diff --git a/10_Wiki/Topics/Frontend_Mastery/Automatic Batching을 통한 React 18 성능 최적화.md b/10_Wiki/Topics/Frontend_Mastery/Automatic Batching을 통한 React 18 성능 최적화.md
new file mode 100644
index 00000000..4283ff32
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/Automatic Batching을 통한 React 18 성능 최적화.md	
@@ -0,0 +1,28 @@
+# [[Automatic Batching을 통한 React 18 성능 최적화]]
+
+## 📌 Brief Summary
+Automatic Batching은 React 18에서 도입된 성능 최적화 기능으로, 여러 상태(state) 업데이트를 단일 리렌더링으로 묶어서 처리합니다 [1-3]. 이전 버전과 달리 프로미스(Promises), `setTimeout`, 비동기 작업 등 업데이트 출처에 관계없이 모든 상태 변경을 일괄 처리하여 불필요한 리렌더링을 방지합니다 [4-6]. 이를 통해 Virtual DOM의 비교(diffing) 작업을 최소화하고 애플리케이션의 성능과 UI 응답성을 크게 향상시킵니다 [1, 4, 7].
+
+## 📖 Core Content
+
+*   **작동 원리 및 이전 버전과의 차이점:**
+    React 18 이전에는 `onClick`이나 `onChange` 같은 네이티브 React 이벤트 핸들러 내에서 발생하는 상태 업데이트만 일괄 처리(배칭)되었으며, `setTimeout`이나 Promise와 같은 비동기 작업에서는 각 업데이트마다 개별적인 리렌더링이 발생했습니다 [2, 6]. 하지만 React 18부터는 자동 배칭(Automatic Batching)이 기본으로 활성화되어, 비동기 작업이나 타임아웃 등 모든 환경에서의 상태 업데이트를 하나의 렌더링 사이클로 그룹화합니다 [4, 5, 8].
+
+*   **성능 향상 및 Virtual DOM 최적화:**
+    여러 상태 변경을 하나로 결합함으로써 React는 Virtual DOM의 diffing 연산과 불필요한 DOM 업데이트 횟수를 최소화합니다 [1, 4, 7]. 실제 데이터 집약적인 대시보드를 대상으로 한 벤치마크 결과에 따르면, 자동 배칭을 활성화할 경우 최대 부하 상태에서 총 렌더링 횟수가 약 40% 감소하고 프레임 속도는 25% 향상되는 성능 개선을 보였습니다 [1, 9]. 이는 깊게 중첩된 컴포넌트를 가진 복잡한 애플리케이션에서 특히 유용합니다 [10].
+
+*   **렌더링 제어 API (`flushSync` 및 `startTransition`):**
+    자동 배칭이 기본 동작이지만, React는 렌더링 시점을 제어할 수 있는 API를 제공합니다 [9, 11]. 
+    *   `flushSync`: 폼 입력값을 즉시 업데이트하여 사용자에게 지연 없이 보여주거나, 상태 변경 직후 DOM 요소를 포커스 및 측정해야 할 때 자동 배칭을 우회하여 동기적 리렌더링을 강제합니다 [9, 12, 13].
+    *   `startTransition`: 리스트 필터링과 같이 긴급하지 않은 상태 업데이트를 표시하여 타이핑이나 클릭 등 우선순위가 높은 상호작용을 차단하지 않도록 양보(yield)합니다 [9, 12].
+
+*   **모니터링 및 베스트 프랙티스:**
+    성능 최적화를 극대화하려면 관련된 업데이트를 같은 이벤트 내에 그룹화하고 함수형 상태 업데이트(`setState(prev => new)`)를 사용하는 것이 좋습니다 [14]. 예상치 못한 리렌더링이 발생한다면 타사 라이브러리가 React의 이벤트 시스템을 우회하고 있지 않은지 확인해야 하며, React DevTools Profiler를 통해 상호작용에 따른 렌더링 횟수와 업데이트 원인을 디버깅하고 모니터링할 수 있습니다 [15-17].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** `[[Virtual DOM]]`, `[[flushSync]]`, `[[startTransition]]`, `[[Concurrent Rendering]]`, `[[useMemo / useCallback]]`
+- **Projects/Contexts:** `[[데이터 집약적 대시보드 성능 최적화]]`, `[[React 18 애플리케이션 마이그레이션]]`
+- **Contradictions/Notes:** 자동 배칭은 대부분의 경우 렌더링 성능을 개선하지만, 즉각적인 DOM 반영이 필요한 예외 상황에서는 방해가 될 수 있습니다. 이 경우 `flushSync`를 사용해 강제로 배칭을 해제할 수 있으나, 이를 남용할 경우 배칭으로 얻는 성능상 이점이 무효화될 수 있으므로 극히 제한적으로 사용해야 한다고 경고하고 있습니다 [11, 12, 14].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/CSR vs SSR vs SSG.md b/10_Wiki/Topics/Frontend_Mastery/CSR vs SSR vs SSG.md
new file mode 100644
index 00000000..637ee346
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/CSR vs SSR vs SSG.md	
@@ -0,0 +1,32 @@
+# [[CSR vs SSR vs SSG]]
+
+## 📌 Brief Summary
+CSR(클라이언트 사이드 렌더링), SSR(서버 사이드 렌더링), SSG(정적 사이트 생성)는 웹 애플리케이션의 HTML 콘텐츠가 언제, 어디서 생성되어 사용자에게 전달되는지를 결정하는 핵심적인 웹 렌더링 전략입니다 [1-3]. CSR은 브라우저에서 JavaScript를 통해 동적으로 UI를 구축하며, SSR은 사용자의 요청마다 서버에서 전체 HTML을 실시간으로 생성합니다 [2]. 반면 SSG는 배포 전 빌드 시점에 모든 HTML 페이지를 미리 생성하여 CDN을 통해 정적 파일로 제공합니다 [2]. 각 렌더링 방식은 초기 로드 속도, SEO(검색 엔진 최적화), 서버 부하, 그리고 상호작용성 측면에서 서로 다른 장단점과 최적의 사용 사례를 가집니다 [4-6].
+
+## 📖 Core Content
+
+**클라이언트 사이드 렌더링 (CSR, Client-Side Rendering)**
+*   **작동 원리**: 서버는 최소한의 빈 HTML 뼈대와 함께 전체 JavaScript 번들을 브라우저에 전송합니다 [4, 7, 8]. 브라우저가 이 JavaScript를 다운로드하고 실행하여 데이터를 가져오고 DOM을 동적으로 구축합니다 [4, 8, 9].
+*   **장점**: 초기 로드가 완료된 후에는 페이지 새로고침 없이 즉각적인 화면 전환이 가능하여 매끄럽고 상호작용이 풍부한 앱과 같은 사용자 경험을 제공합니다 [7, 10, 11]. 렌더링의 무거운 작업을 브라우저가 처리하므로 서버 부하와 호스팅 비용을 줄일 수 있습니다 [10, 12].
+*   **단점**: 브라우저가 큰 JavaScript 번들을 모두 실행하기 전까지는 빈 화면이 표시될 수 있어 초기 로드 속도(First Contentful Paint)가 느립니다 [7, 10, 13]. 또한 검색 엔진 크롤러가 초기에 빈 페이지를 보게 되므로 SEO에 불리할 수 있습니다 [7, 14, 15].
+*   **적합한 사용 사례**: SEO가 중요하지 않으며 고도의 상호작용이 필요한 로그인 기반의 내부 대시보드, SaaS 플랫폼, 싱글 페이지 애플리케이션(SPA) 등에 적합합니다 [4, 10, 16, 17].
+
+**서버 사이드 렌더링 (SSR, Server-Side Rendering)**
+*   **작동 원리**: 사용자가 페이지를 요청할 때마다 서버에서 데이터를 가져와 완전히 렌더링된 HTML 문서를 생성하여 브라우저에 전송합니다 [18-20]. 브라우저는 이 HTML을 즉시 표시하지만, 상호작용을 위해서는 추가로 JavaScript를 다운로드하여 HTML에 연결하는 '하이드레이션(Hydration)' 과정을 거쳐야 합니다 [18, 19, 21-23].
+*   **장점**: 검색 엔진이 완성된 HTML 콘텐츠를 즉시 크롤링할 수 있어 SEO에 매우 유리합니다 [18, 24, 25]. 사용자가 의미 있는 콘텐츠를 빠르게 볼 수 있으며(빠른 FCP), 항상 최신 상태의 동적 데이터를 반영할 수 있습니다 [18, 24, 25].
+*   **단점**: 모든 요청마다 서버에서 렌더링 로직을 실행해야 하므로 트래픽이 급증할 때 서버 부하와 인프라 관리 복잡성이 커집니다 [18, 21, 26, 27]. 또한, 하이드레이션 과정이 완료되기 전까지는 사용자가 버튼을 클릭해도 반응하지 않는 등 상호작용 지연(Time to Interactive) 현상이 발생할 수 있습니다 [18, 21, 23].
+*   **적합한 사용 사례**: 실시간 데이터 업데이트와 우수한 SEO 최적화가 동시에 필요한 뉴스 사이트, 콘텐츠 위주의 웹사이트, 전자상거래 제품 페이지 등에 이상적입니다 [24, 28, 29].
+
+**정적 사이트 생성 (SSG, Static Site Generation)**
+*   **작동 원리**: 사용자의 요청 시점이 아니라, 애플리케이션의 빌드 과정에서 모든 HTML 페이지를 미리 생성(Pre-build)해 둡니다 [30-32]. 생성된 정적 파일은 CDN을 통해 배포되어 전 세계 사용자에게 즉각적으로 제공됩니다 [30, 33, 34].
+*   **장점**: 서버 측 연산 과정이 없으므로 가장 빠르고 압도적인 페이지 로드 속도를 제공합니다 [30, 32, 34]. 미리 렌더링된 완벽한 HTML을 제공하므로 SEO 성능이 탁월하며, 대규모 트래픽에도 매우 저렴하고 효율적으로 확장할 수 있습니다 [31, 33, 35, 36].
+*   **단점**: 콘텐츠를 업데이트하려면 사이트 전체를 다시 빌드하고 배포해야 하므로 데이터가 쉽게 구식이 될 수 있습니다 [33, 37]. 자주 변경되는 실시간 데이터나 사용자별 맞춤 콘텐츠를 제공하는 데는 한계가 있습니다 [33, 37].
+*   **적합한 사용 사례**: 콘텐츠 변동이 적고 방문자 모두에게 동일한 정보를 제공하는 마케팅 랜딩 페이지, 블로그, 기술 문서 사이트 등에 가장 완벽한 방식입니다 [31, 38].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Hydration]], [[Single-Page Application (SPA)]], [[Incremental Static Regeneration (ISR)]], [[Time to Interactive (TTI)]], [[First Contentful Paint (FCP)]]
+- **Projects/Contexts:** Next.js, Nuxt, SvelteKit 등은 프로젝트 내에서 페이지 단위로 SSR, SSG, CSR 전략을 혼합(Hybrid)하여 사용할 수 있도록 지원하는 대표적인 프레임워크입니다 [39-41].
+- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (제공된 소스들 간에 CSR, SSR, SSG의 정의나 성능적 장단점 평가에 있어 상충하거나 모순되는 내용은 확인되지 않습니다.)
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/CSSOM.md b/10_Wiki/Topics/Frontend_Mastery/CSSOM.md
new file mode 100644
index 00000000..d9809541
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/CSSOM.md
@@ -0,0 +1,25 @@
+# [[CSSOM]]
+
+## 📌 Brief Summary
+CSSOM(CSS Object Model)은 웹 페이지의 시각적 외관을 정의하는 스타일 정보의 트리 구조입니다 [1-3]. DOM 생성과 달리 점진적으로 구성되지 않으며, 화면 렌더링을 차단(render-blocking)하는 특징이 있습니다 [1, 2]. 구축된 CSSOM은 DOM과 결합하여 브라우저가 화면에 요소를 계산하고 그리는 데 사용하는 렌더 트리(Render Tree)를 합성하는 핵심 역할을 합니다 [3-5].
+
+## 📖 Core Content
+* **생성 과정 및 특징**
+  브라우저는 CSS 코드를 파싱하여 CSSOM 트리를 생성하며, 여기에는 브라우저의 기본 사용자 에이전트(user agent) 스타일시트도 포함됩니다 [6, 7]. 브라우저는 CSS 규칙을 자신이 이해할 수 있는 스타일 맵으로 변환하고, CSS 선택자를 기반으로 부모, 자식, 형제 관계를 가지는 노드 트리를 구성합니다 [6]. 이 과정에서 가장 일반적인 규칙부터 시작하여 더 구체적인 규칙을 재귀적으로 적용하며 속성값을 캐스케이딩(Cascading)합니다 [7, 8]. 
+
+* **렌더링 차단 (Render-Blocking) 특성**
+  HTML의 DOM 생성은 점진적으로 이루어지지만 CSSOM은 그렇지 않으며 렌더링을 차단하는 작업입니다 [1, 2]. CSS 규칙은 이후에 파싱되는 규칙에 의해 덮어씌워질 수 있기 때문에, 브라우저는 스타일시트를 모두 다운로드하고 파싱하여 CSSOM을 완성할 때까지 페이지 렌더링을 중단합니다 [2, 8]. 이는 사용자가 스타일이 적용되지 않은 날 것의 HTML을 보게 되는 "스타일이 적용되지 않은 콘텐츠의 번쩍임(FOUC, Flash of Unstyled Content)" 현상을 방지하기 위한 안전장치입니다 [1].
+
+* **선택자 복잡도와 성능**
+  CSS 선택자의 복잡도는 CSSOM 구성 속도에 영향을 미칩니다 [9]. 브라우저는 선택자를 오른쪽에서 왼쪽으로 파싱하기 때문에, 특정 요소를 깊게 지칭하는 구체적인 선택자일수록 브라우저 엔진이 조상 관계를 확인하기 위해 DOM 트리를 거슬러 올라가야 하므로 더 많은 연산 작업을 요구합니다 [9, 10]. 하지만 최신 브라우저의 CSSOM 구축 및 파싱 속도는 매우 빠르며, 일반적으로 DNS 조회에 걸리는 시간보다도 적게 소요됩니다 [7, 10]. 
+
+* **렌더 트리(Render Tree)의 합성**
+  CSSOM과 DOM의 구축이 모두 준비되면, 브라우저는 이 두 트리를 결합하여 렌더 트리를 생성합니다 [4, 5, 11]. 렌더 트리는 화면에 표시되는 콘텐츠와 그에 해당하는 계산된 스타일(computed styles)만을 포함하며, `display: none`으로 스타일링된 숨김 요소나 `<head>`, `<script>` 같은 비시각적 노드는 렌더 트리에서 제외됩니다 [4, 5, 11].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[DOM (Document Object Model)]], [[Render Tree]], [[Critical Rendering Path (CRP)]]
+- **Projects/Contexts:** [[Browser Rendering Process]], [[Web Performance Optimization]]
+- **Contradictions/Notes:** 소스에 따르면 더 구체적인 CSS 선택자가 파싱 비용을 증가시키긴 하지만, 브라우저가 이를 마이크로초 단위로 처리할 만큼 속도가 매우 빠르기 때문에 선택자 성능 최적화 자체에만 집중하기보다는 CSS 파일을 최소화(minification)하거나 미디어 쿼리로 비차단(non-blocking) 요청을 분리하는 등 다른 최적화 방식이 더 큰 효과를 줄 수 있다고 조언합니다 [7, 10].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/Client-Side Rendering (CSR).md b/10_Wiki/Topics/Frontend_Mastery/Client-Side Rendering (CSR).md
new file mode 100644
index 00000000..f7c597e6
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/Client-Side Rendering (CSR).md	
@@ -0,0 +1,23 @@
+# [[Client-Side Rendering (CSR)]]
+
+## 📌 Brief Summary
+Client-Side Rendering (CSR)은 브라우저(클라이언트)가 서버로부터 최소한의 HTML 뼈대와 JavaScript 번들을 전달받은 후, JavaScript를 실행하여 동적으로 웹 페이지의 콘텐츠를 렌더링하고 UI를 구축하는 방식입니다 [1-3]. 이 방식은 주로 React나 Vue와 같은 라이브러리를 통해 단일 페이지 애플리케이션(SPA) 형태로 구현됩니다 [2, 4, 5]. 초기 로딩 이후에는 전체 페이지 새로고침 없이 즉각적인 화면 전환이 가능하여 매끄럽고 앱과 같은 사용자 경험을 제공하는 것이 특징입니다 [1, 6-8].
+
+## 📖 Core Content
+*   **작동 메커니즘**: CSR 환경에서 서버는 콘텐츠가 거의 없는 빈 HTML 파일과 JavaScript 코드를 클라이언트로 전송합니다 [1-3]. 브라우저는 이 JavaScript를 다운로드하고 파싱 및 실행한 뒤에야 필요한 데이터를 가져오고 DOM(Document Object Model)을 생성하여 실제 화면에 시각적 콘텐츠를 렌더링합니다 [1, 2, 9].
+*   **주요 장점**:
+    *   **풍부한 상호작용 및 UX**: 첫 페이지 로드 이후 후속 조작 시 서버에 전체 페이지를 다시 요청할 필요 없이 동적으로 필요한 데이터만 업데이트하므로, 전환이 매끄럽고 네이티브 앱과 같은 사용자 경험을 제공합니다 [1, 6-8].
+    *   **서버 부하 및 호스팅 비용 감소**: 서버는 페이지 렌더링 연산을 수행하지 않고 정적 파일(HTML, CSS, JS)만 제공하면 되므로 리소스 부담이 적으며, Amazon S3나 Netlify와 같은 저렴한 정적 호스팅 서버를 활용할 수 있습니다 [6, 10].
+    *   **빠른 개발 속도**: 개발자가 서버 측의 제약이나 호환성을 걱정하지 않고 `window` 객체와 같은 브라우저 전용 API를 자유롭게 활용할 수 있습니다 [10].
+*   **주요 한계 및 단점**:
+    *   **초기 로딩 속도 저하**: 브라우저가 유의미한 콘텐츠를 표시하기 위해 전체 JavaScript 번들을 다운로드하고 실행할 때까지 기다려야 하므로 초기 렌더링(First Contentful Paint) 속도가 느립니다 [1, 6, 8, 9]. 이는 사용자의 기기 성능이나 네트워크 상태에 크게 의존합니다 [11].
+    *   **검색 엔진 최적화(SEO) 제약**: 검색 엔진 크롤러나 소셜 미디어 봇이 웹사이트에 접근할 때 초기에는 빈 페이지만 보게 되므로, JavaScript를 제대로 파싱하지 못하면 콘텐츠 색인화 및 미리보기 생성이 누락될 수 있습니다 [1, 8, 9, 12, 13].
+*   **최적의 사용 사례(Use Cases)**: CSR은 SEO가 상대적으로 중요하지 않고, 사용자 상호작용과 실시간 데이터 업데이트가 필수적인 환경에 이상적입니다 [6, 14]. 로그인 장벽 뒤에 있는 대시보드, SaaS 플랫폼, 내부 비즈니스 도구 및 소셜 미디어 플랫폼 등이 대표적인 적용 사례입니다 [2, 5, 14, 15].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** `[[Server-Side Rendering (SSR)]]`, `[[Single-Page Applications (SPA)]]`, `[[Static Site Generation (SSG)]]`, `[[Document Object Model (DOM)]]`
+- **Projects/Contexts:** `[[SaaS 플랫폼 및 대시보드 개발]]`, `[[React 기반 고도의 동적 웹 애플리케이션 구축]]`
+- **Contradictions/Notes:** 소스 전반에서 CSR의 '뛰어난 상호작용성'과 'SEO 및 초기 로딩의 취약점'에 대한 평가는 일치하며 상충하는 내용은 없습니다 [1, 6, 8, 9, 12, 13]. 다만 최근에는 CSR의 한계를 극복하기 위해 Next.js와 같은 프레임워크를 사용하여 페이지의 목적에 맞게 SSR이나 SSG를 혼합(하이브리드 렌더링)하여 사용하는 방식이 권장되고 있습니다 [15-17].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/Critical Rendering Path (CRP).md b/10_Wiki/Topics/Frontend_Mastery/Critical Rendering Path (CRP).md
new file mode 100644
index 00000000..06ebb795
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/Critical Rendering Path (CRP).md	
@@ -0,0 +1,20 @@
+# [[Critical Rendering Path (CRP)]]
+
+## 📌 Brief Summary
+Critical Rendering Path (CRP)는 웹 브라우저가 HTML, CSS, JavaScript 코드를 수신하여 화면의 픽셀로 변환하기 위해 실행하는 일련의 단계입니다 [1, 2]. 이 경로는 DOM(문서 객체 모델) 및 CSSOM(CSS 객체 모델) 구축, 렌더 트리 생성, 레이아웃 계산, 화면 페인팅 등의 핵심 과정으로 구성됩니다 [2]. CRP를 최적화하면 최초 렌더링(Time to First Render) 시간을 단축하고, 초당 60프레임의 원활한 상호작용을 보장하며, 성능 저하나 끊김(Jank)을 방지할 수 있습니다 [2, 3].
+
+## 📖 Core Content
+- **DOM(Document Object Model) 구축:** 브라우저는 HTML 데이터를 수신하면 점진적 파싱(incremental parsing)을 시작합니다 [3, 4]. 수신된 바이트를 문자, 토큰, 노드로 변환한 뒤 계층적인 DOM 트리를 구축합니다 [3, 4].
+- **CSSOM(CSS Object Model) 구축:** CSS는 HTML과 달리 점진적으로 처리되지 않으며 렌더링 차단(render-blocking) 리소스로 작동합니다 [5, 6]. 브라우저는 화면에 스타일이 지정되지 않은 콘텐츠가 깜빡이는 현상(FOUC)을 막기 위해 렌더 트리를 만들기 전 모든 연결된 스타일시트를 다운로드하고 구문 분석하여 CSSOM을 완성해야 합니다 [5, 6].
+- **렌더 트리(Render Tree) 생성:** DOM과 CSSOM 트리가 준비되면 이를 결합하여 렌더 트리를 합성합니다 [7, 8]. 이 트리에는 화면 렌더링에 필요한 가시적 노드만 포함되며, `<script>`, `<meta>` 요소나 `display: none` 처리된 요소 등 시각적 레이아웃에 영향을 주지 않는 노드는 제외됩니다 [7-9].
+- **레이아웃(Layout / Reflow):** 렌더 트리가 구축되면 브라우저는 뷰포트 크기와 박스 모델을 기반으로 각 요소의 정확한 화면 상 위치(x, y)와 치수(너비, 높이)를 계산합니다 [10-12].
+- **페인트(Paint / Repaint) 및 합성(Compositing):** 페인트 단계에서는 계산된 기하학적 구조와 스타일(색상, 그림자, 텍스트 등)을 바탕으로 요소를 실제 픽셀로 화면에 그립니다 [13-15]. 마지막으로 합성 단계에서는 여러 레이어를 하나의 최종 이미지로 결합하며, 최신 브라우저에서는 성능을 위해 이 과정을 GPU에 오프로드하여 처리합니다 [13, 16].
+- **성능 최적화 전략:** CRP 최적화를 위해서는 다운로드해야 하는 렌더링 차단 리소스(`<head>` 내부의 CSS 및 동기식 JavaScript)의 크기와 개수를 최소화해야 합니다 [17-19]. 중요하지 않은 리소스의 로드를 지연시키거나 비동기로 처리하여 브라우저의 렌더링 파이프라인이 멈추지 않도록 구성하는 것이 핵심입니다 [17, 20].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[DOM (Document Object Model)]], [[CSSOM (CSS Object Model)]], [[Render Tree]], [[Reflow]], [[Repaint]]
+- **Projects/Contexts:** 최신 프론트엔드 개발의 기초 구조 설계, 코어 웹 바이탈(Core Web Vitals) 성능 개선, React의 Virtual DOM 도입을 통한 렌더링 병목 현상 해결 컨텍스트 [1, 2, 21].
+- **Contradictions/Notes:** CSS 선택자의 구체성(specificity)을 높게 작성할 경우 파싱 비용이 증가하지만, 현대 브라우저 엔진은 구문 분석 속도가 매우 빠르기 때문에 이러한 선택자 최적화가 CRP 전체 성능에 미치는 영향은 마이크로초(microseconds) 수준에 불과하여 최적화의 주된 우선순위로 삼기에는 실효성이 부족할 수 있습니다 [22].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/First Contentful Paint (FCP).md b/10_Wiki/Topics/Frontend_Mastery/First Contentful Paint (FCP).md
new file mode 100644
index 00000000..d42d38ec
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/First Contentful Paint (FCP).md	
@@ -0,0 +1,19 @@
+# [[First Contentful Paint (FCP)]]
+
+## 📌 Brief Summary
+First Contentful Paint(FCP)는 브라우저가 화면에 의미 있는 첫 번째 콘텐츠를 렌더링하는 데 걸리는 시간을 측정하는 웹 성능 지표입니다 [1, 2]. 이는 사용자가 웹 페이지가 실제로 로드되고 있음을 시각적으로 인지할 수 있게 해주는 렌더링 경로 상의 중요한 지점입니다 [1]. 선택한 웹 렌더링 전략에 따라 FCP 속도가 결정되며, 특히 서버 사이드 렌더링(SSR)을 사용할 때 시각적 표시가 즉각적으로 이루어져 크게 개선될 수 있습니다 [3, 4].
+
+## 📖 Core Content
+- **콘텐츠가 있는 렌더링 경로 (Contentful Rendering Path):** 전통적인 중요 렌더링 경로(Critical Rendering Path)는 초기 렌더링에 초점을 맞추었으나, 최신 웹 성능 최적화에서는 사용자 중심 지표인 FCP 및 LCP(Largest Contentful Paint)에 도달하는 데 필요한 핵심 리소스를 분석하는 콘텐츠 렌더링 경로의 중요성이 커지고 있습니다 [2].
+- **상호작용까지의 시간(TTI)과의 관계:** FCP는 페이지에 콘텐츠가 처음 표시되는 시점을 의미하며, 이후 페이지가 사용자 입력에 응답할 수 있게 되는 시점인 TTI(Time to Interactive)와는 구별됩니다 [1]. 즉, FCP가 빨라 사용자가 콘텐츠를 즉시 보게 되더라도, 메인 스레드가 자바스크립트를 다운로드 및 파싱하느라 바쁘다면 실제 상호작용(TTI)은 지연될 수 있습니다 [1, 3].
+- **렌더링 방식별 FCP 성능 차이:**
+  - **서버 사이드 렌더링 (SSR):** 브라우저가 전체 콘텐츠가 포함된 사전 렌더링된 HTML을 즉시 수신하므로, 자바스크립트를 실행하기 전이라도 콘텐츠를 거의 즉각적으로 화면에 렌더링할 수 있어 FCP 향상에 매우 유리합니다 [3, 4]. 코어 웹 바이탈(Core Web Vitals)의 FCP 및 LCP 성능이 저조할 때 SSR 도입이 해결책이 될 수 있습니다 [5].
+  - **클라이언트 사이드 렌더링 (CSR):** 브라우저가 자바스크립트 번들을 모두 다운로드하고 실행하기 전까지는 빈 HTML 셸이나 로딩 화면만 표시해야 하므로, 초기 렌더링 시 FCP가 느려지는 근본적인 단점이 있습니다 [4, 6, 7].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Server-Side Rendering (SSR)]], [[Client-Side Rendering (CSR)]], [[Time to Interactive (TTI)]], [[Largest Contentful Paint (LCP)]], [[Critical Rendering Path]]
+- **Projects/Contexts:** [[Core Web Vitals]], [[Web Performance Optimization]]
+- **Contradictions/Notes:** SSR은 FCP를 빠르게 만들어 시각적 콘텐츠 표시 시간을 크게 단축하지만, 이후 브라우저에서 자바스크립트 수화(Hydration) 과정이 완료될 때까지 상호작용이 지연되므로 TTI는 오히려 늦어지는 성능 상의 트레이드오프가 존재합니다 [3, 4]. 
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/Next.js.md b/10_Wiki/Topics/Frontend_Mastery/Next.js.md
new file mode 100644
index 00000000..7b9f3428
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/Next.js.md
@@ -0,0 +1,18 @@
+# [[Next.js]]
+
+## 📌 Brief Summary
+Next.js는 React 기반의 웹 애플리케이션 개발을 위한 프레임워크로, 클라이언트 사이드 렌더링(CSR), 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 점진적 정적 재생성(ISR) 등 다양한 렌더링 전략을 페이지별로 유연하게 혼합하여 사용할 수 있도록 지원합니다 [1, 2]. 특히 App Router를 통한 React 서버 컴포넌트(RSC)를 기본적으로 지원하여 자바스크립트 번들 크기를 줄이고 렌더링 성능을 최적화하는 데 특화되어 있습니다 [3-5]. 더불어 이미지 최적화, 스트리밍, 선택적 하이드레이션(selective hydration) 등 웹 성능을 극대화할 수 있는 강력한 기능들을 내장하고 있습니다 [6-8].
+
+## 📖 Core Content
+* **다양한 렌더링 전략 지원 (Hybrid Rendering):** Next.js는 단일 애플리케이션 내에서 요구사항에 맞춰 CSR, SSR, SSG, ISR을 페이지별로 혼합하여 적용할 수 있습니다 [1, 2]. 예를 들어, 마케팅 페이지에는 SSG를, 제품 목록에는 SSR을, 사용자 대시보드에는 CSR을 사용하는 식입니다 [1, 9]. 특히 ISR(Incremental Static Regeneration)을 활용하면 전체 사이트를 다시 빌드하지 않고도 지정된 주기에 맞춰 백그라운드에서 개별 정적 페이지를 업데이트할 수 있어, 빠른 로딩 속도와 데이터 최신화를 동시에 달성할 수 있습니다 [10-12].
+* **React 서버 컴포넌트(RSC) 및 App Router 환경:** Next.js 13 이상에서 도입된 App Router 모델에서는 페이지와 레이아웃이 기본적으로 서버 컴포넌트로 동작합니다 [4, 5]. 이로 인해 브라우저로 전송되는 자바스크립트 페이로드를 제거할 수 있으며, 서버 환경에서 데이터베이스나 파일 시스템에 직접 접근해 데이터를 페칭할 수 있습니다 [4, 13, 14]. 상호작용(예: 버튼 클릭, 상태 관리 등)이 필요한 요소에 한해서만 파일 상단에 `"use client"` 지시어를 명시해 클라이언트 컴포넌트로 전환합니다 [4, 15, 16].
+* **성능 최적화 및 React Compiler 지원:** 프레임워크 내장 컴포넌트인 `next/image`는 최신 이미지 포맷 변환, 반응형 크기 조절, 지연 로딩을 자동으로 처리하여 최대 콘텐츠 풀 페인트(LCP) 지표를 크게 개선합니다 [6]. 또한 `next/dynamic`을 사용해 화면에 당장 보이지 않는 컴포넌트의 하이드레이션을 지연시키는 선택적 하이드레이션을 구현해 초기 로딩 부담(TBT)을 줄일 수 있습니다 [7]. 성능 최적화와 관련해, Next.js 15.3.1 이상 및 16 버전부터는 수동 메모이제이션 없이도 렌더링을 자동 최적화해주는 SWC 기반의 React Compiler를 설정 파일이나 지시어를 통해 직접 지원합니다 [17, 18].
+* **스트리밍(Streaming) 및 Suspense 통합:** Next.js는 React의 Suspense API와 결합하여 서버에서 HTML을 점진적으로 스트리밍하는 기능을 지원합니다 [8]. 이를 통해 데이터 페칭 등 무거운 작업이 진행되는 동안 로딩 상태(fallback)를 브라우저에 먼저 보여주고, 완료된 조각(chunk)부터 화면에 즉시 렌더링함으로써 사용자가 느끼는 체감 대기 시간을 대폭 줄일 수 있습니다 [19, 20].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** `[[React Server Components]]`, `[[Server-Side Rendering (SSR)]]`, `[[Incremental Static Regeneration (ISR)]]`, `[[Hydration]]`, `[[React Compiler]]`
+- **Projects/Contexts:** `[[App Router]]`, `[[React Suspense]]`, `[[next/image]]`, `[[next/dynamic]]`
+- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/Next.js를 활용한 하이브리드 렌더링 및 React Server Components 도입.md b/10_Wiki/Topics/Frontend_Mastery/Next.js를 활용한 하이브리드 렌더링 및 React Server Components 도입.md
new file mode 100644
index 00000000..7476ef46
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/Next.js를 활용한 하이브리드 렌더링 및 React Server Components 도입.md	
@@ -0,0 +1,28 @@
+# [[Next.js를 활용한 하이브리드 렌더링 및 React Server Components 도입]]
+
+## 📌 Brief Summary
+Next.js를 활용한 하이브리드 렌더링은 단일 애플리케이션 내에서 페이지와 컴포넌트의 특성에 맞춰 CSR, SSR, SSG, ISR 등의 렌더링 방식을 혼합하여 사용하는 유연한 아키텍처입니다 [1, 2]. 여기에 React Server Components(RSC)가 도입되면서, 서버에서만 실행되고 클라이언트로는 JavaScript 번들을 전혀 전송하지 않는 렌더링이 가능해졌습니다 [3-5]. 이를 통해 개발자는 초기 로딩 속도를 대폭 개선하고 클라이언트의 연산 부담을 줄이며, 데이터베이스에 직접 안전하게 접근하는 최적화된 웹 애플리케이션을 구축할 수 있습니다 [6-8].
+
+## 📖 Core Content
+*   **Next.js 하이브리드 렌더링 전략**
+    Next.js와 같은 최신 프레임워크는 모든 페이지에 단일 렌더링 방식을 강제하지 않고 여러 방식을 혼합(Hybrid)하여 사용할 수 있게 합니다 [1, 9]. 예를 들어, 마케팅 및 문서 페이지에는 가장 빠른 속도를 제공하는 SSG를, 실시간 재고 데이터가 필요한 상품 페이지나 뉴스 기사에는 SSR을, 검색 엔진 최적화(SEO)가 필요 없고 상호작용이 많은 사용자 대시보드에는 CSR을 적용하는 등 각 페이지 요구사항에 맞는 렌더링을 선택할 수 있습니다 [1, 2].
+
+*   **React Server Components (RSC)의 특징과 장점**
+    RSC는 클라이언트 측 JavaScript 번들에 0바이트(Zero bytes)의 코드를 추가하는 서버 전용 컴포넌트입니다 [3, 5, 10]. 브라우저로 코드가 전송되지 않으므로, 데이터베이스에 직접 쿼리하거나 로컬 파일 시스템을 읽고, 민감한 환경 변수나 API 키에 접근하는 등의 서버 전용 작업을 안전하게 수행할 수 있습니다 [6, 7, 10]. 또한, 클라이언트 측에서 실행되지 않기 때문에 하이드레이션(Hydration) 과정 자체가 필요하지 않아 더욱 빠른 화면 표시와 최적화가 가능합니다 [4, 11, 12].
+
+*   **서버 컴포넌트와 클라이언트 컴포넌트의 혼합 (Mixing Components)**
+    RSC 모델에서는 상호작용이 필요 없는 무거운 컴포넌트는 서버에 두고, 버튼, 폼 입력 등 브라우저 상태(State)와 이벤트 핸들러(onClick 등)가 필요한 인터랙티브한 부분만 클라이언트 컴포넌트로 분리할 수 있습니다 [10, 13, 14]. 클라이언트 컴포넌트는 파일 최상단에 `"use client"` 지시어를 명시하여 선언합니다 [10, 15]. 중요한 규칙은, 서버 컴포넌트는 클라이언트 컴포넌트를 렌더링(포함)할 수 있지만, 클라이언트 컴포넌트는 서버 컴포넌트를 직접 임포트할 수 없다는 단방향(Server → Client) 의존성 원칙이 적용된다는 것입니다 [15-17].
+
+*   **작동 방식 및 React Flight 프로토콜**
+    RSC는 렌더링 시 단순히 순수한 HTML만 반환하는 것이 아닙니다 [18]. 서버는 정적인 부분의 HTML과 클라이언트가 전체 컴포넌트 트리를 조립하는 데 사용하는 '직렬화된 React 명령어(React Flight 프로토콜)'를 브라우저로 함께 스트리밍(Streaming)합니다 [4, 12, 19].
+
+*   **프로덕션 도입 시 주의점 및 최적화**
+    RSC를 사용한다고 해서 모든 성능 문제가 자동으로 해결되는 것은 아닙니다 [20]. 데이터 페칭 의존성이 순차적으로 구성되어 있다면, 브라우저에서 발생하던 워터폴(Waterfall) 현상이 서버에서 그대로 발생할 수 있습니다 [21, 22]. 따라서 데이터를 병렬로 페칭(Fetching)하도록 아키텍처를 설계해야 합니다 [23, 24]. 또한, `"use client"` 지시어를 남용하여 너무 많은 컴포넌트를 클라이언트로 전환하게 되면, 대규모 JavaScript 번들이 브라우저로 전송되어 RSC의 이점이 사라지므로 클라이언트 경계를 최소한으로 얕게 유지해야 합니다 [25, 26].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Client-Side Rendering (CSR)]], [[Server-Side Rendering (SSR)]], [[Static Site Generation (SSG)]], [[Incremental Static Regeneration (ISR)]], [[Hydration]], [[React Flight 프로토콜]]
+- **Projects/Contexts:** [[Next.js App Router]]
+- **Contradictions/Notes:** 소스에서는 React Server Components가 번들 크기를 줄이고 데이터 액세스를 개선하는 강력한 수단이지만 결코 '은탄환'은 아니라고 지적합니다. 잘못 구성될 경우 캐싱 복잡성을 더하거나 서버 측 워터폴(Server-side Waterfall)을 일으켜 성능 병목 지점만 클라이언트에서 서버로 옮기는 결과를 낳을 수 있으므로 철저한 설계가 필수적입니다 [20, 22, 27].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/React 16+ Core Engine.md b/10_Wiki/Topics/Frontend_Mastery/React 16+ Core Engine.md
new file mode 100644
index 00000000..24d75467
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/React 16+ Core Engine.md	
@@ -0,0 +1,29 @@
+# [[React 16+ Core Engine]]
+
+## 📌 Brief Summary
+React 16+ 핵심 엔진인 파이버(Fiber) 아키텍처는 동시성 렌더링(Concurrent Rendering)을 지원하기 위해 완전히 재작성된 React의 재조정(Reconciliation) 알고리즘입니다 [1, 2]. 과거 동기적으로 전체 컴포넌트 트리를 한 번에 처리하여 메인 스레드를 차단하던 방식에서 벗어나, 렌더링 작업을 '**파이버 노드(Fiber node)**'라는 작은 단위로 나누어 점진적으로 처리합니다 [1-3]. 이 구조는 시간 분할(Time-slicing) 및 레인(Lane) 모델을 통한 작업 우선순위 지정 기능을 제공하여, 무거운 렌더링 중에도 긴급한 사용자 입력 처리가 지연되지 않도록 UI 반응성을 보장합니다 [2-6].
+
+## 📖 Core Content
+
+**가상 DOM과 파이버 데이터 구조**
+기존 React의 가상 DOM은 불변성(Immutable)을 띠는 구조였으나, 단일 자식 노드를 여러 곳에서 공유할 때의 참조 문제 등을 해결하기 위해 React 16+ 엔진은 변경 가능한 '**증강 DOM(Augmented DOM)**' 형태인 파이버(Fiber) 데이터 구조를 사용합니다 [7]. 파이버 트리를 구성하는 각 컴포넌트(파이버 노드)는 컴포넌트의 타입, 상태, 속성(props)은 물론 부모, 자식, 형제 노드를 가리키는 포인터를 포함합니다 [8, 9].
+
+**작업 루프(Work Loop)와 스케줄러 메커니즘**
+파이버 재조정 엔진은 작업 루프를 통해 한 번에 하나의 파이버 노드를 처리합니다 [2]. 스케줄러는 레인 모델에 따른 우선순위와 남은 프레임 시간을 기준으로 다음 처리할 작업 단위를 선택합니다 [10, 11]. 
+하나의 작업 단위를 마칠 때마다 브라우저에 제어권을 양보(Yield)해야 할 긴급한 작업(사용자 입력 등)이 있는지 확인하여 처리 순서를 유연하게 조정합니다 [10, 11]. 진행 중이던 작업(WIP, Work-in-Progress)은 우선순위에 따라 일시 중지(Pause), 재개(Resume), 폐기(Discard), 또는 재생성될 수 있습니다 [12].
+
+**재조정(Reconciliation)의 2단계 분리**
+파이버 아키텍처는 렌더링 작업의 중단 및 우선순위 처리를 가능하게 하려고 전체 과정을 두 가지 명확한 단계로 분리했습니다 [13].
+*   **렌더링 단계 (Render Phase):** 이 단계는 비동기적이며 **중단되거나 재시작될 수 있는 순수 연산 과정**입니다 [13, 14]. 파이버 트리를 순회하면서 이전 상태와 새로운 상태의 차이를 계산하고(Diffing), 노드 삽입, 업데이트, 삭제와 같은 이펙트(Effect) 태그를 할당하여 변경이 필요한 파이버들만 모은 '이펙트 리스트'를 선형적으로 구축합니다 [5, 13-15]. 이 단계에서는 실제 DOM을 직접 수정하지 않습니다 [13, 14].
+*   **커밋 단계 (Commit Phase):** 렌더링 단계와 달리 **동기식으로 진행되며 절대 중단될 수 없습니다** [14, 16, 17]. 렌더링 단계에서 생성된 이펙트 리스트를 바탕으로 실제 DOM 변이(삽입, 삭제, 업데이트)를 한 번에 적용합니다 [14-16]. DOM이 변경된 직후, `useLayoutEffect`가 동기적으로 실행되고 이후 화면이 그려진(Paint) 뒤 비동기적으로 `useEffect`가 실행됩니다 [14, 16-18].
+
+**우선순위 관리와 레인(Lane) 모델**
+복잡한 업데이트들의 우선순위를 정교하게 다루기 위해 React는 32비트 정수 비트마스크 시스템인 '**레인(Lane) 모델**'을 채택했습니다 [5, 6, 19]. 이 시스템은 사용자 클릭/타이핑과 같은 '동기적(Sync) 레인', 스크롤 같은 '연속적(InputContinuous) 레인', 데이터 페칭 등의 '기본(Default) 레인', 그리고 '유휴(Idle) 레인' 등으로 작업의 중요도를 세분화합니다 [4, 20]. 레인 모델의 비트 연산을 통해 렌더러는 여러 우선순위가 겹치는 상황에서도 가장 중요한 작업을 먼저 화면에 반영할 수 있도록 제어합니다 [6, 18, 19].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Virtual DOM]], [[Reconciliation]], [[Concurrent Rendering]], [[Lane Model]], [[Time-slicing]]
+- **Projects/Contexts:** [[React 18 Automatic Batching]], [[React Server Components (RSC)]]
+- **Contradictions/Notes:** 렌더링 단계(Render Phase)는 높은 우선순위 작업이 들어올 경우 언제든 중단되거나 재시작될 수 있으므로 이 단계의 내부 연산에는 절대 사이드 이펙트(DOM 조작 등)가 포함되어서는 안 되며, 부수 효과 처리는 반드시 동기적으로 보장되는 커밋 단계(Commit Phase)에 배치되어야 합니다 [13, 14, 16, 17].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/React 18 자동 일괄 처리 및 React 19 컴파일러 최적화 적용.md b/10_Wiki/Topics/Frontend_Mastery/React 18 자동 일괄 처리 및 React 19 컴파일러 최적화 적용.md
new file mode 100644
index 00000000..1cdf50ad
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/React 18 자동 일괄 처리 및 React 19 컴파일러 최적화 적용.md	
@@ -0,0 +1,24 @@
+# [[React 18 자동 일괄 처리 및 React 19 컴파일러 최적화 적용]]
+
+## 📌 Brief Summary
+React 18의 자동 일괄 처리(Automatic Batching)와 React 19의 컴파일러(React Compiler)는 애플리케이션의 렌더링 성능을 극대화하고 개발자의 부담을 줄이기 위한 핵심 아키텍처 변화입니다. 자동 일괄 처리는 여러 상태 업데이트를 단일 리렌더링으로 묶어 가상 DOM의 비교 연산을 최소화합니다. React 19 컴파일러는 빌드 타임에 코드를 분석하여 수동으로 수행하던 메모이제이션 작업을 자동으로 처리함으로써, 불필요한 연쇄 렌더링을 세밀하게 방지합니다.
+
+## 📖 Core Content
+**React 18 자동 일괄 처리 (Automatic Batching)**
+*   **작동 원리 및 변화:** React 18 이전에는 React 이벤트 핸들러 내에서 발생하는 상태 업데이트만 일괄 처리(Batching)의 대상이었습니다 [1, 2]. 그러나 React 18부터는 프로미스(Promise), `setTimeout`, 비동기 API 호출, 네이티브 이벤트 핸들러 등 출처와 상관없이 동일한 이벤트 루프 내에서 발생하는 모든 상태 업데이트를 자동으로 묶어서 한 번만 리렌더링합니다 [3-6].
+*   **성능 향상:** 이 기능은 가상 DOM(Virtual DOM)의 diffing 횟수를 줄여 CPU 작업량을 크게 감소시킵니다 [4]. 벤치마크 결과에 따르면, 데이터 집약적인 대시보드에서 자동 일괄 처리를 활성화할 경우 총 렌더링 횟수가 최대 40% 감소하고 피크 로드 시 프레임 속도가 25% 향상되는 성능 이점을 보였습니다 [3, 7].
+*   **예외 처리 (Opt-out):** 개발자가 즉각적인 DOM 업데이트를 보장받아야 하는 상황(예: 입력 후 즉시 포커스 이동)에서는 `flushSync` API를 사용하여 자동 일괄 처리를 건너뛰고 동기적으로 렌더링을 강제할 수 있습니다 [7-10].
+
+**React 19 컴파일러 최적화 (React Compiler)**
+*   **수동 메모이제이션의 한계 해결:** 이전에는 렌더링 최적화를 위해 개발자가 `useMemo`, `useCallback`, `React.memo`를 수동으로 적용해야 했습니다 [11, 12]. 이는 인지적 부담을 가중시키고 의존성 배열(dependency array)을 잘못 설정하거나 참조 동일성(referential equality)을 놓쳐 최적화가 깨지는 등 유지보수 문제를 유발했습니다 [13, 14].
+*   **빌드 타임 자동화 및 AST 분석:** React 19 컴파일러(구 React Forget)는 빌드 도구 단계에서 코드의 추상 구문 트리(AST)를 분석하여 데이터 흐름을 추적합니다 [15, 16]. 코드를 정적 값(Static)과 반응형 값(Reactive)으로 분류하고, 최적의 위치에 자동으로 메모이제이션 경계를 삽입하여 렌더링 최적화 작업의 상당 부분을 제거합니다 [15-17].
+*   **세밀한 캐싱 (Granular Optimization):** 컴파일러는 전체 컴포넌트를 래핑하는 대신 `<h2>`, `<button>`과 같은 개별 JSX 요소와 특정 계산식들을 독립적으로 분리하여 캐싱합니다 [18, 19]. 결과적으로 속성(Props)이나 상태가 변경되지 않은 하위 컴포넌트의 불필요한 연쇄 리렌더링을 매우 정밀하게 차단합니다 [15, 20].
+*   **도입 효과:** 수동 메모이제이션 없이도 동일하거나 그 이상의 성능을 제공하며, 상호작용 속도(Interaction to Next Paint, INP)를 크게 개선합니다. 실제로 Meta의 프로덕션 적용 테스트에서 렌더링 횟수 60% 감소 및 사용자 상호작용 속도 2.5배 향상 등의 효과가 입증되었습니다 [21, 22].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[가상 DOM (Virtual DOM) 및 Diffing 알고리즘]], [[수동 메모이제이션 (useMemo, useCallback, React.memo)]], [[flushSync 및 startTransition]], [[동시성 렌더링 (Concurrent Rendering)]]
+- **Projects/Contexts:** [[대규모 데이터 대시보드 성능 최적화]], [[Meta의 프로덕션(Instagram, Quest Store) 최적화 도입 사례]]
+- **Contradictions/Notes:** React 컴파일러가 대부분의 수동 메모이제이션을 대체하지만, 매 렌더링마다 새로운 객체 참조를 반환하는 서드파티 라이브러리를 사용할 경우 자동 메모이제이션 체인이 깨질 수 있으므로 이러한 특정 상황에서는 여전히 수동 메모이제이션(`useMemo`, `useCallback`)이 필요할 수 있습니다 [23-25].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/React Compiler.md b/10_Wiki/Topics/Frontend_Mastery/React Compiler.md
new file mode 100644
index 00000000..c53d1eec
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/React Compiler.md	
@@ -0,0 +1,24 @@
+# [[React Compiler]]
+
+## 📌 Brief Summary
+React Compiler는 개발자가 수동으로 적용해야 했던 메모이제이션(memoization) 작업을 빌드 타임에 자동으로 처리해 주는 React의 새로운 최적화 도구이다 [1-3]. 기존의 `useMemo`, `useCallback`, `React.memo`와 같은 수동 메모이제이션의 번거로움과 오류 발생 가능성을 없애주며, 일반 JavaScript와 React의 규칙(Rules of React)을 이해하여 작동하므로 기존 코드를 재작성할 필요가 없다 [1, 4, 5]. 2025년 말에 안정화(stable) 버전으로 출시되었으며, 데이터 흐름을 분석하여 필요한 곳에만 지능적으로 메모이제이션을 삽입함으로써 애플리케이션의 렌더링 성능을 극대화한다 [3, 5, 6].
+
+## 📖 Core Content
+* **작동 방식 및 아키텍처:** 
+  React Compiler는 빌드 단계에서 동작하는 정적 분석 도구로, Babel 또는 SWC 플러그인 형태로 작동한다 [7, 8]. 작동 과정은 크게 세 단계로 나뉜다. 첫째, 컴포넌트 코드를 추상 구문 트리(AST, Abstract Syntax Tree)로 파싱하고 데이터 흐름을 분석하는 '분석(Analysis) 단계', 둘째, 값이 정적인지, props나 상태에 의존하는 반응형(reactive)인지, 파생된 값인지 판별하는 '추론(Inference) 단계', 셋째, 최적의 지점에 메모이제이션 경계를 삽입하는 '변환(Transformation) 단계'이다 [9, 10].
+* **세밀한 반응성(Fine-Grained Reactivity):** 
+  컴파일러는 표현식 수준에서 메모이제이션을 수행하여, 특정 입력이 변경될 때만 컴포넌트가 리렌더링되도록 한다 [9, 11]. 이를 통해 연쇄적인 리렌더링(cascading re-renders)을 방지하고 불필요하고 비용이 많이 드는 계산을 건너뛰게 만들어 준다 [11, 12].
+* **도입 효과 및 실제 사례:** 
+  Meta의 내부 테스트 결과 초기 로드 시간 12% 단축, 사용자 상호작용 속도 2.5배 향상, 리렌더링 횟수 60% 감소 효과를 보였다 [13]. 콘텐츠 에디터인 Sanity Studio는 렌더링 시간을 20~30% 단축했으며, Wakelet은 LCP를 25%, INP를 47% 향상시켰다 [14, 15]. 이는 수동 메모이제이션에서 발생하는 인지적 과부하, 과도한 메모이제이션, 의존성 배열 오류 등의 문제를 해결하면서 얻은 괄목할 만한 성능 개선이다 [4].
+* **설정 및 점진적 도입:** 
+  React 19 이상, Node.js 18+ 환경에서 사용 가능하며 Vite, Next.js(15.3.1 이상), Expo 등 주요 빌드 도구 및 프레임워크와 호환된다 [7, 16]. 기존 코드베이스에서는 한 번에 모든 것을 바꾸기보다 특정 디렉터리부터 시작하거나 컴포넌트 파일 상단에 `'use compiler'` 지시어를 추가하여 점진적으로 도입하는 전략이 권장된다 [17, 18]. ESLint 플러그인(`eslint-plugin-react-hooks`)을 활용해 컴파일러에 적합하지 않은 코드를 사전에 점검할 수도 있다 [18, 19].
+* **주의사항 및 예외 처리:** 
+  React Compiler는 렌더링 중 발생하는 부수 효과(side effects)나 외부 변형(external mutation)을 지원하지 않으므로, React의 규칙을 철저히 준수해야 한다 [19-21]. 컴파일러가 최적화할 수 없는 패턴에 직면하면 컴파일을 포기(Bailout)하고 기존의 표준 React 동작으로 돌아간다 [21, 22].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Memoization]], [[Abstract Syntax Tree (AST)]], [[Fine-Grained Reactivity]], [[Rules of React]], [[Re-render Cascade]]
+- **Projects/Contexts:** [[React 19]], [[Babel]], [[SWC]], [[Next.js]], [[Vite]]
+- **Contradictions/Notes:** React Compiler가 모든 수동 메모이제이션을 완벽히 대체하는 것은 아니다. 90% 이상의 최적화 작업을 자동으로 수행하지만 [2], 이펙트 의존성(effect dependency)을 제어해야 하거나 참조 안정성(stable references)을 요구하는 특정 서드파티 라이브러리(예: TanStack Query의 `useMutation()`)와 연동할 때는 여전히 개발자가 `useMemo`와 `useCallback`을 사용한 수동 제어를 병행해야 한다고 소스들은 명시하고 있다 [23-26].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/React Fiber Architecture.md b/10_Wiki/Topics/Frontend_Mastery/React Fiber Architecture.md
new file mode 100644
index 00000000..03595db9
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/React Fiber Architecture.md	
@@ -0,0 +1,29 @@
+# [[React Fiber Architecture]]
+
+## 📌 Brief Summary
+React Fiber는 동시성 렌더링(concurrent rendering)을 지원하기 위해 React 16에 도입된 재조정(reconciliation) 엔진의 전면적인 재작성 아키텍처입니다 [1, 2]. 기존의 동기식 "스택 재조정자(stack reconciler)"가 가지던 메인 스레드 차단 문제를 해결하기 위해 렌더링 작업을 "Fiber 노드"라는 작은 작업 단위로 분할합니다 [3, 4]. 이를 통해 렌더링을 일시 중지하고 높은 우선순위의 상호작용에 제어권을 양보한 뒤 다시 재개하는 "타임 슬라이싱(time-slicing)"과 우선순위 기반의 렌더링이 가능해집니다 [3, 4]. 
+
+## 📖 Core Content
+*   **동기식 블로킹의 해결 및 단위 작업 (Unit of Work)**
+    Fiber 이전의 React는 "스택 재조정자"를 사용하여 컴포넌트 트리를 단일 재귀 호출로 처리했기 때문에, 작업이 16.6ms의 프레임 예산을 초과하면 메인 스레드를 차단하고 UI가 사용자 입력에 응답하지 못하게 만들었습니다 [3]. Fiber는 렌더링 작업을 '단위 작업(unit of work)'인 Fiber 노드로 쪼개어 작업 루프(work loop)에서 점진적으로 처리합니다 [4, 5]. 각 단위 작업을 마친 후에는 브라우저에 제어권을 양보할지 계속 진행할지 확인하며, `beginWork`와 `completeWork` 함수를 통해 노드를 순회하고 처리합니다 [5, 6].
+
+*   **재조정 단계 (Reconciliation Phases)**
+    Fiber의 재조정 과정은 중단 가능성과 우선순위 관리를 위해 두 가지 명확한 단계로 나뉩니다 [7].
+    *   **렌더 단계 (Render Phase):** 이 단계는 중단하거나 폐기하고 다시 시작할 수 있습니다 [7, 8]. DOM을 직접 변경하지 않고 순수한 계산만 수행하며, 이전 상태와 새로운 상태의 차이를 계산해 업데이트나 삽입, 삭제 등의 이펙트 태그(effect tags)를 Fiber 노드에 표시합니다 [7-9].
+    *   **커밋 단계 (Commit Phase):** 동기적이며 중단할 수 없는 단계입니다 [8, 10]. 렌더 단계에서 구성된 이펙트 목록을 바탕으로 모든 DOM의 변이(mutation)를 한 번에 적용하며, 레이아웃 이펙트와 패시브 이펙트(useEffect 등)를 실행합니다 [8, 10].
+
+*   **우선순위 기반 스케줄링 및 레인(Lane) 모델**
+    React Scheduler는 "Lanes"라는 우선순위 시스템을 통해 작업을 관리합니다 [3, 9]. 
+    *   사용자 클릭이나 타이핑과 같은 긴급한 상호작용은 **Sync Lane**(즉시 처리)에 할당되고, 데이터 페칭은 **Default Lane**, 화면 밖 렌더링은 **Idle Lane**으로 분류됩니다 [11, 12]. 
+    *   레인 모델은 32비트 정수를 활용한 비트마스크 시스템을 사용하여 우선순위의 중복 여부를 효율적으로 확인하고, 낮은 우선순위 작업의 기아 현상(starvation)을 방지하며 업데이트를 하나로 묶습니다 [13, 14]. 이 모델 덕분에 `useTransition`이나 `useDeferredValue`와 같은 동시성 기능이 가능해집니다 [15].
+
+*   **이펙트 목록 (Effect List) 및 작업 중인 파이버 (WIP) 관리**
+    렌더 단계에서 React는 사이드 이펙트를 가진 Fiber들의 선형 목록인 이펙트 목록(Effect List)을 구축합니다 [16]. 커밋 단계에서는 전체 트리를 다시 탐색하는 대신 이 이펙트 목록만 순회하므로 업데이트가 훨씬 빨라집니다 [16]. 또한, 런타임 조건 및 우선순위에 따라 작업 중인(Work-In-Progress, WIP) Fiber를 일시 중지, 재개, 폐기 또는 재생성하며 UI의 부드러운 반응성을 유지합니다 [17].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Concurrent Rendering]], [[Reconciliation]], [[Virtual DOM]], [[Time-Slicing]], [[Lane Model]]
+- **Projects/Contexts:** [[React 16]], [[React Scheduler]]
+- **Contradictions/Notes:** 소스 문서들은 공통적으로 React Fiber가 기존 동기식 렌더링의 한계를 극복하기 위한 비동기적이며 중단 가능한 아키텍처임을 강조합니다. 또한, React 19의 `useTransition` 및 `useDeferredValue`와 같은 최신 동시성 기능이 모두 Fiber의 Lane 모델 아키텍처 위에서 구현되었음을 뒷받침하고 있습니다 [15, 18, 19].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/React Server Components.md b/10_Wiki/Topics/Frontend_Mastery/React Server Components.md
new file mode 100644
index 00000000..4d01f5a2
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/React Server Components.md	
@@ -0,0 +1,19 @@
+# [[React Server Components]]
+
+## 📌 Brief Summary
+React Server Components(RSC)는 오직 서버 환경에서만 실행되고 클라이언트로 JavaScript 코드를 전혀 전송하지 않는 React의 렌더링 아키텍처입니다 [1-3]. 기존의 SSR(Server-Side Rendering)과 달리 브라우저에서의 하이드레이션(Hydration) 과정이 필요 없으며, 렌더링된 HTML과 직렬화된 UI 명령어만을 클라이언트에 전달하여 번들 크기를 0바이트로 만듭니다 [1-4]. 이를 통해 개발자는 서버 데이터베이스나 파일 시스템에 직접 접근할 수 있으면서도 클라이언트의 연산 부담을 획기적으로 줄일 수 있습니다 [5, 6].
+
+## 📖 Core Content
+*   **등장 배경 및 렌더링 패러다임의 변화:** 기존의 클라이언트 측 렌더링(CSR)과 서버 측 렌더링(SSR)은 최종적으로 브라우저가 방대한 JavaScript 번들을 다운로드하고 이를 실행하여 하이드레이션을 수행해야 하는 구조적 병목 현상이 있었습니다 [7-10]. RSC는 상호작용이 필요 없는 컴포넌트를 서버에서 전적으로 처리하게 함으로써 클라이언트 측 JavaScript를 40~60%가량 감소시키고 INP(Interaction to Next Paint) 성능을 향상시킵니다 [1, 10].
+*   **작동 방식 및 React Flight 프로토콜:** 서버 컴포넌트는 클라이언트로 JavaScript 코드를 보내지 않고, 정적 HTML과 함께 브라우저가 UI를 조합할 수 있도록 돕는 직렬화된 React 명령어(React Flight 프로토콜)를 전송합니다 [2, 3, 11]. 브라우저는 이를 받아 추가적인 스크립트 실행이나 하이드레이션 없이 화면을 구성할 수 있습니다 [4].
+*   **데이터 페칭(Data Fetching) 및 보안:** 서버 환경에서만 실행되므로 API 엔드포인트를 거칠 필요 없이 데이터베이스 쿼리를 직접 실행하거나 파일 시스템 및 서버 환경 변수(비밀키 등)에 안전하게 접근할 수 있습니다 [5, 6, 12]. 또한 별도의 Hook 없이 컴포넌트 내부에서 `async/await`를 직접 사용하여 데이터를 가져올 수 있어 불필요한 네트워크 왕복을 줄여줍니다 [13, 14].
+*   **Client Component와의 하이브리드 아키텍처:** React 19부터는 모든 컴포넌트가 기본적으로 Server Component로 동작합니다 [15]. `onClick`, `useState` 등의 브라우저 상호작용이나 상태 관리가 필요한 경우에만 파일 최상단에 `"use client"` 지시어를 선언하여 Client Component로 사용합니다 [5, 15, 16]. 이때 **Server Component는 Client Component를 렌더링할 수 있지만, Client Component는 Server Component를 직접 임포트할 수 없다**는 엄격한 단방향 의존성 규칙이 존재합니다 [15, 17, 18].
+*   **한계점 (Limitations):** 서버 컴포넌트 자체는 어떠한 브라우저 이벤트 핸들러나 브라우저 전용 API(`window`, `document` 등)도 사용할 수 없습니다 [6, 16, 19]. 또한 여전히 브라우저 환경을 가정하는 일부 서드파티 라이브러리와는 호환되지 않을 수 있으며, 복잡한 스트리밍 인프라가 필요하므로 규모가 작고 단순한 애플리케이션에서는 도입으로 인한 복잡성이 성능 이점을 능가할 수 있습니다 [19-21].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Server-Side Rendering (SSR)]], [[Client Components]], [[Hydration]], [[React Flight]], [[Concurrent Rendering]]
+- **Projects/Contexts:** [[Next.js App Router]], [[React 19]]
+- **Contradictions/Notes:** SSR은 초기 HTML을 서버에서 생성하여 빠르게 보여주지만 결국 컴포넌트를 동작시키기 위해 전체 JS 번들을 클라이언트에 보내고 하이드레이션(Hydration)해야 합니다. 반면, React Server Components는 브라우저에 JS 코드를 전혀 보내지 않고 하이드레이션 과정 자체를 생략한다는 점에서 SSR과 근본적으로 다릅니다 [3, 12, 22, 23]. 또한 모든 경우에 무조건적으로 더 빠른 것은 아니며, 높은 상호작용이 필요한 클라이언트 중심의 앱에서는 오버헤드가 발생할 수 있습니다 [20, 24].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/React 기반 싱글 페이지 애플리케이션(SPA)의 렌더링 최적화.md b/10_Wiki/Topics/Frontend_Mastery/React 기반 싱글 페이지 애플리케이션(SPA)의 렌더링 최적화.md
new file mode 100644
index 00000000..e6affebd
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/React 기반 싱글 페이지 애플리케이션(SPA)의 렌더링 최적화.md	
@@ -0,0 +1,26 @@
+# [[React 기반 싱글 페이지 애플리케이션(SPA)의 렌더링 최적화]]
+
+## 📌 Brief Summary
+React 기반 SPA의 렌더링 최적화는 브라우저의 중요 렌더링 경로(Critical Rendering Path)를 효율적으로 처리하고, 불필요한 DOM 조작 및 연산을 줄여 사용자와 상호작용하는 성능을 향상시키는 과정입니다 [1-3]. 가상 DOM(Virtual DOM)과 휴리스틱 비교(Diffing) 알고리즘을 통해 실제 DOM 업데이트를 최소화하며, Fiber 아키텍처 및 자동 배칭(Automatic Batching)으로 렌더링 작업을 스마트하게 스케줄링합니다 [4-8]. 최신 생태계에서는 수동 최적화의 한계를 극복하기 위해 React 컴파일러를 통한 자동 메모이제이션 및 React 서버 컴포넌트(RSC)를 활용해 클라이언트의 자바스크립트 번들 부담을 극적으로 줄이는 방향으로 발전하고 있습니다 [9-12].
+
+## 📖 Core Content
+*   **브라우저 렌더링 과정과 Reflow/Repaint 최소화**
+    브라우저는 HTML과 CSS를 파싱하여 DOM과 CSSOM을 만들고 이를 결합해 렌더 트리(Render Tree)를 생성합니다 [13-15]. 이어서 요소의 정확한 크기와 위치를 계산하는 레이아웃(Layout 또는 Reflow) 단계와 화면에 픽셀을 그리는 페인트(Paint 또는 Repaint) 단계를 거칩니다 [16-18]. Reflow는 매우 연산 비용이 높고 하위 노드 전체로 파급 효과를 일으킬 수 있기 때문에, 불필요한 DOM 깊이를 줄이고, 레이아웃을 유발하는 속성(width, margin 등) 변경 대신 `transform`을 활용하여 렌더링 성능을 최적화해야 합니다 [17, 19-22].
+*   **가상 DOM(Virtual DOM)과 재조정(Reconciliation)**
+    수동적인 실제 DOM 조작은 레이아웃과 페인트를 즉각적으로 유발하여 느리고 비효율적입니다 [4, 23]. React는 메모리에 가상 DOM이라는 경량화된 UI 구조를 생성한 뒤, 상태가 변경되면 O(n) 복잡도의 휴리스틱 Diffing 알고리즘을 사용해 이전 트리와 비교합니다 [4, 5, 7, 8, 24]. 이 과정을 통해 React는 바뀐 최소한의 DOM 노드나 속성만 실제 브라우저 DOM에 커밋(동기화)하여 리렌더링 오버헤드를 막습니다 [25, 26].
+*   **Fiber 아키텍처와 동시성(Concurrent) 기능**
+    대규모 앱에서 동기적 렌더링은 브라우저의 메인 스레드를 차단해 화면 응답성을 늦출 수 있습니다 [27-29]. 이를 해결하기 위해 React 16부터 도입된 Fiber 아키텍처는 작업을 작은 단위로 나누고(Time-slicing) 중요도에 따라 우선순위(Lanes)를 부여하여 작업을 중단하거나 재개할 수 있는 렌더 단계(Render Phase)를 구현했습니다 [25, 27, 30-32]. 더불어 `useTransition` 및 `useDeferredValue`와 같은 동시성 훅(Hooks)은 긴급한 사용자 상호작용이 무거운 비긴급 UI 업데이트 때문에 지연되지 않게 하여 반응성을 향상시킵니다 [33-35].
+*   **리렌더링 캐스케이드(Cascade) 방지와 최적화 자동화**
+    상태가 변할 때 부모가 리렌더링되면 모든 자식이 함께 리렌더링되는 문제는 큰 성능 낭비를 초래합니다 [36, 37]. 이를 최적화하기 위해 도입된 기능이 **자동 배칭(Automatic Batching)**이며, Promise나 `setTimeout` 내의 여러 상태 업데이트를 단일 렌더링으로 묶어 DOM 렌더링 횟수를 대폭 줄입니다 [6, 38-40]. 또한 `React.memo`나 `useMemo` 같은 기존 수동 메모이제이션이 가진 유지보수 부담과 한계를 극복하기 위해, React 19 컴파일러는 빌드 타임에 AST를 분석해 최적의 지점에 자동으로 메모이제이션을 삽입하여 불필요한 렌더링을 차단합니다 [11, 41-45].
+*   **초기 로드 속도 개선(Code Splitting 및 RSC 적용)**
+    CSR 환경에서 큰 자바스크립트 번들은 초기 로딩(FCP, LCP)과 상호작용(INP)을 늦춥니다 [2, 46-48]. 따라서 `React.lazy()`를 이용한 라우트 단위의 코드 스플리팅(Code Splitting)과, 긴 목록에서 보이는 것만 렌더링하는 가상화(Virtualization) 기술은 체감 성능을 즉시 끌어올립니다 [49-51]. 나아가 React 서버 컴포넌트(RSC)를 채택하면, 데이터 페칭 및 렌더링을 서버 측에서 전담하여 클라이언트 자바스크립트 번들 크기에 0바이트를 기여하며, 클라이언트의 하이드레이션(Hydration) 비용을 완전히 제거할 수 있습니다 [9, 10, 52-54].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Virtual DOM]], [[Critical Rendering Path]], [[Fiber Architecture]], [[React Compiler]], [[React Server Components (RSC)]], [[Automatic Batching]], [[Reflow and Repaint]]
+- **Projects/Contexts:** [[Next.js]], [[React 18 & 19]], [[Single-Page Applications (SPA)]]
+- **Contradictions/Notes:** 
+  - 상태 업데이트 병합 시, React 18의 자동 배칭(Automatic Batching)이 기본 적용되지만 폼 입력 등 즉각적인 반영이 필수적인 경우 `flushSync`를 사용해 배칭을 의도적으로 우회(Opt-Out)하고 DOM 업데이트를 강제할 수 있습니다 [55-57]. 
+  - 수동 메모이제이션 방식(`React.memo`, `useMemo`)은 남용할 경우 비교 연산 및 메모리 저장이라는 자체적인 비용(Overhead)으로 인해 오히려 렌더링보다 더 큰 지연을 유발할 수 있다고 주장됩니다 [41]. 하지만 React 19부터 도입된 React Compiler는 이를 빌드 도구가 정적 분석을 통해 자동으로 최적화해 주어, 오버-메모이제이션의 함정 없이 성능을 보장할 수 있다고 설명합니다 [11, 44, 58].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/React 기반 프론트엔드 성능 최적화.md b/10_Wiki/Topics/Frontend_Mastery/React 기반 프론트엔드 성능 최적화.md
new file mode 100644
index 00000000..83db400a
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/React 기반 프론트엔드 성능 최적화.md	
@@ -0,0 +1,40 @@
+# [[React 기반 프론트엔드 성능 최적화]]
+
+## 📌 Brief 시 Summary
+React 기반 프론트엔드 성능 최적화는 불필요한 연산과 네트워크 페이로드를 최소화하여 빠르고 반응성 높은 사용자 경험을 제공하기 위한 일련의 기술적 접근이다 [1, 2]. 브라우저의 렌더링 경로(CRP)에서 발생하는 병목 현상을 줄이는 기초적인 최적화부터, 가상 DOM(Virtual DOM)의 재조정(Reconciliation) 과정과 리렌더링을 제어하는 React 고유의 최적화 기법을 포괄한다 [2-4]. 현대의 React는 Fiber 아키텍처, 자동 배칭, React Compiler를 통한 자동 메모이제이션, 그리고 React Server Components(RSC)를 활용하여 LCP, INP, CLS와 같은 핵심 웹 지표(Core Web Vitals)를 개선하고 애플리케이션의 성능을 극대화한다 [1, 5-9].
+
+## 📖 Core Content
+
+**1. 브라우저 렌더링 과정 (Critical Rendering Path) 및 Reflow/Repaint 최소화**
+브라우저가 화면을 그리는 렌더링 경로는 HTML 파싱을 통한 **DOM 트리 생성**, CSS 파싱을 통한 **CSSOM 트리 생성**, 이 둘을 결합한 **Render Tree 생성**, 요소의 크기와 위치를 계산하는 **Layout(Reflow)**, 픽셀을 화면에 그리는 **Paint(Repaint)**, 그리고 레이어를 합성하는 **Compositing** 단계로 이루어진다 [10-13]. 
+* **Reflow (Layout):** 요소의 크기(width, height)나 위치, 여백(margin, padding)이 변경될 때 발생하며, 문서 내 다른 요소들의 기하학적 구조까지 다시 계산해야 하므로 연산 비용이 매우 크다 [12, 14, 15]. DOM 노드의 깊이를 줄이고 레이아웃 스래싱(Layout Thrashing)을 방지하는 것이 중요하다 [14, 16].
+* **Repaint (Paint):** 배경색(background-color), 그림자(box-shadow) 등 시각적 속성만 변경될 때 발생하며 레이아웃 변경은 수반하지 않으나, 과도하게 발생할 경우 렌더링 파이프라인을 방해할 수 있다 [14, 17, 18]. 
+* **최적화 방법:** Reflow와 Repaint를 최소화하기 위해 DOM 상호작용을 줄이고, 애니메이션 구현 시 `top`이나 `left` 대신 GPU 가속을 받을 수 있는 `transform` 속성을 사용하는 것이 권장된다 [18-21]. 
+
+**2. React가 빠른 이유: Virtual DOM과 재조정(Reconciliation)**
+React는 실제 DOM을 직접 조작하는 것의 비효율성을 극복하기 위해 메모리 내에 가벼운 UI 표현인 **가상 DOM(Virtual DOM)**을 유지한다 [22, 23]. 상태가 변경되면 React는 새로운 가상 DOM 트리를 생성하고 이전 트리와 비교(Diffing)하여 변경된 부분만 실제 DOM에 적용한다 [22, 23]. 이 "재조정" 과정은 $O(n^3)$의 복잡도를 가지는 기존 트리 비교 알고리즘 대신, 요소의 타입이 다르면 트리를 완전히 새로 구축하고 리스트에서는 `key` prop을 통해 요소를 추적하는 휴리스틱 기반의 **$O(n)$ 최적화 알고리즘**을 사용하여 처리 속도를 비약적으로 높였다 [24-27].
+
+**3. Fiber 아키텍처와 동시성 렌더링(Concurrent Rendering)**
+React 16부터 도입된 **Fiber 아키텍처**는 기존의 동기적이고 차단적인 렌더링을 개선하기 위해 렌더링 작업을 중단하고 재개할 수 있는 '작업 단위(Unit of Work)'로 분할한다 [28-30]. 
+* **렌더 단계(Render Phase):** 부수 효과(Side effect) 없이 가상 DOM 트리를 순회하며 변경 사항을 계산하는 단계로, 높은 우선순위의 작업이 들어오면 언제든 중단되거나 재시작될 수 있다 [31, 32].
+* **커밋 단계(Commit Phase):** 계산된 변경 사항을 실제 DOM에 동기적으로 한 번에 적용하며, 이 단계는 중단할 수 없다 [32, 33].
+Fiber는 우선순위 시스템(Lanes)을 통해 사용자 입력과 같은 긴급한 작업을 데이터 페칭 같은 덜 긴급한 작업보다 먼저 처리할 수 있게 한다 [34, 35]. React 19의 `useTransition`과 `useDeferredValue` 훅은 이 아키텍처를 활용하여 무거운 연산 중에도 메인 스레드를 차단하지 않고 UI 반응성(INP 지표)을 유지하는 동시성 기능을 제공한다 [36-38].
+
+**4. 리렌더링 통제와 React Compiler의 도입**
+컴포넌트의 상태가 변경될 때마다 하위 트리의 모든 컴포넌트가 다시 렌더링되는 '리렌더링 폭포(Re-render Cascade)' 현상은 React 성능 저하의 주요 원인이다 [4, 39].
+* **수동 메모이제이션:** 기존에는 이를 막기 위해 `React.memo`, `useMemo`, `useCallback`을 사용하여 props가 변경되지 않았을 때의 렌더링을 수동으로 차단했다 [40-42]. 하지만 이 방식은 코드 복잡도를 높이고 참조 일치성 관리에 따른 잦은 실수를 유발했다 [43].
+* **React Compiler (자동 메모이제이션):** React 19부터 도입된 React Compiler는 빌드 타임에 AST(추상 구문 트리)를 분석하여 데이터 흐름을 파악하고, 필요한 곳에 자동으로 메모이제이션 경계를 삽입한다 [8, 9, 44, 45]. 이를 통해 개발자는 성능 최적화 코드를 직접 작성하지 않아도 세밀한 반응성(Fine-Grained Reactivity)을 얻어 최대 60% 이상의 불필요한 리렌더링을 줄일 수 있다 [8, 46, 47].
+* **자동 배칭(Automatic Batching):** React 18부터는 Promise나 setTimeout 같은 비동기 콜백 내에서 여러 상태 업데이트가 발생하더라도 이를 묶어 단 한 번의 리렌더링만 트리거하는 자동 배칭이 기본적으로 적용되어 성능을 최적화한다 [7, 48-50].
+
+**5. 렌더링 전략의 진화 (CSR vs SSR vs SSG vs RSC)**
+* **CSR (Client-Side Rendering):** 자바스크립트를 다운로드한 후 브라우저에서 UI를 렌더링하므로 상호작용이 빠르지만, 초기 로드(FCP)가 느리고 SEO에 불리하다 [51-53].
+* **SSR (Server-Side Rendering) & SSG (Static Site Generation):** 서버에서 HTML을 완성하여 전송해 초기 표시 속도와 SEO를 개선한다 [54-56]. 브라우저는 HTML을 화면에 그린 후, 자바스크립트를 실행해 이벤트 리스너를 연결하는 **Hydration** 과정을 거쳐 페이지를 상호작용 가능하게 만든다 [54, 57-59]. 
+* **React Server Components (RSC):** 서버에서만 실행되고 클라이언트로 자바스크립트 코드를 일절 보내지 않는(Zero-Bundle) 새로운 컴포넌트 패러다임이다 [60-63]. 무거운 데이터 페칭이나 정적인 UI 렌더링을 서버가 전담하므로, 번들 크기를 비약적으로 줄이고 Hydration 비용 자체를 제거하여 성능을 극대화한다 [62, 64, 65]. 대규모 애플리케이션에서는 서버 컴포넌트와 클라이언트 컴포넌트를 혼합하여 각 실행 환경의 장점을 모두 취할 수 있다 [62, 66].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Critical Rendering Path]], [[Virtual DOM]], [[React Fiber Architecture]], [[Hydration]], [[React Compiler]], [[React Server Components]]
+- **Projects/Contexts:** [[Next.js 기반 하이브리드 렌더링 (SSR/SSG/ISR)]], [[React 18/19 마이그레이션 및 동시성 렌더링 적용]]
+- **Contradictions/Notes:** 수동 메모이제이션 방식에 대해 소스 18은 "모든 컴포넌트를 무분별하게 메모이제이션(`React.memo` 등)하는 것은 오버헤드를 증가시켜 역효과를 낼 수 있으므로 프로파일링 후 제한적으로 적용해야 한다"고 주의를 줍니다. 반면 최신 기술인 React Compiler를 다룬 소스 336과 341에 따르면, 컴파일러는 코드 분석을 통해 "실제로 혜택을 제공할 수 있는 지점에 지능적으로 메모이제이션을 삽입"하여 개발자의 오버헤드나 오류 없이 성능을 자동으로 획기적으로 개선한다고 설명합니다.
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/React 렌더링 최적화.md b/10_Wiki/Topics/Frontend_Mastery/React 렌더링 최적화.md
new file mode 100644
index 00000000..8752051b
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/React 렌더링 최적화.md	
@@ -0,0 +1,25 @@
+# [[React 렌더링 최적화]]
+
+## 📌 Brief Summary
+React 렌더링 최적화는 애플리케이션의 불필요한 재렌더링을 방지하고 초기 로드 및 상호작용 속도를 향상시켜 사용자 경험을 개선하는 과정입니다 [1-3]. 기본적으로 부모 컴포넌트의 상태가 변경되면 모든 자식 컴포넌트가 다시 렌더링되는 폭포수(Cascade) 문제가 발생할 수 있습니다 [1, 2]. 이를 해결하기 위해 메모이제이션, React 18의 자동 배칭(Automatic Batching), 동시성 렌더링, 그리고 최근 도입된 React Compiler와 같은 기술을 활용하여 성능 병목을 최소화합니다 [4-8].
+
+## 📖 Core Content
+
+*   **가상 DOM과 재조정(Reconciliation):** React는 DOM의 상태를 추상화한 **가상 DOM(Virtual DOM)**을 메모리에 유지하며, 상태가 변경될 때 이전 트리와 새로운 트리를 비교하여 실제 DOM에 필요한 최소한의 변경 사항만 업데이트합니다 [9-11]. 이 비교 과정에서는 **요소의 타입이 다르면 트리를 처음부터 다시 구축하고, 고유한 `key`를 사용하여 리스트 항목의 변경을 추적**하는 O(n) 복잡도의 휴리스틱 알고리즘을 사용합니다 [12-15].
+*   **Fiber 아키텍처와 동시성 렌더링(Concurrent Rendering):** 기존의 동기식 렌더링이 메인 스레드를 차단하는 문제를 해결하기 위해 도입된 **Fiber 아키텍처는 렌더링 작업을 작은 '작업 단위(units of work)'로 나누어 처리**합니다 [16-18]. 중요도(Lane)에 따라 긴급한 상호작용을 우선 처리하고 무거운 작업은 양보하는 '타임 슬라이싱(Time-slicing)'을 지원합니다 [17, 19, 20]. React 19의 `useTransition` 및 `useDeferredValue` 훅을 사용하면 무거운 연산 중에도 메인 스레드를 차단하지 않고 UI 반응성을 유지할 수 있습니다 [5, 21, 22].
+*   **메모이제이션(Memoization):** 컴포넌트의 불필요한 재렌더링을 막기 위해 **`React.memo`, `useMemo`, `useCallback`을 사용하여 이전 계산 결과나 컴포넌트 상태를 캐싱**합니다 [4, 23, 24]. 그러나 매 렌더링마다 인라인 객체나 함수를 생성하면 참조 동등성(reference equality)이 깨져 메모이제이션이 무효화될 수 있습니다 [25-27]. 무분별한 메모이제이션은 오히려 비교 연산 및 메모리 오버헤드를 발생시키므로, 반드시 프로파일링을 통해 병목 지점을 찾은 후 선택적으로 적용해야 합니다 [23, 28].
+*   **자동 배칭(Automatic Batching):** React 18부터는 네이티브 이벤트 핸들러뿐만 아니라 **Promise, `setTimeout` 등 비동기 작업 내에서 발생하는 여러 상태 업데이트를 단일 재렌더링으로 묶어 처리**합니다 [6, 29-31]. 이를 통해 렌더링 횟수를 대폭 줄여 프레임 드롭을 방지할 수 있으며, 즉각적인 DOM 업데이트가 필요한 경우에는 `flushSync` API를 사용하여 배칭에서 예외 처리할 수 있습니다 [32-34].
+*   **React Compiler를 통한 자동화:** React 19에 도입된 React Compiler는 빌드 타임에 코드의 추상 구문 트리(AST)를 분석하여 **필요한 곳에 자동으로 메모이제이션 경계를 삽입**합니다 [7, 35-38]. 개발자가 수동으로 의존성 배열(dependency array)을 관리할 필요성이 사라지며, 성능 향상은 물론 코드의 가독성과 유지보수성도 크게 개선됩니다 [7, 23, 39].
+*   **기타 구조적 최적화 기법:**
+    *   **코드 스플리팅:** `React.lazy()`를 활용해 초기 번들 크기를 줄여 LCP(Largest Contentful Paint) 속도를 개선합니다 [40, 41].
+    *   **가상화(Virtualization):** `react-window` 등을 사용하여 수천 개의 리스트 중 화면에 보이는 DOM 노드만 렌더링합니다 [42, 43].
+    *   **DOM 노드 감소 및 상태 분리:** 불필요한 래퍼를 줄이는 React Fragment의 사용과, 렌더링 파급력을 최소화하기 위해 Context를 업데이트 빈도에 따라 분리하는 기법이 있습니다 [44-46].
+    *   **React Server Components (RSC):** 상호작용이 없는 정적 컴포넌트를 서버에서 전적으로 렌더링해 클라이언트 측으로 전송되는 JavaScript 페이로드를 원천적으로 차단합니다 [47-49].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Virtual DOM]], [[Reconciliation]], [[Fiber Architecture]], [[Automatic Batching]], [[React Compiler]], [[React Server Components]]
+- **Projects/Contexts:** [[프론트엔드 성능 최적화]], [[Core Web Vitals 개선 전략]], [[대규모 단일 페이지 애플리케이션(SPA) 구축]]
+- **Contradictions/Notes:** 기존에는 `useMemo`와 `useCallback`과 같은 수동 메모이제이션이 렌더링 최적화의 핵심으로 여겨졌으나, 새로운 React Compiler의 등장으로 이러한 수동 제어는 대부분 불필요해지거나 오히려 안티 패턴이 될 가능성이 제기되었습니다 [23, 39, 50]. 다만 서드파티 라이브러리의 불안정한 참조 반환 등 일부 엣지 케이스에서는 여전히 수동 메모이제이션이 이스케이프 해치(Escape hatch)로 사용됩니다 [51-53].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/React 컴포넌트 기반 아키텍처.md b/10_Wiki/Topics/Frontend_Mastery/React 컴포넌트 기반 아키텍처.md
new file mode 100644
index 00000000..b2138ccf
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/React 컴포넌트 기반 아키텍처.md	
@@ -0,0 +1,19 @@
+# [[React 컴포넌트 기반 아키텍처]]
+
+## 📌 Brief Summary
+React 컴포넌트 기반 아키텍처(CBA)는 애플리케이션을 재사용 가능하고 독립적인 기능 단위인 '컴포넌트'로 분할하여 조립하는 설계 방법론입니다 [1, 2]. 이 아키텍처는 상태(State)와 UI 로직을 캡슐화하고 Virtual DOM을 통해 브라우저의 렌더링 부하를 최소화하여 성능을 향상시킵니다 [3, 4]. 최근에는 React Server Components(RSC)와 React Compiler의 도입을 통해 서버-클라이언트 간의 하이브리드 실행 및 빌드 타임 렌더링 자동화까지 지원하는 방향으로 발전하고 있습니다 [5-7].
+
+## 📖 Core Content
+- **모듈성 및 캡슐화 (Modularity and Encapsulation):** React 컴포넌트 아키텍처는 관심사의 분리(Separation of Concerns)를 강력하게 지원합니다. 각 컴포넌트는 내부 구현 세부 사항과 상태를 캡슐화하며, 잘 정의된 인터페이스를 통해서만 상호작용합니다 [4, 8]. 이를 통해 여러 개발 팀이 서로 다른 컴포넌트를 병렬로 개발할 수 있어 시스템의 확장성과 유지보수성이 크게 향상됩니다 [9-11].
+- **가상 DOM과 재조정 (Virtual DOM & Reconciliation):** 브라우저의 실제 DOM을 직접 조작하는 것은 연쇄적인 Reflow와 Repaint를 유발해 비용이 매우 큽니다 [3]. React는 가상 DOM(Virtual DOM)이라는 가벼운 메모리 내 UI 표현을 구축하고, 상태 변경 시 O(n) 복잡도의 휴리스틱 Diffing 알고리즘을 통해 변경된 최소한의 노드만을 실제 DOM에 동기화(Reconciliation)합니다 [3, 12-14].
+- **파이버 아키텍처 (Fiber Architecture)와 동시성:** 대규모 렌더링 시 메인 스레드가 차단되는 동기식 렌더링의 한계를 극복하기 위해 React 16부터 파이버(Fiber) 엔진이 도입되었습니다 [15]. 렌더링 작업을 '파이버 노드(Fiber node)'라는 컴포넌트 단위 작업으로 쪼개고, 렌더링을 중단하거나 재개할 수 있게 합니다 [15, 16]. 우선순위(Lanes 모델)에 따라 클릭이나 타이핑 등 긴급한 사용자 상호작용을 먼저 처리하여 UI의 끊김 없는 반응성을 유지합니다 [17-19].
+- **리액트 서버 컴포넌트 (React Server Components, RSC):** 점대점(SPA) 구조에서 발생하는 방대한 번들 크기와 클라이언트 데이터 패칭 병목 현상을 해결하기 위해 등장한 아키텍처입니다 [5, 20]. RSC는 오직 서버에서만 실행되어 브라우저로 JavaScript 코드를 일절 전송하지 않으며(Zero Client-Side JavaScript), 백엔드 리소스(DB, 파일시스템 등)에 직접 접근합니다 [21-23]. 상호작용이 필요한 부분만 **클라이언트 컴포넌트**로 구성하여 불필요한 JS 다운로드와 Hydration 비용을 제거합니다 [21, 23].
+- **렌더링 최적화와 컴파일러 (React Compiler):** 이전에는 부모 컴포넌트가 업데이트될 때 발생하는 '연쇄적 재렌더링(Re-render Cascade)'을 막기 위해 `useMemo`, `React.memo` 등의 수동 메모이제이션이 필요했습니다 [24-27]. React 19부터 도입된 React Compiler는 빌드 타임에 추상 구문 트리(AST)를 분석하여, 불필요한 재렌더링을 막을 수 있는 세밀한 메모이제이션(Memoization) 경계를 자동으로 삽입함으로써 수동 최적화의 부담을 없앱니다 [6, 28, 29].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** `[[Virtual DOM]]`, `[[Reconciliation]]`, `[[Fiber Architecture]]`, `[[React Server Components]]`, `[[React Compiler]]`
+- **Projects/Contexts:** `[[Next.js App Router]]`, `[[Meta's Quest Store and Instagram]]`
+- **Contradictions/Notes:** 컴포넌트 기반 아키텍처는 극대화된 유연성을 제공하지만, 컴포넌트 수가 증가함에 따라 종속성 관리의 복잡성과 상호 통신 오버헤드가 단점으로 작용할 수 있습니다 [30, 31]. 또한 RSC 도입 시, 서버 컴포넌트 내에서는 브라우저 상호작용(예: onClick)이나 상태 관리(useState)를 사용할 수 없으며, 클라이언트 컴포넌트는 서버 컴포넌트를 직접 `import` 할 수 없다는 엄격한 구조적 제약 규칙이 따릅니다 [32-34].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/Reflow and Repaint.md b/10_Wiki/Topics/Frontend_Mastery/Reflow and Repaint.md
new file mode 100644
index 00000000..c66774b3
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/Reflow and Repaint.md	
@@ -0,0 +1,33 @@
+# [[Reflow and Repaint]]
+
+## 📌 Brief Summary
+리플로우(Reflow)와 리페인트(Repaint)는 브라우저가 웹 페이지를 화면에 렌더링하기 위해 수행하는 핵심 과정입니다 [1-3]. 리플로우(또는 레이아웃)는 DOM의 구조나 스타일 변경 시 전체 또는 일부 요소의 정확한 위치와 크기를 재계산하는 비용이 높은 작업입니다 [2, 4]. 반면 리페인트는 레이아웃 변경 없이 요소의 시각적 형태(색상, 배경 등)만 업데이트할 때 화면의 픽셀을 다시 그리는 과정으로, 두 과정 모두 과도하게 발생할 경우 웹 성능 저하의 주요 원인이 됩니다 [5, 6].
+
+## 📖 Core Content
+* **브라우저 렌더링 파이프라인 내의 역할**
+  * 브라우저는 HTML과 CSS를 파싱해 각각 DOM과 CSSOM을 만들고, 이를 결합하여 시각적 요소들만 포함하는 렌더 트리(Render Tree)를 생성합니다 [3, 7].
+  * 렌더 트리가 구성되면, 각 요소의 정확한 화면상 위치와 크기를 계산하는 레이아웃(Layout, 즉 Reflow) 단계를 거칩니다 [1, 7].
+  * 레이아웃이 확정되면, 기하학적 정보를 바탕으로 실제 화면의 픽셀에 시각적 스타일을 칠하는 페인트(Paint, 즉 Repaint) 단계와 층을 병합하는 합성(Compositing) 단계를 진행합니다 [7-9].
+
+* **리플로우(Reflow)의 특성 및 유발 조건**
+  * 브라우저 창 크기 조절, DOM 요소의 추가 및 제거, 또는 `width`, `height`, `margin`, `padding`과 같은 레이아웃 속성 변경 시 발생합니다 [2, 6].
+  * 문서의 연속적인 흐름(Continuous document flow) 특성 때문에, 한 요소의 기하학적 변화는 부모, 자식, 후속 요소들까지 연쇄적인 재계산을 유발할 수 있습니다 [4, 5, 8].
+  * 리플로우는 사용자 상호작용을 차단할 수 있는(User-blocking) 연산 집약적인 작업으로 렌더링 성능에 큰 영향을 미칩니다 [4, 10].
+
+* **리페인트(Repaint)의 특성 및 유발 조건**
+  * 요소의 기하학적 구조나 위치는 변경하지 않고 배경색, 글자색, 그림자 등의 시각적 속성만 변경할 때 픽셀을 다시 그리는 과정입니다 [2, 6, 11].
+  * 리플로우보다 연산 비용은 낮지만, 여전히 과도하게 발생할 경우 프레임 드롭(Frame drop)이나 화면 끊김(Jank)을 초래하고 모바일 기기의 배터리 소모를 가속화할 수 있습니다 [5, 9, 12, 13].
+
+* **최적화 전략 (Performance Optimization)**
+  * **문서 흐름 분리:** 복잡한 애니메이션을 렌더링할 때는 해당 요소를 `position: absolute`나 `position: fixed`를 사용해 일반적인 문서 흐름(Flow)에서 분리함으로써 전체 레이아웃의 리플로우 연산을 방지해야 합니다 [14].
+  * **GPU 가속 및 속성 최적화:** 위치 이동 애니메이션에 `top`이나 `left` 대신 `transform: translate()`을 사용하면, 브라우저가 새로운 리플로우나 리페인트 사이클 없이 자체 레이어 내에서 요소를 이동시키고 GPU 합성(Compositing)을 거쳐 부드러운 60fps 애니메이션을 유지할 수 있습니다 [9, 12, 13].
+  * **DOM 조작 최소화 및 배치 처리:** 루프 내에서의 잦은 DOM 조작을 피하고 업데이트를 일괄 처리하여, 읽기와 쓰기가 번갈아 일어나는 레이아웃 스래싱(Layout thrashing) 현상을 방지해야 합니다 [11, 12, 15].
+  * **구조 및 선택자 단순화:** DOM 트리의 깊이를 줄이고, 매칭 과정에서 더 많은 연산이 필요한 복잡한 하위(Descendant) CSS 선택자의 사용을 피해야 합니다 [12, 14].
+
+## 🔗 	Knowledge Connections
+- **Related Topics:** [[Critical Rendering Path]], [[Render Tree]], [[DOM]], [[CSSOM]], [[Layout Thrashing]], [[GPU Acceleration]]
+- **Projects/Contexts:** [[Frontend Performance Optimization]], [[Browser Rendering Engine]]
+- **Contradictions/Notes:** 소스에 따르면 시각적 속성에 따른 요소 숨김 처리 방식에서 큰 차이가 발생합니다. `display: none`은 렌더 트리에서 요소를 완전히 제거해 리플로우(Reflow)를 유발하지만, `visibility: hidden`은 요소를 빈 상자로 렌더링하여 레이아웃에 공간을 유지하므로 리플로우 없이 리페인트(Repaint)만 발생시킵니다 [16, 17].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/Reflow 및 Repaint.md b/10_Wiki/Topics/Frontend_Mastery/Reflow 및 Repaint.md
new file mode 100644
index 00000000..aa08df23
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/Reflow 및 Repaint.md	
@@ -0,0 +1,27 @@
+# [[Reflow 및 Repaint]]
+
+## 📌 Brief Summary
+웹 브라우저가 화면을 렌더링하는 과정에서 'Reflow(레이아웃)'는 요소의 정확한 크기와 위치 등 기하학적 구조를 계산하는 단계입니다. 반면 'Repaint(페인트)'는 계산된 구조를 바탕으로 배경색이나 텍스트 색상 같은 시각적 요소를 화면의 픽셀로 그려내는 과정입니다. 두 과정 모두 연산 비용이 들며 프레임 속도와 애플리케이션 성능에 직결되므로, 이를 최소화하는 것이 프론트엔드 렌더링 최적화의 핵심입니다 [1-3].
+
+## 📖 Core Content
+- **렌더링 파이프라인의 이해:** 브라우저는 HTML과 CSS를 파싱하여 각각 DOM과 CSSOM을 구성하고, 이를 결합해 화면에 보일 요소들만 포함하는 렌더 트리(Render Tree)를 생성합니다 [4-7]. 이후 렌더 트리를 기반으로 기하학적 구조를 계산하는 Reflow 단계를 거쳐, 픽셀로 변환하는 Repaint, 그리고 여러 레이어를 합성하는 Compositing 단계로 렌더링을 마칩니다 [1, 7, 8].
+- **Reflow (Layout) 상세:**
+  - 뷰포트의 크기와 박스 모델을 기반으로 모든 가시적 요소의 x, y 좌표 및 너비와 높이를 계산합니다 [1, 2].
+  - 브라우저 창의 크기 조절, DOM 요소의 추가 및 제거, 또는 너비(width), 높이(height), 여백(margin, padding)과 같이 레이아웃에 영향을 미치는 CSS 속성 변경 시 발생합니다 [2, 3, 9, 10].
+  - HTML 요소들은 연속적인 문서 흐름(Document Flow) 안에 존재하므로, 한 요소의 기하학적 변화가 다른 요소들까지 연쇄적으로 재계산하게 만들어 연산 비용이 매우 높습니다 [1, 9, 11, 12].
+- **Repaint (Paint) 상세:**
+  - 레이아웃(크기나 위치)의 변화 없이, 요소의 시각적 형태만 변경될 때 발생합니다 [2, 3, 10].
+  - 배경색, 텍스트 색상, 그림자(box-shadow), 가시성 변경 등이 이에 해당합니다 [2, 3, 10].
+  - Reflow보다는 연산 비용이 적게 들지만, 잦은 Repaint 역시 렌더링 파이프라인을 방해해 스크롤이나 애니메이션 시 화면이 버벅거리는 현상(Jank)을 초래할 수 있습니다 [8, 11-13].
+- **성능 최적화 기법 (Optimization Strategies):**
+  - **DOM 조작 최소화:** 불필요한 DOM 트리의 깊이를 줄이고 복잡한 하위 CSS 선택자 사용을 피해야 합니다 [13, 14]. DOM 읽기와 쓰기를 번갈아 하여 발생하는 '레이아웃 스래싱(Layout Thrashing)'을 방지하기 위해 조작을 일괄 처리(Batching)하는 것이 좋습니다 [2, 15].
+  - **GPU 가속 활용:** `top`이나 `left` 속성 대신 `transform`과 `opacity`를 사용하면, Reflow와 Repaint를 유발하지 않고 GPU를 통해 애니메이션을 처리할 수 있습니다 [8, 12, 13, 16].
+  - **스타일 및 위치 최적화:** Reflow를 피하면서 요소를 숨길 때는 `display: none` 대신 `visibility: hidden`을 사용하고 [16], 복잡한 렌더링 변화나 애니메이션이 있는 요소는 `position: absolute`나 `position: fixed`를 사용해 문서의 기본 흐름에서 분리해야 합니다 [14].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** `[[Critical Rendering Path]]`, `[[DOM 및 CSSOM]]`, `[[Render Tree]]`, `[[Compositing (GPU 가속)]]`, `[[Virtual DOM]]`
+- **Projects/Contexts:** `[[프론트엔드 성능 최적화 (Web Performance Optimization)]]`, `[[React 컴포넌트 렌더링 아키텍처]]`
+- **Contradictions/Notes:** 소스 간의 상충되는 의견은 없으며, 모든 자료가 일관되게 Reflow와 Repaint의 발생 횟수를 최소화하는 것이 브라우저의 렌더링 성능 및 60 FPS 유지에 필수적이라고 강조합니다 [8, 12, 17, 18]. 
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/Render Tree.md b/10_Wiki/Topics/Frontend_Mastery/Render Tree.md
new file mode 100644
index 00000000..ca200cf5
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/Render Tree.md	
@@ -0,0 +1,25 @@
+# [[Render Tree]]
+
+## 📌 Brief Summary
+렌더 트리(Render Tree)는 웹 브라우저의 렌더링 과정에서 DOM(문서 객체 모델)과 CSSOM(CSS 객체 모델)이 결합하여 만들어지는 구조입니다 [1-3]. 이 트리는 화면에 시각적으로 출력되어야 하는 노드들과 해당 노드들의 계산된 스타일 정보만을 포함합니다 [3-5]. 완성된 렌더 트리는 이후 화면에서 각 요소의 정확한 위치와 크기를 계산하는 레이아웃(Layout) 단계와 실제 픽셀을 그리는 페인트(Paint) 단계의 핵심 입력 데이터로 사용됩니다 [1, 6, 7].
+
+## 📖 Core Content
+* **생성 과정:** 
+  브라우저는 DOM 트리의 루트에서부터 시작하여 화면에 표시되는(visible) 각 노드를 순회하며 렌더 트리를 구성합니다 [3, 5, 8]. 화면에 표시되는 각각의 노드에 대해 브라우저는 CSSOM에서 일치하는 적절한 규칙을 찾아 적용하며, 최종적으로 콘텐츠와 계산된 스타일을 함께 포함하는 렌더 트리를 완성합니다 [4, 5].
+
+* **포함 및 제외 요소의 기준:** 
+  렌더 트리는 시각적 레이아웃에 영향을 미치는 요소들만 포함합니다 [1]. 따라서 `<head>`, `<script>`, `<meta>`와 같이 시각적 정보가 없는 노드들은 렌더 트리에서 제외됩니다 [1, 3, 5, 8]. 또한 CSS에서 `display: none` 속성이 적용된 요소와 그 자식 노드들 역시 화면의 레이아웃 공간을 차지하지 않기 때문에 렌더 트리에서 완전히 누락됩니다 [1, 3, 5, 9]. 반면에 `visibility: hidden` 속성이 적용된 요소는 화면에 보이지는 않지만 여전히 공간을 차지하므로 렌더 트리에는 포함됩니다 [8, 10].
+
+* **렌더링 파이프라인에서의 역할 (레이아웃 및 페인트):** 
+  렌더 트리가 합성되고 나면 브라우저는 이를 바탕으로 각 요소의 기하학적 형태(크기와 위치)를 결정하는 레이아웃(Layout 또는 Reflow) 단계를 진행합니다 [6, 11, 12]. 레이아웃 단계가 완료되면, 렌더 트리의 노드들을 화면의 실제 픽셀로 변환하는 페인트(Paint) 단계가 이어집니다 [13-15]. 
+
+* **성능 최적화 관점:**
+  새로운 노드가 추가되거나, 콘텐츠가 변경되거나, 노드의 박스 모델 스타일이 업데이트되는 등 렌더 트리에 수정이 발생할 때마다 레이아웃(Reflow) 단계가 다시 발생하게 됩니다 [16]. 렌더 트리의 노드 수가 많을수록, 그리고 적용된 스타일이 복잡할수록(예: 단색 배경 대신 그림자 효과 사용 등) 레이아웃과 페인트에 소요되는 시간이 길어지기 때문에 DOM 트리와 CSSOM을 최적화하는 것이 프론트엔드 성능 개선의 핵심입니다 [13, 16, 17].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[DOM]], [[CSSOM]], [[Critical Rendering Path]], [[Layout]], [[Paint]]
+- **Projects/Contexts:** [[브라우저 렌더링 최적화(Browser Rendering Optimization)]], [[프론트엔드 성능 엔지니어링(Frontend Performance Engineering)]]
+- **Contradictions/Notes:** 제공된 소스 간의 모순은 발견되지 않았으며, 모든 자료가 렌더 트리를 'DOM과 CSSOM의 결합이자 화면에 렌더링되는 시각적 요소들만의 집합'으로 일관되게 정의하고 있습니다.
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/SEO 중심의 마케팅 및 블로그 사이트 구축.md b/10_Wiki/Topics/Frontend_Mastery/SEO 중심의 마케팅 및 블로그 사이트 구축.md
new file mode 100644
index 00000000..575fa163
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/SEO 중심의 마케팅 및 블로그 사이트 구축.md	
@@ -0,0 +1,19 @@
+# [[SEO 중심의 마케팅 및 블로그 사이트 구축]]
+
+## 📌 Brief Summary
+SEO 중심의 마케팅 및 블로그 사이트 구축은 검색 엔진 가시성과 빠른 초기 콘텐츠 로딩 속도를 최우선으로 고려하는 렌더링 전략이 필요합니다. 검색 엔진 크롤러가 페이지의 내용을 즉시 수집할 수 있도록 완성된 HTML을 제공하는 서버 사이드 렌더링(SSR)이나 정적 사이트 생성(SSG) 방식이 필수적입니다. 반면, 자바스크립트 실행 전까지 빈 화면을 제공하는 클라이언트 사이드 렌더링(CSR)은 SEO에 불리하므로, 최적의 사용자 경험과 검색 랭킹을 달성하기 위해서는 프로젝트 성격에 맞는 사전 렌더링(Pre-rendering) 및 하이브리드 접근법을 채택해야 합니다.
+
+## 📖 Core Content
+*   **SEO와 렌더링의 관계:** 검색 엔진은 크롤링, 렌더링, 인덱싱의 과정을 거쳐 웹 페이지를 분석합니다. 검색 엔진 봇이 자바스크립트를 실행하는 과정을 기다리지 않고도 콘텐츠, 메타 태그, 구조화된 데이터를 즉시 파악할 수 있도록 서버에서 완성된 형태의 HTML을 제공하는 것이 SEO 및 검색 랭킹 향상의 핵심입니다 [1-3].
+*   **마케팅 사이트 및 블로그를 위한 정적 사이트 생성(SSG):** SSG는 빌드 시점에 모든 페이지의 HTML 파일을 미리 렌더링하여 CDN을 통해 즉각적으로 제공하는 방식입니다 [4, 5]. 변경이 자주 일어나지 않는 블로그 포스트, 문서 페이지, 랜딩 페이지 및 마케팅 웹사이트에 가장 이상적이며, 초고속 로딩 성능과 탁월한 SEO 역량을 제공하여 리드 생성과 고객 확보에 매우 유리합니다 [6-8].
+*   **콘텐츠가 풍부한 사이트를 위한 서버 사이드 렌더링(SSR):** SSR은 사용자의 요청이 있을 때마다 서버에서 HTML을 생성하여 브라우저에 전달합니다 [9, 10]. 항상 최신 상태의 데이터가 반영되어야 하는 뉴스 플랫폼이나 콘텐츠 중심의 웹사이트에 적합하며, 빠른 초기 콘텐츠 페인트(FCP)와 즉각적인 검색 엔진 가시성을 확보할 수 있습니다 [3, 11-13].
+*   **성능과 최신성 균형을 위한 점진적 정적 재생성(ISR):** 대규모 블로그나 콘텐츠 사이트의 경우, ISR을 활용할 수 있습니다. 이는 사전 생성된 정적 페이지의 빠른 로딩 속도를 유지하면서도 백그라운드에서 지정된 주기에 따라 페이지를 재생성하므로, 성능과 콘텐츠 최신성이라는 두 마리 토끼를 모두 잡을 수 있습니다 [14-16].
+*   **클라이언트 사이드 렌더링(CSR)의 한계와 하이브리드 접근:** CSR은 초기 로드 시 빈 HTML 셸과 자바스크립트 리소스만 제공하므로 검색 엔진 크롤러가 콘텐츠를 놓치거나 인덱싱이 지연될 수 있어 순수 마케팅 사이트에는 부적합합니다 [17-20]. 하지만 Next.js와 같은 최신 프레임워크를 사용하면, 메인 홈페이지나 블로그 글에는 SSG나 SSR을 적용해 SEO를 챙기고, 댓글 섹션이나 개인화된 대시보드같이 상호작용이 중요한 부분에는 CSR을 적용하는 하이브리드(Hybrid) 렌더링 방식을 채택하여 페이지별로 렌더링 전략을 최적화할 수 있습니다 [21-23].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Server-Side Rendering (SSR)]], [[Static Site Generation (SSG)]], [[Incremental Static Regeneration (ISR)]], [[Client-Side Rendering (CSR)]]
+- **Projects/Contexts:** [[Next.js 기반 하이브리드 렌더링 프레임워크 도입]], [[대규모 콘텐츠 플랫폼 구조 설계]]
+- **Contradictions/Notes:** 소스에 따르면, CSR 방식은 앱과 같은 동적이고 매끄러운 상호작용을 제공하는 데는 유리하지만, SEO 최적화 측면에서는 빈 페이지 인식으로 인한 크롤링 지연 및 인덱싱 누락 위험이라는 치명적인 단점이 존재합니다. 따라서 SEO가 필수적인 마케팅 및 블로그 사이트에서는 반드시 SSR이나 SSG를 주력으로 사용하거나 병행해야 합니다.
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/SPA (Single Page Application).md b/10_Wiki/Topics/Frontend_Mastery/SPA (Single Page Application).md
new file mode 100644
index 00000000..91cbc428
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/SPA (Single Page Application).md	
@@ -0,0 +1,18 @@
+# [[SPA (Single Page Application)]]
+
+## 📌 Brief Summary
+SPA(Single Page Application)는 주로 클라이언트 측 렌더링(CSR) 방식을 사용하여 구축되는 웹 애플리케이션 형태입니다 [1, 2]. 초기 로드 시 서버로부터 전체 페이지를 받아오는 대신 최소한의 뼈대만 포함된 단일 HTML을 로드하고, 이후에는 JavaScript를 이용해 브라우저 내에서 동적으로 콘텐츠와 라우팅을 생성합니다 [2, 3]. 이를 통해 매번 페이지를 새로고침할 필요 없이 부드럽고 '앱과 같은(app-like)' 사용자 경험을 제공하는 것이 특징입니다 [4, 5].
+
+## 📖 Core Content
+- **렌더링 방식 및 작동 원리:** SPA는 클라이언트 측 렌더링(CSR) 환경과 뗄 수 없는 관계를 갖습니다 [1, 2]. 사용자가 SPA에 접속하면 브라우저는 헤더, 푸터, 내비게이션 바 등 반복되는 요소가 포함된 뼈대 수준의 최소 HTML과 JavaScript 번들을 다운로드합니다 [2, 3, 5, 6]. 초기 로드 이후에는 서버로부터 새로운 전체 페이지를 요청하지 않으며, JavaScript가 데이터를 동적으로 가져와 브라우저 내에서 인터페이스를 직접 구축하고 경로(Route)를 생성합니다 [3, 5, 6].
+- **성능적 이점 및 장점:** 전체 페이지를 다시 로드할 때 발생하는 끊김 현상을 없애고, 필요한 데이터만 서버에서 받아 현재 페이지를 동적으로 덮어쓰기 때문에 매우 유동적이고 즉각적인 반응성을 제공합니다 [5, 7]. 또한, HTML, CSS, JavaScript 파일만 서비스할 수 있는 정적 서버만으로도 호스팅이 가능하여 고비용의 서버 인프라에 대한 의존도 및 호스팅 비용을 크게 줄일 수 있습니다 [8]. 
+- **한계점 및 단점:** 사용자가 첫 화면을 보기 전에 브라우저가 모든 JavaScript 코드를 다운로드하고 파싱 및 실행해야 하므로 초기 로딩 속도(First Contentful Paint)가 상대적으로 느립니다 [4, 9, 10]. 또한 처음 서버에서 제공하는 HTML이 거의 비어 있기 때문에, JavaScript를 원활하게 실행하지 못하는 검색 엔진 크롤러에게는 콘텐츠가 보이지 않아 검색 엔진 최적화(SEO) 측면에서 한계가 있습니다 [4, 9, 11, 12].
+- **주요 사용 사례:** SEO가 최우선 고려 사항이 아니고 풍부한 상호작용과 실시간 데이터 업데이트가 중요한 환경에 가장 적합합니다 [13, 14]. 주로 로그인 장벽 뒤에 있는 사용자 대시보드, 내부 비즈니스 도구, SaaS(Software as a Service) 플랫폼 등의 구축에 활용되며, React, Vue.js, Angular와 같은 최신 프레임워크가 SPA 구축에 널리 사용됩니다 [6, 13-16].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Client-Side Rendering (CSR)]], [[First Contentful Paint (FCP)]], [[Search Engine Optimization (SEO)]], [[React]], [[Document Object Model (DOM)]]
+- **Projects/Contexts:** [[SaaS 플랫폼]], [[사용자 대시보드]], [[내부 비즈니스 도구]]
+- **Contradictions/Notes:** 소스는 SPA 및 CSR 방식이 상호작용성이 뛰어난 데 반해 SEO와 초기 로딩 속도에 약점을 가지고 있다고 지적합니다. 따라서 검색 노출이 중요한 마케팅 페이지나 블로그, 전자상거래 사이트 등에서는 순수 SPA(CSR) 대신 SSR(Server-Side Rendering)이나 SSG(Static Site Generation) 방식을 적용하거나 혼합(Hybrid)하여 사용하는 것이 권장됩니다 [11, 13, 17, 18].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/Search Engine Optimization (SEO).md b/10_Wiki/Topics/Frontend_Mastery/Search Engine Optimization (SEO).md
new file mode 100644
index 00000000..e3cbfd3f
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/Search Engine Optimization (SEO).md	
@@ -0,0 +1,19 @@
+# [[Search Engine Optimization (SEO)]]
+
+## 📌 Brief Summary
+검색 엔진 최적화(SEO)는 검색 엔진 크롤러가 웹 페이지의 콘텐츠를 효율적으로 크롤링하고 색인(인덱싱)하여 검색 결과에서의 가시성과 순위를 향상시키는 과정입니다 [1-3]. 웹사이트의 렌더링 방식(SSR, SSG, CSR 등)에 따라 검색 엔진이 완전한 HTML 및 메타데이터에 접근하는 속도가 달라지므로, SEO 성과는 애플리케이션의 렌더링 전략 및 아키텍처와 매우 밀접하게 연관되어 있습니다 [4-7].
+
+## 📖 Core Content
+*   **렌더링 방식이 SEO에 미치는 영향:** 검색 엔진의 색인 과정은 크롤링, 렌더링, 색인의 3단계로 이루어지며, 웹사이트가 어떤 렌더링 기술을 사용하는지가 콘텐츠의 빠르고 정확한 색인을 결정짓는 핵심 요소가 됩니다 [3].
+*   **서버 사이드 렌더링(SSR)의 SEO 이점:** SSR은 초기 요청 시 서버에서 완전히 렌더링된 HTML을 브라우저에 제공하므로 SEO에 매우 유리합니다 [5, 8-10]. 검색 엔진 크롤러가 자바스크립트 실행을 기다릴 필요 없이 페이지의 전체 콘텐츠, 메타 태그, 구조화된 데이터를 즉시 확인하고 색인할 수 있어 검색 가시성이 크게 향상됩니다 [1, 2, 11]. 유기적 트래픽 확보가 필수적인 뉴스 사이트나 이커머스 제품 페이지에 이상적입니다 [12, 13].
+*   **정적 사이트 생성(SSG)과 하이브리드 방식:** SSG 역시 빌드 타임에 사전 렌더링된 HTML을 제공하므로 SSR과 마찬가지로 우수한 SEO 성능을 보장하며, 즉각적인 로딩 속도와 결합되어 가장 SEO 친화적인 방식 중 하나로 평가받습니다 [6, 7, 14, 15]. ISR(점진적 정적 재생성)을 활용하면 SEO 친화성을 유지하면서도 최신 콘텐츠로 업데이트가 가능합니다 [16].
+*   **클라이언트 사이드 렌더링(CSR)의 SEO 한계:** CSR 환경에서는 초기에 최소한의 HTML 셸만 제공되고 자바스크립트가 실행된 후에야 실제 콘텐츠가 그려지기 때문에 SEO에 불리합니다 [17-20]. 최근 검색 엔진의 자바스크립트 처리 능력이 개선되었으나, 여전히 색인이 지연되거나 중요한 콘텐츠 및 메타 태그(제목, 설명, `og:image` 등)가 누락될 위험이 존재합니다 [4, 7, 17].
+*   **SEO 최적화를 위한 모범 사례:** SEO가 중요하다면 순수 CSR을 피하고, SSR이나 SSG를 기반으로 한 렌더링 전략을 채택해야 합니다 [6, 21]. 메타데이터와 Open Graph 태그, 구조화된 데이터를 적극적으로 활용해 사전 렌더링의 이점을 극대화해야 하며, SEO가 필수적인 마케팅 페이지에는 SSG/SSR을 적용하고, 비공개 대시보드처럼 상호작용이 중요한 영역에는 CSR을 적용하는 하이브리드 접근법을 사용하는 것이 좋습니다 [22, 23].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Server-Side Rendering (SSR)]], [[Client-Side Rendering (CSR)]], [[Static Site Generation (SSG)]]
+- **Projects/Contexts:** [[Next.js]], [[Nuxt.js]]
+- **Contradictions/Notes:** 검색 엔진이 자바스크립트를 크롤링하는 능력이 과거보다 향상되었음에도 불구하고, 여전히 CSR 환경에서는 초기 빈 페이지 노출 문제로 인해 렌더링 및 색인 지연이 발생할 수 있으므로 SEO 최적화를 위해서는 서버 기반 렌더링 방식이 훨씬 더 안정적이고 권장됩니다 [4, 7, 17].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/Static Site Generation (SSG).md b/10_Wiki/Topics/Frontend_Mastery/Static Site Generation (SSG).md
new file mode 100644
index 00000000..9adfc3dc
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/Static Site Generation (SSG).md	
@@ -0,0 +1,19 @@
+# [[Static Site Generation (SSG)]]
+
+## 📌 Brief Summary
+Static Site Generation (SSG)은 사용자가 페이지를 요청하기 전인 애플리케이션의 빌드(Build) 타임에 전체 웹사이트의 HTML을 미리 생성하는 렌더링 방식입니다 [1-3]. 빌드 시 생성된 정적 파일들은 콘텐츠 전송 네트워크(CDN)를 통해 배포되며, 사용자의 요청이 있을 때 런타임에서의 추가적인 서버 연산 없이 즉각적으로 제공됩니다 [3-5]. 뛰어난 성능과 검색 엔진 최적화(SEO) 이점을 제공하여, 블로그나 마케팅 페이지처럼 콘텐츠가 자주 변경되지 않는 웹사이트에 이상적인 전략입니다 [2, 5-7].
+
+## 📖 Core Content
+- **작동 원리**: 애플리케이션을 배포하기 위한 빌드 과정에서 각 페이지를 구성하는 완전한 HTML 파일이 생성됩니다 [2, 3]. 방문자가 웹사이트를 요청하면 서버는 페이지를 실시간으로 다시 생성하거나 데이터를 새로 가져오는 대신, 이미 만들어진 정적 HTML 파일을 그대로 전송합니다 [2, 3, 8].
+- **성능 및 SEO 최적화**: 서버 측의 연산과 데이터베이스 조회가 생략되므로 초기 로드 시간과 첫 바이트 도달 시간(TTFB)이 모든 렌더링 방식 중 가장 빠릅니다 [4, 5, 8, 9]. 또한, 검색 엔진 크롤러가 자바스크립트의 실행을 기다릴 필요 없이 완전히 렌더링된 HTML을 즉시 읽을 수 있어 뛰어난 SEO 성능과 LCP(Largest Contentful Paint) 점수를 달성할 수 있습니다 [6, 10, 11].
+- **주요 장점**: 생성된 정적 파일은 CDN을 통해 글로벌하게 캐싱되어 서비스되므로, 무한대에 가까운 트래픽 확장이 가능하며 호스팅 비용을 크게 줄일 수 있습니다 [5, 12, 13]. 작동 중인 라이브 서버나 데이터베이스와 직접 연결되지 않으므로 공격 대상이 될 표면이 없어 보안성 또한 극대화됩니다 [5].
+- **한계 및 단점**: 빌드 시점에 콘텐츠가 고정되므로, 실시간 데이터(예: 라이브 스코어, 맞춤형 대시보드)가 필요한 서비스에서는 데이터가 쉽게 구식(stale)이 되는 한계가 있습니다 [5, 12, 14]. 콘텐츠를 수정하거나 업데이트하려면 사이트 전체를 다시 빌드하고 배포해야 하며, 페이지 수가 수천 개 이상인 대규모 사이트의 경우 빌드 시간이 지나치게 길어질 수 있습니다 [5, 14, 15].
+- **활용 사례**: 콘텐츠의 변경 빈도가 낮고 사용자마다 동일한 정보를 보여주는 문서(Documentation) 사이트, 블로그, 포트폴리오, 마케팅 웹사이트 및 안정적인 제품 카탈로그 페이지에 완벽하게 부합합니다 [2, 5-7, 16].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Client-Side Rendering (CSR)]], [[Server-Side Rendering (SSR)]], [[Incremental Static Regeneration (ISR)]], [[Content Delivery Network (CDN)]], [[Search Engine Optimization (SEO)]]
+- **Projects/Contexts:** Next.js, Gatsby, Qwik과 같이 정적 사이트 생성을 특화 지원하는 프레임워크 환경 [2, 8, 17] 및 블로그, 문서화 플랫폼 구축 맥락 [2, 5-7].
+- **Contradictions/Notes:** 소스 전반에 걸쳐 모순되는 주장은 없으나, SSG의 압도적인 로드 속도 이면에는 '실시간 동적 데이터 처리의 어려움'과 '잦은 콘텐츠 업데이트 시 빌드 비용 증가'라는 명확한 트레이드오프가 존재함이 공통으로 지적됩니다 [5, 14]. 이를 보완하기 위해, 전체 사이트를 다시 빌드하지 않고도 특정 주기나 조건에 따라 백그라운드에서 정적 페이지를 업데이트하는 [[Incremental Static Regeneration (ISR)]] 기술을 SSG와 혼합하여 사용하는 대안이 폭넓게 채택되고 있습니다 [4, 6, 12, 18].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/“React가 빠른 이유” 및 렌더링 최적화 개념.md b/10_Wiki/Topics/Frontend_Mastery/“React가 빠른 이유” 및 렌더링 최적화 개념.md
new file mode 100644
index 00000000..7b8304e0
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/“React가 빠른 이유” 및 렌더링 최적화 개념.md	
@@ -0,0 +1,30 @@
+# [[“React가 빠른 이유” 및 렌더링 최적화 개념]]
+
+## 📌 Brief Summary
+React가 빠른 핵심 이유는 브라우저의 무거운 실제 DOM 조작을 최소화하기 위해 가벼운 메모리 내 표현인 Virtual DOM을 사용하고, 효율적인 Reconciliation(조정) 알고리즘을 통해 변경된 부분만 갱신하기 때문입니다 [1-4]. 렌더링 최적화의 근본적인 목표는 연산 비용이 높은 브라우저의 Reflow(레이아웃)와 Repaint를 줄이는 것이며 [5-7], 최근 React는 Fiber 아키텍처, 자동 배칭(Automatic Batching), React Compiler 등을 도입하여 개발자의 수동 개입 없이도 동시성 렌더링과 메모이제이션을 자동화해 UI 성능을 극대화하고 있습니다 [8-11].
+
+## 📖 Core Content
+
+**브라우저 렌더링 과정 (Critical Rendering Path) 및 병목**
+브라우저는 HTML을 파싱하여 DOM(Document Object Model)을 구축하고, CSS를 파싱하여 CSSOM을 만든 뒤 이 둘을 결합하여 화면에 보일 요소들만 포함하는 렌더 트리(Render Tree)를 생성합니다 [12-15]. 이 트리를 바탕으로 각 요소의 정확한 크기와 위치를 계산하는 Layout(또는 Reflow) 단계를 거쳐, 최종적으로 화면에 픽셀을 그리는 Paint(또는 Repaint) 작업을 수행합니다 [5, 16-20]. 요소의 너비, 높이, 위치 등을 변경하면 전체 페이지의 레이아웃을 다시 계산해야 하는 Reflow가 발생하며, 이는 매우 연산 비용이 높고 렌더링 성능 저하의 주된 원인이 됩니다 [5, 6, 21, 22].
+
+**Virtual DOM과 Reconciliation (조정 알고리즘)**
+직접적인 DOM 조작의 비효율성을 극복하기 위해 React는 Virtual DOM(VDOM)이라는 가상의 UI 트리를 메모리에 유지합니다 [1, 2, 4]. 상태가 변경되면 React는 새로운 Virtual DOM을 생성하고 이전 트리와 비교(Diffing)합니다 [2, 23]. React의 조정 알고리즘은 O(n)의 시간 복잡도를 가지며, "서로 다른 타입의 요소는 다른 트리를 생성한다"는 가정과 리스트 렌더링 시 `key` 속성을 사용하여 변경, 추가, 삭제된 최소한의 노드만 식별해 실제 DOM에 패치(Patch)합니다 [1, 3, 24-26]. 이를 통해 불필요한 Reflow와 Repaint를 방지합니다.
+
+**Fiber 아키텍처와 우선순위 기반 스케줄링**
+React 16부터 도입된 Fiber 아키텍처는 동기식 렌더링의 한계를 해결하기 위해 렌더링 작업을 'Fiber 노드'라는 작은 작업 단위로 나눕니다 [8, 27-30]. 이 구조는 '타임 슬라이싱(Time-Slicing)'을 가능하게 하여, 렌더링 도중에도 사용자 입력이나 애니메이션 같은 긴급한 작업(Sync Lane)이 발생하면 기존 작업을 중단(Pause) 및 양보(Yield)하고 우선순위가 높은 작업을 먼저 처리할 수 있도록 돕습니다 [27, 30-34]. 그 결과 메인 스레드 차단을 막아 끊김 없는 UI(동시성 렌더링)를 제공합니다.
+
+**React 최신 버전의 자동 렌더링 최적화**
+*   **자동 배칭 (Automatic Batching):** React 18은 이벤트 핸들러뿐만 아니라 Promise, setTimeout 등 모든 출처에서 발생하는 상태 업데이트를 묶어서 단 한 번의 리렌더링으로 처리합니다 [9, 35-38]. 이로 인해 Virtual DOM 디핑 연산과 실제 DOM 업데이트 횟수가 크게 줄어듭니다.
+*   **React Compiler:** React 19에서 도입된 컴파일러는 빌드 타임에 코드의 AST(추상 구문 트리)를 분석하여 정적 값과 반응형 값을 식별하고 자동으로 메모이제이션을 삽입합니다 [10, 39-41]. 이는 상위 컴포넌트의 상태 변경으로 인한 하위 컴포넌트의 연쇄 리렌더링(Re-render Cascade)을 차단하며, 개발자가 직접 `useMemo`나 `useCallback`을 작성하는 수고를 덜어줍니다 [10, 11, 42-44].
+
+**서버 컴포넌트 (React Server Components, RSC)**
+기존 CSR(클라이언트 사이드 렌더링)이나 SSR(서버 사이드 렌더링) 환경에서는 클라이언트가 결국 방대한 크기의 JavaScript 번들을 다운로드하고 실행(Hydration)해야 하는 부담이 있었습니다 [45-48]. React Server Components는 서버에서 컴포넌트를 실행한 뒤 직렬화된 UI와 HTML만을 클라이언트로 스트리밍합니다 [49-51]. 결과적으로 서버 컴포넌트는 클라이언트 측 자바스크립트 번들에 0바이트를 추가하며, 브라우저의 다운로드 및 실행 부담을 없애 무거운 데이터 연산이나 정적 UI 렌더링 속도를 극대화합니다 [49, 51-53].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** `[[Virtual DOM]]`, `[[Reconciliation]]`, `[[Critical Rendering Path]]`, `[[React Fiber]]`, `[[Hydration]]`, `[[Reflow and Repaint]]`
+- **Projects/Contexts:** `[[React 18 Automatic Batching]]`, `[[React 19 Compiler]]`, `[[React Server Components]]`, `[[Next.js Rendering Strategies]]`
+- **Contradictions/Notes:** 이전까지는 불필요한 렌더링을 막기 위해 개발자가 `useMemo`, `useCallback`, `React.memo`를 사용한 수동 메모이제이션을 구현하는 것이 필수적인 최적화 기법이었습니다 [43, 54, 55]. 그러나 React 19 컴파일러의 등장으로 이러한 수동 메모이제이션의 90% 이상이 불필요해졌으며, 컴파일러가 최적의 메모이제이션 경계를 자동으로 판단하여 적용합니다 [10, 44, 56, 57]. 단, 타사 라이브러리(Third-party library)가 렌더링마다 불안정한 참조를 반환하는 경우 컴파일러 최적화가 실패할 수 있어, 여전히 제한적인 상황에서는 수동 제어가 필요할 수 있습니다 [58, 59].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/단일 페이지 애플리케이션(SPA) UI 성능 관리.md b/10_Wiki/Topics/Frontend_Mastery/단일 페이지 애플리케이션(SPA) UI 성능 관리.md
new file mode 100644
index 00000000..eb9a36bb
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/단일 페이지 애플리케이션(SPA) UI 성능 관리.md	
@@ -0,0 +1,29 @@
+# [[단일 페이지 애플리케이션(SPA) UI 성능 관리]]
+
+## 📌 Brief Summary
+단일 페이지 애플리케이션(SPA)은 클라이언트 사이드 렌더링(CSR)을 기반으로 동작하여 동적이고 부드러운 상호작용을 제공하지만, 초기 로드 속도가 느리고 자바스크립트 실행 비용이 크다는 단점이 있습니다 [1-4]. SPA UI 성능 관리는 브라우저의 중요 렌더링 경로(CRP)를 이해하여 비용이 큰 리플로우(Reflow)와 리페인트(Repaint)를 최소화하는 과정을 포함합니다 [5-7]. 또한, React와 같은 프레임워크의 가상 DOM(Virtual DOM) 구조, 자동 배칭(Automatic Batching), 동시성 렌더링 및 메모이제이션(Memoization) 기술을 활용해 불필요한 재렌더링을 방지함으로써 메인 스레드 차단을 막고 매끄러운 사용자 경험을 유지하는 것을 핵심 목적으로 합니다 [8-11].
+
+## 📖 Core Content
+
+**SPA와 CSR의 성능적 특징**
+SPA는 클라이언트 사이드 렌더링(CSR)을 사용하여 브라우저가 최소한의 HTML을 받은 후 자바스크립트를 통해 동적으로 UI를 구성합니다 [1, 3, 12]. 이는 매끄러운 화면 전환과 풍부한 상호작용을 제공하지만, 사용자가 첫 화면을 보기 전(FCP)에 대규모 자바스크립트 번들을 다운로드하고 실행해야 하므로 초기 로딩 속도가 느리고 기기 성능에 의존하게 된다는 단점이 있습니다 [2, 4, 13].
+
+**브라우저 렌더링 경로(CRP) 최적화**
+화면에 UI를 렌더링하기 위해 브라우저는 HTML과 CSS를 파싱해 각각 DOM과 CSSOM 트리를 생성하고, 이를 결합하여 렌더 트리(Render Tree)를 만듭니다 [5, 14, 15]. 이후 화면 내 요소의 크기와 위치를 계산하는 레이아웃(Reflow) 과정과 픽셀을 그리는 페인트(Repaint) 과정을 거칩니다 [15-17]. 성능 최적화를 위해 리플로우를 유발하는 DOM 조작(너비, 높이, 마진 등 변경)을 최소화하고, DOM 업데이트를 일괄 처리해야 합니다 [7, 18-20]. 또한 애니메이션 처리 시 `transform`과 같은 속성을 사용해 GPU 가속을 활용함으로써 렌더링 파이프라인의 병목을 줄여야 합니다 [20-22].
+
+**가상 DOM과 메모이제이션(Memoization) 기법**
+직접적인 DOM 조작의 비효율성을 극복하기 위해 React는 가상 DOM(Virtual DOM)을 활용하여 실제 DOM과 동기화하는 휴리스틱 O(n) 알고리즘(Reconciliation)을 사용합니다 [8, 23-25]. 하지만 부모 컴포넌트의 상태가 변경되면 하위 트리의 모든 컴포넌트가 불필요하게 렌더링되는 '연쇄 재렌더링(Re-render Cascade)' 문제가 발생할 수 있습니다 [26-28]. 이를 방지하기 위해 얕은 비교를 수행하는 `React.memo`와 안정적인 참조를 유지하는 `useMemo`, `useCallback`을 선별적으로 적용해야 합니다 [29, 30]. 최신 React 19 컴파일러는 빌드 타임에 AST(Abstract Syntax Tree)를 분석하여 이러한 메모이제이션을 자동으로 삽입, 개발자의 수동 최적화 부담을 줄여줍니다 [31-33].
+
+**자동 배칭 및 동시성(Concurrent) 기능 활용**
+React 18에 도입된 자동 배칭(Automatic Batching)은 타이머, 프로미스, 네이티브 이벤트 핸들러 등에서 발생하는 여러 상태 업데이트를 단일 재렌더링 작업으로 묶어주어 불필요한 DOM 업데이트 횟수를 크게 줄입니다 [9, 10, 34, 35]. 더불어 `useTransition` 및 `useDeferredValue`와 같은 동시성 기능을 활용하면 무거운 계산 작업보다 사용자 입력과 같은 긴급한 UI 업데이트를 우선적으로 처리할 수 있어 애플리케이션의 반응성(INP)을 획기적으로 높일 수 있습니다 [36-39].
+
+**자원 및 번들 최적화**
+초기 로드 속도를 단축하기 위해 `React.lazy()`를 활용한 라우트 수준의 코드 스플리팅(Code Splitting)으로 자바스크립트 번들 크기를 줄이는 것이 중요합니다 [40]. 또한 100개 이상의 긴 목록을 렌더링할 때는 화면에 보이는 항목의 DOM 노드만 생성하는 가상화(Virtualization) 기술을 적용하면 렌더링 시간을 수 초에서 즉시 수준으로 단축할 수 있으며 [41, 42], DOM 트리 깊이를 줄이기 위해 불필요한 래퍼 대신 `React.Fragment`를 사용하는 것도 렌더링 효율을 높이는 방법입니다 [43-45].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[클라이언트 사이드 렌더링(CSR)]], [[Critical Rendering Path (CRP)]], [[가상 DOM과 Reconciliation]], [[Reflow 및 Repaint 최적화]]
+- **Projects/Contexts:** [[React Compiler를 활용한 메모이제이션 자동화]], [[React 18 자동 배칭 및 Concurrent 기능 적용]], [[긴 목록 렌더링 가상화(Virtualization)]]
+- **Contradictions/Notes:** 소스 [30]은 모든 컴포넌트에 무조건적인 수동 메모이제이션(useMemo 등)을 적용하는 것은 오버헤드를 발생시켜 오히려 성능을 떨어뜨릴 수 있으므로 프로파일링을 통한 선별적 적용을 주장합니다. 그러나 소스 [11, 46, 47]에 따르면 React 19 컴파일러의 등장으로 이러한 수동 메모이제이션 방식 자체가 구식이 되어가고 있으며, 컴파일러가 최적의 메모이제이션 지점을 자동으로 판단하므로 개발자는 복잡한 최적화 작업의 90%를 덜어낼 수 있다고 설명합니다.
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/대규모 이커머스 플랫폼 렌더링 설계.md b/10_Wiki/Topics/Frontend_Mastery/대규모 이커머스 플랫폼 렌더링 설계.md
new file mode 100644
index 00000000..f9ccba80
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/대규모 이커머스 플랫폼 렌더링 설계.md	
@@ -0,0 +1,18 @@
+# [[대규모 이커머스 플랫폼 렌더링 설계]]
+
+## 📌 Brief Summary
+대규모 이커머스 플랫폼 렌더링 설계는 검색 엔진 최적화(SEO), 빠른 초기 콘텐츠 로딩, 그리고 빈번하게 변경되는 재고 및 가격 데이터의 실시간 반영을 모두 만족시키기 위한 아키텍처 구성 과정입니다 [1-3]. 이를 위해 서버 사이드 렌더링(SSR), 점진적 정적 재생성(ISR), React 서버 컴포넌트(RSC) 등의 전략을 혼합하여 서버 부하와 클라이언트의 부담을 최적의 상태로 분산시킵니다 [3-5]. 최신 아키텍처에서는 무거운 자바스크립트 번들 사이즈를 줄이고 병렬 데이터를 처리하기 위해 서버 중심의 렌더링 모델을 적극 채택하는 추세입니다 [6-8].
+
+## 📖 Core Content
+- **SSR을 활용한 제품 탐색 및 전환율 최적화:** 이커머스 플랫폼에서 제품 목록 페이지(PLP)나 상세 페이지(PDP)는 강력한 검색 엔진 노출이 필수적이므로 SSR이 이상적입니다 [1, 9]. 브라우저에 완전한 형태의 HTML을 서버에서 렌더링하여 제공함으로써, 사용자는 자바스크립트 로딩을 기다릴 필요 없이 즉각적으로 제품 상세 정보와 가격을 확인하고 쇼핑을 시작할 수 있어 전환율 상승으로 이어집니다 [1, 10].
+- **대규모 카탈로그를 위한 정적 사이트 생성(SSG) 및 점진적 재생성(ISR):** 수천 개의 제품 카탈로그를 보유한 이커머스 플랫폼은 동적 렌더링의 서버 부하를 줄이기 위해 ISR을 활용합니다 [2]. ISR은 초기 빌드 시 정적 파일(SSG)로 빠른 속도를 보장하면서도 지정된 인터벌이나 콘텐츠 업데이트 시 백그라운드에서 페이지를 재생성하여 빈번한 재고 및 가격 변동을 관리하는 데 완벽한 균형을 제공합니다 [2, 3, 11, 12]. 반면, 상품 라인이 변하지 않는 경우에는 SSG를 사용하는 것이 유리합니다 [13].
+- **React 서버 컴포넌트(RSC)를 통한 클라이언트 복잡성 및 병렬성 개선:** 읽기 전용 데이터 디스플레이(제품 카탈로그 등) 영역을 서버 컴포넌트로 전환하면 클라이언트 자바스크립트 번들을 40~60%가량 감소시킬 수 있습니다 [6]. RSC는 서버 내에서 병렬적인 데이터 패칭을 지원하기 때문에, 클라이언트 측에서 흔히 발생하는 순차적 데이터 로딩의 폭포수 현상(Waterfall)을 근본적으로 제거하여 체감 지연 시간을 크게 줄여줍니다 [8, 14].
+- **인터랙티브 요소를 위한 하이브리드 접근법:** 제품 페이지나 마케팅 섹션에는 SSR, SSG 또는 ISR을 적용하지만, 높은 수준의 실시간 상호작용이 필요한 장바구니, 결제(Checkout) 프로세스, 로그인된 사용자 대시보드 등의 기능에는 클라이언트 사이드 렌더링(CSR) 또는 클라이언트 컴포넌트를 혼합 적용하여 빠르고 유연한 앱 같은 경험을 제공해야 합니다 [5, 15].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Server-Side Rendering (SSR)]], [[Incremental Static Regeneration (ISR)]], [[React Server Components (RSC)]], [[Client-Side Rendering (CSR)]]
+- **Projects/Contexts:** [[Next.js 기반 하이브리드 렌더링 아키텍처]]
+- **Contradictions/Notes:** 일반적으로 SSR은 가장 빠른 콘텐츠 노출(FCP)을 제공하지만 하이드레이션(Hydration) 대기 시간으로 인해 TTI(Time to Interactive)가 지연되는 단점이 존재합니다 [16, 17]. 그러나 최근의 React 서버 컴포넌트(RSC)를 활용하면 브라우저로 자바스크립트 자체를 전송하지 않아 하이드레이션 과정을 완전히 생략할 수 있으므로, 이러한 성능적 페널티를 근본적으로 회피할 수 있습니다 [18, 19].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/브라우저 렌더링 과정.md b/10_Wiki/Topics/Frontend_Mastery/브라우저 렌더링 과정.md
new file mode 100644
index 00000000..e8c88d96
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/브라우저 렌더링 과정.md	
@@ -0,0 +1,20 @@
+# [[브라우저 렌더링 과정]]
+
+## 📌 Brief Summary
+브라우저 렌더링 과정(중요 렌더링 경로, Critical Rendering Path)은 브라우저가 HTML, CSS, JavaScript를 화면의 실제 픽셀로 변환하기 위해 거치는 일련의 단계입니다 [1]. 이 과정은 문서 객체 모델(DOM) 및 CSS 객체 모델(CSSOM) 생성, 렌더 트리 구축, 레이아웃 연산, 그리고 화면에 픽셀을 그리는 페인트 단계로 구성됩니다 [1-3]. 프론트엔드 개발자는 이 과정을 이해하고 최적화함으로써 초기 렌더링 속도를 높이고 원활한 사용자 상호작용을 보장할 수 있습니다 [4, 5].
+
+## 📖 Core Content
+*   **DOM(Document Object Model) 구축**: 브라우저가 서버로부터 HTML 응답을 받으면 바이트를 문자, 토큰, 노드로 변환하여 DOM 트리를 점진적으로 구축합니다 [6, 7]. 초기 14KB의 데이터(첫 TCP 패킷)만 수신해도 트리 구축을 시작할 수 있지만, 노드의 수가 많아질수록 후속 렌더링 단계에 소요되는 시간이 길어집니다 [6-9].
+*   **CSSOM(CSS Object Model) 구축**: HTML 파싱과 달리 CSS 구문 분석은 점진적이지 않으며 렌더링을 차단(Render-blocking)하는 작업입니다 [8, 10]. 브라우저는 스타일이 지정되지 않은 콘텐츠가 깜빡이는 현상(FOUC)을 방지하기 위해 연결된 모든 스타일시트를 다운로드하고 구문 분석하여 CSSOM을 완성할 때까지 렌더 트리의 구성을 차단합니다 [8, 10].
+*   **렌더 트리(Render Tree) 생성**: DOM과 CSSOM이 모두 준비되면 브라우저는 이 둘을 결합하여 화면에 표시될 렌더 트리를 생성합니다 [11-13]. 렌더 트리는 가시적인 콘텐츠와 계산된 스타일 정보만을 포함하므로, `<head>` 태그 내부 요소나 `display: none` 스타일이 적용된 노드는 렌더 트리에서 제외됩니다 [11-14].
+*   **레이아웃(Layout) 및 리플로우(Reflow)**: 렌더 트리가 구성되면 기기 뷰포트의 크기와 박스 모델을 기반으로 화면에 표시될 각 요소의 정확한 기하학적 위치와 크기(너비, 높이 등)를 계산합니다 [15-17]. 창 크기를 조절하거나 JavaScript로 요소의 크기 및 위치를 조작할 때 이 위치를 다시 계산하는 연산이 발생하는데, 이를 '리플로우(Reflow)'라고 부르며 연산 비용이 매우 높습니다 [15, 18, 19].
+*   **페인트(Paint)와 리페인트(Repaint)**: 레이아웃 계산이 끝나면 브라우저는 기하학적 구조와 스타일을 바탕으로 텍스트, 색상, 그림자 등의 시각적 요소를 실제 픽셀로 화면에 그립니다 [20-22]. 배경색이나 가시성 등 레이아웃에 영향을 주지 않는 시각적 속성만 변경될 때는 위치 계산을 생략하고 픽셀만 다시 그리는 '리페인트(Repaint)' 작업이 발생합니다 [18, 23]. 
+*   **합성(Compositing)**: 페이지의 여러 레이어를 결합하여 단일 이미지로 만드는 최종 단계입니다 [20, 24]. 최신 브라우저는 60FPS의 성능을 유지하기 위해 변환(`transform`)이나 불투명도(`opacity`) 같은 특정 전환 애니메이션 작업을 CPU가 아닌 GPU 연산으로 오프로드(Hardware Acceleration)하여 성능을 최적화합니다 [20, 25, 26].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Critical Rendering Path]], [[DOM 및 CSSOM]], [[Reflow 및 Repaint]]
+- **Projects/Contexts:** [[프론트엔드 성능 최적화(Frontend Performance Optimization)]], [[초기 로딩 속도 개선(LCP 최적화)]]
+- **Contradictions/Notes:** 소스 간의 특별한 모순점은 없으나, DOM 구축은 점진적(Incremental)으로 진행되어 데이터를 수신하는 즉시 파싱을 시작할 수 있는 반면, CSSOM은 규칙이 나중에 덮어씌워질 수 있다는 CSS의 특성 때문에 전체 파싱이 완료될 때까지 렌더링을 완전히 차단한다는 구조적 차이점이 명확히 대조됩니다 [6-8, 10].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/브라우저 메인 스레드 최적화 및 타임 슬라이싱.md b/10_Wiki/Topics/Frontend_Mastery/브라우저 메인 스레드 최적화 및 타임 슬라이싱.md
new file mode 100644
index 00000000..4b803ded
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/브라우저 메인 스레드 최적화 및 타임 슬라이싱.md	
@@ -0,0 +1,26 @@
+# [[브라우저 메인 스레드 최적화 및 타임 슬라이싱]]
+
+## 📌 Brief Summary
+브라우저 메인 스레드 최적화 및 타임 슬라이싱은 단일 스레드로 동작하는 브라우저의 특성상 발생할 수 있는 UI 멈춤(Jank) 현상을 방지하고 상호작용성을 높이기 위한 아키텍처 접근 방식입니다 [1, 2]. 거대한 렌더링 작업을 중단 불가능한 하나의 동기적 작업으로 처리하는 대신, 타임 슬라이싱을 통해 작업을 작은 청크(단위)로 분할합니다 [1, 3]. 이를 통해 메인 스레드는 무거운 렌더링 작업을 중간에 일시 중지하고 사용자 입력과 같은 긴급한 고우선순위 작업을 먼저 처리한 후 남은 렌더링을 재개할 수 있어 애플리케이션의 반응성을 극대화합니다 [1, 4, 5].
+
+## 📖 Core Content
+
+- **메인 스레드의 한계와 동기적 블로킹 문제:** 
+  브라우저는 기본적으로 단일 스레드(Single-threaded) 환경에서 작동하며, 한 번에 하나의 태스크를 처음부터 끝까지 실행합니다 [2]. 메인 스레드는 HTML/CSS 파싱, 자바스크립트 실행, 스타일 계산, 레이아웃(Reflow) 및 페인트(Paint) 등의 렌더링 파이프라인을 모두 책임집니다 [6, 7]. 부드러운 스크롤과 상호작용을 유지하려면 16.67ms(60 FPS) 이내에 프레임 렌더링을 완료해야 합니다 [1, 7]. 그러나 대규모 컴포넌트 트리 업데이트를 단일 재귀 호출로 처리하면 이 프레임 예산을 초과하여 메인 스레드를 오랫동안 점유하게 되며, 이는 TTI(Time to Interactive)를 늦추고 브라우저가 사용자 입력에 반응하지 못하게 만듭니다 [1, 8, 9].
+
+- **타임 슬라이싱(Time-Slicing)과 Fiber 아키텍처:** 
+  이러한 메인 스레드 블로킹 문제를 해결하기 위해 React는 렌더링 작업을 작은 '작업 단위(Units of Work)'로 나누는 Fiber 아키텍처를 도입했습니다 [1, 10]. 타임 슬라이싱은 무거운 업데이트 작업을 작은 청크로 쪼개는 기법입니다 [3]. 작업 루프(Work loop)는 각 작업 단위를 처리한 후 브라우저에 남은 여유 시간이 있는지, 또는 사용자 입력과 같은 긴급한 작업이 들어왔는지 확인합니다 [4]. 만약 시간이 부족하면 렌더링 작업을 일시 중지하고 메인 스레드의 제어권을 브라우저에게 양보(Yield)합니다 [4, 11].
+
+- **스케줄링과 우선순위(Lanes) 제어:** 
+  스케줄러는 UI 업데이트의 우선순위를 지능적으로 관리하는 역할을 합니다 [3]. 사용자 입력(클릭, 타이핑)과 같은 작업은 가장 높은 우선순위(Sync Lane)에 할당되어 즉시 처리되며, 백그라운드 데이터 처리나 무거운 리스트 필터링 등은 낮은 우선순위로 밀려납니다 [12-14]. 스케줄러는 메인 스레드가 바쁘거나 더 높은 우선순위의 작업이 도착하면 현재 진행 중인 작업(WIP Fiber)을 일시 중지(Pause)시키고, 메인 스레드가 유휴 상태가 되었을 때 중단된 지점부터 다시 재개(Resume)합니다 [5]. 이 과정에서 `requestIdleCallback`과 같은 브라우저 API를 활용하여 UI가 멈추지 않도록 방지합니다 [11].
+
+- **최적화 지표 및 동시성 렌더링(Concurrent Rendering):** 
+  이러한 타임 슬라이싱과 우선순위 제어를 바탕으로 React 19의 `useTransition` 및 `useDeferredValue`와 같은 동시성 기능이 작동합니다 [15, 16]. 이 기능들은 무거운 연산을 비긴급 업데이트로 분류하여 메인 스레드가 사용자 입력에 즉각적으로 반응할 수 있는 공간을 확보해 줍니다 [15, 17]. 이는 자바스크립트 실행 속도 자체를 물리적으로 높이는 것은 아니지만, 긴급한 사용자 피드백이 지연되지 않게 하여 앱이 "더 빠르게 느껴지도록(Feel faster)" 인지적 성능을 크게 향상시키며, 결과적으로 INP(Interaction to Next Paint) 코어 웹 바이탈 지표를 직접적으로 개선합니다 [17, 18].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[React Fiber Architecture]], [[Concurrent Rendering]], [[Critical Rendering Path]]
+- **Projects/Contexts:** [[React 18/19]], [[Core Web Vitals (INP, TTI)]]
+- **Contradictions/Notes:** 과거 React의 스택 리컨실러(Stack Reconciler)는 렌더링 작업이 한 번 시작되면 트리를 끝까지 동기적으로 순회해야 했기 때문에 메인 스레드를 블로킹하는 치명적 단점이 있었으나, Fiber 도입 이후 이를 중단 및 재개 가능한(Interruptible) 렌더링 모델로 개선했다는 사실이 소스 전반에 걸쳐 강조됩니다 [1, 19, 20]. 타임 슬라이싱은 코드 자체를 빠르게 만드는 것이 아니라 메인 스레드 가용성을 확보하여 체감 성능을 향상시키는 구조적 접근임을 유의해야 합니다 [18].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/서버 사이드 렌더링(SSR)과 하이드레이션(Hydration).md b/10_Wiki/Topics/Frontend_Mastery/서버 사이드 렌더링(SSR)과 하이드레이션(Hydration).md
new file mode 100644
index 00000000..732cebcb
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/서버 사이드 렌더링(SSR)과 하이드레이션(Hydration).md	
@@ -0,0 +1,35 @@
+# [[서버 사이드 렌더링(SSR)과 하이드레이션(Hydration)]]
+
+## 📌 Brief Summary
+서버 사이드 렌더링(SSR)은 사용자의 요청이 있을 때마다 서버에서 데이터를 포함한 완전한 HTML을 생성하여 브라우저에 전달하는 렌더링 방식입니다. 브라우저가 전달받은 정적 HTML 화면을 즉각적으로 표시한 후, 자바스크립트를 다운로드 및 실행하여 이벤트 리스너와 상태를 연결해 애플리케이션을 상호작용 가능하게 만드는 과정을 하이드레이션(Hydration)이라고 합니다. SSR은 초기 로딩 속도(FCP)가 빠르고 검색 엔진 최적화(SEO)에 탁월하지만, 하이드레이션이 완료되기 전까지 사용자가 상호작용할 수 없는 지연 시간(TTI)이 발생한다는 트레이드오프가 존재합니다.
+
+## 📖 Core Content
+**서버 사이드 렌더링(SSR)의 동작 원리와 특징**
+*   **작동 방식:** 클라이언트(브라우저)에서 요청이 발생하면 서버는 라우팅과 데이터 페칭, 렌더링 로직을 실행하여 완전한 형태의 HTML 문서를 생성한 뒤 브라우저에 보냅니다 [1-3]. 
+*   **장점:** 빈 컨테이너나 로딩 화면 대신 콘텐츠가 채워진 페이지를 즉각적으로 제공하기 때문에 초기 로드 시간(First Contentful Paint, FCP)이 매우 빠릅니다 [4-6]. 또한 검색 엔진 크롤러가 자바스크립트 실행 없이도 완성된 HTML을 바로 수집할 수 있어 검색 엔진 최적화(SEO)와 소셜 미디어 공유(미리보기)에 압도적으로 유리합니다 [1, 5, 7]. 이러한 특성 덕분에 뉴스 사이트나 이커머스 제품 페이지처럼 콘텐츠가 자주 업데이트되고 SEO가 중요한 서비스에 적합합니다 [8, 9].
+*   **단점:** 매 요청마다 서버에서 렌더링 연산을 수행해야 하므로 트래픽이 몰릴 때 서버 부하가 증가하며, 인프라 비용과 관리 복잡성이 커집니다 [10-12]. 서버 측 처리 시간이 필요하여 초기 응답 속도인 Time to First Byte(TTFB)가 100~300ms가량 증가할 수 있습니다 [6, 13].
+
+**하이드레이션(Hydration)의 개념과 메커니즘**
+*   **생명을 불어넣는 과정:** SSR을 통해 서버에서 전달받은 초기 HTML은 시각적으로는 완성되어 있지만, 이벤트 핸들러가 연결되지 않아 클릭 등의 조작에 반응하지 않는 정적인 상태(Static Skeleton)입니다 [12, 14, 15]. 브라우저가 자바스크립트 번들을 다운로드하고 실행하면서 React 등의 프레임워크가 가상 DOM(Virtual DOM)을 실제 HTML에 매핑하고 이벤트 리스너와 상태 관리를 부착하는 과정을 '하이드레이션'이라 부릅니다 [1, 15-17].
+*   이 과정은 기기 성능이나 번들 크기에 따라 최신 기기에서도 대략 200~800ms가 소요됩니다 [16].
+
+**하이드레이션의 성능 문제 및 사용자 경험 저하**
+*   기본적으로 React는 화면에 즉시 보이지 않는 컴포넌트까지 포함하여 페이지 전체를 한 번에 하이드레이션합니다 [18, 19]. 이로 인해 대량의 자바스크립트 실행이 메인 스레드를 차단(Blocking)하게 됩니다 [18].
+*   이러한 차단 현상은 Total Blocking Time(TBT) 지표를 악화시키며, 시각적으로는 버튼이나 폼이 렌더링되어 사용자가 조작을 시도했음에도 하이드레이션이 끝날 때까지 반응하지 않는 불쾌한 경험(Uncanny Valley 현상)을 유발합니다 [12, 16, 20]. 결과적으로 상호작용이 가능해지는 시간인 Time to Interactive(TTI)가 2~5초까지 지연되기도 합니다 [6].
+*   또한 서버에서 렌더링된 HTML과 클라이언트에서 렌더링하려는 결과물이 일치하지 않을 때 발생하는 '하이드레이션 불일치(Mismatch) 에러'도 흔한 문제로 꼽힙니다 [19].
+
+**하이드레이션 최적화 및 고급 전략**
+위와 같은 한계를 극복하기 위해 최신 웹 프레임워크(Next.js 등)는 다음과 같은 하이드레이션 최적화 기술을 활용합니다.
+*   **선택적 및 점진적 하이드레이션 (Selective/Progressive Hydration):** 동적 임포트(Dynamic Imports)를 활용하여 상단 콘텐츠(Above-the-fold)를 우선 처리하고, 덜 중요한 부분의 하이드레이션을 뒤로 미루어 TBT를 최대 40%까지 줄입니다 [21-23].
+*   **가시성 기반 지연 하이드레이션 (Lazy Hydration):** 사용자가 화면을 스크롤하여 특정 요소가 뷰포트 내에 들어올 때만 하이드레이션을 트리거하는 방식입니다 [23, 24].
+*   **아일랜드 아키텍처 (Island Architecture):** 페이지의 대부분을 정적 HTML로 유지하고, 상호작용이 필요한 특정 부분("섬")만 분리하여 클라이언트 기능을 부여함으로써 자바스크립트 실행 최소화를 돕습니다 [21].
+*   **스트리밍 SSR 및 Suspense:** 서버에서 HTML을 청크 단위로 쪼개 브라우저에 점진적으로 스트리밍 전송하여 하이드레이션 부담을 분산시킵니다 [21, 25].
+*   **React 서버 컴포넌트 (RSC):** 상호작용이 없는 컴포넌트를 서버에서만 실행되도록 격리하여, 아예 클라이언트로 자바스크립트 코드를 전송하지 않고 하이드레이션 과정 자체를 생략함으로써 압도적인 성능 개선을 이뤄냅니다 [24-26].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** `[[Client-Side Rendering (CSR)]]`, `[[Static Site Generation (SSG)]]`, `[[Time to Interactive (TTI)]]`, `[[React Server Components (RSC)]]`, `[[Total Blocking Time (TBT)]]`
+- **Projects/Contexts:** `[[Next.js를 활용한 SEO 및 성능 최적화 하이브리드 렌더링 아키텍처 설계]]`, `[[콘텐츠 기반의 이커머스 및 뉴스 웹사이트 성능 튜닝]]`
+- **Contradictions/Notes:** SSR은 FCP와 LCP 지표를 개선해 시각적 속도를 극대화하지만, 그에 대한 대가로 JS 번들이 처리되는 하이드레이션 기간 동안 사용자의 입력(TTI, FID 지표)이 지연된다는 본질적인 트레이드오프를 가지고 있습니다. 따라서 완벽한 해결책이라기보다는 서비스 목적(SEO 최우선 vs. 즉각적 상호작용 최우선)에 맞춰 CSR 등과 결합(하이브리드)하는 방식이 권장됩니다 [6, 27, 28].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/웹 성능 가이드(Web Performance).md b/10_Wiki/Topics/Frontend_Mastery/웹 성능 가이드(Web Performance).md
new file mode 100644
index 00000000..fa387d9b
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/웹 성능 가이드(Web Performance).md	
@@ -0,0 +1,29 @@
+# [[웹 성능 가이드(Web Performance)]]
+
+## 📌 Brief Summary
+웹 성능(Web Performance)은 웹 애플리케이션이 로드되고 렌더링되며 사용자의 상호작용에 즉각적으로 응답하는 속도를 최적화하는 포괄적인 과정을 의미합니다 [1-3]. 이는 브라우저의 중요 렌더링 경로(CRP)를 최소화하고, 리플로우(Reflow)와 리페인트(Repaint) 같은 브라우저의 값비싼 연산을 줄여 메인 스레드(Main Thread)의 과부하를 방지하는 것을 포함합니다 [4-7]. 더 나아가 프로젝트의 요구 사항에 맞춰 CSR, SSR, SSG 등의 렌더링 전략을 선택하고 하이드레이션(Hydration)을 최적화하여, 실제 로드 시간과 사용자의 체감 성능(Perceived Performance)을 모두 향상시키는 것이 핵심 목적입니다 [8-10].
+
+## 📖 Core Content
+- **중요 렌더링 경로(Critical Rendering Path, CRP) 이해와 최적화**
+  브라우저는 네트워크를 통해 HTML과 CSS를 파싱하여 각각 DOM(문서 객체 모델) 및 CSSOM 트리를 생성하고, 이를 결합해 화면에 표시될 렌더 트리(Render Tree)를 구축합니다 [11-14]. 이후 요소의 크기와 위치를 계산하는 레이아웃(Layout)과 실제 화면에 픽셀을 그리는 페인트(Paint) 과정을 거칩니다 [15-20]. 이 경로를 단축하기 위해 초기 렌더링을 차단하는 렌더링 차단 리소스(Render-blocking resources, 예: CSS 및 동기식 JavaScript)를 최소화하고, 비핵심 리소스의 지연 로딩(Lazy Loading)을 적용해야 합니다 [4, 21-25].
+
+- **브라우저 리플로우(Reflow) 및 리페인트(Repaint) 최소화**
+  리플로우(또는 레이아웃)는 브라우저 창 크기 조절, DOM 요소 추가, 혹은 요소의 크기 및 위치(`width`, `margin` 등) 변경 시 페이지 전체 또는 일부의 레이아웃을 다시 계산하는 과정으로, 컴퓨팅 자원을 많이 소모해 성능 저하(Jank)를 유발합니다 [7, 26-31]. 반면 리페인트는 색상이나 그림자 등 시각적 스타일만 변경될 때 발생하며 리플로우보다는 가볍지만, 과도하게 발생할 경우 여전히 성능을 저하시킵니다 [31-33]. 이를 방지하려면 DOM 조작을 일괄 처리하고, 복잡한 렌더링 변경(애니메이션 등) 시 문서 흐름에서 벗어난 요소(`position: absolute` 등)를 사용하거나 GPU 가속을 활용하는 `transform` 속성을 사용해야 합니다 [32, 34-38].
+
+- **웹 렌더링 전략 비교 (CSR, SSR, SSG, ISR)**
+  - **CSR (Client-Side Rendering):** 클라이언트가 빈 HTML과 자바스크립트를 다운로드하여 브라우저에서 동적으로 UI를 렌더링합니다. 초기 로딩(FCP)은 느릴 수 있으나 로드 후 페이지 간 전환과 상호작용이 매우 매끄럽습니다 [39-48].
+  - **SSR (Server-Side Rendering):** 서버에서 HTML을 완전히 렌더링하여 클라이언트에 제공하므로 초기 콘텐츠가 즉시 표시되며 SEO에 유리합니다 [49-55]. 
+  - **SSG (Static Site Generation) & ISR (Incremental Static Regeneration):** 빌드 시점에 정적 HTML을 생성하여 CDN을 통해 서비스하는 SSG는 속도가 가장 빠르며 [56-62], ISR은 백그라운드에서 주기적으로 정적 페이지를 재생성하여 데이터의 최신화와 속도를 동시에 만족시킵니다 [57, 63-67].
+
+- **React 아키텍처 및 렌더링 성능 최적화 기술**
+  - **자동 일괄 처리(Automatic Batching):** React 18부터 도입된 기능으로, 비동기 작업(Promise, `setTimeout` 등) 내에서 발생하는 여러 상태 업데이트를 하나로 묶어 리렌더링 횟수를 대폭 줄여줍니다 [68-72].
+  - **동시성 렌더링(Concurrent Rendering):** `useTransition` 및 `useDeferredValue`를 사용하여 긴급하지 않은 UI 업데이트를 지연시키고, 타이핑이나 클릭 같은 긴급한 상호작용을 우선 처리하여 INP(Interaction to Next Paint) 성능을 크게 개선합니다 [73-77].
+  - **React 컴파일러 (React Compiler):** React 19 컴파일러는 빌드 시점에 코드를 분석(AST)하여 반응형 값과 정적 값을 구별하고, 필요한 위치에 메모이제이션을 자동으로 삽입합니다. 이로 인해 개발자가 수동으로 `useMemo`, `useCallback`, `React.memo`를 작성하는 수고와 잦은 실수(오버/언더 메모이제이션)를 없애줍니다 [78-86].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[중요 렌더링 경로(Critical Rendering Path)]], [[리플로우 및 리페인트(Reflow and Repaint)]], [[웹 렌더링 전략(CSR, SSR, SSG, ISR)]], [[하이드레이션(Hydration)]], [[코어 웹 바이탈(Core Web Vitals)]], [[React 컴파일러(React Compiler)]]
+- **Projects/Contexts:** [[프론트엔드 아키텍처 설계 및 최적화]], [[단일 페이지 애플리케이션(SPA) 성능 프로파일링]]
+- **Contradictions/Notes:** SSR 방식은 HTML을 서버에서 미리 그려 사용자에게 가장 먼저 콘텐츠를 보여주기 때문에 초기 화면 표시(FCP, LCP)나 SEO 측면에서는 훌륭합니다 [49, 50, 54, 55]. 그러나 이 과정에서 생성된 화면은 자바스크립트가 다운로드되고 DOM 요소에 이벤트 핸들러가 결합되는 '하이드레이션(Hydration)' 과정이 완료되기 전까지는 상호작용이 불가능합니다. 따라서 화면은 보이지만 버튼을 눌러도 반응하지 않는 상호작용 지연 현상(Time to Interactive 및 Total Blocking Time 증가)을 유발할 수 있다는 명확한 Trade-off가 존재합니다 [87-93]. 또한 성능 최적화를 위한 `React.memo` 등의 메모이제이션 기법 역시, 측정 없이 남용될 경우 불필요한 속성 비교 연산과 메모리 할당이 추가되어 렌더링이 빠른 가벼운 컴포넌트에서는 오히려 성능 오버헤드를 발생시킬 수 있으므로 주의해야 합니다 [82, 94].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/컴포넌트 기반 아키텍처 (CBA).md b/10_Wiki/Topics/Frontend_Mastery/컴포넌트 기반 아키텍처 (CBA).md
new file mode 100644
index 00000000..56f21a46
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/컴포넌트 기반 아키텍처 (CBA).md	
@@ -0,0 +1,37 @@
+# [[컴포넌트 기반 아키텍처 (CBA)]]
+
+## 📌 Brief Summary
+컴포넌트 기반 아키텍처(Component-Based Architecture, CBA)는 소프트웨어 시스템을 모듈화되고 독립적이며 재사용 가능한 단위인 '컴포넌트(Component)'로 분할하여 구축하는 최신 설계 방법론입니다 [1-3]. 각 컴포넌트는 내부의 데이터와 동작(로직)을 캡슐화하며, 잘 정의된 인터페이스를 통해서만 상호 작용합니다 [1, 4]. 이 아키텍처는 거대한 모놀리식(Monolithic) 시스템을 구축하는 대신 레고 블록을 조립하듯 소프트웨어를 개발하게 해주어, 시스템의 확장성, 유연성 및 유지보수성을 극대화합니다 [3, 5, 6].
+
+## 📖 Core Content
+*   **컴포넌트의 개념 및 특징:**
+    *   소프트웨어 공학에서 컴포넌트는 특정 기능을 수행하는 독립적이고 재사용 가능한 구성 요소입니다 [7].
+    *   주요 특징으로는 구현의 세부 사항을 숨기는 **캡슐화(Encapsulation)**, 다른 호환 가능한 컴포넌트로 교체할 수 있는 **교체 가능성(Replaceability)**, 여러 시스템에 걸쳐 사용할 수 있는 **재사용성(Reusability)**, 그리고 타 컴포넌트와의 의존성을 최소화하는 **독립성(Independence)**이 있습니다 [4, 8-10].
+    *   UI 요소(버튼, 로그인 모듈, 테마, 위젯)뿐만 아니라 백엔드 서비스(인증, 결제 처리기, 데이터 액세스 계층)도 모두 컴포넌트가 될 수 있습니다 [4, 11, 12].
+
+*   **주요 이점 (Advantages):**
+    *   **모듈성과 협업 (Modularity & Collaboration):** 시스템을 관심사(UI, 비즈니스 로직 등)에 따라 분리함으로써, 여러 팀이 서로 간섭하지 않고 병렬적으로 서로 다른 컴포넌트를 개발할 수 있어 출시 시간(Time-to-Market)을 단축합니다 [13-17].
+    *   **유지보수 및 테스트 (Maintainability & Testability):** 버그 수정이나 업데이트를 전체 시스템에 영향을 주지 않고 특정 컴포넌트 내에서만 처리할 수 있습니다. 또한 개별 컴포넌트를 격리된 상태에서 단위 테스트(Unit Testing)하기 쉽습니다 [14, 15, 17].
+    *   **확장성 (Scalability):** 트래픽 증가나 비즈니스 요구에 따라 시스템 전체를 재구축할 필요 없이 특정 컴포넌트(예: 쇼핑카트)만 독립적으로 확장하거나 새 기능을 추가할 수 있습니다 [15, 18].
+
+*   **통신 메커니즘 (Communication):**
+    *   컴포넌트는 내부 정보를 노출하지 않고 정의된 API와 같은 인터페이스를 통해서만 소통합니다 [2, 19].
+    *   분산 시스템 환경에서는 메시징(Publish-subscribe 등), 원격 프로시저 호출(RPC), 서비스 지향 아키텍처(SOA)의 표준 RESTful API 등을 통해 통신이 이루어집니다 [19].
+
+*   **도입 시 직면하는 과제 (Challenges & Drawbacks):**
+    *   **복잡성 및 종속성 관리:** 컴포넌트 수가 증가할수록 상호작용 및 종속성(버전 호환성 등) 관리가 어려워지며, 초기 시스템 설계 시 명확한 경계와 인터페이스를 정의하는 데 시간이 소요됩니다 [20-24].
+    *   **성능 오버헤드:** 네트워크 호출이나 프로세스 간 통신이 필요한 컴포넌트 상호 작용의 경우, 단일 시스템 내에서의 직접 호출보다 지연(Latency) 등 성능 오버헤드가 발생할 수 있습니다 [20, 23, 25].
+    *   **보안 취약점:** 각 컴포넌트가 다양한 라이브러리에 의존할 경우 업데이트 주기가 달라져 구버전 컴포넌트에 취약점이 발생하면 전체 애플리케이션을 위험에 빠뜨릴 수 있습니다 [26].
+
+*   **실제 적용 사례:**
+    *   React, Angular, Vue.js 같은 최신 웹 프론트엔드 프레임워크는 UI 구성을 위해 컴포넌트 기반 아키텍처 원칙을 채택하고 있습니다 [27, 28].
+    *   PayPal, Walmart, Spotify, Uber와 같은 거대 IT 기업들은 일관된 UI 유지, 빠른 기능 출시, 전역적 확장성 관리를 위해 컴포넌트 기반 아키텍처를 도입하여 사용합니다 [29].
+    *   FAB Builder와 같은 노코드(No-code) 플랫폼은 사전 구축된 SaaS 컴포넌트를 활용하여 빠르고 확장이 용이한 앱 생성을 지원합니다 [30].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[모놀리식 아키텍처 (Monolithic Architecture)]], [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[프론트엔드 프레임워크 (React, Angular, Vue)]], [[관심사의 분리 (Separation of Concerns)]], [[가상 DOM (Virtual DOM)]]
+- **Projects/Contexts:** [[엔터프라이즈급 대규모 시스템 확장 (Uber, PayPal, Walmart)]], [[모던 UI/UX 프론트엔드 개발]], [[FAB Builder (No-code 개발 플랫폼)]]
+- **Contradictions/Notes:** 컴포넌트 기반 접근법은 애플리케이션의 유연성과 재사용성을 극대화하여 유지보수를 돕지만, 너무 잘게 쪼개는 '오버 엔지니어링(Over-engineering)'을 할 경우 오히려 통합 오버헤드, 성능 저하 및 인지 부하를 증가시키는 부작용(Trade-off)을 초래할 수 있습니다 [20, 23, 24, 31]. 
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/컴포넌트 기반 아키텍처 개념 수집 포인트.md b/10_Wiki/Topics/Frontend_Mastery/컴포넌트 기반 아키텍처 개념 수집 포인트.md
new file mode 100644
index 00000000..7b75de98
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/컴포넌트 기반 아키텍처 개념 수집 포인트.md	
@@ -0,0 +1,28 @@
+# [[컴포넌트 기반 아키텍처 개념 수집 포인트]]
+
+## 📌 Brief Summary
+컴포넌트 기반 아키텍처(Component-Based Architecture, CBA)는 소프트웨어를 독립적이고 재사용 가능한 단위인 '컴포넌트'로 분할하여 구축하는 현대적인 소프트웨어 설계 패러다임입니다 [1-3]. 마치 레고 블록을 조립하듯 시스템을 구성하여 기존의 거대한 모놀리식(Monolithic) 시스템이 가진 복잡성과 경직성을 극복하는 데 목적이 있습니다 [2, 4]. 이 접근 방식은 코드의 재사용성을 극대화하고 여러 팀의 병렬 개발을 지원하여 개발 속도, 유지보수성, 시스템 확장성을 크게 향상시킵니다 [5-8].
+
+## 📖 Core Content
+**핵심 원칙 및 컴포넌트의 특징**
+* **독립성과 캡슐화(Independence & Encapsulation):** 각 컴포넌트는 내부 로직과 데이터를 캡슐화하여 외부로부터 세부 구현을 숨기고, 잘 정의된 인터페이스(API)를 통해서만 다른 시스템 요소와 상호작용합니다 [1, 9, 10]. 이를 통해 전체 애플리케이션의 구조를 모두 알지 못해도 특정 기능(예: 로그인 모듈, 쇼핑 카트 등)을 독립적으로 개발, 테스트 및 배포할 수 있습니다 [11].
+* **모듈성과 조립성(Modularity & Composability):** 시스템은 뚜렷한 책임을 지닌 모듈들로 구성되며, 개발자는 이러한 개별 컴포넌트들을 다양하게 조합하여 더 크고 복잡한 시스템을 쉽게 구축하고 확장할 수 있습니다 [10, 12, 13].
+* **교체 가능성 및 상호 운용성(Replaceability & Interoperability):** 표준화된 인터페이스를 준수한다면 전체 시스템의 무결성에 영향을 주지 않고 기존 컴포넌트를 새로운 것으로 원활하게 교체할 수 있습니다 [10, 12, 14]. 또한, 서로 다른 기술이나 플랫폼으로 구축되었더라도 원활한 통신과 통합이 가능합니다 [10, 12].
+
+**컴포넌트 기반 아키텍처의 주요 이점**
+* **생산성 향상 및 출시 시간(Time-to-Market) 단축:** 이미 검증된 컴포넌트를 재사용(Reusability)함으로써 코드를 처음부터 다시 작성할 필요가 없어, 개발 비용을 줄이고 제품 출시 속도를 크게 앞당길 수 있습니다 [5-7].
+* **뛰어난 확장성과 유지보수성:** 전체 애플리케이션을 건드리지 않고 트래픽이나 비즈니스 요구사항 변화에 맞춰 특정 컴포넌트만 개별적으로 업그레이드하거나 확장할 수 있습니다 [5, 8, 15]. 또한, 버그 수정이 해당 컴포넌트 내로 격리되므로 부작용 없이 안전하고 단순하게 시스템을 유지보수할 수 있습니다 [5, 8].
+* **협업 촉진 및 테스트 용이성:** 각기 다른 팀이 프론트엔드, 백엔드 등 서로 다른 컴포넌트를 동시에 개발하는 병렬 개발(Parallel development) 환경을 조성합니다 [5, 16-18]. 또한, 전체 앱의 오버헤드 없이 각 컴포넌트의 상태를 독립적으로 분리하여 유닛 테스트를 수행할 수 있어 소프트웨어 품질을 높일 수 있습니다 [16, 19, 20].
+
+**도입 시 주의사항 및 한계점**
+* **초기 설계 복잡성 및 통합 오버헤드:** 수많은 독립적인 컴포넌트를 원활하게 통신하도록 조립하는 과정에서 초기 아키텍처 설계 부담이 커지며, API 호출 등 컴포넌트 간 상호작용으로 인해 성능 오버헤드가 발생할 수 있습니다 [19, 21-24].
+* **의존성 및 버전 관리의 어려움:** 공유되거나 재사용되는 컴포넌트가 많아지면 특정 라이브러리나 다른 컴포넌트 버전에 대한 의존성(Dependency)이 얽혀 버전 호환성 충돌이 일어날 수 있습니다 [19, 24, 25]. 
+* **과도한 엔지니어링(Over-Engineering) 위험:** 시스템의 모듈화를 지나치게 추구하여 컴포넌트를 너무 작고 잘게 분할하면(Granularity 문제), 오히려 시스템이 파편화되고 개발자가 파악해야 할 인지적 부하와 관리 복잡성이 기하급수적으로 증가합니다 [19, 26].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Monolithic Architecture]], [[Microservices Architecture]], [[Separation of Concerns]]
+- **Projects/Contexts:** [[Frontend UI Libraries (React, Angular, Vue)]], [[Enterprise Software Development]]
+- **Contradictions/Notes:** 컴포넌트 기반 아키텍처는 유연성과 재사용성을 제공하여 개발 속도와 유지보수성을 극대화하지만, 맹목적으로 모듈화를 추구하여 컴포넌트를 너무 세밀하게 쪼개면 오히려 의존성 관리가 복잡해지고 통신 오버헤드로 인한 성능 저하를 유발할 수 있습니다. 따라서 적절한 컴포넌트 단위(Granularity)를 설정하는 것이 성능 최적화의 관건입니다 [19, 22, 26].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/프론트엔드 기초 구조 이해.md b/10_Wiki/Topics/Frontend_Mastery/프론트엔드 기초 구조 이해.md
new file mode 100644
index 00000000..81d3b6c9
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/프론트엔드 기초 구조 이해.md	
@@ -0,0 +1,37 @@
+# [[프론트엔드 기초 구조 이해]]
+
+## 📌 Brief Summary
+프론트엔드 기초 구조는 브라우저가 HTML, CSS, JavaScript를 시각적인 화면으로 변환하는 **중요 렌더링 경로(Critical Rendering Path)** 와 이를 효율적으로 제어하기 위한 아키텍처 및 렌더링 전략을 의미합니다 [1]. **리플로우(Reflow)와 리페인트(Repaint)를 최소화**하여 렌더링 성능을 최적화하는 것이 가장 핵심적인 과제입니다 [2, 3]. 현대 프론트엔드는 **컴포넌트 기반 아키텍처(CBA)** 를 통해 재사용성과 유지보수성을 높이며 [4], 애플리케이션의 요구사항에 따라 **CSR, SSR, SSG** 등의 렌더링 방식을 전략적으로 선택하여 사용자 경험을 극대화합니다 [5, 6]. 특히 React는 **Virtual DOM과 Fiber 아키텍처**를 도입하여 DOM 조작 비용을 줄이고 렌더링 성능을 획기적으로 개선했습니다 [7, 8].
+
+## 📖 Core Content
+
+**1. 브라우저 렌더링 과정 (Critical Rendering Path)**
+*   **DOM 및 CSSOM 트리 생성:** 브라우저는 네트워크를 통해 전달받은 HTML을 점진적으로 파싱하여 문서의 구조를 나타내는 **DOM(Document Object Model) 트리**를 구성합니다 [9, 10]. 동시에, 렌더링을 차단(Render-blocking)하는 CSS를 파싱하여 스타일 정보를 담은 **CSSOM(CSS Object Model) 트리**를 생성합니다 [11, 12].
+*   **렌더 트리(Render Tree) 구축:** DOM과 CSSOM이 결합하여 화면에 실제로 표시될 노드들만 포함하는 렌더 트리가 만들어집니다 [13, 14]. `display: none`이 적용된 요소나 `<head>` 태그 등은 시각적 출력이 없으므로 렌더 트리에 포함되지 않습니다 [14, 15].
+*   **레이아웃(Layout) 및 페인트(Paint):** 렌더 트리를 기반으로 기기의 뷰포트 내에서 각 요소의 정확한 크기와 위치를 계산하는 **레이아웃(또는 리플로우)** 과정을 거칩니다 [16-18]. 이후 계산된 기하학적 형태와 스타일을 화면의 실제 픽셀로 그리는 **페인트(Paint)** 단계를 수행하며, 요소가 겹칠 경우 레이어를 합성하는 **컴포지팅(Compositing)**이 발생합니다 [19-21].
+
+**2. Reflow 및 Repaint 최소화 최적화**
+*   **개념:** **리플로우(Reflow)** 는 요소의 너비, 높이, 위치 변경이나 노드의 추가/제거 등 문서의 기하학적 구조가 바뀔 때 전체 또는 일부 레이아웃을 다시 계산하는 매우 무거운 연산입니다 [2, 3]. **리페인트(Repaint)** 는 레이아웃 변화 없이 배경색, 그림자 등 시각적 속성만 변경될 때 발생합니다 [22, 23]. 
+*   **최소화 방법:** 무거운 연산인 리플로우를 줄이려면 불필요한 DOM 깊이를 줄이고, 복잡한 CSS 선택자 사용을 피해야 합니다 [24]. 레이아웃 속성을 읽고 쓰는 작업을 번갈아 하여 발생하는 '레이아웃 스래싱(Layout Thrashing)'을 피하기 위해 DOM 업데이트를 일괄 처리(Batching)하는 것이 좋습니다 [2, 25]. 복잡한 애니메이션을 구현할 때는 문서 흐름에서 벗어나도록 `position-absolute`나 `position-fixed`를 사용하며 [24], `top`이나 `left` 속성 대신 GPU 가속을 지원하는 `transform` 속성을 사용하여 렌더링 성능을 개선해야 합니다 [19, 26].
+
+**3. DOM vs Virtual DOM과 React의 빠른 성능 (Reconciliation & Fiber)**
+*   **Virtual DOM의 도입:** 실제 DOM을 직접 수정하면 렌더링 경로의 레이아웃과 페인트 단계가 매번 트리거되어 속도가 저하됩니다 [7]. React는 가벼운 메모리 내 표현인 **Virtual DOM**을 사용하여 상태 변경 전후의 가상 UI를 비교(Diffing)하고, **실제 DOM에는 변경된 부분만 최소한으로 업데이트**하여 성능을 최적화합니다 [7, 27].
+*   **Reconciliation (조정 알고리즘):** React는 $O(n^3)$의 복잡도를 피하기 위해 노드 타입이 다르면 트리를 완전히 새로 구축하고, 같은 목록의 요소는 `key` 속성을 이용해 식별하는 $O(n)$ 휴리스틱 알고리즘을 사용합니다 [28, 29].
+*   **Fiber 아키텍처와 성능 최적화:** React 16부터 도입된 **Fiber 아키텍처**는 동기식으로 진행되던 기존 렌더링을 작은 단위로 쪼개어, 우선순위(Lanes)에 따라 렌더링 작업을 중단하고 긴급한 사용자 입력을 먼저 처리한 뒤 재개할 수 있도록 하는 동시성(Concurrent) 렌더링을 지원합니다 [8, 30-33]. 또한 React 18의 **자동 배칭(Automatic Batching)** 은 비동기 통신 시 발생하는 여러 상태 업데이트를 하나로 묶어 불필요한 재렌더링을 방지하며 [34, 35], 최근의 **React Compiler**는 코드를 분석해 자동으로 메모이제이션을 적용하여 성능 최적화 작업을 크게 줄여줍니다 [36-38].
+
+**4. 웹 렌더링 전략 (CSR vs SSR vs SSG)**
+*   **CSR (Client-Side Rendering):** 서버에서 빈 HTML과 JavaScript 번들을 보낸 후 브라우저가 화면을 그립니다 [39, 40]. 전환 속도가 빠르고 동적 상호작용에 유리하지만, 초기 로딩이 느리고 SEO에 불리합니다 [39, 41-43].
+*   **SSR (Server-Side Rendering):** 요청 시마다 서버에서 완전한 HTML을 생성해 클라이언트로 보냅니다 [44, 45]. 초기 화면 표시(FCP)가 빠르고 SEO에 우수하나, 브라우저가 JavaScript를 다운로드하고 화면에 이벤트를 연결하는 **하이드레이션(Hydration)** 과정이 끝날 때까지 상호작용(TTI)이 지연될 수 있습니다 [44-46].
+*   **SSG (Static Site Generation) 및 ISR:** 빌드 시점에 미리 정적 HTML을 생성해 CDN을 통해 배포하므로 로딩 속도가 가장 빠릅니다 [47-49]. 자주 변경되지 않는 콘텐츠에 적합하며, 최신 데이터를 반영하기 위해 백그라운드에서 주기로 업데이트하는 **ISR(Incremental Static Regeneration)** 방식과 혼합할 수 있습니다 [47, 50]. 
+
+**5. 컴포넌트 기반 아키텍처 (Component-Based Architecture, CBA)**
+*   **개념 및 이점:** 애플리케이션을 특정 기능을 수행하는 독립적이고 캡슐화된 **소프트웨어 컴포넌트**들로 분할하여 조립하는 아키텍처입니다 [51-53]. 
+*   **효과:** 이 구조는 한 번 만든 컴포넌트를 여러 곳에서 재사용할 수 있게 하여 개발 속도를 높입니다(Reusability) [4, 54]. 또한, 모듈성을 바탕으로 한 구성 요소가 다른 요소에 영향을 미치지 않고 독립적으로 테스트 및 유지보수될 수 있으므로, 대규모 시스템에서의 확장성(Scalability)과 팀 간 병렬 개발을 돕습니다 [4, 54-56].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Critical Rendering Path]], [[Virtual DOM]], [[Reconciliation 및 Fiber 아키텍처]], [[컴포넌트 기반 아키텍처(CBA)]], [[웹 렌더링 전략(CSR, SSR, SSG)]]
+- **Projects/Contexts:** [[Next.js를 활용한 하이브리드 렌더링]], [[React Server Components (RSC)]], [[React Compiler 및 Automatic Batching 적용]]
+- **Contradictions/Notes:** 소스 X[44-46]는 SSR이 SEO와 초기 콘텐츠 로딩(FCP) 측면에서 유리하다고 주장하지만, 동시에 브라우저가 대용량 JavaScript 번들을 다운로드하고 하이드레이션(Hydration)을 마칠 때까지 사용자와의 상호작용(TTI)이 심각하게 지연되는 단점이 존재한다고 설명합니다. 한편, 소스 Y[57, 58]는 React Compiler가 도입되어 수동 메모이제이션의 90%를 자동으로 처리한다고 밝히고 있으나, Effect의 의존성 제어가 필요한 특정 상황이나 서드파티 라이브러리 연동 시에는 여전히 `useMemo` 및 `useCallback`과 같은 수동 제어가 필요함을 지적합니다.
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics/Frontend_Mastery/프론트엔드 성능 최적화 전략.md b/10_Wiki/Topics/Frontend_Mastery/프론트엔드 성능 최적화 전략.md
new file mode 100644
index 00000000..9ff26920
--- /dev/null
+++ b/10_Wiki/Topics/Frontend_Mastery/프론트엔드 성능 최적화 전략.md	
@@ -0,0 +1,31 @@
+# [[프론트엔드 성능 최적화 전략]]
+
+## 📌 Brief Summary
+프론트엔드 성능 최적화 전략은 브라우저의 렌더링 과정(Critical Rendering Path)을 효율적으로 관리하고, 불필요한 연산과 네트워크 다운로드를 줄여 사용자에게 빠르고 매끄러운 웹 경험을 제공하는 기술적 접근 방식이다 [1, 2]. 이를 위해 개발자는 초기 로딩 속도 개선, 렌더링 시 발생하는 Reflow 및 Repaint의 최소화, 효율적인 상태 관리 및 적절한 웹 렌더링 전략(CSR, SSR, SSG 등)을 종합적으로 고려해야 한다 [1, 3-6]. 궁극적인 목표는 LCP(최대 콘텐츠 풀 페인트), INP(다음 페인트에 대한 상호작용), CLS(누적 레이아웃 이동)와 같은 핵심 웹 바이탈(Core Web Vitals) 지표를 개선하여 비즈니스 성과와 사용자 만족도를 높이는 것이다 [7-10].
+
+## 📖 Core Content
+*   **브라우저 렌더링 최적화 (Critical Rendering Path 관리)**
+    *   브라우저가 화면을 그리는 과정에서 렌더링 차단 리소스(CSS, 동기식 JavaScript)를 최소화하여 페이지 초기 렌더링 속도를 앞당겨야 한다 [11-13].
+    *   DOM 트리 및 CSSOM 트리를 생성할 때, 불필요한 DOM 노드의 깊이를 줄이고 CSS 선택자 복잡도를 낮추어 연산 부담을 경감시키는 것이 중요하다 [11, 14-19].
+*   **Reflow 및 Repaint 최소화**
+    *   브라우저 화면의 레이아웃을 재계산하는 Reflow 연산은 처리 비용이 매우 크므로, 잦은 DOM 조작이나 레이아웃 요소(width, height, margin 등) 변경을 최소화해야 한다 [20-23].
+    *   애니메이션 적용 시 `top`, `left` 대신 `transform` 속성을 활용하면 GPU 가속을 통해 Reflow를 우회하고 효율적으로 화면을 다시 그릴 수 있다 [21, 23-26].
+    *   DOM 읽기 및 쓰기 작업을 분리하고 일괄 처리(Batching)하여 성능 저하의 주원인인 레이아웃 스래싱(Layout Thrashing)을 방지해야 한다 [27, 28].
+*   **렌더링 전략의 전략적 선택**
+    *   애플리케이션의 특성에 맞춰 Client-Side Rendering (CSR), Server-Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR) 등의 전략을 적절히 혼합하여 사용해야 한다 [29-36].
+    *   **React Server Components (RSC):** 클라이언트 번들 크기를 '0' 바이트로 유지하면서 서버 인프라에 직접 접근해 데이터를 병렬로 가져오는 최신 아키텍처로, TTI(상호작용까지의 시간)를 크게 향상하고 불필요한 클라이언트 연산을 제거한다 [37-46].
+*   **상태 관리 및 프레임워크 수준의 최적화**
+    *   가상 DOM(Virtual DOM) 환경에서 불필요한 리렌더링을 막기 위해 과거에는 `React.memo`, `useMemo`, `useCallback`과 같은 수동 메모이제이션 방식이 주로 쓰였다 [47-50]. 최근 도입된 **React Compiler**는 빌드 시점에 자동으로 메모이제이션 경계를 삽입하여 최적화 작업의 90% 이상을 자동화하고 코드 복잡성을 줄여준다 [51-56].
+    *   **자동 배칭 (Automatic Batching) 및 Concurrent Features:** React 18/19부터는 여러 상태 업데이트를 하나의 렌더링 사이클로 묶어 처리하며 [57-60], Fiber 아키텍처의 레인(Lanes) 기반 우선순위 관리를 통해 `useTransition`이나 `useDeferredValue` 훅으로 무거운 렌더링 작업을 지연시켜 UI 반응성을 유지한다 [61-71].
+*   **리소스 번들링 및 UI 컴포넌트 다이어트**
+    *   **코드 스플리팅(Code Splitting):** `React.lazy()` 등을 통해 필요한 시점에 라우트 단위나 컴포넌트를 지연 로드하여 초기 자바스크립트 번들 크기를 30~50%까지 줄인다 [72, 73]. 미사용 코드를 제거하는 트리 쉐이킹(Tree Shaking) 기법도 필수적이다 [74].
+    *   수백, 수천 개의 데이터 목록을 렌더링할 때는 화면에 보이는 항목만 DOM에 올리는 **가상화(Virtualization)** 기술을 통해 성능 지연을 원천 차단한다 [75, 76].
+    *   용량이 큰 이미지는 WebP/AVIF 같은 차세대 포맷과 네이티브 지연 로딩(`loading="lazy"`)을 통해 초기 페이지 렌더링 방해를 최소화해야 한다 [77, 78].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Critical Rendering Path]], [[Reflow and Repaint]], [[Client-Side Rendering (CSR)]], [[Server-Side Rendering (SSR)]], [[React Server Components]], [[Virtual DOM]], [[React Fiber Architecture]], [[React Compiler]], [[Automatic Batching]]
+- **Projects/Contexts:** [[Core Web Vitals (LCP, INP, CLS) 최적화 작업]], [[대규모 단일 페이지 애플리케이션(SPA) 아키텍처 설계]]
+- **Contradictions/Notes:** 수동 메모이제이션(`useMemo`, `useCallback`)은 오랫동안 프론트엔드 최적화의 필수 원칙이었으나, 가벼운 컴포넌트에서는 얕은 비교 연산 자체가 렌더링보다 높은 오버헤드를 유발할 수 있다 [79, 80]. 최근 React Compiler의 등장으로 인해 개발자가 직접 메모이제이션을 관리할 필요성이 사라지는 방향으로 패러다임이 진화하고 있다 [53, 81]. 또한 SSR은 초기 콘텐츠 로딩(FCP)과 SEO 측면에서 유리하지만, 서버에서 가져온 HTML에 JavaScript를 연결하는 Hydration 과정에서 메인 스레드가 블로킹되면 사용자의 상호작용이 지연되는 병목(높은 TTI) 현상이 일어날 수 있으므로 무조건적인 해결책이 아니라는 점을 유의해야 한다 [30, 82-86].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/Automatic Batching을 통한 React 18 성능 최적화.md b/10_Wiki/Topics_Art/UI_UX_Assets/Automatic Batching을 통한 React 18 성능 최적화.md
new file mode 100644
index 00000000..4283ff32
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/Automatic Batching을 통한 React 18 성능 최적화.md	
@@ -0,0 +1,28 @@
+# [[Automatic Batching을 통한 React 18 성능 최적화]]
+
+## 📌 Brief Summary
+Automatic Batching은 React 18에서 도입된 성능 최적화 기능으로, 여러 상태(state) 업데이트를 단일 리렌더링으로 묶어서 처리합니다 [1-3]. 이전 버전과 달리 프로미스(Promises), `setTimeout`, 비동기 작업 등 업데이트 출처에 관계없이 모든 상태 변경을 일괄 처리하여 불필요한 리렌더링을 방지합니다 [4-6]. 이를 통해 Virtual DOM의 비교(diffing) 작업을 최소화하고 애플리케이션의 성능과 UI 응답성을 크게 향상시킵니다 [1, 4, 7].
+
+## 📖 Core Content
+
+*   **작동 원리 및 이전 버전과의 차이점:**
+    React 18 이전에는 `onClick`이나 `onChange` 같은 네이티브 React 이벤트 핸들러 내에서 발생하는 상태 업데이트만 일괄 처리(배칭)되었으며, `setTimeout`이나 Promise와 같은 비동기 작업에서는 각 업데이트마다 개별적인 리렌더링이 발생했습니다 [2, 6]. 하지만 React 18부터는 자동 배칭(Automatic Batching)이 기본으로 활성화되어, 비동기 작업이나 타임아웃 등 모든 환경에서의 상태 업데이트를 하나의 렌더링 사이클로 그룹화합니다 [4, 5, 8].
+
+*   **성능 향상 및 Virtual DOM 최적화:**
+    여러 상태 변경을 하나로 결합함으로써 React는 Virtual DOM의 diffing 연산과 불필요한 DOM 업데이트 횟수를 최소화합니다 [1, 4, 7]. 실제 데이터 집약적인 대시보드를 대상으로 한 벤치마크 결과에 따르면, 자동 배칭을 활성화할 경우 최대 부하 상태에서 총 렌더링 횟수가 약 40% 감소하고 프레임 속도는 25% 향상되는 성능 개선을 보였습니다 [1, 9]. 이는 깊게 중첩된 컴포넌트를 가진 복잡한 애플리케이션에서 특히 유용합니다 [10].
+
+*   **렌더링 제어 API (`flushSync` 및 `startTransition`):**
+    자동 배칭이 기본 동작이지만, React는 렌더링 시점을 제어할 수 있는 API를 제공합니다 [9, 11]. 
+    *   `flushSync`: 폼 입력값을 즉시 업데이트하여 사용자에게 지연 없이 보여주거나, 상태 변경 직후 DOM 요소를 포커스 및 측정해야 할 때 자동 배칭을 우회하여 동기적 리렌더링을 강제합니다 [9, 12, 13].
+    *   `startTransition`: 리스트 필터링과 같이 긴급하지 않은 상태 업데이트를 표시하여 타이핑이나 클릭 등 우선순위가 높은 상호작용을 차단하지 않도록 양보(yield)합니다 [9, 12].
+
+*   **모니터링 및 베스트 프랙티스:**
+    성능 최적화를 극대화하려면 관련된 업데이트를 같은 이벤트 내에 그룹화하고 함수형 상태 업데이트(`setState(prev => new)`)를 사용하는 것이 좋습니다 [14]. 예상치 못한 리렌더링이 발생한다면 타사 라이브러리가 React의 이벤트 시스템을 우회하고 있지 않은지 확인해야 하며, React DevTools Profiler를 통해 상호작용에 따른 렌더링 횟수와 업데이트 원인을 디버깅하고 모니터링할 수 있습니다 [15-17].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** `[[Virtual DOM]]`, `[[flushSync]]`, `[[startTransition]]`, `[[Concurrent Rendering]]`, `[[useMemo / useCallback]]`
+- **Projects/Contexts:** `[[데이터 집약적 대시보드 성능 최적화]]`, `[[React 18 애플리케이션 마이그레이션]]`
+- **Contradictions/Notes:** 자동 배칭은 대부분의 경우 렌더링 성능을 개선하지만, 즉각적인 DOM 반영이 필요한 예외 상황에서는 방해가 될 수 있습니다. 이 경우 `flushSync`를 사용해 강제로 배칭을 해제할 수 있으나, 이를 남용할 경우 배칭으로 얻는 성능상 이점이 무효화될 수 있으므로 극히 제한적으로 사용해야 한다고 경고하고 있습니다 [11, 12, 14].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/React 18 자동 일괄 처리 및 React 19 컴파일러 최적화 적용.md b/10_Wiki/Topics_Art/UI_UX_Assets/React 18 자동 일괄 처리 및 React 19 컴파일러 최적화 적용.md
new file mode 100644
index 00000000..1cdf50ad
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/React 18 자동 일괄 처리 및 React 19 컴파일러 최적화 적용.md	
@@ -0,0 +1,24 @@
+# [[React 18 자동 일괄 처리 및 React 19 컴파일러 최적화 적용]]
+
+## 📌 Brief Summary
+React 18의 자동 일괄 처리(Automatic Batching)와 React 19의 컴파일러(React Compiler)는 애플리케이션의 렌더링 성능을 극대화하고 개발자의 부담을 줄이기 위한 핵심 아키텍처 변화입니다. 자동 일괄 처리는 여러 상태 업데이트를 단일 리렌더링으로 묶어 가상 DOM의 비교 연산을 최소화합니다. React 19 컴파일러는 빌드 타임에 코드를 분석하여 수동으로 수행하던 메모이제이션 작업을 자동으로 처리함으로써, 불필요한 연쇄 렌더링을 세밀하게 방지합니다.
+
+## 📖 Core Content
+**React 18 자동 일괄 처리 (Automatic Batching)**
+*   **작동 원리 및 변화:** React 18 이전에는 React 이벤트 핸들러 내에서 발생하는 상태 업데이트만 일괄 처리(Batching)의 대상이었습니다 [1, 2]. 그러나 React 18부터는 프로미스(Promise), `setTimeout`, 비동기 API 호출, 네이티브 이벤트 핸들러 등 출처와 상관없이 동일한 이벤트 루프 내에서 발생하는 모든 상태 업데이트를 자동으로 묶어서 한 번만 리렌더링합니다 [3-6].
+*   **성능 향상:** 이 기능은 가상 DOM(Virtual DOM)의 diffing 횟수를 줄여 CPU 작업량을 크게 감소시킵니다 [4]. 벤치마크 결과에 따르면, 데이터 집약적인 대시보드에서 자동 일괄 처리를 활성화할 경우 총 렌더링 횟수가 최대 40% 감소하고 피크 로드 시 프레임 속도가 25% 향상되는 성능 이점을 보였습니다 [3, 7].
+*   **예외 처리 (Opt-out):** 개발자가 즉각적인 DOM 업데이트를 보장받아야 하는 상황(예: 입력 후 즉시 포커스 이동)에서는 `flushSync` API를 사용하여 자동 일괄 처리를 건너뛰고 동기적으로 렌더링을 강제할 수 있습니다 [7-10].
+
+**React 19 컴파일러 최적화 (React Compiler)**
+*   **수동 메모이제이션의 한계 해결:** 이전에는 렌더링 최적화를 위해 개발자가 `useMemo`, `useCallback`, `React.memo`를 수동으로 적용해야 했습니다 [11, 12]. 이는 인지적 부담을 가중시키고 의존성 배열(dependency array)을 잘못 설정하거나 참조 동일성(referential equality)을 놓쳐 최적화가 깨지는 등 유지보수 문제를 유발했습니다 [13, 14].
+*   **빌드 타임 자동화 및 AST 분석:** React 19 컴파일러(구 React Forget)는 빌드 도구 단계에서 코드의 추상 구문 트리(AST)를 분석하여 데이터 흐름을 추적합니다 [15, 16]. 코드를 정적 값(Static)과 반응형 값(Reactive)으로 분류하고, 최적의 위치에 자동으로 메모이제이션 경계를 삽입하여 렌더링 최적화 작업의 상당 부분을 제거합니다 [15-17].
+*   **세밀한 캐싱 (Granular Optimization):** 컴파일러는 전체 컴포넌트를 래핑하는 대신 `<h2>`, `<button>`과 같은 개별 JSX 요소와 특정 계산식들을 독립적으로 분리하여 캐싱합니다 [18, 19]. 결과적으로 속성(Props)이나 상태가 변경되지 않은 하위 컴포넌트의 불필요한 연쇄 리렌더링을 매우 정밀하게 차단합니다 [15, 20].
+*   **도입 효과:** 수동 메모이제이션 없이도 동일하거나 그 이상의 성능을 제공하며, 상호작용 속도(Interaction to Next Paint, INP)를 크게 개선합니다. 실제로 Meta의 프로덕션 적용 테스트에서 렌더링 횟수 60% 감소 및 사용자 상호작용 속도 2.5배 향상 등의 효과가 입증되었습니다 [21, 22].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[가상 DOM (Virtual DOM) 및 Diffing 알고리즘]], [[수동 메모이제이션 (useMemo, useCallback, React.memo)]], [[flushSync 및 startTransition]], [[동시성 렌더링 (Concurrent Rendering)]]
+- **Projects/Contexts:** [[대규모 데이터 대시보드 성능 최적화]], [[Meta의 프로덕션(Instagram, Quest Store) 최적화 도입 사례]]
+- **Contradictions/Notes:** React 컴파일러가 대부분의 수동 메모이제이션을 대체하지만, 매 렌더링마다 새로운 객체 참조를 반환하는 서드파티 라이브러리를 사용할 경우 자동 메모이제이션 체인이 깨질 수 있으므로 이러한 특정 상황에서는 여전히 수동 메모이제이션(`useMemo`, `useCallback`)이 필요할 수 있습니다 [23-25].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/React 기반 싱글 페이지 애플리케이션(SPA)의 렌더링 최적화.md b/10_Wiki/Topics_Art/UI_UX_Assets/React 기반 싱글 페이지 애플리케이션(SPA)의 렌더링 최적화.md
new file mode 100644
index 00000000..e6affebd
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/React 기반 싱글 페이지 애플리케이션(SPA)의 렌더링 최적화.md	
@@ -0,0 +1,26 @@
+# [[React 기반 싱글 페이지 애플리케이션(SPA)의 렌더링 최적화]]
+
+## 📌 Brief Summary
+React 기반 SPA의 렌더링 최적화는 브라우저의 중요 렌더링 경로(Critical Rendering Path)를 효율적으로 처리하고, 불필요한 DOM 조작 및 연산을 줄여 사용자와 상호작용하는 성능을 향상시키는 과정입니다 [1-3]. 가상 DOM(Virtual DOM)과 휴리스틱 비교(Diffing) 알고리즘을 통해 실제 DOM 업데이트를 최소화하며, Fiber 아키텍처 및 자동 배칭(Automatic Batching)으로 렌더링 작업을 스마트하게 스케줄링합니다 [4-8]. 최신 생태계에서는 수동 최적화의 한계를 극복하기 위해 React 컴파일러를 통한 자동 메모이제이션 및 React 서버 컴포넌트(RSC)를 활용해 클라이언트의 자바스크립트 번들 부담을 극적으로 줄이는 방향으로 발전하고 있습니다 [9-12].
+
+## 📖 Core Content
+*   **브라우저 렌더링 과정과 Reflow/Repaint 최소화**
+    브라우저는 HTML과 CSS를 파싱하여 DOM과 CSSOM을 만들고 이를 결합해 렌더 트리(Render Tree)를 생성합니다 [13-15]. 이어서 요소의 정확한 크기와 위치를 계산하는 레이아웃(Layout 또는 Reflow) 단계와 화면에 픽셀을 그리는 페인트(Paint 또는 Repaint) 단계를 거칩니다 [16-18]. Reflow는 매우 연산 비용이 높고 하위 노드 전체로 파급 효과를 일으킬 수 있기 때문에, 불필요한 DOM 깊이를 줄이고, 레이아웃을 유발하는 속성(width, margin 등) 변경 대신 `transform`을 활용하여 렌더링 성능을 최적화해야 합니다 [17, 19-22].
+*   **가상 DOM(Virtual DOM)과 재조정(Reconciliation)**
+    수동적인 실제 DOM 조작은 레이아웃과 페인트를 즉각적으로 유발하여 느리고 비효율적입니다 [4, 23]. React는 메모리에 가상 DOM이라는 경량화된 UI 구조를 생성한 뒤, 상태가 변경되면 O(n) 복잡도의 휴리스틱 Diffing 알고리즘을 사용해 이전 트리와 비교합니다 [4, 5, 7, 8, 24]. 이 과정을 통해 React는 바뀐 최소한의 DOM 노드나 속성만 실제 브라우저 DOM에 커밋(동기화)하여 리렌더링 오버헤드를 막습니다 [25, 26].
+*   **Fiber 아키텍처와 동시성(Concurrent) 기능**
+    대규모 앱에서 동기적 렌더링은 브라우저의 메인 스레드를 차단해 화면 응답성을 늦출 수 있습니다 [27-29]. 이를 해결하기 위해 React 16부터 도입된 Fiber 아키텍처는 작업을 작은 단위로 나누고(Time-slicing) 중요도에 따라 우선순위(Lanes)를 부여하여 작업을 중단하거나 재개할 수 있는 렌더 단계(Render Phase)를 구현했습니다 [25, 27, 30-32]. 더불어 `useTransition` 및 `useDeferredValue`와 같은 동시성 훅(Hooks)은 긴급한 사용자 상호작용이 무거운 비긴급 UI 업데이트 때문에 지연되지 않게 하여 반응성을 향상시킵니다 [33-35].
+*   **리렌더링 캐스케이드(Cascade) 방지와 최적화 자동화**
+    상태가 변할 때 부모가 리렌더링되면 모든 자식이 함께 리렌더링되는 문제는 큰 성능 낭비를 초래합니다 [36, 37]. 이를 최적화하기 위해 도입된 기능이 **자동 배칭(Automatic Batching)**이며, Promise나 `setTimeout` 내의 여러 상태 업데이트를 단일 렌더링으로 묶어 DOM 렌더링 횟수를 대폭 줄입니다 [6, 38-40]. 또한 `React.memo`나 `useMemo` 같은 기존 수동 메모이제이션이 가진 유지보수 부담과 한계를 극복하기 위해, React 19 컴파일러는 빌드 타임에 AST를 분석해 최적의 지점에 자동으로 메모이제이션을 삽입하여 불필요한 렌더링을 차단합니다 [11, 41-45].
+*   **초기 로드 속도 개선(Code Splitting 및 RSC 적용)**
+    CSR 환경에서 큰 자바스크립트 번들은 초기 로딩(FCP, LCP)과 상호작용(INP)을 늦춥니다 [2, 46-48]. 따라서 `React.lazy()`를 이용한 라우트 단위의 코드 스플리팅(Code Splitting)과, 긴 목록에서 보이는 것만 렌더링하는 가상화(Virtualization) 기술은 체감 성능을 즉시 끌어올립니다 [49-51]. 나아가 React 서버 컴포넌트(RSC)를 채택하면, 데이터 페칭 및 렌더링을 서버 측에서 전담하여 클라이언트 자바스크립트 번들 크기에 0바이트를 기여하며, 클라이언트의 하이드레이션(Hydration) 비용을 완전히 제거할 수 있습니다 [9, 10, 52-54].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Virtual DOM]], [[Critical Rendering Path]], [[Fiber Architecture]], [[React Compiler]], [[React Server Components (RSC)]], [[Automatic Batching]], [[Reflow and Repaint]]
+- **Projects/Contexts:** [[Next.js]], [[React 18 & 19]], [[Single-Page Applications (SPA)]]
+- **Contradictions/Notes:** 
+  - 상태 업데이트 병합 시, React 18의 자동 배칭(Automatic Batching)이 기본 적용되지만 폼 입력 등 즉각적인 반영이 필수적인 경우 `flushSync`를 사용해 배칭을 의도적으로 우회(Opt-Out)하고 DOM 업데이트를 강제할 수 있습니다 [55-57]. 
+  - 수동 메모이제이션 방식(`React.memo`, `useMemo`)은 남용할 경우 비교 연산 및 메모리 저장이라는 자체적인 비용(Overhead)으로 인해 오히려 렌더링보다 더 큰 지연을 유발할 수 있다고 주장됩니다 [41]. 하지만 React 19부터 도입된 React Compiler는 이를 빌드 도구가 정적 분석을 통해 자동으로 최적화해 주어, 오버-메모이제이션의 함정 없이 성능을 보장할 수 있다고 설명합니다 [11, 44, 58].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/React 기반 프론트엔드 성능 최적화.md b/10_Wiki/Topics_Art/UI_UX_Assets/React 기반 프론트엔드 성능 최적화.md
new file mode 100644
index 00000000..83db400a
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/React 기반 프론트엔드 성능 최적화.md	
@@ -0,0 +1,40 @@
+# [[React 기반 프론트엔드 성능 최적화]]
+
+## 📌 Brief 시 Summary
+React 기반 프론트엔드 성능 최적화는 불필요한 연산과 네트워크 페이로드를 최소화하여 빠르고 반응성 높은 사용자 경험을 제공하기 위한 일련의 기술적 접근이다 [1, 2]. 브라우저의 렌더링 경로(CRP)에서 발생하는 병목 현상을 줄이는 기초적인 최적화부터, 가상 DOM(Virtual DOM)의 재조정(Reconciliation) 과정과 리렌더링을 제어하는 React 고유의 최적화 기법을 포괄한다 [2-4]. 현대의 React는 Fiber 아키텍처, 자동 배칭, React Compiler를 통한 자동 메모이제이션, 그리고 React Server Components(RSC)를 활용하여 LCP, INP, CLS와 같은 핵심 웹 지표(Core Web Vitals)를 개선하고 애플리케이션의 성능을 극대화한다 [1, 5-9].
+
+## 📖 Core Content
+
+**1. 브라우저 렌더링 과정 (Critical Rendering Path) 및 Reflow/Repaint 최소화**
+브라우저가 화면을 그리는 렌더링 경로는 HTML 파싱을 통한 **DOM 트리 생성**, CSS 파싱을 통한 **CSSOM 트리 생성**, 이 둘을 결합한 **Render Tree 생성**, 요소의 크기와 위치를 계산하는 **Layout(Reflow)**, 픽셀을 화면에 그리는 **Paint(Repaint)**, 그리고 레이어를 합성하는 **Compositing** 단계로 이루어진다 [10-13]. 
+* **Reflow (Layout):** 요소의 크기(width, height)나 위치, 여백(margin, padding)이 변경될 때 발생하며, 문서 내 다른 요소들의 기하학적 구조까지 다시 계산해야 하므로 연산 비용이 매우 크다 [12, 14, 15]. DOM 노드의 깊이를 줄이고 레이아웃 스래싱(Layout Thrashing)을 방지하는 것이 중요하다 [14, 16].
+* **Repaint (Paint):** 배경색(background-color), 그림자(box-shadow) 등 시각적 속성만 변경될 때 발생하며 레이아웃 변경은 수반하지 않으나, 과도하게 발생할 경우 렌더링 파이프라인을 방해할 수 있다 [14, 17, 18]. 
+* **최적화 방법:** Reflow와 Repaint를 최소화하기 위해 DOM 상호작용을 줄이고, 애니메이션 구현 시 `top`이나 `left` 대신 GPU 가속을 받을 수 있는 `transform` 속성을 사용하는 것이 권장된다 [18-21]. 
+
+**2. React가 빠른 이유: Virtual DOM과 재조정(Reconciliation)**
+React는 실제 DOM을 직접 조작하는 것의 비효율성을 극복하기 위해 메모리 내에 가벼운 UI 표현인 **가상 DOM(Virtual DOM)**을 유지한다 [22, 23]. 상태가 변경되면 React는 새로운 가상 DOM 트리를 생성하고 이전 트리와 비교(Diffing)하여 변경된 부분만 실제 DOM에 적용한다 [22, 23]. 이 "재조정" 과정은 $O(n^3)$의 복잡도를 가지는 기존 트리 비교 알고리즘 대신, 요소의 타입이 다르면 트리를 완전히 새로 구축하고 리스트에서는 `key` prop을 통해 요소를 추적하는 휴리스틱 기반의 **$O(n)$ 최적화 알고리즘**을 사용하여 처리 속도를 비약적으로 높였다 [24-27].
+
+**3. Fiber 아키텍처와 동시성 렌더링(Concurrent Rendering)**
+React 16부터 도입된 **Fiber 아키텍처**는 기존의 동기적이고 차단적인 렌더링을 개선하기 위해 렌더링 작업을 중단하고 재개할 수 있는 '작업 단위(Unit of Work)'로 분할한다 [28-30]. 
+* **렌더 단계(Render Phase):** 부수 효과(Side effect) 없이 가상 DOM 트리를 순회하며 변경 사항을 계산하는 단계로, 높은 우선순위의 작업이 들어오면 언제든 중단되거나 재시작될 수 있다 [31, 32].
+* **커밋 단계(Commit Phase):** 계산된 변경 사항을 실제 DOM에 동기적으로 한 번에 적용하며, 이 단계는 중단할 수 없다 [32, 33].
+Fiber는 우선순위 시스템(Lanes)을 통해 사용자 입력과 같은 긴급한 작업을 데이터 페칭 같은 덜 긴급한 작업보다 먼저 처리할 수 있게 한다 [34, 35]. React 19의 `useTransition`과 `useDeferredValue` 훅은 이 아키텍처를 활용하여 무거운 연산 중에도 메인 스레드를 차단하지 않고 UI 반응성(INP 지표)을 유지하는 동시성 기능을 제공한다 [36-38].
+
+**4. 리렌더링 통제와 React Compiler의 도입**
+컴포넌트의 상태가 변경될 때마다 하위 트리의 모든 컴포넌트가 다시 렌더링되는 '리렌더링 폭포(Re-render Cascade)' 현상은 React 성능 저하의 주요 원인이다 [4, 39].
+* **수동 메모이제이션:** 기존에는 이를 막기 위해 `React.memo`, `useMemo`, `useCallback`을 사용하여 props가 변경되지 않았을 때의 렌더링을 수동으로 차단했다 [40-42]. 하지만 이 방식은 코드 복잡도를 높이고 참조 일치성 관리에 따른 잦은 실수를 유발했다 [43].
+* **React Compiler (자동 메모이제이션):** React 19부터 도입된 React Compiler는 빌드 타임에 AST(추상 구문 트리)를 분석하여 데이터 흐름을 파악하고, 필요한 곳에 자동으로 메모이제이션 경계를 삽입한다 [8, 9, 44, 45]. 이를 통해 개발자는 성능 최적화 코드를 직접 작성하지 않아도 세밀한 반응성(Fine-Grained Reactivity)을 얻어 최대 60% 이상의 불필요한 리렌더링을 줄일 수 있다 [8, 46, 47].
+* **자동 배칭(Automatic Batching):** React 18부터는 Promise나 setTimeout 같은 비동기 콜백 내에서 여러 상태 업데이트가 발생하더라도 이를 묶어 단 한 번의 리렌더링만 트리거하는 자동 배칭이 기본적으로 적용되어 성능을 최적화한다 [7, 48-50].
+
+**5. 렌더링 전략의 진화 (CSR vs SSR vs SSG vs RSC)**
+* **CSR (Client-Side Rendering):** 자바스크립트를 다운로드한 후 브라우저에서 UI를 렌더링하므로 상호작용이 빠르지만, 초기 로드(FCP)가 느리고 SEO에 불리하다 [51-53].
+* **SSR (Server-Side Rendering) & SSG (Static Site Generation):** 서버에서 HTML을 완성하여 전송해 초기 표시 속도와 SEO를 개선한다 [54-56]. 브라우저는 HTML을 화면에 그린 후, 자바스크립트를 실행해 이벤트 리스너를 연결하는 **Hydration** 과정을 거쳐 페이지를 상호작용 가능하게 만든다 [54, 57-59]. 
+* **React Server Components (RSC):** 서버에서만 실행되고 클라이언트로 자바스크립트 코드를 일절 보내지 않는(Zero-Bundle) 새로운 컴포넌트 패러다임이다 [60-63]. 무거운 데이터 페칭이나 정적인 UI 렌더링을 서버가 전담하므로, 번들 크기를 비약적으로 줄이고 Hydration 비용 자체를 제거하여 성능을 극대화한다 [62, 64, 65]. 대규모 애플리케이션에서는 서버 컴포넌트와 클라이언트 컴포넌트를 혼합하여 각 실행 환경의 장점을 모두 취할 수 있다 [62, 66].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Critical Rendering Path]], [[Virtual DOM]], [[React Fiber Architecture]], [[Hydration]], [[React Compiler]], [[React Server Components]]
+- **Projects/Contexts:** [[Next.js 기반 하이브리드 렌더링 (SSR/SSG/ISR)]], [[React 18/19 마이그레이션 및 동시성 렌더링 적용]]
+- **Contradictions/Notes:** 수동 메모이제이션 방식에 대해 소스 18은 "모든 컴포넌트를 무분별하게 메모이제이션(`React.memo` 등)하는 것은 오버헤드를 증가시켜 역효과를 낼 수 있으므로 프로파일링 후 제한적으로 적용해야 한다"고 주의를 줍니다. 반면 최신 기술인 React Compiler를 다룬 소스 336과 341에 따르면, 컴파일러는 코드 분석을 통해 "실제로 혜택을 제공할 수 있는 지점에 지능적으로 메모이제이션을 삽입"하여 개발자의 오버헤드나 오류 없이 성능을 자동으로 획기적으로 개선한다고 설명합니다.
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/React 렌더링 최적화.md b/10_Wiki/Topics_Art/UI_UX_Assets/React 렌더링 최적화.md
new file mode 100644
index 00000000..8752051b
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/React 렌더링 최적화.md	
@@ -0,0 +1,25 @@
+# [[React 렌더링 최적화]]
+
+## 📌 Brief Summary
+React 렌더링 최적화는 애플리케이션의 불필요한 재렌더링을 방지하고 초기 로드 및 상호작용 속도를 향상시켜 사용자 경험을 개선하는 과정입니다 [1-3]. 기본적으로 부모 컴포넌트의 상태가 변경되면 모든 자식 컴포넌트가 다시 렌더링되는 폭포수(Cascade) 문제가 발생할 수 있습니다 [1, 2]. 이를 해결하기 위해 메모이제이션, React 18의 자동 배칭(Automatic Batching), 동시성 렌더링, 그리고 최근 도입된 React Compiler와 같은 기술을 활용하여 성능 병목을 최소화합니다 [4-8].
+
+## 📖 Core Content
+
+*   **가상 DOM과 재조정(Reconciliation):** React는 DOM의 상태를 추상화한 **가상 DOM(Virtual DOM)**을 메모리에 유지하며, 상태가 변경될 때 이전 트리와 새로운 트리를 비교하여 실제 DOM에 필요한 최소한의 변경 사항만 업데이트합니다 [9-11]. 이 비교 과정에서는 **요소의 타입이 다르면 트리를 처음부터 다시 구축하고, 고유한 `key`를 사용하여 리스트 항목의 변경을 추적**하는 O(n) 복잡도의 휴리스틱 알고리즘을 사용합니다 [12-15].
+*   **Fiber 아키텍처와 동시성 렌더링(Concurrent Rendering):** 기존의 동기식 렌더링이 메인 스레드를 차단하는 문제를 해결하기 위해 도입된 **Fiber 아키텍처는 렌더링 작업을 작은 '작업 단위(units of work)'로 나누어 처리**합니다 [16-18]. 중요도(Lane)에 따라 긴급한 상호작용을 우선 처리하고 무거운 작업은 양보하는 '타임 슬라이싱(Time-slicing)'을 지원합니다 [17, 19, 20]. React 19의 `useTransition` 및 `useDeferredValue` 훅을 사용하면 무거운 연산 중에도 메인 스레드를 차단하지 않고 UI 반응성을 유지할 수 있습니다 [5, 21, 22].
+*   **메모이제이션(Memoization):** 컴포넌트의 불필요한 재렌더링을 막기 위해 **`React.memo`, `useMemo`, `useCallback`을 사용하여 이전 계산 결과나 컴포넌트 상태를 캐싱**합니다 [4, 23, 24]. 그러나 매 렌더링마다 인라인 객체나 함수를 생성하면 참조 동등성(reference equality)이 깨져 메모이제이션이 무효화될 수 있습니다 [25-27]. 무분별한 메모이제이션은 오히려 비교 연산 및 메모리 오버헤드를 발생시키므로, 반드시 프로파일링을 통해 병목 지점을 찾은 후 선택적으로 적용해야 합니다 [23, 28].
+*   **자동 배칭(Automatic Batching):** React 18부터는 네이티브 이벤트 핸들러뿐만 아니라 **Promise, `setTimeout` 등 비동기 작업 내에서 발생하는 여러 상태 업데이트를 단일 재렌더링으로 묶어 처리**합니다 [6, 29-31]. 이를 통해 렌더링 횟수를 대폭 줄여 프레임 드롭을 방지할 수 있으며, 즉각적인 DOM 업데이트가 필요한 경우에는 `flushSync` API를 사용하여 배칭에서 예외 처리할 수 있습니다 [32-34].
+*   **React Compiler를 통한 자동화:** React 19에 도입된 React Compiler는 빌드 타임에 코드의 추상 구문 트리(AST)를 분석하여 **필요한 곳에 자동으로 메모이제이션 경계를 삽입**합니다 [7, 35-38]. 개발자가 수동으로 의존성 배열(dependency array)을 관리할 필요성이 사라지며, 성능 향상은 물론 코드의 가독성과 유지보수성도 크게 개선됩니다 [7, 23, 39].
+*   **기타 구조적 최적화 기법:**
+    *   **코드 스플리팅:** `React.lazy()`를 활용해 초기 번들 크기를 줄여 LCP(Largest Contentful Paint) 속도를 개선합니다 [40, 41].
+    *   **가상화(Virtualization):** `react-window` 등을 사용하여 수천 개의 리스트 중 화면에 보이는 DOM 노드만 렌더링합니다 [42, 43].
+    *   **DOM 노드 감소 및 상태 분리:** 불필요한 래퍼를 줄이는 React Fragment의 사용과, 렌더링 파급력을 최소화하기 위해 Context를 업데이트 빈도에 따라 분리하는 기법이 있습니다 [44-46].
+    *   **React Server Components (RSC):** 상호작용이 없는 정적 컴포넌트를 서버에서 전적으로 렌더링해 클라이언트 측으로 전송되는 JavaScript 페이로드를 원천적으로 차단합니다 [47-49].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Virtual DOM]], [[Reconciliation]], [[Fiber Architecture]], [[Automatic Batching]], [[React Compiler]], [[React Server Components]]
+- **Projects/Contexts:** [[프론트엔드 성능 최적화]], [[Core Web Vitals 개선 전략]], [[대규모 단일 페이지 애플리케이션(SPA) 구축]]
+- **Contradictions/Notes:** 기존에는 `useMemo`와 `useCallback`과 같은 수동 메모이제이션이 렌더링 최적화의 핵심으로 여겨졌으나, 새로운 React Compiler의 등장으로 이러한 수동 제어는 대부분 불필요해지거나 오히려 안티 패턴이 될 가능성이 제기되었습니다 [23, 39, 50]. 다만 서드파티 라이브러리의 불안정한 참조 반환 등 일부 엣지 케이스에서는 여전히 수동 메모이제이션이 이스케이프 해치(Escape hatch)로 사용됩니다 [51-53].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/“React가 빠른 이유” 및 렌더링 최적화 개념.md b/10_Wiki/Topics_Art/UI_UX_Assets/“React가 빠른 이유” 및 렌더링 최적화 개념.md
new file mode 100644
index 00000000..7b8304e0
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/“React가 빠른 이유” 및 렌더링 최적화 개념.md	
@@ -0,0 +1,30 @@
+# [[“React가 빠른 이유” 및 렌더링 최적화 개념]]
+
+## 📌 Brief Summary
+React가 빠른 핵심 이유는 브라우저의 무거운 실제 DOM 조작을 최소화하기 위해 가벼운 메모리 내 표현인 Virtual DOM을 사용하고, 효율적인 Reconciliation(조정) 알고리즘을 통해 변경된 부분만 갱신하기 때문입니다 [1-4]. 렌더링 최적화의 근본적인 목표는 연산 비용이 높은 브라우저의 Reflow(레이아웃)와 Repaint를 줄이는 것이며 [5-7], 최근 React는 Fiber 아키텍처, 자동 배칭(Automatic Batching), React Compiler 등을 도입하여 개발자의 수동 개입 없이도 동시성 렌더링과 메모이제이션을 자동화해 UI 성능을 극대화하고 있습니다 [8-11].
+
+## 📖 Core Content
+
+**브라우저 렌더링 과정 (Critical Rendering Path) 및 병목**
+브라우저는 HTML을 파싱하여 DOM(Document Object Model)을 구축하고, CSS를 파싱하여 CSSOM을 만든 뒤 이 둘을 결합하여 화면에 보일 요소들만 포함하는 렌더 트리(Render Tree)를 생성합니다 [12-15]. 이 트리를 바탕으로 각 요소의 정확한 크기와 위치를 계산하는 Layout(또는 Reflow) 단계를 거쳐, 최종적으로 화면에 픽셀을 그리는 Paint(또는 Repaint) 작업을 수행합니다 [5, 16-20]. 요소의 너비, 높이, 위치 등을 변경하면 전체 페이지의 레이아웃을 다시 계산해야 하는 Reflow가 발생하며, 이는 매우 연산 비용이 높고 렌더링 성능 저하의 주된 원인이 됩니다 [5, 6, 21, 22].
+
+**Virtual DOM과 Reconciliation (조정 알고리즘)**
+직접적인 DOM 조작의 비효율성을 극복하기 위해 React는 Virtual DOM(VDOM)이라는 가상의 UI 트리를 메모리에 유지합니다 [1, 2, 4]. 상태가 변경되면 React는 새로운 Virtual DOM을 생성하고 이전 트리와 비교(Diffing)합니다 [2, 23]. React의 조정 알고리즘은 O(n)의 시간 복잡도를 가지며, "서로 다른 타입의 요소는 다른 트리를 생성한다"는 가정과 리스트 렌더링 시 `key` 속성을 사용하여 변경, 추가, 삭제된 최소한의 노드만 식별해 실제 DOM에 패치(Patch)합니다 [1, 3, 24-26]. 이를 통해 불필요한 Reflow와 Repaint를 방지합니다.
+
+**Fiber 아키텍처와 우선순위 기반 스케줄링**
+React 16부터 도입된 Fiber 아키텍처는 동기식 렌더링의 한계를 해결하기 위해 렌더링 작업을 'Fiber 노드'라는 작은 작업 단위로 나눕니다 [8, 27-30]. 이 구조는 '타임 슬라이싱(Time-Slicing)'을 가능하게 하여, 렌더링 도중에도 사용자 입력이나 애니메이션 같은 긴급한 작업(Sync Lane)이 발생하면 기존 작업을 중단(Pause) 및 양보(Yield)하고 우선순위가 높은 작업을 먼저 처리할 수 있도록 돕습니다 [27, 30-34]. 그 결과 메인 스레드 차단을 막아 끊김 없는 UI(동시성 렌더링)를 제공합니다.
+
+**React 최신 버전의 자동 렌더링 최적화**
+*   **자동 배칭 (Automatic Batching):** React 18은 이벤트 핸들러뿐만 아니라 Promise, setTimeout 등 모든 출처에서 발생하는 상태 업데이트를 묶어서 단 한 번의 리렌더링으로 처리합니다 [9, 35-38]. 이로 인해 Virtual DOM 디핑 연산과 실제 DOM 업데이트 횟수가 크게 줄어듭니다.
+*   **React Compiler:** React 19에서 도입된 컴파일러는 빌드 타임에 코드의 AST(추상 구문 트리)를 분석하여 정적 값과 반응형 값을 식별하고 자동으로 메모이제이션을 삽입합니다 [10, 39-41]. 이는 상위 컴포넌트의 상태 변경으로 인한 하위 컴포넌트의 연쇄 리렌더링(Re-render Cascade)을 차단하며, 개발자가 직접 `useMemo`나 `useCallback`을 작성하는 수고를 덜어줍니다 [10, 11, 42-44].
+
+**서버 컴포넌트 (React Server Components, RSC)**
+기존 CSR(클라이언트 사이드 렌더링)이나 SSR(서버 사이드 렌더링) 환경에서는 클라이언트가 결국 방대한 크기의 JavaScript 번들을 다운로드하고 실행(Hydration)해야 하는 부담이 있었습니다 [45-48]. React Server Components는 서버에서 컴포넌트를 실행한 뒤 직렬화된 UI와 HTML만을 클라이언트로 스트리밍합니다 [49-51]. 결과적으로 서버 컴포넌트는 클라이언트 측 자바스크립트 번들에 0바이트를 추가하며, 브라우저의 다운로드 및 실행 부담을 없애 무거운 데이터 연산이나 정적 UI 렌더링 속도를 극대화합니다 [49, 51-53].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** `[[Virtual DOM]]`, `[[Reconciliation]]`, `[[Critical Rendering Path]]`, `[[React Fiber]]`, `[[Hydration]]`, `[[Reflow and Repaint]]`
+- **Projects/Contexts:** `[[React 18 Automatic Batching]]`, `[[React 19 Compiler]]`, `[[React Server Components]]`, `[[Next.js Rendering Strategies]]`
+- **Contradictions/Notes:** 이전까지는 불필요한 렌더링을 막기 위해 개발자가 `useMemo`, `useCallback`, `React.memo`를 사용한 수동 메모이제이션을 구현하는 것이 필수적인 최적화 기법이었습니다 [43, 54, 55]. 그러나 React 19 컴파일러의 등장으로 이러한 수동 메모이제이션의 90% 이상이 불필요해졌으며, 컴파일러가 최적의 메모이제이션 경계를 자동으로 판단하여 적용합니다 [10, 44, 56, 57]. 단, 타사 라이브러리(Third-party library)가 렌더링마다 불안정한 참조를 반환하는 경우 컴파일러 최적화가 실패할 수 있어, 여전히 제한적인 상황에서는 수동 제어가 필요할 수 있습니다 [58, 59].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/브라우저 메인 스레드 최적화 및 타임 슬라이싱.md b/10_Wiki/Topics_Art/UI_UX_Assets/브라우저 메인 스레드 최적화 및 타임 슬라이싱.md
new file mode 100644
index 00000000..4b803ded
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/브라우저 메인 스레드 최적화 및 타임 슬라이싱.md	
@@ -0,0 +1,26 @@
+# [[브라우저 메인 스레드 최적화 및 타임 슬라이싱]]
+
+## 📌 Brief Summary
+브라우저 메인 스레드 최적화 및 타임 슬라이싱은 단일 스레드로 동작하는 브라우저의 특성상 발생할 수 있는 UI 멈춤(Jank) 현상을 방지하고 상호작용성을 높이기 위한 아키텍처 접근 방식입니다 [1, 2]. 거대한 렌더링 작업을 중단 불가능한 하나의 동기적 작업으로 처리하는 대신, 타임 슬라이싱을 통해 작업을 작은 청크(단위)로 분할합니다 [1, 3]. 이를 통해 메인 스레드는 무거운 렌더링 작업을 중간에 일시 중지하고 사용자 입력과 같은 긴급한 고우선순위 작업을 먼저 처리한 후 남은 렌더링을 재개할 수 있어 애플리케이션의 반응성을 극대화합니다 [1, 4, 5].
+
+## 📖 Core Content
+
+- **메인 스레드의 한계와 동기적 블로킹 문제:** 
+  브라우저는 기본적으로 단일 스레드(Single-threaded) 환경에서 작동하며, 한 번에 하나의 태스크를 처음부터 끝까지 실행합니다 [2]. 메인 스레드는 HTML/CSS 파싱, 자바스크립트 실행, 스타일 계산, 레이아웃(Reflow) 및 페인트(Paint) 등의 렌더링 파이프라인을 모두 책임집니다 [6, 7]. 부드러운 스크롤과 상호작용을 유지하려면 16.67ms(60 FPS) 이내에 프레임 렌더링을 완료해야 합니다 [1, 7]. 그러나 대규모 컴포넌트 트리 업데이트를 단일 재귀 호출로 처리하면 이 프레임 예산을 초과하여 메인 스레드를 오랫동안 점유하게 되며, 이는 TTI(Time to Interactive)를 늦추고 브라우저가 사용자 입력에 반응하지 못하게 만듭니다 [1, 8, 9].
+
+- **타임 슬라이싱(Time-Slicing)과 Fiber 아키텍처:** 
+  이러한 메인 스레드 블로킹 문제를 해결하기 위해 React는 렌더링 작업을 작은 '작업 단위(Units of Work)'로 나누는 Fiber 아키텍처를 도입했습니다 [1, 10]. 타임 슬라이싱은 무거운 업데이트 작업을 작은 청크로 쪼개는 기법입니다 [3]. 작업 루프(Work loop)는 각 작업 단위를 처리한 후 브라우저에 남은 여유 시간이 있는지, 또는 사용자 입력과 같은 긴급한 작업이 들어왔는지 확인합니다 [4]. 만약 시간이 부족하면 렌더링 작업을 일시 중지하고 메인 스레드의 제어권을 브라우저에게 양보(Yield)합니다 [4, 11].
+
+- **스케줄링과 우선순위(Lanes) 제어:** 
+  스케줄러는 UI 업데이트의 우선순위를 지능적으로 관리하는 역할을 합니다 [3]. 사용자 입력(클릭, 타이핑)과 같은 작업은 가장 높은 우선순위(Sync Lane)에 할당되어 즉시 처리되며, 백그라운드 데이터 처리나 무거운 리스트 필터링 등은 낮은 우선순위로 밀려납니다 [12-14]. 스케줄러는 메인 스레드가 바쁘거나 더 높은 우선순위의 작업이 도착하면 현재 진행 중인 작업(WIP Fiber)을 일시 중지(Pause)시키고, 메인 스레드가 유휴 상태가 되었을 때 중단된 지점부터 다시 재개(Resume)합니다 [5]. 이 과정에서 `requestIdleCallback`과 같은 브라우저 API를 활용하여 UI가 멈추지 않도록 방지합니다 [11].
+
+- **최적화 지표 및 동시성 렌더링(Concurrent Rendering):** 
+  이러한 타임 슬라이싱과 우선순위 제어를 바탕으로 React 19의 `useTransition` 및 `useDeferredValue`와 같은 동시성 기능이 작동합니다 [15, 16]. 이 기능들은 무거운 연산을 비긴급 업데이트로 분류하여 메인 스레드가 사용자 입력에 즉각적으로 반응할 수 있는 공간을 확보해 줍니다 [15, 17]. 이는 자바스크립트 실행 속도 자체를 물리적으로 높이는 것은 아니지만, 긴급한 사용자 피드백이 지연되지 않게 하여 앱이 "더 빠르게 느껴지도록(Feel faster)" 인지적 성능을 크게 향상시키며, 결과적으로 INP(Interaction to Next Paint) 코어 웹 바이탈 지표를 직접적으로 개선합니다 [17, 18].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[React Fiber Architecture]], [[Concurrent Rendering]], [[Critical Rendering Path]]
+- **Projects/Contexts:** [[React 18/19]], [[Core Web Vitals (INP, TTI)]]
+- **Contradictions/Notes:** 과거 React의 스택 리컨실러(Stack Reconciler)는 렌더링 작업이 한 번 시작되면 트리를 끝까지 동기적으로 순회해야 했기 때문에 메인 스레드를 블로킹하는 치명적 단점이 있었으나, Fiber 도입 이후 이를 중단 및 재개 가능한(Interruptible) 렌더링 모델로 개선했다는 사실이 소스 전반에 걸쳐 강조됩니다 [1, 19, 20]. 타임 슬라이싱은 코드 자체를 빠르게 만드는 것이 아니라 메인 스레드 가용성을 확보하여 체감 성능을 향상시키는 구조적 접근임을 유의해야 합니다 [18].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file
diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/프론트엔드 성능 최적화 전략.md b/10_Wiki/Topics_Art/UI_UX_Assets/프론트엔드 성능 최적화 전략.md
new file mode 100644
index 00000000..9ff26920
--- /dev/null
+++ b/10_Wiki/Topics_Art/UI_UX_Assets/프론트엔드 성능 최적화 전략.md	
@@ -0,0 +1,31 @@
+# [[프론트엔드 성능 최적화 전략]]
+
+## 📌 Brief Summary
+프론트엔드 성능 최적화 전략은 브라우저의 렌더링 과정(Critical Rendering Path)을 효율적으로 관리하고, 불필요한 연산과 네트워크 다운로드를 줄여 사용자에게 빠르고 매끄러운 웹 경험을 제공하는 기술적 접근 방식이다 [1, 2]. 이를 위해 개발자는 초기 로딩 속도 개선, 렌더링 시 발생하는 Reflow 및 Repaint의 최소화, 효율적인 상태 관리 및 적절한 웹 렌더링 전략(CSR, SSR, SSG 등)을 종합적으로 고려해야 한다 [1, 3-6]. 궁극적인 목표는 LCP(최대 콘텐츠 풀 페인트), INP(다음 페인트에 대한 상호작용), CLS(누적 레이아웃 이동)와 같은 핵심 웹 바이탈(Core Web Vitals) 지표를 개선하여 비즈니스 성과와 사용자 만족도를 높이는 것이다 [7-10].
+
+## 📖 Core Content
+*   **브라우저 렌더링 최적화 (Critical Rendering Path 관리)**
+    *   브라우저가 화면을 그리는 과정에서 렌더링 차단 리소스(CSS, 동기식 JavaScript)를 최소화하여 페이지 초기 렌더링 속도를 앞당겨야 한다 [11-13].
+    *   DOM 트리 및 CSSOM 트리를 생성할 때, 불필요한 DOM 노드의 깊이를 줄이고 CSS 선택자 복잡도를 낮추어 연산 부담을 경감시키는 것이 중요하다 [11, 14-19].
+*   **Reflow 및 Repaint 최소화**
+    *   브라우저 화면의 레이아웃을 재계산하는 Reflow 연산은 처리 비용이 매우 크므로, 잦은 DOM 조작이나 레이아웃 요소(width, height, margin 등) 변경을 최소화해야 한다 [20-23].
+    *   애니메이션 적용 시 `top`, `left` 대신 `transform` 속성을 활용하면 GPU 가속을 통해 Reflow를 우회하고 효율적으로 화면을 다시 그릴 수 있다 [21, 23-26].
+    *   DOM 읽기 및 쓰기 작업을 분리하고 일괄 처리(Batching)하여 성능 저하의 주원인인 레이아웃 스래싱(Layout Thrashing)을 방지해야 한다 [27, 28].
+*   **렌더링 전략의 전략적 선택**
+    *   애플리케이션의 특성에 맞춰 Client-Side Rendering (CSR), Server-Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR) 등의 전략을 적절히 혼합하여 사용해야 한다 [29-36].
+    *   **React Server Components (RSC):** 클라이언트 번들 크기를 '0' 바이트로 유지하면서 서버 인프라에 직접 접근해 데이터를 병렬로 가져오는 최신 아키텍처로, TTI(상호작용까지의 시간)를 크게 향상하고 불필요한 클라이언트 연산을 제거한다 [37-46].
+*   **상태 관리 및 프레임워크 수준의 최적화**
+    *   가상 DOM(Virtual DOM) 환경에서 불필요한 리렌더링을 막기 위해 과거에는 `React.memo`, `useMemo`, `useCallback`과 같은 수동 메모이제이션 방식이 주로 쓰였다 [47-50]. 최근 도입된 **React Compiler**는 빌드 시점에 자동으로 메모이제이션 경계를 삽입하여 최적화 작업의 90% 이상을 자동화하고 코드 복잡성을 줄여준다 [51-56].
+    *   **자동 배칭 (Automatic Batching) 및 Concurrent Features:** React 18/19부터는 여러 상태 업데이트를 하나의 렌더링 사이클로 묶어 처리하며 [57-60], Fiber 아키텍처의 레인(Lanes) 기반 우선순위 관리를 통해 `useTransition`이나 `useDeferredValue` 훅으로 무거운 렌더링 작업을 지연시켜 UI 반응성을 유지한다 [61-71].
+*   **리소스 번들링 및 UI 컴포넌트 다이어트**
+    *   **코드 스플리팅(Code Splitting):** `React.lazy()` 등을 통해 필요한 시점에 라우트 단위나 컴포넌트를 지연 로드하여 초기 자바스크립트 번들 크기를 30~50%까지 줄인다 [72, 73]. 미사용 코드를 제거하는 트리 쉐이킹(Tree Shaking) 기법도 필수적이다 [74].
+    *   수백, 수천 개의 데이터 목록을 렌더링할 때는 화면에 보이는 항목만 DOM에 올리는 **가상화(Virtualization)** 기술을 통해 성능 지연을 원천 차단한다 [75, 76].
+    *   용량이 큰 이미지는 WebP/AVIF 같은 차세대 포맷과 네이티브 지연 로딩(`loading="lazy"`)을 통해 초기 페이지 렌더링 방해를 최소화해야 한다 [77, 78].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Critical Rendering Path]], [[Reflow and Repaint]], [[Client-Side Rendering (CSR)]], [[Server-Side Rendering (SSR)]], [[React Server Components]], [[Virtual DOM]], [[React Fiber Architecture]], [[React Compiler]], [[Automatic Batching]]
+- **Projects/Contexts:** [[Core Web Vitals (LCP, INP, CLS) 최적화 작업]], [[대규모 단일 페이지 애플리케이션(SPA) 아키텍처 설계]]
+- **Contradictions/Notes:** 수동 메모이제이션(`useMemo`, `useCallback`)은 오랫동안 프론트엔드 최적화의 필수 원칙이었으나, 가벼운 컴포넌트에서는 얕은 비교 연산 자체가 렌더링보다 높은 오버헤드를 유발할 수 있다 [79, 80]. 최근 React Compiler의 등장으로 인해 개발자가 직접 메모이제이션을 관리할 필요성이 사라지는 방향으로 패러다임이 진화하고 있다 [53, 81]. 또한 SSR은 초기 콘텐츠 로딩(FCP)과 SEO 측면에서 유리하지만, 서버에서 가져온 HTML에 JavaScript를 연결하는 Hydration 과정에서 메인 스레드가 블로킹되면 사용자의 상호작용이 지연되는 병목(높은 TTI) 현상이 일어날 수 있으므로 무조건적인 해결책이 아니라는 점을 유의해야 한다 [30, 82-86].
+
+---
+*Last updated: 2026-04-25*
\ No newline at end of file