Streamable HTTP: 현대 AI 서버 프로토콜이 바꾼 실전 구조—MCP와 SSE 시대를 넘어서

데이터 중심 AI 서버 프로토콜의 대변혁, 왜 Streamable HTTP인가? 

 

2025년, AI·서비스 백엔드 계에서 가장 핫한 변화 가운데 하나는 새로운 스트리밍 서버-클라이언트 프로토콜의 진화다.
과거 MCP(Modal Context Protocol)는 JSON-RPC 2.0 기반 메시지 구조, HTTP+SSE(SSE: Server-Sent Events)로 대표되는 통신 메커니즘을 공식 표준으로 삼고 있었다.
이 구조는 엔트로픽(Anthropic)이 2024년 11월 26일 최초로 제안, 오늘날 다양한 AI 시스템들이 클라이언트-서버 상호작용에 필수로 채택한 전송 프로토콜이 됐다.

 

1. MCP의 JSON-RPC 2.0 포맷

• 모든 메시지는 JSON 객체로 구성되고,  jsonrpc (버전),  method ,  params ,  id  필드를 사용한다.
• 반환값이 없는 경우  id: null 로 알림(Notification) 신호를 보내는 구조.
• 예시 요청:

{
  "jsonrpc": "2.0",
  "method": "generateSummary",
  "params": ["AI 스트림 프로토콜", true],
  "id": 42
}

• 성공시:

{
  "jsonrpc": "2.0",
  "result": "요약내용",
  "id": 42
}

• 실패시:

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32601,
    "message": "Method not found"
  },
  "id": 42
}

이처럼 간단한 JSON-RPC 포맷이

• 비동기 배치/알림 구분
• 플랫폼/언어 독립성
• 다양한 전송 계층 지원(HTTP, WebSocket, TCP 등)을
‘완벽하게’ 지원한다는 점에서 AI 프로토콜계의 핵심으로 자리잡았다.

 HTTP+SSE: 스트리밍 시대를 열었지만, 한계도 명확했던 구조 
초기 MCP 서버들은  HTTP + SSE  기반 표준 메커니즘을 사용했다.
서버가 클라이언트에 연속 메시지를 보내는 ‘persistent connection’을 제공하고, 양방향 통신을 위해

• 클라이언트 → 서버: HTTP POST
• 서버 → 클라이언트: SSE 스트림(GET /sse, Accept: text/event-stream)
이렇게 두 엔드포인트로 메시지를 주고받는 설계가 일반적이었다.

서버는 클라이언트에 최초 연결 시 endpoint 이벤트로 POST 대상 URI를 알려 주고,클라이언트는 이후 별도의 POST로 메시지를 전송한다.

예시 흐름:

1. 클라이언트가  /sse 로 SSE 연결 수립
2. 서버가  event: endpoint 로 메시지 전송 ( data: { "uri": "/send/7890" } )
3. 클라이언트는 URI로 POST해 명령/입력 전달
4. 서버가 클라이언트에 SSE로 message 이벤트( event: message ,  data: {...} )로 응답
 HTTP+SSE의 근본적 한계 
대중화 이후 대규모 MCP 운영 경험에서 SSE 기반 통신이 다음과 같은 문제를 노출시켰다.

1. 스트림 재개(resume) 불가

• 네트워크/서버 장애, 연결 단절시 스트림 이어받기가 불가능하다.
• 클라이언트가 처음부터 요청을 다시 보내야 하며, 서버는 전체 응답을 재생성해야 하는 비효율 발생.

2. 서버 리소스 소모 증가

• 모든 클라이언트와 연결을 장시간 유지,
• 수천~수만 연결 동시 유지 시 비정상적 부하 (로드밸런서, 게이트웨이 이슈 자주 발생).

3. 양방향 통신 제약

• SSE는 서버→클라이언트 단방향, 클라이언트→서버엔 꼭 HTTP POST 필요.
• 중단/취소/수정 등 ‘즉시 커맨드’ 시나리오엔 한계.
 MCP와 Streamable HTTP의 본격적인 전환: 이유와 구조 
이런 한계를 극복하고, 현대적 AI 프록시/서버 환경에 적합하게 MCP는 Streamable HTTP를 2025-03-26 공식 사양으로 채택했다.

1. 기본 설계

• MCP 서버는 GET/POST 모두 지원하는 단일 엔드포인트를 통해,
• 클라이언트가 POST로 JSON 메시지(예: generateText)를 보낸 뒤,
• 서버는 Transfer-Encoding: chunked + text/event-stream으로 응답을 chunk(조각) 단위로 “스트림처럼” 쏟아낸다.

2. 스트림 응답 예시

POST /mcp
Content-Type: application/json
Accept: text/event-stream

{ "jsonrpc": "2.0", "method": "generateText", "params": {"prompt":"날씨 알려줘"}, "id": 1 }

HTTP/1.1 200 OK
Content-Type: text/event-stream
Transfer-Encoding: chunked

data: { "jsonrpc": "2.0", "id": "1", "messageId": "msg-101", "result": "오늘 날씨는..." }
data: { "jsonrpc": "2.0", "id": "1", "messageId": "msg-102", "result": "...맑고 따뜻합니다." }
event: end
data: [DONE]

• 각 응답은 하나의 messageId를 가진 chunk로,
클라이언트는 순차적으로 메시지 수신 →
end 이벤트로 스트림 종료 인식.

3. Resume/재시작(Resumable Stream) 지원

• 연결 단절/장애 발생 시,
클라이언트가 마지막 messageId를 전달하고
서버는 그 시점 이후부터 chunk를 이어서 내보낸다.
• 중복, 누락, 전체 변조 없이 “세션 무결성”을 지킬 수 있음.

4. 리소스 효율/유연성

• 짧은 연결→스트림 수신→종료
• 많은 동시 사용자 환경, 로드밸런서와의 호환성 대폭 개선
• WebSocket 수준의 양방향 효율, HTTP 기반 호환성 유지
 Streamable HTTP의 실제 운용 이점 

• 고가용성: TCP/HTTP 끊김/재연결에도 중간부터 이어받기 가능
• 유연함: HTTP 환경 어디서나, chunked 응답 스트림으로 실시간 메시지 전달
• 양방향성 강화: POST/GET 혼합 지원, 서버-클라이언트 상호 ‘즉시’ 통신 가능
• 실시간 AI 응답 최적화: 텍스트·이미지·명령 등 대용량, 실시간 데이터 처리 모두 대응

결론: 왜 Streamable HTTP인가—현대 AI 서버·클라우드의 표준

MCP

MCP 프로토콜은 2025-03-26 공식 버전부터 HTTP+SSE 바탕의 기존 전송 방식에서 Streamable HTTP로 대변경했다.
이제 AI 서버·멀티 클라우드·고객 경험 중심 서비스 모두에서  “지연/장애/대용량 스트림/실시간성/양방향+유연한 구조”를 모두 만족시키는 현대적 프로토콜이 된 것이다.

이 변화 덕분에,
• AI 챗봇·헬퍼·멀티 메시징 등 고급 MCP 서비스 구현,
• 클라이언트·서버 모두에서 더 빠르고 견고한 AI 서비스
• 개발 생산성/호환성/서비스 교차 연동도 매우 손쉬워졌다.

참고 링크

• MCP Streamable HTTP 공식 사양: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports
• AI/SSE vs Streamable HTTP 비교: https://brightdata.com/blog/ai/sse-vs-streamable-http
• MCP 공식 Github PR: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/206