Suspense와 선언적으로 Data fetching처리

React Suspense를 활용한 "Render-as-you-fetch" 패턴이 기존 Fetch-on-render, Fetch-then-render 방식의 Race Condition과 Waterfall Problem을 어떻게 해결하는지 코드 비교로 설명한다. React-Query와 함께 Suspense를 도입한 카카오엔터테인먼트 페이지 서비스 팀의 실전 경험이 담겨 있다.

핵심 포인트 - 3가지 data fetching 패턴: Fetch-on-render(렌더 후 useEffect 조회) vs Fetch-then-render(모든 데이터 조회 후 렌더) vs Render-as-you-fetch(비동기+렌더 동시 시작, Suspense) - Race Condition 문제: 컴포넌트 생명주기와 비동기 작업 생명주기 불일치로 "데이터는 왔는데 컴포넌트는 이미 언마운트" 같은 상황 발생. 동기화 코드 추가 필요해 복잡도 증가 - Waterfall Problem(Fetch-on-render): 부모 컴포넌트가 데이터 조회를 마칠 때까지 자식 컴포넌트 렌더링 시작 불가 → 순차 실행으로 전체 응답 시간 증가 - Suspense 동작 방식: 컴포넌트가 데이터 미준비 시 Promise를 throw. Suspense 경계가 이를 잡아 fallback(로딩 UI) 렌더 → 데이터 준비 완료 시 정상 렌더 - 선언적 비동기 처리: Suspense + ErrorBoundary 조합으로 로딩/에러 UI를 컴포넌트 내부가 아닌 외부에서 선언적으로 관리 → 비즈니스 로직과 UI 관심사 분리 - React-Query의 Suspense 지원: suspense: true 옵션으로 Suspense와 쉽게 연동

상세 정리 - Fetch-on-render 예시: useEffect에서 fetchPublisher → setPublisher → isEmpty 체크 → 렌더. 자식 Operators도 동일 패턴 → 순차 실행(Waterfall) - 동기화 코드의 문제: isEmpty 체크, 조건부 렌더링이 컴포넌트를 복잡하게 만들고 실제 비즈니스 로직을 가림 - Suspense fallback: 부모 Suspense에 fallback={<Spinner />} 설정 → 자식이 Promise throw 시 자동으로 Spinner 표시 - 병렬 요청: Render-as-you-fetch 방식에서 Publisher와 Operators 데이터 요청을 동시에 시작해 Waterfall 해소 - ErrorBoundary 조합: 비동기 에러도 동일하게 선언적 처리 가능. try-catch 없이 컴포넌트 외부에서 에러 UI 정의 - 주의: Suspense는 아직 실험적 기능(React 18 이전 기준). 서버 사이드 렌더링과 조합 시 주의사항 확인 필요 - React 18의 Concurrent Features: startTransition, useTransition과 Suspense 연계로 더 세밀한 로딩 상태 제어 가능

왜 읽나: Fetch-on-render의 Race Condition과 Waterfall 문제를 Suspense가 구조적으로 해결하는 원리를 코드 비교로 이해하고, React-Query와의 연동 패턴까지 실전에 바로 적용 가능한 수준으로 익힐 수 있다.