Streaming SSR을 "빠른 SSR" 정도로 외워 왔는지, 아니면 Suspense 경계·하이드레이션·캐싱과의 상호작용까지 풀 수 있는지를 가른다.
전통 SSR은 모든 데이터가 모이고 HTML 한 덩어리가 완성될 때까지 응답을 시작하지 못한다. Streaming SSR은 React 18의 renderToPipeableStream/renderToReadableStream처럼 서버가 렌더 결과를 청크 단위로 흘려보내, 브라우저가 먼저 도착한 조각부터 그려 낸다. Suspense 경계 안쪽이 "아직 준비 안 됨"이면 그 부분은 fallback으로 흘리고, 데이터가 도착하는 즉시 해당 영역만 마저 보낸다. 그 결과 TTFB와 첫 콘텐츠 가시성이 빨라지지만, 하이드레이션 시점에 서버/클라이언트 상태가 어긋나면 mismatch가 그대로 노출된다.
Suspense 경계를 다시 그어 "느린 한 조각" 때문에 화면 전체가 늦어지던 구조를 깨 본 경험이 있다면 경계 설계의 실제 효과로 풀어낼 수 있다
Streaming SSR 도입 후 하이드레이션 mismatch를 추적해 본 경험이 있다면 서버/클라이언트 상태 동기화 이야기로 이어갈 수 있다
CDN·Edge 캐싱과 스트리밍 응답을 함께 설계해 본 경험이 있다면 "스트리밍과 캐싱의 충돌" 사례로 보여 줄 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.