MCP 허용 목록만으론 못 막는 소스코드 유출, 입력단 방어법

개발자 커뮤니티에서는 MCP 호출을 허용할 서버 목록으로 관리하고 클로드 코드를 쓰는 정도로는 사내 정보 유출을 막기에 부족하다는 이야기가 나왔다. 문제는 도구 호출 단계가 아니라 프롬프트가 외부 모델로 넘어가기 전 입력 단계에 있다. 그 앞에 프록시를 세워 정책을 적용해야 한다는 논의였다. 실제로 그런 구조가 시장에 있는지, 개인 개발자나 서너 명 팀도 손댈 수 있는 수준인지 확인했다.

MCP 도구 대부분이 데이터에 직접 읽기 권한을 갖는다

MCP 보안을 다룬 CIO코리아 보도에 따르면 조사 대상 MCP 도구의 90% 이상이 연결된 데이터 소스에 직접 읽기 권한을 갖고 있었다. 인터넷에 노출된 MCP 서버 1862대 가운데 표본으로 수동 검증한 119대는 전부 인증 없이 내부 도구 목록에 접근을 허용했다. 별도 조사에서 테스트한 구현체의 43%는 명령어 주입 취약점을, 30%는 URL을 제한 없이 가져오는 SSRF 취약점을 갖고 있었다.

허용된 MCP 서버만 쓰게 막아도 위험이 남는 이유는 따로 있다. 보안 연구업체 제너럴 애널리시스가 공개한 2025년 시연에서는, 서비스형 데이터베이스에 연결된 커서 에이전트가 관리자급 권한으로 지원 티켓을 처리하다 티켓에 심어진 지시를 실행해 통합 토큰을 공격자가 볼 수 있는 지원 티켓에 노출했다. 사용자가 직접 입력한 명령이 아니라 에이전트가 읽어들인 외부 콘텐츠에 숨은 지시였다는 점에서, MCP 서버 허용 목록 관리만으로는 걸러지지 않는 경로였다.

삼성 챗GPT 사고가 확인해 준 입력 단계의 무게

입력 단계가 왜 핵심인지는 2023년 삼성전자 사례가 잘 보여준다. DS부문 직원들이 소스코드 오류 확인과 회의록 요약을 위해 챗GPT에 코드와 회의 내용을 입력했다가 사내 기밀이 외부로 넘어갔다. 회사는 외부 서버에 전송된 내용을 회수·삭제하기 어렵다고 밝히며 사내 기기와 내부망에서 생성형 AI 사용을 일시 제한했다. 이후 사내용 AI를 따로 만드는 쪽으로 방향을 틀었다.

개인정보보호위원회가 2025년 8월 내놓은 「생성형 AI 개발·활용을 위한 개인정보 처리 안내서」도 같은 지점을 짚는다. 프롬프트 입력 내용이 모델 학습에 쓰일 수 있다는 사실과 거부 방법을 이용자에게 고지하라는 요구, 그리고 학습데이터를 가명·익명 처리해도 목적 달성이 가능한 경우 수집 직후 처리하고 입출력 필터를 적용하라는 권고가 담겼다. MCP 호출보다 입력 전달 단계 통제가 핵심이라는 방의 이야기와 이 권고는 정확히 같은 지점을 가리킨다.

입력 앞단 프록시는 실제로 이렇게 동작한다

업계에서는 이런 구조를 AI 게이트웨이라 부른다. 애플리케이션과 모델 제공사 사이에 놓인 리버스 프록시가 모든 요청을 가로채 프롬프트 내용을 의미 단위로 분석한다. 개인정보나 소스코드·인증정보 패턴이 잡히면 기록만 남기거나 아예 막는 식이다. 클라우드플레어의 AI 게이트웨이 DLP 기능은 탐지 항목을 개인정보·소스코드·인증정보·재무정보·고객데이터 같은 콘텐츠 범주와, 탈옥 시도나 악성코드 요청 같은 의도 범주로 나눠 실시간으로 프롬프트와 응답 양쪽을 스캔한다.

국내에서는 세이퍼존·소만사·파수 같은 업체가 이 역할을 상용 제품으로 판다. 소만사의 웹키퍼 AI DLP는 생성형 AI 서비스 접속 통제와 개인정보 유출 방지를 묶었다. 파수의 AI-R DLP는 패턴 매칭과 자체 AI 탐지를 함께 써서 프롬프트로 나가는 데이터를 모니터링·차단한다. 다만 이런 제품은 라이선스 계약과 도입 컨설팅을 전제로 설계돼 있다. 팀 규모가 작을수록 체감 비용이 커진다.

비용 부담 없이 같은 자리에 세울 수 있는 오픈소스 대안도 있다. 라이트LLM은 무료로 셀프호스팅할 수 있는 AI 게이트웨이로, 앤트로픽을 포함한 100개 이상의 공급사를 하나의 API로 묶고 가드레일과 가상 키, 비용 추적 기능을 기본으로 제공한다. 클로드 코드나 자체 스크립트가 호출하는 API 엔드포인트를 이 프록시로만 바꿔도, 나가는 프롬프트를 한곳에서 로깅하고 걸러낼 지점이 생긴다.

클로드 코드 자체에도 잠금장치가 있다

별도 프록시를 세우기 전에 켤 수 있는 통제도 있다. 클로드 코드의 settings.json은 도구별로 allow·deny·ask 규칙을 지원한다. MCP 도구는 mcp__서버이름__도구이름 형식으로 개별 지정할 수 있다. 팀 단위라면 managed-settings.json을 MDM으로 배포해 이 규칙을 관리자만 바꿀 수 있게 고정한다. allowedMcpServers와 allowManagedMcpServersOnly를 함께 설정해 승인된 MCP 서버 외에는 연결하지 못하게 막을 수 있다. 정책 설정으로 생성형 AI 사용 자체를 제한할 수 있다는 방의 이야기가 실제로 구현돼 있는 지점이다.

MCP 서버를 여러 개 붙여 쓰는 팀이라면 도커 MCP 게이트웨이 같은 오픈소스 게이트웨이로 각 서버를 컨테이너에 격리하고 툴 단위 접근 로그를 남기는 방법도 있다. 상용 DLP를 도입하기 전에, 이미 손에 있는 도구만으로 막을 수 있는 범위가 생각보다 넓다.

기술 통제만으론 안 되는 이유

방에서는 기술적 통제만으로는 한계가 있어 임직원 교육 같은 관리적 보안이 함께 필요하다는 결론이 나왔는데, 최근 수치들도 기술적 통제 밖의 AI 사용이 늘고 있음을 보여준다. 버라이즌의 2026년 데이터 유출 조사 보고서는 사내 기기에서 비공식 AI 도구를 정기적으로 쓰는 직원 비율이 1년 새 15%에서 45%로 뛰었다고 집계했다. 페이저듀티 설문에서는 응답자의 66%가 회사 정책상 허용되지 않는다고 생각하면서도 AI 도구를 업무에 썼다고 답했다. 사이버헤이븐의 2026년 보고서에서는 AI 도구와의 상호작용 중 39.7%가 민감정보를 포함했다.

써본 조직들 사이에서는 DLP를 처음부터 차단 모드로 켜면 역효과가 크다는 의견도 많았다. 과도한 오탐이 쌓이면 보안팀이 진짜 위험 신호를 놓친다. 외부 협력사와 일하는 직원까지 차단당하면서, DLP가 유출 방지 도구가 아니라 효율을 깎는 장치로 인식된다는 지적도 나왔다. 그래서 도입 초기에는 차단 대신 기록만 남기는 모니터링 모드로 시작해 어떤 데이터가 어느 경로로 나가는지부터 확인하라는 조언이 반복됐다.

소규모 팀에게 남는 선택은 값비싼 상용 DLP를 도입하느냐가 아니라, 클로드 코드의 permission 규칙과 무료 오픈소스 게이트웨이로 어디까지 막고 어디부터는 기록만 할지를 스스로 정하는 일이다. 그 경계선을 어디에 그을지는 방에서도, 이번 조사에서도 정답이 나오지 않았다.