Streaming 과 Resumability

Streamable HTTP 는 오래 걸리는 결과와 알림을 SSE stream 에 실어 보내. SSE 는 설계부터 재접속에 강해. Event 마다 id 를 붙일 수 있고, 끊긴 client 는 Last-Event-Id header 로 '그 id 다음 것부터 다 줘' 라고 요청할 수 있거든.

MCP 는 그 위에 resumability 를 명시적으로 얹었어. 이걸 지원하는 server 는 event id 를 계속 커지는 순서로 발급하고, 최근 event 를 일정 창만큼 메모리에 들고 있다가, client 가 다시 붙으면 그 Last-Event-Id 다음 것들을 몰아서 다시 보내줘. Client 입장에서는 네트워크가 잠깐 끊긴 게 결과를 잃는 사고가 아니라 잠깐 멈칫한 것으로 보여.

덕분에 오래 걸리는 tool 이 불안정한 네트워크에서도 살아남아. Resumability 가 없으면, 진행 상황을 흘려보내던 10 분짜리 build 에서 client 의 wifi 가 7 분에 끊기는 순간 10 분이 통째로 날아가. 있으면 client 가 7 분 반에 다시 붙어서 놓친 event 와 최종 결과를 받아.

비용은 server 가 들고 있어야 하는 buffer 야. Production server 는 보통 event 5,000 개나 5 분 정도로 상한을 둬 — 평범한 재접속에는 넉넉하면서 메모리가 새지도 않는 선이지. Buffer 를 언제 비우고 얼마나 들고 있을지는 client 가 못 건드리는 server 의 선택이야. 그러니 client 는 너무 오래 지나 다시 붙었을 때 '처음부터 다시' 라는 답을 받을 준비를 해둬야 해.

Code

Last-Event-Id 로 reconnect·text

GET /mcp HTTP/1.1
Mcp-Session-Id: sess_abc123
Accept: text/event-stream
Last-Event-Id: 0042

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

id: 0043
data: {"jsonrpc":"2.0","method":"notifications/progress","params":{...}}

id: 0044
data: {"jsonrpc":"2.0","id":7,"result":{...}}

Server 쪽: resumable id emit·python

# Pseudocode — 실제 SDK 가 resumability 켜져 있을 때 자동 처리
event_id = next_event_id()
sse.send(id=event_id, data=json.dumps(message))
buffer.append((event_id, message))
buffer.evict_older_than(now() - 300)  # 5 분 window

Exercise

오래 걸리는 MCP tool 을 찾거나 하나 짜 (진행 알림이 있는 30 초 이상짜리로). Client 로 돌리다가 stream 한복판에 네트워크를 끊었다 살려. 놓친 event 와 마지막 결과를 제대로 받는지 확인해. 그 복구가 얼마나 매끄러운지가 resumability 의 값이야.

Code

External links

Exercise

Progress

댓글 0