이 가이드에서는 다음을 확인하실 수 있습니다:
- MCP 전송 기술의 역사와 SSE에서 스트리밍 가능 HTTP로의 전환 배경.
- SSE의 정의와 이전 MCP 버전에서의 활용 방식.
- 스트리밍 HTTP(Streamable HTTP)란 무엇이며 현재 MCP 버전에서 어떻게 적용되는지.
- SSE와 스트리밍 HTTP를 비교한 요약표.
- 프로토콜 사양 개발 동향을 지속적으로 파악하는 방법.
자, 시작해 보겠습니다!
MCP가 사용하는 전송 프로토콜의 역사
오늘날 가장 인기 있고 널리 사용되는 AI 프로토콜 중 하나인 MCP(Modal Context Protocol)는 2026-03-26 버전부터 HTTP+SSE 전송 메커니즘을 스트리밍 HTTP로 대체했습니다. 이는 프로토콜 아키텍처의 중대한 변화를 의미합니다.
이제 이 두 전송 메커니즘이 무엇인지 설명하기 전에, 이 변경 사항을 더 잘 이해해 보겠습니다.
AI 프로토콜에 전송 메커니즘이 필요한 이유
MCP와 같은 AI 프로토콜은 프로토콜 아키텍처 내 다양한 구성 요소 간 정보 교환을 용이하게 하기 위해 전송 메커니즘이 필요합니다.
구체적으로 MCP는 클라이언트와 서버 간 통신에 JSON-RPC 2.0을 와이어 형식으로 사용합니다. JSON-RPC 메시지 전송을 위해 HTTP+SSE나 스트리밍 HTTP(로컬 서버의 표준 입력/출력을 통한 통신을 위한 stdio 내 기능) 같은 표준 전송 메커니즘에 의존합니다.
이러한 특수 전송 계층이 필요한 이유는 기존 HTTP의 요청-응답 모델이 실시간 AI 통신에는 비효율적이기 때문입니다. 일반 HTTP는 빈번한 연결 설정으로 인해 높은 오버헤드와 지연 시간을 유발합니다. 반면 MCP는 지속적이고 저지연 데이터 스트림을 요구하는데, 이는 HTTP+SSE와 스트리밍 HTTP가 처리하도록 설계된 영역입니다.
변경 배경
MCP는 원격 시나리오에서 서버-클라이언트 스트리밍을 지원하기 위해 초기에는 HTTP+SSE를 사용했습니다. 그러나 다음 세 가지 주요 한계로 인해 변경이 필요했습니다:
- 재개 가능한 스트림 지원 불가.
- 서버가 장기간 유지되고 고가용성 연결을 유지해야 함.
- 서버 메시지 전달을 SSE로만 제한함.
스트리밍 가능 HTTP는 이러한 문제점을 해결합니다. 상태 비저장 통신을 가능하게 하며 SSE로의 온디맨드 업그레이드까지 지원합니다. 이는 현대 인프라와의 호환성을 개선하고 보다 안정적이며 효율적인 통신을 보장합니다.
HTTP+SSE에서 스트리밍 가능 HTTP로의 전환 영향
전송 프로토콜로서 HTTP+SSE에서 스트리밍 가능 HTTP로의 전환은 MCP에 중요한 변화였습니다. 이는 프로토콜 구현에 상당한 변경을 가져왔으며, 많은 타사 MCP 클라이언트 및 서버 라이브러리의 적응을 요구했습니다.
그러나 현재 시점에서 MCP 클라이언트와 서버는 더 이상 사용되지 않는 HTTP+SSE 전송 방식과의 하위 호환성을 유지할 수 있습니다.
SSE (서버 전송 이벤트)
SSE(서버 전송 이벤트)는 웹 클라이언트가 서버로부터 자동 업데이트를 수신할 수 있게 하는 메커니즘입니다. 이러한 업데이트는“이벤트“로 알려져 있으며, 단일하고 오래 지속되는 HTTP 연결을 통해 전송됩니다.
WebSockets와 달리 SSE는 단방향으로, 데이터는 서버에서 클라이언트로만 흐릅니다. SSE는 서버가 일반적으로 text/event-stream MIME유형으로 형식화된 이벤트 스트림을 이 열린 연결을 통해 전송함으로써 작동합니다.
MCP에서의 HTTP+SSE 사용
MCP가 2024-11-05 버전에서 SSE를 활용한 방식은 다음과 같습니다:
서버는 두 개의 엔드포인트를 제공해야 합니다:
- 클라이언트가 연결을 설정하고 서버로부터 메시지를 수신하기 위한 SSE GET 엔드포인트.
- 클라이언트가 JSON-RPC 메시지를 서버로 전송하기 위한 일반 HTTP POST 엔드포인트.
클라이언트가 연결하면 서버는 클라이언트가 메시지 전송에 사용할 URI를 포함하는 엔드포인트 이벤트를 전송해야 합니다. 이후 모든 클라이언트 JSON-RPC 메시지는 이 URI로 HTTP POST 요청 형태로 전송됩니다.
서버는 열린 SSE 연결을 통해 이벤트를 스트리밍하여 응답하며, 이는 지속적 세션을 시뮬레이션합니다. 구체적으로, 서버 메시지는 SSE 메시지 이벤트로 전달되며, 이벤트 데이터 내 콘텐츠는 JSON으로 인코딩됩니다.
단일 응답의 경우 서버는 메시지를 전송한 후 스트림을 닫습니다. 지속적인 통신을 위해서는 연결이 유지됩니다.
장점과 단점
MCP에서 SSE 사용의 주요 장단점은 다음과 같습니다:
👍 대용량 결과 스트리밍: MCP 도구가 대용량 데이터를 처리하거나 외부 API 응답을 기다리는 동안 지연을 피하고 부분 결과를 즉시 전송할 수 있습니다.
👍 이벤트 기반 트리거: 변경 사항을 알리기 위한 비동기적 서버 이벤트(경고 또는 상태 업데이트)를 지원합니다.
👍 단순성: 표준 HTTP를 사용하므로 특별한 프로토콜이나 복잡한 설정이 필요하지 않습니다.
👎 단방향 전용: SSE 채널에서는 데이터가 서버에서 클라이언트로만 흐를 수 있습니다. 클라이언트는 메시지 전송을 위해 별도의 HTTP POST 요청을 사용해야 합니다.
👎 장기 연결 리소스 사용: 연결 유지 시 서버 리소스를 많이 소모할 수 있으며, 특히 대규모 환경에서 두드러집니다.
스트리밍 HTTP
MCP(Model-Client Protocol) 환경에서 스트리밍 가능 HTTP는 순수 HTTP를 사용하여 클라이언트와 서버 간 데이터를 스트리밍하는 방법입니다. 이는 장기간 연결 없이도 실시간 통신을 가능하게 합니다.
유연성과 하위 호환성을 위해 SSE를 계속 사용할 수는 있지만, 해당 전송 방식은 더 이상 필수적이지 않습니다. 이를 통해 MCP는 고가용성 지속적 연결 유지의 오버헤드 없이 상태 비저장 서버를 지원할 수 있습니다.
ℹ️ 추가: 웹소켓 대신 스트리밍 가능 HTTP + 선택적 SSE를 사용하는 이유?
- 단순한 상태 비저장 RPC 호출에 웹소켓을 사용하면 불필요한 네트워크 및 운영 오버헤드가 발생합니다.
- 브라우저는 WebSockets에
Authorization과같은 헤더를 첨부할 수 없으며, SSE와 달리 WebSockets는 표준 HTTP 도구로 재구현할 수 없습니다. - WebSocket 업그레이드는 GET 요청에서만 작동하므로, POST 기반 흐름은 필수 업그레이드 단계로 인해 복잡하고 느려집니다.
MCP의 스트리밍 가능 HTTP
스트림 가능 HTTP 전송에서 서버는 여러 클라이언트 연결을 처리할 수 있는 독립 프로세스 역할을 합니다. 통신에는 표준 HTTP POST 및 GET 요청을 사용합니다.
선택적으로 서버는 SSE를 사용하여 클라이언트에 여러 메시지를 스트리밍할 수 있습니다. 이는 간단한 요청/응답 도구를 위한 기본 MCP 서버와 스트리밍 및 실시간 서버-클라이언트 알림과 같은 고급 기능을 제공하는 서버 모두를 수용합니다.
서버는 POST 및 GET 메서드를 모두 지원하는 단일 HTTP 엔드포인트(“MCP 엔드포인트”라고함)를 노출해야 합니다.
아래 다이어그램은 스트리밍 가능 HTTP를 사용하는 MCP 클라이언트와 서버 간의 통신 흐름을 보여줍니다:
끊어진 연결 재개 및 잠재적으로 손실된 메시지 재전송을 지원하기 위해 MCP 서버는 스트림별로 고유 ID를 할당합니다. 이 ID는 각 스트림 내 커서 역할을 합니다.
가능한 상호작용의 다양성을 고려하여, 전체 구현 세부 사항은 공식 MCP 문서를 참조하십시오.
장점과 단점
MCP에서 스트리밍 HTTP 사용의 주요 장점은 다음과 같습니다:
👍 상태 비저장 서버 지원: 항상 활성화된 장기 연결이 필요하지 않습니다.
👍 일반 HTTP: SSE 없이도 표준 HTTP 서버로 구현 가능.
👍 인프라 친화적: 일반적인 HTTP 미들웨어, 프록시, 호스팅 플랫폼과 호환됩니다.
👍 하위 호환성: 기존 HTTP+SSE 전송 방식을 점진적으로 확장합니다.
👍 선택적 스트리밍: 필요 시 서버가 SSE로 업그레이드하여 응답을 스트리밍할 수 있습니다.
참고: 작성 시점 기준, 스트리밍 가능 HTTP 전송 메커니즘에 언급할 만한 단점은 없습니다.
SSE 대 스트리밍 가능 HTTP: 요약 비교
아래 SSE 대 스트리밍 가능 HTTP 표에서 두 전송 메커니즘을 비교하세요:
| 측면 | HTTP+SSE | 스트리밍 HTTP |
|---|---|---|
| 통신 유형 | 단방향 (서버 → 클라이언트) | 양방향 (클라이언트 ↔ 서버, GET/POST를 통해) |
| HTTP 프로토콜 사용 | 스트리밍용 GET, 클라이언트 메시지용 별도 POST | 단일 엔드포인트에서 표준 HTTP POST 및 GET 사용 |
| 상태 유지 | 상태 유지 | 상태 유지형이지만 상태 비저장 서버 지원 |
| 장기간 유지되는 HTTP 연결 필요 | 예 | 아니요 |
| 고가용성 필요 | 예, 연결 지속성을 위해 | 아니요, 상태 비저장 또는 일시적 서버와 작동 |
| 확장성 | 제한됨 | 높음 |
| 스트리밍 지원 | 예 ( text/event-stream을 통해) |
예 (선택적 향상 기능으로 SSE를 통해) |
| 인증 지원 | 예 | 예 |
| 재개 가능성 및 재배송 지원 | 아니요 | 아니요 |
| 클라이언트 수 | 다수 | 다중 |
| MCP에서의 사용 | 프로토콜 버전 2026-03-26부터 사용 중단됨 |
프로토콜 버전 2026-03-26에서 도입됨 |
| 하위 호환성 | — | SSE 기반 클라이언트와 완전한 하위 호환성 |
MCP의 전송 방식 미래
MCP는 2024년 11월에 출시되었으므로 아직 매우 젊은 프로토콜입니다. 이를 비교해 보면, 가장 널리 사용되는 버전인 HTTP 1.1은 거의 20년 동안 사용되어 왔습니다.
따라서 MCP 사양이 아직 진화 중이라는 점은 놀랍지 않습니다. 출시 몇 달 후 커뮤니티가 SSE에서 스트리밍 HTTP로 전환하기로 결정한 것처럼, 더 많은 변화가 곧 일어날 수 있습니다.
최신 정보를 확인하려면 공식 MCP GitHub 저장소의 ‘토론’ 페이지를 참고하세요. MCP 웹사이트에서도 향후 프로토콜 버전의 최신 초안을 검토할 수 있습니다.
결론
이 SSE 대 스트리밍 HTTP 비교 블로그 글에서는 MCP가 SSE에서 스트리밍 HTTP로 전환한 이유를 알아보았습니다. 특히, 이 두 전송 메커니즘이 무엇이며 인기 있는 AI 프로토콜 MCP에서 정보 전송에 어떤 영향을 미치는지 이해하셨을 것입니다.
여기서 설명한 바와 같이, 최신 비-비추천 MCP 사양을 따르려는 제3자 MCP 서버는 스트리밍 HTTP를 구현해야 합니다. 최신 기능이 풍부하고 강력한 MCP 서버를 찾고 계시다면 Bright Data의 MCP 서버를 살펴보세요.
Bright Data의 MCP 서버는 최신 버전의 fastmcp를 기반으로 구축되어 스트리밍 HTTP를 완벽히 지원하면서도 SSE와의 하위 호환성을 유지합니다. 20개 이상의 도구를 제공하여 신선한 웹 데이터로 AI 워크플로우를 확장하고, 모든 웹 페이지에서 에이전트 브라우저 상호작용을 수행하는 등 다양한 기능을 제공합니다.
AI 에이전트 개발을 위한 Google ADK와 MCP 서버 통합에 관한 완전한 튜토리얼은 저희 가이드를 참고하세요 .
지금 바로 Bright Data 계정을 무료로 생성하고, AI 에이전트와 애플리케이션을 구동할 인프라를 테스트해 보세요!
