대부분의 ‘생산 준비 완료’ MCP 서버는 실제로는 아니다

출처: Dev.to

Disclosure: 나는 SUPER-MCP, 오픈소스 MCP 서버의 개발자이다. 이 글에 제시된 기준은 SUPER-MCP의 기능 집합이 아니라 위협 모델에서 파생되었다. SUPER-MCP 자체에 이 체크리스트를 적용하면 대부분 항목은 충족하지만 모든 항목을 충족하지는 않는다: 플러그인 OS 격리는 카테고리 2(릴리즈 블로킹 오픈 항목으로 추적됨) 상태이며, 작업 기록 암호화는 문서화된 간극이다.

MCP 생태계는 라벨링 문제가 있다.
GitHub를 오늘 검색하면 수십 개의 MCP 서버 부트스트랩이 “생산 준비”라는 자랑스러운 스탬프를 달고 있음을 알 수 있다. 일부는 깔끔한 README와 실제 별점 수를 가지고 있다. 몇 개는 Docker 설정 파일과 JWT 지원을 제공한다. Anthropic의 자체 스티어링 그룹이 유지하는 MCP 공식 참고 서버들은 이 차이를 명확히 언급하고 있다. 그들의 저장소 README는 이러한 서버들이 교육용 예시이며, 생산 준비 솔루션이 아니라고 명시하고 있으며, 개발자는自身 보안 요구 사항을 평가해야 한다고 설명한다. 그 외의 커뮤니티 저장소들은 그렇지 않다는 점을 몰랐었다.

“Production-ready” 라벨은 거의 의미가 없어졌다. MCP 맥락에서 이 라벨이 암시하는 것과 실제로 제공하는 것 사이의 간극은 사용자에게 실질적인 피해를 초래할 수 있다. 본 문서는 이 간극의 보안 차원을 집중적으로 다루며, 운영, 성능, 안정성은 동등하게 중요하지만 별개의 주제이다.

MCP 서버의 진정한 생산 준비를 10분 안에 평가하는 방법은 다음과 같다. 대부분 신호는 문서, 시작 동작, README 구조에서 확인할 수 있으며, 일부는 간단한 소스 검토가 필요하다(아래 참고).

위협 모델은 규모에서 시작된다.
MCP는 특수한 실험이 아니다. 2026년 초 현재 프로토콜은 월 9700만 SDK 다운로드와 81,000개 이상의 GitHub 별점을 기록했으며, Anthropic, OpenAI, Google, Microsoft, AWS 등 모든 주요 AI 벤더가 지원을 제공한다. 2025년 12월, Anthropic는 MCP를 Linux Foundation의 에이전틱 AI 포럼에 기증해 공식적인 거버넌스 하에 벤더 중립적 표준으로 확고히 했다. 2026년 7월에 출시될 후보 버전은 프로토콜 런칭 이후 가장 큰 수정이자, 첫 번째 클래스 Tasks 지원, 무상태 HTTP 코어, OAuth 2.0과 OpenID Connect에 근접한 인증 강화를 추가한다. 이는 프로토콜이 사라지는 것이 아니라, 에코시스템 내 모든 벤더가 채택하는 보다 넓은 지원을 가지고 있다.

그 맥락이 뒤에 오는 내용을 이해하는 데 중요하다. 이 글에서 설명된 보안 간극은 MCP 자체를 반대하는 논쟁이 아니라, MCP의 규모와 궤적에 비례해 생산 강화를 진지하게 취해야 함을 강조한다.

일반적인 API 서버가 프로덕션에서 실패하면 가동 중단이나 오류가 발생한다. MCP 서버가 프로덕션에서 실패하면 다른 의미가 있다: AI 에이전트가 도구에 접근하면서 사용자 nor 본인이 의도한 방식과 다르게 행동한다.

위협 모델은 근본적으로 다르며, 2025~2026년 연구는 이제 그 규모에서 확인되었다.

2026년 3월 NYIT researchers는 MCP 구현체에 대한 체계적 위협 모델링(arXiv:2603.22489)을 발표하고, STRIDE와 DREAD 프레임워크를 일곱 주요 MCP 클라이언트에 적용했다. 결과: 도구 중독 — 도구 메타데이터 안에 악의적인 지시를 삽입하는 — 가 가장 흔하고 영향력 있는 클라이언트 사이드 취약점이며, 대부분의 클라이언트가 정적 검증 부족으로 인해 실패했다.

이와 별도로 MCPTox 연구(arXiv:2508.14925)는 45개의 실제 MCP 서버를 실제 LLM과 테스트하여 보다 강력한 모델이 도구 수준 공격에 더 취약할 수 있음을 발견했다. 더 큰 모델과 추론 활성화 설정을 사용한 경우, 여러 테스트 조건에서 공격 성공률이 높아졌다 — 우수한 인struction 수행 능력은 모델을 악의적인 메타데이터에 순종하게 만들 뿐, 이를 막는 데 더 강하지 않다. 기업 배포에 대한 의미: 서버를 강화하는 것이 모델이 누락된 것을 포착할 것이라고 가정하는 것보다 중요하다.

그 후 2026년 4월 OX Security는 Anthropic의 공식 MCP SDK(파이썬, 타입스크립트, 자바, 루스트) 전체에 내장된 아키텍처적 결함을 공개했다. 이 결함은 사용자 제어 구성 값을 직접 sanitization 없이 셸 실행에 전달함으로써 원격 코드 실행을 가능하게 한다. 10건의 고위험·중요도 CVE가 발생했으며, 1억5천만 개 이상의 패키지 다운로드가 영향을 받았다. 네 가지 distinct한 공격 경로가 존재했다. VS Code, Cursor, Windsurf, Claude Code, Gemini-CLI 등 영향을 받은 환경이 포함되었다.

Anthropic은 프로토콜 수준에서의 근본적인 패치를 거부했으며, 이는 SDK가 실행에 대해 무관심한 설계 철학을 유지해야 한다고 주장한다. 이 참조 구현을 신뢰한 모든 하위 프레임워크는 해당 결함을 그대로 물려받았다.

같은 연구는 배포 계층에서 별도의 발견도 surfaced했다: 11개 MCP 마켓플레이스 중 9개가 검증 게이트 없이 proof-of-concept 악성 패키지를 받아들였다. 이는 SDK 아키텍처 결함 자체와 구별되는 거버넌스 격차로, 코드 취약점이 아니라 패키지가 유통에 들어가는 시점에 검증 도구 부재라는 생태계 전체 문제다.

이러한 결과는 더 이상 학술 및 벤더 연구에만 국한되지 않는다. 2026년 5월 NSA 인공지능 보안 센터(AI Security Center)는 MCP 보안 전용 사이버보안 정보 시트(CSI U/OO/6030316-26)를 발표했다 — MCP 배포 위험을 다루는 첫 번째 공식 미국 정부 지침이다. 이는 도구 실행 격리, 모든 도구 출력을 신뢰하지 않고 다운스트림에 전달하기 전에 필터링, 그리고 정의된 스키마에 대한 파라미터 검증을 명시적으로 권고한다.

OWASP는 MCP Top 10 프로젝트를 발표해 MCP 배포에서 가장 위험한 취약점 카테고리를 cataloging했으며, 여기에는 도구 중독, 충분치 않은 입력 검증, 부적절한 출력 필터링 등이 포함된다.

일부에서는 프로토콜 수준 책임이 구현자에게 있어야 한다고 주장하며, 이는 SQL 주입 방어가 데이터베이스 엔진이 아니라 개발자 책임과 동일하다고 비유한다. 반론은, 그리고 본 문서가 채택한 관점은 프로토콜 기본값이 공급망 규모에서 중요하다는 점이다. 참조 구현에 아키텍처적 결함이 존재하고 1억5천만 다운로드가 조용히 물려받은 상황에 구현자가 이를 포착해야 한다는 주장은 더 이상 만족스럽지 않다.

“생산 준비”를 마케팅하는 서버들은 이러한 모든 벡터에 대해 대부분 침묵했다. JWT 지원을 추가하고 그 정도만 했다.

MCP의 생산 준비는 기능 수에 대한 것이 아니라, Things가 잘못될 때 어떻게 대응하느냐에 있다.

Given that threat model — tool poisoning exploiting AI compliance, architectural SDK vulnerabilities propagating silently through supply chains, a government cybersecurity agency now publishing MCP-specific guidance — five signals emerge that actually distinguish production-ready implementations from those that merely claim to be. Each is, at root, a different expression of the same underlying question: does this server make its limitations visible, or does it hide them?

This is the single most informative signal, and you can find it in seconds by skimming environment variable documentation or startup behavior.

A server that fails closed refuses to start when its own security invariants aren’t met. A server that warns and continues implicitly says: “this security property is optional.”

Concrete things to look for: Does NODE_ENV=production with a dev-mode auth configuration cause a hard startup failure, or a warning? If rate limiting isn’t configured in production, does the server refuse to start, or does it just run without it? If the plugin sandbox isn’t real, does it block untrusted plugins or silently run them with a log line? Does setting a security feature to a known weak value — a default password, a placeholder secret — trigger rejection rather than acceptance?

The difference matters enormously at 2 AM when someone misconfigures a deployment. Fail-closed servers are self-defending. Warn-and-continue servers