올해 claude_desktop_config.json이나 mcp.json 파일에 연결 문자열을 복사하여 붙여넣음으로써 MCP 서버를 추가한 적이 있다면, 이 글은 당신을 위한 것입니다. 이 글은 "MCP가 좋은가 나쁜가"에 대한 글이 아닙니다. 2026년에 프로토콜 레벨에서 정확히 무엇이 고장 났는지, 그중 일부를 수정하기 위해 6일 후에 출시될 내용은 무엇인지, 그리고 다음 서버를 추가하기 전에 당신의 자체 검토 프로세스에 추가할 가치가 있는 구체적인 점검 사항이 무엇인지에 대한 분석입니다.

2026년 4월 15일, OX Security는 모든 공식 Model Context Protocol SDK — Python, TypeScript, Java, Rust — 내부에 존재하는 결함을 공개했습니다. 네 가지 모두입니다. Anthropic은 해당 동작이 의도된 것이었음을 확인했습니다. 그 후 변경을 거부했습니다.

이 결함은 서버의 구성 파일(configuration file)에 영향을 미칠 수 있는 사람이라면 누구나 호스트 머신에서 임의의 셸 명령(shell commands)을 실행할 수 있게 했습니다. OX Security는 1억 5천만 회 이상의 다운로드 규모를 가진 공급망 내에 존재하는 20만 개 이상의 취약한 인스턴스를 확인했습니다.

저는 매주 새로운 MCP 서버를 연결합니다. 저는 제가 신뢰하는 모든 서버의 밑바닥에 깔린 배선인 프로토콜 자체가, 아무도 되돌릴 의사가 없는 설계 결정과 함께 출시되었는지 단 한 번도 묻지 않았습니다. 이제는 묻습니다.

MCP가 에이전트 스택(Agent Stack)에서 위치하는 곳

저는 제가 구축하는 모든 AI 시스템을 EchoNerve Agent Stack™ — 6개 계층: Models, Tools, Memory, Agents, Workflows, Applications — 에 맞춰 매핑합니다. MCP는 모델이 자신 외부로 손을 뻗어 데이터베이스, 파일 시스템, API를 호출하는 Tools 계층에 거의 전적으로 존재합니다.

MCP 이전에는 이러한 연결 하나하나가 모두 커스텀 코드(custom code)였습니다. MCP는 이를 하나의 공유 인터페이스로 대체했습니다 — 즉, 어떤 MCP 호환 클라이언트(client)든 규격에 맞는 서버를 동일한 방식으로 호출할 수 있습니다. Tools 계층은 에이전트가 현실 세계에서 무엇을 만질 수 있는지를 결정합니다. Models 계층의 출력이 나쁘면 잘못된 문장이 생성되지만, Tools 계층의 연결이 나쁘면 실제 시스템에 대해 잘못된 동작(action)을 수행하게 됩니다.

구체적으로 다음과 같은 모습입니다. 다음과 같은 .mcp.json 항목은 어떠한 검토 게이트(review gate)도 없이, 단 하나의 설정 블록만으로 에이전트에게 운영 데이터베이스에 대한 완전한 읽기/쓰기 권한을 부여합니다:

{
  "mcpServers": {
    "postgres-prod": {
...

MCP 이전에는 그러한 권한을 부여하기 위해 커스텀 통합 (custom integration) 과정이 필요했으며, 대개 두 번째 엔지니어의 승인이 수반되었습니다. MCP는 이 전체 과정을 복사하여 붙여넣기만 하면 되는 하나의 블록으로 압축했습니다. 그 편리함은 실재합니다. 하지만 검토 (review) 단계 역시 그와 함께 압축되어 사라졌다는 사실 또한 실재합니다.

Anthropic이 수정하지 않을 결함

대부분의 데스크톱 및 개발 도구가 사용하는 로컬 프로세스 인터페이스인 MCP의 STDIO 전송 (transport) 방식은, 중간에 정화 (sanitization) 단계 없이 구성 값 (configuration values)을 셸 실행 (shell execution)으로 직접 전달합니다. 만약 공격자가 해당 구성 파일에 영향을 미칠 수 있다면 (악성 npm 패키지, 침해된 툴체인, 쓰기 권한이 있는 내부자 등), 그들의 명령어가 사용자의 머신에서 실행됩니다. 이는 대상 MCP 서버가 성공적으로 시작되지 않더라도 실행됩니다.

이 취약점은 이제 공식 식별 번호를 부여받았습니다: CVE-2026-30623. OX Security는 공식적으로 지원되는 4개의 SDK 모두에서 이 취약점이 동시에 발견됨을 확인했습니다. 이는 특정 팀의 구현 오류가 아니라, 모든 다운스트림 서버가 복제한 참조 아키텍처 (reference architecture) 자체에 내장된 결정입니다.

오늘 바로 실행해 볼 수 있는 간단한 점검 사항은 다음과 같습니다: 구성된 서버 중 실제로 사용자가 완전히 제어할 수 없는 환경 변수 (environment values)를 가지고 STDIO를 통해 실행되는 서버가 있는지, 아니면 앞에 실제 인증 경계 (auth boundary)가 있는 원격 전송 (remote transport) 방식을 사용하는지 감사 (audit)하십시오.

# 설정 파일 내에 인라인 비밀값 (inline secrets)이 포함된 STDIO 서버를 찾아내는 투박한 방법
jq -r '.mcpServers | to_entries[] | select(.value.command != null) | .key' ~/.config/*/mcp.json 2>/dev/null

클라이언트가 구성을 저장하는 경로에 맞춰 경로를 수정하십시오. 핵심은 단순히 서버 이름만 믿는 것을 멈추고, 각 항목별로 전송 (transport) 방식과 자격 증명 노출 (credential exposure) 여부를 확인하기 시작하는 것입니다.

도구 오염 (Tool Poisoning)은 CVE가 필요하지 않다

두 번째 공격 패턴은 도구 (Tools) 레이어를 똑같이 강하게 타격했으며, 이는 프로토콜 수준의 버그를 필요로 하지 않습니다. 도구 오염 (Tool poisoning)은 도구 자체의 description field (모델이 도구를 어떻게, 언제 호출할지 결정하기 위해 읽는 텍스트) 내부에 악의적인 지침을 숨깁니다. 모델은 그 지침을 따릅니다. 외부에서 보기에는 요청의 어떤 부분도 비정상적으로 보이지 않습니다.

2026년 3월, 누군가 발견하기 전까지 340명 이상의 개발자가 mcp-jira-sync라는 이름으로 게시된 서버를 설치했습니다. 이 서버의 list_issues 도구는 설명 필드(description field)에 숨겨진 지침을 포함하고 있었으며, 이로 인해 연결된 에이전트들이 공격자의 서버로 보내는 모든 API 호출에 로컬 ~/.aws/credentials 파일의 내용을 포함하도록 만들었습니다. 아무도 아무것도 클릭할 필요가 없었습니다.

Koi Security는 postmark-mcp라는 npm 패키지에서도 유사한 패턴을 발견했습니다. 이 패키지는 1.0.16 버전이 에이전트가 보내는 모든 이메일을 공격자의 편지함으로 숨은 참조(BCC)하도록 한 줄을 조용히 추가하기 전까지 15번의 깨끗한 릴리스를 배포했습니다.

독립적인 조사(census) 결과, 문서화, 유지보수 및 신뢰성을 기준으로 색인된 17,468개의 MCP 서버를 평가했습니다. 그중 단 12.9%만이 높은 신뢰 기준을 통과했습니다. 약 1,400개의 서버를 대상으로 한 별도의 검토에서는 38.7%가 인증(authentication) 기능이 전혀 없는 상태로 배포된 것으로 나타났습니다.

7월 28일 출시되는 사양 업데이트 (The Spec Update Landing July 28)

2026-07-28 MCP 사양 후보(specification release candidate)는 OAuth 2.1 및 OpenID Connect를 중심으로 권한 부여 (authorization)를 재구축합니다. 클라이언트는 RFC 9207에 따라 모든 권한 부여 응답에서 토큰 발행자 (token issuer)를 검증하게 되며, 이를 통해 한 인증 서버의 응답을 다른 서버를 사칭하여 재전송하는 실제 혼동 공격 (mix-up attack) 클래스를 차단합니다. 또한 사양에서 필수적인 스티키 세션 (sticky sessions)을 제거하여, 원격 MCP 서버가 일반적인 라운드 로빈 (round-robin) 로드 밸런서 뒤에 위치할 수 있도록 합니다.

이 업데이트가 하지 못하는 것: 취약한 200,000개의 STDIO 인스턴스를 소급하여 패치하거나, 업데이트 이후 유지관리자가 오염된 도구 설명을 배포하는 것을 막지는 못합니다. 대신 서버 작성자에게 권한 부여를 처리할 수 있는 표준화된 방법을 제공합니다. 그것이 그들을 대신해 일을 해주는 것은 아닙니다.

다음 mcp add를 하기 전 체크리스트

다음 mcp 추가 전 체크리스트

1. Transport 확인 — 완전히 통제할 수 없는 설정을 가진 STDIO 서버는 실제 자격 증명(credentials)과 근접하게 접촉하기 전에 더 많은 검토를 거칩니다.
2. 도구 설명을 읽으세요 — 모델이 읽는 모든 필드를 단순히 코드뿐만 아니라 낯선 사람의 PR처럼 취급하세요.
3. 설치 횟수를 신뢰 지표로 무시하세요 — 대신 유지보수 활동과 인증 요구 사항을 확인하세요.
4. 도구 호출을 기록하세요 — 오늘날 신뢰하는 서버에 대해서조차 NSA의 2026년 5월 가이드라인에 따라 매개변수와 ID를 첨부하여 기록해야 합니다.
5. 7월 28일 이후: 실제 OAuth 2.1 채택 여부를 검증하세요 — 랜딩 페이지의 'MCP 호환' 라벨만으로는 부족합니다.

MCP가 사라질 것은 아니며, 수십 개의 직접 구축된 연결을 하나의 공유 인터페이스로 통합하여 실제로 해결했던 통합 문제를 가지고 있습니다. 하지만 도구(Tools) 계층은 에이전트의 결정이 실제 시스템에 대한 행동으로 변하는 곳이며, 2026년은 이 계층이 자체적인 감사 규율을 필요로 함을 입증했습니다.

여섯 개 레이어 프레임워크, 전체 수치, 그리고 mermaid 다이어그램과 함께 자세한 내용은 Model Context Protocol Through The Agent Stack Lens를 참고하세요.