React 19 use() 훅이 바꿔놓은 데이터 페칭 패턴
use() 훅 하나로 useEffect + useState 조합이 사라지는 경험을 했다
useState 세 개, useEffect 한 개, 매번 이 조합
React에서 데이터 페칭하면 떠오르는 패턴이 있다. useState로 data, loading, error 만들고, useEffect 안에서 fetch 호출하고, then에서 setData, catch에서 setError, finally에서 setLoading(false). 컴포넌트마다 이 보일러플레이트를 반복했다. 매번.
React 19의 use() 훅을 쓰고 나서 이게 통째로 사라졌다. 처음에는 "에이 설마" 싶었는데, 한 달 실제로 써보니 돌아갈 수가 없다.
use()가 뭐냐면
Promise를 직접 읽을 수 있는 훅이다. 컴포넌트 안에서 const data = use(somePromise)라고 쓰면, Promise가 resolve될 때까지 Suspense 상태가 되고, resolve되면 값을 바로 받는다. 예전에는 useEffect 안에서 비동기 처리하고 상태를 수동 관리해야 했다. use()는 이걸 React가 알아서 하게 해준다.
코드가 얼마나 줄었냐면
프로필 페이지에서 사용자 정보 가져오는 코드를 비교하면 확 와닿는다. 기존 방식은 useState 3개, useEffect 1개, 조건부 렌더링 3개로 25줄쯤. use()로 바꾸면 부모에서 Promise 만들어 넘기고, 자식에서 use(promise)로 읽으면 끝. 10줄도 안 된다.
근데 줄 수보다 중요한 게 있다. 로딩이랑 에러 처리가 컴포넌트 밖으로 나갔다는 거다. Suspense랑 ErrorBoundary가 알아서 해주니까, 컴포넌트는 순수하게 데이터 보여주는 역할에만 집중할 수 있다. 이게 진짜 가치다.
근데 이게 조건문 안에서도 된다고?
use()의 가장 파격적인 특징. 다른 훅이랑 달리 조건문 안에서 호출할 수 있다. if (shouldFetch) { const data = use(promise); } 이게 된다.
기존 훅 규칙에서는 절대 불가능했던 패턴이다. 탭 UI처럼 특정 조건에서만 데이터 가져와야 하는 경우에 코드가 훨씬 자연스러워진다. 예전에는 이런 거 처리하려고 커스텀 훅 만들거나 enabled 플래그를 써야 했다. (그 커스텀 훅들이 이제 다 필요 없어졌다는 뜻이기도 하다.)
TanStack Query 필요 없어지나
이 질문 많이 받는다. 내 답은 아직은 아니다. use()는 Promise 읽는 것에 특화되어 있고, 캐싱, 재시도, 낙관적 업데이트, 무한 스크롤 같은 건 없다. 단순한 데이터 페칭이면 use()로 충분하다. 근데 복잡한 서버 상태 관리가 필요하면 TanStack Query 자리는 여전히 있다. 경쟁이 아니라 레이어가 다르다.
Suspense 경계를 어디에 두느냐가 관건
use() 쓰면 Suspense가 필수가 되는데, 어디에 Suspense를 두느냐가 UX를 결정한다. 페이지 전체를 하나로 감싸면 다 준비될 때까지 전체가 로딩. 컴포넌트마다 감싸면 개별 로딩이지만 UI가 산만해진다.
나는 "의미 있는 단위"로 묶는다. 헤더와 본문은 별도, 본문 안의 차트들은 하나의 Suspense로 묶는 식. 이 감각이 use() 시대에 새로 필요한 아키텍처 스킬이다.
서버 컴포넌트랑 같이 쓸 때 진가가 나온다
Next.js에서는 서버 컴포넌트에서 직접 await를 쓸 수 있으니까, 서버에서 가져올 수 있는 데이터는 use()가 필요 없다. use()가 빛나는 건 클라이언트 컴포넌트에서 서버 컴포넌트가 넘겨준 Promise를 읽을 때다.
서버에서 fetch하는 Promise를 만들고, 클라이언트 컴포넌트에 prop으로 넘기면, 클라이언트에서 use()로 읽으면서 스트리밍의 이점까지 가져갈 수 있다. 이 조합을 처음 써봤을 때 React 팀이 왜 이걸 만들었는지 이해가 됐다.
어쨌든 한번 써보면 안 돌아간다
use()는 편의 기능이 아니라 React의 데이터 흐름 패러다임을 바꾸는 거다. 처음에 낯설 수 있는데, "비동기 데이터도 그냥 값처럼 쓰면 된다"는 감각이 잡히면 컴포넌트 설계가 깔끔해진다. 근데 솔직히 Suspense 경계 설계는 아직도 매번 고민된다. 이건 경험으로 채울 수밖에 없는 영역인 것 같다.