The State of MCP Security [pdf]

MCP(Model Context Protocol)와 보안: 왜 지금 주목해야 하는가

MCP(Model Context Protocol)는 AI 에이전트와 외부 도구·데이터 소스를 연결하는 표준 프로토콜로, 최근 백엔드 생태계에서 빠르게 확산되고 있다. 웹 백엔드 개발자 입장에서 MCP는 단순한 AI 연동 규격이 아니라, 외부 시스템과 동적으로 통신하는 새로운 인터페이스 레이어다. 문제는 이 레이어가 기존 REST API나 gRPC와는 다른 보안 위협 모델을 가진다는 점이다. MCP가 빠르게 도입되는 만큼, 그 보안 현황을 파악하는 것은 선택이 아닌 필수가 되고 있다.

MCP가 열어놓는 공격 표면

MCP 서버는 클라이언트(에이전트 또는 호스트 애플리케이션)의 요청을 받아 로컬 파일 시스템, 데이터베이스, 외부 API 등 다양한 리소스에 접근한다. 이 구조는 기존 웹 서버와 유사해 보이지만, 몇 가지 결정적인 차이가 있다.

• 암묵적 신뢰 문제: MCP 클라이언트가 보내는 요청은 사람이 직접 작성한 것이 아니라, 에이전트가 자동 생성한 것일 수 있다. 요청의 의도를 검증하기 어렵다.
• Tool 정의의 변조 가능성: MCP에서 서버가 노출하는 Tool 스펙은 런타임에 동적으로 로드되는 경우가 많아, 악의적인 Tool 정의가 주입될 여지가 생긴다.
• Prompt Injection 전파: 외부 데이터를 읽어 에이전트에 전달하는 과정에서, 데이터 안에 삽입된 악성 지시문이 에이전트의 동작을 바꿀 수 있다.

Java 백엔드 기준으로 보면, MCP 서버를 Spring Boot 위에 구현할 때 별도의 인가(Authorization) 레이어 없이 Tool 엔드포인트를 열어두는 구조가 흔히 발견된다. 이는 전통적인 IDOR(Insecure Direct Object Reference)나 권한 상승 취약점과 동일한 패턴으로 이어질 수 있다.

실무에서 고려해야 할 보안 설계 원칙

MCP 서버를 운영하거나 연동하는 백엔드 개발자라면 다음 원칙들을 설계 단계부터 반영해야 한다.

**최소 권한 원칙(Principle of Least Privilege)**을 Tool 단위로 적용해야 한다. 각 Tool이 접근할 수 있는 리소스 범위를 명시적으로 선언하고, 런타임에 이를 강제하는 인가 계층을 구현한다.

@McpTool(name = "readUserProfile")
@PreAuthorize("hasScope('profile:read') && #userId == authentication.name")
public UserProfile readUserProfile(String userId) {
    return userRepository.findById(userId)
        .orElseThrow(() -> new ResourceNotFoundException(userId));
}

입력 검증과 출력 필터링도 이중으로 적용해야 한다. MCP를 통해 외부에서 들어오는 파라미터는 에이전트가 생성한 것이므로, 예상치 못한 형식이나 범위를 가질 수 있다. 또한 Tool의 응답이 다시 에이전트의 컨텍스트로 들어가는 구조이기 때문에, 응답 내 민감 정보 노출도 반드시 차단해야 한다.

public String sanitizeToolOutput(String rawOutput) {
    // PII, 내부 스택 트레이스, 시스템 경로 등 제거
    return rawOutput.replaceAll(PII_PATTERN, "[REDACTED]")
                    .replaceAll(PATH_PATTERN, "[PATH]");
}

Transport 레이어 보안도 간과하기 쉽다. MCP는 stdio, SSE, HTTP 등 다양한 전송 방식을 지원하는데, 특히 네트워크를 통한 SSE/HTTP 방식에서는 TLS 적용과 Origin 검증이 필수다.

생태계 성숙도와 개발자의 역할

현재 MCP 보안 생태계는 아직 성숙 단계가 아니다. 표준화된 보안 가이드라인이나 감사 도구가 충분히 갖춰지지 않은 상태에서 프로덕션 도입이 앞서가는 상황이다. 이는 4년차 이상 백엔드 개발자에게 오히려 기회이기도 하다. 보안 설계를 주도적으로 정의하고 팀 내 기준을 세울 수 있는 위치에 있기 때문이다.

보안 리뷰 체크리스트에 MCP 관련 항목을 추가하고, Tool 노출 범위를 아키텍처 문서에 명시하는 습관을 들이는 것이 실질적인 첫걸음이다. 또한 MCP 서버의 접근 로그를 기존 보안 모니터링 파이프라인(SIEM 등)에 통합하여 이상 행동을 조기에 탐지하는 구조도 함께 고려해야 한다.

정리

• MCP는 기존 API와 다른 공격 표면(암묵적 신뢰, Tool 변조, Prompt Injection)을 가지므로 별도의 보안 모델이 필요하다.
• Tool 단위 최소 권한 적용, 입출력 이중 검증, Transport 보안은 MCP 서버 구현 시 반드시 반영해야 할 기본 원칙이다.
• 생태계 표준이 미성숙한 지금, 선제적으로 보안 기준을 정의하고 내재화하는 것이 경쟁력 있는 백엔드 개발자의 역할이다.