---
category: Other
tags: [auto-wikified, technical-documentation, other]
title: Server-Side Rendering (SSR)
description: "서버 사이드 렌더링(SSR)은 클라이언트(브라우저)에 빈 HTML을 보내고 자바스크립트를 다운로드하게 하는 대신, 서버에서 애플리케이션을 미리 렌더링하여 완성된 형태의 HTML 문서를 클라이언트로 전송하는 렌더링 아키텍처 패턴이다 [1, 2]."
last_updated: 2026-05-04
---

# Server-Side Rendering (SSR)

## 📌 Brief Summary
서버 사이드 렌더링(SSR)은 클라이언트(브라우저)에 빈 HTML을 보내고 자바스크립트를 다운로드하게 하는 대신, 서버에서 애플리케이션을 미리 렌더링하여 완성된 형태의 HTML 문서를 클라이언트로 전송하는 렌더링 아키텍처 패턴이다 [1, 2]. 이 방식은 사용자가 초기 화면을 보기까지 빈 화면을 대기해야 하는 문제를 해결하여 초기 로딩(First Paint) 속도를 개선하지만, 완전한 상호작용성을 위해 자바스크립트 기반의 하이드레이션(Hydration) 과정을 거쳐야 한다 [2-4]. 최근에는 스트리밍(Streaming), 지연 하이드레이션(Lazy Hydration), 그리고 서버 컴포넌트(React Server Components)의 도입 등을 통해 기존 SSR의 한계를 극복하는 방향으로 진화하고 있다 [5-7].

## 📖 Core 소스 Content
- **SSR의 렌더링 흐름 및 하이드레이션(Hydration):** 
  SSR 환경에서 서버는 먼저 뼈대(Shell)가 되는 완전한 HTML을 생성해 클라이언트에게 전달한다. 이를 통해 사용자는 화면을 즉시 볼 수 있지만, 이 초기 HTML은 아직 이벤트 핸들러가 연결되지 않은 '건조한(dry)' 상태다 [3, 4]. 이후 자바스크립트 번들이 다운로드되고 파싱되면, 프레임워크가 가상 DOM을 실제 DOM 구조에 맞추고 상호작용성을 불어넣는 '하이드레이션' 단계를 거치게 된다 [4, 8].
- **데이터 페칭(Data Fetching)의 진화:** 
  초기 애플리케이션들은 클라이언트 사이드 렌더링(CSR)을 통해 데이터를 가져왔으나, 성능 문제를 해결하기 위해 Next.js와 같은 메타 프레임워크는 `getServerSideProps` 등을 도입했다 [9-11]. 이를 통해 데이터베이스 쿼리를 포함한 초기 렌더링을 서버 단일 요청 안에서 처리하고, 완전히 채워진 UI를 사용자에게 전송하는 방식으로 발전했다 [10-12]. 정적 사이트 생성(SSG) 또한 빌드 타임에 HTML을 생성한다는 점을 제외하면 SSR의 광의적 개념으로 분류된다 [13].
- **지연 하이드레이션 및 스트리밍 (Lazy Hydration & Streaming):** 
  모든 데이터가 준비될 때까지 기다렸다가 단일 HTML로 보내는 대신, 서버가 쉘을 즉시 전송하고 준비되는 순서대로 Suspense 경계를 스트리밍하여 클라이언트가 점진적으로 하이드레이션하도록 최적화할 수 있다 [5]. Vue 3.5에서는 뷰포트 내에 보이는 컴포넌트만 활성화하는 지연 하이드레이션(Lazy Hydration) 기능을 SSR에 도입하여 초기 로딩 시간을 대폭 단축시켰다 [7].
- **SSR 고유 식별자 및 상태 관리:** 
  서버와 클라이언트 양쪽에서 렌더링이 일어날 때 DOM 트리가 불일치(Mismatch)하는 오류를 방지해야 한다 [7, 14]. Vue 3.5는 서버/클라이언트 간 일관된 고유 ID를 생성하는 `useId()` API를 제공하며, 예상된 불일치 경고를 억제하는 `data-allow-mismatch` 속성을 도입했다 [7, 14]. 또한 SSR 환경에서는 전역 상태(State)가 여러 사용자 요청 간에 공유되어 오염될 위험이 있으므로, Pinia와 같이 요청마다 격리된 인스턴스를 보장하는 도구를 활용해야 한다 [15, 16].

## ⚖️ Trade-offs & Caveats
- **이중 작업 문제(Two-Trip Lie):** 서버에서 HTML을 빠르게 렌더링해 전송하더라도, 브라우저는 여전히 모든 자바스크립트 번들을 다운로드하고 실행하여 클라이언트에서 다시 한 번 컴포넌트 트리를 구성해야 한다 [17]. 즉, 서버 작업을 수행했다고 해서 클라이언트로 전송되는 자바스크립트의 크기나 실행 비용이 본질적으로 줄어들지 않는다 [17, 18]. (이는 이후 서버 컴포넌트가 등장하게 된 결정적 한계점이다.)
- **하이드레이션 간극(Hydration Gap):** SSR의 결과로 UI가 빠르게 화면에 표시(First Paint)되더라도, 하이드레이션이 완료되기 전까지는 사용자가 버튼을 누르거나 폼을 제출하는 등의 상호작용이 전혀 작동하지 않아 "완성된 것처럼 보이지만 실제로는 작동하지 않는" 환상을 제공할 수 있다 [3]. 특정 컴포넌트의 렌더링이 느리면 하위 컴포넌트들의 이벤트 핸들러 연결까지 블로킹될 수 있다 [8].
- **서버 환경에서의 상태 오염(State Pollution):** 상태 스토어를 싱글톤(Singleton) 방식으로 구현할 경우, 다중 요청이 처리되는 서버 환경(Node.js 등)에서는 이전 요청의 상태나 다른 사용자의 상태가 다음 요청에 유출될 수 있는 치명적 보안/버그 위험이 존재한다 [15, 16].

## 🔗 Knowledge Connections

### Related Concepts

#### [렌더링 아키텍처 / 기반 기술]
- [[Hydration (하이드레이션)]]
  - 연결 이유: SSR이 서버에서 렌더링해 보낸 정적 HTML에 상호작용성(이벤트 등)을 주입하여 살아있는 애플리케이션으로 만드는 후속 프로세스이기 때문이다 [3, 4].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 초기 화면이 보이는 시간(First Paint)과 실제 상호작용이 가능해지는 시간(Time To Interactive) 사이의 차이인 하이드레이션 갭(Gap) 및 선택적/점진적 하이드레이션 최적화 원리 [3, 5, 8].
- [[React Server Components (RSC)]]
  - 연결 이유: 기존 SSR의 자바스크립트 번들 사이즈가 줄어들지 않는다는 한계와 클라이언트/서버 중복 연산 문제를 해결하기 위해 등장한 패러다임이기 때문이다 [17, 18].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 렌더링 로직을 서버에 완전히 고정시켜 자바스크립트를 클라이언트에 보내지 않는 방식과, SSR 기반 위에 RSC가 어떻게 보완적으로 적용되는지의 아키텍처적 차이 [6].

#### [구현 / 활용 도구]
- [[Next.js]]
  - 연결 이유: React 생태계 내에서 `getServerSideProps` 방식 등을 통해 서버 사이드 렌더링(SSR) 패턴을 대중화하고, RSC까지 포괄적으로 지원하는 대표적 메타 프레임워크이기 때문이다 [11, 19].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프레임워크가 라우터와 번들러를 결합하여 SSR 및 데이터 페칭을 자동화하고, 컴포넌트 경계를 나누는 방법 [19, 20].
- [[Pinia]]
  - 연결 이유: Vue 기반의 대규모 애플리케이션에서 SSR을 구축할 때 발생하는 크로스-리퀘스트 상태 오염(싱글톤 문제)을 방지하도록 설계된 상태 관리 라이브러리이기 때문이다 [16, 21].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: SSR 환경에서 요청 단위로 독립된 상태 스토어를 생성하고 안전하게 상태 관리를 수행하는 엔터프라이즈급 아키텍처 패턴 [16, 21].

### Deeper Research Questions

- SSR 환경에서 페이지가 상호작용할 수 없는 'Hydration Gap'을 줄이기 위해 도입된 React 18의 선택적 하이드레이션(Selective Hydration) 메커니즘은 내부적으로 어떻게 동작하는가?
- 전통적인 SSR이 전달하는 완성된 HTML 문자열과, React Server Components(RSC)가 전달하는 JSON 유사 형태의 RSC Payload는 각각 어떤 목적과 구조적 차이를 갖는가?
- Vue 3.5에서 새로 도입된 지연 하이드레이션(Lazy Hydration) 기능은 어떠한 원리로 뷰포트 기반 하이드레이션을 수행하며, 실제 대규모 애플리케이션의 메모리 최적화에 어느 정도 기여하는가?
- Node.js 환경에서 SSR 구동 시 메모리 누수를 방지하기 위해 프레임워크 내부 생명주기(Lifecycle Hook)에서 어떤 자원 해제(Cleanup) 로직이 요구되는가?
- E-commerce나 미디어 플랫폼에서 높은 SEO 및 초기 렌더링 성능 확보를 위해 SSR과 SSG(Static Site Generation)를 혼합하여 설계하는 최적의 아키텍처는 무엇인가?

### Practical Application Contexts

- **Implementation:** React(Next.js)나 Vue 3.5 환경에서 서버/클라이언트 간 ID 불일치를 막기 위해 각각 프레임워크가 제공하는 `useId()` 훅을 사용하여 접근성(A11y) 라벨이나 폼 식별자를 통일성 있게 구현한다 [7]. 
- **System Design:** 사용자의 초기 진입 속도와 검색엔진 최적화(SEO)가 비즈니스 성패를 좌우하는 콘텐츠 중심 웹사이트, E-commerce, 미디어 애플리케이션 아키텍처로 적합하다 [22]. 
- **Operation / Maintenance:** 운영 단계에서는 다수의 동시 요청이 백엔드(Node.js 서버)로 인입될 때 상태 저장소가 싱글톤으로 오염되지 않도록 철저한 분리 처리가 되어있는지 모니터링해야 한다 [15, 16].
- **Learning Path:** 우선 빈 HTML에서 시작하는 클라이언트 사이드 렌더링(CSR)의 문제를 이해하고 -> SSR의 원리와 '하이드레이션'의 개념을 숙지한 뒤 -> 스트리밍, 선택적 하이드레이션을 거쳐 -> 자바스크립트를 아예 보내지 않는 서버 컴포넌트(RSC)로 지식을 확장하는 것이 좋다 [3, 5, 8, 17, 18, 23, 24].
- **My Project Relevance:** 거대한 자바스크립트 번들 사이즈로 인한 모바일 환경에서의 초기 로딩 병목(Waterfall)을 해소하고, 사용자 데이터가 준비되는 대로 UI를 점진적으로 스트리밍하기 위해 기술 스택에 적용 여부를 평가할 수 있다.

### Adjacent Topics

- [[Client-Side Rendering (CSR)]]
  - 확장 방향: 클라이언트에서 모든 HTML 구성 및 데이터 페칭을 수행하는 방식으로, 초기 자바스크립트 번들 의존성이 극대화되는 SPA(Single Page Application)의 특성과 SSR의 반대 개념을 비교 분석한다 [25].
- [[Static Site Generation (SSG)]]
  - 확장 방향: SSR의 넓은 범주에 속하지만, 런타임(요청 시점)이 아닌 빌드 타임에 HTML을 사전 생성(Pre-render)하는 방식으로 CDN 캐싱 전략과 결합해 극강의 성능을 내는 아키텍처를 연구한다 [13].

---
*Last updated: 2026-05-03*