Redux vs MobX vs Jotai vs Zustand 비교 (동작 방식 & 원리 차이점)

리액트(React)에서 상태 관리는 중요한 개념이며, 다양한 라이브러리가 존재합니다. 대표적인 상태 관리 라이브러리로 Redux, MobX, Jotai, Zustand가 있으며, 각각의 철학과 동작 방식이 다릅니다. 이번 글에서는 이 네 가지 라이브러리를 비교하여 어떤 프로젝트에 적합한지 살펴보겠습니다.

---

1. Redux - Flux 아키텍처 기반의 중앙 집중 상태 관리

🔹 원리

• Redux는 Flux 패턴을 기반으로 한 상태 관리 라이브러리입니다.
• 단일 전역 상태(store) 를 유지하고, 순수 함수인 리듀서(reducer) 를 통해 상태를 변경합니다.
• 상태 변경 시 불변성(Immutability) 을 유지해야 하며, 액션(action) → 리듀서(reducer) → 새로운 상태의 흐름을 따릅니다.
• React 컴포넌트는 useSelector를 통해 상태를 구독하고, dispatch(action)을 호출해 상태를 변경합니다.

🔹 동작 방식

1. UI에서 이벤트 발생 (dispatch(action)).
2. action이 리듀서에 전달됨.
3. 리듀서가 현재 state와 action을 기반으로 새로운 상태 반환.
4. 변경된 상태가 store에 저장됨.
5. useSelector를 통해 상태를 구독한 컴포넌트가 리렌더링됨.

✅ 장점

✔️ 예측 가능한 상태 관리 (불변성 유지).
✔️ 디버깅과 미들웨어 지원이 강력 (Redux DevTools, Redux-Thunk, Redux-Saga).
✔️ 대규모 전역 상태 관리에 적합.

❌ 단점

❌ 보일러플레이트 코드가 많아 코드가 장황해질 수 있음.
❌ 비동기 상태 관리를 위해 추가적인 미들웨어가 필요.
❌ 최신 React Context API 및 Hooks보다 사용이 복잡할 수 있음.

---

2. MobX - 관찰 가능한 상태 (Observable State)

🔹 원리

• MobX는 관찰자 패턴(Observer Pattern) 을 사용하여 상태를 자동으로 추적 및 업데이트 합니다.
• @observable 데코레이터를 사용해 상태를 만들고, @action을 사용해 상태를 변경하면, MobX가 자동으로 변경 사항을 감지하고 관련된 컴포넌트만 리렌더링 합니다.
• makeAutoObservable()을 사용하면 더욱 간단하게 상태를 선언할 수도 있습니다.

🔹 동작 방식

1. @observable 속성을 가진 상태가 변경됨.
2. 해당 상태를 참조하는 모든 반응형(reaction) 컴포넌트가 자동으로 업데이트됨.
3. 필요 없는 컴포넌트는 리렌더링되지 않음 (최적화됨).

✅ 장점

✔️ 자동 상태 추적 및 최적화 (불필요한 리렌더링 방지).
✔️ 코드가 간결하고 직관적 (Redux보다 보일러플레이트 코드가 적음).
✔️ Class 기반 또는 함수형 컴포넌트 모두 사용 가능.

❌ 단점

❌ 상태 변경이 자동으로 추적되므로 디버깅이 어려울 수 있음.
❌ 예상치 못한 리렌더링이 발생할 가능성이 있음.

---

3. Jotai - 최소 단위(atom) 기반의 상태 관리

🔹 원리

• Jotai는 Recoil과 유사한 Atomic State Model을 사용합니다.
• 개별적인 atom(상태 단위) 을 만들고, 컴포넌트가 해당 atom을 직접 구독합니다.
• 불필요한 리렌더링이 없음, 사용하는 atom만 변경될 때 관련된 컴포넌트만 리렌더링됩니다.

🔹 동작 방식

1. atom()을 생성하여 개별 상태를 정의.
2. useAtom()을 사용하여 해당 atom을 구독하고 값을 읽거나 변경.
3. atom이 변경되면 관련된 컴포넌트만 리렌더링됨 (최적화됨).

✅ 장점

✔️ React Hooks 기반의 단순한 API.
✔️ 부분적인 상태 관리 가능 (필요한 atom만 구독 가능).
✔️ 불필요한 렌더링 최소화.

❌ 단점

❌ Redux처럼 강력한 미들웨어 기능이 부족함.
❌ 전역 상태 관리보다는 로컬 상태 관리에 적합.

---

4. Zustand - 간단하고 빠른 전역 상태 관리

🔹 원리

• Zustand는 React Context API보다 빠르고, Redux보다 간결한 전역 상태 관리 라이브러리 입니다.
• Redux처럼 중앙 집중형 store 를 사용하지만, 리듀서가 필요 없고 불변성을 강제하지 않음.
• useStore() 훅을 사용하여 필요한 상태만 선택하여 구독할 수 있습니다.

🔹 동작 방식

1. create()를 사용해 상태를 생성 (store 생성).
2. useStore() 훅을 사용하여 상태를 읽거나 변경.
3. 필요한 상태만 선택하여 구독 가능 (부분적인 리렌더링 최적화).

✅ 장점

✔️ Redux보다 간결한 API (useStore 사용).
✔️ 불필요한 리렌더링 없음 (구독한 상태만 변경될 때 리렌더링).
✔️ 불변성을 강제하지 않음 → 더 유연한 상태 관리 가능.

❌ 단점

❌ Redux처럼 미들웨어 지원이 강력하지 않음.
❌ 대규모 프로젝트에서 Redux만큼 체계적인 구조를 갖추기 어려울 수 있음.

---

🔥 네 가지 라이브러리 비교 요약

ReduxMobXJotaiZustand

핵심 개념	Flux 패턴 기반, 액션 & 리듀서	관찰자 패턴, 반응형 상태	Atom 기반의 상태 관리	간단한 전역 상태 관리
상태 변경 방식	dispatch(action) -> reducer -> 새로운 상태	@observable 상태 변경 시 자동 감지	useAtom()을 통한 직접 변경	useStore()를 통한 직접 변경
리렌더링 최적화	useSelector를 통한 수동 최적화 필요	자동으로 최적화됨	자동으로 최적화됨	자동으로 최적화됨
보일러플레이트 코드	많음	적음	매우 적음	적음

---

✅ 결론: 언제 어떤 라이브러리를 써야 할까?

• Redux → 대규모 프로젝트에서 예측 가능한 상태 관리 필요.
• MobX → 반응형 상태 관리가 필요하고, 코드가 직관적이어야 할 때.
• Jotai → 작은 상태 관리가 필요하고, 불필요한 리렌더링을 줄이고 싶을 때.
• Zustand → Redux보다 가볍고 간단한 전역 상태 관리가 필요할 때.