AI 요약
최근 AI 에이전트 인터페이스인 MCP(Model Context Protocol)가 실제 대규모 연동 환경에서 심각한 '컨텍스트 소모' 문제를 일으키고 있다는 비판이 제기되고 있습니다. GitHub, Slack, Sentry 등 단 3개의 서비스만 연결해도 도구 정의(Schema)에만 약 55,000개의 토큰이 할당되어 Claude의 20만 토큰 제한 중 25% 이상을 메시지 시작 전에 소모하기 때문입니다. 특히 Scalekit의 벤치마크 테스트 결과, 특정 작업에서 MCP는 CLI 방식보다 압도적으로 많은 토큰을 사용하는 것으로 확인되었습니다. 이러한 효율성 저하로 인해 Duet과 같은 개발팀은 MCP 연동을 전면 철회하고 CLI 기반이나 직접 코드 실행 방식으로 선회하고 있습니다. 업계는 이제 도구 스키마를 압축하거나 동적으로 로딩하는 등의 대안 기술에 주목하고 있습니다.
핵심 인사이트
- MCP 도구 정의 하나당 이름, JSON 스키마, 시스템 지침 등으로 인해 약 550~1,400개의 토큰이 고정적으로 소모됨.
- 특정 사례에서 3개의 MCP 서버가 컨텍스트 윈도우의 72%에 달하는 143,000개의 토큰을 차지하여 추론 공간을 잠식함.
- Scalekit의 75개 비교 테스트 결과, 레포지토리 언어 확인 작업에서 CLI는 1,365토큰을 사용했으나 MCP는 44,026토큰을 소모함 (약 32배 차이).
- Duet의 빌더인 David Zhang(@dzhng)은 MCP의 컨텍스트 비효율성을 이유로 OAuth 구현 후에도 통합을 포기하고 '코드 실행' 방식으로 전환함.
주요 디테일
- 50개 이상의 엔드포인트를 가진 SaaS 플랫폼을 연결할 경우, 실제 작업 지침 없이 도구 설명만으로 50,000개 이상의 토큰이 증발함.
- 에이전트가 실제로 사용하는 도구는 한두 개에 불과함에도 불구하고, 43개 이상의 모든 도구 정의가 매 대화마다 주입되는 오버헤드가 발생함.
- 업계의 세 가지 대응 전략: MCP 스키마 압축/미들웨어 사용, 개발자 워크스페이스 내 직접 코드 실행(Duet 방식), 그리고 Apideck과 같은 CLI 인터페이스 활용.
- MCP를 유지하면서 효율을 높이려면 도구 레지스트리, 검색 로직, 캐싱 및 라우팅을 위한 복잡한 추가 인프라 구축이 필요함.
- CLI 방식은 에이전트에게 최소한의 인터페이스만 제공하고 에이전트가 필요할 때 명령어를 실행하게 함으로써 토큰 사용량을 혁신적으로 줄임.
향후 전망
- 컨텍스트 윈도우가 커지더라도 효율적인 비용 관리를 위해 정적 스키마 제공 방식보다는 '필요 시 로딩(On-demand)' 방식이 선호될 것임.
- AI 에이전트가 복잡한 API 연동을 수행할 때, 구조화된 MCP보다는 에이전트가 직접 환경을 조작하는 CLI나 코드 실행 기반의 인터페이스가 확산될 가능성이 높음.