MCP Server가 Context Window를 잡아먹는다 – CLI 기반 AI Agent 인터페이스 대안 | AI Paper Digest

TL;DR Highlight

Apideck의 CLI 기반 agent 인터페이스는 MCP 툴 정의의 55,000토큰 이상 context bloat 문제를 해결하고 토큰 소비를 ~80토큰으로 감소시킨다.

Who Should Read

AI agent나 LLM 기반 자동화 시스템을 구축 중인 백엔드/풀스택 개발자 중, MCP 서버 연동 시 context window 소진 문제를 겪고 있거나 고민하는 사람.

Core Mechanics

GitHub, Slack, Sentry처럼 세 개의 MCP 서버만 연결해도 agent가 사용자 메시지를 읽기 전에 이미 55,000토큰 이상이 툴 정의로 소모된다. Claude의 200k 컨텍스트 한도에서 무려 27% 이상이 날아가는 셈이다.
MCP 툴 하나당 이름, 설명, JSON 스키마, 필드 설명, enum, 시스템 인스트럭션을 합치면 550~1,400토큰을 쓴다. SaaS 플랫폼처럼 엔드포인트가 50개 넘으면 툴 설명만으로 50,000토큰이 사라진다.
실제로 한 팀은 MCP 서버 세 개가 200,000토큰 중 143,000토큰(72%)을 잡아먹어 실제 대화, RAG 문서, 추론, 응답에 쓸 수 있는 공간이 57,000토큰밖에 남지 않았다고 보고했다.
Scalekit이 Claude Sonnet 4로 75회 동일 조건 비교 테스트를 돌린 결과, MCP는 CLI 대비 4~32배 더 많은 토큰을 소비했다. 가장 단순한 작업인 저장소 언어 확인 하나에서 CLI는 1,365토큰, MCP는 44,026토큰을 썼다. 차이의 대부분은 43개 툴 정의가 매 대화마다 주입되는 스키마 오버헤드였다.
Duet을 만든 David Zhang(@dzhng)은 OAuth와 동적 클라이언트 등록까지 다 구현했음에도 MCP 통합을 완전히 걷어냈다. 그는 이 상황을 '트릴레마'라고 불렀다: 모든 툴을 미리 로드하면 추론·히스토리 공간이 사라지고, 통합 수를 제한하면 기능이 줄고, 동적 로딩을 구현하면 레이턴시와 미들웨어 복잡도가 증가한다.
Apideck이 제안하는 해결책은 MCP 대신 CLI를 agent 인터페이스로 쓰는 것이다. agent 프롬프트를 약 80토큰짜리 셸 명령 안내로 대체하고, 세부 스키마는 `--help` 플래그로 필요할 때만 가져오는 '점진적 공개(progressive disclosure)' 방식을 쓴다. 셸 명령을 실행할 수 있는 agent라면 프로토콜 지원 없이 바로 사용 가능하다.
업계 대응 방향은 크게 세 가지로 수렴 중이다: ① MCP를 유지하되 스키마 압축·온디맨드 툴 검색으로 싸우기, ② MCP를 버리고 CLI/스크립트로 전환하기, ③ 두 방식을 혼합해 agent에게 BASH와 CLI 래퍼만 주고 MCP는 백엔드에서만 쓰기.

Evidence

MCP Core Maintainer라고 밝힌 댓글 작성자는 'context window 문제는 agent harness 문제이지 MCP 프로토콜 자체의 문제가 아니다'라고 반박했다. Claude Code나 Codex 같은 주요 harness는 이미 수개월 전부터 스마트 툴 검색을 지원해서 전체 툴 목록을 매번 전송하는 방식을 쓰지 않는다는 주장이다. MCP vs CLI 논쟁 자체가 블로그 포스트에서 포스트로 반복되는 '클리셰'가 됐다는 비판도 덧붙였다.
CLI의 보안 취약점을 지적한 의견이 있었다. CLI에서 API 시크릿을 관리할 때 환경변수는 프롬프트 인젝션 공격 한 방에 덤프될 수 있고, 크리덴셜 파일도 agent가 접근 가능하다는 문제가 있다. 반면 MCP는 서버 프로세스 안에 시크릿을 격리해서 agent가 악성화되더라도 덤프하기 어렵게 만들 수 있다는 장점이 있다고 설명했다. CLI로 동일한 보안 수준을 달성하려면 결국 MCP와 비슷한 소켓 서버 구조를 재발명하게 된다는 경험도 공유됐다.
실제로 85개 툴을 가진 MCP 서버를 만들면서 툴 매니페스트만 ~17,000토큰이 나왔다는 개발자가 경험을 공유했다. 해결책으로 툴셋을 minimal/authoring/experimental 티어로 나누고 환경변수로 제어하는 방식을 썼으며, 80%의 툴은 `_connect` 호출 전까지 '미연결' 상태로 두는 레이지 로딩 패턴을 적용해 실제 노출되는 툴 수를 줄였다.
CLI의 단점으로 '점진적 공개(progressive disclosure)'가 실제로는 레이턴시를 증가시킨다는 반론이 있었다. `--help`로 스키마를 필요할 때마다 가져오면 새 스레드마다 모델과 추가 왕복이 발생하고, CLI 사용법을 프롬프트에 직접 넣으면 결국 MCP를 임시방편으로 재발명하는 꼴이라는 지적이다. 비용 절감 vs 레이턴시 트레이드오프를 상황에 맞게 선택해야 한다는 의견이었다.
Unix 철학을 인용한 의견도 있었다. 파일과 파이프, 프로세스로 composability를 해결한 Unix처럼, AI agent도 BASH와 CLI 래퍼만 주고 MCP는 백엔드에서만 처리하는 방식이 실용적이라는 경험담이 나왔다. 실제로 소규모 비즈니스 agent를 이렇게 구축해서 잘 작동하고 있다는 사례도 공유됐다.

How to Apply

MCP 서버를 여러 개 연결했더니 context window가 자꾸 초과되는 경우, 툴 정의를 전부 미리 주입하는 대신 환경변수로 툴셋 티어(minimal/full)를 분리하거나 `_connect` 패턴으로 레이지 로딩을 구현하면 실제 노출 토큰 수를 80% 이상 줄일 수 있다.
내부 자동화 도구를 agent에 연결할 때, API를 CLI로 래핑하고 agent에게는 셸 실행 권한만 주는 방식을 검토해볼 수 있다. 세부 스키마는 `--help`로 필요할 때만 조회하게 하면 초기 컨텍스트 점유를 수만 토큰에서 수백 토큰 수준으로 낮출 수 있다. 단, 새 스레드마다 `--help` 왕복이 추가되므로 레이턴시가 중요한 서비스엔 맞지 않을 수 있다.
Claude Code나 Codex처럼 이미 툴 검색(tool search)을 내장한 harness를 쓰고 있다면, MCP를 걷어내기 전에 먼저 해당 기능을 활성화했는지 확인해보자. 전체 툴 목록을 매번 컨텍스트에 넣는 대신 필요한 툴만 동적으로 가져오는 방식이 이미 지원되고 있을 수 있다.
API 시크릿 보안이 중요한 환경에서는 CLI 전환이 오히려 위험할 수 있다. 이 경우엔 MCP 서버를 별도 프로세스로 격리하고 agent의 프로세스 트리 밖에서 시크릿을 관리하는 구조를 유지하면서, 툴 수를 줄이거나 레이지 로딩으로 토큰 소비만 최적화하는 접근이 현실적이다.

Terminology

MCP (Model Context Protocol)AI agent가 외부 툴이나 서비스를 호출할 수 있도록 Anthropic이 만든 표준 프로토콜. agent와 툴 서버 사이의 '공통 언어' 역할을 한다.

context windowLLM이 한 번에 처리할 수 있는 텍스트의 최대 길이. 이 안에 시스템 프롬프트, 대화 히스토리, 툴 정의, 검색 문서가 모두 들어가야 한다.

progressive disclosure처음에는 최소한의 정보만 보여주고, 필요할 때 `--help` 같은 명령으로 세부 정보를 추가로 가져오는 UX 패턴. 초기 로딩 비용을 줄이는 대신 추가 왕복이 생긴다.

tool searchagent harness가 전체 툴 목록을 컨텍스트에 넣는 대신, 현재 작업에 필요한 툴만 검색해서 가져오는 최적화 기법. Claude Code, Codex 등이 지원한다.

lazy loading필요한 시점에만 리소스를 로드하는 패턴. MCP에서는 툴을 처음부터 모두 등록하지 않고, 특정 명령(예: `_connect`)을 호출했을 때만 활성화하는 방식으로 적용된다.

context bloat시스템 프롬프트나 툴 정의 등 본 작업과 무관한 내용이 context window를 과도하게 차지하는 현상. 실제 추론과 대화에 쓸 수 있는 공간이 줄어든다.

MCP Server가 Context Window를 잡아먹는다 – CLI 기반 AI Agent 인터페이스 대안