AI 에이전트 개발에서 간과하기 쉬운 병목은 모델 자체보다 학습 데이터의 실행 가능성이다. 도구 사용 데이터는 대체로 사용자 질의, API 워크플로, 최종 응답을 하나의 묶음으로 다룬다. 이 가운데 질의와 응답이 자연스러워도 중간 API 경로가 작동하지 않는다면 신뢰할 수 있는 학습 사례로 보기 어렵다.
따라서 데이터 생성 방식을 평가할 때는 두 가지를 구분해야 한다. 하나는 문장과 과제가 사용자 관점에서 타당한지이고, 다른 하나는 연결된 도구 호출이 실제로 실행되는지다. ToolGrad는 후자를 생성 과정의 앞단에 배치했다는 점에서 주목할 만하다.
데이터 생성 순서는 비용 구조를 결정한다
기존 ToolBench 방식은 API 풀을 토대로 가상의 사용자 지시를 만든 후 DFS로 해결 경로를 찾는다. 이 접근에서는 가능한 경로를 탐색하고 도구를 실행하는 시행착오가 필요하다. 성공한 경로를 확보하면 데이터로 사용할 수 있지만, 적절한 경로를 찾지 못하면 실행 비용을 쓰고도 주석 생성에 실패할 수 있다.2
이는 단순한 알고리즘 선택 문제가 아니다. 질의를 먼저 정하면 시스템은 그 질의를 해결할 경로를 찾아야 하고, 경로를 먼저 검증하면 시스템은 이미 해결 가능한 작업에 맞춰 질의를 구성할 수 있다. 어느 순서를 택하느냐에 따라 데이터 생산 과정에서 실패가 발생하는 지점도 달라진다.
Google Research가 ACL 2026 Findings 프레임워크로 공개한 ToolGrad는 검증된 API 체인을 먼저 구축한 다음 이에 대응하는 사용자 질의를 작성한다.1 정적인 프롬프트 하나에 의존하기보다, 대규모 도구 라이브러리에서 유효한 워크플로를 반복적으로 구성하는 데 텍스트 그래디언트를 활용한다.
여기서 텍스트 그래디언트는 수학적인 미분값이 아니라 LLM 비평가가 자연어로 제공하는 구체적인 개선 피드백이다. ToolGrad는 API Proposer, API Executors, API Selector, LLM Updater라는 네 모듈을 중심으로 이 반복 과정을 구성한다.1 핵심은 피드백을 문장 수정에만 쓰지 않고 API 체인의 유효성을 높이는 과정에 연결한다는 데 있다.
수치는 ‘무엇이 검증됐는가’와 함께 읽어야 한다
ToolGrad는 ToolBench에서 99.8%의 통과율을 기록했고, DFS 검색은 63.8%를 기록했다.2 이 비교가 직접 보여주는 것은 해당 평가 조건에서 유효한 도구 사용 사례를 구성하는 능력의 차이다. 이를 모든 에이전트 환경에서의 성능 우위나 운영 비용 절감으로 곧바로 확대 해석해서는 안 된다.
다운스트림 결과도 같은 방식으로 읽을 필요가 있다. ToolGrad 데이터 500개로 미세조정된 Gemma-3-12B는 BFCL에서 83.1점을 기록했으며, Gemini 2.5 Pro는 83.2점을 기록했다.1 적은 수의 생성 데이터가 모델 학습에 유용할 가능성을 보여주는 결과지만, 두 점수의 근접성만으로 모델의 전반적인 능력이나 실제 서비스 안정성이 같다고 판단할 수는 없다.
결국 확인해야 할 것은 점수 하나가 아니라 증거의 연결이다. 생성된 API 체인이 실행되는지, 그 체인으로부터 만든 질의가 자연스럽고 의미 있는지, 그리고 해당 데이터로 학습한 모델이 새로운 도구와 과제에서도 성과를 유지하는지를 단계별로 살펴봐야 한다.
실행 가능성을 높이면 다른 품질 기준이 중요해진다
워크플로를 먼저 검증하는 설계는 탐색 실패를 줄이는 방향과 잘 맞는다. 반면 실행 가능한 체인이 존재한다는 사실만으로 그 체인이 실제 사용자의 요구를 잘 대표한다고 보장되지는 않는다. 따라서 ToolGrad 같은 방식을 평가할 때는 다음 항목을 분리해서 보는 편이 합리적이다.
API 체인의 실행 및 검증 통과율
유효한 체인을 얻기까지 필요한 도구 호출과 반복 과정
체인에 맞춰 생성된 사용자 질의의 자연스러움과 다양성
생성 데이터로 학습한 모델의 새로운 도구에 대한 적용 가능성
벤치마크 결과와 실제 운영 조건 사이의 차이
이 구분은 데이터 양 중심의 평가가 놓치기 쉬운 부분을 드러낸다. 많은 샘플을 확보했더라도 실행 실패가 잦으면 학습 신호의 신뢰도가 낮아질 수 있다. 반대로 실행 검증률이 높아도 질의의 범위가 제한적이라면 실제 사용자 요청을 충분히 포괄하는지 별도로 점검해야 한다.
다음 단계는 재현성과 비용 측정이다
코드, 데이터셋, 모델이 Apache-2.0 라이선스로 공개됐다는 점은 외부에서 ToolGrad를 재현하고 다른 도구 환경에 적용해 볼 수 있는 기반을 제공한다.1 앞으로는 ToolBench와 BFCL의 결과가 서로 다른 API 라이브러리와 운영 조건에서도 유지되는지, 텍스트 그래디언트 반복에 필요한 전체 실행 비용이 어느 정도인지, 실행 가능성과 질의 품질 사이의 균형을 어떻게 측정할지가 중요하다.
ToolGrad의 의미는 특정 점수에만 있지 않다. 도구 사용 데이터를 만들 때 먼저 질문을 생성하고 답을 탐색할 것인지, 아니면 검증된 해결 경로를 확보한 뒤 학습 사례를 설계할 것인지라는 데이터 엔지니어링 선택을 전면에 드러냈다는 점이 더 중요하다.
1ToolGrad: Efficient tool-use dataset generation with textual "gradients"
2ToolGrad: Efficient Tool-use Dataset Generation with Textual "Gradients"
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.