src>extensions>Framwork>nextjsrender.mdx

Next.js는 어떻게 렌더링할까?: CSR vs SSR vs SSG vs ISR

v1.0.0
@young_log|Framwork|Published on 2026-01-02

"모든 사이트를 똑같이 만들 순 없다"

@
Details
Changelog
Dependencies

웹 사이트의 성격에 따라 "속도"가 중요한지, "실시간성"이 중요한지 결정해야 한다.
그래서 어떤 서비스냐에 따라 유도리 있게 적용해야 한다.

Next.js가 사랑받는 이유가 바로 페이지별로 다른 렌더링 전략을 취할 수 있기 때문!


CSR (Client Side Rendering)

빈 HTML을 먼저 받고, 브라우저가 자바스크립트를 실행해 화면을 그린다.
즉, 브라우저에서 모두 처리된다!

서버가 하는 역할이 거의 없어 부담은 적지만, 첫 화면이 뜨기까지(FCP) 시간이 오래 걸리고, 검색 엔진 최적화(SEO)에 취약함 (서버에 거치는 부분이 없으니)

언제 쓸까?
관리자 페이지처럼 로그인이 필요하고 검색 노출이 필요 없는 곳


SSR (Server Side Rendering)

요청이 들어올 때마다 서버에서 HTML을 새로 구워서 던져준다.

항상 최신 데이터를 보여주고 SEO에 강하지만, 서버 부하가 있고 응답 시간이 좀 걸릴 수 있다?

언제 쓸까?
주식 차트, 최신 뉴스 피드처럼 데이터가 매초 변하는 곳
블로그도 특성상 검색 되어져야 하는 내용이 많으니 블로그 리스트, 상세페이지도 SSR로 렌더링해줘야 한다.

그런데 SSR이 SEO에 좋다 좋다 하는 건 알겠는데 어떻게 검색되게 하는걸까??

SEO의 핵심은 구글봇(Crawler)

구글이나 네이버도 마찬가지겠지만 이와 같은 검색엔진은 구글 봇 이라는 로봇을 전 세계 사이트에 보낸다.
이 로봇의 역할은 이 사이트가 무슨 내용인지 읽어보고 보고 하는 것!

그렇다면 왜 서버를 거쳐야 한다는 것일까??

CSR인 경우? 로봇은 비어 있는 것으로 받아 들인다.

  1. 구글 봇이 index.html을 딱 열어본다.
  2. 내용이 없네? <div id="root"></div> 하나랑 자바스크립트 파일 링크만 덜렁 있네?
  3. 인내심이 없는 구글 봇은 너무 바쁜 나머지 자바스크립트가 실행될때까지 기다려주지 않고
    돌아가 버린다(최근에는 조금 유해졌는지 기다려 주기도 한다는데 불안정함)
  4. 결과적으로 아무것도 없는 빈 페이지로 인식하고 검색 결과 뒷 페이지로 넘겨 버린다.

SSR인 경우에는 미리 조립된 페이지를 받는다! →Next.js가 미리 화면을 다 그려 준다면?

  1. 구글 봇은 사이트에 오자마자 완성된 HTML을 받는다.
  2. 열어보니 제목(<h1>), 본문(<p>), 키워드들이 이미 다 글자로 적혀 있다.
  3. 구글봇: "오! 이 사이트는 프론트엔드 관련된 블로그구나!" 하고 점수를 팍팍 줌.
    (점수? 구글 내부에는 랭킹 알고리즘이라는 아주 복잡한 채점 시스템이 있다고 한다 - 이것도… 따로 알아볼 수 있다면 알아보겠다.)
  4. 결과 상단에 노출될 확률이 엄청나게 올라간다.

검색 엔진은 이미지나 화려한 애니메이션은 보지 못한다.
Only HTML 소스 코드 안에 박혀 있는 텍스트만 읽을 수 있음

  • 서버를 거친다?
    브라우저가 아니라 미리 자바스크립트를 돌려서 텍스트가 가득 찬 HTML를 만들어 놓는다.
  • SEO 성공?
    검색 로봇이 그 텍스트를 읽고 정보가 있는 사이트로 인식한다.

SSG (Static Site Generation)

빌드 타임에 HTML을 미리 다 만들어둠. 사용자는 만들어진 파일을 받기만 하면 끝.
압도적으로 빠름. 하지만 데이터가 바뀌면 다시 빌드해야 함.
완전한 런타임 SSR이 부담스러우면 요게 좋음.

언제 쓸까?
블로그, 공식 문서, 소개 페이지.


ISR (Incremental Static Regeneration)

개념: SSG처럼 빠르지만, 일정 시간이 지나면 백그라운드에서 HTML을 새로 갱신함.
속도와 최신 데이터를 모두 잡은 Next.js의 필살기

언제 쓸까?
쇼핑몰 상품 리스트, 좋아요 수가 변하는 게시글.


모든 웹사이트를 모두 똑같이 만들 수 없다!

그럼 우리의 프로젝트는 어떤걸 적용해야 할지 고민이라면?

  • SEO가 중요한가? * NO → CSR
    • YES → 데이터가 자주 바뀌는가?
      • NO → SSG
      • YES → 사용자마다 내용이 다른가?
        • YES → SSR
        • NO → ISR

개발 중인 로컬은 왜 배포된 사이트보다 많이 느릴까?

이유는 Next.js의 '개발 모드'와 '프로덕션 모드'의 일하는 방식 차이 때문이다.

  • 로컬의 개발 모드(dev)

    로컬에서 npm run build 를 하면, Next.js는 내가 언제든 코드를 고칠 수 있는 “대기 상태”

    • JIT(Just-In-Time) 컴파일: 모든 페이지를 미리 만들어두지 않고, 내가 주소창에 치는 순간 그때 자바스크립트와 스타일이 컴파일되고 조립된다.
    • HMR(Hot-Module Replacement): 코드를 수정하면, 바로 반영하기 위해 브라우저와 서버가 계속 엄청난 양의 데이터를 주고 받는다.
    • 디버깅 코드: 에러가 나면 어디가 틀렸는지 자세히 알려주기 위해 무거운 디버깅 정보들을 코드에 잔뜩 포함하고 있음.
  • 배포 환경(Production)

    이 사이트처럼 Vercel 같은 곳에 배포하면, 빌드 과정을 거치며 코드가 바뀌지 않을 것이라고 가정

    • 사전 빌드(Pre-rendering): SSG 방식으로 이미 HTML 완성
    • 코드 최적화(Minify & Uglyfy): 자바스크립트 파일에서 공백을 다 없애고 변수명을 a, b 처럼 아주 짧게 줄여서 파일 크기를 최소한으로 한다.
    • 트리쉐이킹(Tree Shaking): 수많은 라이브러리 중 내가 진짜 쓴 코드만 남기로 다 버린다.
  • 서버 위치의 차이 (CDN)

    로컬은 내 컴퓨터가 서버지만, 배포하면 Vercel의 Edge Network(CDN)를 사용
    전 세계 곳곳에 나의 블로그의 복사본이 저장되어 있어서, 사용자와 가장 가까운 서버에서 데이터를 쏴준다.

Comments_Log
TERMINAL
DEBUG CONSOLE
OUTPUT
~/stay-young-loggit(main)npm run comment:write
nickname:
content:
-- TOTAL COMMENTS: 0 --
[LOADING...] fetching data from supabase...