로봇이 시뮬레이션 연습으로 스킬 코드를 스스로 고쳐 실물에서 성공한다

무엇인가

로봇이 다양한 조작 과제를 안정적으로 수행하려면 스킬을 만들고 유지하고, 보상을 설계하고, 지각과 제어를 통합하는 데 사람 손이 많이 든다. 언어모델 기반 로봇 제어는 코드 실행과 온라인 추론 사이에서 줄타기를 한다. Code-as-Policy 계열은 지각·제어 프리미티브를 실행 가능한 프로그램으로 묶어 빠르게 돌리지만, 파지 성공 여부 같은 견고한 심볼릭 판정을 프로그램 논리만으로 명시하기 어렵다. 반대로 Agent-as-Policy는 MLLM을 제어 루프에 남겨 유연한 시각·의미 추론을 얻는 대신 저수준 결정마다 모델을 호출해 느려진다. 이 논문은 반복 실행은 재사용 가능한 코드에 맡기고, 시각·의미 판단이 필요한 결정에만 멀티모달 추론을 쓰는 쪽으로 이 둘을 합치려 한다.

어떻게 동작하나

제안 시스템 RPG는 Reconstruct, Practice, Go Real 세 단계를 Constructor, Runtime Agent, Privileged Agent, Video Analyzer, Implementor, Merger 여섯 에이전트로 운영한다. 실행 시스템은 S_r = (L_r, ρ_r), 즉 공유 스킬 라이브러리와 그 스킬을 어떻게 쓸지 지시하는 시스템 프롬프트의 쌍으로 정의되고, 모델 가중치는 연습 내내 고정된다. Reconstruct 단계에서 Constructor는 오프라인 데이터셋(이 논문은 193개 과제를 담은 ABC를 쓴다)에서 유용하고 다양한 조작 능력을 드러내는 소스 과제를 고르고, 과제당 3~8개 궤적의 영상과 텍스트 설명을 검토해 시뮬레이션 연습 과제를 제안한다. 원 궤적이나 장면 기하를 그대로 재현할 필요는 없고, 소스 과제의 일부나 유사한 조작이면 된다. 예를 들어 선글라스 정리하기는 뚜껑이 열린 채 채워진 케이스를 닫는 과제로 바뀐다. MuJoCo와 YAM 로봇 모델로 환경을 만들고 과제마다 check_success 함수를 작성하며, 연습 시작 전에 사람이 그 함수가 의도한 목표를 측정하는지 확인한다. 초기 라이브러리는 CaP-X의 저수준 도구 9개에 Constructor가 만든 상위 스킬 6개(pick, place, pick-and-place, 테이블 지지 양팔 전달, move-above, push)를 더한 15개다.

무엇과 다른가

Practice 단계에서 Runtime Agent는 배포 로봇에서 얻을 수 있는 관측만으로 스킬과 인자를 고르고, Privileged Agent는 같은 모델과 같은 스킬 라이브러리를 쓰되 시뮬레이터 상태(물체 이름, 포즈, 크기, 속도, 천 모서리 위치)까지 받아 별도 에피소드를 돈다. Video Analyzer는 실패한 Runtime 실행을 Privileged 실행, 그리고 가능하면 데이터셋의 소스 영상과 비교해 첫 실패 지점을 찾고 구체적 변경안을 근거 프레임·트레이스와 함께 제시한다. Implementor는 그 진단을 받아 새 스킬 추가, 기존 스킬 수정, 시스템 프롬프트 개정 후보를 만든다(성공이 5회 미만인 개발 과제마다 최대 1개). 후보는 22개 과제 × 고정 개발 시드 5개 = 110 에피소드로 평가하는데, 평균 성공률이 오르고(ΔĴ > 0) 어떤 과제도 5회 중 1회를 넘게 잃지 않을 때(min_i Δq̂_i ≥ -0.20) 통과한다. 통과 후보는 Merger가 병합하고, 병합본을 다시 같은 기준으로 검증해 남길지 결정한다. 이 루프를 15라운드 돈다.

어떻게 쓰나

평가는 22개 조작 과제의 held-out 시드 10개씩, 총 220 에피소드로 이뤄진다. 1라운드 63/220(28.6%)에서 15라운드 209/220(95.0%)까지 오른다. 같은 조건에서 ASPIRE는 166/220(75.5%), CaP-Agent0에 GPT-6 Astra Pro를 붙인 구성은 132/220(60.0%), Gemini 3.8 Flash를 붙인 CaP-Agent0는 107/220(48.6%), RATs는 92/220(41.8%)다. 라운드 4에서 CaP-Agent0의 네 가지 모델 구성을 모두 넘고, 라운드 5에서 78.2%로 ASPIRE의 최종 수치를 앞선다. 22개 과제 중 17개에서 10회를 모두 성공했고, 실패 11건 중 7건이 타월 접기에 몰려 있어 변형체 조작이 남은 주된 실패 모드다.

전제와 한계

시스템에서 실제로 무엇이 바뀌는지도 보고된다. 15라운드 동안 스킬 라이브러리는 15개에서 38개로 늘고, 신규 스킬 23개와 기존 스킬 수정 66회가 기록된다. 시스템 프롬프트는 첫 4라운드에서 개정되는데, 가장 큰 폭의 개선은 3라운드에서 4라운드 사이 43.2%에서 73.6%로 오르는 구간이고 이 라운드에는 스킬 수정이 없다. 새 프롬프트가 유계 지각-행동 루프를 도입하고 남은 상호작용 예산을 추적하게 만들어, 에이전트가 관측을 반복 요청하는 대신 현재 추정으로 행동하게 된 효과다. 프롬프트가 고정된 뒤 4라운드에서 15라운드 사이에 기존 스킬 60회 수정으로 21.4%p가 더 오른다. 즉 라이브러리 확장과 공유 스킬 구현 수리가 둘 다 기여한다. 곡선은 단조롭지 않아 6라운드와 14라운드에서 성공 수가 1개씩 줄어드는데, 개발 시드 5개 검사를 통과한 수정이 held-out 시드 10개에서는 모든 결과를 개선하지는 못한 경우다.

진단 입력의 기여를 분리한 실험에서 5라운드 기준 full RPG는 172/220(78.2%)인 반면, Video Analyzer를 뺀 변형은 114/220(51.8%), Privileged Agent를 뺀 변형은 112/220(50.9%), 둘 다 뺀 변형은 112/220(50.9%)다. 각각 26.4%p, 27.3%p 하락이고, 단일 제거 변형이 둘 다 제거한 변형과 0.9%p 이내로 붙어 두 구성요소가 상보적 정보를 준다는 해석이 붙는다. 런타임 모델·프롬프트·지각 구현·에피소드 예산을 고정하고 라이브러리만 교체한 통제 비교에서는 4개 과제 10개 초기화에서 26/40에서 37/40으로 27.5%p 오르고, 기존 동작을 지켜야 하는 bottle placement는 10/10을 유지한다. Privileged scripted caller로 바꿔도 19/40에서 39/40으로 오른다. 개별 수리 사례로 lift 스킬은 수정 전 13회 호출 중 12회 실패했지만 수정 후 11회 전부 성공한다. 다만 ABC sorting에서는 6/6이 5/6으로 국소 퇴행해, 공유 스킬 수정은 완전한 과제 수준 행동으로 평가해야 한다는 근거가 된다.

실물 전이는 YAM 로봇에서 세 과제(공을 서랍에 넣고 닫기, 타월 접기, 양손 그릇 전달)를 각 10회씩 평가한다. RPG는 30회를 모두 성공했다. CaP-Agent0에 GPT-6 Astra Pro를 붙인 구성은 서랍 과제 4/10, 그릇 전달 1/10, 타월 접기 9/10이고, Gemini 3.8 Flash 구성은 공을 서랍 안에 넣는 데는 7/10 성공하지만 닫기는 3/10, 그릇을 전달 위치로 옮기는 데는 6/10이지만 핸드오버는 0회다. 추가로 가위 펴기, 마커 뚜껑 열기, 티슈 뽑기, 화이트보드 지우기, 병뚜껑 풀기 5개 과제를 과제별 실물 튜닝 없이 정성적으로 배포한 사례도 보고한다. 개발자 입장에서 이 논문의 요점은 개선 대상이 모델 가중치가 아니라 프롬프트와 스킬 코드라는 것, 그리고 후보 변경을 과제별 회귀까지 포함해 검증하는 게이트를 둔다는 것이다. 시뮬레이터 특권 상태는 진단에만 쓰이고 배포 시에는 Runtime Agent만 남는다는 점, 실물 평가 전에 좌표 캘리브레이션과 하드웨어 적응(패드 오프셋, 빈 그리퍼 개구부)을 공통으로 거치고 객체·과제별 튜닝은 하지 않는다는 점도 함께 봐야 한다.

저자들이 밝힌 병목은 두 가지다. 라운드마다 22개 과제 전체에 대해 Runtime Agent와 Privileged Agent 궤적을 모아야 하는데 API 레이트 리밋이 병렬 롤아웃을 제약한다. 과제 집합이 커지면 공유 스킬에 대한 중복 수정과 의존성이 통합을 어렵게 만든다. 향후 과제로 쿼터를 인식한 롤아웃 스케줄링과 의존성을 고려한 제안 통합을 제시한다. 또한 자기개선은 전부 시뮬레이션에서 이뤄지고 배포 전에 시스템을 동결하며, 설정, 평가자 확인, 연습 중단 결정, 하드웨어 적응은 사람이 맡는다.