📚 목차

1. React 상태관리, 왜 다시 이야기하는가
2. Zustand 선택과 오해
   • Zustand의 특징
   • SSR 오해와 진짜 문제
3. Recoil로 전환한 이유
   • Provider 기반 관리
   • 그러나 Next.js 14/15 대응 문제
4. Jotai로 다시 갈아탄 이유
   • Jotai의 설계 철학
   • Context API 대신 Jotai를 쓴 이유
5. Jotai 사용 시 발생한 주요 이슈
   • 글로벌 상태 공유 문제 (이슈 #404)
   • SSR 환경에서 상태 분리 필요
6. Jotai + React Query 통합 운영 중 겪은 이슈
   • 아톰 초기화 문제
   • 전역 아톰과 라우팅 간 데이터 공유
7. Optimistic Update 전략
   • invalidateQuery 필요/불필요 구분
   • useInfiniteQuery 대신 useQuery를 추천하는 이유
   • Optimistic Update 시 주의점 (cancelQueries, setQueryData, fresh data)
8. 마무리: 상태관리 선택 기준에 대한 인사이트

Chapter 1. 리액트 상태관리란 무엇인가?

1.1 상태(State)의 역할

리액트에서 상태(State)란 컴포넌트가 렌더링하는 UI를 결정하는 데이터다.

상태는 컴포넌트 내부에서 바뀔 수 있으며, 변경될 때마다 리액트는 자동으로 UI를 다시 렌더링해준다.

간단히 말하면, 상태 = UI를 바꾸게 만드는 데이터다.

초기에는 버튼 클릭에 따라 텍스트가 바뀌는 정도처럼 컴포넌트 내부 상태만 관리하면 충분했다.

1.2 왜 상태관리가 필요해졌는가?

하지만 애플리케이션이 복잡해지면서 상황이 바뀌었다.

• 여러 컴포넌트가 같은 상태를 공유해야 하고