코딩 에이전트가 시뮬레이터 상호작용만으로 TAMP 일반화 계획을 합성할 수 있는가

무엇인가

태스크 및 모션 계획(TAMP)은 상태를 완전히 관측할 수 있고 객체 중심으로 표현하더라도 여전히 어려운 문제다. 어떤 물체를 잡을지, 어떤 도구를 쓸지 같은 이산적 결정이 기하학·운동학·동역학 제약과 강하게 얽혀 있고, 계획 지평이 길며 보상은 희소하다. 일반화 TAMP는 문제 인스턴스 사이의 규칙성을 활용해 새 인스턴스에 대한 계획 비용을 줄이려는 접근인데, 기존 방법들은 샘플러·가능성 예측기·탐색 휴리스틱·추상화 등을 학습하기 위해 상당한 TAMP 전용 엔지니어링을 요구한다. 이 논문은 그 엔지니어링 자체를 코딩 에이전트가 대신할 수 있는지 묻는다.

어떻게 동작하나

제안 방법인 AgenticGenPlan은 환경마다 코딩 에이전트에게 태스크 설명, 시뮬레이터 접근 권한, 고정된 합성 예산(모델 사용료 20달러)을 준다. 에이전트는 샌드박스 Docker 컨테이너 안에서 파일을 읽고 코드를 쓰고 임의 명령을 실행할 수 있지만 네트워크는 차단된다. 본 설정에서는 파이썬 인터프리터와 NumPy, SciPy만 주어지고 환경 소스 코드나 손으로 설계한 TAMP 술어·연산자·샘플러·스킬은 전혀 제공되지 않는다. 에이전트는 reset과 step만 노출하는 클라이언트를 통해 스스로 실험을 설계하고, 상태를 들여다보고, 물리 모델을 보정하고, 엣지 케이스를 테스트하면서 프로그램을 고쳐 나간다. 합성이 끝나면 프로그램은 클래스 형태의 정책(reset과 get_action)으로 동결되어 학습 중 숨겨둔 새 인스턴스에서 평가되며, 평가 시점에는 LLM이 전혀 개입하지 않는다. 추가로 환경 소스 코드를 컨테이너 안에 넣어주는 +source 설정도 평가한다.

무엇과 다른가

실험은 KinDER 벤치마크의 25개 환경(Kinematic2D, Dynamic2D, Kinematic3D, Dynamic3D 네 계열)과 PDDLStream의 세 도메인(Packing, Blocked, Rovers)을 합쳐 28개 환경에서 이뤄졌다. 원 논문 벤치마크보다 더 많은 객체 수 변형까지 포함한다. 방법별·환경별로 5회 독립 실행, 생성된 프로그램마다 100개의 홀드아웃 인스턴스를 평가해 총 98,000 에피소드를 돌렸다. 비교 대상은 벤치마크가 제공하는 수작업 TAMP 플래너(28개 중 16개 환경에 존재), LLM 기반 일반화 계획 베이스라인 LLMGenPlan(Opus 5, 도구 사용 불가, 사전 정의된 피드백만 수신), 그리고 첫 프로그램만 쓰는 원샷 생성이다. 평가 타임아웃은 인스턴스당 60초다.

어떻게 쓰나

세 에이전트 구성 모두 플래너가 있는 16개 환경에서 수작업 플래너를 앞섰다. Claude Code(Opus 5)는 평균 82%로 플래너의 47%에 대해 1.7배였고, Codex는 GPT-6 Astra가 95%, GPT-5.6 Sol이 56%였다. Astra는 계열별로 Kinematic2D 99%, Dynamic2D 97%, Kinematic3D 93%, Dynamic3D 65%, PDDLStream은 거의 100%를 기록했고, Opus는 각각 96%, 92%, 90%, 45%, 78%였다. 플래너 대비 우세 환경 수는 Astra 15/16, Opus 12, Sol 9다. 계산 효율에서도 Opus 프로그램은 행동당 평균 11.7ms, Astra는 1.3ms로 Opus보다 약 9배 빨랐다. 플래너가 있고 객체 수 변형이 있는 14개 환경에서 Opus와 Astra 프로그램은 인스턴스당 평균 2.1초와 0.5초를 썼고, 플래너는 29초를 썼다. 소스 코드 접근은 Opus를 74%에서 84%로, Astra를 86%에서 95%로 끌어올렸지만, 같은 소스 코드를 받은 LLMGenPlan은 28%에 그쳤다.

전제와 한계

합성 로그는 에이전트가 단순히 기억된 해를 재생하는 게 아니라 상호작용으로 환경을 파악한다는 증거를 보여준다. Shelf에서는 한 Opus 실행이 인터넷 없이 자기 지식만으로 Kinova Gen3 팔의 초기 운동학 모델을 세우고, 손 위치가 상태에 노출되지 않는 문제를 잡은 큐브를 마커로 삼아 관절 각도에서 큐브 위치를 예측하도록 6개 파라미터를 적합해 RMSE를 38.9mm에서 1.8mm로 줄인 뒤 역기구학 풀이에 활용했다. BalanceBeam에서는 Sol 실행이 블록 배치 목표를 빔 중앙 쪽으로 옮겨 성공률을 6%에서 64%로 올렸고, Blocked에서는 실패 시 원거리 테이블의 블록으로 전환하는 폴백을 추가해 15%에서 56%, 이후 83%까지 올렸다. 에이전트들은 또한 기존 문헌에 없던 비파지 조작이나 환경 레이아웃 활용 전략을 찾아냈다.

실무 관점에서 이 결과는 로봇 조작이나 시뮬레이션 기반 계획 문제에서 도메인 전문가가 손으로 술어·샘플러·스킬을 설계하는 대신, 태스크 설명과 시뮬레이터 인터페이스만 주고 코딩 에이전트에게 정책 프로그램을 합성시키는 방식이 강력한 출발점이 될 수 있음을 뜻한다. 특히 평가 시점에 LLM 호출이 없다는 점, 즉 합성된 프로그램이 동결되어 독립적으로 돌아간다는 점은 지연 시간과 비용 면에서 실용적이다. 다만 에이전트가 목표를 잘못 추론할 수 있다는 점은 주의해야 한다. SortClutteredBlocks에서 소스 코드 없이 만든 Astra 프로그램은 상태 순서로 큐브를 빈에 배정하는 규칙을 썼는데, 큐브 4개에서는 통했지만 20개 인스턴스에서는 전부 실패했다. 목표·성공 조건을 코드에서 읽을 수 있게 하는 것이 성능에 큰 차이를 만든다.

저자들이 명시한 한계는 분명하다. 실험 설정은 완전 관측·객체 중심 상태와 합성 중 시뮬레이터 접근을 전제하므로 지각 불확실성 아래에서의 성능은 검증되지 않았다. 모델의 학습 데이터가 공개되지 않아 벤치마크 코드에 대한 사전 노출을 배제할 수 없다는 점도 인정한다. 다만 합성 로그가 환경 탐침·테스트·상당한 수정 과정을 보여주고, 기존 해법에 없던 전략이 나왔다는 점을 사전 암기 가설에 반하는 증거로 든다. 실패도 남아 있다. 주로 많은 작은 물체를 쓸어 담거나 붓는 것을 요구하는 동적 3차원 환경은 본 설정에서 여전히 거의 풀리지 않았다. 저자들은 이 결과로 코딩 에이전트가 일반화 TAMP 연구의 중요한 베이스라인이 된다고 주장한다.