제목
AI 에이전트에 DB 연결했다가 등골 서늘해진 썰: MCP 보안 구멍 막는 4가지 생존 수칙
본문
요즘 개발자들 사이에서 MCP(Model Context Protocol)가 핫하죠? 저도 얼마 전, 사내 해커톤에서 Cursor와 Claude를 이용해 우리 팀의 레거시 DB와 Jira를 연동하는 'AI 에이전트'를 뚝딱 만들어봤습니다.
솔직히 처음엔 "와, 이게 되네?" 싶어서 신났습니다. 프롬프트 한 줄이면 에이전트가 SQL을 짜서 데이터를 가져오고, 이슈 티켓까지 생성해주니까요. 스타트업 시절 밤새가며 API 깎던 기억이 주마등처럼 스쳐 지나가더군요.
그런데 기쁨도 잠시, "잠깐, 이 MCP 서버... 누가 만든 거지?" 라는 생각이 스치는 순간 식은땀이 흘렀습니다.
우리는 LLM(Claude, GPT) 자체의 보안은 신경 쓰지만, 정작 그 LLM과 우리 데이터를 연결해 주는 '파이프라인(MCP 서버)'이 블랙박스라는 사실은 간과하곤 합니다. 오늘은 제가 겪은 아찔한 경험을 바탕으로, AI 시대를 살아가는 우리가 반드시 챙겨야 할 MCP 보안 생존 수칙 4가지를 정리해 봅니다.
1. "내 프롬프트가 비밀번호를 떠벌리고 있다" 🔑
가장 흔하면서도 치명적인 실수입니다. 주니어 개발자가 에러를 잡겠다고 프롬프트 창에 DB 연결 문자열을 통째로 붙여넣는 상황, 상상이 가시나요?
"왜 연결이 안 되지? `jdbc:mysql://prod-db... User: admin, Pass: SuperS3cret!` 이거 맞는데?"
🚨 위기 상황 이 프롬프트는 단순히 LLM에게만 가는 게 아닙니다. 중간에 있는 MCP 서버를 거치죠. 만약 우리가 가져다 쓴 오픈소스 MCP 서버가 디버깅을 위해 모든 요청을 로그 파일에 평문으로 남기고 있다면? 축하합니다. 당신은 방금 프로덕션 DB 비밀번호를 영원히 어딘가에 박제한 겁니다.
✅ 생존 수칙 (Action Item)
- 어시스턴트 채팅 교육: "프롬프트는 일기장이 아니다." 민감 정보(API Key, Password)는 절대 채팅창에 붙여넣지 않도록 팀 내 합의가 필요합니다.
- PII/PHI 마스킹 도입:
Philterd같은 라이브러리를 사용해 프록시 단에서 주민번호나 비밀번호 패턴을 마스킹 처리하세요. 사람을 믿지 말고 시스템을 믿어야 합니다. - 로깅 감사: 도입하려는 MCP 서버의 소스 코드를 확인해서, 요청 본문(Payload)을 통째로 로깅하는 부분이 있는지 반드시 체크해야 합니다.
2. "이 서버, 이중 스파이 아니야?" 🕵️
MCP 서버는 우리 왕국(데이터베이스, Jira, 슬랙)의 열쇠를 쥐고 있습니다. 그런데 이 서버가 우리가 모르는 곳으로 데이터를 빼돌리고 있다면 어떨까요?
🚨 위기 상황
GitHub에서 별 생각 없이 npm install awesome-mcp-server를 해서 실행했습니다. 겉보기엔 잘 동작하지만, 백그라운드에서 특정 IP로 데이터를 전송하는 악성 코드가 심어져 있을 수도 있습니다. 혹은 공식 버전이 아닌, 누군가 악의적으로 변조한 '짝퉁'일 수도 있죠.
✅ 생존 수칙 (Action Item)
- 공식 인증 확인: 마켓플레이스나 저장소에서 'Verified' 마크나 공식 배포처(예: SonarQube 공식 계정)인지 확인하세요.
- 네트워크 격리 (가장 중요!): MCP 서버를 아무 데나 띄우지 마세요. Docker나 K8s 환경에서 Egress(아웃바운드) 규칙을 엄격하게 제한해야 합니다.
Docker를 쓴다면 아래처럼 iptables로 묶어버리는 게 속 편합니다.
# Docker 네트워크 격리 예시
$ docker network create restricted_net
# 컨테이너 IP 확인 후, 허용된 IP 외에는 전부 DROP
$ iptables -A DOCKER-USER -s <container_ip> -d <allowed_ip> -j ACCEPT
$ iptables -A DOCKER-USER -s <container_ip> -j DROP3. "블랙박스 속 시한폭탄" 🐛
MCP 서버도 결국 소프트웨어입니다. 내가 짠 코드가 아니라고 해서 안전한 건 아닙니다.
🚨 위기 상황
우리가 도입한 MCP 서버가 구버전 Log4j나 취약점이 있는 Jackson 라이브러리를 쓰고 있다면? 공격자는 LLM을 속일 필요도 없습니다. 그냥 그 취약한 MCP 서버에 악성 API 호출 한 방만 날리면 우리 서버가 털리는 겁니다.
✅ 생존 수칙 (Action Item)
- SCA (Software Composition Analysis) 수행: SonarQube나 Snyk 같은 도구로 MCP 서버의 의존성을 스캔하세요. "이 서버는 CVE-2023-xxxx 취약점이 있는 라이브러리를 씁니다"라고 알려줍니다.
- 컨테이너 샌드박스: 이 서버가 언제든 뚫릴 수 있다고 가정하세요. 최소 권한(Least Privilege) 원칙에 따라, 딱 필요한 DB 테이블에만 접근 권한을 주고, OS 레벨 접근은 막아야 합니다.
4. "컨텍스트가 오염되고 있다" 🧪
이건 보안이면서 동시에 성능 문제입니다. AI가 똑똑하게 답변하려면 '정확한' 정보만 줘야 합니다.
🚨 위기 상황 MCP 서버가 질문과 상관없는 문서 100페이지를 긁어와서 프롬프트 컨텍스트에 밀어 넣는다면? (이를 Context Pollution이라 합니다.) LLM은 헛소리(Hallucination)를 시작하고, API 비용은 폭발합니다. 더 무서운 건 Poisoning(독주입)입니다. 악의적인 데이터가 섞여 들어가 AI가 거짓 정보를 사실인 양 답변하게 만드는 것이죠.
✅ 생존 수칙 (Action Item)
- Sub-agent 전략 사용: 하나의 거대한 에이전트가 모든 툴을 쓰게 하지 마세요. 'DB 조회용 에이전트', '문서 검색용 에이전트'처럼 역할을 쪼개고, 각 에이전트에는 필요한 MCP 서버만 연결하세요.
- 필터링 강화: MCP 서버가 가져오는 데이터의 양과 질을 제한하세요. 무조건 다 가져오는 게 능사가 아닙니다.
마치며: 우리는 이제 '감사관'이 되어야 합니다.
8년 차 개발자로 일하면서 뼈저리게 느낀 건, "편리함에는 항상 청구서가 따른다"는 것입니다. AI 에이전트와 MCP는 분명 생산성을 혁신적으로 높여주는 도구입니다. 하지만 그 편리함에 취해 '보안'이라는 기본을 놓치면, 그 청구서는 감당하기 힘든 '사고'로 돌아옵니다.
개발자는 단순히 코드를 짜는 사람이 아니라, 우리 시스템의 데이터를 지키는 최후의 보루여야 합니다. 오늘 당장 우리 팀이 쓰고 있는 그 MCP 서버, 안전한지 한번 확인해 보는 건 어떨까요?
여러분의 안전한 AI 개발을 응원합니다! 🚀
