이미지 출처: dhiwise.com

❓ 리액트 쿼리(React Query)는 원래 리액트를 위한 데이터 패칭 라이브러리로 시작되었지만, 그 기능성과 유용성이 널리 인정되면서 리액트 외의 다른 프레임워크나 환경에서도 사용할 수 있도록 확장되었다. 이러한 확장성 덕분에 더 이상 리액트에만 국한되지 않는 범용적인 상태 관리 및 서버 상태 관리 도구로 자리잡게 되었고, 이에 따라 이름이 탠스택 쿼리(TanStack Query)로 변경되었다. 이 명칭 변경은 해당 라이브러리가 단순히 리액트에 종속되지 않음을 나타내며, Vue, Svelte 같은 다른 프레임워크에서도 사용할 수 있다는 점을 강조하는 것이다.

리액트의 서버, 클라이언트 상태 관리

---

📌 서버 상태 관리와 클라이언트 상태 관리

---

SWR과 React Query의 비교에 앞서, React를 사용한다면 서버 상태 관리와 클라이언트 상태 관리의 차이에 대해서 알아야 한다.

💡 클라이언트 상태 관리

사용자의 브라우저 또는 앱 내에서 발생하는 데이터를 다루는 것이다. 예를 들어, 사용자가 입력한 폼 데이터, 로그인 여부, UI 상태 등은 클라이언트에만 영향을 미치는 데이터이다. 이러한 데이터는 앱이 새로고침되지 않는 한 서버와의 통신이 필요하지 않으며, 앱 내에서 상태 관리 도구(Zustand, Jotai 등)를 사용하여 전역적으로 관리할 수 있다.

💡 서버 상태 관리

서버에서 가져오는 데이터를 다루는 것이다. API를 통해 서버에 저장된 정보를 가져오고, 이러한 데이터를 사용하는 것은 서버 상태 관리에 해당한다. 예를 들어, 사용자가 게시물 목록을 서버에서 불러오거나, 서버에 데이터를 업로드하는 작업이 서버 상태 관리의 일환이다. SWR이나 React Query는 이러한 서버 데이터를 자동으로 가져오고 캐시하며, 이를 효율적으로 관리해준다.

💡 무엇을 사용해야 할까?

만약 클라이언트 전역 상태 관리가 주요 요구사항이라면, Zustand나 Jotai와 같은 상태 관리 라이브러리를 사용하는 것이 적합하다. 반면, 서버에서 데이터를 가져오는 작업이 중요한 경우에는 SWR이나 React Query 같은 데이터 페칭 라이브러리가 더 좋은 선택이다. 또한, 전역 상태 관리와 데이터 페칭을 함께 사용해야 하는 경우, Zustand나 Jotai와 같은 상태 관리 라이브러리를 SWR이나 React Query와 조합하여 클라이언트 상태와 서버 데이터를 효율적으로 함께 관리할 수 있다.

React Query와 SWR의 차이

---

📌 1. 기본 사용 방식

---

💡 Provider 사용

• SWR: 별도의 Provider 없이 컴포넌트에서 바로 사용할 수 있다. 이는 설정이 간단해 초기에 프로젝트를 구성할 때 빠르게 시작할 수 있다는 장점이 있다.
• React Query: 반드시 Provider로 컴포넌트를 감싸야 한다. 이 구조는 애플리케이션 전체에 걸친 데이터 관리를 일관되게 해주며, 쿼리 상태를 더 잘 통합할 수 있게 돕는다.

📌 2. 데이터 관리와 처리

---

💡 데이터 전송 및 뮤테이션

• SWR: useSWR()는 기본적으로 데이터를 읽어오는(read) 데 사용되며, 데이터를 클라이언트 측에서 직접 변경할 때는 mutate() 함수를 사용한다. mutate()는 캐시된 데이터를 업데이트하고, 서버 요청 없이 클라이언트에서 즉시 데이터를 변경하는 데 사용된다. 예를 들어, 사용자가 특정 데이터를 업데이트하면 이를 즉시 화면에 반영하고, 나중에 서버와 동기화한다. 이는 서버에 추가 요청을 보내기 전에 UI를 빠르게 업데이트하는 데 유리하다.
  SWR의 이 방식은 클라이언트 측에서 데이터가 자주 변경되거나, 서버 요청과 관계없이 빠른 UI 업데이트가 필요할 때 유리하다. 예를 들어, 사용자 인터페이스 상에서 작은 변경 사항을 서버 요청 없이 즉시 반영하고 싶은 경우에 적합하다.
• React Query: useMutation()을 사용하여 서버와 직접 상호작용하여 데이터를 전송하고 변경한다. 이 방식은 서버 상태를 동기화하고 관리하는 데 중점을 두기 때문에, 서버의 데이터를 변경하는 작업이 더 명확하게 처리된다. 예를 들어, 사용자가 특정 데이터를 업데이트하면, 서버로 직접 요청을 보내어 데이터를 변경하고, 성공 시 해당 쿼리의 데이터를 다시 가져오도록 하여 클라이언트와 서버 간의 상태가 일관되게 유지되도록 한다.
  React Query는 서버의 상태를 일관되게 유지하고, 데이터가 실제 서버와 동기화되도록 관리하는 데 최적화되어 있다. 서버와의 통신이 중요한 대규모 애플리케이션에서 주로 사용된다.

💡 상태 관리

• SWR: 클라이언트 전역 상태로 데이터를 관리하여 모든 컴포넌트에서 데이터를 공유할 수 있다. 주로 클라이언트 사이드 렌더링에서 데이터를 빠르게 사용할 수 있는 환경에서 유리하다.
• React Query: 서버 상태와 클라이언트 상태를 명확히 구분하여 서버에서 데이터를 받아오는 작업과 이를 관리하는 작업이 분리된다. 이는 서버 데이터의 동기화가 중요한 대규모 애플리케이션에 유리하다.

💡 다중 API 지원

• SWR: 단일 API 엔드포인트에서 데이터를 가져오는 방식에 적합하다. 이는 단순한 API 호출이나 데이터가 많이 복잡하지 않은 상황에서 효율적이다.
• React Query: 여러 API 엔드포인트에서 데이터를 가져올 수 있어, 복잡한 애플리케이션이나 여러 데이터 소스가 필요한 경우 유연하게 대응할 수 있다. 이로 인해 대규모 데이터를 다루는 상황에서 더 적합하다.

📌 3. 성능 및 최적화

---

💡 렌더링 최적화

• SWR: 쿼리마다 개별적으로 컴포넌트를 업데이트하기 때문에 쿼리 개수가 많으면 렌더링 성능이 떨어질 수 있다.
• React Query: 여러 컴포넌트가 동일한 쿼리를 사용할 경우, 한 번에 묶어서 업데이트하여 성능이 더 뛰어나다. 이를 통해 리렌더링을 줄이고 성능 최적화를 달성할 수 있다.

💡 캐싱 및 Garbage Collection

• SWR: 자동으로 데이터를 캐싱하여 네트워크 요청을 줄일 수 있지만, 오래된 데이터(stale data)를 관리하는 방법이 부족하다. 데이터가 자주 업데이트되지 않는 환경에서 적합하다.
• React Query: 캐싱에 대한 세밀한 제어가 가능하며, 사용되지 않는 쿼리를 자동으로 Garbage Collection할 수 있다. 데이터가 빈번하게 업데이트되는 환경에서 React Query가 더 유리하다.

💡 라이브러리 크기

• SWR: 가벼운 라이브러리(4.5kB)로 작은 번들 크기를 유지할 수 있다. 이는 성능과 번들 크기가 중요한 프로젝트에 적합하다.
  

• React Query: 더 많은 기능을 제공하지만, 그만큼 무겁다(13kB). 기능이 복잡하고 다양한 API를 사용하는 경우에는 이 정도의 크기는 용납할 수 있는 수준이다.
  

📌 4. 추가 기능 및 확장성

---

💡 페이지네이션 및 무한 스크롤

• SWR: 추가적인 코드가 필요하지만, 데이터를 가져오고 관리하는 방식이 단순하기 때문에 기본적인 상황에서는 무난하게 작동한다.
• React Query: 페이지네이션 및 무한 스크롤을 위한 설정이 내장되어 있어, 복잡한 페이지네이션 로직을 쉽게 구현할 수 있다. 특히 대규모 데이터 처리 시 유리하다.

💡 오프라인 지원

• SWR: 오프라인 상태에서 요청을 멈추거나 다시 시도하는 기능이 없어, 네트워크 상태에 따라 안정성이 떨어질 수 있다.
• React Query: 오프라인 시 요청을 보류했다가 온라인 상태로 돌아오면 자동으로 재시도하는 기능을 제공한다. 모바일 앱이나 오프라인 우선 애플리케이션에서 유용하다.

💡 DevTools 및 디버깅

• SWR: 커뮤니티에서 개발한 디버깅 도구를 사용할 수 있지만, 공식 DevTools가 없다. 읽기 전용 데이터만 표시하지만 디버깅에 필요한 중요한 정보를 보여준다.
• React Query: 공식 DevTools가 있으며, 캐시된 데이터를 실시간으로 조작할 수 있어 디버깅에 매우 유용하다. 복잡한 상태 관리를 해야 하는 프로젝트에서 필수적이다.

💡 Next.js와의 호환성

Next.js 공식 문서에서는 클라이언트 사이드 데이터 패칭에 대해 Page Router는 SWR을 권장하고, App Router는 SWR과 TanStack Query(React Query) 둘 다를 권장하고 있다.

SWR와 React Query의 클라이언트 사이드 데이터 패칭 속도를 비교 측정한 자료가 있는데, 이 자료에 따르면, Next.js에서 SWR을 권장했음에도 불구하고, 실제 렌더링 속도에서는 React Query가 더 빠른 결과를 보였다.

해당 자료 링크: Server Side Rendering은 정말 빠르게 render 되는가

📌 5. 데이터 안정성 및 오류 처리

---

💡 데이터 안정성

• SWR: 최신 데이터를 즉시 반환하는 방식이므로 빠른 데이터 업데이트가 가능하지만, 이로 인해 race condition이 발생할 수 있다.
• React Query: 데이터 요청 빈도와 캐싱을 제어할 수 있어 데이터 안정성이 더 높으며, race condition 발생 가능성을 줄인다.

💡 에러 핸들링

• SWR: 오류 처리 시스템이 없어, 사용자가 직접 오류 처리를 구현해야 한다.
• React Query: 내장된 에러 핸들링 시스템이 있어, 애플리케이션에서 발생하는 오류를 쉽게 관리할 수 있다. 복잡한 오류 처리가 필요한 애플리케이션에서 유리하다.

📌 6. 요약

---

• SWR: 단순하고 가벼운 솔루션을 찾는 개발자에게 적합하다. 데이터가 자주 변경되지 않거나 캐싱이 간단한 프로젝트에서 적절하다.
• React Query: 데이터 캐싱 및 상태 관리를 세밀하게 제어해야 하거나 복잡한 애플리케이션에서 서버 상태를 효율적으로 관리해야 할 때 적합하다. 또한 실시간 데이터 연동이나 오프라인 기능이 필요한 경우 React Query가 더 나은 선택이다.
• 위 내용들은 모두 Tanstack Query 공식 문서에서 확인 가능하다.
  

참고자료

---

• Comparison | React Query vs SWR vs Apollo vs RTK Query vs React Router | TanStack Query React Docs
• React Query vs SWR
• React-Query vs SWR
• useSWR vs React(TanStack) Query를 비교해보자
• Server Side Rendering은 정말 빠르게 render 되는가 - Blog by Jason Kang