MCP 서버, 안전하다고요?
이 수치 먼저 보세요

MCP(Model Context Protocol)는 AI 에이전트가 외부 도구·데이터에 연결하는 표준 프로토콜입니다. 2024년 11월 Anthropic이 공개한 이후 GitHub에만 약 2만 개의 구현체가 올라왔고, 지금은 Claude·GitHub Copilot·Cursor 등 주요 AI 도구가 공식 지원합니다. 그런데 “MCP는 안전한 표준”이라는 말을 그대로 믿으면 막히는 지점이 있습니다.

MCP가 뭔지 한 줄로 정리하면

MCP는 AI 모델(클라이언트)과 외부 도구·데이터(서버) 사이를 잇는 오픈 표준 프로토콜입니다. 쉽게 말하면 AI를 위한 USB-C 포트라고 보면 됩니다. 지금까지는 GitHub 연동, Slack 알림, DB 조회를 각각 따로 구현해야 했는데, MCP를 쓰면 AI가 하나의 표준 인터페이스로 이 모든 것에 접근합니다.

Anthropic이 2024년 11월 공개한 이후 OpenAI·Microsoft·Google 등 주요 플랫폼이 잇따라 지원을 선언했고, 비공식 레지스트리 mcp.so에는 현재 17,000개 이상의 서버가 등록되어 있습니다. GitHub에는 약 2만 개의 구현체가 있는 것으로 추정됩니다. (출처: Astrix Research, 2025.10)

MCP가 통신에 사용하는 전송 방식은 크게 세 가지입니다. 로컬 프로세스 간 통신에 쓰는 STDIO, 원격 서비스에 쓰는 Streamable HTTP(2025년 11월 스펙 기준 권장), 그리고 일부 구현체에서 여전히 쓰이는 HTTP + SSE. 여기서 SSE 방식은 최신 공식 스펙에서 독립 전송 방식으로는 사실상 deprecated 처리됐습니다. 아직 많은 서버가 SSE를 쓰고 있다는 점은 나중에 보안 이슈와 직결됩니다.

▲ 목차로 돌아가기

5,200개 서버를 직접 뜯어봤더니

보안 리서치 기업 Astrix는 2025년 10월 GitHub에 공개된 오픈소스 MCP 서버 구현체 5,205개를 직접 분석했습니다. (출처: Astrix Security, State of MCP Server Security 2025, 2025.10.15)

이 수치가 실생활에서 의미하는 바는 이렇습니다. 내가 Claude Desktop에 설치한 MCP 서버가 GitHub·Slack·DB에 연결된다면, 그 연결은 10건 중 5건 이상이 만료 기한이 없는 토큰 하나로 유지되고 있을 가능성이 높습니다. 해당 토큰이 한 번이라도 노출되면 권한 회수까지 시간이 걸립니다. 게다가 API 키의 79%는 환경변수(`.env` 파일)에 담겨 있는데, 이 파일이 코드 저장소에 실수로 올라가는 사고는 지금도 매일 발생합니다.

“초기 공식 예제 서버가 가장 간단한 방식인 PAT를 사용했고, 수천 명의 개발자가 그 패턴을 그대로 따라 서버를 만들었다”는 것이 Astrix의 진단입니다. 표준이 선례를 만들고, 선례가 생태계 전체의 기준점이 된 셈입니다.

▲ 목차로 돌아가기

공식 문서도 “강제”는 못 한다고 적어뒀습니다

MCP 공식 스펙(2025-11-25 버전) 보안 섹션을 보면 이런 문장이 있습니다. (출처: modelcontextprotocol.io 공식 스펙, 2025.11.25)

“While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD build robust consent and authorization flows into their applications.”

— MCP 공식 스펙 Security and Trust 섹션

여기서 핵심은 “SHOULD”라는 단어입니다. RFC 2119 기준으로 SHOULD는 “권장하지만 필수는 아님”을 뜻합니다. MCP 스펙이 명시적으로 “프로토콜 레벨에서 보안 원칙을 강제할 수 없다”고 인정한 것입니다. 즉, 공식 사양서 자체가 보안을 구현자에게 위임하고 있습니다.

스펙이 명시하는 4가지 핵심 원칙(사용자 동의, 데이터 프라이버시, 도구 안전, LLM 샘플링 제어)은 모두 구현 지침 수준이지 프로토콜이 기술적으로 보장하는 항목이 아닙니다. “도구 설명(annotation)은 신뢰할 수 없다”는 문장도 공식 스펙에 들어 있습니다. AI가 도구의 동작 방식을 스스로 판단해야 하는데, 그 판단 근거인 설명 자체를 신뢰하지 말라는 뜻입니다.

이 구조가 가진 실제 함의는 이렇습니다. Claude Desktop에서 MCP 서버를 하나 추가할 때 뜨는 동의 팝업이 없다면, 그건 해당 클라이언트 구현자가 그 기능을 빠뜨린 것입니다. MCP 자체가 막지 않기 때문에 가능한 일이고, 실제로 많은 MCP 클라이언트 구현체에서 이런 부분이 생략되어 있습니다.

▲ 목차로 돌아가기

CVE-2025-6515: 세션 ID 하나로 AI 응답이 바뀝니다

2025년 10월 JFrog 보안 리서치 팀이 Oat++ MCP 구현체(oatpp-mcp)에서 CVE-2025-6515를 발견해 공개했습니다. (출처: JFrog Security Research, 2025.10.21) 이 취약점이 보여주는 공격 방식을 “프롬프트 하이재킹(Prompt Hijacking)”이라고 부릅니다.

어떻게 작동하나요?

SSE 전송 방식에서 MCP 서버는 각 클라이언트 세션에 고유한 세션 ID를 발급합니다. 그런데 oatpp-mcp는 세션 ID를 생성할 때 Session 객체의 메모리 주소를 그대로 ID로 사용했습니다. 이 코드입니다.

oatpp::String Session::getId() const {
auto memId = reinterpret_cast<v_uint64>(this);
return oatpp::utils::Conversion::uint64ToStr(memId);
}

메모리 주소를 세션 ID로 쓰면 두 가지 문제가 생깁니다. 첫째, 예측 가능합니다. glibc malloc 같은 메모리 할당자는 해제된 주소를 재사용하기 때문에, 공격자가 세션을 빠르게 만들고 닫는 것을 반복하다 보면 이후 다른 사용자에게 배정되는 세션 ID를 미리 알 수 있습니다. 둘째, 128비트 이상의 암호학적 랜덤성을 요구하는 Streamable HTTP 스펙 요건을 위반합니다.

공격이 성공하면 공격자가 피해자의 세션으로 악의적인 프롬프트를 주입할 수 있습니다. JFrog가 Claude 클라이언트로 시연한 결과, 사용자가 “이미지 처리 라이브러리를 추천해줘”라고 요청했을 때 Claude가 공격자가 주입한 악성 패키지를 정상 패키지인 것처럼 응답한 것이 확인됐습니다. 모델 자체는 손대지 않았음에도 AI의 출력이 바뀐 것입니다.

이 공격이 성립하는 조건은 oatpp-mcp가 HTTP SSE 전송 방식으로 실행되고 공격자가 해당 서버에 네트워크 접근 권한을 가진 경우입니다. 로컬 전용 STDIO 방식에는 해당되지 않지만, 원격 MCP 서버를 운영하거나 연결하는 경우라면 확인이 필요합니다.

▲ 목차로 돌아가기

2026 공식 로드맵에서 보안이 4순위에 밀린 이유

2026년 3월 9일 공개된 MCP 공식 2026 로드맵에는 4개의 핵심 우선 영역이 있습니다. (출처: MCP 공식 블로그, 2026.03.09)

1. Transport Evolution & Scalability — 수평 확장, 상태 없는 세션, 서버 메타데이터 표준화
2. Agent Communication — Tasks 프리미티브 retry/만료 정책 보완
3. Governance Maturation — 기여자 사다리, WG 위임 모델
4. Enterprise Readiness — 감사 추적, SSO 인증, 게이트웨이 패턴

그리고 보안·인증 심화 작업은 “On the Horizon” 섹션에 들어갔습니다. 이 섹션의 의미는 공식 문서가 직접 설명합니다. “코어 메인테이너가 적극적으로 추진하지는 않는 영역”이라는 뜻입니다. DPoP(SEP-1932), Workload Identity Federation(SEP-1933) 같은 보안 강화 제안은 커뮤니티 주도로 진행 중이지만, 우선순위 상위 4개 영역의 SEP처럼 빠른 리뷰를 보장받지 못합니다.

왜 이런 선택을 했을까요? 로드맵은 “엔터프라이즈 배포에서 반복적으로 나타나는 고통 지점”을 기준으로 우선순위를 정했다고 설명합니다. 현실적으로 기업들이 지금 가장 많이 요청하는 것이 수평 확장·감사 추적이기 때문입니다. 보안 강화보다 확장성을 먼저 챙기는 것이 채택 속도를 높이는 데 유리하다는 판단이 깔려 있습니다.

이 구조가 의미하는 것은 하나입니다. 2026년 내에 MCP 프로토콜 레벨에서 세분화된 최소 권한 범위나 OAuth 강제 채택이 표준으로 들어올 가능성은 낮습니다. 보안은 여전히 구현자의 선택에 달려 있습니다.

▲ 목차로 돌아가기

MCP를 REST API처럼 쓰면 생기는 일

“MCP가 편리하니 기존 API 호출을 전부 MCP로 바꿔버리자”는 시도는 실제로 여러 팀이 해봤고, 결과는 대체로 예상과 달랐습니다. ByteBridge의 프로덕션 경험 분석(2026.01)에 따르면, 문제는 크게 세 가지로 나타납니다. (출처: ByteBridge Medium, 2026.01.23)

비용이 예측 불가능하게 커집니다

직접 API 호출은 요청 1건입니다. MCP를 통한 AI 에이전트 호출은 LLM 추론 1회 + 도구 실행 + 결과 해석이 묶입니다. 도구 목록이 30개라면 그 설명만으로도 매 요청마다 수천 토큰이 프롬프트에 추가됩니다. AWS Lambda에 배포한 MCP 서버는 콜드 스타트 시간만 약 5초가 걸린 사례도 있었습니다. AI가 하나의 사용자 요청을 처리하면서 동일한 API를 여러 번 호출하는 루프에 빠지면 비용이 순식간에 불어납니다.

같은 입력도 매번 다르게 실행됩니다

LLM은 확률 모델입니다. 동일한 요청에도 도구 선택 순서나 파라미터가 미묘하게 달라질 수 있습니다. 결제·재고·이메일 발송처럼 실행 순서와 정확성이 중요한 비즈니스 로직에서 이 비결정성은 치명적입니다. Docker 블로그는 이 지점을 명확히 정리했습니다. “MCP는 API가 아닙니다. 비결정적 에이전트가 결정적 도구를 안전하게 사용할 수 있게 하는 것이 목적이지, 직접 API 호출을 대체하는 것이 아닙니다.” (출처: Docker Blog, Jim Clark, 2025.09.03)

뭐가 잘못됐는지 찾기가 훨씬 어렵습니다

일반 API 호출이 실패하면 로그에 에러 코드가 남습니다. MCP 에이전트가 실패하면 “AI가 도구를 호출했는지”, “서버가 응답했는지”, “AI가 응답을 제대로 해석했는지” 세 곳을 모두 봐야 합니다. 기본 MCP 스펙에는 운영 모니터링 기능이 없어서, 프로덕션 환경에서는 도구 호출 로그·상관 ID·프롬프트 로그를 별도로 구축해야 합니다.

결론은 하나입니다. MCP는 AI의 유연한 추론이 필요한 복잡하고 가변적인 워크플로우에서 가치를 발휘합니다. 단순하고 반복적인 API 호출이라면 직접 호출이 더 빠르고 저렴하고 안전합니다.

▲ 목차로 돌아가기

그래서 지금 어떻게 써야 하나

MCP가 문제가 많다는 것이 아닙니다. 다수의 이기종 시스템을 AI로 묶어야 할 때, 사람의 자연어 요청을 복잡한 다단계 작업으로 실행해야 할 때는 현재로서 MCP가 가장 현실적인 표준입니다. 다만 지금 당장 적용할 수 있는 최소한의 체크포인트가 있습니다.

솔직히 말하면, 지금 시점의 MCP 생태계는 “편리하지만 아직 완성되지 않은” 상태입니다. 공식 스펙이 보안을 구현자에게 위임하고, 로드맵에서 보안 강화를 당장의 최우선이 아닌 “지평선” 영역으로 분류한 이상, 빠르게 성장하는 생태계와 보안 성숙도 사이의 간격은 당분간 사용자가 직접 메워야 합니다.

Claude Desktop·Cursor·Copilot Chat에서 MCP 서버를 연결할 때 설치하는 서버가 어떤 자격증명을 어떻게 다루는지 한 번 확인해보는 것, 그게 지금 할 수 있는 가장 현실적인 첫 단계입니다.

▲ 목차로 돌아가기

자주 묻는 질문

▲ 목차로 돌아가기

마치며

MCP는 지금 AI 에이전트 생태계에서 가장 빠르게 확산 중인 표준입니다. 틀림없이 유용하고, 앞으로 더 중요해질 프로토콜입니다. 하지만 “Anthropic이 만든 공개 표준”이라는 타이틀이 자동으로 보안을 보장해주진 않습니다.

5,200개 서버 분석에서 53%가 만료 없는 정적 자격증명을 쓰고 있다는 수치, 공식 스펙이 “프로토콜 레벨에서 강제할 수 없다”고 직접 인정하는 문장, 2026 로드맵이 보안을 최우선 외부로 분류한 사실 — 이 세 가지를 함께 보면 지금 생태계의 실제 상태가 보입니다.

MCP를 쓰지 말라는 게 아닙니다. 어떤 맥락에서 어떤 조건으로 쓰는지를 알고 써야 한다는 것입니다. 그 차이가 나중에 조용히 새는 구멍과 그렇지 않은 시스템을 가릅니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Anthropic 공식 — Introducing the Model Context Protocol (2024.11.25)
2. MCP 공식 스펙 — 2025-11-25 버전 (modelcontextprotocol.io)
3. MCP 공식 블로그 — 2026 MCP Roadmap (2026.03.09)
4. MCP 공식 개발 로드맵 — Priority Areas (modelcontextprotocol.io)
5. Astrix Security Research — State of MCP Server Security 2025 (2025.10.15)
6. JFrog Security Research — CVE-2025-6515: Prompt Hijacking Attack (2025.10.21)
7. ByteBridge Medium — MCP vs Traditional API Calls in Production (2026.01.23)