AI 에이전트를 외부 서비스에 연결하는 표준으로 빠르게 자리 잡은 MCP(Model Context Protocol)를 두고, 이제는 수명을 다했다는 주장이 나오고 있다. 한 개발자는 최근 하루 종일 진행된 MCP 관련 행사에 다녀온 뒤, 발표자들의 열정과는 별개로 MCP 자체에 회의를 느꼈다고 밝혔다. 그의 논지는 단순하다. MCP는 LLM이 지금만큼 똑똑하지 않던 시절에 맞춰 설계된 프로토콜이며, 모델의 능력이 그 전제를 이미 넘어섰다는 것이다. 지지든 반박이든, 이 주장은 에이전트를 실제 업무에 붙여 쓰는 국내 실무자들이 통합 전략을 재점검하게 만드는 지점이 있다.
MCP가 풀려던 문제와 그 부작용
MCP는 2024년 11월 앤트로픽이 공개했다. 당시만 해도 범용 에이전트 워크플로는 지금보다 훨씬 불안정했고, Claude Code 같은 도구도 존재하지 않았다. 그런 환경에서 모델에 외부 서비스 접근 권한을 부여하는 표준화된 방식은 분명한 생산성 향상을 가져왔고, LLM 채택 확산과 맞물려 MCP도 폭발적으로 도입됐다. 프로토콜은 이후 앤트로픽의 관리 아래 발전하다가 2025년 리눅스 재단 산하의 Agentic AI Foundation에 기증됐다.
문제는 도입이 늘면서 드러났다. 사용자들이 여러 MCP 서버를 붙이기 시작하자, 각 서버가 딸려 오는 다수의 도구와 스키마가 모델의 컨텍스트를 잠식하는 이른바 '컨텍스트 비대화(context bloat)' 현상이 나타났다. 이를 우회하려고 Composio, MintMCP, Pipedream 같은 플랫폼은 자격 증명을 한곳에 모으고 에이전트에는 최소한의 검색·실행 도구만 노출하는 방식을 제시했다. 원저자는 이런 해법이 단기적으로는 유효하다고 인정한다. 다만 그 사이에도 모델은 계속 좋아지고 있었고, 바로 그 변화가 충분히 반영되지 않았다는 것이 핵심 비판이다.
모델이 스스로 API를 다루기 시작하다
최근 모델은 코드를 직접 실행하고, 대규모 코드베이스를 추론하며, 훨씬 자율적으로 작동한다. 코딩을 위해 스크립트를 작성하고 실행하는 능력이 쌓이면서, 부수적으로 API를 직접 호출하는 일에도 능숙해졌다. 처음 보는 API를 조합해 유용한 워크플로를 만들어내는 수준에 이른 것이다. 클라우드플레어가 선보인 Code Mode는 이 흐름을 반영해, LLM이 여러 호출을 스크립트로 엮어 샌드박스에서 실행하도록 하는 접근을 택했다.
더 근본적인 변화는 에이전트가 --help 명령으로 CLI 사용법을 스스로 파악하게 됐다는 점이다. 문서화된 API나 CLI로 접근 가능한 서비스라면 별도의 MCP 서버가 없어도 된다는 의미다. 실제로 원격 서비스용 MCP 서버 상당수는 이미 존재하는 API를 감싼 래퍼에 불과하다. 원저자의 팀은 대부분의 MCP 서버를 삭제했다고 밝힌다. 터미널 접근 권한을 가진 에이전트가 그 자리를 대체하며, 오히려 더 유능한 경우가 많다는 것이다.
HTTP·CLI 표준으로의 회귀
물론 한계도 있다. CLI가 반환하는 JSON·XML 같은 기계 판독용 응답은 대체로 장황해 토큰 소모가 크다. 이에 대해 원저자는 에이전트가 HTTP API를 직접 쓰는 방식을 표준화하자고 제안한다. 클라이언트가 헤더로 자신이 에이전트임을 알리면, 서버가 HTML이나 무거운 JSON 대신 마크다운이나 텍스트로 응답을 돌려주는 식이다. 실제로 문서 사이트를 중심으로 Accept: text/markdown 헤더를 존중해 렌더링된 마크다운을 내주는 서버가 늘고 있다. 미디어 타입 자체는 이미 표준이며, 이를 에이전트용 콘텐츠 협상에 쓰는 관행이 확산되는 중이다.
여기서 한발 더 나아간 사례도 있다. 버셀의 엔지니어 말테 우블은 하니스가 선호하는 프로그래밍 언어를 Accept-Language 헤더에 담아 보내면 문서 사이트가 더 구체적인 예제를 제공할 수 있다고 제안했고, 쇼피파이의 토비 뤼트케가 이를 곧바로 쇼피파이 문서에 반영했다. 범용 프로토콜을 중심으로 표준화가 이뤄지며 인터넷이 성장해 온 역사를 떠올리면, 이미 성숙한 HTTP API·표준 콘텐츠 협상·인증 메커니즘을 재활용하자는 주장에는 설득력이 있다.
다만 이 글은 개인의 경험과 관점에 기반한 주장이라는 점을 감안할 필요가 있다. 자체 API나 CLI가 없는 사내 시스템, 세밀한 권한 통제와 감사 로그가 필요한 환경, 자격 증명을 중앙에서 관리해야 하는 조직에서는 MCP 계층이 주는 이점이 여전히 남는다. 결국 실무적 판단은 '무엇을 쓰느냐'보다 '어떤 서비스가 이미 문서화된 인터페이스를 갖추고 있는가'에 달려 있다. 잘 정의된 API와 CLI가 존재하는 영역이라면 에이전트에 터미널을 쥐여 주는 편이 더 단순하고 강력할 수 있으며, 새 통합을 설계할 때 이 선택지를 먼저 검토해 볼 만하다.