핵심 요약
LLM의 컨텍스트 윈도우는 제한된 자원이지만, MCP(Model Context Protocol)를 사용할 경우 도구 정의(Schema)가 이를 과도하게 점유하는 문제가 발생한다. Apideck의 벤치마크에 따르면 GitHub, Slack 등을 연결한 환경에서 사용자 메시지 전송 전 이미 55,000개의 토큰이 소모되었으며, 전체 200,000 토큰 중 72%가 스키마 정의에 사용되기도 했다. 이는 기존 CLI 방식보다 4배에서 32배 더 많은 토큰을 사용하는 수치로, 비용 효율성 측면에서 심각한 과제를 던져준다. Apideck은 이에 대한 대안으로 필요한 시점에만 정보를 공개하는 '점진적 공개' 방식의 CLI를 제안하며 토큰 소모를 획기적으로 줄일 수 있음을 증명했다.
배경
LLM의 토큰 및 컨텍스트 윈도우 개념, Model Context Protocol(MCP)에 대한 기본 이해
대상 독자
LLM 에이전트 및 인프라 개발자
의미 / 영향
MCP의 표준화된 연결 방식이 가진 오버헤드 문제가 공론화됨에 따라, 더 효율적인 도구 호출 프로토콜이나 최적화 기법에 대한 논의가 가속화될 것이다.
섹션별 상세
MCP 서버의 도구 정의가 컨텍스트 윈도우를 과도하게 점유하는 현상이 수치로 확인됐다. GitHub, Slack, Sentry를 포함한 설정에서 사용자 메시지가 입력되기도 전에 55,000개의 토큰이 소모되었으며, 더 넓은 범위의 테스트에서는 200,000 토큰 중 143,000 토큰이 스키마 정의에만 사용되는 결과가 나타났다.
Scalekit의 벤치마크 결과에 따르면 동일한 작업을 수행할 때 MCP는 기존 CLI 방식보다 최소 4배에서 최대 32배 더 많은 토큰을 사용한다. 이는 MCP가 모든 도구의 상세 정의를 사전에 모델에게 전달해야 하는 구조적 특성 때문에 발생하며, 대규모 API 통합 시 심각한 비효율을 초래한다.
Apideck은 이러한 오버헤드를 해결하기 위해 '점진적 공개(Progressive Disclosure)' 방식을 적용한 CLI 대안을 제시했다. 수만 개의 사전 정의 대신 80토큰 분량의 시스템 프롬프트만 사용하며, 에이전트가 필요할 때 --help 명령어를 통해 기능을 단계적으로 탐색하도록 설계하여 토큰 사용량을 획기적으로 줄였다.
실제 회계 쿼리 처리 사례에서 MCP 방식은 10,000개 이상의 토큰을 소모한 반면, Apideck의 CLI 방식은 약 400개의 토큰만으로 동일한 결과를 얻었다. 이는 MCP의 오버헤드에 대한 업계 내 논쟁에 구체적인 데이터 기반의 근거를 제공하며 최적화의 필요성을 시사한다.
실무 Takeaway
- 대규모 도구 세트를 MCP로 연결할 경우 스키마 정의만으로 컨텍스트의 70% 이상을 소모할 수 있으므로 도구 선별과 최적화가 필수적이다.
- 모든 도구 정의를 초기에 주입하는 대신 점진적 공개 전략을 채택하여 시스템 프롬프트 크기를 줄이고 API 호출 비용을 최대 25배 이상 절감할 수 있다.
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료