도구를 쓰는 AI를 키울 때 문제 수보다 무엇을 늘려야 할까

배경과 문제

대규모 언어 모델(LLM)은 여러 단계에 걸쳐 도구를 선택하고 조합하며 상태 변화를 추적하는 도구 사용 에이전트로 발전해 왔다. 이러한 에이전트는 새로운 API를 가진 환경에도 일반화해야 하므로, 다양하고 고품질의 학습 데이터가 필수적이다. 그러나 인터넷 텍스트에는 다단계 도구 상호작용이 드물고, 현실적인 과제·다양한 도구·풍부한 환경 데이터를 모두 갖춘 데이터를 만드는 것은 어렵다.

기존 연구는 LLM을 이용해 도구 사용 데이터를 합성해 왔지만, 대부분 상태가 없는 읽기 전용 도구에 집중하거나 LLM이 도구 응답을 시뮬레이션하는 방식에 의존했다. 복잡한 도구 출력과 상태 전이를 신뢰성 있게 시뮬레이션하기 어렵다는 한계가 있다. 또 다른 접근은 코드로 실행 가능한 도구 환경을 합성하지만, 주로 데이터 양을 늘리는 데 초점을 맞추어 어떤 데이터 속성이 성능을 좌우하는지 밝히지 못했다. 이 논문은 도구 다양성, 과제 다양성, 데이터베이스 상태 다양성이 일반화에 미치는 영향을 분리하여 분석한다.

기존 접근의 한계

LLM이 도구 응답을 시뮬레이션하는 방식(예: Nemotron-Agentic, SimSAT)은 대규모 데이터를 만들 수 있지만, 도구 출력이 복잡해지거나 상태 전이가 많아지면 시뮬레이션이 실제와 달라질 위험이 크다. 반면 코드 기반 실행 환경을 합성하는 방식(예: Agent World Model, EnvScaler, EnvFactory)은 신뢰성은 높지만, 생성된 데이터의 어떤 속성이 성능 향상을 이끄는지에 대한 통제된 분석이 부족했다.

또한 기존 스케일링 연구는 주로 합성 환경의 수를 늘리거나 고정된 과제 수에서 도메인 다양성만 살펴보았다. 고정된 데이터 예산을 새로운 도구, 기존 도구의 추가 과제, 기존 과제의 대체 데이터베이스 상태 사이에 어떻게 배분해야 하는지에 대한 체계적 연구는 없었다. 이 논문은 바로 이 배분 문제를 다룬다.

연구방법을 단계별로

SynthAPI는 두 단계로 구성된다. 첫 단계에서는 '빌더 LLM'(인터넷 접속을 끊은 Gemini-3.1 Pro)이 앱을 생성한다. 먼저 쇼핑, 음악, 생산성, 금융, 피트니스, 메시징, 유틸리티, 소셜 등 8개 분류에서 앱 이름·설명·기능 목록을 만들고, 이어서 Python Enum과 dataclass로 데이터베이스 스키마(db.py)를 정의한다. 마지막으로 이 스키마 위에서 동작하는 API 함수 모음(apis.py)을 생성한다. 각 API는 데이터베이스 객체를 입력받아 읽거나 수정하며, 공개 함수만 에이전트가 호출할 수 있는 도구로 노출된다.

두 번째 단계에서는 과제를 생성한다. 과제는 지시문 x, 검증기 v, 초기 데이터베이스 상태 Db0, 오라클 솔버 π*로 구성된다. 먼저 앱의 기능 목록에서 일부를 샘플링해 모호하지 않은 과제 지시문을 만들고, 이 지시문이 충족되었는지 판단하는 Python 검증기를 생성한다. 그런 다음 과제를 풀기 위한 최소 데이터(Db0core)와 방해 데이터(Db01 등)를 단계적으로 추가해 초기 상태를 만든다. 마지막으로 오라클 솔버를 생성해 과제가 실제로 풀리는지 확인하고, 초기 상태에서 검증기가 거짓이고 솔버 실행 후 참이 되는 과제만 남긴다. 다만 이 검사는 과제를 풀 수 있고 검증기가 솔버와 일관되게 동작하는지 확인한다. 검증기 자체가 지시문의 뜻을 빠짐없이 표현했는지까지 증명하지는 않는다.

에이전트는 Python 코드 블록을 실행하여 도구를 호출한다. 모든 도구 정의를 처음부터 주는 대신 list_apps, list_tools, get_tool_documentation 같은 메타 도구로 필요한 도구를 탐색한다. 과제가 끝났다고 판단하면 complete_task를 호출하고, 검증기가 참을 반환해야 성공으로 기록된다. 학습 데이터는 GLM-5.2 전문가 모델이 각 과제를 최대 4회 시도하여 처음 성공한 궤적만 남기고, Qwen3.5 계열 학생 모델에 다음 토큰 예측 손실로 지도 학습(SFT)한다. 손실은 추론 및 행동 토큰에만 적용된다.

결과와 숫자의 의미

저자들은 총 458,752개 과제, 64개 앱, 10,472개 API(쓰기 6,266개, 읽기 4,206개)를 생성하고 Qwen3.5의 2B·4B·9B·27B 크기를 대상으로 849회의 지도 미세조정 실험을 했다. 데이터 구성은 네 가지 축으로 제어된다: 앱 수 A, 앱당 과제 수 T, 과제당 초기 데이터베이스 수 S, 방해 데이터 깊이 D. 총 과제 수는 N = A × T × S로 계산되며, D는 방해 데이터를 추가하는 깊이이며 과제 수 자체를 늘리지는 않는다. 성능 분석의 중심은 AppWorld와 새 앱 4개·과제 100개의 SynthAPI-Holdout이며, AppWorld Test-N은 168개, Test-C는 417개 과제다. 성공률은 네 번 시도의 평균으로 평가한다.

고정 과제 예산에서 앱 수와 과제 수를 배분하는 실험(9B 모델 기준)에서, 낮은 예산(64~512개 과제)에서는 앱 수가 적은 A=8이 가장 좋았지만, 4096개 이상에서는 A=64가 명확히 우세했다. 데이터베이스 다양성 S도 비슷한 패턴을 보였다. 32~512개 과제에서는 S=1이, 512~4096개에서는 S=2가, 그 이상에서는 S=4가 최적이었다. 방해 데이터 깊이 D는 높은 과제 예산에서 D=4가 D=1,2보다 큰 향상을 가져왔다. 이러한 경향은 해당 실험 규모에서 관찰된 것이며 보편적 임계값은 아니다.

이 관찰을 바탕으로 데이터 구성 의존 스케일링 법칙을 세웠다. 이 법칙은 상위 25% FLOPs의 실행을 보류하고 나머지로 적합했을 때, 보류된 실행(최대 16배 큰 FLOPs 예산 포함)에서 정규화 점수 예측의 평균 절대 오차(MAE)가 0.0285였다. 반면 과제 수만 사용하는 법칙은 MAE가 0.1706으로 훨씬 나빴다. 여기서 비교식은 전체 궤적 수만 반영하며, 연산량은 보류할 큰 학습 실험을 정하는 데 사용한다. 이 실험에서는 양만으로 예측할 때보다 구성까지 반영할 때 외삽 오차가 작았다는 뜻이다.

최적 구성(A=64, T=128, S=4, D=4)과 차선 구성(A=32, T=1024, S=1, D=2)을 고정 과제 예산 32,768개에서 비교한 결과, Table 1에 제시한 4B·9B·27B의 네 벤치마크에서 최적 구성이 더 나았다. 예를 들어 4B 모델의 AppWorld Test-C 성공률은 38.4%에서 45.0%로 6.6%p 상승했고, 9B는 53.0%에서 56.2%로 3.2%p, 27B는 73.8%에서 74.1%로 0.3%p 상승했다. 과제 수가 같아도 궤적 길이와 학습 토큰 수가 달라 연산량까지 같다는 뜻은 아니다. SynthAPI-Big(전체 데이터, 4 에포크)은 AppWorld Test-C에서 4B 66.4%, 9B 77.0%, 27B 81.5%를 기록했다.

구체적인 예시

작동 원리를 풀어 쓴 가상의 쇼핑 앱 예로 들면, '빨간 머그컵을 사라'는 과제를 위해 제품, 사용자, 장바구니, 주문 등의 데이터 클래스가 필요하다. SynthAPI는 먼저 이 과제를 풀기 위한 최소 데이터(빨간 머그컵 제품, 사용자 계정)를 만들고, 이후 방해 데이터로 유사한 제품, 다른 사용자의 주문, 관련 없는 리뷰 등을 추가한다. 에이전트는 list_tools로 검색 API를 찾고, get_tool_documentation으로 인자 형식을 확인한 뒤, 검색 결과에서 올바른 제품 ID를 찾아 장바구니에 담고 주문을 완료해야 한다.

검증기는 데이터베이스 상태를 검사하여 주문이 올바른 제품과 수량으로 생성되었는지 확인한다. 오라클 솔버는 전체 데이터베이스 객체에 접근할 수 있어 정확한 제품 ID를 바로 알지만, 에이전트는 API를 통해 탐색해야 한다. 이 차이가 에이전트 학습의 핵심 난점을 만든다. 방해 데이터가 많아질수록 에이전트는 더 정교한 검색과 판단을 해야 하므로, D를 늘리는 효과를 시험할 수 있다. D=4가 유리했다는 증거는 이 가상 예시 자체가 아니라 앞서 소개한 실험 결과다.

한계와 오해하기 쉬운 점

이 연구의 스케일링 법칙은 SynthAPI라는 단일 데이터 파이프라인과 특정 모델 범위에서만 검증되었다. 부록은 별도의 SimSAT 데이터에서도 앱 수와 과제 수의 배분 경향을 128~1,024개 과제 예산에서 추가 확인했다. 그러나 전체 예측식과 모든 구성 요소가 다른 파이프라인·학습 설정에 그대로 전이된다고 검증한 것은 아니다. 또한 SynthAPI는 사용자와의 대화형 상호작용(질문을 통한 명확화)을 시뮬레이션하지 않으며, 긴 이메일 체인이나 복잡한 문서 같은 의미적 깊이가 있는 정보 검색 과제는 부족하다.

숫자를 해석할 때 주의할 점이 있다. MAE 0.0285는 정규화 점수의 예측 오차이지 실패 확률 2.85%가 아니다. 정규화 점수는 제로샷 성능을 0, 학습된 모델 중 최고 성능을 1로 놓은 상대 척도이다. 또한 Table 1의 SynthAPI-Big은 추가 규모와 4 에포크 학습을 사용하므로 고정 예산의 SynthAPI-Opt와 직접 비교하면 안 된다. Table 2의 BFCL 결과는 Qwen3 모델, AppWorld 결과는 Qwen3.5 모델 기준이므로 모델을 혼동하지 말아야 한다. 기존 연구의 SFT+RL 방식과 대규모 SFT만 사용한 이 연구는 학습 규모가 달라 합성 방법만의 인과적 우위나 데이터 효율성을 증명하지 않는다.

실제로 어떻게 활용할까

이 연구의 실용적 교훈은 총 과제 수만 기록하지 말고 앱 수·앱당 지시 수·초기 데이터 상태·방해 데이터 깊이도 함께 설계하라는 것이다. 논문의 32,768개 과제 실험에서는 32개 앱에 각 1,024개 지시와 한 초기 상태를 둔 구성보다, 64개 앱에 각 128개 지시와 네 초기 상태를 둔 구성이 좋았다. 두 구성의 방해 데이터 깊이도 각각 2와 4로 달라, 앱 수 하나만 바꾼 실험은 아니다. 이 비율을 모든 업무의 최적 배합으로 받아들이기보다 자체 평가로 시험할 가설로 쓰는 것이 적절하다.

또한 이 스케일링 법칙은 새로운 데이터를 생성하기 전에 특정 FLOPs 예산에서 최적의 데이터 구성을 예측하는 데 사용할 수 있다. 연구자나 엔지니어는 소규모 실험으로 법칙을 적합한 뒤, 더 큰 예산에서의 성능을 외삽하여 데이터 생성 전략을 결정할 수 있다. 다만 이 법칙은 SynthAPI와 유사한 실행 가능한 환경 합성 파이프라인에 한정되므로, 다른 유형의 도구 사용 데이터에는 추가 검증이 필요하다.