MCP를 연결할수록 AI가 더 강력해진다고 생각하기 쉽습니다. Linear, Notion, Slack까지 죄다 붙여놓으면 AI가 모든 걸 할 수 있을 것 같죠. 그런데 실제로는 반대 현상이 일어납니다. 연결할수록 AI가 생각할 공간이 줄어드는 겁니다.
보험 자동화 스타트업 Quandri의 엔지니어링팀이 자사 실제 스택(Linear, Notion, Slack, Postgres)에 연결된 MCP 서버들을 직접 측정한 결과를 공개했습니다. 4개 서버를 동시에 연결했을 때 도구 정의만으로 컨텍스트 윈도우의 10.5%가 사라졌습니다. GPT-4o 기준으로는 16.5%입니다.
출처: MCP is dead — Quandri Engineering
왜 MCP는 컨텍스트를 잡아먹는가
MCP 서버를 연결하면 그 서버가 제공하는 모든 도구의 정의(이름, 설명, 파라미터 스키마)가 컨텍스트에 올라옵니다. AI가 “어떤 도구를 쓸 수 있는지”를 알아야 하기 때문입니다.
Quandri 팀이 측정한 결과를 보면 규모가 실감됩니다. Linear MCP 하나만 연결해도 42개 도구 정의가 올라오면서 약 12,807 토큰을 씁니다. Notion은 14개 도구에 4,039 토큰, Slack은 12개 도구에 3,792 토큰. 4개 서버를 모두 연결하면 도구 정의만 21,077 토큰입니다.
원문은 이걸 식당 비유로 설명합니다. 자리에 앉자마자 10개의 메뉴판이 테이블을 가득 채웁니다. 실제 음식(작업 내용)을 올려놓을 공간이 줄어드는 거죠. 게다가 메뉴판은 매 대화마다 다시 펼쳐집니다.
CLI와 비교하면 차이가 더 선명합니다. Linear에서 이슈 하나를 조회하는 작업을 CLI 방식으로 하면 약 200 토큰이 드는데, MCP로 하면 12,957 토큰입니다. 65배 차이입니다. 정보를 가져오는 응답 자체는 동일한데, MCP는 사용 여부와 무관하게 42개 도구 정의를 항상 들고 있어야 합니다.
업데이트 참고: 원문이 작성된 이후, Claude Code는 도구 정의를 필요할 때만 로드하는 “Tool Search with Deferred Loading” 기능을 출시했습니다. 이 기능을 사용하면 컨텍스트 사용량이 85% 이상 줄어든다고 합니다. 아래 신뢰성·속도 문제와 아키텍처 논점은 여전히 유효합니다.
컨텍스트만의 문제가 아니다
MCP는 별도 프로세스를 띄워서 운영해야 하는 구조입니다. 여기서 신뢰성 문제가 생깁니다. 초기화 실패와 재인증 요구가 반복되고, 서버가 세션 중간에 죽는 경우도 있습니다.
속도도 구조적 한계입니다. 참조된 원조 글의 저자가 Jira MCP를 REST API와 직접 비교 측정했는데, MCP가 호출당 3배, 초기화를 포함한 첫 호출에서는 9.4배 느렸습니다. 이건 Jira만의 문제가 아닙니다. MCP는 LLM과 실제 API 사이에 프로세스 레이어를 하나 더 끼워 넣는 구조이기 때문에, 어떤 서버든 이 오버헤드는 기본으로 따라옵니다.
디버깅도 까다롭습니다. CLI나 API는 터미널에서 바로 재현할 수 있지만, MCP 오류는 대화 컨텍스트 안에서만 재현됩니다. 뭔가 잘못됐을 때 원인을 찾기가 훨씬 어렵죠.
대안: 필요할 때만 꺼내는 Skills 패턴
Quandri 팀이 제안하는 대안은 “Skills 패턴”입니다. MCP가 연결하자마자 모든 메뉴판을 펼치는 방식이라면, Skills는 필요한 책만 꺼내달라고 사서에게 요청하는 방식입니다.
작동 방식은 이렇습니다.
- CLI 명령어와 API 정보를 담은 짧은 지침 파일(Skill)을 만들어 둡니다
- 특정 작업이 필요할 때만 해당 Skill을 컨텍스트에 불러옵니다
- LLM은 이미 CLI 문법을 학습으로 알고 있으므로 별도 도구 정의 없이 명령을 실행합니다
Linear 이슈 조회를 예로 들면, API 주소와 인증 방식, curl 명령어 패턴 몇 줄로 Skill을 만들어두면 됩니다. 이 Skill을 호출할 때만 컨텍스트에 올라오고, 그 크기는 MCP의 1/60 수준입니다.
CLI-우선 전략이 함께 작동합니다. LLM은 이미 man 페이지와 StackOverflow에서 학습했기 때문에 gh, psql, aws 같은 표준 CLI 도구는 별도 정의 없이도 잘 씁니다. 이미 설치돼 있고, 사람과 AI가 동일한 인터페이스를 쓰며, 파이프라인으로 자유롭게 조합할 수 있습니다.
MCP가 여전히 유효한 경우
Quandri 팀은 MCP를 완전히 버리지는 않았습니다. 세 가지 상황에서는 MCP가 명확한 장점을 갖습니다.
CLI가 없는 서비스는 MCP가 사실상 유일한 연결 방법입니다. 프로덕션 데이터베이스처럼 쿼리 안전성이 중요한 곳에서도 MCP가 낫습니다. MCP 서버는 서버 레벨에서 읽기 전용 모드를 강제하거나 위험한 쿼리를 차단할 수 있는데, CLI 방식으로는 LLM이 DROP TABLE을 실행하는 걸 막을 방법이 없습니다. 팀 전체가 공통 인증으로 접근해야 하는 환경에서도 MCP의 중앙화된 자격 증명 관리가 유리합니다.
Quandri 팀이 실제로 쓰는 방식도 이런 판단을 반영합니다. gh, psql, aws처럼 기존에 쓰던 CLI 도구는 그대로 씁니다. 커밋 초안 작성이나 PR 리뷰 같은 반복 워크플로는 Skills로 묶어뒀습니다. Slack, Linear, Notion처럼 CLI가 약하거나 팀 단위 권한 관리가 필요한 서비스만 MCP를 씁니다.
MCP 지원이 마케팅 문구가 된 지금
요즘 SaaS 랜딩 페이지에는 거의 다 “MCP 지원”이 들어갑니다. 서버가 얼마나 안정적인지, 컨텍스트를 얼마나 잡아먹는지는 중요하지 않습니다. 체크박스를 채우는 게 목적이죠. 과거의 “AI 탑재”나 “블록체인 기반” 같은 마케팅 패턴과 같습니다.
Quandri 팀의 결론은 간결합니다. “연결을 늘리는 것보다, 잘 가르치는 게 낫다.” MCP 서버를 Skills와 CLI로 교체하면서 21K 토큰의 컨텍스트를 확보하고, 초기화 실패를 일상에서 없앴으며, 디버깅을 터미널로 되돌렸습니다.
도구를 연결하는 방식보다 AI에게 무엇을, 어떻게 알려주는지가 더 큰 차이를 만든다는 이야기입니다.
참고자료: MCP is dead. Long live the CLI — ejholmes.github.io
답글 남기기