MCP가 쇠퇴하고 있는 이유: 모델 컨텍스트 프로토콜에 대한 비판적 검토

TL;DR – MCP는 점점 더 덜 중요해지고 있다

Model Context Protocol (MCP)는 2024년 11월에 출시되었지만, 오늘날의 대규모 언어 모델은 직접 API나 명령줄 도구를 탐색하고 호출할 수 있기 때문에 점점 더 불필요해지고 있다. 이로 인해 MCP 서버가 유발하는 컨텍스트 과잉과 운영 부담이 사라지고 있다.

MCP의 원초적 약속

MCP는 Anthropic가 에이전트가 외부 서비스에 접근할 수 있도록 통합된 JSON-RPC 인터페이스를 제공하기 위해 개발했다. 초기 모델들은 자연어 의도를 구체적인 도구 호출로 변환하기 위한 얇은 추상화 계층이 필요했고, 터미널 접근이 없는 에이전트에게 플러그 앤 플레이 솔루션으로 빠르게 인기를 끌었다.

"MCP는 2024년 11월 Anthropic 팀에 의해 출시되었으며, 에이전트가 외부 서비스와 데이터 소스에 연결하는 데 도움을 주는 프로토콜로 설계되었다"【1】.

프로토콜이 무너지기 시작한 이유

점점 커지는 도구 세트로 인한 컨텍스트 과잉

각 MCP 서버는 여러 도구를 포함하며, 각 도구마다 고유한 스키마를 가진다. 에이전트가 여러 서버를 로드할 경우, 합쳐진 스키마가 모델의 컨텍스트 창을 초과하게 되어 개발자들이 도구를 줄이거나 프록시해야만 한다.

"각 서버는 여러 도구를 포함하며, 각 도구마다 고유한 스키마를 가지고 있었고, 이는 모든 모델의 컨텍스트를 과부하시키기 시작했다"【1】.

더 나은 모델은 직접 코드를 생성하고 실행할 수 있다

현대의 에이전트(Claude Code, Meta Muse, OpenClaw 등)는 스크립트를 작성하고, 다중 서비스 워크플로우를 구성하며, 본 적 없는 API를 호출할 수 있다. Cloudflare의 Code Mode는 LLM이 사전 격리된 환경에서 실행 가능한 스크립트로 다양한 호출을 조합하도록 하여 MCP 서버에 의존하지 않도록 하는 이 변화를 보여준다【1】.

"LLM이 이 정도로 발전했기 때문에 Cloudflare는 Code Mode를 출시했는데, 이는 LLM이 다양한 호출을 스크립트로 조합하여 사전 격리된 환경에서 실행할 수 있도록 하는 MCP를 더 나은 방식으로 사용하는 방법이다"【1】.

`--help`를 통한 직접 CLI 탐색

에이전트는 이제 명령줄 도구의 --help 출력을 사용하여 인수를 추론하여 별도의 탐색 계층이 필요 없게 되었다.

"LLM은 --help 명령을 사용하여 CLI를 탐색하는 방법을 이해했기 때문에, 많은 서비스에 접근하기 위해 더 이상 MCP 서버가 필요하지 않다"【1】.

커뮤니티의 반론

거버넌스, 인증, 감사 가능성

몇몇 댓글러들은 MCP가 자격 증명 처리, 권한 경계, 감사 로그를 제공하는 통제된 게이트웨이 역할을 한다고 주장한다. 이는 순수한 API나 CLI 접근에서는 부족한 기능이다.

"MCP는 에이전트가 접근할 수 있는 외부 서비스를 정확히 통제하고, API 키를 노출하지 않고 인증을 처리하며, 강력한 감사 로깅을 제공하는 데 도움이 된다" – @simonw.

기업 수준의 도구 및 플러그인 스토어

기업 사용자는 ChatGPT/Claude 마켓플레이스에서 일클릭으로 설치 가능한 MCP 플러그인에 의존하며, 이는 인증과 UI 통합을 포함한다.

"MCP는 ChatGPT와 Claude 앱 내부에 플러그인 스토어가 있기 때문에 성공하고 있다. 이 플러그인들은 일클릭 설치 가능한 MCP 서버이며, 인증을 지원한다" – @whazor.

원격 제어 시나리오

에이전트가 공개 API가 없는 UI 전용 애플리케이션이나 장치와 상호작용해야 할 때, MCP 서버는 소켓 수준의 명령 프로토콜을 노출할 수 있다.

"UI 애플리케이션(예: 게임 엔진 에디터)을 원격으로 제어해야 할 경우, MCP 서버는 여전히 큰 의미를 갖는다. 그렇지 않으면 어떤 '접근 지점'도 없기 때문이다" – @flohofwoe.

MCP보다 직접 HTTP 또는 CLI가 더 좋은 경우

무상태이고 잘 문서화된 REST 엔드포인트 – 에이전트는 Accept: text/markdown 헤더(또는 유사한 것)를 첨부하여 추가 스키마 없이 간결하고 에이전트 친화적인 응답을 받을 수 있다.
대규모 JSON 페이로드 – jq 또는 curl과 크기 제한을 함께 사용하면 에이전트가 데이터를 반복적으로 필터링할 수 있으며, MCP 응답으로 인한 토큰 폭발을 피할 수 있다.
보안 중심 환경 – 중앙 집중식 인증 및 권한 시스템은 API 게이트웨이에 직접 구현할 수 있어 추가적인 MCP 계층이 필요 없게 된다.

"에이전트가 직접 HTTP API를 사용하는 방식을 표준화하기 시작해야 한다. 예를 들어, 에이전트 클라이언트는 자신을 에이전트로 식별하기 위해 헤더를 첨부할 수 있고, 서버는 자동으로 Markdown 또는 텍스트 형식으로 응답 데이터를 전송할 수 있다" – 저자.

등장하는 실용적 사례들

Accept-Markdown 헤더 – 문서 사이트는 이제 Accept: text/markdown을 존중하여 HTML 대신 렌더링된 Markdown을 제공함으로써 토큰 수를 줄인다.
Accept-Language를 통한 SDK 선택 – Vercel과 Shopify는 언어 선호도를 사용하여 언어별 SDK 예제를 제공하여 에이전트에게 더 관련성 있는 정보를 제공한다.

앞으로의 길 – 이분법이 아닌 선택

커뮤니티의 합의는 세밀하다:

고유한 가치를 제공하는 곳에서는 MCP를 유지하라 – 통제된 자격 증명 처리, 레거시 UI 자동화, 기업용 플러그인 생태계.
간단하고 무상태 서비스에는 MCP를 단계적으로 폐기하라 – 직접 HTTP 호출이나 --help로 탐색 가능한 CLI 도구로 대체하라.
에이전트 친화적인 HTTP 표준화 – User-Agent: agent/1.0과 같은 헤더와 콘텐츠 협상 형식을 도입하여 API를 MCP 도구만큼 LLM이 사용하기 쉽게 만들라.

결론

MCP는 초기 LLM을 위한 실용적인 다리였지만, 모델 능력의 급속한 향상, 코드 생성 도구의 부상, MCP 서버 유지 관리의 부담이 비용-편익 균형을 바꾸었다. 조직은 MCP가 진정한 문제를 해결하는지(예: 보안적인 자격 증명 중개, 원격 UI 제어)를 평가한 후에만 이를 채택해야 하며, 그렇지 않으면 더 단순하고 성능이 뛰어나며 컨텍스트 과잉이 덜 발생하는 직접 HTTP 또는 CLI 접근 방식을 채택해야 한다.