💧 07. Next.js SSR과 상태 공유 누수 방어: "왜 내 포인트가 남한테 보이죠?!"

🎯 이 섹션을 읽고 나면:

• Next.js의 SSR 환경(Node.js 서버)에서 모듈 레벨의 싱글톤 전역 변수가 어떤 치명적인 보안 사고를 내는지 원리를 설명할 수 있다.
• Zustand 공식 문서에서 권장하는 Context API + Zustand 팩토리 패턴을 적용하여 사용자(Request)마다 완전히 격리된 스토어를 생성할 수 있다.
• 이중 렌더링 환경에서의 Hydration Mismatch를 방어하는 초기 상태 주입법을 익힐 수 있다.

📋 목차

• 🤔 왜 알아야 하는가
• 🏗️ 1. 스토어 팩토리 패턴: "매 요청마다 스토어를 새로 뽑자"
• 💎 2. Context API의 화려한 귀환
• 🧩 3. Next.js App Router 에 바르는 법 (Hydration 동기화)
• 🏋️‍♂️ 영철의 테스트 타임 (Q&A)

📌 이 문서를 읽기 전에

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

🗺️ 이 문서의 흐름
클라이언트 싱글톤 vs 서버 싱글톤의 차이 → 상태 누수(State Leaking) 재현 → Context API를 이용한 Request-Per-Store 팩토리 패턴 결합

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

• 🐣 영철 ( 신입 ): "리드 님!! 큰일 났어요! 커뮤니티 앱 상단 헤더에 '내 포인트 잔액'을 띄우려고 Zustand로 useUserStore를 만들고 Next.js에 배포했거든요? 근데 방금 영수 님이 접속하셨는데, 본인 포인트가 아니라 제 포인트 잔액이 화면에 뜬대요! 해킹당한 건가요?!"
• 🦁 영호 ( 리드 ): "아닙니다. 영철 님, 해킹이 아니라 넥스트 서버의 메모리 스페이스를 나눠 썼기 때문이에요. 브라우저에서 Zustand 스토어는 나 혼자 쓰는 1인용 락커지만, SSR을 담당하는 Node.js 서버에서 선언된 스토어는 모든 접속자가 같이 쓰는 공중목욕탕입니다. 당장 배포 롤백하시고, 스토어 격리 수술 7원칙 들어갑니다."

🤔 왜 알아야 하는가

React 컴포넌트 내부에서 상태를 관리(useState)하지 않고 밖으로 빼는 도구를 모듈 상태(Module State) 라고 부릅니다. Zustand의 create 함수가 파일 최상단에서 한 번만 호출되는 것이 그 증거죠.

클라이언트 사이드 렌더링(CSR)만 하는 앱(Vite, Create React App 등)에서는 이 방식이 완벽합니다. 사용자가 사이트에 접속하면 그 사람의 브라우저 전용으로 새로운 자바스크립트 엔진 메모리가 할당되고, 거기서 싱글톤으로 스토어를 만드니까요. "1 유저 = 1 브라우저 = 1 스토어" 공식이 성립합니다.

하지만 Next.js의 SSR (Server-Side Rendering) 환경으로 넘어오면 이야기가 완전히 뒤집힙니다.

서버(Node.js)는 하나입니다. 이 하나의 서버 프로그램이 A 유저의 요청도 처리하고, B 유저의 요청도 처리합니다. 이때 파일 최상단에서 create된 스토어는 서버 런타임이 올라간 직후 딱 한 번만 생성된 전역 싱글톤 객체입니다.
A 유저가 1000포인트를 스토어에 넣는 순간, 이 1000포인트는 서버 메모리에 기록되고, 0.1초 뒤 접속한 B 유저의 HTML을 렌더링할 때 이 스토어의 1000포인트를 그대로 읽어서 화면에 그려버리게 됩니다! 이를 상태 유출(State Leaking / Cross-Request State Pollution) 이라 부릅니다. 대형 보안/프라이버시 사고의 주범입니다.

🏗️ 1. 스토어 팩토리 패턴: "매 요청마다 스토어를 새로 뽑자"

이 재앙을 막기 위해 5년 차 개발자들은 상태를 정의하는 "틀(Factory)"만 만들어두고, 요청(Request)이 들어올 때마다 새로운 빈 스토어 객체를 찍어내는(Instantiate) 아키텍처로 선회합니다.

기존에 create를 바로 때렸던 코드를 팩토리 함수로 감쌉니다.

// store/user-store.ts
import { createStore } from 'zustand/vanilla'; // 🚨 주의: 기본 create가 아닙니다. 코어 엔진만 가져옵니다!
 
export interface UserState {
  points: number;
  setPoints: (p: number) => void;
}
 
// ❌ 기존 위험한 방식 (전역 1회 생성)
// export const useUserStore = create<UserState>(...)
 
// ✅ Pro Approach: 매번 새 스토어 코어(StoreApi)를 반환하는 공장 함수
export const createUserStore = (initialPoints: number = 0) => {
  return createStore<UserState>()((set) => ({
    points: initialPoints,
    setPoints: (points) => set({ points }),
  }));
};

이렇게 하면 createUserStore()를 호출할 때마다 세상에 단 하나뿐인 새로운 스토어 인스턴스가 튀어나옵니다.

💎 2. Context API의 화려한 귀환

"잠깐, 그럼 이 생성된 스토어 코어(store instance)를 언제, 어디서 만들어서 컴포넌트에 넘겨주나요? 프롭스로 다 뚫고 내려갈 건가요?"

여기서 우리가 1편에서 밀어냈던 Context API가 최후의 구원투수로 재등장합니다. 하지만 예전처럼 "상태 값" 변경으로 인한 리렌더링 폭탄 용도가 아닙니다. 오직 "이 클라이언트(혹은 이 SSR 렌더 패스) 전용으로 생성된 스토어 인스턴스의 주소값 하나" 만을 배달하는 우체부 역할로 쓰입니다. 주소값은 절대 변하지 않으므로 Context 리렌더링 폭발 현상도 제로입니다!

// store/user-store-provider.tsx
'use client'; // Context 관련 훅을 써야 하므로 Client Component 경계를 선언합니다.
 
import { createContext, useContext, useRef } from 'react';
import { useStore } from 'zustand';
import { createUserStore, UserState } from './user-store';
 
// 1. 반환 타입 추출 (StoreApi)
export type UserStoreApi = ReturnType<typeof createUserStore>;
 
// 2. 우체통(Context) 만들기
export const UserStoreContext = createContext<UserStoreApi | undefined>(undefined);
 
// 3. Provider 컴포넌트: React 생명주기 내에서 스토어를 "1번만" 찍어냄
export const UserStoreProvider = ({ children, initialPoints = 0 }) => {
  // 🦁 영호: 서버 렌더링 중이든 클라이언트든, 최초 마운트 시점에만 스토어를 생성해요.
  const storeRef = useRef<UserStoreApi>();
  
  if (!storeRef.current) {
    storeRef.current = createUserStore(initialPoints);
  }
 
  return (
    <UserStoreContext.Provider value={storeRef.current}>
      {children}
    </UserStoreContext.Provider>
  );
};
 
// 4. 컴포넌트 전용 커스텀 훅 만들기
// 🦁 영호: 이제 아무 곳에서나 1편 2편처럼 Selector를 던지면, 
// 전역 변수가 아닌 이 컨텍스트 안의 '내 전용 스토어'에서 값을 꺼내옵니다.
export const useUserStore = <T,>(selector: (store: UserState) => T): T => {
  const context = useContext(UserStoreContext);
  if (!context) throw new Error('Provider로 감싸주세요!');
  
  // zustand 패키지의 기본 useStore를 이용해 코어를 리액트에 결합합니다.
  return useStore(context, selector);
};

🧩 3. Next.js App Router 에 바르는 법 (Hydration 동기화)

이제 팩토리와 프로바이더의 세팅이 끝났습니다. 유저 정보 조회 API를 쏘는 최상단 서버 컴포넌트(레이아웃 등)에서 껍데기를 감싸주고 서버 데이터 초깃값을 밀어 넣어줍니다.

// app/layout.tsx (Server Component)
import { UserStoreProvider } from '@/store/user-store-provider';
import { getUserPointsFromDB } from '@/lib/db';
 
export default async function RootLayout({ children }) {
  // 👔 영수: SSR 환경에서 DB를 찔러 A유저의 찐 포인트를 가져옵니다.
  const initPoints = await getUserPointsFromDB();
 
  return (
    <html lang="en">
      <body>
        {/* 🦁 영호: 이 순간 생성된 Provider 내의 스토어는 오직 이 A유저의 요청 렌더링 패스에서만 유효합니다! */}
        <UserStoreProvider initialPoints={initPoints}>
          {children}
        </UserStoreProvider>
      </body>
    </html>
  );
}

이제 하위의 모든 클라이언트 컴포넌트(영철이 만든 글쓰기 폼, 헤더, 장바구니 등)에서는 익숙하게 const points = useUserStore(state => state.points); 를 호출하기만 하면 됩니다.

• 서버 렌더링 단계: initPoints (예: 1000)가 바로 렌더링되어 HTML에 박힘.
• 클라이언트 Hydration 단계: useRef가 HTML 결과물과 완벽히 동기화된 1000을 바라보며 초기화되므로 Mismatch 0%!
• A유저와 B유저는 각각의 요청마다 생성된 <Provider>의 서로 다른 ref 객체를 보게 되므로 상태 누수 완벽 차단!

📝 마무리 퀴즈

Q1. Next.js App Router (SSR 환경)에서 모듈 스코프(파일 최상단)에 Zustand 스토어 인스턴스를 단일로 선언하면 절대 안 되는 치명적인 이유는 무엇인가요?

• A) 브라우저 메모리가 터져 나간다.
• B) Node.js 서버 프로세스 하나를 여러 렌더링 요청이 공유하므로, A 유저의 상태가 B 유저의 렌더링 결과(HTML)에 섞여 나가는 상태 유출(State Leaking)이 발생한다.
• C) 서버 컴포넌트 내부에서는 TypeScript 에러가 강제 발생하기 때문이다.
• D) Zustand 개발팀이 법적으로 금지했다.

✅ 정답: B

💡 상세 해설:

• 원리 설명: 서버는 한 놈이지만, 요청하는 유저는 수만 명입니다. 파일 최상단에서 전역 변수로 할당된 1개의 스토어 하나에 API로 가져온 A 유저의 민감 정보를 때려 박으면, 그 직후 B 유저 화면을 렌더링하던 Node 런타임이 그 오염된 스토어를 읽어서 HTML을 반환해버립니다.
• 오답 피드백: "영철 님, CSR에선 괜찮았지만 백엔드가 개입하는 순간 모두의 공중목욕탕이라는 개념을 명심해야 합니다."
• 📌 핵심 기억법: 🦁 영호: "클라이언트 스토어는 개인 라커룸, 서버 스토어(전역)는 공용 목욕탕입니다."

Q2. SSR에서 사용자별로 격리된(Request-Per-Store) 안전한 Zustand 상태 관리를 구축하기 위해 사용하는 디자인 패턴은 무엇인가요?

• A) Immer 미들웨어 + React.memo
• B) LocalStorage를 서버 쿠키로 덮어씌워서 복사하기
• C) 모듈 변수를 함수 안으로 이동시키는 싱글톤 트리 패턴
• D) 스토어 인스턴스 팩토리(Factory) + Context API 프로바이더 결합

✅ 정답: D

💡 상세 해설:

• 원리 설명: 상태를 정의하는 팩토리 함수(createStore())만 만들어두고, 요청이 들어와 최상위 렌더링이 시작될 때(useRef) 새로운 빈 스토어 객체를 찍어냅니다. 이 갓 태어난 스토어 주소값을 React의 Context API에 담아 자식들에게 뿌리면 서버 메모리 풀이 완벽하게 격리됩니다.
• 오답 피드백: "영철 님, Context는 더 이상 상태 리렌더링 폭탄이 아니에요. 그저 스토어 주소를 안전하게 전달하는 아주 단단한 파이프관일 뿐입니다."
• 📌 핵심 기억법: 🦁 영호: "Context가 우체부 역할을 해서, 유저마다 고유한 스토어의 주소지를 정확히 꽂아줍니다."

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

영철이가 쇼핑 앱을 Next.js(Pages Router/App Router)로 개발 중입니다. '다크 모드' 여부를 저장하는 UI 테마 스토어(useThemeStore)는 SSR 상태 누수 위험을 막기 위해 무조건 위와 같은 Provider 팩토리 패턴으로 마이그레이션 해야 할까요?

✅ 정답: 아닙니다. 서버 상호작용이 전혀 없는 순수한 클라이언트 로직이라면 기존 create 전역 패턴을 유지해도 됩니다.

💡 상세 해설:

• 원리 설명: 상태 누수는 "SSR" 시점에 "사용자별 고유한 데이터"가 전역 공간에 섞일 때 폭발하는 이슈입니다. 다크 모드, 임시 폼 에러 메시지 텍스트 등은 어차피 사용자 브라우저 렌더링 패스(useEffect 혹은 Client Component)에서만 굴러가는 값들이며, 서버 렌더링 시점에 의존성을 개입시킬 이유가 없습니다. (Next.js 캐시 환경 규칙에 따라 달라질 수 있지만, 근본 정보의 소유자 관점에선 무해합니다.)
• 오답 피드백: "영철 님, 전역으로 만들었다고 다 에러가 나는 게 아니에요. 스토어에 담긴 상태가 **특정 유저의 민감 정보(토큰, 포인트 등 SSR 과정에서 주입되어야 하는 값)**인가? 라는 본질을 따지세요. 팝업 열림/닫힘 처리에 저 거창한 보일러플레이트를 태우는 건 투머치입니다."
• 📌 핵심 기억법: 🦁 영호: "내 노트북에서만 도는 건 전역 스토어. 서버를 거치며 남한테 보여선 안 될 데이터가 섞이는 건 Provider 스토어."

🐣 영철이의 퇴근 일기

와. 오늘 서버 메모리 누수 얘기를 들으면서 내 머리카락이 반쯤 빠지는 줄 알았다. 아무 생각 없이 Vercel에 올리고 다 됐다고 좋아했는데, 상태 라이브러리 하나조차도 서버사이드(SSR) 개념이 끼어들면 아키텍처를 뒤집어엎어야 한다는 사실에 충격을 받았다. 그래도 바닐라 코어 모델(zustand/vanilla)이랑 Context API를 섞어 쓰는 영호 리드 님의 우아한 방어 코드를 보니까 나도 저런 시니어가 되고 싶다는 전투력이 불타오른다! (그래도 퇴근 후엔 머리가 핑핑 도니까 치킨 생각만 난다... 내일 회사 가면 이 패턴부터 외워야지.)

💡 "상태를 박제하지 말고 매번 새 상자를 내어주자. 서버 메모리는 만인의 공중화장실이다."