상태관리 [3편] - Zustand의 유연함이 대규모 프로젝트에서 어려운 이유

🌀 Zustand는 왜 Flux 아키텍처가 아닐까?

• Action이라는 개념이 필수 아님
• Dispatcher가 없음
• 상태 변경 흐름을 엄격히 제어하지 않음
• set()으로 언제든지 상태 변경 가능

⚔️ Zustand의 set() vs Redux의 dispatch()

비유	Redux (dispatch)	Zustand (set)
역할	비서에게 메모 전달	직접 수첩에 작성
제어 흐름	간접적 (Action → Reducer)	직접 상태 변경
디버깅	액션 로그 추적 가능	추적 어려움 (수동 로깅 필요)

🚧 Zustand가 대형 프로젝트에서 어려운 이유

1. 아키텍처와 구조 강제가 없다

• Redux는 구조 강제 → 협업에 유리
• Zustand는 자유로운 만큼 설계 일관성 부족

2. 상태 변경 추적 어려움

• Redux: DevTool로 상태/액션 추적 가능
• Zustand: 수동 로그나 미들웨어 필요

3. 비동기 흐름이 표준화되지 않음

• Redux: thunk, saga, RTK Query 등 다양한 방식 제공
• Zustand: 미들웨어 기능 제한적, 커스텀 설계 필요

4. 상태 분리/모듈화의 어려움

Redux는 slice로 도메인 분리 가능, Zustand는 단일 store 방식 기본

5. 한번에 여러 Store를 조작하는 방식

Redux는 extraReducers를 사용해서, 각각의 store 내부의 state를 편하게 조작할 수 있다.

// Redux 예시
// userSlice.ts
extraReducers: (builder) => {
  builder.addCase('LOGOUT', () => ({ name: '', token: null }));
};

// postSlice.ts
extraReducers: (builder) => {
  builder.addCase('LOGOUT', () => ({ posts: [] }));
};

 

Zustand는 Redux처럼 한번에 여러 store를 조작할 수 있는 방법이 한정적이기 때문에, 외부 로직 내에 store 조작 코드를 넣어서 관리할 수 있다. ( => 코드가 분산되기 때문에 Redux에 비해 코드를 파악하는 데 어려움이 있다.)

// 상태와 set을 각각의 store로 분리
// stores/userStore.ts
export const useUserStore = create(set => ({
  user: null,
  setUser: (user) => set({ user }),
}));

// stores/settingsStore.ts
export const useSettingsStore = create(set => ({
  darkMode: false,
  setDarkMode: (val) => set({ darkMode: val }),
}));

// usecases/login.ts
export const login = async (email, pw) => {
  const res = await api.login(email, pw);
  useUserStore.getState().setUser(res.user);
  useSettingsStore.getState().setDarkMode(res.user.prefersDarkMode);
};

👉 이렇게 하면 store는 상태만 관리하고, 복잡한 흐름은 외부 usecase에서 관리 가능!

✅ 결론

구분	Redux	Zustand
철학	구조화된 상태 흐름	자유롭고 유연한 상태
장점	디버깅, 예측 가능성	보일러플레이트 없음, 빠른 개발
단점	코드가 복잡하고 많음	구조적 통일성 부족, 추적 어려움
추천	대규모 협업 프로젝트	작은 규모, 빠른 개발