MCP는 처음부터 나쁜 아이디어였다?

출처: Maharshi Patel 개인 블로그 (maharship.com)
원문: https://maharship.com/blog/why-mcp-was-always-a-bad-idea/
작성자: 팔복소프트-김팔복

한눈에 보기

• 개발자 Maharshi Patel이 MCP(Model Context Protocol)는 모델이 덜 똑똑하던 시절의 산물이니 이제 대부분 걷어내자는 의견 글을 올렸습니다.
• 핵심 논거는 요즘 에이전트가 스크립트를 짜고 --help로 CLI를 스스로 파악하는 수준이라, 기존 API를 감싸기만 한 MCP 서버는 불필요하다는 것입니다.
• MCP 서버를 여러 개 붙이면 도구 스키마가 컨텍스트를 잡아먹는 문제가 생겼고, 이를 해결하려는 게이트웨이·모니터링 생태계가 오히려 복잡도를 키웠다고 봅니다.
• 대안으로 Accept: text/markdown 같은 HTTP 콘텐츠 협상을 에이전트용으로 표준화하자고 제안합니다.
• 공식 발표나 벤치마크가 아닌 개인 의견 글이므로, 주장과 근거를 나눠서 읽어야 합니다.

배경

MCP는 LLM 에이전트가 외부 서비스나 데이터에 접근하도록 도구 목록과 호출 규격을 통일한 프로토콜입니다. Anthropic이 2024년 11월에 공개했고, 2025년에 Linux Foundation 산하 Agentic AI Foundation으로 이관됐습니다. 쉽게 말해 "에이전트용 USB 포트" 역할을 노린 규격인데, 이 글은 그 포트 자체가 더는 필요 없다고 주장합니다.

주요 내용

문제로 지목한 것: 컨텍스트 비대화와 그 주변 산업

MCP가 빠르게 퍼지면서 사용자들은 서버를 여러 개 연결하기 시작했고, 서버마다 딸려오는 도구와 스키마가 모델의 컨텍스트를 채워버렸습니다. 이를 줄이려고 Composio, MintMCP, Pipedream 같은 플랫폼이 자격 증명을 한곳에 모으고 에이전트에는 "검색 후 실행" 같은 최소한의 도구만 노출하는 방식을 내놓았습니다. 필자는 이런 해법이 단기적으로는 유효하다고 인정하면서도, 모니터링·스키마 관리·응답 품질 점검까지 MCP를 떠받치는 인프라가 계속 쌓이는 상황을 문제 삼습니다.

필자의 근거: 모델이 이미 API를 직접 다룬다

코딩 작업을 거치며 모델이 스크립트 작성과 실행에 능숙해졌고, 그 결과 처음 보는 API도 문서를 읽고 호출할 수 있게 됐다는 것이 필자의 판단입니다. Cloudflare가 2025년 9월 발표한 Code Mode(모델이 여러 MCP 호출을 하나의 스크립트로 묶어 샌드박스에서 실행하는 방식)도 이 흐름의 예로 듭니다. 원격 MCP 서버 대부분이 결국 기존 API를 한 번 더 감싼 것에 불과하다는 지적도 덧붙입니다.

제안: HTTP를 에이전트 친화적으로

필자는 새 프로토콜 대신 이미 성숙한 HTTP 문서, 콘텐츠 협상, 인증 체계를 쓰자고 말합니다. 예시는 두 가지입니다. 하나는 문서 사이트 등이 Accept: text/markdown 요청에 HTML 대신 마크다운을 돌려주는 방식이고, 다른 하나는 Vercel의 Malte Ubl이 제안한, 선호 프로그래밍 언어를 Accept-Language 헤더에 담아 보내는 아이디어입니다. Shopify의 Tobi Lutke가 이 제안에 호응해 Shopify 문서에서 지원하겠다고 밝혔습니다. CLI가 JSON·XML처럼 장황한 출력을 내 토큰을 많이 쓰는 문제는 필자도 한계로 인정합니다.

아래는 원문 주장을 바탕으로 편집자가 정리한 비교입니다.

팔복소프트 관점

"감싸기만 한 MCP 서버는 줄여도 된다"는 부분에는 동의합니다. GitHub처럼 gh CLI와 잘 정리된 API가 이미 있는 서비스라면, 터미널이 있는 코딩 에이전트에게 별도 MCP 서버를 붙이는 건 컨텍스트만 늘리는 경우가 많습니다. Claude Code나 Cursor 같은 도구를 쓰는 팀이라면 지금 연결된 MCP 서버 목록을 한번 점검해볼 가치가 있습니다.

다만 "MCP를 EOL하자"까지 가는 건 무리라고 봅니다. 이유는 세 가지입니다.

• 터미널이 없는 환경이 더 많습니다. 필자의 논리는 에이전트가 셸과 코드 실행 권한을 가진다는 전제 위에 서 있습니다. 사내 챗봇, 웹 기반 어시스턴트, 비개발 직군용 도구에서는 이 전제가 성립하지 않고, 이때 MCP는 여전히 가장 현실적인 연결 수단입니다.
• 보안은 오히려 반대 방향일 수 있습니다. 에이전트에게 임의 API 호출과 셸 실행을 열어주는 것보다, 허용된 도구만 노출하는 쪽이 감사(audit)와 권한 통제가 쉽습니다. 금융·공공 프로젝트처럼 보안 심사가 까다로운 국내 환경에서는 이 차이가 도입 가부를 가릅니다.
• 국내 서비스의 API 문서 사정. 필자의 대안은 "문서화가 잘 된 API"를 전제합니다. 국내 SaaS나 공공 API 중에는 문서가 PDF나 HTML 게시판 형태로만 있거나 인증 절차가 복잡한 곳이 적지 않습니다. 모델이 이런 문서를 읽고 매번 정확하게 호출하길 기대하기보다, 한 번 제대로 만든 MCP 서버가 더 안정적인 경우가 많습니다.
  Accept-Language에 프로그래밍 언어를 담자는 아이디어도 짚어둘 부분이 있습니다. 이 헤더는 원래 ko-KR 같은 자연어 선호를 전달하는 용도라, 한국어 문서를 제공하는 사이트라면 의미가 충돌할 수 있습니다. 반면 Accept: text/markdown 대응은 비용이 적고 효과가 분명하니, 기술 문서나 개발자 포털을 운영하는 팀이라면 지금 적용을 검토해볼 만합니다.

정리

이 글은 MCP의 종말 선언이라기보다, 무분별하게 늘어난 MCP 서버를 정리하라는 신호로 읽는 편이 유용합니다. 코딩 에이전트 환경에서는 CLI·API 직접 호출이 충분히 대안이 되지만, 터미널이 없거나 권한 통제가 중요한 환경에서는 MCP의 역할이 여전합니다. 당장 할 일은 두 가지입니다. 연결된 MCP 서버 중 기존 CLI로 대체 가능한 것을 추려내고, 운영하는 문서 사이트가 에이전트에게 마크다운을 돌려줄 수 있는지 확인해보는 것입니다.

• MCP
• AI 에이전트
• LLM
• API 설계
• 개발 도구