프론트엔드 개발을 하다 보면 한 번쯤 이런 말을 듣게 됩니다.

  • “CSR은 느리고 SSR은 빠르다”
  • “SEO 때문에 SSR을 써야 한다”
  • “Next.js는 SSR 프레임워크다”
  • “use client를 붙이면 클라이언트 컴포넌트다”

하지만 이런 말들은 절반은 맞고 절반은 틀린 이야기입니다.

렌더링 방식은 단순히 “빠르다 / 느리다”로 나눌 수 있는 문제가 아니기 때문입니다.

이번 글에서는 CSR과 SSR을 단순 개념 비교에서 끝내지 않고 다음 흐름까지 연결해서 이해해보겠습니다.

  • 브라우저가 화면을 보여주는 과정
  • 하이드레이션(Hydration) 비용
  • SEO와 검색 엔진 크롤러 관점
  • React Server Components

렌더링(Rendering)이란 무엇인가

렌더링(Rendering)은 사용자가 볼 수 있는 HTML UI를 만들어 브라우저에 보여주는 과정을 의미합니다.

여기서 중요한 질문은 다음과 같습니다.

누가, 언제, 어디서 UI를 만드는가

렌더링 방식의 차이는 바로 이 지점에서 발생합니다.

  • CSR(Client-Side Rendering)
    브라우저에서 자바스크립트를 실행하여 화면을 만듭니다.
  • SSR(Server-Side Rendering)
    서버가 먼저 HTML을 생성하여 브라우저에 전달합니다.

즉 핵심 차이는 다음과 같습니다.

초기 화면 생성의 책임이 서버에 있는가, 클라이언트에 있는가

 

다만 실제 서비스에서는 CSR과 SSR이 완전히 분리되어 동작하지 않습니다.
특히 Next.js 환경에서는 서버 렌더링 이후 클라이언트 하이드레이션이 이어지는 구조로 동작합니다.

CSR(Client-Side Rendering)의 동작 원리

CSR에서는 브라우저가 처음 받는 HTML이 매우 단순한 껍데기 형태인 경우가 많습니다.

예를 들어 다음과 같은 구조입니다.

<div id="root"></div>
 

실제 화면은 이후 자바스크립트가 실행되면서 만들어집니다.

CSR의 동작 흐름을 단순화하면 다음과 같습니다.

  1. 브라우저가 HTML을 요청합니다.
  2. 서버는 최소한의 HTML과 JS 번들 경로를 반환합니다.
  3. 브라우저는 JS 번들을 다운로드합니다.
  4. JS를 파싱하고 실행합니다.
  5. React가 컴포넌트를 렌더링합니다.
  6. API를 호출하여 데이터를 받아 화면을 완성합니다.

이 방식의 장점은 다음과 같습니다.

  • 풍부한 인터랙션 구현이 쉽습니다
  • 클라이언트 라우팅이 자연스럽습니다
  • SPA(Single Page Application) 구조에 적합합니다

하지만 단점도 존재합니다.

초기 로딩 시점에는 다음 작업이 모두 끝나야 합니다.

  • JS 다운로드
  • JS 파싱
  • JS 실행
  • 데이터 요청

이 때문에 초기 화면 표시가 늦어질 수 있습니다.

CSR의 한계가 자주 이야기되는 이유

CSR의 가장 큰 특징은 초기 렌더링이 자바스크립트에 강하게 의존한다는 점입니다.

다음과 같은 상황에서는 CSR이 불리해질 수 있습니다.

  • JS 번들 크기가 큰 경우
  • 저사양 기기에서 JS 실행 비용이 큰 경우
  • 네트워크 환경이 느린 경우
  • 초기 데이터 요청이 여러 번 발생하는 경우

즉 CSR이 느린 이유는 단순히

“클라이언트에서 렌더링하기 때문”

 

이 아니라

초기 화면 표시를 위해 브라우저가 해야 할 일이 너무 많기 때문입니다.

SSR(Server-Side Rendering)의 동작 원리

SSR은 사용자가 페이지를 요청했을 때 서버가 먼저 HTML을 생성하여 브라우저에 전달하는 방식입니다.

브라우저는 HTML을 받자마자 초기 화면을 빠르게 표시할 수 있습니다.

 

SSR의 동작 흐름은 다음과 같습니다.

  1. 브라우저가 페이지를 요청합니다.
  2. 서버가 필요한 데이터와 컴포넌트를 기반으로 HTML을 생성합니다.
  3. 브라우저는 HTML을 받아 화면을 먼저 표시합니다.
  4. 이후 JS가 다운로드됩니다.
  5. React가 하이드레이션을 수행합니다.

즉 SSR의 핵심은 다음과 같습니다.

콘텐츠는 먼저 보여주고, 상호작용은 나중에 활성화합니다.

SSR이 정말 CSR보다 빠를까요?

많은 분들이 SSR이 CSR 보다 빠르다고 생각하시지만,

"상황에 따라 다르다" 라고 말할 수 있습니다.

 

SSR은 다음 상황에서 유리합니다.

  • 블로그
  • 상품 상세 페이지
  • 문서 페이지
  • 랜딩 페이지

즉 읽을 콘텐츠가 중요한 페이지에서 유리합니다.

하지만 SSR에도 비용이 존재합니다.

예를 들어 다음 요소들이 있습니다.

  • 서버 렌더링 시간
  • 데이터 조회 시간
  • 네트워크 왕복 시간
  • 서버 인프라 지연

서버 응답이 느리면 오히려 CSR보다 느려질 수도 있습니다.

따라서 중요한 것은

어떤 성능 지표를 기준으로 판단하는가입니다.

FCP(First Contentful Paint)

FCP는 사용자가 처음으로 콘텐츠를 화면에서 볼 수 있는 시점을 의미합니다.

즉 다음과 같은 요소가 처음 나타나는 순간입니다.

  • 텍스트
  • 이미지
  • SVG
  • Canvas

이 지표가 중요한 이유는 사용자가 서비스가 응답하고 있다고 느끼는 최초 시점이기 때문입니다.

예를 들어

  • 오랫동안 하얀 화면만 보이면 사용자는 불안합니다.
  • 제목이나 스켈레톤 UI라도 빨리 보이면 서비스가 작동한다고 느낍니다.

이런 관점에서 SSR은 초기 HTML을 제공하므로 FCP 개선에 유리할 수 있습니다.

TTI(Time To Interactive)

TTI(Time To Interactive)는 페이지가 완전히 상호작용 가능해지는 시점을 의미합니다.

즉 사용자가 다음 행동을 해도 정상적으로 반응하는 상태입니다.

  • 버튼 클릭
  • 입력
  • 스크롤
  • 메뉴 열기

페이지가 인터랙티브 상태가 되려면 다음 조건이 충족되어야 합니다.

  • 주요 JS 실행 완료
  • 이벤트 핸들러 등록 완료
  • 메인 스레드가 장시간 블로킹되지 않음

예를 들어 SSR 페이지는 다음 상황이 발생할 수 있습니다.

  • HTML은 이미 화면에 보입니다.
  • 하지만 JS가 아직 실행되지 않았습니다.
  • 버튼을 눌러도 아무 반응이 없습니다.

이 경우 FCP는 빠르지만, TTI는 느릴 수 있습니다.

 

즉 성능을 평가할 때는 단순히 화면이 언제 보이는지(FCP) 뿐 아니라 언제 상호작용이 가능한지(TTI) 도 함께 고려해야 합니다.

블로킹 패턴 이해하기

초기 렌더링이 느려지는 이유를 이해하려면 무엇이 화면 표시를 막고 있는지를 봐야 합니다.

이를 크리티컬 렌더링 패스(Critical Rendering Path) 관점에서 이해할 수 있습니다.

대표적인 블로킹 요소는 다음과 같습니다.

  • 큰 JavaScript 번들 다운로드
  • JS 파싱 및 실행
  • 데이터 요청 대기
  • CSS 로딩 지연
  • 서버 응답 지연

CSR에서는 JavaScript 실행이 주요 병목이 되고
SSR에서는 서버 응답 시간이 병목이 될 수 있습니다.

네트워크 병목과 서버 오버헤드

SSR이 항상 빠르지 않은 이유는 서버가 처리해야 할 작업이 많기 때문입니다.

대표적인 요소는 다음과 같습니다.

  • 네트워크 지연
  • TLS 연결
  • CDN 캐시 미스
  • 백엔드 API 지연
  • 데이터베이스 연결

또 하나 중요한 요소는 Cold Start입니다.

서버리스 환경에서는 오랫동안 사용되지 않았던 런타임이 처음 실행될 때 초기화 비용이 발생할 수 있습니다.

이 때문에 SSR 성능을 논할 때는 단순히 프론트엔드 코드가 아니라 인프라 구조 전체를 함께 고려해야 합니다.

하이드레이션(Hydration)이란 무엇인가

SSR에서 서버가 HTML을 미리 생성하더라도 그 HTML은 처음에는 정적인 결과물입니다.

사용자가 버튼을 클릭하거나 입력을 하기 위해서는 React가 HTML과 컴포넌트 트리를 연결해야 합니다.

이 과정을 Hydration이라고 합니다.

 

Next.js 환경에서는 다음 순서로 진행됩니다.

  1. HTML을 먼저 보여줍니다
  2. React Server Components Payload를 전달받습니다
  3. 클라이언트 JS를 실행합니다
  4. React가 이벤트를 연결합니다

즉 SSR은 끝이 아니라 시작입니다.

서버가 먼저 보여주고, 클라이언트가 나중에 UI를 살아 움직이게 만듭니다.

하이드레이션 비용이 중요한 이유

SSR을 사용한다고 해서 성능이 항상 좋아지는 것은 아닙니다.

왜냐하면 하이드레이션 비용이 존재하기 때문입니다.

 

다음 상황에서는 하이드레이션 비용이 증가할 수 있습니다.

  • 클라이언트 컴포넌트가 너무 많은 경우
  • 초기 화면에 인터랙션이 집중된 경우
  • JS 번들이 큰 경우
  • 서버와 클라이언트 렌더 결과가 다른 경우

특히 서버 HTML과 클라이언트 결과가 다르면 Hydration mismatch가 발생할 수 있습니다.

Hydration mismatch가 발생하면 Next.js 에서 자체적으로 에러를 띄우기 때문에, 반드시 해결해야할 문제입니다.

Hydration 실패로 에러가 난 모습

 

왜 SSR이 SEO에 유리할까요?

SEO(검색 엔진 최적화, Search Engine Optimization)란 구글, 네이버 등 검색 엔진의 알고리즘을 이해하여

웹사이트나 콘텐츠를 검색 결과 상위에 노출시키는 디지털 마케팅 기술입니다.

 

고품질 콘텐츠 생성, 키워드 배치, 기술적 구조 최적화를 통해 유기적 트래픽(방문자)을 증대시키는 것이 주 목적입니다.

 

SSR이 SEO에 유리하다고 말하는 이유는 검색 엔진이 HTML을 더 쉽게 이해할 수 있기 때문입니다.

CSR 페이지도 Google은 JavaScript를 실행하여 렌더링할 수 있습니다.

 

하지만 다음과 같은 차이가 있습니다.

 

CSR 페이지는 다음 단계를 거칩니다.

Crawling → Rendering → Indexing
 

즉 Redering 단계에서 JavaScript의 실행이 필요합니다.

 

반면 SSR 페이지는 초기 HTML에 콘텐츠가 이미 존재하기 때문에, 검색 엔진이 콘텐츠를 더 안정적으로 이해할 수 있습니다.

또한 구글의 검색 엔진의 경우, SSR 페이지에게 가산점을 준다고 하니, SSR이 SEO에 충분히 유리하다고 볼 수 있을 것 같습니다.

크롤러는 어떻게 동작할까요?

Google Search Central 기준으로 크롤링 과정은 다음과 같습니다.

  1. URL Crawling
  2. Rendering
  3. Indexing

Googlebot은 JavaScript를 실행할 수 있지만
항상 즉시 실행된다고 가정하면 안 됩니다.

따라서 검색에 중요한 콘텐츠는 초기 HTML에 포함되는 것이 안정적입니다.

React Server Components

React Server Components는 서버에서 실행되는 React 컴포넌트입니다.

장점은 다음과 같습니다.

  • 서버에서 데이터 접근 가능
  • 클라이언트 JS 감소
  • 하이드레이션 비용 감소

즉

브라우저는 인터랙션에 집중하고
서버는 데이터와 렌더링을 담당합니다.

"use client"가 필요한 이유

Next.js App Router에서는 기본적으로 Server Component입니다.

브라우저 기능이 필요한 경우에만 "use client"를 선언합니다.

대표적인 경우는 다음과 같습니다.

  • useState
  • useEffect
  • 이벤트 핸들러
  • 브라우저 API 접근

즉 "use client"는 다음 의미입니다.

이 컴포넌트는 브라우저에서 실행됩니다.

Server Component vs Client Component

Server Component

서버 컴포넌트의 특징은 다음과 같습니다.

  • 서버에서 실행
  • 데이터 조회에 유리
  • 클라이언트 JS 감소

하지만 다음은 사용할 수 없습니다.

  • useState
  • useEffect
  • 이벤트 핸들러
  • 브라우저 API

Client Component

클라이언트 컴포넌트의 특징은 다음과 같습니다.

  • 브라우저에서 실행
  • 상태 관리 가능
  • 인터랙션 구현 가능

하지만 단점도 있습니다.

  • JS 번들 증가
  • 하이드레이션 비용 증가

실무에서의 판단 기준

SSR과 CSR은 이분법적으로 선택하는 기술이 아닙니다.

중요한 질문은 다음입니다.

  • 초기 콘텐츠 노출이 중요한가?
  • SEO가 중요한 페이지인가?
  • 복잡한 인터랙션이 많은가?
  • 서버 응답이 충분히 빠른가?

이를 적용해본다면 적당한 예시를 생각해볼 수 있습니다.

SSR이 유리한 경우

  • 블로그
  • 문서
  • 상품 상세 페이지
  • 마케팅 페이지

CSR이 자연스러운 경우

  • 관리자 페이지
  • 대시보드
  • 실시간 인터랙션 앱

Next.js App Router에서 가장 중요한 관점

Next.js를 공부할 때 가장 중요한 것은

SSR을 사용하는 법이 아니라
서버와 클라이언트의 경계를 설계하는 법입니다.

 

오늘의 내용을 요약하자면 다음과 같습니다.

  • CSR은 브라우저가 화면을 만듭니다.
  • SSR은 서버가 먼저 HTML을 생성합니다.
  • SSR이 항상 빠른 것은 아닙니다.
  • FCP는 콘텐츠가 처음 보이는 시점입니다.
  • TTI는 상호작용이 가능한 시점입니다.
  • 하이드레이션은 HTML에 React를 연결하는 과정입니다.
  • Next.js App Router는 Server Component 중심 구조입니다.

마무리

SSR과 CSR을 제대로 이해한다는 것은 단순히 용어를 아는 것이 아닙니다.

다음 흐름을 이해하는 것입니다.

  • 브라우저가 언제 화면을 보여주는가
  • 서버가 어디까지 책임지는가
  • 클라이언트가 언제 개입하는가
  • 성능 지표가 무엇을 의미하는가

그리고 Next.js App Router 시대에는 다음 질문이 중요해졌습니다.

이 UI는 서버에서 렌더링하는 것이 맞을까요,
클라이언트에서 렌더링하는 것이 맞을까요?

 

이 질문에 답할 수 있어야 "use client"를 남발하지 않고
Server Component와 Client Component를 올바르게 설계할 수 있습니다.

 

결국 좋은 Next.js 코드는

SSR을 사용했다는 코드가 아니라
서버와 클라이언트의 경계를 잘 설계한 코드입니다.

 

 

 

오늘도 긴 글을 봐주셔서 감사합니다!

'Next.js' 카테고리의 다른 글

Next.js 스타일링 전략: Tailwind CSS, shadcn/ui, 그리고 CSS-in-JS  (0) 2026.05.17
Next.js에서의 인증 전략과 쿠키 vs 토큰  (0) 2026.05.10
Next.js 데이터 페칭과 Server Actions  (2) 2026.04.09
렌더링 전략 완전 이해 - SSG, ISR, PPR, Cache Components  (0) 2026.03.29
Next.js App Router 라우팅 & Proxy 완벽 이해하기  (0) 2026.03.17

티스토리툴바