React 상태 관리 비교 2026 — Zustand vs Jotai vs Redux Toolkit vs Valtio
React 상태 관리 라이브러리 4종의 번들 크기, API 설계 철학, 보일러플레이트, SSR 지원을 비교한다. Zustand의 단일 스토어 패턴, Jotai의 아토믹 조합, Redux Toolkit이 여전히 유효한 경우, 프로젝트 규모별 선택 기준과 서버/클라이언트 상태 분리 전략을 코드 예시와 함께 정리한다.
React 상태 관리 라이브러리는 Redux 독점 시대를 지나 Zustand, Jotai, Valtio, Recoil 등 경량 라이브러리가 주류가 됐다. 2026년 기준 npm 다운로드 수, 번들 크기, API 설계 철학, 실제 사용 패턴을 비교하고, 프로젝트 규모와 팀 상황별 선택 기준을 제시한다. Redux Toolkit이 여전히 유효한 경우와, 더 이상 Redux가 필요 없는 경우를 구분한다.
상태 관리가 복잡해지는 시점 — 언제 라이브러리가 필요한가
React의 기본 상태 관리(useState, useContext)로 충분한 경우가 많다. 상태 관리 라이브러리를 도입해야 하는 명확한 시그널은 다음과 같다:
Prop Drilling 3단계 이상: 부모 → 자식 → 손자 → 증손자로 props가 관통하면서 중간 컴포넌트가 불필요한 props를 전달만 하고 있다
Context 성능 문제: useContext를 쓰는 컴포넌트가 20개 이상이면, 하나의 상태 변경이 모든 구독 컴포넌트를 리렌더링한다
서버 상태와 클라이언트 상태 분리 필요: API 응답 캐싱과 UI 상태(모달 열림, 탭 선택 등)를 별도 레이어로 관리해야 할 때
복잡한 상태 전이: 여러 상태가 서로 의존하고, 특정 순서로 변경되어야 하는 비즈니스 로직
2026년 핵심 흐름: 서버 상태(API 데이터)는 TanStack Query(React Query)로, 클라이언트 상태(UI 상태)는 Zustand 또는 Jotai로 관리하는 조합이 사실상 표준이 됐다. Redux로 모든 상태를 관리하던 시대는 끝났다. 서버 상태와 클라이언트 상태를 분리하는 것이 첫 번째 설계 결정이다.
Zustand — 가장 실용적인 선택
Zustand는 번들 크기 1.1KB(gzip), 보일러플레이트 최소, React 외부에서도 사용 가능한 경량 상태 관리 라이브러리다. Jotai와 함께 pmndrs(Poimandres) 그룹이 관리하며, npm 주간 다운로드 700만 이상으로 Redux Toolkit을 추월했다(2026년 4월 기준).
Zustand의 핵심 특징:
단일 스토어, 슬라이스 패턴: 하나의 create()로 스토어를 만들고, 관심사별로 슬라이스를 분리
선택적 구독: 셀렉터 함수로 필요한 상태만 구독해서 불필요한 리렌더링 방지
미들웨어: persist(로컬스토리지), devtools(Redux DevTools 연동), immer(불변 업데이트) 내장
React 외부 사용: getState(), subscribe()로 프레임워크 외부에서 상태 접근 가능