오후 3시, 판교의 한 AI 스타트업 사무실. 개발자가 모니터에 띄운 로그 창에는 매 턴마다 4만 개가 넘는 토큰이 소모되고 있다. 정작 모델이 수행하는 작업은 간단한 API 호출 하나인데, 연결된 수십 개의 도구 설명서(Schema)가 컨텍스트의 절반을 차지하고 있기 때문이다.

이런 풍경은 AI 에이전트가 다루는 도구의 수가 늘어날수록 반복되는 고질적인 문제다. 모델이 현재 작업에 필요 없는 도구 정보까지 모두 읽어야 하는 구조적 낭비가 발생한다. 이 장면 뒤에 숨은 '토큰 세금' 문제를 해결하려는 시도가 나왔다.

MCP 도구 세금 해결로 토큰 소모 85% 절감

AI 에이전트에 다양한 외부 도구를 연결하면 내부적으로 도구 연결 수가 늘어날수록 컨텍스트 윈도우의 점유율이 급격히 상승하는 병목 현상이 발생한다. MCP(Model Context Protocol) 서버 5개를 연결하고 34개의 도구를 설정한 실제 운용 환경에서 턴당 평균 토큰 소모량은 45,000토큰으로 측정됐다. 이 중 약 50%에 해당하는 22,000토큰이 실제 작업 수행과 무관한 도구 스키마 오버헤드로 낭비된다. 모델이 질문에 답하기 위해 읽어야 할 텍스트의 절반이 JSON 형태의 도구 명세서로 채워진 셈이다.

Anthropic의 엔지니어링 데이터에 따르면 최적화 과정을 거치지 않은 도구 정의는 최대 134,000토큰을 점유하며, 일반적인 멀티 서버 배포 환경에서는 턴당 15,000에서 60,000토큰의 추가 비용이 발생한다. 이를 'MCP 도구 세금'이라 정의한다. 불필요한 도구 정의가 컨텍스트의 상당 부분을 점유하면 정작 중요한 사용자 지시어나 이전 대화의 핵심 맥락이 밀려나며 추론 품질이 저하된다.

Tool Search 기능을 적용하면 도구 정의에 사용되는 토큰량을 85%까지 줄일 수 있다. 모든 도구 스키마를 프롬프트에 미리 로드하는 기존 방식에서 벗어나, 모델이 필요한 시점에만 특정 도구를 검색해 로드하는 온디맨드 방식을 채택했기 때문이다. 컨텍스트 윈도우에서 불필요한 선택지를 제거함으로써 가짜 긍정 반응을 억제하고 모델의 추론 정확도를 개선했다.

BM25 알고리즘을 활용한 도구 점진적 공개 구조

Hermes Agent는 모든 도구를 미리 로드하지 않는 점진적 공개 구조를 설계했다. 기존의 방대한 도구 배열을 `search_tools`, `load_tool`, `unload_tool`이라는 3개의 브릿지 도구로 대체한 것이 핵심이다. 모델은 이제 전체 도구 목록을 읽는 대신 브릿지를 통해 필요한 도구만 선택적으로 호출하여 토큰 소모를 물리적으로 억제한다.

브릿지 도구의 내부 검색 로직은 BM25(Best Matching 25) 알고리즘을 기반으로 작동한다. 모델이 입력한 쿼리를 도구의 이름, 상세 설명, 파라미터 명칭과 대조해 관련성 점수가 높은 순으로 도구를 필터링해 제안한다. 만약 BM25 결과에서 유효한 매칭 점수가 나오지 않는 경우에는 리터럴 부분 문자열(substring) 매칭으로 폴백(Fallback)을 수행해 정확한 도구를 찾아낸다.

카탈로그는 매 턴 도구 정의 리스트에서 재구축하는 스테이트리스(Stateless) 방식을 채택했다. 세션 동안 카탈로그를 유지하지 않고 매번 새로 생성함으로써 저장된 정보와 실제 도구 레지스트리가 어긋나는 드리프트 버그를 방지한다. 실제 도구 호출 단계에서는 브릿지 도구가 사라지고 실제 도구 이름을 대상으로 가드레일과 승인 프롬프트가 작동하며, `load_tool`로 불러온 뒤 실행 명령을 내릴 때 비로소 보안 검증과 사용자 승인 절차가 수행된다.

전체적인 작동 흐름은 검색, 로드, 실행의 3단계로 구분된다. 모델이 `search_tools`를 호출해 후보군을 찾으면, 필요한 도구의 스키마를 `load_tool`로 컨텍스트에 올린다. 이후 기능을 수행하고 더 이상 필요 없어진 도구는 `unload_tool`로 제거해 공간을 확보한다.

불필요한 정보 제거로 Opus 4 정확도 74% 달성

Anthropic의 내부 MCP 평가 결과, Tool Search 적용 후 Opus 4 모델의 정확도는 49%에서 74%로 상승했다. 대규모 도구 카탈로그가 컨텍스트 윈도우를 가득 채울 때 모델은 현재 작업에 불필요한 옵션까지 모두 고려하며 판단의 우선순위를 놓치는 '결정 마비(Decision Paralysis)' 현상을 겪는다. 이 과정에서 작업과 무관한 도구를 호출하는 오탐(False Positive) 발생률이 급증한다.

컨텍스트에서 무관한 옵션을 제거하자 모델은 정답에 도달하는 경로를 더 빠르게 찾았다. 이는 단순히 API 비용을 절감하는 차원을 넘어, 컨텍스트 윈도우 내의 노이즈를 걷어내어 모델이 핵심 명령에만 집중하게 만든 구조적 개선이다.

도구 연결 방식의 변화는 모델이 처리해야 할 선택지의 수를 물리적으로 줄였다. 정확도 49%라는 수치는 대규모 도구 환경에서 모델이 얼마나 쉽게 방향을 잃는지를 보여주며, 74%로의 상승은 데이터 노이즈를 제거해 모델의 추론 능력을 극대화한 결과다.

컨텍스트 점유율 10% 기준의 자동 최적화 메커니즘

Hermes Agent는 도구 호출 방식을 제어하기 위해 `hermes.yaml` 설정 파일에서 `tool_search` 옵션을 제공한다. 설정값은 `auto`, `on`, `off` 세 가지로 구분되며, 개발자가 컨텍스트 점유율을 일일이 계산해 설정을 변경하던 수동 관리 방식에서 벗어나 제어권을 시스템에 위임할 수 있다.

`auto` 모드는 도구 스키마가 활성 모델 컨텍스트 윈도우의 10% 이상을 점유하는 시점을 기준으로 작동한다. 도구 정의가 차지하는 비중이 10% 미만일 때는 별도의 검색 과정 없이 모든 스키마를 모델에 전달하는 순수 패스스루(Pass-through) 방식으로 작동해 검색 단계의 누락 가능성과 연산 오버헤드를 차단한다. 반면 임계치인 10%를 넘어서는 순간 시스템은 자동으로 검색 레이어를 가동해 필요한 도구만 필터링하여 전달한다.

시스템은 매 턴마다 도구 스키마의 점유율을 재평가하여 활성화 여부를 동적으로 결정한다.

tool_search: auto

위 설정은 매 요청마다 실시간으로 계산되는 동적 스위치다. 도구 라이브러리가 확장되어 컨텍스트 비중이 10%를 초과하면 즉시 검색 모드로 전환되고, 다시 도구가 줄어들면 패스스루 모드로 돌아온다. 특히 다수의 MCP 서버를 연결해 도구 스키마가 가변적으로 변하는 환경에서 설정 변경 없이도 성능 저하를 막는 실질적인 제어 수단이 된다.

한국형 엔터프라이즈 MCP 에이전트 구축을 위한 시사점

이러한 최적화 기술은 복잡한 내부망과 파편화된 API 연결 방식을 가진 한국 기업의 엔터프라이즈 환경에서 특히 중요하다. 수십 개의 API가 얽힌 전사적 자원 관리(ERP)나 고객 관계 관리(CRM) 시스템을 MCP 서버로 연결할 경우, 앞서 언급한 도구 스키마 오버헤드로 인해 운영 비용이 직접적으로 상승하기 때문이다.

기업은 인프라 전체를 변경하지 않고 `hermes.yaml` 설정 파일에 `tool_search: auto`를 추가하는 것만으로 토큰 비용과 성능 사이의 트레이드오프를 관리할 수 있다. 내부적으로 BM25 알고리즘과 부분 문자열 일치 방식을 통해 검색 누락을 방지하고, 스테이트리스 카탈로그로 라이브 레지스트리와의 동기화 오류를 막는 구조를 활용할 수 있다.

도구 카탈로그가 방대하고 업무 자동화 단계가 복잡한 환경일수록, 불필요한 옵션을 제거해 오탐을 줄이는 것이 정확도 향상의 핵심이다. 앤스로픽의 데이터가 증명하듯 도구 정의 토큰 사용량을 85% 감소시키면서도 전체 라이브러리에 대한 접근성을 유지하는 것은, 수많은 내부 API를 연결해야 하는 한국형 에이전트 구축에서 컨텍스트 최적화가 성능의 결정적 변수임을 보여준다.

MCP 도구 오버헤드를 낮춘 결과는 단순한 효율 개선을 넘어 추론 정확도의 상승으로 직결되었다. 불필요한 컨텍스트 소모를 억제함으로써 모델이 작업 본연의 논리에 집중할 수 있는 환경을 구축한 것이다. 이는 모델 크기를 키우는 대신 인터페이스를 경량화해 성능을 높인 사례로, 에이전트의 실질적 성능은 이제 모델의 체급이 아닌 도구 활용의 최적화 수준에서 결정된다.

MCP 도구 오버헤드를 85% 수준으로 낮춘 결과는 단순한 효율 개선을 넘어 추론 정확도의 상승으로 직결되었다. 불필요한 컨텍스트 소모를 억제함으로써 모델이 작업 본연의 논리에 집중할 수 있는 환경을 구축한 것이다. 이는 도구 호출 과정의 노이즈가 모델의 판단력을 흐리는 고질적인 문제를 데이터 기반의 최적화로 해결했음을 의미한다. 단순한 파라미터 증설보다 인터페이스의 경량화가 더 큰 성능 향상을 가져온 사례다. 에이전트의 실질적 성능은 이제 모델의 체급이 아닌 도구 활용의 최적화 수준에서 결정된다.