[Next.js] Next.js의 4가지 렌더링 방식(SSG, ISR, SSR, CSR)

🗣️ Next.js의 4가지 렌더링 방식에 대해서 설명할 수 있나요?

• 의도: 지원자가 Next.js의 다양한 렌더링 방식을 이해하고 있는지 평가

• 팁
  • 각 렌더링 방식(SSR, ISR, SSR, CSR)의 정의와 특징을 설명한다.
  • 각 방식의 사용 사례를 설명한다.
  • 각 렌더링 방식을 구현하는 방법을 설명한다.

• 주어진 답안 (모범 답안)

  Next.js는 총 4가지 렌더링 방식을 지원합니다. 각각의 특징과 사용법을 설명드리겠습니다.

  SSG는 Static Site Generation으로, 빌드 타임에 미리 정적인 HTML 만들어 두는 방식입니다.
  App Router에서는 fetch에서 기본 캐시(force-cache)를 사용하면, 그 라우트가 자동으로 정적 페이지로 빌드됩니다.
  이런 방식은 블로그 글, 문서, 마케팅 페이지처럼 자주 바뀌지 않는 콘텐츠에 적합하고, 빠른 로딩 속도와 SEO에 강점이 있습니다.

  ISR은 Incremental Static Regeneration으로, SSG 페이지를 배포 후에도 일정 주기로 다시 생성할 수 있게 해주는 방식입니다.
  라우트 파일 상단에 revalidate를 설정하거나, fetch 옵션으로 revalidate 주기를 설정해서 정적 페이지를 백그라운드에서 갱신합니다.
  이렇게 하면 최초에는 SSG처럼 빠르게 응답하면서도, 몇 분에서 몇 시간 단위로 데이터가 변하는 리스트나 게시판에 최신 데이터를 반영할 수 있고, 매 요청마다 서버 렌더링을 하는 SSR보다 성능 면에서 이점이 있습니다.

  SSR은 Server-Side Rendering으로, 요청이 들어올 때마다 서버에서 데이터를 가져와 페이지를 렌더링하는 방식입니다.
  라우트 파일 상단에 dynamic을 force-dynamic으로 설정하거나, fetch에서 cache 옵션을 'no-store'로 주면 요청 시마다 데이터를 새로 가져오도록 만들 수 있습니다.
  이런 방식은 항상 최신 데이터가 필요하거나, 로그인 사용자별 맞춤 정보처럼 요청마다 다른 데이터를 렌더링해야 하는 페이지에 적합합니다.
  하지만 매 요청마다 서버에서 렌더링을 수행하므로 성능 부담이 있을 수 있습니다.

  CSR은 Client-Side Rendering으로, 페이지를 먼저 로드한 후 클라이언트에서 JavaScript를 이용해 데이터를 가져와 동적으로 렌더링하는 방식입니다.
  "use client"가 선언된 클라이언트 컴포넌트 안에서 useEffect, React Query, SWR 등을 사용해 API를 호출하면, 그 부분은 CSR로 동작합니다.
  이 방식은 SEO보다는 사용자의 상호작용과 상태 관리가 중요한 대시보드나, 로그인 후 개인화된 정보가 필요한 페이지에 적합합니다.

  각 렌더링 방식은 프로젝트의 요구사항에 따라 선택적으로 적용할 수 있으며, Next.js는 이들을 조합하여 유연한 웹 애플리케이션을 개발할 수 있도록 지원합니다.

---

📝 개념 정리

🌟 공통으로 알아두면 좋은 개념

1. Pre-rendering (사전 렌더링)

Next.js는 기본적으로 브라우저가 JS를 실행하기 전에 HTML을 먼저 만들어서 보내는 방식을 사용한다.
이 HTML을 미리 만드는 시점이 네 방식의 핵심 차이이다.

• SSG: 빌드 시점에 HTML을 만든다. (next build)
• ISR: SSG처럼 만들어두되, 배포 후 일정 시간마다 다시 만든다.
• SSR: 요청이 올 때마다 서버에서 HTML을 생성한다.
• CSR: 서버에서 HTML은 거의 빈 상태로 보내고, 브라우저에서 JS로 렌더링한다.

2. Hydration (하이드레이션)

SSG, ISR, SSR은 모두 서버에서 HTML + 브라우저에서 JS로 인터랙션 붙이는 2단계 구조를 쓴다.
이미 화면이 보이는 상태에서 React가 이벤트 핸들러와 상태를 입히는 과정을 hydration이라고 한다.

---

🌟 SSG (Static Site Generation)

1. 개념

• 빌드 시점에 HTML을 전부 만들어서, 요청마다 그대로 재사용하는 방식
• next build할 때
  • 데이터 fetch → HTML 파일을 생성
  • 배포 후에는 CDN에서 정적 파일처럼 서빙
• 요청이 들어와도 서버에서 다시 렌더링되지 않으며, 이미 만들어 둔 HTML만 응답한다.

2. Next.js(App Router)에서 어떻게 쓸까?

별도 함수 없이도

• 정적 데이터만 사용하거나
• fetch가 캐시 가능한 방식(기본값 또는 cache: 'force-cache')

이면 해당 라우트가 정적 렌더링(SSG)으로 처리된다.

3. 장단점

• 장점
  • 아주 빠른 응답 속도: HTML이 이미 만들어져 있으니 TTFB(Time to First Byte)/총 로딩이 빠르다.
  • CDN 캐싱이 쉬움: 서버 부하가 거의 없다.
  • SEO에 유리: HTML에 콘텐츠가 다 들어 있다.
• 단점
  • 데이터가 바뀌면 다시 빌드/배포해야 반영된다.
  • 사용자별 맞춤 데이터는 기본 SSG만으로 처리하기 어렵다.
• 언제 쓰면 좋을까?
  • 블로그, 문서 페이지, 소개/랜딩 페이지
  • 가격표처럼 자주 안 바뀌는 정보

---

🌟 ISR (Incremental Static Regeneration)

1. 개념

• SSG + 배포 후에도 일정 간격으로 정적 페이지를 다시 생성해주는 방식
• 즉, 정적 페이지지만 stale-while-revalidate 패턴으로 점진적으로 새로 고친다.
• 초기에는 SSG처럼 빌드 시점에 한 번 생성된다.
• 배포 후에는
  • revalidate 시간이 지나면, 다음 요청이 들어오는 순간 백그라운드에서 새 HTML을 생성한다.
  • 현재 요청한 유저는 기존(조금 오래된) HTML을 받고, 다음 유저부터는 새 HTML을 받게 된다.

2. Next.js(App Router)에서 어떻게 쓸까?

• 라우트 파일 상단에

  export const revalidate = 60; // 페이지 단위

• 또는 fetch 옵션에서

  await fetch('https://api.example.com/posts', {
    next: { revalidate: 60 },
  });

3. 장단점

• 장점
  • SSG처럼 빠르고 저렴하면서도 콘텐츠를 주기적으로 자동 업데이트할 수 있다.
  • 전 사이트를 다시 빌드할 필요 없이 바뀌는 페이지만 다시 생성한다.
• 단점
  • revalidate 시간이 지나지 않으면 옛날 데이터(캐시)를 보여줄 수밖에 없다.
  • 따라서 revalidate 주기 설계 + 캐시/무효화 전략을 잘 잡아야 한다.
  • 실시간성이 아주 중요한 경우(주식, 실시간 수치 등)에는 적합하지 않다.
• 언제 쓰면 좋을까?
  • 몇 분~몇 시간 단위로 갱신되는 콘텐츠 (실시간까지는 아니어도 되는 경우)
  • 뉴스 리스트, 인기 글, 가격/재고 정보
  • 공지사항, 이벤트 페이지 등

---

🌟 SSR (Server-Side Rendering)

1. 개념

• 요청이 들어올 때마다 서버에서 React를 렌더링해 HTML을 만들어 보내는 방식
• 사용자가 페이지를 요청하면, 서버는
  • 해당 라우트의 React 컴포넌트를 렌더링하고,
  • 필요한 데이터를 그 자리에서 fetch/DB 쿼리한다.
  • 그 결과를 포함한 HTML + Hydration용 JS를 응답한다.
• 브라우저는 이 HTML을 렌더링하고, JS가 로드되면 hydration으로 인터랙션을 활성화한다.

2. Next.js(App Router)에서 어떻게 쓸까?

• 라우트 파일 상단에

  export const dynamic = 'force-dynamic';

• 또는 fetch 옵션에서

  await fetch('https://api.example.com/posts', {
    cache: "no-store",
  });

3. 장단점

• 장점
  • 항상 최신 데이터를 제공한다. (요청마다 새 렌더)
  • 유저별/세션별 맞춤 데이터(쿠키, 헤더, 토큰)를 자연스럽게 처리한다.
  • HTML에 데이터가 들어가 있으므로 SEO에 적합하다.
• 단점
  • 요청마다 렌더링이 되므로 서버 부하가 증가한다.
  • TTFB가 SSG/ISR보다 느릴 수 있다.
  • 트래픽이 큰 서비스에서는 비용 측면에서 부담된다.
• 언제 쓰면 좋을까?
  • 로그인 후 개인화 대시보드
  • 항상 거의 실시간에 가까운 데이터를 보여줘야 하는 페이지
  • SEO도 중요하고, 데이터도 자주 바뀌는 경우

---

🌟 CSR (Client-Side Rendering)

1. 개념

• 서버에서는 최소한의 HTML만 보내고, 실제 UI와 데이터 렌더링은 브라우저에서 하는 방식
• 초기에 서버가 보내는 HTML은 거의 빈 div + JS 번들 스크립트이다.
• 브라우저는 JS를 다운로드하여 실행하고, API 호출로 데이터를 가져와 React로 화면을 그린다.
• 전통적인 React SPA(create-react-app 등)가 이 방식이다.
• Next.js에서는
  • app/ 또는 pages/ 안에서 "use client"가 선언된 컴포넌트 안에서
  • useEffect, React Query, SWR 등을 통해 브라우저에서 fetch하면 사실상 CSR이다.

2. Next.js에서의 CSR 사용 예

"use client";

import { useEffect, useState } from "react";

export default function ClientPage() {
  const [data, setData] = useState(null);
  
  useEffect(() => {
    fetch("/api/data")
      .then(res => res.json())
      .then(setData);
  }, []);
  
  if (!data) return <div>Loading...</div>;
  return <div>{data.message}</div>;
}

이 경우 HTML은 거의 텅 빈 상태로 내려오고, 브라우저에서 JS 실행 후에야 실제 내용을 볼 수 있다.

3. 장단점

• 장점
  • 초기 로드 후 페이지 전환/상호작용이 매우 부드럽다.
  • 서버 렌더링 없이 순수 프론트엔드 앱 구조를 그대로 가져갈 수 있다.
  • 로그인 이후 내부 대시보드 등 SEO가 중요하지 않은 페이지에 적합하다.
• 단점
  • 첫 로딩 때 비어 있는 화면이나 로딩 스피너를 보게 될 수 있다.
  • 검색 엔진이 JS 실행을 못 하는 경우, SEO가 매우 취약하다.
  • JS 번들이 크면 초기 FCP, TTI가 느려진다.
• 언제 쓰면 좋을까?
  • 로그인 뒤 내부 관리 페이지, 대시보드
  • SEO가 필요 없고, 사용자 상호작용이 많은 영역
  • 이미 상단에서 SSG/SSR로 뼈대를 렌더한 뒤, 일부 위젯만 클라이언트에서 CSR로 붙이는 하이브리드 섬(Islands) 구조

---

🌟 네 가지 방식 한 번에 비교하기

방식	HTML 생성 시점	데이터 신선도	SEO	서버 부하	대표 사용처
SSG	빌드 타임	빌드 시점 기준 (변경 시 재빌드 필요)	매우 좋음	거의 없음(CDN)	블로그, 문서, 랜딩
ISR	빌드 타임 + revalidate 주기마다 백그라운드에서 재생성	일정 주기마다 갱신	좋음	낮음	뉴스/리스트, 자주 갱신되는 컨텐츠
SSR	요청 시마다 서버 렌더링	항상 최신	좋음	높음	개인화 페이지, 실시간성 필요한 페이지
CSR	브라우저에서 JS로 렌더링	클라이언트 fetch 시점 기준	기본적으로 약함	서버 렌더링 부하는 없음 (API만)	내부 대시보드, 앱형 UI