Zustand 학습 로드맵: store·action·selector·persist 순서

node --version
npm --version
npm create vite@latest zustand-lab -- --template react-ts
cd zustand-lab
npm install
npm install zustand@5

import { create } from 'zustand';
type Selection = { selectedId: string | null; select: (id: string | null) => void };
const useSelection = create<Selection>()((set) => ({
  selectedId: null,
  select: (selectedId) => set({ selectedId }),
}));
function SelectedLabel() {
  const id = useSelection((state) => state.selectedId);
  return <p>선택: {id ?? '없음'}</p>;
}
export default function App() {
  const select = useSelection((state) => state.select);
  return (
    <main>
      <SelectedLabel />
      <button onClick={() => select('task-1')}>첫 작업 선택</button>
      <button onClick={() => select(null)}>선택 해제</button>
    </main>
  );
}

npm run dev
npm run build

Zustand는 무엇을 해결하는가

React의 useState는 컴포넌트 내부 상태를 관리하기 좋습니다.

하지만 같은 상태를 여러 컴포넌트가 사용하기 시작하면 상태를 어디에 둘지 고민해야 합니다.

예를 들어 다음 값이 있다고 가정합니다.

selectedTaskId
isTaskModalOpen
taskFilter
theme
sidebarOpen

이 값들을 서로 멀리 떨어진 컴포넌트가 함께 사용한다면 props를 여러 단계 전달하거나 Context를 만들어야 합니다.

Zustand는 이런 클라이언트 전역 상태를 store에 두고 필요한 컴포넌트가 직접 구독하도록 만들 수 있습니다.

기본 흐름은 다음과 같습니다.

store 생성
↓
state 정의
↓
action 정의
↓
컴포넌트에서 필요한 값만 selector로 구독
↓
필요한 상태만 persist
↓
devtools / middleware / migration 적용

Zustand 학습 순서

BlogFlow의 Zustand 과정은 다음 순서로 진행합니다.

초급

1. 전체 학습 로드맵
2. React state vs Zustand
3. Zustand 개념과 Store 설계
4. Zustand 설치와 첫 Store
5. state 읽기와 변경

중급

6. action으로 변경 로직 분리
7. selector로 필요한 상태만 구독
8. 리렌더링 원리와 selector 최적화
9. 상태 변경 후 화면이 안 바뀌는 문제 해결
10. persist로 새로고침 후 상태 복원

고급

11. combine과 immer
12. subscribeWithSelector와 devtools
13. persist migration
14. 실무 Store 설계 점검
15. TaskFlow Zustand 최종 통합

React state와 Zustand의 경계

모든 상태를 Zustand에 넣는 것이 좋은 구조는 아닙니다.

다음 값은 보통 컴포넌트 로컬 state가 더 자연스럽습니다.

input에 입력 중인 문자열
한 컴포넌트에서만 사용하는 열림/닫힘
잠깐 표시되는 hover 상태
로컬 폼의 임시 입력값

반대로 다음처럼 여러 화면이나 컴포넌트가 공유해야 하는 값은 Zustand 후보가 됩니다.

selectedTaskId
전역 modal 상태
사용자 UI 설정
여러 컴포넌트가 공유하는 필터
클라이언트에서 오래 유지해야 하는 선택 상태

판단 기준은 “전역 상태인가?”보다 “여러 위치에서 공유해야 하고, 생명주기를 컴포넌트 하나에 묶기 어려운가?”에 가깝습니다.

서버 상태와 Zustand를 구분해야 하는 이유

API에서 가져온 원본 데이터는 클라이언트 상태와 성격이 다릅니다.

예를 들어 서버에서 tasks를 가져온다면 다음 문제를 함께 다뤄야 합니다.

• 로딩
• 에러
• 캐시
• refetch
• stale 상태
• mutation 후 동기화

이런 서버 상태는 TanStack Query가 더 적합합니다.

따라서 이 과정에서 원칙은 다음과 같습니다.

서버에서 가져온 원본 데이터
→ TanStack Query


selectedTaskId
modal
UI filter
사용자 인터페이스 설정
임시 편집 상태
→ Zustand

현재 TaskFlow의 tasks는 로컬 학습 데이터이므로 Zustand 이전을 연습하지만, 이후 서버 데이터로 바뀐다면 TanStack Query가 원본을 담당하도록 역할을 다시 나눕니다.

TaskFlow 15회 확장 로드맵

시작 상태는 다음과 같습니다.

TaskContext
TaskProvider
taskReducer
dispatch
useContext

과정이 끝나면 다음 구조를 목표로 합니다.

useTaskStore
state
actions
selectors
persist
devtools
migration
명확한 store 경계

전체 흐름은 다음과 같습니다.

React reducer + Context
→ Zustand 도입 기준 정리
→ Store 설계
→ Zustand 설치
→ state 이전
→ action 이전
→ selector 적용
→ 리렌더링 측정
→ 잘못된 업데이트 수정
→ persist
→ combine / immer 판단
→ subscribeWithSelector / devtools
→ persist migration
→ store 경계 재검토
→ 최종 TaskFlow 통합

자주 하는 시작 단계 실수

Context를 전부 Zustand로 바꾸려고 합니다

Context 자체가 잘못된 것은 아닙니다.

테마, 인증 Provider, 라이브러리 Provider처럼 Context가 자연스러운 경우도 많습니다.

Zustand는 Context를 없애는 도구가 아니라, 여러 컴포넌트가 공유하는 클라이언트 상태를 더 단순하게 다루는 선택지입니다.

서버 데이터를 store에 복제합니다

TanStack Query로 받은 데이터를 다시 Zustand에 복사하면 두 상태 중 무엇이 최신인지 판단하기 어려워집니다.

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

처음부터 middleware를 모두 사용합니다

persist, devtools, immer, subscribeWithSelector는 필요한 시점에 도입합니다.

기본 store와 selector를 이해하기 전에 middleware를 많이 붙이면 문제가 생겼을 때 원인을 찾기 어렵습니다.

학습 완료 체크리스트

• Zustand를 클라이언트 전역 상태 관리 도구라고 설명할 수 있습니다.
• 로컬 state와 전역 store를 구분할 수 있습니다.
• 서버 상태와 클라이언트 상태의 차이를 설명할 수 있습니다.
• store → action → selector → persist 순서를 설명할 수 있습니다.
• TaskFlow가 reducer + Context에서 Zustand로 어떻게 바뀌는지 이해했습니다.

# 이전 계획

tasks: 현재 Context → 06에서 Zustand → 서버 도입 시 Query.
입력: TaskForm 로컬 state. 선택·모달·필터: 공유 UI 후보.

step-18-reducer-context

TaskProvider
├─ tasks
├─ taskReducer
└─ dispatch

Context 안에 여러 상태를 계속 추가할 가능성이 있음
상태의 성격을 구분하는 기준이 아직 없음

React 로컬 state
Zustand 클라이언트 전역 상태
TanStack Query 서버 상태


세 영역의 책임을 구분함

tasks
- 현재는 로컬 실습 데이터
- Zustand 이전 연습 가능
- 서버 데이터가 되면 TanStack Query로 이동


selectedTaskId
- 여러 컴포넌트가 공유
- Zustand 후보


isTaskModalOpen
- 여러 위치에서 제어 가능
- Zustand 후보


filter
- 목록과 필터 UI가 함께 사용
- Zustand 후보


formInput
- TaskForm 내부에서만 사용
- 로컬 state 유지 가능

→ 1. Zustand 과정 전체 로드맵
○ 2. 상태 경계 결정
○ 3. Store 구조 설계
○ 4. Zustand 설치
○ 5. state 이전
○ 6. action 이전
○ 7. selector
○ 8~15. 최적화·persist·실무 구조

zustand-step-01-roadmap

다음 학습

다음 글에서는 React state, Context, Zustand를 실제 기준으로 비교하고 TaskFlow의 상태를 로컬 상태와 전역 상태로 나눕니다.

다음 글: React state vs Zustand: 전역 상태가 필요한 기준

공식 문서

• Zustand 공식 문서: https://zustand.docs.pmnd.rs/
• Zustand GitHub: https://github.com/pmndrs/zustand

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

Zustand · 1 / 15 · 필수 길잡이 · 과정 안내

Zustand를 처음 공부할 때 가장 중요한 것은 API를 많이 외우는 것이 아니라, 어떤 상태를 전역 store로 옮겨야 하고 어떤 상태는 컴포넌트에 남겨야 하는지 기준을 잡는 것입니다.

처음에는 작은 state와 action을 가진 store를 만들고, selector로 구독 범위를 좁힌 다음 필요한 값에만 persist를 적용하세요. 이 순서라면 상태 소유권·변경 규칙·렌더 기준·저장 수명을 차례로 확인할 수 있습니다. 이전 프로젝트 없이 시작할 준비 단계와 선택 예제가 아래에 있습니다.

상단에서는 이 글만 찾아온 독자도 Zustand 학습 순서를 이해할 수 있게 설명하고, 하단에서는 React TaskFlow의 현재 상태를 점검해 Zustand 과정의 출발점을 만듭니다.

이번 글에서 배우는 내용

• Zustand가 해결하려는 문제
• React state, Context, Zustand의 역할 차이
• store → action → selector → persist 순서
• middleware와 devtools를 언제 도입하는지
• persist migration이 필요한 이유
• 서버 상태와 클라이언트 전역 상태를 구분하는 기준
• TaskFlow가 15회 동안 어떻게 바뀌는지

먼저 알아야 할 내용

이 과정은 React 기본 문법을 알고 있다는 전제에서 진행합니다.

최소한 다음 내용을 이해하면 좋습니다.

• useState
• props
• Context
• useReducer
• 컴포넌트 리렌더링
• TypeScript 기본 타입

누적 프로젝트를 이어갈 때의 시작 상태는 하단 프로젝트 영역에서 확인합니다.

목차