상태관리 [2편] - Redux vs Zustand 비교 – 왜 생겼고 언제 쓰는가?

📊 Redux vs Zustand 비교 요약

항목	Redux	Zustand
등장 시기	2015년 (Flux 기반)	2020년 (간단한 상태 관리 목적)
철학	Flux 아키텍처 기반의 단방향 흐름	Flux와 무관, 간단한 API
사용 목적	예측 가능하고 구조화된 상태 관리	가볍고 빠른 상태 공유
코드 구조	Action → Reducer → Store → State	set()으로 직접 상태 변경
보일러플레이트	많음	거의 없음
미들웨어	redux-thunk, redux-saga 등 별도 구성	내장 미들웨어로 간단 설정 가능
DevTool	Redux 공식 DevTool 지원	내장 DevTool 제공 (기능 제한적)
상태 구독	useSelector, connect 등	Hook 기반
리렌더링 제어	최적화 필요	선택적 구독으로 간단
TypeScript 지원	복잡한 타입 설계 필요	타입 지원 우수, 심플함
상태 영속성	redux-persist 등 외부 도구 필요	persist 미들웨어로 간단 지원

🧠 Redux는 왜 만들어졌을까?

• Facebook의 Flux 아키텍처에서 영감을 받아 등장
• 상태는 오직 Action을 통해서만 바뀜
• 상태 변화 추적 및 시간 여행 디버깅 가능

📌 사용 예시: UI 상태, 도메인 상태, API 상태가 복잡하게 얽힌 대형 프로젝트

🌱 Zustand는 왜 생겼을까?

• “작고 단순한 상태 관리”를 위해 등장
• create 함수 하나로 store 생성
• set, get, subscribe로 상태 조작
• Flux 구조 없이 사용 가능

📌 사용 예시: 중소형 프로젝트, 간단한 앱, 빠른 프로토타입

🔍 언제 무엇을 써야 할까?

상황	추천 도구	이유
대규모 프로젝트	Redux	구조 명확, 디버깅 강력
중소형, 빠른 개발	Zustand	보일러플레이트 없음
서버 상태 연동 필요	Redux + RTK Query	서버와 상태 동기화 용이
간단한 상태 관리	Zustand	Hook 기반으로 빠르게 구현
TypeScript 기반	Zustand	타입 설계가 간결