데이터 패칭 TanStack Query 및 SWR편집자 확인

TanStack Query는 선언적 쿼리를 사용하여 데이터를 패칭한다. 개발자는 useQuery 훅에 고유한 쿼리 키와 데이터를 가져오는 비동기 함수(페치 함수)를 제공한다. 라이브러리는 이 키를 기반으로 데이터를 자동으로 캐싱하고, 컴포넌트가 마운트되거나 윈도우가 다시 포커스될 때 등 다양한 조건에서 데이터를 자동으로 다시 가져온다([2]). 또한 뮤테이션 후 관련 쿼리를 무효화하여 데이터를 최신 상태로 유지하는 전략을 제공한다.

반면 SWR은 "스태일-와일-리밸리데이트" 전략을 핵심 메커니즘으로 삼는다. 이는 캐시에 있는 데이터(스태일 데이터)를 먼저 반환한 후, 백그라운드에서 재검증 요청을 보내고, 최신 데이터로 교체하는 방식이다. useSWR 훅은 첫 번째 인자로 고유한 키(일반적으로 URL 문자열)를 받으며, 데이터 패칭 로직은 기본적으로 내장된 페처를 사용하거나 사용자가 직접 제공할 수 있다. SWR은 또한 포커스나 네트워크 재연결 시 자동 재검증을 기본으로 지원한다.

두 라이브러리의 주요 차이점은 초기 데이터가 없을 때의 동작과 패칭 트리거에 있다. TanStack Query는 쿼리가 특정 상태(로딩, 성공, 에러)를 명확히 가지며, 초기 데이터가 없으면 로딩 상태를 유지한다. SWR은 스태일 데이터가 없으면 즉시 데이터 패칭을 시도하지만, 동시에 null이나 undefined 데이터를 반환할 수 있어 개발자가 이를 처리해야 한다. 다음 표는 두 방식을 간략히 비교한다.

결론적으로, TanStack Query는 상태 머신에 가까운 체계적인 데이터 패칭 라이프사이클을 제공하는 반면, SWR은 캐시 우선의 빠른 사용자 경험에 초점을 맞춘 즉각적인 데이터 반환 메커니즘을 강조한다.

두 라이브러리는 모두 클라이언트 사이드 캐싱을 통해 불필요한 네트워크 요청을 줄이고 사용자 경험을 향상시키지만, 그 접근 방식에는 차이가 있습니다.

TanStack Query는 구조화된 캐시 키 시스템을 기반으로 합니다. 각 쿼리는 고유한 키로 식별되며, 이 키는 캐시에서 데이터를 저장하고 검색하는 데 사용됩니다. 기본적으로 가져온 데이터는 메모리에 보관되며, 특정 시간(기본값 5분)이 지나면 '만료(stale)' 상태로 표시됩니다. 만료된 데이터는 화면에 즉시 표시되지만, 백그라운드에서 자동으로 재검증(refetch)이 트리거됩니다. 캐시된 데이터의 수명은 cacheTime 옵션으로 제어할 수 있으며, 이 기간 동안은 비활성 쿼리 데이터도 메모리에 유지되어 빠른 재접속 시 사용할 수 있습니다. 또한, 뮤테이션이 성공적으로 완료되면 관련 쿼리의 데이터를 자동으로 무효화하여 최신 데이터를 다시 가져오도록 할 수 있습니다.

반면, SWR은 이름에서 유래한 스태일-와일-리밸리데이트 전략을 핵심 철학으로 삼습니다. 이는 데이터를 일단 캐시에서 즉시 보여준 후(Stale), 백그라운드에서 재검증 요청(Revalidate)을 보내 최신 상태로 갱신하는 방식입니다. 캐시 키는 일반적으로 문자열이지만, 함수나 배열도 사용할 수 있습니다. 재검증 동작은 매우 세밀하게 제어할 수 있으며, 포커스 복귀 시, 네트워크 재연결 시, 정기적인 간격으로 등의 조건에 따라 자동으로 트리거됩니다. SWR은 또한 로컬 뮤테이션을 통해 서버에 요청을 보내기 전에 캐시 데이터를 낙관적으로 업데이트하여 반응성을 높이는 기능을 제공합니다.

TanStack Query와 SWR은 모두 비동기 데이터 패칭 과정에서 발생할 수 있는 에러를 구조적으로 처리할 수 있는 기능을 제공한다. 두 라이브러리 모두 쿼리의 상태(isError, error)를 반환하여 컴포넌트 레벨에서 에러 상황을 쉽게 감지하고 UI에 반영할 수 있게 한다. 또한 전역적인 에러 콜백을 설정하는 방법을 지원하여, 중앙에서 일관된 에러 처리 로직(예: 에러 모달 표시, 로깅)을 적용할 수 있다.

구체적인 접근 방식에는 차이가 존재한다. TanStack Query는 useQuery와 useMutation 훅의 onError 콜백 옵션을 통해 개별 쿼리나 뮤테이션 수준에서 에러를 처리할 수 있다. 더 나아가, QueryClient를 생성할 때 defaultOptions를 설정하거나 QueryCache와 MutationCache에 전역 에러 리스너를 부착하여 애플리케이션 전체의 에러를 한 곳에서 관리하는 체계를 갖추고 있다. 반면 SWR은 useSWR 훅의 onError 옵션으로 개별 요청의 에러를 처리하며, <SWRConfig>의 공급자(provider)를 통해 전역 설정을 공유할 수 있다.

에러 발생 후의 재시도(retry) 정책도 중요한 부분이다. 두 라이브러리 모두 기본적인 재시도 로직을 내장하고 있으며, 재시도 횟수, 재시도 간 지연 시간, 특정 에러 타입에 따른 재시도 여부 등을 세밀하게 구성할 수 있다. TanStack Query의 경우 네트워크 장애 시 지수 백오프(exponential backoff) 전략을 기본적으로 적용하는 반면, SWR은 보다 단순한 간격으로 재시도한다[3]. 개발자는 이러한 재시도 동작을 필요에 맞게 조정하거나 완전히 비활성화할 수 있다.

TanStack Query에서 쿼리는 서버로부터 데이터를 가져오는(fetch) 모든 비동기 작업을 의미합니다. 주로 GET 요청에 해당하며, 데이터를 읽는 데 사용됩니다. 쿼리는 고유한 키(일반적으로 문자열 또는 배열)로 식별되며, 이 키는 캐싱과 리밸리데이션의 기준이 됩니다. useQuery 훅을 사용하여 쿼리를 정의하고, 로딩 상태, 에러 상태, 성공적으로 가져온 데이터에 접근할 수 있습니다. 쿼리는 자동으로 캐시에 저장되며, 동일한 키를 가진 후속 요청은 캐시된 데이터를 우선적으로 반환합니다.

반면에 뮤테이션은 서버의 데이터를 생성, 수정, 삭제하는 작업을 의미합니다. 주로 POST, PUT, PATCH, DELETE 요청에 해당합니다. useMutation 훅을 사용하여 정의하며, 쿼리와 달리 고유 키가 필수는 아닙니다. 뮤테이션은 실행 함수(mutate)를 반환하며, 이 함수를 호출해야 실제 요청이 시작됩니다. 뮤테이션의 주요 특징은 관련된 쿼리의 무효화와 자동 리페칭을 쉽게 트리거할 수 있다는 점입니다. 예를 들어, 게시글을 생성하는 뮤테이션이 성공한 후, 게시글 목록을 보여주는 쿼리를 무효화하면 목록이 자동으로 최신 상태로 갱신됩니다.

쿼리와 뮤테이션의 상태 및 사이드 이펙트 관리 방식은 다음과 같이 비교할 수 있습니다.

이러한 분리는 관심사 분리 원칙을 따르며, 애플리케이션의 데이터 흐름을 선언적이고 예측 가능하게 만듭니다. 개발자는 데이터를 어떻게 가져올지(쿼리)와 어떻게 변경할지(뮤테이션)를 명확히 정의하고, 라이브러리가 캐시 일관성과 UI 상태 동기화를 관리하도록 위임할 수 있습니다.

TanStack Query의 인피니트 쿼리는 페이지네이션 또는 무한 스크롤을 구현할 때 사용하는 특수한 쿼리 타입이다. 기존의 쿼리가 단일 데이터 세트를 가져오는 데 중점을 둔다면, 인피니트 쿼리는 사용자가 스크롤하거나 '더 보기' 버튼을 클릭할 때 추가 페이지의 데이터를 연속적으로 가져오는 데 최적화되어 있다. useInfiniteQuery 훅을 통해 구현되며, 각 페이지의 데이터를 배열로 관리하고, 다음 페이지를 요청할 수 있는 함수를 제공한다.

인피니트 쿼리의 핵심은 getNextPageParam과 fetchNextPage 함수에 있다. getNextPageParam 함수는 마지막으로 가져온 페이지의 데이터를 분석하여 다음 페이지를 요청하는 데 필요한 파라미터(예: 페이지 번호, 커서)를 반환한다. 개발자는 이 함수를 정의하여 API의 페이지네이션 로직에 맞춰야 한다. 사용자가 다음 데이터를 요청하면, fetchNextPage 함수가 호출되어 getNextPageParam에서 반환된 파라미터로 새로운 요청을 수행한다. 가져온 데이터는 data.pages 배열에 누적되어 저장된다.

이 기능은 성능과 사용자 경험을 크게 향상시킨다. 필요한 시점에만 데이터를 지연 로딩하여 초기 로딩 시간을 단축하고, 불필요한 네트워크 요청을 줄인다. 또한, 가져온 모든 페이지 데이터를 자동으로 캐싱하고 통합하여 관리하므로, 캐시 무효화나 데이터 재동기화 시 일관성을 유지하기 쉽다. 다음은 인피니트 쿼리의 기본적인 사용 패턴을 보여주는 코드 구조이다.

```javascript

const {

data,

fetchNextPage,

hasNextPage,

isFetchingNextPage,

} = useInfiniteQuery({

queryKey: ['projects'],

queryFn: ({ pageParam = 1 }) => fetchProjects(pageParam),

getNextPageParam: (lastPage, allPages) => lastPage.nextCursor,

});

```

위 예시에서 hasNextPage는 getNextPageParam이 undefined를 반환하지 않는 한 true를 유지하며, isFetchingNextPage는 다음 페이지를 가져오는 중인지 여부를 나타낸다. 이를 통해 UI에서 로딩 상태를 표시하거나, 더 이상 로드할 데이터가 없을 때 '더 보기' 버튼을 비활성화하는 등의 로직을 구현할 수 있다.

TanStack Query의 프리페칭 기능은 사용자가 특정 데이터를 필요로 하기 전에 미리 해당 데이터를 가져와 캐시에 저장하는 전략이다. 이는 사용자 경험을 크게 향상시키는 데 목적이 있다. 예를 들어, 사용자가 목록에서 특정 항목을 클릭하여 상세 페이지로 이동할 가능성이 높을 때, 해당 상세 데이터를 미리 불러오면 페이지 전환 시 로딩 지연 없이 즉시 데이터를 표시할 수 있다.

프리페칭은 주로 prefetchQuery 또는 prefetchInfiniteQuery 메서드를 통해 실행된다. 이 메서드들은 쿼리 키와 패칭 함수를 인자로 받아 데이터를 가져온 후 캐시에 저장한다. 프리페칭된 데이터는 이후 동일한 쿼리 키로 데이터를 요청하는 컴포넌트에서 즉시 사용 가능하다. 데이터의 신선도는 해당 쿼리에 설정된 staleTime에 따라 관리된다.

프리페칭을 구현하는 일반적인 접근법은 다음과 같다.

이러한 프리페칭은 데이터 접근성을 예측할 수 있는 상황에서 매우 효과적이다. 그러나 과도하게 사용하면 불필요한 네트워크 요청을 초래하여 서버에 부하를 줄 수 있다. 따라서 사용자의 실제 행동 패턴을 분석하여 프리페칭을 적용할 데이터와 시기를 신중하게 결정하는 것이 중요하다.

SWR의 핵심 철학은 스태일-와일-리밸리데이트(Stale-While-Revalidate) 전략에 기반한다. 이는 캐시된 데이터(스태일 데이터)가 최신 상태가 아니더라도(Stale) 즉시 사용자에게 보여주고, 백그라운드에서 새로운 데이터를 가져와(Revalidate) 캐시를 갱신하는 접근 방식이다. 이를 통해 사용자는 데이터를 기다리는 지연 시간 없이 빠르게 화면을 볼 수 있으며, 이후에 자동으로 최신 데이터로 업데이트된다.

구현 메커니즘은 다음과 같다. 컴포넌트가 마운트되거나 포커스를 다시 얻을 때, SWR은 먼저 캐시에서 해당 키의 데이터를 반환한다. 동시에 백그라운드에서 패칭 요청을 시작하여 서버에 최신 데이터를 요청한다. 요청이 완료되면 캐시가 갱신되고, 컴포넌트는 새로운 데이터로 다시 렌더링된다. 이 과정은 revalidateOnMount, revalidateOnFocus, revalidateOnReconnect 같은 옵션을 통해 세밀하게 제어할 수 있다.

이 전략의 주요 장점은 사용자 경험의 극대화에 있다. 애플리케이션은 느린 네트워크 상황에서도 캐시 덕분에 즉시 반응하며, 서버 부하를 줄이는 데도 기여한다. 불필요한 로딩 상태를 최소화하면서도 데이터의 최신성을 유지할 수 있는 효율적인 절충안을 제공한다.

의존성 쿼리는 SWR에서 제공하는 기능으로, 특정 쿼리의 실행이 다른 쿼리의 데이터 결과에 의존하도록 설정하는 것을 말한다. 이를 통해 비동기 데이터 패칭의 순차적 흐름이나 조건부 실행을 쉽게 구현할 수 있다.

의존성 쿼리는 useSWR 훅의 key 매개변수를 함수 형태로 전달하거나, enabled 옵션을 사용하여 구성한다. 예를 들어, 사용자 프로필을 먼저 패칭한 후, 해당 프로필의 ID를 사용하여 추가적인 데이터(예: 주문 내역)를 패칭해야 하는 경우에 유용하다. 첫 번째 쿼리의 데이터가 성공적으로 로드되지 않으면, 두 번째 쿼리는 자동으로 실행되지 않거나 null 키를 가진 상태로 대기한다.

이 접근 방식은 여러 쿼리 간의 명확한 의존 관계를 선언적으로 표현함으로써 코드의 가독성을 높이고, 불필요한 네트워크 요청을 방지한다. 또한 React의 컴포넌트 상태를 사용하여 복잡한 조건부 로직을 관리할 필요가 줄어든다. SWR의 스태일-와일-리밸리데이트 전략과 결합되면, 의존성 데이터가 변경될 때 자동으로 연쇄적인 재검증이 이루어져 데이터의 일관성을 유지하는 데 도움이 된다.

SWR의 로컬 뮤테이션은 서버에 실제 요청을 보내기 전에, 낙관적 업데이트를 통해 클라이언트의 캐시 데이터를 즉시 변경하는 기능이다. 사용자 경험을 향상시키기 위해, 데이터 변경 요청에 대한 서버 응답을 기다리지 않고 UI를 먼저 업데이트한다. 이는 mutate 함수를 사용하여 수행되며, 첫 번째 인자로 새로운 데이터를, 두 번째 인자로 낙관적 업데이트 여부를 나타내는 optimisticData 옵션을 전달할 수 있다.

로컬 뮤테이션의 동작 흐름은 다음과 같다. 먼저, mutate 함수가 호출되면 optimisticData로 지정된 값으로 관련 쿼리의 캐시가 즉시 갱신되고 컴포넌트가 리렌더링된다. 동시에, 백그라운드에서 실제 서버에 데이터 변경 요청(예: POST 또는 PUT 요청)이 전송된다. 서버 요청이 성공하면, 서버에서 반환된 실제 데이터로 캐시를 재검증하여 최종적으로 일치시킨다. 만약 요청이 실패하면, 자동으로 이전의 올바른 캐시 데이터로 롤백된다.

이 기능을 효과적으로 사용하기 위한 주요 옵션은 아래와 같다.

로컬 뮤테이션은 댓글 작성, 좋아요 토글, 폼 제출과 같이 사용자 인터랙션이 빈번한 UI에서 반응성을 극대화하는 데 유용하다. 그러나 서버 상태와 클라이언트 상태가 일시적으로 불일치할 수 있으므로, 에러 발생 시 사용자에게 적절한 피드백을 제공하는 것이 중요하다.

두 라이브러리는 불필요한 리렌더링을 줄이고 UI 반응성을 높이기 위해 다양한 렌더링 최적화 전략을 제공한다.

TanStack Query는 쿼리 키를 기반으로 한 세밀한 구독 모델을 사용한다. 컴포넌트는 정확히 자신이 의존하는 쿼리 데이터의 변화에만 반응하여 리렌더링된다. 또한 기본적으로 구조적 공유를 통해 데이터의 참조 안정성을 유지하여, 실제 데이터 내용이 변경되지 않았을 경우 메모이제이션된 컴포넌트의 불필요한 리렌더링을 방지한다. 인피니트 쿼리나 페이지네이션을 사용할 때도 이전에 가져온 페이지 데이터는 안정적인 참조를 유지한다.

SWR은 스태일-와일-리밸리데이트 전략 덕분에 초기 로딩 상태 없이 즉시 캐시된 데이터를 렌더링할 수 있어 사용자 경험을 향상시킨다. useSWR 훅은 동일한 키를 가진 여러 요청을 자동으로 중복 제거하고 하나의 네트워크 요청으로 처리하며, 그 결과를 모든 구독 컴포넌트에 공유한다. 로컬 뮤테이션을 통해 낙관적 업데이트를 수행하면, 서버 응답을 기다리지 않고도 UI를 즉시 업데이트하여 반응성을 높인다.

두 라이브러리는 불필요한 네트워크 요청을 줄여 애플리케이션 성능을 향상시키는 전략을 제공합니다. TanStack Query는 쿼리 키를 기반으로 한 중앙 집중식 캐시 관리와 스마트 리페칭 정책을 통해, 동일한 데이터에 대한 중복 요청을 자동으로 통합하고 캐시된 데이터를 우선적으로 제공합니다. 또한 프리페칭 기능을 통해 사용자가 필요로 할 데이터를 미리 불러와 캐시에 저장함으로써, 실제 데이터 요청 시 네트워크 호출을 생략할 수 있습니다.

SWR은 이름의 유래가 된 스태일-와일-리밸리데이트 전략을 핵심으로 합니다. 이 전략은 캐시된 데이터(스태일 데이터)를 즉시 반환한 후, 백그라운드에서 재검증(리밸리데이트) 요청을 보내 네트워크 사용을 최적화합니다. 또한 포커스 리밸리데이트나 인터벌 리밸리데이트와 같은 옵션을 통해 데이터 새로고침 주기를 세밀하게 제어할 수 있어, 과도한 폴링을 방지합니다.

두 도구 모두 다음과 같은 공통적인 방법으로 네트워크 요청을 최소화합니다.

이러한 메커니즘은 특히 데이터 변경 빈도가 낮거나, 동일한 데이터를 여러 컴포넌트에서 요구하는 복잡한 애플리케이션에서 네트워크 트래픽과 서버 부하를 현저히 줄여줍니다.

TanStack Query는 복잡한 서버 상태 관리가 필요한 대규모 애플리케이션에 특히 적합하다. 서버 데이터의 캐싱, 동기화, 업데이트를 포괄적으로 관리해야 하는 경우 강력한 이점을 발휘한다. 뮤테이션 API가 풍부하여 데이터 생성, 수정, 삭제 후의 캐시 무효화 및 자동 재요청 전략을 세밀하게 구성할 수 있다. 이는 대시보드, 관리자 패널, 실시간 데이터가 중요한 e-커머스 플랫폼과 같은 프로젝트에 유용하다.

다음과 같은 구체적인 요구사항이 있을 때 TanStack Query를 선택하는 것이 바람직하다.

또한, TypeScript와의 통합이 뛰어나고, 공식 문서와 커뮤니티가 매우 활성화되어 있어 문제 해결과 학습에 용이하다. React 외에도 Solid.js, Svelte, Vue와 같은 다른 프레임워크를 공식적으로 지원하므로, 기술 스택이 다양하거나 변경될 가능성이 있는 프로젝트에도 적합하다.

SWR은 비교적 단순한 데이터 패칭 요구사항, 빠른 프로토타이핑, 그리고 Next.js 애플리케이션과의 긴밀한 통합이 필요한 경우에 특히 적합하다. 기본 제공되는 스태일-와일-리밸리데이트 전략 덕분에 사용자 경험을 저해하지 않으면서도 데이터를 자동으로 최신 상태로 유지하는 것이 핵심 목표일 때 강점을 발휘한다.

애플리케이션의 데이터 구조가 복잡하지 않고, CRUD 연산 중 'Read'(조회)에 더 중점을 두며, 실시간성이 크게 요구되지 않는 프로젝트에 잘 어울린다. 예를 들어, 블로그 포스트 목록, 사용자 프로필 정보, 설정 데이터 등을 패칭하는 경우가 이에 해당한다. 또한, 로컬 뮤테이션 기능을 통해 서버 응답을 기다리지 않고도 UI를 즉시 낙관적으로 업데이트할 수 있어 사용자에게 빠른 반응성을 제공할 수 있다.

TanStack Query에 비해 번들 크기가 상대적으로 작은 점도 고려할 만한 장점이다. 따라서, 복잡한 서버 상태 관리보다는 클라이언트 사이드에서의 효율적인 데이터 캐싱과 HTTP 요청 최적화에 초점을 맞추고자 하는 팀에게 좋은 선택지가 될 수 있다.