장점만 외워 왔는지, 아니면 캐시 키 설계와 클라이언트 상태 라이브러리와의 경계까지 같이 고민해 봤는지를 가른다.
TanStack Query는 서버 상태를 가져오고 동기화하는 반복 로직(로딩·에러·재시도·캐시·무효화)을 한 곳에서 다루게 해 주는 라이브러리다. 동일 쿼리 중복 요청 제거, staleTime 기반 재요청 제어, 백그라운드 refetch, mutation 이후 invalidate 같은 패턴을 일관된 규칙으로 운영할 수 있어 화면 수가 늘어도 유지보수성이 흔들리지 않는다. 단 쿼리 키 설계가 엉성하면 캐시 충돌이나 stale 데이터 버그가 따라 붙는다. 핵심 가치는 "코드량 감소"보다 "서버 상태 일관성을 한 규칙으로 정렬한다"는 쪽이다.
useEffect 기반 fetch 로직을 TanStack Query로 옮기며 중복 요청과 staleness 버그가 줄어든 경험이 있다면 도입 이유의 근거로 풀어낼 수 있다
쿼리 키 설계 실수로 캐시가 꼬여 본 경험이 있다면 "key가 곧 캐시 식별자"라는 원칙으로 일반화할 수 있다
mutation 이후 invalidate 전략을 팀에서 합의해 본 경험이 있다면 서버 상태 일관성 관리 이야기로 자연스럽게 이어갈 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.