MCP는 죽었나? — 개발자가 실제로 알아야 할 핵심 정리

MCP는 죽었나? — 개발자가 실제로 알아야 할 핵심 정리

MCP(Model Context Protocol)는 2024년 말 출시 이후 "AI 생태계의 USB-C"로 불리며 화제를 모았습니다. 그러나 실제 개발 워크플로에서 써본 개발자들 사이에서는 뜨거운 논쟁이 벌어지고 있습니다. "MCP는 비용이 너무 크다", "CLI가 더 효율적이다", " Skills가 대안이다" — 다양한 목소리가 있습니다.구경시 죽었는지, 아니면 오히려진화하고 있는 것인지. 개발자 관점에서 데이터를 통해 정리해 봅니다.

MCP가 비판받는 세 가지 핵심 문제

MCP에 대한 비판은 크게 세 축으로 집약됩니다. 실제 측정 데이터와 함께 살펴보겠습니다.

문제 1: 컨텍스트 창을 크게 소모한다

MCP 서버를 연결하면 실제 작업 내용 아니라 도구 정의만으로도 상당한 컨텍스트를 차지합니다.Quandri 환경에서 실제 도구 정의를 추출해 측정한 결과는 다음과 같습니다.

MCP 서버	도구 수	크기(문자)	토큰 추정
Linear	42개	51,229자	12,807토큰
Notion	14개	16,156자	4,039토큰
Slack	12개	15,168자	3,792토큰
Postgres	9개	1,755자	438토큰
전체	77개	84,308자	약 21,077토큰

단 4개 서버만 연결해도 도구 정의만으로 Claude 200K 컨텍스트의 10.5% 를 차지합니다. 특히 Linear 단독으로도 42개 도구 정의가 항상 로드되어 약 12,800토큰 이상을 소비합니다. 실제로는 get_issue와 save_issue 단 두 개만 쓰는 경우에도 전체 정의가 함께 실려 있습니다.

문제 2: 성능과 운영 안정성 부담

MCP는 별도 서버 프로세스를 시작하고 유지해야 하기 때문에 여러 운영 문제가 발생합니다.

• 초기화 실패와 반복 인증 문제 — 프로세스 시작 시 인증 실패가 종종 발생합니다

• 응답 속도 저하 — 도구 호출마다 외부 서버 왕복이 필요해 AI 응답이 느려집니다

• 세션 중 도구 사라짐 — MCP 서버 프로세스가 충돌하면 세션 중간에 사용하던 도구가 사라질 수 있습니다

• 권한 가시성 낮음 — 각 도구가 실제로 어떤 권한을 갖는지 불분명합니다

Jira MCP 벤치마크에서는 REST API 직접 호출 대비 MCP가 호출당 3배 느렸고, 초기화를 포함한 첫 호출은 9.4배 느렸습니다. 이 성능 차이는 Jira에만 한정되지 않습니다. LLM과 기본 API 사이에 MCP 서버라는 프로세스 계층이 추가되는 구조적 문제입니다.

문제 3: 기존 CLI/API와 중복된다

항목	CLI/API	MCP
사람과 AI가 같은 명령 사용	가능	불가능
파이프, jq, grep 조합	자유롭게 가능	서버 반환 형식에 묶임
터미널에서 재현·디버깅	즉시 가능	대화 컨텍스트 안에서만 가능
man page로 사용법 학습	이미 가능	별도 도구 정의 필요
설치·설정	대부분 이미 설치됨	서버 설정·인증·프로세스 관리 추가 필요

Linear 이슈를 조회할 때 MCP 방식은 CLI 방식보다 약 65배 많은 토큰을 소비합니다.

# CLI 방식: 약 200토큰curl 명령 프롬프트: 약 50토큰응답: 약 150토큰# MCP 방식: 약 12,957토큰항상 로드되는 Linear 도구 정의 42개: 약 12,807토큰도구 호출과 응답: 약 150토큰

대안: CLI 우선 전략과 Skills

MCP 비판론자들이 제시하는 대안은 명확합니다. CLI → API → 문서 순서로 제공하는 방식이 더 가볍고 직접적입니다.

LLM은 이미 man page와 StackOverflow를 통해 CLI 사용법을 학습했기 때문에 별도 도구 정의를 항상 싣지 않아도 됩니다. 기존 CLI를 직접 사용하면 도구 정의로 컨텍스트를 낭비하지 않고, 사람과 AI가 같은 인터페이스를 사용하므로 디버깅이 쉽습니다.

MCP가 "식탁에 모든 메뉴를 미리 펼쳐놓는" 방식이라면, Skills는 "필요한 책만 사서에게 요청하는" 방식에 가깝습니다.

> Skills란? 도구 호출 시에만 로드되고, 사용 중일 때만 컨텍스트를 차지하는 경량 설정 방식입니다. CLI 사용 지침을 Skills 안에 넣는 것이 핵심입니다.

# Linear Skill 예시# Linear Issue Lookup Skill# - Linear API: https://api.linear.app/graphql# - Auth: Bearer Token ($LINEAR_TOKEN env var)# - Get issue: curl 명령 + GraphQL 쿼리# - Results are JSON, parse with jq

이 방식에서는 LLM이 해당 스킬을 호출할 때만 위 내용을 컨텍스트에 로드합니다. 42개 Linear 도구 정의를 항상 들고 다니지 않고, 필요한 CLI 명령만 로드하면 됩니다.

Claude Code의 대응: 지연 도구 로딩

MCP 비판에 대한 Anthropic의 답변은 빠르게 왔습니다. Claude Code에는 측정 이후 Tool Search with Deferred Loading이 도입되어 MCP 도구 스키마를 필요할 때만 로드하고 컨텍스트 사용량을 85%이상 줄였습니다.

이는 맥락을 미리 싣는 대신 도구 이름만 넣어두고, 실제 호출 시 스키마를 로드하는 방식입니다. 2025년 11월에 도입된 이 기능으로 현재 Claude Code에서는 컨텍스트 팽창 문제가 상당 부분 완화되었습니다.

MCP가 여전히 유효한 경우

다만, 모든 상황에서 MCP가 CLI보다 나쁜 것은 아닙니다. 다음 상황에서는 MCP가 여전히 가치를 갖습니다.

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

서비스에 CLI가 없다면 MCP가 유일한 연결 방식일 수 있습니다. 특히 외부 API도 없이 MCP 서버만 제공하는 서비스들이 늘어나고 있어, 에이전트가 해당 서비스에 접근하려면 MCP가 필요합니다.

비개발자 사용자를 고려할 때

터미널을 쓰지 않는 비개발자 사용자에게는 MCP가 더 접근하기 쉬운 방식일 수 있습니다. 별도 CLI 설치나 터미널 사용 없이도 AI가 도구를 활용할 수 있기 때문입니다.

실시간 양방향 통신이 필요할 때

단순 요청-응답을 넘어서는 실시간 양방향 통신에서는 MCP가 적합합니다. SSE나 WebSocket 같은 메커니즘을 활용한 확장된 통신이 가능하기 때문입니다.

데이터베이스 접근에서의 선택 기준

환경	권장 방식	이유
로컬 개발 / 개인 DB	Skills + CLI	가볍고 빠르며 실수에서 복구하기 쉬움
프로덕션 DB / 공유 팀 환경	MCP	서버 레벨의 쿼리 검증과 접근 제어 같은 안전장치가 중요

데이터베이스에서는 MCP의 장점도 분명합니다. MCP 서버가 읽기 전용 모드를 강제하고 위험한 쿼리를 서버 레벨에서 차단할 수 있으며, 자격 증명이 프롬프트에 노출되지 않는다는 점이 있습니다.

2026년 MCP 로드맵: 죽지 않고 진화 중

"MCP가 죽었다"는 논의와 별개로, MCP는 실제로 급속하게 성장하고 있습니다. 2026년 공식 로드맵에서 확인되는 현재 상황은 다음과 같습니다.

생태계 현황 (2026년)

• Glama 레지스트리에 등록된 MCP 서버: 19,831개 이상

• 월간 SDK 다운로드: 9,700만 회

• 주요 지원사: Anthropic, OpenAI, Google, Microsoft

2026년 네 가지 우선순위 영역

1. 전송 계층 진화와 확장성

Streamable HTTP는 MCP 서버를 로컬 프로세스가 아닌 원격 서비스로 실행할 수 있게 했지만, 확장성 문제들이 표면화되고 있습니다. 상태 저장 세션이 로드 밸런서와 충돌하고, 수평 확장에 워크어라운드가 필요하며, 레지스트리가 라이브 연결 없이 서버 기능을 알 방법이 없습니다. 2026년 핵심 과제는 세션을 유지하지 않고 수평 확장할 수 있는 전송 및 세션 모델 진화와, .well-known을 통해 서버 기능을 발견할 수 있는 메타데이터 형식 표준화입니다.

2. 에이전트 간 통신

Tasks 기본 요소(SEP-1686)가 실험적 기능으로 출하되어 설계된 목적에 잘 작동하고 있습니다. 다만 초기 프로덕션 사용에서 수명주기 격차를 발견했습니다. 일시적 실패 시 재시도 의미론과 완료 후 결과 보존 기간에 대한 만료 정책이 바로 그것입니다.

3. 거버넌스 성숙

현재 모든 SEP은 분야와 무관하게 전체 핵심 유지관리자 검토가 필요합니다. 이는 병목 현상입니다. 기여자 래더 문서화와 신뢰할 수 있는 작업 그룹이 자체 영역에서 SEP을 수락할 수 있는 위임 모델이 도입될 예정입니다.

4. 기업 준비도

기업들이 MCP를 배포하면서 감사 추적, SSO 통합 인증, 게이트웨이 동작, 구성 이식성 등의 예측 가능한 문제에 직면하고 있습니다. 이 영역은 네 가지 중 가장 정의되지 않았지만 의도적인 것입니다. 기업 인프라에서 이러한 도전을 경험하는 사람들이 작업을 정의하는 데 참여할 것으로 기대됩니다.

실무 적용: Quandri의 선택

Quandri는 서비스 유형에 따라 세 가지 방식을 함께 사용합니다.

매일 쓰는 도구에는 Bash + CLI — gh, psql, aws처럼 매일 쓰는 도구에는 Bash + CLI를 사용합니다. 컨텍스트 비용이 없고 유연성이 높으며 터미널에서 바로 디버깅할 수 있습니다.

반복적 다단계 워크플로에는 Skills — 커밋 작성과 PR 리뷰처럼 반복적인 다단계 워크플로에는 Skills를 사용합니다. 호출될 때만 로드되므로 효율적입니다.

CLI가 없거나 팀 단위 권한 제어가 필요한 경우에만 MCP — Slack, Linear, Notion처럼 강력한 CLI가 없는 서비스에는 MCP를 사용합니다. 프로덕션 데이터베이스 접근처럼 팀 단위 인증이나 권한 범위 지정이 중요한 경우에도 MCP가 적합합니다.

핵심은 명확합니다. 모든 것을 연결하는 것보다 잘 가르치는 것이 더 중요합니다.

정리: MCP는 선택지이지 만능이 아니다

MCP에 대한 논쟁은 기술적 우위지쟁이기보다 적용 맥락의 문제입니다.

MCP가 과도한 경우:

• CLI나 API가 이미 존재하는 도구를 연결할 때

• 컨텍스트 비용이 걱정되는 소규모 작업에서

• 빠른 재현과 디버깅이 중요한 개발 초기 단계에서

MCP가 적합한 경우:

• CLI 없는 SaaS 서비스에 접근해야 할 때

• 팀 단위 권한 제어와 감사 추적이 필요한 프로덕션 환경에서

• 비개발자 사용자가 AI와 도구를 연결할 때

2026년 MCP 생태계는 19,831개 이상의 서버와 9,700만 월간 SDK 다운로드를 기록하며 계속 성장하고 있습니다. 전송 확장성, 에이전트 통신, 거버넌스, 기업 준비도 등의 영역에서 활발히 진화하고 있습니다.

Dead라고 하기엔 너무 이르고, 만능이라고 하기엔 너무 많은 것이 MCP입니다. 개발자라면 자신의 워크플로에 맞는 도구를 선택하는 것이 가장 현명한 자세가 될 것입니다.

---

📚 출처

• https://news.hada.io/topic?id=30028