TestForge Blog
← 전체 포스트
#ai #agent #streaming #sse #websocket

AI Agent 스트리밍 응답 설계 - SSE와 WebSocket 중 무엇을 선택할까

AI Agent는 최종 답변만 빠른 것이 아니라 처리 중 상태를 어떻게 보여주느냐가 중요합니다. 이 글에서는 토큰 스트리밍, 단계 상태 표시, 툴 실행 이벤트, 중간 결과 전송을 기준으로 SSE와 WebSocket을 비교하고 실무적인 선택 기준을 정리합니다.

TestForge Team ·

왜 스트리밍이 중요한가

AI Agent 서비스에서 사용자가 가장 민감하게 느끼는 것은 “언제 답이 나오느냐”보다 “지금 뭔가 진행 중인지”입니다.

Agent는 보통 아래 흐름을 거칩니다.

  • 질문 해석
  • 문서 검색
  • 외부 툴 호출
  • 중간 결과 조합
  • 최종 답변 생성

이 과정을 모두 끝낸 뒤 한 번에 답을 주면 체감 속도가 크게 나빠집니다.

스트리밍 설계에서 먼저 나눠야 할 이벤트

실무에서는 스트리밍할 데이터를 분리해서 생각해야 합니다.

1. 텍스트 토큰 스트리밍

  • LLM이 생성 중인 답변 조각

2. 상태 이벤트

  • retrieving
  • running_tool
  • summarizing
  • completed

3. 구조화된 중간 결과

  • 검색된 문서 목록
  • 계산 결과
  • 차트 데이터
  • 경고 메시지

즉, Agent 스트리밍은 단순한 “문자 찍기”가 아니라 이벤트 스트림 설계에 가깝습니다.

SSE가 잘 맞는 경우

SSE는 서버에서 클라이언트로 단방향 이벤트를 보내는 구조입니다.

장점:

  • 구현이 단순함
  • HTTP 기반이라 인프라 호환성이 좋음
  • 토큰 스트리밍에 매우 적합
  • 브라우저 클라이언트 구현이 쉬움

AI Agent에서 SSE가 잘 맞는 케이스:

  • 답변 토큰 스트리밍
  • 단계 상태 업데이트
  • 검색 문서 목록 순차 표시
  • 단일 사용자 세션 응답

예를 들면 아래처럼 이벤트를 설계할 수 있습니다.

event: status
data: {"step":"retrieving"}

event: citation
data: {"title":"10-Q Filing","source":"sec"}

event: token
data: {"text":"엔비디아는 "}

event: token
data: {"text":"최근 90일 기준 "}

event: done
data: {"latency_ms":8420}

WebSocket이 필요한 경우

WebSocket은 양방향 통신이 가능하므로 더 복잡한 상호작용에 적합합니다.

장점:

  • 클라이언트와 서버가 계속 메시지를 주고받을 수 있음
  • 장시간 세션 관리에 유리
  • 협업형 UI나 다중 이벤트 제어에 적합

필요한 경우:

  • 사용자가 실행 중 작업을 중단
  • 툴 호출 중 추가 파라미터를 요청
  • 협업형 에이전트 워크스페이스
  • 브라우저와 서버 간 지속적인 상태 동기화

하지만 단순한 Q&A Agent라면 WebSocket이 과한 경우가 많습니다.

선택 기준은 “복잡도 대비 가치”다

실무에서는 아래 기준으로 정리하면 됩니다.

SSE를 우선 선택할 때

  • 질문 1회에 응답 1회 흐름이 명확함
  • 서버에서 클라이언트로만 이벤트를 보내면 충분함
  • 빠르게 MVP를 만들고 싶음
  • 프록시/로드밸런서 환경을 단순하게 유지하고 싶음

WebSocket을 선택할 때

  • 양방향 상호작용이 꼭 필요함
  • 실행 중 제어 이벤트가 많음
  • 세션이 길고 상태 동기화가 자주 필요함
  • 단순 챗봇이 아니라 실시간 협업형 UI에 가까움

대부분의 AI Agent 제품은 SSE로 시작하고, 필요할 때만 WebSocket으로 확장하는 편이 더 현실적입니다.

백엔드 이벤트 모델은 어떻게 나누는가

Agent 실행 엔진은 내부적으로 여러 이벤트를 발행하고, 프론트엔드는 그 일부만 받아야 합니다.

추천 이벤트 타입:

  • status
  • token
  • artifact
  • citation
  • warning
  • error
  • done

이렇게 타입을 분리하면 UI에서 렌더링이 쉬워집니다.

예를 들어:

  • status는 상단 진행 상태 바
  • token은 답변 본문
  • artifact는 우측 패널 카드
  • citation은 출처 목록
  • warning은 주의 문구

툴 호출이 있는 Agent는 스트리밍 UX가 더 중요하다

RAG나 계산형 Agent는 아래처럼 시간이 분산됩니다.

  • 검색 2초
  • 외부 API 3초
  • 모델 생성 5초

전체 응답 시간이 10초라면, 사용자에게는 “기다림”이 아니라 “검색 중 → 분석 중 → 응답 생성 중”이라는 흐름으로 보여줘야 합니다.

좋은 UI 예시:

  • 상단: 진행 단계 표시
  • 중앙: 생성 중 답변 스트리밍
  • 우측: 검색된 근거 문서와 툴 결과 갱신

취소와 타임아웃도 같이 설계해야 한다

스트리밍만 설계하고 취소를 빼먹으면 운영에서 불편해집니다.

필요한 것:

  • 사용자가 요청 취소 가능
  • 서버는 취소 시 툴 실행 중단 시도
  • 타임아웃 시 부분 결과 또는 안내 메시지 반환
  • 장시간 실행은 백그라운드 작업 전환 고려

특히 WebSocket이 아니더라도, SSE 세션 종료 감지와 서버 작업 취소는 꼭 넣는 편이 좋습니다.

프론트엔드 구현 시 자주 놓치는 포인트

  • 토큰 스트리밍과 구조화 이벤트를 한 상태에 섞어버림
  • done 이벤트 없이 종료를 연결 끊김에만 의존
  • 재연결 시 중복 출력 발생
  • 긴 응답에서 자동 스크롤 UX가 불안정함
  • 인용 문서와 답변 본문 동기화가 안 됨

그래서 프론트엔드에서는 stream state, message state, artifact state를 분리하는 편이 좋습니다.

추천 구현 조합

초반 MVP

  • 프론트: Next.js
  • 백엔드: FastAPI
  • 스트리밍: SSE
  • 이벤트 종류: status, token, citation, done

확장 단계

  • 툴 실행 이력 추가
  • 취소 처리
  • 재시도 처리
  • 세션 저장

고급 단계

  • 장시간 실행 작업 큐
  • WebSocket 기반 양방향 제어
  • 협업형 세션

마무리

AI Agent에서 스트리밍은 보기 좋은 효과가 아니라 사용자 신뢰를 만드는 기본 기능입니다.

정리하면:

  • 대부분의 Agent는 SSE로 시작해도 충분합니다.
  • WebSocket은 양방향 상호작용이 꼭 필요할 때 선택합니다.
  • 토큰뿐 아니라 상태, 근거, 툴 결과도 이벤트로 설계해야 합니다.
  • 스트리밍 UX는 속도보다도 “진행 중임을 보여주는 능력”에 가깝습니다.

좋은 Agent는 답변을 빨리 내놓는 것뿐 아니라, 그 답이 만들어지는 과정을 사용자에게 이해 가능하게 보여줍니다.