MCP는 2026년에 죽었나?

아니다. 다만 "MCP는 죽었다"는 주장에는 분명한 일리가 있었다. r/WebAfterAI의 한 스레드는 그 주장이 과장됐다고 봤는데, 맞는 말이다. 공식 MCP 레지스트리는 2026년 5월 24일 기준 약 9,652개 서버를 보유했고, Anthropic은 활성 공개 서버를 10,000개 이상으로 집계하며, SDK는 월 9,700만 건 넘게 다운로드된다. 이런 숫자를 가졌고 최대 규모의 AI·클라우드 기업들이 공동으로 거버넌스하는 프로토콜은 시체가 아니다. 그렇다고 죽었다고 선언한 사람들이 없는 말을 지어낸 것도 아니다.

비판이 맞았던 부분

핵심 불만은 컨텍스트 비대화였고, 그건 사실이었다. 연결한 MCP 서버는 에이전트가 쓰든 안 쓰든 처음에 자신의 모든 도구 정의를 모델의 컨텍스트 윈도에 올린다. 도구가 스무 개씩 달린 서버 다섯 개를 붙이면, 모델이 사용자 메시지를 한 줄 읽기도 전에 함수 설명에만 수천 토큰을 쓰게 된다. 규모가 커지면 그건 더 느리고, 더 멍청하고, 더 비싸다. 사람들은 가정적인 상황을 두고 투덜댄 게 아니다. 실제 토큰 청구서를 재고 있었다.

출시된 해결책

그 비판은 이제 대부분 대응 가능하다. Anthropic은 모든 정의를 컨텍스트에 올리는 대신 에이전트가 도구를 호출하는 코드를 작성하는, 코드 실행 방식을 공개했다. 어떤 워크플로에서는 토큰을 98.7% 줄였다. 지연(레이지) 도구 로딩은 도구가 실제로 필요해질 때만 정의가 도착하게 한다. Cloudflare의 Code Mode도 같은 발상을 밀어붙인다. 프롬프트를 스키마로 가득 채우는 대신, 모델이 API 표면을 상대로 코드를 생성하게 하는 것이다. 초기 패닉 시점엔 이 중 어느 것도 없었다. 비대화 불만은 프로토콜을 버릴 이유가 아니라, 해결된 엔지니어링 과제로 나이를 먹었다.

MCP가 죽지 않았다는 근거

누가 뒤를 받치고 있는지 보라. 2025년 12월 9일, MCP는 Linux Foundation 산하의 새로운 Agentic AI Foundation에 기증됐다. 이 재단은 Anthropic, Block, OpenAI가 공동 설립했고 Google, Microsoft, AWS, Cloudflare, Bloomberg가 후원한다. OpenAI는 2025년 10월 ChatGPT의 Developer Mode에 MCP 지원을 출시했다. 클라이언트 지원은 이제 ChatGPT, Cursor, Gemini, Copilot, VS Code, Claude에 걸쳐 있다. 최대 경쟁사가 당신의 프로토콜을 채택하고, 나아가 중립적인 재단을 통해 함께 거버넌스한다면, "죽었다"는 틀린 단어다.

솔직한 반론

기세가 곧 보편성은 아니다. Stacklok의 2026년 설문에서 MCP를 프로덕션에서 운영하는 조직은 약 41%에 그쳤다(제한적 사용 29%, 광범위 사용 12%). 또 30%는 여전히 파일럿 단계다. 이건 강한 채택 곡선이지, 자리 잡은 표준은 아니다. 그리고 옹호자들이 건너뛰는 대목이 여기 있다. 모델의 학습 데이터에 이미 들어 있는 것이라면, CLI나 짧은 스크립트가 MCP 서버를 완승으로 이기는 경우가 많다. 모델은 git, curl, jq, 그리고 ffmpeg 플래그를 줄줄 꿰고 있다. 그걸 MCP로 감싸면, 모델이 직접 호출할 수 있는 기능을 위해 네트워크 홉과 컨텍스트 비용만 늘릴 뿐이다. MCP는 다른 데서 제 자리를 번다. 쓸 만한 CLI가 없는 SaaS 제품, 팀 단위 인증과 감사, 가드레일 뒤에 두고 싶은 데이터베이스 접근 같은 곳이다. 일에 따라 골라라. 진영을 고르지 마라.

Scavio의 자리

우리는 https://mcp.scavio.dev/mcp에서 호스팅형 MCP 서버를 운영한다(인증은 x-api-key 헤더, Google, Reddit, YouTube, Amazon, Walmart, TikTok을 아우르는 33개 도구). 이건 MCP가 실제로 이기는 경우의 구체적인 예다. "하나의 인증으로 Reddit, TikTok, Amazon을 가로질러 검색"할 만한 쓸 만한 CLI는 없으니, 도구 계층이 올바른 형태다. 과금은 크레딧 기반으로 호출당 $0.005이며, 이는 유휴 연결에는 비용이 들지 않는다는 뜻이다. 도구가 돌아갈 때 내는 것이지, 서버를 붙여 두는 데 내는 게 아니다. 이게 솔직한 제안이다. CLI가 이미 당신 일을 해낸다면, CLI를 써라.

핵심: MCP냐 CLI냐의 판단 규칙

내가 적용할 규칙은 이렇다. 그 기능이 모델이 학습으로 이미 아는 것(흔한 CLI, 문서가 잘 된 공개 명령, 표준 파일 작업)이라면, 먼저 스크립트로 손을 뻗어라. 토큰도 홉도 덜 든다. 대상이 깔끔한 CLI가 없는 SaaS나 서비스일 때, 팀 인증과 감사 로그가 필요할 때, 또는 데이터베이스 앞에 가드레일 계층을 두고 싶을 때 MCP로 손을 뻗어라. MCP는 죽었나? 아니다. 항상 답인가? 그것도 아니다. 2026년의 MCP는 진짜 틈새를 얻어내고, 최악의 결함을 고쳤으며, 모든 주요 연구소의 지지를 받은 도구다. 그건 부고 기사보다도, 과대광고보다도 훨씬 흥미로운 이야기다.