🚀 11. Next.js App Router + Jotai SSR 전략

📋 개요

SSR에서 Provider 필수 이유, useHydrateAtoms로 서버 데이터 주입, Server→Client Component 데이터 전달, SWC 플러그인을 배웁니다.

🎯 이 섹션을 읽고 나면:

SSR 환경에서 Provider 가 왜 필수이며, 없으면 어떤 보안 사고가 나는지 설명할 수 있다.

useHydrateAtoms 로 Server Component 에서 fetch 한 데이터를 Client Component 의 atom 에 주입하는 패턴을 구현할 수 있다.

SWC 플러그인 설정으로 DX 를 개선할 수 있다.

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 35분 (전체) / 핵심 파트만: 20분

🗺️ 이 문서의 배경 세계관: 최악의 배포 날

영수네 팀이 영수네 커뮤니티 앱을 처음으로 실서버에 배포한 날이야. 론칭 10분 만에 영수 님의 전화가 울렸어:

👔 영수 님 (패닉): "야, 지금 사용자들이 다른 사람 이름이랑 이메일이 보인다고 난리다! 내 계정으로 들어갔더니 영호 이름이 뜬다고!"
🦁 영호 님 (침착하게 코드 열어보며): "영철 님, layout.tsx 에 Provider 있어요?"
🐣 영철: (손 떨면서) "Provider 요? 로컬에서 잘 됐는데... 아, 없어요."
🦁 영호 님: "지금 바로 롤백하고 Provider 추가해서 재배포해요. 5분 걸려요."
👔 영수 님: "왜 이런 일이 생긴 거야?"
🦁 영호 님: "서버에서 모든 요청이 전역 store 하나를 공유해서요. A 유저가 쓴 store 를 B 유저가 읽은 거예요. 오늘부터 이 원인을 제대로 이해하고 넘어가야 해요."

🚨 실제 보안 사고 — Provider 없이 배포한 날 🔴

🎯 이 섹션을 읽고 나면:

전역 싱글턴 store 가 서버에서 왜 위험한지 구체적인 타임라인으로 이해한다

시간 00:00.000 — 영철이 세션 요청 도착
  → 서버가 userAtom 에 { name: '영철', email: 'youngcheol@email.com' } 를 set
  → HTML 렌더링 시작

시간 00:00.050 — 영수 세션 요청 도착 (렌더 완료 전!)
  → 서버가 userAtom.get() 호출
  → 전역 store 에는 아직 '영철' 데이터가 있음
  → 영수에게 영철의 이름, 이메일이 포함된 HTML 전송 💀

시간 00:00.100 — 영철이 요청 완료
  → 이미 늦었음

이게 Race Condition + 전역 상태 공유가 만들어내는 최악의 시나리오야. 보안 감사에서 "개인정보 무단 노출" 로 분류될 수 있는 사고야.

// ❌ 사고의 원인 코드 — Provider 없는 layout.tsx
 
// app/layout.tsx
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="ko">
      <body>
        {children} {/* ← 전역 싱글턴 store 가 모든 요청에 공유됨 */}
      </body>
    </html>
  )
}
 
// atoms/user.ts
// 🐣 영철: "모듈 최상단에 atom 선언했는데, 이게 서버 전역 변수가 돼버리는 거였어요"
export const userAtom = atom<User | null>(null)
// → 이 atom 의 값이 서버 인스턴스의 전역 store 에 저장됨
// → 요청 간 공유 → 보안 사고

🔒 SSR 에서 Provider 가 필수인 이유 🔴

🎯 이 섹션을 읽고 나면:

Node.js 의 모듈 캐싱이 왜 이 문제를 일으키는지 이해한다

Provider 가 어떻게 요청 단위의 store 격리를 만드는지 설명할 수 있다

Node.js 서버의 특성:
  - 모듈은 한 번만 로드되고 캐싱됨
  - atom config (설계도)는 모듈 최상단에서 한 번 생성
  - Provider-less 모드의 전역 store 도 모듈 레벨에서 한 번 생성
  → 모든 HTTP 요청이 같은 store 를 공유!

Provider 의 동작:
  - Provider 컴포넌트는 내부적으로 createStore() 를 호출해서 새 store 를 만듦
  - React 렌더링 시 Provider 가 새 store 인스턴스를 생성
  - SSR 에서는 요청마다 React 가 렌더링되므로 → 요청마다 새 store 생성
  → 요청 간 완전한 격리!

// ✅ 해결된 상태 — Provider 가 요청마다 새 store 를 격리
 
// 요청 1 (영철 세션): Provider 렌더 → createStore() → store A 생성
//                     userAtom in store A = { name: '영철' }
 
// 요청 2 (영수 세션): Provider 렌더 → createStore() → store B 생성
//                     userAtom in store B = { name: '영수' }
 
// store A 와 store B 는 완전히 독립 → 데이터 격리 ✅

🏗️ layout.tsx Provider 설정 패턴 🟡

🎯 이 섹션을 읽고 나면:

App Router 에서 Provider 래퍼 컴포넌트를 올바르게 설정하는 패턴을 알 수 있다

'use client' 가 왜 필요한지, 어디에 붙여야 하는지 이해한다

// 🦁 영호: "layout.tsx 는 기본이 Server Component 야. Provider 는 Client Component 이라서
//          바로 쓸 수 없어. 래퍼 컴포넌트로 분리해요."
 
// app/providers.tsx — Client Component 래퍼
'use client'
 
import { Provider } from 'jotai'
import type { ReactNode } from 'react'
 
interface JotaiProviderProps {
  children: ReactNode
}
 
export function JotaiProvider({ children }: JotaiProviderProps) {
  return <Provider>{children}</Provider>
}

// app/layout.tsx — Server Component 유지 (메타데이터, 폰트 등 활용 가능)
import { JotaiProvider } from '@/app/providers'
import type { Metadata } from 'next'
 
export const metadata: Metadata = {
  title: '영수네 스터디 커뮤니티',
  description: '개발자 스터디 매칭 플랫폼',
}
 
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="ko">
      <body>
        {/*
          JotaiProvider 는 Client Component.
          children (Server Components) 은 여전히 서버에서 렌더됨.
          이 구조는 Next.js의 "Client Component 에 Server Component 를 자식으로 넘기기" 패턴.
        */}
        <JotaiProvider>
          {children}
        </JotaiProvider>
      </body>
    </html>
  )
}

createStore 를 직접 넘기는 고급 패턴

// 🦁 영호: "초기 데이터를 미리 store 에 심어두고 싶을 때는 이렇게 해요"
// app/providers.tsx
'use client'
 
import { Provider, createStore } from 'jotai'
import { useRef } from 'react'
 
export function JotaiProvider({ children }: { children: React.ReactNode }) {
  // useRef 로 store 를 한 번만 생성 (렌더마다 재생성 방지)
  // 🐣 영철: "useState 가 아니라 useRef 를 쓰는 이유가 뭔가요?"
  // 🦁 영호: "useRef 는 리렌더를 트리거하지 않아서 store 초기화에 적합해요"
  const storeRef = useRef<ReturnType<typeof createStore>>()
  if (!storeRef.current) {
    storeRef.current = createStore()
  }
 
  return <Provider store={storeRef.current}>{children}</Provider>
}

💉 useHydrateAtoms — 서버 데이터를 atom 에 주입하기 🔴

🎯 이 섹션을 읽고 나면:

useHydrateAtoms 의 동작 원리와 사용법을 정확히 이해한다

Server Component 에서 fetch 한 데이터를 atom 에 초기값으로 주입하는 패턴을 구현할 수 있다

// 공식 레퍼런스의 핵심 경고:
// "useHydrateAtoms 는 클라이언트 코드에서 사용해야 합니다. 'use client' 지시어가 필요합니다."
 
import { useHydrateAtoms } from 'jotai/utils'
 
const countAtom = atom(0)
 
const ClientComponent = ({ countFromServer }: { countFromServer: number }) => {
  // countAtom 을 countFromServer 값으로 초기화
  // 이 호출은 컴포넌트가 처음 마운트될 때만 효과적
  useHydrateAtoms([[countAtom, countFromServer]])
 
  const [count] = useAtom(countAtom)
  // count 는 0 이 아니라 countFromServer 값
  return <div>{count}</div>
}

주의: atom 은 store 당 한 번만 hydrate 된다

// ⚠️ 중요: 같은 store 에서 atom 은 한 번만 hydrate 됨
// initialValue 가 리렌더 시 바뀌어도 atom 값은 업데이트되지 않아
 
const Component = ({ count }: { count: number }) => {
  // count prop 이 5 → 10 으로 바뀌어도 atom 은 여전히 5
  useHydrateAtoms([[countAtom, count]])
  // 이 동작은 의도된 것 — "초기값 주입" 이 목적이니까
}
 
// 강제로 재주입이 필요하면 (위험 주의)
useHydrateAtoms([[countAtom, count]], { dangerouslyForceHydrate: true })

🔗 Server → Client Component 데이터 전달 전체 흐름 🔴

🎯 이 섹션을 읽고 나면:

Server Component 에서 fetch 하고 Client Component 에서 atom 으로 관리하는 완전한 패턴을 구현할 수 있다

// 전체 데이터 흐름:
// [Server Component] fetch 데이터
//   ↓ props 로 전달
// [Client Component] useHydrateAtoms 로 atom 에 주입
//   ↓ 이후
// [Client 상태] atom 으로 자유롭게 읽고 쓰기
 
// ─────────────────────────────────────────────────
 
// 1단계: atom 정의 (공유 파일)
// atoms/study.ts
import { atom } from 'jotai'
 
export interface Study {
  id: string
  title: string
  likeCount: number
  memberCount: number
}
 
export const studyListAtom = atom<Study[]>([])
export const studyFiltersAtom = atom({ category: 'all', sortBy: 'latest' })

// 2단계: Server Component — 데이터 fetch
// app/studies/page.tsx (Server Component — 'use client' 없음)
import { StudyListClient } from '@/components/StudyListClient'
 
async function fetchStudyList(): Promise<Study[]> {
  // 🦁 영호: "Server Component 에서 fetch 하면 서버에서 실행돼요.
  //          캐싱, 토큰, DB 직접 접근 모두 가능해요."
  const res = await fetch('https://api.example.com/studies', {
    cache: 'no-store', // 항상 최신 데이터
  })
  return res.json()
}
 
export default async function StudiesPage() {
  // 서버에서 데이터 가져오기
  const initialStudyList = await fetchStudyList()
 
  return (
    <main>
      <h1>스터디 목록</h1>
      {/*
        Server Component 에서 fetch 한 데이터를 Client Component 에 props 로 전달.
        Client Component 에서 useHydrateAtoms 로 atom 에 주입.
      */}
      <StudyListClient initialStudyList={initialStudyList} />
    </main>
  )
}

// 3단계: Client Component — atom 에 초기값 주입 후 사용
// components/StudyListClient.tsx
'use client'
 
import { useAtom, useAtomValue } from 'jotai'
import { useHydrateAtoms } from 'jotai/utils'
import { studyListAtom, studyFiltersAtom } from '@/atoms/study'
 
interface Props {
  initialStudyList: Study[]
}
 
export function StudyListClient({ initialStudyList }: Props) {
  // 🦁 영호: "useHydrateAtoms 는 마운트 시 한 번만 atom 에 초기값을 심어요.
  //          이후 atom 은 완전히 클라이언트 상태가 돼요."
  useHydrateAtoms([[studyListAtom, initialStudyList]])
 
  // 이후 atom 을 자유롭게 사용
  const studies = useAtomValue(studyListAtom)
  const [filters, setFilters] = useAtom(studyFiltersAtom)
 
  const filteredStudies = studies.filter((s) =>
    filters.category === 'all' ? true : s.category === filters.category
  )
 
  return (
    <div>
      <FilterBar filters={filters} onFilterChange={setFilters} />
      <ul>
        {filteredStudies.map((study) => (
          <StudyCard key={study.id} study={study} />
        ))}
      </ul>
    </div>
  )
}

// 4단계: 좋아요 같은 클라이언트 상태 변경
// components/StudyCard.tsx
'use client'
 
import { useAtom } from 'jotai'
import { studyListAtom } from '@/atoms/study'
 
export function StudyCard({ study }: { study: Study }) {
  const [, setStudyList] = useAtom(studyListAtom)
 
  const handleLike = async () => {
    // 낙관적 업데이트 — 서버 응답 전에 UI 먼저 업데이트
    setStudyList((prev) =>
      prev.map((s) =>
        s.id === study.id ? { ...s, likeCount: s.likeCount + 1 } : s
      )
    )
    // 백그라운드에서 서버에 동기화
    await fetch(`/api/studies/${study.id}/like`, { method: 'POST' })
  }
 
  return (
    <div>
      <h3>{study.title}</h3>
      <button onClick={handleLike}>❤️ {study.likeCount}</button>
    </div>
  )
}

여러 atom 을 한 번에 hydrate

// 🐣 영철: "여러 atom 을 동시에 초기화할 수 있나요?"
// 🦁 영호: "useHydrateAtoms 는 배열이라서 여러 쌍을 한 번에 넘길 수 있어요"
 
useHydrateAtoms([
  [studyListAtom, initialStudyList],
  [userAtom, initialUser],
  [notificationsAtom, initialNotifications],
])

⚙️ SWC 플러그인 설정 🟡

🎯 이 섹션을 읽고 나면:

Jotai SWC 플러그인이 DX 를 어떻게 개선하는지 이해한다

Next.js 에서 SWC 플러그인을 설정하는 방법을 안다

Jotai SWC 플러그인은 두 가지 기능을 자동으로 처리해줘:

debugLabel 자동 추가 — 각 atom 에 파일명/변수명 기반 디버그 레이블 자동 추가
Hot Reload 지원 — 개발 중 atom 변경 시 빠른 HMR

npm install @swc-jotai/debug-label @swc-jotai/react-refresh

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    swcPlugins: [
      // atom 에 자동으로 debugLabel 추가 (DevTools 에서 식별 용이)
      ['@swc-jotai/debug-label', {}],
      // 개발 중 atom 변경 시 Hot Module Replacement 지원
      ['@swc-jotai/react-refresh', {}],
    ],
  },
  // jotai-devtools UI CSS 트랜스파일
  transpilePackages: ['jotai-devtools'],
}
 
module.exports = nextConfig

// SWC 플러그인 적용 전
const studyListAtom = atom<Study[]>([])
// debugLabel 없음 → DevTools 에서 "atom1", "atom2" 로 표시
 
// SWC 플러그인 적용 후 (자동 변환)
const studyListAtom = atom<Study[]>([])
studyListAtom.debugLabel = 'studyListAtom' // 자동 추가!
// → DevTools 에서 'studyListAtom' 으로 정확하게 표시

🧪 SSR 에서 atom 을 직접 쓰지 않는 이유 🟡

🎯 이 섹션을 읽고 나면:

Server Component 에서 React 훅을 쓸 수 없는 이유를 설명할 수 있다

데이터 흐름이 "서버 fetch → props → Client atom" 이어야 하는 이유를 이해한다

// ❌ Server Component 에서 atom 을 직접 쓰려 했을 때 에러
// app/studies/page.tsx
 
// 이렇게 하고 싶어도 안 됨!
import { useAtomValue } from 'jotai' // ❌ Server Component 에서 훅 사용 불가
 
export default async function StudiesPage() {
  // Error: Invalid hook call.
  // Hooks can only be called inside of the body of a function component.
  const studies = useAtomValue(studyListAtom) // 💥 에러!
}

// 🦁 영호: "Server Component 는 React 훅을 실행할 환경이 없어요.
//          훅은 React 가 컴포넌트 트리를 관리하면서 실행되는데,
//          Server Component 는 서버에서 한 번 실행되고 끝이에요."
 
// ✅ 올바른 패턴 — Server 에서 fetch, Client 에서 atom 으로 관리
// Server Component: 데이터만 가져온다
export default async function StudiesPage() {
  const studies = await fetchStudies() // fetch (훅 아님) ✅
 
  return <StudyListClient initialStudyList={studies} />
  //      ↑ Client Component 에 props 로 전달
}
 
// Client Component: atom 으로 상태 관리
'use client'
export function StudyListClient({ initialStudyList }: Props) {
  useHydrateAtoms([[studyListAtom, initialStudyList]]) // 주입 ✅
  const studies = useAtomValue(studyListAtom) // 이후 atom 으로 자유롭게 사용 ✅
}

💥 에러 해결 카탈로그

에러 메시지가 뜨면 Ctrl+F 로 검색해봐. 대부분 여기 있어.

❌ 다른 유저의 데이터가 보이는 현상

원인: layout.tsx 에 <Provider> 없이 전역 atom 사용 (08번 가이드 참고)

해결책:

// app/providers.tsx
'use client'
export function JotaiProvider({ children }: { children: React.ReactNode }) {
  return <Provider>{children}</Provider>
}
 
// app/layout.tsx
import { JotaiProvider } from '@/app/providers'
export default function RootLayout({ children }) {
  return <html><body><JotaiProvider>{children}</JotaiProvider></body></html>
}

❌ "Invalid hook call" — Server Component 에서 useAtom 사용

해결책: Server Component 에서 훅 사용 불가. 데이터를 props 로 Client Component 에 전달하고 거기서 useHydrateAtoms 사용

❌ useHydrateAtoms 가 prop 업데이트에 반응하지 않음

원인: useHydrateAtoms 는 같은 store 에서 한 번만 동작해

해결책:

// 재주입이 꼭 필요하면 dangerouslyForceHydrate 옵션 사용
// (concurrent rendering 에서 잘못된 동작 가능 — 주의해서 사용)
useHydrateAtoms([[countAtom, count]], { dangerouslyForceHydrate: true })

❌ SWC 플러그인 적용 후 "Module not found" 에러

해결책:

# 플러그인 패키지 설치 확인
npm install @swc-jotai/debug-label @swc-jotai/react-refresh
 
# next.config.js 의 experimental.swcPlugins 설정 확인

🏁 이번에 배운 내용 총정리

📋 Next.js App Router + Jotai 전체 구조

app/
├── layout.tsx              ← Server Component + JotaiProvider 래퍼 사용
├── providers.tsx           ← 'use client' JotaiProvider 래퍼
├── studies/
│   └── page.tsx            ← Server Component: fetch 데이터
└── components/
    └── StudyListClient.tsx ← 'use client': useHydrateAtoms + useAtom

atoms/
└── study.ts                ← atom 정의 (Server/Client 공유)

⚠️ 핵심 체크리스트

체크	내용
✅	`layout.tsx` 에 `JotaiProvider` 래퍼 추가
✅	`providers.tsx` 에 `'use client'` 추가
✅	Server Component 에서는 `fetch` 만, 훅은 Client Component 에서
✅	`useHydrateAtoms` 는 Client Component (`'use client'`)에서만
✅	SWC 플러그인으로 debugLabel 자동화

📝 마무리 퀴즈

Q1. 🚨 긴급 디버깅 (영수의 호통)

배포 직후 "A 유저가 B 유저 정보를 보고 있다" 고 신고가 들어왔어.
영철이가 확인하니 layout.tsx 에 <Provider> 가 없었어.
영호 님의 기술적 설명으로 가장 정확한 것은?

A) 서버에서 atom 의 초기값이 null 이라서 다른 유저의 데이터를 읽었다
B) Next.js SSR 에서 Provider 없이 atom 을 쓰면, Node.js 모듈 레벨의 전역 store 가 모든 요청에 공유되어 이전 요청의 데이터가 다음 요청에 노출된다
C) useHydrateAtoms 를 쓰지 않아서 발생한 문제다
D) atom 을 Server Component 에서 사용해서 발생한 문제다

✅ 정답: B

💡 상세 해설:

원리 설명: Node.js 서버에서 JavaScript 모듈은 한 번 로드되어 캐싱됨. Provider-less 모드의 전역 default store 도 모듈 레벨에서 한 번 생성되어 공유돼. <Provider> 는 렌더할 때마다 내부적으로 createStore() 를 호출해서 새 store 를 만들어. SSR 에서는 요청마다 React 가 렌더링을 실행하므로, 요청마다 새 Provider → 새 store → 완전한 격리가 이루어져.
오답 피드백: A 는 초기값 문제가 아닌 store 공유 문제야. C 와 D 는 사고의 원인이 아니야.
📌 핵심 기억법: "SSR + Provider 없음 = 공용 락커룸. 전 사용자 옷이 그대로 남아있어."

Q2. 💉 useHydrateAtoms 의 동작

영철이가 useHydrateAtoms([[countAtom, serverCount]]) 를 사용했어.
이후 서버에서 serverCount prop 이 5 에서 10 으로 바뀌었어.
atom 의 값은 어떻게 되는가?

A) 자동으로 10 으로 업데이트된다
B) useHydrateAtoms 는 컴포넌트 마운트 시 한 번만 atom 에 값을 주입하므로, prop 이 바뀌어도 atom 은 여전히 5 다
C) 에러가 발생한다
D) atom 이 리셋되어 초기값 0 으로 돌아간다

✅ 정답: B

💡 상세 해설:

원리 설명: 공식 레퍼런스에 명시되어 있어: "같은 store 에서 atom 은 한 번만 hydrate 된다". useHydrateAtoms 의 목적은 "초기값 주입" 이지, "prop 동기화" 가 아니야. 마운트 후에는 atom 이 독립적인 클라이언트 상태가 되어, 사용자가 직접 변경하거나 setAtom 을 호출해야 값이 바뀌어.
오답 피드백: A 는 useEffect + setAtom 으로 prop 을 atom 에 동기화하는 별도 로직이 필요해.
📌 핵심 기억법: "useHydrateAtoms = 씨앗 심기. 한 번 심으면 이후 자라는 건 식물(atom)의 몫."

Q3. 🏗️ 아키텍처 설계

영호 님이 물었어: "Server Component 에서는 왜 atom 을 직접 쓸 수 없나요?"
영철이가 면접 연습 삼아 대답해봤어. 가장 정확한 답변은?

예시 답변:

"Server Component 는 서버에서 한 번 실행되고 HTML 을 반환하는 함수예요. React 훅은 React 가 컴포넌트 트리를 메모리에 유지하면서 리렌더와 상태 관리를 하는 컨텍스트에서만 동작해요. Server Component 에서 훅을 호출하면 'Invalid hook call' 에러가 발생해요. 그래서 Server Component 에서는 fetch 나 DB 접근으로 데이터를 가져오고, 그 데이터를 Client Component 에 props 로 전달한 후, Client Component 에서 useHydrateAtoms 로 atom 에 주입하는 패턴을 써야 해요."

💡 이 답변을 자신의 언어로 말할 수 있다면: 오늘 배운 핵심을 완전히 이해한 거야.

🐣 영철이의 퇴근 일기

오늘은 진짜 잊지 못할 하루였다. 배포 10분 만에 보안 사고가 나다니.

처음엔 Provider 라는 게 "그냥 있으면 좋고 없어도 되는 거" 라고 생각했어. 로컬에서 잘 됐으니까. 근데 Node.js 서버가 모듈을 캐싱한다는 특성 때문에, 전역 store 가 모든 요청에 공유된다는 걸 이번에 뼈저리게 배웠어. 이론으로 알던 걸 실서버 사고로 배우는 건 완전히 다른 경험이야.

영호 님이 침착하게 5분 안에 롤백하고 Provider 추가하고 재배포했을 때 진짜 대단하다고 생각했어. 나는 손이 떨려서 키보드를 못 쳤는데. "시니어가 되면 이런 상황에서도 침착해지는 건가" 싶었어.

💡 오늘의 교훈: "SSR 에서 Provider 는 선택이 아니라 보안 필수 요소다. 공용 냉장고에 개인 음식을 넣으면 다른 사람이 먹어버린다."

useHydrateAtoms 패턴도 오늘 처음 제대로 써봤어. 서버에서 fetch 하고 props 로 넘기고 atom 에 주입하는 흐름이 처음엔 복잡해 보였는데, 해보니까 확실히 깔끔한 패턴이야. 서버의 장점(빠른 fetch, 캐싱)과 클라이언트의 장점(인터랙티브 상태 관리)를 같이 쓸 수 있으니까.

오늘은 진짜 일찍 자야겠다. 긴장해서 에너지를 다 써버렸어. 내일 아침 출근해서 영수 님한테 같이 사과드려야지.

🚀 11. Next.js App Router + Jotai SSR 전략

📋 목차

📌 이 문서를 읽기 전에

🚨 실제 보안 사고 — Provider 없이 배포한 날 🔴

🔒 SSR 에서 Provider 가 필수인 이유 🔴

🏗️ layout.tsx Provider 설정 패턴 🟡

createStore 를 직접 넘기는 고급 패턴

💉 useHydrateAtoms — 서버 데이터를 atom 에 주입하기 🔴

주의: atom 은 store 당 한 번만 hydrate 된다

🔗 Server → Client Component 데이터 전달 전체 흐름 🔴

여러 atom 을 한 번에 hydrate

⚙️ SWC 플러그인 설정 🟡

🧪 SSR 에서 atom 을 직접 쓰지 않는 이유 🟡

💥 에러 해결 카탈로그

❌ 다른 유저의 데이터가 보이는 현상

❌ "Invalid hook call" — Server Component 에서 useAtom 사용

❌ useHydrateAtoms 가 prop 업데이트에 반응하지 않음

❌ SWC 플러그인 적용 후 "Module not found" 에러

🏁 이번에 배운 내용 총정리

📋 Next.js App Router + Jotai 전체 구조

⚠️ 핵심 체크리스트

📝 마무리 퀴즈

🐣 영철이의 퇴근 일기

🔗 더 알아보기