MCP의 숨겨진 비밀: 당신의 에이전트가 생각보다 10~32배 더 많은 토큰을 소모하고 있습니다

당신의 AI 에이전트가 MCP 서버를 호출할 때마다, 당신은 숨겨진 세금을 지불하고 있습니다. 달러가 아니라, 바로 토큰(tokens)으로 말이죠. 만약 에이전트를 대규모로 운영하고 있다면, 이 세금은 빠르게 복리로 불어납니다.

실제로 수행된 작업량에 비해 일일 토큰 사용량이 급증하는 것을 발견하고 수치를 계산해 보았습니다. 범인은 모델의 추론(reasoning) 능력이 아니었습니다. 바로 매 턴(turn)마다 주입되는 MCP 도구 정의(tool definitions)로 인한 컨텍스트 오버헤드(context overhead)였습니다.

MCP 컨텍스트 세금의 실제 모습

에이전트를 MCP 서버에 연결하면, 서버의 도구 정의(tool definitions) — 모든 파라미터(parameter), 설명(description), 그리고 스키마(schema) — 가 시스템 프롬프트(system prompt)에 채워집니다. 20개의 도구가 포함된 5개의 MCP 서버를 추가하면, 모델이 단 한 마디를 내뱉기도 전에 *모든 대화 턴(conversation turn)*마다 8,000~15,000개의 토큰이 추가됩니다.

다음은 구체적인 측정 결과입니다. 저는 Claude Code 에이전트를 사용하여 동일한 10턴 대화를 두 번 실행했습니다. 처음에는 MCP 서버가 없는 상태로, 그다음에는 3개의 서버가 연결된 상태로 실행했습니다.

오타가 아닙니다. 5개의 서버 × 10턴 = 대화 턴당 31,200개의 토큰입니다. Claude Opus의 1K 토큰당 비용이 $0.015일 때, 각 에이전트가 5개의 서버를 사용하며 매일 50개의 대화를 진행하는 바쁜 에이전트 팀은 MCP 오버헤드로만 월 $23,400를 소모하게 됩니다.

오버헤드가 보이는 것보다 더 심각한 이유

단순한 토큰 수치만으로는 문제의 심각성을 다 보여주지 못하는데, 여기에는 두 가지 이유가 있습니다.

1. 컨텍스트 윈도우(Context window) 압박이 품질을 저하시킵니다. 컨텍스트 윈도우의 30~40%가 MCP 도구 스키마(tool schemas)로 채워지면, 모델이 실제 대화 기록과 작업 컨텍스트(task context)를 담을 공간이 줄어듭니다. 대화가 길어질수록 품질은 더 빠르게 저하됩니다. 모델이 3턴 전에 알았던 내용을 "잊어버리는" 현상이 나타나기 시작하는데, 이는 실제로 잊은 것이 아니라 단지 공간이 부족한 것입니다.

2. 오버헤드는 압축할 수 없습니다. 시스템 프롬프트(System prompts)는 사용자 메시지에 적용되는 것과 동일한 컨텍스트 압축(context compression) 기술의 혜택을 받지 못합니다. 당신은 매 턴마다 무기한으로 전액을 지불하고 있는 셈입니다.

MCP 생태계 보고서(2026년 5월)의 수치들은 이 문제가 구조적임을 확인시켜 줍니다. 현재 13,000개 이상의 MCP 서버가 존재하며, 평균적인 개발자는 자신의 에이전트에 4~7개의 서버를 연결합니다. 컨텍스트 세금(context tax)은 이제 일급 인프라 비용(first-class infrastructure cost)이 되었습니다.

실제로 효과가 있는 세 가지 해결책

저는 표준 권장 사항들을 테스트해 보았고, 그중 대부분을 제외했습니다. 남은 것은 다음과 같습니다:

해결책 1: 온디맨드 도구 로딩(On-Demand Tool Loading)을 갖춘 MCP 게이트웨이

모든 도구 정의(tool definitions)를 사전에 로드하는 대신, 현재 관련 있는 도구 스키마(tool schemas)만 주입하는 게이트웨이를 통해 MCP 호출을 라우팅하십시오. 모델이 특정 도구 카테고리를 요청하면, 그제서야 게이트웨이가 해당 서버의 스키마를 컨텍스트에 추가합니다.

# 단순화된 MCP 게이트웨이 패턴
async def route_to_mcp(tool_name: str, params: dict) -> dict:
    # 필요한 단 하나의 서버 스키마만 주입
...

MCP 길드(MCP Guild)의 게이트웨이 사양(v0.3)은 2026년 5월 기준으로 이를 기본적으로 지원합니다. AWS, Instana, Honeycomb 모두 선택적 로딩(selective loading)을 지원하는 GA(General Availability) 게이트웨이 엔드포인트를 제공합니다.

해결책 2: 저렴한 분류기(Classifier)를 이용한 시맨틱 도구 라우팅(Semantic Tool Routing)

MCP 서버로 요청을 보내기 전에, 경량 의도 분류기(intent classifier)를 실행하여 가장 관련성이 높은 서버로만 라우팅하십시오. 이는 별도의 저렴한 모델 호출(약 $0.0001)이며, 에이전트가 한 번에 5개의 서버 중 보통 1개만 필요로 하는 경우 MCP 오버헤드를 60~80%까지 절감할 수 있습니다.

INTENT_PROMPT = """이 사용자 요청을 고려할 때, 어떤 MCP 서버가 가장 관련이 있습니까?
옵션: filesystem, github, database, search, slack

...

핵심 통찰: 분류기 호출 비용은 $0.0001입니다. 5개의 서버를 사용하는 10턴 대화에서의 토큰 절감액은 약 $0.15입니다. 하루에 100개의 대화를 실행하는 팀의 경우, 월 $30의 분류기 비용을 지불하고 월 $1,500를 절약할 수 있습니다.

해결책 3: 도구 스키마 압축(Tool Schema Compression)

MCP의 장황한 JSON 스키마 (JSON schema) 형식은 효율성이 아닌 정확성을 위해 설계되었습니다. 프로덕션 (Production) 환경을 위해, 저는 설명을 필수 명사로 축소하고, examples 필드를 제거하며, 파라미터 (parameter) 이름을 축약합니다. 400토큰 규모의 도구 스키마는 기능 손실 없이 약 120토큰으로 압축됩니다. 모델이 read_file 도구를 올바르게 호출하는 데 장황한 설명은 필요하지 않기 때문입니다.

# 압축 전: 380토큰
TOOL_SCHEMA = {
    "name": "filesystem_read",
...

내가 배운 점

저는 MCP의 토큰 오버헤드 (token overhead)가 여기저기서 발생하는 몇 백 토큰 정도의 사소한 비효율성일 것이라고 예상하며 이 작업을 시작했습니다. 하지만 제가 발견한 것은, 멀티 서버 에이전트 (multi-server agents)의 경우 이것이 대부분의 팀이 아직 수치화하지 못한 _주요 비용 동인 (first-class cost driver)_이라는 사실입니다.

불편한 진실은 이렇습니다. 만약 당신이 5개 이상의 MCP 서버를 사용하여 프로덕션 에이전트를 운영하고 있으면서 턴(turn)당 토큰 오버헤드를 측정하지 않았다면, 아마도 API 비용의 30~40%를 모델의 추론 (reasoning)에 전혀 도움이 되지 않는 컨텍스트 (context)에 지불하고 있을 것입니다.

해결책은 도구를 적게 사용하는 것이 아닙니다. 해당 도구 정의가 컨텍스트 윈도우 (context window)에 언제, 어떻게 들어갈지를 의도적으로 결정하는 것입니다. 컨텍스트 예산 (Context budget)은 인프라입니다. 그렇게 취급하십시오.

만약 프로덕션에서 MCP를 운영하고 있다면, 오버헤드를 어떻게 처리하고 계신지 듣고 싶습니다. 특히 위에 언급한 세 가지 방법보다 더 효과적인 패턴을 발견하셨다면 댓글로 남겨주세요.