Zustand 실무 사용 기준: store가 복잡해질 때 피할 실수

실수 1. 모든 상태를 Zustand에 넣기

다음 값은 한 컴포넌트에서만 사용한다면 로컬 state가 더 단순합니다.

inputValue
hoveredId
localErrorMessage
accordionOpen
임시 form field

const [title, setTitle] = useState('');

전역 store는 여러 위치에서 공유해야 하고 컴포넌트 하나의 생명주기에 묶기 어려운 상태에 집중합니다.

실수 2. 하나의 거대한 Store

useAppStore
├─ tasks
├─ theme
├─ modal
├─ sidebar
├─ notifications
├─ editor
└─ settings

다음 조건이 여러 개 겹치면 store 분리를 검토합니다.

1. 변경 이유가 서로 다릅니다.
2. 초기화 시점이 다릅니다.
3. persist 정책이 다릅니다.
4. 독립적으로 테스트할 필요가 있습니다.
5. 서로 다른 화면에서 별개로 사용됩니다.

실수 3. 서버 상태 복제

서버에서 가져온 tasks를 TanStack Query와 Zustand에 동시에 저장하면 어느 쪽이 최신 원본인지 불분명해집니다.

서버 tasks, 로딩, 에러, 캐시, mutation
→ TanStack Query


selectedTaskId
taskFilter
task modal
UI preferences
→ Zustand

원본 데이터의 소유자를 하나로 유지하는 것이 중요합니다.

실수 4. setter만 늘리기

setTasks
setSelectedTaskId
setModalOpen
setPreferences

setter 자체는 문제가 아니지만 변경 규칙이 컴포넌트에 흩어질 수 있습니다. 행동 중심 action을 사용하면 책임이 더 명확합니다.

selectTask
openTaskModal
closeTaskModal
toggleCompact

실수 5. persist 범위가 너무 큼

persist되는 필드가 많을수록 migration 책임도 커집니다.

다음 질문으로 저장 여부를 결정합니다.

사용자가 다음 방문에도 기대하는가?
새로고침 후 복원할 가치가 있는가?
서버 원본과 중복되지 않는가?
구조 변경 비용을 감수할 가치가 있는가?

실수 6. selector 추상화가 과함

선택 훅은 반복을 줄일 수 있지만 모든 selector를 감추면 어떤 값을 구독하는지 추적하기 어려울 수 있습니다.

export const useTaskFilter = () =>
  useTaskStore((state) => state.taskFilter);

의미가 반복되는 구독 단위만 추상화합니다.

Store 분리 예시

useTaskUiStore
├─ selectedTaskId
├─ taskFilter
├─ isTaskModalOpen
└─ actions


useUiPreferencesStore
├─ compact
├─ showCompleted
└─ persist


서버 tasks
→ TanStack Query

현재 TaskFlow 규모에서는 하나의 store를 유지해도 됩니다. 분리는 파일 수를 늘리는 목적이 아니라 책임을 분리하기 위한 선택입니다.

실무 점검 체크리스트

• 한 컴포넌트에서만 쓰는 state가 전역에 있지 않은가
• 서버 원본이 Zustand에 복제되지 않았는가
• action 이름이 행동을 설명하는가
• selector가 필요한 값만 구독하는가
• persist 대상이 최소화되어 있는가
• migration 기준이 있는가
• middleware가 실제 문제를 해결하는가

# 최종 상태 점검

tasks는 메모리 원본이며 서버 원본의 복제본이 아닙니다. taskFilter·선택·표시 설정만 persist합니다. 모달과 입력은 저장하지 않습니다. 배열 selector에서 매번 새 배열을 반환하지 않고 tasks 원본과 필터를 따로 구독합니다. 서버 API를 도입하면 tasks 소유권을 Query로 옮기는 별도 트랙입니다.

zustand-step-13-migration

tasks
→ 현재 학습용 로컬 데이터
→ API 도입 시 TanStack Query로 이동


taskFilter
→ Zustand


selectedTaskId
→ Zustand


isTaskModalOpen
→ Zustand


preferences
→ Zustand + persist


form title
→ TaskForm 로컬 state

remainingCount
completedCount
visibleTasks

const completedCount = useTaskStore(
  (state) =>
    state.tasks.filter(
      (task) => task.completed,
    ).length,
);

taskFilter
selectedTaskId
preferences

isTaskModalOpen
임시 form 값
loading / error

persist
→ 저장이 실제로 필요한 경우 유지


devtools
→ 개발 중 action 추적에 유용


subscribeWithSelector
→ 외부 구독이 실제로 있을 때 유지


immer
→ 중첩 상태 업데이트가 충분히 복잡할 때 유지

npm run dev
npm run build

✓ 1~13. Zustand 주요 기능 학습
→ 14. 실무 설계 점검
○ 15. 최종 TaskFlow 통합

zustand-step-14-design-review

다음 학습

마지막 글에서는 store, action, selector, persist, devtools, migration 기준을 하나의 TaskFlow 최종 구조로 통합합니다.

다음 프로젝트 단계: Zustand Todo 완성 실습: actions·선택 훅·persist 연결

공식 문서

• Zustand 공식 문서: https://zustand.docs.pmnd.rs/
• Guides: https://zustand.docs.pmnd.rs/guides/

글 소개·학습 준비·전체 목차

Zustand · 14 / 15 · 고급 학습 · 실무 설계 점검

Zustand는 작은 API 덕분에 쉽게 시작할 수 있지만, store에 상태가 계속 쌓이면 구조가 불분명해질 수 있습니다. 독립적인 서버 작업 목록 사례로 상태의 소유자와 저장 범위를 점검합니다. 하단에서는 이 기준을 TaskFlow store에 적용합니다.

이번 글에서 배우는 내용

• 모든 상태를 전역화하면 안 되는 이유
• 거대한 store를 피하는 기준
• 서버 상태와 클라이언트 상태 분리
• action 책임과 selector 범위
• persist 대상 최소화
• store 분리 기준

목차