MCP 논란 완벽 정리: 실측 데이터로 검증한 3가지 한계와 반론

Q: Skills 패턴은 어떻게 구현하나요?

Claude Code 기준으로는 .claude/ 폴더 아래 마크다운 파일로 CLI 사용법과 API 엔드포인트를 정리해두면 됩니다. 에이전트가 해당 도구가 필요할 때 그 파일만 로드하는 방식이에요. MCP 서버 설정 없이 텍스트 파일만으로 구현됩니다. 직군별 실전 활용 방법은 직군별 AI 도구 선택 가이드에서도 확인하실 수 있어요.

MCP가 정말 죽었을까요? Quandri 엔지니어링의 실측 데이터로 검증한 MCP의 3가지 핵심 한계와, 이 주장의 빈틈까지 냉정하게 짚어봅니다.

MCP 컨텍스트가 컨텍스트 창의 10.5%를 먹는다고? 실측 데이터로 따져봅니다

안녕하세요! Claude Code나 Cursor에 MCP 서버를 여러 개 붙여서 쓰다가 응답이 갑자기 엉뚱해진 적 있으셨나요? 저는 Linear, Notion, Slack 세 개만 연결해도 뭔가 느려지는 것 같아서 “혹시 컨텍스트 문제인가?” 의심하고 있었거든요. 그러던 중 GeekNews에서 Quandri 엔지니어링의 「MCP is Dead」라는 글이 올라왔는데, 실제 측정 데이터가 담겨 있어서 정신이 번쩍 들었습니다. 😮

GeekNews 댓글에서도 “프로토콜로서 MCP는 죽지 않았다”, “CLI 없는 조직엔 필수” 같은 반론이 바로 올라왔거든요. 그래서 직접 원문을 끝까지 읽고, 주장의 근거와 빈틈을 모두 정리해봤습니다.

1. MCP 컨텍스트 비용: 실측 데이터로 본 진짜 숫자

Quandri 엔지니어링의 Chloe Kim은 자사 스택에서 실제로 로드된 MCP 서버의 도구 정의를 직접 추출해 측정했습니다. 가장 충격적인 결과는 이겁니다. Linear, Notion, Slack, Postgres 4개 서버만 연결해도 도구 정의만으로 컨텍스트 창의 10.5%가 사라진다는 것이에요.

MCP 서버	도구 수	토큰 수
Linear	42개	~12,807토큰
Notion	14개	~4,039토큰
Slack	12개	~3,792토큰
Postgres	9개	~438토큰
합계	77개	~21,077토큰

① Claude vs GPT-4o — 모델별 컨텍스트 점유율 차이

Claude 200K 컨텍스트에서는 10.5%지만, GPT-4o의 128K 컨텍스트에서는 동일한 도구 정의가 16.5%를 차지합니다. 컨텍스트가 작을수록 피해가 커지는 구조예요. 그리고 여기서 핵심이 있어요. 이 10.5%는 지금 당장 쓸 도구만 로드된 게 아닙니다. Linear에 연결하는 순간 42개 도구 정의 전체가 항상 로드됩니다. 실제로 get_issue와 save_issue만 쓰는 세션에서도요.

💡 실제 활용 시나리오 예시:
Claude Code에서 Linear 이슈 하나만 조회하는 단순 작업을 하는데, 연결된 MCP 서버 때문에 이미 21,000토큰이 소비된 상태입니다. 200K 토큰짜리 긴 코드베이스 리뷰 작업을 같이 하면 실제 코드 분석에 쓸 수 있는 공간이 그만큼 줄어드는 셈이에요.

2. 운영 신뢰성 문제: 초기화 실패와 속도 저하

MCP는 별도 서버 프로세스를 띄워서 유지해야 합니다. 이 구조 자체가 여러 장애 포인트를 만들어요. 초기화 실패, 반복되는 재인증 요구, 세션 도중 서버 충돌로 도구가 갑자기 사라지는 문제 등이 실제로 발생합니다.

① Jira MCP 벤치마크 — REST API 직접 호출 대비 속도

원문에서 인용한 별도 벤치마크에 따르면, MCP는 REST API 직접 호출 대비 호출당 3배 느리고, 초기화 포함 첫 호출은 9.4배 느립니다. 이 차이는 Jira에만 국한된 게 아니에요. LLM과 실제 API 사이에 MCP 서버라는 프로세스 계층이 하나 더 끼어드는 구조적 문제라서, Linear·Notion·Slack 모두 동일한 오버헤드를 갖습니다.

💡 실제 활용 시나리오 예시:
팀 스프린트 중 AI 에이전트가 Linear에서 이슈 10개를 순차 조회하는 작업을 실행할 때, MCP 방식은 REST 직접 호출 대비 최소 3배 이상 시간이 걸립니다. 에이전트가 반복 루프를 돌리는 자동화 시나리오일수록 이 지연이 누적돼 체감이 커집니다.

3. CLI/API와의 중복: 65배 토큰 차이의 의미

같은 Linear 이슈를 조회할 때 MCP 방식과 CLI 방식의 토큰 소비량을 비교하면 차이가 극명합니다. CLI 방식은 약 200토큰, MCP 방식은 약 12,957토큰 — 무려 65배 차이입니다.

# CLI 방식 (~200토큰)
curl -s -H "Authorization: Bearer $LINEAR_TOKEN"   -H "Content-Type: application/json"   -d '{"query":"{ issue(id: "ISSUE-ID") { title state { name } } }"}'   https://api.linear.app/graphql

# MCP 방식 (~12,957토큰)
# 42개 도구 정의 자동 로드: ~12,807토큰
# 실제 호출+응답: ~150토큰

② CLI의 구조적 장점 — 사람과 AI가 같은 인터페이스 사용

CLI/API는 사람과 LLM이 동일한 명령어를 씁니다. 터미널에서 바로 재현하고 디버깅할 수 있고, jq·grep·파이프로 자유롭게 조합할 수 있어요. 반면 MCP는 대화 컨텍스트 안에서만 재현 가능해서 디버깅이 훨씬 어렵습니다. 게다가 LLM은 이미 수많은 man page와 StackOverflow를 통해 CLI 사용법을 학습했기 때문에, 별도 도구 정의 없이도 CLI를 잘 씁니다.

💡 실제 활용 시나리오 예시:
AI 에이전트가 Slack 메시지를 검색하다 에러가 발생했을 때, CLI 방식이면 같은 curl 명령을 터미널에서 그대로 실행해 즉시 확인할 수 있습니다. MCP 방식에서는 서버 프로세스 로그를 따로 확인해야 해서 디버깅 사이클이 훨씬 길어집니다.

4. Quandri의 대안: Skills 패턴이란 무엇인가

Quandri는 MCP 서버를 걷어내고 기존 CLI를 Skills로 감싸는 방식으로 전환했습니다. Skills는 “필요한 도구를 필요할 때만 로드”하는 경량 패턴이에요. MCP가 “식당에 앉자마자 메뉴판 전체를 테이블에 펼쳐놓는” 방식이라면, Skills는 “먹고 싶은 메뉴 이름을 말하면 그 레시피만 가져오는” 방식입니다.

① Linear Skill 예시 — 필요한 정보만 담은 최소 정의

# Linear Issue Lookup Skill
- Linear API: https://api.linear.app/graphql
- Auth: Bearer Token ($LINEAR_TOKEN env var)
- Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN"     -d '{"query":"{ issue(id: "ISSUE-ID") { title state { name } } }"}'     https://api.linear.app/graphql
- Results are JSON, parse with jq

이 Skill이 호출될 때만 위 내용이 컨텍스트에 로드됩니다. 필요한 CLI 명령어 몇 줄만 그때그때 올라오는 구조예요. Quandri는 이 전환으로 약 21K 토큰을 확보했고, 초기화 실패 문제도 사라졌다고 밝혔습니다.

💡 실제 활용 시나리오 예시:
PR 리뷰 자동화 워크플로에서 Linear·GitHub·Slack을 모두 쓰더라도, 각 도구의 Skill은 해당 단계에서만 로드됩니다. 전체 세션 동안 21K 토큰이 고정 점유되는 MCP 대비 훨씬 많은 코드와 diff를 컨텍스트에 담을 수 있어요.

5. 반론 정리: 이 주장의 빈틈은 어디인가

GeekNews와 Hacker News 커뮤니티에서는 이 글에 대한 반론도 상당히 올라왔습니다. 저도 동의하는 부분이 있어서 솔직하게 정리해볼게요.

① “Deferred Loading으로 컨텍스트 문제는 이미 해결됐다”

원문 자체에서도 언급하듯, Claude Code에는 이미 Tool Search with Deferred Loading이 도입됐습니다. MCP 도구 스키마를 필요할 때만 로드하고 컨텍스트 사용량을 85% 이상 줄이는 기능이에요. 즉, 글의 가장 핵심 근거인 “21K 토큰 낭비”는 최신 Claude Code에서는 그대로 적용되지 않습니다. 성능·디버깅·아키텍처 문제는 여전히 남아 있지만, 컨텍스트 비용 문제는 상당 부분 완화됐어요.

💡 포인트:
이 글은 Deferred Loading 이전 측정 기반입니다. Claude Code 사용자라면 컨텍스트 비용은 낮아졌지만, 속도와 디버깅 문제는 여전히 체크해볼 가치가 있어요.

② “구현 품질이 문제, 프로토콜이 문제가 아니다”

커뮤니티에서 가장 많이 나온 지적입니다. 42개 도구를 덕지덕지 붙인 Linear MCP 서버가 비효율적인 것이지, MCP 프로토콜 자체의 설계 문제가 아닐 수 있다는 거예요. “MCP는 죽었나?”보다 더 정확한 질문은 “현재 시판 중인 MCP 서버들이 잘 만들어졌나?”일 수 있습니다.

💡 포인트:
프로토콜 자체는 살아있고, 문제는 현재 구현체들의 품질에 가깝습니다. 잘 설계된 경량 MCP 서버라면 이야기가 달라질 수 있어요.

6. 그래도 MCP가 맞는 경우

원문도 인정하듯 MCP가 여전히 유효한 상황이 있습니다. 이걸 명확히 알면 “무조건 MCP 걷어내야 해”가 아니라 상황에 맞는 선택을 할 수 있어요.

1) CLI가 없는 서비스에 연결할 때

일부 SaaS 서비스는 공식 CLI가 없습니다. 이 경우 MCP 서버가 인증과 연결을 대신 처리해주는 실질적 가치를 가집니다.

💡 실제 활용 시나리오 예시:
CLI가 없는 고객 데이터 플랫폼(CDP)을 AI 에이전트와 연결할 때, MCP 서버가 인증 토큰 갱신과 API 호출을 캡슐화해줘서 에이전트 구현이 단순해집니다.

2) 프로덕션 DB + 팀 권한 제어가 필요할 때

Skills + CLI 방식은 연결 문자열이 프롬프트에 노출될 수 있고 위험한 쿼리를 막기 어렵습니다. MCP 서버는 읽기 전용 강제, 서버 레벨 쿼리 검증, 팀 단위 접근 제어를 제공할 수 있어요. 로컬 개발에는 Skills + CLI, 프로덕션 DB 공유 환경에는 MCP가 더 안전합니다.

💡 실제 활용 시나리오 예시:
여러 팀원이 동일한 AI 에이전트로 프로덕션 DB를 조회하는 환경에서, MCP 서버가 읽기 전용 접근과 민감 테이블 블라인드 처리를 중앙에서 관리합니다.

Claude Code나 Cursor에 MCP 서버를 3개 이상 연결해서 쓰고 있는 개발자
AI 에이전트 응답이 왜 갑자기 엉뚱해지는지 원인을 파악하고 싶은 분
팀 AI 도구 스택을 설계 중인 엔지니어링 리드
MCP vs CLI vs Skills 중 무엇을 써야 할지 판단 기준이 필요한 분
“MCP는 죽었다”는 주장을 냉정하게 검증하고 싶은 기술 독자

8. 자주 묻는 질문 (FAQ)

Q. 최신 Claude Code에서도 MCP 컨텍스트 문제가 심각한가요?

A. Deferred Loading 도입 이후 컨텍스트 사용량이 85% 이상 줄었습니다. 원문의 21K 토큰 문제는 상당 부분 완화된 상태예요. 다만 속도 오버헤드(첫 호출 9.4배)와 디버깅 어려움은 여전히 존재합니다. Claude Code 사용자라면 컨텍스트보다 속도와 안정성 측면에서 MCP를 재평가해보세요.

Q. Skills 패턴은 어떻게 구현하나요?

A. Claude Code 기준으로는 .claude/ 폴더 아래 마크다운 파일로 CLI 사용법과 API 엔드포인트를 정리해두면 됩니다. 에이전트가 해당 도구가 필요할 때 그 파일만 로드하는 방식이에요. MCP 서버 설정 없이 텍스트 파일만으로 구현됩니다. 직군별 실전 활용 방법은 직군별 AI 도구 선택 가이드에서도 확인하실 수 있어요.

Q. 지금 쓰는 MCP 서버를 당장 걷어내야 할까요?

A. 무조건 제거할 필요는 없습니다. 하루에 한 번도 안 쓰는 MCP 서버가 연결돼 있다면 정리할 가치가 있어요. CLI가 있는 서비스(GitHub, Linear, Slack)는 Skills로 전환을 고려하고, CLI가 없거나 팀 권한 제어가 필요한 서비스는 MCP를 유지하는 게 합리적입니다.

✍️ 글을 마치며

「MCP is Dead」는 단순한 클릭베이트 제목이 아니었습니다. 실제 측정 데이터와 구체적인 대안을 갖춘 엔지니어링 포스트였어요. 다만 “죽었다”는 결론보다는 “현재 MCP 서버들이 너무 과도하게 설계됐고, 더 가벼운 대안이 있다”는 주장으로 읽는 게 더 정확합니다.

저는 당장 하루에 한 번도 안 쓰는 MCP 서버부터 끊고, Linear는 Skills로 전환해볼 생각이에요. 21K 토큰이 비워지면 코드베이스를 얼마나 더 올릴 수 있는지 직접 확인해보고 싶거든요. 😊

여러분은 어떤 부분이 가장 인상적이셨나요? 댓글로 자유롭게 의견 남겨주세요!