스트리밍 UI의 실패 복구 패턴

스트리밍 UI는 사용자가 기다리는 시간을 짧게 느끼게 해줍니다. 서버 렌더링 결과를 조각으로 보내거나, AI 응답을 토큰 단위로 보여주거나, 대시보드 데이터를 단계적으로 채우는 방식이 모두 여기에 속합니다. 하지만 스트리밍은 한 번에 성공하거나 실패하는 화면보다 복구 설계가 더 까다롭습니다.

실패 지점을 화면 단위로 나눈다

전통적인 페이지는 로딩, 성공, 실패의 세 상태로 충분해 보입니다. 스트리밍 UI는 그렇지 않습니다. 헤더는 이미 렌더링됐고, 요약은 도착했으며, 상세 표는 실패했고, 추천 액션은 아직 생성 중일 수 있습니다. 따라서 상태를 페이지 하나에 몰아넣지 말고 영역별로 나누어야 합니다.

사용자가 이미 본 정보를 유지한 채 실패한 조각만 다시 시도할 수 있으면 경험은 훨씬 안정적으로 느껴집니다.

중간 결과를 버리지 않는다

AI 응답이나 리포트 생성 화면에서 네트워크가 끊겼다고 이미 도착한 내용을 모두 지우면 사용자는 작업이 사라졌다고 느낍니다. 좋은 패턴은 중간 결과를 고정하고, 실패한 지점에 이어받기 또는 재생성 액션을 제공하는 것입니다.

이때 화면에는 다음 정보가 필요합니다.

• 마지막으로 성공한 시각
• 아직 완료되지 않은 영역
• 다시 시도할 수 있는 범위
• 사용자가 저장하거나 복사할 수 있는 중간 결과

중간 결과는 임시 상태가 아니라 사용자에게 이미 전달된 가치입니다.

재시도는 조용하지만 명확해야 한다

스트리밍 중 작은 패킷 손실이나 일시적 오류는 자동 재시도로 처리할 수 있습니다. 하지만 사용자가 볼 수 있는 데이터가 달라질 수 있다면 조용히 덮어쓰면 안 됩니다. 자동 재시도와 수동 재시도의 기준을 나누고, 재시도 후 결과가 바뀌었을 때는 변경 사실을 드러내야 합니다.

예를 들어 대시보드 카드 하나의 숫자 갱신은 자동 재시도가 어울립니다. 반면 문서 생성 결과나 결제 관련 요약은 사용자의 확인이 필요할 수 있습니다.

구현 체크리스트

• 스트리밍 영역마다 독립적인 로딩과 오류 상태를 둔다.
• 이미 렌더링된 콘텐츠는 실패 시 유지한다.
• 중간 결과를 저장 가능한 상태로 만든다.
• 자동 재시도 횟수와 백오프를 제한한다.
• 서버 이벤트에는 청크 ID나 단계 ID를 포함한다.

스트리밍 UI의 목표는 단지 빠르게 보이는 것이 아닙니다. 불완전한 도착, 지연, 실패까지 화면의 언어로 다룰 때 사용자는 시스템을 더 신뢰합니다.

Continue Reading

다음으로 읽기 좋은 글

🖥️ Frontend

프론트엔드 Error Boundary 전략

실패를 적절히 격리하면서도 UI 전체를 복구 미로로 만들지 않는 error boundary 배치 전략을 정리합니다.

🖥️ Frontend

Optimistic UI의 Reconciliation 경계

낙관적 UI는 빠르게 느껴지지만, 서버 진실과 충돌하는 순간 복잡성이 드러납니다. 어디까지 낙관적으로 처리할지 경계를 정리합니다.

📈 최신 동향

React Foundation 이 엔지니어링 팀에 의미하는 것

React Foundation 소식이 단순 거버넌스 뉴스가 아니라 프레임워크 생태계의 장기 예측 가능성에 어떤 의미를 갖는지 정리한 글입니다.

📱 Mobile

모바일 앱 시작 시간 추적 플레이북

콜드 스타트, 웜 스타트, 첫 화면 표시, 초기 네트워크 호출을 분리해 모바일 성능을 개선하는 실전 기준을 정리합니다.