🚀 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. 영철 님이 마이페이지(SSR 필수)에서 내 개인정보를 보여주는 기능을 짰다. 이 페이지 최상단 컴포넌트인 app/dashboard/layout.tsx 에 export const dynamic = "force-static" 을 붙여서 고의로 억지 최적화를 감행하려 시도했다. 영철 님의 순진한 코드는 빌드 시점에 어떤 문제를 마주치게 될 것이며 그 이유는 무엇인가?

✅ 정답: Dynamic server usage: cookies 에러를 뿜으며 빌드를 거부한다.

💡 상세 해설:

• 원리 설명: 강제로 force-static(SSG)을 지정했음에도 불구하고, 자식 컴포넌트 어딘가에서 cookies() 나 headers() 같은 런타임 제약 함수를 사용한다면 Next.js는 즉시 에러를 뿜으며 빌드를 거부해.
• 오답 피드백: 영철 님, "쿠키는 유저가 브라우저로 접속해야만 생겨나는 정보인데, 왜 나한테 접속자도 없는 빌드 타임에 미리 정적으로 구워놓으라고 강요하냐?" 라며 컴파일러가 강력히 항의하는 논리 구조야. SSR 기능과 Static 강제화는 동시에 성립될 수 없는 모순이지.
• 📌 핵심 기억법: 정적(Static)과 동적(Dynamic)은 물과 기름 같은 것!

Q2. 영수네 커뮤니티 메인 대문(/) 은 완벽한 ○ (Static) 판정을 받았다. 그런데 어느 날 영철 님이 "메인 페이지 최상단에 오늘 접속자들이 검색한 트렌드 키워드를 실시간 파라미터로 붙여서 노출합시다!" 라며 컴포넌트 Props로 searchParams 를 내려받는 코드를 작성해 넣었다. 이 코드 한 줄은 메인 서버에 어떤 치명적인 리소스 변화를 몰고 올까?

✅ 정답: 비용이 0이었던 메인 홈페이지 전체가 매 접속마다 서버 CPU를 소모하는 ƒ (Dynamic) 렌더링으로 강등된다.

💡 상세 해설:

• 원리 설명: searchParams 는 브라우저 주소창 파라미터(?query=123)를 추적해야 하므로 런타임에만 알 수 있는 Dynamic 정보야.
  💡 상세 해설:
• 원리 설명: searchParams 는 브라우저 주소창 파라미터(?query=123)를 추적해야 하므로 런타임에만 알 수 있는 Dynamic 정보야.
• 오답 피드백: 이것을 부모 레벨 컴포넌트에서 읽는 순간, 비용이 0(Zero)이었던 거대한 메인 홈페이지 전체가 매 접속마다 서버 CPU를 깎아먹는 ƒ (Dynamic) 렌더링으로 몽땅 희생 강등 처리돼.
• 📌 핵심 기억법: 영호 리드 님 이라면 이런 상황에서 클라이언트 컴포넌트 Leaf 부분으로 검색 파라미터 로직만 격리시켜 메인 page.tsx 의 Static 속성을 끈질기게 수호했을 거야.

🐣 영철이의 퇴근 일기

오늘 다양한 렌더링 전략을 배우면서 상황에 맞는 도구를 고르는 게 얼마나 중요한지 깨달았어! 특히 '미리 끓여놓는 육수(Static)' 와 '주문 즉시 볶아내는 요리(Dynamic)' 의 비유는 영원히 잊지 못할 것 같아.

💡 오늘의 교훈: "서버의 평화를 위해, Dynamic 함수는 꼭 필요한 곳에만 Suspense로 격리하자!"

내가 무심코 추가한 cookies() 한 줄이 서버 비용을 폭증시킬 수 있다는 게 정말 무섭더라. 앞으로는 빌드 로그의 ○ 와 ƒ 아이콘을 연인 얼굴 보듯 꼼꼼히 챙겨봐야겠어. 오늘은 머리를 너무 많이 썼더니 당이 떨어지네. 집에 가는 길에 달달한 초코 우유 하나 사서 마셔야지! 비록 지금은 실수투성이 영철이지만, 내일은 오늘보다 더 '정적(Static)'이고 우아한 코드를 짜보겠어! 🐣

🔗 더 알아보기

• Next.js Docs: Rendering