🔥 React Query가 필요 없을 수도 있습니다

React 서버 컴포넌트가 React Query를 대체할까요? 최근 몇 달간 가장 많이 받은 질문입니다. 솔직히 말하면 저도 확실한 답을 가지고 있지 않습니다. 이 업계의 대부분 개발자처럼 저 역시 상황에 맞춰 해결책을 찾아가는 중입니다. 제가 모든 것에 대한 거창한 계획을 가지고 있을 거라 기대하신다면 실망하실 수 있습니다. 저도 여러분만큼이나 앞으로 어떻게 될지 궁금합니다. 😅

@TkDodo

데이터 가져오기 관련 라이브러리 관리자로서 서버 컴포넌트와 Suspense에 대해 주로 두려움을 느끼고 있다는 점을 솔직히 인정합니다.
"이게 react-query와 어떻게 연동될까요?"라는 질문은 좋은 질문입니다. 제가 답변을 가지고 있어야 할 것 같지만 사실 그렇지 않습니다. 지금 엄청난 가면 증후군을 겪고 있네요.

그럼에도 불구하고 이 주제에 대해 조금 더 자세히 살펴볼 시간을 가졌고, 저보다 이 주제에 대해 훨씬 더 잘 아는 사람들과 논의도 했습니다. 이제 이 주제에 대한 _제 의견_을 충분히 자신 있게 말씀드릴 수 있을 것 같습니다. 하지만 이것은 어디까지나 _제 생각_일 뿐이니 참고만 해주세요.

제 견해

우리가 사용하는 모든 도구는 우리가 겪고 있는 문제를 해결하는 데 도움을 주어야 합니다. 전통적으로 React는 애플리케이션에서 데이터를 가져오는 방법에 대해 특별한 의견을 제시하지 않았습니다. 그저 useEffect를 제공할 뿐이었고, 개발자가 원하는 대로 사용하면 되었습니다.

이때 React Query나 swr 같은 라이브러리가 탄생했습니다. 이들은 큰 간극을 메워주었고, 뛰어난 개발자 경험과 사용자에게 가져다주는 개선점 덕분에 빠르게 채택되었습니다. React Router도 비슷한 범주에 속합니다. "뷰" 라이브러리가 기본적으로 제공하지 않는 라우팅 기능에 대한 필요성을 해결해주었죠.

서버 사이드 렌더링이 등장했을 때, 우리는 주로 초기 페이지 로딩 속도를 높이기 위해 서버에서 HTML을 미리 렌더링하는 데 집중했습니다. 그 이후에는 애플리케이션이 완전한 단일 페이지 애플리케이션처럼 동작했습니다. 클라이언트 측 페이지 이동과 같은 기능을 포함해서 말이죠. 이런 환경에서 React Query도 중요한 역할을 했습니다. 초기 데이터 가져오기를 서버로 옮기고, 그 결과를 클라이언트에서 재사용할 수 있게 해주었거든요. 이는 캐시를 최대한 빨리 채우는 좋은 방법이었습니다. 서버에서 말이죠.

그래서 무엇이 바뀌었나요?

시대는 발전하고 있고, 상황도 좋아지고 있습니다. 겉으로 보기에는 앞뒤로 왔다갔다 하는 것처럼 보일 수 있지만, 사실 꾸준히 앞으로 나아가고 있습니다:

@swyx

@Mappletons님이 더 잘 할 수 있겠지만, "개발자들은 그저 끝없는 주기로 왔다갔다 할 뿐이다"라는 댓글을 볼 때마다 제 머릿속에 떠오르는 이미지입니다.

React는 여전히 컴포넌트를 렌더링하는 라이브러리에 불과하지만, 서버 컴포넌트를 통해 새로운 애플리케이션 아키텍처를 제공합니다. 이를 통해 컴포넌트를 서버에서 미리 렌더링할 수 있게 되었죠. 이는 빌드 시간에 할 수도 있고, 런타임에 할 수도 있습니다. 클라이언트에서 쿼리해야 하는 API를 만들지 않고도 데이터에 접근할 수 있게 해줍니다:

export default async function Page() {
  const data = await fetch(
    `https://api.github.com/repos/tanstack/react-query`
  )
 
  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.description}</p>
    </div>
  )
}
 
javascript복사

React 컴포넌트 안에서 async/await를 사용하는 것이 _그냥 작동한다_는 사실이 여전히 놀랍습니다. 프레임워크들이 이 문제를 해결하기 위해 일급 솔루션을 제공하는 것을 보는 것도 흥미롭습니다. 이는 이러한 아키텍처를 채택하는 애플리케이션에 큰 변화를 가져옵니다. React Query는 기본적으로 클라이언트에서 비동기 상태를 관리하는 라이브러리입니다. 만약 데이터 가져오기가 전적으로 서버에서 이루어진다면, 왜 React Query가 필요할까요?

필요 없을 수도 있습니다

그리고 답은 이렇습니다: 아마도 필요 없을 겁니다. 새로운 애플리케이션을 시작하고 있고, Next.js나 Remix와 같이 데이터 가져오기와 변경에 대한 좋은 해결책을 가진 성숙한 프레임워크를 사용한다면, React Query가 필요 없을 수 있습니다.

그리고 그건 전혀 문제가 되지 않습니다. 제가 React Query를 관리하고 있다고 해서 모든 상황에서 React Query를 사용하라고 권하지는 않습니다. React Query를 사용하기로 결정했다면, 그것은 문제를 해결하는 데 도움이 되기 때문이어야 합니다.

통합

서버 컴포넌트의 새로운 세계에 React Query를 통합할 여지는 여전히 많습니다. 우선, 대부분의 프로젝트는 완전히 새롭게 시작하지 않습니다. 수년에 걸쳐 구축된 수많은 애플리케이션이 있고, app 디렉토리를 점진적으로 채택할 수 있지만 서버 컴포넌트를 활용하려면 어느 정도의 재설계가 필요합니다.

이 전환 기간 동안 React Query는 app 디렉토리 및 서버 컴포넌트와 잘 통합됩니다. 일부 컴포넌트를 서버에서만 데이터를 가져오도록 이동하거나, 서버 컴포넌트를 사용해 캐시를 미리 가져와 클라이언트 컴포넌트에 전달할 수 있습니다. 꼭 전부 아니면 전무의 상황일 필요는 없습니다. 공식 문서에는 이미 이 통합에 대한 좋은 가이드가 있고, 앞으로 주의해야 할 점들에 대해 다른 블로그 포스트로 다룰 예정입니다.

하이브리드 접근 방식

이 하이브리드 접근 방식은 특히 서버 컴포넌트에서 (아직) 잘 지원되지 않는 사용 사례를 다룰 때 유용할 수 있습니다.

예를 들어, 무한 스크롤 목록을 렌더링하고 싶을 수 있습니다. 이때 첫 번째 페이지는 서버에서 미리 가져오지만, 사용자가 목록의 끝으로 스크롤할 때 클라이언트에서 더 많은 페이지를 가져오고 싶을 수 있습니다. 또는 네트워크 연결 없이도 앱이 작동해야 하는 요구 사항이 있을 수 있습니다. 아니면 단순히 명시적인 사용자 상호 작용 없이도 항상 최신 데이터를 볼 수 있는 사용자 경험을 선호할 수도 있습니다(예: 주기적 가져오기나 React Query에서 제공하는 모든 스마트한 자동 리프레시 등).

React Query는 이러한 모든 상황에 대해 훌륭한 해결책을 제공합니다. 따라서 서버 컴포넌트와 React Query를 함께 사용하는 것이 의미 있는 경우가 분명히 있습니다. 하지만 React Query를 주로 데이터를 가져와서 사용자에게 표시하는 데 사용했다면, 서버 컴포넌트가 이 부분을 잘 처리할 것입니다. 그리고 뮤테이션 관련 이야기(서버 액션)가 확립된 패턴이 되면, 데이터 업데이트에도 React Query가 필요 없을 수 있습니다.

"킬러"는 아닙니다

모든 사람이 서버 컴포넌트를 채택하지는 않을 것이라고 말하는 것도 공정할 것 같습니다. 여러 가지 이유가 있을 수 있습니다. 백엔드가 Node.js로 작성되지 않았고, 프론트엔드가 전용 서버 없이 SPA인 것으로 충분할 수 있습니다. 아니면 React Native로 모바일 앱을 만들고 있을 수도 있죠. TanStack Query 사용자라면 React를 전혀 사용하지 않을 수도 있습니다.

더 나아가, React Query를 데이터 가져오기 이외의 용도로 사용할 수 있습니다. 아이디어를 얻으려면 이 트윗에 대한 답변들을 살펴보세요:

@TkDodo

TanStack Query를 데이터 가져오기 이외의 용도로 어떻게 사용하시나요? 여러분이 가진 다른 사용 사례들이 궁금합니다 😄

이 모든 것들은 클라이언트에서 비동기 상태 관리자로 Query를 선택하기에 완벽히 적합한 사용 사례입니다. 하지만 이를 위한 일급 지원을 내장한 프레임워크를 선택한다면 그걸 사용하세요! Remix를 사용하면서 데이터를 로더에서 가져오지 않을 이유가 있을까요? 🤷♂️

따라서 제 예측으로는 React 서버 컴포넌트 외에도, 그리고 심지어 서버 컴포넌트와 결합해서도 TanStack Query를 사용할 기회가 여전히 많을 것 같습니다. 현재의 이야기는 모두 RSC에 관한 것이고, 그건 괜찮습니다. 모두가 시도해보고 싶어 하는 새롭고 흥미진진한 기술이니까요.

하지만 아직 초기 단계이며 최신 기술입니다. 서버 컴포넌트를 사용하려면 특정 프레임워크, 라우터, 번들러와 긴밀하게 통합해야 합니다. 또한 추가적인 서버 부하를 처리할 수 있는 인프라가 필요합니다. 계속 반복해서 말씀드리지만:

공짜 점심은 없습니다. 모든 것은 트레이드오프입니다.

그러므로 모든 것을 즉시 서버 컴포넌트로 옮겨야 한다고 생각하지 마세요. Next.js 사용자인 저도 우리 앱을 app 디렉토리로 옮기는 것에 대해 흥분하고 있습니다. 주로 중첩 라우트의 이점을 누리기 위해서죠. 그리고 분명히 더 정적인 데이터 가져오기(예: staleTime: Infinity를 사용하는 경우)를 서버 컴포넌트로 옮길 것입니다.

하지만 React Query의 죽음에 대한 소문은 크게 과장되었습니다.