상태관리 [4편]: Tanstack-Query, 왜 프론트엔드에서 상태를 나눠 관리해야 할까?

🤔 왜 상태 관리가 이렇게 복잡할까?

프론트엔드 개발을 하다 보면 “이 상태는 어디에 저장해야 하지?” 하는 고민이 생깁니다.
로그인 정보, 모달 열림 여부, API 응답값까지…
이 모든 걸 하나의 상태로 묶어도 될까요?

 

1. API에서 받아온 정보가 곧 클라이언트 상태 아닌가?

처음엔 이렇게 생각할 수 있어요. “서버에서 데이터를 받아오면 그게 바로 상태지!”
하지만 실제로는 두 가지 상태로 나눠서 관리하는 게 더 명확합니다.

구분	서버 상태 (Server State)	클라이언트 상태 (Client State)
정의	서버에서 가져온 데이터	브라우저 내부 UI 상태
소유자	서버가 원본 (Source of Truth)	프론트엔드 앱
예시	게시물 목록, 유저 정보	모달 열림 여부, 현재 페이지, 입력값
동기화 필요	예 (서버와 일치해야 함)	아니오 (앱에서만 사용)

 

2. 왜 굳이 이렇게 나눠야 할까?

• 서버 상태는 비동기이고 예측이 어려움
• 클라이언트 상태는 내가 직접 제어 가능
• 동기화 책임이 다름 (API 요청 vs UI 이벤트)
• 테스트와 유지보수가 쉬워짐

// 구분해서 관리하면 깔끔함
const { data: user } = useQuery(['user'], fetchUser); // 서버 상태
const [isEditing, setIsEditing] = useState(false);    // 클라이언트 상태

 

3. 매번 API로 가져오면 안 되나?

단순히 생각하면, 페이지마다 서버에서 요청하면 되는 거 아닌가? 싶지만, 문제가 많습니다.

문제	설명
속도 저하	항상 새 요청 = 느린 UX
서버 부하	같은 데이터 반복 요청 → 트래픽 증가
불필요한 요청	페이지를 왔다 갔다 할 때마다 새로 요청
오프라인 미지원	네트워크 순간 오류 시 아무것도 못 보여줌

 

4. 서버에서 캐싱하면 되지 않나?

물론 서버도 캐싱을 합니다. CDN, Redis 등을 통해 빠르게 응답하죠.
하지만 프론트엔드에 필요한 캐싱은 조금 다릅니다.

• 서버 캐시는 모든 사용자 공통 – 사용자 맞춤 데이터엔 한계 있음
• 사용자 브라우저에 저장해야 오프라인 대응 가능
• UI 패턴에 따라 유연하게 리패치 제어해야 함

즉, 프론트엔드는 사용자 경험 최적화를 위해 자체 캐싱 전략이 필요합니다.

 

5. 그래서 나온 도구 - Tanstack Query

이런 문제를 해결하기 위해 사용하는 대표적인 도구가 Tanstack Query입니다.

• 자동 캐싱
• stale-while-revalidate 패턴 지원
• 에러, 로딩 상태 자동 관리

const { data: user } = useQuery(['user'], fetchUser);

Tanstack Query의 캐싱 기준

옵션	설명
Query Key	캐시를 식별하는 고유 이름
staleTime	데이터를 “신선”하다고 간주할 시간
cacheTime	언마운트 후 캐시 유지 시간
refetchOnWindowFocus	창 다시 열 때 자동 리패치
enabled	조건부로 쿼리 실행 제어

 

6. Tanstack Query는 어디에 데이터를 저장할까?

모든 데이터는 QueryClient라는 객체 안에 저장됩니다.

const queryClient = new QueryClient();


  

각 사용자의 브라우저 메모리에 캐시가 저장되며, 같은 쿼리 키가 들어오면 기존 데이터를 재사용합니다.

 

✅ 요약

• API로 받아온 데이터와 UI 상태는 성격이 다르다 → 분리 필요
• 매번 API 요청하면 UX, 성능, 서버 부하 측면에서 비효율
• 서버 캐시로는 사용자 개인화 대응이 어려움
• 프론트엔드 캐싱은 사용자 경험 향상, 오프라인 대응 등에 필수
• 이를 위해 Tanstack Query 같은 도구를 활용하자!