MCP 서버를 프로덕션에 올리기 전에
— 보안 설계 체크리스트
MCP 서버 하나가 에이전트에게
DB, 파일시스템, API 접근을 열어줍니다.
편리하지만, 보안 없이 올리면 전체 인프라의 백도어가 됩니다.
MCP 스펙 자체에는 인증이 없습니다.
MCP는 도구의 정의와 호출 방법을 표준화한 프로토콜이지,
보안 프레임워크가 아닙니다.
인증, 인가, 감사, 입력 검증은 전부 구현자의 몫입니다.
이 글은 OWASP MCP Top 10 분석의 후속입니다.
위협을 알았으니, 이제 방어를 설계할 차례입니다.
MCP의 구조 — 공격 표면 이해하기
MCP 통신은 네 계층으로 이루어집니다.
각 계층마다 서로 다른 공격 표면이 존재합니다.
Host Application
Claude Desktop, IDE 플러그인 등.
사용자의 요청을 받아 MCP 클라이언트에 전달합니다.
위협: 사용자 입력에 포함된 인젝션이 그대로 전달
MCP Client
호스트와 서버 사이의 중개자.
어떤 서버의 어떤 도구를 호출할지 결정합니다.
위협: 악성 서버가 클라이언트를 통해 다른 서버의 데이터에 접근
MCP Server
도구(Tools), 리소스(Resources), 프롬프트(Prompts)를 제공합니다.
실제 외부 시스템과 연결되는 지점입니다.
위협: 도구 description 인젝션, 과다 권한, 시크릿 노출
Tools / Resources
DB 쿼리, 파일 읽기/쓰기, API 호출, 쉘 실행 등.
에이전트가 실제로 “행동”하는 단위입니다.
위협: 명령어 인젝션, 경로 순회, 권한 상승
1. 인증과 인가 — 가장 먼저, 가장 확실하게
MCP 스펙은 전송 계층(stdio, SSE)만 정의하고
인증 메커니즘은 규정하지 않습니다.
즉, 기본 상태의 MCP 서버는 누구나 호출할 수 있습니다.
서버 인증
· SSE/HTTP 전송 시 OAuth 2.1 또는 mTLS 적용
· stdio 전송은 로컬 프로세스 격리로 보호
· API 키 방식은 단기 토큰 + 자동 갱신으로 전환
· 하드코딩된 크레덴셜 절대 금지
도구별 인가
· 도구마다 필요한 최소 권한만 부여
· 읽기 전용 도구와 쓰기 도구를 분리
· 호출자(에이전트/사용자)별 접근 제어
· 권한 부여 시 TTL(유효 기간) 설정
CVE-2025-6514의 교훈
43만 회 이상 다운로드된 mcp-remote 패키지에서
인증 우회 취약점이 발견되었습니다 (CVSS 9.6).
“유명한 패키지니까 안전하겠지”는 통하지 않습니다.
인증은 직접 검증해야 합니다.
2. 도구 정의 보안 — description이 무기가 되지 않게
MCP에서 도구의 description은 단순한 설명이 아닙니다.
LLM은 description을 읽고 도구 사용 여부를 판단합니다.
여기에 악성 지시문이 들어가면 에이전트의 행동이 바뀝니다.
방어 원칙
· description에 LLM 지시문이 포함되어 있는지 검사
· 도구 등록 시 description 해시를 기록하고, 런타임에 변경 감지
· 입력 스키마를 엄격하게 정의 (JSON Schema validation)
· 도구 응답(output)도 검증 — 응답에 후속 지시문이 삽입될 수 있음
Rug Pull 공격
처음에는 정상적인 도구로 등록한 뒤,
승인 후 description이나 동작을 변경하는 공격입니다.
도구 정의의 무결성을 지속적으로 검증해야 하는 이유입니다.
3. 입출력 검증 — 파라미터를 절대 신뢰하지 말 것
MCP 도구가 받는 인자(argument)는
사용자 입력, RAG 검색 결과, 다른 도구의 응답 등
다양한 경로를 통해 들어옵니다.
어떤 경로든 신뢰할 수 없습니다.
명령어 인젝션 방지
쉘 명령이나 SQL을 실행하는 도구는
문자열 조합이 아닌 파라미터 바인딩을 사용해야 합니다.
2,614개 MCP 서버 조사에서
34%가 명령어 인젝션에 취약했습니다.
경로 순회 차단
파일 접근 도구는 허용된 디렉토리 밖으로
나갈 수 없도록 경로를 정규화하고 검증해야 합니다.
../../etc/passwd 같은 패턴을 차단하세요.
82%의 MCP 서버가 이 취약점에 노출되어 있었습니다.
출력 검증
도구의 응답도 검증 대상입니다.
악성 MCP 서버가 응답에 LLM 지시문을 삽입하면
에이전트의 다음 행동을 조작할 수 있습니다.
응답에서 프롬프트 인젝션 패턴을 필터링하세요.
4. 감사 로그 — 기록이 없으면 사고도 모른다
MCP 도구 호출은 반드시 기록되어야 합니다.
사고가 발생했을 때 “어떤 에이전트가 어떤 도구를
어떤 인자로 호출했는가”를 추적할 수 없으면
원인 분석도, 대응도, 재발 방지도 불가능합니다.
최소 기록 항목
· Who — 어떤 사용자의 요청으로 트리거되었는가
· What — 어떤 도구가 호출되었는가
· With — 어떤 인자(argument)로 호출되었는가
· When — 언제 호출되었는가 (타임스탬프)
· Result — 결과가 무엇이었는가 (성공/실패/응답 요약)
· Context — 어떤 컨텍스트에서 호출이 결정되었는가
로그는 변조 불가능해야 합니다.
에이전트 자신이 로그를 수정하거나 삭제할 수 없어야 하고,
별도의 감사 시스템에 실시간으로 전송되어야 합니다.
5. 되돌릴 수 없는 행동 — Human-in-the-Loop
모든 도구 호출에 사람의 승인을 요구하면
에이전트를 쓰는 의미가 없습니다.
핵심은 되돌릴 수 없는 행동만 구분하는 것입니다.
승인 없이 허용 (읽기)
· DB 조회 (SELECT)
· 파일 읽기
· API GET 요청
· 검색, 상태 확인
사전 승인 필수 (쓰기/실행)
· 데이터 삭제 (DELETE, DROP)
· 이메일/메시지 발송
· 결제, 주문 실행
· 인프라 변경 (배포, 스케일링)
· 권한 변경 (사용자 추가/삭제)
6. 섀도우 MCP 서버 — 보이지 않으면 관리도 안 된다
개발자가 테스트용으로 띄운 MCP 서버가
기본 설정 그대로 프로덕션 네트워크에 남아 있는 경우입니다.
조직 내에서 운영 중인 MCP 서버의 목록을 관리하고,
허용 목록(allowlist)에 없는 서버는 연결을 차단해야 합니다.
섀도우 서버 탐지
· MCP 서버 인벤토리(목록) 유지 — 누가, 어디서, 어떤 도구를
· 네트워크에서 MCP 트래픽 패턴 모니터링
· 미등록 서버 연결 시도 시 알림
· 정기적으로 불필요한 서버 정리
7. 컨텍스트 격리 — 정보가 새어나가지 않게
MCP 도구 호출 시 전달되는 컨텍스트에
의도하지 않은 민감 정보가 포함될 수 있습니다.
대응
· 세션별 컨텍스트 격리 — 다른 세션의 데이터가 섞이지 않게
· 도구 호출 시 필요한 최소 컨텍스트만 전달
· 민감 정보(API 키, 개인정보) DLP 필터링
· 세션 종료 시 컨텍스트 완전 삭제
배포 전 체크리스트 — 10개 항목
MCP 서버에 인증이 적용되어 있는가? (OAuth 2.1 / mTLS)
인증
도구별 최소 권한이 설정되어 있는가? (읽기/쓰기 분리)
인가
하드코딩된 시크릿이 없는가? (토큰, API 키, DB 비밀번호)
시크릿
도구 description에 인젝션 가능한 내용이 없는가?
도구 보안
입력 파라미터에 바인딩/검증이 적용되어 있는가?
입력 검증
파일 접근 도구에 경로 순회 방어가 되어 있는가?
입력 검증
도구 호출 감사 로그가 활성화되어 있는가? (Who/What/With/When/Result)
감사
되돌릴 수 없는 행동에 Human-in-the-Loop가 설정되어 있는가?
실행 제어
허용된 MCP 서버 목록(allowlist)이 있는가?
거버넌스
도구 응답에서 프롬프트 인젝션 패턴을 필터링하는가?
출력 검증
리원에이스 제품과의 연결
AIR — MCP 서버 프레임워크
이 체크리스트의 01~06번을 프레임워크 수준에서 해결합니다.
인증, 권한 분리, 시크릿 관리, 도구 스키마 검증,
입력 바인딩이 기본 내장되어 있어
보안을 별도로 구현할 필요가 없습니다.
Sentinel — MCP Audit & Analytics Gateway
07번(감사 로그)을 전담합니다.
모든 도구 호출을 실시간으로 기록하고,
이상 행동 패턴을 자동 탐지합니다.
Miraju — AI 방화벽
10번(출력 인젝션 필터링)과
도구 description 인젝션 탐지를 담당합니다.
MCP는 에이전트 시대의 핵심 인프라이지만,
보안은 프로토콜이 아닌 구현자가 책임져야 합니다.
위의 10개 항목이 모두 체크되어 있지 않다면
아직 프로덕션에 올릴 준비가 안 된 것입니다.
하나라도 빠지면 그것이 공격의 시작점이 됩니다.
본 글은 리원에이스 기술개발본부가 작성한 기술 콘텐츠입니다. 외부 공유 시 출처를 명시해 주세요.
2026년 8월 19일
리원에이스 기술개발본부