서문에서 이 시리즈가 “AI와 협업하는 감각”을 기르는 연습 문제집이 되길 바란다고 했습니다. 이 부록은 그 실습편입니다. 코딩 에이전트든 챗봇이든, AI에게 이 시리즈의 작업을 시켜 본다면 무엇을 어떻게 시키고, 답을 받으면 무엇을 되물어야 하는지 — 본문에서 우리가 겪은 일들을 그대로 질문 기술로 번역했습니다.
두 가지 원칙부터
이 부록의 예시 전부를 관통하는 원칙은 둘뿐입니다.
원칙 1 — 시킬 때는 제약과 검증 기준을 함께 준다. “걷게 해줘”가 아니라 “걷게 해줘, 성공 기준은 10초간 낙상 0회에 평균 속도 0.4m/s 이상”이라고 시킵니다. 기준이 없으면 AI는 가장 쉬운 해석을 고릅니다 — 보상 해킹(R01)이 채점표의 빈틈을 찾듯, 모호한 지시의 빈틈을 찾는 것도 같은 최적화입니다.
원칙 2 — 받을 때는 대리 지표가 아니라 직접 지표를 요구한다. “됐습니다”라는 보고와 그럴듯한 영상은 증거가 아닙니다(10편, 17편). 주장하는 것을 가장 직접적으로 재는 숫자를 달라고 하세요.
예시 1. 코드 개조 시키기 — 제약을 함께 담는 법
02~06편의 상황: 공식 go2(4족) 예제를 G1(2족)용으로 옮겨야 합니다.
시키기: “Genesis의 go2 보행 학습 예제를 Unitree G1용으로 개조해줘. 주의할 제약: G1은 다리·허리·팔 관절이 DOF 인덱스에 뒤섞여 있어서 go2처럼 연속 슬라이스로 못 잡아. 관절 이름으로 인덱스를 매핑하는 방식으로 일반화해줘. 완료 기준: 다리 12관절만 정책이 제어하고, 나머지는 PD로 기본자세 고정.”
제약(“인덱스가 뒤섞여 있다”)을 빼고 시키면, AI는 go2의 슬라이스 방식을 그대로 옮기고 “됐습니다”라고 할 확률이 높습니다. 코드는 돌아가지만 팔 관절을 다리로 착각한 채로요. 내가 아는 함정은 지시문에 미리 심어 두는 것이 협업의 절반입니다.
예시 2. 채점표 허점 찾기 시키기 — 셔플을 미리 잡는 질문
06편에서 우리는 보상표를 짜고 바로 학습을 돌렸고, 그 결과가 10편의 셔플이었습니다. 학습 전에 이렇게 물었다면 어땠을까요.
시키기: “이 보상 항목들(속도 추종 +, 출렁임 −, 키 유지 −, …)로 학습하면, ‘걷지 않고도’ 만점을 받는 행동이 가능할까? 최적화기의 입장에서 이 채점표의 빈틈을 세 가지 상상해봐.”
AI는 이런 ‘만약에’ 놀이에 꽤 능합니다 — “발을 끌며 미끄러지면 출렁임 벌점을 피하면서 속도를 낼 수 있다” 같은 답이 나올 수 있고, 그러면 셔플을 40분짜리 학습 전에 공짜로 잡는 겁니다. 설계안을 만들자마자 같은 AI에게 그 설계를 공격하게 시키는 것은 보상표 말고도(실험 설계, 글의 논리) 어디에나 통합니다.
예시 3. 실험 설계 상담 — 원리를 아는지 확인하며 묻기
08편의 상황: 로봇이 회전 명령을 무시합니다.
시키기: “회전 명령을 알아듣게 하려면 보상을 바꿔야 할까, 학습 중 명령 분포를 바꿔야 할까? 각각 무엇이 달라지는지 근거와 함께 비교해줘.”
정답이 하나인 질문(“어떻게 고쳐?”)보다 선택지를 놓고 근거를 요구하는 질문이 낫습니다. 답에 “신경망은 변하지 않는 입력을 무시한다”(08편)에 해당하는 근거가 들어 있으면 원리를 알고 답한 것이고, 근거 없이 한쪽만 권하면 더 캐물어야 한다는 신호입니다.
예시 4. 성공 보고 되묻기 — 이 시리즈의 심장
우리가 두 번 속을 뻔했던 지점입니다(10편의 셔플, 17편의 가짜 등반). 두 사건을 그대로 되묻기 견본으로 쓸 수 있습니다.
보고: “학습 완료. 로봇이 잘 걷습니다. 영상 첨부합니다.”
되묻기: “영상 말고 수치로 보자. 걸음 빈도, 발 들림 높이, 보폭, 좌우 발 간격을 재서 사람 보행 수치와 나란히 표로 보여줘.”
보고: “계단 등반 성공. 몸통 높이가 15초에 +0.56m 올랐습니다.”
되묻기: “몸통 높이는 대리 지표야. 발밑 지면 높이를 매초 기록해서 단조 상승하는지 보여주고, 상승률이 계단 기하와 맞는지 대조해줘. 그리고 지면 높이에서 찍은 영상도.”
첫 되묻기는 8Hz 셔플을, 둘째 되묻기는 물리 엔진 튕김을 잡아냈습니다. 패턴은 같습니다: “그 주장을 가장 직접적으로 재는 지표가 뭐지?”를 묻고 그것을 요구한다. 덤으로, 측정 스크립트가 새로 만들어졌다면 “답을 아는 곳(평지)에서 그 측정을 먼저 돌려봐”까지 시키면 17편의 좌표계 사고도 예방됩니다.
예시 5. 실패 진단 시키기 — 탐색 순서를 지정하는 법
15편의 상황: 지형에서 학습이 붕괴했습니다(보상 3.0, 제자리 버티기).
시키기: “지형 위 학습이 무너졌어. 보상 튜닝은 마지막 수단이야. 순서대로: (1) 지형 요철 크기를 실측해서 로봇 보폭과 비교하고, (2) 스폰 직후 파묻힘·튕김이 없는지 확인하고, (3) 그래도 원인이 안 나오면 그때 보상을 보자.”
진단 순서를 지정하지 않으면 AI는 가장 익숙한 손잡이(보상 가중치)부터 돌리기 쉽습니다. 15편의 실제 원인은 보상이 아니라 지형(±25cm 산악)이었고, 측정 한 번이 튜닝의 늪에 빠지는 걸 막아 줬습니다. 환경부터, 명세부터, 그다음이 학습이라는 순서 자체를 지시에 넣으세요.
되묻기 요약
성공 보고를 받을 때마다 다섯 가지를 순서대로 물으면, 이 시리즈에서 우리가 겪은 함정의 대부분이 걸러집니다.
- 그 주장을 가장 직접적으로 재는 지표는 무엇인가 — 그것을 쟀는가?
- 그 측정 도구는 답을 아는 상황에서 검증됐는가?
- 같은 결과가 반복되는가 (다른 씨드, 다른 시행)?
- 이 개선으로 이전에 되던 것이 무너지지 않았는가 (회귀 검증)?
- 채점하지 않은 자유도는 지금 어디로 갔는가?
이 다섯 질문은 로봇 RL에만 통하는 게 아닙니다. AI에게 무엇을 맡기든 — 코드든, 분석이든, 글이든 — 보고와 실체 사이의 틈은 늘 같은 자리에서 생기니까요.
이 시리즈의 전체 글 목록 → 시리즈 목차