도구가 많아질수록 에이전트는 왜 더 멍청해질까: Tool Search로 컨텍스트 예산 관리하기

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 에이전트에게 도구를 많이 붙일수록 왜 성능과 비용이 동시에 나빠질 수 있을까?
• 핵심 출처:
  • Introducing Advanced Tool Use on the Claude Developer Platform - 2025-11-24, 확인일 2026-06-12
  • Tool search | OpenAI API - 게시일 미표기, 확인일 2026-06-12
  • Function calling | OpenAI API - 게시일 미표기, 확인일 2026-06-12
  • Tools - Model Context Protocol - draft 문서, 확인일 2026-06-12
  • Tool search tool - Claude API Docs - 게시일 미표기, 확인일 2026-06-12

1. 왜 지금 봐야 하나

AI 에이전트를 만들다 보면 처음에는 도구를 하나씩 붙이는 일이 즐겁다. GitHub 이슈 조회, Slack 검색, DB 쿼리, 배포 상태 확인, 결제 취소, 문서 검색, 캘린더 등록까지 연결하면 “이제 진짜 자동화가 되겠다”는 느낌이 든다. 그런데 도구가 5개에서 50개, 500개로 늘어나는 순간 문제가 바뀐다. 모델이 더 많은 일을 할 수 있게 되는 것이 아니라, 해야 할 일을 찾기 전에 도구 설명서부터 읽느라 컨텍스트와 주의력을 써버리는 시스템이 될 수 있다.

Anthropic의 Advanced Tool Use 글은 이 문제를 숫자로 보여준다. 여러 MCP 서버를 붙인 전통적 방식에서는 GitHub, Slack, Sentry, Grafana, Splunk 같은 도구 정의만으로 약 55K 토큰을 시작 전에 소비할 수 있고, 내부 사례에서는 최적화 전 도구 정의가 134K 토큰까지 커졌다고 설명한다. Anthropic은 Tool Search Tool을 통해 모든 도구 정의를 미리 넣는 대신 필요한 도구만 온디맨드로 로드하는 방식을 제시했고, OpenAI 문서도 많은 함수나 큰 스키마가 있을 때 tool_search로 드문 도구를 지연 로딩하라고 안내한다.

이 글의 핵심은 “새 API 옵션 소개”가 아니다. 에이전트 도구 설계의 기본 단위가 “모델에게 모든 도구를 보여주기”에서 도구 카탈로그, 즉시 사용 도구, 지연 로딩 도구, 검색 표면을 나누는 컨텍스트 예산 관리로 바뀌고 있다는 점이다.

2. 핵심 개념

Tool Search는 RAG와 비슷하지만 검색 대상이 문서가 아니라 도구 정의다. 모델이 처음부터 모든 함수의 이름, 설명, 파라미터 스키마를 보는 대신, 처음에는 검색 도구와 핵심 도구 몇 개만 본다. 이후 작업에 필요한 능력이 생기면 “billing refund tool”, “github pull request”, “sentry issue lookup” 같은 식으로 도구 카탈로그를 검색하고, 검색된 3~5개 정도의 도구 정의만 컨텍스트에 추가해 호출한다.

여기서 중요한 구분이 있다.

첫째, 즉시 로딩 도구다. 거의 모든 요청에서 쓰이거나, 안전상 항상 명확히 보여야 하거나, 모델이 시작부터 알아야 하는 도구다. 예를 들어 현재 사용자 정보 조회, 읽기 전용 로그 검색, 작업 상태 저장 같은 도구는 자주 쓰일 수 있다.

둘째, 지연 로딩 도구다. 사용 빈도는 낮지만 필요할 때는 정확히 찾아야 하는 도구다. OpenAI 문서는 함수나 namespace, MCP server에 defer_loading을 적용해 큰 도구 표면을 나중에 로드할 수 있다고 설명한다. Claude 문서도 defer_loading: true로 표시된 도구는 초기 프롬프트에 들어가지 않고, Tool Search Tool이 찾았을 때 참조가 확장된다고 설명한다.

셋째, 검색 표면이다. 도구 검색은 단순히 스키마를 숨기는 기능이 아니다. 모델이 검색할 수 있도록 namespace 이름, 서버 설명, 도구 이름, 파라미터 설명이 명확해야 한다. 도구 이름이 doThing2이고 설명이 “utility function”이면 검색해도 잘 찾을 수 없다. 반대로 billing.refundPayment, github.createPullRequest, sentry.findIssueByTraceId처럼 영역과 행위가 드러나면 모델이 더 잘 고른다.

넷째, 실행 표면이다. 검색으로 도구를 찾았다고 바로 안전한 것은 아니다. MCP Tools draft는 도구가 모델이 제어하는 capability이며, 사용자가 노출된 도구와 호출을 볼 수 있어야 하고 위험 작업에는 확인 절차가 필요하다고 강조한다. Tool Search는 권한 시스템을 대체하지 않는다. 이전 글의 표현을 빌리면, 검색은 “어떤 도구를 보여줄지”의 문제이고 권한은 “무엇을 실제로 실행할 수 있는지”의 문제다.

3. 최신 이슈와 연결

최근 주요 플랫폼 문서의 방향은 꽤 일관적이다.

Anthropic은 Advanced Tool Use에서 세 가지를 묶어 발표했다. Tool Search Tool은 수백·수천 개 도구 중 필요한 도구만 동적으로 발견하게 하고, Programmatic Tool Calling은 여러 도구 호출과 중간 데이터 처리를 코드 실행 환경에서 처리해 컨텍스트 오염을 줄인다. Tool Use Examples는 JSON Schema만으로 전달하기 어려운 사용 패턴을 예제로 보강한다. Anthropic은 Tool Search를 쓰면 50개 이상의 MCP 도구를 모두 로드하는 방식보다 토큰 사용을 크게 줄이고, 내부 MCP 평가에서 도구 선택 정확도가 좋아졌다고 설명한다.

OpenAI도 비슷한 문제를 문서화했다. Function Calling 문서는 함수 정의가 시스템 메시지에 주입되며 컨텍스트 한도와 입력 토큰 비용에 포함된다고 설명한다. 따라서 시작 시점에 사용 가능한 함수 수를 작게 유지하고, 많은 함수나 큰 스키마가 있으면 Tool Search로 큰 도구 표면을 지연 로딩하라고 권한다. Tool Search 가이드는 hosted tool search와 client-executed tool search를 나누며, deferred function, namespace, MCP server와 함께 사용할 수 있다고 설명한다.

MCP Tools draft는 프로토콜 레벨에서 tools/list, tools/call, inputSchema, 선택적 outputSchema, pagination, cache hint 같은 구조를 제공한다. 즉, 도구는 더 이상 애플리케이션 내부의 임시 함수 목록이 아니라, 검색·캐싱·권한·사용자 확인을 함께 설계해야 하는 외부 capability 목록이 되고 있다.

4. 개발자 관점 해석

에이전트가 도구를 잘 쓰게 하려면 “도구를 많이 붙이면 된다”가 아니라 “도구 표면을 작게 시작하고 필요할 때 넓힌다”가 기본값이 되어야 한다.

첫 번째 판단 기준은 초기 컨텍스트 비용이다. 도구 정의는 공짜가 아니다. 함수 이름, 설명, JSON Schema, enum, nested object, 예제는 모두 입력 토큰이고 모델의 주의 예산이다. 특히 고객지원, 백오피스, DevOps 에이전트처럼 SaaS API와 사내 도구가 많은 시스템은 실제 사용자 질문보다 도구 설명이 더 긴 프롬프트가 되기 쉽다.

두 번째 판단 기준은 도구 선택 오류다. 도구가 많아지면 비슷한 이름의 도구가 생긴다. user.search, user.lookup, member.find, account.get처럼 의미가 겹치면 모델은 올바른 도메인과 파라미터를 고르기 어렵다. Tool Search는 후보를 줄여주지만, 도구 이름과 설명이 부정확하면 검색 결과도 부정확해진다.

세 번째 판단 기준은 중간 결과 오염이다. 여러 도구 호출 결과를 매번 모델 컨텍스트에 모두 넣으면 다음 추론은 길고 지저분한 로그 위에서 일어난다. Programmatic Tool Calling이 강조하는 지점이 여기다. 루프, 필터링, 집계, 병렬 호출, 오류 재시도 같은 작업은 자연어 대화 기록으로 누적하기보다 코드 또는 애플리케이션 레이어에서 처리하고, 모델에는 결론과 필요한 근거만 돌려주는 편이 안정적일 수 있다.

네 번째 판단 기준은 권한과 감사 가능성이다. Tool Search를 붙이면 모델이 더 많은 도구를 “찾을 수” 있게 된다. 그러므로 도구 카탈로그에는 읽기 전용·쓰기·결제·삭제·배포 같은 위험 등급이 들어가야 한다. 검색 가능하다는 것과 실행 가능하다는 것을 분리해야 한다.

5. 내 프로젝트에 적용할 체크포인트

1. 도구 인벤토리를 먼저 만든다. 현재 에이전트에 노출한 함수, MCP 서버, built-in tool, 내부 API를 표로 적는다. 이름, 설명, 위험도, 예상 사용 빈도, 읽기/쓰기 여부를 함께 적는다.

2. 항상 로드할 도구를 3~10개로 줄인다. OpenAI 문서는 시작 시점의 함수 수를 작게 유지하라고 권한다. 숫자 자체보다 중요한 것은 “처음부터 보여줄 이유가 있는가”다.

3. 나머지는 namespace나 서버 단위로 묶는다. billing, github, observability, crm, deployment처럼 검색하기 쉬운 도메인 설명을 붙인다. 개별 함수 수십 개보다 의미 있는 namespace가 모델에게 더 좋은 검색 표면이 될 때가 많다.

4. 도구 설명은 검색 쿼리처럼 쓴다. “Fetch data”가 아니라 “Look up a Sentry issue by trace ID or error event ID”처럼 사용자가 말할 법한 단어와 도메인 단어를 넣는다.

5. 쓰기 도구는 검색 가능성과 실행 권한을 분리한다. 모델이 billing.cancelSubscription을 찾을 수는 있어도, 실행에는 사용자 확인·정책 검사·감사 로그가 필요할 수 있다.

6. 중간 결과는 모두 모델에 넣지 않는다. 대량 검색, 표 계산, 파일 스캔은 도구나 코드 실행 레이어에서 줄이고, 모델에는 “선택된 근거 + 요약 + 불확실성”을 전달한다.

7. 평가 세트를 만든다. “올바른 도구를 찾는가”, “비슷한 도구를 혼동하지 않는가”, “필수 파라미터가 없으면 질문하는가”, “쓰기 도구 전에 승인을 요구하는가”를 테스트한다.

6. 오늘 10분 액션

오늘은 새 기능을 붙이지 말고, 기존 에이전트의 도구 표면을 10분만 점검해보자.

1. 지금 모델 요청에 함께 보내는 tool/function 정의 개수를 센다.
2. 각 도구를 always, defer, remove 세 칸으로 나눈다.
3. always에는 정말 자주 쓰는 읽기 도구만 남긴다.
4. defer 도구에는 어떤 검색어로 발견되어야 하는지 한 줄 설명을 붙인다.
5. 위험한 쓰기 도구에는 “검색 가능”, “실행 가능”, “승인 필요”를 별도 컬럼으로 표시한다.

작은 팀이라면 실제 Tool Search API를 바로 도입하지 않아도 된다. 먼저 프롬프트에 들어가는 도구 정의를 줄이고, 라우터나 간단한 검색 함수로 관련 도구만 골라 넣는 실험부터 해도 충분하다. 중요한 것은 에이전트의 능력을 “도구 개수”로 보지 않고 “필요한 순간에 필요한 도구를 안정적으로 찾고 실행하는 구조”로 보는 습관이다.

7. 더 볼 자료

• Anthropic의 Advanced Tool Use 글은 Tool Search, Programmatic Tool Calling, Tool Use Examples가 각각 어떤 병목을 줄이려는지 보여준다.
• OpenAI Tool Search 가이드는 hosted search와 client-executed search, deferred function, namespace, MCP server를 어떻게 조합하는지 확인하기 좋다.
• OpenAI Function Calling 문서는 도구 정의가 컨텍스트와 비용에 포함된다는 점, strict mode, tool choice, 함수 수를 줄이는 설계 팁을 함께 설명한다.
• MCP Tools draft는 에이전트 도구를 프로토콜 capability로 볼 때 필요한 tools/list, tools/call, schema, 캐싱, 사용자 확인 요구를 정리한다.
• Claude Tool Search Tool 문서는 deferred tool loading이 prompt caching과 strict mode와 어떻게 함께 동작하는지 이해하는 데 도움이 된다.

중복 회피 메모

최근 ai_dev 글은 장기 컨텍스트 관리, 에이전트 권한 계약, prefill/decode 기반 서빙 지연, RAG 검색 품질을 다뤘다. 이번 글은 권한 승인 자체나 RAG 문서 검색이 아니라, 에이전트에 노출되는 도구 정의가 컨텍스트 예산과 도구 선택 정확도에 미치는 영향, 그리고 Tool Search/deferred loading으로 도구 표면을 설계하는 방법에 집중한다.