🍕 03. 다중 스토어 vs 슬라이스 패턴: 스토어를 조립식으로 쪼개기

🎯 이 섹션을 읽고 나면:

• 비대해진 스토어를 관심사(도메인)별로 분리하는 조각(Slice) 패턴을 구현할 수 있다.
• 여러 개의 Store를 남발했을 때의 치명적 단점(좀비 상태)을 이해한다.
• 여러 개의 Slice를 하나로 결합하고, Slice 간에 상태를 교차 참조(통신)하는 방법을 배운다.

📋 목차

• 🤔 도입: 스토어가 너무 뚱뚱해졌어요!
• 🚨 1. 주니어의 실수: 다중 스토어 (Multiple Stores)
• 💡 2. 해결책: 슬라이스 패턴 (Slice Pattern) 도입
  • Step 1: 관심사 분리 (조각 내기)
  • Step 2: 메인 스토어 조립 (Bound Store)
• ⚒️ 3. 슬라이스 간의 우아한 통신
• 📝 마무리 퀴즈
• 🐣 영철이의 퇴근 일기

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 15분 / 핵심 파트: 8분

🗺️ 이 문서의 흐름
스토어 비대화 원인 파악 → 다중 스토어 패턴의 실패 구경 팝콘 뜯기 → 슬라이스 분리 및 결합 → 교차 참조 해결법

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

• 🐣 영철 ( 신입 ): "영호 리드 님, 어제 말씀하신 대로 스토어 뎁스를 깊게 안 파려고 노력 중인데요. 그러다 보니까 전체 상태를 들고 있는 useAppStore.ts 파일이 500줄이 넘어갔어요! 이거 도메인별로 파일 분리해야 할 것 같은데... 그냥 스토어(create)를 여러 개 따로 만들면 안 될까요?"
• 🦁 영호 ( 리드 ): "영철 님, 스토어 파일이 무거워지는 건 좋은 신호(?)입니다. 상태 관리가 중앙집중화되고 있다는 뜻이니까요. 하지만 말씀하신 대로 이대로 두면 유지보수가 불가능해집니다. 그렇다고 무작정 Store를 여러 개로 찢어발기면 진짜 지옥이 펼쳐집니다. 오늘은 상태를 물리적으로 쪼개되, 개념적으로는 하나로 묶어내는 '슬라이스 패턴(Slice Pattern)'을 배울 차례군요."

🤔 도입: 스토어가 너무 뚱뚱해졌어요!

Zustand로 앱을 구축하다 보면, 하나의 파일 안에 인증(Auth), 장바구니(Cart), UI 테마(Theme) 등 온갖 상태가 다 섞이는 순간이 옵니다.

// 🐣 영철: 파일 하나에 다 때려박았더니 코드가 500줄이 넘어갔어요...
export const useStore = create((set) => ({
  user: null, // 유저 기능
  login: () => { ... },
  
  isDarkMode: false, // UI 기능
  toggleTheme: () => { ... },
  
  cartItems: [], // 장바구니 기능
  addItem: () => { ... },
}));

코드가 너무 길어지면 당연히 분리가 필요합니다. 이때 개발자들은 두 가지 갈림길에 섭니다.

1. "그냥 create를 여러 번 써서 스토어를 여러 개 만들자!" (다중 스토어)
2. "하나의 스토어 안에서 기능별로 블록을 조립하자!" (슬라이스 패턴)

결론부터 말하면 실무 아키텍처에서는 전자를 안티 패턴, 후자를 권장 패턴으로 여깁니다. 왜 그런지 비교해봅시다.

🚨 1. 주니어의 실수: 다중 스토어 (Multiple Stores)

Zustand가 너무 간결하다 보니 많은 주니어들이 이런식으로 객체를 남편/아내처럼 완전히 갈라놓습니다.

// store/userStore.ts
export const useUserStore = create((set) => ({ user: null }));
 
// store/cartStore.ts
export const useCartStore = create((set) => ({ cartItems: [] }));

얼핏 보면 아주 깔끔해 보입니다. 도메인별로 파일이 나뉘었으니까요. 하지만 **"유저가 로그아웃하면 장바구니도 비워져야 한다"**는 기획팀의 요구사항이 들어오는 순간, 지옥문이 열립니다.

❌ 안티 패턴: 강제 동기화 (좀비 useEffect의 탄생)

서로 남남이 된 스토어들은 서로의 내부를 조작할 수 없습니다. 결국 불쌍한 'UI 컴포넌트'가 중간다리 역할을 떠맡게 됩니다.

// ⚠️ 나쁜 예: TopNav 컴포넌트가 비즈니스 로직(스토어 간 동기화)을 떠안음
const TopNav = () => {
  const { user, logout } = useUserStore();
  const { clearCart } = useCartStore();
 
  const handleLogout = () => {
    logout();     // 1. 유저 스토어 변경
    clearCart();  // 2. 카트 스토어 변경 (UI가 왜 이런 것까지 책임져야 하죠?)
  };
  
  // 💀 더 최악인 경우:
  useEffect(() => {
    if (!user) clearCart(); 
  }, [user]); // 버그의 온상! 사이드 이펙트로 억지 동기화
}

이 방식은 치명적입니다.

1. 비즈니스 로직 파편화: 로그아웃 시 일어나는 일이 TopNav 파일 안에 숨어버립니다.
2. 순환 참조 에러: 나중에는 스토어 파일끼리 억지로 import를 하다가 무한 루프 에러(Circular Dependency)를 마주합니다.
3. 디버깅 헬: Redux DevTools를 달아도, 스토어가 찢어져 있어서 앱 전체의 상태 변화를 '비디오 돌려보듯' 한눈에 감시할 수 없습니다.

🦁 영호의 조언: "영철 님, 우리 프로덕트처럼 '유저 상태'나 'UI 상태'가 장바구니 등 앱 곳곳에 얽히는 거미줄 구조라면, 상태를 결코 남남처럼 찢어서는 안 됩니다. 하나의 몸통(Single Truth)을 유지한 채 팔다리를 모듈로 분리해야 합니다."

💡 2. 해결책: 슬라이스 패턴 (Slice Pattern) 도입

Redux 시절부터 내려온 근본 있는 아키텍처인 Slice(조각) 패턴이 정답입니다. 기능별 조각(Slice)을 별도의 파일이나 함수로 독립시키되, 마지막에 메인 스토어(useBoundStore) 단 한 곳에서 합치는 방식입니다.

Step 1: 관심사 분리 (조각 내기)

각 Slice는 Zustand가 제공하는 특별한 제네릭인 StateCreator를 사용하여 정의합니다. 여기서 cartSlice는 자기가 맡은 일방만 묵묵히 구현합니다.

// features/cart/cartSlice.ts
import { StateCreator } from 'zustand';
 
export interface CartSlice {
  cartItems: string[];
  addItem: (item: string) => void;
  clearCart: () => void; // 🐣 영철: 카트 비우는 능력치군요!
}
 
// 🦁 영호: 이 함수는 아직 'Store'가 아닙니다. 그저 '상태 조작 설명서'에 불과해요.
export const createCartSlice: StateCreator<CartSlice> = (set) => ({
  cartItems: [],
  addItem: (item) => set((state) => ({ cartItems: [...state.cartItems, item] })),
  clearCart: () => set({ cartItems: [] }), 
});

유저 슬라이스도 똑같이 분리합니다.

// features/user/userSlice.ts
import { StateCreator } from 'zustand';
 
export interface UserSlice {
  user: string | null;
  login: (name: string) => void;
}
 
export const createUserSlice: StateCreator<UserSlice> = (set) => ({
  user: null,
  login: (name) => set({ user: name }),
});

Step 2: 메인 스토어 조립 (Bound Store)

이제 흩어진 파일들을 중앙 통제소 폴더(store/)의 useBoundStore.ts로 수집합니다. 바인드(Bound) 스토어란, 모든 슬라이스가 최종적으로 '묶인' 스토어를 의미합니다.

// store/useBoundStore.ts
import { create } from 'zustand';
import { UserSlice, createUserSlice } from '../features/user/userSlice';
import { CartSlice, createCartSlice } from '../features/cart/cartSlice';
 
// 1. 타입 합치기 (Intersection Type)
// 🐣 영철: 여기서 타입들을 '+' 기호처럼(&) 합치는군요!
export type StoreState = UserSlice & CartSlice;
 
// 2. Zustand 본체(create) 하나만 생성하기
// 🦁 영호: set, get 인자를 각각의 Slice 함수에 그대로 토스(Toss)합니다.
export const useBoundStore = create<StoreState>()((...a) => ({
  ...createUserSlice(...a),
  ...createCartSlice(...a),
}));

UI 컴포넌트는 오직 이 useBoundStore 하나만 import해서 쓰면 됩니다. 단일 스토어의 장점(안정성, 통합 디버깅)과 다중 스토어의 장점(코드 모듈화)을 완벽히 흡수한 아키텍처입니다!

⚒️ 3. 슬라이스 간의 우아한 통신

이제 앞서 다중 스토어(Multiple Stores) 파트에서 실패했던, "로그아웃하면 장바구니도 같이 초기화된다" 코드를 슬라이스 패턴 안에서 해결해 볼 차례입니다.

Zustand의 useState 안에는 사실 set 말고도 숨겨진 get 변수가 있습니다. 바인드 스토어로 합쳐진 상태에서는 get()을 호출하면 다른 슬라이스의 존재를 인지하고 명령을 내릴 수 있습니다.

// features/user/userSlice.ts
import { StateCreator } from 'zustand';
import { StoreState } from '../../store/useBoundStore'; // 💡 앗! 전체 타입을 가져오네요?
 
export interface UserSlice {
  user: string | null;
  login: (name: string) => void;
  logout: () => void;
}
 
// ✨ 좋은 예: Slice 내부에서 교차 참조 (get)
// 🦁 영호: StateCreator 제네릭이 <전체스토어, 미들웨어1, 미들웨어2, 현재슬라이스> 순서로 확장됩니다.
export const createUserSlice: StateCreator<
  StoreState, // 1. 전체 스토어 모델 (get()으로 다른 슬라이스 참조 필수)
  [],         // 2. 추가 미들웨어 등 (없으면 빈 배열)
  [],         // 3. 추가 미들웨어 등 (없으면 빈 배열)
  UserSlice   // 4. 이 슬라이스 본인의 타입 지정
> = (set, get) => ({
  user: null,
  login: (name) => set({ user: name }),
  logout: () => {
    set({ user: null });          // 내 방(User)청소 완료!
    get().clearCart();            // 다른 방(Cart) 불도 안전하게 꺼버리기! ✅
  },
});

너무 아름답지 않나요? TopNav 같은 UI 컴포넌트는 그저 logout() 하나만 호출하면 됩니다. 비즈니스 로직이 UI 밖으로 완벽히 빠져나와 순수하게 Store 내부에서만 통신이 이루어집니다.

🌟 디자인 원칙:
다만 Slice 간 결합도가 너무 높아지면 스파게티 코드가 됩니다. "로그아웃 시 카트 비우기" 정도의 단방향 흐름은 좋지만, 카트 슬라이스가 다시 유저 슬라이스를 건드리는 식의 탁구(Ping-Pong) 결합은 절대 피해야 합니다.

📝 마무리 퀴즈

Q1. 여러 개의 create 스토어를 마구잡이로 만들었을 때(다중 스토어) 발생하는 가장 치명적인 문제는 무엇인가요?

• A) 폴더 구조가 지저분해진다.
• B) 각 스토어 간의 상태를 동기화하기 위해 컴포넌트 레벨에 억지 코드를 짜야 하고, 순환 참조 에러가 일어날 확률이 높다.
• C) 성능이 단일 스토어보다 느리다.
• D) 타입스크립트를 사용할 수 없다.

✅ 정답: B

💡 상세 해설:

• 원리 설명: 상태를 분리하는 건 좋지만 물리적인 그릇(create) 자체를 쪼개버리면 자바스크립트는 파일 간 문맥이 단절됩니다. 결국 중간에서 컴포넌트가 useEffect로 두 스토어를 잇는 징검다리 노릇을 강제받으며 버그의 온상이 됩니다.
• 오답 피드백: "영철 님, 기능마다 useFooStore, useBarStore 만들다가 로딩 상태 공유하려다 밤새신 적 있죠? 그게 다중 스토어의 함정입니다."
• 📌 핵심 기억법: 🦁 영호: "작은 톱니바퀴 여러 개를 만드는 데 그치면 각자 따로 놉니다. 톱니를 나눠 깎더라도 하나의 시계판(Bound Store) 위에 올려야 정확한 시너지를 내는 법이죠."

Q2. 슬라이스(Slice) 간 교차 참조를 통해 상대방 슬라이스의 함수를 실행시키려면 어떤 방법을 써야 하나요?

• A) 상대 코드를 파일 상단에 import 해서 직접 create 인스턴스를 조작한다.
• B) UI쪽 상위 페이지에서 부모 컴포넌트에 Context Provider를 씌워 함수를 물려받는다.
• C) StateCreator를 만들 때 인자로 받아오는 get() 함수를 호출하여 전체 컨텍스트에 접근한다.
• D) Redux 미들웨어를 무조건 설치해야 한다.

✅ 정답: C

💡 상세 해설:

• 원리 설명: 슬라이스 생성 함수(StateCreator)는 묶여진 전체 스토어(StoreState)의 타입 컨텍스트 위에서 정의됩니다. 따라서 내부의 get() 함수를 호출하면 다른 슬라이스의 상태를 읽을 수 있고, set()을 통해 수정도 가능합니다.
• 오답 피드백: "영철 님, 슬라이스를 조각냈다고 서로 소통이 끊기는 게 아니에요. 톱니바퀴들은 get이라는 축으로 마법처럼 연결되어 있습니다."
• 📌 핵심 기억법: 🦁 영호: "다른 부서(Slice) 서류가 필요할 때 가장 빠른 출입문은 get()입니다."

Q3. [영철이의 테스트 타임: 라이브러리 트레이드오프]
이번 신규 프로젝트에서 PM 영수님이 "유저 인증 정보, 로컬 폼 임시 저장, 장바구니 데이터를 각각 로컬스토리지에 저장하고 싶은데요. Zustand 쓰기로 했죠?" 라고 요구하셨습니다. 만일 영철이가 다중 스토어 3개를 생성했고 영호가 1개의 슬라이스 패턴 묶음 스토어를 생성했다면, 미들웨어(persist) 연동 시 코드 복잡도 면에서 어떤 극명한 차이가 날까요?

✅ 정답: 다중 스토어는 3개의 스토어에 각각 개별적으로 persist 미들웨어 코드를 감싸줘야 하지만, 슬라이스 패턴은 합쳐진 메인 useBoundStore 한 곳에 단 한 번만 미들웨어를 입히면 3개 슬라이스 모두에 영속성이 일괄 적용된다.

💡 상세 해설:

• 원리 설명: 미들웨어(저장소 연동, 디버그, 로깅 등)는 스토어의 파이프라인 역할을 합니다. 단일 진실 공급원(Single Source of Truth)을 유지하면 확장이 무척 쉽습니다. BoundStore 한 번만 선언해주면 그 아래에 조립된 모든 모듈이 공통 미들웨어의 수혜를 받습니다.
• 오답 피드백: "영철 님, 미들웨어 3번 복붙하는 거 은근히 피곤하지 않으셨어요? 한 방에 끝내는 게 고수의 길입니다."
• 📌 핵심 기억법: 🦁 영호: "단일 뼈대(BoundStore)를 구축하면 갑옷(미들웨어)을 한 벌만 맞춰 입어도 온몸이 방어됩니다."

🐣 영철이의 퇴근 일기

와. 오늘 기존 500줄짜리 useAppStore.ts 코드를 슬라이스로 쪼갰다!
처음엔 "그냥 create 여러 번 쓰면 되는 거 아냐?" 라고 반항했다가, 영호 리드 님이 보여주신 '좀비 useEffect 나비효과'를 보고 소름이 돋았다.

기능을 찢을 때는 완전히 박살을 내는 게 아니라 레고 블록처럼 분해했다가, useBoundStore라는 넓은 판에 다시 꼭꼭 꽂아 넣는 거였구나! 제일 짜릿했던 건 get().clearCart()로 쪼개진 남의 슬라이스 기능까지 스토어 내부에서 고상하게 컨트롤할 때였다. 어설프게 UI 컴포넌트에서 비즈니스 로직을 동기화하던 짓은 이제 영원히 안녕이다!

내일은 퇴근하고 모처럼 치맥 한 잔 시원하게 걸치며, 깔끔하게 정리된 스토어 폴더를 감상해봐야겠다 🍗🍺!

💡 "상태를 조각(Slice)처럼 나누되, 물리적으론 쪼개지 말고 메인 스토어라는 하나의 레고판에 끼워 맞추자."