SSG란 무엇인가 — 그리고 Astro는 왜 SSG로 시작하나

이 블로그는 글을 마크다운 파일로 두고, 빌드할 때 HTML로 통째로 찍어낸다. 서버에서 매번 페이지를 조립하지 않는다는 뜻이다. 이 방식을 SSG(Static Site Generation, 정적 사이트 생성) 라고 부른다.

언제 HTML을 만드느냐의 문제

웹 페이지를 만드는 타이밍은 크게 셋으로 갈린다.

CSR (클라이언트 렌더링): 서버는 거의 빈 HTML과 자바스크립트만 보내고, 브라우저가 화면을 그린다. React SPA의 기본형이다.
SSR (서버 렌더링): 요청이 올 때마다 서버가 그 자리에서 HTML을 조립해 보낸다. 로그인 상태나 실시간 데이터처럼 매번 달라지는 화면에 맞다.
SSG (정적 생성): 빌드 시점에 모든 페이지의 HTML을 미리 다 만들어 둔다. 사용자가 접속하면 이미 완성된 파일을 그대로 내려주기만 한다.

블로그·문서·소개 페이지처럼 내용이 사용자마다 달라지지 않는 사이트는 SSG가 잘 맞는다. 글은 발행 시점에 이미 정해져 있으니, 요청이 100번 오든 만 번 오든 매번 다시 만들 이유가 없다.

SSG가 주는 것

미리 다 만들어 두면 얻는 게 명확하다.

속도: 서버가 할 일이 “파일 찾아서 보내기”뿐이다. 렌더링 지연이 없다.
배포 단순함: 결과물이 그냥 HTML·CSS·JS 파일 묶음이라, DB도 서버 프로세스도 필요 없다. 정적 호스팅(GitHub Pages, Netlify 등)에 파일만 올리면 끝이다.
안정성·보안: 요청마다 도는 서버 코드가 없으니 공격 표면이 작고, 트래픽이 몰려도 잘 안 죽는다.

대신 내용이 바뀌면 다시 빌드해야 반영된다. 그래서 이 블로그도 글을 추가하면 사이트를 새로 빌드해 배포한다.

Astro는 왜 SSG가 기본인가

Astro는 콘텐츠 중심 사이트를 겨냥한 프레임워크라, 기본 출력이 SSG다. 페이지를 빌드 때 정적 HTML로 뽑고, 여기에 두 가지 무기를 얹는다.

자바스크립트 제로가 기본: Astro 컴포넌트는 서버(빌드)에서만 실행되고 결과 HTML만 남는다. 상호작용이 필요 없는 부분엔 JS를 아예 안 보낸다.
필요한 곳만 살리는 아일랜드: 검색창처럼 상호작용이 필요한 조각만 client:* 지시어로 되살린다. 페이지 전체가 아니라 그 섬만 자바스크립트를 받는다.

---
// 이 코드는 빌드 때 실행된다. 브라우저로 가지 않는다.
const posts = await getCollection("blog");
---
<ul>
  {posts.map((p) => <li>{p.data.title}</li>)}
</ul>
<!-- 결과: 순수 HTML <ul>. 목록엔 JS가 붙지 않는다. -->

정리하면 SSG는 “미리 만들어 두고 그대로 내보낸다”는 단순한 전략이고, Astro는 그 전략에 “필요한 만큼만 자바스크립트를 얹는다”를 더한 프레임워크다. 내용이 고정된 사이트라면, 매 요청마다 페이지를 다시 조립하는 비용부터 없애는 게 가장 큰 최적화다.