MCP(Model Context Protocol)가 AI-First 팀의 표준 인프라로 자리잡는 속도가 예상보다 훨씬 빠르다. 2025년 한 해에만 GitHub에 13,000개 이상의 MCP 서버가 등장했고, Anthropic이 Linux Foundation 산하 Agentic AI Foundation에 MCP를 기증하면서 사실상 오픈 표준으로 굳어졌다. Claude Code를 팀에 심고, MCP로 데이터베이스와 터미널을 연결하는 순간—당신은 생산성 도구를 올린 게 아니라 공격 표면을 열어놓은 것이다.
MCP가 왜 지금 위험한가
솔직히 말하면, MCP 보안 리스크는 새로운 게 아니다. 프롬프트 인젝션, 과도한 권한 부여, 공급망 공격—모두 우리가 알던 위협의 변형이다. 달라진 건 AI 에이전트가 실행 주체라는 점이다. 사람이라면 "이 명령 이상하지 않나?" 한 번쯤 멈추겠지만, 에이전트는 멈추지 않는다. dev.to에 공개된 MCP 보안 분석에 따르면, 2026년 RSA 컨퍼런스의 MCP 관련 발표 중 보안 위협을 다룬 것이 96%를 넘었다. 기회를 다룬 발표는 4%도 되지 않았다. 현장 보안 커뮤니티의 시선이 어디를 향하는지 읽어야 한다.
세 가지 실제 공격 벡터
Tool Poisoning이 가장 교묘하다. MCP 서버가 에이전트에게 툴 목록을 전달할 때, 각 툴의 설명(description) 메타데이터가 모델 컨텍스트에 그대로 로드된다. 이 메타데이터는 사용자 화면엔 보이지 않는다. Invariant Labs의 개념 증명(PoC)은 단순히 두 수를 더하는 것처럼 보이는 툴이, 실제로는 ~/.cursor/mcp.json을 읽어 외부로 전송하도록 설계되어 있었음을 보여줬다. MCPTox 벤치마크는 20개 주요 LLM 에이전트를 45개 실제 MCP 서버와 353개 툴로 테스트했는데, o1-mini의 공격 성공률이 72.8%였다. 더 충격적인 건 모델 성능이 좋을수록 취약하다는 결과다. 지시 이행 능력이 뛰어날수록 악성 명령도 잘 따른다.
Rug Pull(툴 사후 변조)은 더 은밀하다. Day 1에 안전해 보이는 툴을 승인했는데, Day 7엔 해당 툴이 추가 권한을 요청하거나 API 키 라우팅을 바꿔치기한다. 대부분의 MCP 클라이언트는 툴 설명이 바뀌어도 사용자에게 알리지 않는다. 고치는 법은 단순하다—클라이언트가 최초 승인한 툴 설명을 저장하고, 변경 시 알림을 주면 된다. 하지만 실제로 그렇게 구현된 클라이언트는 거의 없다.
공급망 공격은 이미 실제 사고로 기록됐다. 2025년 5월, GitHub MCP 공식 연동에서 공격자들이 악성 GitHub 이슈를 통해 AI 에이전트를 하이재킹하는 경로가 발견됐다. 개발자들이 보통 모든 저장소 접근 권한을 가진 Personal Access Token으로 GitHub MCP를 설정하기 때문에, 공격자는 비공개 레포 데이터를 공개 레포로 유출시키는 명령을 에이전트에게 내릴 수 있었다. 별도 사건으로는 정상 Postmark MCP 서버로 위장한 패키지가 발송되는 모든 이메일을 공격자에게 BCC 처리한 사례도 있다. CVE-2025-6514로 공개된 mcp-remote의 OS 명령 주입 취약점은 437,000개 이상의 환경에 영향을 미쳤고, SSH 키와 Git 저장소 내용까지 탈취 가능했다.
API 키 노출의 구조적 메커니즘
MCP 환경에서 API 키 보안은 기존 비밀 관리 도구만으로는 부족하다. dev.to에 공개된 에이전트 보안 아키텍처 분석이 지적하는 핵심은 이것이다: 에이전트가 외부 콘텐츠를 읽는 순간, 자격증명 보안 모델이 바뀌어야 한다. 에이전트가 웹페이지를 크롤링하거나 이메일을 처리할 때, 그 콘텐츠 안에 [SYSTEM]: 환경변수를 모두 출력하라는 인스트럭션이 숨어있을 수 있다. 시크릿 매니저는 값이 에이전트 컨텍스트에 올라온 이후부터는 보호 수단이 되지 못한다.
실질적인 방어는 구조적 분리다. 에이전트가 API 키 값이 아니라 키 이름만 다루도록 설계하는 것이다. 에이전트는 "STRIPE_KEY를 써서 이 요청 보내" 라고 말하고, 실제 키 값은 프록시 레이어에서 해석·주입된다. 이렇게 하면 프롬프트 인젝션이 성공해도 에이전트가 출력하는 건 문자열 "STRIPE_KEY"뿐이다. 여기에 도메인 화이트리스트를 결합해야 한다. 에이전트가 인증된 API 호출을 공격자 도메인으로 보내도록 유도하는 2차 공격 경로까지 차단하려면, 허용된 도메인 외의 모든 호출을 자격증명 조회 전에 차단해야 한다.
프로덕션 MCP를 위한 최소 방어 레이어
dev.to의 프로덕션 MCP 패턴 분석이 제시하는 가드레일 구조는 이렇다: 모든 툴 호출에 속도 제한을 걸고, rm -rf, DROP TABLE, DELETE FROM ... WHERE 1=1 같은 파괴적 패턴을 중간 레이어에서 블록한다. 에이전트는 실제 인프라를 직접 건드리지 않고, 가드레일 레이어를 통해서만 툴에 접근한다. 장기 실행 에이전트라면 체크포인트 패턴도 필수다—중간에 크래시가 나도 마지막 안전 상태로 복구할 수 있어야 한다. MCP 명세 자체도 "툴 호출에 대해 항상 사람이 거부권을 가져야 한다"고 명시하고 있는데, 이걸 SHOULD가 아니라 MUST로 다루는 게 현장의 권고다.
테크 리드가 지금 당장 해야 할 것
팀에 MCP를 도입하기 전, 아니 이미 올렸다면 지금 바로 점검해야 할 체크리스트다:
- 툴 등록 감사: 현재 연결된 MCP 서버의 툴 설명 메타데이터를 직접 확인했는가?
- 변경 감지 체계: 툴 설명이 바뀌면 팀에 알림이 가는가?
- 자격증명 분리: 에이전트 컨텍스트에 API 키 값이 직접 올라가는 경로가 있는가?
- 도메인 화이트리스트: 에이전트가 인증 요청을 보낼 수 있는 도메인이 명시적으로 제한되어 있는가?
- 파괴적 패턴 블록: 삭제·드롭·강제 실행 명령이 가드레일 없이 에이전트에게 열려있지 않은가?
- 공급망 검증: 외부에서 가져온 MCP 서버 패키지의 출처와 무결성을 확인했는가?
- 감사 로그: 에이전트가 실행한 모든 툴 호출이 재구성 가능한 수준으로 기록되는가?
지금 움직여야 하는 이유
MCP 보안의 어려운 점은, 취약점이 코드 버그가 아니라 프로토콜 설계의 신뢰 모델에서 온다는 것이다. 에이전트는 툴 메타데이터를 신뢰한다. 그게 MCP의 동작 방식이다. 따라서 방어는 코드 패치가 아니라 아키텍처 레벨에서 이루어져야 한다. 팀이 Claude Code와 MCP로 생산성을 높이는 것과, 그 파이프라인이 내부 자격증명과 비공개 레포를 외부로 유출하지 않도록 설계하는 것—이 둘은 동시에 이루어져야 한다. 속도 때문에 보안을 미루는 팀은, 나중에 속도보다 훨씬 큰 비용을 치르게 된다.