MCP 서버를 붙이면 컨텍스트를 얼마나 먹나 — 직접 측정해봤다

MCP 서버를 붙이면 도구 정의가 컨텍스트에 올라가서 그만큼 사용량이 늘어난다는 설명을 여러 번 봤다. 사실 내가 이전에 쓴 글에도 똑같이 써놨다.

“연결된 서버의 도구 정의가 컨텍스트에 올라가기 때문에 붙이는 만큼 소모가 늘어납니다.”

그런데 이 말을 그대로 믿고 넘어가기 전에, --strict-mcp-config로 서버 개수를 하나씩 통제하면서 직접 재보면 검증할 수 있겠다는 생각이 들었다. 재봤더니 이 설명은 절반만 맞았다.

측정 방법 — 서버 개수를 0부터 통제한다

Claude Code CLI에는 --mcp-config로 MCP 서버 목록을 지정하고 --strict-mcp-config로 그 외 서버를 전부 배제하는 옵션이 있다. 여기에 --output-format json을 더하면 응답에 usage 필드가 딸려온다.

# 서버 0개 (기준선)
echo '{"mcpServers":{}}' > none.json
claude -p "say OK" --strict-mcp-config --mcp-config none.json \
  --output-format json --model haiku

{
  "usage": {
    "input_tokens": 10,
    "cache_creation_input_tokens": 54954,
    "cache_read_input_tokens": 0
  },
  "total_cost_usd": 0.1101
}

cache_creation_input_tokens + cache_read_input_tokens + input_tokens를 더하면 그 요청이 실제로 소비한 입력 토큰 총량이 나온다. 이 값을 서버 구성별로 비교하면 된다.

테스트에 쓴 서버는 공개 npm 패키지 두 개다. context7(도구 2개, 작음)과 playwright(도구 24개, 큼) — 독자도 그대로 설치해서 재현할 수 있다.

{"mcpServers":{"playwright":{"command":"npx","args":["-y","@playwright/mcp@latest"]}}}

노이즈부터 확인한다

측정을 시작하기 전에, 아무것도 안 바꾸고 같은 요청을 반복하면 값이 얼마나 흔들리는지부터 봤다. 이걸 안 하면 나중에 나오는 작은 차이가 신호인지 노이즈인지 구분할 수 없다.

none #1: 54,745
none #2: 54,747
none #3: 54,746

±1토큰. 이 정도면 이후 나오는 두 자릿수 차이는 노이즈가 아니라고 볼 수 있다.

결과 — 도구 개수가 아니라 서버 개수

기준선(54,746) 대비로 정리하면 이렇다.

구성	서버 수	MCP 도구 수	총 입력 토큰	기준 대비
없음	0	0	54,746	—
context7	1	2	54,737	−9
playwright	1	24	54,757	+11
context7 + playwright	2	26	54,977	+231
playwright × 2 (이름만 다르게 복제)	2	48	55,023	+277
playwright × 3	3	72	55,287	+541

도구가 24개인 playwright 하나를 붙여도 +11토큰이다. 도구 스키마가 컨텍스트에 실제로 실린다면 이 정도로 끝날 수 없다. 실제로 도구가 등록됐는지는 --output-format stream-json의 init 이벤트로 확인했다.

claude -p "hi" --strict-mcp-config --mcp-config pw.json \
  --output-format stream-json --verbose --model haiku

{"type":"system","subtype":"init","tools":["mcp__playwright__browser_click", "mcp__playwright__browser_close", "..."]}

tools 배열에 mcp__playwright__*가 24개 다 들어 있다. 도구는 진짜로 등록됐는데, 그게 컨텍스트 크기에는 거의 안 잡힌다는 뜻이다.

결정적 실험 — 서버 개수 vs 도구 개수

여기서 의심이 하나 남는다. “context7 + playwright”가 +231인 게 context7이라는 특정 서버의 특성 때문일 수도 있지 않을까? 이걸 가르려면 도구 종류는 다르게, 서버 개수 조건만 같게 만들어야 한다.

playwright를 이름만 다르게 두 개 등록했다 — playwright, playwright2. context7은 아예 안 썼다.

{
  "mcpServers": {
    "playwright": {"command":"npx","args":["-y","@playwright/mcp@latest"]},
    "playwright2": {"command":"npx","args":["-y","@playwright/mcp@latest"]}
  }
}

결과: 도구 48개, +277. context7이 전혀 없는데도 “서버 2개” 조합인 앞의 +231과 비슷한 폭으로 늘었다. context7의 특성이 아니라 “서버가 몇 개인가”가 원인이라는 뜻이다. 3개로 늘리면 어떻게 되는지도 확인했다.

playwright × 1: 도구 24개    +11
playwright × 2: 도구 48개   +277
playwright × 3: 도구 72개   +541

서버가 2개→3개로 늘 때 증가폭은 +264, 1개→2개로 늘 때는 +266~277. 도구 개수는 24개씩 늘었는데(24→48→72) 토큰 증가폭은 거의 일정하다. 추가 서버 하나당 대략 +265토큰의 고정 비용이 붙는 구조로 보인다.

다만 완전히 깨끗하지는 않다. 도구 26개짜리 “서버 2개”(+231)와 도구 48개짜리 “서버 2개”(+277)를 비교하면 46토큰 차이가 나는데, 도구 수 차이(22개)에 비하면 작지만 0은 아니다. 서버 개수가 압도적인 비중을 차지하고, 도구 개수도 아주 작게(도구당 2토큰 안팎) 영향을 준다고 보는 게 더 정확하다. 이 잔차가 정확히 뭔지는 이번 측정만으로 확정할 수 없다[확인 필요] — 시스템 프롬프트의 “연결된 서버” 안내 텍스트 때문일 가능성이 있지만 Claude Code 내부 구현을 직접 보지 않고는 단정할 수 없다.

그럼 도구는 언제 로드되나

정의가 미리 안 실린다면, 모델은 도구가 있다는 걸 어떻게 알고 쓸까. context7으로 실제 검색을 시켜봤다.

claude -p "context7 MCP로 'zod' 라이브러리 문서를 찾아봐" \
  --strict-mcp-config --mcp-config c7.json \
  --output-format stream-json --model haiku --max-turns 6

호출 순서: ToolSearch → ToolSearch → mcp__context7__resolve-library-id. 모델이 먼저 ToolSearch로 필요한 도구를 찾은 다음에야 실제 MCP 도구를 호출했다. 이 요청은 4턴에 걸쳐 누적 22만 토큰 넘게 썼는데, 이건 cache_read_input_tokens가 턴마다 다시 쌓이는 값이라 “도구 하나 쓰는 데 22만 토큰”으로 읽으면 안 된다 — 등록 비용(이 글의 본론)과 실제 사용 비용은 다른 층위다.

정정

이 측정 결과는 이전에 쓴 MCP 설정 글의 설명과 어긋난다. “도구 정의가 컨텍스트에 올라가서 붙이는 만큼 소모가 늘어난다”는 설명은, 정확히는 “도구 개수만큼”이 아니라 “서버 개수만큼”이었다. 그 글의 FAQ에 이 글을 근거로 정정 문구를 추가해뒀다.

정리

질문	확인된 사실
도구 24개짜리 서버 하나, 비용은?	거의 0 (+11, 노이즈 수준)
서버 2개, 비용은?	+230~280
서버 3개, 비용은?	+541 (2개 대비 +264)
도구 정의가 컨텍스트에 실리나?	아니오 — 등록만 되고 ToolSearch로 나중에 찾아옴
무엇에 비례해서 늘어나나?	도구 개수 아님, 서버 개수(대부분)

“MCP를 많이 붙일수록 컨텍스트가 커진다”는 방향 자체는 맞다. 다만 그 이유는 도구 스키마가 아니라 서버 연결 개수 쪽이었다 — 도구가 몇 개인 서버인지는 이번 측정 범위에서는 거의 영향이 없었다.

이 글의 측정값은 Claude Code 2.1.229, --model haiku 기준이다. 버전이 바뀌면 시스템 프롬프트 자체가 달라져 절대값이 변할 수 있으니, 정확한 값이 필요하면 이 글의 방법을 그대로 본인 버전에 적용해서 재확인하는 편이 안전하다.