로봇 평가의 시계는 언제 흐르는가 — RobotWorld에서 실기 시험까지

2026년 10월 7일 공개된 RobotWorld는 조작·이동 조작·보행·주행·비행을 포함하는 84개 시뮬레이션 과제로 범용 멀티모달 에이전트를 평가한다. 논문 초록과 제출 이력

이 글의 질문은 개발자가 이 평가를 자신의 로봇 인터페이스에 어떻게 옮길 것인가다. 작업 지시를 잘 해석했다는 사실만으로는 배치 판단을 내리기 어렵다. 관측을 언제 받았고, 무엇을 명령할 수 있었으며, 어느 시점의 상태를 성공으로 인정했는지가 함께 있어야 실패를 재현할 수 있다.

이하에서는 원문에서 확인한 사실을 출처와 함께 짧게 제시하고, 그 뒤의 실무 제안을 별도로 표시한다. 제안은 이 글에서 수행한 실험 결과가 아니다. 기존의 VLA 구조나 에이전트 평가 개론을 반복하기보다, 로봇 실행의 시간과 판정 경계를 구체화하는 데 집중한다. 기준일은 2026-10-20 KST이며 프리프린트의 결과를 현장 성능 보증으로 해석하지 않는다.

Code as Policies는 언어 모델이 지각 결과를 처리하고 제어 primitive API를 조합하는 정책 코드를 생성하는 접근을 제시했다. 피드백 루프와 계층적 함수 생성을 포함한다. Code as Policies 초록

실무 제안. 평가 대상의 경계를 다음처럼 문서화하자. 모델은 목표와 관측으로 프로그램을 작성하고, 실행기는 허용된 API를 호출하며, 제어기는 주기적으로 명령을 적용한다. 이 중 어디에 경로 생성기나 물체 위치 추정기가 들어가는지까지 그려야 한다. 같은 자연어 지시를 해결하더라도 제공된 도움의 범위가 다르면 같은 문제를 풀었다고 보기 어렵다.

예를 들어 place(object, target)를 제공한 시험과 관절 목표를 직접 지정하는 시험은 구분해 보고한다. 전자는 조작 primitive 선택을, 후자는 더 세부적인 제어 결정을 요구하도록 설계할 수 있다. 코드가 문법적으로 유효한지, API 인자가 유효한지, 실행 후 물체가 원하는 상태인지도 각각 기록한다. 이렇게 해야 실패가 코드 생성, 인터페이스 사용, 물리적 실행 중 어디에 속하는지 다음 실험에서 분리할 수 있다.

RobotWorld는 관측·행동·제어 보조·예산·평가기를 과제 계약에 포함한다. RobotWorld §3.1

실무 제안. 다음 표를 자체 시험의 최소 명세로 사용하자. 표의 항목은 구현 예시이며 RobotWorld의 배포 설정을 복사한 것이 아니다.

명세에 식별자를 부여하고 결과 파일이 이를 참조하게 만들면 모델 교체 전후를 비교하기 쉬워진다. 비교 도중 카메라를 추가했다면 모델 개선만으로 성능 차이를 설명하지 않는다. 반대로 모델은 그대로 두고 관측만 바꾼 실험이라면 시스템 변경 효과로 보고할 수 있다. 실행 로그와 명세의 연결이 끊긴 결과는 재현 가능한 비교에서 보류하는 편이 낫다.

RobotWorld에서는 추론과 오프라인 계산 중 물리가 멈춘다. 제어 스텝·도구 호출·벽시계 시간은 서로 다른 자원이다. RobotWorld §3.4

실무 제안. 같은 작업을 두 가지 모드로 시험하자. 첫 모드는 추론 동안 장면을 정지시켜 관측에서 행동으로 이어지는 판단을 점검한다. 두 번째 모드는 장면을 계속 진행시켜 지연이 있는 조건에서 작업을 수행하게 한다. 두 모드의 차이를 모두 모델의 추론 능력 차이로 해석하면 안 된다. 두 번째 시험에는 실행기와 하위 제어기의 지연 대응까지 들어간다.

기록은 capture_time → inference_start → command_accept → actuation_end 순서로 연결한다. 각 시각의 시계 종류와 동기화 오차도 명세에 남긴다. 명령을 적용할 때 관측이 얼마나 오래되었는지 계산할 수 있어야 한다. 허용 가능한 관측 나이는 작업별 요구사항으로 정하고, 이를 넘었을 때 재관측·명령 폐기·정지 중 무엇을 수행할지 시험 전에 결정한다. 이 글은 보편적인 지연 임계값을 제시하지 않는다.

Code as Policies의 정책 프로그램은 지각 출력을 받아 반응형 제어를 표현할 수 있다. 논문 초록

실무 제안. 도구 호출 수만 줄이는 최적화는 평가 목표로 부족하다. 한 호출이 짧은 동작 하나인지, 상태를 반복 확인하는 프로그램인지부터 구분한다. 프로그램에 허용한 반복 수, 관측 접근, 정지 조건과 제어 명령 범위를 결과와 함께 저장한다. 그래야 호출을 묶어서 얻은 이득과 작업 자체를 적은 움직임으로 해결한 이득을 따로 분석할 수 있다.

비교 실험은 같은 초기 상태에서 직접 명령 방식과 제한된 코드 실행 방식을 각각 적용하는 형태로 설계할 수 있다. 성공 여부 외에 실제 수행 스텝, 재관측 횟수, 중단 사유를 수집한다. 이때 코드 실행에만 더 풍부한 상태값을 제공하면 두 요인이 동시에 바뀌므로 그 사실을 밝혀야 한다. 장시간 프로그램이 중간 오류를 숨기지 않도록 진행 기록도 남긴다. 이는 새 시스템의 시험 제안이며, 어느 방식이 우수하다는 측정 결과는 아니다.

RobotWorld의 성공 검사는 실행 궤적의 상태와 사건을 사용한다. 에이전트의 완료 선언만으로 성공이 되지는 않는다. RobotWorld §3.4·§4.3

실무 제안. 선반에 물체를 놓는 자체 시험을 가정하자. 평가기는 목표 영역 포함 여부, 지지 상태, 손에서 놓였는지, 필요한 유지 시간이 충족됐는지를 검사하도록 설계할 수 있다. 이것은 설명용 예시이며 실제 임계값은 물체·선반·센서에 맞춰 정해야 한다. 카메라에서 잠깐 겹쳐 보였다는 이유로 성공을 확정하지 않도록 판정 근거를 보존한다.

평가기 자체에도 대조 사례를 넣자. 물체를 목표 위치에 계속 잡고 있는 경우, 놓았지만 곧 떨어지는 경우, 잘못된 물체를 놓은 경우가 모두 통과한다면 성공 정의가 불완전할 수 있다. 사람이 정답을 확인한 소규모 사례부터 판정기를 점검하고 불일치 사례를 모은다. 센서가 충분한 증거를 주지 못한 결과는 미확인으로 남긴다. 미확인을 성공으로 계산하지 않되, 과제 실패와 계측 실패의 비율은 따로 공개해야 다음 수정 방향을 결정할 수 있다.

EmbodiedBench는 고수준 의미 과제와 저수준 행동 과제를 구분하고, 시각·언어 조건을 바꾸는 ablation을 다룬다. EmbodiedBench §4·§5

실무 제안. 자체 로봇 평가에서도 지시 해석과 자세 보정에 필요한 관측을 구별해 보자. 첫 시험은 현재 이미지, 두 번째는 이미지와 최근 행동, 세 번째는 여기에 허용된 상태값을 추가한다. 과제와 예산을 고정하고 어느 실패 유형이 줄었는지 기록한다. 입력을 많이 줬을 때 성공한 사례 하나로 전체 설계를 바꾸기보다, 추가 정보가 없던 경우와 짝을 이루는 비교가 필요하다.

관측 패킷에는 촬영 시각과 에피소드 식별자를 붙인다. 이전 프레임을 새 프레임처럼 전달하거나 다른 실행의 상태값을 섞으면 모델의 판단을 해석하기 어려워진다. 또한 평가기만 쓰도록 정한 정답 상태가 에이전트 입력으로 유입되지 않게 입력 경로를 점검한다. 이 절은 정보량을 늘리면 성능이 오른다는 주장이 아니라, 어떤 정보가 실제로 필요한지 검증하기 위한 설계다.

RobotWorld는 명령 거부와 실행됐지만 의도한 효과가 없는 경우를 구별할 피드백을 다룬다. RobotWorld §3.3

실무 제안. 자체 실행기에는 invalid_request, executed_no_progress, observation_unavailable, budget_exhausted처럼 원인을 드러내는 결과를 두자. 이 이름들은 제안한 예시이며 논문의 API 명칭이 아니다. 오류 메시지를 그대로 길게 전달하는 것보다, 실행 여부와 마지막으로 확인한 상태를 함께 주는 편이 후속 시험을 설계하기 쉽다.

재시도는 실패를 인정한 뒤에만 추가하고 전체 허용량에 포함한다. 성공한 마지막 시도만 기록하면 사용한 자원과 초기 실패가 사라진다. 예산을 늘린 실험은 기존 시험과 별도의 조건으로 보관하고, 성공률 변화와 수행량 변화를 함께 비교한다. 복구가 있었다면 재관측했는지, 행동을 바꿨는지, 같은 명령을 반복했는지 로그에 표시한다. 어느 복구 규칙이 유효한지는 반복 시험으로 확인할 사안이며, 이 글에서 개선 폭을 추정하지 않는다.

EmbodiedBench는 여러 환경과 능력별 부분집합으로 평가를 구성한다. EmbodiedBench 초록

실무 제안. 자체 보고서에는 과제군별 성공 건수와 전체 실행 건수를 먼저 적는다. 조작과 주행의 구성 비율이 바뀌면 전체 평균이 달라질 수 있으므로, 서로 다른 시험 묶음의 평균을 바로 비교하지 않는다. 같은 초기 조건을 반복한 결과와 새 장면으로 확장한 결과도 구분한다. 반복 수를 공개하고 불확실성을 표현할 통계 방법을 사전에 정한다.

효율 지표는 성공한 실행끼리의 비교와 전체 실행의 자원 소비를 함께 보여준다. 빨리 종료된 실패가 효율적인 성공처럼 보이지 않도록 성공 여부를 그래프의 조건에 포함한다. 예를 들어 행에는 과제군, 열에는 성공/전체·중단 사유·제어량·경과 시간을 둘 수 있다. 새로운 모델의 우위를 주장하려면 단지 평균이 높다는 사실에 더해 과제 구성과 도움 수준이 같은지 확인해야 한다. 여기서는 논문 간 순위나 모델 간 성능 우열을 계산하지 않는다.

RobotWorld는 실기 전이와 실시간 제약을 미해결 검증 대상으로 남긴다. RobotWorld §7

실무 제안. 첫 단계는 정지형 시뮬레이션에서 명세와 평가기를 점검하는 것이다. 다음에는 장면을 계속 진행시키고 지연·관측 누락 조건을 바꾼다. 이후 제한된 실기 환경에서 같은 명세로 반복하되, 물리 환경에서 직접 관측할 수 없는 판정 조건은 계측 방식과 함께 다시 정의한다. 시뮬레이터 내부의 정답 상태를 실기에서도 얻을 수 있다고 가정하지 않는다.

진행 기준은 실제 사용 요구에서 정해야 한다. 종료 조건 준수, 관측 유효성, 작업 결과를 설명할 기록이 없으면 원인 분석을 먼저 한다. 통과하더라도 새로운 물체·배치·외란에 대한 일반화는 별도 시험이다. 이 글은 모델 가용성, 소프트웨어 라이선스, 실기 성공률을 검증한 자료가 아니며 해당 항목을 추정하지 않는다.

다음 실험의 산출물은 작게 잡을 수 있다. 과제 명세 하나, 시간축이 연결된 실행 로그, 독립 판정 결과, 실패 재현 사례를 한 묶음으로 남기자. 그러면 다음 모델이나 실행기 변경이 무엇을 개선했는지 같은 질문으로 다시 검사할 수 있다.