ToyBlocks 분석: 로봇이 실패했을 때 계획과 동작을 나눠 보는 법

성공 영상 다음에 물어야 할 질문

작업대 위의 빨간 블록을 파란 블록 위에 올리는 로봇을 생각해 보자. 실패한 영상에서는 빨간 블록이 파란 블록 옆에 놓여 있다. 이 장면만 보고 “더 큰 모델이 필요하다”거나 “집기 데이터를 늘리자”고 결정하면 서로 다른 문제에 같은 처방을 내리게 된다.

계획기가 처음부터 ‘옆에 놓기’를 지시했는지, ‘위에 놓기’라는 올바른 지시를 동작기가 수행하지 못했는지부터 구분해야 한다. 처음에는 제대로 쌓았지만 종료 전에 다시 건드렸을 가능성도 있다. 마지막 화면은 같아도 필요한 수정은 다르다.

Ai2는 2026년 11월 6일 ToyBlocks를 공개했다. 로봇 팔과 탁상 블록을 다루는 시뮬레이션 환경으로, 자동 시연 데이터 생성과 학습·평가를 연결한다. 넓은 현실을 한 번에 재현하기보다 좁은 환경의 조건을 바꾸며 실패를 조사하는 FoundationWorlds 구상의 첫 사례다. 공식 발표

이 글은 11월 7일 확인한 문헌 분석이다. 로봇이나 시뮬레이터를 직접 실행하지 않았다. 아래 블록 과제와 진단표는 테크독해가 구성한 가상 평가 설계이며, 특정 모델의 성능 결과가 아니다. 독자가 가져갈 결과는 실패를 분해하는 비교 순서와 다시 쓸 수 있는 기록지다.

계획을 고르는 모델과 팔을 움직이는 모델

ToyBlocks의 공개 저장소는 상위 정책이 다음 행동을 정하고 하위 정책이 팔을 제어하는 구성을 설명한다. 여기서 정책은 관측을 받아 행동을 선택하는 규칙 또는 모델이다. 공개 학습 경로에는 하위 시각·동작 정책인 ManiFlow가 포함된다. 시연 데이터는 LeRobot 형식으로 기록하며, README의 기술 보고서 링크는 확인 시점에 ‘coming soon’으로 표시되어 있었다. 고정 커밋 README

빨간 블록을 쌓는 예에서는 상위 단계가 “빨간 블록을 집어 파란 블록 위에 놓는다”라는 선택을 맡고, 하위 단계가 팔과 집게의 움직임으로 바꾼다고 이해할 수 있다. 실제 연결에는 대상 지점과 행동 형식도 필요하다. 두 단계가 각각 잘 작동해도 대상 좌표나 행동 의미를 다르게 해석하면 전체 과제가 실패할 수 있다.

ToyBlocks 평가 문서는 계층형 구성의 한쪽을 oracle, 즉 비교 기준 역할을 하는 계획기·동작기로 교체하는 방법을 제공한다. 상위 oracle은 PDDL로 표현한 과제의 기호 계획을 사용하고, 하위 oracle은 데이터 생성에 쓰는 동작 계획 기반 기술을 사용한다. 이를 통해 학습된 두 부분을 함께 평가할 때보다 실패 위치를 좁혀 볼 수 있다. 정책 교체 방식

oracle이라는 이름을 ‘현실에서 항상 정답을 내는 로봇’으로 읽으면 안 된다. 문서에는 하위 oracle의 실행 실패도 별도 지표로 남는다. 교체 부품이 사용하는 정보와 도달 가능한 상태가 원래 모델과 다르므로, 결과는 인과관계를 더 조사할 단서다. oracle 실패 기록

같은 실패를 네 가지 구성으로 비교한다

먼저 ‘빨강이 파랑 위에 안정적으로 있고 집게가 놓인 상태’를 목표로 정하자. 주변의 초록 블록은 움직이면 안 된다고 가정한다. 이 문장의 어느 조건을 성공 판정에 넣는지 실험 전에 합의해야 한다. 다음 표는 이 가상 과제에 적용할 비교 순서다.

비교 구성	고정할 것과 바꿀 것	답하려는 질문
기록된 전문가 행동 재생	초기 상태를 복원하고 기록된 행동을 재생	데이터와 평가 환경이 서로 맞는가
학습 계획기 + 학습 동작기	실제 비교 대상 전체를 연결	전체 시스템은 어디서 멈추는가
기준 계획기 + 학습 동작기	상위 선택을 기준 구성으로 교체	올바른 순서·대상 지시가 주어져도 동작이 실패하는가
학습 계획기 + 기준 동작기	하위 실행을 기준 구성으로 교체	동작 부담을 줄여도 잘못된 선택·종료가 남는가

첫 행은 다른 세 행과 같은 의미의 모델 평가가 아니다. 재생은 기록된 행동을 그대로 적용하는 열린 고리 방식이고, 정책 평가는 새 관측에 따라 다음 행동을 고르는 닫힌 고리 방식이다. 재생부터 크게 어긋나면 모델 교체에 앞서 초기 상태·제어 설정·기록의 일치를 점검할 이유가 있다. 재생 성공도 새 상황의 대응 능력을 증명하지 않는다. 공식 재생 문서

가령 전체 구성은 빨간 블록을 잘못 골랐는데 기준 계획기로 교체한 뒤 목표를 달성했다고 하자. 다음에는 상위 모델이 받은 이미지, 대상 지점, 행동 선택을 살펴볼 근거가 생긴다. 이 결과만으로 언어 이해가 유일한 원인이라고 단정할 수는 없다. 기준 계획기는 모델이 보지 못한 상태 정보에 접근했을 수 있기 때문이다.

반대로 상위 선택을 바꿔도 집기가 계속 실패한다면 대상이 실제로 도달 가능한지, 카메라의 지점이 어느 블록을 가리키는지, 하위 모델이 받은 명령의 의미가 맞는지 확인한다. 하위 동작기를 바꿨을 때만 성공하더라도 ‘데이터 부족’으로 바로 결론 내리지 않는다. 제어기·충돌·대상 전달의 차이가 원인일 수도 있다.

두 교체 구성은 각각 성공하는데 둘을 학습 모델로 연결하면 실패할 수도 있다. 이때는 어느 한 모델을 일괄 탈락시키기보다 인계 시점을 조사한다. 하위 단계가 아직 움직이는 중에 다음 지시가 나왔는지, 끝났다는 신호의 뜻이 같은지, 직전 동작이 바꾼 상태를 상위 단계가 새로 관측했는지가 점검 대상이다. 이 사례는 가설이며 ToyBlocks에서 관측한 버그 보고가 아니다.

한 번 쌓았다는 것과 끝까지 유지했다는 것

공식 지표는 success_once와 success_at_end를 구분한다. 전자는 실행 중 성공한 적이 있는지, 후자는 마지막 단계에서도 성공 상태인지다. hl_done은 학습된 상위 모델이 종료 신호를 냈는지 따로 남긴다. 지표의 정의

같은 시간 한도를 끝까지 관찰한다고 가정하면 다음 세 기록은 서로 다른 후속 작업으로 이어진다. 성공 직후 종료하는 설정에서는 이후 무너지는 모습이 기록되지 않으므로, 비교 전에 종료 규칙을 맞춘다.

가상 기록	한 번 성공	종료 시 성공	다음에 확인할 것
쌓고 놓은 뒤 그대로 유지	예	예	종료 선언과 실제 상태가 맞는가
쌓았지만 후속 동작으로 무너뜨림	예	아니오	성공 이후 동작·종료 판단이 왜 계속됐는가
끝내 쌓지 못함	아니오	아니오	계획·대상 전달·동작 실행 중 어디서 막혔는가

진행률도 완료와 다르다. 빨간 블록을 집어 올렸다는 중간 진전이 있어도 파란 블록 위에 놓지 못했다면 물품 인계는 끝나지 않았다. 따라서 진단에는 부분 진전을 쓰되 업무 완료의 의미를 평균 진행률로 대체하지 않는다.

주변 블록을 건드리는 판정도 주의할 부분이다. 이 커밋의 기본 평가에서 collision은 비대상 블록이 2cm 또는 15도보다 크게 이동했는지를 검사한다. 이는 모든 접촉력이나 사람에 대한 위험을 포괄하는 안전 점수가 아니다. 해당 이동을 실패로 처리하는 설정과 판정하지 않는 설정의 성공률을 같은 조건처럼 비교해서는 안 된다. 이동 기반 판정과 별도 접촉 지표

초록 블록을 밀어 공간을 만든 뒤 빨강과 파랑을 쌓은 결과를 생각해 보자. 목표 두 블록만 보면 성공처럼 보이지만, 앞서 정한 ‘주변은 유지’라는 요구에는 어긋난다. 점수보다 먼저 과제에 허용되는 변화를 적어야 하는 이유다.

영상을 늘리는 것과 새 동작을 배우는 것은 다르다

ToyBlocks의 렌더링 단계는 기록된 로봇·물체 자세를 다시 배치해 영상을 만든다. 이 단계에서는 물리를 다시 진행하거나 계획을 다시 세우지 않는다. 같은 실행을 다른 외형으로 여러 번 렌더링할 수 있다는 뜻이다. 렌더링 단계의 역할

따라서 빨간 블록을 집는 동일한 궤적에 배경 열 개를 붙였다고 해서 열 가지 다른 집기 경험이 생긴 것은 아니다. 외형 변화에 견디는지 조사하는 데는 유용할 수 있지만, 닿지 않는 위치에서 팔을 움직이는 경험은 별도로 필요하다. 데이터 행 수만으로 경험의 다양성을 판단하면 이 차이를 놓친다.

실험을 설계할 때는 다음 세 축을 나누는 편이 좋다. 이 표는 공식 벤치마크 결과를 옮긴 것이 아니라, 가상 블록 과제를 위한 자체 분할 제안이다.

바꾸는 축	예시	비교에 남길 구분
외형	같은 자세·동작에 배경과 조명 변경	같은 원본 궤적의 파생 영상인지
공간·물리 조건	블록 시작 위치·크기·마찰 변경	학습 범위 안인지 밖인지, 새 실행인지
과제 조합	두 블록 쌓기에서 더 긴 순서로 확장	본 기술의 재조합인지 새로운 기술인지

원본 궤적을 학습과 평가 양쪽에 나누고 배경만 바꿨다면 ‘본 적 없는 물리적 문제’라고 보고하지 않는다. 원본 에피소드 단위로 분리하고 파생 영상이 어느 쪽에 속하는지 함께 관리한다. 반대로 목적이 외형 변화만의 영향이라면 같은 궤적을 통제 조건으로 쓰는 설계도 가능하다. 무엇을 일반화라고 부르는지에 따라 올바른 분할이 달라진다.

공식 발표 역시 작업 공간 안의 새 배치와 학습 범위 밖의 배치를 구분한다. 실물 로봇으로 옮기는 문제는 여기에 센서·마찰·제어 오차가 추가되는 별도 단계다. 좁은 블록 환경의 결과만으로 창고의 모든 물체를 다룰 수 있다고 결론 내릴 수 없다. 공간 일반화 연구의 범위

첫 평가 전에 고정할 기록지

현재 설치 안내는 NVIDIA GPU가 있는 Linux, CUDA 12.8을 지원하는 드라이버와 Python 3.11을 전제로 한다. Docker 안내도 x86_64 호스트를 요구하며 Apple Silicon용 실행 경로로 제시하지 않는다. 이 글은 해당 환경을 준비하거나 설치 성공을 확인하지 않았으므로 복사 실행용 명령 대신 공식 설치 문서로 연결한다. 설치 전제

같은 초기 상태와 seed를 사용해도 궤적이 비트 단위로 같아진다는 보장은 없다. 공식 문서는 GPU 물리 계산과 병렬 환경의 공유 상태 등을 이유로 들며, 여러 에피소드의 집계 비교와 개별 궤적 디버깅을 구분한다. 한 번 성공한 실행을 그대로 다시 얻지 못했다고 즉시 모델 회귀로 판정하지 않는다. 재현성의 한계

아래 빈칸은 평가 기록지 JSON으로도 제공한다. 자체 작성한 미실행 계획 양식이며 ToyBlocks 설정 파일이나 평가 결과가 아니다.

질문 / 목표 상태 / 움직여도 되는 대상:
코드·하위 모듈 커밋 / 모델 체크포인트 / 데이터 버전:
원본 에피소드 ID / 학습과 평가 분할 / 파생 렌더 연결:
GPU·드라이버·시뮬레이터 / 환경 병렬 수 / 반복 조건:
계획기 / 동작기 / 관측과 대상 전달 형식:
시간 한도 / 종료 규칙 / 주변 블록 이동 판정:
한 번 성공 / 종료 시 성공 / 종료 선언 / 실패 위치:
다음 변경 한 가지 / 유지할 대조 구성:

첫 비교는 전체 과제를 늘리기보다 실패한 질문 하나에서 시작한다. 예를 들어 “블록을 놓은 뒤 왜 다시 건드리는가”라면 종료 선언과 성공 이후의 행동을 남긴다. “새 위치에서만 집지 못하는가”라면 외형은 고정하고 위치를 나눈다. 이렇게 해야 점수가 바뀌었을 때 어떤 선택이 영향을 줬는지 조사할 수 있다.

일회성 시연만 필요한 팀에는 이 평가 환경을 준비하는 비용이 더 클 수 있다. 반면 학습 데이터 구성을 반복해서 바꾸거나 계획기와 동작기의 조합을 고르는 연구팀에는 실패 상태와 조건을 다시 다룰 수 있다는 점이 가치다. 이번 글은 그 연구 설계를 돕는 분석이며 성능 향상이나 개발 시간 절감을 측정한 보고서가 아니다.

문서 속 변경을 따라가는 능력과 물리적 실행을 구분해 읽으려면 StateBench의 상태 추적 분석, 평가 입력을 바꿀 때 판정이 흔들리는 문제는 AI 신규성 심사의 평가 조건으로 이어갈 수 있다. 기록지는 다음 실험에 저장해 두고, 관련 연구는 AI 시스템 모음과 RSS에서 확인할 수 있다.