Step 02: Zustand 상태관리 — 수동 직렬화 vs 자동 하이드레이션

예상 시간: 6분

Step 02: Zustand 상태관리 — 수동 직렬화 vs 자동 하이드레이션

PM 요청 (김도연)

"준혁님, 안녕하세요! 이번에 사용자 정보를 서버에서 가져와서 전역 상태로 관리하고 싶어요. 팀에서 Zustand를 쓰기로 했는데, Express랑 Next.js에서 어떻게 다르게 작동하는지 궁금합니다. 둘 다 React를 쓰는 건 똑같은데, 뭐가 다를까요?"

시니어 멘토링 (이준혁)

핵심 질문부터 던져보자

"좋아, 도연씨. 질문 하나 할게. SSR을 하면 서버에서 HTML을 만들어서 보내잖아? 그럼 서버에서 만든 상태와 클라이언트에서 만드는 상태가 같다는 걸 어떻게 보장하지?"

"음... 서버에서 데이터를 가져와서 렌더링하면 클라이언트에서도 같은 데이터로 렌더링해야 하는데... 어떻게 전달하나요?"

"바로 그거야! 이게 SSR에서 상태관리의 핵심 문제야."

SSR에서 상태관리의 근본 문제

"Zustand 같은 상태관리 라이브러리를 SSR에서 쓰려면 3단계 과정이 필요해:

서버에서 Store 생성 → 데이터 채우기
상태를 클라이언트로 전송 (이게 핵심!)
클라이언트에서 Store 재생성 → 같은 데이터로 초기화

이 과정을 **Hydration(수화)**이라고 불러. 서버에서 만든 '마른' HTML에 클라이언트가 '물'을 부어서 살아있는 React 앱으로 만드는 거지."

┌─────────────────────────────────────────────────────────────┐
│ 서버 (Node.js)                                               │
│                                                              │
│  1. Store 생성                                               │
│     { user: "김영빈", theme: "dark" }                        │
│                                                              │
│  2. React 렌더링 → HTML                                      │
│     <div>안녕, 김영빈</div>                                   │
│                                                              │
│  3. 상태 직렬화                                              │
│     JSON.stringify(state) → '{"user":"김영빈",...}'          │
│                                                              │
│  4. HTML에 주입 ⬇                                            │
└─────────────────────────────────────────────────────────────┘
                             │
                    <script>
                      window.__INITIAL_STATE__ = {...}
                    </script>
                             │
┌─────────────────────────────────────────────────────────────┐
│ 클라이언트 (Browser)                                          │
│                                                              │
│  1. window.__INITIAL_STATE__ 읽기                            │
│     JSON.parse() → { user: "김영빈", ... }                   │
│                                                              │
│  2. Store 재생성                                             │
│     create((set) => ({ user: "김영빈", ... }))               │
│                                                              │
│  3. hydrateRoot()                                            │
│     서버 HTML과 비교 → 일치 확인 ✓                            │
│                                                              │
│  4. Interactive App! 🎉                                      │
└─────────────────────────────────────────────────────────────┘

"이 파이프라인에서 상태가 하나라도 안 맞으면 Hydration Mismatch 에러가 터져. React가 '서버가 보낸 HTML'과 '클라이언트가 렌더링한 HTML'을 비교했는데 다르다는 거지."

Express + Zustand: 배관공이 되어보자

"Express에서는 이 모든 걸 직접 만들어야 해. 하나씩 배관을 연결해보자."

1단계: Store Factory 패턴 (필수!)

// stores/userStore.js
import { create } from 'zustand';
 
// ❌ 잘못된 방법: 전역 store
// export const useUserStore = create((set) => ({ ... }));
// → 요청 A의 데이터가 요청 B에 남아있음!
 
// ✅ 올바른 방법: Factory 함수
export const createUserStore = (initialState = {}) =>
  create((set) => ({
    user: initialState.user || null,
    theme: initialState.theme || 'light',
    isLoggedIn: initialState.user !== null,
 
    setUser: (user) => set({ user, isLoggedIn: user !== null }),
    setTheme: (theme) => set({ theme }),
    logout: () => set({ user: null, isLoggedIn: false }),
  }));

"왜 Factory 패턴이 필수냐고? 서버는 동시에 여러 요청을 처리하잖아. 만약 전역 store를 쓰면:

// 시간 순서:
// 1. 사용자 A 요청 → store.user = "김영빈"
// 2. 사용자 B 요청 → store.user = "이도연" (덮어쓰기!)
// 3. 사용자 A 응답 전송 → "이도연"이 보임 😱

이게 바로 개인정보 보안 사고야. 각 요청마다 독립된 store를 만들어야 해."

2단계: 서버 배관 코드

// server.js
import express from 'express';
import React from 'react';
import { renderToString } from 'react-dom/server';
import { createUserStore } from './stores/userStore.js';
import { StoreProvider } from './contexts/StoreContext.jsx';
import HomePage from './pages/HomePage.jsx';
 
const app = express();
 
app.get('/', async (req, res) => {
  try {
    // 1️⃣ 서버에서 데이터 fetch
    const userId = req.cookies.userId;
    const user = await db.users.findById(userId);
    const preferences = await db.preferences.findByUserId(userId);
 
    // 2️⃣ 이 요청 전용 store 생성 (격리!)
    const store = createUserStore({
      user: user ? { id: user.id, name: user.name } : null,
      theme: preferences?.theme || 'light',
    });
 
    // 3️⃣ React 렌더링
    const html = renderToString(
      React.createElement(StoreProvider, { store },
        React.createElement(HomePage)
      )
    );
 
    // 4️⃣ 상태 직렬화 — 핵심 배관!
    const initialState = store.getState();
 
    // ⚠️ 함수는 직렬화 불가 → 제거
    const serializableState = {
      user: initialState.user,
      theme: initialState.theme,
      isLoggedIn: initialState.isLoggedIn,
      // setUser, setTheme 등 함수는 제외!
    };
 
    // 5️⃣ XSS 방지: JSON.stringify 결과를 안전하게 이스케이프
    const stateJSON = JSON.stringify(serializableState)
      .replace(/</g, '\\u003c')
      .replace(/>/g, '\\u003e')
      .replace(/&/g, '\\u0026');
 
    // 6️⃣ HTML 완성
    res.send(`<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="UTF-8">
  <title>My App</title>
</head>
<body>
  <div id="root">${html}</div>
  <script>
    window.__INITIAL_STATE__ = ${stateJSON};
  </script>
  <script src="/public/react-bundle.js"></script>
</body>
</html>`);
  } catch (error) {
    console.error('SSR Error:', error);
    res.status(500).send('Server Error');
  }
});
 
app.listen(3000);

"여기서 주의할 점이 3가지야:

위험 1: 함수 직렬화

// ❌ 이렇게 하면 함수가 [Function] 문자열로 변환됨
JSON.stringify(store.getState());
 
// ✅ 데이터만 추출
const { user, theme, isLoggedIn } = store.getState();
JSON.stringify({ user, theme, isLoggedIn });

위험 2: XSS 공격

// 만약 user.name = "</script><script>alert('hacked!')</script>" 라면?
// → HTML이 깨지고 악성 스크립트 실행!
 
// 해결: JSON.stringify 결과를 이스케이프
.replace(/</g, '\\u003c') // < → \u003c

위험 3: 요청 격리 실패

// ❌ 전역 store
const globalStore = create(...);
app.get('/', (req, res) => {
  globalStore.setState({ user: ... }); // 다른 요청과 섞임!
});
 
// ✅ 요청별 store
app.get('/', (req, res) => {
  const store = createUserStore(...); // 독립!
});
```"
 
#### 3단계: 클라이언트 배관 코드
 
```javascript
// client/react-entry.jsx
import React from 'react';
import { hydrateRoot } from 'react-dom/client';
import { createUserStore } from '../stores/userStore.js';
import { StoreProvider } from '../contexts/StoreContext.jsx';
import HomePage from '../pages/HomePage.jsx';
 
// 1️⃣ 서버가 주입한 상태 읽기
const initialState = window.__INITIAL_STATE__;
 
if (!initialState) {
  console.error('초기 상태가 없습니다! SSR 배관을 확인하세요.');
}
 
// 2️⃣ 클라이언트 store 생성 (서버와 동일한 데이터로!)
const store = createUserStore(initialState);
 
// 3️⃣ Hydration
hydrateRoot(
  document.getElementById('root'),
  <StoreProvider store={store}>
    <HomePage />
  </StoreProvider>
);

Context Provider (공통 코드)

// contexts/StoreContext.jsx
import React, { createContext, useContext } from 'react';
 
const StoreContext = createContext(null);
 
export function StoreProvider({ store, children }) {
  return (
    <StoreContext.Provider value={store}>
      {children}
    </StoreContext.Provider>
  );
}
 
export function useStore() {
  const store = useContext(StoreContext);
  if (!store) {
    throw new Error('useStore must be used within StoreProvider');
  }
  return store;
}

컴포넌트에서 사용

// pages/HomePage.jsx
import React from 'react';
import { useStore } from '../contexts/StoreContext.jsx';
 
export default function HomePage() {
  const store = useStore();
  const user = store(state => state.user);
  const theme = store(state => state.theme);
  const setTheme = store(state => state.setTheme);
 
  return (
    <div className={`theme-${theme}`}>
      <h1>안녕하세요, {user?.name || '게스트'}님!</h1>
      <button onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>
        테마 변경
      </button>
    </div>
  );
}

"자, 이제 전체 배관이 완성됐어. 총 6개 파일, 약 150줄의 배관 코드가 필요하지. 이게 Express SSR의 현실이야."

Next.js + Zustand: 자동 배관의 마법

"Next.js는 어떨까? 같은 기능을 구현해보자."

1단계: 일반 Zustand Store (Factory 불필요!)

// stores/userStore.ts
import { create } from 'zustand';
 
interface User {
  id: string;
  name: string;
}
 
interface UserStore {
  user: User | null;
  theme: 'light' | 'dark';
  isLoggedIn: boolean;
  setUser: (user: User | null) => void;
  setTheme: (theme: 'light' | 'dark') => void;
  logout: () => void;
}
 
// ✅ 전역 store로 선언해도 OK!
// → 클라이언트에서만 실행되므로 요청 격리 문제 없음
export const useUserStore = create<UserStore>((set) => ({
  user: null,
  theme: 'light',
  isLoggedIn: false,
 
  setUser: (user) => set({ user, isLoggedIn: user !== null }),
  setTheme: (theme) => set({ theme }),
  logout: () => set({ user: null, isLoggedIn: false }),
}));

"왜 전역 store를 써도 되냐고? Next.js의 Client Component는 브라우저에서만 실행되거든. 서버에서는 실행 안 돼."

2단계: Server Component (데이터 fetch)

// app/page.tsx
import { cookies } from 'next/headers';
import { db } from '@/lib/db';
import HomeClient from './HomeClient';
 
// 이건 서버에서만 실행됨! (Client Component 아님)
export default async function HomePage() {
  // 1️⃣ 서버에서 데이터 fetch
  const cookieStore = cookies();
  const userId = cookieStore.get('userId')?.value;
 
  const user = userId ? await db.users.findById(userId) : null;
  const preferences = userId ? await db.preferences.findByUserId(userId) : null;
 
  // 2️⃣ Client Component에 props로 전달
  // → Next.js가 자동으로 직렬화/역직렬화!
  return (
    <HomeClient
      initialUser={user ? { id: user.id, name: user.name } : null}
      initialTheme={preferences?.theme || 'light'}
    />
  );
}

3단계: Client Component (상태 초기화)

// app/HomeClient.tsx
'use client';
 
import { useEffect } from 'react';
import { useUserStore } from '@/stores/userStore';
 
interface HomeClientProps {
  initialUser: { id: string; name: string } | null;
  initialTheme: 'light' | 'dark';
}
 
export default function HomeClient({ initialUser, initialTheme }: HomeClientProps) {
  const { user, theme, setUser, setTheme } = useUserStore();
 
  // 1️⃣ 마운트 시 서버 데이터로 초기화
  useEffect(() => {
    setUser(initialUser);
    setTheme(initialTheme);
  }, [initialUser, initialTheme, setUser, setTheme]);
 
  // 2️⃣ 렌더링
  return (
    <div className={`theme-${theme}`}>
      <h1>안녕하세요, {user?.name || '게스트'}님!</h1>
      <button onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>
        테마 변경
      </button>
      {user && (
        <button onClick={() => useUserStore.getState().logout()}>
          로그아웃
        </button>
      )}
    </div>
  );
}

"끝이야. 3개 파일, 약 60줄. Express의 절반도 안 되지?"

왜 이렇게 간단하지? — 자동화의 비밀

"도연씨, Next.js가 자동으로 해주는 걸 정리해볼까?"

1. 자동 직렬화 (RSC Payload)

// Server Component
return <ClientComponent data={complexObject} />;
 
// Next.js가 내부적으로:
// 1. complexObject를 직렬화 (JSON)
// 2. 특수 포맷(RSC Payload)으로 변환
// 3. HTML과 함께 전송
// 4. 클라이언트에서 자동 역직렬화
// 5. Props로 주입
 
// Express에서는 이걸 JSON.stringify + window.__STATE__ + JSON.parse로 직접 구현!

2. 자동 XSS 방지

// Next.js
<ClientComponent user={user} />
// → Props는 자동으로 이스케이프됨
 
// Express
const userJSON = JSON.stringify(user)
  .replace(/</g, '\\u003c') // 수동 이스케이프!
  .replace(/>/g, '\\u003e');

3. 자동 요청 격리

// Next.js: Server Component는 요청마다 새로 실행
export default async function Page() {
  const data = await fetch(...); // 요청마다 독립적!
  return <Client data={data} />;
}
 
// Express: 수동으로 store를 매번 생성해야 함
app.get('/', (req, res) => {
  const store = createStore(); // 수동 격리!
});

4. 자동 타입 안전성

// Next.js: Server → Client props 타입 체크
interface Props {
  user: User | null; // TypeScript가 검증
}
 
// Express: window.__STATE__는 any 타입
const state = window.__INITIAL_STATE__; // any!

배관 비교표: Express vs Next.js

단계	Express (수동 배관)	Next.js (자동 패턴)	절감 효과
Store 생성	Factory 패턴 필수`createUserStore()` 함수	일반 전역 store`useUserStore`	코드 20줄 → 0줄
데이터 fetch	`async (req, res) =>` 내부	`async function Page()`	동일
상태 직렬화	`JSON.stringify(getState())`함수 제거 수동	자동 (RSC 직렬화)Props 전달만	배관 코드 불필요
HTML 주입	`<script>window.__STATE__=...</script>`	불필요 (Props로 전달)	HTML 조작 0줄
XSS 방지	수동 이스케이프`.replace(/</g, ...)`	자동 처리	보안 코드 5줄 → 0줄
클라이언트 파싱	`window.__INITIAL_STATE__JSON.parse`	Props 자동 전달	파싱 코드 불필요
Store 초기화	`createUserStore(state)`	`useEffect + setUser`	패턴만 다름
요청 격리	수동 (Factory 필수)실수 시 보안 사고	자동 (SC는 요청별 실행)	사고 위험 ↓
타입 안전성	`any` (window 객체)	TypeScript Props 체크	런타임 에러 ↓
총 코드량	~150줄 (6개 파일)	~60줄 (3개 파일)	60% 감소
버그 위험도	⚠️⚠️⚠️ 높음(XSS, 격리 실패 등)	✅ 낮음(프레임워크 보장)	안정성 ↑

실전 시나리오: 인증 상태 관리

"실제 프로젝트에서 자주 쓰는 패턴을 보여줄게."

Express 버전

// server.js
app.get('/dashboard', async (req, res) => {
  // 인증 체크
  const token = req.cookies.token;
  if (!token) {
    return res.redirect('/login');
  }
 
  const user = await verifyToken(token);
  if (!user) {
    return res.redirect('/login');
  }
 
  // Store 생성
  const store = createUserStore({ user });
 
  // 추가 데이터 fetch
  const [posts, notifications] = await Promise.all([
    db.posts.findByUserId(user.id),
    db.notifications.findByUserId(user.id),
  ]);
 
  // Store 업데이트
  store.setState({
    posts,
    notifications,
    unreadCount: notifications.filter(n => !n.read).length,
  });
 
  // 렌더링 + 직렬화
  const html = renderToString(
    React.createElement(StoreProvider, { store },
      React.createElement(Dashboard)
    )
  );
 
  const stateJSON = JSON.stringify({
    user: store.getState().user,
    posts: store.getState().posts,
    notifications: store.getState().notifications,
    unreadCount: store.getState().unreadCount,
  }).replace(/</g, '\\u003c');
 
  res.send(`<!DOCTYPE html>...`);
});

Next.js 버전

// app/dashboard/page.tsx
import { redirect } from 'next/navigation';
import { cookies } from 'next/headers';
import { verifyToken } from '@/lib/auth';
import { db } from '@/lib/db';
import DashboardClient from './DashboardClient';
 
export default async function DashboardPage() {
  // 인증 체크
  const token = cookies().get('token')?.value;
  if (!token) redirect('/login');
 
  const user = await verifyToken(token);
  if (!user) redirect('/login');
 
  // 병렬 데이터 fetch
  const [posts, notifications] = await Promise.all([
    db.posts.findByUserId(user.id),
    db.notifications.findByUserId(user.id),
  ]);
 
  // Props로 전달 (자동 직렬화!)
  return (
    <DashboardClient
      user={user}
      posts={posts}
      notifications={notifications}
      unreadCount={notifications.filter(n => !n.read).length}
    />
  );
}

"코드 길이가 반으로 줄었지? 그리고 실수할 여지도 줄었어. JSON.stringify 깜빡하면? XSS 이스케이프 빼먹으면? Next.js는 그런 걱정이 없어."

언제 Express를 써야 할까?

"그럼 Express는 무조건 나쁜 거냐고? 아니야. 각자 쓸 곳이 있어."

상황	Express 유리	Next.js 유리
기존 Node.js 서버 있음	✅ 통합 쉬움	❌ 별도 앱 필요
다른 백엔드(Python 등)	✅ API 모드 사용	⚠️ API Routes 제한적
WebSocket, SSE	✅ 완전한 제어	⚠️ Route Handlers로 가능하나 제약
복잡한 미들웨어	✅ Express 생태계	⚠️ Middleware 제한적
SSR 상태관리	❌ 수동 배관	✅ 자동화
파일 기반 라우팅	❌ 수동 구현	✅ 내장
TypeScript 통합	⚠️ 수동 설정	✅ 기본 지원
SEO 최적화	⚠️ 수동 구현	✅ Metadata API
러닝 커브	✅ 낮음 (자유도 높음)	⚠️ 높음 (규칙 많음)

"결론: 단순 API 서버나 레거시 통합은 Express. 풀스택 SSR 앱은 Next.js가 압도적으로 유리해."

디버깅 팁: Hydration Mismatch 해결

"배관 작업하다 보면 꼭 이 에러를 만나게 돼:

Warning: Text content did not match. Server: "김영빈" Client: "null"

원인 3가지야:"

원인 1: 초기화 타이밍

// ❌ 잘못된 클라이언트 코드
const store = createUserStore(); // 빈 상태로 생성!
const initialState = window.__INITIAL_STATE__;
store.setState(initialState); // 늦게 업데이트
 
// → 첫 렌더링 시 빈 상태 → Mismatch!
 
// ✅ 올바른 순서
const initialState = window.__INITIAL_STATE__;
const store = createUserStore(initialState); // 바로 초기화

원인 2: 랜덤 값 (Date, Math.random 등)

// ❌ 컴포넌트에서 Date 사용
function Post() {
  const now = new Date(); // 서버/클라이언트 시간 다름!
  return <div>{now.toISOString()}</div>;
}
 
// ✅ 서버에서 생성 후 Props로 전달
// Server
const createdAt = new Date().toISOString();
return <Post createdAt={createdAt} />;
 
// Client
function Post({ createdAt }) {
  return <div>{createdAt}</div>; // Props 사용
}

원인 3: 브라우저 전용 API

// ❌ 서버에서 실행 불가
function Profile() {
  const width = window.innerWidth; // ReferenceError!
  return <div>Width: {width}</div>;
}
 
// ✅ useEffect로 클라이언트에서만 실행
function Profile() {
  const [width, setWidth] = useState(0);
 
  useEffect(() => {
    setWidth(window.innerWidth);
  }, []);
 
  return <div>Width: {width || 'Loading...'}</div>;
}

성능 비교: 실제 측정 결과

"우리 팀에서 같은 페이지를 두 방식으로 만들어봤어. 결과는:"

테스트 환경:
- 페이지: 사용자 대시보드 (인증 + Zustand + 10개 컴포넌트)
- 서버: AWS EC2 t3.medium
- 네트워크: 3G 시뮬레이션
 
┌─────────────────────┬──────────┬──────────┬──────────┐
│ 지표                │ Express  │ Next.js  │ 차이     │
├─────────────────────┼──────────┼──────────┼──────────┤
│ 서버 응답 시간      │ 120ms    │ 95ms     │ -21%     │
│ HTML 크기           │ 45KB     │ 38KB     │ -16%     │
│ JS 번들 크기        │ 180KB    │ 165KB    │ -8%      │
│ FCP (First Paint)   │ 1.2s     │ 0.9s     │ -25%     │
│ TTI (Interactive)   │ 2.8s     │ 2.1s     │ -25%     │
│ Lighthouse 점수     │ 78/100   │ 92/100   │ +14pt    │
└─────────────────────┴──────────┴──────────┴──────────┘

"Next.js가 빠른 이유:

Automatic Code Splitting: 페이지별로 JS 분리
RSC Payload 최적화: JSON보다 작은 직렬화 포맷
Streaming SSR: 부분적으로 HTML 전송 가능
Built-in 최적화: Image, Font 자동 최적화"

체크리스트: Express Zustand 배관 점검

"Express로 SSR을 만든다면 이걸 꼭 체크해:"

배관 안전 체크리스트:
□ Factory 패턴 사용 (전역 store 금지)
□ JSON.stringify 전 함수 제거
□ XSS 이스케이프 (<, >, & 치환)
□ window.__STATE__ 존재 확인 (클라이언트)
□ Store 초기화 순서 (Parse → Create)
□ Hydration Mismatch 테스트
□ Date/Random 값 서버에서 생성
□ 에러 처리 (SSR 실패 시 fallback)
□ 메모리 누수 체크 (store 정리)
□ 동시 요청 격리 확인 (보안!)

PM 도연의 깨달음

"아, 이제 이해했어요! Express에서 Zustand를 쓰려면:

서버: Factory로 store 생성 → 데이터 채우기 → JSON 직렬화 → HTML 주입
클라이언트: window 객체 읽기 → JSON 파싱 → Store 재생성 → Hydration

이 5단계 배관을 전부 직접 만들어야 하는 거네요. 그리고 실수하면 보안 사고나 Hydration 에러가 나고...

Next.js는 Server Component가 Props로 넘기면 자동으로 직렬화/역직렬화하니까 3단계로 줄고, 실수할 여지도 없어지는 거고요!"

"정확해! 특히 요청별 store 격리를 빼먹으면 개인정보 유출 사고가 나. 실제로 이런 버그로 보안 사고 난 스타트업도 있어. Next.js는 Server Component가 요청마다 새로 실행되니까 아예 이런 실수를 할 수가 없지."

핵심 요약

Express SSR + Zustand의 5대 배관

Factory 패턴: createStore(initialState) — 요청 격리
데이터 Fetch: await db.query() — 서버에서 데이터 준비
직렬화: JSON.stringify(getState()) — 함수 제거 + XSS 방지
HTML 주입: <script>window.__STATE__</script> — 클라이언트로 전송
재생성: createStore(window.__STATE__) — 클라이언트 초기화

Next.js의 자동화

Props 전달: Server Component → Client Component
자동 직렬화: RSC Payload (JSON보다 효율적)
useEffect 패턴: setUser(initialUser) — 상태 동기화

코드 비교 (라인 수)

Express:
- stores/userStore.js (Factory): 30줄
- server.js (배관): 60줄
- client/entry.jsx (파싱): 25줄
- contexts/StoreContext.jsx: 20줄
- 총 ~135줄 + 보안 코드
 
Next.js:
- stores/userStore.ts: 15줄
- app/page.tsx (SC): 20줄
- app/ClientPage.tsx: 25줄
- 총 ~60줄
 
감소율: 55%
버그 위험: Express(높음) vs Next.js(낮음)

다음 단계

**Step 03: TanStack Query 데이터 페칭**에서는 더 복잡한 배관인 Dehydrate/Hydrate 파이프라인을 다룹니다. Zustand는 단순한 key-value 상태였지만, TanStack Query는 비동기 데이터의 캐시, 로딩 상태, 에러 처리까지 직렬화해야 합니다. Express에서는 dehydrate() → JSON.stringify → hydrate() 배관을 직접 만들고, Next.js는 HydrationBoundary로 자동 처리하는 차이를 배웁니다.

학습 시간: 약 22분 난이도: ⭐⭐⭐ (중급) 선수 지식: React Hooks, SSR 기본 개념 실습 코드: GitHub - step-02-zustand

💡 멘토의 한마디 "상태관리 라이브러리를 SSR에 쓰는 건 '배관공' 작업이야. Express는 모든 배관을 직접 연결하고, Next.js는 자동 배관 시스템을 제공하는 거지. 프로젝트 초기에 배관 복잡도를 고려 안 하면, 나중에 유지보수 지옥에 빠져. 특히 요청 격리 실수는 보안 사고로 이어지니까 조심해!"