RoboTwin의 전문가 코드 생성으로 play_once()를 얻어도 새 과제의 정의가 모두 완성된 것은 아닙니다. 공식 안내에서 자동 생성하는 부분은 로봇의 동작 순서입니다. 장면을 준비하고 물체를 배치하며 성공을 판정하는 메서드는 별도로 구현해야 합니다. 이후 학습된 정책을 평가한다면, 정책의 행동 표현과 시뮬레이터의 로봇 구성도 맞아야 합니다.
이 글은 ‘코드 파일을 만들었다’에서 ‘무슨 과제를 어떤 로봇으로 평가하는가’로 넘어갈 때 남는 작업을 설명합니다. 합성 장면과 행동 궤적의 차이는 합성 데이터와 로봇 학습에서 더 넓게 다룹니다.
생성기는 동작 순서를 채운다
2026년 10월 15일 확인한 RoboTwin Expert Code Generation 문서는 play_once()만 생성 대상으로 명시합니다. setup_demo(), load_actors(), check_success()는 사용자가 구현할 영역입니다. 문서의 템플릿에서 각 메서드는 다음 역할을 갖습니다.
| 메서드 | 맡는 일 | 그 결과만으로 알 수 없는 것 |
|---|---|---|
setup_demo() |
에피소드 시작 시 시뮬레이션 환경 준비 | 목표 작업을 달성했는지 |
load_actors() |
장면에 필요한 물체를 불러오고 초기 배치 구성 | 정책의 행동이 적절한지 |
play_once() |
로봇이 수행할 동작 순서 | 최종 상태가 성공 조건을 만족하는지 |
check_success() |
과제의 성공 여부 판정 | 다른 로봇·현실 환경에서도 같은 결과인지 |
표의 마지막 열은 역할 구분을 위한 해석입니다. 어느 메서드가 있다는 사실만으로 다른 메서드의 책임까지 충족되지는 않습니다.
예를 들어 병을 목표 구역에 세워 놓는 가상의 과제를 만든다고 합시다. 병을 잡고 이동하고 놓는 동작은 play_once()에 들어갈 수 있습니다. 그러나 ‘성공’을 병의 중심이 구역 안에 들어온 상태로 볼지, 똑바로 서 있고 그리퍼에서 놓인 상태까지 요구할지는 과제 정의의 문제입니다.
성공 판정이 위치만 본다면 병이 누워 있어도 성공으로 처리될 수 있습니다. 반대로 의도한 작업과 무관한 조건을 추가하면, 잘 수행한 시범도 실패로 처리할 수 있습니다. 이는 RoboTwin에서 관측한 오류 사례가 아니라, 사용자가 성공 조건을 구현해야 하는 이유를 보여주는 예시입니다.
오류를 고치는 생성 방식도 성공 기준을 대신 정하지 않는다
공식 안내에는 기본 생성, 오류 피드백을 이용한 반복 수정, 다중 모달 관측을 이용한 수정 경로가 나옵니다. 생성된 파일은 envs_gen에 저장됩니다. 오류를 받아 코드를 수정하는 기능은 유용하지만, 올바른 작업의 정의가 자동으로 보장된다는 뜻은 아닙니다.
특히 성공 판정이 생성 과정의 피드백으로 사용된다면 판정 함수의 의미가 더 중요해집니다. 병을 구역에 눕혀 놓아도 성공으로 받아들이는 기준 아래에서는, 생성기가 그 기준을 만족하는 동작을 찾더라도 독자가 원한 ‘세워 놓기’ 과제를 해결한 것이 아닐 수 있습니다.
따라서 새로운 과제를 준비할 때는 성공으로 받아들일 상태와 받아들이지 않을 상태를 먼저 구분하는 편이 좋습니다. 앞의 예시라면 구역 안에 선 병, 구역 밖에 선 병, 구역 안에 누운 병을 서로 어떻게 판정할지 명시할 수 있습니다. 이 상태들은 검사 설계를 설명하기 위한 예이며, 여기서 실제 시뮬레이션을 실행해 확인한 결과는 아닙니다.
정책 평가로 넘어가면 두 설정의 주인을 나눈다
전문가 동작 코드를 생성하는 경로와 학습된 정책을 평가하는 경로는 구분해야 합니다. RoboTwin의 XPolicyLab 안내는 정책 평가를 scripts/eval_policy.sh로 연결합니다. 여기에서 --env-cfg-type은 XPolicyLab의 행동 프로파일을 선택하고, 시뮬레이터의 로봇 구성은 --task-config가 제어한다고 설명합니다.
따라서 --env-cfg-type의 이름을 바꿨다는 이유만으로 시뮬레이터 안의 로봇까지 바뀌었다고 판단하면 안 됩니다. 정책 쪽에서 해석하는 행동과 실제 시뮬레이터 구성을 따로 확인해야 합니다. 문서가 예로 드는 arx_x5는 기본 aloha-agilex 배치와 맞는 행동 프로파일입니다. 임의의 다른 로봇에도 그대로 맞는다는 일반 규칙이 아닙니다.
행동 종류도 별도의 선택입니다. 문서의 action_type은 정책이 내보내는 행동 공간을 가리키며 joint 또는 ee 같은 값을 사용합니다. 관절 행동을 내보내도록 학습한 정책을 말단장치 행동으로 해석한다면, 같은 길이의 배열을 전송할 수 있다는 사실만으로 의미가 맞지는 않습니다.
여기서 확인하려는 것은 정책 서버가 응답했는가만이 아닙니다. 그 응답이 어느 로봇 구성에서 어떤 종류의 명령으로 해석되는가입니다. 새 정책의 평가 결과가 이상하다면 모델 성능을 판단하기 전에 이 연결을 확인할 이유가 있습니다.
병을 놓는 과제를 끝까지 연결하면
가상 과제의 흐름을 다시 이어 보겠습니다. 장면 준비에서 병과 목표 구역을 배치하고, 생성된 play_once()가 동작을 수행하며, 별도로 구현한 check_success()가 정해 둔 최종 상태를 판단합니다. 이 동작으로 데이터를 준비하고 정책을 학습했다면, 정책 평가 단계에서는 학습 때의 행동 표현과 XPolicyLab 프로파일, 시뮬레이터의 로봇 구성을 연결합니다.
이 중 하나가 달라지면 문제가 생긴 위치도 달라집니다. 잘못 놓인 초기 물체는 장면 문제이고, 부적절한 동작 순서는 생성 코드 문제이며, 누운 병을 성공으로 받는 것은 판정 문제입니다. 정책 명령을 다른 행동 표현으로 읽는 것은 평가 연결 문제입니다. 생성 파일이 존재한다는 한 가지 결과로 이 네 문제를 구분할 수는 없습니다.
문서 확인은 구현 범위를 정하는 근거입니다. 이 글에서는 RoboTwin 코드 생성, 시범 수집, 정책 평가나 실제 로봇 동작을 실행하지 않았습니다. 생성된 동작의 성공과 그 동작을 학습한 정책의 성공, 실제 장치로의 이전은 각각 해당 조건에서 확인해야 할 결과입니다.