오늘날 가장 주목받는 AI 프로토콜 중 하나인 **MCP(Modal Context Protocol)**는 2025년 3월 26일자 버전부터 기존의 HTTP+SSE 전송 메커니즘을 Streamable HTTP로 대체하는 중대한 아키텍처 변경을 단행했습니다.
이러한 변화는 단순한 기술 교체를 넘어, MCP가 지향하는 실시간 AI 통신의 효율성과 확장성을 극대화하기 위한 전략적 결정입니다.
이번 포스팅에서는 MCP와 같은 AI 프로토콜에서 전송 메커니즘이 왜 중요한지, 그리고 왜 MCP가 HTTP+SSE에서 Streamable HTTP로 전환했는지, 두 방식의 차이점과 이로 인한 영향을 심도 있게 분석해 보겠습니다.
AI 프로토콜에 전송 메커니즘이 필요한 이유
MCP와 같은 AI 프로토콜은 아키텍처 내의 여러 구성 요소 간에 원활한 정보 교환을 위해 효율적인 전송 메커니즘을 필요로 합니다.
MCP는 클라이언트와 서버 간의 통신을 위해 JSON-RPC 2.0을 기본 형식으로 사용하며, 이 메시지를 전송하기 위해 HTTP+SSE나 Streamable HTTP와 같은 표준 전송 메커니즘에 의존합니다.
왜 전통적인 HTTP 방식이 아닌 특화된 전송 계층이 필요할까요? 그 이유는 기존 HTTP의 요청-응답(request-response) 모델이 실시간 AI 통신에는 비효율적이기 때문입니다. 일반 HTTP는 잦은 연결 설정으로 인해 높은 오버헤드와 지연 시간(latency)을 유발합니다. 반면, MCP는 지속적이고 지연 시간이 짧은 데이터 스트림을 요구하며, HTTP+SSE와 Streamable HTTP는 바로 이러한 요구를 처리하도록 설계되었습니다.
MCP의 첫 번째 선택: HTTP+SSE
MCP는 초기에 원격 시나리오에서 서버가 클라이언트로 데이터를 스트리밍하기 위해 HTTP+SSE를 사용했습니다.
SSE (Server-Sent Events)란?
SSE는 웹 클라이언트가 서버로부터 자동으로 업데이트를 수신할 수 있게 하는 기술입니다. 이 업데이트는 "이벤트"라고 불리며, 단일하고 오래 지속되는(long-lived) HTTP 연결을 통해 전송됩니다.
웹소켓(WebSockets)과 달리 SSE는 **단방향(unidirectional)**이며, 데이터가 서버에서 클라이언트로만 흐릅니다. 서버는 text/event-stream MIME 타입으로 포맷된 이벤트 스트림을 전송하는 방식으로 작동합니다.
MCP에서의 HTTP+SSE (버전 2024-11-05)
MCP는 HTTP+SSE를 다음과 같은 방식으로 활용했습니다.
- 서버는 두 개의 엔드포인트를 제공해야 했습니다.
- 클라이언트가 연결을 설정하고 서버 메시지를 수신하기 위한 SSE GET 엔드포인트.
- 클라이언트가 JSON-RPC 메시지를 서버로 보내기 위한 일반 HTTP POST 엔드포인트.
- 클라이언트가 연결되면, 서버는 클라이언트가 메시지 전송에 사용할 URI가 포함된 endpoint 이벤트를 전송합니다.
- 클라이언트의 모든 JSON-RPC 메시지는 이 URI를 향해 HTTP POST 요청으로 전송됩니다.
- 서버는 열린 SSE 연결을 통해 이벤트를 스트리밍하여 응답합니다.
HTTP+SSE의 장단점
장점:
- 대용량 결과 스트리밍: MCP 도구가 대용량 데이터를 처리하거나 외부 API 응답을 기다리는 동안, 지연 없이 부분적인 결과를 즉시 전송할 수 있습니다.
- 이벤트 기반 트리거: 서버가 일방적으로 클라이언트에 변경 사항, 알림 또는 상태 업데이트를 알릴 수 있습니다.
- 단순성: 특별한 프로토콜이나 복잡한 설정 없이 표준 HTTP를 사용합니다.
단점:
- 단방향성: SSE 채널로는 데이터가 서버에서 클라이언트로만 흐를 수 있습니다. 클라이언트는 메시지를 보내기 위해 별도의 HTTP POST 요청을 사용해야 합니다.
- 리소스 소모: 연결을 계속 유지해야 하므로, 특히 대규모 환경에서 서버 리소스를 많이 소모할 수 있습니다.
진화의 시작: Streamable HTTP로의 전환
그렇다면 MCP는 왜 HTTP+SSE를 버리기로 결정했을까요? 여기에는 세 가지 주요 한계점이 있었습니다.
- 스트림 재개(Resumable) 미지원: 연결이 끊겼을 때 스트림을이어서 받을 수 없었습니다.
- 서버의 높은 가용성 요구: 서버가 오래 지속되는 연결을 항상 유지해야 했습니다.
- SSE를 통한 서버 메시지 전송만 허용: 유연성이 떨어졌습니다.
**Streamable HTTP**는 이러한 문제들을 해결합니다. 이 방식은 상태 비저장(stateless) 통신을 가능하게 하며, 필요에 따라 SSE로 업그레이드하는 것까지 지원합니다. 이는 최신 인프라와의 호환성을 높이고 더 안정적이며 효율적인 통신을 보장합니다.
새로운 표준: Streamable HTTP
MCP의 맥락에서 Streamable HTTP는 순수 HTTP를 사용하여 클라이언트와 서버 간에 데이터를 스트리밍하는 방식입니다. 이는 오래 지속되는 연결 없이도 실시간 통신을 가능하게 합니다.
유연성과 하위 호환성을 위해 여전히 SSE를 사용할 수 있지만, 더 이상 필수 사항이 아닙니다. 이로써 MCP는 고가용성의 영구적인 연결을 유지해야 하는 오버헤드 없이 상태 비저장(stateless) 서버를 지원할 수 있게 되었습니다.
잠깐: 왜 웹소켓(WebSockets)을 사용하지 않나요?
Streamable HTTP + 선택적 SSE가 웹소켓보다 선호되는 이유는 다음과 같습니다.
- 단순하고 상태 비저장인 RPC 호출에 웹소켓을 사용하면 불필요한 네트워크 및 운영 오버헤드가 추가됩니다.
- 브라우저는 웹소켓에 Authorization 같은 헤더를 첨부할 수 없으며, 표준 HTTP 도구로 재구현할 수 없습니다.
- 웹소켓 업그레이드는 GET 요청에서만 작동하므로, POST 기반 흐름을 복잡하고 느리게 만듭니다.
MCP에서의 Streamable HTTP (버전 2025-03-26)
Streamable HTTP 전송 방식에서 서버는 여러 클라이언트 연결을 처리할 수 있는 독립형 프로세스로 작동합니다. 통신을 위해 표준 HTTP POST 및 GET 요청을 사용합니다.
- 서버는 단일 HTTP 엔드포인트("MCP 엔드포인트")를 노출하며, 이 엔드포인트는 POST와 GET 메서드를 모두 지원합니다.
- 서버는 선택적으로 SSE를 사용하여 클라이언트에 여러 메시지를 스트리밍할 수 있습니다.
- 연결이 끊어졌을 때 메시지 재전송 및 스트림 재개를 지원하기 위해, MCP 서버는 스트림별로 ID를 할당하여 커서처럼 활용합니다.
Streamable HTTP의 장점
장점:
- 상태 비저장(Stateless) 서버 지원: 항상 연결을 유지할 필요가 없습니다.
- 순수 HTTP: SSE 없이도 모든 표준 HTTP 서버를 사용하여 구현할 수 있습니다.
- 인프라 친화적: 일반적인 HTTP 미들웨어, 프록시, 호스팅 플랫폼과 완벽하게 호환됩니다.
- 하위 호환성: 이전 HTTP+SSE 전송 방식을 기반으로 점진적으로 개선되었습니다.
- 선택적 스트리밍: 필요할 때만 서버가 SSE로 업그레이드하여 스트리밍 응답을 보낼 수 있습니다.
(참고: 이 글을 작성하는 시점에서 Streamable HTTP 전송 메커니즘의 주목할 만한 단점은 없습니다.)
한눈에 비교: HTTP+SSE vs Streamable HTTP
| 항목 | HTTP+SSE | Streamable HTTP |
| 통신 유형 | 단방향 (서버 → 클라이언트) | 양방향 (GET/POST를 통한 클라이언트 ↔ 서버) |
| HTTP 프로토콜 | 스트리밍용 GET, 클라이언트 메시지용 별도 POST | 단일 엔드포인트에서 표준 HTTP POST 및 GET 사용 |
| 상태 유지 | 상태 유지(Stateful) | 상태 유지(Stateful), 상태 비저장(Stateless) 서버 지원 |
| 연결 유지 | 예 (Long-lived HTTP) | 아니요 |
| 고가용성 요구 | 예 (연결 유지를 위해) | 아니요 (상태 비저장 또는 임시 서버에서도 작동) |
| 확장성 | 제한적 | 높음 |
| 스트리밍 지원 | 예 (text/event-stream) | 예 (선택적 SSE 향상 기능) |
| 인증 지원 | 예 | 예 |
| 재개/재전송 | 아니요 | 아니요 |
| MCP 사용 | 2025-03-26부터 사용되지 않음 (Deprecated) | 2025-03-26부터 도입됨 |
| 하위 호환성 | — | SSE 기반 클라이언트와 완벽 호환 |
MCP 전송 방식의 미래와 시사점
MCP는 2024년 11월에 출시된 매우 젊은 프로토콜입니다. 가장 널리 사용되는 HTTP 1.1이 거의 20년 동안 사용된 것을 감안하면, MCP 사양이 계속 진화하는 것은 놀라운 일이 아닙니다.
HTTP+SSE에서 Streamable HTTP로의 전환은 MCP가 더 유연하고, 확장 가능하며, 현대적인 인프라에 친화적인 방향으로 나아가고 있음을 보여줍니다.
이러한 변화는 MCP를 기반으로 서드파티 클라이언트나 서버 라이브러리를 개발하는 개발자들에게 중요한 시사점을 줍니다. 최신 MCP 사양을 따르려면 Streamable HTTP 구현이 필수적입니다.
만약 최신 사양을 준수하며 강력한 기능을 갖춘 MCP 서버를 찾고 있다면, fastmcp 최신 버전을 기반으로 구축된 Bright Data의 MCP 서버를 검토해 볼 수 있습니다. 이 서버는 Streamable HTTP를 완벽하게 지원하는 동시에 SSE와의 하위 호환성을 유지하며, 웹 데이터 수집, 에이전트 브라우저 상호작용 등 AI 워크플로우를 확장할 수 있는 20가지 이상의 도구를 제공합니다.
AI 에이전트와 애플리케이션의 성능을 극대화하고자 한다면, 이러한 프로토콜의 진화에 지속적으로 관심을 기울일 필요가 있습니다.
'인공지능' 카테고리의 다른 글
| 스펙 주도 개발(SDD)은 정말 워터폴의 귀환일까? - AI 코딩 에이전트 시대에 다시 등장한 문서 중심 개발 방식의 실체 (0) | 2025.11.18 |
|---|---|
| Grok 4.1, 대규모 업데이트로 돌아오다: 실제 성능이 달라진 이유 (0) | 2025.11.18 |
| Agents 2.0 시대의 도래: 얕은 루프를 넘어서는 딥 에이전트 아키텍처 (0) | 2025.11.17 |
| Google Workspace Flows 완벽 가이드: Gmail·Docs·Sheets 안에서 작동하는 진짜 AI 자동화의 시작 (0) | 2025.11.17 |
| AI Observability, 왜 지금 ‘통제(Control)’가 가장 중요한가? (0) | 2025.11.17 |
