🚀 Next.js 3장: App Router의 3대 렌더링 전략 (SSR, SSG, ISR)

📋 목차

• 📌 이 문서를 읽기 전에
• 🤔 왜 알아야 하는가
• 🏗️ 비유로 먼저 이해하기
• 🛑 렌더링 시점의 비밀: Build-time vs Run-time 🟢
• 🧩 1. Static Rendering (과거의 SSG) 🟢
• 🧩 2. Dynamic Rendering (과거의 SSR) 🟢
• 🧩 3. ISR: 반자동 렌더링의 마법 🟡
• 🧪 따라해보기: 내 라우트가 Static인지 Dynamic인지 확인하기
• 💥 에러 해결 카탈로그
• 🎯 개인화 피드와 SSR 격리 전략 🟡
• 🏁 이번에 배운 내용 총정리
• 📝 마무리 퀴즈
• 🐣 영철이의 퇴근 일기
• 🔗 더 알아보기

📌 이 문서를 읽기 전에

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

🗺️ 이 문서의 흐름
렌더링 시점 두 가지 → 정적 렌더링(SSG) → 동적 렌더링(SSR) → 점진적 재생성(ISR) → 빌드 결과 꿀팁(영수네 커뮤니티 예제)

🎯 이 문서를 다 읽으면 할 수 있는 것

• 각 화면 성격과 서비스 요구사항에 맞춰 최적의 서버 렌더링 방식을 스스로 설계할 수 있다.
• 빌드 로그를 통해 코드가 의도치 않게 서버 자원을 고갈시키고 있지 않은지 통제할 수 있다.

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

• 영철(새로 온 주니어): "어? 분명히 로컬에서는 잘 됐는데... 배포하고 나니까 회사 소개 페이지 하나 열 때마다 서버가 비명을 질러요! 😭"
• 영호(FE 리드): "영철 님... 소개 페이지 최상단에 cookies() 함수를 넣으셨더군요. 그 한 줄 때문에 정적으로 구워져야 할 페이지가 실시간 햄버거가 된 거예요!"

🤔 왜 알아야 하는가

영수네 커뮤니티에 드디어 유입자가 몰리기 시작했어.

의욕 넘치는 영철(새로 온 주니어) 님은 무척 기뻤지만, 기쁨도 잠시. 스터디 매칭 앱의 "소개 페이지(/about)" 하나 보려고 들어온 유저들 때문에 DB 서버 CPU가 100%를 찍으며 전체 서비스가 마비되어 버렸어.

영수(PM/백엔드) 님이 울상을 지으며 달려왔어. "아니, 일 년 내내 글자 하나 안 변하는 회사 소개 페이지에 접속할 때 마다 왜 이런 과도한 부하가 걸리는 거죠? 대체 서버에서 국밥을 새로 끓이는 이유가 뭡니까!"

범인은 이번에도 영철 님. 그는 쿠키 기반 다국어 처리를 한답시고 최상위 영역에 cookies() 함수를 최상위에 넣었고, 이로 인해 Next.js가 미리 아주 맛있게 구워두었던(Static) 페이지들을 모조리 런타임 즉석 렌더링(Dynamic)으로 강등시켜버린 거야. 렌더링 전략을 제대로 모르면 이런 '서버 부하 문제'을 만들게 돼.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면? (영수네 국밥집)

렌더링 전략은 음식을 만들어두는 타이밍 의 차이야.

1. Static Rendering (SSG): 새벽 장사 전(빌드 타임)에 대형 가마솥에 국밥을 싹 다 끓여두는 거야. 손님이 오면 1초 만에 툭 던져줘. 제일 빠르고 알바생(서버)도 안 힘들어. (회사 소개, 블로그)
2. Dynamic Rendering (SSR): 이건 즉석에서 볶는 제육볶음 이야. 손님이 주문(접속)할 때마다 알바생이 불 켜고 고기를 새로 볶아. 서버가 고생하지만, "전 비계 빼주세요(개인화 쿠키)" 같은 요구를 100% 맞춰 줄 수 있어. (마이페이지, 장바구니)
3. ISR (Incremental Static Regeneration): "일정 시간마다 새로 무쳐 나오는 겉절이" 같은 거야. 미리 무쳐두지만, 10분마다 주방에서 새 걸로 무쳐서 채워 넣어. 신선함과 속도를 다 잡는 방법이지.

🛑 렌더링 시점의 비밀: Build-time vs Run-time 🟢

🎯 이 섹션 이후에 당신은:

• 빌드 타임과 런타임의 기술적 차이를 명확히 구분할 수 있다.
• 왜 빌드 타임 최적화가 서버 비용 절감의 핵심인지 이해한다.

가장 핵심이 되는 기준은 결국 "HTML을 도대체 언제 만드느냐?" 야.

1. Build Time (빌드 타임): 개발자가 서버에 코드 배포하려고 npm run build 를 쳤을 때.(사용자 0명)
2. Run Time (런타임): 빌드 끝내고 운영 중일 때, 사용자가 우리 앱 도메인 치고 접속한 바로 그 순간.

🧩 1. Static Rendering (과거의 SSG) 🟢

🎯 이 섹션 이후에 당신은:

• Static Rendering이 기본값(Default)으로 동작하는 원리를 안다.
• 어떤 코드가 Static 최적화를 깨뜨리는지 인지한다.

📖 용어: SSG(Static Site Generation) — 앱을 배포 전(빌드 타임)에 미리 HTML을 싹 다 생성해두는 방식.

이게 뭔가? & 왜 필요한가?

아무런 특이 설정 없이 짠 순수 Server Component는 Next.js가 자동으로 Static Rendering으로 간주해.
영철 님이 짜던 /about 페이지처럼 정적인 문서들을 한 번만 구워서 전 세계 CDN 에 복사해두면, 아무리 10만 명이 몰려도 서버 부하가 0(Zero) 이란 뜻이지.

❌ 순진한 코드 (Naive Approach)
페이지를 CSR(React) 로 만들어 굳이 클라이언트의 통신 능력을 낭비하게 함.

✅ 우아한 코드 (Pro Approach) - 완벽한 Static 최적화

// app/about/page.tsx
// 🦁 영호: "아무런 동적 함수가 없으니, 이 페이지는 빌드 때 딱 한 번만 구워집니다."
 
export default function AboutPage() {
  return (
    <main>
      <h1>대한민국 No.1 스터디 매칭, 영수네 커뮤니티</h1>
    </main>
  )
}

🧩 2. Dynamic Rendering (과거의 SSR) 🟢

🎯 이 섹션 이후에 당신은:

• 어떤 함수가 페이지를 SSR로 '강제 강등'시키는지 리스트를 기억한다.
• Dynamic 렌더링이 필요한 필연적인 상황을 구분할 수 있다.

📖 용어: SSR(Server-Side Rendering) — 사용자가 접속하는 그 런타임 시점 에, 그 사람만을 위한 최신 데이터와 헤더로 HTML을 뼈부터 구워주는 방식.

언제 강제 전환되는가?

내 페이지가 Static에서 비싼 Dynamic SSR로 강등되는 조건은 명확해. "Next.js가 미리 알 수 없는 실시간 유저 정보"를 건드리는 순간!

• cookies() 읽기
• headers() (유저의 Agent 등) 읽기
• searchParams를 페이지 프롭스로 받아 렌더링에 쓸 때

// app/dashboard/page.tsx
import { cookies } from 'next/headers'
 
export default async function DashboardPage() {
  // 🐣 영철: "아항, 쿠키를 읽는 이 라인이 추가되는 순간,
  // 빌드 타임에는 이게 누구 쿠키인지 알 수가 없으니 런타임 SSR 렌더링이 강제되는구나!"
  const cookieStore = cookies()
  const userToken = cookieStore.get('auth_token')
 
  return (
    <main>
      <h1>내 스터디 현황</h1>
    </main>
  )
}

🧩 3. ISR: 반자동 렌더링의 마법 🟡

🎯 이 섹션 이후에 당신은:

• revalidate 옵션을 통해 정적 페이지를 주기적으로 갱신할 수 있다.
• Stale-While-Revalidate 전략의 장단점을 이해한다.

영숙(디자이너) 님이 요구했어. "영호 님, 메인 화면의 '실시간 급상승 인기 스터디' 목록은 한 10분에 한 번 정도만 갱신돼도 충분할 거 같아요. 접속자가 몰릴 때 로딩 걸리는 건 절대 싫고요!"

영호(FE 리드) 님은 씩 웃으며 대답했어. "ISR로 캐시를 치면 완벽하죠!"

ISR 동작 원리

정적 페이지의 강력한 속도를 유지하면서 백그라운드에서 주기적으로 캐시를 갱신해.

// app/trending/page.tsx
export default async function TrendingPage() {
  // ✅ next: { revalidate: 600 } -> 10분(600초)짜리 ISR 전략 선언!
  const res = await fetch('https://api.youngsu.com/bestsellers', {
    next: { revalidate: 600 }
  })
  const trends = await res.json()
 
  // 🦁 영호: "사용자는 10분 동안 구워진 HTML을 광속으로 받고, 10분이 지나면 백그라운드에서 새 국밥이 끓여집니다."
  return <ul>{trends.map(t => <li key={t.id}>{t.title}</li>)}</ul>
}

[시니어 관점의 ISR의 함정 주의]
ISR의 단점은 완벽한 실시간성을 보장할 수 없고, 누군가 희생양 1명이 지나간 이후에야 새 컨텐츠로 덮어씌워진다는 거야(Stale-While-Revalidate 아키텍처 한계). 즉각 무효화가 필요할 땐 훗날 다룰 revalidateTag 등 고급 기법이 요구돼.

🧪 따라해보기: 내 라우트가 Static인지 Dynamic인지 확인하기

🎯 이 섹션 이후에 당신은:

• npm run build 결과물을 보고 내 코드의 렌더링 전략을 판독할 수 있다.

영호 님이 영철 님에게 가장 먼저 가르친 것은 바로 빌드 로그 읽는 법이었어.

npm run build

다 끝나면 대시보드에 이런 멋진 결과가 떠.

Route (app)                              Size     First Load JS
┌ ○ /                                    142 B    84.1 kB
├ ○ /about                               182 B    84.2 kB
├ ƒ /dashboard                           312 B    84.3 kB
└ ◐ /trending                            240 B    84.2 kB
 
○  (Static)  automatically rendered as static HTML (uses no initial props)
ƒ  (Dynamic) server-rendered on demand using Node.js
◐  (ISR)     incremental static regeneration (uses revalidate in fetch())

🎯 개인화 피드와 SSR 격리 전략 🟡

🎯 이 섹션을 읽고 나면:

• 개인화 피드가 왜 SSR이 필요한지 이유를 설명할 수 있다.
• Suspense 경계로 SSR 필요한 부분만 격리하고 나머지 Static을 유지하는 패턴을 적용할 수 있다.
• useSearchParams 를 쓸 때 전체 페이지가 Dynamic으로 강등되지 않도록 처리하는 방법을 안다.

개인화 피드는 왜 SSR이어야 할까?

영수네 커뮤니티 메인 피드 페이지는 로그인하면 "내가 팔로우하는 스터디 그룹" 의 최신 게시글만 보여줘야 해. 이 피드는 아래 이유로 빌드 타임에 미리 구워둘 수가 없어:

1. 사용자마다 다르다 — 영철 님의 피드는 "프론트엔드" 스터디만 보이고, 영숙 님의 피드는 "디자인" 스터디만 보여. 미리 구울 수가 없지.
2. 쿠키/세션에 의존한다 — 로그인 상태를 서버에서 쿠키로 확인해야 해. cookies() 함수를 쓰는 순간 Static 불가.
3. 실시간성이 필요하다 — 방금 올라온 게시글이 있으면 바로 보여야 해.

이 경우 피드 컴포넌트만큼은 SSR(Dynamic Rendering) 이 맞아. 접속할 때마다 서버에서 쿠키를 읽고, 해당 유저의 구독 스터디 목록을 DB에서 꺼내서 HTML을 즉석으로 만들어야 하거든.

문제: 피드 하나 때문에 페이지 전체가 Dynamic으로 강등된다!

이 개인화 피드를 page.tsx 최상단에 바로 넣으면 큰일 나.

// ❌ 순진한 코드: 메인 페이지 전체가 Dynamic으로 강등됨
// app/feed/page.tsx
export default async function FeedPage() {
  const cookieStore = await cookies() // 🐣 영철: "아무 생각 없이 여기서 쿠키를 읽었더니..."
  const userId = cookieStore.get('user-id')?.value
  const feed = await db.posts.findMany({ where: { authorFollowedBy: userId } })
 
  return (
    <div>
      <HeroSection />        {/* Static으로 충분한데, 덩달아 Dynamic으로 강등됨 */}
      <TrendingTopics />     {/* ISR이면 충분한데, 역시 Dynamic으로 강등됨 */}
      <PersonalizedFeed feed={feed} />  {/* 이것만 Dynamic이 필요한데 */}
    </div>
  )
}

빌드 결과를 보면 /feed 가 ƒ (Dynamic) 으로 표시되어, 1만 명이 동시에 접속하면 1만 번 즉석 렌더링이 발생해. HeroSection 과 TrendingTopics 는 Static으로 충분했는데 억울하게 희생된 거야.

해결책: Suspense 경계로 SSR 부분만 정밀 격리

영호 님 이 제시한 실전 아키텍처야. SSR이 필요한 컴포넌트만 비동기 서버 컴포넌트로 분리하고, 나머지는 Static으로 유지 하는 방법이야.

// ✅ 우아한 코드: SSR 격리 + Static 보존
// app/feed/page.tsx
import { Suspense } from 'react'
import PersonalizedFeed from '@/components/PersonalizedFeed'
 
// 🦁 영호: "page.tsx 자체는 정적(Static)으로 남겨두고, 쿠키 사용처만 도려냅니다."
export default function FeedPage() {
  return (
    <div>
      <HeroSection />
      <TrendingTopics />
 
      <Suspense fallback={<FeedSkeleton />}>
        <PersonalizedFeed />  {/* 이 컴포넌트 안에서만 cookies() 사용 */}
      </Suspense>
    </div>
  )
}

// app/components/PersonalizedFeed.tsx
// 이 컴포넌트만 SSR (Dynamic)
import { cookies } from 'next/headers'
 
export default async function PersonalizedFeed() {
  const cookieStore = await cookies()  // ← 여기서만 쿠키 접근
  const userId = cookieStore.get('user-id')?.value
 
  if (!userId) return <LoginPrompt />
 
  const posts = await db.posts.findMany({
    where: { authorFollowedBy: userId },
    orderBy: { createdAt: 'desc' },
    take: 20,
  })
 
  return <ul>{posts.map(p => <PostCard key={p.id} post={p} />)}</ul>
}

빌드 결과 비교:

useSearchParams 도 같은 원리로 격리해야 해

퀴즈 2번 해설에서 나온 searchParams 도 마찬가지야. useSearchParams() 를 쓰는 클라이언트 컴포넌트가 page.tsx 상단에 있으면 전체 페이지가 Dynamic으로 강등돼.

// ✅ searchParams 격리 패턴
// app/feed/page.tsx — Static 유지
export default function FeedPage() {
  return (
    <div>
      <HeroSection />
      <Suspense fallback={<FilterSkeleton />}>
        <FilteredFeed />  {/* searchParams 쓰는 클라이언트 컴포넌트를 격리 */}
      </Suspense>
    </div>
  )
}

// app/components/FilteredFeed.tsx
'use client'
import { useSearchParams } from 'next/navigation'
 
export default function FilteredFeed() {
  const searchParams = useSearchParams()
  const category = searchParams.get('category') // ?category=frontend
  // ...
}

⚠️ 주의: useSearchParams() 를 쓰는 클라이언트 컴포넌트를 Suspense로 감싸지 않으면 Next.js가 빌드 경고를 내보내. 반드시 <Suspense> 경계 안에 넣어야 해.

💡 한 줄로 기억하기
Dynamic이 필요한 부분만 <Suspense> 안의 서버 컴포넌트(쿠키 접근)나 클라이언트 컴포넌트(searchParams)로 격리해. 나머지는 Static이 유지돼서 CDN이 대신 처리해줄 거야.

🏁 이번에 배운 내용 총정리

• SSG (○): 변하지 않는 텍스트의 회사 소개나 에러 폼. 최상의 속도.
• SSR (ƒ): 쿠키 등 개인화가 무조건 필요한 대시보드.
• ISR (◐): 준-실시간이 필요한 쇼핑몰 베스트셀러, 커뮤니티 인기글.

📝 마무리 퀴즈

Q1. 정적 렌더링과 동적 렌더링을 가르는 핵심 질문은?

✅ 정답: 요청마다 달라지는 입력이 렌더링 결과를 바꾸는가이다.

💡 상세 해설: cookies(), headers(), 사용자별 권한처럼 요청에 묶인 값이 필요하면 동적 렌더링이 자연스럽다. 모두에게 같은 결과라면 정적 렌더링이나 ISR을 검토할 수 있다.

Q2. ISR이 어울리는 데이터는 어떤 데이터인가?

✅ 정답: 모두에게 같지만 일정 주기로 새로워져야 하는 데이터다.

💡 상세 해설: 공지 목록이나 인기 글처럼 몇 분 늦어도 괜찮은 데이터는 revalidate 시간을 둘 수 있다. 내 알림처럼 사용자별 즉시성이 필요한 데이터에는 맞지 않는다.

Q3. 영철이의 테스트 타임: 홈에는 공지 목록과 내 알림 수가 함께 있다. 렌더링 전략을 어떻게 나눌까?

✅ 정답: 공지 목록은 정적/ISR 후보로, 내 알림 수는 동적 영역으로 분리한다.

💡 상세 해설: 한 화면 안에서도 데이터 성격은 다를 수 있다. 영호는 페이지 전체를 한 단어로 부르기 전에 각 데이터의 신선도와 개인화 여부를 나누라고 조언할 것이다.

🐣 영철이의 퇴근 일기

오늘은 페이지를 빠르게 만들지 동적으로 만들지 감으로 고르지 않게 됐다.

💡 "렌더링 전략은 성능 취향이 아니라 데이터가 언제 누구에게 달라지는지의 결과다."

다음 설계에서는 데이터마다 공개성, 신선도, 요청 의존성을 먼저 표로 나누겠다.

🔗 더 알아보기

• Next.js Docs: Rendering