— agentic coding tool 의 자기 발전 루프 (mine → gate → dedup → re-inject) 를 로봇 코드 생성에 적용해 보았습니다.
에이전트형 코딩 시스템 (예: Voyager, SWE-agent) 은 같은 작업을 반복할수록 자기가 만든 코드에서 쓸 만한 함수를 추출 → 라이브러리로 쌓아 → 다음 번에 재활용 하는 루프를 공통적으로 가지고 있습니다. 이 프로젝트는 그 루프를 NVIDIA CaP-X (로봇용 LLM 코드 생성 셋팅) 위에 얹어, NVIDIA 저자들이 trial 수백 개를 *손으로* 읽으며 골라낸 9 개 helper 를 자동 mining loop 가 같은 수준으로 해낼 수 있는지, 또는 일부 조건에서 더 잘할 수 있는지 를 단일 task 에서 검증합니다. 큰 그림은 더 일반적인 환경의 로봇이 사람이 helper API 를 손으로 늘려주지 않아도 code-as-policy 를 잘 적용하는 방향 이며, 본 프로젝트는 그 큰 그림의 한 작은 발걸음입니다. 학술 용어 다 빼고 풀어 씁니다.
⏱ 약 5분 · 끝까지 한 번에 읽으실 수 있는 길이입니다
로봇에게 일을 시키는 LLM (예: ChatGPT) 이 있다고 가정합니다. "큐브를 들어 올려" 라고 지시하면 LLM 이 그 자리에서 Python 코드를 작성하고, 그 코드가 시뮬레이터에서 실행되어 로봇이 움직입니다. 실패하면 LLM 이 코드를 다시 작성하여 재시도합니다.
NVIDIA 의 원본 setup (CaP-X) 에도 *도구 상자* 가 존재합니다. 단 그 도구 상자 안의 함수들은 연구자 (사람) 가 직접 골라 넣은 것들입니다. 사람이 LLM 의 수백 trial 코드를 들여다본 뒤 "이런 함수가 자주 등장하고 유용하다" 싶은 9 개를 추려 API 에 추가한 형태 (S3 Reduced API). 즉 *LLM 의 코드를 사람이 큐레이션* 하여 만든 도구 상자입니다.
본 프로젝트 auto-capx 는 그 큐레이션 단계를 자동화 합니다. LLM 이 작성한 함수를 알고리즘이 직접 추출 한 뒤 품질 검사와 중복 제거를 거쳐 도구 상자에 보관합니다. 다음 trial 이 시작될 때 LLM 에게 "이전에 본인이 작성한 도구들" 로 함께 제공됩니다. 사람의 손이 개입하지 않습니다.
질문은 단순합니다. 그 자동 큐레이션이 실제로 도움이 되는가?
네 가지 질문을 ablation 으로 검증하였습니다 (각 구성 요소를 켜고 끄며 비교).
위쪽 (within-trial 재시도 흐름) 은 동일합니다. 아래쪽 (skill memory layer) 가 auto-capx 가 추가한 부분입니다.
위쪽 5 개 박스는 한 trial 안에서 일어나는 일입니다 (LLM 코드 작성 → 실행 → 실패 시 재시도). 아래쪽 4 개 박스는 trial 종료 후 일어나는 일입니다 (코드에서 함수 추출 → 양질의 함수만 선별 → 중복 제거 → 도구 상자에 추가). 갱신된 도구 상자가 다음 trial 의 LLM 에게 다시 제공됩니다.
"큐브 1 개 들기" task 에서 도구 상자 적용 시 78% → 97% (gpt-4.1 기준). 19pp 개선이며 통계적으로 단단합니다.
단 *어떤 알고리즘으로 도구 상자를 정리하는가* 가 결정적입니다. 동일한 11 개 도구라도 잘못 고르면 78% → 83% (효과 미미), 잘 고르면 78% → 94%.
| 모델 | 도구 상자 없음 | NVIDIA 수동 9 개 | 자동 도구 상자 |
|---|---|---|---|
| gpt-4.1 | 78% | 90% | 97% |
| Claude Sonnet 4 | 86% | — (미실행) | 98% |
| DeepSeek v3 | 6% | 84% | 94% |
가장 약한 모델이 가장 큰 이득 을 봅니다. DeepSeek 은 도구 상자가 없으면 거의 작동하지 않지만 (6%), 도구 상자가 주어지면 94% 까지 도달합니다.
"큐브 3 개 차곡차곡 쌓기" task 를 추가하여 측정한 결과 0/15 (베이스라인과 library 모두 0%). 도구 상자가 있어도 task 자체가 풀리지 않습니다.
원인은 vision pipeline 입니다. 큐브가 3 개 있어 카메라가 개별 객체를 잘 구분하지 못합니다 (mask 가 200 개 이상 조각으로 쪼개짐). LLM 이 아무리 우수해도 카메라 출력이 엉망이면 해결할 방법이 없습니다.
흥미로운 부수 발견 한 가지: 도구 상자가 있을 때 코드 작성 자체가 27% 더 빠릅니다 (성공/실패 무관). "library 가 도움이 된다" 가 *task 성공률* 과 *코드 효율성* 두 갈래로 나뉘어 나타납니다.
한 번 도구 상자를 구성한 뒤, 그 도구 상자를 사용하여 다시 trial 을 돌리면서 "새 도구가 추가로 나오는가" 를 측정하였습니다. 결과: 0 개 추가.
이유는 다음과 같습니다. LLM 이 *충분히 좋은 도구 상자* 를 받으면 새 함수를 만들 동기가 사라집니다. 기존 함수의 조합으로 모든 task 를 해결합니다. 새로 발명할 도구가 더 이상 남아 있지 않은 상태입니다.
execute_grasp 같은 핵심 함수는 모든 trial 에서 호출됩니다. 변두리 함수는 retry 시에만 등장합니다.20 일에 걸쳐 결론을 10 번 갈아 엎었습니다. 9 번째 reversal 은 paper v10 작성 도중 *세웠던 mechanism 가설* 이 *논문 작성 중에* empirically refuted 된 사건입니다. 다행히 publish 직전에 잡혔습니다. 10 번째는 paper v11 closing 이후 발견된 framing 자체의 오류 — auto-capx 의 비교 대상 (P21_a) 이 NVIDIA 의 *published* baseline 이 아니라 *ablation* 이었다는 사실 — 이며, NVIDIA-9 직접 비교 (Phase v12) 로 정정하였습니다.
cube_lifting 의 90% 이상 성공률은 vision pipeline 이 풀기 쉬운 regime 의 산물일 가능성이 있습니다. 큐브 한 개 + 단색 배경은 카메라가 trivial 하게 해결합니다. 큐브 3 개로 넘어가자마자 카메라가 막혔습니다.
20 일 프로젝트의 누적 비용은 약 $254 입니다. LLM API 호출이 ~$182, GPU pod 가 ~$72. 한 학기 수업료보다 저렴합니다.
multi-backbone 검증 (gpt-4.1, Claude, DeepSeek × n=50 each) 의 단일 실행에 ~$64–69, 9 시간이 소요되었습니다. 다행히 한 번에 완료되었습니다.
약한 LLM (DeepSeek 6%) 이 강한 LLM (Claude 86%) 만큼 도움을 받습니다 (양쪽 모두 도구 상자 적용 시 ~94%). 즉 library 가 약한 모델을 강한 모델 수준으로 끌어 올립니다. 본 프로젝트에서 가장 흥미로운 발견 중 하나입니다.
본 paper 의 실제 측정은 "큐브 1 개 들기" 한 가지 task 에 한정되며, NVIDIA 의 수동 9 개와 자동 14 개가 통계적으로 구분되지 않는다는 결과입니다. 더 큰 그림은 다음 가설입니다 — 같은 자기개선 루프 (이전 코드에서 쓸 만한 함수 발견 → 라이브러리화 → 재적용) 가, 사람이 helper 함수를 손으로 추가해 주지 않아도, 더 다양한 환경의 로봇이 code-as-policy 를 스스로 잘 적용하도록 도울 수 있을까? 이 가설을 직접 검증하려면 (i) 더 어려운 task 에서 vision pipeline 을 개선한 뒤 재측정, (ii) 사전등록된 equivalence margin 으로 우열 검정, (iii) 장기 horizon (n=100~200) 에서 라이브러리 진화 관찰 — 이 세 단계가 다음 paper-v3 의 작업 항목입니다.
위 문서는 5 분 압축 버전입니다. 정확한 수치, 통계 검정 (Wilson CI / one-sided binomial P-values), mechanism 분석, 한계 등은 정식 페이지와 논문에 정리되어 있습니다.