[Web] Hydration(하이드레이션)

 

SSR을 사용하는 당신이라면 꼭 알아야 할 개념

 

하이드레이션이란?

Hydration(하이드레이션) 이란,
서버에서 미리 렌더링된 정적인 HTML에 클라이언트에서 자바스크립트 로직을 덧씌워서 동적으로 만드는 과정입니다.

즉,

• SSR로 HTML을 미리 전달
• 클라이언트에서 이벤트 핸들러, 상태 관리, 로직을 연결
• 그렇게 완성된 것이 "인터랙티브한 웹 앱"

이 과정을 하이드레이션이라고 부릅니다.

왜 하이드레이션이 필요한가?

SPA 방식은 브라우저에서 전체 HTML을 자바스크립트로 생성합니다.
하지만 이는 초기 로딩 시간이 길어지고 SEO가 불리하다는 단점이 있죠.

그래서 등장한 것이 SSR(Server-Side Rendering):

• 서버에서 HTML을 렌더링 → 빠른 첫 렌더링(FCP)
• 하지만 이 HTML은 정적일 뿐, 버튼 클릭 같은 동작은 안 됨

여기에 동적인 기능을 붙여주는 것이 바로 하이드레이션입니다.

하이드레이션의 동작 원리

1. 서버는 React/Vue 등의 컴포넌트를 HTML 문자열로 렌더링해서 클라이언트에 보냄
2. 브라우저는 이 HTML을 바로 화면에 보여줌
3. 동시에 자바스크립트 번들이 로딩됨
4. 자바스크립트는 DOM을 다시 분석하여 React 앱을 "같은 모양으로" 초기화함
5. 이벤트 핸들러, 상태 등을 활성화함 (이 시점부터 SPA처럼 작동)

서버에서 뿌려준 정적인 껍데기를, 클라이언트에서 살아있는 앱으로 되살리는 과정 = Hydration

CSR vs SSR vs Hydration

항목	CSR (Client-Side Rendering)	SSR (Server-Side Rendering)	SSR + Hydration
초기 렌더링 속도	느림	빠름	빠름
SEO	불리	유리	유리
자바스크립트 없이 작동?	X	O	X (Hydration 필요)
사용자 인터랙션	빠름	없음	있음 (Hydration 이후)

• SSR만으로는 "정적인 화면"일 뿐입니다.
• Hydration이 있어야 동작 가능한 SPA가 완성됩니다.

하이드레이션의 장점

장점	설명
빠른 첫 렌더링	HTML을 먼저 보여줘서 perceived performance 향상
SEO 최적화	검색 엔진이 HTML을 쉽게 파싱 가능
CSR보다 UX 우수	초기 비어있는 화면 없이 즉시 콘텐츠 표시
완전한 SPA 경험	Hydration 이후에는 CSR처럼 동작함

 

하이드레이션의 한계와 문제점

한계	설명
JS 번들 필요	JS 로딩이 늦으면 사용자 인터랙션 지연
중복 렌더링	서버에서 한 번, 클라이언트에서 또 한 번 렌더링함
성능 부담	복잡한 컴포넌트는 Hydration 비용이 큼
Debugging 어려움	SSR과 Hydration mismatch 시 버그 추적이 까다로움

 

특히 React에서는 서버와 클라이언트 DOM이 다르면 콘솔에 “Hydration failed” 경고가 뜨기도 합니다.

Partial Hydration이란?

부분 하이드레이션(Partial Hydration) 은 전체 페이지가 아닌 일부 컴포넌트만 하이드레이션하는 방식입니다.

• 서버에서는 전체 페이지를 정적으로 렌더링
• 동작이 필요한 영역만 JavaScript로 활성화

대표 사례

• Astro (기본적으로 정적 HTML + 필요한 곳만 클라이언트)
• Next.js의 dynamic() with { ssr: false } 옵션 등

이 방식은 성능 최적화에 매우 효과적이며, 최신 SSR 프레임워크들의 주요 트렌드입니다.

결론 및 정리

Hydration은 SSR의 완성 단계입니다.
서버에서 빠르게 HTML을 그려주고, 클라이언트에서 살아 움직이게 만드는 연결 고리죠.

하지만 하이드레이션은 무조건 좋은 것만은 아닙니다.

• 초반 로딩 성능은 좋지만
• 클라이언트 JS가 많을수록 hydration 비용도 커지고
• 이를 해결하기 위한 부분 하이드레이션, 아일랜드 아키텍처 등이 각광받고 있습니다.

정적인 속도 + 동적인 UX,
그 둘을 모두 잡고 싶다면 하이드레이션과 그 한계까지 제대로 이해하는 것이 중요합니다.