수백 개의 도구를 가진 에이전트

도구(Tools)가 언어 모델을 에이전트로 변화시켰고, Model Context Protocol (MCP)은 이들을 연결하는 비용을 충분히 저렴하게 만들어서 아무도 세 개에서 멈추지 않게 했습니다. 에이전트가 접해야 하는 모든 시스템은 자체적인 도구 세트를 추가하며, 각각 수십 개의 엔드포인트를 가집니다. 따라서 처음에는 세 개의 도구로 시작한 에이전트는 어떤 작업에 필요하든 간에 훨씬 더 많은 것을 마주하게 됩니다. 문제는 이러한 정의들이 모두 컨텍스트 창(context window)에 미리 로드된다는 것입니다. 첫 번째 메시지가 도착하기 전에 이미 상당 부분이 사라집니다. 그리고 비슷해 보이는 도구가 너무 많기 때문에, 모델은 예상보다 자주 잘못된 것을 선택합니다. 완전히 실패하는 것은 없지만, 에이전트는 더 오래 걸리고 턴당 비용이 더 많이 들며, 때때로 로그에 단 하나의 오류도 없이 잘못된 행동을 합니다.

이렇게 많은 도구를 연결하는 것은 배선(wiring) 문제가 아니라 컨텍스트 문제입니다. 모델이 무엇을 언제 보는지에 따라 에이전트가 작동할지 여부가 결정됩니다. 이 결정은 모델 주변의 하네스(harness), 루프, 그리고 도구링(tooling)에 속하며, 그 안에 어떤 모델이 자리 잡든 사용자의 몫입니다. '점진적 공개(progressive disclosure)'라고 불리는 패턴에서, 모델은 전체 카탈로그를 결코 보지 못합니다.

모든 도구가 어디서 오는가

대부분의 이 도구들은 최초의 MCP 서버로 거슬러 올라가는 습관에서 비롯됩니다. 당시 일반적인 구축 방식은 API의 모든 엔드포인트를 자체 도구에 매핑하는 것이었습니다. 이것이 하나의 통합(integration)을 아무도 에이전트가 필요로 하는지 묻기도 전에 수십 개의 도구로 변하게 만듭니다. Neon의 최근 영상 MCP Just Got a Whole Lot Better은 이러한 습관이 어떻게 생겨났는지, 그리고 그 결과 Neon이 자체 서버에서 무엇을 변경했는지를 설명하므로, 서버 측 관점을 원한다면 시작하기 좋은 곳입니다.

도구 정의(tool definitions)는 턴마다 청구되며, 프롬프트 캐싱(prompt caching)이 활성화된 경우 할인이 적용됩니다. MCP 클라이언트 모범 사례는 이들을 모두 로드하는 것과 필요할 때 가져오는 것 사이의 차이를 보여줍니다:

출처: MCP 클라이언트 모범 사례, Model Context Protocol 문서에서 가져옴.

잘못된 도구는 청구서에서 볼 수 없는 부분과 같으며, Anthropic의 도구 검색 문서에 따르면 Claude가 올바른 도구를 선택하는 능력은 사용 가능한 도구가 30~50개를 초과하면 저하됩니다. 이 한계는 이미 각각 수십 개의 도구를 통합한 두 가지 통합만으로도 넘어선 수준입니다. 고급 도구 사용을 소개한 게시물에서는 Anthropic 자체 MCP 평가에서 도구 검색이 만드는 차이를 측정했습니다:

모델이 요청한 정의만 컨텍스트에 들어갑니다.

MCP 가이드는 이 패턴을 점진적 발견(progressive discovery)이라고 부르며, 나중에 검색할 때 알아두면 좋을 이름이므로 언급하며, 여러 서버에 연결되는 클라이언트에 권장합니다.

점진적 공개(Progressive disclosure)는 도구 정의가 컨텍스트 창의 상당 부분을 차지하여 회수할 가치가 있을 때만 효과를 발휘합니다. 그보다 적거나 모든 요청에서 모든 도구가 사용될 경우에는 일반적인 도구 호출(plain tool calling)이 더 적합합니다. 이 가이드에서는 라인을 어디에 놓을지 예시로 컨텍스트 창의 1%~5%를 제시하는 반면, Anthropic은 10개의 도구나 정의 10,000 토큰에서 자체적으로 기준을 설정합니다.

모델이 무언가를 요청하면, 누군가가 무엇이 일치하는지 결정해야 하며, 이 가이드에서는 이를 수행하는 네 가지 방법을 나열합니다:

• 키워드 매칭(Keyword matching), BM25 또는 정규 표현식(regex): 도구 이름과 설명이 서술적일 때 간단하고 잘 작동합니다.
• 도구 설명을 이용한 임베딩(Embeddings over the tool descriptions): 동의어와 키워드가 놓치는 구문을 처리할 수 있습니다.
• 작고 빠른 모델을 서브 에이전트(sub-agent)로 사용하여 작업에 맞는 도구를 선택하게 하는 방식: 보통 잘 작동하지만 비용이 더 많이 들 수 있습니다.
• 하이브리드 방식: 키워드 및 임베딩 순위를 점수화하거나 사용 사례별로 전략을 전환하는 방식

위 네 가지 방법은 제공업체가 자체적인 도구 검색 기능을 제공하지 않거나, 사용자 지정 순위가 필요할 때 구축해야 하는 것들입니다.

한 가지 주의할 점은 검색 결과가 비어올 수 있다는 것이며, 패턴 자체는 에이전트에게 이에 대해 무엇을 해야 할지 알려주지 않습니다. Anthropic의 도구 검색 기능은 일치하는 항목이 없을 때 오류를 반환하는 대신 빈 목록을 반환하므로, 모델은 일반적인 방식대로 다시 시도하며 다른 쿼리로 또다시 시도합니다. 중단(stop)은 하네스(harness)에서 와야 하며, Strands의 경우 각 호출에 전달하는 limits를 통해 라운드 수와 실행이 사용할 수 있는 총 토큰 수를 제한함으로써 이루어집니다. 예산이 소진되었을 때 무슨 일이 발생하는지는 부분적인 답변, 단순한 '할 수 없습니다'라는 메시지, 또는 사람에게 인계(hand-off) 등 사용자의 결정에 달려 있습니다.

검색 기능의 위치

이 세 가지 도구는 서버에서 실행될 수도 있고, 모든 서버 앞에 있는 게이트웨이에서 실행될 수도 있으며, 루프를 실행하는 클라이언트에서 실행될 수도 있습니다. 이들 간의 변화는 단순히 인덱스를 누가 보유하느냐에 달려 있을 뿐입니다.

서버에서

서버는 세 가지 도구 대신 각 엔드포인트당 하나의 도구를 사용할 수 있습니다. Neon은 이를 계층적 도구 호출(layered tool call)이라고 부르며, 많은 MCP 서버가 이 방식으로 전환했음을 설명합니다. AWS도 자체적인 AWS API MCP Server를 이렇게 구축했으며, 이는 검색을 위한 suggest_aws_commands와 찾은 명령어를 실행하기 위한 call_aws라는 두 가지 도구로 전체 API를 포괄합니다:

from fastmcp import Context, FastMCP
from typing import Any

...

AWS Labs에서 AWS API MCP Server를 각색했습니다.

검색 자체는 코드에 포함되어 있지 않습니다. 왜냐하면 suggest_aws_commands가 AWS가 호스팅하는 서비스로 쿼리를 보내고, 이 서비스가 가장 가능성이 높은 CLI 명령어와 그 설명 및 매개변수를 반환하기 때문에 검색과 정의가 한 단계에서 도착하기 때문입니다. AWS는 이후 해당 서버를 개발 종료(end of development) 상태로 표시하고 사용자들에게 대신 관리형 AWS MCP Server를 사용하도록 안내하고 있습니다.

이 제한은 같은 방식으로 구축된 10개의 서버가 있을 때 나타납니다. 왜냐하면 에이전트가 10개의 인덱스와 10세트의 메타 도구 중에서 선택해야 하기 때문입니다. 공정하게 말하자면, Andre Landgraf의 게시물 Give your agent Neon tools에서 설명하는 Neon 자체 카운터는 하나의 워크플로우에 세 번의 호출을 묶어 도구로 만드는 것이 에이전트가 매번 같은 실수를 하는 것을 막아준다고 합니다. 이는 SDK가 원시 엔드포인트를 편의 메서드로 감싸는 방식과 같습니다. 이러한 워크플로우 도구들은 여전히 서버에 속합니다.

게이트웨이에서 (On the gateway)

게이트웨이는 에이전트와 모든 서버 사이에 위치하므로, 뒤에 무엇이 있든 연결은 하나이고 인덱스는 하나입니다. Solo Enterprise의 agentgateway는 Michael Levan이 자신의 게시물 MCP Progressive Disclosure: Save Tokens, Retrieve Schemas에서 설명하는 두 개의 메타 도구인 get_tool과 invoke_tool을 사용하여 이를 구현합니다. AWS의 경우, AgentCore Gateway는 검색 기능을 내장된 도구인 x_amz_bedrock_agentcore_search로 제공하며, 이는 게이트웨이가 생성될 때 활성화해야 하며 나중에 켤 수 없습니다. Strands에서는 AWS가 bedrock-agentcore 패키지에 해당 검색을 위한 플러그인을 제공합니다:

from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client
from strands import Agent
from strands.tools.mcp import MCPClient
...

Amazon AgentCore Tool Search를 통해 Strands Agents 문서에서 가져온 내용입니다.

요청이 발생하기 전에, 이 플러그인은 모델에게 사용자가 원하는 바를 한 줄로 요약하도록 요청하고, 그 문장으로 게이트웨이를 검색한 다음 돌아오는 도구만 로드합니다. 따라서 모델은 스스로를 검색하지 않습니다. 단점은 요청당 추가적인 모델 호출 비용과 모든 도구 호출마다 한 번의 추가적인 경유지(hop)가 발생한다는 것입니다.

클라이언트에서 (On the client)

클라이언트에서 (On the client)

이 가이드 자체는 호스트가 모든 서버의 도구 목록을 한 번에 나열하고, 정의를 자신의 측에 유지하며 검색 기능을 노출하는 방식으로 작성되었습니다. 따라서 서버들은 그대로 유지됩니다. Strands 1.57에서는 이 패턴의 더 거친 버전인 vended tool, 즉 MCP 라우터(MCP router)가 추가되었습니다:

from strands import Agent
from strands.vended_tools import make_mcp_router

...

MCP Router의 Strands Agents 문서를 참고했습니다.

모델은 이름으로 서버에 연결하고, 그 서버의 도구 목록을 나열하며, 모든 것을 동일한 도구를 통해 호출합니다. 따라서 list_tools는 전체 서버에 대한 get_definition 역할을 하고, call_tool은 invoke 역할을 합니다. 이 라우터에는 검색 기능이 없어 모델이 오직 이름만으로 서버를 선택하고 그 위의 모든 정의를 읽도록 만듭니다. search_tools 도구와 지연 로딩(deferred loading)은 Strands의 로드맵에 있으며, 도구 선택 디자인에서 확인할 수 있습니다.

Anthropic의 도구 검색 기능과 OpenAI의 기능은 전체 패턴의 네이티브 버전입니다. 이 경우 제공업체의 검색 도구를 tools 배열에 추가하고 나머지 도구들은 defer_loading으로 표시합니다. Bedrock에서는 Anthropic의 버전이 InvokeModel API를 통해 작동하지만, Strands가 사용하는 Converse는 그렇지 않기 때문에, 여기서는 라우터 위에 대한 검색 기능은 여전히 사용자가 직접 구축해야 합니다.

클라이언트 측에서 주의할 점은 프롬프트 캐시(prompt cache)입니다. 대부분의 제공업체들이 tools 배열과 함께 프롬프트 접두사(prefix)를 캐싱하기 때문에, 대화 중간에 정의가 추가되면 무효화될 수 있으며, 이로 인한 누락(miss) 비용이 저장한 정의보다 더 클 수 있습니다. 가이드에서 제시된 두 가지 해결책 중, 라우터는 모든 호출을 단일하고 안정적인 도구를 통해 보내 배열이 절대 변경되지 않게 하는 방식을 채택했고, 네이티브 버전들은 캐시된 접두사 뒤에 검색으로 찾은 내용을 추가하는 다른 방식을 채택했습니다.

코드 모드

Search는 모델이 보는 정의를 잘라내지만(cuts), 각 호출은 여전히 모델을 통해 왕복(round trip)을 합니다. 코드 모드에서는 모델이 호출들을 연결하는 스크립트를 작성하고, 이 스크립트는 샌드박스(sandbox)에서 실행되며 출력되는 내용만 반환됩니다. Cloudflare의 Kenton Varda와 Sunil Pai는 이를 Code Mode라고 명명했으며, 가이드에서는 프로그램 방식 도구 호출(programmatic tool calling)이라고 부릅니다. 그들의 동료 Matt Carey가 만든 후속편은 이를 검색과 결합하여 2,500개 이상의 Cloudflare 엔드포인트를 두 개의 도구 뒤에 배치합니다.

Strands에서는 strands-harness 패키지가 이를 내장 도구인 programmatic_tool_caller로 제공하며, 이 도구는 에이전트가 가진 다른 모든 도구를 스크립트가 호출할 수 있는 함수로 변환합니다. 게이트웨이 검색 플러그인이 먼저 도구들을 로드함에 따라, 모델은 하나의 스크립트에서 이들을 호출합니다: