웹 애플리케이션을 개발할 때 가장 중요한 선택 중 하나는 렌더링 방식이다.
각 방식은 고유한 장단점을 가지고 있으며, Next.js를 통해 이러한 방식들을 유연하게 활용할 수 있다.
렌더링 방식
CSR (Client Side Rendering)
클라이언트 사이드 렌더링은 웹 페이지의 렌더링을 사용자의 브라우저가 담당하는 방식이다.
사용자가 웹 페이지를 요청하면 서버는 가장 기본적인 HTML 구조인 텅 빈 index.html을 먼저 전달하고, 이후 필요한 자바스크립트 파일과 리액트 컴포넌트 등을 클라이언트로 전송한다.
동작 과정
- 사용자가 웹 페이지에 접속하면 서버는 초기 구조만 있는
index.html을 전송 - 브라우저는 이 HTML 파일을 받은 후, 리액트 라이브러리와 컴포넌트들을 서버로부터 다운로드
- 리액트가 로드되고 실행되면서 HTML 내의
div요소(div root)에 자바스크립트를 연결하고 컴포넌트를 실제 DOM 요소로 변환 후 화면에 렌더링

장점
- 페이지 전체를 새로 불러오지 않고 필요한 부분만 업데이트하여 빠른 사용자 경험 제공
- 모든 처리가 클라이언트 측에서 이루어지므로 서버 부담 감소
문제점
- 모든 자바스크립트 파일과 리소스가 로드되고 실행될 때까지 사용자는 빈 화면을 보게 됨
- TTV와 FCP가 길어 로딩시간 지연
- 자바스크립트 비활성화 시 웹 페이지가 전혀 표시되지 않을 수 있음
- 검색 엔진 최적화(SEO)에 적합하지 않아 초기 콘텐츠 인덱싱에 어려움
- 클라이언트 측에서 모든 코드를 처리하기 때문에 보안상 취약점 발생 가능
- 동적으로 생성되는 콘텐츠의 특성상 CDN 캐시가 어려움
TTV (Time To View)
- 사용자가 웹 브라우저에서 내용을 볼 수 있는 시점
FCP (First Contentful Paint)
- 페이지가 로드를 시작한 시점부터 의미 있는 콘텐츠가 처음 렌더링되는 시점까지의 시간을 측정하는 지표
CDN (Content Delivery Network)
- 지리적인 제약 없이 전 세계 사용자에게 빠르고 안전하게 콘텐츠 전송을 할 수 있는 기술
위와 같은 문제를 해결하기 위한 대안으로 SSR과 SSG를 고려할 수 있다.
SSG (Static Side Generation)
정적 사이트 생성은 서버에서 웹 페이지를 렌더링하는 방식이지만, 이 렌더링은 사전에 빌드 타임에 실행된다.
즉, 웹 페이지의 모든 HTML 파일은 서버에서 미리 생성되고 사용자의 요청에 따라 이 파일들이 제공된다.
동작 과정
- 빌드 시점에 개발자가 작성한 리액트 코드가 HTML로 변환
- 필요한 데이터는 데이터베이스 혹은 클라우드에서 미리 읽어와서 페이지를 구성
- 빌드가 완료되면, 생성된 HTML 파일들이 서버에 저장
- 사용자가 웹 사이트에 접속할 때, 서버는 미리 생성된 정적 파일을 바로 전송
장점
- 미리 생성된 페이지들이기 때문에 TTV가 빠름
- 모든 페이지가 HTML로 미리 렌더링되기 때문에 자바스크립트 비활성 상태에서도 문제없이 작동
- 검색 엔진은 정적 HTML을 쉽게 인덱싱할 수 있기 때문에 SEO에 유리
- 동적 스크립트가 적으므로 XSS 같은 보안 위험을 줄일 수 있음
- 정적 파일은 CDN에 캐시되어 전 세계 어디서든 빠르게 제공 가능
XSS (Cross Site Scripting)
관리자가 아닌 사람이 악성 스크립트 코드를 삽입해 치명적인 오류를 발생시키거나 쿠키 등을 탈취하는 공격
문제점
- 사이트가 빌드 시 생성되기 때문에 실시간 데이터 변경이 어려움
- 모든 사용자에게 동일한 정적 파일을 제공하기 때문에 사용자 개인화 기능 구현이 제한적
위와 같은 문제를 해결하기 위한 대안으로 ISR과 SSR을 고려할 수 있다.
ISR (Incremental Static Regeneration)
증분적 정적 재생성은 SSG의 확장 개념으로, 정적 사이트를 생성하면서도 정해진 주기에 따라 특정 페이지를 다시 생성할 수 있는 방식이다.
이를 통해 변경될 수 있는 데이터를 반영하면서도 정적 사이트의 이점을 유지할 수 있다.
동작 과정
- 사이트가 빌드되는 시점에 정적 페이지가 생성
- 페이지가 요청될 때마다 새로운 데이터로 페이지를 재생성할 필요가 있는지 검사
- 설정된 주기에 따라 페이지를 재생성하고, 이 과정에서 최신 데이터를 반영
- 새롭게 생성된 페이지는 이후 요청에 사용되어 데이터의 신선도를 유지
장점
SSG의 장점과 더불어 주기적인 업데이트를 통해 데이터의 신선도를 보장한다는 장점이 있다.
문제점
주기적으로 페이지를 업데이트하지만, 실시간으로 변경 사항을 반영하지는 않기 때문에 SSG가 가지고 있던 문제점을 완전히 해결하지는 못한다.
이러한 문제점들을 해결하기 위해 SSR을 사용할 수 있다.
SSR (Server Side Rendering)
서버 사이드 렌더링은 웹 페이지를 렌더링하는 주체가 서버인 방식이다.
클라이언트의 요청에 따라 서버에서 페이지를 즉시 렌더링하고 HTML 파일을 클라이언트에게 전송한다.
동작 과정
- 클라이언트가 웹 페이지에 접속 요청
- 서버는 필요한 코드를 실행하고, 필요한 경우 데이터베이스나 클라우드 데이터베이스에서 데이터를 가져옴
- 이 데이터를 바탕으로 HTML 파일을 생성
- 생성된 HTML 파일을 클라이언트에게 전송
장점
SSG와 ISR의 장점과 더불어 요청 시마다 새로운 데이터를 반영하기 때문에
- 실시간 데이터 처리로 동적인 웹 페이지 제공 가능
- 각 사용자의 요구에 맞춘 개인화된 콘텐츠 제공 가능
- 매우 유연한 웹 애플리케이션 구현 가능
하다는 장점이 있다.
문제점
- SSG, ISR에 비해 페이지 로딩이 비교적 느릴 수 있음
- 모든 요청이 서버에서 렌더링되기 때문에 서버의 과부하 발생 가능
- 트래픽이 많은 경우 서버의 overhead 증가
- 동적으로 생성되는 페이지는 CDN에 캐싱하기 어려워 콘텐츠 전달 속도가 느려질 수 있음
렌더링 방식 비교
| 특성 | CSR | SSG | ISR | SSR |
| 렌더링 주체 | 클라이언트 | 빌드 시점 | 빌드 + 주기적 | 서버 |
| TTV | 느림 | 빠름 | 빠름 | 중간 |
| SEO | 불리 | 유리 | 유리 | 유리 |
| 실시간 데이터 | 가능 | 불가능 | 제한적 | 가능 |
| 개인화 | 가능 | 불가능 | 불가능 | 가능 |
| 서버 부하 | 적음 | 적음 | 적음 | 많음 |
| CDN 캐시 | 어려움 | 쉬움 | 쉬움 | 어려움 |
Next.js
완벽한 렌더링 방식은 존재하지 않지만, Next.js를 사용하면 각 렌더링 방식의 단점을 극복할 수 있다.
Next.js는 SSR의 장점을 살리면서 페이지 로딩 시간을 최적화하고, 필요에 따라 정적 생성(SSG)과 서버 사이드 렌더링(SSR)을 혼합하여 사용할 수 있는 기능을 제공한다.
Next.js의 장점
- 서버 부하 감소
- CDN 캐싱 최적화
- 동적인 기능과 정적인 이점을 동시에 활용 가능
Hydration
하이드레이션은 SSR에서 생성된 정적 HTML 페이지가 클라이언트 측에서 동적인 기능으로 활성화되는 과정을 말한다.
Next.js는 이 과정을 자동으로 처리하여 웹 애플리케이션의 초기 로드 시간을 단축시키고, 사용자 경험을 개선한다.
동작 과정
- 클라이언트가 서버에 웹 페이지를 요청
- Next.js는 서버에서 HTML, CSS 등을 결합하여 정적인 HTML 페이지를 생성
- 사용자가 빠르게 콘텐츠를 볼 수 있도록 함 (Pre-rendering)
- 프리렌더링된 페이지는 사용자에게 전송되고, 사용자는 정적 콘텐츠를 즉시 볼 수 있음
- 이 시점에서의 페이지는 동적 기능을 수행할 수 없음
- 사용자의 브라우저는 배경에서 리액트와 필요한 자바스크립트 코드를 다운로드
- 다운로드된 자바스크립트가 실행되면서 정적 페이지에 동적 기능을 부여
- 클라이언트 사이드에서 리액트 컴포넌트가 실제로 렌더링
- 페이지가 완전히 인터랙티브하게 됨
하이드레이션의 이점:
- 빠른 로딩
- 필요한 시점의 동적 활성화
- 효율적이고 매력적인 사용자 경험
렌더링 방식 선택 가이드
프로젝트에 적합한 렌더링 방식을 선택하는 플로우차트
1. 사용자의 로그인이 필요한가?
├─ Yes → CSR, SSR, Hybrid (SSG + CSR)
└─ No → 2번으로
2. 데이터가 변경되는가?
├─ Yes → 3번으로
└─ No → SSG
3. 자주 변경되는가?
├─ Yes → SSR (과부하 염려 시 Hybrid: SSG + CSR)
└─ No → ISR
사용 사례별 권장 방식
SSG 추천:
- 블로그, 마케팅 페이지
- 문서 사이트, 포트폴리오
- 정적 콘텐츠 중심 사이트
ISR 추천:
- 뉴스 사이트, 제품 목록
- 자주는 아니지만 주기적으로 업데이트되는 콘텐츠
SSR 추천:
- 소셜 미디어 피드
- 실시간 대시보드
- 개인화된 콘텐츠
CSR 추천:
- 복잡한 인터랙션이 많은 애플리케이션
- SEO가 중요하지 않은 관리자 페이지
Hybrid (SSG + CSR) 추천:
- 전자상거래 사이트
- 로그인 기능이 있는 블로그
- 정적 콘텐츠 + 동적 기능 혼합
각 렌더링 방식은 특정 상황에 최적화되어 있으며, Next.js를 통해 이러한 방식들을 유연하게 조합하여 사용할 수 있다.
프로젝트의 요구사항, 트래픽 패턴, 데이터 업데이트 빈도를 고려하여 적절한 렌더링 전략을 선택하는 것이 중요하다.
'Frontend' 카테고리의 다른 글
| Zustand로 전역 상태 관리하기 (0) | 2025.11.18 |
|---|---|
| aria-label과 텍스트 콘텐츠 (0) | 2025.11.13 |
| 타입스크립트 유틸리티 타입 (0) | 2025.11.05 |
| 타입스크립트 타입 시스템: 계층과 호환성 (0) | 2025.10.31 |
| 타입스크립트의 동작 원리 (0) | 2025.10.27 |
