🧱 02. 핵심 개념과 기본 스토어 설계: "이 스토어, 너무 무겁지 않나요?"

🎯 이 섹션을 읽고 나면:

• Zustand의 create, set, get 동작 원리를 이해할 수 있다.
• Zustand set 의 얕은 병합과 중첩 객체(Nested Objects) 업데이트 시 불변성 규칙을 지킬 수 있다.

📋 목차

• 🤔 왜 알아야 하는가
• 🏗️ 1. 스토어의 탄생: create
  • 💡 create를 두 번 호출하는 커링(Currying) 패턴
• 🎯 2. 업데이트의 핵: set과 얕은 병합 (Shallow Merge)
  • 🚨 불변성의 함정: 중첩된 객체(Nested Objects)
• 🔍 3. 현재 상태를 훔쳐보는 get
• 🏋️‍♂️ 영철의 테스트 타임 (Q&A)

📌 이 문서를 읽기 전에

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

🗺️ 이 문서의 흐름
스토어 생성 원리(create) → 얕은 병합 업데이트(set) → 비동기 로직 내 상태 참조(get)

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

• 🐣 영철 ( 신입 ): "영호 리드 님! Zustand 모델링 엄청 직관적이네요. 신나서 커뮤니티 앱에 있는 유저 정보, 게시글 리스트, UI 테마, 글 작성 데이터까지 다 useAppStore 하나에 때려 박았어요! 어라, 근데 영수 님이 PR 보시더니 '왜 스토어가 모놀리식 백엔드 서버마냥 무겁냐'고 리뷰를 다셨어요..."
• 🦁 영호 ( 리드 ): "영철 님, 전역으로 뺀 거까진 좋았어요. 그런데 Zustand의 진짜 강력함은 그 가벼운 create 함수 안에 있어요. 객체를 뚱뚱하게 만들면 관리 포인트가 늘어나고, 불변성(Immutability) 업데이트도 점점 깊이 들어가는 늪(Depth Hell)이 됩니다. 기본 뼈대인 set과 get부터 단단하게 다져봅시다."

🤔 왜 알아야 하는가

Zustand를 처음 사용할 때 가장 많이 하는 실수는 '하나의 거대한 창고'를 만드는 것입니다. Redux의 Store 하나짜리 철학과 헷갈리기 때문입니다.

Zustand 스토어 안의 상태를 업데이트하는 함수(set)는 기존 상태를 기반으로 새로운 객체(참조)를 반환해야 리액트 트리에 변경을 알릴 수 있습니다. 스토어가 너무 거대하고 중첩(Nest)이 깊어지면, 스프레드 연산자(...) 지옥이 열리고 휴먼 에러로 참조 동일성(Reference Equality) 함정에 빠지기 쉽습니다.

'어떻게 스토어를 생성(create)하고, 값을 가져오고(get), 안전하게 업데이트할 것인가(set)'를 깊이 이해해야만 깃털처럼 가벼운 Zustand의 진짜 속도를 경험할 수 있습니다.

🏗️ 1. 스토어의 탄생: create

Zustand 스토어는 create 함수 하나로 만들어집니다. create는 콜백 함수를 인자로 받는데, 이 콜백은 set, get, api를 주입받아 객체(초기 상태와 액션)를 반환합니다.

// 🐣 영철: Zustand에서는 Reducer가 따로 없으니, 액션 함수도 바로 넣으면 되네요!
import { create } from 'zustand';
 
interface EditorState {
  title: string;
  content: string;
  wordCount: number;
  setTitle: (title: string) => void;
  setContent: (content: string) => void;
}
 
export const useEditorStore = create<EditorState>()((set, get) => ({
  title: '',
  content: '',
  wordCount: 0,
  
  setTitle: (title) => set({ title }), // 💡 얕은 병합!
  setContent: (content) => {
    // 💡 get()으로 현재 상태를 읽어올 수 있어요!
    const currentWordCount = content.trim().split(/\s+/).length;
    set({ content, wordCount: currentWordCount });
  },
}));

💡 create를 두 번 호출하는 커링(Currying) 패턴

위 TypeScript 예제에서 <EditorState>()(...) 처럼 괄호가 연속되는 패턴을 볼 수 있습니다. 이는 Zustand가 타입 추론을 완벽하게 돕기 위해 빈 인자로 한 번 호출하고, 그다음 진짜 스토어 정의를 받는 커링(Currying) 기법입니다. (TS를 쓸 때만 등장하는 괴상한 괄호의 정체입니다.)

🎯 2. 업데이트의 핵: set과 얕은 병합 (Shallow Merge)

set 함수는 Zustand의 알파이자 오메가입니다.

React의 useState에서 배열 훅(setState)을 사용할 때 1차원(Root 레벨) 상태 필드들은 어떤가요? 기존 상태를 다 복사(...prev)해서 넣어줘야 했습니다.

그런데 Zustand의 set은 기본적으로 최상위(1st level) 속성들에 대해 얕은 병합(Shallow Merge) 을 알아서 해줍니다.

// 🦁 영호: Zustand는 똑똑해요. 명시한 필드만 덮어쓰고 나머지는 건들지 않아요.
const useUserStore = create((set) => ({
  name: '영철',
  level: 1,
  
  // ⛔ useState 방식 (불필요한 중복)
  levelUpBad: () => set((state) => ({ ...state, level: state.level + 1 })),
  
  // ✅ Zustand 방식 (자동 얕은 병합)
  levelUpGood: () => set((state) => ({ level: state.level + 1 })),
}));

🚨 불변성의 함정: 중첩된 객체(Nested Objects)

얕은 병합은 최상위 뎁스(Depth 1)에서만 안전합니다. 중첩된 속성을 업데이트할 때는 반드시 깊은 복사를 수동으로 해줘야 합니다. 안 그러면 참조가 끊겨 컴포넌트 리렌더링이 발생하지 않습니다.

// 😡 영수: "영철 님! 프로필 사진 바꿨는데 왜 헤더 이미지는 안 바뀌어요?!"
 
const useDeepStore = create((set) => ({
  user: {
    name: '영철',
    profile: { url: 'old.jpg', badge: 'junior' }
  },
  
  // ❌ 끔찍한 실수 (참조 동일성 깨짐, 불변성 위반)
  updateProfileBad: (newUrl) => set((state) => {
    state.user.profile.url = newUrl; // Mutation! 리액트가 변화를 감지 못함
    return { user: state.user }; 
  }),
 
  // ✅ 안전한 불변성 업데이트 (스프레드 지옥)
  updateProfileSpread: (newUrl) => set((state) => ({
    user: {
      ...state.user,
      profile: {
        ...state.user.profile,
        url: newUrl
      }
    }
  }))
}));

🦁 영호의 한마디: "이래서 스토어를 모놀리식하게 짜면 유지보수가 박살 난다는 겁니다. 깊이가 2뎁스 이상 들어가면 Immer 미들웨어를 쓰거나, 스토어 자체를 납작(Flat)하게 설계하세요."

🔍 3. 현재 상태를 훔쳐보는 get

액션 함수 내부에서 상태를 읽어야 할 때나, 이전 상태 값을 계산에 사용해야 할 때는 get()을 꺼내 씁니다. 만약 비동기 함수(API 호출 등) 뒤에 최신 상태가 필요하다면 get()은 필수입니다.

const useCounterStore = create((set, get) => ({
  count: 0,
  submitScore: async () => {
    const currentCount = get().count; // 💡 비동기 작업 직전 스냅샷 읽기
    await api.post('/score', { score: currentCount });
    
    // 만약 여기서 다시 get()을 하면 API 대기 중 변한 최신 값을 얻을 수 있음.
  }
}));

📝 마무리 퀴즈

Q1. Zustand의 set 함수가 기본적으로 제공하는 상태 업데이트 방식은 무엇인가요?

• A) 무조건 전체 상태를 새로 교체해야 한다.
• B) 깊은 불변성(Deep Immutability) 보장
• C) 최상위 뎁스(Depth 1)에 대한 얕은 병합 (Shallow Merge)
• D) React의 useState 배열 업데이트 방식과 완전 동일

✅ 정답: C

💡 상세 해설:

• 원리 설명: Zustand의 set은 객체를 반환할 때 기존 상태 최상위(1st level) 필드들에 대해 자동으로 얕은 병합을 해줍니다. 덕분에 ...state 같은 스프레드 연산자를 매번 적을 필요가 없습니다.
• 오답 피드백: "영철 님, Zustand가 마법사는 아니에요. 중첩 객체 깊은 곳까지 알아서 병합해주지 않으니 2뎁스부터는 조심해야 합니다."
• 📌 핵심 기억법: 🦁 영호: "Zustand의 set은 겉도는 1차원만 알아서 병합해주는 친절한 도구입니다."

Q2. 비동기 통신(API 호출) 중에 최신 상태를 읽어와야 할 때 가장 올바른 Zustand 사용법은 무엇인가요?

• A) 스토어 외부에 전역 변수를 만들어서 참조한다.
• B) 콜백으로 주입되는 get 함수(get())를 호출하여 현재 스냅샷을 찍어온다.
• C) React의 useRef를 빌려서 스토어에 연결해둔다.
• D) set 함수를 강제로 호출해서 리렌더링을 발생시킨 뒤 상태를 받아온다.

✅ 정답: B

💡 상세 해설:

• 원리 설명: 스토어를 생성할 때 create((set, get) => ...) 형태로 get이 함께 제공됩니다. 액션 함수나 비동기 로직 중간에 현재 상태값을 읽어야 할 때는 get()을 호출하면 즉시 최신 상태를 확인할 수 있습니다.
• 오답 피드백: "영철 님, 전역 상태를 쓸 때는 철저하게 제공된 도구(get)만 활용해야지 외부 변수나 React 훅(useRef)에 의존하면 스파게티 코드가 됩니다."
• 📌 핵심 기억법: 🦁 영호: "값이 궁금하면 훔쳐보는 게 아니라 당당하게 get()을 요청하세요."

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

영철이가 쇼핑몰 장바구니 기능을 만들면서 cart 배열 안에 있는 특정 아이템의 수량(quantity)만 증가시키려고 합니다. 스토어 상태 구조는 { cart: [{ id: 1, qty: 1 }] } 입니다. 어떻게 set을 호출해야 안전하게 리액트 화면에 반영될까요?

✅ 정답: map 메서드 등을 이용해 수정되는 아이템의 새로운 객체 참조를 만들어 불변성을 유지하며 cart 배열 전체를 업데이트한다.

💡 상세 해설:

• 원리 설명: Zustand 최상위의 cart 키 자체는 얕은 병합을 지원하지만, 그 내부 배열의 요소가 가진 중첩된 객체를 직접 수정(item.qty++)하면 원본 객체를 변이(Mutation)시키는 꼴이 됩니다. 얕은 비교(!==)를 기반으로 리렌더링을 트리거하는 Zustand와 React는 객체의 내장 주소값이 똑같으니 화면을 다시 그리지 않습니다.
• 오답 피드백: "영철 님, item.qty = newValue 처럼 찌르는 방식은 배열 안에 지뢰를 심는 행위예요. 반드시 전개 연산자나 불변성 유틸리티 함수(Immer 등)를 적용해야 합니다."
• 📌 핵심 기억법: 🦁 영호: "Zustand의 set은 편판(1차원)에만 자동 병합 마법을 부려줍니다. 서랍 안의 보석함 내용물을 바꿀 때는 보석함 모양 전체를 새로 짜서 교체하세요."

🐣 영철이의 퇴근 일기

오늘도 영호 리드 님한테 깊은 복사 실수로 혼났다. 프로필 이미지가 안 바뀌어서 백엔드 캐시 문제인 줄 알고 영수 님한테 따지러 갈 뻔했는데, 내 Zustand 로직이 Mutations 범벅이었다니 식은땀이 쫙 났다. state.user.profile.url = '...' 이거 내가 Vanilla JS 하던 버릇이 아직도 남아있었네 ㅠㅠ 내일은 이 깊은 뎁스를 컴포넌트 단위나 도메인 단위로 평탄화(Flat)하는 법을 제대로 여쭤봐야겠다. 집 가서 씻고 유튜브로 Zustand 불변성 강의 하나만 더 보고 자야지. 파이팅 영철!

💡 "상태를 깊숙이 파고들수록 스프레드 연산자의 저주가 시작된다. 납작(Flat)한 스토어가 생명 연장의 꿈!"