[Next] SSG(Static Site Generation)란? 🚀

SSG(Static Site Generation)란?🚀 

Next.js에서 SSG(Static Site Generation, 정적 사이트 생성)

빌드 시점에 HTML을 생성하여, 요청 시 빠르게 제공할 수 있도록 하는 렌더링 방식입니다.

 

즉, 페이지를 서버에서 미리 렌더링해놓고 정적인 HTML 파일로 저장하여, 사용자가 접속할 때 즉시 제공하는 방식이에요.

 

이렇게 하면 사용자에게 빠른 로딩 속도를 제공하고, 검색 엔진 최적화(SEO)에도 유리하다는 장점이 있습니다.

🥸 SSG는 왜 생겨났을까요?

과거에는 동적 콘텐츠를 제공하기 위해 서버사이드 렌더링(SSR)이나 클라이언트사이드 렌더링(CSR) 방식이 주로 사용되었습니다.

그러나 이 방식은 페이지 로딩 시간이나 서버 부하 문제 등에서 한계를 드러냈습니다.

 

특히, 사용자가 웹사이트를 방문할 때마다 매번 서버에서 요청하고 응답을 받아야 하는 과정이 UX 경험에 상당히 안좋았죠.

 

이러한 문제를 해결하기 위해 CSR과 SSR과는 다르게 "그냥 미리 빌드해버리자!"는 필요에  SSG가 등장하게 되었습니다.

이는 정적인 페이지를 미리 생성하여 사용자가 요청할 때 즉시 제공함으로써 성능을 획기적으로 향상시켰습니다.

---

🔥 SSG(Static Site Generation)의 원리

📌 빌드 타임에 HTML을 생성

• Next.js는 getStaticProps(Pages Router) 또는 generateStaticParams(App Router)를 사용하여 정적인 데이터를 가져오고, 이를 바탕으로 미리 HTML을 생성합니다.
• 생성된 HTML은 CDN(콘텐츠 전송 네트워크)에 배포되어 초고속 로딩 속도를 제공합니다.
• 따라서, 서버 요청 없이 HTML과 필요한 자바스크립트만 로드하면 끝!

📌 SSG가 적합한 상황

• ✔️ 변경이 적고, 모든 사용자에게 동일한 데이터를 제공하는 페이지
• ✔️ 검색 엔진 최적화(SEO)가 중요한 블로그, 문서 사이트, 마케팅 페이지
• ✔️ 서버 부하를 줄이고 싶을 때

📌 SSG의 주요 함수

📍 Pages Router에서 사용

export async function getStaticProps() {
  const res = await fetch('https://jsonplaceholder.typicode.com/posts');
  const posts = await res.json();

  return {
    props: { posts }, // 빌드 타임에 posts 데이터를 가져와서 정적인 HTML에 삽입
  };
}

 

📍 App Router에서 사용

export async function generateStaticParams() {
  const res = await fetch('https://jsonplaceholder.typicode.com/posts');
  const posts = await res.json();

  return posts.map((post) => ({
    slug: post.id.toString(),
  }));
}

---

🎯  CSR, SSR과 비교

렌더링 방식	설명	요청 시 서버 작업	초기 로딩 속도	SEO
CSR (Client-Side Rendering)	클라이언트에서 데이터를 가져와 렌더링	필요	느림	SEO에 불리
SSR (Server-Side Rendering)	요청마다 서버에서 HTML을 생성	항상	느림	SEO 가능
SSG (Static Site Generation)	빌드 시 HTML을 생성하여 제공	없음	빠름	SEO 가능

✅ CSR(Client-Side Rendering)과 차이점

• CSR은 초기 HTML에 데이터가 없음, 브라우저에서 API 요청 후 데이터를 가져와 그립니다.
• 사용자가 처음 페이지를 로드할 때까지 빈 화면이 나올 수 있음(Loading UI 필요)

✅ SSR(Server-Side Rendering)과 차이점

• SSR은 매 요청마다 서버에서 HTML을 생성하기 때문에 TTV(Time To View)가 늦을 가능성이 있음
• SSG는 한 번만 빌드하면 끝이라 초기 로딩이 더 빠름.

---

🔍  SSG에서 빌드될 때 생성되는 파일

🛠️ SSG로 생성된 파일을 확인하는 방법

1️⃣ Next.js 프로젝트를 빌드합니다.

npm run build

 

2️⃣ .next/ 폴더를 확인해보면, 정적 HTML 파일이 생성됩니다.

ls .next/static

 

3️⃣ out/ 폴더에서 HTML 파일을 확인할 수도 있습니다.

npm run export  # 정적 사이트를 export
ls out/

---

🏗️ 생성되는 주요 파일들

📂 .next/ 내부 구조

.next/
 ├── static/             # 정적인 JS, CSS, 이미지 등
 ├── server/             # SSR 관련 파일
 ├── build-manifest.json # 빌드된 리소스 목록
 ├── prerender-manifest.json # SSG된 페이지 목록
 └── routes-manifest.json # 경로 관리

---

🔥 Hydration 과정에서 어떤 일이 일어날까?

• HTML은 미리 렌더링되어 제공되지만, React가 브라우저에서 이를 활성화(hydrate)하여 상호작용 가능하도록 함
• 브라우저에서 JavaScript를 실행하면서 클릭, 입력 등의 이벤트를 연결하는 과정이 포함됨
• 따라서, Hydration이 완료되기 전까지는 버튼 클릭이 안 될 수도 있음!

---

🏆  App Router(파일 기반 라우팅)에서 SSG 사용 시 차이점

📍 Pages Router(getStaticProps) vs. App Router(generateStaticParams)

	Pages Router (getStaticProps)	App Router (generateStaticParams)
호출 시점	빌드 타임	빌드 타임
데이터 제공 방식	props로 전달	params로 정적 경로 생성
다이내믹 라우팅 지원	✅	✅
클라이언트 요청 필요 여부	❌	❌

💡 결론

App Router는 경로를 미리 생성하여 정적 HTML로 제공하는 방식이지만,

Pages Router와 다르게 generateStaticParams()로 동적 경로를 정적으로 정의해야 한다는 차이점이 있음.

---

✅  SSG가 적합한 경우 vs SSR이 적합한 경우

요구 사항	SSG(Static Generation)	SSR(Server-Side Rendering)
데이터 변경 빈도	거의 변하지 않음 (블로그, 문서)	자주 변경됨 (사용자 프로필, 대시보드)
SEO 중요도	매우 중요 (검색엔진 최적화)	중요하지만, SSG보다는 느림
첫 페이지 로딩 속도	빠름 (정적 HTML 제공)	상대적으로 느림 (서버 렌더링 필요)
API 요청 필요 여부	❌ (미리 HTML 생성)	✅ (요청마다 새로운 데이터)

💡 결론:

• ✔️ SSG는 정적인 페이지에 강력하지만, 실시간 데이터가 필요한 경우 SSR 또는 CSR을 고려해야 함
• ✔️ 이미지 같은 정적 파일을 CDN과 함께 사용하면 성능 최적화 가능
• ✔️ 다이나믹 API 데이터가 많다면 ISR(Incremental Static Regeneration) 고려 가능

---

🔥 SSG vs. MPA(멀티 페이지 애플리케이션)

	SSG (Static Site Generation)	MPA (Multi-Page Application)
페이지 로딩 방식	미리 생성된 정적 HTML 제공	새로운 페이지 요청마다 전체 HTML 다시 다운로드
SEO	✅ 매우 유리 (HTML이 미리 생성됨)	✅ 유리하지만, 서버 렌더링이 필요
속도	✅ 최초 로딩 빠름	❌ 네트워크 요청 많으면 느려질 수 있음
서버 부하	✅ 서버 요청이 거의 없음	❌ 매 페이지마다 서버에 요청
UX	✅ 부드러운 전환 (클라이언트 내비게이션)	❌ 새로고침이 발생하여 UX가 덜 부드러움
사용 사례	✅ 블로그, 문서 사이트, 정적 콘텐츠	✅ 관리자 페이지, 포털 사이트, 검색 기반 서비스

✅ MPA는 어떤 경우에 더 유리할까?

• 검색 기반 웹 서비스: 검색 엔진이 매번 새로운 데이터를 가져와야 할 때
• 대형 사이트/포털: 네비게이션이 중요하고, 페이지 간 상태 공유가 적을 때
• 보안이 중요한 서비스: 매 요청마다 새로운 HTML을 불러오는 것이 보안에 유리

💡 결론

MPA는 매 요청마다 전체 HTML을 다시 받아오기 때문에 UX가 다소 떨어질 수 있지만,

서버 중심 애플리케이션에서는 여전히 강력한 선택지예요.

---

🧐 SSG가 항상 최고의 선택일까?

SSG는 속도와 SEO 측면에서 강력하지만, 모든 상황에서 최선은 아니에요. 아래와 같은 한계점이 존재합니다.

 

❌ (1) 데이터가 자주 변경되면 적합하지 않음

• SSG는 빌드 시 데이터를 고정하기 때문에, 자주 변하는 데이터에는 적합하지 않음
• 예를 들어, 실시간 뉴스, 주식 가격, 사용자 프로필 페이지와 같이 자주 업데이트되는 데이터는 SSG가 비효율적일 수 있어요.

✅ 해결 방법: ISR(Incremental Static Regeneration) 사용하기

Next.js의 ISR(증분 정적 생성)을 활용하면, 특정 주기로 정적 페이지를 다시 생성할 수 있어요.

export async function getStaticProps() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();

  return {
    props: { data },
    revalidate: 60, // 60초마다 페이지 재생성
  };
}

 

👉 이렇게 하면 정적 페이지의 성능을 유지하면서도 최신 데이터 반영 가능! 🎯

 

❌ (2) 빌드 시간이 오래 걸릴 수 있음

• 페이지가 많을수록 빌드 시간이 길어짐
• 예를 들어, 수천 개의 블로그 글을 SSG로 생성하면 빌드 시간이 수십 분 이상 소요될 수도 있음

✅ 해결 방법: 동적 경로 제한 및 ISR 적용

• generateStaticParams() 또는 getStaticProps()에서 필요한 데이터만 사전 생성하고, 나머지는 동적 요청으로 처리
• ISR을 활용하여 일부 페이지는 정적 생성 후 점진적으로 업데이트

 

❌ (3) 사용자별 데이터가 필요한 경우 어려움

• SSG는 한 번 생성되면 모든 사용자에게 동일한 HTML을 제공
• 하지만 로그인한 사용자마다 다른 데이터를 제공해야 하는 경우 SSG는 적합하지 않음
• 예를 들어, 쇼핑몰의 마이페이지, 대시보드, 사용자 맞춤 콘텐츠 등

✅ 해결 방법:

1️⃣ SSG + 클라이언트 사이드 데이터 패칭(CSR) 조합

function UserProfile() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch('/api/user')
      .then((res) => res.json())
      .then((data) => setUser(data));
  }, []);

  if (!user) return <p>Loading...</p>;

  return <p>Welcome, {user.name}!</p>;
}

 

2️⃣ SSR(Server-Side Rendering)로 특정 페이지만 서버에서 렌더링

export async function getServerSideProps(context) {
  const res = await fetch(`https://api.example.com/user/${context.params.id}`);
  const user = await res.json();

  return { props: { user } };
}

 

👉 결론: SSG + CSR + ISR + SSR을 적절히 조합하면 문제 해결 가능! 🔥

---

🎯  SSG가 빛을 발하는 경우 vs. 다른 전략이 필요한 경우

상황	SSG 사용 가능?	대안
✅ 정적인 콘텐츠 (블로그, 문서)	SSG
❌ 실시간 데이터 (뉴스, 주식)	ISR / CSR / SSR	revalidate 사용
❌ 사용자별 맞춤 데이터 (대시보드)	SSR / CSR	getServerSideProps 또는 API 요청
❌ 매우 많은 페이지 (100,000+ 페이지)	SSG + ISR	generateStaticParams로 제한
✅ SEO가 중요한 페이지	SSG / SSR
✅ 속도가 중요한 랜딩 페이지	SSG

---

🚀 마무리

💡 SSG는 빠르고 SEO 최적화에 유리하지만, 항상 정답은 아니다!

💡 자주 변하는 데이터, 사용자별 콘텐츠가 있다면 ISR/SSR/CSR을 조합하는 것이 필요하다.

 

📌 정리하면:

✅ 변경이 거의 없는 페이지는 SSG가 최고

✅ 데이터가 가끔 변한다면 ISR(Incremental Static Regeneration) 사용

✅ 사용자별 데이터가 필요하면 SSR 또는 CSR 활용

 

🌷전설의 개발자가 되어봅시당! 🌷