MCP 서버 보호가 제품 카테고리로: 12개 통제 항목의 buy-vs-build 테스트

2026년 10월 14일, Radware(NASDAQ: RDWR)가 Model Context Protocol (MCP) Server Protection을 출시했습니다 — 상장된 네트워크 보안 벤더가 내놓은 최초의 전용 MCP 방어 제품입니다. 출시 발표는 Stacklok의 State of Model Context Protocol in Software 2026을 시장 맥락으로 인용합니다: 조사 대상 소프트웨어 기업의 절반 가까이가 프로덕션에서 MCP 서버를 운영하고, 19%는 광범위한 프로덕션 상태입니다. 상장 기업이 텅 빈 보안 표면으로는 제품을 만들지 않습니다. 동시에 공격 장부는 계속 길어지고 있습니다. Splunk 자체의 MCP Server가 10월에 CVE-2026-76286을 공개했습니다 — 커스텀 도구 구성이 가리키는 임의의 URL로 사용자의 Splunk 인증 토큰을 넘겨버리는 SSRF입니다. 따라서 엔지니어링 리더에게 질문은 더 이상 "MCP 서버를 강화해야 하는가"가 아닙니다 — 12개 통제 항목 체크리스트가 그 질문은 이미 매듭지었습니다. 지금의 질문은: MCP 방어를 사면 실제로 무엇이 막히고, 무엇이 열려 있느냐입니다.

이 문서는 Radware가 발표한 다섯 개 역량 그룹을 12개 통제 항목 기준선에 대응시킵니다. 그 결과: 3개 통제 항목은 네트워크 가장자리에서 막히고, 5개 항목은 부분적인 커버를 받으며, 4개 항목 — 침해가 시끄러운지 조용한지를 결정하는 애플리케이션 계층 통제 항목 — 는 제품 유무와 관계없이 모든 배포에서 여러분이 직접 구축할 몫으로 남습니다. 아래의 의사결정 매트릭스가 그 결과물입니다.

매트릭스 앞에 두 개의 정직한 표식을 남깁니다. 둘 다 읽는 방식에 영향을 줍니다. 첫째, 제품의 역량 주장은 보도자료에 담긴 설계 의도입니다 — 각 항목은 "설계되었다"는 표현으로 서술되며, 검증의 장은 12월 3일 Radware 웨비너지 발표 자체가 아닙니다. 둘째, 아래 매핑은 발표된 역량 목록을 대상으로 합니다. 네트워크 계층 제품이 무엇을 볼 수 있는가에 관한 검증 가능한 가설이지, 출고된 동작에 대한 리뷰가 아닙니다. 누군가의 제품을 발주서에 넣기 전에 여러분의 트래픽을 여러분의 강화 증거와 대조해 보십시오.

핵심 요약

• Radware(NASDAQ: RDWR)가 2026년 10월 14일 전용 설계의 MCP Server Protection을 출시 — 상장 네트워크 보안 벤더로서는 최초의 MCP 방어 제품. Stacklok의 State of MCP 2026 조사를 인용: 소프트웨어 기업의 절반 가까이가 프로덕션에서 MCP 서버 운영, 19%는 광범위한 프로덕션.
• Splunk가 2026년 10월 7일 자체 MCP Server에서 CVE-2026-76286을 공개(CWE-918, CVSS 5.3, 1.2.1에서 수정) — 실행 중인 사용자의 플랫폼 토큰을 커스텀 API 도구에 구성된 URL로 보내는 SSRF. 생태계 최초의 CVSS 10.0(CVE-2026-16496)과 CISA KEV 등재 2건을 이미 담은 장부에 합류합니다.
• 12개 강화 기준 항목에 대비해 네트워크 계층 MCP 제품이 차단하는 것은 3개 항목 — 네트워크 격리, 플러딩과 DoS, 섀도 서버 탐지 — 이고, 4개 애플리케이션 계층 통제 항목(출처 검증, STDIO 강화, 컨텍스트 경계, kill switch)은 모든 배포에서 운영자의 몫으로 남습니다.
• 5개 부분 커버 행은 차단이 아니라 탐지입니다 — 인증 공격 탐지, 에이전트 신원 모니터링, 네트워크 지점 감사 텔레메트리는 OAuth 롤아웃, 신원 수명 주기, 변경 불가능한 호출별 감사 기록을 대신하지 않습니다.
• 12개 통제 항목은 RFP의 역할도 겸합니다 — Radware의 발표 목록은 노출된 도구와 리소스에 대한 가시성을 주장하지만 tools/list 드리프트 탐지는 주장하지 않으므로, Deadbugz 계열 메타데이터 포이즈닝을 잡아내는 fingerprint-and-diff 통제 항목은 운영자의 구축 목록에 남습니다.

상장 벤더는 수요가 측정된 곳에 만든다

보안 제품 카테고리는 네 가지 전제 조건이 동시에 충족될 때 형성됩니다. 위험이 열거되어 있고, 공격이 구체적이며, 사고에 이름이 있고, 수요가 측정 가능할 때. 이번 달 MCP는 이 네 가지 선을 동시에 넘었습니다:

• 위험이 열거되어 있습니다. OWASP MCP Top 10은 Beta v0.1에서 Token Mismanagement부터 Context Injection과 Over-Sharing까지 명명된 열 개의 카테고리를 정리합니다.
• 공격이 구체적입니다. 네 개의 커뮤니티 공격 계열이 프로덕션 수준의 상세로 문서화되어 있습니다: STDIO 명령 주입(OX Security, 1억 5천만+ 다운로드 영향), Postmark MCP 백도어(정상처럼 보이는 npm 패키지 안의 tool poisoning), SHA-피닝 우회, 그리고 Deadbugz의 런타임 게이트식 메타데이터 포이즈닝(74분 만에 23개 풀 리퀘스트, 신뢰된 세 번의 호출 후에야 드러나는 악성 도구 정의).
• 사고에 이름과 번호가 있습니다. CVE-2026-16496은 생태계 최초의 CVSS 10.0을 만들었습니다 — Terraform MCP Server의 스테이트풀 전송 모드에서의 세션 하이재킹 우회입니다. MCP 인접 CVE 2건이 CISA의 알려진 악용 취약점 카탈로그에 올랐고, 두 번째(CVE-2026-59822, CVSS 8.8)는 9월 16일 연방 수정 기한을 갖고 있습니다. Splunk는 10월 7일 자체 MCP Server에서 CVE-2026-76286을 공개하고 1.2.1에서 수정했습니다. Zenity의 AgentCorruption은 관리형 플랫폼의 피해 범위를 보여줬습니다: 공개 에이전트 하나로 보낸 프롬프트 하나가 AWS 계정의 모든 에이전트에 닿는 자격 증명을 내놓게 만들었습니다.
• 수요가 측정되어 있습니다. Stacklok의 조사는 채택률을 벤더가 시장을 산정할 수 있는 지점에 놓아둡니다: 조사 대상 소프트웨어 기업의 절반 가까이가 프로덕션, 19%는 광범위한 프로덕션 — 같은 방법으로 조사한 금융 서비스와 리테일 코호트를 앞섭니다.

스캔 기반 수치가 긴박성의 고리를 닫습니다: 인증 없이 공개 접근 가능한 1,467개의 MCP 서버(Trend Micro의 수정 집계, 이 중 1,227개는 폐기된 SSE 전송에 있음)와 조사 대상 2,614개 서버 중 82%의 경로 순회 노출, 8.5%의 OAuth 채택률(Practical DevSecOps). Radware CTO David Aviv는 제품 논지를 한 문장으로 말했습니다: "조직은 자신이 어떤 MCP 서버를 갖고 있는지, 그 서버가 무엇을 노출하는지, 어떤 에이전트가 접근하는지, 그리고 그 상호작용이 안전한지 알아야 합니다." 그 문장은 거의 한 구절 한 구절, 체크리스트의 인벤토리와 드리프트 모니터링 통제 항목입니다 — 이제 제품 홍보 문구가 되었습니다.

제품이 주장하는 것 — 5개 역량 그룹

발표는 Radware MCP Server Protection을 기존 Agentic AI Protection과 LLM Firewall 제품군 곁에 배치하고, 클라우드 서비스(Cloud Application Protection Service) 또는 Alteon과 DefensePro 기반의 클라우드 보강형 온프레미스로 퍼블릭 클라우드, 프라이빗 클라우드, Kubernetes, 하드웨어 데이터 센터 전반에 배포 가능하다고 하며, 다섯 개의 역량 그룹을 주장합니다:

1. MCP 공격 표면 가시성 — 배포된 서버, 노출된 도구와 리소스, 에이전트 활동, 사용 패턴, 통신 흐름.
2. MCP 인지형 공격 방어 — 프로토콜 남용, 인증 공격, 도구와 리소스 열거, 무단 MCP 상호작용, AI 기반 도구 플러딩, 서비스 거부.
3. 거버넌스 — 노출 평가, 취약점 식별, 규모를 두고의 정책 적용.
4. 에이전트 활동 모니터링 — 에이전트 신원, 도구 호출 패턴, 행동 이상, 리소스 소비 추세.
5. 배포 유연성 — 클라우드 서비스, 또는 클라우드 보강형 Alteon과 DefensePro 온프레미스.

이 목록을 공격 장부에 대조해 읽으면 일치는 진짜이지만 부분적입니다. 방어 그룹(2)이 이름 붙인 것은 바로 와이어상에 보이는 공격 표면입니다: 프로토콜 남용, 열거, 플러딩, 서비스 거부 — MCP Paradox 문서가 프로토콜의 마찰 없는(friitionless) 설계로 거슬러 올라가는 바로 그 부류입니다. 목록에 없는 것도 똑같이 많은 정보를 줍니다: 도구 정의 드리프트 탐지(Deadbugz 계열)를 주장하는 항목은 없고, 패키지 출처 검증을 주장하는 항목은 없고, 컨텍스트 창 강제 적용을 주장하는 항목은 없고, kill switch를 주장하는 항목은 없습니다. 이것들은 모듈 이전과 모듈 내부에 사는 통제 항목이고, 이 문서의 매트릭스가 운영자의 일로 채점하는 것들입니다.

Splunk의 CVE가 실무에서 이 구분이 왜 중요한지를 보여줍니다. CVE-2026-76286은 도구 구성의 결함입니다: MCP Server가 실행 중인 사용자의 플랫폼 인증 토큰을 해당 도구에 구성된 URL로 보냈습니다 — 다른 사용자가 그 URL을 제어하고 있었다면 토큰을 가로채고 그 사용자로 행동할 수 있었습니다. 네트워크 통제는 사후에 송출 시도를 표시할 수 있지만, 수정은 12개 통제 기준선에 이미 있던 구성 규칙입니다 — 서버가 도구별로 구성된 모든 URL을 검증하고 소유하며, 모듈의 아웃바운드 경로는 토큰이 움직이기 전에 좁혀집니다(CWE-918, CVSS 5.3, 1.2.1에서 패치됨). 가장자리에서의 탐지와 구성에서의 강제 적용은 서로 다른 통제 항목이며, 토큰이 새어나가지 못하게 막는 것은 둘 중 하나뿐입니다.

12개 통제 항목의 buy-vs-build 테스트

아래 매트릭스는 이 문서의 작업 결과물입니다. 상태는 다섯 개의 발표된 역량 그룹에 대비해 채점됩니다: 차단은 발표된 역량이 해당 통제 항목의 공격 계열을 네트워크 가장자리에서 커버한다는 뜻이고, 부분 커버는 제품이 표면을 보거나 탐지할 수 있지만 강제 적용·수명 주기·권위 있는 기록은 운영자에게 남아 있다는 뜻이며, 미커버는 해당 통제 항목의 표면이 구조적으로 네트워크 계층 도구에 보이지 않는다는 뜻입니다 — 반드시 특정 제품의 잘못이 아닙니다.

#	통제 항목	제품이 커버한다고 주장할 수 있는 것	상태	당신에게 남는 것
1	SSE → Streamable HTTP 마이그레이션	인벤토리가 폐기된 SSE 서버를 표시	부분 커버	마이그레이션 자체 — 필터 규칙이 아니라 아키텍처 변경
2	네트워크 격리와 출처 검증	L3–L7 경계 강제 적용(벤더의 홈 그라운드)	차단	SDK 내부의 Host/Origin 검증은 여전히 애플리케이션 계층
3	OAuth 2.1 + OIDC 강제 적용	인증 공격 탐지, 무단 상호작용 탐지	부분 커버	토큰 발급, 스코프, RFC 8707 오디언스 바인딩 — 롤아웃은 당신의 일
4	에이전트 신원 분리	에이전트 신원 모니터링, 행동 이상	부분 커버	프로비저닝, 어테스테이션, 취소 수명 주기(SCIM/SPIFFE)는 당신의 일
5	도구 포이즈닝 스캔 / 드리프트 탐지	와이어상의 프로토콜 남용과 열거	부분 커버	승인 시점 스캔과 설치 후 tools/list 핑거프린팅(Deadbugz 계열)은 당신의 일
6	서명된 출처 검증과 AIBOM	—	미커버	레지스트리와 npm 공급망: 서버가 말하기 전에 착지하는 공격
7	STDIO 강화	—	미커버	클라이언트와 서브프로세스 사이의 localhost 전송; 검사할 와이어 트래픽 없음
8	레이트 리밋(플러딩 / DoS)	AI 기반 도구 플러딩, 서비스 거부	차단	경계 너머의 도구별·에이전트별 모듈 수준 제한
9	컨텍스트 경계(OWASP MCP10)	—	미커버	모델이 세션 안에서 읽는 것은 네트워크 데이터가 아님
10	모듈별 kill switch	—	미커버	여러분의 feature flag; 네트워크 차단은 최후의 봉쇄
11	호출별 감사 로그	네트워크 지점의 흐름·이상 텔레메트리	부분 커버	입력 해시가 붙은 권위 있는 변경 불가능 호출별 JSON은 당신의 일
12	섀도 서버 탐지	배포된 서버의 공격 표면 발견	차단	"알려진 정상"을 정의하는 레지스트리 심사와 드리프트 정책

합계: 3개 차단, 5개 부분 커버, 4개 미커버. 이 신흥 카테고리의 모든 벤더에서 같은 구조가 성립합니다. 이 분할은 제품의 한계가 아니라 아키텍처 경계이기 때문입니다. UpGuard가 밝힌 "15대 중 1대가 위장 서버"라는 사실은 위장체가 npm 쪽에 있으면 네트워크 경계에는 보이지 않고, Deadbugz 페이로드는 정상 MCP 응답 안에 도착해서 모니터에 보이지만 의미론적으로 판단할 수는 없으며, 모델의 컨텍스트 창은 네트워크 제품이 강제할 수 있는 어떤 경계 안쪽에도 있습니다.

매트릭스를 하나의 뷰로: 세 개의 커버 밴드, 그 뒤에 있는 시장 수치, 그리고 그림이 실어 나르는 RFP 규칙:

부분 커버를 사는 것은 여전히 합리적 — 정직하게 점수를 매긴다면

5개 부분 커버 행은 조달 대화가 빗나가는 지점입니다. "인증 공격 탐지"는 OAuth 2.1이 배포되었다는 뜻이고, 에이전트 신원 모니터링이 에이전트 신원이 취소 가능하다는 뜻은 아니며... 부분 커버에는 진짜 가치가 있습니다 — 강제 없는 탐지는 트립와이어이고, 여러분이 등록하지 않은 서버를 골라내는 네트워크 인벤토리는 살 수 있는 가장 빠른 섀도 MCP 인구조사입니다. 이것들을 통제 항목의 완결이 아니라 탐지 커버로 채점하십시오:

• C1/C3/C4 부분 커버는 운영자 자신의 작업이 일어났을 때만 완전한 통제가 됩니다 — 전송 마이그레이션, OAuth 롤아웃, 신원 수명 주기. 모니터링은 수정 대기열을 움직일 수 있지만 수정 그 자체가 될 수는 없습니다.
• C5 부분 커버는 구체적인 RFP 질문이 붙을 만합니다. 결과가 가장 무거운 갭이기 때문입니다: 제품이 한 서버의 tools/list 응답을 시점별로 diff하고 의미론적 드리프트에 경보를 낼 수 있는가? 발표는 노출된 도구와 리소스 가시성을 이름 지을 뿐, 드리프트 탐지는 주장하지 않고, Deadbugz는 diff되지 않은 네 번째 호출 앞에서 멈추는 모든 검토를 이기도록 설계되어 있습니다.
• C11 부분 커버는 양쪽 방향으로 베어 넣습니다: 네트워크 지점 텔레메트리는 모듈이 볼 수 없는 이상 탐지에 먹거리가 되지만, 권위 있는 감사 기록 — 타임스탬프, 에이전트 ID, 도구, 입력 해시, 출력 상태 — 는 구조화되고 변경 불가능하며 여러분의 통제 아래 있어야 합니다. AgentCorruption은 그 이유를 매듭짓는 반례입니다: 플랫폼 기본 역할이 계정의 모든 에이전트를 노출한 뒤, "어느 에이전트가, 어떤 도구로, 누구의 입력으로"는 운영자가 소유한 로그에서만 답할 수 있었습니다.

buy-vs-build 경계

네 가지 규칙이 매트릭스에서 자연히 떨어져 나옵니다:

1. 노출이 네트워크 형태면 네트워크 계층을 사십시오. 플러딩, 열거, 프로토콜 남용, 알려지지 않은 서버 모집단은 와이어에서 보이는 문제이고, DDoS/WAF 혈통의 벤더는 이를 서비스로서 정상 가격에 운영합니다. 공유 인프라 위에서 멀티 테넌트, 멀티 팀 에이전트 집단을 운영한다면 그 계층은 아마도 타인의 핵심 역량입니다.
2. 구매 여부와 무관하게 네 가지 애플리케이션 계층 통제를 소유하십시오. 출처 검증(C6), STDIO 강화(C7), 컨텍스트 좁히기(C9), kill switch(C10)는 이번 주 어떤 네트워크 벤더의 주장 목록에도 없고, 제품군으로 구매할 수 있는 종류의 것이 아닙니다 — 모듈이 어떻게 만들어지고 운영되는지에 관한 속성입니다. MCP Module Code Standard는 이를 모듈 내부에서 강제 가능하게 만드는 빌드 측 참조입니다.
3. 12개 통제 항목을 RFP로 바꾸십시오. 후보 MCP 보안 벤더에게 주장이 아니라 매트릭스에 대비한 증거를 요구하십시오. Deadbugz 패턴에 대한 드리프트 탐지 시연, 여러분 스키마에 맞는 샘플 감사 기록, 그리고 "거버넌스"의 정확한 범위 — 무엇을 어디서 강제하는가. 벤더가 증명할 수 있는 것이 막히고, 못하는 것은 여러분의 구축 목록에 남습니다.
4. 구축 절반에는 무료 참조물이 있습니다. Microsoft Agent Governance Toolkit은 OWASP MCP Top 10의 10/10 커버(7개 완전, 3개 로드맵 동반 부분)를 오픈소스 런타임으로 내놓습니다 — 상용 경계의 비영리 보완물입니다. 체크리스트의 점수 모델(12/12 프로덕션 준비; 8 미만은 프로덕션 노출 금지)이 두 절반 모두의 수용 게이트입니다.

이 패턴은 Radware 너머로 확장됩니다. Black Hat 2026 물결은 이미 섀도 서버 발견(Cyera Agent Guardian), 신원 거버넌스(SailPoint), 네트워크 계층 모니터링(Check Point AI Network Firewall)을 가져왔고 — 부모 체크리스트의 업데이트 로그가 이를 커버합니다 — TrueFoundry 같은 게이트웨이 벤더가 거버넌스 절반을 담당합니다. Radware의 진출이 특화 제품 뒤에 상장 벤더를 놓았습니다. 카테고리의 수렴은 이제 시장의 몫입니다. 네트워크 제품이 볼 수 없는 네 가지 통제는 운영자의 몫으로 남습니다.

함께 읽기

• MCP 보안 강화 체크리스트: 1,467개 노출 서버와 그것을 막는 통제 항목 — 부모 문서: 이 문서의 매트릭스가 대조하는 5계층 12개 통제 항목, 그리고 CVE, KEV 등재, 공격 계열의 업데이트 로그.
• 모델이 아니라 기본 역할:프롬프트 하나가 AWS 계정의 모든 에이전트를 장악하다 — 운영자 측 감사 요건을 정의한 관리형 플랫폼 사건: 계정 전체에 적용되는 플랫폼 기본 실행 역할이 피해 범위를 정했습니다.
• Deadbugz : 네 번째 MCP 공격 계열은 신뢰할 때까지 숨어 있다 — 이 문서의 C5 RFP 질문 뒤에 있는 런타임 게이트식 메타데이터 포이즈닝 계열: 승인 시점 스캔에는 보이지 않고, 핑거프린트와 diff에는 보입니다.

---

대표적인 빌드: 중견 유통사가 하나의 MCP 모듈을 프로덕션에 노출합니다 — NetSuite 카탈로그 리더와 견적 생성기, ERP 쓰기-백이 붙어 있습니다. 네트워크 계층(그 에스테이트가 이미 신뢰하는 제품의 어떤 형태든)은 모듈을 발견하고, 에이전트 트래픽을 모니터링하고, 경계에서 플러딩으로부터 지켜냅니다. 네 가지 애플리케이션 계층 통제는 첫 도구 호출 전에 모듈 안으로 빌드됩니다. 아티팩트에 서명된 출처 검증, STDIO에 사용자 제어 경로 전무, 컨텍스트는 도구별로 좁히고, kill switch는 스테이징에서 한 번 시행합니다. 일주일짜리 Discovery 단계가 서버 인벤토리와 12개 통제 점수카드를 만들어, 어떤 벤더의 역량 목록 — 이번 것이든 다음 것이든 — 을 슬라이드가 아니라 검증 가능한 RFP 응답으로 바꿉니다.

일주일짜리 discovery. 시스템 인벤토리, 워크플로 지도, 고정 범위를 받게 됩니다 — 우리와 함께 구축하든 안 하든.