🛡️ 04. Zustand와 TypeScript: "타입 추론이 왜 자꾸 깨지죠?"

🎯 이 섹션을 읽고 나면:

• Zustand create 함수의 커링(Currying) 문법 원리를 이해하고 정확한 위치에 타입을 주입할 수 있다.
• 미들웨어(DevTools, Persist 등) 적용 시 타입스크립트가 왜 고장 나는지 원리를 파악하고 픽스할 수 있다.
• StateCreator 타입을 활용해 쪼개진 슬라이스(Slice) 스토어에 완벽한 타입 체계를 구축할 수 있다.

📋 목차

• 🤔 왜 알아야 하는가
• 🏗️ 1. 영철이의 마법의 (오답) 코드
  • ❌ 제네릭 직접 주입 실패 (오답)
  • ✅ 커링 패턴: 괄호를 두 번 치세요 (정답)
• 💎 2. 통곡의 벽: 미들웨어 파티와 타입 지옥
  • ❌ 미들웨어가 추가되면서 터지는 코드
• 🧩 3. 5년 차의 비기: StateCreator 로 슬라이스 조립하기
  • ✅ StateCreator 모듈화 병법 (최종 정답 코드)
• 🏋️‍♂️ 영철의 테스트 타임 (Q&A)

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 12분 / 핵심 파트: 7분

🗺️ 이 문서의 흐름
create 함수 기본 타입 주입(Currying) → 미들웨어 적용 시 타입 이슈 해결 → StateCreator를 이용한 조립식 Slice 타입 지정

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

• 🐣 영철 ( 신입 ): "리드 님! 어제 알려주신 대로 Zustand를 도입했는데 빨간 줄이 너무 그어져요. set(state => ...) 할 때 state가 자꾸 any 타입이라고 에러를 뱉어서, 일단 귀찮아서 // @ts-ignore 떡칠해두고 퇴근했습니다 하하!"
• 🦁 영호 ( 리드 ): "영철 님... 프론트엔드 개발자에게 any는 마약과도 같습니다. 당장은 편하지만 나중에 유지보수 할 때 내 코드가 나를 찌르는 칼이 돼요. Zustand가 제공하는 타입 제네릭 구조만 한 번 딱 이해하면, 자동 완성(IntelliSense)의 황홀함을 맛보게 될 겁니다. 빨간 줄 지우러 가봅시다."

🤔 왜 알아야 하는가

Zustand는 원래 생 자바스크립트(Vanilla JS)를 위해 아주 가볍게 디자인된 라이브러리였습니다. TypeScript를 지원하긴 하지만, 객체를 반환하는 create 함수의 독특한 구조와 여러 미들웨어를 겹겹이 감싸는(Wrapping) 특성 때문에 타입스크립트 엔진이 한 번에 모든 타입을 추론하지 못하는 병목 구간이 존재합니다.

1년 차 프론트엔드 개발자가 가장 많이 겪는 Zustand의 좌절 구간이 바로 "미들웨어 하나 추가했더니 스토어 전체 타입이 빨간 불로 터져버리는 현상" 입니다. 이 고비만 넘기면 5년 차 개발자처럼 빈틈없는 인프라 코드와 환상적인 자동 완성 경험을 동료들에게 제공할 수 있습니다.

🏗️ 1. 영철이의 마법의 (오답) 코드

❌ 제네릭 직접 주입 실패 (오답)

interface MyStore {
  count: number;
  increment: () => void;
}
 
// 🐣 영철: "제네릭 배웠다! create 뒤에 붙이면 되겠지?"
const useStore = create<MyStore>((set) => ({
  count: 0,
  // 🚨 에러 발생! set 타입이 고장 나면서 state가 unknown 또는 any로 빠짐
  increment: () => set((state) => ({ count: state.count + 1 })), 
}));

Zustand의 타입 선언부를 뜯어보면, create 함수는 미들웨어 체이닝을 위해 내부적으로 커링(Currying) 이라는 구조로 짜여 있습니다. 함수를 호출하면 또 다른 함수가 반환되는 형태죠. 제네릭을 그냥 <MyStore> 하나만 던지면 타입 검사기가 길을 잃습니다.

✅ 커링 패턴: 괄호를 두 번 치세요 (정답)

// 🦁 영호: "create<Type>()() <- 이렇게 빈 괄호를 먼저 호출한 뒤에 함수를 여세요."
const useStore = create<MyStore>()((set) => ({
  count: 0,
  // 💡 완벽하게 추론됨! 이제 마우스 올리면 state.count 가 number로 인식!
  increment: () => set((state) => ({ count: state.count + 1 })),
}));

이 텅 빈 ()가 Zustand 타이핑의 가장 큰 진입 장벽이자 핵심 열쇠입니다. 이 빈 괄호가 제네릭 타입의 스코프를 닫아주고, 뒤이어 오는 화살표 함수에 온전한 타입을 물려줍니다.

💎 2. 통곡의 벽: 미들웨어 파티와 타입 지옥

영철이가 앱을 런칭하고 나서 상태 추적을 위해 devtools를, 새로고침 백업을 위해 persist 미들웨어를 덕지덕지 붙이기 시작했습니다.

❌ 미들웨어가 추가되면서 터지는 코드

import { devtools, persist } from 'zustand/middleware';
 
// 🐣 영철: "미들웨어로 스토어 감쌌더니 아까 기껏 맞춘 타입이 또 다 박살 났어요 ㅠㅠ"
const useStore = create<MyStore>()(
  devtools(
    persist(
      (set) => ({
        count: 0,
        increment: () => set((state) => ({ count: state.count + 1 })),
      }),
      { name: 'my-storage' }
    )
  )
);

에러가 터지는 이유는 간단합니다. 미들웨어 박스 하나를 포장할 때마다 Zustand 내부적으로 요구하는 Mutators (변형기) 시그니처가 달라지기 때문입니다. 하지만 5년 차들은 당황하지 않고 마법의 빈 괄호 규칙만 기억합니다. "제네릭은 맨 처음 딱 한 번만 정의한다" 는 원칙 말이죠.

위 코드는 사실 문법적으론 틀린 게 없지만, TypeScript 4.x/5.x 환경에서 가끔 set 파라미터단에서 에러로 식별될 때가 있습니다. ( Zustand 버전에 따라 다릅니다. )
이럴 때 가장 우아하고 확실하게 타입 에러를 무력화하는 방법이 바로 StateCreator 를 분리해서 사용하는 것입니다.

🧩 3. 5년 차의 비기: StateCreator 로 슬라이스 조립하기

이전 가이드 03. 슬라이스 패턴 에서 뚱뚱한 스토어를 기능별로 분리했던 것 기억나시나요?
실무에서는 Zustand 타입을 설계할 때, 생성 단계를 두 개로 나눕니다.

1. 설계도 그리기 (StateCreator): 오직 타입과 초기 구조만 정의
2. 조립하기 (create): 여러 미들웨어 필드를 버무려서 최종 승인

✅ StateCreator 모듈화 병법 (최종 정답 코드)

import { create, StateCreator } from 'zustand';
import { devtools, persist } from 'zustand/middleware';
 
// 1. 타입 명세서
interface AuthSlice {
  isLogged: boolean;
  login: () => void;
}
 
// 2. 🦁 영호: 슬라이스의 모양(뼈대)을 StateCreator로 굳혀버립니다.
// 이때 미들웨어 배열 식별자를 제네릭 뒤에 달아주면 완벽한 타입 호환을 이룹니다.
const createAuthSlice: StateCreator<
  AuthSlice, 
  [["zustand/devtools", never], ["zustand/persist", unknown]]
> = (set) => ({
  isLogged: false,
  login: () => set({ isLogged: true }, false, "login"), // devtools를 위한 액션 라벨링 "login"
});
 
 
// 3. 메인 스토어 조립 (TypeScript가 더 이상 혼란을 겪지 않습니다)
export const useAuthStore = create<AuthSlice>()(
  devtools(
    persist(createAuthSlice, { name: 'auth-storage' })
  )
);

이 패턴의 핵심은, "타입스크립트에게 내가 앞으로 이 뼈대에 무슨 미들웨어(devtools, persist)를 바를 건지 제네릭으로 미리 귓뜸을 해두는 것" 입니다. [["zustand/devtools", never], ["zustand/persist", unknown]] 이 다소 투박해 보일 수 있지만, 공식 문서에서 권장하는 가장 빈틈없는 미들웨어 타이핑 전략입니다.

📝 마무리 퀴즈

Q1. Zustand의 create 함수에 제네릭 타입을 주입할 때 올바른 문법은 무엇인가요?

• A) create<MyStore>((set) => ...)
• B) create((set) => ...)<MyStore>
• C) create<MyStore>()((set) => ...)
• D) create<MyStore>()

✅ 정답: C

💡 상세 해설:

• 원리 설명: Zustand의 create 함수는 커링(Currying) 패턴으로 작성되어 있어, 빈 괄호 ()를 한 번 더 호출해서 타입 추론 범위를 닫아주어야 뒤따라오는 화살표 함수 콜백에서 상태(state)의 타입이 올바르게 추론됩니다.
• 오답 피드백: "영철 님, A번처럼 쓰면 set 내부에서 타입스크립트가 길을 잃고 any 잔치를 벌이게 됩니다. 빈 괄호 하나가 자동 완성을 살려줍니다!"
• 📌 핵심 기억법: 🦁 영호: "제네릭을 썼으면, 빈 괄호로 한 번 쉬고 가야 코드가 안 깨집니다."

Q2. 슬라이스 패턴을 구현하거나 미들웨어를 여러 개 겹칠 때 타입 붕괴를 막기 위해 Zustand가 권장하는 타입 헬퍼는 무엇인가요?

• A) CombineState
• B) StateCreator
• C) StoreApi
• D) ZustandSlice

✅ 정답: B

💡 상세 해설:

• 원리 설명: 미들웨어가 추가될 때마다 요구하는 타입 시그니처가 변동되는데, 스토어 정의 뼈대 자체를 StateCreator로 미리 타입 선언해두면 create 함수 내부에서 미들웨어를 아무리 감싸도 타입이 견고하게 유지됩니다.
• 오답 피드백: "영철 님, 미들웨어 때문에 빨간 불이 들어온다면 스토어 로직을 밖으로 빼서 StateCreator로 옷을 먼저 입혀주세요."
• 📌 핵심 기억법: 🦁 영호: "StateCreator는 Zustand 스토어의 무적 방패입니다."

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

영철이가 Slice 패턴으로 유저 스토어와 장바구니 스토어 두 개를 결합하여 거대한 useBoundStore를 만들려고 합니다. 둘이 타입을 제대로 합치려면 메인 스토어의 create 함수 제네릭에 어떻게 적어줘야 할까요?

✅ 정답: create<UserSlice & CartSlice>()(...) 처럼 인터섹션(&)을 사용한다.

💡 상세 해설:

• 원리 설명: 객체 인터페이스들을 하나로 융합할 때는 TypeScript의 인터섹션 타입(&) 을 사용해야 합니다. Zustand의 메인 스토어는 각 슬라이스들이 제공하는 상태와 액션 메서드가 합쳐진 거대한 하나의 거인 객체가 됩니다. 따라서 UserSlice & CartSlice 가 되어야 스토어 내부에서 state.userName 과 state.cartItems 를 모두 자동 완성받을 수 있습니다.
• 오답 피드백: "영철 님, | (Union) 를 쓰면 유저 스토어 거나 장바구니 둘 중 하나란 소리니까 교집합 성질에 의해 둘 다 공통으로 가진 프로퍼티(거의 없음)만 쓸 수 있게 돼요. 무조건 &로 합치세요!"
• 📌 핵심 기억법: 🦁 영호: "슬라이스는 개별 StateCreator<자신타입>, 합치는 공장은 create<A & B & C>()"

🐣 영철이의 퇴근 일기

오늘도 영호 리드 님이 내 등짝을 때렸다. // @ts-ignore 를 스토어 파일 윗줄에 10개나 달아놓은 걸 들켰기 때문이다. 하지만 오늘 Zustand 타입 선언법을 제대로 배우고 나니까, VSC에서 속성값을 타이핑할 때마다 바로 나타나는 자동 완성을 보며 눈물이 날 뻔했다. 이래서 다들 TypeScript를 쓰는구나! 제네릭 괄호가 좀 징그러워 보일 때도 있지만, 한번 세팅해두면 1년은 편하다는 말이 진짜인 것 같다. 내 스토어에도 이제 '안전 제일' 딱지가 붙었다!

💡 "create<Type>()(...) 빈 괄호의 마법을 잊지 말자. 미들웨어가 낄 때는 StateCreator로 뼈대부터 탄탄히 만들자."