AI 에이전트 도구 8200개, 토큰 40% 줄인 게이트웨이

도구를 늘릴수록 에이전트가 길을 잃는다

AI 에이전트에 도구(tool, 모델이 직접 호출할 수 있는 외부 기능)를 붙이는 일은 이제 기본 설계에 가깝다. 캘린더를 읽고, 사내 문서를 검색하고, 티켓을 생성한다. 그런데 도구를 늘리면 금세 벽에 부딪힌다. 모델이 도구를 고르려면 그 도구의 설명을 문맥에 넣어야 하는데, 넣을 수 있는 분량이 정해져 있기 때문이다. 열 개는 쉽고, 백 개는 비싸고, 수천 개는 아예 불가능하다.

다단계 작업에서는 이 문제가 더 날카로워진다. 여러 단계를 거치는 과제는 필요한 도구 하나만 빠져도 그대로 실패한다. '많이 담기'와 '정확히 고르기'가 동시에 요구되는 셈이다.

핵심: 8,200개를 3개 인터페이스 뒤로 숨겼다

이 논문이 다루는 플랫폼에는 약 8,200개의 도구가 있다. 저자들은 그 정의를 모두 합치면 평가에 쓴 어떤 모델의 문맥 창에도 들어가지 않는다고 적는다. 제안은 간단하다. 도구 목록을 모델에 넣지 말고, 고정된 3개의 인터페이스만 노출한 뒤 그 안에서 필요한 도구를 찾아 주는 것이다. 일반적인 MCP 서버가 드러내는 도구 수보다 수백 배 많은 범위를 같은 문맥 비용으로 다루게 된다.

보고된 측정 결과는 다음과 같다.

벤치마크 점수만이 아니라 실제 청구된 비용을 기준으로 절감을 보고한 점이 눈에 띈다.

어떻게 동작하는가: 위치가 곧 설계다

기술적 핵심은 검색 모델이 아니라 '어디에 두는가'다. 이 시스템은 에이전트와 도구 사이의 게이트웨이에서 돈다. 에이전트의 모든 호출이 이 지점을 지나므로, 여기서 세 가지를 한꺼번에 처리할 수 있다. 첫째, 과제에 필요한 도구를 추천한다. 둘째, 호출을 최종 사용자 본인의 자격증명으로 실행한다. 셋째, 그 호출이 사용자가 서비스별로 허용한 범위와 에이전트에 허용한 도구 목록에 들어맞는지 대조한다.

추천과 권한 확인이 같은 자리에서 일어난다는 점이 중요하다. 도구를 수천 개로 늘리면 '에이전트가 무엇을 건드릴 수 있는가'가 통제하기 어려워지는데, 관문이 하나라면 거기서 막을 수 있다.

그래서 진짜 의미하는 것

조심해서 읽어야 할 부분이 셋 있다. 첫째, 이 수치는 해당 플랫폼을 운영하는 쪽이 자기 시스템을 보고한 결과이고 독립적인 재현 결과가 아니다. 둘째, 비교 기준이 '고정된 100개 도구 목록'이다. 운영자가 과제에 맞춰 도구를 미리 잘 골라 둔 설정과 비교한 것이 아니므로, 절감 폭은 기준선을 어떻게 잡느냐에 따라 달라진다. 셋째, 종단 실험은 14회 실행과 Codex 세션 단위 집계로 표본이 크지 않다.

그 전제를 달고 보면 함의는 분명하다. 지금 에이전트 비용의 상당 부분은 '쓰지 않을 도구 설명을 매 호출마다 다시 읽히는 값'이다. 토큰을 17%에서 40%까지 줄이면서 과제 완료율이 같았다는 결과는, 그 부분이 성능에 기여하지 않는 낭비였다는 쪽에 가깝다.

실무에서 당장 점검할 수 있는 숫자도 있다. 에이전트에 붙인 도구 정의가 프롬프트의 몇 퍼센트를 차지하는지, 그중 실제로 호출되는 비율이 얼마인지다. 두 숫자의 격차가 크다면 도구를 검색해서 꺼내 쓰는 구조로 바꿀 여지가 있다.

마무리

도구를 많이 붙일수록 좋은 에이전트가 되는 것은 아니다. 이 논문은 '전부 보여주기'를 '필요할 때 찾아 주기'로 바꾸는 쪽이 비용과 성공률 모두에서 낫다는 사례를 운영 데이터로 제시한다. 다만 수치가 운영 주체의 자체 보고라는 점을 감안해, 자기 환경에서 기준선을 직접 잡고 비교해 보는 편이 안전하다.

출처: Sam Partee, River Stevens, Thierry Damiba 외 1명, "Tool Recommendation for Multi-Step Agents: Finding Every Tool a Task Needs", arXiv:2610.23707v1, 2026년 10월 16일. arxiv.org/abs/2610.23707v1