셀렉터를 잘못 써서 모든 컴포넌트가 리렌더됩니다.

객체 리터럴을 매번 반환하면 참조가 바뀌어 구독이 넓어집니다. shallow·필드 단위 셀렉터·useMemo로 분리하세요.

Next.js에서 서버와 클라이언트 상태가 섞입니다.

요청마다 스토어를 만들거나, 클라이언트 전용으로 가두고 초기 데이터는 props·fetch로 주입합니다. localStorage persist는 클라이언트에서만 활성화합니다.

Persist에 토큰을 넣어도 되나요?

XSS에 노출되면 그대로 유출됩니다. 민감 정보는 httpOnly 쿠키·서버 세션을 쓰고, 스토어에는 UI 상태만 둡니다.

Zustand 완벽 가이드 | 간단한 상태 관리·React·TypeScript·Middleware·실전 활용

2026년 4월 7일 · 4분 읽기 · 수정 2026년 4월 18일 초급

이 글의 핵심

Zustand는 외부 스토어(vanilla)와 React 바인딩을 분리하고, 셀렉터 기반으로 리렌더를 최소화합니다. immer·persist·SSR·Next.js App Router에서의 스토어 공유 패턴과 흔한 함정을 정리합니다.

이 글의 핵심

Zustand로 간단한 상태 관리를 구현하는 완벽 가이드입니다. Redux 없이 가볍게, TypeScript 지원, Middleware, Persist까지 실전 예제로 정리했습니다.

실무 경험 공유: Redux에서 Zustand로 전환하면서, 보일러플레이트가 90% 감소하고 번들 크기가 50% 줄어든 경험을 공유합니다.

들어가며: “Redux가 복잡해요”

실무 문제 시나리오

시나리오 1: 보일러플레이트가 너무 많아요

Redux는 복잡합니다. Zustand는 간단합니다. 시나리오 2: 번들 크기가 커요

Redux는 무겁습니다. Zustand는 1KB입니다. 시나리오 3: TypeScript 설정이 어려워요

Redux는 타입 설정이 복잡합니다. Zustand는 자동 추론됩니다.

1. Zustand란?

핵심 특징

Zustand는 간단한 React 상태 관리 라이브러리입니다. 주요 장점:

간단한 API: 보일러플레이트 없음
작은 크기: 1KB
TypeScript: 완벽한 지원
Middleware: Persist, Devtools
React 외부: Vanilla JS 사용 가능

2. 기본 사용

설치

npm install zustand

Store 생성

// store/useStore.ts
import { create } from 'zustand';
interface Store {
  count: number;
  increment: () => void;
  decrement: () => void;
  reset: () => void;
}
export const useStore = create<Store>((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 })),
  reset: () => set({ count: 0 }),
}));

컴포넌트에서 사용

// components/Counter.tsx
import { useStore } from '../store/useStore';
export default function Counter() {
  const count = useStore((state) => state.count);
  const increment = useStore((state) => state.increment);
  const decrement = useStore((state) => state.decrement);
  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
    </div>
  );
}

3. 고급 패턴

Async Actions

interface UserStore {
  users: User[];
  loading: boolean;
  error: string | null;
  fetchUsers: () => Promise<void>;
}
export const useUserStore = create<UserStore>((set) => ({
  users: [],
  loading: false,
  error: null,
  fetchUsers: async () => {
    set({ loading: true, error: null });
    try {
      const response = await fetch('/api/users');
      const users = await response.json();
      set({ users, loading: false });
    } catch (error) {
      set({ error: error.message, loading: false });
    }
  },
}));

Computed Values

interface CartStore {
  items: CartItem[];
  addItem: (item: CartItem) => void;
  removeItem: (id: string) => void;
  total: () => number;
}
export const useCartStore = create<CartStore>((set, get) => ({
  items: [],
  addItem: (item) =>
    set((state) => ({ items: [...state.items, item] })),
  removeItem: (id) =>
    set((state) => ({
      items: state.items.filter((item) => item.id !== id),
    })),
  total: () => {
    const { items } = get();
    return items.reduce((sum, item) => sum + item.price, 0);
  },
}));

4. Middleware

Persist

import { create } from 'zustand';
import { persist } from 'zustand/middleware';
interface AuthStore {
  user: User | null;
  token: string | null;
  login: (user: User, token: string) => void;
  logout: () => void;
}
export const useAuthStore = create<AuthStore>()(
  persist(
    (set) => ({
      user: null,
      token: null,
      login: (user, token) => set({ user, token }),
      logout: () => set({ user: null, token: null }),
    }),
    {
      name: 'auth-storage',
    }
  )
);

Devtools

import { devtools } from 'zustand/middleware';
export const useStore = create<Store>()(
  devtools(
    (set) => ({
      count: 0,
      increment: () => set((state) => ({ count: state.count + 1 })),
    }),
    { name: 'CounterStore' }
  )
);

Immer

import { immer } from 'zustand/middleware/immer';
export const useStore = create<Store>()(
  immer((set) => ({
    nested: { deep: { value: 0 } },
    updateDeep: (value: number) =>
      set((state) => {
        state.nested.deep.value = value;
      }),
  }))
);

5. Slice Pattern

// store/slices/userSlice.ts
export const createUserSlice = (set, get) => ({
  users: [],
  fetchUsers: async () => {
    const users = await api.getUsers();
    set({ users });
  },
});
// store/slices/cartSlice.ts
export const createCartSlice = (set, get) => ({
  items: [],
  addItem: (item) => set((state) => ({ items: [...state.items, item] })),
});
// store/index.ts
import { create } from 'zustand';
import { createUserSlice } from './slices/userSlice';
import { createCartSlice } from './slices/cartSlice';
export const useStore = create((set, get) => ({
  ...createUserSlice(set, get),
  ...createCartSlice(set, get),
}));

6. Selector 최적화

잘못된 예

// 전체 store를 구독 (불필요한 리렌더링)
const store = useStore();

올바른 예

// 필요한 값만 구독
const count = useStore((state) => state.count);
const increment = useStore((state) => state.increment);

Shallow 비교

import { shallow } from 'zustand/shallow';
const { count, increment } = useStore(
  (state) => ({ count: state.count, increment: state.increment }),
  shallow
);

7. Vanilla JS

import { createStore } from 'zustand/vanilla';
const store = createStore<Store>((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));
// 구독
const unsubscribe = store.subscribe((state) => {
  console.log('Count:', state.count);
});
// 사용
store.getState().increment();
console.log(store.getState().count); // 1
// 구독 해제
unsubscribe();

심화: 구독 모델·Next.js·트러블슈팅

스토어와 리렌더

useStore(selector)는 Zustand가 셀렉터 결과의 동일성을 추적해 변경된 컴포넌트만 다시 그립니다. 셀렉터가 매번 새 객체를 만들면({ a, b } 형태) 참조가 달라져 불필요한 리렌더가 납니다. 이때 shallow 비교를 쓰거나, 필드를 쪼개 여러 useStore 호출로 나눕니다.

미들웨어 체인

devtools·persist·immer는 스토어를 래핑해 동작합니다. 순서에 따라 타입 추론과 저장 포맷이 달라질 수 있으므로, 팀에서 표준 순서를 문서화하는 편이 좋습니다. persist의 부분 저장·마이그레이션 버전은 장기 운영 시 필수입니다.

Next.js App Router

서버 컴포넌트와 클라이언트 컴포넌트 경계에서 전역 스토어를 공유하려면, 클라이언트 트리 안에서만 스토어 모듈을 import하도록 합니다. SSR 초기 상태는 props나 fetch 결과로 내려받고, 클라이언트에서 하이드레이션 후 스토어를 시드하는 패턴이 안전합니다.

트러블슈팅

증상	점검
상태는 맞는데 UI만 안 바뀜	셀렉터가 참조 동일 객체를 반환
무한 루프	`set`이 `subscribe` 콜백 안에서 다시 호출
테스트끼리 상태 공유	각 테스트마다 새 스토어 또는 `setState` 초기화

취업·면접과 연결하기

상태 관리·전역 스토어 설계는 프론트엔드 면접에서 자주 묻습니다. 기술 면접 완벽 대비 가이드와, 이력서에 Redux→Zustand 전환 같은 수치 스토리를 쓰는 법은 개발자 이력서·서류·면접 가이드를 참고하세요.

정리 및 체크리스트

핵심 요약

Zustand: 간단한 상태 관리
작은 크기: 1KB
TypeScript: 완벽한 지원
Middleware: Persist, Devtools, Immer
Selector: 최적화 가능
Vanilla JS: React 외부 사용

구현 체크리스트

같이 보면 좋은 글

이 글에서 다루는 키워드

Zustand, State Management, React, TypeScript, Redux, Frontend, Performance

자주 묻는 질문 (FAQ)

Q. Redux와 비교하면 어떤가요?

A. Zustand가 훨씬 간단하고 가볍습니다. Redux는 더 많은 기능을 제공하지만 복잡합니다.

Q. Context API와 비교하면 어떤가요?

A. Zustand가 성능이 더 좋고 사용이 간편합니다. Context API는 prop drilling을 피하는 용도로 적합합니다.

Q. 프로덕션에서 사용해도 되나요?

A. 네, 많은 기업에서 안정적으로 사용하고 있습니다.

Q. SSR을 지원하나요?

A. 네, Next.js와 함께 사용할 수 있습니다.

심화 부록: 구현·운영 관점

이 부록은 앞선 본문에서 다룬 주제(「Zustand 완벽 가이드 | 간단한 상태 관리·React·TypeScript·Middleware·실전 활용」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.

내부 동작과 핵심 메커니즘

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(런타임·게이트웨이·프로세스)
  participant D as 의존성(API·DB·큐·파일)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)

불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.

프로덕션 운영 패턴

영역	운영 관점 질문
관측성	요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성	입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능	캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가
용량	피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.

확장 예시: 엔드투엔드 미니 시나리오

앞선 본문 주제(「Zustand 완벽 가이드 | 간단한 상태 관리·React·TypeScript·Middleware·실전 활용」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.

handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)
  authorize(validated, ctx)
  result = domainCore(validated)
  persistOrEmit(result, idempotentKey)
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스, 타임아웃, 외부 의존성, DNS	최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하	N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납	상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패	환경 변수, 권한, 플랫폼 차이, lockfile	CI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정 불일치	프로필·시크릿·기본값, 리전	스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화
데이터 불일치	비멱등 재시도, 부분 쓰기, 캐시 무효화 누락	멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.

이 글이 도움이 되셨나요?

여러분의 피드백은 더 나은 콘텐츠를 만드는 데 도움이 됩니다

문제가 있거나 개선 제안이 있으시면 연락처로 알려주세요.

Keyboard Shortcuts

이 글의 핵심

이 글의 핵심

들어가며: “Redux가 복잡해요”

실무 문제 시나리오

Redux는 타입 설정이 복잡합니다. Zustand는 자동 추론됩니다.

1. Zustand란?

핵심 특징

2. 기본 사용

설치

Store 생성

컴포넌트에서 사용

3. 고급 패턴

Async Actions

Computed Values

4. Middleware

Persist

Devtools

Immer

5. Slice Pattern

6. Selector 최적화

잘못된 예

올바른 예

Shallow 비교

7. Vanilla JS

심화: 구독 모델·Next.js·트러블슈팅

스토어와 리렌더

미들웨어 체인

Next.js App Router

트러블슈팅

취업·면접과 연결하기

상태 관리·전역 스토어 설계는 프론트엔드 면접에서 자주 묻습니다. 기술 면접 완벽 대비 가이드와, 이력서에 Redux→Zustand 전환 같은 수치 스토리를 쓰는 법은 개발자 이력서·서류·면접 가이드를 참고하세요.

정리 및 체크리스트

핵심 요약

구현 체크리스트

같이 보면 좋은 글

이 글에서 다루는 키워드

자주 묻는 질문 (FAQ)

Q. Redux와 비교하면 어떤가요?

Q. Context API와 비교하면 어떤가요?

Q. 프로덕션에서 사용해도 되나요?

Q. SSR을 지원하나요?

심화 부록: 구현·운영 관점

내부 동작과 핵심 메커니즘

프로덕션 운영 패턴

확장 예시: 엔드투엔드 미니 시나리오

문제 해결(Troubleshooting)

이 글이 도움이 되셨나요?