렌더링 방식

같은 페이지라도 그 HTML을 언제, 어디서 만드느냐에 따라 방식이 갈린다. 음식으로 치면 이렇다. SSR은 주문받고 그때 조리해서 내주고, CSR은 재료만 주고 손님이 직접 만들고, SSG는 미리 만들어 진열해두고, ISR은 진열하되 주기적으로 새로 갈아둔다. 화면 결과물은 비슷해 보여도, 언제 요리했느냐가 속도·최신성·서버 부하를 전부 바꾼다.

CSR, 브라우저가 직접 그린다

브라우저가 거의 빈 HTML과 JS 뭉치를 받아, 브라우저 안에서 화면을 그린다. 순수 React(Vite·CRA)의 기본값이다. 서버는 파일만 던져주면 되니 부담이 적고, 한번 뜬 뒤엔 페이지 전환이 앱처럼 빠르다. 대신 JS가 다 실행될 때까지 초기 화면이 늦게 뜨고, 검색엔진이 빈 HTML을 먼저 보니 SEO에 불리하다. 그래서 로그인 후 대시보드·관리자 화면처럼 SEO가 필요 없는 내부 앱에 잘 맞는다.

SSR, 요청마다 서버가 완성해 내려준다

요청이 올 때마다 서버가 HTML을 완성해서 내려준다. 사용자는 내용이 채워진 페이지를 바로 보고, 검색엔진도 읽을 게 있으니 SEO가 좋다. 매 요청마다 서버가 다시 그리니 항상 최신이다. 단점은 그 "매 요청마다"가 곧 서버 부하라는 것. 자주 바뀌면서 SEO도 필요한 것(상품 상세, 뉴스)에 적합하다.

SSG, 빌드 때 미리 다 구워둔다

빌드 시점에 HTML을 전부 미리 만들어둔다. 요청이 오면 완성된 파일만 그대로 전달하니 제일 빠르고(CDN에 얹기 좋다), 서버 부하는 거의 0이다. 대신 내용이 바뀌면 다시 빌드해야 새 HTML이 나온다. 잘 안 바뀌는 것(블로그, 문서, 랜딩)에 최적이다.

ISR, 진열해두되 주기적으로 새로 굽는다

SSG인데, 일정 시간마다 백그라운드에서 자동으로 다시 생성한다(예: 60초마다 갱신). 정적 파일의 속도를 그대로 누리면서, 주기적으로 최신 내용으로 갈아 끼우는 절충안이다. 가끔 바뀌는데 트래픽은 많은 것(상품 목록, 인기글)에 맞다. Next.js의 킬러 기능으로 꼽힌다.

한 장 비교

방식	HTML 만드는 시점	속도	SEO	데이터 신선도
CSR	브라우저에서 실행될 때	초기 느림 · 전환 빠름	불리	부른 만큼 실시간
SSR	요청이 올 때마다 서버	초기 빠름	좋음	항상 최신
SSG	빌드 때 한 번	제일 빠름 (CDN)	좋음	빌드 시점에 고정
ISR	빌드 + 주기적 재생성	정적만큼 빠름	좋음	주기적으로 최신

Next.js의 진짜 강점, 섞어 쓴다

넷 중 뭘 쓰느냐가 아니라, 한 사이트 안에서 페이지마다 골라 쓴다는 게 Next.js의 핵심이다. 랜딩은 SSG로 미리 구워 CDN에 얹고, 상품 상세는 ISR로 주기 갱신하고, 마이페이지는 CSR로 브라우저에서 그린다. 페이지 성격에 맞는 방식을 각각 물릴 수 있어서, "무조건 서버 렌더" 같은 한 방식에 묶이지 않는다.

우리 프로젝트에선

지금 읽고 있는 이 0to1 블로그는 output: 'export'로 굳힌 SSG다. 서버가 따로 없고, npm run build가 돌 때마다 모든 글·위키 페이지를 HTML로 전부 구워서 정적 파일로 떨군다. 그래서 배포는 그 구운 결과물을 그대로 올리는 것뿐이고, 사이트를 서비스하는 데 상시 켜둔 렌더 서버가 없다.

이 "빌드 때 다 굽는다"는 성질 덕에 자동화도 빌드 파이프라인에 얹혀 돌아간다. 신선도 점수·글 목록을 만드는 스크립트가 빌드 단계에서 함께 실행되는 식이다 — 그 언저리는 AI 하네스플레이북AI 하네스Claude Code를 무인으로 부리려고 짠 협업 하네스.에 정리해뒀다. 방식을 골라 쓰게 해주는 프레임워크 자체 얘기는 Next.js플레이북Next.js화면(HTML)을 언제 만드느냐로 갈린다.에서 이어진다.

더 읽기

네 방식을 그림·예제로 더 풀어놓은 글들. 헷갈릴 때 하나씩.

• Next.js에서의 렌더링 방식 — CSR vs SSR vs SSG vs ISR (velog) — 네 가지를 한 글에서 나란히 비교
• 렌더링 방식의 이해 (CSR·SSR·SSG·ISR) — Nextjs 완전정복 (wikidocs) — 목차 잡힌 교과서식 정리