불과 1년 전만 해도 "AI 보안"은 직원이 ChatGPT 채팅창에 뭘 붙여넣느냐의 문제였습니다. 지금은 다릅니다. Claude Desktop, Cursor, Claude Code를 쓰는 개발팀에서는 AI가 채팅창을 넘어 로컬 파일 시스템, GitHub 저장소, Slack, 데이터베이스, 터미널에 직접 손을 뻗습니다. 그 통로가 바로 MCP(Model Context Protocol)입니다.
문제는 이겁니다. 대부분의 회사는 "우리 개발자 PC의 Claude Desktop에 지금 어떤 MCP 서버가 붙어 있고, 그게 어디까지 접근할 수 있는가?"라는 질문에 한 명도 답하지 못합니다. 이 글은 그 질문에 스스로 답하도록 돕습니다. 30분이면 됩니다.
MCP는 편의를 위해 과도한 권한을 기본값으로 갖는 경우가 많다. 위험은 "AI를 쓰는 것"이 아니라 "AI 에이전트가 무엇을 할 수 있는지 아무도 모르는 것"이다. 답은 금지가 아니라 가시성과 권한 통제다.
MCP가 뭐길래 보안 사각인가
MCP는 AI 애플리케이션(호스트)이 외부 도구·데이터(서버)에 표준화된 방식으로 연결하는 프로토콜입니다. Claude Desktop이 로컬 파일을 읽고, Cursor가 GitHub PR을 만들고, 에이전트가 Slack에 메시지를 보내는 일이 전부 MCP 서버를 통해 일어납니다.
기존 DLP(데이터 유출 방지)나 SWG(보안 웹 게이트웨이)가 이걸 못 보는 이유는 구조적입니다. 그런 솔루션은 브라우저와 네트워크 트래픽을 감시하도록 설계됐습니다. 그런데 MCP 서버 상당수는 stdio 기반으로 로컬에서 동작합니다. 즉 개발자 PC 안에서 프로세스 대 프로세스로 오가는 접근이라, 네트워크 계층에서는 보이지 않습니다.
웹 트래픽만 보는 보안으로는 Claude Desktop의 로컬 MCP 서버도, Cursor가 여는 저장소도 보이지 않는다. 이건 설정의 문제가 아니라 아키텍처의 사각지대다.
개발팀이 실제로 마주하는 MCP 위험 5가지
추상적인 "위험"이 아니라, 실제 claude_desktop_config.json에서 흔히 발견되는 다섯 가지 구체적 패턴입니다.
1. filesystem 서버가 홈 디렉토리 전체에 접근
가장 흔하고 가장 위험합니다. filesystem MCP 서버를 /Users/<name> 같은 넓은 경로로 열어두면, AI 에이전트가 프로젝트 폴더뿐 아니라 SSH 키, .env, 다운로드 폴더의 계약서, 다른 회사 프로젝트까지 읽을 수 있습니다.
2. write 권한을 가진 GitHub·저장소 서버
읽기만 해도 위험한데 repo:write 스코프까지 있으면, 프롬프트 인젝션 한 번에 에이전트가 코드를 커밋하거나 PR을 만들 수 있습니다. AI가 만든 PR에 취약 코드나 백도어가 섞일 여지가 생깁니다.
3. env에 평문으로 박힌 API 키
MCP 서버 설정의 env 블록에 ghp_…, sk-…, AWS 키가 평문으로 들어가는 경우가 매우 흔합니다. 이 설정 파일이 백업·동기화·실수로 커밋되는 순간 키가 유출됩니다.
4. 출처 불명의 custom 바이너리
command: "./run.sh"처럼 로컬 스크립트나 검증되지 않은 npm 패키지를 MCP 서버로 실행하면, 그 코드가 개발자 권한으로 무엇이든 할 수 있습니다. 공급망 위험이 그대로 데스크톱으로 들어옵니다.
5. 원격 MCP + OAuth + write
외부 remote MCP 서버에 OAuth로 연결하고 write 권한까지 부여하면, 그 외부 서비스가 회사 데이터에 상시 접근하는 통로가 됩니다. tool poisoning, 데이터 exfiltration의 표적이 됩니다.
내 PC의 MCP 서버 직접 점검하는 법
솔루션을 도입하기 전에, 지금 당장 손으로 확인할 수 있습니다. 핵심은 설정 파일이 어디 있는지 아는 것입니다.
Claude Desktop (macOS):
~/Library/Application Support/Claude/claude_desktop_config.jsonCursor / VS Code 계열은 프로젝트 루트의 .cursor/mcp.json 또는 사용자 설정에, Claude Code는 프로젝트별 설정과 ~/.claude 하위에 둡니다. 파일을 열어 mcpServers 블록을 보면 됩니다.
파일을 열었다면 다음 세 가지만 먼저 보세요.
- 경로 범위 — filesystem류 서버의
path가 프로젝트 폴더로 좁혀져 있는가, 아니면 홈 전체인가? - 스코프 — 각 서버가 read-only인가, write까지 가능한가?
- 시크릿 —
env에 평문 키·토큰이 박혀 있는가?
이 세 가지를 서버 개수만큼 반복하면 됩니다. 서버가 2~3개면 손으로 충분합니다. 문제는 팀 규모가 커지고, 개발자마다 다르고, 어제 없던 서버가 오늘 붙는다는 점입니다. 그때부터는 자동화가 필요합니다.
MCP 위험도를 판정하는 기준
점검을 반복 가능하게 만들려면 판정 기준이 있어야 합니다. 타이거쉴드가 쓰는 4단계 기준을 공유합니다.
- LOW 공식 MCP + read-only + 특정 폴더로 제한
- MEDIUM custom 서버 + GitHub read, 또는 검증됐지만 넓은 read 범위
- HIGH filesystem이 홈 전체, 또는 외부 remote + OAuth + write
- CRITICAL 출처 불명 바이너리 + env에 평문 API 키, 또는 write 권한 + 광범위 접근 결합
핵심은 "AI를 쓰느냐"가 아니라 접근 범위 × 권한 × 출처의 조합으로 위험을 본다는 것입니다. 같은 GitHub 서버라도 read-only 특정 저장소면 Low, write 전체면 High입니다.
팀 단위로 지속 통제하는 법
한 번의 점검은 스냅샷일 뿐입니다. 진짜 통제는 세 가지를 상시로 돌리는 것입니다.
- 인벤토리 — 팀 전체의 MCP 서버·권한·시크릿을 한 화면에서. 누가 무엇에 접근 가능한지.
- 변경 감시 — 새 MCP 서버가 붙으면 즉시 알림. allowlist 밖의 서버는 차단하거나 승인 요청.
- 증적 — 무엇을 언제 통제했는지 로그. 단, 프롬프트·파일 원문은 저장하지 않고 메타데이터만.
여기서 마지막 원칙이 중요합니다. 개발자를 감시하는 도구가 되면 팀이 우회합니다. 통제는 사람이 아니라 데이터와 권한에만 걸어야 하고, 프롬프트 원문은 아예 서버로 보내지 않는 설계여야 합니다. 그래야 도입 저항이 사라집니다.
네트워크 게이트웨이가 못 보는 로컬 MCP 설정을 엔드포인트에서 직접 스캔합니다. Claude Desktop·Cursor·Claude Code에 붙은 서버·권한·시크릿을 위험 점수화하고, 새 서버가 붙으면 알립니다. 프롬프트 원문은 저장하지 않습니다. — MCP Scanner 자세히 보기
30초 체크리스트
- 우리 팀이 쓰는 AI 도구(Claude Desktop·Cursor·Claude Code)를 나열했는가?
- 각 도구의 MCP 설정 파일 위치를 아는가?
- filesystem류 서버의 경로가 프로젝트로 좁혀져 있는가?
- write 권한을 가진 서버를 파악했는가?
env에 평문 API 키가 없는가?- 출처 불명의 custom 서버·바이너리가 없는가?
- 새 MCP 서버가 붙었을 때 알 방법이 있는가?
세 개 이상 "아니오"라면, 지금이 점검을 시작할 때입니다.