STUDY NOTE · 개념 정리
SSR vs CSR 개념 정리 (+ SSG, ISR, 하이드레이션)
Next/Express
CSR과 SSR의 차이는 HTML을 누가, 언제 만드느냐다. CSR은 브라우저가 JS로 만들고, SSR은 서버가 요청마다 만들어서 보낸다. 이 차이가 첫 화면 속도, SEO, 서버 부하를 가른다.
1. 렌더링이란
여기서 렌더링은 데이터와 컴포넌트를 합쳐 화면에 보일 HTML을 만드는 일이다. 이 일을 어디서 하느냐에 따라 렌더링 방식이 나뉜다.
2. CSR (Client-Side Rendering)
- 서버가 거의 빈 HTML(
<div id="root"></div>)과 JS 번들 주소를 응답 - 브라우저가 JS 다운로드 및 실행
- JS가 API를 호출해 데이터 수신
- JS가 DOM을 만들어 화면 표시
React, Vue로 만든 SPA(Single Page Application)의 기본 방식이다. 페이지 이동도 서버에 새 HTML을 요청하지 않고 JS가 화면을 바꾼다.
3. SSR (Server-Side Rendering)
- 요청이 오면 서버가 데이터를 조회하고 컴포넌트를 렌더링
- 완성된 HTML을 응답 → 브라우저가 바로 화면 표시
- JS 번들 다운로드
- 하이드레이션(Hydration): 이미 있는 HTML에 이벤트 핸들러를 연결해 상호작용 가능하게 만듦
SSR에서는 "화면이 보이는 시점"과 "버튼이 동작하는 시점"이 다르다.
4. 한눈에 비교
| 구분 | CSR | SSR |
| HTML 생성 위치 | 브라우저 | 서버 |
| 초기 응답 HTML | 거의 비어 있음 | 내용이 채워져 있음 |
| 첫 화면 표시 (FCP) | 느림 (JS 실행·API 응답까지 대기) | 빠름 |
| 첫 바이트 (TTFB) | 빠름 (정적 파일) | 느릴 수 있음 (서버가 렌더링하는 시간) |
| 페이지 전환 | 빠름 (JS로 화면 교체) | 전체 이동이면 매번 요청 |
| SEO, 링크 미리보기 | 불리 | 유리 |
| 서버 부하 | 낮음 (CDN으로 정적 파일 제공) | 높음 (요청마다 렌더링) |
| 개발 시 주의점 | 번들 크기, 로딩 상태 처리 | window 등 브라우저 API 사용 제약, 하이드레이션 불일치 |
| 적합한 화면 | 관리자, 대시보드, 로그인 후 화면 | 상품 상세, 블로그, 랜딩 등 공개 페이지 |
5. 왜 SSR이 필요한가
- SEO: 검색엔진은 HTML의 내용으로 페이지를 이해한다. 구글은 JS를 실행해 색인하지만 별도 렌더링 대기열을 거쳐 늦어질 수 있고, 다른 검색엔진이나 카카오톡·슬랙의 링크 미리보기 봇은 대부분 JS를 실행하지 않는다.
- 첫 화면 속도: 사용자는 JS가 다 받아지고 실행될 때까지 기다리지 않고 내용부터 본다. 느린 기기·네트워크에서 차이가 크다.
- 공유 메타 태그: 페이지마다 다른
og:title,og:image가 HTML에 들어 있어야 미리보기가 정확하다.
6. 하이드레이션 (Hydration)
서버가 만든 HTML(정적인 "건조한" 화면)에 JS가 이벤트와 상태를 입혀 살아 움직이게 만드는 과정이다. React는 하이드레이션 때 클라이언트에서 다시 렌더한 결과가 서버 HTML과 같다고 가정한다. 다르면 하이드레이션 불일치(mismatch) 오류가 난다.
| 불일치 원인 | 이유 |
| new Date(), 현재 시각 | 서버와 브라우저의 시각·시간대가 다름 |
| Math.random() | 실행할 때마다 값이 다름 |
| window, localStorage | 서버에는 존재하지 않음 |
| 브라우저 확장 프로그램 | 하이드레이션 전에 DOM을 수정함 |
해결 원칙은 "첫 렌더는 서버와 똑같이, 브라우저 전용 값은 마운트 후(useEffect)에 반영"이다.
7. SSG와 ISR
| 구분 | SSG | ISR | SSR | CSR |
| HTML 생성 시점 | 빌드할 때 | 빌드 후 주기적으로 재생성 | 요청할 때마다 | 브라우저에서 |
| 데이터 최신성 | 재배포 전까지 고정 | 설정한 주기만큼 늦음 | 항상 최신 | 항상 최신 |
| 속도 | 가장 빠름 (CDN) | 빠름 | 보통 | 첫 화면 느림 |
| 서버 필요 | 불필요 | 필요 | 필요 | 불필요 |
| 예시 | 블로그 글, 문서 | 상품 목록, 뉴스 | 개인화된 페이지, 실시간 재고 | 관리자 화면 |
판단 기준은 "이 HTML을 언제 미리 만들 수 있는가"다. 빌드 때 알 수 있으면 SSG, 요청이 와야 알 수 있으면 SSR, 사용자의 브라우저에서만 알 수 있으면 CSR이다.
8. Next.js App Router의 방식: Server Component
App Router에서는 컴포넌트 단위로 렌더링 위치를 나눈다.
| 구분 | Server Component (기본) | Client Component ("use client") |
| 실행 위치 | 서버에서만 | 서버(초기 HTML) + 브라우저 |
| JS 번들 포함 | 안 됨 | 됨 |
| 가능한 일 | DB·API 직접 조회, 비밀 키 사용 | useState, useEffect, 이벤트 처리 |
| 불가능한 일 | 상태, 이벤트, 브라우저 API | 서버 전용 코드 직접 실행 |
데이터 조회와 정적인 부분은 서버 컴포넌트로 두고, 버튼·입력처럼 상호작용이 필요한 부분만 클라이언트 컴포넌트로 만들면 번들이 줄고 하이드레이션 비용도 준다.
9. 실제로 어떻게 적용되나
- 쇼핑몰 상품 상세: 검색 노출과 공유 미리보기가 중요하므로 SSR 또는 ISR. 가격·재고처럼 자주 바뀌는 값만 클라이언트에서 다시 조회하기도 한다.
- 블로그·기술 문서: 내용이 자주 바뀌지 않으므로 SSG. 서버 없이 CDN만으로 가장 빠르게 제공된다. 이 사이트의 개인 공부 글도 빌드 시점에 정적 생성한다.
- 관리자 페이지: 검색 노출이 필요 없고 상호작용이 많으므로 CSR로 충분하다.
- 같은 앱 안에서 혼합: Next.js는 페이지마다(또는 컴포넌트마다) 방식을 다르게 고를 수 있다.
10. 면접 질문으로 정리
- Q. CSR과 SSR의 차이는? CSR은 빈 HTML을 받은 뒤 브라우저가 JS로 화면을 만들고, SSR은 서버가 데이터를 채운 HTML을 만들어 보낸다. SSR은 첫 화면과 SEO에 유리하지만 서버 부하가 크고, CSR은 초기 로딩이 느리지만 이후 화면 전환이 빠르고 서버 부담이 적다.
- Q. 하이드레이션이란? 서버에서 렌더링된 HTML에 클라이언트 JS가 이벤트 핸들러와 상태를 연결해 상호작용 가능하게 만드는 과정이다.
- Q. 하이드레이션 불일치는 왜 생기나? 서버와 클라이언트의 첫 렌더 결과가 다를 때 생긴다. 현재 시각, 랜덤 값, window·localStorage 같은 브라우저 전용 값이 원인이며, 이런 값은 마운트 후에 반영한다.
- Q. SSG와 SSR은 언제 각각 쓰나? 요청마다 내용이 달라지지 않으면 빌드 시 생성하는 SSG가 빠르고 저렴하다. 사용자별·요청 시점별로 달라야 하면 SSR을 쓴다.