Apideck CLI: AI 에이전트를 위한 MCP의 저컨텍스트 대안

MCP의 컨텍스트 윈도우 문제

이 글은 구체적인 시나리오를 설명합니다: GitHub, Slack, Sentry를 MCP 서버(약 40개의 도구)를 통해 연결하면 에이전트가 단일 사용자 메시지를 처리하기 전에 55,000개 이상의 토큰을 소비합니다. 이는 Claude의 200k 제한의 4분의 1 이상입니다. 각 MCP 도구 정의는 이름, 설명, JSON 스키마, 필드 설명, 열거형 및 시스템 지침으로 인해 550~1,400개의 토큰이 소요됩니다.

한 팀은 3개의 MCP 서버가 200,000개 토큰 중 143,000개(컨텍스트 윈도우의 72%)를 소비하여 실제 대화, 검색된 문서, 추론 및 응답에 사용할 수 있는 토큰이 57,000개만 남았다고 보고했습니다.

Duet을 구축 중인 David Zhang(@dzhng)은 "삼중고"로 인해 MCP 통합을 완전히 제거했다고 설명했습니다: 모든 것을 미리 로드하여 작업 메모리를 잃거나, 통합을 제한하여 에이전트가 소수의 서비스와만 통신하도록 하거나, 지연 시간과 미들웨어 복잡성을 추가하는 동적 도구 로딩을 구축하는 것입니다.

벤치마크 결과

Scalekit의 벤치마크는 75회의 직접 비교(동일 모델: Claude Sonnet 4, 동일 작업, 동일 프롬프트)를 실행하여 다음과 같은 결과를 발견했습니다:

• 동일한 작업에서 MCP가 CLI보다 4배에서 32배 더 많은 토큰을 소비합니다.
• 저장소의 언어를 확인하는 작업은 CLI를 통해 1,365개의 토큰을, MCP를 통해 44,026개의 토큰을 소비했습니다.
• 오버헤드는 거의 전적으로 스키마 때문입니다: 모든 대화에 43개의 도구 정의가 주입되며, 에이전트는 이 중 하나 또는 두 개만 사용합니다.

Apideck CLI 접근 방식

Apideck CLI는 수만 개의 스키마 토큰을 대체하는 약 80개의 토큰 에이전트 프롬프트를 사용합니다. --help를 통한 점진적 공개와 바이너리에 내장된 구조적 안전성을 특징으로 합니다. 셸 명령을 실행할 수 있는 모든 에이전트는 프로토콜 지원 없이도 이를 사용할 수 있습니다.

컨텍스트 팽창에 대한 업계의 대응

이 글은 업계의 세 가지 접근 방식을 확인합니다:

• 압축 기술을 사용한 MCP: 스키마를 압축하거나, 도구 검색을 사용하여 정의를 필요할 때 로드하거나, OpenAPI 사양을 더 작은 조각으로 나누는 미들웨어를 구축합니다. 이는 작고 명확하게 정의된 상호 작용에는 효과적이지만, 도구 레지스트리, 검색 로직, 캐싱, 라우팅과 같은 인프라 요구 사항을 추가합니다.
• CLI 우선 인터페이스: Apideck CLI가 채택한 접근 방식입니다.
• 에이전트 네이티브 프로토콜: 제공된 원본 텍스트에는 언급되었지만 자세히 설명되지 않았습니다.