---
id: wiki-2026-0508-hydration
title: Hydration
category: Architecture
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation, merged, architecture]
raw_sources: []
last_reinforced: 2026-05-08
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
  language: unspecified
  framework: unspecified
---

# React Hydration


## 📌 한 줄 통찰 (The Karpathy Summary)
React Hydration은 서버 사이드 렌더링(SSR)을 통해 생성된 정적인 HTML 문서에 클라이언트 측 React가 이벤트 핸들러와 상호작용성을 주입하는 과정이다 [1]. 빈 화면(White Screen)을 보여주는 대신 완전히 형태를 갖춘 HTML을 사용자에게 먼저 제공하여 초기 체감 로딩 속도를 향상시키기 위해 사용된다 [1, 2]. React 코어 팀의 댄 아브라모프(Dan Abramov)는 이를 "마른(dry) HTML에 상호작용성이라는 물을 주는 것"이라고 비유했다 [1].

## 📖 구조화된 지식 (Synthesized Content)
*   **작동 메커니즘**: 하이드레이션은 DOM을 처음부터 다시 생성(Re-rendering)하는 것이 아니다 [3]. React는 서버에서 이미 렌더링된 DOM 트리를 순회하면서, 자신이 구축 중인 Fiber 트리와 병렬로 비교한다 [3]. 각 Fiber를 기존 DOM 노드에 매칭시켜 `fiber.stateNode`에 참조를 저장한 뒤, 이벤트 리스너를 부착하고 DOM을 재사용함으로써 애플리케이션을 활성화한다 [1, 3].
*   **선택적 하이드레이션 (Selective Hydration)**: 과거에는 전체 트리가 하이드레이션될 때까지 기다려야 했지만, React 18은 Lanes 우선순위 시스템을 통해 이 과정을 개선했다 [4]. 사용자가 애플리케이션의 특정 요소와 상호작용을 시도하면, React는 진행 중이던 하이드레이션을 중단하고 `SyncLane`을 사용해 사용자가 상호작용한 경계로 점프하여 해당 부분만 우선적으로 하이드레이션한 뒤 나머지 작업을 재개한다 [4].
*   **스트리밍과 점진적 적용 (Streaming)**: 서버는 데이터가 모두 준비될 때까지 기다리지 않고 셸(Shell)을 즉시 클라이언트로 전송하며, Suspense 경계 단위로 데이터가 해결되는 대로 스트리밍한다 [4]. 클라이언트는 나머지 데이터가 도착하는 동안 이미 수신된 부분부터 점진적으로 하이드레이션을 시작할 수 있다 [4].
*   **클라이언트 컴포넌트와 서버 컴포넌트의 차이**: 클라이언트 컴포넌트(Client Components)는 서버에서 먼저 실행된 후 클라이언트에서 하이드레이션을 위해 다시 한 번 실행된다 [5, 6]. 반면, React 서버 컴포넌트(RSC)는 오직 서버에서만 실행되므로 클라이언트 측의 하이드레이션 단계 자체가 존재하지 않는다 [6].

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
*   **하이드레이션 갭 (The Hydration Gap)**: SSR과 하이드레이션은 사용자가 페이지를 더 빨리 볼 수 있게 하지만, **화면이 완성되어 보임에도 실제로는 상호작용할 수 없는 '착시 구간'**을 만들어낸다 [3, 7]. 이벤트 리스너가 부착되기 전까지는 버튼을 클릭하거나 드롭다운을 눌러도 애플리케이션이 아무런 반응을 하지 않는다 [7].
*   **전체 트리 순회에 따른 블로킹**: 기본적으로 React는 트리를 순차적으로 순회하며 하이드레이션을 진행하기 때문에, 트리 상단에 처리 속도가 느린 컴포넌트가 하나라도 있으면 하단 요소의 클릭 핸들러 부착까지 전체적으로 지연되는 병목 현상이 발생한다 [3].
*   **이중 작업과 자바스크립트 번들 비용 (The Two-Trip Lie)**: 서버에서 HTML을 먼저 렌더링하더라도, 결국 상호작용을 위해 클라이언트는 전체 자바스크립트 번들을 그대로 다운로드하고 파싱해야 한다 [8, 9]. 서버에서 데이터를 페칭하여 HTML을 완성했음에도 불구하고, 클라이언트가 다시 동일한 컴포넌트를 실행하게 되므로 전체적인 클라이언트 작업량이나 JavaScript 번들 크기는 감소하지 않는다는 근본적인 한계가 있다 [8]. (이러한 단점을 해결하기 위해 등장한 것이 React 서버 컴포넌트이다 [9].)

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

## 📚 Legacy Insights & Additional Context
> [!NOTE]
> Below is content merged from previous versions of this documentation.

## 📌 한 줄 통찰 (The Karpathy Summary)
지연 하이드레이션(Lazy Hydration)은 Vue 3.5에서 서버 사이드 렌더링(SSR)을 위해 도입된 성능 최적화 기능입니다 [1]. 이 기능은 컴포넌트가 화면(뷰포트)에 표시될 때만 하이드레이션이 수행되도록 활성화를 지연시킵니다 [1, 2]. 이를 통해 불필요한 초기 연산을 방지하여 초기 로드 시간을 단축하고 전반적인 사용자 경험을 향상시킵니다 [1, 3].

## 📖 구조화된 지식 (Synthesized Content)
* **동작 메커니즘 및 성능 향상:** 지연 하이드레이션은 SSR 환경에서 컴포넌트가 사용자의 뷰포트 내에 들어오기 전까지는 활성화(하이드레이션)를 미루는 방식으로 작동합니다 [1, 2]. 이 전략은 애플리케이션의 초기 페이지 로드 시간을 감소시키고 Vue.js의 렌더링 성능을 향상시키는 데 직접적으로 기여합니다 [1, 2].
* **주요 적용 분야:** 이 패턴은 빠른 로딩 시간과 검색 엔진 최적화(SEO)가 비즈니스 성공에 필수적인 콘텐츠 관리 시스템(CMS), 이커머스 사이트, 미디어 플랫폼 등 콘텐츠가 풍부한 대규모 웹 애플리케이션에서 매우 유용합니다 [4]. 
* **사용자 경험(UX) 개선:** 컴포넌트를 실제로 필요한 시점에만 활성화함으로써 대규모 애플리케이션 환경에서도 사용자에게 훨씬 더 부드러운 상호작용(Interaction) 경험을 제공할 수 있습니다 [3]. 빠른 초기 화면 로딩을 달성하면서도 대화형 기능들을 무리 없이 유지할 수 있도록 돕습니다 [4].

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
소스에 관련 정보가 부족합니다. (제공된 소스 데이터 내에는 'Lazy Hydration' 기법 적용에 따른 구체적인 기술적 부작용, 제약 사항 또는 반대 급부에 대한 내용이 포함되어 있지 않습니다.)

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

## 📚 Legacy Insights & Additional Context
> [!NOTE]
> Below is content merged from previous versions of this documentation.

## 📌 한 줄 통찰 (The Karpathy Summary)
하이드레이션(Hydration)은 프론트엔드 프레임워크가 서버 사이드 렌더링(SSR)을 통해 생성된 정적 HTML을 클라이언트에서 넘겨받아 이벤트 핸들러를 연결하고 상호작용성(Interactivity)을 부여하는 과정입니다 [1]. 이는 '건조한(dry)' HTML에 상호작용성이라는 '물(water)'을 주는 것에 비유됩니다 [1]. 사용자에게 화면을 더 빨리 보여줄 수 있다는 장점이 있지만, 최적화되지 않을 경우 페이지가 렌더링된 후 상호작용이 가능해질 때까지의 지연(하이드레이션 갭)이 발생하는 한계도 지니고 있습니다 [2].

## 📖 구조화된 지식 (Synthesized Content)
* **하이드레이션의 동작 원리**
  하이드레이션은 처음부터 DOM을 다시 생성하는 재렌더링(re-rendering) 작업이 아닙니다 [3]. 예를 들어 React는 기존에 서버가 렌더링한 DOM 트리를 순회하면서 생성 중인 Fiber 트리와 대조(matching)하여 기존 DOM을 재사용하고 이벤트 리스너만 연결하는 방식으로 작동하므로, 완전히 새로 렌더링하는 것보다 빠릅니다 [1, 3]. 

* **프레임워크별 하이드레이션 최적화 전략**
  * **React 18의 선택적 하이드레이션(Selective Hydration)**: 기존의 하이드레이션은 순차적으로 진행되었으나, React 18부터는 우선순위(Lanes) 시스템을 도입하여 사용자가 클릭 등 상호작용을 시도하면 해당 부분의 하이드레이션을 우선적으로 처리한 뒤 나머지 트리의 작업을 재개할 수 있습니다 [4].
  * **스트리밍(Streaming)과의 결합**: 서버가 모든 데이터를 기다리지 않고 UI 셸(Shell)을 먼저 보낸 뒤 데이터가 해결되는 대로 청크 단위로 스트리밍하면, 클라이언트는 나머지 데이터가 도착하는 중에도 이미 도착한 부분부터 하이드레이션을 시작할 수 있습니다 [4].
  * **Vue 3.5의 지연 하이드레이션(Lazy Hydration)**: Vue 3.5는 서버 사이드 렌더링 시 컴포넌트가 뷰포트에 표시될 때만 하이드레이션되도록 지연시키는 기능을 도입했습니다 [5]. 이를 통해 초기 로드 시간을 줄이고 불필요한 활성화를 지연시켜 애플리케이션의 성능을 향상시킵니다 [5, 6].

* **서버 컴포넌트(RSC)를 통한 하이드레이션 제거**
  React 서버 컴포넌트(RSC)는 오직 서버에서만 실행되며 클라이언트로 전송되는 자바스크립트 번들에 포함되지 않습니다 [7, 8]. 따라서 클라이언트에서 다시 실행되거나 하이드레이션할 필요가 없어 하이드레이션 비용 자체를 완전히 제거하고 초기 로딩 및 상호작용 속도를 향상시킬 수 있습니다 [7, 9].

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
* **하이드레이션 갭(Hydration Gap)**
  전통적인 SSR과 하이드레이션 방식에서는 서버가 렌더링한 HTML이 클라이언트에 표시될 때 "페이지가 준비된 것처럼 보이지만 실제로는 그렇지 않은" 상태가 존재합니다 [2]. React가 이벤트 리스너를 완전히 부착하기 전까지는 사용자가 버튼을 클릭하거나 폼을 제출하려고 해도 아무런 반응이 없는 현상이 발생합니다 [2].
* **전체 트리 블로킹(Blocking) 문제**
  기본적인 하이드레이션 과정에서는 전체 트리의 하이드레이션이 완료되기 전까지는 UI의 어떤 부분도 상호작용할 수 없습니다 [3]. 만약 트리 상단에 처리 속도가 느린 컴포넌트가 존재한다면, 트리 하단에 있는 단순한 버튼의 클릭 핸들러조차 작동하지 못하게 막는 병목 현상을 초래합니다 [3].
* **자바스크립트 번들 크기 문제 유지**
  SSR과 하이드레이션의 조합은 초기 빈 화면을 해결해 주지만, 결국 서버에서 렌더링된 모든 컴포넌트의 자바스크립트 코드를 클라이언트가 다운로드하고 실행해야 합니다 [10]. 결과적으로 서버 작업이 클라이언트의 연산량이나 자바스크립트 번들 크기를 줄여주지는 못한다는 근본적인 제약이 있습니다 [10, 11].

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

## 📚 Legacy Insights & Additional Context
> [!NOTE]
> Below is content merged from previous versions of this documentation.

## 📌 한 줄 통찰 (The Karpathy Summary)
[[Hydration|Hydration]]은 서버에서 렌더링된 정적 HTML 뼈대에 JavaScript를 실행하고 이벤트 리스너를 연결하여 완전한 상호작용이 가능한 애플리케이션으로 변환하는 과정입니다 [1, 2]. 기본적으로 React는 페이지 전체를 한 번에 Hydration하면서 메인 스레드를 차단하여 TBT(Total Blocking Time)와 TTI(Time to Interactive) 지표를 악화시킬 수 있습니다 [3]. 이를 해결하기 위해 선택적 Hydration, 지연 로딩, [[React Server Components|React Server Components]](RSC) 등의 최적화 기법을 도입하여 초기 로드 성능과 상호작용성을 극대화할 수 있습니다 [4-6].

---

Hydration(하이드레이션)은 React가 서버에서 렌더링된 정적 HTML에 이벤트 리스너와 상태를 연결하여 상호작용이 가능하도록 만드는 과정입니다 [1]. [[Next.js 15|Next.js 15]] 환경에서는 이러한 하이드레이션 과정이 오직 클라이언트 컴포넌트(Client Components)에서만 발생합니다 [1]. [[CSS-in-JS|CSS-in-JS]]와 같은 스타일링 방식을 사용할 때, 서버와 클라이언트 간의 생성 결과물이 다르면 '하이드레이션 불일치(hydration mismatch)'가 발생할 수 있으므로 세심한 관리가 필요합니다 [2-4].

---

하이드레이션(Hydration)은 서버에서 사전 렌더링된 정적 HTML을 클라이언트가 전달받은 후, [[JavaScript|JavaScript]]를 실행하여 이벤트 리스너와 상태를 연결함으로써 완전한 상호작용이 가능한 애플리케이션으로 변환하는 과정입니다 [1]. SSR(Server-Side Rendering)의 빠른 콘텐츠 표시 장점과 CSR(Client-Side Rendering)의 상호작용성을 결합하지만, 하이드레이션이 완료되기 전까지는 사용자의 입력에 응답하지 않아 지연이 발생할 수 있습니다 [1-5].

## 📖 구조화된 지식 (Synthesized Content)
*   **Hydration의 개념 및 주요 성능 병목 현상:**
    *   Hydration은 SSR(Server-Side Rendering) 환경에서 서버가 생성한 HTML을 클라이언트가 넘겨받아 상호작용을 부여하는 필수적인 과정입니다 [2, 3]. 
    *   문제는 React가 기본적으로 시야에 보이지 않는 컴포넌트까지 포함하여 페이지 전체를 한 번에 Hydration 하려 한다는 점입니다 [3]. 이로 인해 JavaScript 실행이 메인 스레드를 장시간 점유하게 되고, 결과적으로 TBT(Total Blocking Time), FID(First Input Delay), TTI(Time to Interactive) 등의 핵심 웹 성능 지표가 크게 저하되며 사용자의 입력 지연을 초래합니다 [3, 7].
    *   또한 서버에서 렌더링된 HTML과 클라이언트의 렌더링 결과가 다를 때 발생하는 'Hydration Mismatch' 오류와, 모든 컴포넌트를 위한 전체 JavaScript를 다운로드해야 해서 발생하는 번들 크기 비대화(Bundle Size Bloat) 문제도 겪을 수 있습니다 [4, 8].

*   **점진적 및 선택적 Hydration (Selective & Progressive Hydration):**
    *   페이지 전체를 일괄 처리하는 대신 스크롤 위쪽(Above-the-fold)의 중요한 콘텐츠를 우선 처리하고, 덜 중요한 컴포넌트는 Hydration을 지연시킵니다 [4].
    *   [[Next.js|Next.js]] 환경에서는 `next/dynamic`을 활용한 동적 임포트(Dynamic Imports)를 통해 구현하거나, IntersectionObserver API를 사용하여 요소가 뷰포트에 들어올 때만 Hydration을 수행하는 지연(Lazy) 방식을 적용할 수 있습니다 [5, 9]. 이를 통해 메인 스레드 차단을 분산시켜 TBT를 최대 40%까지 줄일 수 있습니다 [5].

*   **[[React Server Components (RSC)|React Server Components (RSC]]의 활용:**
    *   [[Next.js App Router|Next.js App Router]] 등에서 지원하는 React Server Components는 오직 서버에서만 실행되며 클라이언트로 JavaScript 페이로드를 전혀 보내지 않습니다 [5, 10, 11].
    *   정적이거나 상호작용이 필요 없는 UI(예: 텍스트, 사이드바 등)를 RSC로 구성하면 해당 영역은 Hydration 프로세스 자체가 필요 없어지므로 클라이언트의 부담과 번들 크기가 비약적으로 감소합니다 [6, 12, 13].

*   **Streaming 및 Suspense 적용:**
    *   React의 Suspense API를 활용하면 서버에서 HTML을 점진적으로 스트리밍(Streaming)할 수 있습니다 [6].
    *   이를 통해 렌더링이 완료된 일부 화면을 사용자에게 더 빠르게 보여주면서(FCP 개선), 복잡한 부분에 대한 Hydration 작업은 나중으로 미루어 체감 성능을 향상시킬 수 있습니다 [6, 14]. [[React 18|React 18]]의 동시성 렌더링([[Concurrent Rendering|Concurrent Rendering]])은 Hydration 작업을 작은 청크로 쪼개어 브라우저가 사용자 입력을 처리할 수 있도록 양보(yield)하는 기능을 제공합니다 [15].

*   **부분 Hydration (Partial Hydration) 및 기타 팁:**
    *   정적인 콘텐츠 영역을 고립시키고 상호작용이 필요한 특정 부분만 Hydration하는 섬 아키텍처([[Island Architecture|Island Architecture]])를 도입하거나, 절대적으로 정적인 콘텐츠의 경우 `dangerouslySetInnerHTML`을 사용하여 통째로 Hydration 과정에서 배제하는 것도 유용한 전략입니다 [16-18].
    *   불가피하게 클라이언트와 서버 간의 렌더링 불일치가 예상되는 곳에는 `suppressHydrationWarning`을 제한적으로 사용하거나, Hydration 완료 이후에 동작해야 하는 로직을 의존성 배열이 빈 `useEffect` 내에 배치하여 불일치 에러를 방지할 수 있습니다 [17, 19].

---

* **하이드레이션의 작동 원리:** React 애플리케이션에서 하이드레이션은 서버가 완전한 초기 HTML을 생성하고, 브라우저가 클라이언트 컴포넌트용 [[JavaScript|JavaScript]]를 다운로드한 후, React가 해당 컴포넌트에 상호작용(인터랙티비티)을 부여하는 순서로 진행됩니다 [1, 4]. 
* **하이드레이션 불일치(Hydration Mismatch):** 서버에서 생성한 콘텐츠와 클라이언트가 기대하는 콘텐츠가 다를 때 발생합니다 [4]. 예를 들어, 서버와 클라이언트가 서로 다른 타임스탬프를 생성하거나 동적으로 다른 CSS 클래스명을 생성할 때 이 문제가 일어납니다 [3, 4].
* **[[styled-components|styled-components]]와 하이드레이션 문제 해결:** [[Next.js App Router|Next.js App Router]] 및 서버 사이드 렌더링(SSR) 환경에서 styled-components를 사용할 때 서버와 클라이언트가 다른 클래스명을 생성하여 하이드레이션 불일치 위험이 발생할 수 있습니다 [3]. 이를 방지하기 위해 개발자는 `next.config.js`에서 `styledComponents` 컴파일러 옵션을 활성화하여 서버와 클라이언트 경계에서 일관된 클래스명이 생성되도록 보장해야 합니다 [3].
* **테마 전환 시의 하이드레이션 관리:** 라이트 모드와 다크 모드 같은 테마를 전환할 때, 일관된 클래스명 해시를 유지하여 하이드레이션 불일치를 방지하려면 테마 객체를 `ThemeProvider`에 올바르게 전달하여 클래스명을 안정화해야 합니다 [2, 5].

---

*   **작동 방식 및 역할:**
    *   서버는 데이터가 포함된 HTML을 생성하여 클라이언트(브라우저)로 전송합니다 [3, 5].
    *   브라우저는 이 HTML을 즉시 표시하므로 사용자는 콘텐츠를 바로 볼 수 있지만, 이 시점에서는 상호작용할 수 없는 정적인 상태입니다 [2, 3].
    *   이후 브라우저가 JavaScript 번들을 다운로드하고 실행하면, React가 가상 DOM을 렌더링된 HTML에 "연결(attach)"하여 버튼 클릭 등 각종 이벤트 핸들러와 상태 관리를 활성화합니다. 이 과정이 바로 하이드레이션입니다 [1, 2, 5].
*   **성능에 미치는 영향 및 주요 과제:**
    *   하이드레이션은 TBT(총 차단 시간), FID(최초 입력 지연), TTI(상호작용까지의 시간) 등 핵심 성능 지표([[Core Web Vitals|Core Web Vitals]])에 직접적인 영향을 미칩니다 [6]. 
    *   기본적으로 React는 전체 페이지를 한 번에 하이드레이션하려 하기 때문에 메인 스레드를 차단하는 불필요한 JavaScript 실행이 발생하고, 이로 인해 사용자가 클릭해도 즉각적으로 반응하지 않는 입력 지연(Input lag)을 초래할 수 있습니다 [5, 7]. 
    *   서버 렌더링 결과와 클라이언트 측 렌더링이 일치하지 않을 때 발생하는 '하이드레이션 불일치 에러(Mismatch errors)'와 모든 컴포넌트의 JavaScript 번들을 로드해야 해서 발생하는 번들 크기 비대화(Bundle size bloat) 문제도 자주 겪는 과제입니다 [7-9].
*   **하이드레이션 최적화 전략:**
    *   **점진적/선택적 하이드레이션 (Selective Hydration):** 동적 임포트(`next/dynamic`)를 사용해 화면 상단(Above-the-fold)의 중요한 콘텐츠를 먼저 처리하고 나머지 덜 중요한 컴포넌트의 하이드레이션을 분산시킵니다 [8, 10, 11].
    *   **가시성 기반 지연 하이드레이션 (Lazy Hydration):** `IntersectionObserver` API 등을 활용하여 컴포넌트가 뷰포트에 들어올 때만 하이드레이션을 실행합니다 [10, 11].
    *   **부분 하이드레이션 (Partial Hydration) 및 아일랜드 아키텍처:** 상호작용이 필요한 특정 부분만 하이드레이션하고 나머지는 정적 HTML로 남겨둡니다 [12, 13].
    *   **스트리밍 및 Suspense:** React의 Suspense API를 사용하여 서버에서 HTML을 점진적으로 스트리밍 처리합니다 [14].
    *   **[[React Server Components (RSC)|React Server Components (RSC]]:** 클라이언트 측으로 전송되는 JavaScript를 완전히 없애고 오직 서버에서만 실행되게 함으로써, 해당 컴포넌트들에 대해서는 하이드레이션 과정 자체를 생략합니다 [15-23].

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
No trade-offs available.

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Server-Side Rendering (SSR)|Server-Side Rendering (SSR]], React Server Components (RSC), Total Blocking Time (TBT), [[Concurrent Rendering|Concurrent Rendering]]
- **Projects/Contexts:** [[Next.js App Router|Next.js App Router]], [[Island Architecture|Island Architecture]]
- **Contradictions/Notes:** SSR은 클라이언트에게 완성된 HTML을 즉시 제공하여 FCP(First Contentful Paint)와 SEO를 크게 향상시키지만, JavaScript 번들이 다운로드되고 Hydration이 완료될 때까지 사용자가 페이지와 상호작용할 수 없으므로 TTI(Time to Interactive)가 오히려 지연되는 성능적 트레이드오프(Trade-off)가 존재합니다 [20, 21].

---
*Last updated: 2026-04-25*

---

- **Related Topics:** [[React Server Components (RSC)|React Server Components (RSC]], Client Components, CSS-in-JS, [[styled-components|styled-components]]
- **Projects/Contexts:** [[Next.js App Router|Next.js App Router]], [[Server-Side Rendering (SSR)|Server-Side Rendering (SSR]]
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.

---
*Last updated: 2026-04-26*

---

- **Related Topics:** [[Server-Side Rendering (SSR)|Server-Side Rendering (SSR]], Client-Side Rendering (CSR), React Server Components (RSC), [[Time to Interactive (TTI)|Time to Interactive (TTI]], Total Blocking Time (TBT
- **Projects/Contexts:** [[Next.js|Next.js]], [[React 18|React 18]]
- **Contradictions/Notes:** SSR은 초기 콘텐츠 렌더링(FCP)이 빠르고 SEO에 유리하다는 큰 장점이 있지만, 하이드레이션 단계가 완료되기 전까지 애플리케이션의 상호작용이 지연된다는 뚜렷한 한계(트레이드오프)가 있습니다 [4, 24, 25]. 이 문제를 근본적으로 해결하기 위해 [[React 18|React 18]]은 동시성 렌더링을 통한 하이드레이션 청크 분할 및 사용자가 상호작용하는 부분을 우선순위로 두는 선택적 하이드레이션을 도입하였고 [26], [[React Server Components|React Server Components]]는 하이드레이션 단계를 완전히 제거하는 구조를 제시합니다 [21, 23].

---
*Last updated: 2026-04-25*

## 🤖 LLM 활용 힌트 (How to Use This Knowledge)

**언제 이 지식을 쓰는가:**
- *(TODO)*

**언제 쓰면 안 되는가:**
- *(TODO)*

## 🧪 검증 상태 (Validation)

- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*

## 🧬 중복 검사 (Duplicate Check)

- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

## 🕓 변경 이력 (Changelog)

| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |

## 💻 코드 패턴 (Code Patterns)

**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*

```text
# TODO
```

## 🤔 의사결정 기준 (Decision Criteria)

**선택 A를 써야 할 때:**
- *(TODO)*

**선택 B를 써야 할 때:**
- *(TODO)*

**기본값:**
> *(TODO)*

## ❌ 안티패턴 (Anti-Patterns)

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*