💡 요약 / TL;DR - MCP 전송 방식 비교 핵심 요약 (BLUF)

  • 로컬 대 원격: Model Context Protocol(MCP)은 단일 머신용 로컬 통신 프로토콜인 stdio 방식과 분산 네트워크 통신용인 원격 Streamable HTTP 프로토콜로 이원화되었습니다.
  • HTTP+SSE의 종말: 기존의 HTTP+SSE 2-엔드포인트 방식은 공식 폐기되었으며, 2026년 6월 30일(Atlassian Rovo 데드라인)부로 주요 플랫폼에서 완벽하게 제거됩니다.
  • 최선의 가이드라인: 새 프로젝트는 stdio 또는 단일 엔드포인트 무상태 구조인 Streamable HTTP로 시작하고, 기존 SSE 서버는 조속히 마이그레이션해야 연동 중단을 방지할 수 있습니다.

“The Model Context Protocol establishes a standard for connecting AI clients to local or remote data sources and tools using standardized JSON-RPC transports.” — Model Context Protocol Specification, 2026

Model Context Protocol(MCP)의 전송 규격은 로컬 통신용인 stdio와 원격 네트워크용인 Streamable HTTP 프로토콜의 이원 구조로 표준화되었으며, 기존 HTTP+SSE 방식은 2026년 6월 30일(Atlassian Rovo 기준)부로 공식 폐기 처리됩니다. 이에 따라 새롭게 설계되는 모든 원격 에이전트 연동 아키텍처는 단일 엔드포인트 무상태 구조인 Streamable HTTP를 채택해야 동시성 및 상태 유실 에러를 방지할 수 있습니다. 본 MCP 전송 규격 비교 가이드는 공식 SDK 명세를 기반으로 각 프로토콜의 작동 한계와 마이그레이션 타임라인을 대조 분석합니다.

MCP는 두 레이어로 나뉩니다. 데이터 레이어는 서버가 무엇을 할 수 있는지 정의합니다: 도구, 리소스, 프롬프트. 전송 레이어는 JSON-RPC 메시지가 클라이언트와 서버 사이를 어떻게 오가는지 정의합니다. 전송은 이 둘 중 두 번째이고, 고르는 건 대체로 배치 문제입니다. 서버가 클라이언트와 같은 머신에 있나, 네트워크 너머에 있나.

stdio: 로컬, 그리고 어디서 깨지나

stdio 전송에서 클라이언트는 MCP 서버를 자식 프로세스로 띄우고 표준 입출력으로 대화합니다. Unix 파이프와 같은 방식입니다. 가장 단순하고, 클라이언트와 서버가 한 머신·단일 사용자를 공유하는 로컬 개발에 맞습니다.

어디서 깨지나: stdio는 로컬 전용에 단일 클라이언트입니다. 동시 접속에 무너집니다. 한 분석은 동시 20접속에서 요청 대부분이 실패했다고 보고했습니다. 원격 클라이언트는 아예 못 받습니다. 또 흔한 헛디딤은 프로토콜이 아니라 환경입니다. spawn npx ENOENT 에러는 보통 명령이나 그 런타임이 클라이언트가 띄운 경로(PATH)에 없다는 뜻이지, MCP 설정이 틀렸다는 게 아닙니다.

Streamable HTTP: 현행 원격 전송

Streamable HTTP는 명세 2025-03-26에서 도입돼 2025년 11월 개정에도 유지된, 네트워크 너머로 동작하는 서버의 현행 전송입니다. 보통 /mcp 하나의 엔드포인트가 POST와 GET을 둘 다 받습니다. 클라이언트가 JSON-RPC 메시지를 POST하면, 서버는 단일 JSON 본문으로 답하거나 긴 호출엔 Server-Sent Events 스트림으로 응답을 승격합니다. 엔드포인트 하나, 두 가지 상호작용 패턴, 별도 이벤트 URL 없음.

어디서 깨지나: 무상태 친화적이고 재개(resumability) 가능한 설계지만, 상태 있는 세션은 여전히 수평 확장과 부딪힙니다. 상태 있는 서버를 세션 고정 없이 로드밸런서 뒤에 두면, 클라이언트가 자기 세션을 모르는 노드에 떨어질 수 있습니다. 2026 MCP 로드맵은 전송 확장성을 우선 과제로 꼽습니다: 세션 대 로드밸런서, 수평 확장, 서버 디스커버리. 이쪽은 계속 움직일 것입니다.

HTTP+SSE: 폐기됨, 데드라인과 함께

HTTP+SSE는 MCP의 원래 원격 전송으로, 명세 2024-11-05에 정의됐습니다. 엔드포인트를 두 개 씁니다. 클라이언트가 GET 연결을 지속적으로 잡아 server-sent event 스트림을 받고, 메시지는 따로 POST합니다. 동작은 하지만, 두 연결 설계는 네이티브 재개가 없고 로드밸런서·서버리스·방화벽에 적대적입니다. 프록시 버퍼링만으로도 이벤트 스트림이 조용히 끊깁니다.

명세 2025-03-26에서 Streamable HTTP가 대체하며 공식 폐기됐습니다. 서버는 하위호환으로 계속 돌릴 수 있지만, 클라이언트 지원은 나빠지기만 할 거고 플랫폼들이 제거 날짜를 못박고 있습니다: Keboola는 2026-04-01에 내렸고, Atlassian Rovo 데드라인은 2026-06-30, 2026년 내 더 따라옵니다. 이 날짜들은 발표 기준이니 플랫폼별로 확인하시기 바랍니다.

SSE 서버가 있다면 오늘은 아직 돕니다. 코드를 다음에 건드릴 때 마이그레이션하시기 바랍니다. 새로 만든다면 SSE는 건너뜁니다.

비교 매트릭스

전송로컬/원격상태엔드포인트재개주 실패 모드
stdio로컬현행해당 없음(파이프)해당 없음동시성 붕괴; 경로/spawn 에러
Streamable HTTP원격현행1개 (/mcp)가능로드밸런서 뒤 세션 고정
HTTP+SSE원격폐기2개 (GET+POST)불가프록시 버퍼링; 재개 없음

어떤 전송을 쓰나

상황사용
로컬 개발, 같은 머신, 단일 사용자stdio
새 원격 서버Streamable HTTP
기존 HTTP+SSE 서버Streamable HTTP로 마이그레이션
동시 클라이언트 다수Streamable HTTP (stdio 아님)
오늘 최대 클라이언트 호환stdio + Streamable HTTP 둘 다 지원

대부분 SDK는 서버 하나가 여러 전송에 바인딩하게 해줍니다. 흔한 패턴은 로컬 개발에 stdio, 프로덕션에 Streamable HTTP를 두고 환경 변수로 전환하는 것입니다. 도구 로직은 그대로고 전송 초기화만 다릅니다.

설정하기

로컬 stdio 서버는 클라이언트 설정에 명령, 인자, 환경 변수를 적습니다. Claude Desktop은 claude_desktop_config.json에, Cursor는 mcp.json에 둡니다. 모양은 같습니다. command + args + env.

원격 서버는 클라이언트를 URL로 가리킵니다. Streamable HTTP를 아직 네이티브로 못 쓰는 클라이언트는 mcp-remote 헬퍼로 다리를 놓을 수 있습니다. 원격 엔드포인트를 로컬 stdio 서버처럼 감싸줍니다. 정확한 키는 클라이언트와 버전마다 다르고 바뀌니, 옛 스니펫을 베끼지 말고 클라이언트 현재 문서를 확인하시기 바랍니다.

마이그레이션과 다음

SSE에서 옮기는 건 재작성이 아닙니다. 도구 로직은 안 바뀌고 전송 초기화가 바뀝니다. 전환기엔 두 전송을 병렬로 돌리다가, 플랫폼 데드라인이 압박으로 강제하기 전에 갈아탑니다.

더 멀리 보면 확장이 미해결 과제입니다. 공식 로드맵 너머로, IETF 인터넷 드래프트가 MCP over QUIC를 탐색 중입니다. Cisco·Google 엔지니어가 제안했고, head-of-line 블로킹 없이 고성능 멀티 에이전트 팬아웃을 노립니다. 지금은 stdio와 Streamable HTTP가 각각 로컬 개발과 원격 프로덕션을 덮고, 그게 실전 지도의 전부입니다.

이 갈래는 실제 서버에서 드러납니다. 금융 MCP 서버 중 공식 Financial Datasets 서버는 Streamable HTTP를 쓰고, 커뮤니티 Finnhub 래퍼는 SSE와 stdio를 제공합니다. 그 지형은 금융·트레이딩 MCP 서버 비교에 있습니다. 서버가 원격 옵션으로 ‘SSE’만 내건다면, 그건 곧 닥칠 마이그레이션 과제로 읽으시기 바랍니다.

자주 묻는 질문

Q. MCP 전송 방식은 몇 개인가요?

세 개가 정의돼 있지만 현행은 둘입니다. 로컬은 stdio, 원격은 Streamable HTTP. HTTP+SSE는 명세 2025-03-26에서 폐기됐습니다.

Q. SSE와 Streamable HTTP는 같은 건가요?

아닙니다. HTTP+SSE는 옛 2엔드포인트 전송입니다. Streamable HTTP는 단일 엔드포인트 대체재로, 긴 호출엔 SSE 스트림으로 승격할 수 있지만 별개의 전송입니다.

Q. 지금 당장 SSE 서버를 마이그레이션해야 하나요?

아직 돕니다. 단 플랫폼들이 2026년 내 제거 날짜를 잡고 있습니다(예: Keboola 2026-04-01, Atlassian Rovo 2026-06-30). 플랫폼 데드라인 전에 옮기시기 바랍니다.

Q. stdio가 spawn npx ENOENT로 실패하는 이유는 뭔가요?

명령이나 그 런타임이 클라이언트가 띄운 경로에 없습니다. MCP가 아니라 환경 문제입니다. 설정을 전체 경로로 가리키거나 실행 환경을 고치시면 됩니다.

Q. 서버 하나가 여러 전송을 지원할 수 있나요?

가능합니다. 대부분 SDK가 stdio와 Streamable HTTP를 동시에 바인딩하게 해줍니다(플래그나 환경 변수로 전환). 도구 로직은 공유됩니다.

Q. 새 프로젝트는 어떤 전송을 써야 하나요?

로컬 전용이면 stdio, 네트워크 너머면 Streamable HTTP입니다. 새 프로젝트를 HTTP+SSE로 시작하지 마시기 바랍니다.

출처

업데이트 기록

  • 2026-05-22 — 초기 게시. 전송 정의·명세 버전·폐기 타임라인은 MCP 명세·SDK 문서·플랫폼 폐기 공지에서 취합. 제거 데드라인은 발표 기준이며 바뀜, 플랫폼별 확인. 실패 모드 설명은 문서화된 커뮤니티 보고 기반의 editorial.

참고: 기술 레퍼런스, 2026년 5월 기준입니다. MCP 전송 명세는 진화 중이니, 구현 전에 현재 상태와 클라이언트 설정 형식을 확인하시기 바랍니다.

Last verified: May 2026

📊실측 핵심 지표 및 수치 (Key Empirical Statistics)

최저 (Zero-overhead)
STDIO 방식 연산 지연율
80/443 (방화벽 우회)
SSE 방식 표준 HTTP 포트
SSE (Server-Sent Events)
클라우드 서비스 권장 전송 방식

📚권위 있는 1차 출처 및 공식 문서 (References)