ProgAgent는 도구 호출을 프로그램으로 바꿔 장기 작업 훈련을 개선한다

무엇인가

LLM 에이전트가 장기(long-horizon) 작업에서 여러 도구를 조율해야 하는 요구가 커지고 있다. 기존 방식인 직접 도구 호출(DTC, Direct Tool Calling)은 모델이 턴마다 도구를 순차 호출하고 그 응답이 전부 모델 컨텍스트에 누적된다. 논문은 이 누적이 컨텍스트 부패(context rot)와 조율 붕괴(orchestration breakdown)를 일으킨다고 지적한다. 반면 프로그램 방식 도구 호출(PTC, Programmatic Tool Calling)은 실행 가능한 코드를 통해 도구를 호출하고 중간 결과를 런타임 변수에 담아 두며, 명시적으로 출력한 값만 컨텍스트에 넣는다. 기존 연구는 PTC를 주로 추론 시점 최적화로 다뤘을 뿐, 훈련 패러다임으로서의 이점은 검증되지 않았고 PTC 훈련에 맞는 검증 가능 과제도 거의 없었다.

어떻게 동작하나

이 논문이 제안하는 ProgAgent는 세 부분으로 구성된 PTC 훈련 스택이다. 첫째, PTC에 맞춘 검증 가능한 장기 과제를 합성하는 파이프라인. 둘째, 턴 사이에 실행 상태를 보존하는 경량 PTC 런타임. 셋째, 콜드스타트 지도미세조정(SFT)에 이어 강화학습(RL)을 수행하는 2단계 훈련 레시피다. 과제 합성은 23개 도메인에서 LLM이 사용자 의도를 만들고, 생성 에이전트가 관계형 데이터베이스와 파일 워크스페이스를 구축한 뒤 도구 집합과 지시문, 파이썬 검증기, 오라클 해법을 만든다. 오라클이 만점을 받지 못하면 환경·도구·지시문·검증기를 자동 수리 루프로 고친다. 이때 과제 지시문과 내부 로직, 도구 스키마는 고정한 채 환경 상태 크기만 단계마다 약 2배로 키워 v0~v3 네 가지 변형을 만든다. 이후 별도 하네스 에이전트가 일관성을 감사하고, DeepSeek V4 Pro로 PTC 하네스에서 과제당 8개 궤적을 샘플링해 모든 스케일에서 통과율이 (0, 0.8) 구간에 드는 과제만 남긴다. 최종적으로 215개 과제가 4개 스케일로 인스턴스화되어 860개 훈련 인스턴스 풀이 된다.

무엇과 다른가

런타임은 PTC를 MCP 서버로 노출한다. 에피소드 시작 시 데이터 생성기를 목표 스케일로 돌려 환경 상태를 초기화하고, 모델이 생성한 프로그램은 샌드박스 처리된 영구 IPython 커널에서 실행된다. 도구 프록시가 프로그램 안의 호출을 실제 환경 도구로 라우팅하고 결과를 파이썬 객체로 돌려주며, 런타임 변수는 턴이 바뀌어도 유지된다. 샌드박스는 에이전트가 검증기 구현과 오라클 해법에 접근하지 못하게 막는다. 에피소드 종료 시 검증기가 최종 응답과 환경 상태를 평가해 0 또는 1의 이진 보상을 준다. 훈련은 Qwen3 8B·14B를 대상으로 DTC, PTC, 하이브리드(PTC+DTC) 세 하네스에서 동일한 과제 풀과 하이퍼파라미터로 진행했고, 3에폭 SFT(배치 64) 후 GSPO로 150스텝, 스텝당 32개 과제에 16개 롤아웃을 샘플링했다.

어떻게 쓰나

실험은 MCPMark, MCP-Atlas, Toolathlon-Verified, LOCA-bench 네 벤치마크에서 이뤄졌다. MCPMark에서 ProgAgent는 8B 18.3%, 14B 29.7%의 평균 통과율을 기록했다. Toolathlon-Verified에서는 8B 9.3%, 14B 17.1%로, 같은 크기 베이스라인의 최대 2.8%와 1.9%를 크게 앞섰다. MCP-Atlas에서 ProgAgent-14B는 45.6%로 DTC 하네스의 Claude Sonnet-4.5(43.8%)와 비슷한 수준에 도달했다. 격차가 가장 큰 곳은 LOCA-bench다. 64k 토큰 환경 상태에서 비교 가능한 크기의 베이스라인이 0%인 반면 ProgAgent-14B는 30.7%를 기록했고, 64k 구간에서 17.3~30.7%의 통과율을 유지했다. 같은 하네스에서 훈련 레시피별로 비교한 결과, PTC 레시피가 두 모델 크기 모두에서 모든 벤치마크의 집계 점수가 가장 높았다. ProgAgent-14B는 MCPMark 29.7%, MCP-Atlas 45.6%로 DTC 레시피의 8.0%, 29.7%를 앞선다.

전제와 한계

훈련 동역학 분석도 흥미롭다. Qwen3-14B 기준으로 DTC의 보상은 0.08에서 0.15로 거의 오르지 않았지만, PTC와 하이브리드는 0.50 근처에서 시작해 각각 0.70, 0.72까지 상승했다. DTC는 에피소드당 약 30k 토큰을 원시 도구 출력으로 소비한 반면, PTC는 훈련 중 도구 출력 토큰이 약 20% 줄어 20k 아래로 내려갔고 도구 호출 횟수도 DTC의 절반 수준이었다. PTC 런타임 오류는 14B에서 6.4→3.6, 8B에서 7.5→5.0으로 감소했다. 환경 상태 스케일링의 효과도 확인된다. DeepSeek V4 Pro의 pass@8은 DTC에서 v0의 0.95에서 v3의 0.42로 단조 하락하지만 PTC에서는 네 스케일 모두 0.90 이상을 유지한다. 훈련을 v0 환경으로만 제한하면 LOCA-bench 평균 통과율이 8B에서 24.3%→16.0%, 14B에서 38.3%→23.7%로 떨어진다. 하네스를 교차 평가한 결과, PTC로 훈련한 모델이 DTC 훈련 모델보다 두 인터페이스 모두에서 우수했고, DTC 평가에서도 MCP-Atlas 기준 14B 모델이 11.9%포인트 앞섰다. 더 유연한 행동 공간을 제공한 하이브리드가 PTC보다 성능이 낮았다는 점도 저자들은 PTC의 통일된 인터페이스가 학습 난이도를 낮춘다고 해석한다.

저자들이 밝힌 한계는 두 가지다. 첫째, 환경이 예측 불가능하거나 비정형적인 내용을 반환할 때 PTC 에이전트가 DTC처럼 퇴화한다. Playwright 환경에서 ProgAgent-14B의 PTC 호출 중 40.7%가 제어 흐름·오류 처리·선택적 출력 없이 단일 도구 호출만 담고 있었다. 둘째, 조용한 서버 실패다. ProgAgent의 PTC 하네스는 MCP의 isError 필드로 도구 예외를 감지하는데, 이를 누락하는 비규격 서버는 예외 기반 복구를 우회한다. 서버 수준 오류 감지를 끄면 LOCA-bench 통과율이 8B에서 24.3%→19.3%, 14B에서 38.3%→34.5%로 하락한다.

실무 관점에서 이 논문이 주는 시사점은 명확하다. MCP 도구를 여러 턴에 걸쳐 호출하는 에이전트를 만든다면, 도구 응답을 그대로 컨텍스트에 쌓는 구조보다 샌드박스 코드 실행과 선택적 출력으로 중간 결과를 관리하는 구조가 장기 작업에서 유리하다. 다만 PTC 인터페이스를 제공하는 것만으로는 성능이 오르지 않는다는 점이 중요하다. 훈련되지 않은 베이스라인은 PTC 하네스에서 오히려 가장 낮은 점수를 냈다. 또 MCP 서버가 isError 필드를 제대로 채우는지, 그리고 Playwright처럼 비정형 스냅샷을 다루는 도구에서 에이전트가 단일 호출로 퇴화하지 않는지를 실제 배포 전에 확인해야 한다.