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

[렌더링 아키텍처 / 기반 기술]

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

10 KiB Raw Blame History