과연 MCP는 죽어가고 있는가

(아래는 ChatGPT 5.4 thinking 에게 위 글에 대한 평가를 해보라고 요청하여 받은 응답입니다.)

이 글은 “터미널 안에서 돌아가는 로컬 코딩 에이전트”라는 아주 특정한 전장에서는 꽤 날카롭습니다. 하지만 거기서 곧바로 “MCP는 죽어가고 있다”로 점프하는 순간, 진단이 과장됩니다. 2026년 3월 6일 기준으로 MCP는 오히려 Linux Foundation 산하 AAIF의 창립 프로젝트가 되었고, Anthropic·OpenAI·Block이 공동 창립에 참여했으며, Google·Microsoft·AWS 등이 지원하고 있습니다. MCP 프로젝트 측은 2025년 12월 시점에 월간 SDK 다운로드 9,700만+, 활성 서버 1만+, ChatGPT·Claude·Gemini·Microsoft Copilot·VS Code 등 주요 클라이언트 지원을 언급했고, OpenAI 공식 문서도 MCP를 “industry standard가 되어가고 있다”고 설명합니다. 즉, 불편한 것은 맞지만, 죽는 중이라고 보긴 어렵습니다. (ejholmes.github.io)

그럼에도 Holmes 글이 강한 이유는, 추상적 표준 담론이 아니라 실제 개발자 작업감을 건드리기 때문입니다. Pi는 의도적으로 MCP를 코어에 넣지 않았고, OpenClaw도 “코어 런타임에 1급 MCP를 넣기보다 mcporter 브리지 모델을 선호한다”고 밝힙니다. 이유도 Holmes의 주장과 닮았습니다. 코어를 lean하게 유지하고, 재시작 없이 MCP 서버를 갈아끼우고, MCP 자체의 변화가 코어 안정성과 보안을 흔들지 않게 하겠다는 것입니다. 여기에 더해 GitHub와 Claude Code 문서는 MCP 문제 해결 시 로그 확인, 서버/IDE 재시작 같은 절차를 안내하고 있고, Gemini CLI는 아예 “충돌하는 MCP 서버, 숨은 환경변수, 누락된 API 키 때문에 생기는 애매한 시작 실패”를 줄이기 위해 extension settings를 내놓았습니다. 즉, 운영 마찰은 Holmes 혼자 겪는 착각이 아니라 실제 제품 문서에도 드러납니다. (Armin Ronacher's Thoughts and Writings)

특히 CLI의 장점을 짚는 대목은 정곡입니다. 사람이 jira issue view나 gh pr view 123을 직접 재현해볼 수 있고, jq·grep·리다이렉션·파이프라는 수십 년짜리 조합성이 있으며, Terraform plan 같은 큰 산출물을 맥락창에 다 집어넣지 않고 기존 유닉스 도구로 잘라낼 수 있다는 주장은 강합니다. 이건 단순 취향이 아니라 디버깅 가능성, 재현 가능성, 토큰 효율의 문제입니다. Holmes가 제시한 terraform show -json ... | jq ... 예시는 왜 터미널 중심 워크플로가 아직도 강력한지 잘 보여줍니다. (ejholmes.github.io)

다만 이 글이 약해지는 지점은, CLI가 잘 먹힌다는 사실에서 별도 프로토콜은 무의미하다는 결론을 꺼내는 부분입니다. 프로토콜은 “모델이 CLI를 못 써서” 생기는 게 아닙니다. MCP의 핵심 가치는 모델에게 셸을 가르치는 것이 아니라, 여러 클라이언트가 공통 방식으로 도구를 발견하고(tools/list), 각 도구의 이름·설명·입출력 스키마(JSON Schema)를 이해하고, 구조화된 결과를 다루도록 만드는 데 있습니다. 인간용 CLI는 종종 표 출력, 인터랙티브 프롬프트, 로케일, 셸 quoting, 플랫폼 차이 같은 인간 친화적 복잡성을 품고 있는데, MCP는 그 위를 기계 친화적 계약으로 평탄화하려는 시도입니다. (Model Context Protocol)

그래서 Holmes의 “LLM은 특수 프로토콜이 필요 없다”는 말은 절반만 맞습니다. 한 대의 머신, 한 명의 운영자, 잘 정비된 개발용 CLI가 있는 환경에서는 맞습니다. 하지만 여러 클라이언트(예: ChatGPT, Codex CLI, VS Code, Copilot, Gemini CLI)가 같은 서비스 통합을 공유해야 하는 순간, CLI 하나만으로는 부족해집니다. GitHub는 공식 MCP 서버를 유지하고 있고, GitHub 내 Copilot Chat에서는 그 서버가 자동 구성되며 일부 기능은 바로 쓸 수 있습니다. Visual Studio도 MCP 호환 서버를 Copilot agent mode에 붙이는 방식을 공식 문서로 안내합니다. Google은 공식 MCP 서버들을 내놓고 있고, OpenAI는 ChatGPT Apps·deep research·API 통합을 위한 원격 MCP 서버 구축 가이드를 제공합니다. 이건 “대화 안에만 갇힌 툴”이 아니라 여러 호스트가 재사용하는 통합 계층에 가깝습니다. (GitHub Docs)

Holmes의 첫 문장도 사실관계가 좀 거칩니다. 그는 “OpenClaw doesn’t support it. Pi doesn’t support it.”라고 썼지만, Pi 글 자체가 설명하듯 OpenClaw은 mcporter를 통해 MCP를 쓰고 있고, OpenClaw의 비전 문서도 “OpenClaw supports MCP through mcporter”라고 못 박습니다. 즉, OpenClaw은 MCP 부정론의 증거가 아니라 MCP를 코어 런타임에서 분리해 브리지로 다루자는 설계 선택의 사례입니다. Pi 역시 “MCP는 나쁘다”보다 “코드가 스스로 도구를 만들어가게 하겠다”는 철학적 선택에 가깝습니다. 이 둘을 근거로 생태계 전체의 쇠퇴를 말하는 건 표본이 너무 편향돼 있습니다. (ejholmes.github.io)

인증(auth) 비판도 비슷합니다. Holmes는 MCP가 auth에 과도하게 개입한다고 느끼지만, 공식 문서는 HTTP 기반 전송에서만 권장되는 authorization 프레임워크를 설명하고, STDIO 전송은 그 스펙을 따르지 말고 환경변수 기반 credential을 사용하라고 적습니다. 다시 말해 로컬 MCP는 CLI와 같은 방식의 자격증명 재사용을 허용합니다. 다만 Google Apigee는 별도로 “MCP는 빠르게 진화 중이며, enterprise 요구사항인 authentication, authorization, observability를 아직 충분히 말해주지 않는다”고 적었습니다. 이건 Holmes의 불만이 완전히 틀린 게 아니라, 주로 원격/기업형 배포에서 더 크게 드러나는 문제라는 뜻입니다. (Model Context Protocol)

권한 모델을 향한 그의 비판은 현재 시점에는 가장 약한 편입니다. Claude Code 문서는 이미 세밀한 permission 규칙, MCP 서버/도구 이름 단위 매칭(mcp__server__tool), 관리형 정책, PreToolUse hook 기반 승인/거부를 설명합니다. OpenAI API 쪽은 원격 MCP 도구에 대해 allowed_tools를 배열 또는 { read_only, tool_names } 형태로 설정할 수 있다고 명시합니다. 그러니 “MCP permissions are all-or-nothing”은 MCP 자체의 속성이라기보다 일부 클라이언트 구현의 한계 또는 당시 체감에 가까운 말입니다. 다만 Holmes가 더 깊게 겨냥한 “의미 단위 정책” — 예를 들어 ‘merge는 막고 view만 허용’, 혹은 특정 인자 조합만 차단 — 은 여전히 매끈하게 풀린 문제가 아니라고 보는 편이 공정합니다. (Claude)

오히려 2026년 흐름은 CLI와 MCP가 싸우는 게 아니라 겹쳐지고 있는 것에 가깝습니다. Codex는 “CLI와 IDE extension 모두에서 MCP 서버를 지원한다”고 밝히고 있고, Gemini CLI도 FastMCP 및 여러 확장을 통해 MCP를 터미널 안으로 끌어들입니다. OpenClaw은 mcporter로 MCP를 브리지하고, 그 mcporter는 반대로 MCP 서버를 독립 실행형 CLI로 생성할 수 있다고 설명합니다. 즉 시장은 “CLI 대신 MCP”가 아니라 CLI가 MCP 클라이언트가 되고, MCP가 다시 CLI로 컴파일되는 방향으로 움직이고 있습니다. 이 점에서 Holmes의 제목은 논쟁적으로는 성공했지만, 기술적 현실을 가장 잘 설명하는 문장은 아닙니다. (OpenAI Developers)

또 하나 Holmes가 과소평가한 건 비-터미널 상호작용입니다. MCP Apps는 대시보드, 폼, 시각화, 다단계 워크플로, PDF 뷰어 같은 인터랙티브 UI를 대화 안에서 렌더링하도록 표준화했고, 공식 블로그는 ChatGPT·Claude·Goose·VS Code 지원을 언급합니다. 이 영역에서는 CLI가 사람에게 친숙하다는 장점이 그대로 우세하지 않습니다. 데이터 탐색, 설정 wizard, 문서 검토처럼 텍스트와 셸만으로는 어색한 작업이 분명 있기 때문입니다. Holmes의 논변은 너무 “터미널-중심 코딩 에이전트”에 최적화돼 있어서, 이 넓은 범위를 놓칩니다. (Model Context Protocol Blog)

그래서 가장 정확한 재서술은 이겁니다. “MCP는 죽었다”가 아니라 “로컬 코딩 에이전트는 CLI-first여야 한다.” 이건 상당히 설득력 있습니다. 반대로 “CLI가 있으니 MCP는 불필요하다”는 말은 약합니다. 둘은 같은 계층의 경쟁재가 아닙니다. CLI는 인간과 로컬 자동화를 위한 실행 인터페이스이고, MCP는 여러 AI 호스트와 서비스 사이의 상호운용 계약입니다. 좋은 API가 가장 밑바닥에 있어야 하고, 그 위에 좋은 CLI가 있어야 하며, 여러 클라이언트에 도구를 배포하려면 MCP가 추가되는 식이 더 자연스럽습니다. Google도 “APIs are the foundation”라고 적습니다. 나는 Holmes의 마지막 조언을 “좋은 API를 만들고, 좋은 CLI를 만들고, 다중 클라이언트 상호운용성이 필요하면 MCP도 제공하라”로 고쳐 쓰는 편이 맞다고 봅니다.

정리하면, 이 글은 현장 불만의 진단서로서는 강하고, 거시적 예언서로서는 약합니다. 로컬 개발 워크플로, 디버깅, 유닉스 조합성, 기존 인증 재사용에 대한 찬가는 타당합니다. 하지만 OpenClaw/Pi 사례로 생태계 쇠퇴를 일반화한 것, MCP의 표준화 가치와 다중 클라이언트 재사용성을 과소평가한 것, 최신 권한/도구 제어 흐름을 반영하지 못한 것은 분명한 약점입니다. 내 최종 평결은 간단합니다. CLI는 부활할 필요가 없을 만큼 원래 강했고, MCP도 죽지 않았습니다. 앞으로는 CLI가 현장 UX를 담당하고, MCP가 이식성과 배포를 담당하는 혼합 체제가 더 유력합니다. (ejholmes.github.io)