TL;DR. MCP가 토큰을 태운다는 진단은 옳다. 하지만 그건 모든 도구 정의를 미리 들이붓는 적재 방식의 문제지 프로토콜의 문제가 아니다 — 그 적재 방식은 이미 tool search로 갈리고 있다. 그리고 회의론의 처방인 CLI로 돌아가라는 셸에서 닿는 표면이 이미 있는 도구에만 통한다. Unity처럼 라이브 에디터 상태에 묶인 도구엔 그 표면이 없다. 그래서 필자는 MCP를 못 끈다.
MCP라는 약속
2024년 말 Anthropic이 Model Context Protocol을 내놨을 때 붙은 별명이 AI를 위한 USB-C였다. LLM을 GitHub·Linear·Notion·Slack 같은 외부 도구에 꽂는 표준 커넥터 하나면, 도구마다 어댑터를 새로 짜던 시대가 끝난다는 약속. 1년 반 만에 MCP는 기반 인프라로 받아들여졌고, 어지간한 SaaS가 자기 MCP 서버를 냈다.
회의론의 근거
그 약속을 매일 쓰는 개발자들이 지금 등을 돌리고 있다. 가장 정면의 반론은 Quandri 엔지니어링 블로그의 "MCP is dead"다. 핵심은 비용이다.
- 컨텍스트 잠식 — Quandri가 붙인 MCP 서버 4개가 쓰기도 전에 약 21,077 토큰, Claude 200K 컨텍스트의 10.5%를 먹었다. Linear 하나가 42개 도구 정의로 12,807 토큰. 그중 실제로 쓰는 건 한 줌이다.
- 65배 — Linear 이슈 하나를 CLI로 조회하면 약 200 토큰, MCP로 같은 일을 하면 약 12,957 토큰. 같은 결과에 65배.
- 느림 — 독립 벤치마크에서 MCP는 호출당 3배, 첫 호출은 9.4배 느렸다. 세션 중 서버 크래시, 인증 실패 후 프로세스 재시작, 불투명한 권한 모델까지.
이건 한 회사의 불만이 아니다. Perplexity는 내부에서 MCP를 들어내며 컨텍스트의 72%가 낭비된다고 밝혔고, 한 측정에선 GitHub·Playwright·IDE 서버 셋만 꽂아도 200K 중 143K(72%)가 도구 설명으로 차고 도구 선택 정확도가 43%에서 14% 아래로 무너졌다. 회의론은 정서가 아니라 수치다. 깎을 카드가 아니다.
처방은 이미 나와 있다
회의론의 처방은 두 가지다. 이미 쓰는 CLI를 써라 — 모델은 man page와 Stack Overflow로 그 도구를 이미 학습했다. 그리고 Skills — 모든 정의를 상주시키지 말고 필요할 때만 도구 사용법을 로드하라. 둘 다 옳다. 다만 둘 다 같은 진단을 공유한다: 문제는 MCP가 무엇이냐가 아니라 정의를 어떻게 적재하느냐다.
그리고 바로 그 적재 방식이 지난 반년 사이 갈렸다.
- code execution with MCP — Anthropic이 도구 카탈로그를 모델 컨텍스트가 아니라 코드/파일시스템으로 옮기는 방식을 냈다. 에이전트가 도구를 직접 호출하는 대신 코드를 써서 호출하고, 정의는 필요할 때만 읽는다. 한 워크플로가 150K 토큰에서 2K로 — 98.7% 감소, 약 10배 빠름.
- tool search — Anthropic의 Tool Search와 Programmatic Tool Calling이 2026년 2월 GA로 풀렸다. 도구 설명이 컨텍스트의 10%를 넘으면 전부 상주시키는 대신 이름만 띄워두고 스키마는 검색으로 끌어온다.
- Code Mode — Cloudflare가 2월에 낸 방식은 API 전체를 search·execute 두 도구, 약 1,000 토큰으로 노출한다. 네이티브 MCP로 같은 표면을 펴면 1.17M 토큰.
필자가 이 블로그를 쓰는 Claude Code가 정확히 그렇게 돈다. 수십 개 MCP 도구가 이름만 떠 있다가, 필요할 때 ToolSearch로 스키마를 끌어온다. 회의론이 친 21,077 토큰을 미리 붓는 설계는 이미 과거형이다. MCP는 죽는 게 아니라 적재 방식이 바뀌는 중이다.
CLI가 닿지 않는 곳
여기까지면 "MCP 회의론이 맞고 처방도 나왔다"로 끝난다. 끝나지 않는 이유는 회의론의 1번 처방에 박힌 전제 때문이다 — CLI로 돌아가라는 셸에서 닿는 표면이 이미 있다고 가정한다. git·gh·Linear에는 CLI가 있다. man page도 있다. 그 도구들은 MCP 없이도 텍스트로 조작된다.
Unity에는 그게 없다. 필자는 리듬게임 하나를 Unity로 만들며 Unity MCP를 쓰는데, 이건 셸에서 대체되지 않는다. 라이브 씬 그래프를 읽고, 선택된 GameObject의 직렬화 필드를 들여다보고, 도메인 리로드를 걸고, 콘솔 로그를 받고, 플레이 모드 상태를 만지는 일 — unity-cli로 GameObject를 선택하고 인스펙터 값을 읽는 명령은 존재하지 않는다. Unity는 GUI에 묶인 stateful 런타임이고, 그 살아 있는 상태로 들어가는 문은 에디터에 박힌 MCP 서버 하나뿐이다.
Blender·Figma·게임 엔진·DAW — 라이브 에디터 상태를 다루는 카테고리 전체가 같다. 여기서 MCP는 CLI와 중복이 아니라 유일한 진입로다. 회의론의 처방은 셸 텍스트로 환원되는 도구에만 닿는다. 환원되지 않는 도구는 처방의 사정거리 밖에 있다. 그래서 토큰을 태우는 걸 알면서도 끌 수 없다.
다시 설계될 MCP
그러니 단정은 이렇다. MCP는 회의의 대상이 맞지만, 회의의 표적은 프로토콜이 아니라 eager-loading이고, 표적은 이미 무너지고 있다. 토큰과 컨텍스트를 침해하지 않고 MCP를 쓰는 법의 윤곽은 나와 있다 — 정의를 미리 붓지 말고 검색으로 끌어오고(tool search), 카탈로그를 모델 컨텍스트가 아니라 코드로 내려라(code execution).
남은 리서치는 stateful 도구다. tool search와 code execution은 호출이 무상태(stateless)인 SaaS API를 전제로 최적화돼 있다. Unity처럼 상태가 살아 있는 도구에서 progressive disclosure를 어떻게 거는지는 아직 미성숙하다 — 씬 그래프 전체를 들이부으면 컨텍스트가 또 터지고, 너무 깎으면 에이전트가 눈을 잃는다. 라이브 상태를 필요한 만큼만 모델에 노출하는 적재 전략, 그게 다음 자리다. 필자가 그 방향을 판다.
회의론자에게 빚진 한 줄은 분명하다 — 토큰을 미리 붓는 MCP는 죽어 마땅하다. 다만 그건 MCP의 죽음이 아니라 나쁜 적재 방식의 죽음이다.
참고
회의론 측
- Quandri — MCP is dead
- Perplexity, 내부에서 MCP 제거 — 컨텍스트 72% 낭비
- The bloat tax — MCP 도구가 컨텍스트를 먹고 도구 선택 정확도가 무너지는 측정
처방 측