React로 만든 첫 프로젝트가 잘 돌아가는 순간, 어느 틈엔가 이런 생각이 찾아옵니다. "이 유저 정보를 저 컴포넌트까지 어떻게 전달하지?" props가 5개를 넘는 순간, 이미 컴포넌트 구조가 잘못됐을 가능성이 큽니다. 컴포넌트가 3단계, 4단계 깊어지면서 props를 계속 아래로 내려보내는 일이 고역이 되기 시작합니다. 이른바 props drilling의 시작입니다.
이 문제를 해결하기 위해 React는 Context API를 내장하고 있고, 생태계는 Zustand라는 간결한 상태관리 라이브러리를 만들어냈습니다. 그런데 둘 다 쓸 수 있다면 언제 어떤 것을 선택해야 할까요?
이 글은 단순한 기능 비교가 아닙니다. "언제 Context로 충분하고, 언제 Zustand가 필요한가"라는 실무 판단 기준을 2026년 최신 트렌드와 실전 코드를 토대로 명확하게 정리합니다.
1. 왜 상태 관리가 갑자기 중요해질까?
React 입문 단계에서는 useState 하나면 충분합니다. 하지만 앱이 성장하면서 이런 구조가 등장합니다.
<App> ← user 상태가 여기 있음
<Layout>
<Sidebar>
<UserProfile /> ← user 상태가 필요한 곳
</Sidebar>
</Layout>
</App>App에서 UserProfile까지 user 상태를 전달하려면 Layout → Sidebar → UserProfile 순서로 props를 계속 내려야 합니다. Layout과 Sidebar는 user를 실제로 쓰지도 않는데 받아서 전달만 합니다. 이것이 props drilling입니다. 기능이 늘수록 관리 불가 상태가 됩니다.
💡 핵심 메시지
React 앱이 커질수록 "상태를 어디에 둘 것인가"가 가장 중요한 아키텍처 결정이 됩니다. 이 선택이 개발 생산성과 앱 성능 모두에 영향을 미칩니다.
2. Context API — 강점과 정확한 사용 범위
Context API는 React에 내장된 전역 상태 공유 도구입니다. 별도 라이브러리 설치 없이 props drilling을 해결할 수 있습니다.
📄 UserContext.tsx — 기본 구조
import { createContext, useContext } from 'react';
type User = { name: string; role: string };
const UserContext = createContext<User | null>(null);
// Provider: 상태를 하위 트리에 공급
export function App() {
const user = { name: 'Kim', role: 'admin' };
return (
<UserContext.Provider value={user}>
<Layout />
</UserContext.Provider>
);
}
// Consumer: 어디서든 바로 꺼내서 사용
function UserProfile() {
const user = useContext(UserContext);
return <div>{user?.name}</div>;
}Context가 가장 잘 어울리는 상황은 명확합니다. 자주 바뀌지 않고 앱 전체에서 공유되는 값입니다.
| Context 적합 사례 | 이유 |
|---|---|
| 🔐 로그인 사용자 정보 | 로그인 후 거의 변경 없음 |
| 🌙 다크모드 / 테마 | 사용자가 설정한 값, 드물게 변경 |
| 🌍 언어 설정 (i18n) | 세션 중 거의 고정 |
| ⚙️ 전역 설정값 | 앱 초기화 시 결정, 이후 변경 없음 |
3. Context API의 한계 3가지 (실전 기준)
Context가 좋아 보여도 프로젝트가 성장하면 반드시 이 세 가지 문제에 부딪힙니다.
⚠️ 한계 1 — 리렌더링 문제 (정확한 이해 필요)
정확히는 이렇습니다. Context value가 변경되면, 해당 Context를 구독하는 컴포넌트들이 리렌더링됩니다. React.memo로 감싼 컴포넌트도 Context를 직접 구독하고 있다면 리렌더링을 피할 수 없습니다.
실무에서 문제가 되는 이유는, 하나의 Context에 여러 상태를 묶으면 관계없는 상태가 바뀌어도 같은 Context를 구독하는 모든 컴포넌트가 함께 재실행되기 때문입니다. 결과적으로 "전체가 리렌더링되는 것처럼 보이는 구조"가 만들어집니다.
// user, theme, notifications를 하나의 Context에 묶은 경우
const AppContext = createContext({ user: null, theme: 'light', notifications: [] });
function Header() {
const { theme } = useContext(AppContext);
// ⚠️ notifications가 바뀌어도 theme를 쓰는 Header가 함께 리렌더링!
// AppContext 전체를 구독하기 때문
return <header className={theme}>...</header>;
}💡 해결책은? Context를 기능별로 분리하거나 useMemo로 value를 안정화할 수 있습니다. 하지만 이 과정 자체가 복잡해지는 것이 Context의 한계입니다. (자세한 내용은 아래 '비교표' 이후 다룹니다)
⚠️ 한계 2 — 상태가 커질수록 복잡해진다
여러 상태를 한 Context에 넣으면 거대한 전역 객체가 됩니다. 나눠도 문제입니다. UserContext, ThemeContext, CartContext, NotificationContext… Provider가 중첩되면 "Provider 지옥"이 됩니다. useMemo로 최적화를 시도해도 보일러플레이트가 크게 늘어납니다.
⚠️ 한계 3 — 보일러플레이트 증가
Context 하나를 제대로 만들려면 Context 생성 → Provider 작성 → 커스텀 Hook 작성 → TypeScript 타입 정의까지 최소 4단계가 필요합니다. 상태 하나 추가할 때마다 이 과정이 반복됩니다.
✅ 결론 — Context는 "적절한 범위에서 쓸 때만 좋은 도구"입니다. 자주 변경되거나 여러 컴포넌트에 걸쳐 복잡하게 연결된 상태라면 다른 도구가 필요합니다.
4. Zustand — 왜 선택받고 있는가?
Zustand(독일어로 "상태")는 주간 다운로드 2,300만 회, GitHub 스타 5만 7천 개(2026년 4월 기준)를 기록하며 React 상태관리 라이브러리 중 가장 빠르게 성장하고 있습니다. 번들 크기는 약 1KB(min+gzip)에 불과하고, Provider 없이 어디서든 상태를 구독할 수 있습니다.
📄 useCartStore.ts — Zustand 기본 구조
import { create } from 'zustand';
type CartStore = {
count: number;
items: string[];
addItem: (item: string) => void;
removeItem: (item: string) => void;
};
const useCartStore = create<CartStore>((set) => ({
count: 0,
items: [],
addItem: (item) =>
set((state) => ({
items: [...state.items, item],
count: state.count + 1,
})),
removeItem: (item) =>
set((state) => ({
items: state.items.filter((i) => i !== item),
count: state.count - 1,
})),
}));Zustand의 핵심 장점은 네 가지입니다.
- 선택적 구독 —
state.count만 구독하면count가 바뀔 때만 렌더링. 다른 상태 변경에 반응하지 않음 - Provider 불필요 — 앱 최상단에 Provider를 감쌀 필요 없음. 스토어를 만들고 어디서든 바로 사용 가능
- 스토어 단위 분리 —
useCartStore,useUserStore,useUIStore처럼 기능별로 자연스럽게 나뉨 - TypeScript 친화적 — Generic 타입 하나로 자동 추론, 별도 타입 파일 불필요
5. 실전 코드 비교 — 같은 기능, 두 가지 방식
같은 "장바구니 카운터" 기능을 두 방식으로 구현해봅니다. 코드량과 구조의 차이를 직접 확인하세요.
📦 Context API 방식
// 1. Context 생성
const CartContext = createContext<{ count: number; add: () => void } | null>(null);
// 2. Provider 작성
export function CartProvider({ children }: { children: React.ReactNode }) {
const [count, setCount] = useState(0);
const add = () => setCount((c) => c + 1);
return (
<CartContext.Provider value={{ count, add }}>
{children}
</CartContext.Provider>
);
}
// 3. 커스텀 Hook 작성
function useCart() {
const ctx = useContext(CartContext);
if (!ctx) throw new Error('CartProvider 안에서 사용하세요');
return ctx;
}
// 4. 컴포넌트에서 사용
function CartBadge() {
const { count, add } = useCart();
return <button onClick={add}>장바구니 {count}</button>;
}
// 5. 앱 최상단에 Provider 감싸기 (잊으면 에러)
// <CartProvider><App /></CartProvider>🐻 Zustand 방식
// 1. 스토어 하나로 끝
const useCartStore = create<{ count: number; add: () => void }>((set) => ({
count: 0,
add: () => set((state) => ({ count: state.count + 1 })),
}));
// 2. 핵심: selector로 필요한 상태만 구독 (전체 구독 X)
function CartBadge() {
// ✅ count가 바뀔 때만 이 컴포넌트가 리렌더링됨
const count = useCartStore((state) => state.count);
const add = useCartStore((state) => state.add);
return <button onClick={add}>장바구니 {count}</button>;
}
// ⚠️ 이렇게 쓰면 안 됨 — store 전체를 구독해서 장점 사라짐
// const { count, add } = useCartStore(); ← 지양
// 💡 고급: 객체 여러 개를 한 번에 구독할 때는 shallow 비교 활용
import { shallow } from 'zustand/shallow';
function CartSummary() {
const { count, items } = useCartStore(
(state) => ({ count: state.count, items: state.items }),
shallow // 참조가 아닌 값 비교 → 불필요한 리렌더링 방지
);
return <div>{count}개 / {items.length}종</div>;
}📊 코드 비교 — Context: 약 25줄 (Provider + Hook + 타입 + 감싸기) → Zustand: 약 10줄. 같은 기능을 2배 이상 적은 코드로 구현하면서 선택적 구독까지 기본 제공합니다.
💡 실무에서 체감되는 차이
Context 방식의 문제
- 상태 하나 변경 → 관련 없는 컴포넌트도 리렌더링
- 성능 문제 발생 지점 추적 어려움
- 최적화하려면 Context 분리 + useMemo + selector 패턴 → 코드 복잡도 급증
Zustand 방식의 효과
- selector 단위로 구독 → 필요한 컴포넌트만 업데이트
- 성능 이슈 발생 지점이 명확하고 추적 쉬움
- 디버깅 난이도가 크게 낮아짐 → 개발 속도 향상
→ 실제 프로젝트에 적용해보면 이 차이가 훨씬 명확하게 느껴집니다. 특히 컴포넌트가 20개 이상 되는 순간, Zustand의 선택적 구독이 얼마나 강력한지 체감하게 됩니다.
6. Context vs Zustand 핵심 비교표
| 비교 항목 | Context API | Zustand |
|---|---|---|
| 제공 방식 | React 내장 | 외부 라이브러리 (~1KB) |
| 설정 난이도 | 중간 (보일러플레이트 多) | 매우 낮음 |
| 리렌더링 | 동일 Context 구독 컴포넌트 전체 | selector 구독 상태만 (선택적) |
| Provider 필요 | 필수 | 불필요 |
| 상태 분리 | 수동, 어려움 | 스토어 단위로 자연스럽게 |
| TypeScript | 타입 정의 직접 필요 | Generic으로 자동 추론 |
| 미들웨어 | 없음 | persist, devtools 지원 |
| 추천 규모 | 소형 / 정적 전역 값 | 중형 이상 / 동적 상태 |
💡 한 줄 정리 — Context는 "공유"에 가깝고, Zustand는 "관리"에 가깝다
🔧 Context도 최적화할 수 있습니다 — 하지만…
Context의 리렌더링 문제는 다음 방법으로 어느 정도 해결할 수 있습니다.
- Context 분리 — UserContext, ThemeContext, CartContext를 각각 나누기
- useMemo로 value 안정화 — 객체 참조 변경을 막아 불필요한 리렌더링 방지
- use-context-selector 라이브러리 — Zustand처럼 특정 상태만 구독 가능
⚡ 문제는 이 과정 자체가 복잡해진다는 것입니다. 최적화 코드를 추가할수록 오히려 가독성이 떨어지고 유지보수가 어려워집니다. 바로 이 복잡도의 한계가 Zustand를 도입하는 실질적인 이유입니다.
7. 2026년 React 상태관리 트렌드
2026년 현재 React 상태관리 생태계는 뚜렷한 방향성을 가지고 있습니다.
🔍 2026 핵심 변화
React Server Components(RSC)의 확산으로 서버 상태는 컴포넌트 자체에서 직접 처리하는 경향이 강해졌습니다. 이에 따라 클라이언트 상태관리의 범위가 줄어들었고, 남은 클라이언트 상태는 Zustand처럼 가볍고 빠른 도구로 처리하는 것이 주류가 되었습니다. "서버 상태와 클라이언트 상태를 명확히 분리하는 것"이 현대 React 아키텍처의 핵심 원칙입니다. Zustand는 클라이언트 상태에만 집중하고, 서버 데이터는 TanStack Query에게 맡기는 구조가 2026년 사실상의 표준입니다. Zustand는 Next.js App Router + RSC 환경과도 잘 호환됩니다.
8. 언제 무엇을 써야 하나? — 실무 판단 기준
질문 하나로 판단할 수 있습니다. "이 상태가 얼마나 자주 바뀌고, 몇 개의 컴포넌트가 사용하는가?"
✅ Context API를 선택하는 상황
- 변경이 드문 전역 설정값 (테마, 언어, 인증)
- 소규모 프로젝트로 빠르게 만들어야 할 때
- 외부 라이브러리 추가를 최소화해야 하는 환경
- 상태가 2~3개 이하이고 컴포넌트 깊이가 얕을 때
✅ Zustand를 선택하는 상황
- 자주 변경되는 상태 (장바구니, 실시간 알림, 모달/토스트 UI)
- 여러 컴포넌트에서 동시에 구독하고 업데이트하는 상태
- props drilling이 3단계 이상 깊어지기 시작할 때
- 상태 로직이 복잡해서 스토어로 분리 관리하고 싶을 때
- localStorage 지속성(persist 미들웨어)이 필요할 때
🏆 실무에서 가장 현실적인 전략
방법 1 (단계적 도입) — 처음엔 Context로 시작 → 복잡해지면 Zustand로 마이그레이션
방법 2 (역할 분리, 추천) — 테마·인증 같은 전역 설정 → Context / 장바구니·UI 상태·비즈니스 로직 → Zustand / API 서버 데이터 → TanStack Query
9. 초보자가 자주 저지르는 실수 3가지
❌ 실수 1 — Context에 모든 상태를 넣는다
자주 변경되는 상태를 Context에 넣으면 불필요한 리렌더링이 폭발적으로 늘어납니다. 장바구니 수량이 바뀔 때마다 앱 전체가 흔들립니다.
❌ 실수 2 — Zustand 스토어를 하나로 합친다
useAppStore 하나에 모든 상태를 몰아넣으면 Context 한계와 똑같은 문제가 생깁니다. 기능 단위로 스토어를 분리하세요. useCartStore, useUserStore, useUIStore처럼 나누는 것이 올바른 방향입니다.
❌ 실수 3 — API 데이터를 Zustand에 저장한다
서버에서 오는 데이터(게시글 목록, 유저 프로필 등)는 Zustand의 역할이 아닙니다. 로딩·캐싱·재요청 등을 수동으로 다 처리해야 해서 복잡도가 폭증합니다. 서버 상태는 TanStack Query(React Query)를 사용하고, Zustand는 순수한 클라이언트 UI 상태만 담당하게 하세요.
10. 면접에서 이렇게 답하면 됩니다
"Context API와 Zustand의 차이를 설명해보세요"라는 질문은 프론트엔드 면접에서 자주 등장합니다. 아래 답변 구조를 참고하세요.
💬 모범 답변 예시
"Context API는 React에 내장된 전역 상태 공유 도구로, 테마나 인증 정보처럼 자주 변경되지 않는 전역 값에 적합합니다. 다만 Context를 구독하는 컴포넌트들은 해당 Context의 value가 바뀌면 모두 리렌더링되기 때문에, 하나의 Context에 여러 상태를 묶으면 관련 없는 상태 변경에도 불필요한 재렌더링이 발생합니다. useMemo나 Context 분리로 최적화할 수 있지만, 이 과정 자체가 복잡해지는 것이 실질적인 한계입니다.
Zustand는 이 문제를 해결한 경량 상태관리 라이브러리로, selector를 통해 필요한 상태만 선택적으로 구독하기 때문에 불필요한 리렌더링이 발생하지 않습니다. Provider도 필요 없고 코드량도 훨씬 적어 중형 이상 프로젝트에서는 Zustand를 우선 검토합니다. 저는 전역 설정은 Context, 비즈니스 상태는 Zustand, 서버 데이터는 TanStack Query로 역할을 나누어 사용합니다. 이것이 2026년 현재 실무에서 가장 많이 쓰이는 React 상태관리 조합입니다."
✅ 실전 체크리스트 — 도구 선택 전 확인
- ☑상태가 자주 변경되는가? → Zustand 검토
- ☑상태를 3개 이상의 컴포넌트가 공유하는가? → Zustand 검토
- ☑테마·언어·인증처럼 거의 안 바뀌는 전역 값인가? → Context 적합
- ☑API에서 가져온 서버 데이터를 상태에 저장하려는가? → TanStack Query 사용
- ☑localStorage에 상태를 저장해야 하는가? → Zustand + persist 미들웨어
- ☑10명 이상 팀, 엄격한 상태 흐름이 필요한가? → Redux Toolkit 검토
🔑 핵심 정리
- Context API는 구린 도구가 아닙니다. 테마·인증·언어처럼 저빈도 전역 값에는 여전히 최적입니다
- Context의 핵심 한계는 리렌더링 제어 불가. 동일 Context를 구독하는 컴포넌트들이 관련 없는 상태 변경에도 함께 재렌더링됩니다
- Zustand는 selector 기반 선택적 구독으로 리렌더링 문제 해결. 주간 2,300만 다운로드로 2026년 가장 빠르게 성장 중 (
shallow비교로 추가 최적화 가능) - 서버 데이터(API 응답)는 Zustand가 아닌 TanStack Query로 별도 관리하는 것이 2026년 표준
- 실무 추천 조합: Context(전역 설정) + Zustand(클라이언트 상태) + TanStack Query(서버 상태)
- 도구 선택 기준은 "유행"이 아니라 "상태의 변경 빈도와 공유 범위"입니다
❓ 자주 묻는 질문 (FAQ)
Q1. React 소규모 프로젝트에서 Zustand와 Context API 중 뭘 먼저 배워야 하나요?
Context API를 먼저 이해하는 것을 추천합니다. React의 기본 개념이기 때문에 Zustand의 동작 원리를 이해하는 데도 도움이 됩니다. 실습 순서는 이렇게 권장합니다. ① useState로 로컬 상태 관리 → ② Context API로 전역 공유 경험 → ③ 리렌더링 문제를 직접 겪은 후 Zustand 도입. 문제를 먼저 경험하면 Zustand의 장점이 훨씬 선명하게 느껴집니다.
Q2. Zustand는 Next.js App Router(React Server Components) 환경에서도 사용 가능한가요?
사용 가능합니다. 단, Zustand는 클라이언트 사이드 도구이므로 사용하는 컴포넌트에 'use client' 지시어가 필요합니다. SSR 환경에서 서버 요청 간 상태가 공유되는 문제를 방지하려면, Zustand 공식 문서의 Next.js 가이드에 따라 createStore + Context Provider 패턴을 사용하는 것이 권장됩니다. Next.js 15·16과의 호환성은 검증되어 있습니다.
Q3. Context API의 리렌더링 문제를 useMemo로 해결할 수 없나요? 굳이 Zustand가 필요한가요?
useMemo와 Context 분리로 어느 정도 최적화는 가능하지만 한계가 있습니다. Context를 여러 개로 나누면 Provider 중첩이 늘어나고, useMemo로 value를 메모이제이션해도 참조 동일성 문제로 여전히 의도치 않은 리렌더링이 발생할 수 있습니다. 상태가 자주 변경된다면 최적화 코드를 추가하는 비용보다 Zustand를 도입하는 것이 생산성 면에서 훨씬 효율적입니다.
Q4. Zustand와 Redux를 함께 사용하는 프로젝트에서 마이그레이션하려면 어떻게 시작하면 좋나요?
점진적 마이그레이션을 추천합니다. 전체를 한 번에 바꾸려 하지 말고, Redux slice 하나를 Zustand store로 전환하는 것부터 시작하세요. 순서는 이렇습니다. ① Zustand 설치 → ② 가장 단순한 Redux slice를 Zustand store로 재작성 → ③ 해당 slice를 사용하는 컴포넌트를 Zustand hook으로 교체 → ④ Redux slice 제거. 이 과정을 반복하면서 Redux 의존성을 점진적으로 줄여나갈 수 있습니다.
NEXT STEP
상태 선택이 끝났다면, 이제 데이터 흐름을 설계할 차례입니다
Zustand로 클라이언트 상태를 정리했다면, 서버에서 오는 데이터는 어떻게 관리해야 할까요? React Query(TanStack Query)와의 역할 분리가 다음 핵심 주제입니다.
📌 이 글은 React 학습 시리즈 입니다
1편: TypeScript + React 입문 프로젝트 (Vite 기반) | 2편: Compound Component & Render Props
💡 실제 프로젝트에 적용해보면 Context와 Zustand의 차이가 훨씬 명확하게 느껴집니다
🔗 이전 글 (시리즈 연결)
✓ TypeScript + React 입문자를 위한 첫 프로젝트 만들기 (Vite 기반) · 2026 완전 가이드
✓ React 컴포넌트 설계 패턴 완전 입문 — Compound Component & Render Props
'AI' 카테고리의 다른 글
| 크롬 확장 프로그램 자동화 가이드 - Magical + Thunderbit 사용법 (1) | 2026.05.07 |
|---|---|
| React Custom Hook 설계 패턴 - 로직을 분리하고 재사용하는 실무 전략 (0) | 2026.05.06 |
| AI 고블린 문제, OpenAI가 밝힌 진짜 원인은 '버그'가 아니었다 (1) | 2026.05.05 |
| Cursor AI 단축키만 외우지 마세요 - 생산성 2배 올리는 고급 기능 총정리 (2) | 2026.05.04 |
| Claude Code 설치 후 바로 써먹는 실전 초기 세팅 완전 가이드 (0) | 2026.05.04 |