[태그:] SSE & Streamable HTTP

HTTP 스트리밍과 SSE의 원리부터 MCP의 Streamable HTTP, FastAPI·AI Agent 시스템의 통신 설계까지 따라가는 4부작.

SSE와 Streamable HTTP 4부 — FastAPI + AI Agent + MCP에서 SSE와 Streamable HTTP는 어디에 써야 할까?
지금까지 세 편에 걸쳐 SSE와 Streamable HTTP의 구조를 살펴봤습니다.

1부에서는 하나의 HTTP Response가 어떻게 데이터를 조금씩 전달할 수 있는지 알아봤습니다.
```
Request
   │
   ▼
Response
   │
   ├── data
   ├── data
   ├── data
   └── end
```
2부에서는 SSE만으로 모든 통신 문제를 해결할 수 없다는 것을 살펴봤습니다.

AI Agent와 같은 복잡한 시스템에서는 단순한 데이터 스트리밍을 넘어 다음과 같은 메시지 관계를 처리해야 합니다.
```
Request
Response
Notification
Streaming
Session
```
3부에서는 MCP가 왜 Streamable HTTP를 사용하는지 살펴봤습니다.
```
HTTP Request / Response
          +
필요할 때 Streaming
          =
Streamable HTTP
```
그렇다면 이제 실제 시스템을 만들어봅시다.

이번 글에서는 사용자가 웹에서 인보이스를 업로드하면 AI Agent가 MCP Tool을 이용해 데이터를 추출하는 서비스를 예제로 사용하겠습니다.

여기서 중요한 질문은 이것입니다.

Browser, FastAPI, Agent, MCP Server 사이에서 SSE와 Streamable HTTP를 각각 어디에 사용해야 할까?

1. 우리가 만들 시스템

사용자가 웹 화면에서 PDF 또는 이미지 인보이스를 업로드한다고 가정해보겠습니다.
```
Browser

[ invoice.pdf ]

[ 자동 입력 ]
```
사용자가 자동 입력 버튼을 누르면 서버에서 다음 작업이 실행됩니다.
```
파일 업로드
    │
    ▼
문서 분석
    │
    ▼
OCR / VLM
    │
    ▼
필드 추출
    │
    ▼
검증
    │
    ▼
결과 반환
```
최종적으로 다음과 같은 구조화된 데이터를 얻고 싶습니다.
```
{
  "invoice_number": "INV-2026-001",
  "invoice_date": "2026-09-15",
  "vendor": "ABC Corporation",
  "total_amount": 1250.00,
  "currency": "USD"
}
```
그리고 Browser는 이 값을 화면의 입력 필드에 자동으로 채웁니다.
```
Invoice Number : INV-2026-001

Invoice Date   : 2026-09-15

Vendor         : ABC Corporation

Total Amount   : 1,250.00

Currency       : USD
```
사용자 입장에서는 단순한 기능입니다.

하지만 내부에서는 여러 컴포넌트가 동작할 수 있습니다.

2. 전체 아키텍처부터 그려보자

시스템을 다음과 같이 구성해보겠습니다.
```
┌──────────────┐
│   Browser    │
│    Web UI    │
└──────┬───────┘
       │
       │ HTTP
       ▼
┌──────────────┐
│   FastAPI    │
│     API      │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│    Agent     │
│   Runtime    │
└──────┬───────┘
       │
       │ MCP
       ▼
┌──────────────┐
│  MCP Server  │
└──────┬───────┘
       │
       ├── Document Parser
       │
       ├── OCR / VLM
       │
       ├── Invoice Extractor
       │
       └── Validator
```
각 컴포넌트의 역할은 다릅니다.
```
Browser

사용자 인터페이스


FastAPI

외부 API Endpoint


Agent Runtime

작업 판단 및 Tool orchestration


MCP Server

Agent가 사용할 Tool 제공
```
여기서 중요한 것은 모든 구간에 같은 통신 방식을 사용할 필요가 없다는 것입니다.

3. Browser → FastAPI는 일반 HTTP로 시작한다

사용자가 파일을 업로드합니다.
```
Browser
   │
   │ POST /invoices/analyze
   ▼
FastAPI
```
예를 들어 다음과 같은 API가 있을 수 있습니다.
```
@app.post("/invoices/analyze")
async def analyze_invoice(file: UploadFile):
    ...
```
파일 업로드 자체는 일반적인 HTTP Request입니다.
```
POST /invoices/analyze

Content-Type: multipart/form-data
```
여기서 굳이 WebSocket이나 SSE를 사용할 이유는 없습니다.

Browser가 서버에게 명확한 요청을 보내는 동작이기 때문입니다.
```
Browser ───── Request ─────> FastAPI
```
4. 그런데 분석에 20초가 걸린다면?

문제는 그다음입니다.

인보이스 분석이 다음 과정을 거친다고 해보겠습니다.
```
PDF Rendering        2 sec
       │
       ▼
OCR / VLM            8 sec
       │
       ▼
Field Extraction     6 sec
       │
       ▼
Validation           4 sec
```
총 20초입니다.

가장 단순한 구현은 20초 동안 기다렸다가 결과를 반환하는 것입니다.
```
Browser                         FastAPI
   │                               │
   │──── POST /analyze ───────────>│
   │                               │
   │                               │
   │          20 seconds           │
   │                               │
   │                               │
   │<──── JSON Result ─────────────│
```
기술적으로 문제는 없습니다.

하지만 사용자 경험은 좋지 않습니다.

화면에서는 20초 동안 이런 상태만 보일 수 있습니다.
```
분석 중...

████████████████
```
사용자는 궁금해집니다.
```
정상적으로 처리되고 있는 건가?

서버가 멈춘 건가?

파일 업로드가 실패한 건가?

AI가 아직 분석하고 있는 건가?
```
그래서 진행 상황을 보여주고 싶어집니다.

5. 이 구간에서 SSE가 유용하다

Browser가 받고 싶은 정보는 대부분 서버에서 발생합니다.
```
파일 업로드 완료

PDF 변환 중

OCR 분석 중

필드 추출 중

데이터 검증 중

완료
```
통신 방향을 보면 명확합니다.
```
FastAPI ───────────────────> Browser
```
즉 Server → Client입니다.

이런 상황은 SSE가 잘하는 영역입니다.
```
Browser <══════ SSE ══════ FastAPI
```
예를 들어 서버가 다음과 같은 이벤트를 보낼 수 있습니다.
```
event: progress
data: {"step":"rendering"}

event: progress
data: {"step":"ocr"}

event: progress
data: {"step":"extracting"}

event: progress
data: {"step":"validating"}

event: completed
data: {"status":"completed"}
```
Browser에서는 이 이벤트를 받아 화면을 업데이트할 수 있습니다.
```
✓ 파일 업로드

✓ PDF 변환

● OCR 분석 중...

○ 필드 추출

○ 데이터 검증
```
사용자는 시스템이 실제로 무엇을 하고 있는지 알 수 있습니다.

6. FastAPI에서 SSE Endpoint 만들기

개념적으로 다음과 같은 Endpoint를 만들 수 있습니다.
```
from fastapi.responses import StreamingResponse


@app.get("/tasks/{task_id}/events")
async def task_events(task_id: str):

    async def event_generator():

        async for event in get_task_events(task_id):

            yield (
                f"event: {event.type}\n"
                f"data: {event.json()}\n\n"
            )

    return StreamingResponse(
        event_generator(),
        media_type="text/event-stream"
    )
```
Browser는 이 Endpoint에 연결합니다.
```
const source = new EventSource(
    `/tasks/${taskId}/events`
);

source.addEventListener(
    "progress",
    (event) => {
        console.log(event.data);
    }
);
```
이제 서버에서 이벤트가 발생할 때마다 Browser가 받을 수 있습니다.
```
FastAPI

yield progress
      │
      ▼
Browser

UI Update
```
7. 여기서 중요한 설계 포인트

한 가지 중요한 점이 있습니다.

SSE가 실제 분석 작업을 수행하는 것은 아닙니다.
```
SSE ≠ Worker
```
SSE는 작업 결과나 상태를 전달하는 통신 채널일 뿐입니다.

실제 작업은 Agent 또는 Worker가 수행할 수 있습니다.
```
FastAPI
   │
   │ enqueue
   ▼
Agent Worker
   │
   │ processing
   ▼
MCP Server
```
그리고 Worker가 작업 상태를 저장하거나 이벤트를 발행합니다.

예를 들어 Redis를 사용할 수 있습니다.
```
Agent Worker
     │
     │ progress event
     ▼
Redis
     │
     ▼
FastAPI
     │
     │ SSE
     ▼
Browser
```
전체 흐름은 다음과 같습니다.
```
Browser
   │
   │ HTTP
   ▼
FastAPI
   │
   │ enqueue
   ▼
Worker
   │
   │ progress
   ▼
Redis
   │
   ▼
FastAPI
   │
   │ SSE
   ▼
Browser
```
즉 SSE를 사용한다고 해서 HTTP Endpoint에서 긴 작업을 직접 수행해야 하는 것은 아닙니다.

8. 이제 Agent가 등장한다

FastAPI는 분석 요청을 Agent에게 전달합니다.
```
FastAPI
   │
   ▼
Agent Runtime
```
Agent의 역할은 단순히 OCR을 실행하는 것이 아닐 수 있습니다.

예를 들어 다음과 같이 판단할 수 있습니다.
```
파일 형식 확인
     │
     ▼
PDF인가?
     │
     ├── Yes → PDF Parser
     │
     └── No
          │
          ▼
        Image?
          │
          ▼
        OCR / VLM
```
그리고 결과에 따라 다른 Tool을 선택할 수 있습니다.
```
Agent
  │
  ├── parse_document()
  │
  ├── extract_invoice()
  │
  └── validate_invoice()
```
이 Tool들이 MCP Server에 있다고 가정해보겠습니다.

9. Agent → MCP Server에서는 통신의 성격이 달라진다

Agent가 MCP Tool을 호출합니다.
```
Agent
  │
  │ tools/call
  ▼
MCP Server
```
예를 들어 다음과 같은 호출입니다.
```
extract_invoice("invoice.pdf")
```
이것은 Browser에게 진행 상태를 알려주는 것과 성격이 다릅니다.

여기서는 명확한 RPC 관계가 있습니다.
```
Request

"extract_invoice를 실행해줘"

        ↓

MCP Server

        ↓

Response

"추출 결과는 이것이야"
```
즉 핵심은 Server → Client 스트리밍이 아니라,
```
Request
   ↓
Tool Execution
   ↓
Response
```
입니다.

이 구간에서 Streamable HTTP가 자연스럽습니다.

10. Streamable HTTP로 Tool 호출하기

전체 구조를 단순화하면 다음과 같습니다.
```
Agent                         MCP Server
  │                               │
  │──── POST /mcp ───────────────>│
  │                               │
  │       Tool Execution          │
  │                               │
  │<──── JSON Response ───────────│
```
빠르게 끝나는 Tool이라면 일반 JSON Response면 충분합니다.

예를 들어:
```
get_vendor_info()
```
같은 Tool이 100ms 안에 끝난다면 굳이 스트리밍할 이유가 없습니다.
```
POST /mcp
    │
    ▼
Tool
    │
    ▼
JSON Response
```
이것이 Streamable HTTP의 장점 중 하나입니다.

모든 Tool 호출을 Streaming으로 만들 필요가 없습니다.

11. 오래 걸리는 Tool이라면?

이번에는 extract_invoice()가 15초 걸린다고 해보겠습니다.
```
extract_invoice()
       │
       ▼
Rendering
       │
       ▼
VLM
       │
       ▼
Extraction
       │
       ▼
Validation
```
필요하다면 서버는 스트리밍 Response를 사용할 수 있습니다.
```
Agent                         MCP Server
  │                               │
  │──── POST /mcp ───────────────>│
  │                               │
  │<════ SSE Stream ══════════════│
  │<──── message ─────────────────│
  │<──── message ─────────────────│
  │<──── result ──────────────────│
```
즉 같은 Streamable HTTP에서도 상황에 따라 다르게 처리할 수 있습니다.
```
                 Tool Call
                     │
                     ▼
                MCP Server
                     │
           ┌─────────┴─────────┐
           │                   │
           ▼                   ▼
      빠른 작업             긴 작업
           │                   │
           ▼                   ▼
    JSON Response          SSE Stream
```
12. 이제 두 종류의 Streaming이 보인다

여기서 재미있는 부분이 나타납니다.

우리 시스템에는 두 종류의 Streaming이 존재할 수 있습니다.

첫 번째는:
```
FastAPI ───── SSE ─────> Browser
```
목적은 사용자 경험입니다.
```
"분석 시작"

"OCR 진행 중"

"추출 중"

"완료"
```
두 번째는:
```
MCP Server ─── Stream ───> Agent
```
목적은 Agent와 Tool Server 사이의 프로토콜 통신입니다.

둘 다 내부적으로 SSE를 사용할 수 있지만 목적은 전혀 다릅니다.
```
Browser SSE

목적:
사용자에게 진행 상황 전달


MCP Streaming

목적:
Agent와 MCP Server 사이 메시지 전달
```
이 차이를 이해하는 것이 중요합니다.

13. 전체 데이터 흐름을 다시 그려보자

이제 전체 시스템을 하나의 그림으로 연결해보겠습니다.
```
┌──────────────┐
│   Browser    │
└──────┬───────┘
       │
       │ POST /analyze
       ▼
┌──────────────┐
│   FastAPI    │
└──────┬───────┘
       │
       │ Task
       ▼
┌──────────────┐
│ Agent Worker │
└──────┬───────┘
       │
       │ Streamable HTTP
       ▼
┌──────────────┐
│  MCP Server  │
└──────┬───────┘
       │
       ├── OCR / VLM
       ├── Extractor
       └── Validator
```
그리고 사용자에게 진행 상황을 전달하는 별도의 흐름이 있습니다.
```
Agent Worker
      │
      │ progress
      ▼
    Redis
      │
      ▼
   FastAPI
      │
      │ SSE
      ▼
   Browser
```
두 흐름을 합치면 다음과 같습니다.
```
                         Streamable HTTP
                 ┌──────────────────────────┐
                 │                          ▼
Browser ───> FastAPI ───> Agent Worker ───> MCP Server
   ▲                            │                │
   │                            │                ├── OCR
   │                            │                ├── Parser
   │                            │                └── Validator
   │                            │
   │                            │ progress
   │                            ▼
   │                          Redis
   │                            │
   └────────── SSE ─────────────┘
```
이 그림이 이번 글의 핵심입니다.

14. Redis는 왜 중간에 넣을까?

Agent Worker에서 바로 Browser로 SSE를 보내면 되지 않을까요?
```
Agent Worker ─────> Browser
```
작은 시스템이라면 가능할 수 있습니다.

하지만 운영 환경에서는 Worker와 Web API를 분리하는 경우가 많습니다.
```
Web API

Worker #1

Worker #2

Worker #3
```
Browser는 FastAPI에 연결되어 있지만 실제 작업은 Worker #2가 수행하고 있을 수 있습니다.
```
Browser
   │
   ▼
FastAPI

Worker #2
```
두 프로세스는 서로 다른 서버에 있을 수도 있습니다.

그래서 중간에 이벤트 전달 계층을 둘 수 있습니다.
```
Worker
   │
   │ progress event
   ▼
Redis
   │
   ▼
FastAPI
   │
   ▼
Browser
```
Redis Streams나 Pub/Sub 같은 기능을 사용할 수 있습니다.

예를 들어 Worker가 다음 이벤트를 발행합니다.
```
{
  "task_id": "task-123",
  "type": "progress",
  "step": "ocr",
  "message": "OCR processing"
}
```
FastAPI는 해당 이벤트를 받아 SSE Client에게 전달합니다.

15. Redis Streams와 Pub/Sub 중 무엇을 쓸까?

진행 상황 전달만 필요하다면 Redis Pub/Sub도 사용할 수 있습니다.
```
Worker
   │
   │ publish
   ▼
Redis Pub/Sub
   │
   ▼
FastAPI
```
하지만 이벤트를 일정 기간 보존하거나 Consumer가 잠시 끊겼다가 다시 처리해야 한다면 Redis Streams가 더 적합할 수 있습니다.
```
Worker
   │
   │ XADD
   ▼
Redis Stream
   │
   ▼
FastAPI
```
이 둘의 차이를 아주 단순하게 표현하면 다음과 같습니다.
```
Pub/Sub

Worker ── publish ──> Redis ──> FastAPI

                      ↓

                그 순간 구독자가
                없으면 이벤트 소실


Streams

Worker ─── XADD ───> Redis Stream
                         │
                         ├── event 1
                         ├── event 2
                         ├── event 3
                         └── event 4
                              │
                              ▼
                           FastAPI
```
따라서 단순히 현재 접속 중인 사용자에게 진행 상황만 보여주는 것이 목적이라면 Pub/Sub으로도 충분할 수 있습니다.

반면 다음과 같은 요구사항이 있다면 Streams를 고려할 수 있습니다.
- 이벤트를 일정 시간 보존해야 한다.
- Consumer가 잠시 중단되어도 다시 읽어야 한다.
- 작업 처리 이력을 남겨야 한다.
- 여러 Consumer가 이벤트를 처리해야 한다.
- 장애 이후에도 이벤트 처리를 이어가야 한다.
중요한 것은 SSE와 Redis Streams를 같은 종류의 기술로 생각하지 않는 것입니다.
```
Redis Streams

Backend 내부의 이벤트 전달 / 저장


SSE

Backend → Browser 이벤트 전달
```
서로 다른 계층에서 다른 문제를 해결합니다.

16. 최종 결과는 어떻게 Browser까지 전달할까?

이제 Agent의 작업이 완료됐다고 생각해보겠습니다.

MCP Server가 구조화된 결과를 반환합니다.
```
{
  "invoice_number": "INV-2026-001",
  "invoice_date": "2026-09-15",
  "vendor": "ABC Corporation",
  "total_amount": 1250.00,
  "currency": "USD"
}
```
이 결과는 먼저 Agent에게 전달됩니다.
```
MCP Server
     │
     │ Tool Result
     ▼
   Agent
```
Agent는 결과를 검증하거나 여러 Tool의 결과를 조합할 수도 있습니다.
```
OCR Result
     │
     ├──────────┐
     │          │
     ▼          ▼
Extractor    Validator
     │          │
     └────┬─────┘
          ▼
      Final Result
```
최종 결과가 준비되면 Backend에 저장할 수 있습니다.
```
Agent
  │
  │ save result
  ▼
Database
```
그리고 작업 완료 이벤트를 발행합니다.
```
Agent
  │
  │ completed
  ▼
Redis
```
FastAPI는 이 이벤트를 받아 Browser에 전달합니다.
```
Redis
  │
  ▼
FastAPI
  │
  │ SSE
  ▼
Browser
```
예를 들어 마지막 SSE Event는 다음과 같을 수 있습니다.
```
event: completed
data: {
  "task_id": "task-123",
  "invoice_number": "INV-2026-001",
  "vendor": "ABC Corporation",
  "total_amount": 1250.00
}
```
Browser는 이 이벤트를 받으면 화면의 입력 필드를 자동으로 채웁니다.
```
Invoice Number
[ INV-2026-001          ]

Vendor
[ ABC Corporation       ]

Total
[ 1,250.00              ]

Currency
[ USD                    ]
```
이제 사용자가 처음 눌렀던 자동 입력 버튼의 전체 작업이 완료됩니다.

17. 그런데 최종 결과까지 SSE로 보내야 할까?

여기서 설계 선택지가 하나 생깁니다.

완료 이벤트에 최종 결과 전체를 담을 수도 있습니다.
```
SSE

event: completed
data: { ... final result ... }
```
하지만 다른 방법도 있습니다.

완료 여부만 SSE로 전달하는 것입니다.
```
event: completed
data: {
  "task_id": "task-123"
}
```
그다음 Browser가 별도의 API를 호출합니다.
```
Browser
   │
   │ GET /tasks/task-123/result
   ▼
FastAPI
   │
   ▼
Database
   │
   ▼
JSON Result
```
즉 다음과 같이 역할을 나눌 수 있습니다.
```
SSE

상태 변화 알림


REST API

최종 데이터 조회
```
이 구조는 꽤 실용적입니다.

SSE 연결이 중간에 끊겨도 최종 결과 자체는 Database에 남아 있기 때문입니다.
```
SSE 연결 끊김
      │
      X

하지만

Database
   │
   └── Result 존재
```
Browser는 다시 접속한 뒤 현재 작업 상태를 조회할 수 있습니다.
```
GET /tasks/task-123
```
응답:
```
{
  "task_id": "task-123",
  "status": "completed"
}
```
그리고 결과를 다시 가져올 수 있습니다.
```
GET /tasks/task-123/result
```
실제 운영 환경에서는 이런 구조가 장애 복구 측면에서 더 안전할 수 있습니다.

18. SSE 연결이 끊어지면 작업도 중단될까?

여기서 아주 중요한 문제가 하나 있습니다.

사용자가 Browser를 닫았다고 생각해봅시다.
```
Browser
   │
   X
SSE Disconnect
```
그렇다면 Agent 작업도 중단해야 할까요?

반드시 그렇지는 않습니다.

SSE는 작업 실행 채널이 아니라 작업 상태를 관찰하는 채널이기 때문입니다.
```
Browser
   │
   │ SSE
   ▼
FastAPI


Agent Worker
   │
   │ Task Processing
   ▼
MCP Server
```
Browser 연결과 실제 작업의 생명주기를 분리할 수 있습니다.

따라서 Browser가 닫혀도:
```
Browser
   X

Agent Worker
   │
   ├── OCR
   ├── Extract
   ├── Validate
   └── Complete
```
작업은 계속 수행될 수 있습니다.

사용자가 다시 접속하면 현재 상태를 조회합니다.
```
GET /tasks/task-123
```
예를 들어:
```
{
  "task_id": "task-123",
  "status": "completed"
}
```
이 구조에서 중요한 원칙이 하나 나옵니다.

Client 연결의 생명주기와 Backend Task의 생명주기를 분리한다.

Long-running AI 작업을 설계할 때 상당히 중요한 원칙입니다.

19. 그렇다면 사용자가 작업을 취소하면?

이번에는 사용자가 명시적으로 취소 버튼을 눌렀다고 생각해보겠습니다.
```
[ 분석 취소 ]
```
이것은 SSE로 보낼 필요가 없습니다.

Client → Server 요청이기 때문입니다.

일반 HTTP API로 충분합니다.
```
Browser
   │
   │ POST /tasks/task-123/cancel
   ▼
FastAPI
```
FastAPI는 Task 상태를 변경합니다.
```
RUNNING

   ↓

CANCEL_REQUESTED
```
그리고 Worker가 이를 확인합니다.
```
Worker
   │
   │ cancel requested?
   ▼
  Yes
   │
   ▼
Stop Processing
```
최종 상태는 다음과 같이 바뀔 수 있습니다.
```
CANCEL_REQUESTED
       │
       ▼
   CANCELLED
```
그리고 다시 SSE로 Browser에 알립니다.
```
FastAPI
   │
   │ SSE
   ▼
Browser

event: cancelled
```
전체 흐름을 보면 재미있습니다.
```
                 HTTP POST
Browser ─────────────────────> FastAPI
             cancel


                    Backend
                       │
                       ▼
                    Worker
                       │
                    cancelled
                       │
                       ▼


                    SSE
Browser <───────────────────── FastAPI
            cancelled
```
즉 하나의 기능 안에서도 HTTP Request와 SSE가 함께 사용됩니다.

20. Human-in-the-Loop가 들어가면 더 재미있어진다

AI Agent가 항상 자동으로 모든 결정을 내릴 수 있는 것은 아닙니다.

예를 들어 인보이스 금액이 너무 크거나 추출 신뢰도가 낮다고 생각해보겠습니다.
```
Total Amount

₩ 95,000,000


Confidence

0.62
```
Agent가 판단합니다.
```
Confidence < 0.7

       ↓

Human Review Required
```
작업 상태를 변경합니다.
```
RUNNING
   │
   ▼
WAITING_HUMAN
```
그리고 사용자에게 SSE 이벤트를 보냅니다.
```
event: human_review_required
data: {
  "task_id": "task-123",
  "reason": "low_confidence"
}
```
Browser에서는 검토 화면을 보여줍니다.
```
AI가 추출한 값의 확인이 필요합니다.

Vendor
[ ABC Corporation ]

Total
[ 95,000,000 ]

[ 승인 ]    [ 수정 ]    [ 거절 ]
```
사용자가 승인합니다.

이것은 다시 Client → Server 요청입니다.
```
Browser
   │
   │ POST /tasks/task-123/approve
   ▼
FastAPI
```
Agent는 작업을 재개합니다.
```
WAITING_HUMAN
      │
      │ approve
      ▼
   RUNNING
      │
      ▼
   COMPLETED
```
전체 흐름은 다음과 같습니다.
```
Agent
  │
  │ Human Review Required
  ▼
Redis
  │
  ▼
FastAPI
  │
  │ SSE
  ▼
Browser
  │
  │ Approve
  ▼
FastAPI
  │
  ▼
Agent
  │
  ▼
Continue
```
이 구조를 보면 SSE와 HTTP Request의 역할이 아주 명확하게 나뉩니다.
```
Server → Client 상태 알림

SSE


Client → Server 사용자 액션

HTTP Request
```
21. Agent와 MCP 사이에서도 HITL이 가능하다

조금 더 깊게 들어가면 Human-in-the-Loop가 Agent Runtime 내부에 들어갈 수도 있습니다.
```
Agent
  │
  │ Tool Call
  ▼
MCP Server
  │
  ▼
Invoice Tool
  │
  ▼
Low Confidence
```
Agent Runtime은 현재 상태를 Checkpoint에 저장합니다.
```
Agent State

{
  task_id,
  current_step,
  tool_result,
  extracted_fields,
  status
}
```
그리고 실행을 멈춥니다.
```
RUNNING
   │
   ▼
WAITING_HUMAN
```
사용자 승인이 들어오면 저장된 상태에서 다시 시작합니다.
```
Checkpoint
    │
    ▼
Agent Resume
    │
    ▼
Next Step
```
이때 Transport와 Runtime을 구분해서 생각하는 것이 중요합니다.
```
SSE

상태 전달


Streamable HTTP

Agent ↔ MCP 통신


Checkpoint

Agent 실행 상태 저장
```
각 기술이 해결하는 문제가 완전히 다릅니다.

22. 실패 처리도 생각해야 한다

실제 운영에서는 성공보다 실패 처리가 더 중요할 때가 많습니다.

예를 들어 MCP Tool 호출이 실패했다고 생각해보겠습니다.
```
Agent
  │
  │ tools/call
  ▼
MCP Server
  │
  X
VLM Timeout
```
Agent는 Retry 정책을 적용할 수 있습니다.
```
Attempt 1
   │
   X

Retry

Attempt 2
   │
   X

Retry

Attempt 3
   │
   ▼
Success
```
이 과정도 사용자에게 모두 보여줄 필요는 없습니다.

Browser에서는 단순히:
```
AI 분석 중...
```
이라고 보여줄 수도 있습니다.

즉 내부 이벤트와 사용자 이벤트를 분리하는 것이 좋습니다.
```
Internal Event

tool_retry
mcp_timeout
worker_retry
model_fallback


User Event

processing
review_required
completed
failed
```
Backend 내부 구현 세부사항을 그대로 Browser에 노출하면 UI와 Backend가 지나치게 강하게 결합될 수 있습니다.

23. Event를 계층별로 나누자

실제 시스템에서는 이벤트를 다음과 같이 나누는 것이 좋습니다.

Infrastructure Event
```
worker_started
worker_retry
redis_error
mcp_reconnect
```
운영 및 모니터링 용도입니다.

Agent Event
```
tool_started
tool_completed
tool_failed
human_review_required
```
Agent Runtime의 상태를 표현합니다.

User Event
```
processing
progress
review_required
completed
failed
```
사용자 UI에 전달하기 위한 이벤트입니다.

전체 구조는 다음과 같습니다.
```
Infrastructure
      │
      ▼
Agent Runtime
      │
      ▼
Application Event
      │
      ▼
User Event
      │
      ▼
SSE
      │
      ▼
Browser
```
이렇게 한 단계 추상화하면 Backend 내부 구현이 변경되어도 Frontend에 미치는 영향을 줄일 수 있습니다.

24. SSE Event Schema도 미리 정의하는 것이 좋다

처음에는 다음과 같이 문자열만 보내기 쉽습니다.
```
data: OCR 진행 중
```
하지만 시스템이 커지면 구조화된 이벤트가 필요해집니다.

예를 들어:
```
{
  "event": "progress",
  "task_id": "task-123",
  "step": "ocr",
  "progress": 40,
  "message": "OCR을 진행하고 있습니다."
}
```
완료 이벤트:
```
{
  "event": "completed",
  "task_id": "task-123",
  "progress": 100
}
```
실패 이벤트:
```
{
  "event": "failed",
  "task_id": "task-123",
  "error_code": "VLM_TIMEOUT",
  "message": "문서 분석에 실패했습니다."
}
```
이렇게 Schema를 정의해두면 Frontend 구현도 단순해집니다.
```
event == progress
      ↓
Progress UI


event == completed
      ↓
Result UI


event == failed
      ↓
Error UI
```
25. Task 상태도 명확하게 정의하자

Long-running 작업이라면 이벤트뿐만 아니라 Task 자체의 상태도 필요합니다.

예를 들어:
```
PENDING

RUNNING

WAITING_HUMAN

COMPLETED

FAILED

CANCELLED
```
상태 전이를 그려보면 다음과 같습니다.
```
PENDING
   │
   ▼
RUNNING
   │
   ├──────────────> FAILED
   │
   ├──────────────> CANCELLED
   │
   ├──> WAITING_HUMAN
   │          │
   │          ▼
   │       RUNNING
   │
   ▼
COMPLETED
```
이 상태는 Database에 저장하는 것이 좋습니다.
```
tasks

task_id
status
current_step
progress
result_id
error_code
created_at
updated_at
```
SSE는 이 상태 변화를 실시간으로 전달하는 역할을 합니다.

다시 말해:

SSE 자체를 상태 저장소로 사용해서는 안 됩니다.

26. 연결이 끊겨도 복구할 수 있는 구조

이제 시스템이 상당히 안정적으로 변했습니다.

Browser의 SSE 연결이 끊겼다고 생각해봅시다.
```
Browser
   X
Network Error
```
Agent 작업은 계속 진행됩니다.
```
Agent Worker
   │
   ├── OCR
   ├── Extraction
   └── Validation
```
상태는 Database에 저장됩니다.
```
task-123

status = COMPLETED
```
사용자가 다시 페이지를 엽니다.
```
Browser
   │
   │ GET /tasks/task-123
   ▼
FastAPI
```
서버가 현재 상태를 반환합니다.
```
{
  "task_id": "task-123",
  "status": "completed"
}
```
Browser는 결과를 가져옵니다.
```
GET /tasks/task-123/result
```
즉 실시간 연결이 끊어져도 시스템의 상태는 사라지지 않습니다.

이것이 운영 가능한 Long-running AI 시스템에서 매우 중요한 특성입니다.

27. 전체 아키텍처를 완성해보자

지금까지의 내용을 모두 합쳐보겠습니다.
```
                        ┌─────────────────┐
                        │     Browser     │
                        └───────┬─────────┘
                                │
                    HTTP Request│
                                ▼
                        ┌─────────────────┐
                        │     FastAPI     │
                        └───────┬─────────┘
                                │
                             enqueue
                                │
                                ▼
                        ┌─────────────────┐
                        │  Agent Worker   │
                        └───────┬─────────┘
                                │
                     Streamable HTTP
                                │
                                ▼
                        ┌─────────────────┐
                        │   MCP Server    │
                        └───────┬─────────┘
                                │
                  ┌─────────────┼─────────────┐
                  ▼             ▼             ▼
                Parser        OCR/VLM      Validator


Agent Worker
     │
     │ progress / status
     ▼
┌───────────────┐
│ Redis Streams │
└───────┬───────┘
        │
        ▼
    FastAPI
        │
        │ SSE
        ▼
     Browser


Agent Worker
     │
     │ state / result
     ▼
┌───────────────┐
│   Database    │
└───────────────┘
```
이제 각각의 통신 방식이 담당하는 역할이 명확하게 보입니다.
```
Browser → FastAPI
    일반 HTTP Request

FastAPI → Agent Worker
    Task 전달

Agent Worker ↔ MCP Server
    Streamable HTTP

Agent Worker → Redis
    Backend Event

FastAPI → Browser
    SSE

Agent Worker → Database
    Task 상태 / 최종 결과 저장
```
중요한 것은 이 구조에서 어느 하나의 기술이 전체 시스템의 통신을 담당하지 않는다는 점입니다.

각 구간의 요구사항에 가장 적합한 방식을 선택합니다.

28. 요청부터 완료까지 전체 흐름

이제 사용자가 자동 입력 버튼을 누르는 순간부터 화면에 데이터가 채워질 때까지 전체 과정을 순서대로 따라가 보겠습니다.

Step 1. 사용자가 분석을 요청한다
```
Browser
   │
   │ POST /invoices/analyze
   │ invoice.pdf
   ▼
FastAPI
```
FastAPI는 Task를 생성합니다.
```
{
  "task_id": "task-123",
  "status": "pending"
}
```
그리고 바로 Browser에 반환합니다.
```
HTTP 202 Accepted
```
즉 파일 분석이 끝날 때까지 HTTP Request를 붙잡고 있지 않습니다.

Step 2. Browser가 진행 상황을 구독한다

Browser는 Task ID를 이용해 SSE Endpoint에 연결합니다.
```
GET /tasks/task-123/events
```
연결 구조는 다음과 같습니다.
```
Browser
   │
   │ GET /events
   ▼
FastAPI
   │
   │
   └════ SSE Stream ════> Browser
```
이제 Browser는 서버에서 발생하는 상태 변화를 받을 준비가 됐습니다.

Step 3. Worker가 작업을 시작한다
```
FastAPI
   │
   │ enqueue
   ▼
Agent Worker
```
Task 상태가 변경됩니다.
```
PENDING
   │
   ▼
RUNNING
```
Worker는 이벤트를 발행합니다.
```
{
  "event": "progress",
  "step": "started",
  "progress": 5
}
```
이 이벤트가 Redis를 거쳐 Browser까지 전달됩니다.
```
Worker
  │
  ▼
Redis
  │
  ▼
FastAPI
  │
  │ SSE
  ▼
Browser
```
Step 4. Agent가 필요한 Tool을 결정한다

Agent가 문서를 확인합니다.
```
Agent

"What type of document is this?"

        │
        ▼

Invoice PDF
```
Agent는 필요한 Tool을 선택합니다.
```
parse_document()

extract_invoice()

validate_invoice()
```
Step 5. Agent가 MCP Tool을 호출한다
```
Agent
  │
  │ tools/call
  ▼
MCP Server
```
이 구간에서는 Streamable HTTP가 사용됩니다.
```
Agent                         MCP Server
  │                               │
  │──── POST /mcp ───────────────>│
  │                               │
  │       Tool Execution          │
  │                               │
  │<──── Result ──────────────────│
```
빠른 작업이라면 일반 JSON Response가 반환될 수 있습니다.

필요한 경우에는 Streaming Response를 사용할 수도 있습니다.

Step 6. 작업 진행 상황을 사용자에게 전달한다

Agent가 OCR 단계에 들어갑니다.
```
Agent Worker
     │
     │ progress
     ▼
Redis
```
FastAPI가 이벤트를 전달합니다.
```
FastAPI
   │
   │ SSE
   ▼
Browser
```
사용자 화면은 다음과 같이 변경됩니다.
```
✓ 파일 업로드 완료

✓ PDF 변환 완료

● OCR 분석 중...

○ 데이터 추출

○ 데이터 검증
```
Step 7. 데이터 추출이 완료된다

MCP Tool이 구조화된 데이터를 반환합니다.
```
{
  "invoice_number": "INV-2026-001",
  "invoice_date": "2026-09-15",
  "vendor": "ABC Corporation",
  "total_amount": 1250.00,
  "currency": "USD"
}
```
Agent가 결과를 검증합니다.
```
Extraction Result
       │
       ▼
   Validation
       │
       ▼
  Final Result
```
Step 8. 결과를 저장한다
```
Agent Worker
     │
     │ Final Result
     ▼
Database
```
Task 상태도 변경합니다.
```
RUNNING
   │
   ▼
COMPLETED
```
Step 9. 완료 이벤트를 전달한다
```
Agent Worker
     │
     ▼
Redis
     │
     ▼
FastAPI
     │
     │ SSE
     ▼
Browser
```
Browser가 다음 이벤트를 받습니다.
```
event: completed
data: {
  "task_id": "task-123"
}
```
Step 10. Browser가 최종 결과를 가져온다
```
Browser
   │
   │ GET /tasks/task-123/result
   ▼
FastAPI
   │
   ▼
Database
```
결과를 반환합니다.
```
{
  "invoice_number": "INV-2026-001",
  "invoice_date": "2026-09-15",
  "vendor": "ABC Corporation",
  "total_amount": 1250.00,
  "currency": "USD"
}
```
그리고 화면에 자동으로 입력합니다.
```
Invoice Number
[ INV-2026-001       ]

Invoice Date
[ 2026-09-15         ]

Vendor
[ ABC Corporation    ]

Total
[ 1,250.00           ]

Currency
[ USD                 ]
```
사용자 입장에서는 단순히 버튼 하나를 눌렀지만 Backend에서는 여러 종류의 통신이 협력하고 있었습니다.

29. 왜 모든 것을 SSE로 만들지 않을까?

여기까지 보면 이런 생각도 들 수 있습니다.

이미 SSE 연결이 있는데 그냥 모든 데이터를 SSE로 주고받으면 안 될까?

문제는 SSE 자체가 Server → Client 이벤트 전달을 위한 방식이라는 것입니다.

Client가 분석을 시작하는 것은 명확한 Command입니다.
```
POST /analyze
```
작업을 취소하는 것도 Command입니다.
```
POST /tasks/{id}/cancel
```
승인하는 것도 Command입니다.
```
POST /tasks/{id}/approve
```
반면 진행 상황은 Event입니다.
```
processing

progress

review_required

completed
```
그래서 역할을 다음처럼 나누면 구조가 명확해집니다.
```
Command

Browser ───── HTTP ─────> Server


Event

Browser <───── SSE ────── Server
```
이 패턴은 꽤 이해하기 쉽습니다.

Client의 의도는 HTTP Request로 전달하고, Server에서 발생하는 변화는 SSE Event로 전달한다.

30. 왜 모든 것을 WebSocket으로 만들지 않을까?

WebSocket으로도 구현할 수 있습니다.
```
Browser <════════════════> Server

analyze
progress
cancel
review
approve
completed
```
하지만 이 시스템에서는 Browser가 서버로 지속적인 실시간 데이터를 보내야 하는 상황이 많지 않습니다.

대부분의 Client → Server 동작은 명확한 Command입니다.
```
Analyze

Cancel

Approve

Reject
```
그리고 대부분의 Server → Client 데이터는 상태 변화입니다.
```
Processing

Progress

Review Required

Completed
```
따라서 굳이 전체 시스템을 지속적인 Full-Duplex 연결로 만들 필요가 없다면,
```
HTTP + SSE
```
조합이 더 단순할 수 있습니다.

물론 실시간 음성 대화나 공동 편집처럼 양쪽에서 지속적인 데이터가 발생한다면 이야기는 달라집니다.

그때는 WebSocket이 더 자연스러울 수 있습니다.

31. 왜 Browser가 MCP Server를 직접 호출하지 않을까?

이런 구조도 생각할 수 있습니다.
```
Browser
   │
   │ MCP
   ▼
MCP Server
```
하지만 일반적인 업무용 AI 시스템에서는 중간에 Application Backend를 두는 것이 자연스럽습니다.
```
Browser
   │
   ▼
FastAPI
   │
   ▼
Agent
   │
   ▼
MCP Server
```
FastAPI와 Agent Runtime에는 다음과 같은 책임이 있기 때문입니다.
```
Authentication

Authorization

Tenant Isolation

Business Logic

Task Management

Rate Limiting

Audit Logging

Agent Orchestration

HITL

Usage Tracking
```
MCP Server의 책임은 조금 다릅니다.
```
Tool 제공

Resource 제공

외부 시스템 접근

기능 실행
```
즉 다음과 같이 책임을 나누는 것입니다.
```
FastAPI

Application Boundary


Agent Runtime

Decision / Orchestration


MCP Server

Tool Boundary
```
이렇게 분리하면 MCP Tool을 다른 Agent에서도 재사용하기 쉬워집니다.

32. FastAPI와 FastMCP의 역할도 명확해진다

이 구조를 이해하면 자주 나오는 질문도 자연스럽게 해결됩니다.

FastMCP를 사용하는데 FastAPI는 왜 필요한가?

둘은 경쟁 관계가 아닙니다.

FastAPI는 사용자가 접근하는 Application API를 담당할 수 있습니다.
```
Browser
   │
   ▼
FastAPI

POST /login

POST /documents

POST /invoices/analyze

GET /tasks/{id}

GET /tasks/{id}/result
```
FastMCP 기반 MCP Server는 Agent가 사용하는 Tool Interface를 담당할 수 있습니다.
```
Agent
   │
   ▼
MCP Server

tools/list

tools/call

resources/read
```
전체적으로 보면:
```
User
 │
 ▼
Web UI
 │
 ▼
FastAPI
 │
 ▼
Agent
 │
 ▼
FastMCP
 │
 ▼
Tools
```
각 계층의 책임이 다릅니다.

33. 결국 Transport는 계층별로 선택한다

전체 시스템에서 사용된 통신 방식을 다시 정리해보겠습니다.
```
Browser
   │
   │ HTTP Request
   ▼
FastAPI
```
사용자의 명령 전달입니다.
```
FastAPI
   │
   │ Task Queue
   ▼
Agent Worker
```
장시간 작업을 API Process와 분리합니다.
```
Agent
   │
   │ Streamable HTTP
   ▼
MCP Server
```
Agent가 Tool을 호출합니다.
```
Agent Worker
   │
   │ Event
   ▼
Redis Streams / PubSub
```
Backend 내부에서 상태 변화를 전달합니다.
```
FastAPI
   │
   │ SSE
   ▼
Browser
```
사용자에게 실시간 진행 상황을 전달합니다.

어느 하나가 다른 것을 대체하는 관계가 아닙니다.

각자의 역할이 있습니다.

34. 선택 기준을 아주 단순하게 정리하면

일반 HTTP

이런 질문을 해봅니다.

Client가 요청하고 결과를 받으면 끝나는가?

그렇다면 일반 HTTP가 가장 단순합니다.
```
Client ─── Request ───> Server
Client <── Response ─── Server
```
SSE

이런 요구사항이라면 SSE를 고려합니다.

Server에서 발생하는 데이터를 Client에게 계속 전달해야 하는가?
```
Server ───────────────> Client
```
예:
```
LLM Streaming

Progress

Notification

Agent Status
```
WebSocket

이런 요구사항이라면 WebSocket을 고려합니다.

양쪽에서 지속적으로 실시간 메시지를 보내야 하는가?
```
Client <══════════════> Server
```
예:
```
Realtime Chat

Voice

Game

Collaborative Editing

Realtime Control
```
Streamable HTTP

이런 요구사항이라면 Streamable HTTP가 잘 맞습니다.

RPC Request/Response를 기본으로 하면서 필요할 때 Streaming도 필요한가?
```
Request
   │
   ▼
Response

or

Request
   │
   ▼
Stream
```
MCP가 대표적인 사례입니다.

Redis Streams / PubSub

이것은 Browser 통신 방식의 선택과는 다른 문제입니다.

질문은 다음과 같습니다.

Backend Process 사이에서 이벤트를 어떻게 전달할 것인가?
```
Worker
   │
   ▼
Redis
   │
   ▼
API
```
즉 애플리케이션 내부 메시징 계층의 문제입니다.

35. 가장 중요한 설계 원칙

이번 구조에서 몇 가지 중요한 원칙을 얻을 수 있습니다.

첫 번째는:

작업 실행과 Client 연결의 생명주기를 분리한다.
```
SSE Disconnect

≠

Task Cancel
```
두 번째는:

실시간 이벤트와 영구 상태를 분리한다.
```
SSE / Redis

Event


Database

State
```
세 번째는:

Client Command와 Server Event를 구분한다.
```
Command

Client ─── HTTP ───> Server


Event

Client <─── SSE ──── Server
```
네 번째는:

Agent와 Tool의 경계를 명확하게 한다.
```
Agent

판단 / Orchestration


MCP Server

Tool 제공 / 실행
```
그리고 마지막으로:

하나의 통신 기술로 모든 문제를 해결하려 하지 않는다.

이 원칙이 가장 중요할 수 있습니다.

마치며

이번 시리즈는 SSE라는 비교적 단순한 기술에서 시작했습니다.

1부

HTTP 연결 하나로 데이터를 계속 보내는 SSE
```
HTTP Response
   │
   ├── data
   ├── data
   ├── data
   └── end
```
하나의 HTTP Response가 어떻게 데이터를 조금씩 전달할 수 있는지 살펴봤습니다.

2부

SSE만으로는 부족한가? 양방향 통신과 RPC의 문제
```
Request

Response

Notification

Streaming
```
복잡한 AI 시스템에서는 단순한 Server → Client 스트리밍만으로는 충분하지 않다는 것을 살펴봤습니다.

3부

MCP는 왜 Streamable HTTP를 사용하는가
```
HTTP Request / Response
          +
필요할 때 Streaming
          =
Streamable HTTP
```
MCP가 왜 HTTP의 단순함을 유지하면서 필요할 때 스트리밍할 수 있는 Transport를 사용하는지 살펴봤습니다.

그리고 이번 4부에서는 이 기술들을 실제 AI Agent 시스템 안에 배치해봤습니다.
```
Browser
   │
   │ HTTP
   ▼
FastAPI
   │
   ▼
Agent Worker
   │
   │ Streamable HTTP
   ▼
MCP Server
   │
   ├── Parser
   ├── OCR / VLM
   ├── Extractor
   └── Validator
```
동시에 사용자에게 진행 상황을 전달합니다.
```
Agent Worker
     │
     ▼
Redis
     │
     ▼
FastAPI
     │
     │ SSE
     ▼
Browser
```
결국 SSE, WebSocket, Streamable HTTP, Redis Streams는 서로 경쟁하는 기술이 아닙니다.

각자 다른 문제를 해결합니다.
```
HTTP
    Request / Response


SSE
    Server → Client Streaming


WebSocket
    Full-Duplex Communication


Streamable HTTP
    RPC + Optional Streaming


Redis Streams
    Backend Event Messaging
```
AI 시스템이 복잡해질수록 중요한 것은 새로운 기술을 많이 사용하는 것이 아닙니다.

각 통신이 무엇을 위해 존재하는지 구분하는 것입니다.

사용자의 요청인지,

서버의 이벤트인지,

Agent의 Tool 호출인지,

Backend 내부의 상태 변화인지,

영구적으로 보존해야 하는 상태인지.

이 경계를 명확하게 나누면 시스템의 구조도 자연스럽게 단순해집니다.

그리고 그때 SSE와 Streamable HTTP가 어디에 필요한지도 훨씬 명확하게 보이기 시작합니다.
2026년 10월 05일
SSE와 Streamable HTTP 3부 — MCP는 왜 Streamable HTTP를 사용하는가
1부에서는 SSE가 하나의 HTTP Response를 유지하면서 데이터를 조금씩 전달하는 원리를 살펴봤습니다.

2부에서는 한 단계 더 나아가 이런 질문을 던졌습니다.

SSE만으로 복잡한 AI 시스템의 통신을 처리할 수 있을까?

SSE는 Server → Client 방향의 스트리밍에는 매우 유용합니다.

WebSocket을 사용하면 양방향 통신도 가능합니다.

하지만 MCP 같은 RPC 기반 시스템에서 중요한 것은 단순히 단방향인가, 양방향인가의 문제가 아니었습니다.

MCP에서는 다양한 형태의 메시지를 처리해야 합니다.
```
Request
Response
Notification
Streaming
Session
```
그리고 2부 마지막에 이런 질문을 남겼습니다.

HTTP의 단순한 Request/Response 구조를 유지하면서, 필요한 순간에만 스트리밍할 수는 없을까?

이번 글에서 살펴볼 Streamable HTTP가 바로 이 질문과 연결됩니다.

1. 먼저 이름부터 살펴보자

Streamable HTTP라는 이름을 처음 보면 흔히 이렇게 생각할 수 있습니다.
```
SSE
 ↓
새로운 스트리밍 기술
 ↓
Streamable HTTP
```
하지만 이렇게 이해하면 조금 어색합니다.

Streamable HTTP는 SSE를 대체하는 새로운 스트리밍 포맷이라고 보기보다는,

HTTP를 기본 전송 방식으로 사용하면서 필요할 때 스트리밍까지 사용할 수 있도록 구성한 MCP의 Transport 방식이라고 이해하는 편이 좋습니다.

이름도 자세히 보면
```
Streaming HTTP
```
가 아니라
```
Streamable HTTP
```
입니다.

항상 Streaming하는 HTTP가 아니라,

필요하면 Stream할 수 있는 HTTP

라는 관점입니다.

2. 가장 단순한 경우부터 생각해보자

MCP Client가 MCP Server에게 Tool 목록을 요청한다고 해보겠습니다.
```
MCP Client                     MCP Server
    │                              │
    │──── tools/list ─────────────>│
    │                              │
    │<──── tool list ──────────────│
    │                              │
```
이 요청은 일반적인 Request/Response로 충분합니다.

굳이 장시간 연결을 유지하거나 지속적인 이벤트 스트림을 만들 필요가 없습니다.

개념적으로는 평범한 HTTP 요청처럼 처리할 수 있습니다.
```
POST /mcp
Content-Type: application/json

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list"
}
```
서버가 처리한 뒤 결과를 반환합니다.
```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        ...
    }
}
```
구조만 보면 우리가 오래전부터 사용해온 HTTP API와 크게 다르지 않습니다.
```
Client
   │
   │ HTTP POST
   ▼
Server
   │
   │ 처리
   ▼
JSON Response
```
여기까지만 보면 스트리밍은 필요하지 않습니다.

3. 그런데 모든 Tool이 빨리 끝나는 것은 아니다

이번에는 다른 Tool을 호출해보겠습니다.
```
tools/call
    │
    ▼
analyze_invoice()
```
인보이스 분석 Tool 내부에서 다음과 같은 작업이 발생한다고 해봅시다.
```
PDF
 │
 ▼
Rendering
 │
 ▼
OCR / VLM
 │
 ▼
Field Extraction
 │
 ▼
Validation
 │
 ▼
Result
```
이 작업이 20초 걸린다고 생각해봅시다.

가장 단순한 방법은 20초를 기다린 뒤 결과를 반환하는 것입니다.
```
Client                         Server
   │                              │
   │──── tools/call ─────────────>│
   │                              │
   │                              │
   │         20 seconds           │
   │                              │
   │                              │
   │<──── result ─────────────────│
```
기술적으로 아무 문제 없습니다.

하지만 경우에 따라 서버가 처리 과정에서 여러 메시지를 전달해야 할 수도 있습니다.
```
processing...

OCR completed

extracting...

validating...

completed
```
이제 단순 JSON Response 하나만으로는 표현하기 불편해집니다.

이때 스트리밍이 필요해집니다.

4. Streamable HTTP의 핵심 구조

Streamable HTTP의 핵심 아이디어를 단순화하면 다음과 같습니다.
```
                  POST /mcp

MCP Client ───────────────────────> MCP Server
```
Client는 MCP 메시지를 HTTP POST로 보냅니다.

그런데 서버의 Response는 상황에 따라 달라질 수 있습니다.

단순한 요청이라면:
```
MCP Client                     MCP Server
    │                              │
    │──── POST /mcp ──────────────>│
    │                              │
    │<──── JSON Response ──────────│
```
스트리밍이 필요하다면:
```
MCP Client                     MCP Server
    │                              │
    │──── POST /mcp ──────────────>│
    │                              │
    │<════ SSE Stream ═════════════│
    │<──── message ────────────────│
    │<──── message ────────────────│
    │<──── message ────────────────│
    │<──── result ─────────────────│
```
즉 같은 HTTP 기반 Transport 안에서 상황에 따라 다른 Response 형태를 사용할 수 있습니다.
```
                 POST /mcp
                     │
                     ▼
                MCP Server
                     │
            ┌────────┴────────┐
            │                 │
            ▼                 ▼
     JSON Response       SSE Stream
```
이 구조가 Streamable HTTP를 이해하는 가장 중요한 그림입니다.

5. 여기서 SSE가 사라진 것이 아니다

이 부분에서 많이 헷갈립니다.

MCP가 기존 SSE Transport에서 Streamable HTTP로 이동했다고 하면,

“이제 MCP에서는 SSE를 사용하지 않는구나.”

라고 생각할 수 있습니다.

그렇지 않습니다.

Streamable HTTP에서도 SSE가 사용될 수 있습니다.

차이는 SSE가 Transport 전체를 지배하는 구조가 아니라는 것입니다.

개념적으로 보면 다음과 같습니다.
```
Streamable HTTP
      │
      ├── HTTP POST
      │
      ├── JSON Response
      │
      └── SSE Response
```
즉 SSE는 사라진 것이 아니라 필요한 경우 사용할 수 있는 스트리밍 메커니즘으로 들어가 있습니다.

그래서 이름이 꽤 정확합니다.
```
HTTP
 +
optional streaming
 =
Streamable HTTP
```
6. 기존 SSE Transport는 어떻게 동작했을까?

이 차이를 이해하려면 기존 MCP의 HTTP+SSE Transport를 살펴보는 것이 좋습니다.

단순화하면 Client는 먼저 SSE 연결을 만들었습니다.
```
MCP Client                     MCP Server
    │                              │
    │──── GET /sse ───────────────>│
    │                              │
    │<════ SSE Connection ═════════│
    │                              │
```
그리고 서버는 이 SSE 연결을 통해 Client가 메시지를 보낼 HTTP endpoint를 알려줄 수 있었습니다.

개념적으로 다음과 같은 구조입니다.
```
                  SSE
MCP Client <════════════════ MCP Server
    │
    │
    │ POST message
    └──────────────────────> MCP Server
```
즉 메시지 흐름을 단순화하면:
```
Client → Server
    HTTP POST

Server → Client
    SSE
```
였습니다.

그래서 두 개의 통신 경로를 관리하게 됩니다.
```
          POST
Client ─────────────> Server

          SSE
Client <═════════════ Server
```
동작은 가능하지만 구조가 조금 복잡합니다.

7. Streamable HTTP에서는 구조가 단순해진다

Streamable HTTP에서는 MCP 통신을 하나의 MCP HTTP endpoint 중심으로 구성할 수 있습니다.

예를 들어:
```
POST /mcp
```
입니다.

Client가 메시지를 보냅니다.
```
Client
   │
   │ POST /mcp
   ▼
MCP Server
```
서버는 요청 특성에 따라 적절한 Response를 반환합니다.
```
                  POST /mcp
                      │
                      ▼
                 MCP Server
                      │
          ┌───────────┴───────────┐
          │                       │
          ▼                       ▼
  application/json        text/event-stream
          │                       │
          ▼                       ▼
     JSON Response            SSE Stream
```
이렇게 보면 Streamable HTTP라는 이름이 훨씬 이해하기 쉬워집니다.

8. 그런데 GET은 왜 필요할까?

여기서 조금 더 깊이 들어가보겠습니다.

Streamable HTTP에서 핵심은 POST이지만, 경우에 따라 Client가 서버에서 발생하는 메시지를 받기 위한 SSE Stream을 열 수 있습니다.

개념적으로는 다음과 같습니다.
```
MCP Client                     MCP Server
    │                              │
    │──── GET /mcp ───────────────>│
    │                              │
    │<════ SSE Stream ═════════════│
    │                              │
```
이 연결을 통해 서버가 Client에게 메시지를 전달할 수 있습니다.

즉 전체적으로 보면 이런 형태가 가능합니다.
```
                POST /mcp
Client ─────────────────────────> Server


                 GET /mcp
Client ─────────────────────────> Server
Client <════════ SSE ════════════ Server
```
여기서 중요한 것은 모든 요청마다 반드시 SSE 연결이 필요한 것은 아니라는 점입니다.

필요한 통신 패턴에 따라 사용할 수 있습니다.

9. 하나의 Endpoint가 중요한 이유

기존 구조를 다시 보겠습니다.
```
/sse

/messages
```
처럼 통신 역할이 나뉘어 있을 수 있었습니다.

Streamable HTTP에서는 개념적으로 다음처럼 단순화됩니다.
```
/mcp
```
그리고 HTTP Method가 역할을 구분합니다.
```
POST /mcp
    │
    └── Client → Server message


GET /mcp
    │
    └── Server → Client SSE stream
```
이 구조는 일반적인 HTTP 인프라와도 잘 맞습니다.

예를 들어:
```
Client
   │
   ▼
Load Balancer
   │
   ▼
API Gateway / Reverse Proxy
   │
   ▼
MCP Server
```
기존 HTTP 운영 환경에서 다루기 훨씬 자연스러운 구조가 됩니다.

10. HTTP 인프라를 그대로 활용할 수 있다

WebSocket은 매우 강력하지만 일반 HTTP와 연결 생명주기가 다릅니다.
```
HTTP

Request
   ↓
Response
   ↓
End
```
WebSocket은 연결을 Upgrade한 뒤 장시간 유지합니다.
```
HTTP
 │
 │ Upgrade
 ▼
WebSocket
 │
 │
 │ persistent connection
 │
 │
 ▼
```
반면 Streamable HTTP는 기본적으로 HTTP의 세계에 남아 있습니다.
```
HTTP POST

HTTP GET

HTTP Status

HTTP Header

Authentication

Proxy

Load Balancer
```
따라서 기존 웹 인프라와 자연스럽게 통합할 수 있다는 장점이 있습니다.

특히 MCP Server를 실제 운영 환경에 배포한다고 생각하면 이 차이가 중요해집니다.

11. Stateless하게 사용할 수도 있다

Streamable HTTP의 또 다른 중요한 특징은 반드시 모든 Client 연결에 대해 무거운 장기 세션 상태를 유지해야 하는 것은 아니라는 점입니다.

예를 들어 아주 단순한 MCP Server라면:
```
Client
   │
   │ POST tools/call
   ▼
Server
   │
   │ Tool 실행
   ▼
Response
```
요청 하나가 끝나면 서버가 별도의 연결 상태를 유지하지 않아도 됩니다.

이런 구조는 서버 확장에도 유리합니다.
```
                 Load Balancer
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
      MCP #1        MCP #2        MCP #3
```
특정 Client가 반드시 같은 서버 프로세스에 계속 붙어 있어야 하는 구조보다 운영이 단순해질 수 있습니다.

물론 실제 MCP 시스템에서는 세션이 필요한 경우도 있습니다.

중요한 것은 Transport 자체가 모든 통신을 하나의 영구 연결에 강하게 묶지 않는다는 것입니다.

12. Session이 필요한 경우도 있다

반대로 Client와 Server 사이에 상태를 유지해야 하는 경우도 있습니다.

예를 들어 Server가 Client에게 Session ID를 제공한다고 생각해봅시다.
```
Client                         Server
   │                              │
   │──── initialize ─────────────>│
   │                              │
   │<──── Session ID: abc123 ─────│
```
이후 Client는 해당 Session을 식별해서 요청할 수 있습니다.
```
POST /mcp

Mcp-Session-Id: abc123
```
개념적으로 보면:
```
Client
   │
   │ Session abc123
   │
   ├──── tools/list
   │
   ├──── tools/call
   │
   └──── resources/read
   │
   ▼
MCP Server
```
따라서 Streamable HTTP는 단순한 Stateless HTTP만을 의미하는 것도 아닙니다.

필요한 경우 Session을 유지할 수도 있습니다.

13. 그래서 Streamable HTTP는 양방향인가?

여기서 재미있는 질문이 생깁니다.

Streamable HTTP는 양방향 통신인가?

WebSocket과 같은 의미의 Full-Duplex 양방향 연결이라고 생각하면 조금 다릅니다.

WebSocket은 하나의 연결에서 양쪽이 자유롭게 메시지를 보냅니다.
```
Client <════════════════════> Server
```
Streamable HTTP는 기본적으로 HTTP Request와 Response 모델을 사용합니다.
```
Client ───── Request ───────> Server
Client <──── Response ─────── Server
```
필요한 경우 서버 방향의 스트림을 추가할 수 있습니다.
```
Client ───── GET ───────────> Server
Client <════ SSE ════════════ Server
```
따라서 통신 결과만 보면 양쪽 방향의 메시지를 처리할 수 있지만,

WebSocket처럼 하나의 Full-Duplex 연결을 만드는 방식과는 구조적으로 다릅니다.

14. 세 가지를 다시 비교해보자

이제 SSE, WebSocket, Streamable HTTP를 한 번에 비교해보겠습니다.

SSE
```
Server ───────────────────> Client
```
특징:
- Server → Client 스트리밍
- HTTP 기반
- 단순한 이벤트 스트림
- LLM 응답이나 진행 상태 전달에 적합
WebSocket
```
Server <══════════════════> Client
```
특징:
- Full-Duplex
- 지속적인 연결
- 양쪽에서 자유롭게 메시지 전송
- 실시간 상호작용에 적합
Streamable HTTP
```
Client ───── POST ─────────> Server
Client <──── JSON ────────── Server

필요한 경우

Client <════ SSE ═══════════ Server
```
특징:
- HTTP Request/Response 중심
- 필요할 때 Streaming
- SSE 사용 가능
- RPC 형태의 통신에 적합
- 기존 HTTP 인프라와 잘 맞음
즉 셋은 누가 더 좋은 기술인가를 비교하는 관계가 아닙니다.

해결하려는 문제가 다릅니다.

15. 실제 AI 서비스에서는 어떻게 사용할까?

이제 실제 시스템에 적용해봅시다.

사용자가 웹에서 인보이스를 업로드하고 AI Agent가 이를 분석한다고 가정하겠습니다.

전체 구조는 다음과 같습니다.
```
Browser
   │
   │ POST /analyze
   ▼
FastAPI
   │
   ▼
Agent
   │
   │ MCP
   ▼
MCP Client
   │
   │ Streamable HTTP
   ▼
MCP Server
   │
   ├── OCR Tool
   ├── Invoice Parser
   └── Validation Tool
```
여기서 두 종류의 스트리밍이 존재할 수 있습니다.

첫 번째는 사용자 경험을 위한 스트리밍입니다.
```
FastAPI
   │
   ├── "분석 시작"
   ├── "OCR 진행 중"
   ├── "필드 추출 중"
   └── "완료"
        │
        ▼
      Browser
```
이 구간에서는 SSE가 좋은 선택이 될 수 있습니다.
```
FastAPI ═════ SSE ═════> Browser
```
반면 Agent와 MCP Server 사이에서는 Tool 호출이라는 RPC적인 통신이 발생합니다.
```
Agent
  │
  │ tools/call
  ▼
MCP Server
  │
  │ Tool 실행
  ▼
Result
```
여기에서는 Streamable HTTP가 자연스럽습니다.
```
Agent ══ Streamable HTTP ══> MCP Server
```
즉 같은 시스템 안에서도 서로 다른 통신 방식이 사용될 수 있습니다.

16. SSE와 Streamable HTTP는 경쟁 관계가 아니다

이 시리즈에서 가장 강조하고 싶은 부분입니다.

처음에는 이렇게 생각하기 쉽습니다.
```
SSE vs Streamable HTTP
```
마치 Streamable HTTP가 SSE를 대체하기 위해 등장한 새로운 스트리밍 기술처럼 느껴집니다.

하지만 실제 시스템에서는 이렇게 보는 편이 더 정확합니다.
```
Web Application

Browser
   │
   │ SSE
   ▼
FastAPI


Agent System

Agent
   │
   │ Streamable HTTP
   ▼
MCP Server
```
두 기술은 서로 다른 구간에서 서로 다른 문제를 해결할 수 있습니다.

Browser와 FastAPI 사이에서는 사용자가 작업 진행 상황이나 LLM의 생성 결과를 실시간으로 받아야 할 수 있습니다.
```
Browser <════ SSE ════ FastAPI
```
이때 SSE는 매우 단순하고 효과적인 방법입니다.

반면 Agent와 MCP Server 사이에서는 단순한 이벤트 전달보다 Tool 호출, Request/Response, Notification, Session 같은 RPC적인 통신이 중요합니다.
```
Agent ──── tools/call ──────> MCP Server
Agent <──── result ────────── MCP Server
```
이런 구간에서는 Streamable HTTP가 더 자연스럽습니다.

따라서 둘의 관계를
```
SSE
 ↓
구식 기술

Streamable HTTP
 ↓
새로운 기술
```
처럼 이해해서는 안 됩니다.

오히려 다음과 같이 보는 편이 좋습니다.
```
SSE
│
└── Server → Client Streaming


Streamable HTTP
│
├── HTTP Request / Response
│
└── 필요할 경우 SSE Streaming
```
그리고 중요한 사실이 하나 있습니다.

Streamable HTTP 자체도 필요할 때 SSE를 사용합니다.

즉 SSE는 Streamable HTTP의 경쟁자가 아니라, Streamable HTTP가 스트리밍을 구현할 때 활용할 수 있는 메커니즘이기도 합니다.

17. 왜 MCP는 이런 구조가 필요했을까?

이제 다시 MCP의 목적을 생각해봅시다.

MCP Server는 단순한 스트리밍 서버가 아닙니다.

AI Agent에게 외부 기능을 제공하는 서버입니다.

예를 들어 다음과 같은 Tool이 있다고 해보겠습니다.
```
search_documents()

analyze_invoice()

send_email()

query_database()

generate_report()
```
Agent는 필요한 순간에 특정 Tool을 호출합니다.
```
Agent
  │
  │ tools/call
  ▼
MCP Server
  │
  ▼
Tool
```
대부분의 Tool 호출은 매우 자연스러운 Request/Response 구조를 가집니다.
```
Request

"이 Tool을 실행해줘"

        ↓

Tool 실행

        ↓

Response

"결과는 이것이야"
```
그런데 Tool의 특성은 모두 다릅니다.

어떤 Tool은 100ms 안에 끝날 수 있습니다.
```
get_current_time()

      ↓

   100ms

      ↓

   Result
```
어떤 Tool은 수십 초가 걸릴 수도 있습니다.
```
analyze_invoice()

      ↓

PDF Rendering

      ↓

VLM Analysis

      ↓

Field Extraction

      ↓

Validation

      ↓

Result
```
따라서 MCP Transport는 두 가지 상황을 모두 다룰 수 있어야 합니다.
```
짧은 작업
   │
   ▼
Request / Response


긴 작업
   │
   ▼
Request / Streaming / Response
```
Streamable HTTP는 바로 이런 특성에 잘 맞습니다.

18. WebSocket을 기본 Transport로 사용하지 않는 이유도 보인다

여기까지 이해하면 처음에 했던 질문으로 다시 돌아갈 수 있습니다.

그냥 WebSocket을 사용하면 더 간단하지 않을까?

WebSocket을 사용하면 물론 양방향 메시징을 구현할 수 있습니다.
```
MCP Client <══════════════> MCP Server
```
하지만 MCP의 대부분의 동작은 본질적으로 RPC에 가깝습니다.
```
tools/list

tools/call

resources/read

prompts/get
```
즉 기본 패턴은 다음과 같습니다.
```
Request
   │
   ▼
Server Processing
   │
   ▼
Response
```
모든 요청을 처리하기 위해 반드시 영구적인 Full-Duplex 연결을 유지해야 하는 것은 아닙니다.

HTTP가 이미 잘 처리하고 있는 문제를 굳이 다른 통신 모델로 바꿀 필요가 없는 것입니다.

또 실제 운영 환경을 생각하면 HTTP가 가진 장점도 큽니다.
```
Reverse Proxy

Load Balancer

Authentication

HTTP Header

HTTP Status

Observability

Rate Limiting

Existing Infrastructure
```
많은 인프라가 이미 HTTP를 중심으로 만들어져 있습니다.

Streamable HTTP는 이런 생태계를 그대로 활용할 수 있습니다.

19. 이름에 답이 있다

이제 다시 이름을 보겠습니다.
```
Streamable HTTP
```
처음에는 조금 애매하게 느껴졌던 이름이 이제는 꽤 정확하게 보입니다.

핵심은 이것입니다.

HTTP를 사용한다. 그리고 필요한 경우 Stream할 수 있다.

즉,
```
HTTP
 │
 ├── 일반 Response 가능
 │
 └── Streaming Response 가능
```
입니다.

항상 연결을 유지하는 것도 아니고,

항상 SSE를 사용하는 것도 아니며,

항상 Streaming하는 것도 아닙니다.

필요한 통신 방식에 따라 HTTP의 Response 형태를 선택할 수 있습니다.

그래서 Streaming HTTP가 아니라 Streamable HTTP입니다.

20. 세 기술을 한 문장으로 정리하면

이제 SSE, WebSocket, Streamable HTTP를 아주 단순하게 정리해보겠습니다.

SSE

서버가 클라이언트에게 지속적으로 데이터를 보내고 싶다.
```
Server ─────────────────> Client
```
LLM 답변, 작업 진행 상황, 알림 등에 잘 맞습니다.

WebSocket

클라이언트와 서버가 지속적으로 서로 메시지를 주고받고 싶다.
```
Server <════════════════> Client
```
채팅, 게임, 협업 시스템처럼 지속적인 Full-Duplex 통신에 잘 맞습니다.

Streamable HTTP

HTTP Request/Response를 기본으로 사용하면서 필요한 경우 스트리밍도 하고 싶다.
```
Client ───── Request ─────> Server
Client <──── Response ───── Server

          또는

Client ───── Request ─────> Server
Client <════ SSE Stream ═══ Server
```
RPC 기반의 MCP 통신에 잘 맞습니다.

21. 실제 시스템에서는 함께 사용한다

중요한 것은 하나의 기술을 선택해서 시스템 전체에 적용해야 하는 것이 아니라는 점입니다.

예를 들어 AI 기반 인보이스 분석 서비스를 만든다고 생각해보겠습니다.
```
┌──────────────┐
│   Browser    │
└──────┬───────┘
       │
       │ HTTP
       ▼
┌──────────────┐
│   FastAPI    │
└──────┬───────┘
       │
       │
       ▼
┌──────────────┐
│    Agent     │
└──────┬───────┘
       │
       │ MCP
       ▼
┌──────────────┐
│  MCP Server  │
└──────┬───────┘
       │
       ├── OCR Tool
       ├── Parser Tool
       └── Validation Tool
```
여기서 Browser와 FastAPI 사이에서는 사용자에게 진행 상황을 보여주고 싶을 수 있습니다.
```
Browser <════ SSE ════ FastAPI

"파일 업로드 완료"

"OCR 진행 중"

"데이터 추출 중"

"검증 중"

"완료"
```
반면 Agent와 MCP Server 사이에서는 Tool 호출이 이루어집니다.
```
Agent
  │
  │ tools/call
  ▼
MCP Server
  │
  ▼
OCR Tool
```
이 구간에서는 Streamable HTTP를 사용할 수 있습니다.
```
Browser
   │
   │ SSE
   ▼
FastAPI
   │
   ▼
Agent
   │
   │ Streamable HTTP
   ▼
MCP Server
```
이 그림을 보면 SSE와 Streamable HTTP를 왜 단순 비교해서는 안 되는지 명확해집니다.

사용되는 계층과 해결하는 문제가 다르기 때문입니다.

22. 결국 중요한 것은 Transport가 아니라 요구사항이다

개발하다 보면 새로운 기술이 등장할 때마다 이런 질문을 하게 됩니다.
```
SSE가 좋은가?

WebSocket이 좋은가?

Streamable HTTP가 좋은가?
```
하지만 사실 이 질문에는 정답이 없습니다.

먼저 물어야 하는 것은 이것입니다.
```
데이터는 어느 방향으로 흐르는가?

연결을 계속 유지해야 하는가?

Request / Response 관계가 중요한가?

서버가 임의의 시점에 메시지를 보내야 하는가?

스트리밍이 항상 필요한가?

세션 상태를 유지해야 하는가?

기존 HTTP 인프라를 활용해야 하는가?
```
이 요구사항이 정해진 뒤 Transport를 선택해야 합니다.

예를 들어 단순한 LLM 스트리밍이라면:
```
SSE
```
만으로 충분할 수 있습니다.

실시간 협업 시스템이라면:
```
WebSocket
```
이 자연스러울 수 있습니다.

Agent와 Tool Server 사이의 RPC 통신이라면:
```
Streamable HTTP
```
가 좋은 선택이 될 수 있습니다.

기술을 먼저 선택하고 시스템을 거기에 맞추는 것이 아니라,

통신의 특성을 먼저 이해하고 그에 맞는 기술을 선택하는 것이 중요합니다.

마치며

이번 시리즈는 아주 단순한 질문에서 시작했습니다.

HTTP는 Response를 한 번 보내는데 어떻게 데이터를 계속 전달할 수 있을까?

1부에서는 그 답으로 SSE를 살펴봤습니다.
```
HTTP Response
   │
   ├── data
   ├── data
   ├── data
   └── end
```
그리고 2부에서는 SSE만으로 모든 통신 문제를 해결할 수 없다는 것을 살펴봤습니다.

복잡한 AI 시스템에서는 단순한 스트리밍뿐 아니라 다음과 같은 메시지의 관계가 중요했습니다.
```
Request

Response

Notification

Streaming

Session
```
그리고 이번 3부에서는 MCP가 왜 Streamable HTTP라는 방식을 사용하는지 살펴봤습니다.

Streamable HTTP의 핵심은 의외로 단순합니다.

HTTP Request/Response를 기본으로 사용하고, 필요한 경우 스트리밍할 수 있도록 한다.

그래서 일반적인 요청은 평범한 HTTP Response로 끝날 수 있습니다.
```
Request
   │
   ▼
JSON Response
```
하지만 스트리밍이 필요하다면 SSE를 사용할 수도 있습니다.
```
Request
   │
   ▼
SSE Stream
   │
   ├── message
   ├── message
   ├── message
   └── end
```
즉 Streamable HTTP는 SSE를 버린 것이 아닙니다.

오히려 HTTP와 SSE를 필요한 상황에 맞게 활용할 수 있도록 Transport 구조를 정리한 것에 가깝습니다.

그리고 이 구조는 MCP처럼 다양한 Tool을 호출하는 AI Agent 시스템과 잘 맞습니다.
```
Browser
   │
   │ SSE
   ▼
FastAPI
   │
   ▼
Agent
   │
   │ Streamable HTTP
   ▼
MCP Server
   │
   ├── Tool
   ├── Tool
   └── Tool
```
결국 중요한 것은 어떤 기술이 더 최신인가가 아닙니다.

어떤 구간에서 어떤 종류의 통신이 필요한가를 이해하는 것입니다.

SSE, WebSocket, Streamable HTTP는 서로를 대체하기 위해 존재하는 기술이라기보다 각자 다른 통신 문제를 해결하기 위한 도구입니다.

이 차이를 이해하면 AI Agent와 MCP 기반 시스템을 설계할 때 Transport를 훨씬 명확하게 선택할 수 있습니다.

시리즈 정리

1부

HTTP 연결 하나로 데이터를 계속 보내는 SSE

HTTP Response와 Streaming의 기본 원리를 살펴봤습니다.

2부

SSE만으로는 부족한가? 양방향 통신과 RPC의 문제

SSE와 WebSocket의 차이, 그리고 MCP에서 Request/Response와 Notification이 왜 중요한지 살펴봤습니다.

3부

MCP는 왜 Streamable HTTP를 사용하는가

HTTP Request/Response와 SSE Streaming을 함께 활용하는 Streamable HTTP의 구조와 MCP에서 이 방식이 필요한 이유를 살펴봤습니다.
2026년 10월 05일
SSE와 Streamable HTTP 2부 — SSE만으로는 부족한가? 양방향 통신과 RPC의 문제
1부에서는 SSE(Server-Sent Events)가 어떻게 하나의 HTTP Response를 이용해 서버에서 클라이언트로 데이터를 계속 전달할 수 있는지 살펴봤습니다.

핵심은 단순했습니다.

HTTP Response는 반드시 한 번에 전달될 필요가 없다.

하나의 HTTP Response를 종료하지 않고 데이터를 조금씩 전달하면 서버는 클라이언트에게 지속적으로 이벤트를 보낼 수 있습니다.
```
Client                         Server
   │                              │
   │──── HTTP Request ───────────>│
   │                              │
   │<──── data: message 1 ────────│
   │<──── data: message 2 ────────│
   │<──── data: message 3 ────────│
   │<──── data: done ─────────────│
   │                              │
```
LLM의 답변 스트리밍이나 작업 진행 상태를 전달하는 용도라면 이 구조만으로도 상당히 많은 문제를 해결할 수 있습니다.

그런데 시스템이 조금 더 복잡해지면 질문이 하나 생깁니다.

서버만 계속 데이터를 보내면 충분할까?

이번 글에서는 이 질문에서 시작해보겠습니다.

1. SSE의 방향은 기본적으로 Server → Client다

SSE의 데이터 흐름은 기본적으로 단방향입니다.
```
Server ─────────────────────> Client
```
서버가 이벤트를 생성하고 클라이언트가 이를 받습니다.

예를 들어 LLM 서비스라면 이런 구조가 자연스럽습니다.
```
Client
   │
   │ POST /question
   ▼
Server
   │
   │ LLM 실행
   │
   ├──── token
   ├──── token
   ├──── token
   └──── done
         │
         ▼
       Client
```
질문은 일반적인 HTTP Request로 보내고, 생성되는 결과는 스트림으로 받습니다.

파일 분석 서비스도 비슷합니다.
```
Client
   │
   │ PDF Upload
   ▼
Server
   │
   ├── parsing...
   ├── OCR...
   ├── analyzing...
   ├── extracting...
   └── completed
         │
         ▼
       Client
```
이런 상황에서는 서버에서 클라이언트 방향의 데이터 흐름이 대부분이기 때문에 SSE가 매우 잘 맞습니다.

하지만 모든 시스템이 이렇게 단순하지는 않습니다.

2. 클라이언트도 계속 메시지를 보내야 한다면?

이번에는 채팅 시스템을 생각해봅시다.

사용자가 메시지를 보내고 서버가 응답합니다.

그런데 응답이 끝나기 전에 사용자가 작업을 취소할 수도 있습니다.
```
Client                         Server
   │                              │
   │──── question ───────────────>│
   │                              │
   │<──── token ──────────────────│
   │<──── token ──────────────────│
   │                              │
   │──── cancel ─────────────────>│
   │                              │
   │<──── cancelled ──────────────│
```
조금 더 복잡한 Agent 시스템에서는 이런 흐름도 생길 수 있습니다.
```
Client                         Agent
   │                              │
   │──── task ───────────────────>│
   │                              │
   │<──── processing ─────────────│
   │                              │
   │<──── approval_required ──────│
   │                              │
   │──── approve ────────────────>│
   │                              │
   │<──── processing ─────────────│
   │                              │
   │<──── completed ──────────────│
```
이제 통신 방향이 한쪽만이 아닙니다.
```
Client <────────────────────> Server
```
이쯤 되면 자연스럽게 떠오르는 기술이 있습니다.

WebSocket입니다.

3. 그러면 그냥 WebSocket을 쓰면 되지 않을까?

WebSocket은 클라이언트와 서버가 하나의 연결을 유지하면서 양방향으로 메시지를 주고받을 수 있도록 합니다.
```
Client                         Server
   │                              │
   │<═══════ WebSocket ═════════>│
   │                              │
   │──── message ────────────────>│
   │<──── message ────────────────│
   │──── message ────────────────>│
   │<──── message ────────────────│
```
SSE와 비교하면 차이가 분명합니다.
```
SSE

Server ─────────────────────> Client


WebSocket

Server <────────────────────> Client
```
실시간 채팅, 멀티플레이 게임, 공동 편집, 실시간 제어처럼 양쪽에서 지속적으로 메시지가 발생하는 시스템이라면 WebSocket은 매우 자연스러운 선택입니다.

그렇다면 여기서 이런 의문이 생깁니다.

MCP 같은 시스템도 Client와 Server가 계속 통신해야 하는데 그냥 WebSocket을 사용하면 되지 않을까?

기술적으로는 가능합니다.

하지만 여기에는 조금 다른 문제가 있습니다.

4. 모든 통신이 양방향 스트림일 필요는 없다

MCP Client가 MCP Server에게 Tool 목록을 요청한다고 생각해봅시다.
```
MCP Client                    MCP Server
    │                             │
    │──── tools/list ────────────>│
    │                             │
    │<──── tool list ─────────────│
    │                             │
```
이것은 전형적인 Request/Response입니다.

Tool을 호출하는 경우도 비슷합니다.
```
MCP Client                    MCP Server
    │                             │
    │──── tools/call ────────────>│
    │                             │
    │        Tool 실행            │
    │                             │
    │<──── result ────────────────│
```
이런 요청을 처리하기 위해 반드시 장시간 유지되는 완전한 양방향 메시징 채널이 필요한 것은 아닙니다.

HTTP가 이미 아주 잘하는 방식이 있습니다.
```
Request
   │
   ▼
Server
   │
   ▼
Response
```
그렇다면 기존 HTTP Request/Response 모델을 버릴 이유가 있을까요?

오히려 필요한 것은 이런 구조일 수 있습니다.
```
일반적인 요청

Client ─── Request ─────────> Server
Client <── Response ───────── Server


스트리밍이 필요한 요청

Client ─── Request ─────────> Server
Client <── event ──────────── Server
Client <── event ──────────── Server
Client <── event ──────────── Server
Client <── result ─────────── Server
```
즉,

평소에는 HTTP Request/Response를 사용하고, 필요할 때만 Response를 스트리밍할 수 있으면 어떨까?

여기서 중요한 관점의 변화가 시작됩니다.

5. MCP 통신은 단순한 채팅이 아니다

MCP Client와 Server 사이에서는 다양한 종류의 메시지가 오갈 수 있습니다.

예를 들어 다음과 같습니다.
```
initialize

tools/list

tools/call

resources/list

resources/read
```
그리고 모든 요청의 특성이 같지는 않습니다.

어떤 요청은 즉시 끝날 수 있습니다.
```
tools/list
    │
    ▼
200 OK
```
반면 어떤 Tool은 오래 걸릴 수 있습니다.
```
tools/call
    │
    ▼
PDF 분석
    │
    ▼
OCR
    │
    ▼
데이터 추출
    │
    ▼
검증
    │
    ▼
Result
```
또 경우에 따라 서버에서 클라이언트로 별도의 메시지를 전달해야 할 수도 있습니다.

즉 MCP 통신에는 다음과 같은 성격이 함께 존재합니다.
```
Request / Response

Notification

Streaming
```
이것이 단순한 SSE와 WebSocket의 선택 문제만으로 보기 어려운 이유입니다.

6. RPC 관점에서 생각해보자

여기서 RPC라는 개념을 잠깐 살펴볼 필요가 있습니다.

RPC는 Remote Procedure Call의 약자입니다.

이름 그대로 다른 프로세스나 다른 서버에 있는 기능을 마치 함수를 호출하듯 사용하는 개념입니다.

로컬 Python 함수라면 다음과 같이 호출할 수 있습니다.
```
result = analyze_invoice("invoice.pdf")
```
하지만 analyze_invoice()가 다른 서버에 있다면 직접 호출할 수 없습니다.

네트워크를 통해 요청해야 합니다.
```
Agent
  │
  │ analyze_invoice("invoice.pdf")
  ▼
Network
  │
  ▼
MCP Server
  │
  ▼
analyze_invoice()
```
논리적으로는 함수 호출처럼 보이지만 실제로는 네트워크 메시지가 오갑니다.
```
Client                           Server
   │                                │
   │──── method: analyze_invoice ──>│
   │                                │
   │            실행                │
   │                                │
   │<──── result ───────────────────│
```
MCP 역시 이런 RPC적인 성격을 가지고 있습니다.

Client가 Server에게 특정 기능의 실행을 요청하고 결과를 받습니다.

7. 요청과 응답을 어떻게 구분할까?

네트워크에서는 여러 요청이 동시에 발생할 수도 있습니다.
```
Client                         Server
   │                              │
   │──── Request A ──────────────>│
   │──── Request B ──────────────>│
   │──── Request C ──────────────>│
   │                              │
```
그런데 처리 시간이 모두 같다는 보장은 없습니다.
```
Request A ───────────────── Result A

Request B ─── Result B

Request C ───────── Result C
```
Request B가 A보다 늦게 들어왔지만 먼저 끝날 수도 있습니다.

그래서 RPC에서는 요청을 식별할 수 있는 ID가 중요합니다.

예를 들어 JSON-RPC에서는 개념적으로 다음과 같은 요청을 보낼 수 있습니다.
```
{
  "jsonrpc": "2.0",
  "id": 10,
  "method": "tools/call",
  "params": {
    "name": "analyze_invoice"
  }
}
```
서버의 응답에는 같은 ID가 포함됩니다.
```
{
  "jsonrpc": "2.0",
  "id": 10,
  "result": {
    "status": "completed"
  }
}
```
그러면 Client는 알 수 있습니다.
```
Request id=10
      │
      ▼
  MCP Server
      │
      ▼
Response id=10
```
즉,

이 Response는 내가 보냈던 id=10 요청의 결과구나.

이렇게 Request와 Response를 연결할 수 있습니다.

8. Notification은 조금 다르다

모든 메시지가 Response를 요구하는 것도 아닙니다.

상대방에게 어떤 사실을 알려주기만 하면 되는 메시지도 있습니다.
```
Client                         Server
   │                              │
   │<──── Notification ───────────│
   │                              │
```
Notification은 일반적인 RPC Request와 달리 응답을 요구하지 않습니다.

따라서 통신 구조는 점점 다양해집니다.
```
Request
   │
   └────────> Response


Notification
   │
   └────────> No Response


Long-running Request
   │
   ├────────> Progress
   ├────────> Progress
   ├────────> Progress
   └────────> Result
```
이제 단순히
```
Server → Client
```
또는
```
Server ↔ Client
```
만으로 설명하기에는 부족합니다.

9. 중요한 것은 방향만이 아니라 메시지의 성격이다

SSE와 WebSocket을 비교하다 보면 흔히 통신 방향에만 집중하게 됩니다.
```
SSE       : Server → Client

WebSocket : Server ↔ Client
```
물론 중요한 차이입니다.

하지만 MCP 같은 RPC 시스템에서는 또 다른 질문이 중요합니다.

이 메시지는 무엇을 의미하는가?

예를 들어 다음을 구분해야 합니다.
```
Request인가?

Response인가?

Notification인가?

중간 진행 상황인가?

최종 결과인가?
```
즉 통신 채널뿐만 아니라 메시지의 의미와 생명주기도 관리해야 합니다.

10. Agent 시스템에서는 더 복잡해진다

AI Agent를 생각하면 이 문제가 더욱 명확해집니다.

예를 들어 사용자가 인보이스 PDF를 업로드했다고 해봅시다.
```
User
 │
 │ invoice.pdf
 ▼
Agent
```
Agent는 MCP Tool을 호출합니다.
```
Agent
 │
 │ tools/call
 ▼
MCP Server
 │
 ▼
Invoice Tool
```
그런데 분석 과정에서는 여러 단계가 발생할 수 있습니다.
```
Invoice Tool
     │
     ▼
  Parsing
     │
     ▼
    OCR
     │
     ▼
Field Extraction
     │
     ▼
 Validation
     │
     ▼
   Result
```
어떤 작업은 100ms 만에 끝날 수도 있고, 어떤 작업은 20초가 걸릴 수도 있습니다.

심지어 중간에 사용자 확인이 필요할 수도 있습니다.
```
Agent
  │
  │ tools/call
  ▼
MCP Server
  │
  ├── OCR
  │
  ├── Extraction
  │
  └── Human Review Required
              │
              ▼
             User
              │
           Approve
              │
              ▼
           Continue
```
이런 시스템에서는 단순히 “연결 하나를 열어놓자”만으로 문제가 해결되지 않습니다.

요청과 응답의 관계, 상태, 이벤트, 스트리밍 등을 함께 고려해야 합니다.

11. 그렇다면 우리가 원하는 통신 방식은?

지금까지의 요구사항을 정리해보겠습니다.

우리는 기존 HTTP의 장점을 활용하고 싶습니다.
```
POST
GET
HTTP Status
Authentication
Proxy
Load Balancer
```
단순한 요청이라면 평범하게 처리하고 싶습니다.
```
Request
   │
   ▼
Response
```
하지만 필요한 경우에는 스트리밍도 하고 싶습니다.
```
Request
   │
   ▼
Response
   │
   ├── event
   ├── event
   ├── event
   └── result
```
그리고 서버에서 발생하는 Notification도 처리할 수 있어야 합니다.

결국 우리가 원하는 모습은 대략 이렇습니다.
```
             HTTP

Client ───── POST ───────────> Server
Client <──── JSON ──────────── Server


       필요할 때 Streaming

Client ───── Request ────────> Server
Client <──── Event ─────────── Server
Client <──── Event ─────────── Server
Client <──── Result ────────── Server
```
여기서 재미있는 질문이 하나 생깁니다.

HTTP Request/Response의 단순함은 유지하면서 필요할 때만 스트리밍할 수는 없을까?

바로 이 질문이 Streamable HTTP를 이해하는 출발점입니다.

12. Streaming HTTP가 아니라 Streamable HTTP

이름을 자세히 보면 재미있는 부분이 있습니다.

Streaming HTTP가 아니라 Streamable HTTP입니다.

이 차이가 꽤 중요합니다.

모든 통신을 항상 스트리밍한다는 의미가 아닙니다.

필요하다면 일반적인 HTTP Response를 사용할 수 있습니다.
```
Request
   │
   ▼
JSON Response
```
그리고 필요한 경우에는 스트리밍 Response를 사용할 수도 있습니다.
```
Request
   │
   ▼
Streaming Response
   │
   ├── event
   ├── event
   ├── event
   └── end
```
즉 핵심은 항상 Streaming이 아니라 Streamable, 다시 말해 필요하면 스트리밍할 수 있다는 것입니다.

그리고 이것이 다음 편에서 살펴볼 핵심 주제입니다.

마치며

1부에서는 SSE를 통해 이런 사실을 확인했습니다.

하나의 HTTP Response는 데이터를 조금씩 전달할 수 있다.

이번 2부에서는 여기서 한 단계 더 나아갔습니다.

SSE는 Server → Client 스트리밍에 매우 유용하지만, MCP 같은 RPC 시스템에서는 단순한 데이터 방향만으로는 충분하지 않습니다.

우리가 다뤄야 하는 것은 다음과 같은 것들입니다.
```
Request
Response
Notification
Streaming
Session
```
WebSocket처럼 완전한 양방향 채널을 만드는 것도 하나의 방법입니다.

하지만 모든 요청이 지속적인 양방향 통신을 필요로 하는 것은 아닙니다.

오히려 이런 질문을 해볼 수 있습니다.

HTTP의 단순한 Request/Response 구조는 그대로 사용하면서, 정말 필요한 순간에만 스트리밍할 수는 없을까?

이 질문에 대한 답이 Streamable HTTP입니다.

다음 3부에서는 드디어 Streamable HTTP의 구조를 본격적으로 살펴보겠습니다.

왜 MCP가 이 방식을 사용하게 되었는지, 일반 HTTP 요청과 SSE가 어떻게 하나의 Transport 안에서 공존하는지, 그리고 기존 SSE 기반 MCP Transport와 무엇이 달라졌는지를 구조적으로 살펴보겠습니다.

다음 편

SSE와 Streamable HTTP 3부 — MCP는 왜 Streamable HTTP를 사용하는가
2026년 10월 05일
SSE와 Streamable HTTP 1부 — HTTP 연결 하나로 데이터를 계속 보내는 SSE
LLM을 이용한 서비스를 개발하다 보면 자연스럽게 스트리밍(Streaming)이라는 말을 접하게 됩니다.

ChatGPT에 질문을 입력했을 때를 생각해봅시다. 답변 전체가 완성될 때까지 기다렸다가 한꺼번에 화면에 나타나는 것이 아니라, 생성되는 내용이 조금씩 화면에 나타납니다.
```
Redis
Redis Streams는
Redis Streams는 메시지를
Redis Streams는 메시지를 순서대로...
```
서버에서는 아직 답변을 만들고 있는데 클라이언트는 이미 그 일부를 받고 있습니다. 이것이 우리가 흔히 말하는 스트리밍 응답(Streaming Response)입니다.

그런데 여기서 한 가지 궁금증이 생깁니다.

HTTP는 요청(Request)을 보내면 응답(Response)을 한 번 받는 프로토콜 아닌가?

그렇다면 서버는 어떻게 하나의 HTTP 요청에 데이터를 여러 번 보내는 것처럼 동작할 수 있을까요? 이 질문을 이해하면 SSE(Server-Sent Events)의 동작 방식도 자연스럽게 이해할 수 있습니다.

1. 우리가 익숙한 HTTP 요청과 응답

일반적인 HTTP API는 다음과 같이 동작합니다.
```
Client                              Server
   │                                   │
   │──── POST /question ──────────────>│
   │                                   │
   │                                   │ 처리
   │                                   │ 처리
   │                                   │ 처리
   │                                   │
   │<──────── Response ────────────────│
   │                                   │
```
클라이언트가 요청을 보내면 서버가 작업을 수행합니다. 작업이 끝나면 서버는 결과를 응답으로 돌려줍니다.

예를 들어 FastAPI에서 다음과 같은 API가 있다고 해봅시다.
```
@app.post("/question")
async def question():
    result = await generate_answer()
    return {"answer": result}
```
generate_answer()가 10초 걸린다면 사용자는 10초 동안 아무것도 받지 못합니다.
```
0초    질문 전송
 │
 │      서버 처리 중...
 │
10초   전체 답변 수신
```
일반적인 REST API에서는 별문제가 아닙니다. 하지만 LLM처럼 처리 시간이 길면서 중간 결과를 사용자에게 보여줄 수 있는 서비스에서는 이야기가 달라집니다.

2. LLM은 이미 결과를 만들고 있다

LLM이 다음과 같은 답변을 생성한다고 해봅시다.
```
Redis Streams는 메시지를 순서대로 저장하고
여러 Consumer가 이를 처리할 수 있도록 제공하는
Redis의 메시징 기능입니다.
```
모델이 10초 동안 아무것도 하지 않다가 마지막 순간에 문장 전체를 갑자기 만들어내는 것은 아닙니다. 출력 토큰은 순차적으로 생성됩니다.
```
1초  → "Redis"
2초  → " Streams는"
3초  → " 메시지를"
4초  → " 순서대로"
...
```
그렇다면 서버는 전체 답변이 완성될 때까지 기다리지 않고, 생성되는 데이터를 클라이언트에게 바로 전달할 수 있습니다.
```
LLM
 │
 ├── Redis
 ├── Streams는
 ├── 메시지를
 └── 순서대로...
       │
       ▼
     Client
```
여기서 필요한 것이 HTTP Streaming입니다.

3. HTTP 응답은 반드시 한 번에 보내야 할까?

HTTP 요청 하나에는 HTTP 응답 하나가 대응합니다. 하지만 HTTP 응답 하나를 반드시 한 번에 전부 보내야 하는 것은 아닙니다.

일반적인 응답은 다음과 같습니다.
```
HTTP/1.1 200 OK
Content-Type: application/json

{"answer":"Redis Streams는 ..."}
```
반면 서버가 응답을 바로 종료하지 않고 데이터를 조금씩 전달할 수도 있습니다.
```
HTTP Response 시작
        │
        ├── 데이터 A
        ├── 데이터 B
        ├── 데이터 C
        ├── 데이터 D
        │
        └── Response 종료
```
중요한 점은 응답을 네 번 보낸 것이 아니라는 것입니다. HTTP Response는 여전히 하나입니다.
```
Request 1개
      │
      ▼
Response 1개
      ├── chunk
      ├── chunk
      ├── chunk
      └── chunk
```
단지 Response Body가 한꺼번에 전달되지 않고 점진적으로 전달되는 것입니다. 이 개념이 SSE를 이해하는 핵심입니다.

4. SSE(Server-Sent Events)

SSE는 서버에서 클라이언트 방향으로 이벤트를 전달하기 위한 방식입니다.
```
Server ────────────────> Client
```
서버는 HTTP 응답을 유지하면서 클라이언트에게 이벤트를 계속 전달합니다.
```
Client                              Server
   │                                   │
   │──── GET /events ─────────────────>│
   │                                   │
   │<──── data: hello ─────────────────│
   │<──── data: processing ────────────│
   │<──── data: result ────────────────│
   │<──── data: done ──────────────────│
   │                                   │
```
HTTP 요청이 계속 발생하는 것이 아닙니다. 처음 만들어진 HTTP 연결을 통해 하나의 Response가 계속 전달되고 있는 것입니다.

5. SSE의 text/event-stream

일반적인 JSON API는 다음과 같은 Content-Type을 사용합니다.
```
Content-Type: application/json
```
SSE에서는 다음을 사용합니다.
```
Content-Type: text/event-stream
```
실제 데이터는 대략 다음과 같은 형식으로 전달됩니다.
```
data: hello

data: processing

data: result

data: done
```
각 이벤트는 빈 줄로 구분됩니다. 이벤트 이름과 JSON 데이터도 사용할 수 있습니다.
```
event: progress
data: {"progress": 30}

event: progress
data: {"progress": 70}

event: complete
data: {"result": "finished"}
```
6. FastAPI에서는 어떻게 구현할까?

FastAPI에서는 StreamingResponse를 이용할 수 있습니다.
```
from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import asyncio

app = FastAPI()

async def event_generator():
    for i in range(5):
        yield f"data: message {i}\n\n"
        await asyncio.sleep(1)

@app.get("/stream")
async def stream():
    return StreamingResponse(
        event_generator(),
        media_type="text/event-stream"
    )
```
여기서 중요한 부분은 yield입니다. return은 값을 반환하고 함수를 종료하지만, yield는 값을 하나 내보낸 뒤 실행 상태를 유지합니다.
```
event_generator()
       │
       ├── yield message 0
       │      잠시 중단
       ├── yield message 1
       │      잠시 중단
       ├── yield message 2
       │      ...
       └── 종료
```
그래서 서버가 데이터를 생성하는 즉시 HTTP Response Body에 조금씩 전달하는 스트리밍 처리와 잘 어울립니다.

7. LLM과 SSE가 잘 어울리는 이유

개념적인 코드는 다음과 같습니다.
```
async def generate():
    async for token in llm.stream(prompt):
        yield f"data: {token}\n\n"
```
전체 데이터 흐름은 다음과 같습니다.
```
LLM
 │ token 생성
 ▼
Python Async Iterator
 │ yield
 ▼
StreamingResponse
 │
 ▼
HTTP
 │
 ▼
Browser
```
LLM이 데이터를 생성할 때마다 서버가 받아 클라이언트에게 바로 전달할 수 있습니다.

8. SSE가 정말 데이터를 여러 번 보내는 것일까?

겉으로는 서버가 메시지를 계속 보내는 것처럼 보입니다. 하지만 SSE는 기본적으로 하나의 HTTP Response를 이용합니다.
```
Client
   │
   │ HTTP Request
   ▼
Server
   │
   ▼
HTTP Response
┌───────────────────────────────┐
│ data: message 1               │
│                               │
│ data: message 2               │
│                               │
│ data: message 3               │
│                               │
│ data: message 4               │
└───────────────────────────────┘
```
새로운 Response가 계속 만들어지는 것이 아닙니다. 하나의 Response가 아직 끝나지 않은 것입니다.

9. SSE는 양방향 통신이 아니다

SSE 스트림 자체의 데이터 흐름은 기본적으로 서버에서 클라이언트 방향입니다.
```
Server ────────────────> Client
```
반면 WebSocket은 연결 이후 양쪽에서 메시지를 주고받을 수 있습니다.
```
Client <──────────────> Server
```
SSE를 사용하면서 클라이언트가 서버로 데이터를 보내야 한다면 별도의 HTTP 요청을 사용할 수 있습니다.
```
             HTTP POST
Client ──────────────────────> Server

                SSE
Client <────────────────────── Server
```
이 차이는 이후 WebSocket과 Streamable HTTP를 이해할 때 중요합니다.

10. SSE가 특히 잘 맞는 상황

SSE는 서버에서 발생하는 정보를 클라이언트가 지속적으로 받아야 하는 상황에 잘 맞습니다.
- LLM 답변 스트리밍
- Agent 작업 진행 상태
- 파일 분석 진행률
- 실시간 알림
- 로그 스트리밍
- 장시간 작업 상태 전달
예를 들어 AI 문서 분석 서비스에서는 다음과 같은 진행 상태를 전달할 수 있습니다.
```
사용자
  │ PDF 업로드
  ▼
Server
  │
  ├── 업로드 완료
  ├── OCR 시작
  ├── OCR 완료
  ├── 데이터 분석 중
  ├── 필드 추출 완료
  └── 분석 완료
        │
        ▼
      Browser
```
11. 그렇다면 WebSocket을 쓰면 되지 않을까?

WebSocket도 훌륭한 선택입니다. 특히 클라이언트와 서버가 지속적으로 양방향 메시지를 교환해야 한다면 WebSocket이 자연스러운 경우가 많습니다.

하지만 모든 스트리밍 문제에 양방향 연결이 필요한 것은 아닙니다. LLM 답변처럼 대부분의 데이터가 서버에서 클라이언트 방향으로 흐른다면 HTTP 기반의 SSE만으로도 충분할 수 있습니다.

12. 그런데 문제가 하나 있다

AI Agent가 MCP Server와 통신한다고 생각해봅시다.
```
Agent
  │
  ├── initialize
  ├── tools/list
  ├── tools/call
  └── tools/call
        │
        ▼
    MCP Server
```
여기서는 단순한 Server → Client 스트리밍을 넘어 요청, 응답, 알림, 스트리밍, 세션 같은 통신 요구사항을 함께 생각해야 합니다.
```
Request
Response
Notification
Streaming
Session
```
그리고 여기서 Streamable HTTP 이야기가 시작됩니다.

마치며

SSE를 이해할 때 가장 중요한 것은 data: 문법이나 FastAPI의 StreamingResponse 사용법이 아닙니다.

HTTP Response는 반드시 한 번에 전달될 필요가 없다.

HTTP 요청 하나에 응답 하나가 대응한다는 기본 구조는 그대로 유지됩니다. 다만 그 하나의 Response를 바로 끝내지 않고 데이터를 조금씩 전달할 수 있습니다.
```
Request
   │
   ▼
Response
   │
   ├── data
   ├── data
   ├── data
   ├── data
   └── end
```
SSE는 이 특성을 이용해 서버에서 클라이언트로 이벤트를 지속적으로 전달합니다. 그래서 LLM 스트리밍, 작업 진행 상태, Agent 실행 로그처럼 서버에서 계속 발생하는 데이터를 사용자에게 전달해야 하는 상황에서 유용합니다.

다음 편에서는 SSE만으로는 무엇이 부족한지, WebSocket과는 어떤 차이가 있는지, 그리고 왜 MCP의 통신 구조를 이해하려면 단순한 Server → Client 스트리밍을 넘어 생각해야 하는지 살펴보겠습니다.

다음 편

SSE와 Streamable HTTP 2부 — SSE만으로는 부족한가? 양방향 통신과 RPC의 문제
2026년 10월 05일

[태그:] SSE & Streamable HTTP

SSE와 Streamable HTTP 4부 — FastAPI + AI Agent + MCP에서 SSE와 Streamable HTTP는 어디에 써야 할까?

1. 우리가 만들 시스템

2. 전체 아키텍처부터 그려보자

3. Browser → FastAPI는 일반 HTTP로 시작한다

4. 그런데 분석에 20초가 걸린다면?

5. 이 구간에서 SSE가 유용하다

6. FastAPI에서 SSE Endpoint 만들기

7. 여기서 중요한 설계 포인트

8. 이제 Agent가 등장한다

9. Agent → MCP Server에서는 통신의 성격이 달라진다

10. Streamable HTTP로 Tool 호출하기

11. 오래 걸리는 Tool이라면?

12. 이제 두 종류의 Streaming이 보인다

13. 전체 데이터 흐름을 다시 그려보자

14. Redis는 왜 중간에 넣을까?

15. Redis Streams와 Pub/Sub 중 무엇을 쓸까?

16. 최종 결과는 어떻게 Browser까지 전달할까?

17. 그런데 최종 결과까지 SSE로 보내야 할까?

18. SSE 연결이 끊어지면 작업도 중단될까?

19. 그렇다면 사용자가 작업을 취소하면?

20. Human-in-the-Loop가 들어가면 더 재미있어진다

21. Agent와 MCP 사이에서도 HITL이 가능하다

22. 실패 처리도 생각해야 한다

23. Event를 계층별로 나누자

Infrastructure Event

Agent Event

User Event

24. SSE Event Schema도 미리 정의하는 것이 좋다

25. Task 상태도 명확하게 정의하자

26. 연결이 끊겨도 복구할 수 있는 구조

27. 전체 아키텍처를 완성해보자

28. 요청부터 완료까지 전체 흐름

Step 1. 사용자가 분석을 요청한다

Step 2. Browser가 진행 상황을 구독한다

Step 3. Worker가 작업을 시작한다

Step 4. Agent가 필요한 Tool을 결정한다

Step 5. Agent가 MCP Tool을 호출한다

Step 6. 작업 진행 상황을 사용자에게 전달한다

Step 7. 데이터 추출이 완료된다

Step 8. 결과를 저장한다

Step 9. 완료 이벤트를 전달한다

Step 10. Browser가 최종 결과를 가져온다

29. 왜 모든 것을 SSE로 만들지 않을까?

30. 왜 모든 것을 WebSocket으로 만들지 않을까?

31. 왜 Browser가 MCP Server를 직접 호출하지 않을까?

32. FastAPI와 FastMCP의 역할도 명확해진다

33. 결국 Transport는 계층별로 선택한다

34. 선택 기준을 아주 단순하게 정리하면

일반 HTTP

SSE

WebSocket

Streamable HTTP

Redis Streams / PubSub

35. 가장 중요한 설계 원칙

마치며

1부

2부

3부

SSE와 Streamable HTTP 3부 — MCP는 왜 Streamable HTTP를 사용하는가

1. 먼저 이름부터 살펴보자

2. 가장 단순한 경우부터 생각해보자

3. 그런데 모든 Tool이 빨리 끝나는 것은 아니다

4. Streamable HTTP의 핵심 구조

5. 여기서 SSE가 사라진 것이 아니다

6. 기존 SSE Transport는 어떻게 동작했을까?

7. Streamable HTTP에서는 구조가 단순해진다

8. 그런데 GET은 왜 필요할까?

9. 하나의 Endpoint가 중요한 이유

10. HTTP 인프라를 그대로 활용할 수 있다

11. Stateless하게 사용할 수도 있다

12. Session이 필요한 경우도 있다

13. 그래서 Streamable HTTP는 양방향인가?

14. 세 가지를 다시 비교해보자

SSE

WebSocket

Streamable HTTP

15. 실제 AI 서비스에서는 어떻게 사용할까?

16. SSE와 Streamable HTTP는 경쟁 관계가 아니다

17. 왜 MCP는 이런 구조가 필요했을까?

5. SSE의 `text/event-stream`