'MCP가 CLI보다 토큰을 32배 더 먹는다'는 벤치마크, 어디까지 믿어야 하나

MCP 토큰 오버헤드 실측치는 4~32배부터 '호출당 +50토큰'까지 범위가 넓다. 모순처럼 보이는 두 숫자는 서로 다른 도구 구성을 측정한 결과다. 스키마 크기, 세션 길이, 캐싱·필터링 여부라는 세 가지 조건으로 벤치마크를 읽는 법을 정리한다.

이 글은 2026년 9월 9일 기준으로 확인한 공개 벤치마크와 커뮤니티 실측을 다룹니다. MCP와 에이전트 도구 생태계는 기능이 빠르게 바뀌고 있어서(스키마 지연 로딩, 도구 검색, 코드 실행 방식 등), 여기서 인용한 수치와 지원 여부는 확인 시점 이후 달라졌을 수 있습니다. 또 특정 벤치마크의 결론을 ‘정답’이나 어느 한 방식의 우열 판정으로 읽지 않기를 권합니다. 숫자는 모두 특정 조건에서 나온 값이고, 조건이 바뀌면 결론도 바뀝니다.

서로 다른 두 개의 실측치

최근 “MCP는 죽었다, CLI를 써라”는 주장과 함께 자주 인용되는 숫자가 있습니다. 인증 인프라 스타트업 Scalekit이 2026년 3월에 공개한 벤치마크로, 같은 모델(Claude Sonnet 4)·같은 작업에서 MCP가 CLI보다 4~32배 많은 토큰을 소비했다는 결과입니다(출처의 발표값).

그런데 거의 반대 방향의 실측도 있습니다. 21개 도구를 가진 MCP 서버를 직접 운영하는 개발자가 r/mcp에 올린 측정에서는, MCP의 오버헤드가 세션 시작 시 약 1,300토큰 + 호출당 약 50토큰에 불과했다고 보고합니다(커뮤니티 자체 측정, 아래에서 신뢰도를 따로 다룹니다). 200k 컨텍스트의 0.65%이고, 8~10회 호출이면 손익분기점을 지난다는 계산입니다.

32배와 +50토큰. 둘 중 하나는 틀린 걸까요? 결론부터 말하면 둘 다 자기 조건 안에서는 맞을 수 있습니다. 이 글의 논지는 이것입니다 — MCP 토큰 오버헤드는 프로토콜의 고유 상수가 아니라 배포 구성의 함수다. 벤치마크를 인용하거나 도입 판단에 쓸 때는 “몇 배냐”가 아니라 “어떤 구성에서 잰 몇 배냐”를 먼저 물어야 합니다.

32배는 어떤 조건에서 나왔나

Scalekit 벤치마크(발표값, 벤치마크 코드 공개)의 측정 조건을 원문에서 확인한 대로 정리하면 이렇습니다.

• 모델: Claude Sonnet 4, 작업·프롬프트는 세 방식 공통
• 비교 대상: ① 맨 CLI(bash + gh, 가이드 없음) ② CLI + Skills(약 800토큰의 gh 팁 문서 추가) ③ MCP — GitHub 공식 Copilot MCP 서버(api.githubcopilot.com/mcp/)에 원격 접속
• 작업: 공개 저장소 anthropics/anthropic-sdk-python에 대한 읽기 전용 작업 5종(저장소 언어·라이선스 확인, PR 상세, 메타데이터, 병합 PR 요약, 최신 릴리스 의존성)
• 총 75회 실행, 작업별 중앙값. CLI 대비 MCP 차이는 p<0.05로 통계적으로 유의하다고 밝힘

토큰 사용량(출처의 발표값, 작업별 중앙값):

여기서 배율이 어떻게 만들어지는지 주목할 점이 있습니다. 32배는 가장 간단한 작업에서 나왔고, 4배는 가장 무거운 작업에서 나왔습니다. 분자인 MCP 쪽 토큰은 작업이 무엇이든 대체로 비슷한 덩어리(3만~8만)인데, 분모인 CLI 토큰이 작업 난이도에 따라 1,365에서 8,750까지 변하기 때문입니다. 즉 “32배”의 정체는 MCP가 무거웠다기보다, CLI가 1,365토큰이면 끝낼 사소한 작업에 43개 도구 전체의 스키마가 따라붙은 것입니다.

Scalekit 자신도 원인을 이렇게 진단합니다. “MCP의 오버헤드는 프로토콜 문제가 아니라 스키마 주입 문제다.” GitHub Copilot MCP 서버는 43개 도구를 노출하고, 클라이언트는 대화마다 43개 스키마 전체를 컨텍스트에 싣습니다. 에이전트가 실제로 쓰는 도구는 한두 개인데도 gist 생성, webhook 관리 스키마까지 매번 따라갑니다.

측정 조건에서 놓치기 쉬운 두 가지를 더 짚어두겠습니다.

첫째, 이 벤치마크의 MCP는 원격 호스팅 서버 접속입니다. 함께 보고된 “MCP 실패율 28%“(25회 중 7회 실패)의 원인은 전부 TCP 수준 ConnectTimeout이었습니다 — 프로토콜 오류도, 잘못된 도구 호출도 아니라 GitHub 쪽 원격 서버가 시간 안에 응답하지 않은 경우입니다. gh는 로컬에서 실행되니 이 실패 모드가 없습니다. 신뢰성 차이는 ‘MCP 대 CLI’의 차이가 아니라 ‘원격 서버 대 로컬 실행’의 차이에 가깝습니다.

둘째, 비용 환산도 같은 조건에 묶여 있습니다. 월 1만 회 작업 기준 CLI 약 $3.20, 직접 MCP 약 $55.20(출처의 발표값, Claude Sonnet 4 가격 $3/$15 per M token 기준 계산값)이라는 숫자는 스키마 필터링도 캐싱도 없는 구성의 값입니다. 같은 글에서 게이트웨이로 스키마를 2~3개 도구만 걸러 주면 약 $5 수준(출처의 추정치)으로 내려간다고 밝히고 있습니다.

반대측 실측: +50토큰은 어떤 조건인가

r/mcp에 올라온 반대 측 측정(커뮤니티 자체 측정)의 조건은 Scalekit과 거의 정반대입니다.

• 도구 21개의 MCP 서버, 본인이 직접 운영(로컬·경량 스키마로 추정되나 원문에 전송 방식 명시 없음)
• 세션 시작 시 스키마 로드 1회: 약 1,300토큰
• 호출당: MCP 약 800토큰 vs CLI 약 750토큰 — 차이 약 50토큰
• 결론: 8~10회 호출에서 손익분기, 이후 세션이 길어질수록 오버헤드는 노이즈

같은 글과 댓글에서 확인되는 조건 의존 사례도 있습니다. 도구 4개, 단순 스키마의 원격 서버는 오버헤드가 총 약 400토큰이라 1~2회 호출이면 회수된다는 보고, 반대로 “스키마가 비대한 서버(50개 이상 도구, 1만 토큰 이상 스키마)에서는 CLI 우세가 맞다”는 자기 한정까지, 게시자 스스로 조건에 따라 결론이 갈린다고 적고 있습니다.

신뢰도 등급을 구분해서 다룰 필요가 있습니다. 이 측정은 (1) 방법론·원시 로그가 공개되지 않았고, (2) 게시자가 MCP 서버 운영 당사자라 이해관계가 있으며(댓글에서도 이 지적이 나옵니다), (3) 표본 크기·반복 횟수를 알 수 없습니다. Scalekit 벤치마크 역시 인증·게이트웨이 제품을 파는 회사의 발표라는 이해관계는 마찬가지지만, 코드와 데이터를 공개(github.com/scalekit-inc/mcp-vs-cli-benchmark)하고 재현을 요청했다는 점에서 검증 가능성은 더 높습니다. 다만 두 경우 모두 독립 제3자의 재현 결과는 아직 확인하지 못했습니다. 이 글에서 쓰는 모든 배율은 ‘출처의 발표값’이지 독립 검증된 상수가 아닙니다.

72%와 98.7%도 조건을 떼면 오독된다

이 논쟁에서 함께 도는 두 숫자도 같은 방식으로 읽어야 합니다.

“도구 설명만으로 컨텍스트의 72%를 점유” — Perplexity CTO Denis Yarats가 개발자 콘퍼런스에서 밝혔다고 보도된 값입니다(2차 보도 기준, 발표 조건인 도구 수·서버 수는 보도마다 ‘수십 개 도구 등록’ 수준으로만 언급). Tyk의 정리 글은 “30개 도구를 등록하면 설명만으로 15,000~20,000토큰”이라는 근사치를 덧붙입니다. 역시 ‘많은 도구를 전부 upfront 로딩하는 구성’의 값이지, MCP 일반의 값이 아닙니다.

“98.7% 절감” — Anthropic이 2025년 11월 엔지니어링 블로그에서 발표한 값으로, 수십 개 서버·수백~수천 개 도구를 연결한 에이전트에서 전체 도구 정의를 upfront로 실으면 15만 토큰이 들던 것을, 파일 트리로 도구 API를 만들어 필요한 정의만 필요 시점에 읽게 하면 2,000토큰으로 줄었다는 사례입니다(출처의 발표값). 주목할 점은 이 절감이 MCP를 버린 결과가 아니라 MCP를 쓰는 방식을 바꾼 결과라는 것입니다. Cloudflare의 “Code Mode”도 같은 방향의 발견을 공개했습니다. 2025년 9월 발표된 Code Mode는 MCP 도구를 LLM에 직접 노출하는 대신 TypeScript API로 변환하고 LLM이 그 API를 호출하는 코드를 쓰게 하는 방식인데, 여러 도구 호출을 연결할 때 중간 결과가 매번 모델 컨텍스트를 왕복하며 생기는 토큰 낭비를 건너뛸 수 있다고 보고합니다(출처의 발표값). 즉 스키마 주입을 줄이는 Anthropic의 접근과 도구 호출 자체를 코드로 바꾸는 Cloudflare의 접근이 서로 다른 경로로 같은 지점 — ‘전체 upfront 로딩 + 직접 도구 호출’ 구성의 비효율 — 을 가리킵니다. Anthropic 스스로 코드 실행에는 샌드박싱·리소스 제한·모니터링이라는 새 운영 비용이 붙는다고 명시합니다.

조건 세 개로 벤치마크 읽기

정리하면, MCP 토큰 오버헤드 실측치가 어디에 붙는지 결정하는 변수는 크게 세 개입니다.

1) 스키마 크기와 도구 수. 43개 도구의 GitHub 서버와 4개 도구의 경량 서버는 다른 물체입니다. 오버헤드는 프로토콜 헤더가 아니라 스키마 텍스트에서 나오므로, 도구 수 × 스키마 장황함이 곧 고정비입니다.

2) 고정비를 나누는 세션 길이. 스키마 로드가 세션당 1회라면 고정비는 호출 횟수로 상각됩니다. Scalekit 벤치마크처럼 작업당 짧은 대화에서 43개 스키마가 매번 따라가면 32배가 되고, r/mcp 측정처럼 한 번 로드하고 10회 이상 호출하면 +50토큰/호출로 수렴합니다. 두 숫자는 같은 물리량의 양극단입니다.

3) 필터링·캐싱·지연 로딩 유무. 필요한 도구만 골라 주입하는 라우팅(BM25 등), 스키마를 한 번만 싣고 ID로 참조하는 캐싱, 파일 트리로 필요한 정의만 읽는 코드 실행 방식은 모두 ‘전체 upfront 로딩’이라는 최악의 구성을 해체하는 기법입니다. Tyk는 라우팅으로 스키마 오버헤드 80~90% 절감, Scalekit은 게이트웨이 필터링으로 44,000→약 3,000토큰(출처들의 발표값)을 보고합니다. Perplexity API 문서에도 MCP 도구 정의를 지연 로딩하는 옵션(defer_loading)이 이미 들어가 있습니다 — 벤치마크가 잰 구성과 현재의 기본 구성이 벌써 다를 수 있다는 뜻입니다.

여기에 토큰 비용 밖의 축을 얹으면 판단 표가 완성됩니다. r/mcp 스레드의 한 댓글이 제안한 대로, 실패한 호출 수·재시도 깊이·사람 개입률을 함께 봐야 합니다. 토큰이 싼 레인도 재시도와 운영자 시간을 태우면 총비용에서 질 수 있습니다. 그리고 Scalekit이 벤치마크 후반부에서 스스로 인정하듯, “개발자 본인의 워크플로우 자동화”와 “고객을 대신해 행동하는 제품”은 요구사항이 다릅니다 — 후자에서는 사용자별 OAuth, 테넌트 분리, 감사 로그가 필요하고, 이 통치 비용은 토큰 단가와 다른 저울에 올라갑니다.

판단 체크리스트

QSike 관점에서, 에이전트 도구 연결 방식을 정할 때 “MCP는 몇 배 비싼가”라는 질문은 이렇게 바꿔야 한다고 봅니다. 각 문항에는 벤치마크를 인용하기 전에 자기 구성에서 직접 확인할 방법을 함께 적었습니다.

1. 등록할 도구 몇 개, 스키마는 몇 토큰인가? — 10개 미만 경량 스키마라면 고정비 논쟁은 사실상 끝납니다. 수십 개 도구를 전부 켜려는 구성이라면 어떤 벤치마크를 보기 전에 줄이는 게 먼저입니다.
   • 확인 방법: MCP 서버의 tools/list 응답(JSON)을 받아 모델 제공자의 토큰 카운트 API로 셉니다. 예: Anthropic의 POST /v1/messages/count_tokens 엔드포인트는 메시지를 실제로 생성하지 않고도 도구(tools) 정의를 포함한 입력 토큰 수를 반환합니다. 도구 수를 10개·20개·전체로 바꿔가며 한 번만 재보면 자기 구성의 고정비가 나옵니다. 수십 개 도구 규모라면 Tyk의 근사치(30개 도구당 15,000~20,000토큰, 출처의 발표값)와 자릿수가 맞는지 대조해 볼 수 있습니다.
2. 세션당 호출이 몇 회인가? — 단발 쿼리 위주면 CLI·직접 API가 구조적으로 유리하고, 긴 멀티턴 세션이면 스키마 고정비는 상각됩니다.
   • 확인 방법: 최근 업무 로그에서 작업 한 건당 평균 모델 호출 횟수를 세고, ‘스키마 고정비 ÷ 호출당 추가 토큰’으로 손익분기 호출 수를 계산해 둘을 비교합니다. 주의할 점은 이 식이 항상 스레드의 주장과 일치하지는 않는다는 것입니다 — r/mcp 측정의 숫자(고정비 약 1,300토큰, 호출당 차이 약 50토큰)만 대입하면 약 26회가 나오는데, 게시자는 “8~10회”를 주장하면서 도출 과정을 공개하지 않았습니다(비교 대상이나 가정한 조건이 다를 수 있습니다). 출처 자체 측정의 내부 일관성도 함께 확인해야 한다는 뜻입니다(입력값은 출처의 자체 측정값).
3. 클라이언트가 필터링·지연 로딩·캐싱을 지원하는가? — 지원한다면 “4~32배” 벤치마크의 구성 자체가 이미 과거입니다. 지원 여부를 제품 문서에서 직접 확인해야 합니다(이 글의 확인 시점: 2026-09-09).
   • 확인 방법: 클라이언트·게이트웨이 문서에서 ‘도구 필터링(라우팅)’, ‘지연 로딩(defer/lazy loading)’, ‘프롬프트 캐싱’ 세 키워드를 직접 검색합니다. 프로토콜 차원에서는 MCP 사양 2025-06-18 개정판의 Streamable HTTP 전송이 Mcp-Session-Id 기반의 상태 유지 세션을 정의하고 있어 스키마를 세션당 한 번만 싣는 구성의 전제가 됐습니다. 다만 현재 사양 버전(2026-07-28)에서는 프로토콜 수준의 세션이 제거됐으므로, 세션 기반 캐싱은 사양 보장이 아니라 구현별 기능입니다. 실제 캐싱·필터링 지원은 구현마다 다르므로 사양이 아니라 쓰는 제품의 문서에서 확인해야 합니다.
4. 로컬 실행인가 원격 서버인가? — 신뢰성 차이(재시도, 타임아웃)는 대부분 이 축에서 나옵니다. 원격이면 풀링·재시도 설계가 토큰보다 큰 비용 항목이 될 수 있습니다.
   • 확인 방법: 자기 구성에서 호출을 표본 추출(예: Scalekit처럼 25회 이상)해 오류를 ‘연결 타임아웃 / 프로토콜 오류 / 도구 오류’로 분류하고, 실패율과 재시도 깊이·사람 개입률을 함께 기록합니다. Scalekit의 “실패율 28%“도 전부 ConnectTimeout이었듯, 오류의 종류를 갈라야 원인이 프로토콜인지 원격 서버인지 판단할 수 있습니다.
5. 에이전트가 누구를 대신해 행동하는가? — 본인 자동화인지, 다수 사용자·다중 테넌트 제품인지. 후자라면 통치 요구사항이 토큰 단가 논의를 덮습니다.
   • 확인 방법: 도입 전에 사용자별 OAuth 토큰 발급·보관 방식, 테넌트 분리, 감사 로그, 권한 범위(scope) 최소화를 요구사항 목록으로 적고, 후보 연결 방식이 이 목록을 충족하는지 대조합니다. 이 항목들은 토큰 비용과 별개로 방식 선택을 결정할 수 있습니다.

가상 예시: 우리 구성의 고정비부터 재는 순서

참고: 다음은 가상 예시입니다. 도구 수와 로그 기간은 설명용 가정이며, 어떤 토큰 값이나 절감 성과도 실측 결과가 아닙니다.

사내 저장소 질의 자동화에 MCP 서버를 붙이려는데, 후보 서버가 30개 도구를 노출한다고 가정해 보겠습니다. 벤치마크 배율을 인용하기 전에 (1) tools/list 응답을 토큰 카운터로 재서 스키마 고정비를 구하고, (2) 최근 한 달 업무 로그에서 작업 한 건당 평균 모델 호출 횟수를 세고, (3) 고정비와 호출당 차이를 대입해 손익분기 호출 수를 계산합니다. 평균 호출 수가 손익분기보다 적으면 그 구성에서는 CLI나 직접 API가 유리하고, 많으면 스키마 고정비는 세션 길이로 상각됩니다. 여기까지는 토큰 카운터와 자기 로그만으로 재현할 수 있는 절차이고, 남의 벤치마크에서 “몇 배”를 옮겨오는 것보다 먼저 할 일입니다.

“MCP가 CLI보다 32배 비싸다”와 “MCP 오버헤드는 노이즈다”는 모두 참인 문장입니다 — 각각 자기가 측정한 구성 안에서만. 벤치마크 숫자를 인용할 때 조건을 같이 옮기지 않으면, 그 인용 자체가 스키마 없는 도구 호출처럼 엉뚱한 결과를 만들어냅니다.

확인한 출처 / 근거

• Scalekit, “MCP is up to 32× more expensive than CLI. Here’s why we still use it.” (2026-03-11) — 4~32배, 실패율 28%, 월 비용 환산, 게이트웨이 절감 발표값과 측정 조건(모델·작업·서버). https://www.scalekit.com/blog/mcp-vs-cli-use
• Scalekit 벤치마크 공개 코드 — 재현 가능 범위 확인. 저장소 README의 예시 결과 표(배율 1.3~80×, 30회 실행)는 본문이 인용한 블로그 발표값(4~32×, 총 75회 실행)과 다른 별도 실행 출력으로 보이므로, 이 글의 수치는 블로그 글(2026-03-11) 기준이다. https://github.com/scalekit-inc/mcp-vs-cli-benchmark
• r/mcp, “I measured MCP vs CLI token costs — the ‘MCP is dead’ take is wrong (with data)” (작성 2026-03-16, UTC 기준) — 반대측 커뮤니티 자체 측정(초기 약 1,300토큰, 호출당 약 +50토큰, 손익분기 8~10회)과 댓글의 조건 의존 사례(도구 4개 서버 약 400토큰 등). 신뢰도 한계는 본문에 명시. https://www.reddit.com/r/mcp/comments/1rv6jyj/
• Anthropic Engineering, “Code execution with MCP: Building more efficient agents” (2025-11-04) — 150,000→2,000토큰(98.7%) 절감 발표값과 조건(수백~수천 도구, 파일 트리 기반 필요 시점 로딩), 코드 실행의 운영 비용 명시. https://www.anthropic.com/engineering/code-execution-with-mcp
• Cloudflare Blog, “Code Mode: the better way to use MCP” (2025-09-26) — MCP 도구를 TypeScript API로 변환해 LLM이 코드로 호출하게 하는 방식과 중간 결과 컨텍스트 왕복 절감 주장(발표값) 1차 확인. https://blog.cloudflare.com/code-mode/
• Repello AI, “MCP vs CLI: What Perplexity’s Move Actually Means for AI Security Teams” — Perplexity CTO Denis Yarats의 ‘컨텍스트 72% 점유’ 발언(Ask 2026 콘퍼런스) 2차 보도. https://repello.ai/blog/mcp-vs-cli
• Tyk Learning Center, “MCP vs CLI for AI agents: Enterprise comparison guide” — 72% 발언 정리, 도구 30개당 15,000~20,000토큰 근사치, BM25 라우팅 80~90% 절감, 게이트웨이 관점. https://tyk.io/learning-center/mcp-vs-cli-for-ai-agents-enterprise-comparison-guide/
• Perplexity API 문서, MCP 도구 defer_loading(스키마 지연 로딩) 옵션 — 벤치마크 이후 클라이언트 기능 변화 확인. https://docs.perplexity.ai/docs/agent-api/tools/mcp
• Anthropic API 문서, “Count tokens in a Message” — 체크리스트 1번의 스키마 토큰 측정 방법(메시지 생성 없이 tools 포함 입력 토큰 수 반환) 근거. https://docs.anthropic.com/en/api/messages-count-tokens
• MCP 사양, “Transports” (2025-06-18) — Streamable HTTP의 Mcp-Session-Id 기반 상태 유지 세션 정의, 체크리스트 3번의 캐싱 전제 설명 근거(구버전 한정). https://modelcontextprotocol.io/specification/2025-06-18/basic/transports
• MCP 사양, “Streamable HTTP” (2026-07-28, 현재 버전) — 2026-07-28 개정에서 프로토콜 수준 세션(Mcp-Session-Id)이 제거됐다는 확인 근거. https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
• 참고: 위 링크의 HTTP 접근 가능 여부(200)는 2026-09-09에 확인했으나, 링크 생존과 내용 사실 검증은 별개이며 최종 사실 검증은 후속 단계에서 수행한다. 모든 배율·비용 수치는 각 출처의 발표값이고, 이 글에서 독립 재현한 값은 없다.