MCP의 월간 SDK 다운로드 수가 9,700만 건에 도달했습니다. 블로그 포스트는 어디에나 넘쳐나고, GitHub 스타 수도 계속해서 올라가고 있습니다. 하지만 제가 프로덕션 (Production) 환경과 유사한 곳에서 MCP 서버를 실행하려고 했을 때, 저는 계속해서 똑같은 벽에 부딪혔습니다. 바로 실패 모드 (Failure mode)에 대한 문서가 아무도 작성하지 않았다는 점입니다.

두 팀에 걸쳐 세 번의 서로 다른 MCP 배포를 진행한 6개월이 지난 지금, 저는 증거를 가지고 있습니다. 제가 실제로 배운 것들은 다음과 같습니다.

약속 vs 현실

MCP — 모델 컨텍스트 프로토콜 (Model Context Protocol) — 은 스스로를 "AI의 USB-C"라고 정의합니다. 플러그인 방식이며, 표준화되어 있고, 보편적입니다. 그리고 로컬 개발 (Local development) 환경에서는 대부분 그 약속을 이행합니다. 서버를 연결하고 클라이언트를 그곳으로 지정하면 도구들이 작동하기 시작합니다.

하지만 프로덕션 (Production)은 이야기가 다릅니다.

2026년 MCP 로드맵 (2026년 3월 발표)은 이 점에 대해 솔직합니다. 올해의 핵심 초점은 정확히 MCP를 프로덕션에서 사용하기 고통스럽게 만드는 요소들인 전송 확장성 (Transport scalability), 엔터프라이즈 준비성 (Enterprise readiness), 거버넌스 (Governance)에 맞춰져 있습니다. 그 로드맵은 일종의 고백입니다. 팀은 2025년에 출시된 것들이 프로덕션 수준으로 강화되지 않았음을 인정하고 있습니다.

실무에서 이것이 의미하는 바는 다음과 같습니다:

부하 상황에서 무상태성 (Statelessness)이 무너집니다. MCP의 기존 HTTP 전송 (Transport) 방식은 요청-응답 (Request-response)의 단순함을 위해 설계되었습니다. 하지만 프로덕션 에이전트 (Agent) 워크로드는 장시간 실행되며, 다단계적이고, 상태 유지 (Stateful)적입니다. 에이전트가 단일 세션 동안 6개의 MCP 서버에 걸쳐 40번의 도구 호출 (Tool calls)을 수행하면, 단일 요청 테스트에서는 나타나지 않았던 컨텍스트 파편화 (Context fragmentation) 현상이 나타나기 시작합니다.

서버 디스커버리 (Server discovery) 문제가 해결되지 않았습니다. 개발 단계에서는 http://localhost:3000을 하드코딩하거나 로컬 파일 경로를 지정하면 됩니다. 하지만 프로덕션에서는 디스커버리가 필요합니다. 어떤 서버가 존재하는지, 어떤 서버가 건강한 상태인지, 현재 작업에 필요한 도구를 가진 서버가 무엇인지 알아야 합니다. 생태계에는 몇 가지 접근 방식이 있지만 표준은 없습니다. 직접 구현하거나 누군가의 주관적인 프레임워크를 선택해야 하는 상황입니다.

**2026년 출시 후보 (Release candidate, 2026년 5월)**는 이 문제 중 일부를 다루었습니다 — 무상태 코어 (Stateless core), HTTP 확장성 (Scalability), 서버 렌더링 확장 기능 (Server-rendered extensions) 등입니다. 이는 올바른 방향입니다. 하지만 현재 시중에 나와 있는 대부분의 MCP 서버는 이를 위해 구축되지 않았습니다.

아무도 문서화하지 않는 세 가지 실패 모드 (Failure Modes)

스테이징 (Staging) 환경에서 MCP를 실행하고 몇 주 동안 로그를 관찰한 결과, 세 가지 실패 패턴이 반복적으로 나타났습니다.

1. 타임아웃 연쇄 반응 (Timeout Cascades)

MCP 서버가 예상보다 오래 걸릴 때 (데이터베이스 쿼리, 느린 API, 콜드 스타트 (Cold Start) 등), 에이전트 (Agent)는 대기합니다. 대부분의 클라이언트 구현체는 보통 30~60초 정도의 엄격한 타임아웃 (Hard Timeout)을 가집니다. 하지만 에이전트는 타임아웃 시간이 종료될 때까지 자신이 타임아웃되고 있다는 사실을 알지 못합니다. 결국 작업은 절반만 실행된 상태로 남게 되고, 깔끔한 재시도 (Retry) 경로도 확보할 수 없게 됩니다.

제가 찾아낸 해결책은 모든 서버 호출에 서킷 브레이커 (Circuit Breaker) 래퍼 (Wrapper)를 적용하는 것이었습니다. 만약 서버가 3회 연속 요청을 놓치면, 해당 서버를 성능 저하 (Degraded) 상태로 표시하고 폴백 (Fallback) 경로로 라우팅합니다. 화려한 방법은 아니지만, 연쇄적인 장애 (Cascade Failures)를 막아줍니다.

import time
from typing import Callable, TypeVar, Optional

...

2. 도구 스키마 드리프트 (Tool Schema Drift)

MCP 서버는 JSON 스키마 (JSON Schemas)를 통해 도구 (Tools)를 노출합니다. 이러한 스키마는 계속 진화합니다. 1월에 테스트했던 서버가 3월에는 도구 이름, 파라미터 (Parameters), 또는 반환 형태 (Return Shapes)를 변경했을 수도 있습니다. 그러면 에이전트는

2026년 5월 출시 후보(Release Candidate, RC) 버전은 이러한 문제 중 일부를 직접적으로 해결합니다. 상태 비저장 코어(Stateless core)는 세션 어피니티(Session affinity) 없는 수평적 확장(Horizontal scaling)을 의미합니다. HTTP 확장(HTTP extensions)은 더욱 조합 가능한 전송 계층(Transport layer)을 제공합니다. 규제 산업에 종사하고 있다면 엔터프라이즈 거버넌스 기능(감사 로그(Audit logs), 서버 서명(Server signing))이 중요합니다.

만약 당신이 2026년 중반에 새롭게 시작한다면, 6개월 전의 저보다 더 나은 위치에 있을 것입니다. 2025년 안정화 버전(Stable release)이 아닌 2026년 RC 버전을 기반으로 구축하세요.

하지만 진짜 교훈은 아키텍처에 있습니다: MCP 서버를 '실행 후 망각(Fire-and-forget)' 방식으로 취급하지 마세요. MCP 서버도 다른 프로덕션 서비스와 마찬가지로 관측성(Observability), 회복력 패턴(Resilience patterns), 그리고 생명주기 관리(Lifecycle management)가 필요합니다. 프로토콜은 베팅할 만큼 충분히 성숙했습니다. 운영 측면의 성숙도는 아직 따라가는 중입니다.

6개월 전의 나에게 해주고 싶은 말

첫날부터 "범용 MCP 서버"라는 꿈을 쫓지 마세요. 잘 테스트된 서버 하나로 시작하여, 회로 차단기(Circuit breakers)와 모니터링을 먼저 구축한 다음 확장하세요. MCP 생태계는 빠르게 움직이고 있지만, 프로덕션의 신뢰성은 다운로드되는 것이 아니라 쌓아가는 것입니다.

9,700만 건의 다운로드는 실재합니다. 하지만 프로덕션 플레이북은 여전히 작성되고 있습니다. 이는 기회일 수도 있고, 제품을 출시하기 전 세부 사항을 얼마나 주의 깊게 읽느냐에 따라 함정이 될 수도 있습니다.