MCP 보안이란 AI 에이전트가 Model Context Protocol(MCP) 서버를 통해 무엇에 접근할 수 있는지, 각 연결을 누가 승인하는지, 모든 도구 호출을 어떻게 기록하고 철회하는지를 통제하는 일입니다. 아래 10가지 통제는 서버 신뢰, 인증, 최소 권한, 프롬프트 인젝션, 사람의 승인, 격리, 로깅, 사고 대응을 다룹니다.
Model Context Protocol은 AI 애플리케이션이 MCP 서버를 통해 외부 도구와 데이터에 연결하도록 하는 개방형 표준입니다. 프로토콜이 처음이라면 MCP 완벽 해설: AI 에이전트는 어떻게 업무 도구와 데이터에 연결되는가를 먼저 읽어 보세요. 이 글은 연결이 실제로 운영될 때 무엇이 잘못될 수 있는지에 집중합니다.
MCP 서버는 파일을 읽고, 데이터베이스를 조회하고, API를 호출하고, 메시지를 보내는 도구를 제공할 수 있습니다. 그것이 가치이자 위험입니다. 서버가 하나 연결될 때마다 에이전트의 실수나 공격 한 번이 닿는 범위가 넓어집니다.
MCP 보안 체크리스트 한눈에 보기
- 모든 MCP 서버와 담당자를 목록으로 관리한다.
- 검토된 서버만 신뢰하고 버전을 고정한다.
- 모든 원격 서버와 사용자를 인증한다.
- 각 서버에 필요한 최소 권한만 부여한다.
- 클라이언트 토큰을 하위 API로 그대로 전달하지 않는다.
- 도구 설명과 도구 출력을 신뢰할 수 없는 입력으로 취급한다.
- 영향이 큰 작업은 사람의 승인을 요구한다.
- 로컬 서버를 격리하고 네트워크 접근을 제한한다.
- 모든 도구 호출을 사용자, 에이전트, 파라미터와 함께 기록한다.
- 권한 철회와 사고 대응을 준비한다.
MCP가 보안 모델을 바꾸는 이유
MCP 이전에는 AI 연동이 팀이 검토하는 맞춤 코드였습니다. MCP에서는 에이전트가 여러 서버의 도구를 발견하고 호출할 수 있으며, 일부는 제3자가 만든 것입니다. 에이전트는 도구 설명과 결과처럼 도구에서 오는 텍스트를 포함한 텍스트를 바탕으로 어떤 도구를 호출할지 결정합니다.
이는 AI 에이전트 보안 체크리스트에서 다룬 일반적인 에이전트 위험과 함께 다음 위험을 만듭니다.
- 도구를 통한 프롬프트 인젝션: 도구 결과나 설명에 숨은 지시가 들어 있어 에이전트의 방향을 바꿉니다.
- 도구 오염과 사후 변경(rug pull): 승인한 뒤 서버가 도구 설명이나 동작을 바꿉니다.
- 과도한 권한: 서버가 넓은 토큰을 가지고 있어 실수 한 번으로 작업에 필요한 것보다 훨씬 많은 데이터가 노출됩니다.
- 혼동된 대리인(confused deputy) 문제: 접근 권한이 없는 사용자를 대신해 서버가 자체 권한으로 동작합니다.
- 공급망 위험: 검토되지 않은 패키지나 제3자 서버가 내 컴퓨터나 네트워크에서 코드를 실행합니다.
- 데이터 유출: 한 도구가 반환한 민감 데이터가 다른 도구를 통해 외부로 전달됩니다.
OWASP Agentic Applications Top 10과 공식 MCP 문서의 보안 가이드가 이 위협 환경의 좋은 참고 자료입니다.
1. 모든 MCP 서버와 담당자를 목록으로 관리한다
목록으로 만들 수 없는 서버는 보호할 수 없습니다. 각 서버의 용도, 담당자, 실행 위치(로컬 또는 원격), 제공하는 도구, 접근 가능한 시스템과 자격 증명, 사용할 수 있는 에이전트와 사용자를 기록하세요. 목록을 정기적으로 검토하고 담당자가 없는 서버는 제거합니다.
2. 검토된 서버만 신뢰하고 버전을 고정한다
MCP 서버는 코드를 실행할 수 있는 다른 의존성과 똑같이 다루어야 합니다. 이미 신뢰하는 벤더의 서버나 직접 만든 서버를 우선하고, 소스 코드나 벤더의 보안 문서를 검토하며, 조용한 업데이트로 동작이 바뀌지 않도록 버전을 고정하세요. 서버가 업데이트될 때마다 도구 설명을 다시 검토합니다.
- 인기가 많다는 이유만으로 출처를 모르는 서버를 설치하지 마세요.
- 서버가 요구하는 권한과 네트워크 접근을 확인하세요.
- 서버의 도구 목록이나 설명이 바뀌면 알림을 받으세요.
3. 모든 원격 서버와 사용자를 인증한다
누구나 호출할 수 있는 원격 MCP 서버는 데이터로 통하는 열린 문입니다. MCP 사양에는 원격 서버를 위한 OAuth 기반 인증 프레임워크가 포함되어 있습니다. 실제 인증을 사용하고, 세션을 사용자와 연결하며, 내부 API와 같은 접근 규칙을 적용하세요.
4. 각 서버에 필요한 최소 권한만 부여한다
서버마다 전용 ID를 만들고 작업에 필요한 범위(scope)만 부여하세요. 읽기 전용 리포팅 도구가 쓰기나 삭제 권한이 있는 토큰을 가져서는 안 됩니다. 범위를 좁히면 에이전트가 조작되더라도 피해가 제한됩니다.
- 사용 사례가 허락하는 곳에서는 읽기 전용 자격 증명을 쓰세요.
- 데이터베이스 접근을 특정 스키마나 뷰로 제한하세요.
- 철회할 수 있는 수명이 짧은 토큰을 선호하세요.
5. 클라이언트 토큰을 하위 API로 그대로 전달하지 않는다
서버가 클라이언트의 토큰을 받아 다른 서비스로 그대로 전달하면 하위 시스템의 통제를 우회할 수 있고 누가 무엇을 했는지 흐려집니다. 서버가 각 하위 서비스에 대해 올바른 범위의 자체 자격 증명을 발급받고, 토큰이 해당 서버를 대상으로 발급되었는지 검증하게 하세요.
6. 도구 설명과 도구 출력을 신뢰할 수 없는 입력으로 취급한다
서버 자체가 정직하더라도 웹 페이지, 지원 티켓, 공격자가 쓴 이메일을 반환하면 그 안에 모델을 겨냥한 지시가 들어 있을 수 있습니다. 도구 출력이 민감한 작업을 직접 트리거하지 못하게 하세요.
- 프롬프트에서 신뢰할 수 없는 콘텐츠와 지시를 분리하세요.
- 프롬프트가 아니라 코드에서 모든 도구 호출의 파라미터를 검증하세요.
- 에이전트가 신뢰할 수 없는 콘텐츠를 읽은 뒤 실행할 수 있는 도구를 제한하세요.
7. 영향이 큰 작업은 사람의 승인을 요구한다
에이전트는 읽기와 초안 작성은 자유롭게 할 수 있어야 하지만, 송금, 데이터 삭제, 권한 변경, 고객 메시지 발송 같은 작업은 사람이 정확한 작업을 승인해야 합니다. 요약이 아니라 도구 이름과 실제 파라미터를 사용자에게 보여 주세요.
8. 로컬 서버를 격리하고 네트워크 접근을 제한한다
로컬 MCP 서버는 흔히 실행한 사용자와 같은 권한으로 동작합니다. 샌드박스나 컨테이너에서 실행하고, 파일 시스템 경로를 제한하고, 도구에 필요 없는 외부 네트워크 접근을 차단하고, 관리자 권한으로 실행하지 마세요. URL을 가져오는 서버는 내부 주소로의 요청을 차단해 서버 측 요청 위조(SSRF) 위험을 줄입니다.
9. 모든 도구 호출을 기록한다
문제가 생기면 어떤 에이전트가 어떤 사용자를 위해 어떤 파라미터로 어떤 도구를 호출했고 무엇이 반환되었는지 알아야 합니다. 전체 워크플로를 담은 로그를 보관하되, 로그에 민감 정보가 있을 수 있으므로 보호하세요. 대량 조회나 비정상 시간대의 도구 호출 같은 이상 패턴에 알림을 설정합니다.
10. 권한 철회와 사고 대응을 준비한다
서버를 끊고, 자격 증명을 철회하고, 영향을 받은 사람들에게 알리는 방법을 미리 정하세요. 철회가 실제로 작동하는지 테스트하고, 공격자보다 먼저 실제 MCP 환경에 프롬프트 인젝션을 시도하는 레드팀 훈련을 정기적으로 수행합니다.
개발 파트너에게 물어볼 MCP 보안 질문
벤더가 MCP 서버나 에이전트 연동을 만들어 준다면 계약 전에 다음을 물어보세요.
- 사용자와 서버를 어떻게 인증하고 자격 증명은 어디에 저장하나요?
- 각 서버에 어떤 범위가 필요하고 어떻게 제한하나요?
- 도구 출력에서 오는 프롬프트 인젝션을 어떻게 방어하나요?
- 어떤 작업에 사람의 승인이 필요한가요?
- 무엇을 기록하고 누가 로그를 볼 수 있나요?
- 접근을 얼마나 빨리 철회하고 롤백할 수 있나요?
프로덕션 수준의 AI 에이전트 구축 가이드는 더 넓은 아키텍처를 다루고, 15가지 벤더 체크리스트는 파트너 평가에 도움이 됩니다.
자주 묻는 질문
MCP는 기본적으로 안전한가요?
모든 배포에서 기본적으로 안전한 프로토콜은 없습니다. MCP는 클라이언트와 서버가 대화하는 방식을 정의할 뿐이며, 실제 환경의 보안은 인증, 권한 범위, 서버 격리, 각 서버가 할 수 있는 일의 검토 방식에 달려 있습니다.
가장 큰 MCP 보안 위험은 무엇인가요?
대부분의 기업에서는 과도한 권한과 프롬프트 인젝션의 결합입니다. 많은 데이터에 접근할 수 있는 에이전트가 신뢰할 수 없는 텍스트에 조종될 수 있기 때문입니다. 최소 권한과 위험 작업에 대한 사람의 승인이 이를 가장 많이 줄입니다.
제3자 MCP 서버를 써도 되나요?
쓸 수 있지만 다른 제3자 코드처럼 다루세요. 검토하고, 버전을 고정하고, 격리해서 실행하고, 필요한 접근만 주세요. 민감한 시스템이라면 작은 서버를 직접 만드는 편이 더 많은 통제권을 줍니다.
로컬 MCP 서버에도 보안 통제가 필요한가요?
네. 로컬 서버는 흔히 내 사용자 권한으로 실행되므로, 침해되었거나 악의적인 서버는 파일을 읽고 명령을 실행할 수 있습니다. 샌드박스에서 실행하고 접근 범위를 제한하세요.
Nextchain과 함께 안전한 MCP 연동 설계하기
Nextchain.tech는 업무 도구와 데이터 연동을 포함한 AI 에이전트 시스템을 설계하고 구축합니다. MCP 설계나 에이전트 프로젝트에 대한 추가 검토가 필요하다면 스코핑 콜을 예약하거나 contact@nextchain.kr로 문의하세요.
