🧠 01. Zustand 멘탈 모델: 리렌더링 폭탄에서 탈출하기

🎯 이 섹션을 읽고 나면:

• Context API의 구조적 한계와 리렌더링 폭발의 원인을 이해할 수 있다.
• Zustand의 핵심인 '독립적인 스토어'와 '선택적 구독(Select)' 멘탈 모델을 장착할 수 있다.

📋 목차

• 🤔 왜 알아야 하는가
• 🏗️ 1. Context API의 한계와 Zustand의 철학
  • Context API의 '넓은 공격 범위'
  • Zustand의 '정밀 타격(Select)'
• 🧠 2. 리액트 바깥의 독립적인 스토어
• 🎯 3. Action과 State의 공존
• 🏋️‍♂️ 영철의 테스트 타임 (Q&A)

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 10분 / 핵심 파트: 5분

🗺️ 이 문서의 흐름
Context API의 한계점 확인 → Zustand의 정밀 타격 모델 이해 → 스토어의 독립성 파악

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 🐣 영철 ( 신입 ): "저희 커뮤니티 앱 헤더에 유저 프로필 아이콘 띄우려고 UserContext를 만들었거든요? 근데 로그인 상태 관리하려고 감싼 건데, 헤더뿐만 아니라 하위의 메인 피드까지 계속 리렌더링이 일어나요. 컨텍스트를 도메인별로 다 쪼개야 할까요? Redux는 세팅이 너무 복잡해서 무서워요..."
• 🦁 영호 ( 리드 ): "영철 님, Context API로 전역 상태를 통제하려는 시도 자체는 좋은 출발이에요. 하지만 Context는 값 하나가 바뀌면 하위 트리를 무조건 렌더링시키는 구조적 한계가 있죠. 무조건 큰 망치(Redux)를 꺼낼 필요는 없어요. 아주 가볍지만 강력한 저격총, Zustand를 쥐어 드릴게요."

🤔 왜 알아야 하는가

React의 기본 스토리지인 useState와 Context API는 지역적인 상태 관리나 '자주 변하지 않는 값(예: 테마)'을 내려주기엔 훌륭합니다. 하지만 유저 정보 인증 상태, 모달 열림 여부, 작성 중인 폼 임시 데이터 등 빈번하게 변하고 애플리케이션 전역에서 읽고 써야 하는 클라이언트 상태를 Context API로 다스리려면, 'Provider 지옥'과 불필요한 리렌더링 폭발이라는 페인 포인트를 피할 수 없습니다.

반대로 기존의 Redux는 강력하지만, 하나의 상태를 추가하기 위해 Action Type, Action Creator, Reducer까지 세팅해야 하는 거대한 보일러플레이트가 영철이 같은 주니어의 기동성을 떨어뜨립니다.

이때 Zustand가 등장합니다. 독일어로 '상태'를 뜻하는 이 라이브러리는 Redux의 장점인 단방향 데이터 흐름을 계승하면서도, 보일러플레이트를 0에 수렴하게 만들고 컴포넌트 생명주기 바깥에 스토어를 위치시킴으로써 리렌더링 폭발을 원천 봉쇄합니다.

🏗️ 1. Context API의 한계와 Zustand의 철학

Zustand를 이해하려면, 먼저 우리가 왜 기존 도구에서 불편함을 느꼈는지 되짚어봐야 합니다.

Context API의 '넓은 공격 범위'

Context API는 Provider 내부의 컴포넌트들이 useContext를 통해 값을 읽습니다. 문제는 Provider의 value가 변경되면, 해당 컨텍스트를 구독하는 모든 하위 컴포넌트가 리렌더링된다는 점입니다.

// 🐣 영철: 상태 하위 구조 중 theme만 쓰고 싶은데, user가 바뀌어도 저까지 리렌더링 돼요!
const { theme } = useContext(AppStoreContext); 

Zustand의 '정밀 타격(Select)'

Zustand는 이와 달리, 렌더링 생태계 바깥(React 외곽) 에 거대한 보관소를 만듭니다. 그리고 컴포넌트가 그 보관소 안의 특정 값 하나만 콕 집어서(Select) 구독할 수 있게 해줍니다.

// 🦁 영호: Zustand로는 'theme'만 구독할 수 있어요. user가 바뀌어도 얘는 조용합니다.
const theme = useAppStore((state) => state.theme);

이것이 Zustand의 핵심 멘탈 모델입니다. 단일 스토어(Single Source of Truth)를 유지하되, 구독은 컴포넌트가 각자 필요한 곳에만 얇게 바르는 것(Selector).

🧠 2. 리액트 바깥의 독립적인 스토어

Zustand가 다른 React 전용 상태 관리 라이브러리와 차별화되는 가장 큰 특징은 스토어가 컴포넌트 트리에 종속되지 않는다는 것입니다.

Redux나 Context API는 반드시 애플리케이션 최상단에 <Provider>로 앱을 감싸야 합니다. 이 말은 상태가 React 트리의 맥락(Context) 안에 갇혀 있다는 뜻입니다.

반면 Zustand 스토어는 순수한 JavaScript 클로저 기반으로 만들어집니다.

// 🐣 영철: Provider가 없어요?! 그럼 언제 어디서 이 상태를 쓰죠?
import { create } from 'zustand';
 
export const useBearStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
  removeAllBears: () => set({ bears: 0 }),
}));

• <Provider> 트리로 감쌀 필요가 없으므로 앱 진입점이 깔끔해집니다.
• 가장 강력한 점: React 컴포넌트가 아닌 순수 JS 함수(예: Axios 인터셉터 내부, 웹소켓 유틸 함수 안)에서도 저장소의 값을 직접 읽고(useBearStore.getState()) 업데이트(useBearStore.setState()) 할 수 있습니다.

🎯 3. Action과 State의 공존

Redux 멘탈 모델에 익숙한 사람들을 괴롭히는 것은 상태 보관 공간(Reducer)과 상태를 업데이트하는 함수(Action/Dispatch)를 분리해야 한다는 강박입니다.

Zustand는 이 둘을 한 공간에 둡니다. 상태 값(bears)과 그 값을 바꾸는 함수(increasePopulation)가 하나의 스토어 오브젝트 안에 동거합니다.

// 🦁 영호: Zustand는 상태 보관 박스 안에, 그 박스를 조작하는 명세서(함수)도 같이 넣어두는 방식이에요.
const bears = useBearStore((state) => state.bears); // 상태만 쏙!
const increasePopulation = useBearStore((state) => state.increasePopulation); // 함수만 쏙!

이로 인해 코드를 따라가며 역추적(Debugging)하는 과정이 단일 파일 안에서 끝나며, 코드량이 획기적으로 줄어듭니다.

📝 마무리 퀴즈

Q1. Context API의 가장 큰 구조적 단점은 무엇인가요?

• A) 하위 컴포넌트 트리를 구성하기 위해 Provider가 필수적이지 않다.
• B) 구독 중인 상태의 특정 값이 아니라, 객체의 참조가 바뀌면 해당 Context를 읽는 모든 하위 컴포넌트가 리렌더링된다.
• C) Redux보다 보일러플레이트 코드가 많아 설정이 복잡하다.
• D) 외부(React 트리 바깥) 스토리지와의 연동이 불가능하다.

✅ 정답: B

💡 상세 해설:

• 원리 설명: Context API는 value 프로퍼티로 전달되는 값이 변경되면 useContext를 호출하는 모든 자식 컴포넌트를 리렌더링합니다. 특정 프로퍼티만 골라서 구독(Select)하는 기능이 내장되어 있지 않습니다.
• 오답 피드백: "영철 님, Context는 값을 묶어서 던지는 광역 마법이에요. A, C, D는 다 틀린 설명입니다. 오히려 보일러플레이트가 적고 직관적이지만 정밀 타격이 안 되는 게 문제죠."
• 📌 핵심 기억법: 🦁 영호: "Context는 스위치 하나 켜면 집안 전체 불이 깜빡거리는 구조입니다."

Q2. Zustand 스토어의 가장 큰 특징이자 장점은 무엇인가요?

• A) React의 Context API를 내부적으로 사용하여 구현되었다.
• B) 애플리케이션 최상단에 반드시 <Provider>를 선언해야만 작동한다.
• C) 상태 변경을 위한 Reducer 함수를 강제하여 단방향 데이터 흐름을 엄격하게 지킨다.
• D) 스토어가 React 컴포넌트 트리 바깥(독립된 클로저)에 존재하며, 필요한 상태만 선택적(Selector)으로 구독할 수 있다.

✅ 정답: D

💡 상세 해설:

• 원리 설명: Zustand는 내부적으로 클로저와 구독(Publish/Subscribe) 패턴을 이용해 React 트리 바깥에 스토어를 만듭니다. 덕분에 Provider가 필요 없고, 순수 JS 함수에서도 스토어 접근이 가능합니다.
• 오답 피드백: "영철 님, 상태 관리를 꼭 React 안에 가둬놓을 필요는 없어요. 바깥에 빼면 오히려 자유로워져요!"
• 📌 핵심 기억법: 🦁 영호: "Zustand는 React 컴포넌트들이 언제든 전화해서 물어볼 수 있는 '바깥 사무실'입니다."

Q3. 🏋️‍♂️ 영철의 테스트 타임 (Q&A)

영철이가 커뮤니티 게시글 목록 뷰를 만들면서, Context API로 로그인 유저 정보를 뿌려주고 있습니다. 다른 컴포넌트에서 글 작성 모달 상태 정보를 추가하자마자, 로그인 유저 컨텍스트를 바라보던 게시글 목록이 리렌더링되기 시작했습니다. 영철이가 Zustand로 이 상황을 해결한다면 어떤 원리를 통해 리렌더링을 막을 수 있을까요?

✅ 정답: Selector(선택적 구독)를 통해 필요한 상태만 잘라서 사용한다.

💡 상세 해설:

• 원리 설명: Context API는 value 객체 참조가 바뀌면 하위 트리를 무조건 리렌더링시킵니다. 하지만 Zustand는 useStore((state) => state.user) 처럼 상태의 특정 파편(Slice)만 선택(Select)하여 구독합니다. Zustand 내부는 이 선택된 값이 바뀔 때만 리액트에 렌더링 신호를 보내기 때문에, 모달 상태가 변경되어도 유저 정보만 구독 중인 컴포넌트는 재평가되지 않습니다.
• 오답 피드백: "영철 님, Context 안에서 메모이제이션(useMemo)을 열심히 거는 건 임시방편이에요. 애초에 감시 초소를 스위치 하나 단위로 좁히는 Zustand의 Selector 패턴이 더 근본적인 성능 개선책이랍니다."
• 📌 핵심 기억법: 🦁 영호: "Zustand는 뷔페에서 원하는 접시만 퍼오는 거고, Context API는 뷔페 식탁을 통째로 쏟아놓고 네가 알아서 골라 먹으라는 방식입니다."

🐣 영철이의 퇴근 일기

맨날 최상단에 Provider 박아넣고 "왜 다 리얼타임으로 깜빡거리지?" 절망했던 날들은 이제 안녕이다! 전역 상태를 리액트 바깥에 스토어로 빼버리니까 파일 구조도 오히려 훨씬 시원해졌다. 내일은 이 곰팡이 난 Context 로직들 싹 다 Zustand로 마이그레이션 해야지. 그나저나 퇴근길에 마라탕에 꿔바로우 먹고 싶은데, 영호 리드 님이랑 같이 갈까 물어볼까. (아마 원리 설명하시며 거절하시겠지 🤔)

💡 "상태 관리는 앱을 커다란 보자기로 감싸는 게 아니라, 필요한 컴포넌트에만 얇은 파이프라인을 꽂아 넣는 것이다."