📃ASPIRE 리뷰

manipulation

llm

code-as-policy

agentic

skill-library

ASPIRE: Agentic /Skills Discovery for Robotics

Published

October 19, 2026

Paper Link (arXiv:2607.00272v1)
Paper PDF (프로젝트 페이지 개정판, 2026-10-16): 이 리뷰가 읽은 판본이다. arXiv에는 2026-10-19 확인 시점까지 v1(2026-06-30)만 올라와 있고, 프로젝트 페이지 PDF는 모델 스케일링·루빅스 큐브·케이스 스터디·역방향 전이가 추가된 개정판이다. 차이는 판본 차이 절에 정리했다.
Code Link (NVlabs/ASPIRE): Apache-2.0. 2026-10-19 확인 시점 main 커밋 fa00f0e(v1.0, 2026-10-15)와 6월 논문 시점 코드인 v0.1이 공존한다. 이 블로그가 LIBERO-Pro 부분을 직접 설치해 1개 태스크 규모로 돌려 본 범위는 재현 노트에 있다.
Project
Runyu Lu*†, Yubo Wu*, Ethan Kou*, Haotian Lin*, Letian Fu, Wenli Xiao, Ajay Mandlekar, Yinzhen Xu, Guanya Shi, Ken Goldberg, Ang Chen, Mosharaf Chowdhury, Jan Kautz, Yuke Zhu†, Linxi “Jim” Fan†, Guanzhi Wang† (* 동등 기여, † 프로젝트 리드)
NVIDIA · University of Michigan · UIUC · UC Berkeley · CMU, arXiv preprint 2026 (학회 채택 표기 없음)

💡 로봇 프로그래밍을 “가중치 학습”이 아니라 코딩 에이전트가 로봇 프로그램을 쓰고, 실행 흔적을 보며 고치고, 검증된 수리법을 텍스트 스킬로 쌓는 지속 학습 문제로 바꾼다.
⚙️ 인지·계획·제어 호출마다 멀티모달 흔적을 남기는 로봇 실행 엔진, 검증자 에이전트가 재현해야만 등재되는 스킬 라이브러리, 후보 프로그램 K개를 돌려 살아남은 것에 다음 세대를 조건화하는 진화 탐색을 코디네이터-액터 구조로 묶는다.
🎯 Claude Opus 4.6 기준으로 LIBERO-Pro 세 스위트 평균 72%(최강 베이스라인 CaP-Agent0 18%), Robosuite 양팔 handover 20% → 92%, 처음 보는 LIBERO-Pro Long에 zero-shot 30.5%(CaP-Agent0 3.8%)를 보고하고, 같은 루프를 Claude Opus 5.5로 돌리면 LIBERO-Pro 80개 태스크 평균 99%에 이른다.

🔍 Ping Review

🔍 Ping — A light tap on the surface. Get the gist in seconds.

Code as Policies 계열은 LLM이 인지·계획·제어 API를 조합해 로봇 프로그램을 쓰게 한다. 프로그램이니 원리적으로는 읽고 고치고 디버깅할 수 있다. 그런데 기존 시스템이 돌려주는 피드백은 대개 “성공/실패” 한 비트나 사람이 미리 정한 장면 요약뿐이다. 실패가 인지 탓인지, 잡기 자세 탓인지, 경로 계획 탓인지 알 수 없으니 에이전트는 어디를 고칠지 모른다. 게다가 한 태스크에서 찾은 수리법은 그 태스크가 끝나면 버려진다. 저자들의 표현으로 “백 번째 태스크를 푸는 에이전트가 첫 번째를 푸는 에이전트보다 나을 게 없다”.

ASPIRE(Agentic Skill Programming through Iterative Robot Exploration)는 사람 로봇 엔지니어의 작업 방식을 그대로 옮긴다. 실행을 다시 보고, 인지 결과와 궤적을 뜯어보고, 고장 난 하위 시스템을 짚고, 고치고, 그 요령을 기억해 둔다. 코드 릴리스 README의 한 줄 요약이 이 논문의 프레이밍을 잘 보여 준다. “training” is skill refinement instead of gradient descent. “Trained model” is a repo of sensorimotor skills instead of floating weights. 즉 이 시스템에서 학습되는 것은 신경망 가중치가 아니라 마크다운 파일에 적힌 수리 지식이다.

시스템 개요(Fig. 1). 코디네이터가 태스크마다 액터(코딩 에이전트)를 띄우고, 액터는 로봇 실행 엔진의 원시 호출별 멀티모달 흔적(깊이, SAM3 마스크, 잡기 후보, 모션 플랜)으로 반복 디버깅·진화 탐색을 한다. 검증된 수리법은 공유 스킬 라이브러리(/skills)에 쓰이고, 일부는 실로봇 프로그래밍의 문맥 지침으로 옮겨진다.

핵심 방법론:

세 부품이 열린 학습 루프를 이룬다. (1) 로봇 실행 엔진은 인지·계획·잡기·제어 호출마다 입력·출력·반환 상태를 남기고, 동작 호출 전후의 RGB 키프레임과 인지 결과의 오버레이를 붙인다. 에이전트는 영상 전체가 아니라 실패에 연루된 호출 주변의 증거만 골라 본다. (2) 스킬 라이브러리는 “실패 서명, 언제 적용할지, 수리 전략, 필요하면 코드 스케치”로 된 텍스트 항목이다. 액터가 제안하면 새로 띄운 검증자 액터가 제안문만 보고 원 태스크를 다시 풀어 내야 등재된다. (3) 진화 탐색은 반복 디버깅이 같은 전략만 땜질하는 국소 루프에 빠지는 것을 막는다. 라운드 i마다 에이전트 M이 상위 3개 이전 프로그램과 실패 흔적, 라이브러리 \mathcal L을 보고 후보 K개를 낸다(Algorithm 1).

\{P_i^k\}_{k=1}^{K}\leftarrow \textsc{ProposeRepairs}\big(M,\tau,\mathrm{Top3}(\mathcal H),\mathcal L,\mathcal H\big),\qquad (r_i^k,Z_i^k)=\textsc{Execute}(P_i^k,S_\text{dbg})

여기서 \mathcal H는 (프로그램, 점수, 흔적 묶음) 이력이고 S_\text{dbg}는 디버그용 환경 시드다. 디버그 시드 점수가 임계값 \theta를 넘거나 T라운드를 다 쓰면 멈추고, 최종 프로그램 P^\star는 겹치지 않는 평가 시드 S_\text{eval}에서 단 한 번 평가된다. 평가 시점에는 LLM이 개입하지 않는다(BEHAVIOR-1K는 예외로, 시드마다 코드 블록을 점진 생성한다).

주요 결과:

LIBERO-Pro(Opus 4.6, 태스크당 50 평가 시드): 위치·과제 교란 평균 Object 96.5%, Goal 63%, Spatial 55.5%로 최강 베이스라인 대비 +77/+41.5/+42.5 %p. OpenVLA·π0는 전 칸 0%, π0.5는 과제 교란(지시문 바꿔 말하기)에서 거의 붕괴한다(Table 5).
Robosuite: 7개 태스크 평균 68% → 81%, 양팔 handover 20% → 92%. 다만 two_arm_lift는 74% → 71%로 오히려 낮다(Table 6).
BEHAVIOR-1K: 라디오 줍기 과제 성공 56% → 88%(사람이 쓴 프로그램 36%)(Table 7).
Zero-shot 전이: LIBERO-90에서 쌓은 라이브러리로 LIBERO-Pro Long을 추가 디버깅 없이 30.5%(CaP-Agent0 3.8%). 라이브러리 크기 N=0/25/50/90에서 4.7/13.7/21.5/30.5%(Table 8).
모델 스케일링: 같은 루프에서 코딩 에이전트 모델만 바꾸면 LIBERO-Pro Goal(위치 교란) 성공률이 GPT-6 Luna 15%에서 Claude Opus 5.5 99%까지 벌어진다. Opus 5.5는 LIBERO-Pro 80개 평균 99%, Robosuite·BEHAVIOR 대표 태스크 100%.
실로봇(YAM 양팔): 시뮬레이션에서 찾은 스킬을 문맥에 넣으면 첫 성공까지 총 토큰이 9.4배(캔 들기)·4.1배(서랍) 줄고, 서랍은 0/20 → 11/20(Table 1). 루빅스 큐브는 세 에피소드 중 두 번 풀었다.

결론:

새로운 것은 개별 부품보다 “로봇 프로그램 디버깅을 소프트웨어 엔지니어링 에이전트의 작업 환경으로 만든다”는 관점이다. 실행 엔진은 에이전트에게 디버거를, 스킬 라이브러리는 사내 위키를, 진화 탐색은 여러 가설을 동시에 시험하는 습관을 준다. 그 결과 성능이 상당 부분 코딩 에이전트 모델의 능력을 따라 움직인다는 점이 이 논문의 가장 흥미로운 관찰이자 가장 큰 약점이다. 아래 Ring에서는 평가가 무엇을 재는지(태스크별 디버깅 후 같은 태스크의 다른 시드), 한 번 돌린 결과의 흔들림이 얼마나 큰지(같은 조건 4회 실행이 55.6~67.4%), 그리고 실로봇 결과가 어디까지를 보였는지를 원문 표로 따진다.

🔔 Ring Review

🔔 Ring — An idea that echoes. Grasp the core and its value.

한 줄로 시작하면

ASPIRE는 “로봇 정책을 학습한다”는 말의 뜻을 바꾼다. 정책은 매번 LLM이 새로 쓰는 파이썬 프로그램이고, 학습으로 쌓이는 것은 그 프로그램을 쓰는 요령이다. “SAM3가 ’앞쪽 그릇’을 못 알아들으면 마스크를 다 받은 뒤 x좌표로 정렬하라”, “cuRobo가 PLANNING_ERROR를 내면 목표를 물체 주위로 45°·90°·180° 돌려 다시 잡아라” 같은 문장이 쌓인다. 이 요령이 쌓일수록 다음 태스크를 더 빨리 푼다는 것이 논문의 주장이다. 그리고 그 요령을 읽고 쓰는 주체가 Claude Code나 Codex 같은 범용 코딩 에이전트라서, 로봇 성능이 코딩 모델의 세대 교체를 그대로 따라간다는 것이 이 논문이 실증으로 보여 준 가장 강한 현상이다.

배경: 왜 로봇 코드 디버깅은 어려운가 (§1)

Code as Policies(Liang et al., 2023) 이후 LLM이 인지·계획·제어 API를 조합해 로봇 프로그램을 쓰는 흐름이 이어졌다. 같은 그룹의 CaP-X(Fu et al., 2026)는 이를 벤치마크화하고 시각적 차분(visual differencing)과 사전 정의 스킬 라이브러리, 에피소드별 테스트 시점 재시도를 붙인 CaP-Agent0를 내놨다. 이 논문의 주 베이스라인이 그것이다.

저자들이 짚는 기존 방식의 한계는 둘이다.

피드백이 거칠다. 실패한 롤아웃은 “태스크가 실패했다”는 것만 알려 준다. 원인은 잘못된 인지일 수도, 불안정한 잡기일 수도, 계획 오류일 수도, 하류의 회복 실패일 수도 있다. 사람이 설계한 고정 인터페이스는 증거를 너무 적게 주면 실패한 호출을 가리고, 원시 영상을 통째로 주면 인과 사슬에서 주의를 흩뜨린다.
경험이 쌓이지 않는다. 한 태스크에서 찾은 수리법과 회복 전략은 그 태스크가 끝나면 버려진다.

반면 사람 엔지니어는 실행을 다시 보고, 고장 난 하위 시스템을 짚고, 고친 뒤, 그 요령(잡기 회복 휴리스틱, 내비게이션 전략, 프롬프트 레시피)을 내면화한다. ASPIRE는 이 과정을 에이전트 루프로 옮긴 것이다.

방법 상세 (§2)

코디네이터-액터 구조

중앙의 코디네이터가 공유 스킬 라이브러리를 관리하고 태스크마다 액터(코딩 에이전트)를 띄운다. 액터는 실행 엔진 안에서 프로그램을 쓰고, 돌리고, 진단하고, 고친다. 중요한 설계 선택은 액터끼리 대화 이력이나 원시 궤적을 주고받지 않는다는 점이다. 전이 가능한 경험은 라이브러리로만 증류되고, 각 액터의 컨텍스트 창은 태스크 명세, 현재 프로그램, 현재 실패의 구조화된 흔적에만 쓰인다. 병렬 태스크가 서로의 컨텍스트를 오염시키지 않으면서 지식은 공유하는 구조다.

1) 로봇 실행 엔진 (§2.1)

엔진은 각 원시 호출(perception·planning·grasping·control)에 대해 호출한 API, 입력과 출력, 반환 상태, 그리고 가능하면 RGB 키프레임·오버레이·잡기 후보·물체 자세·모션 플래닝 결과를 기록한다. 액터는 영상 전체를 받지 않는다. 호출 직전·직후 프레임과 그 오버레이·반환값만 받는다. 저자들은 이 반복을 “iterative debugging”이라 부른다. 공개 코드(v1.0 src/cap_harness/runtime.py)를 보면 전후 키프레임은 모든 호출이 아니라 움직임·그리퍼 도구(move_to_pose, execute_trajectory, close_gripper 등 10개)에만 붙는다. 분할 같은 인지 호출은 키프레임 없이 입력·출력과 마스크 오버레이로 남는다. 다만 공개 코드는 이 서술보다 넉넉하다. 디버그 실행은 media/videos/에 mp4를 남기고, 액터 프롬프트가 이를 증거로 쓰라고 지시한다(subagent-prompt.md: “debug runs keep videos — they are your evidence”, 증거 목록에 media/videos/). 호출 전후 키프레임이 기본 시야인 것은 맞지만 영상이 차단되지는 않는다. 논문의 “영상 전체를 받지 않는다”는 설계 원칙으로 읽고, 배포된 파이프라인의 실제 제한으로 읽지는 않는 편이 정확하다.

로봇 실행 엔진의 흔적 기반 디버깅(Fig. 2). BEHAVIOR-1K “이동해서 라디오 줍기”. (a) 에고 뷰 키프레임은 로봇이 라디오를 찾았지만 다가가지 못함을 보여 준다. (b) 원시 호출 흔적이 실패를 반복된 PLANNING_ERROR로 좁힌다. 후보 이동 목표 3개가 모두 탁자의 충돌 회피 버퍼 안에 있었다. (c) 에이전트가 다각도 접근 루틴으로 프로그램을 고치고, 이 수리가 Multi-Angle Approach 스킬로 등재된다.

Fig. 2의 예가 엔진의 효용을 잘 보여 준다. 흔적을 보면 인지는 성공했고(라디오 위치 [3.02, 4.91, 0.30], 로봇과 1.91 m), 문제는 navigate_to_pose가 반복해서 PLANNING_ERROR를 낸 것이다. 반환값과 로그를 보면 생성된 이동 목표가 탁자 가장자리에서 약 20 cm 이내라 충돌 회피 버퍼에 걸렸다. 그러니 고칠 곳은 인지 프롬프트도 잡기 원시 동작도 아니고 이동 목표의 실현 가능성이다. 수리 코드는 라디오 주위로 접근 각도를 바꿔 가며 목표를 샘플링한다. 흔적 로그상 이 에피소드는 0~1205초 동안 진행됐고, 인지 탐색에만 153초, cuRobo 실패 반복에 약 390초가 들었다.

프로젝트 페이지의 "Robot Execution Engine" 영상(36초, 재인코딩). LIBERO "위 서랍을 열고 그릇을 넣어라"에서 흔적(trace.json)을 읽고 "서랍 손잡이를 허공에서 잡음, 손잡이가 위에서 접근하기엔 너무 낮음" → "옆에서 IK 경유점으로 접근"으로 진단·수리하는 과정을 보여 준다.

2) 스킬 라이브러리 (§2.2)

저자들의 관찰은 “실패는 태스크를 넘어 반복되지만, 재사용 가능한 지식은 태스크 프로그램 전체인 경우가 드물다”는 것이다. 그래서 라이브러리는 프로그램이 아니라 이질적인 수리 지식을 담는다. 위치 파악 휴리스틱, 인지 프롬프트, 잡기 제약, 내비게이션 회복, 모션 원시 동작, 장면 이해 루틴, 디버깅 작업 흐름까지 들어간다. 이 분류는 미리 정하지 않고 검증된 수리에서 귀납된다고 한다.

스킬 라이브러리(Fig. 3). 위: 대표 항목(다중 물체 구별, 바닥 평면 선형 밀기, 다각도 접근). 가운데: 위치 파악·모션 원시 동작·내비게이션·물체별 잡기·장면 이해·디버깅으로 퍼진 라이브러리. 아래: 시뮬레이션에서 찾은 스킬 일부를 실로봇 프로그래밍의 문맥 지침으로 쓴 예.

항목 하나는 실패 서명, 적용 조건(when-to-apply), 수리 전략, 필요하면 대표 코드 스케치로 이뤄진다. Fig. 2의 라디오 사례에서 등재되는 것도 “라디오 줍기 프로그램”이 아니라 “장애물 경계 근처에서 플래너 오류가 반복되면 물체 주위의 다른 접근 방향을 샘플링한 뒤 인지·잡기를 재시도하라”는 회복 패턴이다.

디버깅 스킬 항목의 예(Fig. 11, 부록 A). “한 시행에 과적합하지 마라”: 같은 증상이 2회 이상 나타날 때만 (증상, 적용 범위) 쌍을 라이브러리 후보로 올린다. 메타 수준의 작업 규칙도 스킬로 쌓인다는 것을 보여 준다.

등재 절차는 두 단계 검사다. 액터가 실패 양상, 검증된 수리, 전이 가능해 보이는 패턴을 구조화된 보고서로 낸다. 그러면 새로 띄운 검증자 액터가 제안된 스킬만 받아 원 태스크를 디버그 시드 일부에서 독립적으로 다시 풀고, 각 항목을 건전·결함·미검증으로 표시한다. 코디네이터는 허용 API 정책 준수 여부를 확인하고 검증자가 성공을 재현한 항목만 올린다. 이 절차는 텍스트가 지식을 전달하는가를 확인할 뿐 다른 태스크로 일반화되는가를 확인하지는 않는다. 코드 레포의 라이브러리 README가 이 구분을 스스로 명시한다(“passing shows the text transmits, not that it transfers”). 이 구분은 아래 zero-shot 결과를 읽을 때 중요하다.

3) 진화 탐색 (§2.3)

반복 디버깅만으로는 액터가 같은 실패 전략을 계속 땜질하는 국소 루프에 빠질 수 있다. 진화 탐색은 탐색 대상을 로봇 프로그램 자체로 두고 Algorithm 1처럼 돈다.

초기 프로그램 P^0을 디버그 시드 S_\text{dbg}에서 실행해 점수 r^\star와 흔적 Z^0을 얻는다.
라운드 i=1..T마다 에이전트가 이력 \mathcal H의 상위 3개와 남은 실패 흔적, 라이브러리 \mathcal L을 보고 후보 K개를 낸다.
각 후보를 S_\text{dbg}에서 실행해 (r_i^k,Z_i^k)를 얻고 이력에 넣는다. 최고 후보가 기존 최고를 넘으면 P^\star를 교체한다.
r^\star\ge\theta이면 멈춘다.
디버그 이력에서만 패턴 \mathcal G를 뽑고, P^\star를 S_\text{eval}에서 한 번 실행해 보고한다.

논문 본문은 K, T, \theta 값을 적지 않는다. 공개 코드(.claude/skills/evosearch/)에서 K=8, 최대 5라운드, 디버그 시드 80% 이상이면 해결이라는 값은 일관된다. 그러나 종료 규칙은 세 파일이 서로 다르다. 코디네이터용 참고표(main-agent-prompt.md)는 “2회 연속 5 %p 미만 개선이면 정체로 멈춤”을 두지만, 액터가 실제로 따르는 runbook(subagent-prompt.md)은 80% 또는 5라운드에서만 멈추고 “작은 개선이 이어진다고 일찍 멈추지 말라”고 쓰며, 반복 가이드(skills/evosearch-iteration.md)는 “2회 이상 3 %p 미만이면 구조를 바꾸라”고 한다. 부모 선택도 갈린다. Algorithm 1은 전체 이력 \mathcal H의 Top3에 조건화하는데, runbook은 “현재 라운드의 상위 3개 생존자”에서, 반복 가이드는 “이전 모든 라운드의 상위 3개”에서 다음 세대를 만들라고 한다. 논문 결과를 낸 실행이 어느 규칙을 따랐는지는 알 수 없다. 부록 Table 20은 “반복 디버깅 결과가 90% 미만인 태스크에만 진화 탐색을 걸었다”고 적는다.

4) 커리큘럼과 역방향 전이 (§2.4)

코디네이터는 커리큘럼 에이전트도 겸한다. 현재 라이브러리를 보고 다음 태스크를 고른다. 라이브러리의 빈틈을 메우거나, 기존 스킬을 새 태스크에 시험하거나, 최근 발견을 같은 스위트에 이어 쓰는 식이다. 태스크를 순서대로 풀기 때문에 앞쪽 태스크는 작은 라이브러리만 갖는다. 그래서 모든 태스크가 끝나면 점수가 낮고 옛 라이브러리로 풀었던 태스크를 한 번 더 최종 라이브러리로 돌린다. 저자들은 이를 backward skill transfer라 부른다.

직관: “학습”은 어디에 쌓이는가

이 시스템의 학습 신호와 저장소를 일반적인 정책 학습과 나란히 놓으면 무엇이 다른지가 선명해진다.

구분	신경망 정책(VLA·RL)	ASPIRE
학습되는 것	가중치	태스크별 파이썬 프로그램 + 공유 텍스트 스킬
학습 신호	시연 손실·보상	시뮬레이터 성공 판정 + 원시 호출별 흔적
일반화의 단위	관측 분포	“적용 조건”이 맞는 실패 양상
능력의 상한	데이터·모델 용량	노출된 API(SAM3·cuRobo·Contact-GraspNet·PyRoki) + 코딩 모델
경험 공유	같은 가중치	검증자를 통과한 마크다운 항목

이 표에서 두 가지가 보인다. 첫째, 세밀한 지각·제어 능력은 학습되지 않는다. 물체를 보는 것은 SAM3와 깊이 역투영이, 잡는 자세를 고르는 것은 Contact-GraspNet이, 경로를 찾는 것은 cuRobo·PyRoki가 한다. ASPIRE가 배우는 것은 이 전문 프로바이더들을 어떤 순서로, 어떤 인자로, 실패하면 어떻게 부를지다. 저자들도 한계 절에서 “API가 디버깅을 다룰 만하고 안전하게 만들지만, 에이전트가 표현할 수 있는 행동의 범위를 묶는다”고 쓴다. 둘째, 저장소가 텍스트라서 사람이 읽고 감사할 수 있다. “Trained model이 sensorimotor skill의 레포”라는 표현은 과장이 섞여 있지만(감각운동 능력 자체는 프로바이더에 있다), 무엇이 쌓였는지를 사람이 직접 열어 볼 수 있다는 점은 가중치 학습에 없는 실질적 장점이다.

실험 셋업 (§3.1~3.3)

코딩 에이전트: 시뮬레이션 주 결과는 Claude Code + Claude Opus 4.6(1M 토큰 컨텍스트). 모델 어블레이션은 Claude 6종(Opus 4.6·5·5.5, Sonnet 5.5, Haiku 5.5, Fable 5.1), GPT 4종(GPT-6 Astra·Sol·Luna, GPT-6.1 Sol), 공개 가중치 2종(Kimi K3, Qwen 3.8 Max) 등 12개. Claude와 공개 가중치 모델은 Claude Code로, GPT 계열은 Codex CLI로 돌린다.
실로봇: 스킬 전이(§3.6)는 Codex + GPT-5.5(reasoning-xhigh), 온라인 학습(§3.7)은 Codex + GPT-6 Astra. 둘 다 YAM 양팔 스테이션.
베이스라인: CaP-Agent0(시각 차분, 사전 정의 스킬, 에피소드별 재시도)와 OpenVLA, π0, π0.5. BEHAVIOR-1K에는 사람 전문가가 쓴 프로그램(“Human”)도 있다.
평가 프로토콜: 환경 시드가 물체 자세·방해물·초기 상태를 고정한다. 디버그 시드와 평가 시드는 겹치지 않는다. ASPIRE는 LIBERO-Pro·Robosuite에서 태스크당 프로그램 하나를 만들어 평가 시드 전체에 돌리고, CaP-Agent0는 시드마다 테스트 시점 추론·재시도로 프로그램을 새로 만든다.

벤치마크	성격	태스크	디버그 시드	평가 시드
LIBERO-Pro Object·Goal·Spatial	단기, 위치(Pos)·지시문(Task) 교란	스위트당 10 × 교란 2	51–65 (검증 66–80)	1–50
LIBERO-Pro Long	장기, zero-shot 전이 대상	10 × 교란 2	(zero-shot: 없음)	1–50
Robosuite	접촉 많은 단일·양팔 조작	7	101–125	1–100
BEHAVIOR-1K	장기 이동 조작(가정)	2 (소다캔, 라디오)	26–35	1–25

여기서 짚어 둘 점이 있다. LIBERO-Pro에서 ASPIRE가 디버깅하는 시드 51–65는 같은 태스크, 같은 교란 조건의 다른 배치다. 즉 주 결과의 “held-out”은 같은 태스크 안에서 처음 보는 배치라는 뜻이지 처음 보는 태스크라는 뜻이 아니다. 처음 보는 태스크에 대한 증거는 §3.5의 zero-shot 실험뿐이다. 이 차이가 VLA 베이스라인과의 비교를 읽는 방식을 바꾸는데, 아래 비판 절에서 다시 다룬다.

실험 1: 주요 결과 (§3.4)

주 평가(Fig. 4, 모두 Claude Opus 4.6). (a) LIBERO-Pro: 스위트·교란별로 10개 태스크 × 50 평가 시드의 매크로 평균. (b) Robosuite: 태스크당 100회. 2A는 양팔. (c) BEHAVIOR-1K: 두 가정 과제의 이동(Nav)·과제(Task) 성공을 따로 보고.

부록 Table 5~7의 정확한 값을 옮기면 다음과 같다.

LIBERO-Pro	Object Pos	Object Task	Goal Pos	Goal Task	Spatial Pos	Spatial Task	전체
OpenVLA	0	0	0	0	0	0	0
π0	0	0	0	0	0	0	0
π0.5	17	1	38	0	20	1	13
CaP-Agent0	22	18	26	17	12	14	18
ASPIRE	98	95	81	45	51	60	72

Robosuite 태스크	CaP-Agent0	ASPIRE
cube_lift	97	97
cube_stack	98	99
cube_restack	89	100
spill_wipe	100	99
two_arm_handover (양팔)	20	92
two_arm_lift (양팔)	74	71
nut_assembly	0	9
평균	68	81

BEHAVIOR-1K	Human Nav	Human Task	CaP-Agent0 Nav	CaP-Agent0 Task	ASPIRE Nav	ASPIRE Task
소다캔 줍기	80	72	84	72	92	88
라디오 줍기	88	36	80	56	100	88

초록의 “최대 77%”, “72%”, “최대 32%”는 모두 %p 차이다. 검산하면 Object는 (98+95)/2 − (22+18)/2 = 96.5 − 20 = 76.5, Goal은 63 − 21.5(CaP-Agent0) = 41.5, Spatial은 55.5 − 13 = 42.5로 본문과 맞는다. handover는 92 − 20 = 72, BEHAVIOR 라디오 과제 성공은 88 − 56 = 32다. 사람 프로그램(36%) 대비로는 52 %p다.

수치를 읽을 때의 주의점 셋.

어려운 칸은 여전히 낮다. Goal 과제 교란 45%, Spatial 위치 교란 51%, Robosuite nut_assembly 9%다. “모든 벤치마크에서 개선”은 맞지만 Opus 4.6 기준으로 LIBERO-Pro가 풀린 것은 아니다.
two_arm_lift는 베이스라인보다 낮다(74 → 71). 본문은 “쉬운 접촉 과제에서 거의 포화 성능을 유지”라고만 쓰고 이 역전을 언급하지 않는다.
BEHAVIOR-1K는 평가 방식이 다르다. 시드마다 현재 멀티모달 흔적을 보고 다음 코드 블록을 생성하는 점진 실행이라 평가 시점에도 LLM이 돈다. “프로그램 하나를 고정해 평가한다”는 LIBERO·Robosuite의 서술은 여기에 적용되지 않는다. 평가 시드도 25개라 한 시드가 4 %p다.

실험 2: 처음 보는 태스크로의 zero-shot 전이 (§3.5)

LIBERO-90에서 N\in\{0,25,50,90\}개 태스크로 라이브러리 스냅숏을 만들고, LIBERO-Pro Long의 처음 보는 장기 태스크에 추가 디버깅·재시도·라이브러리 갱신 없이 프로그램 하나를 써서 평가한다. 주 결과와 달리 이 실험은 진짜로 “처음 보는 태스크”에 대한 증거다.

LIBERO-Pro Long zero-shot 전이(Fig. 5, Opus 4.6). (a) N=90 라이브러리 vs 베이스라인. (b) 라이브러리 크기에 따른 성공률. 축별 10개 태스크 매크로 평균.

방법	Pos	Task	전체
OpenVLA / π0	0.0	0.0	0.0
π0.5	8.0	1.0	5.0
CaP-Agent0	5.2	2.4	3.8
ASPIRE N=0	0.0	9.4	4.7
ASPIRE N=25	5.6	21.8	13.7
ASPIRE N=50	13.8	29.2	21.5
ASPIRE N=90	22.6	38.3	30.5

집계로는 깔끔하게 단조 증가한다. 그런데 부록 Table 9의 태스크별 값을 보면 그림이 다르다.

20개 칸 중 의미 있게 오르는 것은 소수다. N=90에서 Pos 축은 10개 중 7개 태스크가 0%이고, 평균 22.6%의 86%가 “스토브+모카포트” 100%와 “크림치즈+버터” 94% 두 태스크에서 나온다. “그릇 서랍에 넣기”, “머그 전자레인지에 넣기”는 모든 N에서 Pos·Task 모두 0%다.
라이브러리가 커지면 떨어지는 칸이 있다. “수프+토마토소스” Task는 N=0에서 78%였다가 N=50에서 2%로 떨어지고 N=90에서 70%로 돌아온다. “스토브+모카포트” Task는 N=50 68% → N=90 26%, “머그 두 접시” Task는 28 → 8 → 0%다. 저자들도 한계 절에서 “라이브러리가 커지면 일부 항목이 낡거나 지나치게 구체적이거나 오도할 수 있고, 이것이 zero-shot 전이에서 개별 태스크를 해칠 수 있다”고 인정한다. 다만 본문 §3.5는 “success increases consistently”라고만 쓴다. 이 단조성은 매크로 평균의 성질이지 태스크의 성질이 아니다.
실행은 N마다 1회다. 아래 Table 25가 보여 주는 실행 간 흔들림(같은 조건에서 태스크 하나가 0%↔︎100%)을 생각하면, 위의 비단조 칸 중 상당수는 라이브러리 효과가 아니라 실행 잡음일 수도 있다. 논문만으로는 구별되지 않는다.
표 사이 사소한 반올림 불일치. Table 9의 태스크별 값으로 평균을 내면 N=90 Task가 38.2%인데 Table 8은 38.3%, Table 9 Mean 행은 38.0%다. Table 9 Mean 행은 정수로 반올림돼 있고(N=25 Pos 계산 5.6 vs 표기 6.0), 결론에는 영향이 없다.

결론적으로 “스킬 라이브러리가 처음 보는 태스크로 전이된다”는 주장은 평균 수준에서는 성립하지만 그 근거가 소수 태스크에 집중되어 있다. CaP-Agent0와 비슷한 N=0(4.7%)에서 출발해 N=90에서 30.5%로 오르는 것은 분명한 신호다. 그러나 “라이브러리가 클수록 좋다”는 일반 명제로 읽기에는 태스크별 변동이 크다.

실험 3: 실로봇 교차 체화 전이 (§3.6)

Franka 기반 시뮬레이션에서 ASPIRE가 만든 스킬 세 개(소다캔 줍기, 그릇을 접시에 놓기, 서랍 밀고 당기기)를 고르고, 체화·API가 다른 YAM 양팔 실로봇의 코딩 에이전트(Codex + GPT-5.5)에게 문맥 지침으로 준다. 정책을 그대로 배포하는 것이 아니다. 실로봇은 자체 인지·보정·제어 스택을 쓰고, 에이전트는 실기 실행 흔적을 보며 여전히 프로그램을 고쳐야 한다. 질문은 “시뮬레이션 스킬이 실기 디버깅의 양을 줄이는가”다.

태스크	출력 토큰(M) 스킬 없음	스킬 있음	총 토큰(M) 스킬 없음	스킬 있음	성공 스킬 없음	스킬 있음
그릇을 접시에	0.05	0.04	8.65	5.11	20/20	20/20
소다캔 들기	0.18	0.03	61.94	6.58	13/20	19/20
서랍 열기/닫기	1.33	0.36	334.92	81.67	0/20	11/20

토큰은 첫 성공 프로그램까지(못 하면 예산 소진까지) 센 값이고, 성공률은 생성된 프로그램의 평가 시행이다. 총 토큰 비율은 1.7배, 9.4배, 4.1배다. 서랍은 스킬 없이는 더 큰 예산을 다 쓰고도 성공 프로그램을 못 만들었다.

프로젝트 페이지의 "Long Horizon Table Bussing" 영상(27초, 재인코딩). 우상단 인셋이 해당 시뮬레이션 스킬, 아래 자막이 실기 하위 과제다(서랍 닫기, 접시 놓기, 캔 버리기 등). 이 장기 테이블 정리 데모는 논문 본문·부록 어디에도 정량 결과가 없다(논문 grep에서 "bussing" 0회). 코드 README는 "Claude Opus 4.6(sim), GPT-5.5(real)"로 표기한다.

이 결과가 보여 주는 것과 보여 주지 않는 것을 나눠 두자.

보여 주는 것: 시뮬레이션에서 증류한 텍스트 스킬이 체화·API가 다른 실기 코딩 에이전트의 탐색을 줄일 수 있다. “시뮬레이터 특화 코드를 외운 것이 아니다”라는 저자 해석은 API가 달라도 도움이 됐다는 점에서 일리가 있다.
보여 주지 않는 것: 태스크 3개, 조건당 실행 1회, 시행 20회다. 어느 스킬을 줄지는 사람이 골랐다(“We select three skills”). 시뮬레이션의 코딩 모델(Opus 4.6)과 실기의 모델(GPT-5.5)이 다르다. “디버깅 예산”의 크기는 적혀 있지 않다. 그릇 과제는 스킬 없이도 20/20이라 토큰 절감 외에는 정보가 없다. 무엇보다 실기 쪽에서 스킬 라이브러리가 자라는 것, 즉 논문 제목의 “지속 학습”은 이 실험에 없다.

실험 4: 실로봇 온라인 스킬 학습, 루빅스 큐브 (§3.7)

고정된 도구 집합을 주고, 코딩 에이전트가 “System 2”로서 실행 가능한 인지·행동 도구를 호출하며 배운 것을 텍스트 스킬로 적는다. 한 GPT-6 Astra 세션에서 세 번의 실제 에피소드를 연달아 돌린다. 에이전트는 무작위로 섞인 큐브와 사람이 준 과제 지침을 받고, 시각 관찰만으로 모든 면의 색 배치를 알아낸 뒤, 기호 솔버(Kociemba)로 수순을 얻어 물리적으로 실행·검증한다. 처음 몇 번의 시도에서 면 돌리기 전략을 탐색해 “두 층 지지, 한 층 분리, 면-축 정렬, 충돌 피하는 손 넘김, 상태 인지 미끄러짐 회복” 같은 텍스트 스킬을 쌓는다.

실로봇 루빅스 큐브(Fig. 6). (a) 면 하나 돌리기: 그리퍼 배치 → 큐브 고정 → 한 층 돌리기 → 층 정렬 → 그리퍼 놓기. (b) 완료된 회전 1회당 토큰(막대)과 시간(선)이 에피소드를 거치며 줄어든다.

프로젝트 페이지의 루빅스 큐브 회전 영상(16초, 16배속, 재인코딩). 좌상단 카운터(13/16 → 15/16)는 진행 중인 수순 번호로 보이고, 우상단에 에이전트가 호출한 cap_move_to_pose 등의 도구 호출이 겹쳐 표시된다.

본문 수치를 표로 옮기고 몇 가지를 직접 계산해 붙이면 다음과 같다(마지막 두 열은 필자 계산).

에피소드	결과	시간	완료 회전 수	회전당 시간	회전당 토큰	에피소드 총 토큰(계산)	에피소드 추정 비용(계산)
1	미해결	50분 54초	3	16분 58초	11.27M	약 33.8M	약 $50.6
2	해결	39분	5	7분 48초	5.56M	약 27.8M	(본문 미보고)
3	해결	77분 10초	25	3분 05초	2.01M	약 50.3M	약 $72.3

회전당 시간은 본문 값과 정확히 맞는다(50:54/3 = 16.97분, 39/5 = 7.8분, 77:10/25 = 3.09분). 회전당 비용 $16.85 → $2.89는 본문 값이고, 에피소드 총량은 그것에 회전 수를 곱한 필자 계산이다. 여기서 눈여겨볼 점이 있다.

회전당 지표는 고정 비용을 분모로 나눈다. 각 에피소드에는 큐브 상태를 인지하고 솔버를 부르는 고정 비용이 있고, 저자들도 이 지표가 “실패 시도·회복·컨텍스트 압축을 포함한 에피소드 전체 상각치”라고 밝힌다. 그런데 에피소드 2는 5회전, 에피소드 3은 25회전으로 섞인 정도(수순 길이)가 다르다. 수순이 길면 고정 비용이 더 많은 회전에 나눠지므로 회전당 값은 스킬 축적이 없어도 줄어든다. 실제로 에피소드 총 토큰은 에피소드 3이 가장 많고 추정 비용도 약 $72로 가장 크다. “회전당 효율이 좋아졌다”는 결론 자체는 맞을 수 있지만, 그중 얼마가 스킬 덕이고 얼마가 상각 덕인지는 이 설계로 분리되지 않는다.
n = 3, 세션 1개다. 같은 문맥 창 안에서 이어지므로 개선이 “텍스트 스킬” 덕인지 “같은 세션의 대화 이력” 덕인지도 구분되지 않는다. 논문은 이를 “learning through context refinement rather than model-weight updates”라고 쓰는데, 이 표현은 두 가능성을 모두 포함한다.
사람의 몫이 크다. 부록 D에 따르면 사람 운영자가 휴리스틱 문서(일반 규칙과 예상 실패 사례)를 주고, 큐브 풀이 자체는 Kociemba 솔버가 한다. 에이전트가 배우는 것은 면 돌리기라는 조작 기술을 안정적으로 실행하는 요령이다. 그 자체로 어려운 접촉 조작이지만, “로봇이 루빅스 큐브를 푼다”는 헤드라인이 연상시키는 것보다 범위가 좁다.

부록 D의 System 2 하네스는 별도로 볼 가치가 있다. 에이전트는 MCP(Model Context Protocol)로 영속적인 CaP 런타임에 붙는다. MCP 브리지는 명시적 도구 허용 목록과 JSON 스키마 검증을 거치고, 물리 동작은 직렬화된 백그라운드 작업으로 돌며 동시 구동 요청은 거부된다. cap_move_to_pose는 내부적으로 Mink IK와 cuRobo 궤적 계획을 쓴다. 구동은 서버 시작 시 명시적으로 활성화해야 한다. 저자들은 “Control-level success only confirms the commanded motion; the agent judges task completion from physical evidence”라고 적는다. 즉 실기에서 과제 성공 판정은 에이전트 자신의 시각 판단이다.

실로봇 System 2 작업 흐름(Fig. 17, 부록 D). Codex 에이전트가 관찰-추론-도구 사용-검증 루프를 돌고, MCP 서버를 거쳐 CAP 서비스(SAM3, cuRobo)와 YAM 환경(30 Hz 제어 루프)에 한 틱에 한 동작씩 명령한다.

System 2 실로봇 예시(Fig. 18, 부록 D). (a) 병뚜껑 풀기, (b) 알약 넣고 뚜껑 잠그기, (c) 컵 뒤집어 쌓기, (d) 루빅스 큐브. 루빅스 큐브 외 세 과제는 그림만 있고 성공률·시행 수가 보고되지 않는다.

실험 5: 어블레이션 (§3.8)

실행 엔진과 진화 탐색

실행 엔진·진화 탐색 어블레이션(Fig. 7, LIBERO-Pro, Opus 4.6). (a)(b) 엔진·진화 탐색 없는 기본 → 엔진 추가 → 진화 탐색 추가의 누적 막대. (c) 성능이 낮은 태스크들의 진화 탐색 반복별 평균.

엔진이 매크로 평균을 14% → 62%로 가장 크게 올리고, 진화 탐색이 72%까지 더한다. 부록 Table 10·11에서 확인되는 세부 사항이 이 그림의 읽는 법을 바꾼다.

“엔진 없음”의 정체. 기본 조건은 “zero-shot Claude Opus 4.6 with 15 example programs”이고, “w/o Evo”는 “the program repaired with the robot execution engine and skill library”다. 즉 이 단계 차이는 흔적 엔진, 반복 디버깅, 스킬 라이브러리를 한꺼번에 켠 효과다. 엔진의 흔적이 성공 신호만 주는 디버깅보다 얼마나 나은지, 라이브러리가 같은 스위트 안에서 얼마나 기여하는지는 따로 측정되지 않았다. 라이브러리의 독립 기여는 zero-shot 실험과 역방향 전이에서만 간접적으로 보인다.
디버깅이 평가 시드 성능을 깎는 태스크가 있다. Goal 위치 교란 “가운데 서랍 열기”는 zero-shot 28% → 디버깅 후 2%, “와인병 캐비닛 위에”는 100% → 24%, Spatial “라메킨 위”는 58% → 42%다. 15개 디버그 시드에 맞춰 고친 프로그램이 50개 평가 시드에서 나빠진 것으로, 디버그 시드 과적합의 직접 증거다. 본문은 이를 언급하지 않는다.
최종 선택이 평가 시드 기준 최선이 아니다. “ASPIRE” 열은 반복 디버깅 결과와 진화 탐색 결과 중 검증 시드 66–80에서 나은 쪽을 고른 것이다. 평가 시드를 보지 않고 고른다는 점에서 프로토콜은 정직하다. 다만 그 선택이 자주 빗나간다. 과제 교란 Spatial “접시와 라메킨 사이”는 진화 탐색 84%를 두고 8%가, “나무 캐비닛 위”는 98%를 두고 46%가, Goal “와인 캐비닛 위”는 72%를 두고 14%가 선택됐다. 15개 시드짜리 검증 세트로는 두 프로그램을 안정적으로 구별하지 못한다는 뜻이다.
반복별 곡선은 태스크 단위로는 단조가 아니다. Fig. 7(c)는 “처음 몇 라운드 꾸준히 개선”이라 하지만 Table 12의 최고 후보 평가 시드 성공률은 “그릇 → 접시”가 62 → 60 → 60 → 18 → 86%, “쿠키 상자 옆 그릇”이 16 → 20 → 4 → 4 → 40%로 출렁인다. 최고 후보는 디버그 시드 기준으로 고르므로 평가 시드에서의 값은 흔들릴 수 있다.

역방향 스킬 전이

Claude Opus 5 LIBERO-Pro Long 캠페인에서 초기 성공률이 낮았던 5개 태스크를 최종 라이브러리로 다시 돌린다.

태스크	초기	재실행 후	Δ (%p)
pos/0 수프+소스 → 바구니	37/50 (74%)	47/50 (94%)	+20
pos/3 그릇 → 서랍, 닫기	0/50 (0%)	26/50 (52%)	+52
pos/9 머그 → 전자레인지, 닫기	0/50 (0%)	0/50 (0%)	0
task/3 병 → 서랍, 닫기	0/50 (0%)	36/50 (72%)	+72
task/6 빨간 머그 → 접시	39/50 (78%)	43/50 (86%)	+8
20개 전체	746/1000 (74.6%)	822/1000 (82.2%)	+7.6

산술은 맞는다(5개 태스크 증가분 합 76회 = 822 − 746). 다만 이 실험은 같은 50개 평가 시드에서 점수가 낮았던 태스크를 골라 같은 시드로 다시 잰다. 공개 코드의 재실행 규칙도 “임계값 미만이고 라이브러리가 바뀐 태스크”를 고른다. 이 설계에서는 (1) 라이브러리 효과, (2) 단순히 “한 번 더 시도한” 효과, (3) 낮은 값을 골랐을 때의 평균 회귀가 섞인다. 같은 조건의 반복 실행에서 태스크 하나가 0%와 100%를 오가는 것(아래 Table 25)을 감안하면 (2)는 무시할 크기가 아니다. 옛 라이브러리로 다시 돌린 대조군이 있어야 라이브러리의 몫을 분리할 수 있다.

모델 어블레이션

환경·API·시드 분할·실행 프로토콜을 고정하고 코딩 에이전트의 LLM만 바꾼다. Fig. 8은 LIBERO-Pro Goal 위치 교란 10개 태스크에서 빈 라이브러리로 시작하는 반복 디버깅만(진화 탐색 없음)으로 12개 모델을 비교한다.

모델별 성공률 vs 추정 API 비용(Fig. 8). 태스크당 비용(정가 기준, 로그 축). 초록 선은 “더 싼 모델 중 이보다 나은 것이 없는” 비용-성공 프런티어로, GPT-6 Luna → Claude Haiku 5.5 → GPT-6.1 Sol → Claude Sonnet 5.5 → Claude Opus 5.5로 이어진다.

모델	공개 가중치	성공	태스크당 비용	총비용	태스크당 에이전트 시간(분)
Claude Opus 5.5		99.2%	$18.29	$183	51
Claude Sonnet 5.5		98.8%	$12.11	$121	56
Claude Fable 5.1		96.6%	$42.24	$422	68
GPT-6 Astra		94.4%	$35.37	$354	31
Claude Opus 5		90.6%	$59.72	$597	76
GPT-6.1 Sol		88.0%	$9.52	$95	49
Kimi K3	✓	78.4%	$58.19	$582	139
Claude Haiku 5.5		68.0%	$3.97	$40	54
GPT-6 Sol		59.2%	$7.64	$76	42
Qwen 3.8 Max	✓	56.0%	$39.82	$398	103
Claude Opus 4.6		55.6%	$23.58	$236	61
GPT-6 Luna		14.8%	$0.83	$8	47

(Table 18을 성공률 순으로 재배열. 비용은 정가 기준 추정이다.)

이어서 Fig. 9와 Table 3·4는 Opus 5, Opus 5.5, GPT-6 Astra를 Opus 4.6과 전 벤치마크에서 비교한다. 여기서는 스위트 안에서 라이브러리를 이어 쓴다.

LIBERO-Pro 모델 어블레이션(Fig. 9의 막대 부분). 스위트·교란별 평가 시드 성공률(10 태스크 × 50 시드). 빗금은 진화 탐색의 추가분. 같은 그림의 오른쪽 표(BEHAVIOR-1K, Robosuite)는 아래 표로 옮겼다.

벤치마크	Opus 4.6	Opus 5	Opus 5.5	GPT-6 Astra
LIBERO-Pro Obj·Goal·Spat 평균 (반복 디버깅만)	62% (진화 탐색 포함 72%)	96%	98.9%	98%
LIBERO-Pro Long (반복 디버깅만)	47.6% (Table 24)	74.6% (재실행 후 82.2%)	97.9%	87.9%
Robosuite 7개 평균	81%	99%	100%	99%
Robosuite nut_assembly	9%	98%	100%	99%
BEHAVIOR 소다캔 Task	88%	100%	100%	96%
BEHAVIOR 라디오 Task	88%	92%	100%	96%

이 결과에서 저자들이 끌어내는 결론은 “ASPIRE는 특정 모델에 의존하지 않고, 기반 모델이 좋아질수록 좋아진다”이다. 두 번째 절반은 표가 강하게 지지한다. 첫 번째 절반은 해석이 필요하다. 15%에서 99%까지의 폭은 ASPIRE의 성능이 모델에 강하게 의존한다는 뜻이기도 하다.

몇 가지 관찰을 더한다.

강한 모델에서는 진화 탐색과 라이브러리의 몫이 줄어든다. Object·Goal·Spatial에서 진화 탐색은 Opus 5·Astra·Opus 5.5에 최대 2 %p만 바꾼다(Opus 4.6은 최대 34 %p). Long에서도 Opus 5.5에는 0이다. 라이브러리도 마찬가지로, 빈 라이브러리(Fig. 8)와 라이브러리를 이어 쓴 경우(Fig. 9)의 Goal 위치 교란을 비교하면 Opus 5.5는 99.2% → 97%, Astra는 94.4% → 97%, Opus 5는 90.6% → 97%다. 논문의 세 부품 중 두 개의 효과가 모델이 강해질수록 측정 범위 아래로 내려간다.
“Opus 5.5가 모든 태스크에서 97~100%”는 아니다. 코드 README는 “Claude Opus 5.5 reaches 97–100% success on every task”라고 쓰지만, 논문 Table 13~16을 보면 Opus 5.5의 태스크별 값에는 BBQ 소스 88%(Object 위치), 접시 밀기 84%(Goal 위치), 책 캐디 84%(Long 위치), 수프+버터 88%(Long 과제)가 있다. 97~100%는 스위트 평균 범위다. 논문 본문은 “80개 평균 99%”라고 정확히 쓴다.
비용 표의 Opus 4.6은 다른 실행이다. Table 20 각주에 따르면 Opus 4.6의 비용은 “a re-run with the current pipeline”이고 성공률은 원래 실행(Table 10·11)에서 가져왔다. 성공과 비용이 같은 실행에서 나오지 않았다.

한 번 돌린 결과는 얼마나 흔들리는가 (부록 Table 25)

이 논문에서 가장 중요한 표 중 하나는 본문에 언급되지 않는 부록 Table 25다. Opus 4.6으로 Goal 위치 교란을 빈 라이브러리에서 독립적으로 세 번 돌렸다.

태스크	Run 1	Run 3	Run 4	평균	표준편차
가운데 서랍 열기	0%	100%	0%	33.3%	47.1%
서랍 열고 그릇 넣기	62%	0%	0%	20.7%	29.2%
와인병 랙에	70%	98%	100%	89.3%	13.7%
캐비닛 위 그릇	96%	80%	96%	90.7%	7.5%
스토브로 접시 밀기	0%	0%	0%	0.0%	0.0%
10개 평균	62.8%	67.4%	59.2%	63.1%	3.4%

(일부 태스크만 발췌. 런 번호는 원문 그대로 1, 3, 4이고 Run 2는 표에 없으며 그 이유는 적혀 있지 않다.)

논문 서술상 같은 조건(Opus 4.6, Goal 위치 교란, 빈 라이브러리, 진화 탐색 없음)인 Table 19의 55.6%까지 합치면 네 번의 실행이 55.6~67.4%에 걸친다. 이 폭은 Fig. 8의 여러 순위를 무의미하게 만든다. Haiku 5.5(68.0%)와 GPT-6 Sol(59.2%), Qwen 3.8 Max(56.0%)가 모두 Opus 4.6 한 모델의 실행 간 범위 안에 들어간다. 위쪽 모델들(98~99%)은 천장 효과로 분산이 작을 가능성이 높지만, 그 모델들은 반복 실행이 보고되지 않았다. 태스크 단위에서는 “가운데 서랍 열기”가 0/100/0%로 갈린다. 평가 시드 50개짜리 이항 신뢰구간(예: 70%면 대략 ±13 %p)은 이 실행 간 분산을 전혀 반영하지 못한다. 프로그램 하나를 쓰는 과정 자체가 확률적이기 때문이다.

실험 6: 코딩 에이전트 케이스 스터디 (§3.9)

다섯 해결자, 두 과제(Fig. 10). 각 행은 에피소드 하나. 위는 원래 LIBERO 데이터셋의 사람 원격조작 시연, 아래는 각 모델이 쓴 ASPIRE 프로그램의 평가 에피소드. 퍼센트는 50 평가 시드 성공률(Table 26).

“책을 선반 아래에 넣기”는 선반 아래 틈이 책을 세워 든 손이 들어가기엔 너무 낮다. 사람은 책 윗모서리를 잡고 45° 기울여 밀어 넣는다. 어떤 모델도 이 방법을 찾지 못했다. Opus 4.6은 책을 캐비닛 위로 들고 가서 멈추고(0%), Opus 5는 책을 눕히지만 목표 위 칸에 넣는다(2%). 성공한 두 모델은 책을 놓아 버린다. Opus 5.5는 잡지도 않고 책을 쳐서 눕힌 뒤 밀어 넣고(68%), Astra는 눕혀서 떨어뜨린 뒤 민다(22%). “접시 밀기”(위치 교란: 접시 앞에 그릇, 경로에 상자)에서는 Opus 5.5가 그릇과 상자를 먼저 치우고 접시를 밀며(84%), Astra는 아예 밀지 않고 접시를 들어 장애물을 넘긴다(62%).

프로젝트 페이지 "Same task, five solvers: 책을 선반 아래에" 영상의 뒷부분(28초, 재인코딩). Claude Opus 5.5(쳐서 눕힌 뒤 밀기, 68%)와 GPT-6 Astra(눕혀 떨어뜨린 뒤 밀기, 22%) 장면과 마지막 성공률 막대(사람 100, Opus 4.6 0, Opus 5 2, Opus 5.5 68, Astra 22)를 담았다.

저자들의 정리는 “약한 모델은 기본 잡고-옮기기 전략을 고수하다 로봇의 한계에서 실패하고, 강한 모델은 전략을 바꿔 다른 길로 목표에 닿는다”이다. 본문이 스스로 밝히듯 각 행은 한 에피소드라서 전략의 예시이지 대응 비교가 아니다. 덧붙여 Table 26 각주에 따르면 케이스 스터디 수치는 부록 E의 태스크별 표와 별개 실행이다. 실제로 “접시 밀기”에서 Opus 5.5는 Table 26에서 84%, Table 19(빈 라이브러리)에서 92%, Table 14(라이브러리 이어 쓰기)에서 84%이고, “그릇 스토브에”의 Opus 4.6은 Table 26 56%, Table 19 0%, Table 25 세 실행 8/0/0%다. 같은 모델·같은 태스크가 실행에 따라 이만큼 다르다는 것 역시 앞 절의 분산 문제를 다시 보여 준다. 또 하나, 책 과제에서 성공한 전략은 모두 “물체를 쳐서 눕히고 민다”인데, 이것이 실기에서도 바람직한 조작인지(물체 손상, 예측 불가능한 굴림)는 성공 판정이 묻지 않는다.

비판적으로 보면

강점

“무엇이 실패했는가”를 에이전트가 고를 수 있게 한 것. 원시 호출별 흔적은 디버거의 스택 트레이스에 해당한다. 사람이 정한 장면 요약 대신 에이전트가 관련 호출의 키프레임·반환값을 골라 보게 한 설계가 14% → 62%라는 가장 큰 단일 이득을 낸다(라이브러리와 묶인 효과이긴 하다). Fig. 2의 라디오 사례처럼 “인지는 맞았고 목표 자세가 충돌 버퍼 안이었다”를 짚는 능력은 성공/실패 한 비트로는 얻을 수 없다.
스킬 등재에 “독립 재현” 관문을 둔 것. 제안자 코드 없이 제안문만으로 검증자가 원 태스크를 다시 풀어야 등재된다. LLM이 쓴 “교훈”은 그럴듯하지만 틀리기 쉬운데, 이 관문은 적어도 텍스트가 실행 가능한 지식을 전달한다는 것을 보장한다. 저자들이 이것이 “전이”의 보장이 아니라는 점까지 레포 문서에 명시한 것도 정직하다.
평가 시드 봉인과 단일 프로그램 평가. 디버그·검증·평가 시드를 나누고, 평가 시점에는 프로그램을 고정해 한 번만 돌린다. 시드마다 재시도하는 CaP-Agent0보다 엄격한 프로토콜이다. 공개 코드는 시드 분할이 실제로 서로 다른 배치인지 점검하는 audit_seeding.py까지 갖추고 있다.
불리한 데이터를 부록에 다 실었다. 디버깅 후 성능이 떨어진 태스크(Table 10), 진화 탐색 반복별 출렁임(Table 12), 실행 간 분산(Table 25), 라이브러리가 커지며 떨어지는 zero-shot 칸(Table 9)이 모두 부록에 있다. 본문 서사가 이를 충분히 반영하지 않을 뿐, 독자가 검증할 재료는 공개돼 있다.
모델·비용 축을 정면으로 다뤘다. 12개 모델의 성공률·비용·시간을 한 표에 두고, 비용-성공 프런티어를 그린 것은 이 장르 논문에서 드문 실용적 기여다. “더 강한 모델이 꼭 더 비싸지는 않다”(Opus 5.5 $18/태스크 99% vs Opus 5 $60/태스크 91%)는 실무자에게 바로 쓸모 있다.
지식이 사람이 읽을 수 있는 형태로 남는다. 라이브러리 항목은 실패 서명·적용 조건·전략·코드 스케치로 된 마크다운이다. 무엇이 쌓였는지 열어 보고, 틀린 항목을 사람이 고칠 수 있다.

약점·한계

(a) “스킬”의 범위와 학습 없는 정책의 일반화 한계.

ASPIRE가 쌓는 스킬은 SAM3(분할), 깊이 역투영, Contact-GraspNet(잡기), cuRobo·PyRoki(IK·경로 계획) 위에서 이 도구들을 어떻게 부를지에 대한 지식이다. 감각운동 능력 자체는 사전 훈련된 프로바이더에 있다. 저자들도 한계 절 세 번째 항목에서 “노출된 원시 동작 밖의 감지·제어·상호작용이 필요하면 에이전트는 비효율적으로 근사하거나 사람이 API를 확장해야 한다”고 인정한다. 촉각·힘 제어·변형체처럼 API가 다루지 않는 영역에서는 이 방식의 이득이 불분명하다. Robosuite에서 가장 접촉이 정교한 nut_assembly가 Opus 4.6으로 9%였던 것이 그 경계를 시사한다(강한 모델은 98~100%로 넘었다).
주 결과의 일반화는 같은 태스크의 다른 배치에 대한 것이다. 각 태스크는 자기 교란 분포에서 15개 디버그 시드로 디버깅되고, 같은 분포의 50개 시드로 평가된다. 반면 OpenVLA·π0·π0.5는 교란된 태스크에 맞춰 적응할 기회 없이 평가된다. “VLA가 0%인데 ASPIRE는 72%”는 방법의 우열이라기보다 태스크별 적응을 허용했는가의 차이가 크다. 논문은 VLA 수치를 재실행했는지, 어떤 체크포인트인지도 밝히지 않는다. 진짜 처음 보는 태스크의 결과(zero-shot 30.5%)는 72%보다 훨씬 낮고, 앞서 본 대로 소수 태스크에 집중돼 있다.
디버그 시드에 맞춘 수리가 평가 시드에서 성능을 깎는 태스크가 있다(Table 10: 28 → 2%, 100 → 24%). 프로그램은 가중치보다 해석하기 쉽지만 15개 시드에 과적합하는 데는 가중치와 다르지 않다. 공개 코드의 액터 프롬프트가 “디버그 시드에서 관측한 좌표·치수를 상수로 박지 마라”고 거듭 경고하는 것도 이 위험을 보여 준다. 이 블로그가 1개 태스크로 루프를 돌려 본 결과에서도 같은 구조가 보였다. 디버그 시드 5개에서 5/5가 된 프로그램이 평가 시드에서 7/10이었고, 실패 셋은 모두 디버그 시드에 한 번도 나타나지 않은 단일 실패 양상(파지 유지 실패)이었다(재현 노트). 디버그 시드에 없는 실패는 루프가 고칠 신호 자체가 없다.

(b) 평가가 코딩 에이전트 모델에 의존한다: 비용과 재현성.

같은 루프가 모델에 따라 15%에서 99%까지 간다. 저자들은 이를 “모델에 의존하지 않는다”의 근거로 쓰지만, 반대로 읽으면 ASPIRE의 성능은 프레임워크보다 모델이 결정한다. 강한 모델에서는 진화 탐색(±2 %p)과 라이브러리(빈 라이브러리와 이어 쓴 라이브러리의 차이 −2~+6 %p)의 몫이 거의 사라진다. 프레임워크의 기여를 순수하게 분리하려면 같은 모델로 “흔적 엔진 없이, 라이브러리 없이” 돌린 비교가 강한 모델에서도 필요하다.
재현성이 구조적으로 약하다. 주 결과의 Opus 4.6은 이미 구세대 모델이고, 사용된 모델 대부분은 비공개 API다. 모델 버전이 바뀌거나 사라지면 같은 수치를 다시 얻을 방법이 없다. 같은 모델·같은 조건에서도 실행 간 범위가 55.6~67.4%(Table 19·25)이고 태스크 하나가 0↔︎100%로 갈린다. 그런데 Fig. 8의 12개 모델은 각 1회 실행이고, 본문 어디에도 실행 간 분산이 언급되지 않는다. Table 25의 런 번호도 1, 3, 4로 Run 2가 빠져 있다.
비용이 크다. 부록 Table 20·22를 합치면 Opus 4.6으로 LIBERO-Pro 80개 태스크(Object·Goal·Spatial 60개 + Long 20개)를 돌린 비용은 반복 디버깅 $1,787 + 진화 탐색 $5,553, 대략 $7,300(정가 추정, 비용은 재실행 기준)이고 토큰은 약 126억 개다(대부분 캐시 읽기). 진화 탐색은 탐색한 태스크당 $89~147로 반복 디버깅($21~23)의 4~7배인데, 72 − 62 = 10 %p를 더한다. Opus 5.5로는 같은 80개가 약 $1,200이다. 저자들도 “디버그·진화 탐색 루프는 계산 집약적”이라고 한계에 적는다. 시뮬레이터 롤아웃 수(Opus 4.6 LIBERO-Pro 60개에 반복 디버깅 12,214회 + 진화 탐색 9,529회)도 결코 작지 않다. “데이터 없이 배운다”는 인상과 달리 시뮬레이션 상호작용과 API 토큰이라는 다른 형태의 데이터를 대량으로 쓴다.
평가 시드를 보고 다음 행동을 고르는 지점이 있다. 공개 코드에 따르면 진화 탐색 대상은 “반복 디버깅의 held-out 결과가 90% 미만인 태스크”이고, 역방향 전이 재실행 대상도 평가 시드 점수가 낮은 태스크다. 각 프로그램을 평가 시드로 튜닝하는 것은 아니지만, 어느 태스크에 추가 예산을 쓸지를 평가 시드로 정하면 보고되는 평균은 선택된 태스크에 한해 낙관적으로 기운다. 특히 Table 2(+7.6 %p)는 같은 50개 시드로 다시 쟀고, 옛 라이브러리로 다시 돌린 대조군이 없다.

(c) 안전: 생성 코드에 실행 권한을 넘긴다는 것.

논문은 안전을 두 곳에서만 다룬다. 한계 절에서 API가 “디버깅을 안전하게 만든다”고 하고, 실세계 배포에는 “안전 모니터링”이 더 필요하다고 한다. 시뮬레이션에서 금지 API(시뮬레이터 내부 상태, 성공 판정, BDDL·URDF 파일 읽기)를 막는 장치는 프롬프트 규칙(“STRICTLY FORBIDDEN”), 코디네이터의 준수 확인, 린터다. 공개 코드 v1.0의 프로그램 계약은 import math 외 import를 막고 공개 도구만 주입하지만, 코드 README는 이것이 보안 경계가 아니라고 경고한다: “ASPIRE executes language-model-generated Python with full import access. Trial processes and watchdogs are not a security sandbox. Run generated code on an isolated host without credentials …, restrict network access, and never grant a simulation agent access to physical hardware.” 게다가 코딩 에이전트(Claude Code·Codex) 자체는 셸과 파일 시스템 권한을 갖고 돈다. 결과 무효화(평가 부정)와 호스트 보안 양쪽에서, 경계가 기술적 강제보다 지시 준수에 많이 기댄다.
시뮬레이션 기본 모션 전략은 충돌을 보지 않는다. 공개 코드의 액터 프롬프트에 따르면 MotionStrategy()의 기본값은 PyRoki IK + 직선 관절 보간이고, 팔이 조리대나 열린 서랍을 밀고 지나가 목표 관절각에 도달하면 ok=True를 반환한다. 접촉에 막혀 관절이 수렴하지 못하면 그때는 TIMEOUT과 joint_error_rad로 드러난다(아래 재현에서 와인병 예제가 이 경로로 실패했다). 즉 충돌은 “막혀서 못 간 경우”에만 신호가 되고, 장면을 밀어내며 지나간 경우에는 조용하다. cuRobo 충돌 검사도 환경 변수 하나로 전역 해제할 수 있다. 시뮬레이션에서는 성공률에만 영향을 주지만, 같은 습관의 프로그램이 실기로 넘어갈 때를 생각하면 가볍지 않다.
실기 System 2 하네스(부록 D)는 도구 허용 목록, 스키마 검증, 직렬화된 단일 구동 작업, 명시적 구동 활성화를 갖췄다. 이는 좋은 설계다. 그러나 힘·속도 제한, 작업 공간 경계, 비상 정지, 사람과의 공존 같은 물리 안전 장치는 논문에 기술되지 않는다. 과제 성공 판정을 에이전트 자신의 시각 판단에 맡긴다는 점도, 저자들이 지적한 “견고한 성공 판정” 문제가 실기에서 열려 있다는 뜻이다. 책을 쳐서 눕히는 식의 “창의적” 전략(Fig. 10)이 실기 물체에 어떤 결과를 낼지도 성공 판정은 묻지 않는다.

(d) 실로봇 결과의 검증 범위.

정량 실기 결과는 Table 1의 태스크 3개 × 조건당 실행 1회 × 시행 20회와 루빅스 큐브 에피소드 3회가 전부다. 장기 테이블 정리(프로젝트 영상), 병뚜껑·알약·컵 쌓기(Fig. 18)는 정량 결과가 없다. 코드 README도 이 세 레시피가 “distilled from demo sessions, not a new real-robot validation”이라고 적는다.
실기 전이 실험에서 스킬은 사람이 골라 넣었고, 실기 에이전트가 쓰는 모델(GPT-5.5)과 시뮬레이션 모델(Opus 4.6)이 다르다. 실기에서 라이브러리가 스스로 자라는 루프는 보이지 않는다. 저자들 스스로 “완전 자율 실세계 평생 학습자는 아직 아니다. 시뮬레이션과 달리 성공 확인과 장면 리셋이 싸지 않다”고 한계 첫 항목에 적는다. 이것이 “sim → real 지속 학습” 서사의 실제 경계다.
루빅스 큐브의 “점점 효율적”은 회전당 상각 지표이고, 에피소드마다 수순 길이(3, 5, 25회전)가 달라 스킬 효과와 상각 효과가 분리되지 않는다. 에피소드 총 토큰은 마지막이 가장 많다(필자 계산 약 50M). 사람이 휴리스틱 문서를 주고, 풀이는 Kociemba 솔버가 한다.

그 밖의 관찰.

ASPIRE의 학습 신호는 시뮬레이터의 성공 판정이다. 프로그램은 성공 판정에 접근하지 못하지만, 디버깅 루프는 그 판정으로 후보를 고른다. 이는 사람이 주는 보상과 같은 성격이고 정당하다. 다만 실기에서 이 판정이 없다는 점이 위 (d)의 근본 원인이다.
벤치마크 구현이 포크다. 공개 코드의 의존성 잠금 파일에 따르면 LIBERO-PRO, robosuite, SAM3가 모두 원본이 아니라 공저자 계정의 포크(uynitsuj/LIBERO-PRO, Max-Fu/robosuite, Max-Fu/sam3)에 핀돼 있다. 베이스라인 수치와 같은 벤치마크 구현인지는 논문에 적혀 있지 않다.
시드 버그 이력이 코드에 남아 있다. 공개 코드의 audit_seeding.py 머리말은 “the campaign it was written for had a real seeding bug — every seed resolving to the same layout — which was fixed mid-run, invalidating every sweep taken before the fix”라고 적고, docs/libero-pro.md도 “Earlier buggy seeded runs restored saved state 0”라고 쓴다. 어느 캠페인인지, 논문의 어떤 수치가 수정 이후 실행인지는 논문·코드 어디에도 적혀 있지 않다. 논문 수치가 영향을 받았다는 증거는 없지만, 논문 실행 당시 평가 시드 50개가 실제로 50개의 서로 다른 배치였는지는 독자가 확인할 수 없다. 현재 v1.0 코드에서는 seeded 모드가 제대로 동작한다. 이 블로그가 libero_goal_swap 태스크 0에서 감사 스크립트를 돌려 보니 평가 시드 1–50이 서로 다른 배치 50개였고 디버그 시드 51–70과 겹치는 배치는 없었다. 반대로 CLI 기본값인 saved 모드에서는 시드 {1, 2, 3, 51, 52, 53}이 배치 3개로 접혔다(같은 시드를 seeded로 돌리면 6개). 파이프라인 스크립트는 LIBERO에 seeded를 넘기지만, cap-harness run을 손으로 칠 때 --init-mode seeded를 빼면 디버그 시드가 평가 시드와 같은 장면이 된다.
“학습된 모델”이 공개돼 있지 않은 것으로 보인다. README는 “trained model = 스킬 레포”라고 하지만, 2026-10-19 확인 시점 main의 라이브러리(.claude/skills/iterative-debugging/skills/)는 총 약 29 KB의 구조 템플릿이고(파일 머리말이 “No task-specific strategies — those are discovered through experiment”라고 쓴다), v0.1의 BEHAVIOR 스킬 파일들은 각 400바이트 안팎의 빈 틀이다. Fig. 5의 N=90 스냅숏이나 태스크별 최종 프로그램은 트리에서 찾지 못했다(파일 트리 검색 기준, 정적 확인). 그렇다면 논문 수치를 재현하려면 학습(=에이전트 캠페인) 전체를 다시 돌려야 하고, 이는 (b)의 모델·비용 문제로 되돌아간다.

🔧 재현 노트

🔬 이 절은 논문의 주장이 아니라 이 블로그가 공개 코드(NVlabs/ASPIRE v1.0, 커밋 fa00f0e)를 직접 돌려 본 결과다(2026-10-19). 범위는 LIBERO-Pro, 그것도 1개 태스크뿐이고, Robosuite·BEHAVIOR-1K·실로봇·진화 탐색·검증자 등재·커리큘럼은 돌리지 않았다. 또 SAM3 가중치를 받지 못해(Hugging Face 게이트 미승인 계정은 HTTP 403) 같은 API 계약을 흉내 내는 Grounding DINO + SAM ViT-H 대체 분할기를 썼다. 따라서 아래의 어떤 수치도 논문 수치의 재현이 아니다. 확인한 것은 “공개된 하네스와 반복 디버깅 루프가 서술대로 작동하는가”까지다.

환경. RTX 5090(32 GB, 이웃 프로세스가 약 10 GB 점유) 1장, 레포의 rtx5090 프로파일과 공식 부트스트랩 스크립트 그대로. 코딩 에이전트는 Claude Code(Opus 5.5)가 코디네이터와 워커를 겸했다.

하네스 점검.

깨끗한 v1.0 체크아웃에서 cap-harness doctor --reset이 ValueError로 죽는다. LIBERO 어댑터가 numpy 배열에 진리값 검사(not init_states)를 하기 때문으로, 업스트림에 같은 내용의 이슈 #26·#27이 열려 있다(2026-10-18). 한 줄(len(init_states) == 0)을 고치면 통과하고, 그 뒤 LIBERO-Pro 스모크 검증은 80개 (스위트, 태스크) 쌍 모두 통과했다. 스모크는 리셋·스키마·한 틱 이동 같은 구조 검사이지 과제 성공 검사가 아니다.
동봉 예제 프로그램 5개는 시드 1에서 0/5였다. 원인은 둘이다. 대체 분할기가 엉뚱한 캔을 고르거나 서랍 손잡이를 못 찾았고(인지), 분할이 맞은 와인병 두 과제는 IK가 먼 해로 튀면서 충돌을 보지 않는 직선 관절 보간이 팔을 스토브로 휘둘렀고, 접촉에 막힌 관절이 수렴하지 못해 move_to_pose가 TIMEOUT(관절 오차 0.667 rad)으로 끝났다(앞서 비판 (c)에서 짚은 기본 MotionStrategy()의 문제가 실제로 나타났다). 레포 문서는 SAM3로 이 예제들이 시드 1에서 성공한다고 쓰는데, 분할기가 다르므로 그 주장을 반박하는 결과는 아니다. 프로그램이 마스크·점군 통계에 그만큼 민감하다는 관찰이다.

반복 디버깅 루프를 1개 태스크로. 동봉 예제가 없는 libero_goal_swap 태스크 8(“그릇을 접시에”)을 골라 공식 스킬 문서(iterative-debugging)의 절차를 규모만 줄여 따랐다.

단계	실패 양상 → 수리	디버그 시드 51–55
v00	라이브러리의 잡기-놓기 템플릿(위에서 잡기, 실패 시 중심 잡기)	0/5
v01	위에서 잡기 후보가 전부 기각되고 중심 잡기가 그릇 바닥에 걸림 → 그릇 테두리를 y축 방향으로 잡기	1/5
v02	접시 쪽 테두리를 잡으면 손이 접시 너머 나무 랙에 닿음 → 반대쪽 테두리 잡기	5/5
미관측 확인 66–70 (1회)	v02 그대로	4/5
평가 시드 1–10 (코디네이터)	v02 그대로	7/10

두 번의 수리 모두 원시 호출 흔적(관절 오차, 동작 전후 키프레임, 마스크 오버레이)으로 실패를 하위 시스템 하나에 귀속시킨 결과다. 시뮬레이션 에피소드 31회, 루프 전체 약 20분이 들었다. 논문 §2.1~2.2가 서술한 메커니즘이 공개 코드에서 그대로 작동한다는 것을 보여 준다.

평가 시드에서 놓친 셋(미관측 확인 시드 1개 포함하면 넷)은 모두 파지 유지 실패였다. 모든 동작이 성공을 반환하지만 그릇이 테이블을 떠나지 않는다. 이 양상은 디버그 시드 5개에 한 번도 나오지 않았으므로 루프에는 고칠 신호가 없었다. 앞의 비판 (a)에서 Table 10을 근거로 짚은 “디버그 시드에 맞춘 프로그램이 평가 시드에서 흔들린다”는 문제가 작은 규모에서 같은 형태로 나타난 셈이다. 다만 1개 태스크, 평가 시드 10개, 더 약한 분할기, 검증자·라이브러리 성장 없음이라는 조건에서의 관찰이고, 논문의 Goal 스위트 성공률(10 태스크 × 50 시드)에 대한 추정치로 읽으면 안 된다.

판본 차이: arXiv v1 vs 2026-10 개정판

항목	arXiv v1 (2026-06-30)	프로젝트 PDF (2026-10-16)
저자	14명	Haotian Lin, Jan Kautz 추가(16명)
주 결과 (Opus 4.6)	LIBERO-Pro 72%, Robosuite 81%, BEHAVIOR, zero-shot 30.5%, 실기 Table 1	같은 값
방법	§2.1~2.3	§2.4 커리큘럼·역방향 전이 추가
실험	주 결과, zero-shot, 실기 전이, 엔진·진화 탐색 어블레이션	+ 루빅스 큐브(§3.7), 역방향 전이(Table 2), 12개 모델 어블레이션, 케이스 스터디(§3.9)
부록	프롬프트 전문(CLAUDE.md, 금지 API 목록, 진화 탐색 지침)	프롬프트 전문 삭제, System 2 하네스(D), 모델별 표·비용·분산(E.4~E.10), 코드 구조(G)
한계 서술	“더 작거나 약한 LLM이 같은 루프를 유지할 수 있는지 검증하지 않았다”	약한 모델 15~59%, 최고 공개 가중치 78%로 실측 보고

주 결과 수치는 두 판본이 같다. 개정판은 “모델이 좋아질수록 좋아진다”는 축을 새로 세웠고, v1의 한계 문장 하나를 실험으로 바꿨다. 반대로 v1 부록에 있던 프롬프트 전문은 코드 레포로 옮겨졌다.

요약

ASPIRE는 로봇 프로그래밍을 “코딩 에이전트가 실행 흔적을 보며 고치고, 검증된 요령을 텍스트로 쌓는” 문제로 바꾼 시스템 논문이다. 원시 호출별 멀티모달 흔적, 독립 검증자를 거치는 스킬 라이브러리, 프로그램 공간의 진화 탐색이라는 세 부품으로 Opus 4.6 기준 LIBERO-Pro 72%(VLA 0~13%, CaP-Agent0 18%), 처음 보는 장기 태스크 zero-shot 30.5%를 보고하고, 모델을 Opus 5.5로 바꾸면 80개 태스크 평균 99%까지 간다. 흔적을 에이전트가 골라 보게 한 설계와 사람이 읽을 수 있는 지식 저장소는 오래 남을 아이디어다.

한계는 무엇을 쟀는가에 몰려 있다. 주 결과는 같은 태스크의 다른 배치에 대한 일반화이고 VLA는 적응 기회 없이 비교됐다. 성능은 프레임워크보다 코딩 모델이 크게 좌우하며, 강한 모델에서는 진화 탐색과 라이브러리의 효과가 측정 범위 아래로 내려간다. 같은 조건의 실행 간 범위가 12 %p에 이르는데 모델 비교는 각 1회 실행이다. 일부 추가 예산(진화 탐색, 재실행) 배분은 평가 시드 점수로 정해진다. 실기 결과는 태스크 3개와 루빅스 큐브 에피소드 3회로, “sim → real 지속 학습”의 첫 증거라는 저자 표현 이상으로 읽기 어렵다. 생성 코드 실행의 안전은 지시 준수에 기대고, 레포 스스로 보안 경계가 아니라고 경고한다.

그래도 이 논문이 남기는 질문은 크다. 로봇 성능이 코딩 모델의 세대 교체를 따라 15%에서 99%로 움직인다면, 로봇 학습 연구가 최적화할 대상은 정책 네트워크가 아니라 코딩 에이전트에게 주는 작업 환경(흔적, API, 지식 저장소)일 수 있다. 그 환경이 실기의 성공 판정·리셋·안전 문제까지 감당할 수 있는지가 다음 시험대다.