웹 렌더링 방식이란?

  • 웹사이트를 만드는 재료(데이터, HTML, CSS, JS)를 누가, 언제, 어떻게 조립해서 사용자에게 보여줄 것 인가에 대한 전체 과정과 전략을 말함

렌더링 방식의 핵심 원리

  • 웹 렌더링을 서버, 클라이언트, 빌드 도구 중 누가 주도권을 쥐느냐에 따라 나뉜다. 640x349

렌더링 방식이 중요한 이유?

  • 조금 과장해서 렌더링 방식에 따라 웹사이트의 성패가 달라질 수 있기에, 웹페이지를 운영하는 목적에 따라 렌더링 방식을 전략적으로 고려하는 것도 좋은 방법일 것 같다.
    • 성능(Performance) : 첫 페이지가 얼마나 빨리 뜨는지
    • 사용자 경험(UX) : 페이지를 이동하거나 상호작용 할 때 얼마나 부드러운지
    • 검색엔진 최적화(SEO) : 검색엔진이 웹페이지의 내용을 얼마나 잘 읽어갈 수 있는지

웹 렌더링 방식

SSR (Server Side Rendering)

  • SSR은 초기 웹 환경에서부터 사용된 고전적인 방식이었으나, 최근에는 사용자 경험과 SEO를 위해 현대적인 프레임워크(Next.js 등)에서 재도입되어 활용되고 있다.
  • 웹 렌더링의 주도권을 Server 가 가지는 방식으로, 여기서 말하는 서버는 웹 호스팅 서버이다.
  • 파일 서버이자 호스팅을 담당하면서 데이터 처리와 HTML조립을 모두 맡아 처리한다.

640x515

장점 1. SEO (검색 엔진 최적화)에 유리

  • 위 시퀀스 다이어그램에서 보이듯, 요청 순간 데이터를 조회하고 HTML에 바인딩하여 완성된 HTML을 반환하기 때문에, 크롤러가 사이트 방문 시 페이지 결과를 바로 볼 수 있고, 좋은 컨텐츠로 인식하여 검색 결과에 노출하기가 수월한 편이다.

구글 공식 검색 프로세스(3단계)

  • 발견하고 Crawling
  • 이해하고 Indexing
  • 순위를 매겨 보여주는 Serving

위 세 단계를 통해 검색 결과를 제공하는데, 세 단계가 동시에 진행되는 것이 아니라 며칠에 걸쳐 이뤄진다. 특히 구글은 크롤링(HTML 다운로드)과 인덱싱(콘텐츠 분석)을 한 번에 처리하지 않고, 효율성을 위해 두 단계(Two-Pass)로 나누어 처리한다.

1단계 : Crawling

640x164

CSR의 경우 구글은 이 단계에서 <title> 태그와 <meta> 태그 등 페이지의 기본 정보는 우선 파악하고 색인에 포함시키긴 하지만 실제 콘텐츠(본문)는 2단계 WRS를 거쳐야만 읽을 수 있다.

2단계 : Indexing

색인이 되기 위해 콘텐츠가 반드시 필요한 CSR 페이지들은 1단계에서 보류된 후, 구글의 웹 렌더링 서비스(WRS: Web Rendering Service) 라는 별도의 시스템으로 보내지는데, 이것이 시간 지연의 원인이 된다.

장점 2. 초기 로딩 속도가 빠름(FCP 한정)

  • SSR이 초기 로딩 속도가 빠르다는 것은 FCP (First Contentful Paint)를 의미하는데, 이는 사용자가 화면에서 의미 있는 콘텐츠를 처음 볼 수 있을 때까지 걸리는 시간을 말한다.
  • React.js(CSR) 와 Next.js(SSR) 로 간단히 비교하자면, CSR(React.js)은 빈 DOM 구조를 먼저 파싱한 후 JS 파일을 다운로드하고 실행하여 데이터를 가져와 최종 화면을 렌더링하는 반면, SSR(Next.js)은 응답 시점에 완성된 HTML을 전달하므로 FCP가 빠를 수밖에 없다.

‘초기 로딩 속도’에서 중요한 세 가지 지표

  • TTFB (Time To First Byte) : 서버가 요청을 받고, 첫 번째 데이터를 브라우저에 보내는 데 걸리는 시간. (SSR 느림 < CSR 빠름)

  • FCP (First Contentful Paint) : 사용자가 화면에서 의미 있는 콘텐츠(텍스트나 이미지)를 처음 볼 수 있을 때까지 걸리는 시간. (SSR 빠름 > CSR 느림)

  • TTL (Time To Interactive) : 사용자가 페이지와 상호작용 할 수 있을 때까지 걸리는 시간 (SSR은 FCP와 TTL의 간격이 크고, CSR은 FCP와 TTL의 간격이 거의 차이가 없음)

SSR과 CSR의 FCP vs TTI 비교

640x228

장점 3. 낮은 초기 처리 부하 (저 사양 기기 유리)

  • 앞서 보았듯 SSR은 페이지를 그리는 모든 무거운 작업 (데이터 바인딩, HTML 조립 등)들이 성능 좋은 서버에서 미리 처리되므로 상대적으로 브라우저 의 부하가 크게 줄어든다. 그래서 클라이언트(브라우저) 성능에 크게 좌우되지 않는 편이다. (하이드레이션으로 인한 부하는 제외 - 이미 화면에 그려진 DOM 구조를 다시 스캔하여 이벤트 리스너 등을 하나하나 연결하는 작업)

단점 1. 느린 서버 응답 시간 (TTFB 지연 가능성)

  • 원인: SSR은 사용자의 요청이 있을 때마다 서버에서 데이터베이스(DB)에 접속하여 데이터를 조회하고, 템플릿에 렌더링하여 완성된 HTML을 즉시 생성해야 함. 이 일련의 서버 처리 과정 자체가 시간이 소요됨.

  • 문제점: 동시에 많은 요청이 들어오거나(트래픽 급증), DB 조회 시간이 길어지면, 서버에 과부하가 걸려 응답 시간이 느려짐.

  • 결과: 사용자가 첫 번째 데이터(첫 바이트)를 받을 때까지 걸리는 시간인 TTFB (Time To First Byte)가 CSR보다 길어질 수 있음. (CSR은 빈 HTML만 즉시 보내면 되므로 TTFB가 빠름.)

단점 2. TTL 지연 (느린 상호작용)

  • 원인: SSR은 HTML을 빠르게 보내 FCP를 달성하지만, 이후 Hydration(하이드레이션)이라는 무거운 클라이언트 측 JS 실행 및 연결 작업이 필수적임.

  • 문제점: Hydration 과정이 끝날 때까지 페이지는 사용자 입력에 반응할 수 없는 ‘먹통 구간’이 됨.

  • 결과: 사용자 눈에는 페이지가 완성된 것처럼 보이지만, 클릭이 안 되는 답답한 경험을 주어 UX가 저하됨. (FCP와 TTI 간 간격이 큼.)

단점 3. 서버 리소스 및 운영 비용 증가

  • 원인: SSR은 모든 요청을 서버가 직접 처리하고 HTML을 생성해야 함. (CSR은 대부분의 렌더링 작업을 사용자의 브라우저에 떠넘김.)

  • 문제점: 서버는 DB 조회, 템플릿 엔진 실행, HTML 생성 등 복잡한 연산을 반복적으로 수행해야 하므로 CPU와 메모리 사용량이 매우 높음.

  • 결과: 서버를 운영하기 위한 하드웨어 사양과 클라우드 비용이 CSR 대비 크게 증가함. 특히 트래픽이 폭증할 경우, 서버 증설 비용 부담이 커짐.

CSR (Client Side Rendering)

  • CSR은 SSR과 정반대되는 철학을 가지는데, 서버의 부담을 최소화 하고, 모든 동적인 작업을 사용자의 브라우저에 맡기는 방식이다.
  • 웹 렌더링 주도권을 Client(Browser)가 가지는 형태이다.
  • 초기 로딩 시 기본 뼈대만 있는 HTML 파일과 JS 번들을 먼저 응답한 다음, JS 파싱 및 실행 후 데이터를 조회해 데이터 바인딩 및 완성된 HTML을 생성 한다.
  • 여기서 웹 서버는 단순히 파일 호스팅만 담당하고, 실제 HTML 조립은 브라우저의 Javascript 가 처리한다.

640x974

장점 1. 빠른 페이지 전환 (부드러운 UX)

  • CSR 앱은 초기 로딩 시 한 번만 전체 JS 코드를 다운로드 하고 나면, 이후 페이지 이동 시 HTML 전체를 다시 서버에서 받아올 필요가 없다.
  • 필요한 데이터만 API를 통해 JSON 형태로 받아와 화면의 필요한 부분만 갱신함. 이는 페이지가 깜빡이거나 새로고침되는 현상 없이 매우 빠르고 부드러운 사용자 경험을 제공함.
  • 여기서 SSR도 초기 로딩 시 전체 JS 코드를 다운받는데? 라는 의문이 들 수 있는데, 여기서 중요한 사용 방식의 차이는 CSR은 기본적으로 SPA(Single Page Application) 형태로 동작한다는 것이다.

SPA vs MPA 핵심 차이점 비교

640x308

my-react-app/
├── public/
│   └── index.html          # 빈 껍데기 (단 하나의 HTML)
│
└── src/
    ├── pages/              # Home.jsx, About.jsx, Product.jsx
    ├── components/         # Header.jsx, Footer.jsx
    ├── App.jsx             # 라우팅 설정
    └── index.js            # ReactDOM.render 진입점

<!-- public/index.html: 유일한 HTML -->
<!DOCTYPE html>
<html>
  <body>
    <div id="root"></div>  <!-- 비어있음 -->
    <script src="bundle.js"></script>
  </body>
</html>

장점 2. 웹 호스팅 서버 부하 감소 및 비용 절감

  • 원인: 웹 호스팅 서버는 데이터 처리(DB 조회)와 HTML 템플릿 렌더링을 할 필요가 없음.

  • 결과: 서버는 요청에 대해 빈 HTML 뼈대와 JS 파일, 그리고 이후 순수한 데이터(JSON)만 제공하면 됨. 서버의 CPU 부담이 대폭 줄어들어, 운영 비용이 낮고 대용량 트래픽에도 안정적으로 대응함.

장점 3. FCP와 TTI 간격 최소화

  • 원인: JS가 실행되어야만 콘텐츠가 화면에 보이기 시작함 (FCP). 이벤트 리스너도 이 과정에서 동시에 붙음 (TTI).

  • 결과: TTI 자체가 늦어지더라도, FCP와 TTI 사이의 ‘먹통 구간’이 거의 없어 사용자에게 “보이는데 클릭은 안 되는” 답답함을 주지 않음.

단점 1. 느린 초기 로딩 속도 (FCP 지연)

  • 원인: 브라우저가 사용자에게 콘텐츠를 보여주기 위해 대용량의 JS 파일을 모두 다운로드하고 실행할 때까지 기다려야 함.

  • 문제점: JS 파일이 클 경우, 사용자는 긴 시간 동안 하얀 화면(White Screen)만 보게 됨.

  • 결과: 초기 로딩 속도 지표인 FCP가 SSR에 비해 현저히 느려지는 결정적인 단점이 있음.

단점 2. 검색 엔진 최적화 (SEO) 불리

  • 원인: Googlebot이 1단계 크롤링 시점에 받아보는 HTML 파일이 <div id="root"></div>와 같은 빈 껍데기이기 때문임.

  • 문제점: 실제 콘텐츠를 읽으려면 구글의 WRS(Web Rendering Service) 대기열을 거쳐 JS를 실행해야 함. 이 과정에서 색인에 시간이 더 오래 걸리는 지연(Delay) 이 발생할 수 있어 SSR보다 불리할 수 있음.

단점 3. 클라이언트 성능 의존성이 높음

  • 원인: 페이지 렌더링 및 상호작용 관련 모든 복잡한 연산을 사용자 기기의 CPU가 처리해야 함.

  • 결과: 사용자의 네트워크 환경이 불안정하거나 저사양 스마트폰을 사용할 경우, JS 다운로드 및 실행 시간이 오래 걸려 앱이 느리게 느껴지거나 버벅거림.

SSG (Static Site Generation)

  • SSG는 웹사이트를 사용자가 요청하는 시점이 아니라, 배포 및 빌드하는 시점에 미리 완성된 HTML 파일을 생성해 놓는 전략이다. 따라서 SSG의 장단점은 매우 명확한데, 속도는 엄청 빠르지만 데이터 변경 시에는 재 배포가 필요하다는 점이다.

작동 원리 (빌드 시점의 SSR)

  1. 빌드 시점: 개발자가 웹사이트를 서버에 올릴 때(빌드), SSG 도구(Next.js, Astro, Gatsby 등)가 데이터베이스에 접속하여 필요한 모든 데이터를 조회함.

  2. HTML 생성: 조회된 데이터로 수천, 수만 개의 완성된 HTML 파일을 미리 만들어냄.

  3. 배포: 이렇게 만들어진 정적인 HTML, CSS, JS 파일 묶음을 CDN(Content Delivery Network) 같은 분산된 파일 서버에 저장함.

  4. 사용자 요청 (Runtime): 사용자가 페이지를 요청하면, 서버가 HTML을 만드는 것이 아니라, 가장 가까운 CDN 위치에서 이미 만들어진 HTML 파일을 즉시 가져와 보여줌.

640x718

장점 1. 압도적인 속도 (TTFB, FCP 최상)

  • TTFB가 매우 빠르다. 서버에서 데이터를 조회하고 HTML을 만들 필요가 없기 때문에, 단순 파일을 전송하는 속도만 나오기 때문이며, 이에 따라 FCP 역시 매우 빠른 편이다.

장점 2. 최고의 SEO

  • SSR처럼 이미 완성된 HTML이 크롤러에게 제공되므로, 구글의 WRS 대기열을 거칠 필요가 없다.

장점 3. 낮은 비용 및 높은 안정성

  • 웹 호스팅 서버 대신 CDN에서 단순 파일을 제공하므로, 서버 운영 비용이 거의 들지 않는 편이다. 또한 트래픽이 아무리 폭증해도 CDN은 안정적으로 파일을 제공할 수 있다.

단점 1. 실시간 데이터 반영 어려움

  • 데이터가 업데이트될 때마다 전체 웹사이트를 다시 빌드하고 배포해야 한다. (예: 블로그 포스팅 하나 수정 시 전체 사이트 재빌드)

  • 뉴스 사이트처럼 실시간으로 데이터가 바뀌어야 하는 곳에는 부적합하다.

  • SSG는 데이터 업데이트 시 재빌드가 필요하지만, 최근에는 ISR과 같은 기술을 통해 일정 주기를 설정하여 부분적으로만 재빌드하여 실시간성 문제를 완화하고 있다고 한다.

단점 2. 개인화 어려움

페이지가 미리 만들어져 있기 때문에, 로그인한 사용자별로 내용이 달라지는 개인화된 페이지(Personalized Content)를 만드는데 제약이 따른다. (이 경우 SSR이나 CSR 혼합 방식이 필요함)

640x163

웹 렌더링 방식 3가지 핵심 비교

640x467

참고자료