최근 AI 에이전트 아키텍처에서 가장 논쟁적인 주제는 외부 도구 호출(Tool Calling) 방식의 표준화다. 앤스로픽(Anthropic)이 주도하는 모델 컨텍스트 프로토콜(MCP)이 업계 표준으로 자리 잡는 듯했으나, 프로덕션 환경의 실측 데이터는 벤치마크 상에서 전혀 다른 양상을 보여준다. dev_to에 공개된 최신 지표에 따르면, 단순한 리포지토리 쿼리 작업에서 CLI는 1,365토큰을 소모한 반면, MCP는 44,026토큰을 소모하며 무려 32배(32x)의 토큰 오버헤드를 발생시켰다. 신뢰성(Reliability) 지표 역시 CLI가 100%를 달성할 때 MCP는 72% 수준에 머물렀다. 이는 단순한 추론 오차(rounding error)가 아닌, 시스템의 근본적인 비용-성능 구조(Cost-Performance Structure)의 결함을 시사한다.
이러한 토큰 낭비의 근본 원인은 MCP의 JSON-RPC 전송 계층과 장황한 스키마 정의(Schema Definitions)에 있다. 더 심각한 것은 보안성 유지보수에 따른 레이턴시(Latency) 페널티다. n8n 워크플로우 보안 분석 사례에서 드러났듯, 기본 MCP 환경은 도구 정의 변조(Tool Poisoning)에 취약하여 MCPTox 벤치마크 기준 72.8%의 오염 성공률과 CVE-2025-6514(CVSS 9.6)와 같은 치명적인 원격 코드 실행(RCE) 취약점을 노출했다. 이를 방어하기 위해 MCPS(MCP Secure) 규격이 등장하여 HMAC-SHA256 암호학적 서명, 툴 정의 피닝(Pinning), 논스(Nonce) 기반 리플레이 방어 등의 계층을 추가했다. 하지만 이는 직렬화/역직렬화 과정의 연산 복잡도를 급증시키며, 실제 서빙 환경에서 P99 지연 시간의 치명적인 병목(Bottleneck)으로 작용하게 된다.
아키텍처 관점에서 신뢰 경계(Trust Boundary)의 위상수학적(Topological) 구조를 독립적으로 분석해보면 MCP의 한계는 더욱 명확해진다. '에이전트 → JSON-RPC → 서버 → 샌드박스 정책 → 시스템'으로 이어지는 MCP 환경과 '에이전트 → bash → rbash/gVisor 샌드박스 → 시스템'으로 이어지는 CLI 격리 환경은 통계적으로 동일한 보안 격리 수준을 제공한다. AWS STS나 Docker 컨텍스트 스위칭 등 수십 년간 검증된 OS 레벨의 멀티 테넌트 인증(Multi-Tenant Auth) 인프라를 두고, 굳이 애플리케이션 계층에서 무거운 프로토콜을 재발명할 이유가 없다. 또한 CLI의 --help 호출은 에이전트에게 런타임에 필요한 만큼만 컨텍스트를 주입(Context Burn 최소화)하는 반면, MCP는 초기 도구 로딩 시 수만 토큰의 페이로드를 강제하여 LLM의 제한된 컨텍스트 윈도우 활용도를 심각하게 훼손한다.
결과적으로 상관관계와 인과관계를 분리하여 엄밀히 평가할 때, MCP는 도구 통합 인프라를 직접 구축하기 꺼리는 팀을 위한 '사전 패키징된 샌드박스 편의 계층(Convenience Layer)'에 불과하다. 토큰당 비용 효율성과 에이전트 라우팅 속도에 민감한 데이터 중심의 엔지니어링 조직이라면, 프로덕션 서빙 시 MCP의 사용을 비판적으로 재고해야 한다. 에이전트 시스템의 환각(Hallucination)을 줄이고 E2E 신뢰성을 100%에 가깝게 끌어올리며 폭발적인 API 비용(TCO)을 통제하려면, 결정론적(Deterministic)으로 동작하는 네이티브 CLI 래퍼(Wrapper)와 OS 수준의 컨테이너 격리를 결합하는 것이 수치상 압도적으로 우월한 최적화 전략이다.