MCP 프로덕션 보안은 게이트웨이를 넘어 4개 계층으로 강제해야 한다

InfoQ 中文어제조회 2

MCP(Model Context Protocol)를 프로덕션 통합 계층으로 쓰려는 팀이 늘면서, 보안을 게이트웨이 하나로 해결하려는 접근이 한계에 부딪히고 있다. 2026년 들어 첫 60일 동안 MCP 배포를 겨냥한 CVE가 30건 넘게 보고됐고, 결함이 여러 곳에 흩어진 게 아니라 몇 개의 경계에 몰려 나타난다는 관찰이 나왔다. 그래서 제안되는 답은 단일 게이트웨이가 아니라 네 개의 통제 계층이다.

네 계층은 안전한 도구 실행, 격리된 관리 평면, 제한된 아웃바운드 신뢰 경계, 의미 무결성이다. 각 계층은 서로 다른 '가장 이른 신뢰 강제 지점'을 가지며, 게이트웨이는 이 가운데 두 계층에 부분적으로만 관여한다. 게이트웨이가 인증·인가·감사·정책 평가를 중앙화하는 지점인 것은 맞지만, 그것만으로 도구 핸들러의 인자 처리나 관리 콘솔 격리, 아웃바운드 호출, 도구 정의 변경까지 통제할 수는 없다는 것이다.

1계층은 도구 핸들러가 인자를 명령이 아니라 데이터로 취급하도록 만드는 문제다. 30개 CVE 중 13개가 같은 패턴을 보였다. CVE-2026-2130(mcp-maigret), CVE-2026-2178(xcode-mcp-server), CVE-2026-2131(HarmonyOS-mcp-server)은 도구 인자를 exec()로 실행했고, CVE-2026-1977은 Python 차트 명세 인자에 eval()을 썼다. CVE-2026-27203은 검증되지 않은 개행 문자로 환경 변수를 조작해 다음 서버 재시작 시점에 페이로드가 실행되게 했다. 대응은 셸 문자열 보간 대신 배열 인자를 받는 execFile·spawn을 쓰고, CI에 exec·eval·os.system·subprocess(shell=True) 같은 위험한 호출을 차단하는 Semgrep 규칙을 넣는 것이다. 다만 이런 규칙은 출발점일 뿐이며 다른 인터프리터나 우회 경로까지 덮으려면 규칙 집합을 확장해야 한다.

2계층은 검사기, 테스트 하네스, 등록 UI, 관리 콘솔 같은 관리 인프라다. 30개 CVE 중 6개는 프로토콜 자체가 아니라 개발·운영 인프라를 겨냥했다. CVE-2026-23744(MCPJam Inspector)는 인증 없는 엔드포인트를 기본으로 0.0.0.0에 열어 임의 MCP 서버 설치를 허용했고, CVE-2026-23523(Dive MCP Host)은 조작된 딥링크로 클라이언트 앱 안에 악성 설정을 심었다. 개발 환경이 소스 코드, 키, 빌드 시스템, 배포 자격 증명 등 프로덕션보다 많은 접근 권한을 쥐고 있다는 점이 이 계층의 위험을 키운다.

3계층은 아웃바운드 신뢰 경계다. Azure MCP Server의 SSRF 취약점(CVE-2026-26118, CVSS 8.8)은 인바운드 인증만으로는 부족하다는 걸 보여준 사례다. 공격자가 Azure 리소스 식별자를 악성 URL로 바꾸면 서버가 자신의 관리 ID 토큰을 들고 그 URL로 호출을 보내, 공격자가 서버가 접근 가능한 Azure 리소스를 통제하게 된다. 대응은 서버가 실제로 필요한 대상만 허용하는 이그레스 허용 목록(NetworkPolicy 등)과, 토큰 영향 범위를 도구 영향 범위에 맞추는 최소 권한 스코프다. 다만 클러스터 CNI가 NetworkPolicy를 실제로 강제해야 효과가 있다.

4계층은 문법이 아니라 의미, 즉 도구가 신뢰받던 시점의 뜻을 그대로 유지하는지를 다룬다. 요청이 형식에 맞고 스키마도 통과하고 인증도 됐는데 위험한 경우가 여기 해당한다. 등록 후 서버가 도구 정의를 바꾸는 'rug-pull', 공급망 타이포스쿼팅, 서버 간 컨텍스트 남용이 대표적이다. Pillar Security는 2026년 3월 MCP 관련 11개 취약점 유형을 정리했고, Maloyan과 Namiot(2026)는 실행 시점에 도구 정의가 클라이언트가 신뢰한 것과 같음을 증명할 수단이 프로토콜에 없다는 점을 '역량 증명의 부재'로 정식화했다. 대응은 등록 시점에 도구 Manifest를 정규화해 이름·설명·파라미터 스키마를 SHA-256으로 해시하고 이를 서명 기준선으로 고정하는 것이다. 재연결이나 업데이트 때 해시를 다시 비교해 같으면 통과시키고, 다르면 보류한 뒤 차이 분류기로 외형적 변경과 실질적 스키마 변경을 구분한다. 웹의 Subresource Integrity와 유사한 발상이지만 MCP 규격 자체의 기능이 아니라 게이트웨이에서 구현하는 패턴이다.

배경에는 규격 성숙 속도보다 빠른 현장 도입이 있다. 2026년 3월 9일 메인테이너 David Soria Parra가 2026 MCP 로드맵을 공개하며 기업 준비성을 우선순위로 꼽았지만, 네 방향 가운데 가장 불명확한 항목일 수 있다고 덧붙였다. 4월 2~3일 MCP 개발자 서밋에서는 AWS와 Uber가 각자의 MCP Gateway·Registry 프로덕션 아키텍처를 공개했고, Pinterest 엔지니어링 팀은 도메인 전용 MCP 서버 생태계를 소개했다. 같은 시기 Adversa AI가 500개 이상의 MCP 서버를 스캔한 결과 38%의 중요 엔드포인트에 인증이 없었고 43%에 명령 실행 취약점이 있었다고 보고했다.

실무적으로 달라지는 것은 책임 소재와 점검 위치다. 인증 게이트웨이를 붙였다는 사실은 출발점일 뿐이고, CI 게이트·도구 격리·Manifest 차이 리뷰·행동 기준선 같은 조작 가능한 통제를 각 팀이 자기 경계에서 강제해야 한다. 이 프레임워크가 엄밀한 분류 체계는 아니라는 점, 실행 환경을 강화해도 취약한 아웃바운드 경로는 그대로 남고 Manifest를 고정해도 검사기 신원이 증명되지는 않는다는 점은 전제로 깔려 있다. 규격은 나중에 따라오겠지만 프로덕션은 기다릴 수 없다는 것이 이 제안의 입장이다.