서비스를 조합해 크로스 환경 에이전트를 학습시키는 CompoWorld

무엇인가

LLM 에이전트 학습용 환경을 자동 생성하는 연구는 이미 여럿 있지만 대부분 하나의 환경 안에서 태스크를 만든다. 반면 실제 업무 흐름은 여러 서비스를 넘나든다. Snowflake에서 연체 티켓을 조회하고, PDF 운영 매뉴얼을 확인한 뒤, 매니저와 고객에게 메일을 보내는 식이다. 성공은 툴 호출 횟수가 아니라 시스템 사이로 올바른 정보와 제약을 옮겨 다니는 능력에 달려 있다. 이 논문은 서비스 자체를 조합 가능한 단위로 삼아 환경 스케일링의 축을 하나 더 만들자는 제안이다.

어떻게 동작하나

첫 번째 구성 요소는 개별 서비스를 실행 가능한 환경으로 만드는 것이다. 공개 MCP(Model Context Protocol) 명세를 크롤링해 툴 이름·설명·타입이 지정된 파라미터 스키마를 모으고, 코딩 에이전트가 Pydantic 모델로 서비스 상태를 정의한 뒤 각 툴을 상태 전이 연산으로 구현한다. 모든 툴은 통일된 JSON 응답을 돌려주므로 서로 다른 서비스가 같은 실행 인터페이스를 공유한다. 에이전트는 격리된 샌드박스에서 테스트를 반복 실행하며 정상 사용 사례와 오류 처리 사례를 통과시킨다. 자기 테스트는 구현의 맹점을 물려받을 수 있으므로 별도 세션이 명세에서 직접 경계 조건을 포함한 적대적 테스트를 도출해 검증하고, 실패한 툴은 격리한다. 외부 시스템 의존 등으로 결정론적으로 구현할 수 없는 툴은 LLM 월드 모델이 상태 갱신과 관측을 예측해 대신하며, 예측된 갱신도 같은 Pydantic 모델을 거쳐 타입 유효성을 유지한다. 이렇게 만든 서비스가 448개, 노출된 툴이 10,130개다.

무엇과 다른가

두 번째는 크로스 환경 태스크의 생성과 검증이다. 서비스 풀에서 K개를 뽑아 곱 환경을 만들고, 랜덤 워크로 서비스 수준 의존 그래프를 구성한다. 워크는 선택된 모든 서비스를 방문하고, 같은 서비스를 연속 방문하지 않으며, 최소 한 번은 재방문해야 한다(L > K). 간선은 정보 의존을 뜻한다. 뒤 서비스가 필요로 하는 입력이 앞 서비스의 관측에서만 나온다는 것이고, 재방문은 중간 단계 때문에 앞서 읽은 값이 낡아 다시 읽어야 하는 상황을 만든다. 난이도의 주된 손잡이는 워크 길이 L이고 서비스 수 K와 도메인도 조절 변수다. 태스크 작성 에이전트는 explore, design, probe, submit 네 단계를 돈다. 탐색으로 툴과 상태 형식을 익히고, 설계에서 초기 상태와 지시문, 루브릭을 만들고, 프로브에서 실제로 태스크를 풀어 목표 상태와 기준 해답을 확보한다. 이때 참조 해답이 실제 툴 호출로 도달 가능해야 하고 검증기가 이를 받아들여야 한다. 검증기는 목표 상태와 정확히 일치할 것을 요구하지 않으므로 다른 툴 순서로 푼 해답도 통과할 수 있다.

어떻게 쓰나

세 번째는 학습이다. 검증된 성공 궤적으로 SFT를 하고, 같은 조합 환경에서 RL을 한다. RL 보상은 태스크 루브릭에서 나오는데 여기서 Completion-Focused Rubric Reward를 쓴다. 각 태스크마다 N개 궤적을 샘플링해 기준별 통과율 p를 구하고 가중치 w = λ + (1 - p)를 준다. 롤아웃 그룹 안에서 자주 못 맞히는 기준일수록 더 큰 가중치를 받는다. 균일 평균 보상은 레코드는 갱신했지만 알림은 보내지 않은 부분 완료를 높게 평가할 수 있는데, 이 가중치는 남은 병목에 학습 신호를 몰아준다. 가중치는 그룹 단위로 계산해 정책 업데이트 동안 고정하고, 정규화로 보상은 0과 1 사이가 되며 모든 기준을 통과할 때만 1이 된다. 이 보상을 GRPO의 그룹 상대 어드밴티지로 바꿔 정책을 업데이트하며, 툴 관측은 컨텍스트에 들어가지만 손실에서는 제외한다.

전제와 한계

실험은 Qwen3.6-35B-A3B를 백본으로 SFT 3천 궤적과 RL 1천 태스크로 학습했다. 환경·태스크 합성에는 GLM-5.3, 궤적 생성에는 DeepSeek-V4-Flash를 썼고, 기본 설정은 서비스 5개 조합에 방해용 서비스 5개, 워크 길이 7~12다. 8개 벤치마크에서 백본 대비 평균 9.17점 향상했다. AutomationBench 성공률은 10.33%에서 32.33%로 22.00점 올라 GPT-5.4(27.67%)와 Claude Opus 4.6(25.50%)을 넘었고 DeepSeek-V4-Flash(36.33%)에 근접했다. 같은 35B-A3B 규모의 에이전트 특화 모델 6종을 모두 앞섰고 가장 강한 보고 baseline인 Occamy-1.0보다 4.73점 높았다. SkillsBench는 15.19점, VitaBench는 10.50점 오른 반면 VitaBench 2.0은 1.62점에 그쳤다. AutomationBench 1.0.6의 부분 점수 평균은 41.94에서 72.68로 올랐고, HR 49.40점, Marketing 32.51점, Sales 31.45점, Finance·Support·Operations는 21.49~26.56점 개선됐다.

논문은 조합 자체의 효과도 따로 측정한다. 서비스 448개로 5개를 고르면 약 1.47×10^11, 7개를 고르면 약 6.86×10^14개의 후보 조합이 나온다. SFT 데이터를 100, 500, 1천, 3천으로 늘린 실험에서 100개만으로도 네 벤치마크 모두 백본을 앞섰고, 3천에서 τ3-Banking은 10.65에서 17.87, DeepPlanning은 26.04에서 35.02로 올랐다. AutomationBench는 1천에서 33.33%, 3천에서 32.67%였고 SkillsBench는 500에서 44.23, 1천에서 45.13으로 정점을 찍은 뒤 3천에서 40.91로 내려갔다(백본 32.52). 같은 1천 궤적 예산으로 단일 환경 학습과 조합 환경 학습을 비교하면 조합 쪽이 일관되게 앞선다. τ3-Banking은 9.62에서 17.53, AutomationBench는 12.83에서 33.33으로 뛰었고, 단일 환경 SFT는 τ3-Banking과 DeepPlanning에서 오히려 백본보다 나빠지기도 했다.

실무 관점의 시사점은 두 가지다. 첫째, 사내 API나 MCP 서버를 타입이 있는 상태 모델과 통일된 JSON 인터페이스로 감싸 두면 그것들이 그대로 에이전트 학습·평가용 환경 자산이 된다. 서비스를 새로 만들지 않고 조합만 바꿔 태스크 난이도와 다양성을 늘릴 수 있다는 것이 이 접근의 핵심 주장이다. 둘째, 여러 시스템을 넘나드는 워크플로를 평가할 때 성공률만 보면 안 된다. 이 논문의 AutomationBench 결과처럼 부분 점수는 72.68까지 올라가도 완전 성공은 32.33%에 머문다. 기준별 통과율을 뽑아 어디서 막히는지 확인하는 루브릭 기반 평가는 실무 디버깅에도 쓸모가 있다. 다만 파이프라인을 그대로 재현하려면 MCP 명세 수집, 코딩 에이전트 기반 서비스 구현, 월드 모델 폴백, 태스크 검증기 생성까지 상당한 엔지니어링이 필요하다.

저자들이 밝힌 한계도 분명하다. AutomationBench 성공률 32.33%는 부분 진전에도 불구하고 모든 요구사항을 동시에 만족시키는 것이 여전히 어렵다는 것을 보여준다. Sales 도메인은 58.93으로 가장 낮아 의존성과 제약을 더 강화할 여지가 있다고 논문은 적는다. VitaBench 2.0의 1.62점 상승은 개인화·장기 지원으로의 전이가 제한적임을 시사하고, τ3-Banking·DeepPlanning·VitaBench 2.0에서는 프론티어 모델이 여전히 앞선다. RL은 항상 이득이 아니어서 SkillsBench에서는 크게 올랐지만 τ3-Banking에서는 소폭 하락했고, 8개 벤치마크 평균 RL의 SFT 대비 개선은 1.2점에 그친다. 저자들 스스로 성능 향상은 주로 SFT가 이끌었다고 정리한다. 또한 결정론적으로 구현할 수 없는 툴은 월드 모델 시뮬레이션에 의존하므로 그 범위와 품질이 학습 데이터의 신뢰도에 영향을 준다.