MCP 토큰 오버헤드를 측정해 보았습니다. 결과는 예상보다 더 심각했습니다.

Reddit의 누군가가 질문을 단 하나 입력하기도 전에 자신의 MCP 설정이 67,000개의 토큰을 소비했다고 게시했습니다. 저는 그 말을 믿지 않았습니다 — 직접 측정해 보기 전까지는 말이죠. 그 후 저는 왜 이런 일이 발생하는지, 그리고 어떻게 해결해야 하는지 알아내기 위해 일주일 동안 매달렸습니다.

제가 발견한 내용은 다음과 같습니다.

설정 (The Setup)

저는 간단한 코드 리뷰 에이전트(code review agent)를 구축하고 있었습니다. PR 설명을 읽고, diff를 확인하고, 댓글을 남기는 작업입니다. 저는 이를 네 개의 MCP 서버와 연결했습니다: GitHub, 벡터 스토어 (vector store), Slack 알림 도구 (Slack notifier), 그리고 데이터베이스 인스펙터 (database inspector). 깔끔하고 운영 환경에 가까운, 특별할 것 없는 구성이었습니다.

기준점 (MCP 미사용 시): 요청당 480 토큰.
네 개의 서버를 모두 활성화했을 때: 11,200 토큰.

이는 23배의 오버헤드입니다. 하루에도 수백 번씩 실행되는 코드 리뷰 에이전트에서 말이죠.

저는 원인을 파헤치기 시작했습니다.

토큰이 어디로 사라지는가

MCP의 토큰 비용은 단일 요소가 아니라, 네 가지 요소가 층층이 쌓인 결과입니다.

1. 세션 초기화 (Session initialization)
모든 MCP 세션은 핸드셰이크 (handshake)로 시작됩니다. 도구 스키마 (tool schemas)가 매 대화 컨텍스트 (conversation context)의 시작 시점에 모델로 전송됩니다. 모델은 도구를 호출하기 전에 어떤 도구들이 존재하는지 알아야 합니다.

MCP 스펙 리포지토리 (spec repo)의 한 이슈를 보면, 누군가가 세션당 도구 당 약 1,000 토큰의 오버헤드를 측정했습니다. agentmemory와 같은 53개의 도구를 가진 MCP 서버는 컨텍스트에 53개의 도구를 추가하는 것이 아니라, 53,000개의 토큰을 추가하는 셈입니다.

2. 도구 스키마 팽창 (Tool schema inflation)
이 부분이 저를 당황하게 만든 지점이었습니다. GitHub MCP 서버는 단순히 get_pr()을 함수 호출로 노출하는 데 그치지 않습니다. 모든 파라미터에 대한 설명, 타입 어노테이션 (type annotations), 열거형 (enum) 값, 중첩된 객체 구조를 포함한 전체 OpenAPI 스키마를 전송합니다.

Anthropic의 문서에서는 이를 구체적으로 지적합니다: 도구 스키마가 간결하고 정확할 때 모델의 성능이 더 좋아집니다. 하지만 MCP 서버는 토큰 효율성이 아니라 범용성을 위해 작성됩니다. 그 결과, 특정 작업을 위해 직접 작성할 스키마보다 5~10배 더 큰 스키마가 생성됩니다.

3. 도구 결과 포맷팅 (Tool result formatting)
MCP 도구가 반환될 때, 그 결과는 구조화된 메시지 (structured message) 형태로 컨텍스트 (context)에 다시 들어갑니다. 만약 도구가 (관련된 필드뿐만 아니라) 전체 API 응답을 반환한다면, 컨텍스트 윈도우 (context window)에 엄청난 양의 노이즈를 채워 넣게 됩니다. 단 3개의 컬럼만 필요할 때 47개의 컬럼을 반환하는 데이터베이스 조사 도구 — 이것이 매 호출마다 낭비되는 토큰입니다.

4. 컨텍스트 윈도우 누적 (Context window compounding)
이것이 제 예산을 망가뜨린 주범입니다. 멀티 턴 대화 (multi-turn conversation)를 진행할 때, MCP 스키마 (schema)와 모든 도구 결과는 세션 전체 동안 컨텍스트에 유지됩니다. 대화가 진행될 때마다 더 많은 양이 추가됩니다. 4개의 MCP 서버가 활성화된 상태에서의 30개 메시지 대화는 쉽게 300k 이상의 오버헤드 (overhead) 토큰을 축적할 수 있으며, 이 중 대부분은 모델이 실제로 호출하지도 않은 도구들로부터 발생합니다.

벤치마크 (The Benchmark)

OnlyCLI는 2026년에 동일한 작업에 대해 MCP와 직접적인 CLI를 비교하는 벤치마크를 발표했습니다. 결과는 다음과 같습니다:

단순 저장소 메타데이터 확인: CLI 1,365 토큰 vs MCP 47,000 토큰 (~34배)
파일 검색 작업: CLI 890 토큰 vs MCP 12,400 토큰 (~14배)
멀티 도구 워크플로우 (Multi-tool workflow): CLI 3,200 토큰 vs MCP 89,000 토큰 (~28배)

비율은 작업의 복잡도에 따라 다르지만, 일관되게 4배에서 35배 사이를 나타냅니다. 작업이 단순할수록 비율은 더 나빠지는데, 이는 고정된 MCP 오버헤드가 지배적이기 때문입니다.

내가 실제로 변경한 것들

첫째: 무엇보다 먼저 측정했습니다.
에이전트 루프 (agent loop)에 토큰 카운팅 (token counting)을 추가했습니다. 모든 요청은 다음을 기록합니다: input_tokens, output_tokens, mcp_tools_called, mcp_results_size_bytes. 번거로워 보일 수 있지만, 한 곳에서 실행되는 하나의 함수일 뿐입니다.

import anthropic
from anthropic import Anthropic

...

둘째: 도구를 미리 등록하지 않고 지연 등록 (lazily)했습니다.
세션 시작 시 4개의 MCP 서버를 모두 로드하는 대신, 모델이 도구를 사용하려는 의도를 처음으로 표현할 때 로드하도록 했습니다. 이를 통해 초기화 비용을 실제로 필요한 서버로만 전환할 수 있으며, 종종 단 하나의 서버만 필요하게 됩니다.

셋째: 스키마 (schemas)를 공격적으로 축소했습니다.
대부분의 MCP 서버는 노출할 도구 (tools)를 설정할 수 있게 해줍니다. 저는 서버당 23개의 도구에서 6개로 줄였습니다. 모델은 여전히 올바른 도구를 선택합니다. 이전에는 선택지가 너무 많아서 잘못된 도구를 선택했던 것이니까요.

넷째: 도구 결과에 페이지네이션 (pagination)을 적용했습니다.
데이터베이스 인스펙터 (database inspector)에게 "모든 최근 트랜잭션"을 요청하는 대신, "금액 기준 내림차순 상위 10개"를 요청합니다. 모델은 이 패턴을 학습합니다. 필요한 것이 명시적일 때, 모델은 정확히 필요한 것을 요청하는 데 더 능숙해집니다.

변경 후 수치

이러한 변경 사항을 적용한 후:

기준점 (MCP 미사용): 480 토큰 (변동 없음)
4개 서버 중 2개 사용, 축소된 스키마 적용: 3,100 토큰 (기존 11,200 토큰)
지연 로딩 (lazy loading) + 페이지네이션 적용: 1,850 토큰
비율: 23배가 아닌 약 4배

여전히 오버헤드 (overhead)가 존재합니다. 하지만 4배는 관리 가능한 수준입니다. 23배는 점심시간이 되기도 전에 제 컨텍스트 예산 (context budget)을 다 써버릴 정도였습니다.

새로 시작하는 사람에게 해주고 싶은 말

MCP는 가치가 있습니다. 생태계는 실재합니다. 13,000개 이상의 서버, 2026년 AWS의 GA (General Availability) 예정, 월간 다운로드 9,700만 회를 기록하고 있습니다. 도구 (tooling) 측면에서 승리하고 있습니다. 하지만 다음 사항을 염두에 두고 시작하세요:

직접적인 API 호출 대비 MCP 작업당 4~32배의 토큰 오버헤드를 예산에 반영하세요.
토큰을 3개월 차가 아닌, 첫날부터 계산하세요.
도구를 지연 등록 (register lazily) 하세요. 사용하지 않는 도구에 비용을 지불하지 마세요.
스키마가 당신의 컨텍스트 윈도우 (context window)를 깎아먹기 전에 먼저 스키마를 축소하세요.

데모에서 인상적으로 보이는 에이전트 (agent)가 프로덕션 환경에서는 예산 재앙이 될 수 있습니다. 먼저 측정하고, 그다음에 최적화하세요.