LLM 스트리밍 애플리케이션: SSE·웹소켓·HTTP 비교와 구현법

핵심 메시지

• LLM은 전체 답변을 만드는 데 수 초가 걸리므로, 생성되는 대로 토큰을 흘려보내는 스트리밍이 좋은 사용자 경험의 핵심이다.
• ChatGPT나 Claude에서 텍스트가 한 토큰씩 나타나는 것이 바로 스트리밍이다.
• 일반 HTTP 요청은 응답 하나를 받으면 연결이 닫혀 스트리밍에 부적합하고, 웹소켓은 양방향 대화에 맞아 LLM 응답에는 과하다.
• 서버 전송 이벤트(SSE)는 하나의 HTTP 요청에 여러 업데이트를 보내고 끝에 연결을 닫아 LLM 스트리밍에 가장 적합하다.
• 서버는 FastAPI의 StreamingResponse로 청크를 yield 하고, 클라이언트는 자바스크립트 EventSource API로 업데이트를 받는다.

쉽게 이해하기

대규모 언어 모델(LLM)은 다른 머신러닝 모델과 결정적으로 다른 점이 있다. 전체 답변을 반환하기까지 수 초가 걸린다는 것이다. 아마존 프라임 배송 몇 시간도 못 기다리는 사용자가 로딩 스피너만 바라보며 LLM 응답을 기다릴 리 없다. 그래서 답변이 생성되는 즉시 조금씩 흘려보내는 '스트리밍'이 필요하다.

우리가 ChatGPT나 Claude를 쓸 때 텍스트가 한 토큰씩 화면에 나타나는 것이 바로 스트리밍이다. 사용자가 '잘 지내?'라고 물으면 요청이 서버의 LLM으로 전달되고, 'I am good' 같은 토큰이 순차적으로 브라우저에 도착한다. 전체 시퀀스를 다 디코딩한 뒤 한꺼번에 보내면 대기 시간이 길어 사용자 경험이 크게 나빠지기 때문이다.

영상은 스트리밍 구현의 세 가지 방식을 비교한다. 첫째, 가장 흔한 일반 HTTP 요청은 요청 하나에 응답 하나를 받고 연결이 닫히므로 스트리밍에 적합하지 않다(롱 폴링으로 흉내 낼 수는 있으나 최선이 아니다). 둘째, 웹소켓은 HTTP 요청이 업그레이드되어 만들어지는 양방향 터널로, 두 사용자가 서로 대화하는 것처럼 메시지를 아무 때나 주고받는 상호작용에 적합하다. 그러나 LLM은 보통 요청 하나에 응답 하나를 흘려보내는 구조라 웹소켓은 과하다.

그래서 LLM 스트리밍에 가장 적합한 방식이 서버 전송 이벤트(SSE)다. HTTP 요청을 보내되 단일 응답 대신 그 요청에 대한 여러 번의 업데이트를 받고, LLM이 시퀀스 종료 신호를 보내면 연결을 닫는다. 기존 HTTP 요청을 SSE로 업그레이드할 수 있어 스트리밍 앱 구축에 좋은 선택지가 된다.

구현 측면에서 서버는 FastAPI의 StreamingResponse 모듈을 쓴다. 응답 청크를 생성할 때마다 yield 하는 비동기 함수를 StreamingResponse에 넘기면 SSE 형태로 HTTP 요청에 여러 업데이트가 전달된다. 클라이언트에서는 자바스크립트 EventSource API를 등록해 초기 HTTP 응답의 업데이트를 기다리며 받는다. EventSource는 대부분의 브라우저가 지원한다.

주요 인사이트

• 스트리밍의 본질은 기술이 아니라 사용자 경험이다. 같은 답변이라도 통째로 늦게 주느냐, 토큰을 즉시 흘려보내느냐가 체감 품질을 가른다.
• 전송 방식 선택은 통신 패턴에 달렸다. HTTP는 단발 요청-응답, 웹소켓은 양방향 상호작용, SSE는 한 요청에 대한 다중 서버 업데이트에 맞는다. LLM 응답은 마지막 패턴이다.
• SSE는 기존 HTTP 인프라를 그대로 업그레이드해 쓸 수 있어, 웹소켓 같은 별도 터널을 새로 깔지 않고도 스트리밍을 도입할 수 있다.
• 서버(yield 하는 StreamingResponse)와 클라이언트(EventSource) 양쪽이 짝을 이뤄야 스트리밍이 완성된다. 한쪽만 준비해서는 동작하지 않는다.

자주 묻는 질문

관련 AI 소식