Next.js

식당을 생각하면 편하다. 음식을 언제 만드느냐가 갈린다. 주문을 받고 그때부터 조리하면 항상 갓 만든 음식이 나오지만 손님이 좀 기다린다. 재료만 손님 테이블에 주고 직접 조리하게 하면 주방은 편한데 손님 자리에서 시간이 든다. 아니면 아예 미리 다 만들어 진열대에 올려두고 손님이 오면 바로 집어가게 한다. Next.js가 화면(HTML)을 만드는 방식이 딱 이 셋이다. 각각 SSR, CSR, SSG다.

Next.js는 React "위에 얹힌" 프레임워크다. React는 화면을 컴포넌트로 그리는 재료고, Next.js는 그 화면을 언제, 어디서 그릴지를 정해주는 틀이다.

화면을 언제 만드느냐, 세 가지

같은 결과(HTML)를 만드는데, 만드는 시점과 장소가 다르다.

• SSR (Server-Side Rendering) — 요청이 올 때마다 서버가 그 자리에서 HTML을 굽는다. 주문받고 조리하는 식당. 항상 최신 데이터가 나오고 로그인한 사람마다 다른 화면을 줄 수 있다. 대신 요청마다 서버가 일한다.
• CSR (Client-Side Rendering) — 서버는 거의 빈 껍데기 HTML만 주고, 브라우저가 자바스크립트를 돌려 화면을 그린다. 재료만 받아 손님이 직접 조리. 처음 화면이 뜨기까지 조금 걸리지만, 한 번 뜨면 이후 조작이 매끄럽다.
• SSG (Static Site Generation) — 빌드할 때 미리 모든 페이지를 HTML로 구워둔다. 진열대에 미리 올려둔 음식. 요청이 오면 이미 구운 걸 즉시 내주니 제일 빠르다. 대신 내용이 바뀌면 다시 구워야(빌드) 한다.

Java로 서버 렌더링 해본 사람 기준 다리

새로운 개념이 아니라 이미 해본 것들이다. 자리만 이름이 바뀐 거다.

Spring MVC에서 컨트롤러가 뷰 이름을 반환하고 서버가 HTML을 만들어 내려줬다면, 그게 정확히 SSR이 하는 일이다. 반대로 @RestController로 JSON만 주고 화면은 프론트가 그리게 했다면 그건 CSR 구조다. Next.js는 이 선택을 페이지 단위로 골라 쓰게 해준다는 게 다르다.

SSG로 화면이 나오기까지

이 블로그가 쓰는 방식인 SSG를 한 번 따라가 보면 감이 온다.

언제 뭘 쓰나

정답은 하나로 안 정해지고, 화면 내용이 얼마나 자주 바뀌느냐로 갈린다.

• 거의 안 바뀌는 화면(블로그 글, 문서, 소개 페이지) — SSG. 미리 구워두는 게 제일 빠르고 서버도 필요 없다.
• 요청마다 최신이어야 하거나 사람마다 다른 화면(대시보드, 주문 내역, 로그인 후 화면) — SSR 또는 CSR. 그때그때 만들거나 브라우저에서 채운다.
• 실무에선 한 사이트 안에서 섞어 쓴다. Next.js의 강점이 바로 이 "페이지마다 골라 쓰기"다.

우리 프로젝트에선

지금 읽고 있는 이 0to1 블로그가 통째로 SSG다. Next.js 설정에 output: 'export'를 줘서, 서버 없이 빌드 때 모든 페이지를 HTML로 구워버린다. 매번 npm run build를 돌리는 게 정확히 그 "미리 다 굽는" 과정이다. 그래서 배포된 사이트엔 돌아가는 서버가 없고, 구워진 정적 파일 뭉치만 CDN에 올라가 있다.

덕분에 빠르고 배포가 단순하지만, 글을 고치면 반드시 다시 빌드해야 화면에 반영된다 — 진열대 음식을 새로 만들어 다시 올려두는 셈이다. 이 빌드를 밤마다 자동으로 돌리는 장치가 AI 하네스플레이북AI 하네스Claude Code를 무인으로 부리려고 짠 협업 하네스.에 있다.

더 읽기

그림과 표로 셋을 더 풀어놓은 글들. 헷갈릴 때 하나씩.

• Next.js에서의 렌더링 방식 — CSR vs SSR vs SSG vs ISR (velog @minw0_o) — 다이어그램과 단계별 설명으로 네 방식을 한눈에
• Next.js의 렌더링 방식 — SSR, SSG, ISR (velog @donggoo) — 표로 비교하고 "블로그는 SSG" 같은 실제 예시로 감 잡기