MCP SSE vs Streamable HTTP 차이: 무엇을 써야 하나요?

SSE는 지원 중단된 MCP의 이전 HTTP 트랜스포트이고, Streamable HTTP는 모든 메시지를 POST로 받는 단일 엔드포인트로 이를 대체했습니다. 무엇을 고를지 정리합니다.

읽는 시간 5분Sume
전체 글

SSE와 Streamable HTTP는 MCP가 HTTP로 메시지를 실어 나르는 이전 방식과 새 방식입니다. 프로토콜 버전 2024-11-05의 HTTP+SSE 트랜스포트는 엔드포인트 두 개를 썼습니다. 클라이언트가 연결해 서버의 메시지를 받는 Server-Sent Events 엔드포인트, 그리고 클라이언트의 POST를 받는 별도 엔드포인트입니다. Streamable HTTP는 이를 MCP 엔드포인트 하나로 대체했으며, 여기서는 모든 클라이언트 메시지가 새 POST이고 서버는 JSON이나 SSE 스트림으로 응답합니다. HTTP+SSE는 이제 지원 중단(deprecated)되었으므로, 서버가 Streamable HTTP를 제공한다면 언제나 Streamable HTTP를 고르세요.

트랜스포트 규칙은 MCP 명세의 2024-11-05, 2025-11-25, 2026-07-28 트랜스포트 페이지와 2026-07-28 변경 로그에서 가져왔습니다. 클라이언트별 명칭은 각 클라이언트의 문서에서, Sume 쪽 내용은 MCP 빠른 시작과 현재 서버 코드에서 가져왔습니다. 모두 2026-09-28에 확인했습니다.

SSE와 Streamable HTTP는 무엇이 다른가요?

이전 트랜스포트는 받기와 보내기를 엔드포인트 두 개로 나누고, 새 트랜스포트는 모든 것을 엔드포인트 하나에서 받으며 서버가 원할 때만 스트리밍합니다. 둘 다 HTTP 트랜스포트입니다. 클라이언트가 서버를 하위 프로세스로 실행하는 stdio와의 비교는 로컬 vs 원격 MCP 서버에서 다룹니다.

MCP 2024-11-05·2025-11-25 트랜스포트 페이지와 2026-07-28 변경 로그 기준, 2026-09-28 확인.
질문HTTP+SSEStreamable HTTP
상태2024-11-05 개정판에서 정의. 2025-03-26부터 지원 중단HTTP+SSE를 대체. MCP의 두 표준 트랜스포트 중 하나
엔드포인트두 개: SSE 엔드포인트와 일반 HTTP POST 엔드포인트https://example.com/mcp 같은 MCP 엔드포인트 하나
클라이언트는 어떻게 보내나요?클라이언트가 연결할 때 서버가 endpoint 이벤트로 알려 준 URI로 POST모든 메시지를 MCP 엔드포인트에 새 HTTP POST로 전송
서버는 어떻게 응답하나요?이벤트 데이터에 JSON을 담은 SSE message 이벤트요청마다 JSON 객체 하나(application/json) 또는 SSE 스트림(text/event-stream)

MCP에서 SSE는 지원 중단되었나요?

네. 2025-11-25 명세는 Streamable HTTP가 2024-11-05의 HTTP+SSE 트랜스포트를 대체한다고 밝힙니다. 2026-07-28 변경 로그는 2025-03-26부터 지원 중단 상태였던 HTTP+SSE를 MCP 기능 수명 주기 정책에 따라 Deprecated 단계로 재분류하고, "Migrate to Streamable HTTP."(Streamable HTTP로 마이그레이션)라는 지시를 달았습니다. 지원 중단된 기능은 삭제 대상이 되기 전까지 최소 열두 달, 신속 삭제 예외에서는 구십 일 동안 명세에 남으며, 새 구현은 이 기능을 채택하지 않아야 합니다.

이전 방식과 새 방식은 여전히 함께 동작할 수 있습니다. 명세의 하위 호환 절차에서 클라이언트는 먼저 URL에 initialize 요청을 POST합니다. 이것이 400, 404, 405로 실패하면 클라이언트는 GET을 보내고, 첫 이벤트가 endpoint인 이전 방식의 SSE 스트림을 기대합니다.

Streamable HTTP도 여전히 SSE를 쓰나요?

서버가 스트리밍하려 할 때만 씁니다. 클라이언트가 POST한 요청마다 서버는 Content-Type: application/json과 JSON 객체 하나를 반환하거나, text/event-stream을 반환해 SSE 스트림을 엽니다. 클라이언트는 둘 다 지원해야 합니다. 2025-11-25에서는 클라이언트가 엔드포인트에 GET을 보내, 서버가 먼저 시작하는 메시지를 받을 스트림을 열 수도 있습니다. 그런 스트림을 제공하지 않는 서버는 405 Method Not Allowed로 응답합니다. 2026-07-28 개정판은 이 GET 스트림을 subscriptions/listen 요청으로 대체합니다. 이 요청은 클라이언트가 옵트인하는, 변경 알림용 장기 스트림입니다. 모든 메시지는 여전히 POST이고, 응답은 JSON 객체나 요청 범위의 SSE 스트림으로 도착합니다.

MCP 클라이언트는 두 트랜스포트를 어떻게 표시하나요?

클라이언트마다 부르는 이름이 다르니, 고르기 전에 표시된 이름을 확인하세요. Claude Code v2.1.265부터는 --transport http로 SSE 전용 서버에도 연결됩니다. 먼저 HTTP를 시도하고, 서버가 받아들이지 않으면 SSE로 전환합니다.

Claude Code, GitHub Copilot CLI, AnythingLLM, Android Studio 문서 기준, 2026-09-28 확인.
클라이언트Streamable HTTPHTTP+SSE
Claude Code--transport http. JSON 설정에서는 streamable-http가 http의 별칭--transport sse. 문서에서 SSE 트랜스포트를 지원 중단으로 표시
GitHub Copilot CLIServer Type HTTPServer Type SSE. MCP 명세에서는 지원 중단이지만 하위 호환을 위해 계속 지원
AnythingLLM"type": "streamable""type": "sse". type이 없으면 이 값으로 간주
Android Studio(Gemini)httpUrlurl. SSE 엔드포인트는 보통 URL에 /sse가 들어 있음

Sume MCP 서버는 어떤 트랜스포트를 쓰나요?

Streamable HTTP만 씁니다. Sume 빠른 시작 문서는 streamable HTTP MCP 클라이언트가 https://mcp.sume.com/mcp를 가리키게 하라고 안내하므로, 클라이언트에서 HTTP나 Streamable HTTP 옵션을 고르고 SSE는 절대 고르지 마세요. AnythingLLM에서는 type을 명시적으로 설정하세요. type이 없으면 sse로 간주되기 때문입니다(AnythingLLM MCP 서버 설정).

현재 코드에서 Sume mcp_health 도구는 transport를 streamable_http로 보고하며, 서버는 POST로 들어온 요청마다 SSE 스트림이 아니라 JSON 응답 하나로 답합니다. SSE 클라이언트는 /mcp에 GET을 보내 연결하는데, 이 요청은 자격 증명이 없으면 401을 받고, 유효한 자격 증명이 있으면 405와 "Remote MCP uses POST JSON-RPC requests." 메시지를 받습니다. 그래서 SSE로 설정한 클라이언트는 이벤트 스트림을 끝내 받지 못합니다. 연결을 직접 확인하려면 MCP 서버 테스트 방법을 참고하세요.

Sume 기초 페이지는 호스팅 MCP가 여전히 동작하지만 현재 주 경로는 아니라고 설명합니다. n8n의 "SSE Endpoint" 필드 이름은 n8n MCP Client Tool과 Sume에서 다룹니다.

출처

관련 글

개발자 카테고리의 다른 글

개발자 글 전체 보기

작성자 Sume