서버사이드 렌더링(SSR)와 클라이언트 사이드 렌더링(CSR)

Lemon·2025년 9월 5일
CS
0

CS

목록 보기
18/18
post-thumbnail

웹 개발에서 SSR과 CSR은 렌더링 방식을 나타내는 핵심 아키텍처 개념입니다. 렌더링은 결국 HTML을 언제 어디서 완성해서 사용자에게 보여줄지를 결정하는 과정이에요.

  • CSR(Client Side Rendering) : 클라이언트에서 HTML 완성
  • SSR(Server-Side Rendering) : 서버에서 HTML 완성

서버사이드 렌더링 (SSR) 이란?

서버사이드 렌더링은 서버에서 HTML을 미리 생성해서 클라이언트(브라우저)에 전달하는 방식입니다. 사용자가 페이지를 요청하면, 서버에서 HTML을 동적으로 생성하고 완성된 HTML 파일을 클라이언트에 전송하여 바로 페이지를 표시합니다.

SSR은 서버에서 HTML을 생성해서 클라이언트에게 보내는 아키텍처이기 때문에 서버가 꼭 JS일 필요가 없어요. 서버가 하는 건 “HTML 문자열을 생성해서 클라이언트에게 보내기”이니까, PHP, Python, Java, Ruby, C#, Node.js 등 서버에서 실행 가능한 언어라면 전부 가능합니다.

SSR 동작 방식 예시

블로그 사이트에서 "최근 포스트" 목록을 보여주는 경우를 살펴보겠습니다.

<!-- 서버가 클라이언트에게 전송한 HTML -->
<html>
  <head>
    <title>최근 포스트</title>
  </head>
  <body>
    <h1>최근 포스트</h1>
    <ul>
      <li>포스트 1</li>
      <li>포스트 2</li>
      <li>포스트 3</li>
    </ul>
  </body>
</html>

서버사이드 렌더링에서는 사용자가 페이지를 요청하면, 서버에서 "최근 포스트" 데이터를 가져와서 HTML로 변환한 후, 완성된 HTML 페이지를 클라이언트(사용자의 브라우저)에게 보냅니다. 그러면 브라우저는 이 HTML을 바로 렌더링하여 사용자에게 페이지를 표시합니다.

장점

  • 빠른 첫 페이지 로딩: 페이지를 처음 로딩할 때, HTML이 이미 완성되어 있으므로, 사용자에게 빠르게 콘텐츠를 보여줄 수 있습니다.
  • SEO에 유리: 검색 엔진이 페이지를 쉽게 크롤링할 수 있어 검색 결과에 바로 잘 노출될 수 있습니다.

단점

  • 서버 부담: 서버에서 HTML을 동적으로 생성하므로, 많은 사용자가 동시에 페이지를 요청하면 서버에 부담이 될 수 있습니다.
  • 사용자 상호작용이 느릴 수 있음: HTML을 완전히 만들어서 브라우저로 보내기 때문에 사용자가 눈으로 즉시 화면을 확인할 수는 있지만 SSR로 내려온 HTML은 정적 HTML이기 때문에 클릭, 입력 같은 동적 이벤트는 연결에 시간이 걸립니다. 클라이언트에서 React가 서버에서 내려온 HTML 과 hydrate 과정을 통해서 인터랙티브하게 동작하도록 해줍니다.
[SSR HTML] → 브라우저에 바로 보여짐 (빠른 화면)
         ↘
      [React hydrate 진행] → 이벤트/상태 바인딩
         ↘
      [인터랙티브 SPA] → 클릭, 입력 등 동작 가능

클라이언트 사이드 렌더링 (CSR)

클라이언트 사이드 렌더링은 서버가 빈 HTML 파일만 보내고, 브라우저에서 JavaScript를 실행해서 DOM을 구성하고 화면을 그리고 방식입니다. 서버는 기본 HTML 구조만 전송하고, 클라이언트(브라우저)에서 JavaScript를 통해 페이지의 내용이 동적으로 로드되고 렌더링됩니다.

CSR은 본질적으로 브라우저 안에서 동작하는 방식이기 때문에 HTML 문서 안에 <script>로 JS를 불러와서 실행해야 하니까, 언어는 무조건 JavaScript일 수밖에 없어요. 그래서 CSR 얘기할 때는 React, Vue, Angular 같은 JavaScript 기반 프레임워크들이 항상 언급됩니다.

CSR 동작 방식 예시

같은 "최근 포스트" 목록을 보여주는 페이지를 예시로 보겠습니다.

<!-- 서버가 클라이언트에 전송한 빈 HTML -->
<html>
  <head>
    <title>최근 포스트</title>
  </head>
  <body>
    <div id="posts"></div> <!-- JavaScript로 동적으로 채워질 곳 -->
    <script src="app.js"></script>
  </body>
</html>
// app.js에서 데이터를 받아서 페이지에 동적으로 렌더링
fetch('/api/posts') // 서버에서 포스트 목록을 받아옴
  .then(response => response.json())
  .then(posts => {
    const postsContainer = document.getElementById('posts');
    posts.forEach(post => {
      const postElement = document.createElement('li');
      postElement.textContent = post.title;
      postsContainer.appendChild(postElement);
    });
  });

클라이언트 사이드 렌더링에서는 사용자가 페이지를 요청하면, 서버는 빈 HTML 파일을 전송합니다. 그리고 클라이언트에서는 JavaScript가 실행되면서 API를 호출하여 "최근 포스트" 목록을 서버에서 받아옵니다. 받은 데이터를 이용해 페이지를 동적으로 렌더링합니다.

장점

  • 서버 부담 감소: 서버는 단순히 빈 HTML 파일과 API 데이터를 제공하므로, 서버의 부담이 적습니다.
  • 빠른 후속 페이지 로딩: JavaScript를 통해 페이지가 로드된 후에는 새로운 페이지를 빠르게 전환할 수 있습니다. 페이지가 다시 요청되지 않고 빠른 전환이 가능해집니다.
  • 풍부한 상호작용 : 클라이언트에서 즉시 동적 상호작용이 가능합니다.

단점

  • 첫 페이지 로딩 시간이 길어질 수 있음: 처음 페이지를 로드할 때 JavaScript 파일을 다운로드하고 실행해야 하므로, 첫 페이지 로딩 시간이 길어질 수 있습니다.
  • SEO에 불리함: 클라이언트에서 동적으로 콘텐츠를 생성하므로, 검색 엔진이 페이지를 크롤링하기 어려운 경우가 많습니다. 검색엔진 최적화(SEO) 측면에서 불리할 수 있습니다.

Next.js는 어디에 위치할까?

React는 CSR 중심 라이브러리이고, Next.js는 React를 기반으로 한 풀스택 프레임워크에요.

그래서 CSR도 가능하고, SSR도 가능합니다. 심지어 SSG, ISR(Incremental Static Regeneration)도 지원해요.

  • CSR 지원 (기본 React 앱처럼 동작)
  • SSR 지원 (서버에서 HTML 생성)
  • SSG 지원 (Static Site Generation - 빌드 시 정적 HTML 생성)
  • ISR 지원 (Incremental Static Regeneration - 점진적 정적 재생성)

즉, React 기반이지만 모든 렌더링 방식을 지원하는 하이브리드 프레임워크입니다.

언제 어떤 방식을 선택해야 할까?

SSR을 선택하는 경우

  • SEO가 중요한 웹사이트 (블로그, 뉴스 사이트, 전자상거래)
  • 빠른 첫 페이지 로딩이 중요한 서비스
  • 검색 엔진 노출이 비즈니스에 중요한 영향을 미치는 경우

CSR을 선택하는 경우

  • 상호작용이 많은 웹 애플리케이션 (대시보드, 관리자 패널)
  • 실시간 데이터 업데이트가 빈번한 서비스
  • 서버 비용을 절약하고 싶은 경우

실무에서의 SSR 도입 검토

개발팀에서 CSR에서 SSR로 전환을 검토할 때 마주치는 현실적인 상황을 살펴보겠습니다.

프론트엔드 팀의 관점

React 기반 CSR 환경에서 직면하는 문제들

  • SEO에 취약하여 검색엔진 노출이 어려
  • 번들 크기 증가로 인한 첫 로딩 시간 지연
  • 수동 라우팅 설정과 코드 스플리팅 관리의 복잡성
  • 빌드 최적화 설정의 번거로움

Next.js 도입을 통해 기대하는 개선점

  • SSR 지원으로 SEO와 초기 로딩 성능 개선
  • 파일 기반 라우팅으로 라우팅 구조 단순화
  • 자동 코드 스플리팅과 이미지 최적화
  • 개발자 경험(DX) 향상: Hot Reload, TypeScript 지원, ESLint 통합
  • 성능 최적화 도구들의 기본 제공
  • 간단한 백엔드 기능(API Routes)까지 제공해 개발 효율성을 높여줍니다.

백엔드 팀의 우려사항

하지만 백엔드 관점에서는 여러 현실적인 문제들이 있습니다.
Next.js를 도입하면 서버 구조에도 변화가 필요합니다.

1. 인프라 복잡성 증가

Client ← Nginx (정적 파일) ← CDN
                ↓
Client ← Spring Boot API ← Database

SSR 도입 후 필요한 구조

Client ← Nginx ← Next.js Server (Node.js) ← Spring Boot API ← Database

CSR은 정적 파일을 웹서버에서 서빙하면 끝이지만, SSR은 요청마다 HTML을 생성해야 하므로 Node.js 서버가 필요합니다. 예를 들어, 기존이 Nginx + Spring 구조라면, SSR을 적용하기 위해서는 Node 서버를 추가해야 합니다. 이로 인한 장애 지점 증가할 수 있습니다. Node.js 서버 다운 시 전체 서비스 영향을 미칩니다.

2. B2B 서비스에서의 SSR 효과 제한

B2B 서비스의 특징

  • 대부분의 핵심 기능이 로그인 후 제공
  • 검색 엔진 노출 필요성 낮음 (직접 링크로 접근)
  • 대시보드/관리 도구 성격의 화면이 대부분

이런 경우 SSR의 주요 장점인 SEO 개선 효과가 미미합니다. 오히려 서버 비용 증가와 운영 복잡성만 커질 수 있습니다. 이 경우 CSR 방식이 더 단순하고 안정적입니다.

3. 개발팀 간 역할 경계 모호화

기존 CSR 구조

  • 프론트엔드: 클라이언트 코드 개발
  • 백엔드: API 서버 개발 및 운영

SSR 도입 후

  • Next.js 서버는 프론트엔드가 개발하지만 서버 운영이 필요
  • API 호출 로직이 서버에서도 실행 (getServerSideProps)
  • 장애 발생 시 책임 소재 불분명

SSR에서의 역할 분담

백엔드 (API 서버)

  • DB와 통신, 비즈니스 로직 처리
  • JSON 형태로 데이터 반환

프론트엔드 (SSR 서버 : Next.js)

  • 클라이언트에게 내려줄 HTML을 서버에서 미리 그림
  • 이 과정에서 백엔드 API를 호출해 데이터 가져와 HTML 반영
  • 완성된 HTML을 브라우저에 전달

클라이언트(브라우저)

  • 서버에서 받은 HTML을 우선 표시 (빠른 첫 화면)
  • 이후 React가 "hydrate"라는 과정을 통해 이벤트 바인딩 → CSR처럼 동작 시작
    • 💡Hydration(하이드레이션) 이란? SSR로 렌더링된 HTML은 시각적으로만 완성된 정적 페이지이며, React 컴포넌트의 이벤트 핸들러나 상태 관리 로직은 아직 연결되지 않은 상태입니다. Hydration은 서버에서 전달받은 HTML에 클라이언트의 React 코드(이벤트, 상태, 가상 DOM)를 연결하여 상호작용 가능한 React 앱으로 만드는 과정입니다. SSR 직후 (Hydration 전)
      <button>좋아요 👍</button>
*<!-- 버튼이 보이지만 onClick 이벤트는 작동하지 않음 -->*
      Hydration 이후

      • React가 클라이언트에서 실행되면서 가상 DOM 생성

      • 서버에서 받은 HTML과 비교하여 일치성 확인

      • 이벤트 핸들러 연결 → 완전한 SPA처럼 동작 시작

        특징

      • 빠른 첫 화면: HTML을 먼저 보여주므로 초기 로딩 속도 향상

      • CSR 전환: Hydration 완료 후에는 CSR처럼 동작

      • 성능 고려사항: 페이지가 클수록 Hydration 과정이 무거워질 수 있음

즉, SSR에서도 프론트엔드는 여전히 React/JS코드 작성을 합니다. 다만 렌더링이 브라우저뿐 아니라 서버에서도 수행되며, 백엔드 API와 연계해 초기 HTML을 만들어내는 책임이 추가된다는 점이 다릅니다. SSR 시 프론트엔드는 여전히 React 개발하지만, 렌더링이 서버에서도 수행되고 백엔드 API를 불러와 HTML을 만들어내는 역할까지 맡습니다.

SSR 도입을 검토할 때 고려해야 할 질문들

비즈니스 관점

  • SEO가 비즈니스에 중요한 영향을 미치는가?
  • 첫 로딩 속도 개선이 사용자 경험에 크게 기여하는가?
  • 추가 인프라 비용을 감당할 수 있는가?

기술 관점

  • Node.js 서버 운영 경험이 있는가?
  • 현재 인프라에 Node.js 서버를 안정적으로 통합할 수 있는가?
  • 장애 대응 체계가 준비되어 있는가?

조직 관점

  • 프론트엔드와 백엔드 팀 간 협업 체계가 구축되어 있는가?
  • SSR 관련 기술 역량을 확보할 수 있는가?

마무리

현대 웹 개발에서는 SSR과 CSR의 경계가 점점 모호해지고 있습니다. Next.js, Nuxt.js, SvelteKit 같은 프레임워크들은 두 방식의 장점을 결합한 하이브리드 렌더링을 지원하며, 페이지 단위로 CSR과 SSR을 선택적으로 적용할 수 있습니다.

최근에는 SEO와 초기 로딩 속도가 중요한 서비스(예: 전자상거래, 콘텐츠 서비스)에서는 SSR이나 하이브리드 방식을 선호하고, 실시간 데이터 갱신이나 상호작용이 중요한 서비스(예: 대시보드, 관리자 패널)에서는 CSR을 많이 활용합니다.

또한, 단순히 SSR과 CSR에 국한되지 않고, SSG(Static Site Generation), ISR(Incremental Static Regeneration) 같은 정적 생성 기법을 활용하여 성능과 비용을 최적화하는 경우도 늘고 있습니다.

결국, 하나의 정답이 존재하는 것은 아니며, 서비스의 특성, 비즈니스 목표, 인프라 환경에 따라 적절한 조합을 선택해야 합니다.

profile
Lemon
개미는 뚠뚠..오늘도 뚠뚠🐜
이전 포스트

[CS] HTTP vs 쿠키 vs 세션 vs 웹스토리지

0개의 댓글