feat: massive wikification of styling systems and SaaS architecture

Processed 100+ files including Design Systems, CSS Architectures, and Enterprise Frontend strategies.

10_Wiki/Topics/Frontend_Mastery/Reflow and Repaint.md

@@ -1,33 +1,31 @@
 # [[Reflow and Repaint]]
 
 ## 📌 Brief Summary
-리플로우(Reflow)와 리페인트(Repaint)는 브라우저가 웹 페이지를 화면에 렌더링하기 위해 수행하는 핵심 과정입니다 [1-3]. 리플로우(또는 레이아웃)는 DOM의 구조나 스타일 변경 시 전체 또는 일부 요소의 정확한 위치와 크기를 재계산하는 비용이 높은 작업입니다 [2, 4]. 반면 리페인트는 레이아웃 변경 없이 요소의 시각적 형태(색상, 배경 등)만 업데이트할 때 화면의 픽셀을 다시 그리는 과정으로, 두 과정 모두 과도하게 발생할 경우 웹 성능 저하의 주요 원인이 됩니다 [5, 6].
+Reflow(리플로우)는 요소의 너비, 높이 등 레이아웃에 영향을 미치는 변경이 발생할 때 브라우저가 페이지의 구조를 다시 계산하는 과정이며, Repaint(리페인트)는 배경색 등 시각적 요소만 변경될 때 레이아웃 계산 없이 화면을 다시 그리는 작업입니다 [1, 2]. 이 두 과정은 비용이 많이 드는 작업으로 브라우저 렌더링 성능에 큰 영향을 미치며, 특히 애니메이션이나 동적 UI를 구현할 때 성능 저하와 버벅거림(Jank)의 주된 원인이 됩니다 [1, 3, 4]. 따라서 유지보수 가능하고 확장성 있는 CSS를 설계하기 위해서는 리플로우와 리페인트를 최소화하는 렌더링 최적화 전략이 필수적입니다 [5-7].
 
 ## 📖 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].
+*   **Reflow와 Repaint의 개념**
+    *   **Repaint:** 요소의 가시성(visibility), 배경색(background color), 윤곽선(outline) 등 레이아웃에 영향을 주지 않는 시각적 스킨의 변화가 생길 때 발생합니다 [1, 2]. 브라우저는 DOM 트리에 있는 다른 노드들의 가시성까지 확인해야 하므로 비용이 발생합니다 [2].
+    *   **Reflow:** 요소의 크기(width, height), 여백(margin, padding), 위치(left, top 등) 등 레이아웃 기하학이 변경될 때 발생합니다 [3, 8]. 해당 요소뿐만 아니라 자식 요소, 조상 요소, 그리고 DOM 트리에서 그 뒤에 오는 요소들까지 연쇄적으로 리플로우를 유발하므로 전체 페이지를 다시 배치하는 것과 맞먹는 높은 비용이 듭니다 [2, 4].
 
-* **리페인트(Repaint)의 특성 및 유발 조건**
-  * 요소의 기하학적 구조나 위치는 변경하지 않고 배경색, 글자색, 그림자 등의 시각적 속성만 변경할 때 픽셀을 다시 그리는 과정입니다 [2, 6, 11].
-  * 리플로우보다 연산 비용은 낮지만, 여전히 과도하게 발생할 경우 프레임 드롭(Frame drop)이나 화면 끊김(Jank)을 초래하고 모바일 기기의 배터리 소모를 가속화할 수 있습니다 [5, 9, 12, 13].
+*   **성능 저하를 유발하는 주요 원인**
+    *   창 크기 조절, 폰트 변경, DOM 스크립트 조작, CSS 가상 클래스(`:hover` 등) 활성화, 클래스 속성 변경, `offsetWidth` 및 `offsetHeight` 계산 등 다양한 작업이 리플로우를 유발합니다 [9, 10].
+    *   DOM을 읽고 쓰는 작업을 짧은 루프 안에서 연속적으로 실행하면 브라우저가 강제로 동기적 리플로우를 수행해야 하는 레이아웃 스래싱(Layout Thrashing)이 발생하여 프레임 속도가 크게 저하됩니다 [11, 12]. 
+    *   크기나 여백 같은 레이아웃 속성을 애니메이션으로 처리하면 브라우저가 렌더링 엔진을 매 프레임마다 호출해야 하므로 성능에 치명적입니다 [1, 3].
 
-* **최적화 전략 (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].
+*   **Reflow 및 Repaint 최적화(감소) 기법**
+    *   **GPU 가속 활용:** 레이아웃을 변경하는 속성 대신 `transform`과 `opacity`를 애니메이션에 사용하면 브라우저가 값비싼 Layout과 Paint 단계를 건너뛰고 GPU에서 합성(Compositing)만 처리하므로 성능이 크게 향상됩니다 [8, 13, 14].
+    *   **DOM 변경 및 스타일 적용 최소화:** 여러 개의 인라인 스타일을 각각 설정하는 것을 피하고, 변경 사항을 묶어 CSS 클래스로 처리해야 합니다 [15, 16]. 또한 리플로우의 파급 범위를 줄이기 위해 DOM 트리의 가능한 가장 낮은 하위 노드에서 클래스를 변경해야 합니다 [17].
+    *   **문서 흐름(Flow) 분리:** 애니메이션이 적용되는 요소에는 `position: fixed` 또는 `absolute`를 적용하여 주변 요소의 레이아웃에 영향을 주지 않고 리페인트만 발생하도록 유도할 수 있습니다 [15].
+    *   **테이블 레이아웃 지양:** 테이블은 아주 작은 변화에도 내부의 모든 노드가 리플로우를 일으킬 수 있고, 전체 콘텐츠를 파악하기 위해 여러 번의 렌더링 패스가 필요하므로 레이아웃 목적으로 사용해서는 안 됩니다 [18].
+    *   **렌더링 힌트 제공:** 변경이 빈번하게 일어날 요소에는 `will-change` 속성을 사용하여 브라우저가 미리 렌더링 최적화를 준비하도록 지시할 수 있습니다 [12, 19].
+    *   **애니메이션 주기의 동기화:** `requestAnimationFrame`을 사용하여 자바스크립트 애니메이션을 브라우저의 기본 리페인트 주기와 동기화해야 합니다 [11, 12].
 
-## 🔗 	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].
+## 🔗 Knowledge Connections
+- **Related Topics:** [[CSS Animations]], [[Layout Thrashing]], [[GPU Acceleration (Compositing)]], [[CSS Architecture]]
+- **Projects/Contexts:** [[애니메이션 (transition / keyframes) 성능 최적화]], [[실무에서 CSS 관리하는 방법]]
+- **Contradictions/Notes:** 브라우저 성능 최적화를 돕는 `will-change` 속성은 유용하지만, 최후의 수단으로만 사용해야 합니다. 이를 성능 문제 예측용으로 무분별하게 너무 많은 요소에 남용할 경우, 과도한 메모리 사용 등 그 자체로 심각한 성능 저하를 초래할 수 있다고 경고하고 있습니다 [19, 20].
 
 ---
-*Last updated: 2026-04-25*
+*Last updated: 2026-04-26*