React Query와 서버 상태 관리 정리

핵심 요약

• React Query는 서버에서 가져온 데이터를 클라이언트에서 효율적으로 다루기 위한 도구다.
• 핵심은 "서버 상태"와 "클라이언트 상태"를 구분해서 관리하는 데 있다.
• 캐싱, refetch, loading/error 상태, 중복 요청 제어를 직접 다 짜지 않아도 돼서 실무에서 많이 쓴다.
• 면접에서는 "Redux랑 뭐가 다르냐", "왜 필요한가", "staleTime과 cacheTime(gcTime)을 어떻게 이해하는가" 정도를 설명하면 좋다.

서버 상태가 뭐냐

프론트엔드에서 상태라고 해도 다 같은 상태가 아니다.

• input 값, 모달 열림 여부처럼 화면 안에서만 쓰는 값은 클라이언트 상태다.
• 사용자 목록, 상품 정보, 알림 개수처럼 서버에서 가져오고 다시 동기화해야 하는 값은 서버 상태다.

서버 상태는 내가 완전히 소유한 값이 아니라는 점이 중요하다.
시간이 지나면 바뀔 수 있고, 다른 사용자가 바꿨을 수도 있고, 다시 가져와야 최신 상태가 된다.

왜 별도 도구가 필요하냐

서버 상태를 useEffect + useState로도 다룰 수는 있다.
그런데 조금만 커져도 같은 문제가 반복된다.

• 로딩 상태 관리
• 에러 상태 관리
• 중복 요청 방지
• 새로고침 타이밍 제어
• 탭 전환 후 재조회
• 캐시 재사용

페이지가 늘어나면 같은 패턴을 계속 복붙하게 된다.
React Query는 이걸 공통 문제로 보고 도구로 풀어준다.

React Query의 핵심 개념

1. Query Key

데이터를 구분하는 식별자다.
예를 들어 ['todos'], ['post', postId] 같은 식으로 키를 잡는다.

이 키를 기준으로 캐시되고, 다시 가져오고, 무효화한다.

2. Query

조회 작업이다.
useQuery로 데이터를 가져오고, 로딩/에러/성공 상태를 함께 관리한다.

3. Mutation

생성, 수정, 삭제 같은 변경 작업이다.
useMutation으로 처리하고, 성공 후 관련 Query를 무효화해서 최신 데이터를 다시 가져오게 하는 패턴이 많다.

staleTime을 어떻게 이해하면 되나

staleTime은 "이 데이터가 얼마나 신선하다고 볼 것인가"에 가깝다.

• staleTime이 길면 같은 데이터를 다시 요청하지 않고 캐시를 더 믿는다.
• staleTime이 짧으면 더 자주 최신 데이터를 확인한다.

예를 들어 자주 안 바뀌는 공통 코드 테이블은 staleTime을 길게 둘 수 있고, 실시간성이 중요한 알림 개수는 짧게 두거나 별도 갱신 전략이 필요하다.

cacheTime(gcTime)은 뭐냐

이건 사용되지 않는 캐시를 메모리에 얼마나 남겨둘지에 대한 개념이다.

즉 staleTime은 "신선도", cacheTime(gcTime)은 "보관 기간"에 더 가깝다.
둘을 헷갈리지 않고 설명하면 면접에서 깔끔하다.

Redux랑 뭐가 다르냐

Redux 같은 전역 상태 관리 도구는 애플리케이션 전체에서 공유할 상태를 예측 가능하게 관리하는 데 강하다.
반면 React Query는 서버 상태를 가져오고, 캐시하고, 다시 동기화하는 문제를 푸는 데 특화돼 있다.

즉 경쟁 관계라기보다 역할이 다르다.

• UI 상태, 필터 상태, 폼 진행 상태: Redux/Zustand/Context 같은 도구가 더 어울릴 수 있다.
• API 조회 결과와 동기화: React Query가 더 잘 맞는다.

실무에서는 둘을 같이 쓰는 경우도 많다.

예시로 이해하기

상품 목록 페이지를 생각해 보면,

1. 진입 시 상품 목록을 조회한다.
2. 같은 페이지를 다시 열면 캐시된 데이터를 먼저 보여줄 수 있다.
3. 백그라운드에서 최신 데이터를 다시 가져올 수 있다.
4. 상품 수정 후 목록 Query를 무효화하면 최신 목록이 다시 반영된다.

이 흐름을 매번 손으로 짜지 않아도 된다는 게 큰 장점이다.

장점만 있는 건 아니다

1. 학습 없이 쓰면 캐시 전략이 꼬일 수 있다

키 설계가 어색하거나 무효화 범위를 잘못 잡으면 "왜 안 바뀌지?" 혹은 "왜 너무 자주 다시 부르지?" 같은 문제가 생긴다.

2. 모든 상태를 여기에 넣으면 오히려 복잡해진다

단순 UI 상태까지 Query로 다루면 모델이 흐려진다.
서버 상태와 클라이언트 상태를 구분하는 감각이 중요하다.

3. 낙관적 업데이트도 신중해야 한다

사용자 경험은 좋아지지만 실패 롤백까지 고려해야 해서 도메인에 따라 조심해서 써야 한다.

면접 답변 예시

React Query는 서버에서 가져온 데이터를 캐싱하고 동기화하는 데 특화된 라이브러리라고 이해하고 있습니다. 프론트엔드 상태 중에는 모달 열림 여부 같은 클라이언트 상태도 있지만, 사용자 목록이나 상품 정보처럼 서버와 계속 맞춰야 하는 서버 상태도 있는데요. 이런 값은 로딩, 에러, 중복 요청, 재조회 시점 같은 공통 문제가 반복되기 때문에 React Query를 쓰면 관리가 훨씬 단순해집니다. 특히 query key를 기준으로 캐시와 무효화를 관리하고, staleTime으로 신선도를 조절할 수 있다는 점이 핵심이라고 생각합니다.

장점

• 서버 상태 관리에 필요한 반복 코드를 크게 줄일 수 있다.
• 캐시 재사용, 재조회, 로딩/에러 처리를 일관되게 가져가기 좋다.
• 변경 작업 후 관련 데이터 동기화를 구조적으로 풀기 쉽다.

단점

• 캐시 키 설계와 무효화 전략을 잘못 잡으면 디버깅이 어렵다.
• 단순한 프로젝트에서는 오히려 개념이 과할 수 있다.
• 상태의 성격을 구분하지 못하면 전역 상태 관리와 책임이 섞일 수 있다.

주의사항 / 실무 팁

• useEffect로 직접 fetch하던 습관을 그대로 가져오지 말고 Query Key 중심으로 사고하는 게 중요하다.
• staleTime은 도메인마다 다르게 잡아야 한다. 자주 바뀌는 데이터와 거의 안 바뀌는 데이터가 같을 수 없다.
• 수정/삭제 후에는 어떤 Query를 invalidate할지 먼저 설계하는 편이 좋다.
• 면접에서는 "React Query를 써봤다"보다 "서버 상태가 왜 별도 관리 대상인지"를 먼저 설명하면 더 설득력 있다.