1장: 스트리밍 아키텍처의 필요성과 핵심 개념

학습 목표

• 요청-응답 모델과 스트리밍 모델의 근본적 차이를 이해합니다
• AI 시대에 스트리밍이 필수가 된 배경을 파악합니다
• 세 가지 스트리밍 패러다임(이벤트 스트림, 메시지 큐, 토큰 스트리밍)을 구분합니다
• TTFT와 TPOT 등 지연시간 구성요소를 학습합니다
• 프로토콜 생태계의 전체 지도를 조망합니다

요청-응답의 한계

전통적인 웹 아키텍처는 Request-Response(요청-응답) 패턴 위에 세워졌습니다. 클라이언트가 요청을 보내면, 서버는 모든 처리를 완료한 뒤 한 번에 응답을 돌려줍니다. 이 패턴은 단순하고 이해하기 쉬우며, HTTP/1.1 시절부터 웹의 근간이 되어 왔습니다.

그러나 LLM(Large Language Model, 대규모 언어 모델) 시대에 이 패턴은 치명적인 문제를 드러냅니다.

[요청-응답]
사용자 요청 ──────────────────────────────────> 전체 응답 (8초 후)
                   (빈 화면에서 대기)
 
[스트리밍]
사용자 요청 ─> 첫 토큰(0.3초) ─> ─> ─> ─> ─> 마지막 토큰 (8초)
               (즉시 텍스트가 나타남)

GPT-4 클래스 모델의 긴 응답은 완성까지 10초 이상 걸릴 수 있습니다. 요청-응답 방식이라면 사용자는 그 시간 동안 빈 화면만 바라보게 됩니다. 반면 스트리밍 방식에서는 첫 번째 토큰이 수백 밀리초 안에 도착하면서, 사용자는 AI가 "생각하고 있다"는 것을 즉시 확인할 수 있습니다.

AI 시대, 스트리밍이 필수인 이유

2026년 현재, 실시간 AI 시스템은 더 이상 선택이 아닙니다. 다음 세 가지 변화가 스트리밍을 필수 인프라로 만들었습니다.

1. 모델 크기와 추론 시간의 증가

모델 파라미터가 커질수록 토큰 하나를 생성하는 데 걸리는 시간도 늘어납니다. 사용자 경험을 유지하려면 토큰이 생성되는 즉시 전달해야 합니다.

2. 멀티모달 실시간 처리

텍스트를 넘어 오디오, 비디오, 이미지를 실시간으로 처리하는 AI 애플리케이션이 보편화되었습니다. 음성 대화 에이전트는 사용자의 발화가 끝나기 전에 이미 이해를 시작해야 하며, 이는 스트리밍 입력과 스트리밍 출력 양쪽 모두를 요구합니다.

3. 에이전트 워크플로우

단순한 질의응답을 넘어, AI 에이전트가 도구를 호출하고 여러 단계를 거쳐 작업을 수행하는 패턴이 확산되었습니다. 사용자에게 각 단계의 진행 상황을 실시간으로 보여주는 것은 투명성과 신뢰의 문제입니다.

세 가지 스트리밍 패러다임

스트리밍은 하나의 개념이 아닙니다. 용도에 따라 크게 세 가지 패러다임으로 나뉩니다.

이벤트 스트림 (Event Stream)

서버에서 클라이언트로 이벤트를 연속적으로 보내는 패턴입니다. **SSE(Server-Sent Events)**가 대표적이며, HTTP 위에서 동작하므로 기존 인프라와의 호환성이 뛰어납니다. LLM 토큰 스트리밍의 사실상 표준입니다.

// 서버가 클라이언트에게 이벤트를 연속으로 전달
// 클라이언트는 수신만 함 (단방향)
const eventSource = new EventSource("/api/stream");
eventSource.onmessage = (event) => {
  console.log("새 토큰:", event.data);
};

메시지 큐 (Message Queue)

Kafka, RabbitMQ 같은 메시지 브로커를 통해 생산자와 소비자를 분리하는 패턴입니다. 대규모 데이터 파이프라인과 마이크로서비스 간 통신에 적합합니다. AI 추론 요청을 큐에 넣고 여러 GPU 서버가 소비하는 구조에서 핵심 역할을 합니다.

토큰 스트리밍 (Token Streaming)

LLM에 특화된 패러다임으로, 모델이 토큰을 하나씩 생성할 때마다 즉시 전달합니다. 위의 이벤트 스트림이나 WebSocket을 전송 계층으로 사용하되, 토큰 단위의 점진적 렌더링, 부분 JSON 파싱 등 고유한 처리 로직이 필요합니다.

지연시간의 해부: TTFT와 TPOT

스트리밍 시스템의 성능을 논할 때, 두 가지 핵심 지표를 반드시 이해해야 합니다.

TTFT (Time To First Token)

**TTFT(Time To First Token, 첫 토큰 도달 시간)**는 사용자가 요청을 보낸 시점부터 첫 번째 토큰이 화면에 표시되기까지의 시간입니다. 이 지표는 체감 응답성을 좌우합니다.

TTFT를 구성하는 요소는 다음과 같습니다.

TPOT (Time Per Output Token)

**TPOT(Time Per Output Token, 토큰당 출력 시간)**는 첫 토큰 이후 각 토큰이 생성되는 간격입니다. 이 값이 작을수록 텍스트가 더 빠르게 화면을 채워갑니다.

총 응답 시간 = TTFT + (출력 토큰 수 x TPOT)
 
예시: TTFT 300ms, TPOT 30ms, 200 토큰 응답
= 300 + (200 x 30) = 6,300ms = 6.3초
 
스트리밍에서 사용자가 느끼는 지연 = TTFT = 0.3초
요청-응답에서 사용자가 느끼는 지연 = 6.3초

프로토콜 생태계 지도

스트리밍을 구현하는 데 사용할 수 있는 프로토콜은 여러 가지가 있습니다. 각각의 특성과 적합한 용도를 한눈에 살펴보겠습니다.

프로토콜 선택 가이드

실무에서 프로토콜을 선택할 때는 다음 질문에 답해보면 됩니다.

1. 클라이언트가 서버에게도 실시간으로 데이터를 보내야 하는가? 아니라면 SSE가 가장 단순한 선택입니다.
2. 양방향 통신이 필요한가? 채팅에서 사용자가 생성 중단을 요청하거나 실시간 협업이 필요하다면 WebSocket을 고려합니다.
3. 백엔드 서비스 간 통신인가? 브라우저가 관여하지 않는다면 gRPC가 성능과 타입 안전성 면에서 최적입니다.
4. 하나의 정답은 없다. 프로덕션 시스템은 대부분 하이브리드 접근을 취합니다. 예를 들어, LLM 출력은 SSE로, 백엔드 추론 파이프라인은 gRPC로, 협업 기능은 WebSocket으로 구성하는 식입니다.

이 시리즈에서 다룰 내용

이 시리즈는 10장에 걸쳐 스트리밍 아키텍처의 이론부터 실전 구현까지를 체계적으로 다룹니다.

• 2-4장: 핵심 프로토콜 심층 분석 (SSE, WebSocket, gRPC)
• 5-6장: LLM 스트리밍 응답 처리와 추론 파이프라인 설계
• 7-8장: 이벤트 소싱, 백프레셔 등 아키텍처 패턴
• 9장: 프로덕션 인프라 구성
• 10장: 실전 프로젝트 — 하이브리드 스트리밍 AI 시스템 구축

정리

이번 장에서는 스트리밍 아키텍처가 AI 시대에 왜 필수인지, 그리고 그 핵심 개념들을 살펴보았습니다.

• 요청-응답 모델은 LLM의 긴 추론 시간에서 치명적인 UX 문제를 일으킵니다
• 스트리밍은 전체 처리 시간이 아닌 체감 지연시간을 줄이는 전략입니다
• TTFT와 TPOT는 스트리밍 성능을 측정하는 핵심 지표입니다
• 프로토콜마다 강점이 다르며, 프로덕션에서는 하이브리드 접근이 일반적입니다

다음 장에서는 LLM 토큰 스트리밍의 사실상 표준인 **SSE(Server-Sent Events)**를 심층적으로 분석합니다. HTTP 위에서 동작하는 단순함이 어떻게 강력한 이점이 되는지, 그리고 Next.js와 FastAPI에서의 실제 구현 방법을 살펴보겠습니다.