MCP 최신 사양 기준
IT/AI · 보안
MCP 보안 취약점, 직접 확인했습니다
— 생각보다 위험했습니다
AI 에이전트가 확산되면서 MCP(Model Context Protocol)를 연결하는 개발자가 급증하고 있습니다. 그런데 공식 사양을 직접 읽어보니, 대부분의 블로그가 말하지 않은 구조적 허점이 여러 개 있었습니다.
(ZeroLeaks 실험)
인증(Auth) 처리 수준
활성 MCP 서버 수
MCP가 뭔지부터 — 왜 지금 이게 문제가 됐나
MCP(Model Context Protocol)는 Anthropic이 2024년 말 공개한 오픈 표준입니다. LLM이 외부 툴이나 데이터 소스에 연결되는 방식을 규격화해, 개발자가 여러 AI 클라이언트에 맞게 각각 연동 코드를 짜지 않아도 되게 만든 거예요. 덕분에 GitHub, Slack, Notion, Spotify 같은 서비스에 AI 에이전트를 붙이는 게 훨씬 쉬워졌습니다.
확산 속도가 빠릅니다. 2026년 3월 현재 Pulse MCP 서버 디렉터리에 등록된 활성 서버만 4,300개가 넘습니다. (출처: CIO Korea, 2025.06) 문제는 이 숫자가 빠르게 늘어나는 만큼, 검증되지 않은 서버도 같이 늘어나고 있다는 점이에요.
MCP 클라이언트(예: Claude Desktop, Cursor)가 MCP 서버를 통해 데이터 소스에 연결되는 구조에서, 서버 하나가 뚫리면 연결된 서비스 전체가 영향을 받을 수 있습니다. 필라 시큐리티 CEO 도르 사리그는 이를 “왕국의 열쇠”라고 표현했고, 실제로 MCP 서버에는 인증 토큰과 외부 서비스 실행 권한이 집중돼 있습니다. (출처: CIO Korea, 2025.06)
공식 사양에서 “인증은 선택”이라고 나옵니다
💡 공식 발표문과 실제 구현 흐름을 같이 놓고 보니 이런 차이가 보였습니다 — 대부분의 설명글은 OAuth를 쓴다고 소개하지만, 공식 사양 원문에는 “선택”이라고 명시돼 있습니다.
MCP 공식 인증 사양 원문을 직접 확인했습니다. 첫 줄에 이렇게 나옵니다.
“Authorization is OPTIONAL for MCP implementations.”
(출처: MCP 공식 인증 사양 — modelcontextprotocol.io/specification/draft/basic/authorization)
인증이 강제 사항이 아닙니다. “HTTP 기반 트랜스포트를 쓰는 구현체는 SHOULD 준수”이고 STDIO 트랜스포트에서는 이 사양 자체를 따르지 않도록 명시돼 있습니다. 즉, 수천 개의 MCP 서버 중 얼마나 많은 서버가 실제로 인증을 구현했는지는 서버 개발자 각자의 판단에 달려 있습니다.
이건 꽤 중요한 차이입니다. “MCP는 OAuth를 쓴다”라는 설명이 많지만, OAuth를 쓴다고 해서 곧 인증이 된다는 뜻이 아니에요. 실제 커뮤니티에서도 현재 OAuth 권한 부여 사양이 기업 환경의 관행과 충돌하는 구현 세부사항을 포함하고 있다는 지적이 나왔고, 이를 개선하는 PR이 진행 중입니다. (출처: Red Hat 공식 블로그, 2025.07)
프롬프트 인젝션 성공률 91.3% — 실험 수치로 확인했습니다
💡 보안 평가 도구로 직접 테스트한 결과가 공개됐습니다 — 숫자가 예상보다 훨씬 높았습니다.
스페인의 보안 연구자 루카스 발부에나는 AI 보안 평가 도구 ‘ZeroLeaks’를 활용해 오픈클로(OpenClaw) 기반 MCP 환경을 테스트한 결과를 공개했습니다. 프롬프트 인젝션 공격 성공률 91.3%, 시스템 프롬프트 추출 성공률 84.6%였고, 종합 보안 점수는 100점 만점에 2점이었습니다. (출처: 조선비즈 IT, 2026.02.05)
| 공격 유형 | 성공률 | 의미 |
|---|---|---|
| 프롬프트 인젝션 | 91.3% | 자연어 명령으로 AI 판단 왜곡 |
| 시스템 프롬프트 추출 | 84.6% | 내부 규칙·역할 정의 노출 |
| 종합 보안 점수 | 2 / 100 | ZeroLeaks 기준 최하위 |
성공률 91.3%가 뜻하는 건 간단합니다. 외부에서 들어온 문장 하나가 AI의 판단을 바꿀 수 있는 경우가 10번 중 9번 이상이라는 겁니다. 기존 서버 사이드 보안 점검이나 WAF로는 이런 공격을 잡기 어렵습니다. 코드에 취약점이 없어도, AI가 해석하는 ‘의미’ 자체가 조작되기 때문이에요.
Cisco AI 위협·보안 연구팀은 이런 구조를 “기능적으로는 혁신적이지만, 보안 관점에서는 악몽에 가깝다”고 평가했습니다. AI 에이전트가 이메일, 문서, 메시지에 동시에 접근하면서 외부 입력도 계속 받는 구조 자체가 문제라는 지적입니다. (출처: 조선비즈 IT, 2026.02.05)
“확인 버튼”이 있어도 막지 못한 이유
💡 사용자 승인 단계가 있다고 안전한 건 아닙니다 — WhatsApp 채팅 내역을 유출한 실험에서 실제로 확인됐습니다.
Invariant Labs가 공개한 실험 결과가 흥미롭습니다. 연구팀은 Cursor(MCP 클라이언트)에 신뢰할 수 있는 WhatsApp MCP 서버와 공격자가 만든 악성 MCP 서버를 동시에 연결했습니다. 악성 서버는 처음에는 “오늘의 랜덤 상식” 같은 완전히 무해한 툴 설명을 보여줍니다. 사용자가 승인하면, 두 번째 실행부터 툴 설명이 바뀌어 AI 에이전트의 행동 전체를 재프로그래밍합니다. (출처: Invariant Labs 공식 블로그)
결과는 WhatsApp 채팅 전체 내역 유출이었습니다. 그리고 사용자에게 보이는 “툴 실행 확인 다이얼로그”는 이렇게 표시됩니다.
- 수신자: 조작된 전화번호 (연락처 목록 없이는 알기 어려움)
- 메시지 내용: ‘Hi’ — 하지만 오른쪽으로 스크롤하면 유출 페이로드가 숨겨져 있음
현대 UI는 스크롤바를 숨기는 디자인이 많아, 메시지가 잘려 보이더라도 사용자가 전체 내용을 확인하지 않는 경우가 많습니다. 승인 버튼을 눌러도 공격이 완성되는 구조입니다. (출처: Invariant Labs 공식 블로그)
설치 당시엔 정상이었던 MCP 서버가 바뀌는 경우
💡 툴 설명이 업데이트로 바뀌어도 재승인을 요구하지 않는 클라이언트가 많습니다 — 이 부분은 아직 많은 MCP 클라이언트에서 해결되지 않은 문제입니다.
이른바 ‘러그풀(rug-pull)’ 공격입니다. 처음 설치한 MCP 서버가 소스 코드 변경 없이, 혹은 업데이트를 통해 나중에 악성으로 바뀌는 시나리오예요. Red Hat 공식 블로그는 이 위험을 직접 기술했습니다. 원래 날씨 정보를 수집하는 툴이 업데이트 후에는 기밀 정보를 수집해 공격자에게 전송하도록 변경될 수 있다는 겁니다. (출처: Red Hat 공식 블로그, 2025.07)
Invariant Labs의 실험에서도 이 방식이 실제로 작동했습니다. 처음엔 완전히 정상적인 툴 설명을 보여주다가, 두 번째 서버 실행 시점부터 악성 지시가 포함된 설명으로 전환했습니다. 슬리퍼(sleeper) 공격이라고 부르는 방식입니다. 시간대나 특정 사용자 그룹에서만 활성화되도록 설계하면 탐지가 더 어려워집니다.
메시지 하나만으로도 공격이 가능한 케이스도 확인됐습니다. Experiment 2에서 연구팀은 악성 MCP 서버를 설치하지 않고, 공격 대상에게 조작된 WhatsApp 메시지 하나를 보내는 것만으로 해당 사용자의 연락처 목록 전체를 유출하는 데 성공했습니다. (출처: Invariant Labs 공식 블로그) 외부에서 들어오는 데이터가 곧 AI 에이전트에게는 ‘명령’처럼 해석될 수 있다는 게 핵심입니다.
실제로 적용 가능한 방어 체계 — 공식 권고 기준
공식 권고와 보안 연구팀의 실험 결과를 교차 정리하면, 지금 당장 적용할 수 있는 방어 방법은 크게 네 가지로 압축됩니다.
MCP 서버 버전 고정
설치 후 코드나 구성이 바뀌면 사용자에게 알림이 가도록 설정하세요. 클라이언트 수준에서 버전을 핀(pin)해두면 러그풀 공격을 상당 부분 차단할 수 있습니다. (출처: Red Hat 공식 블로그)
최소 권한 원칙
API 토큰과 컨텍스트 토큰은 유효 기간을 짧게 설정하고, 해당 작업에 필요한 최소 권한만 부여해야 합니다. 토큰이 하나 탈취돼도 피해 범위가 제한됩니다. (출처: CIO Korea)
로컬 서버 샌드박스 실행
로컬 MCP 서버는 명시적으로 허용된 실행과 파일 접근만 가능하도록 샌드박스 환경에서 운영하는 게 좋습니다. (출처: Red Hat 공식 블로그)
MCP 활동 로깅 필수
데이터 접근 요청, 인증 실패, 설정 변경을 모두 로그로 남기고 정기적으로 검토해야 합니다. 사후 대응의 유일한 수단이 됩니다. (출처: CIO Korea)
개인 사용자라면 현재 오픈클로(OpenClaw)처럼 개인정보, 금융정보, 협업 도구를 한꺼번에 연동하는 환경은 피하는 게 바람직합니다. 기업 환경이라면 DLP(데이터 유출 방지) 솔루션이 MCP 에이전트의 우회 경로가 될 수 있다는 지적도 있으니, 현행 DLP 설정을 함께 점검하는 게 좋습니다.
Q&A
MCP 서버를 직접 만들지 않고 가져다 쓰는 경우에도 위험한가요?
네, 오히려 더 주의가 필요합니다. 외부에서 만들어진 MCP 서버는 소스 코드를 직접 검토하기 어렵고, 업데이트 이후 내용이 바뀌어도 클라이언트가 알림을 주지 않는 경우가 많습니다. 공신력 있는 출처에서 배포된 서버라도 버전을 고정해 두는 게 좋습니다.
Claude Desktop이나 Cursor처럼 유명한 클라이언트도 이 공격에 노출되나요?
Invariant Labs의 실험은 Cursor를 대상으로 수행됐고, 공격이 성공했습니다. Claude Desktop도 같은 실험 환경에서 테스트됐습니다. 클라이언트 자체의 문제라기보다는 MCP 프로토콜의 구조적 특성에서 비롯된 문제라, 특정 클라이언트만 예외가 되기 어렵습니다.
MCP-Scan 같은 스캐너를 쓰면 완전히 막을 수 있나요?
현재 시점에서 완전한 방어는 어렵습니다. MCP-Scan은 알려진 취약 패턴을 탐지하는 도구이고, 사전에 확인되지 않은 공격 방식은 잡지 못할 수 있습니다. 스캐너는 방어 체계의 일부로 활용하되, 최소 권한 설정, 로깅, 버전 고정과 함께 운영하는 게 현실적입니다.
Anthropic은 이 문제를 인지하고 있나요?
Claude 3.7 Sonnet 시스템 카드에서 컴퓨터 사용 시 발생하는 프롬프트 인젝션 공격 위험과 평가 방법, 저항 훈련 방식을 명시했습니다. (출처: Anthropic 공식 블로그, 2025.02.24) 단, 프로토콜 수준의 근본적인 해결보다는 모델 훈련으로 저항력을 높이는 방향에 초점이 맞춰져 있습니다.
개인 사용자가 지금 당장 할 수 있는 가장 효과적인 조치 하나만 꼽는다면?
연동 범위 축소입니다. Google 계정, Slack, Notion, 이메일을 동시에 MCP에 연결하는 설정은 피하세요. 외부 입력 하나가 여러 서비스에 연쇄적으로 작동하는 구조 자체가 위험 면적을 키웁니다. 하나씩 필요한 서비스만 연결하고, 쓰지 않을 때는 연결을 해제하는 게 가장 현실적인 방법입니다.
마치며
MCP는 분명히 편리하고 강력한 표준입니다. 문제는 이 편리함이 “설치하면 연결되는” 느낌을 주면서, 그 아래에 깔린 구조적 위험을 잘 드러내지 않는다는 점이에요.
공식 사양에서 인증이 선택 사항이라는 것, 프롬프트 인젝션 성공률이 91%를 넘는 실험 수치, 악성 MCP 서버가 설치 당시엔 정상으로 보이다가 이후에 바뀌는 슬리퍼 구조, 그리고 메시지 하나만으로도 연락처 전체가 유출된 실험까지 — 이 모든 게 2025~2026년에 실제로 문서화된 내용입니다.
MCP를 쓰지 말라는 게 아닙니다. 다만 “연결됐으니 괜찮다”는 가정은 지금 시점에서 위험합니다. 연동 범위를 최소화하고, 버전을 고정하고, 로그를 남기는 것. 이 세 가지가 지금 당장 할 수 있는 가장 현실적인 방어입니다.
본 포스팅 참고 자료
⚠️ 본 포스팅은 2026년 3월 29일 기준으로 작성됐습니다. MCP 프로토콜 사양, 클라이언트 동작 방식, 보안 연구 결과는 이후 업데이트로 달라질 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으며, 보안 관련 결정은 반드시 최신 공식 문서와 전문가의 검토를 함께 참고하시기 바랍니다.
댓글 남기기