요약 (TL;DR): 도구별 MCP 토큰 비용을 측정하고, MCP "메뉴 세금 (menu tax)"을 줄이며, 2% 미만의 지연 시간 추가만으로 모든 MCP 서버에 엄격한 예산을 강제하는 방법.

얼마 전 저는 Claude Code에 Bright Data의 MCP를 추가하고 문서 페이지를 가져오라고 요청했는데, 다음과 같이 처참하게 실패하는 것을 목격했습니다:

오류: MCP 도구 “scrape_as_markdown” 응답 (278,649 토큰)이 허용된 최대 토큰 수(25,000)를 초과했습니다. 응답 크기를 줄이기 위해 페이지네이션 (pagination), 필터링 (filtering) 또는 제한 파라미터를 사용하십시오.

278k 토큰이 LLM이 단 한 줄을 읽거나, 생각을 형성하거나, 제가 실제로 요청한 작업을 수행하기도 전에 소비되었습니다. 이는 대부분의 LLM 컨텍스트 창 (context window)보다 많은 양입니다! Claude Code는 실제로 25k 토큰을 초과하는 모든 것을 거부하지만 (MAX_MCP_OUTPUT_TOKENS를 통해 설정 가능), 일부 다른 클라이언트들은 명시적인 제한이 전혀 없습니다 — 그들은 품질이 저하될 때까지 컨텍스트를 채우도록 내버려 둡니다 (이는 논쟁의 여지가 있지만 더 나쁜 상황입니다).

그럼 이를 실제로 해결해 봅시다. 어떤 MCP 서버가 얼마나 많은 토큰 비용을 발생시키는지 계산하는 방법, 약간의 노력으로 가능한 해결책들, 그리고 마지막으로 어떤 MCP 서버 앞에도 배치하여 엄격한 토큰 예산을 강제할 수 있는, 클라이언트 불가지론적 (client-agnostic)인 작은 프록시를 보여드리겠습니다 — LLM이 확인하기 전에 MCP 페이로드 (payload)를 축소하는 방법입니다.

왜 MCP 응답은 이렇게 큰가?

MCP 응답이 큰 이유는 서버가 **절약이 아닌 충실도 (fidelity)**에 최적화되어 있기 때문입니다 — 서버는 사용자가 어떤 부분을 필요로 하는지 알 수 없기 때문에 전체 페이지, 파일 또는 JSON 블록을 반환합니다. 두 번째 비용인 tools/list "메뉴 세금 (menu tax)"은 매 턴마다 마운트된 모든 도구의 스키마 (schema)를 컨텍스트에 주입합니다.

💡 MCP 서버는 본질적으로 LLM을 위한 API이지만, 응답은 여전히 엄격한 크기 제한(컨텍스트 창)이 있는 버퍼에 맞아야 합니다. 우리의 토큰 예산 관리 프록시는 이 두 세계 사이에서 임피던스 매칭 (impedance-matcher) 역할을 하며, 호출을 상위로 전달하고 응답이 모델에 도달하기 전에 다듬습니다.

이것은 세 가지 차원에서 복합적으로 발생합니다:

1. 페이로드 (Payload) 자체. 도메인에 관계없이 단일 결과가 엄청나게 클 수 있습니다. 긴 위키 페이지나 API 문서에 대한 Bright Data MCP의 scrape_as_markdown은 100k~150k+ 토큰에 달할 수 있으며, GitHub MCP의 get_file_contents/get_pull_request_diff는 파일 전체나 diff를 반환하고, Playwright MCP의 browser_snapshot은 전체 접근성 트리 (accessibility tree)를 덤프합니다.
2. 결과물의 개수. 컬렉션을 열거하는 호출은 상한선 없이 항목당 비용을 배가시킵니다. 예를 들어, GitHub의 search_code 또는 list_* 엔드포인트는 페이지당 100개의 데이터가 채워진 (hydrated) 항목을 반환합니다.
3. tools/list 오버헤드 — 대부분의 사람들은 MCP를 사용할 때, 단 하나의 도구가 실행되기 전에 연결된 모든 서버의 모든 도구 스키마 (schema)가 컨텍스트 (context)에 주입된다는 사실을 모릅니다. 이 "메뉴 세금 (menu tax)"은 서버마다 크게 다릅니다.

공식 GitHub MCP는 이 점이 특히 심각합니다. 스키마 세금이 실제 도구 응답 크기의 거의 3배에 달합니다.

거대한 MCP 응답은 실제로 어떤 비용을 발생시키는가?

이것은 여러분에게 두 번의 비용을 발생시킵니다. API 호출당 발생하는 달러 비용과, LLM이 데이터를 확인하기도 전에 소모되는 컨텍스트 창 (context window) 용량입니다.

이해를 돕기 위해, Bright Data MCP의 scrape_as_markdown 도구로 서로 다른 페이지를 가져온 결과(토큰을 달러 비용으로 변환, Sonnet 가격 기준)를 아래에 정리했습니다:

색상 구분을 주목하십시오. 파란색(블로그 포스트)만이 Claude Code의 25k 제한 미만인 유일한 막대입니다. 그 외의 모든 것 — 심지어 "작은" 제품 페이지 가져오기조차 — 이미 예산을 초과했습니다.

MCP 토큰 비용을 측정하는 방법

각 서버에 대해 tools/list와 하나의 대표적인 도구(tool)를 호출하는 하네스(harness)를 사용하여 MCP 토큰 비용을 측정하고, tiktoken (cl100k_base)으로 토큰을 계산합니다. 서버별로 실행하여 턴당 스키마 세금(schema tax)과 호출당 페이로드 크기(payload size)를 모두 확인하세요. 이 두 가지는 전체 MCP 비용을 유발하는 별개의 두 가지 소모처(sinks)입니다.

measure.py

# 1) tools/list 스키마 세금 측정
# 및 2) 서버당 하나의 대표적인 호출에 대한 토큰 수 측정
import asyncio, json, os  
...

함께 따라 해보려면, Bright Data MCP를 사용하기 위해 여기에서 가입하고 제어판(Control Panel)에서 API_TOKEN을 받아 환경 변수로 설정해야 합니다. npx -y @brightdata/mcp로 서버를 실행하세요. 지금은 PRO_MODE=true를 설정하지 마십시오. 이를 설정하면 그들의 원격 Scraping Browser를 기반으로 하는 브라우저 도구가 추가되는데, 이는 Playwright만큼이나 비대한 스냅샷을 쏟아낼 수 있습니다.

GitHub의 경우 Settings → Tokens에서 GITHUB_PERSONAL_ACCESS_TOKEN을 가져와야 하며, Docker도 필요합니다. Playwright는 추가로 필요한 것이 없습니다.

다음 명령어로 하네스를 실행하세요:

pip install mcp tiktoken  
python measure.py

제가 보유한 4개의 MCP 서버를 대상으로 실행한 결과입니다:

tools/list (Bright Data rapid): 5 tools, 1,161 tokens  
scrape_as_markdown (Bright Data rapid): 278,649 tokens in response   # Amazon SERP  

...

tools/list 비용은 저를 정말로 경악하게 만든 부분입니다. 이 스키마 또는 "메뉴" 세금은 모든 대화의 매 턴마다, 영원히 지불해야 하는 비용입니다 — 그리고 GitHub MCP의 경우, 실제 도구 호출(tool call) 응답 크기의 거의 3배에 달합니다!

MCP 응답 크기를 줄이는 네 가지 방법

첫째, 두 가지 서로 다른 토큰 소모처(token sinks)가 있음을 이해해야 합니다. 매 턴마다 당신은 두 번 비용을 지불합니다:

• 하나는 tools/list의 스키마 "메뉴" 세금 (schema "menu" tax) 때문입니다 (모든 도구의 설명이 실행 전 주입됩니다).
• 다른 하나는 각 도구 호출(tool call)이 반환하는 응답 페이로드 (response payload) 때문입니다.

다음 네 가지 접근 방식을 통해 이를 줄일 수 있습니다: (1) 더 적은 수의 도구를 마운트하여 tools/list 스키마 세금을 절감하기, (2) 네이티브 서버 제한 파라미터 사용하기, (3) 응답 페이로드를 위한 토큰 예산 관리 프록시 (token-budgeting proxy) 배포하기, 그리고 (4) 너무 큰 응답 페이로드를 디스크로 넘기기 (spill to disk). 즉, 방법 12는 스키마 오버헤드(schema overhead)를 겨냥하며, 방법 34는 응답 페이로드를 겨냥합니다.

방법 #1: 사용하지 않는 도구 로드 중단하기

LLM에 도구를 알리는 데 드는 턴당 비용을 줄이는 유일하고 확실한 방법은 **"메뉴를 줄이는 것"**입니다. 즉, 필요 없는 서버를 언마운트(unmount)하거나, 클라이언트 설정에서 개별 도구를 숨기거나, 서버 자체에서 가벼운 도구 모드(lean tool modes)를 활성화하는 것입니다.

(a) 애초에 해당 서버를 마운트하지 마세요. 작업 과정에서 GitHub을 전혀 사용하지 않는다면, GitHub MCP를 비활성화하세요. 즉, 클라이언트 설정에서 완전히 제외하십시오. 연결되지 않은 서버는 tools/list에 아무것도 넣을 수 없으며 토큰 비용을 발생시키지 않습니다.

모든 MCP 클라이언트는 UI를 통해 이를 수행할 수 있게 해주지만, JSON 설정을 수정하는 것도 가능합니다.

(b) 마운트된 서버 내에서 불필요한 도구를 숨기세요. 대부분의 클라이언트는 활성화된 서버 내에서 개별 도구를 선택할 수 있게 해줍니다 (Cursor는 UI에서 이를 수행하며, Claude Code는 mcp__github__*와 같은 권한 거부 (deny) 규칙을 가지고 있고, 다른 클라이언트들은 allowedTools / excludeTools를 제공합니다). 이렇게 세밀한 방식으로 거부된 도구들은 컨텍스트에서 완전히 제외됩니다. 단순히 호출 시점에 차단되는 것이 아닙니다.

MCP 서버의 도구에 대한 세밀한 제어(Fine grained control)가 Cursor에서 가능합니다. 흐릿하게 표시된(dimmed) 도구는 숨겨졌다는 의미입니다.

(c) 서버가 스스로 필요한 만큼만 자르도록 하세요. 드문 경우지만, 일부 MCP 서버는 기본적으로 적은 수의 도구를 사용하고 필요할 때 더 많은 도구를 선택하도록 허용합니다. 예를 들어, Bright Data는 5개의 도구 / 1,161 토큰을 기본값으로 설정하며, 전체 카탈로그는 PRO_MODE=true일 때만 노출됩니다(74개 도구 / 13,851 토큰). GitHub의 --toolsets/--tools와 Playwright의 --caps 옵션도 같은 방식으로 작동합니다.

기본적으로 에이전트가 사용 사례(use-case)에 실제로 필요한 것만으로 “메뉴”를 간소화하세요.

방법 #2: 더 작은 응답을 네이티브하게 요청하기 (Ask For a Smaller Response, Natively).

서버가 이미 더 작은 응답 페이로드(response payload)를 요청할 수 있도록 허용하는지 확인해 보세요. 30만 토큰을 다운로드한 후 대부분을 버리는 것보다 출처에서 제한하는 것이 훨씬 좋습니다.

이렇게 “적게 요청하기”는 다양한 형태를 가질 수 있습니다. 일부 MCP 서버는 페이지네이션(max_results, per_page)을 허용하거나, 더 적은 필드만 요청하도록 (fields=[...]) 하거나, 형식/상세도(format/verbosity)를 조정할 수 있도록 합니다 (format: "compact").

이 서버에서 네이티브하게 더 작은 응답을 받을 수 있나요? 인기 있는 MCP 서버 3개를 비교했습니다. “디스크에 쏟아내기(Spill to disk)”는 여기서 네이티브한 방법만 계산합니다.

문제는 대부분의 MCP 서버에는 그러한 설정이 없다는 것이며, 호출당 매개변수(per-call params)는 모델이 매번 설정하는 방식에 따라 달라집니다. 서버 개발자들은 모델이 필드 이름을 환각(hallucinate)할 수 있기 때문에 개방형 필드 선택을 경계하며, 합리적인 기본값을 강제하는 것을 선호합니다.

네이티브 제한이 없거나 신뢰할 수 없을 때는, 모델이 요청하는 내용과 관계없이 모든 응답에 하드한 상한선(hard ceiling)을 적용하는 **토큰 예산 관리 프록시(token-budgeting proxy)**가 필요합니다.

방법 #3: 토큰 예산 관리 프록시 구축하기 (Build a Token-Budgeting Proxy)

토큰 예산 관리 프록시 (token-budgeting proxy)는 클라이언트와 실제 서버 사이에 위치하는 가벼운 MCP 서버입니다. 이 프록시는 모든 호출을 상위(upstream)로 전달하고, 모델이 응답을 확인하기 전에 페이로드(payload)의 형태에 따라 strip, JSON projection 또는 disk spill 등을 사용하여 각 응답을 엄격한 토큰 예산(예: 8,000 토큰) 이하로 후처리합니다.

에이전트(Agent)는 이 프록시와 통신합니다. 여러분의 프록시는 실제 MCP 서버와 통신합니다. 어느 쪽도 그 차이를 알지 못합니다.

┌──────────┐   stdio    ┌────────────────┐   stdio    ┌───────────────────┐  
│  Client  │ ─────────► │  budget-proxy  │ ─────────► │ Bright Data MCP   │  
│ (Claude) │ ◄───────── │  (your code)   │ ◄───────── │ (@brightdata/mcp) │  
...