Model Context Protocol(MCP)은 AI 에이전트를 엔터프라이즈 데이터와 도구에 연결하기 위한 공통 표준으로 빠르게 자리 잡고 있습니다. MCP는 도구별 임시 통합을 공유 인터페이스로 대체하여, 에이전트가 외부 서버를 호출하고 컨텍스트를 검색하며 작업을 실행할 수 있게 합니다. 하지만 에이전트가 통신하는 모든 MCP 서버는 새로운 신뢰 경계입니다. 최근 보안 사고 — 정당한 이메일 서비스를 사칭한 악성 npm 패키지와 공식 MCP SDK에서 공개된 취약점 — 는 팀이 MCP 서버를 플러그 앤 플레이로 취급할 때 어떤 일이 발생하는지 보여줍니다.
MCP 보안은 각 서버를 기본적으로 신뢰하지 않는 것으로 취급하고, 출처를 검증하며, 도구 접근을 스코핑하고, 실행을 격리하고, 작업을 로깅하고, 명시적인 정책으로 배포를 거버넌스하는 것을 의미합니다. 귀하의 팀이 프로덕션 환경의 에이전틱 AI에서 다루는 파일럿에서 프로덕션까지의 여정을 진행 중이라면, MCP 보안은 에이전트가 프로덕션에 도달했을 때 엔터프라이즈 데이터를 안전하게 다룰 수 있는지를 결정하는 계층입니다.
핵심 요약
- MCP는 모든 외부 서버를 새로운 신뢰 경계로 만듭니다. 기본 개방형 MCP 통합은 에이전트의 의도된 스코프를 넘어 엔터프라이즈 데이터를 노출할 수 있습니다.
- 2026년 주요 위험에는 tool poisoning, MCP 서버 응답을 통한 prompt injection, rug-pull 및 공급망 공격, 과도하게 넓은 도구 스코프, OAuth 또는 토큰 검증 실패가 포함됩니다.
- MCP 보안 모범 사례는 서버 검증 및 버전 고정, 최소 권한 도구 스코프, 실행 샌드박싱, 포괄적인 감사 로깅, 민감한 작업에 대한 human-in-the-loop 승인을 다룹니다.
- 엔터프라이즈 거버넌스가 격차를 해소합니다: 문서화된 정책, 데이터 분류, ISO/IEC 27001:2022 및 SOC 2와의 정합을 지원할 수 있는 제어 — 하지만 그 자체로 컴플라이언스를 확립하지는 않습니다.
- 인증된 원격 MCP 서버는 네트워크 세분화, 스코프된 인가, 이그레스 제어, 중앙화된 로깅과 결합할 때 거버넌스하기 더 쉬운 경우가 많습니다. 원격이 자동으로 더 안전한 것은 아니며, 해당 제어가 적용될 때만 더 안전합니다.
Model Context Protocol(MCP)이란 무엇인가요?
Model Context Protocol은 LLM 애플리케이션이 외부 데이터 소스와 도구에 연결하는 방식을 표준화하는 개방형 프로토콜입니다. 공식 Model Context Protocol 사양에 따르면, MCP는 세 가지 역할을 정의합니다: 호스트(에이전트를 관리하는 애플리케이션), 클라이언트(호스트 내부에서 서버에 연결하는 엔티티), 서버(도구, 리소스, 프롬프트를 노출하는 프로그램). MCP는 Anthropic의 Model Context Protocol 소개에서 설명된 대로 Anthropic이 원래 도입한 개방형 프로토콜입니다. 단일 벤더가 독점하지 않습니다.
팀이 임시 도구 통합을 넘어서는 이유
MCP 이전에는 에이전트를 데이터베이스, CRM, 파일 저장소에 연결하는 것이 도구별로 맞춤 통합을 작성하는 것을 의미했습니다. MCP는 MCP 호환 클라이언트가 모든 서버를 호출할 수 있는 공유 프로토콜로 이를 대체합니다. 더 빠른 통합, 재사용 가능한 서버, 모델 이식성이라는 이점은 실재하지만, 동일한 편의성이 공격 표면을 확장합니다. 개발자가 몇 초 만에 MCP 서버를 설치할 수 있을 때, 질문은 “이것을 구축할 수 있는가?”에서 “이 서버를 우리 데이터로 신뢰해야 하는가?”로 이동합니다.
MCP가 기본적으로 보안하는 것 — 그리고 보안하지 않는 것
MCP는 클라이언트와 서버 간의 통신을 표준화합니다. 전체 통합을 보안하지는 않습니다. 다음은 호스트와 클라이언트의 책임으로 남습니다: 서버 신뢰, 인가, 동의, 출력 검증, 실행 제어(샌드박싱, 속도 제한, 격리). 사양은 도구 설명과 어노테이션을 신뢰할 수 있는 서버에서 온 것이 아니면 신뢰할 수 없는 것으로 간주해야 한다고 명시합니다. MCP는 연결하는 표준 방법을 제공할 뿐, 연결 대상이 안전하다는 보장은 제공하지 않습니다.
지금 MCP 보안이 중요한 이유
MCP 서버는 종종 데이터베이스, 파일 시스템, 이메일 제공자 또는 비즈니스 API에 대한 자격 증명을 보유합니다. 서버가 침해되거나, 과도한 권한이 부여되거나, 악성인 경우, 데이터 유출 표면은 해당 자격 증명이 도달할 수 있는 모든 것으로 확장됩니다.
| 차원 | 임시 통합 | MCP 기반 통합 |
|---|---|---|
| 신뢰 경계 | 도구별 하나의 맞춤 통합 | 서버당 하나의 표준 경계, 에이전트 간 재사용 |
| 권한 스코프 | 통합별로 정의, 종종 검토됨 | 종종 서버 기본값에서 상속, 쉽게 과도하게 스코프됨 |
| 감사 가능성 | 통합별 맞춤 로깅 | 표준화된 호출, 하지만 로깅은 여전히 구성해야 함 |
| 공급망 위험 | 선택된 종속성으로 제한 | 설치 가능한 모든 서버가 잠재적 종속성이 됨 |
MCP는 새로운 서버를 추가하는 것을 매우 쉽게 만들며, 각각이 경계를 확장합니다. 많은 파일럿이 기본 설정으로 로컬 서버를 실행합니다 — 인증 없음, 감사 로그 없음, 스코프된 자격 증명 없음 — 이는 데모에는 적합하지만 에이전트가 실제 고객 데이터를 다룰 때는 적합하지 않습니다.
문서화된 MCP 보안 사고, 취약점, 공격 패턴
모든 MCP 보안 우려가 동일한 것은 아닙니다. 일부는 확인된 실제 사고입니다. 다른 일부는 알려진 악용 전에 패치된 공개된 취약점입니다. 또 다른 일부는 연구 시연입니다. 이 섹션은 세 가지를 구분합니다.
확인된 사고: 악성 postmark-mcp npm 패키지
2025년 9월, postmark-mcp라는 악성 서드파티 npm 패키지가 이메일 배송 서비스인 Postmark를 사칭했습니다. 이것은 공식 Postmark 패키지가 아니었습니다 — Postmark는 이 사고 전에 npm에 공식 MCP 서버를 게시하지 않았습니다. Postmark의 공식 보안 공지에 따르면, 이 패키지는 15개 버전에 걸쳐 신뢰를 구축한 후 버전 1.0.16에서 외부 서버로 아웃바운드 이메일을 숨겨서 BCC로 전송하는 백도어를 추가했습니다. Koi Security의 악성 패키지 분석은 주당 약 1,500건의 다운로드를 보고했으며; Koi Security에 귀속된 숨겨진 BCC 목적지는 giftshop.club 도메인의 주소였습니다.
이것은 실제 악성 패키지 및 소프트웨어 공급망 사고였으며, Postmark의 공식 플랫폼 침해가 아니었습니다. Postmark의 합법적인 API와 서비스는 침해되지 않았으며 영향을 받지 않았습니다. 이 사고는 공급망 위험, 과도한 권한 위험, 서버 검증 실패, 버전 변경 위험을 보여줍니다. 패턴은 rug-pull과 유사합니다; “rug pull”은 여기서 패턴의 설명으로 사용되며, Postmark 자체의 분류가 아닙니다.
공개된 취약점: CVE-2025-66414 및 CVE-2025-66416
공식 MCP SDK의 두 가지 공개된 취약점은 구현 수준의 위험을 강조합니다. 이들은 공개된 구현 취약점이지 확인된 실제 침해가 아니며, 야생에서의 악용에 대한 공개 증거는 없습니다.
CVE-2025-66414 — TypeScript SDK. 1.24.0 이전에 MCP TypeScript SDK는 HTTP 기반 서버에 대해 기본적으로 DNS rebinding 보호를 활성화하지 않았습니다. 서버가 StreamableHTTPServerTransport 또는 SSEServerTransport를 사용하여 인증 없이 localhost에서 실행되고, enableDnsRebindingProtection이 활성화되지 않았을 때, 악성 웹사이트가 same-origin 정책을 우회하고 노출된 도구나 리소스를 호출할 수 있었습니다. stdio 전송에는 영향을 주지 않습니다. 1.24.0에서 수정되었습니다. CVE-2025-66414의 GitHub 자문 및 CVE-2025-66414의 NVD 기록을 참조하세요.
CVE-2025-66416 — Python SDK. 1.23.0 이전에 MCP Python SDK(PyPI의 mcp)는 HTTP 기반 서버에 대해 기본적으로 DNS rebinding 보호를 활성화하지 않았습니다. 서버가 FastMCP와 streamable HTTP 또는 SSE를 사용하여 인증 없이 localhost에서 실행되고, TransportSecuritySettings가 구성되지 않았을 때, 악성 웹사이트가 same-origin 정책을 우회하고 노출된 도구나 리소스를 호출할 수 있었습니다. stdio 전송에는 영향을 주지 않습니다. 1.23.0에서 수정되었습니다. CVE-2025-66416의 GitHub 자문 및 CVE-2025-66416의 NVD 기록을 참조하세요.
두 자문 모두 인증 없이 로컬에서 HTTP 기반 MCP 서버를 실행하는 것은 권장되지 않는다고 명시합니다. 영향을 받는 구성은 특정합니다: stdio 전송과 인증된 서버는 영향을 받지 않았습니다.
연구 시연 및 이론적 공격 패턴
보안 연구자들은 MCP가 어떻게 악용될 수 있는지를 보여주는 공격 패턴을 시연했습니다. 이들은 개념 증명이지 확인된 실제 사고가 아닙니다. 문서화된 MCP 공격 패턴은 악성 명령이 모델에는 보이지만 사용자에게는 명확하지 않은 도구 설명에 삽입될 수 있어, 에이전트가 사용자가 승인하지 않은 작업을 수행하게 할 수 있음을 보여줍니다. 또한 처음에 양성이던 서버가 반환된 데이터를 통해 간접적인 prompt injection을 도입하여 모델을 직접 악용하지 않고도 에이전트의 동작을 조작할 수 있는 방법도 보여줍니다.
2026년 주요 MCP 보안 위험
Tool poisoning 및 악성 MCP 서버
Tool poisoning은 서버가 모델은 읽지만 사용자는 볼 수 없는 도구 설명이나 메타데이터에 악성 명령을 삽입할 때 발생합니다. 에이전트는 해당 명령을 따르고 사용자의 의도를 벗어난 작업을 수행할 수 있습니다. postmark-mcp 사고는 정당한 프로젝트를 사칭한 악성 서버의 확인된 사례입니다.
MCP 서버 응답을 통한 prompt injection
MCP 서버는 데이터 — 파일 내용, 데이터베이스 행, API 응답 — 를 반환합니다. 해당 데이터에 명령이 포함되어 있으면, 에이전트가 이를 명령으로 취급할 수 있습니다. 에이전트는 서버를 데이터 소스로 신뢰하기 때문에, 반환된 콘텐츠는 호스트가 이를 검증하고 격리하지 않는 한 인젝션 표면이 됩니다. 더 깊은 내용은 에이전틱 AI를 위한 LLM 보안를 참조하세요.
Rug-pull 및 서드파티 공급망 위험
Rug-pull은 처음에 안전했던 서버가 업데이트 후 동작을 변경할 때 발생합니다. 공급망 위험은 종속성, 전이적 패키지, 유지보수되지 않는 서버로 확장됩니다. 에이전트는 도구를 자동으로 빈번하게 호출하므로, 침해된 서버의 피해 반경은 일반적인 라이브러리 종속성보다 큽니다.
과도하게 넓은 도구 스코프 및 자격 증명 노출
서버는 종종 필요 이상으로 더 넓은 권한을 부여받습니다. 자격 증명이 침해되거나 과도한 권한을 가진 서버를 통과할 때, 노출은 해당 자격 증명이 도달할 수 있는 모든 것으로 확장됩니다. 최소 권한은 서버가 잘못되었을 때 피해를 제한하는 제어입니다.
OAuth, 토큰 검증, 인가 실패
HTTP 기반 원격 서버에 대한 MCP 인가는 MCP 인가 가이드에 설명된 대로 OAuth 2.1 규칙을 따릅니다. 인가는 MCP 서버가 노출하는 민감한 리소스와 작업을 보호합니다. OAuth는 자동적인 보안 보장이 아닙니다: 구현은 토큰 audience, issuer, 만료, 스코프를 검증해야 합니다; 토큰은 수명이 짧고 안전하게 저장되어야 합니다; 프로덕션 흐름은 HTTPS를 사용해야 합니다; 자격 증명, 인가 헤더, 토큰, 인가 코드는 로그에 기록되지 않아야 합니다; catch-all 스코프는 피하고 도구별 최소 권한 스코프를 부여해야 합니다. MCP는 개발자를 대신하여 OAuth를 안전하게 구현하지 않습니다. 토큰 패스스루, confused-deputy 위험, SSRF, 스코프 최소화에 대한 더 포괄적인 가이드는 MCP 보안 모범 사례를 참조하세요.
MCP 보안 모범 사례
모든 MCP 서버를 검증하고 고정하기
모든 MCP 서버를 신뢰할 수 없는 소프트웨어로 취급하세요: 게시자가 공식인지 확인하고, 요청된 권한을 검토하고, 소스코드나 신뢰할 수 있는 감사를 읽고, 특정 버전에 고정하고, 신뢰하는 조직의 서버를 선호하세요. postmark-mcp 사고가 주의 사례입니다.
도구 스코프에 최소 권한 적용
각 서버에 필요한 최소 접근만 부여하세요. 읽기와 쓰기 스코프를 분리하세요. 공유된 관리자 토큰 대신 스코프된 자격 증명을 사용하세요. 서버가 침해되면 피해는 부여된 좁은 스코프로 제한됩니다.
MCP 서버 실행 샌드박싱 및 격리
MCP 서버를 격리된 환경 — 컨테이너, VM 또는 별도의 네트워크 세그먼트 — 에서 실행하고 호스트에서 직접 실행하지 마세요. 서버 간에 파일 시스템이나 자격 증명을 공유하지 마세요. 샌드박싱은 피해 반경을 “서버가 모든 것에 도달할 수 있음”에서 “서버가 명시적으로 허용된 것에만 도달할 수 있음”으로 줄입니다.
감사 로깅 및 에이전트 관측 가능성
인증된 식별자, 부여된 스코프, 도구 호출, 정제된 입력 및 출력, 정책 결정, 승인 이벤트, 오류, 최종 작업 결과를 로깅하세요. 자격 증명, 토큰, 민감한 개인 데이터는 로그에 나타나지 않아야 합니다. 로그는 팀이 이벤트를 재구성하고, 컴플라이언스를 증명하고, 사고가 되기 전에 이상을 탐지할 수 있게 합니다.
민감한 작업에 대한 human-in-the-loop
실제 영향이 있는 작업에 대해 사람의 승인을 요구하세요: 프로덕션 데이터베이스 쓰기, 외부 이메일 발송, 유료 API 호출, 고객 기록 수정. 임계값은 데이터 분류를 기반으로 해야 합니다 — 공개 데이터는 승인이 필요 없을 수 있지만, 기밀 및 제한 데이터는 명시적인 승인이 필요합니다.
AI 에이전트 엔터프라이즈 거버넌스 프레임워크
정책, 소유권, 승인 워크플로
거버넌스는 문서화된 정책에서 시작됩니다: 새로운 MCP 서버를 승인할 수 있는 사람, 필요한 검토, 각 에이전트 배포의 소유자. 명시적인 소유권이 없으면 개발자가 임시로 서버를 설치하고 보안 팀은 사고 후에야 발견합니다. 제안, 검토, 승인, 배포의 간단한 워크플로는 프로덕션 전에 대부분의 공급망 위험을 중단시킵니다.
데이터 분류 및 거주지 제어
데이터를 공개, 내부, 기밀, 제한으로 분류하고, 에이전트와 해당 서버가 다룰 수 있는 클래스를 결정하세요. 필요한 경우 거주지 제어를 적용하세요: EU 또는 US 규제를 받는 데이터는 적절한 지역 외부의 서버를 통과해서는 안 됩니다.
MCP 사용을 ISO/IEC 27001:2022 및 SOC 2에 맞추기
MCP 보안 제어는 ISO/IEC 27001:2022 및 SOC 2와의 정합을 지원할 수 있지만, 이러한 제어만 구현한다고 컴플라이언스가 확립되지는 않습니다. 서버 검증은 공급자 위험 관리에 매핑됩니다; 최소 권한은 접근 제어에 매핑됩니다; 감사 로깅은 모니터링에 매핑됩니다; human-in-the-loop는 변경 관리에 매핑됩니다. 전체 컴플라이언스는 더 포괄적인 관리 시스템, 위험 평가, 내부 감사, 외부 인증을 요구합니다.
안전한 AI 통합 아키텍처 패턴
로컬 vs 원격 MCP 서버
로컬 서버는 동일한 호스트에서 실행됩니다 — 개발에는 간단하지만 파일 시스템과 네트워크를 공유하여 피해 반경을 증가시킵니다. 원격 서버는 별도로 실행되고, 인증될 수 있으며, 감사하기 더 쉽습니다. 원격이 자동으로 더 안전한 것은 아닙니다: 개방된 인터넷상의 인증되지 않은 원격 서버는 적절히 구성된 로컬 서버보다 더 위험합니다. 인증된 원격 서버는 네트워크 세분화, 스코프된 인가, 이그레스 제어, 중앙화된 로깅과 결합할 때 거버넌스하기 더 쉬운 경우가 많습니다.
OAuth 및 인증된 MCP 연결
HTTP 기반 원격 서버에 대한 MCP 인가는 OAuth 2.1 규칙을 따릅니다. 스코프되고 수명이 짧으며 순환되는 토큰을 안전하게 저장하여 사용하세요. 모든 요청에서 토큰 audience, issuer, 만료, 스코프를 검증하세요. 자격 증명, 인가 헤더, 토큰, 인가 코드를 로그에 기록하지 마세요. catch-all 스코프를 피하고 도구별 최소 권한 스코프를 부여하세요. 프로덕션 흐름은 HTTPS를 사용해야 합니다. MCP가 대신 OAuth를 안전하게 구현하지 않습니다 — 프로토콜 수준 요구사항과 토큰 패스스루, confused-deputy 위험, 스코프 최소화에 대한 더 포괄적인 가이드는 MCP 인가 가이드 및 MCP 보안 모범 사례를 참조하세요.
네트워크 세분화 및 이그레스 제어
MCP 서버를 제어된 이그레스가 있는 프라이빗 서브넷에 배치하세요. 아웃바운드 트래픽을 IP 주소와 도메인의 허용 목록으로 제한하세요. 이는 서버가 침해된 경우 유출 경로를 제한합니다 — HDWEBSOFT가 IP 허용 목록을 사용하는 NAT Gateway를 통한 아웃바운드 이메일에 사용하는 것과 동일한 원칙입니다. 안전한 AI 통합에 대한 더 포괄적인 맥락은 당사의 AI 개발 서비스 및 사이버보안 서비스를 참조하세요.
보안 우선 MCP 배포 워크플로
방어 가능한 MCP 배포는 반복 가능한 워크플로를 따릅니다: 서버 감사(출처 확인, 권한 검토, 코드 읽기), 권한 스코핑(도구별 최소 권한, 스코프된 자격 증명), 실행 격리(컨테이너 또는 별도의 네트워크 세그먼트), 동작 관측(식별자, 스코프, 도구 호출, 정제된 I/O, 정책 결정, 승인, 오류, 결과 로깅), 그리고 인적 감독 적용(데이터 분류에 기반한 민감한 작업 승인).
HDWEBSOFT는 AI 에이전트와 엔터프라이즈 데이터를 다루는 클라이언트 프로젝트에 이 워크플로를 적용합니다. ISO 9001 및 ISO/IEC 27001 인증 소프트웨어 개발 파트너로서, HDWEBSOFT는 보안을 최종 체크리스트가 아닌 릴리스 게이트로 취급합니다. 목표는 팀을 늦추는 것이 아니라, 에이전트가 프로덕션에 도달했을 때 MCP 계층이 문제를 일으키는 부분이 아니도록 보장하는 것입니다.
결론
MCP는 AI 에이전트를 엔터프라이즈 데이터에 연결하기 위한 올바른 방향입니다. 공유 프로토콜은 맞춤 통합의 얽힘보다 낫습니다. 하지만 MCP 보안은 자동적이지 않습니다. 모든 서버는 신뢰 경계이며, 모든 도구 스코프는 잠재적인 피해 반경이며, 모든 업데이트는 동작이 변경될 기회입니다. 안전하게 출시하는 팀은 서버를 검증하고, 최소 권한을 적용하고, 실행을 격리하고, 중요한 것을 로깅하며, 인간을 루프에 유지합니다.
귀하의 팀이 MCP를 통해 AI 에이전트를 엔터프라이즈 데이터에 연결 중이라면, 가장 가치 있는 다음 단계는 프로덕션 전 독립적인 검토입니다. AI 보안 및 아키텍처 감사 요청을 통해 서버 검증, 도구 스코프, 인가, 로깅, 거버넌스의 격차를 식별하고 — 사고가 강제하기 전에 구체적인 수정 계획을 받으세요.
FAQ
MCP 보안이란 무엇인가요?
MCP 보안은 Model Context Protocol을 통해 외부 데이터와 도구에 연결되는 AI 에이전트를 보호하는 실무입니다. 여기에는 서버 검증, 최소 권한 도구 스코프, 실행 격리, 감사 로깅, human-in-the-loop 제어, 그리고 MCP 기반 통합의 엔터프라이즈 거버넌스가 포함됩니다.
가장 흔한 MCP 서버 보안 위험은 무엇인가요?
가장 흔한 MCP 보안 위험에는 악성 서버로 인한 tool poisoning, MCP 서버 응답을 통해 전달되는 prompt injection, rug-pull 및 서드파티 공급망 공격, 과도하게 넓은 도구 스코프와 자격 증명 노출, 그리고 인증 배포 환경에서의 OAuth 또는 토큰 검증 실패가 포함됩니다.
프로덕션에서 MCP 서버를 어떻게 보안하나요?
프로덕션에서 MCP 서버를 보안하려면 모든 서버를 검증하고 버전을 고정하고, 최소 권한 도구 스코프를 적용하고, 서버 실행을 샌드박싱하고, 인증된 식별자와 도구 호출을 로깅하고, 민감한 작업에 human-in-the-loop 승인을 적용하며, 배포를 엔터프라이즈 거버넌스 및 컴플라이언스 제어에 맞춰야 합니다.
Model Context Protocol은 엔터프라이즈 AI 에이전트에 안전한가요?
팀이 모든 MCP 서버를 새로운 신뢰 경계로 취급하고 명시적인 보안 제어를 적용할 때, MCP는 엔터프라이즈 AI 에이전트에 안전합니다. MCP는 클라이언트와 서버 간의 통신을 표준화하지만, 서버 신뢰, 인가, 출력 검증, 실행 제어는 호스트와 클라이언트의 책임으로 남습니다.
MCP 보안은 ISO/IEC 27001:2022 또는 SOC 2 컴플라이언스를 어떻게 지원하나요?
MCP 보안 제어는 서버 검증, 최소 권한 접근, 감사 로깅, 공급자 위험 관리를 기존 컨트롤 카테고리에 매핑하여 ISO/IEC 27001:2022 및 SOC 2와의 정합을 지원할 수 있습니다. 이러한 제어만 구현한다고 컴플라이언스가 확립되지는 않으며, 조직은 더 포괄적인 관리 시스템과 감사 요구사항을 완수해야 합니다.
AI Security & Architecture Audit는 언제 실행해야 하나요?
AI 에이전트를 프로덕션으로 승격하기 전, 보안 사고나 임박한 사고 후, 에이전트를 새로운 민감 데이터 소스에 연결할 때, 그리고 새로운 MCP 서버가 프로덕션 워크플로에 도입될 때 AI Security & Architecture Audit를 실행해야 합니다.
