From d53665ae7a186033869b29a0c71ebe38a98dcedc Mon Sep 17 00:00:00 2001
From: Antigravity Agent <antigravity@gstack.com>
Date: Sat, 25 Apr 2026 23:02:04 +0900
Subject: [PATCH] chore: clean up placeholders and wikify real-time incoming
 knowledge

---
 ...��키텍처와 동시성 (Concurrent Rendering).md |  0
 .../Hydration 성능 최적화.md                  |  0
 .../React Fiber 및 동시성 렌더링.md           | 32 +++++++++++++++++
 ...M (Virtual DOM) 및 재조정(Reconciliation).md | 30 ++++++++++++++++
 .../가상 DOM과 재조정 (Reconciliation).md     |  0
 .../단일 페이지 애플리케이션 (SPA).md         |  0
 .../브라우저 렌더링 프로세스 (CRP).md         |  0
 .../성능 및 SEO 최적화 프로젝트.md            |  0
 .../웹 프론트엔드 아키텍처 설계.md            |  0
 ...요 렌더링 경로 (Critical Rendering Path).md |  0
 .../UI_UX_Assets/Hydration 성능 최적화.md     | 34 +++++++++++++++++++
 .../React Fiber 및 동시성 렌더링.md           | 32 +++++++++++++++++
 .../단일 페이지 애플리케이션 (SPA).md         | 18 ++++++++++
 .../브라우저 렌더링 프로세스 (CRP).md         | 21 ++++++++++++
 .../성능 및 SEO 최적화 프로젝트.md            | 28 +++++++++++++++
 ...요 렌더링 경로 (Critical Rendering Path).md | 23 +++++++++++++
 16 files changed, 218 insertions(+)
 rename {00_Raw => 10_Wiki/Topics/Frontend_Mastery}/Fiber 아키텍처와 동시성 (Concurrent Rendering).md (100%)
 rename {00_Raw => 10_Wiki/Topics/Frontend_Mastery}/Hydration 성능 최적화.md (100%)
 create mode 100644 10_Wiki/Topics/Frontend_Mastery/React Fiber 및 동시성 렌더링.md
 create mode 100644 10_Wiki/Topics/Frontend_Mastery/가상 DOM (Virtual DOM) 및 재조정(Reconciliation).md
 rename {00_Raw => 10_Wiki/Topics/Frontend_Mastery}/가상 DOM과 재조정 (Reconciliation).md (100%)
 rename {00_Raw => 10_Wiki/Topics/Frontend_Mastery}/단일 페이지 애플리케이션 (SPA).md (100%)
 rename {00_Raw => 10_Wiki/Topics/Frontend_Mastery}/브라우저 렌더링 프로세스 (CRP).md (100%)
 rename {00_Raw => 10_Wiki/Topics/Frontend_Mastery}/성능 및 SEO 최적화 프로젝트.md (100%)
 rename {00_Raw => 10_Wiki/Topics/Frontend_Mastery}/웹 프론트엔드 아키텍처 설계.md (100%)
 rename {00_Raw => 10_Wiki/Topics/Frontend_Mastery}/중요 렌더링 경로 (Critical Rendering Path).md (100%)
 create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/Hydration 성능 최적화.md
 create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/React Fiber 및 동시성 렌더링.md
 create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/단일 페이지 애플리케이션 (SPA).md
 create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/브라우저 렌더링 프로세스 (CRP).md
 create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/성능 및 SEO 최적화 프로젝트.md
 create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/중요 렌더링 경로 (Critical Rendering Path).md

diff --git a/00_Raw/Fiber 아키텍처와 동시성 (Concurrent Rendering).md b/10_Wiki/Topics/Frontend_Mastery/Fiber 아키텍처와 동시성 (Concurrent Rendering).md
similarity index 100%
rename from 00_Raw/Fiber 아키텍처와 동시성 (Concurrent Rendering).md
rename to 10_Wiki/Topics/Frontend_Mastery/Fiber 아키텍처와 동시성 (Concurrent Rendering).md
diff --git a/00_Raw/Hydration 성능 최적화.md b/10_Wiki/Topics/Frontend_Mastery/Hydration 성능 최적화.md
similarity index 100%
rename from 00_Raw/Hydration 성능 최적화.md
rename to 10_Wiki/Topics/Frontend_Mastery/Hydration 성능 최적화.md
diff --git a/10_Wiki/Topics/Frontend_Mastery/React Fiber 및 동시성 렌더링.md b/10_Wiki/Topics/Frontend_Mastery/React Fiber 및 동시성 렌더링.md
new file mode 100644
index 00000000..511cf74e
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/React Fiber 및 동시성 렌더링.md	
@@ -0,0 +1,32 @@
+# [[React Fiber 및 동시성 렌더링]]
+
+## 📌 Brief 시 Summary
+React Fiber는 동기식 렌더링의 한계를 극복하고 동시성 렌더링(Concurrent rendering)을 지원하기 위해 도입된 React의 재조정(Reconciliation) 엔진 아키텍처이다 [1, 2]. 전체 컴포넌트 트리를 단일 호출로 처리하던 기존 방식과 달리, 렌더링 작업을 '파이버 노드(Fiber node)'라는 작은 단위로 쪼개어 스케줄링한다 [3, 4]. 이를 통해 메인 스레드를 차단하지 않고 렌더링을 일시 정지하거나 재개할 수 있으며, 타자 입력이나 클릭과 같은 긴급한 업데이트를 우선적으로 처리하여 반응성 높은 UI를 제공할 수 있다 [3, 5, 6].
+
+## 📖 Core Content
+**도입 배경 및 문제점 해결**
+Fiber 아키텍처 이전의 React는 '스택 재조정자(Stack reconciler)'를 사용하여 전체 컴포넌트 트리를 한 번의 재귀 호출로 처리했다 [3]. 대규모 애플리케이션의 경우 이러한 방식은 메인 스레드를 16.6ms 이상 차단하여 UI의 애니메이션이나 사용자 입력 반응을 지연시키는 문제를 발생시켰다 [3]. React 16부터 도입된 Fiber는 렌더링을 완전히 재작성하여, 작업을 더 작은 청크로 나누고 여러 프레임에 걸쳐 분산할 수 있도록 설계되었다 [1, 4].
+
+**작업 루프(Work Loop)와 렌더링의 두 단계**
+React Fiber는 작업 루프를 통해 렌더링 단위를 점진적으로 처리하며, 전체 과정은 두 가지 주요 단계로 나뉜다 [4, 7].
+*   **렌더 단계(Render Phase):** 이 단계는 중단할 수 있으며(Interruptible), DOM 변경 없이 순수한 연산만 수행된다 [7]. React는 Fiber 트리를 순회하면서(`beginWork`, `completeWork`) 이전 상태와 새로운 상태를 비교한다 [7, 8]. 이때, 메인 스레드가 바쁘거나 우선순위가 높은 상호작용이 들어오면 작업을 일시 정지, 재개 또는 폐기(WIP, Work-In-Progress 관리)할 수 있다 [9]. 변경이 필요한 노드에는 이펙트 태그(Placement, Update, Deletion 등)가 지정되며 이펙트 목록(Effect list)이 만들어진다 [7, 10, 11]. 
+*   **커밋 단계(Commit Phase):** 이 단계는 동기적이고 중단 불가능(Uninterruptible)하다 [12]. 렌더 단계에서 생성된 이펙트 목록을 바탕으로 실제 DOM 변형이 이루어진다 [10, 12]. 이 단계는 DOM 변형 전(Before Mutation), 변형(Mutation), 레이아웃 이펙트(`useLayoutEffect` 실행), 패시브 이펙트(`useEffect` 실행) 순으로 처리된다 [13].
+
+**우선순위 스케줄링과 차선(Lane) 모델**
+Fiber는 '차선(Lanes)'이라고 불리는 비트마스크(Bitmask) 기반의 우선순위 시스템을 사용하여 동시성 작업을 관리한다 [11, 14]. 
+*   **우선순위 레벨:** 클릭이나 타이핑 등 즉각 반응이 필요한 작업은 Sync 레벨, 스크롤이나 호버는 InputContinuous, 네트워크 응답 등은 Default, 오프스크린 렌더링은 Idle 레벨로 구분된다 [5, 15].
+*   이를 통해 낮은 우선순위의 작업을 처리하는 중에도 우선순위가 높은 상호작용이 들어오면 실행 중인 작업을 멈추고 중요한 작업을 먼저 렌더링하게 된다 [6]. 
+
+**React 18 이후의 동시성 기능 활용**
+이러한 아키텍처를 기반으로 React 18 및 19에서는 개발자가 렌더링 우선순위를 직접 조정할 수 있는 동시성 훅을 제공한다. 
+*   `useTransition`: 특정 상태 업데이트를 낮은 우선순위로 지정하여, 무거운 필터링 작업이 진행되는 동안에도 타이핑 등의 긴급한 입력이 지연되지 않도록 한다 [16, 17]. 
+*   `useDeferredValue`: 외부에서 전달받은 값의 소비를 지연시켜 무거운 렌더링 중에 UI가 동결되는 것을 막는다 [17, 18].
+*   또한 동시성 렌더링은 클라이언트의 Hydration 과정에서도 메인 스레드를 심하게 막지 않고 작은 청크로 쪼개어 렌더링할 수 있도록 돕는다 [19].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Reconciliation]], [[Virtual DOM]], [[Time-Slicing]], [[Hydration]]
+- **Projects/Contexts:** [[React 18 Concurrent Features]], [[useTransition 및 useDeferredValue]]
+- **Contradictions/Notes:** 제공된 소스 전반에 걸쳐 Fiber 아키텍처와 동시성 렌더링의 매커니즘, 장점에 대해 일관된 설명을 제공하고 있으며, 상충되는 의견은 존재하지 않습니다. 
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/가상 DOM (Virtual DOM) 및 재조정(Reconciliation).md b/10_Wiki/Topics/Frontend_Mastery/가상 DOM (Virtual DOM) 및 재조정(Reconciliation).md
new file mode 100644
index 00000000..f590f355
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/가상 DOM (Virtual DOM) 및 재조정(Reconciliation).md	
@@ -0,0 +1,30 @@
+# [[가상 DOM (Virtual DOM) 및 재조정(Reconciliation)]]
+
+## 📌 Brief Summary
+가상 DOM(Virtual DOM)은 메모리 상에 사용자 인터페이스(UI) 요소들을 일반 자바스크립트 객체 형태로 가볍게 표현한 개념입니다 [1, 2]. 재조정(Reconciliation)은 React가 변경 사항을 감지하기 위해 새로 생성된 가상 DOM과 이전 버전의 가상 DOM을 비교(diff)하여, 실제 DOM을 가장 효율적인 방식으로 업데이트하는 프로세스를 의미합니다 [1-3]. 이 방식을 통해 개발자는 선언적 API를 사용하여 UI의 상태만 정의하면 되며, 수동적인 DOM 조작과 이로 인해 발생하는 렌더링 비효율성을 신경 쓰지 않아도 됩니다 [1, 3, 4].
+
+## 📖 Core Content
+
+*   **가상 DOM의 필요성과 역할**
+    실제 DOM을 직접 수정하는 작업은 브라우저의 레이아웃(Reflow) 및 페인트(Repaint) 단계를 매번 유발하기 때문에 본질적으로 느립니다 [1, 5]. React는 가상 DOM이라는 메모리 상의 이상적인 UI 표현을 유지하며, 이를 통해 선언된 상태와 실제 DOM이 일치하도록 최소한의 업데이트만 수행하여 렌더링을 최적화합니다 [1, 3]. 설계상 가상 DOM 트리는 불변(immutable) 객체로 취급됩니다 [6].
+
+*   **휴리스틱 Diff 알고리즘과 $O(n)$ 최적화**
+    두 개의 트리를 비교하여 최소한의 연산으로 변환하는 일반적인 알고리즘은 $O(n^3)$의 시간 복잡도를 가지므로, 요소가 많은 실제 애플리케이션에 적용하기에는 비용이 너무 큽니다 [7, 8]. 이에 React는 다음 두 가지 가정을 바탕으로 $O(n)$ 복잡도로 동작하는 휴리스틱 기반의 diff 알고리즘을 사용합니다 [7, 8].
+    1.  **다른 타입의 요소**: 루트 요소의 타입이 다르면(예: `<a>`에서 `<img>`로 변경), React는 이전 트리를 완전히 파괴하고 새로운 트리를 처음부터 구축합니다 [7, 9]. 반면, 같은 타입의 DOM 요소인 경우에는 유지하면서 변경된 속성(예: className이나 특정 style)만 업데이트합니다 [10].
+    2.  **Key 속성**: 여러 번의 렌더링 사이에서 리스트 내의 어떤 자식 요소가 안정적으로 유지되는지 식별하기 위해 `key` 속성을 사용합니다 [7, 8]. 자식 요소의 순서가 변경되거나 추가될 때 `key`를 활용하면 기존 하위 트리를 파괴하지 않고 요소의 이동만으로 트리를 효율적으로 재구성할 수 있습니다 [11, 12].
+
+*   **React Fiber와 점진적 재조정(Incremental Reconciliation)**
+    React 16부터는 기존의 동기식 차단(synchronous blocking) 문제를 해결하고 동시성 렌더링(concurrent rendering)을 지원하기 위해, 재조정 엔진을 완전히 재작성한 'Fiber 아키텍처'를 도입했습니다 [13-15]. Fiber 기반의 재조정 과정은 크게 두 단계로 나뉩니다.
+    1.  **렌더 단계(Render phase)**: DOM을 조작하지 않는 순수한 연산 과정으로, 중단이나 취소, 재시작이 가능합니다. 이 단계에서는 Fiber 트리를 순회하며 이전 상태와 새로운 상태의 차이를 계산하고, 업데이트나 삽입 등 변화가 필요한 요소들의 효과 목록(effect list)을 구축합니다 [16].
+    2.  **커밋 단계(Commit phase)**: 렌더 단계와 달리 동기적으로 작동하며 중단할 수 없습니다. 구축된 효과 목록을 바탕으로 모든 변경 사항과 실제 DOM 조작(삽입, 삭제, 속성 업데이트)을 한 번에 적용합니다 [17].
+
+*   **재조정 알고리즘의 트레이드오프**
+    재조정 알고리즘은 휴리스틱에 의존하기 때문에 주어진 가정이 충족되지 않으면 성능이 저하될 수 있습니다 [18]. 예를 들어, 하위 트리가 형제 요소 사이에서 이동한 것은 파악할 수 있지만, 트리 내의 완전히 다른 위치로 이동한 것은 인식하지 못해 전체 하위 트리를 다시 렌더링하게 됩니다 [19]. 또한 인덱스를 `key`로 사용하거나 예측 불가능한 불안정한 키를 사용할 경우, 불필요한 DOM 노드 및 컴포넌트 재생성으로 인해 성능 저하와 자식 컴포넌트의 상태 손실이 발생할 수 있습니다 [18, 20].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[React Fiber 아키텍처]], [[브라우저 렌더링 과정 (Critical Rendering Path)]], [[Reflow 및 Repaint]]
+- **Projects/Contexts:** [[프론트엔드 기초 구조 이해 핵심 목적]]
+- **Contradictions/Notes:** 소스 자료에 따르면, 두 트리를 비교하는 완벽한 트리 변환 알고리즘은 이론적으로 $O(n^3)$의 복잡도를 요구하여 브라우저에서 실행하기 어렵습니다. 하지만 React는 '타입(Type)'과 '키(Key)'라는 두 가지 단순하고 강력한 가정만으로 알고리즘 복잡도를 $O(n)$으로 극적으로 줄임으로써 빠른 성능을 확보했습니다 [7, 8, 21].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/00_Raw/가상 DOM과 재조정 (Reconciliation).md b/10_Wiki/Topics/Frontend_Mastery/가상 DOM과 재조정 (Reconciliation).md
similarity index 100%
rename from 00_Raw/가상 DOM과 재조정 (Reconciliation).md
rename to 10_Wiki/Topics/Frontend_Mastery/가상 DOM과 재조정 (Reconciliation).md
diff --git a/00_Raw/단일 페이지 애플리케이션 (SPA).md b/10_Wiki/Topics/Frontend_Mastery/단일 페이지 애플리케이션 (SPA).md
similarity index 100%
rename from 00_Raw/단일 페이지 애플리케이션 (SPA).md
rename to 10_Wiki/Topics/Frontend_Mastery/단일 페이지 애플리케이션 (SPA).md
diff --git a/00_Raw/브라우저 렌더링 프로세스 (CRP).md b/10_Wiki/Topics/Frontend_Mastery/브라우저 렌더링 프로세스 (CRP).md
similarity index 100%
rename from 00_Raw/브라우저 렌더링 프로세스 (CRP).md
rename to 10_Wiki/Topics/Frontend_Mastery/브라우저 렌더링 프로세스 (CRP).md
diff --git a/00_Raw/성능 및 SEO 최적화 프로젝트.md b/10_Wiki/Topics/Frontend_Mastery/성능 및 SEO 최적화 프로젝트.md
similarity index 100%
rename from 00_Raw/성능 및 SEO 최적화 프로젝트.md
rename to 10_Wiki/Topics/Frontend_Mastery/성능 및 SEO 최적화 프로젝트.md
diff --git a/00_Raw/웹 프론트엔드 아키텍처 설계.md b/10_Wiki/Topics/Frontend_Mastery/웹 프론트엔드 아키텍처 설계.md
similarity index 100%
rename from 00_Raw/웹 프론트엔드 아키텍처 설계.md
rename to 10_Wiki/Topics/Frontend_Mastery/웹 프론트엔드 아키텍처 설계.md
diff --git a/00_Raw/중요 렌더링 경로 (Critical Rendering Path).md b/10_Wiki/Topics/Frontend_Mastery/중요 렌더링 경로 (Critical Rendering Path).md
similarity index 100%
rename from 00_Raw/중요 렌더링 경로 (Critical Rendering Path).md
rename to 10_Wiki/Topics/Frontend_Mastery/중요 렌더링 경로 (Critical Rendering Path).md
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/Hydration 성능 최적화.md b/10_Wiki/Topics_Art/UI_UX_Assets/Hydration 성능 최적화.md
new file mode 100644
index 00000000..05a683d4
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/Hydration 성능 최적화.md	
@@ -0,0 +1,34 @@
+# [[Hydration 성능 최적화]]
+
+## 📌 Brief Summary
+Hydration은 서버에서 렌더링된 정적 HTML 뼈대에 JavaScript를 실행하고 이벤트 리스너를 연결하여 완전한 상호작용이 가능한 애플리케이션으로 변환하는 과정입니다 [1, 2]. 기본적으로 React는 페이지 전체를 한 번에 Hydration하면서 메인 스레드를 차단하여 TBT(Total Blocking Time)와 TTI(Time to Interactive) 지표를 악화시킬 수 있습니다 [3]. 이를 해결하기 위해 선택적 Hydration, 지연 로딩, React Server Components(RSC) 등의 최적화 기법을 도입하여 초기 로드 성능과 상호작용성을 극대화할 수 있습니다 [4-6].
+
+## 📖 Core 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/dynamic`을 활용한 동적 임포트(Dynamic Imports)를 통해 구현하거나, IntersectionObserver API를 사용하여 요소가 뷰포트에 들어올 때만 Hydration을 수행하는 지연(Lazy) 방식을 적용할 수 있습니다 [5, 9]. 이를 통해 메인 스레드 차단을 분산시켜 TBT를 최대 40%까지 줄일 수 있습니다 [5].
+
+*   **React Server Components (RSC)의 활용:**
+    *   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의 동시성 렌더링(Concurrent Rendering)은 Hydration 작업을 작은 청크로 쪼개어 브라우저가 사용자 입력을 처리할 수 있도록 양보(yield)하는 기능을 제공합니다 [15].
+
+*   **부분 Hydration (Partial Hydration) 및 기타 팁:**
+    *   정적인 콘텐츠 영역을 고립시키고 상호작용이 필요한 특정 부분만 Hydration하는 섬 아키텍처(Island Architecture)를 도입하거나, 절대적으로 정적인 콘텐츠의 경우 `dangerouslySetInnerHTML`을 사용하여 통째로 Hydration 과정에서 배제하는 것도 유용한 전략입니다 [16-18].
+    *   불가피하게 클라이언트와 서버 간의 렌더링 불일치가 예상되는 곳에는 `suppressHydrationWarning`을 제한적으로 사용하거나, Hydration 완료 이후에 동작해야 하는 로직을 의존성 배열이 빈 `useEffect` 내에 배치하여 불일치 에러를 방지할 수 있습니다 [17, 19].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Server-Side Rendering (SSR)]], [[React Server Components (RSC)]], [[Total Blocking Time (TBT)]], [[Concurrent Rendering]]
+- **Projects/Contexts:** [[Next.js App Router]], [[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*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/React Fiber 및 동시성 렌더링.md b/10_Wiki/Topics_Art/UI_UX_Assets/React Fiber 및 동시성 렌더링.md
new file mode 100644
index 00000000..511cf74e
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/React Fiber 및 동시성 렌더링.md	
@@ -0,0 +1,32 @@
+# [[React Fiber 및 동시성 렌더링]]
+
+## 📌 Brief 시 Summary
+React Fiber는 동기식 렌더링의 한계를 극복하고 동시성 렌더링(Concurrent rendering)을 지원하기 위해 도입된 React의 재조정(Reconciliation) 엔진 아키텍처이다 [1, 2]. 전체 컴포넌트 트리를 단일 호출로 처리하던 기존 방식과 달리, 렌더링 작업을 '파이버 노드(Fiber node)'라는 작은 단위로 쪼개어 스케줄링한다 [3, 4]. 이를 통해 메인 스레드를 차단하지 않고 렌더링을 일시 정지하거나 재개할 수 있으며, 타자 입력이나 클릭과 같은 긴급한 업데이트를 우선적으로 처리하여 반응성 높은 UI를 제공할 수 있다 [3, 5, 6].
+
+## 📖 Core Content
+**도입 배경 및 문제점 해결**
+Fiber 아키텍처 이전의 React는 '스택 재조정자(Stack reconciler)'를 사용하여 전체 컴포넌트 트리를 한 번의 재귀 호출로 처리했다 [3]. 대규모 애플리케이션의 경우 이러한 방식은 메인 스레드를 16.6ms 이상 차단하여 UI의 애니메이션이나 사용자 입력 반응을 지연시키는 문제를 발생시켰다 [3]. React 16부터 도입된 Fiber는 렌더링을 완전히 재작성하여, 작업을 더 작은 청크로 나누고 여러 프레임에 걸쳐 분산할 수 있도록 설계되었다 [1, 4].
+
+**작업 루프(Work Loop)와 렌더링의 두 단계**
+React Fiber는 작업 루프를 통해 렌더링 단위를 점진적으로 처리하며, 전체 과정은 두 가지 주요 단계로 나뉜다 [4, 7].
+*   **렌더 단계(Render Phase):** 이 단계는 중단할 수 있으며(Interruptible), DOM 변경 없이 순수한 연산만 수행된다 [7]. React는 Fiber 트리를 순회하면서(`beginWork`, `completeWork`) 이전 상태와 새로운 상태를 비교한다 [7, 8]. 이때, 메인 스레드가 바쁘거나 우선순위가 높은 상호작용이 들어오면 작업을 일시 정지, 재개 또는 폐기(WIP, Work-In-Progress 관리)할 수 있다 [9]. 변경이 필요한 노드에는 이펙트 태그(Placement, Update, Deletion 등)가 지정되며 이펙트 목록(Effect list)이 만들어진다 [7, 10, 11]. 
+*   **커밋 단계(Commit Phase):** 이 단계는 동기적이고 중단 불가능(Uninterruptible)하다 [12]. 렌더 단계에서 생성된 이펙트 목록을 바탕으로 실제 DOM 변형이 이루어진다 [10, 12]. 이 단계는 DOM 변형 전(Before Mutation), 변형(Mutation), 레이아웃 이펙트(`useLayoutEffect` 실행), 패시브 이펙트(`useEffect` 실행) 순으로 처리된다 [13].
+
+**우선순위 스케줄링과 차선(Lane) 모델**
+Fiber는 '차선(Lanes)'이라고 불리는 비트마스크(Bitmask) 기반의 우선순위 시스템을 사용하여 동시성 작업을 관리한다 [11, 14]. 
+*   **우선순위 레벨:** 클릭이나 타이핑 등 즉각 반응이 필요한 작업은 Sync 레벨, 스크롤이나 호버는 InputContinuous, 네트워크 응답 등은 Default, 오프스크린 렌더링은 Idle 레벨로 구분된다 [5, 15].
+*   이를 통해 낮은 우선순위의 작업을 처리하는 중에도 우선순위가 높은 상호작용이 들어오면 실행 중인 작업을 멈추고 중요한 작업을 먼저 렌더링하게 된다 [6]. 
+
+**React 18 이후의 동시성 기능 활용**
+이러한 아키텍처를 기반으로 React 18 및 19에서는 개발자가 렌더링 우선순위를 직접 조정할 수 있는 동시성 훅을 제공한다. 
+*   `useTransition`: 특정 상태 업데이트를 낮은 우선순위로 지정하여, 무거운 필터링 작업이 진행되는 동안에도 타이핑 등의 긴급한 입력이 지연되지 않도록 한다 [16, 17]. 
+*   `useDeferredValue`: 외부에서 전달받은 값의 소비를 지연시켜 무거운 렌더링 중에 UI가 동결되는 것을 막는다 [17, 18].
+*   또한 동시성 렌더링은 클라이언트의 Hydration 과정에서도 메인 스레드를 심하게 막지 않고 작은 청크로 쪼개어 렌더링할 수 있도록 돕는다 [19].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Reconciliation]], [[Virtual DOM]], [[Time-Slicing]], [[Hydration]]
+- **Projects/Contexts:** [[React 18 Concurrent Features]], [[useTransition 및 useDeferredValue]]
+- **Contradictions/Notes:** 제공된 소스 전반에 걸쳐 Fiber 아키텍처와 동시성 렌더링의 매커니즘, 장점에 대해 일관된 설명을 제공하고 있으며, 상충되는 의견은 존재하지 않습니다. 
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/단일 페이지 애플리케이션 (SPA).md b/10_Wiki/Topics_Art/UI_UX_Assets/단일 페이지 애플리케이션 (SPA).md
new file mode 100644
index 00000000..f74ae4c6
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/단일 페이지 애플리케이션 (SPA).md	
@@ -0,0 +1,18 @@
+# [[단일 페이지 애플리케이션 (SPA)]]
+
+## 📌 Brief Summary
+단일 페이지 애플리케이션(SPA)은 서버에서 라우트마다 완전한 HTML을 받아오는 대신, 클라이언트 사이드 렌더링(CSR)을 활용하여 브라우저 내에서 콘텐츠를 동적으로 생성하는 웹 애플리케이션입니다 [1-3]. 초기 로드 시 필요한 모든 HTML, CSS 및 자바스크립트 파일을 다운로드하며, 그 이후부터는 서버를 통한 전체 페이지 새로고침 없이 사용자의 상호작용을 처리합니다 [4]. 이를 통해 사용자에게 페이지 전환이 즉각적으로 이루어지는 매끄러운 '앱과 같은(app-like)' 경험을 제공합니다 [1, 4].
+
+## 📖 Core Content
+* **작동 방식:** SPA는 서버로부터 기본 구조만 갖춘 최소한의 HTML 템플릿과 자바스크립트 번들을 전달받습니다 [1-3]. 이후 자바스크립트가 문서의 제어권을 넘겨받아 브라우저 내에서 각 라우트를 동적으로 생성하고 데이터를 채워 넣습니다 [2, 3]. 
+* **성능 및 사용자 경험 측면의 장점:** SPA는 페이지를 새로고침할 때 발생하는 끊김 현상을 제거하여 매우 유동적이고 반응성이 뛰어난 사용자 경험을 제공합니다 [4, 5]. 또한 렌더링 작업을 클라이언트로 넘기므로 서버 부하가 감소하며, 복잡한 자바스크립트 런타임 서버 없이 정적 서버(Amazon S3, Netlify 등)에 호스팅할 수 있어 비용 효율적입니다 [5, 6].
+* **초기 로딩 및 SEO의 한계:** 브라우저가 자바스크립트를 모두 다운로드하고 구문 분석 및 실행을 완료하기 전까지는 의미 있는 콘텐츠가 화면에 나타나지 않으므로 초기 로드 시간(First Contentful Paint)이 느리다는 단점이 있습니다 [1, 7]. 또한, 빈 HTML 껍데기만 먼저 전송되기 때문에 일부 검색 엔진 크롤러가 콘텐츠를 제대로 읽지 못해 검색 엔진 최적화(SEO)에 불리할 수 있습니다 [1, 7, 8]. 사용자 기기의 컴퓨팅 성능에 따라 렌더링 성능이 크게 좌우되기도 합니다 [9].
+* **이상적인 활용 사례:** SEO가 우선순위가 아니며 복잡하고 풍부한 사용자 상호작용이 필수적인 애플리케이션에 매우 적합합니다 [10]. 주로 로그인 장벽 뒤에 있는 내부 비즈니스 도구, 실시간 데이터가 업데이트되는 사용자 대시보드, SaaS 플랫폼 등에서 이상적으로 활용됩니다 [5, 10].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[클라이언트 사이드 렌더링 (CSR)]], [[검색 엔진 최적화 (SEO)]], [[초기 로드 시간 (Initial Load Time)]]
+- **Projects/Contexts:** [[SaaS 플랫폼 및 인터랙티브 대시보드 개발]]
+- **Contradictions/Notes:** 소스에 따르면 SPA의 핵심인 CSR 방식은 상호작용성과 개발 속도 면에서 뛰어나지만 SEO와 초기 로드 시간에서는 뚜렷한 한계를 보입니다. 이러한 단점은 서버 사이드 렌더링(SSR)이나 정적 사이트 생성(SSG)이 갖는 장점(빠른 초기 화면 및 SEO 최적화)과 정확히 대조됩니다 [1, 7, 8, 11].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/브라우저 렌더링 프로세스 (CRP).md b/10_Wiki/Topics_Art/UI_UX_Assets/브라우저 렌더링 프로세스 (CRP).md
new file mode 100644
index 00000000..7fb91638
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/브라우저 렌더링 프로세스 (CRP).md	
@@ -0,0 +1,21 @@
+# [[브라우저 렌더링 프로세스 (CRP)]]
+
+## 📌 Brief Summary
+브라우저 렌더링 프로세스, 즉 중요 렌더링 경로(Critical Rendering Path, CRP)는 브라우저가 HTML, CSS, JavaScript를 화면의 픽셀로 변환하기 위해 실행하는 일련의 단계입니다 [1, 2]. 이 과정은 DOM 및 CSSOM 트리 생성, 렌더 트리 합성, 레이아웃(Reflow) 계산, 그리고 화면에 픽셀을 그리는 페인트(Paint) 및 합성(Composite) 단계로 구성됩니다 [2, 3]. 이 경로를 최적화하는 것은 첫 렌더링 시간을 단축하고, 원활한 사용자 상호작용을 보장하며 성능 병목현상을 피하기 위한 프론트엔드 엔지니어링의 핵심 목표입니다 [1, 4].
+
+## 📖 Core Content
+브라우저 렌더링 프로세스는 코드가 화면의 시각적 요소로 변환되는 과정으로, 다음과 같은 핵심 단계들을 거칩니다:
+
+*   **문서 객체 모델(DOM) 구축:** 브라우저가 서버로부터 HTML 데이터를 수신하면, 바이트를 문자, 토큰, 노드로 순차적으로 변환하여 계층적인 DOM 트리를 구성합니다 [1, 5]. 이 DOM 구축은 점진적으로 진행되므로 브라우저는 네트워크 요청이 활성화된 상태에서도 트리를 구축할 수 있습니다 [1, 6]. 그러나 노드 수가 많아질수록 이후의 렌더링 단계에서 더 많은 계산 시간이 소요됩니다 [6, 7].
+*   **CSS 객체 모델(CSSOM) 구축:** CSS는 콘텐츠가 어떻게 스타일링될지 정의합니다. DOM 구축과 달리 CSSOM 구축은 점진적이지 않으며 렌더링을 차단(render-blocking)하는 작업입니다 [6, 7]. 브라우저는 스타일이 적용되지 않은 콘텐츠가 화면에 노출되는 현상(FOUC)을 방지하기 위해 연결된 모든 스타일시트를 다운로드하고 파싱할 때까지 렌더 트리를 빌드하지 않습니다 [6, 7]. 
+*   **렌더 트리(Render Tree) 합성:** DOM과 CSSOM이 모두 준비되면 브라우저는 두 트리를 결합하여 렌더 트리를 만듭니다 [8, 9]. 이 트리는 화면에 렌더링하는 데 필요한 노드만 포함하므로, `<script>`, `<meta>` 태그나 CSS에서 `display: none`으로 설정된 요소는 렌더 트리에 포함되지 않습니다 [8-10].
+*   **레이아웃(Layout) 또는 리플로우(Reflow):** 렌더 트리가 구성되면 브라우저는 기기의 뷰포트 크기와 박스 모델을 기반으로 각 시각적 요소의 정확한 위치와 치수(너비, 높이 등)를 계산합니다 [11-13]. 화면 크기 조정이나 DOM의 추가/삭제와 같은 변경이 일어나면 페이지 전체의 레이아웃을 다시 계산해야 하며 이를 리플로우(Reflow)라고 부르는데, 이는 계산 비용이 매우 높습니다 [11, 14, 15].
+*   **페인트(Paint) 및 합성(Compositing):** 레이아웃 계산이 완료되면 기하학적 구조와 스타일을 바탕으로 브라우저는 화면의 픽셀을 채우는 페인트(Repaint) 단계를 거칩니다 [16-18]. 색상, 그림자 등의 시각적 속성을 업데이트하는 페인트 작업은 리플로우보다는 자원 소모가 덜하지만 과도하게 발생하면 성능에 영향을 줍니다 [19, 20]. 마지막으로 여러 레이어를 단일 이미지로 결합하는 합성(Compositing) 단계를 거치며, 최신 브라우저들은 렌더링 성능 최적화를 위해 특정 작업들을 GPU(그래픽 처리 장치)로 오프로드합니다 [16, 21].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[DOM 및 CSSOM]], [[Reflow 및 Repaint]], [[Virtual DOM]], [[렌더링 차단 리소스(Render-blocking resources)]]
+- **Projects/Contexts:** [[프론트엔드 성능 최적화(Frontend Performance Optimization)]], [[단일 페이지 애플리케이션(SPA) 렌더링 설계]]
+- **Contradictions/Notes:** 주어진 소스들 간에 렌더링 과정과 관련하여 기술적인 모순은 없으나, 최적화의 우선순위 측면에서 단순히 페인트(Paint) 시간을 줄이는 미세한 CSS 선택자 성능 최적화보다는 레이아웃(Reflow) 발생을 최소화하거나 불필요한 DOM 노드를 줄이는 것이 훨씬 큰 성능 향상을 가져온다는 점을 주의해야 합니다 [14, 17, 22].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/성능 및 SEO 최적화 프로젝트.md b/10_Wiki/Topics_Art/UI_UX_Assets/성능 및 SEO 최적화 프로젝트.md
new file mode 100644
index 00000000..3905939a
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/성능 및 SEO 최적화 프로젝트.md	
@@ -0,0 +1,28 @@
+# [[성능 및 SEO 최적화 프로젝트]]
+
+## 📌 Brief Summary
+성능 및 SEO 최적화 프로젝트는 애플리케이션의 초기 로드 속도와 반응성을 개선하고 검색 엔진 크롤러에 대한 접근성을 높여 최적의 사용자 경험과 비즈니스 성과를 달성하기 위한 목적을 가집니다. 브라우저의 중요 렌더링 경로(CRP)를 이해하여 불필요한 Reflow와 Repaint를 최소화하며, 프로젝트의 성격에 맞게 CSR, SSR, SSG, ISR 등 적절한 웹 렌더링 전략을 선택하는 것이 중요합니다. 더불어, React 기반 애플리케이션에서는 Virtual DOM과 Fiber 아키텍처, 자동 배칭(Automatic Batching), React Compiler 및 React Server Components(RSC)를 활용하여 렌더링 효율성을 극대화하고 JavaScript 번들 크기를 줄이는 최적화 작업을 수행합니다.
+
+## 📖 Core Content
+**브라우저 렌더링 메커니즘과 렌더링 최적화**
+* **중요 렌더링 경로 (Critical Rendering Path, CRP):** 브라우저가 HTML, CSS, JavaScript를 화면의 픽셀로 변환하는 과정입니다 [1, 2]. HTML을 파싱하여 DOM을 만들고 CSS를 파싱하여 CSSOM을 생성한 후, 두 개를 결합하여 화면에 보일 요소만 담은 렌더 트리(Render Tree)를 구성합니다 [2-4]. 이후 각 요소의 크기와 위치를 계산하는 Layout(Reflow) 단계와 화면에 실제 픽셀을 그리는 Paint(Repaint) 단계를 거칩니다 [5-8].
+* **Reflow 및 Repaint 최소화:** DOM 노드의 추가/제거나 요소의 크기 및 위치(width, height, margin 등)를 변경하면 막대한 비용이 드는 Reflow가 발생합니다 [9-11]. 성능 최적화를 위해서는 불필요한 DOM 깊이를 줄이고, 레이아웃 계산을 피할 수 있도록 `position: absolute`나 `position: fixed`를 사용하며, 애니메이션에는 Reflow를 유발하지 않는 `transform` 속성을 사용해야 합니다 [12-14].
+
+**전략적 웹 렌더링 방식 (CSR, SSR, SSG, ISR)**
+* **CSR (Client-Side Rendering):** 서버에서 빈 HTML 뼈대와 자바스크립트를 보내고 브라우저가 모든 렌더링을 처리합니다. 페이지 전환이 부드럽고 상호작용성이 뛰어나지만, 초기에 화면이 비어 있어 FCP(First Contentful Paint)가 늦고 검색 엔진 최적화(SEO)에 불리합니다 [15-19].
+* **SSR (Server-Side Rendering):** 요청 시 서버에서 완전한 HTML을 렌더링하여 클라이언트에 제공합니다. 검색 엔진이 즉시 콘텐츠를 읽을 수 있어 SEO에 탁월하고 초기 화면을 빠르게 띄울 수 있습니다 [20-23]. 단, 자바스크립트가 다운로드되어 이벤트를 연결하는 하이드레이션(Hydration) 단계가 완료될 때까지 상호작용(TTI, Time to Interactive)이 지연될 수 있습니다 [20, 24-26].
+* **SSG (Static Site Generation) 및 ISR (Incremental Static Regeneration):** SSG는 빌드 타임에 HTML을 생성하여 CDN으로 배포하므로 로딩 속도와 SEO 측면에서 최상의 성능을 냅니다 [27-29]. ISR은 SSG의 성능을 유지하면서도 설정된 주기마다 백그라운드에서 페이지를 업데이트하여 최신 콘텐츠를 제공하는 하이브리드 방식입니다 [27, 30-32].
+
+**React 아키텍처를 통한 렌더링 최적화 전략**
+* **Virtual DOM과 Reconciliation:** React는 메모리상에 가상의 DOM을 유지하고, 상태 변경 시 O(n) 복잡도를 갖는 휴리스틱 Diffing 알고리즘을 통해 이전 트리와 변경된 트리를 비교하여 실제 DOM에는 변경된 부분만 최소한으로 업데이트합니다 [33-36].
+* **Fiber 아키텍처와 동시성 렌더링 (Concurrent Rendering):** React 16부터 도입된 Fiber는 렌더링 작업을 중단하고 재개할 수 있는 작은 '작업 단위'로 나눕니다 [37-39]. 사용자 입력과 같은 긴급한 작업을 우선 처리하는 우선순위 라인(Priority Lanes)과 Time Slicing 기술을 활용하여 무거운 연산 중에도 UI가 멈추지 않고 반응성을 유지하도록 돕습니다 [38, 40-43].
+* **자동 배칭과 React Compiler:** React 18의 자동 배칭(Automatic Batching)은 여러 번의 상태 업데이트를 묶어 한 번의 리렌더링만 발생하도록 하여 불필요한 렌더링을 줄입니다 [44-47]. 나아가 React 19의 React Compiler는 빌드 타임에 코드를 분석해 `useMemo`나 `useCallback`과 같은 수동 처리 없이도 자동으로 최적화된 메모이제이션을 삽입하여 개발자의 인지적 부담과 성능 이슈를 동시에 해결합니다 [48-51].
+* **React Server Components (RSC):** RSC는 클라이언트로 다운로드되는 자바스크립트 번들에 포함되지 않고 전적으로 서버에서 실행됩니다 [52, 53]. 하이드레이션 과정을 생략할 수 있어 클라이언트가 부담해야 할 번들 크기를 제로(Zero)에 가깝게 만들며, 서버에 직접 접근해 효율적으로 데이터를 패칭할 수 있어 초기 로드와 상호작용 속도를 모두 개선합니다 [53-57].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Critical Rendering Path]], [[Reflow와 Repaint]], [[Server-Side Rendering (SSR)]], [[Virtual DOM과 Reconciliation]], [[React Server Components (RSC)]]
+- **Projects/Contexts:** [[대규모 콘텐츠 기반 애플리케이션 및 전자상거래 플랫폼 구축]], [[프론트엔드 성능 최적화 및 SEO 개선 프로젝트]]
+- **Contradictions/Notes:** 클라이언트 사이드 렌더링(CSR)은 로드 후 동적 상호작용에는 강점이 있으나 초기 FCP 저하 및 SEO 크롤링 측면에서 불리합니다. 반대로 서버 사이드 렌더링(SSR)은 뛰어난 SEO 및 초기 화면 노출을 보장하지만, 하이드레이션(Hydration) 병목으로 인해 TTI(Time to Interactive)가 지연되어 사용자가 버튼을 클릭해도 즉시 반응하지 않는 현상이 발생할 수 있다는 렌더링 방식 간의 명확한 트레이드오프가 존재합니다 [15, 20, 25, 58, 59].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/중요 렌더링 경로 (Critical Rendering Path).md b/10_Wiki/Topics_Art/UI_UX_Assets/중요 렌더링 경로 (Critical Rendering Path).md
new file mode 100644
index 00000000..6a3e90c3
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/중요 렌더링 경로 (Critical Rendering Path).md	
@@ -0,0 +1,23 @@
+# [[중요 렌더링 경로 (Critical Rendering Path)]]
+
+## 📌 Brief Summary
+중요 렌더링 경로(Critical Rendering Path, CRP)는 브라우저가 HTML, CSS, JavaScript 코드를 수신하여 화면의 픽셀로 변환하기까지 거치는 일련의 필수 단계를 의미합니다 [1, 2]. 이 경로는 문서 객체 모델(DOM), CSS 객체 모델(CSSOM) 생성부터 렌더 트리 구축, 레이아웃, 그리고 페인트 단계까지 포함합니다 [2]. 중요 렌더링 경로의 과정을 최적화하면 웹 페이지의 첫 렌더링 시간(Time to First Render)을 단축하고 사용자 상호작용의 지연을 막을 수 있습니다 [1, 3].
+
+## 📖 Core Content
+브라우저는 웹 페이지를 화면에 렌더링하기 위해 다음의 순차적인 단계들을 실행합니다:
+
+* **DOM(Document Object Model) 트리 구축**: 브라우저가 서버로부터 HTML 응답을 받으면 데이터를 바이트에서 문자, 토큰, 노드로 변환하며 점진적으로 DOM 트리를 구축합니다 [1, 4, 5]. DOM은 문서의 구조와 콘텐츠 전체를 담고 있습니다 [6, 7].
+* **CSSOM(CSS Object Model) 트리 구축**: DOM과 유사하게 CSS 규칙들을 파싱하여 CSSOM을 만듭니다 [6, 7]. 다만 CSSOM은 후속 규칙이 이전 스타일을 덮어쓸 수 있기 때문에 점진적으로 구축될 수 없으며, 처리가 완료될 때까지 화면 렌더링을 차단(Render-blocking)합니다 [7, 8].
+* **렌더 트리(Render Tree) 결합**: 브라우저는 DOM과 CSSOM을 결합하여 실제로 화면에 렌더링될 요소들만을 포함하는 렌더 트리를 만듭니다 [9, 10]. 이 단계에서 `<head>` 태그나 `display: none` 속성이 적용된 비가시적 요소는 렌더 트리에서 제외됩니다 [10, 11].
+* **레이아웃(Layout) 또는 리플로우(Reflow)**: 렌더 트리가 준비되면 뷰포트(Viewport) 크기를 기준으로 각 요소의 정확한 위치와 기하학적 크기(너비, 높이 등)를 계산합니다 [12-14]. 화면 크기가 변하거나 DOM 노드가 추가/수정될 때마다 레이아웃이 다시 발생할 수 있습니다 [15, 16].
+* **페인트(Paint) 및 합성(Compositing)**: 레이아웃 계산을 마치면 브라우저는 요소의 텍스트, 색상, 그림자 등을 화면의 실제 픽셀로 그리는 페인트 단계를 거칩니다 [17-19]. 페이지 구성 요소가 여러 레이어로 나뉘어 있는 경우, 이를 GPU 등을 활용해 올바른 순서로 화면에 병합하는 합성(Compositing) 작업이 수행됩니다 [17, 20].
+
+웹 성능을 최적화하기 위해서는 이 경로상에 있는 차단 리소스(예: 렌더링 차단 CSS나 파서 차단 동기식 JavaScript)의 수와 크기를 최소화하고, 로드 순서를 제어해야 합니다 [21-24].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[DOM(Document Object Model)]], [[CSSOM(CSS Object Model)]], [[리플로우 및 리페인트(Reflow and Repaint)]]
+- **Projects/Contexts:** [[웹 성능 최적화(Web Performance Optimization)]]
+- **Contradictions/Notes:** CSS는 기본적으로 페이지 렌더링을 차단하는 리소스이지만, `<link>` 요소의 `media` 속성을 통해 현재 뷰포트 조건과 일치하지 않는 CSS를 설정함으로써 렌더링 차단 리소스에서 제외시킬 수 있습니다 [25, 26]. 
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file