Next.js 렌더링 전략과 서버 컴포넌트
Next.js의 렌더링을 이해할 때 먼저 구분해야 할 개념은 크게 두 가지.
- SSG / ISR / SSR / CSR
→ 페이지의 결과를 언제 생성하는지에 대한 렌더링 전략 - Server Component / Client Component
→ React 컴포넌트가 어느 환경에서 실행되는지에 대한 구분
두 개념은 서로 다른 기준이기 때문에 분리해서 이해할 필요가 있음.
웹 렌더링 전략
CSR — Client-Side Rendering
브라우저에서 JavaScript를 실행하여 화면을 렌더링하는 방식.
HTML / JavaScript 전달
→ JavaScript 실행
→ 데이터 요청
→ 브라우저에서 화면 구성
특징
- 주요 렌더링 주체는 클라이언트
- 페이지 로드 이후 필요한 데이터만 다시 받아 UI 갱신 가능
- 사용자 상호작용이 많은 화면에 적합
고려할 점
- JavaScript 다운로드와 실행으로 초기 렌더링이 늦어질 수 있음
- 초기 HTML에 콘텐츠가 충분하지 않은 경우 SEO 및 초기 성능 측면에서 불리할 수 있음
관리자 페이지, 로그인 이후 대시보드처럼 검색 노출보다 사용자 상호작용이 중요한 화면에서 활용하기 적합.
SSR — Server-Side Rendering
사용자의 요청이 들어온 시점에 서버에서 HTML을 생성하는 방식.
사용자 요청
→ 서버 데이터 조회
→ HTML 생성
→ 브라우저에 전달
특징
- 요청마다 서버에서 HTML 생성 가능
- 요청 시점의 최신 데이터 반영 가능
- 사용자별 콘텐츠 구성 가능
- 초기 HTML에 콘텐츠가 포함되어 SEO에 유리
고려할 점
요청마다 서버에서 데이터를 가져오고 HTML을 생성하기 때문에 SSG나 ISR과 비교하면 서버 연산 비용이 높음.
따라서 다음과 같은 경우에 적합.
- 사용자별 개인화 페이지
- 로그인 정보에 따라 달라지는 화면
- 요청 시점의 최신 데이터가 필요한 페이지
SSG — Static Site Generation
빌드 시점에 HTML을 미리 생성하는 방식.
Build
→ HTML 생성
→ 정적 파일 저장
사용자 요청
→ 생성된 HTML 반환
특징
- 요청 시 별도의 HTML 생성 과정이 거의 없음
- 빠른 초기 응답
- CDN 활용에 적합
- 초기 HTML에 콘텐츠가 포함되어 SEO에 유리
다만 콘텐츠가 변경되면 일반적으로 다시 빌드해야 하고, 페이지가 많아질수록 빌드 시간이 증가할 수 있음.
적합한 화면
- 블로그
- 문서
- 랜딩 페이지
- 변경 빈도가 낮은 콘텐츠
ISR — Incremental Static Regeneration
SSG의 정적 페이지를 유지하면서 필요한 페이지를 이후에 다시 생성할 수 있는 방식.
정적 HTML 제공
→ 재검증 조건 발생
→ 해당 페이지 재생성
→ 이후 요청부터 새로운 HTML 제공
SSG의 빠른 응답을 유지하면서 전체 사이트를 다시 빌드하지 않고 일부 콘텐츠를 갱신할 수 있다는 점이 특징.
적합한 화면
- 상품 상세
- 뉴스 / 콘텐츠
- 페이지 수가 많은 서비스
- 데이터는 변경되지만 요청마다 최신값까지 필요하지 않은 화면
SSG / ISR / SSR / CSR 비교
| 방식 | 생성 시점 | 데이터 최신성 | 적합한 경우 |
|---|---|---|---|
| SSG | 빌드 시 | 낮음 | 변경이 거의 없는 콘텐츠 |
| ISR | 빌드 + 재검증 | 중간 | 주기적으로 변경되는 콘텐츠 |
| SSR | 요청 시 | 높음 | 최신 데이터, 개인화 |
| CSR | 브라우저 | 높음 | 사용자 상호작용 중심 |
중요한 점은 서비스 전체에서 하나의 방식만 선택할 필요가 없다는 것.
예를 들어 하나의 서비스에서도 다음과 같이 구성 가능.
서비스 소개 페이지 → SSG
상품 상세 → ISR
개인화된 추천 → SSR
필터 / 버튼 → Client-side 처리
어떤 렌더링 전략을 선택해야 할까?
콘텐츠 변경 빈도
거의 변경되지 않음
→ SSG
주기적 / 특정 이벤트마다 변경
→ ISR
요청 시 최신 데이터 필요
→ SSR / CSR
가능하면 SSG와 ISR을 활용하고, 요청 시점의 최신 데이터가 반드시 필요한 경우 SSR을 고려하는 방향.
SEO가 중요한지
검색 엔진에 노출되어야 하는 콘텐츠라면 초기 HTML에서 콘텐츠와 메타데이터를 확인할 수 있는 방식이 유리.
SSG, ISR, SSR 모두 초기 HTML에 콘텐츠를 제공할 수 있기 때문에 SEO가 필요한 공개 페이지에서 활용하기 적합.
❓ SSG, ISR, SSR 중 어떤 방식이 SEO에 가장 좋을까?
렌더링 방식 자체만으로 순위를 나누기보다는 페이지 로딩 속도, 콘텐츠 최신성, 메타데이터, Core Web Vitals 등을 함께 고려할 필요가 있음.
상호작용이 많은지
페이지가 대부분 정적이라면 서버나 빌드 단계에서 콘텐츠를 만들고, 상호작용이 필요한 부분만 클라이언트에서 처리하는 방향이 적합.
개인화된 콘텐츠가 필요한지
사용자마다 결과가 달라진다면 요청 시점의 사용자 정보가 필요할 가능성이 높음.
모든 사용자에게 동일
→ SSG / ISR
사용자마다 다름
→ SSR / CSR
React Server Components
Server Component
- 서버에서 실행되는 React 컴포넌트
- 빌드 시점 또는 요청 시점에 실행 가능
- 서버의 데이터 레이어에 직접 접근 가능
- 브라우저로 전송되지 않음
- 서버에서만 필요한 코드와 라이브러리를 클라이언트 번들에서 제외 가능
Client Component
- 브라우저에서 상호작용이 필요한 컴포넌트
"use client"지시어 사용useState등의 상호작용 API 사용 가능- Server Component와 함께 구성 가능
Server Component + SSR
Server Component
→ 서버에서 컴포넌트 렌더링
SSR
→ 렌더링 결과를 초기 HTML로 생성
Server Component와 SSR은 동일한 개념이 아니며 함께 사용할 수 있습니다.