TanStack Query를 쓰는 이유: 서버 상태를 캐시하고 갱신하는 실전 기준 빠른 답 TanStack Query는 서버 응답을 전역 상태처럼 보관하는 도구가 아니라, 서버 데이터의 조회, 캐싱, 갱신 흐름을 관리하는 도구입니다. 같은 데이터를 여러 컴포넌트가 읽을 때 중복 요청을 줄이고, 로딩과 에러, 재요청 상태를 일관된 방식으로 다룰 수 있습니다. staleTime , gcTime , queryKey 설계가 맞지 않으면 최신성 문제나 불필요한 네트워크 요청이 생길 수 있습니다. 입력값, 모달 열림 여부, 작성 중인 폼 값처럼 브라우저가 원본인 상태는 useState , Zustand, Redux 같은 클라이언트 상태와 분리해서 다루는 편이 좋습니다. 목차 시간 흐름으로 이해하기 흐름으로 보기 서버 상태는 일반 상태와 다르다 현재 기준 용어와 버전 차이 QueryClient에서 기본 정책 잡기 queryKey로 데이터 소유권 나누기 mutation 후 캐시 갱신하기 리렌더링 관점에서 보는 장점 흔한 안티패턴 언제 쓰고 언제 분리할까 더 읽을 공식 문서 시간 흐름으로 이해하기 컴포넌트 마운트 useQuery 를 호출한 컴포넌트가 특정 쿼리를 구독합니다. → 캐시 조회 TanStack Query가 queryKey 로 기존 캐시를 찾습니다. → 데이터 반환 캐시가 있으면 화면은 먼저 기존 데이터를 사용할 수 있습니다. → 신선도 판단 staleTime 이 지났거나 무효화된 데이터인지 확인합니다. → 백그라운드 갱신 stale 상태라면 조건에 따라 다시 요청하고 캐시를 갱신합니다. 흐름으로 보기 흐름 다이어그램 이 흐름에서 컴포넌트는 서버 데이터를 직접 소유하지 않습니다. 서버 데이터의 원본은 서버에 있고, TanStack Query는 브라우저 안의 캐시와 갱신 정책을 관리합니다. 컴포넌트는 캐시를 구독하고, 필요한 시점에 다시 가져오거나 무효화하도록 요청합니다. 이 차이를 이해하면 TanStack Query를 “또 하나의 전역 상태 ...