⚛️ 리액트 개발 환경 세팅: CRA vs Vite

⚛️ 리액트 개발 환경 세팅: CRA vs Vite

SWR vs React Query 비교 분석: 내 프로젝트에 맞는 선택은?

가볍고 빠른 SWR인가, 강력하고 거대한 React Query인가?


리액트 프로젝트를 시작할 때마다 마주하는 즐거운(?) 고민이 하나 있습니다.
바로 "서버 상태 관리 라이브러리로 무엇을 쓸 것인가?"에 대한 문제입니다.
과거에는 Redux가 당연한 선택지였지만, 이제는 데이터 페칭(Data Fetching)에 특화된 두 거대 라이브러리, SWRReact Query(TanStack Query)가 시장을 양분하고 있습니다.
둘 다 너무 좋은 도구라서 선택하기가 더 어려운데요.
오늘 이 글에서는 두 라이브러리의 핵심 차이를 분석하고, 여러분의 프로젝트 성격에 딱 맞는 도구를 고르는 기준을 제시해 드리겠습니다.

🤝 1. 둘은 무엇이 같을까? (기본 철학)

비교하기 전에, 두 라이브러리가 공유하는 핵심 철학을 이해해야 합니다.
두 라이브러리 모두 "서버 데이터는 캐싱(Caching)되어야 하고, 적절한 시점에 갱신(Revalidation)되어야 한다"는 목표를 가지고 있습니다.

📡 공통 기능 요약

  • 데이터 캐싱: 한 번 불러온 데이터를 저장해 불필요한 네트워크 요청을 줄입니다.
  • 자동 갱신: 창 포커스 시(Window Focus) 등의 이벤트 발생 시 데이터를 최신화합니다.
  • 로딩/에러 처리: `isLoading`, `error` 등의 상태를 직관적으로 제공합니다.
  • Hook 기반: 리액트 훅(Hook) 문법을 사용하여 사용이 간편합니다.

즉, 기본적인 사용 목적은 동일합니다.
하지만 "얼마나 많은 기능을 제공하는가?""얼마나 가벼운가?"에서 차이가 발생합니다.


⚖️ 2. SWR vs React Query 상세 비교

이제 본격적으로 두 라이브러리의 체급 차이를 살펴보겠습니다.
SWR은 '미니멀리즘'을, React Query는 '올인원 솔루션'을 지향합니다.

항목 SWR (Vercel) React Query (TanStack)
번들 사이즈 약 4~5KB (매우 가벼움) 약 13KB (상대적으로 무거움)
개발자 도구 별도 설치 필요
(기능 단순함)
강력한 전용 DevTools 제공
(데이터 흐름 시각화 탁월)
기능 확장성 필수 기능 위주
(Next.js와 궁합 좋음)
무한 스크롤, 오프라인 지원 등
다양한 기능 내장
러닝 커브 낮음 (직관적 API) 중간 (설정 옵션이 많음)

🔎 코드 스타일 비교

코드는 놀라울 정도로 비슷하지만, React Query가 조금 더 구조적인 설정을 요구합니다.

⚡ SWR

const { data, error } =
useSWR('/api/user', fetcher);

🔴 React Query

const { data, error } =
useQuery(['user'], fetcher);

* React Query는 쿼리 키(Query Key)를 배열 형태로 관리하여 더 체계적인 캐시 관리가 가능합니다.


🧭 3. 그래서 무엇을 선택해야 할까?

두 라이브러리의 우열을 가리는 것은 의미가 없습니다.
중요한 것은 "내 프로젝트의 규모와 복잡도"입니다.
아래의 체크리스트를 통해 결정해 보세요.

✅ SWR을 선택

  • Next.js를 사용하여 프로젝트를 진행 중이다 (같은 Vercel 생태계).
  • 프로젝트 규모가 작고, 가볍고 빠르게 개발하고 싶다.
  • 복잡한 캐싱 로직보다는, 단순히 데이터를 가져와서 보여주는 것이 주 목적이다.
  • 번들 사이즈를 최소화해야 하는 환경이다.

✅ React Query를 선택

  • 대규모 프로젝트이며, 엔터프라이즈급 데이터 관리가 필요하다.
  • 무한 스크롤, 페이지네이션, 낙관적 업데이트(Optimistic Update) 등 고급 기능이 필수다.
  • React Native 앱을 개발 중이다.
  • 강력한 DevTools를 통해 캐시 상태를 눈으로 확인하며 디버깅하고 싶다.

📌 요약 및 결론

결국 "Simple is Best"라면 SWR을, "Power & Control"이 필요하다면 React Query를 선택하는 것이 정답에 가깝습니다.
하지만 어떤 도구를 선택하든, 기존의 `useEffect`와 상태 관리를 직접 구현하던 방식보다는 생산성이 200% 이상 향상될 것입니다.
지금 바로 작은 토이 프로젝트에서 두 라이브러리를 한 번씩 찍먹 해보시는 건 어떨까요?

댓글 쓰기