에이전트가 도구를 잘 쓰게 만들고 싶을 때 흔히 떠올리는 출발점은 사용자 요청이다. ‘이번 주 매출을 정리해 줘’ 같은 문장을 먼저 만들고, 그 요청을 해결하는 API 호출을 뒤에서 찾는다. 하지만 실제 자동화에서는 이 순서가 자주 흔들린다. 요청 문장은 그럴듯해도 권한이 없거나, 입력 형식이 맞지 않거나, 필요한 도구 조합이 성립하지 않아 실행 경로를 완성하지 못할 수 있다.
Google Research가 9월 10일 소개한 ToolGrad는 이 순서를 뒤집는다. 먼저 실제로 성공한 도구 호출 연쇄를 만들고, 그 연쇄에 맞는 사용자 요청을 나중에 붙인다. ACL 2026 Findings에 실린 논문은 이를 ‘answer-first’ 방식으로 설명한다. 학습용 데이터에서 가장 비싼 낭비가 자연스러운 질문을 만드는 일이 아니라, 끝내 실행되지 않는 호출 경로에 주석을 다는 일일 수 있다는 문제의식이다.
질문 우선 방식에서 무엇이 새나
전통적인 합성 데이터 흐름은 대체로 API 후보군에서 가상의 요청을 만들고, 에이전트가 탐색으로 답을 찾게 한다. 논문이 비교 대상으로 든 방식은 깊이 우선 탐색(DFS)을 사용한다. DFS는 가능한 경로를 따라 내려가며 해답을 찾는 방법이다. 도구가 많고 호출 단계가 길어질수록 실패한 후보도 함께 늘어난다.
여기서 실패는 모델의 답변이 틀렸다는 뜻만이 아니다. 호출 인자가 API 규격과 맞지 않거나, 앞 단계 출력이 다음 단계 입력으로 이어지지 않거나, 호출 자체가 실패하는 경우도 포함된다. 이런 궤적을 학습 데이터로 남기면 모델은 문제 해결법보다 우연한 형식을 배울 위험이 있다. 반대로 실패 사례를 학습에 쓰려면, 단순히 실패했다는 표시가 아니라 어떤 조건에서 왜 잘못됐는지를 별도로 설계해야 한다.
ToolGrad는 실행 결과를 다음 선택의 근거로 쓴다
ToolGrad는 API Proposer, API Executors, API Selector, LLM Updater라는 네 모듈을 순서대로 둔다. 제안 모듈이 현재 워크플로를 늘릴 후보 API를 고르고, 실행 모듈이 후보를 병렬로 시험한다. 선택 모듈은 실행 보고서를 보고 다음 단계에 붙일 호출 하나를 고른다. 마지막으로 업데이트 모듈이 바뀐 API 집합에 맞춰 사용자 요청과 응답을 고친다.
여기서 ‘텍스트 그래디언트’는 수학적 미분값이 아니다. 실행 보고서처럼 다음 선택을 더 낫게 만드는 자연어 피드백을 가리킨다. 예를 들어 호출이 성공했는지, 어떤 입력을 받았는지, 결과가 뒤 단계에 쓸 수 있는지 같은 기록이 다음 후보를 거르는 기준이 된다. 따라서 이 접근은 도구 선택을 한 번에 맞히는 모델을 만들겠다는 주장이라기보다, 검증된 경로를 합성 데이터의 출발점으로 쓰겠다는 설계에 가깝다.
Google Research의 설명에 따르면 ToolBench의 1만 6천 개 이상 실제 API를 사용해 데이터를 만들었고, ToolGrad-500으로 Gemma 3의 1B·4B·12B 모델을 후학습했다. ACL 논문은 ToolGrad-500이 더 복잡한 도구 사용을 담으면서도 거의 100%의 통과율을 보였다고 보고한다. 다만 이 수치는 생성 파이프라인과 해당 평가 설정에서의 결과다. 조직의 사내 API, 권한 모델, 데이터 품질에서 같은 비율이 나온다고 받아들일 근거는 아니다.
작은 자동화에도 적용할 수 있는 데이터 기준
이 연구를 사내 모델 학습으로 곧바로 연결할 필요는 없다. 대부분의 팀은 대규모 후학습보다 업무 자동화의 프롬프트와 테스트 사례를 먼저 관리하게 된다. 그때도 질문 목록만 모으는 방식보다, 실제로 재현된 실행 기록에서 시작하는 편이 유용하다.
가령 CRM에서 이번 달 미접촉 고객을 찾아 담당자에게 초안 메시지를 만드는 자동화를 생각해 볼 수 있다. 학습 또는 평가 사례 한 건에는 자연어 요청만 넣지 않는다. 사용한 조회 조건, 반환된 필드, 빈 결과일 때의 처리, 초안 생성이 외부 발송과 분리됐는지까지 남긴다. 이렇게 하면 모델 교체 뒤에도 ‘문장을 잘 썼는가’와 ‘올바른 고객만 조회했는가’를 나눠 점검할 수 있다.
실행 가능한 경로가 곧 업무상 안전한 경로는 아니라는 점도 중요하다. ToolGrad의 공개 저장소에는 MCP 파일시스템 데모가 있지만, 데모가 작동한다는 사실이 운영 권한을 정당화하지는 않는다. 읽기 전용 도구, 샌드박스 데이터, 발송·수정 전 사람 승인 같은 경계는 데이터 생성 단계와 별도로 둬야 한다. 성공률을 올리려다 과도한 권한을 준다면, 그 데이터는 재사용할수록 더 위험해질 수 있다.
실험은 세 가지 기록으로 시작하면 된다
- 성공한 경로를 먼저 고른다. 자주 쓰는 읽기 전용 업무 하나를 정하고, 실제 입력·호출 순서·출력 검사를 한 사례로 저장한다. 개인정보와 운영 데이터는 익명화하거나 테스트 데이터로 바꾼다.
- 실패를 이유와 함께 분리한다. 권한 거부, 필수 인자 누락, 결과 없음, 형식 불일치를 같은 ‘실패’로 묶지 않는다. 재시도해도 되는 실패와 사람 검토가 필요한 실패를 구분한다.
- 질문을 나중에 다양화한다. 검증된 경로 하나에 대해 여러 표현의 요청을 붙여 본다. 이때 표현이 달라도 호출 범위와 승인 조건이 바뀌지 않는지 회귀 테스트로 확인한다.
성능 숫자보다 남겨야 할 것
ToolGrad의 흥미로운 점은 에이전트 품질을 모델 이름이나 벤치마크 점수만으로 보지 않는 데 있다. 실제 도구 사용에서 필요한 것은 유창한 요청 해석과 함께, 어떤 호출이 어떤 결과를 냈는지 되짚을 수 있는 경로다. 학습 데이터든 테스트 세트든 실행 보고서를 남기면, 모델이 실패했을 때 프롬프트 문제인지 도구 규격 문제인지 권한 문제인지 좁혀 볼 수 있다.
논문의 비교 결과는 연구 환경의 데이터 생성 효율과 도구 호출 성능을 보여 준다. 이를 특정 제품의 즉시 도입 근거로 확대하면 안 된다. 그래도 개인이나 작은 팀이 에이전트를 시험할 때 ‘좋은 질문을 더 많이 모으자’에서 한 걸음 옮길 힌트는 된다. 먼저 재현 가능한 작업 경로를 만들고, 그 경로가 틀리거나 멈췄을 때 남길 기록을 정한 뒤, 그 위에 자연어 요청을 쌓는 방식이다.