MCP(Model Context Protocol)는 AI 에이전트와 외부 도구를 잇는 'USB-C 포트'로 불릴 만큼 빠르게 표준으로 자리잡고 있다. Composio가 500개 이상, Paragon이 130개 이상의 커넥터를 제공하는 지금, MCP 생태계의 확산 속도는 보안 설계가 따라가기 버거울 정도다. 문제는 이 연결의 편리함이 그대로 공격 표면이 된다는 점이다.
핵심 이슈: 세 가지 구조적 취약점
dev.to에 공개된 MCP 보안 분석에 따르면, 현재 MCP 서버 구현에서 반복적으로 발견되는 취약점은 크게 세 가지다. 첫째, Command Injection — 입력값을 제대로 검증하지 않고 셸 명령을 실행하는 MCP 서버는 악의적인 프롬프트 한 줄로 임의 명령이 실행된다. 둘째, SSRF(Server-Side Request Forgery) — LLM이 제공한 URL을 그대로 HTTP 요청에 사용하면 내부 서비스나 클라우드 메타데이터에 접근하는 경로가 열린다. 셋째, 임의 파일 접근 — 파일 시스템 권한이 있는 서버는 SSH 키, 환경변수, 자격증명까지 읽히거나 악성 내용이 쓰일 수 있다.
이 취약점들의 공통점은 'MCP 서버가 너무 많은 것을 할 수 있다'는 설계 문제에서 비롯된다는 것이다. 편의를 위해 넓게 열어둔 권한이 곧 공격 경로가 된다.
맥락 해석: API를 MCP로 변환하면 무슨 일이 벌어지나
더 구체적인 위험은 실제 API를 MCP 도구로 변환하는 과정에서 드러난다. 한 개발자가 Stripe, GitHub, Slack 등 10개의 주요 API를 MCP 도구로 변환해 파괴적 엔드포인트를 집계한 결과가 충격적이다. 10개 API 전체에서 300개 이상의 파괴적 엔드포인트(DELETE, 취소, 접근 권한 해제 등)가 존재했고, 이 중 공식 MCP 서버를 제공하는 서비스는 단 하나도 없었다.
Stripe 하나만 봐도 delete_customer, cancel_subscription, void_invoice 등 47개의 DELETE 엔드포인트가 있다. 에이전트에게 '테스트 데이터 정리'를 맡겼다가 라이브 구독이 취소되는 상황, GitHub에서 '조직 정리'를 시켰다가 레포지토리가 삭제되는 상황은 상상이 아니라 실제로 일어날 수 있는 일이다. 에이전트 입장에서 get_customer와 delete_customer는 그냥 '도구 목록의 두 항목'일 뿐이기 때문이다.
여기엔 보너스로 따라오는 문제가 하나 더 있다. MCP 도구 정의 하나당 200~500 토큰을 차지하는데, Stripe의 314개 엔드포인트를 전부 로드하면 도구 메타데이터만으로 6만~15만 토큰이 소비된다. Perplexity CTO가 공개적으로 지적했듯, MCP 도구 설명이 컨텍스트 윈도우의 40~50%를 잡아먹는 상황에서 에이전트는 실제 작업을 시작하기도 전에 이미 느려진다. 안전성과 성능, 두 문제의 해법이 같다 — 로드하기 전에 필터링하라.
시사점: 설계 원칙 세 가지
이 문제들을 프론트엔드 개발자 관점에서 정리하면, 결국 '에이전트에게 무엇을 쥐여줄 것인가'를 의도적으로 설계해야 한다는 결론으로 수렴한다.
1. 권한은 최소로, 범위는 명시적으로
MCP 서버 구성에서 매니페스트 기반 권한 모델을 적용하는 것이 기본이다. 허용 경로, 최대 파일 크기, 네트워크 접근 여부를 명시적으로 선언하고, 기본값은 항상 읽기 전용으로 출발해야 한다. 쓰기·삭제 권한은 세션 단위로 명시적으로 부여하고, 시간 제한 토큰을 활용하는 것이 좋다. gVisor나 Firecracker 같은 샌드박싱 도구로 신뢰할 수 없는 MCP 서버를 격리하는 것도 프로덕션 환경에서는 선택이 아닌 필수다.
2. 도구 로드 전에 위험 분류를 자동화하라
OpenAPI 스펙을 MCP 도구로 변환할 때 HTTP 메서드, 엔드포인트 패턴(/cancel, /revoke, /destroy), 뮤테이션 의미론을 기준으로 safe / moderate / destructive를 자동 태깅하고, --max-risk moderate 같은 플래그로 파괴적 도구를 아예 로드하지 않는 방식이 현실적이다. 314개 대신 267개, 실제로 필요한 결제 관련 도구만 25개를 로드하는 것이 에이전트를 더 안전하고 빠르게 만든다.
3. 감사 자동화로 재현 가능한 보안 루틴을 만들어라
Claude Code Custom Skill로 보안 감사를 자동화한 사례는 이 방향의 좋은 예시다. /security-audit all 한 줄로 Next.js, Vercel, Supabase, iOS에 걸친 6단계 감사가 재현 가능하게 실행된다. 핵심은 Chrome MCP를 활용해 CLI로는 접근할 수 없는 대시보드 설정(Vercel의 Deployment Protection, Supabase Auth의 MFA·이메일 확인 설정 등)까지 자동으로 검사한다는 점이다. OWASP Top 10:2025, WSTG, MASVS v2를 그대로 기준으로 삼아 팀과 외부 리뷰어가 공통 언어를 쓸 수 있게 한 설계도 눈여겨볼 만하다. '보안 점검을 언젠가 해야지'에서 '지금 바로 실행 가능한 루틴'으로 바꾸는 것이 핵심 가치다.
전망: 생태계가 클수록 설계 규율이 먼저다
MCP 생태계는 계속 빠르게 성장할 것이다. 그리고 에이전트가 더 많은 도구에 연결될수록, '연결 가능하다'와 '연결해야 한다'를 구분하는 판단이 개발자의 책임이 된다. 2026년 엔터프라이즈 환경에서는 모든 도구 호출에 대한 감사 추적, SSO 통합 인증, 게이트웨이 기반 요청 필터링이 사실상 필수 요건으로 자리잡을 것이다.
AI 에이전트를 프로덕션에 붙이는 일은 이제 낯선 실험이 아니다. 하지만 에이전트가 손에 쥔 도구 목록을 누가, 어떤 기준으로 설계하느냐는 여전히 개발자의 몫이다. 편리함은 생태계가 제공하지만, 안전은 설계에서 나온다.