Hydration

SSR 페이지를 처음 열면 화면은 곧바로 보이는데, 버튼을 눌러도 잠시 반응이 없을 때가 있습니다. 사용자는 이미 HTML을 보고 있지만, 브라우저 안의 JavaScript는 아직 그 화면이 어떤 컴포넌트였는지, 어느 버튼에 어떤 이벤트를 연결해야 하는지 모르는 상태이기 때문입니다. 서버가 HTML을 그려 주는 것만으로는 인터랙션이 생기지 않습니다. 화면을 빨리 보여 주는 것과 그 화면을 살아 있는 애플리케이션으로 만드는 것은 서로 다른 단계이고, 이 사이를 메우는 과정이 바로 Hydration입니다.

초기 서버 렌더링은 완성된 HTML을 보내는 데는 강했지만, 이후 상호작용을 이어받기 위해서는 브라우저 쪽 프레임워크가 같은 UI를 다시 이해할 수 있어야 했습니다. 프론트엔드 프레임워크가 서버와 클라이언트에서 같은 컴포넌트 코드를 공유하기 시작하면서, '서버가 먼저 그린 화면을 버리지 않고 이어서 살릴 수 있지 않을까'라는 접근이 가능해졌습니다. 이때 등장한 개념이 Hydration입니다. 이미 존재하는 DOM을 기반으로 클라이언트가 이벤트 핸들러와 상태를 연결해, SSR의 빠른 초기 표시와 SPA의 인터랙션을 이어 붙이는 다리 역할을 합니다.

Hydration은 먼저 서버가 보낸 HTML을 브라우저가 화면에 그리는 것으로 출발합니다. 사용자는 이 시점에 이미 텍스트와 레이아웃을 볼 수 있습니다. 그다음 JavaScript 번들이 로드되면 프레임워크는 같은 컴포넌트 트리를 브라우저 안에서 다시 계산합니다. 이 과정에서 프레임워크는 현재 DOM 노드와 클라이언트가 기대한 출력이 일치하는지 비교하며 대응 관계를 만듭니다. 일치하면 기존 DOM을 재사용한 채 필요한 이벤트 핸들러와 상태 연결만 붙입니다. 그래서 같은 HTML을 다시 그리는 낭비를 줄일 수 있습니다. 문제는 서버와 클라이언트 출력이 다를 때입니다. 현재 시간, 랜덤 값, 브라우저 전용 API처럼 서버와 브라우저에서 결과가 달라지는 값이 렌더링에 섞이면 hydration mismatch가 발생합니다. 이때는 경고가 뜨거나, 프레임워크가 일부 DOM을 버리고 다시 그리게 됩니다.

Hydration과 SSR은 붙어 다니지만 같은 개념은 아닙니다. SSR은 서버가 HTML을 만들어 보내는 렌더링 전략이고, Hydration은 그 HTML을 브라우저의 이벤트와 상태 시스템에 연결하는 후속 단계입니다. HTML 생성과 인터랙션 활성화라는 역할이 다릅니다. SPA와도 구분해야 합니다. SPA는 처음부터 브라우저가 화면을 생성하고, Hydration은 이미 존재하는 서버 HTML을 재사용해 브라우저 애플리케이션으로 넘겨받는 과정입니다. 그래서 Hydration은 SSR이 있을 때 등장하는 개념이고, 순수한 클라이언트 렌더링에서는 필요하지 않습니다.

Hydration은 서버에서 첫 화면을 빠르게 보여 주고 싶은 거의 모든 현대적 프론트엔드 프레임워크에서 핵심 단계입니다. 상품 상세, 문서, 랜딩 페이지처럼 먼저 보여 줄 가치가 큰 화면에서 특히 중요합니다. 실무에서는 mismatch를 줄이는 것이 가장 큰 과제입니다. 렌더링 시점에 `window`를 직접 읽거나, 현재 시간과 랜덤 값을 그대로 UI에 넣거나, 서버와 클라이언트에서 다른 조건 분기를 타면 Hydration 경고가 발생합니다. 이런 값은 효과적으로 지연시키거나 클라이언트 전용 영역으로 격리해야 합니다. 또 모든 컴포넌트를 한 번에 Hydration할 필요는 없습니다. 사용자가 바로 상호작용할 영역부터 우선 활성화하거나, 특정 섬만 나중에 깨우는 전략을 쓰면 초기 반응성을 더 잘 관리할 수 있습니다. 결국 Hydration은 '보여 주기'와 '살아 있게 만들기' 사이의 시간을 어떻게 줄일지에 관한 설계 문제이기도 합니다.