MCP 전송 방식
— stdio, SSE, Streamable HTTP는 언제 쓰는가
MCP를 구축하려고 하면 가장 먼저 부딪히는 질문.
“전송 방식을 뭘로 해야 하지?”
MCP(Model Context Protocol)는
AI 에이전트가 외부 도구와 통신하는 프로토콜입니다.
프로토콜이지 전송 방식이 아닙니다.
HTTP가 프로토콜이고 TCP가 전송 계층인 것처럼,
MCP도 메시지 형식(JSON-RPC 2.0)을 정의하고
그 메시지를 어떻게 주고받을지는 별도로 선택합니다.
현재 MCP가 지원하는 전송 방식은 세 가지입니다.
한눈에 비교
| stdio | SSE | Streamable HTTP | |
|---|---|---|---|
| 통신 방식 | 프로세스 stdin/stdout | HTTP + SSE 스트림 | HTTP POST + 선택적 SSE |
| 네트워크 | 로컬 전용 | 원격 가능 | 원격 가능 |
| 상태 관리 | 프로세스 수명 = 세션 | SSE 연결 유지 필수 | 상태 유지/비유지 모두 가능 |
| 방향 | 양방향 | 서버→클라이언트 단방향 스트림 | 양방향 |
| 인증 | OS 프로세스 격리 | HTTP 헤더 (Bearer 등) | HTTP 헤더 (OAuth 2.1 등) |
| TLS (HTTPS) | 해당 없음 | 적용 가능 | 적용 가능 |
| 스케일링 | 1:1 (호스트:서버) | 제한적 (연결 유지 필요) | 수평 확장 가능 |
| 현재 상태 | 표준 | 레거시 (유지 중) | 표준 (권장) |
stdio — 로컬에서 가장 단순한 방식
MCP 서버를 로컬 프로세스로 실행하고,
표준 입력(stdin)으로 요청을 보내고
표준 출력(stdout)으로 응답을 받는 방식입니다.
네트워크를 타지 않습니다.
호스트 애플리케이션이 MCP 서버 프로세스를 직접 실행(spawn)하고,
프로세스가 종료되면 세션도 끝납니다.
언제 쓰는가
· Claude Desktop에서 로컬 도구를 연결할 때
· IDE 플러그인에서 프로젝트 파일에 접근할 때
· 개발/테스트 환경에서 빠르게 MCP 서버를 돌릴 때
· 싱글 유저, 싱글 세션 환경
장점
· 설정이 거의 없음 — 실행 명령어만 지정하면 끝
· 네트워크 보안 고려 불필요 — OS 프로세스 격리로 보호
· 지연 시간이 극히 짧음 — 같은 머신 내 통신
한계
· 원격 서버 연결 불가 — 같은 머신에서만 동작
· 멀티 유저/멀티 세션 불가
· 수평 확장 불가
보안 특성
stdio는 네트워크에 노출되지 않으므로
별도의 인증이 필요하지 않습니다.
보안은 OS 수준의 프로세스 격리와
파일시스템 권한에 의존합니다.
단, MCP 서버 프로세스가 접근할 수 있는
파일/디렉토리 범위는 반드시 제한해야 합니다.
SSE (Server-Sent Events) — 레거시, 하지만 아직 살아 있다
HTTP 기반의 원격 전송 방식입니다.
클라이언트가 HTTP POST로 요청을 보내고,
서버가 SSE 스트림으로 응답을 내려보냅니다.
MCP 초기(2024년)에 도입된 방식으로,
현재는 Streamable HTTP로 대체가 권장됩니다.
하지만 기존에 SSE로 구축된 서버가 많아서
당분간 지원이 유지됩니다.
SSE의 구조적 한계
· 서버 → 클라이언트 단방향 스트림 — 서버가 클라이언트에 요청을 보내려면 별도 채널 필요
· SSE 연결을 계속 유지해야 함 — 연결이 끊기면 세션 상태를 잃음
· 로드밸런서 뒤에서 어려움 — sticky session 또는 세션 ID 관리 필요
· 수평 확장이 까다로움 — 연결 상태 유지가 스케일링의 병목
새로 MCP 서버를 구축한다면
SSE 대신 Streamable HTTP를 선택하세요.
기존 SSE 서버도 점진적으로 마이그레이션하는 것을 권장합니다.
Streamable HTTP — 프로덕션 원격 배포의 표준
2025년에 도입된 최신 전송 방식으로,
SSE의 한계를 해결하기 위해 설계되었습니다.
모든 통신이 HTTP POST를 기반으로 하고,
필요할 때만 SSE로 스트리밍을 시작합니다.
상태 유지(stateful)와 상태 비유지(stateless) 모두 지원합니다.
SSE 대비 개선점
· 양방향 통신 — 서버도 클라이언트에 요청 가능 (알림, 리소스 업데이트 등)
· 연결 유지 불필요 — 각 요청이 독립적. 연결이 끊겨도 세션 유지 가능
· 수평 확장 — 상태 비유지 모드에서 일반 HTTP 서버처럼 스케일 가능
· 로드밸런서 친화적 — sticky session 없이도 동작
· 점진적 스트리밍 — 짧은 응답은 일반 HTTP, 긴 응답만 SSE 스트림
동작 방식
1. 클라이언트가 /mcp 엔드포인트로 HTTP POST 요청
2. 서버가 응답을 판단:
— 짧은 응답 → 일반 JSON 응답으로 즉시 반환
— 긴 응답/스트리밍 필요 → SSE 스트림으로 전환
3. 상태 유지가 필요하면 Mcp-Session-Id 헤더로 세션 관리
— 상태 비유지 서버는 이 헤더를 쓰지 않아도 됨
HTTPS는 어디서 적용하는가
MCP 스펙에 “HTTPS”라는 전송 방식은 없습니다.
하지만 HTTPS를 사용할 수 없다는 뜻이 아닙니다.
MCP가 말하는 “HTTP”는 애플리케이션 프로토콜 계층이고,
TLS(HTTPS)는 그 아래 전송 보안 계층입니다.
웹 서버에 HTTPS를 적용하는 것과 완전히 같은 원리입니다.
SSE와 Streamable HTTP 모두
HTTP 위에서 동작하므로
TLS를 적용하면 곧 HTTPS가 됩니다.
적용 방법
· 리버스 프록시에서 TLS 종단 — Nginx, Caddy, Traefik 등에서 인증서 처리. MCP 서버 자체는 HTTP로 동작하고, 프록시가 HTTPS를 담당
· MCP 서버에서 직접 TLS — Node.js의 https 모듈 등으로 서버 자체에 인증서 적용. 소규모 배포에 적합
· 클라우드 로드밸런서 — AWS ALB, GCP Cloud Run 등에서 자동 TLS 적용
프로덕션에서 HTTPS는 선택이 아닌 필수
MCP 서버가 네트워크에 노출되는 순간
(SSE든 Streamable HTTP든)
TLS 없이 운영하면 안 됩니다.
도구 호출에 포함된 크레덴셜, API 키, 사용자 데이터가
평문으로 전송됩니다.
어떤 전송 방식을 쓸 것인가 — 판단 기준
로컬 개발/테스트, 단일 사용자
→ stdio
Claude Desktop, IDE 플러그인에서 로컬 도구를 연결할 때.
설정이 가장 간단하고 네트워크 보안 걱정이 없습니다.
원격 서버, 프로덕션, 멀티 유저
→ Streamable HTTP + HTTPS
신규 구축이라면 무조건 이 방식.
수평 확장, 로드밸런서 호환, 상태 유지/비유지 선택 가능.
반드시 TLS를 적용하고, OAuth 2.1 인증을 추가하세요.
기존 SSE 서버가 있는 경우
→ SSE 유지 + 점진적 마이그레이션 계획
당장 깨지는 건 아니지만, 스케일링 한계에 부딪히기 전에
Streamable HTTP로 전환을 계획하세요.
보안 관점에서의 차이
| 보안 항목 | stdio | SSE / Streamable HTTP |
|---|---|---|
| 인증 | OS 프로세스 격리 | OAuth 2.1 / mTLS 필수 |
| 전송 암호화 | 불필요 (로컬) | TLS(HTTPS) 필수 |
| 네트워크 노출 | 없음 | 있음 — 방화벽/ACL 설정 |
| 도구 포이즈닝 | 동일 위험 | 동일 위험 |
| 감사 로그 | 동일하게 필요 | 동일하게 필요 |
전송 방식과 무관하게
도구 포이즈닝, 입출력 검증, 감사 로그는 동일하게 적용해야 합니다.
전송 방식이 바뀐다고 보안 요구사항이 줄어들지 않습니다.
전송 방식과 무관한 MCP 보안 설계에 대해서는
“MCP 서버를 프로덕션에 올리기 전에 — 보안 설계 체크리스트”를 참고하세요.
정리
stdio는 로컬, 단일 사용자, 개발/테스트 환경.
Streamable HTTP는 원격, 멀티 유저, 프로덕션 환경.
SSE는 레거시. 새로 쓸 이유가 없습니다.
네트워크에 노출되는 순간 HTTPS는 필수이고,
어떤 전송 방식을 쓰든 도구 보안, 감사 로그,
입출력 검증은 동일하게 적용해야 합니다.
본 글은 리원에이스 기술개발본부가 작성한 기술 콘텐츠입니다. 외부 공유 시 출처를 명시해 주세요.
2026년 8월 19일
리원에이스 기술개발본부