MCP는 처음부터 나쁜 아이디어였을까요?

AI 요약

이 글은 Model Context Protocol(MCP)이 LLM과 외부 서비스·데이터를 연결하는 문제를 해결했지만, 모델이 빠르게 발전한 지금까지 계속 유지할 필요는 없다고 주장합니다. 글쓴이는 MCP를 둘러싼 발표와 생태계 자체를 부정하지는 않지만, 현재의 에이전트가 과거보다 훨씬 자율적으로 코드를 작성하고 API를 호출하는 상황에서 MCP가 오히려 불필요한 중간 계층이 됐다고 봅니다.

■ MCP가 등장한 배경

MCP는 Anthropic이 2024년 11월 공개한 프로토콜입니다. 당시 목적은 에이전트가 외부 서비스와 데이터 소스에 연결하도록 돕는 것이었습니다. 지금과 비교하면 당시 모델은 상대적으로 원시적이었고 Claude Code도 아직 나오지 않았습니다. 범용 에이전트 워크플로도 안정성이 낮았습니다. 외부 서비스에 접근할 수 있게 하자 사용자가 체감하는 생산성이 크게 높아졌고, MCP 채택은 경제 전반의 LLM 확산과 함께 빠르게 늘었습니다.

MCP는 Anthropic이 관리하며 발전하다가 2025년 Linux Foundation 산하 Agentic AI Foundation에 기부됐습니다. 글쓴이는 이 과정을 MCP의 실용성이 증명된 역사로 보면서도, 초기 모델을 기준으로 설계한 연결 방식이 모델의 능력 향상을 따라가지 못했다고 설명합니다.

■ MCP 서버가 만든 컨텍스트 부하

사용자가 설정에 MCP 서버를 여러 개 추가하면서 문제가 드러났습니다. 서버마다 여러 도구가 포함되고, 도구마다 별도의 스키마가 붙습니다. 에이전트는 호출 가능한 도구와 각 입력 형식을 모두 컨텍스트에서 다뤄야 하므로, 서버 수가 늘수록 컨텍스트가 비대해집니다.

Harness 개발자들은 이 문제를 줄이기 위해 여러 우회 방식을 만들었습니다. Composio, MintMCP, Pipedream 같은 플랫폼은 여러 외부 서비스의 인증 정보를 한곳에 보관하고, 에이전트에는 적은 수의 도구만 보여줍니다. 에이전트가 일반적인 검색·실행 도구를 호출하면 플랫폼이 실제 서비스와 연결합니다. 이렇게 하면 각 MCP 서버의 도구와 스키마를 모두 컨텍스트에 넣지 않아도 됩니다. 글쓴이는 이 방식을 단기적으로는 좋은 해결책이라고 인정합니다.

다만 그 과정에서 MCP 서버를 감시하고, 응답 품질을 확인하고, 에이전트가 도구에 쉽게 접근하도록 만들고, 스키마를 해석하고, 특정 시점에 어떤 도구를 제공할지 판단하는 별도 시스템이 늘어났습니다. 글쓴이는 모델이 좋아지고 있다는 사실을 고려하면, MCP를 유지하기 위해 주변에 복잡한 보조 장치를 계속 쌓는 방식이 방향을 잘못 잡았다고 말합니다.

■ 직접 코드와 API를 호출하는 모델

최근 모델은 컴퓨터에서 코드를 실행하고, 큰 코드베이스를 분석하고, 사용자의 개입을 최소화한 채 작업을 진행합니다. 코딩 과정에서 스크립트를 작성하고 실행하는 능력이 좋아지면서, 문서에 나온 API를 직접 호출하는 능력도 함께 향상됐습니다. 모델은 이전에 보지 못한 API를 대상으로도 필요한 스크립트를 만들고, 여러 서비스를 조합해 하나의 워크플로를 구성할 수 있습니다.

Cloudflare는 이런 흐름을 Code Mode로 구현했습니다. Code Mode는 모델이 여러 MCP 호출을 하나의 스크립트로 조합한 뒤 샌드박스에서 실행하도록 합니다. 글쓴이는 MCP를 더 잘 사용하는 방식으로 소개된 이 기능조차 MCP 서버를 직접 나열하는 방식보다 모델의 코드 작성 능력에 기대고 있다고 봅니다.

모델은 CLI의 --help 명령을 읽고 사용법을 찾는 일도 익혔습니다. 따라서 문서화된 API나 CLI가 있는 서비스라면, 에이전트가 해당 서비스 전용 MCP 서버 없이도 접근할 수 있습니다. 글에 따르면 원격 서비스용 MCP 서버 상당수는 이미 존재하는 API를 감싼 래퍼에 가깝습니다.

■ 제안하는 대안

글쓴이가 제시하는 방법은 대부분의 MCP 서버를 삭제하는 것입니다. 터미널 접근 권한이 있는 에이전트는 많은 MCP 서버를 대신할 수 있고, 경우에 따라 더 유연하게 작업합니다. 다만 CLI가 JSON이나 XML 같은 기계 판독용 결과를 반환하면 출력이 지나치게 길어지고 토큰을 많이 소비하는 문제가 남습니다. 글에서는 이 문제를 해결할 방법이 이미 있다고만 설명합니다.

대안으로는 문서화된 HTTP API, 표준 콘텐츠 협상, 성숙한 인증 체계를 활용하자고 합니다. 에이전트가 HTTP API를 직접 사용하는 규칙도 정리해야 합니다. 예를 들어 클라이언트가 요청 헤더로 자신이 에이전트임을 알리면, 서버가 HTML이나 장황한 JSON 대신 Markdown 또는 일반 텍스트를 응답하도록 만들 수 있습니다.

실제 사례로는 Accept: text/markdown 헤더가 제시됩니다. 문서 사이트처럼 텍스트 중심인 서버 가운데 일부는 이 헤더를 받으면 일반적인 HTML 대신 렌더링된 Markdown을 반환합니다. 글에서는 이 미디어 타입이 표준화되어 있고, 에이전트용 콘텐츠 협상에도 점점 쓰인다고 설명합니다.

문서에 Accept-Language 헤더를 활용하는 사례도 소개합니다. Vercel 엔지니어는 Harness가 클라이언트가 선호하는 프로그래밍 언어를 요청에 포함하자고 제안했습니다. 문서 사이트가 Python 같은 선호 언어를 확인하면 일반적인 예제 대신 해당 언어의 SDK 예제를 우선 제공할 수 있습니다. Shopify의 Tobi Lütke가 이 제안을 긍정적으로 받아들였고, Shopify 문서에도 적용됐다고 합니다.

■ MCP 이후의 방향

글쓴이는 공통 프로토콜을 표준화한 방식이 오늘날의 인터넷을 키웠다고 말합니다. 현재 에이전트는 스크립트를 작성하고, 필요한 데이터를 구체적으로 요청하며, 기존 API와 CLI를 직접 사용할 정도로 발전했습니다. 따라서 MCP를 계속 확장하기보다 필요한 인터페이스가 이미 존재하는 곳에서는 HTTP API와 CLI를 직접 사용하고, 에이전트가 읽기 좋은 응답 형식과 요청 규칙을 표준화하자는 주장입니다.

■ Hacker News 반응

• @tobyhinloopen — 무엇이든 출력 내용을 캡처하고 LLM이 나중에 그 내용을 질의하게 만드는 도구 래퍼를 만들었습니다. 토큰을 아끼려고 출력을 “영리하게” 잘라냅니다. 기본적으로 Node의 util.inspect와 비슷하게 동작하고, 잘린 내용을 LLM이 확장해서 볼 수 있게 합니다. capture some-cli처럼 호출하면 CLI 출력을 캡처하고, 일부 결과와 계속 질의할 수 있는 핸들을 함께 출력합니다. 이렇게 하면 도구가 엄청난 양의 내용을 반환하는 위험을 해결합니다.
• @layer8 — 출력을 캡처하고 LLM이 나중에 질의하게 만든다는 건, 다르게 부르면 ‘파일’ 아닌가요?
• @dezgeg — 대부분의 Harness가 bash 명령에 이미 그렇게 하지 않나요?
• @skyyr — 저는 이 문제 때문에 headroom-ai를 사용해 보고 있습니다. 이 프로젝트는 다른 영리한 방법으로도 토큰을 줄입니다. 살펴본 적이 있나요?
• @honoluluxyz — CLI 모드만 사용하자고 제안하려면 모델에게 인증 정보를 숨기는 해결책도 제시해야 합니다. 셸 접근 권한이 없는 에이전트 문제를 해결하는 방법도 필요합니다.

원문: Maharship / 번역·요약: Trawling