엔지니어링Mar 28, 2026

프로덕션에서의 MCP: Transport, 인증, 스케일링 과제 해결

Engineering Team

프로토타입에서 프로덕션으로: 무엇이 달라지는가

노트북에서 작동하는 MCP 서버를 구축하는 것은 비교적 간단합니다. 분산 인프라 전체에서 수천 개의 AI 에이전트 세션을 동시에 처리하는 서버를 운영하는 것은 완전히 다른 엔지니어링 과제입니다. 프로덕션 MCP 배포는 프로토타입에서 무시할 수 있는 다섯 가지 문제를 해결해야 합니다: 트랜스포트 확장성, 인증 및 권한 부여, 대규모 세션 관리, 감사 추적, 멀티 서버 오케스트레이션.

이 문서는 MCP 서버를 개발에서 프로덕션으로 이전하는 엔지니어링 팀을 위한 기술 가이드입니다. 최소 하나의 MCP 서버를 구축하고 프로토콜의 기본 사항을 이해하고 있다고 가정합니다. 아직이라면 첫 번째 MCP 서버 구축에 관한 관련 문서부터 시작하세요.

트랜스포트 확장성: stdio vs SSE vs Streamable HTTP

MCP는 세 가지 트랜스포트 메커니즘을 정의합니다. 프로덕션에 적합한 것을 선택하는 것이 첫 번째 아키텍처 결정입니다.

stdio 트랜스포트

stdio 트랜스포트는 표준 입출력 스트림을 통해 통신합니다. Host 애플리케이션이 MCP 서버를 자식 프로세스로 시작하고 stdin/stdout을 통해 JSON-RPC 메시지를 교환합니다.

장점:

네트워크 설정 불필요
프로세스 수준 격리
포트 충돌 없음
최저 지연 시간(네트워크 스택 없음)

제한:

서버가 Host와 같은 머신에서 실행되어야 함
Client 세션당 하나의 서버 프로세스
로드 밸런싱 불가
수평 확장 불가

적합한 용도: 로컬 개발 도구, IDE 확장, 단일 사용자 데스크톱 애플리케이션.

SSE(Server-Sent Events) 트랜스포트

SSE 트랜스포트는 클라이언트에서 서버로의 메시지에 HTTP를 사용하고, 서버에서 클라이언트로의 메시지에 Server-Sent Events를 사용합니다. 서버는 HTTP 서비스로 동작합니다.

장점:

네트워크를 통해 접근 가능(원격 서버)
기존 HTTP 인프라와 호환
여러 클라이언트 동시 지원
방화벽 및 프록시 통과

제한:

단방향 스트리밍(SSE는 서버에서 클라이언트만)
세션 어피니티 필요(스테이트풀 연결)
일부 로드 밸런서가 장기 SSE 연결에서 문제
프로토콜에 내장된 재연결 시맨틱 없음

적합한 용도: 소규모~중규모 배포, 내부 도구, 기존 HTTP 인프라가 있는 팀.

Streamable HTTP 트랜스포트

Streamable HTTP는 최신 트랜스포트로, 프로덕션 배포를 위해 특별히 설계되었습니다. 모든 메시지에 표준 HTTP POST를 사용하고, 장기 실행 작업에는 선택적 SSE 스트리밍을 사용합니다.

장점:

완전히 스테이트리스한 요청/응답 모델
모든 HTTP 로드 밸런서와 동작
Mcp-Session-Id 헤더를 통한 내장 세션 관리
스트리밍 및 비스트리밍 응답 모두 지원
CDN 및 프록시와 호환

제한:

서버 측 세션 스토리지 필요(Redis, 데이터베이스)
stdio보다 메시지당 오버헤드 약간 높음
새로운 트랜스포트 — 에코시스템 도구가 적음

적합한 용도: 프로덕션 클라우드 배포, 멀티테넌트 플랫폼, 엔터프라이즈 환경.

트랜스포트 비교 매트릭스

특성	stdio	SSE	Streamable HTTP
네트워크 지원	아니오	예	예
수평 확장	아니오	제한적	예
로드 밸런싱	아니오	세션 어피니티 필요	표준 HTTP LB
세션 관리	프로세스별	서버 메모리	외부 스토어
지연 시간	최저	낮음	낮음
방화벽 호환	N/A	예	예

인증 및 권한 부여

OAuth 2.0 통합

프로덕션 MCP 서버는 클라이언트가 자체 인증하고 특정 도구 및 리소스에 대한 접근을 제한하는 방법이 필요합니다. MCP 프로토콜은 원격 서버에 대해 OAuth 2.0을 지원합니다.

흐름은 다음과 같습니다:

MCP client가 서버에 연결하고 initialize 요청 전송
서버가 OAuth 메타데이터 URL이 포함된 WWW-Authenticate 헤더와 함께 401 Unauthorized로 응답
Client가 /.well-known/oauth-authorization-server에서 OAuth 설정 가져오기
Client가 브라우저 기반 인증 흐름을 사용하여 액세스 토큰 획득
이후 요청에 Authorization 헤더에 Bearer 토큰 포함

도구 수준 권한 부여

인증만으로는 충분하지 않습니다. 프로덕션 시스템에는 사용자가 어떤 도구를 호출하고 어떤 리소스에 접근할 수 있는지 제어하는 세밀한 권한 부여가 필요합니다.

권장 접근 방식:

역할 기반 접근 제어(RBAC): 역할에 도구 권한 할당. 예: analyst 역할은 읽기 전용 쿼리 도구에 접근, admin 역할은 쓰기 작업에 접근.
스코프 기반 제어: OAuth 스코프를 사용하여 도구 접근 제한. 예: mcp:tools:query:read 스코프는 SELECT 쿼리만 허용.
동적 도구 필터링: 인증된 사용자의 권한에 따라 사용 가능한 도구 목록 필터링.

Redis를 이용한 수평 확장

스테이트리스 Streamable HTTP 트랜스포트를 사용하면 여러 MCP 서버 인스턴스를 로드 밸런서 뒤에서 실행할 수 있습니다. 세션 상태는 Redis에 저장되어 모든 인스턴스에서 공유됩니다.

Client → Load Balancer → MCP Server 1 ↔ Redis
                       → MCP Server 2 ↔ Redis
                       → MCP Server 3 ↔ Redis

각 요청에는 Mcp-Session-Id 헤더가 포함되며, 어떤 서버 인스턴스든 Redis에서 세션 상태를 가져와 처리를 계속할 수 있습니다.

Kubernetes에서의 오토스케일링

MCP 서버를 Kubernetes에 배포하면 활성 세션 수 또는 CPU 사용률에 따라 Pod를 자동으로 확장할 수 있습니다. Horizontal Pod Autoscaler(HPA)에서 커스텀 메트릭을 사용합니다.

감사 로깅

엔터프라이즈 배포에서는 AI가 외부 도구를 호출할 때마다 상세한 감사 추적이 필요합니다. 각 도구 호출에 대해 다음을 기록합니다:

타임스탬프: 호출 시간
사용자 ID: AI 작업을 시작한 사용자
도구 이름: 호출된 MCP 도구
입력 매개변수: 도구에 전송된 데이터
출력 결과: 도구가 반환한 데이터
실행 시간: 도구 호출에 걸린 시간
오류: 발생한 오류

구조화된 로깅(JSON 형식)을 사용하고, 로그를 중앙 로그 관리 시스템(ELK Stack, Datadog, CloudWatch)으로 전송합니다.

게이트웨이 아키텍처

대규모 배포에서는 MCP 게이트웨이 패턴 구현을 고려하세요. 게이트웨이는 MCP client와 백엔드 MCP 서버 사이의 리버스 프록시 역할을 합니다.

게이트웨이 책임:

인증 중앙화: 모든 OAuth 검증을 게이트웨이에서 처리
속도 제한: 사용자별, 도구별 속도 제한 적용
라우팅: 도구 이름에 따라 요청을 적절한 백엔드 서버로 라우팅
감사 로그 수집: 모든 도구 호출을 게이트웨이 수준에서 기록
서킷 브레이커: 백엔드 서버 장애 시 폴백 처리

FAQ

Q: 프로덕션에서 stdio 트랜스포트를 사용할 수 있나요? A: 네, 하지만 제한적인 시나리오에서만. 각 사용자가 자체 로컬 MCP 서버 프로세스를 실행하는 데스크톱 애플리케이션에 적합합니다. 공유 서버 인프라에는 Streamable HTTP를 사용하세요.

Q: MCP 세션을 영속화해야 하나요? A: 네, Streamable HTTP를 사용하는 경우. 세션 상태에는 클라이언트 기능, 협상된 프로토콜 버전, 등록된 알림이 포함됩니다. Redis가 권장 세션 스토어입니다.

Q: MCP 서버의 버전 관리는 어떻게 해야 하나요? A: initialize 응답의 서버 버전 필드를 사용합니다. 호환성을 깨는 변경(도구 제거, 스키마 변경)의 경우 메이저 버전을 범프하고 마이그레이션 기간 동안 이전 버전과 새 버전을 모두 지원합니다.

Q: MCP의 최대 메시지 크기는 얼마인가요? A: 프로토콜은 최대 크기를 정의하지 않지만, 실제 제한은 트랜스포트에 따라 다릅니다. Streamable HTTP의 경우 응답을 10 MB 이하로 유지하세요. stdio의 경우 시스템 파이프 버퍼(일반적으로 64 KB)로 인해 큰 응답에는 청킹이 필요할 수 있습니다.

태그

AI DevOps Security