MCP는 끝났는가? 개발자들이 Model Context Protocol에 의구심을 갖는 이유에 대한 심층 분석 (2026년 5월)

Model Context Protocol (MCP)는 AI 에이전트가 작업을 수행하는 데 필요한 도구 및 서비스와 통신할 수 있는 표준화된 방식으로서, 위대한 통합자가 될 예정이었습니다. 2024년 말에 출시된 이 프로토콜은 Anthropic, OpenAI, 그리고 성장하는 도구 제공업체 생태계에 의해 빠르게 "AI 생태계의 USB-C"로 추앙받았습니다.

하지만 신혼여행은 끝났을지도 모릅니다. Quandri Engineering의 파괴적인 새로운 분석과 격렬한 Hacker News 토론 (195 포인트, 174개 댓글)이 결합되면서 MCP의 명성에 심각한 타격을 입혔습니다. 결론은 무엇일까요? MCP는 컨텍스트 (Context)를 잡아먹고, 신뢰도가 낮으며, 이미 완벽하게 작동하고 있는 기존의 CLI 및 API 도구들과 상당 부분 중복된다는 것입니다.

문제 1: 컨텍스트 윈도우 (Context Window)를 집어삼키다

Quandri의 분석에서 가장 치명적인 발견은 MCP 도구 정의 (tool definitions)에 의해 소비되는 엄청난 양의 토큰 (tokens)입니다. 그들의 실제 스택 (Linear, Notion, Slack, 그리고 Postgres MCP 서버)에서, 도구 정의만으로 21,000개 이상의 토큰을 소비했습니다. 이는 Claude 200K 컨텍스트 윈도우의 10.5%이며, **GPT-4o의 128K 컨텍스트의 16.5%**에 달하는 수치입니다.

MCP 서버	도구 (Tools)	예상 토큰 수
Linear	42	~12,807
...

이 문제는 아키텍처 수준의 문제입니다. 모든 도구 정의에는 JSON 스키마 (JSON schema) — 파라미터 (parameters), 설명 (descriptions), 반환 타입 (return types) — 가 포함되며, 모델이 실제로 사용할지 여부와 관계없이 모든 정의가 컨텍스트에 로드됩니다. Linear의 경우, 사용자가 get_issue와 save_issue만 사용하더라도 42개의 도구 정의(~12,807 토큰)를 제공합니다.

기사에서 인용한 식당 비유: "자리에 앉았는데 테이블 위에 메뉴판 10개가 펼쳐져 있는 것과 같습니다. 실제 음식을 놓을 공간이 남아나지 않습니다."

업데이트: 이러한 측정치가 기록된 이후, Claude Code는 지연 로딩을 통한 도구 검색 (Tool Search with Deferred Loading) 기능을 출시했습니다. 이 기능은 MCP 도구 스키마 (tool schemas)를 필요할 때만 로드하여 컨텍스트 (context) 사용량을 85% 이상 줄여줍니다. 따라서 이 특정 문제는 완화되고 있지만, 아키텍처 (architectural) 측면의 우려는 여전히 남아 있습니다.

문제 2: 낮은 운영 신뢰성 (Low Operational Reliability)

MCP의 신뢰성 문제는 무시하기가 더 어렵습니다. Quandri 팀은 MCP의 아키텍처에서 기인하는 몇 가지 실패 모드 (failure modes)를 기록했습니다:

문제	세부 사항
초기화 실패, 반복적인 재인증	별도의 프로세스를 시작하고 유지해야 함
...

성능 수치는 극명합니다. 원문 기사의 저자는 Jira MCP를 REST API와 직접 벤치마킹했습니다: MCP는 호출당 3배 더 느렸으며, 초기화 오버헤드 (initialization overhead)를 포함한 첫 번째 호출에서는 9.4배 더 느렸습니다. 이는 Jira에 국한된 문제가 아니라 아키텍처의 문제입니다. 모든 MCP 서버는 LLM과 하위 API 사이에 프로세스 계층을 추가합니다.

문제 3: 기존 CLI/API와의 중복

아마도 가장 근본적인 비판은 이것일 것입니다: MCP는 이미 존재하며 더 잘 작동하는 기능을 중복해서 제공합니다.

측면	CLI / API	MCP
인간-기계 동등성 (Human-machine parity)	인간과 LLM이 동일한 명령어를 사용	LLM 대화 내부에서만 존재
...

토큰 (token) 비교 결과는 참혹합니다. 동일한 Linear 이슈를 조회할 때:

• CLI 방식: 총 약 200 토큰 (curl 명령 프롬프트에 50, 응답에 150)
• MCP 방식: 총 약 12,957 토큰 (항상 로드되는 도구 정의에 12,807, 실제 호출에 150)

동일한 작업에 대해 65배 더 많은 토큰을 사용하는 셈입니다.

CLI 우선 대안 (The CLI-First Alternative)

제시된 대안은 우아할 정도로 단순합니다: 기존의 CLI 도구를 LLM에 제공하는 것입니다. LLM은 이미 매뉴얼 페이지 (man pages), StackOverflow, 그리고 수백만 개의 GitHub gist로부터 학습했습니다. LLM은 이미 curl 명령어를 구성하고, jq를 통해 파이프 (pipe)를 연결하며, 결과를 grep으로 검색하는 방법을 알고 있습니다. 새로운 프로토콜은 필요하지 않습니다.

# CLI 접근 방식 — 현재 바로 작동하며, MCP 서버가 필요 없음
curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \
  -H "Content-Type: application/json" \
...

진짜 이야기는 무엇인가?

공정하게 말하자면, MCP가 하룻밤 사이에 사라지지는 않을 것입니다. 생태계에 대한 투자가 상당합니다. Anthropic은 특히 MCP 툴링 (tooling)을 가속화하기 위해 Stainless를 인수했으며, GitHub, Notion, Linear와 같은 주요 플랫폼들은 공식 MCP 서버를 출시했습니다. 이 프로토콜은 AI 에이전트 (AI agents)가 외부 서비스와 상호작용할 수 있도록 표준화된 인터페이스 (interface)를 제공한다는 실질적인 문제를 해결합니다.

하지만 비판론자들은 **아키텍처 철학 (architectural philosophy)**에 대한 중요한 질문을 던집니다. Claude Code나 Codex와 같은 LLM (Large Language Models)을 매우 효과적으로 만들었던 "상자에 SSH로 접속하여 CLI를 사용하는" 방식은 MCP 서버 모델보다 근본적으로 더 단순합니다. 이 방식은 새로운 인프라 (infrastructure), 프로토콜 협상 (protocol negotiation), 별도의 프로세스 생명주기 관리 (process lifecycle management)를 필요로 하지 않습니다.

한 HN (Hacker News) 댓글 작성자가 언급했듯이, "MCP는 존재하지 않는 문제를 해결하려는 것처럼 느껴집니다. 우리는 이미 소프트웨어와 소프트웨어 간에 작동하는 인터페이스를 가지고 있었습니다. 돌파구는 LLM이 이제 동일한 인터페이스를 사용할 수 있게 되었다는 점입니다."

결론

이 논쟁의 명칭이 된 원문 "MCP is dead" 포스트는 의도적으로 도발적일 수 있습니다. 하지만 그 이면의 데이터는 실재합니다. 오늘날 AI 에이전트 워크플로 (agent workflows)를 구축하는 팀들에게 MCP와 직접적인 CLI/API 접근 방식 사이의 선택은 이데올로기의 문제가 아닙니다. 이는 토큰 (tokens), 지연 시간 (latency), 그리고 신뢰성 (reliability) 측면에서 측정 가능한 비용의 문제입니다.

가장 현명한 접근 방식은 무엇일까요? 선택하지 않는 것입니다. MCP가 잘하는 것(표준화된 탐색 (standardized discovery), 빠른 프로토타이핑 (rapid prototyping), 생태계 호환성)에는 MCP를 사용하고, 빈도가 높고 지연 시간에 민감한 작업에는 직접적인 CLI/API 호출로 전환하십시오. 최고의 에이전트 아키텍처는 두 프로토콜을 투명하게 모두 지원하는 에이전틱 (agnostic)한 형태가 될 것입니다.

MCP에 대한 여러분의 경험은 어떠신가요? 이 프로토콜에 더 집중하고 계신가요, 아니면 CLI 우선 (CLI-first) 대안을 살펴보고 계신가요? Hacker News의 토론에서 여러분의 생각을 공유해 주세요.

이 기사는 원래 The Agent Report에 게시되었습니다.