Next.js SSR vs SSG vs ISR: 언제 무엇을 써야 하나

Next.js에서 페이지를 만들 때 가장 자주 헷갈리는 선택지가 SSR, SSG, ISR입니다. 이름은 비슷하지만 운영 결과는 꽤 다릅니다. SSR은 요청이 올 때 서버에서 HTML을 만들고, SSG는 빌드할 때 HTML을 미리 만들며, ISR은 정적 페이지를 유지하되 일정 시간이 지나면 백그라운드에서 다시 생성합니다. 그래서 선택 기준은 "기술 취향"이 아니라 데이터가 얼마나 자주 바뀌는지, 사용자가 개인화된 화면을 보는지, 빌드 시간이 감당 가능한지로 잡아야 합니다.

한 줄 기준

SSG는 거의 변하지 않는 공개 콘텐츠에 맞습니다. SSR은 로그인, 권한, 실시간 가격, 재고처럼 요청마다 판단이 필요한 화면에 맞습니다. ISR은 블로그, 상품 상세, 문서, 랭킹처럼 자주 읽히지만 매초 새로울 필요는 없는 공개 페이지에 잘 맞습니다.

관련해서 메타 데이터까지 같이 정리하려면 Next.js 메타태그 가이드, 성능 점검은 PageSpeed 점검 도구, 설명문 길이는 메타 태그 체커, 예상 체류시간은 읽기 시간 계산기를 함께 보면 좋습니다. 이미지 최적화까지 묶어야 한다면 WebP·AVIF 이미지 포맷 가이드도 실무 체크리스트가 됩니다.

SSR을 쓰는 경우

SSR은 요청 시점의 정보를 HTML에 반영해야 할 때 선택합니다. 예를 들어 사용자별 대시보드, 결제 상태, 관리자 페이지, A/B 테스트가 서버 쿠키로 갈리는 페이지, 재고와 가격이 자주 바뀌는 예약 화면이 여기에 들어갑니다. 장점은 최신성과 개인화입니다. 단점은 요청마다 서버 작업이 필요하므로 캐시 전략, 데이터베이스 지연, 서버 비용을 같이 관리해야 한다는 점입니다.

실무에서는 "이 HTML을 다른 사용자에게 그대로 보여줘도 되는가"라고 물어보면 빠릅니다. 답이 아니면 SSR 가능성이 큽니다. 단, 모든 동적 페이지를 SSR로 만들 필요는 없습니다. 사용자 이름 한 줄만 다르고 본문은 같다면 정적 페이지에 클라이언트 컴포넌트로 작은 개인화 영역만 붙이는 편이 더 가볍습니다.

SSG를 쓰는 경우

SSG는 빌드 시점에 페이지를 만들어 CDN에 올리는 방식입니다. 회사 소개, 약관, 도움말, 오래 유지되는 튜토리얼, 변경 빈도가 낮은 랜딩 페이지에 적합합니다. 페이지 응답이 빠르고 서버 부담이 낮으며 장애 표면도 작습니다. 검색엔진이 보기에도 완성된 HTML이 안정적으로 제공됩니다.

주의할 점은 빌드 시간입니다. 글이 수만 개이고 모든 글을 빌드마다 다시 생성한다면 배포가 느려집니다. 또 콘텐츠가 바뀐 뒤 즉시 반영되어야 하는 운영 환경에서는 새 빌드가 필요합니다. 따라서 SSG는 "변경이 드물고, 변경 시 배포를 기다려도 되는 페이지"에 쓰는 것이 가장 자연스럽습니다.

ISR을 쓰는 경우

ISR은 SSG와 SSR 사이의 현실적인 절충안입니다. 첫 생성 후에는 정적 파일처럼 빠르게 제공하고, 설정한 재검증 시간이 지나면 백그라운드에서 새 HTML을 만듭니다. 블로그 글, 상품 상세, 지역별 가이드, 가격 비교 글, 공개 랭킹 페이지처럼 공개 콘텐츠이면서 가끔 업데이트되는 페이지에 잘 맞습니다.

예를 들어 블로그 본문은 하루에 한두 번 보강되지만 방문자는 계속 들어옵니다. 이때 매 요청 SSR을 쓰면 비용이 늘고, 순수 SSG를 쓰면 업데이트 반영이 번거롭습니다. ISR을 쓰면 캐시된 페이지를 빠르게 주면서도 일정 주기마다 최신 내용을 반영할 수 있습니다.

선택 표

운영 체크리스트

첫째, 페이지가 공개 캐시에 올라가도 되는지 확인합니다. 둘째, 데이터 변경 주기를 분 단위, 시간 단위, 일 단위로 나눕니다. 셋째, 빌드 시간이 콘텐츠 증가와 함께 얼마나 늘어나는지 측정합니다. 넷째, 검색 노출이 중요한 페이지는 메타태그와 구조화 데이터를 서버에서 안정적으로 제공합니다. 다섯째, 이미지와 폰트가 렌더링 전략보다 성능을 더 크게 망치고 있지 않은지도 같이 점검합니다.

결론

정답은 하나가 아닙니다. 정적이고 오래가는 페이지는 SSG, 공개 콘텐츠지만 계속 보강되는 페이지는 ISR, 사용자나 요청마다 달라지는 페이지는 SSR로 시작하면 대부분의 선택이 단순해집니다. Next.js 프로젝트가 커질수록 렌더링 방식은 페이지 단위로 섞는 것이 정상입니다. 중요한 것은 모든 페이지를 한 방식으로 밀어붙이지 않고, 캐시 가능성·최신성·빌드 시간·개인화 요구를 기준으로 나누는 것입니다.

💡 실전 인사이트

SSR, SSG, ISR 선택은 성능 용어 암기가 아니라 “사용자가 보는 정보가 언제 바뀌는가”로 결정하는 게 안전합니다. 가격, 재고, 로그인 상태처럼 요청마다 달라지는 값은 SSR이 맞고, 소개글·가이드·정책 페이지처럼 거의 변하지 않는 콘텐츠는 SSG가 유리합니다. 중간 지점에 있는 랭킹, 블로그 목록, 도구 설명 페이지는 ISR로 캐시를 살리면서 일정 주기로 갱신하는 쪽이 운영 부담이 적습니다.

실무에서는 처음부터 모든 페이지를 SSR로 만들면 LCP와 서버 비용이 같이 나빠지고, 반대로 전부 SSG로 밀면 오래된 정보가 검색에 남을 수 있습니다. 그래서 핵심 페이지는 “변경 빈도, 개인화 여부, 색인 중요도, 장애 시 대체 가능성” 네 가지 기준으로 나눠야 합니다. 이 기준을 배포 체크리스트에 넣어두면 새 기능을 추가할 때마다 렌더링 방식을 다시 싸우지 않아도 됩니다.

FAQ

SSR이 항상 SEO에 더 좋은가요?

아닙니다. SSG와 ISR도 완성된 HTML을 제공하므로 공개 콘텐츠 SEO에는 충분히 좋습니다. SSR은 최신성이나 개인화가 필요할 때 가치가 큽니다.

ISR의 revalidate 값은 어떻게 정하나요?

콘텐츠 변경 주기를 기준으로 잡습니다. 뉴스성 페이지는 짧게, 일반 가이드는 몇 시간 또는 하루 단위로 두는 식입니다.

블로그는 SSG와 ISR 중 무엇이 낫나요?

글 수가 적고 거의 수정하지 않으면 SSG가 단순합니다. 글이 많고 자주 보강한다면 ISR이 운영 부담을 줄입니다.

로그인 페이지도 ISR을 쓸 수 있나요?

로그인 사용자별 데이터가 HTML에 들어간다면 ISR은 맞지 않습니다. 공개 영역은 ISR, 개인화 영역은 SSR이나 클라이언트 fetch로 분리하세요.

빌드 시간이 너무 길면 어떻게 하나요?

모든 페이지를 빌드하지 말고 핵심 페이지만 사전 생성한 뒤 나머지는 ISR 또는 온디맨드 생성으로 옮깁니다.

App Router에서도 기준이 같은가요?

네. 구현 API는 달라졌지만 캐시 가능성, 최신성, 개인화라는 판단 기준은 그대로입니다.