MCP는 애초부터 나쁜 생각이었나?

• MCP는 모델 성능이 낮던 시기에는 필요했지만, 이제는 대부분 수명을 다했음

  • MCP는 에이전트가 외부 서비스와 데이터 소스에 연결하도록 돕는 프로토콜로 2024년 11월 공개됐음

    • 당시에는 Claude Code도 없었고, 범용 에이전트 워크플로도 지금보다 훨씬 불안정했음

  • 외부 서비스 접근이 새로운 생산성을 제공하면서 LLM 보급과 함께 MCP 채택도 급증함

  • Anthropic이 발전시키던 MCP는 2025년 Linux Foundation 산하 Agentic AI Foundation에 기증됐음

• MCP 서버가 늘어나면서 도구 스키마가 모델의 컨텍스트를 과도하게 차지하기 시작함

  • 서버마다 여러 도구와 개별 스키마가 포함돼 컨텍스트가 비대해졌음

  • Composio, MintMCP, Pipedream 등은 여러 서비스의 자격 증명을 한곳에서 관리하고, 검색·실행용 최소 도구만 에이전트에 제공하는 방식으로 이 문제를 완화함

    • 단기적으로는 유용하지만, MCP 서버의 응답 품질과 접근성, 스키마, 적절한 도구 호출 시점까지 관리하는 별도 시스템이 필요해졌음

• 모델의 코드 실행 능력이 향상되면서 MCP가 맡던 역할을 직접 수행할 수 있게 됨

  • 최신 모델은 컴퓨터에서 코드를 실행하고 대규모 코드베이스를 추론하며 이전보다 자율적으로 작업 가능함

  • 스크립트를 작성해 처음 보는 API를 호출하고 여러 서비스를 조합한 워크플로를 최소한의 사용자 개입으로 실행할 수 있음

  • 모델은 --help로 CLI 사용법을 파악할 수 있어, 문서화된 API나 CLI를 제공하는 서비스에는 MCP 서버가 필요하지 않은 경우가 많음

    • 원격 서비스용 MCP 서버 대부분은 결국 기존 API를 감싼 형태임

• 터미널에 접근할 수 있는 에이전트라면 대부분의 MCP 서버를 없애고 HTTP API와 CLI로 대체할 수 있음

  • CLI의 JSON·XML 응답은 장황해 토큰을 많이 소비할 수 있지만, 문서화된 HTTP API와 표준 콘텐츠 협상, 성숙한 인증 체계라는 대안이 이미 존재함

    • 에이전트가 자신을 식별하는 헤더를 보내면 서버가 HTML이나 장황한 JSON 대신 Markdown 또는 텍스트를 반환하도록 사용 방식을 표준화할 수 있음

• Accept: text/markdown을 활용한 에이전트 친화적 콘텐츠 정의가 확산 중임

  • 문서 사이트처럼 텍스트가 많은 일부 서버는 이 헤더를 받으면 일반 HTML 대신 렌더링된 Markdown을 반환함

    • text/markdown 미디어 타입은 이미 표준화돼 있으며, 에이전트용 응답 형식으로 활용하는 사례가 늘고 있음

• 선호 프로그래밍 언어를 헤더로 전달하면 문서가 더 적합한 예제를 제공할 수 있음

  • 클라이언트가 선호 언어를 Accept-Language 헤더에 넣자는 제안은 Python처럼 특정 언어의 SDK 문서를 일반 예제보다 우선 제공하려는 방식임

    • 이 방식을 지지한 Shopify는 자사 문서에 지원을 도입했음

• 새 전용 프로토콜을 계속 확장하기보다 기존의 공통 프로토콜을 활용해야 함

  • 인터넷은 공통 프로토콜을 표준화하며 성장했음

  • 이제 에이전트는 스크립트를 작성하고 필요한 응답 형식을 직접 요청할 수 있으므로, 필요한 인터페이스가 이미 있는 곳에서는 MCP를 단계적으로 종료하고 HTTP API와 CLI에 직접 연결하는 편이 나음

^{source https://maharship.com/blog/why-mcp-was-always-a-bad-idea/}

HN에서는 MCP가 쓸모를 다했다는 주장보다, 터미널을 자유롭게 쓰는 개인 개발자의 경험을 모든 에이전트 환경에 일반화한 점을 더 큰 문제로 봤다. 최신 모델이 API 문서를 읽고 CLI나 curl을 다룰 수 있다는 데는 대체로 동의했지만, 그 능력만으로 MCP의 역할까지 사라지지는 않는다는 판단이다.

쟁점의 중심은 모델의 성능보다 접근 통제다. 기업과 팀에서는 에이전트에 API 키나 셸 권한을 그대로 넘기기 어렵다. 접속 가능한 서비스와 작업 범위를 제한하고, 인증 정보를 감추며, 사용 기록과 권한 회수를 관리해야 한다. 내부 API보다 좁고 안전한 기능만 내주거나 민감 정보를 걸러 내는 중간 계층으로 MCP를 쓴다는 경험도 나왔다. 터미널이 없는 웹 기반 에이전트나 비개발자용 플러그인에서는 도구 검색과 인증을 한데 묶는 장점도 있다.

비판도 구체적이다. 도구 정의가 늘면 컨텍스트와 토큰을 많이 쓰고, 큰 요청이나 복잡한 상태에서는 안정성이 떨어질 수 있다. 이미 잘 만든 CLI가 있다면 필요한 도움말만 단계적으로 읽히는 편이 더 가볍고 범용적이라는 평가가 있었다. 직접 API 호출도 강력한 대안이다. 다만 문서와 매개변수를 매번 다시 파악하는 비용, 셸 인자 처리 오류, 최신 기능을 찾아내는 문제는 남는다.

개인 자동화에는 CLI나 직접 API 호출이 단순할 수 있다. 여러 사용자와 실행 환경에서 권한·인증·감사를 일관되게 관리해야 한다면 MCP가 여전히 실용적이다.