서버는 토큰을 조금씩 보내는데 브라우저에는 한꺼번에 표시됩니다. 스트리밍 지연은 어디에서 생기나요?

애플리케이션이 write했다고 모든 계층이 즉시 클라이언트에 전달하는 것은 아닙니다. 프레임워크·압축·프록시·CDN·브라우저의 버퍼링을 구간별로 확인해야 합니다.

동작 원리와 전제

생성 시각, 서버 flush, 프록시 수신·전달, 브라우저 read 시각을 비교합니다. 작은 데이터가 압축 버퍼나 최소 청크 정책에 쌓일 수 있습니다. proxy buffering 설정을 바꾸기 전에 실제 경로와 버전의 동작을 확인합니다.

선택과 실패 처리

스트림에 heartbeat를 넣을 수 있지만 불필요한 트래픽과 idle timeout 계약을 고려합니다. 클라이언트 취소가 원본 생성·DB 작업을 중단하는지도 별도입니다. 중간 오류는 이미 200 헤더를 보낸 뒤 상태 코드로 바꾸기 어려우므로 스트림 이벤트의 오류·종료 상태를 정의합니다.

구체적인 사례와 검증

LLM 응답을 proxy 없이 직접 요청하면 토큰이 바로 보이는데 CDN 경로에서는 묶여 나온다면 생성 모델보다 중간 전달 계층을 먼저 조사합니다. 압축을 끄거나 버퍼링 옵션을 조정하는 실험은 같은 payload와 연결 조건에서 비교합니다. 클라이언트의 화면 갱신 코드가 모든 본문을 await한 뒤 렌더링하는 경우도 있으므로 네트워크 chunk 수신과 DOM 반영을 나눠 봅니다. 이미 시작된 스트림이 실패하면 partial 결과를 성공 답변처럼 저장하지 않습니다. 오류 이벤트와 최종 완료 표식, 재개 가능한 작업 ID를 두면 사용자가 실제 완료 상태를 확인할 수 있습니다.

큰·작은 청크, 느린 소비자, 프록시 timeout, 연결 종료를 시험합니다. 첫 바이트 시간·청크 간격·최종 완료를 나눠 봅니다. 스트리밍은 체감 응답을 개선할 수 있어도 전체 작업을 더 빨리 끝내거나 결과의 완전성을 자동 보장하지 않습니다.