React 프로젝트에서 서버 데이터를 관리하려면 어떤 라이브러리를 써야 할까? SWR과 TanStack Query는 현 시점에서 가장 인기 있는 두 선택지다. 둘 다 훌륭하지만, 프로젝트 규모와 복잡도에 따라 선택이 달라진다. 오늘은 실무 경험을 바탕으로 두 라이브러리를 철저히 비교해보겠다.
목차
SWR란?
SWR은 Vercel에서 만든 React 데이터 페칭 라이브러리다. 이름은 "Stale-While-Revalidate"라는 HTTP 캐시 전략에서 왔다. 캐시된 데이터를 먼저 보여주고, 백그라운드에서 최신 데이터를 가져오는 방식이다.
SWR의 핵심 개념
SWR의 가장 큰 장점은 단순함이다. API 호출을 선언적으로 작성할 수 있고, 자동으로 캐싱, 재검증, 요청 중복 제거를 해준다. 번들 크기도 4.2KB(gzipped)로 매우 가볍다.
Next.js와의 통합도 완벽하다. Vercel 자신의 라이브러리이기 때문에, ISR(Incremental Static Regeneration)이나 서버 컴포넌트 환경과의 연동이 자연스럽다.
SWR v2의 업데이트
SWR v2에서 useSWRMutation 훅이 추가되었다. 이전까지는 POST, PUT, DELETE 같은 변경 작업이 조금 번거로웠는데, 이제는 좀 더 체계적으로 처리할 수 있다. 다만 TanStack Query의 mutation 경험과는 여전히 차이가 있다.
TanStack Query란?
TanStack Query는 이전에 React Query로 알려진 라이브러리다. v5(최신 5.99.0)부터 프레임워크 중립적인 TanStack Query로 이름을 바꿨다. 주간 다운로드 12.3M, GitHub 스타 48K로 더 큰 규모의 프로젝트에서 많이 사용된다.
TanStack Query v5의 강점
TanStack Query는 기능의 깊이가 다르다. 전문적인 mutation 관리, 고급 캐싱 전략, 자동 최적화 기능들이 탑재되어 있다. DevTools도 별도로 제공되어 디버깅이 훨씬 편하다.
v5부터는 TypeScript 타입 추론이 크게 개선되었다. 자동으로 접근한 필드만 추적해서 필요한 부분만 리렌더링하는 기능도 있다. React Suspense도 공식 지원한다.
번들 크기
gzipped 기준 13.4KB로 SWR보다는 크다. 하지만 요즘 웹 프로젝트 규모를 생각하면 거의 무시할 수 있는 수준이다. 더 많은 기능을 제공하는 것을 감안하면 합리적인 트레이드오프다.
핵심 비교 표
핵심 비교
첈들 크기 비교
SWR의 가장 큰 강점은 번들 크기다. 4.2KB는 진짜 가볍다. 모바일 사용자가 많은 프로젝트라면 이것만으로도 선택할 이유가 된다.
하지만 현실적으로는 두 라이브러리의 차이(9.2KB)가 프로젝트 성능에 미치는 영향은 미미하다. 이미지 하나 최적화가 훨씬 효과가 크다.
Mutation API의 차이
SWR의 경우, 데이터 변경 작업(POST, PUT, DELETE)을 처리할 때 여전히 수동적인 부분이 있다. useQuery로 데이터를 가져오고, 별도로 fetch를 작성해서 mutation을 다루곤 했다.
TanStack Query의 useMutation은 처음부터 mutation을 위해 설계됐다. 로딩 상태, 에러 처리, 자동 재시도, optimistic update까지 체계적으로 지원한다.
DevTools의 가치
TanStack Query DevTools를 한 번 써보면 돌아가기 어렵다. 쿼리 상태, 캐시, 요청 히스토리 등을 시각적으로 확인할 수 있다. 복잡한 데이터 페칭 로직을 디버깅할 때 정말 강력하다.
SWR은 이 부분에서 약하다. 상태를 확인하려면 React DevTools나 console.log에 의존해야 한다.
TypeScript 지원
TanStack Query v5띀 타입 추론이 특별히 개선된다. 쿼리 데이터의 타입이 자동으로 추론되고, 접근한 필드만 추적해서 불필요한 리렌더링을 방지한다.
SWR도 기본적으로 TypeScript를 지원하지만, v5 TanStack Query만큼 정교하지는 않다.
캐싱 전략
SWR은 기본적인 캐싱만 제공한다. stale-while-revalidate 패턴으로 충분한 경우가 대부분이다.
TanStack Query는 더 세밀한 제어가 가능하다. staleTime, gcTime, refetchInterval 같은 옵션으로 복잡한 캐싱 요구사항을 처리할 수 있다.
SSR과 React Suspense
Next.js를 쓴다면 SWR의 SSR 지원이 아주 깔끅하다. Vercel 자신의 라이브러리인 만큼 자연스럽게 통합된다.
TanStack Query도 SSR을 잘 지원하지만, 설정이 조금 더 필요하다. React Suspense는 TanStack Query의 useSuspenseQuery가 더 안정적이다.
학습곡선
SWR은 정말 배우기 쉽다. 기본 훅 몇 개만 알면 대부분의 데이터 페칭 요구사항을 해결할 수 있다.
TanStack Query는 좀 더 시간이 걸린다. 하지만 한 번 익힌면 훨씬 강력하고 체계적인 데이터 관리가 가능하다.
성능 비교
렌더링 최적화
TanStack Query v5의 자동 필드 추적 기능은 정말 인상적이다. 쿼리 데이터의 일부만 사용하는 컴포넌트는 그 부분이 바뀔 때만 리렌더링된다. SWR은 전체 데이터가 바뀌면 항상 리렌더링다.
대규모 데이터셋을 다루는 프로젝트라면 이 차이가 꽤 중요할 수 있다.
요청 중복 제거
두 다 같은 URL에 대한 동시 요청을 자동으로 한 번으로 통합한다. 여러 컴포넌트에서 같은 API를 호출해도 네트워크 요청을 한 번만 나간다.
이것은 SWR과 TanStack Query 모두 잘 처리한다. 우위는 없다.
캐싱 성능
SWR의 stale-while-revalidate 패턴은 사용자 경험 관점에서 아주 좋다. 캐시된 데이터를 즉시 보여주고, 백그라운드에서 갱신하니까 항상 빠르다.
TanStack Query도 비슷한 동작을 하도록 설정할 수 있다. 다만 기본값은 좀 더 보수적이다.
실전 코드 비교
기본 쿼리
SWR로 데이터 가져오기:
TanStack Query로 데이터 가져오기:
기본 수준에서는 둘 다 비슷하다. SWR이 약간 더 간단해 보인다.
Mutation 처리
SWR에서 데이터 변경하기:
TanStack Query에서 데이터 변경하기:
여기서 차이가 확실해진다. TanStack Query의 useMutation은 로딩 상태, 에러 처리, 캐시 무효화를 체계적으로 관리한다.
언제 뭘 쓸까?
SWR을 선택해야 할 때
- ✅ 번들 크기가 정말 중요한 경우: 모바일 사용자가 많고, 네트워크 환경이 좋지 않은 프로젝트
- ✅ Next.js 프로젝트: 특히 SSR, SSG를 많이 쓰늕 경우
- ✅ 간단한 데이터 페칭: CRUD 작업이 단순하고, mutation이 많지 않은 경우
- ✅ 빠른 프로토타입: 학습 시간을 최소화하고 빠리 시작하고 싶을 때
- ✅ Vercel 에코시스템: Vercel에 배포하고, 다른 Vercel 라이브러리를 많이 쓸 때
TanStack Query를 선택해야 할 때
- ✅ 복잡한 데이터 페칭: mutation, infinite query, pagination을 많이 사용
- ✅ 대규모 프로젝트: 수십 개 이상의 API 엔드포인트를 관리할 때
- ✅ 고급 캐싱: 복잡한 캐싱 전략이 필요한 경우
- ✅ DevTools가 필요할 때: 디버깅과 상태 추적이 중요한 프로젝트
- ✅ React Suspense: 최신 React 기능을 적극 활용하고 싶을 때
- ✅ 멀티 프레임워크: Vue, Svelte 등으로도 확장할 가능성이 있을 때 (TanStack Query는 프레임워크 중립적)
의사결정 기준
간단하게 생각해보자.
내 선택
솔직하게 얘기하자면, 나는 TanStack Query를 메인으로 쓴다.
10년차 풀스택 개발자로서 여러 프로젝트를 해보닋, 초기에는 SWR의 간단함이 좋아 보인다. 하지만 프로젝트가 성장하면서 복잡한 mutation, 캐시 무효화, 동시성 요청 처리 같은 것들이 필요해진다. 그때 TanStack Query의 진가가 드러난다.
특히 DevTools가 정말 유용하다. 디버깅 시간을 크게 단축할 수 있고, 팀원들과 데이터 흐름을 공유할 때도 좋다. TypeScript 지원도 v5에서 정말 좋아져서, 타입 안정성이 높다.
다만 가볼운 사이드 프로젝트에선 SWR도 좋다. 번들 크기 제약이 있거나, 정말 간단한 CRUD만 필요하면 SWR의 단순함이 최고다. Next.js로 블로그나 마케테 사이트를 만들 때도 SWR이 충분한다.
결국 상황에 맞는 선택이 정답이다. 프로젝트의 복잡도와 팀의 선호도를 고려해서 고르면 된다.
관련 글
- ESLint vs Biome 비교 2026: JavaScript 코드 품질 도구
- Vitest vs Jest 비교 2026: JavaScript 테스트 프레임워크
- Bun vs Node.js 비교 2026: JavaScript 런타임
이 글은 2026년 4월 기준으로 작성되었습니다. React 에코시스템의 발전 속도가 빠르므로, 나중에 읽蝄 때는 최신 버전을 확인해주세요.
댓글
댓글 쓰기