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

로컬 state가 기본인 이유

상태는 가능한 한 사용하는 곳과 가까운 위치에 두는 것이 이해하기 쉽습니다.

예를 들어 검색 input에 입력 중인 문자열이 해당 컴포넌트에서만 필요하다면 useState가 가장 단순합니다.

const [keyword, setKeyword] = useState('');

이 값을 굳이 전역 store로 옮기면 다른 파일을 열어야 상태 변경 흐름을 추적할 수 있습니다.

따라서 기본 원칙은 다음과 같습니다.

한 컴포넌트 또는 가까운 하위 컴포넌트만 사용
→ useState 우선

Context는 언제 사용하는가

Context는 트리 아래 여러 컴포넌트에 같은 값을 전달할 때 유용합니다.

예를 들어 다음 값은 Context가 자연스러울 수 있습니다.

• 테마
• 언어
• 인증 정보
• 라이브러리 Provider
• 특정 화면 트리 전체가 공유하는 값

하지만 Context에 상태와 변경 로직이 계속 추가되면 Provider가 커질 수 있습니다.

TaskProvider
├─ tasks
├─ selectedTaskId
├─ modal
├─ filter
├─ theme
├─ dispatch
└─ 여러 helper

이때 모든 값이 같은 변경 주기와 같은 구독 범위를 갖는 것은 아닙니다.

Zustand가 필요한 신호

다음 질문에 여러 번 “예”라고 답한다면 Zustand를 검토할 수 있습니다.

1. 서로 멀리 떨어진 컴포넌트가 같은 상태를 사용하는가?
2. props를 여러 단계 전달하고 있는가?
3. 상태 변경 함수를 여러 컴포넌트가 함께 사용하는가?
4. 특정 상태만 선택적으로 구독하고 싶은가?
5. 새로고침 후 일부 상태를 복원해야 하는가?
6. 상태 변경 흐름을 devtools로 확인하고 싶은가?

예를 들어 다음 값은 Zustand 후보입니다.

selectedTaskId
isTaskModalOpen
taskFilter
sidebarOpen
userUiPreferences

서버 상태는 왜 다른가

API 응답은 단순한 전역 변수와 다릅니다.

서버 데이터에는 다음 개념이 붙습니다.

• 언제 가져왔는가
• 다시 가져와야 하는가
• 요청 중인가
• 실패했는가
• 캐시가 유효한가
• 수정 후 어떤 쿼리를 갱신해야 하는가

그래서 서버 원본 데이터는 TanStack Query가 담당하는 편이 자연스럽습니다.

API tasks
→ TanStack Query


selectedTaskId
→ Zustand

두 라이브러리를 함께 사용할 때 가장 중요한 규칙은 원본을 중복 저장하지 않는 것입니다.

상태 선택 기준

useState

다음 조건이면 우선 useState를 사용합니다.

• 컴포넌트 내부에서만 사용
• 짧은 생명주기
• 공유 필요 없음
• 새로고침 후 유지 필요 없음

Context

다음 조건이면 Context를 검토합니다.

• 트리 전체가 같은 값을 읽음
• 값의 변경 빈도가 높지 않음
• Provider 구조 자체가 의미 있음

Zustand

다음 조건이면 Zustand를 검토합니다.

• 여러 화면에서 같은 클라이언트 상태 공유
• 선택 구독 필요
• action을 store에 모으고 싶음
• persist나 devtools가 필요함

잘못된 기준: “전역이면 Zustand”

전역이라는 이유만으로 store에 넣으면 안 됩니다.

예를 들어 modal이 앱 전체에 하나 있다고 해도 실제로 특정 페이지에서만 사용한다면 해당 페이지 내부 state가 더 단순할 수 있습니다.

중요한 것은 범위와 생명주기입니다.

학습 완료 체크리스트

• useState를 기본 선택으로 둘 수 있습니다.
• Context와 Zustand의 차이를 설명할 수 있습니다.
• 서버 상태를 Zustand에 중복 저장하면 안 되는 이유를 설명할 수 있습니다.
• 공유 범위와 생명주기로 상태 위치를 결정할 수 있습니다.

# 상태 소유권

| 값 | 소유자 | 저장 |
|---|---|---|
|입력 문자열|TaskForm|아니오|
|tasks|현재 Context, 06부터 Zustand|메모리만|
|필터·선택|04·05부터 Zustand|10부터 선택 저장|
|모달|05부터 Zustand|아니오|

zustand-step-01-roadmap

로컬 UI 상태
클라이언트 전역 상태
서버 상태 후보

TaskForm 입력값
→ 로컬 state


selectedTaskId
→ Zustand


isTaskModalOpen
→ Zustand


filter
→ Zustand


tasks
→ 현재 로컬 학습 데이터이므로 Zustand 이전 실습
→ 서버 API 도입 후에는 TanStack Query 원본으로 변경

type TaskFilter = 'all' | 'active' | 'completed';


type TaskUiState = {
  selectedTaskId: string | null;
  isTaskModalOpen: boolean;
  filter: TaskFilter;
};

Before
상태가 필요해질 때마다 Context 또는 useState에 추가


After
로컬 state / Zustand / 서버 상태의 경계를 먼저 결정

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

zustand-step-02-boundary

다음 학습

다음 글에서는 Zustand의 store, state, action 구조를 reducer + Context와 비교하고 실제 설치 전에 useTaskStore의 모양을 설계합니다.

다음 글: Zustand란? React 상태 관리 선택 기준과 기본 Store

공식 문서

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

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

Zustand · 2 / 15 · 필수 학습 · 상태 경계

React에서 상태 관리 도구를 선택할 때 가장 먼저 해야 할 일은 라이브러리를 고르는 것이 아니라 상태의 범위를 구분하는 것입니다.

useState로 충분한 값을 Zustand에 넣으면 store가 불필요하게 커지고, 반대로 여러 컴포넌트가 공유해야 하는 값을 로컬 state로만 관리하면 props 전달과 상태 동기화가 복잡해집니다.

이번 글에서는 React state, Context, Zustand를 어떤 기준으로 나누는지 설명하고, 하단에서는 TaskFlow의 상태를 실제로 분류합니다.

이번 글에서 배우는 내용

• 로컬 state가 적합한 경우
• Context가 적합한 경우
• Zustand가 적합한 경우
• 서버 상태를 Zustand와 분리하는 이유
• 전역 상태를 판단하는 질문
• TaskFlow 상태 분류

목차