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와 Repaint.md

@@ -1,30 +1,24 @@
 # [[Reflow와 Repaint]]
 
 ## 📌 Brief Summary
-Reflow(리플로우)와 Repaint(리페인트)는 웹 브라우저가 화면에 콘텐츠를 렌더링할 때 거치는 핵심 과정이다. Reflow는 DOM 요소의 기하학적 속성(크기, 위치 등)이나 구조가 변경될 때 브라우저가 전체 혹은 일부의 레이아웃을 다시 계산하는 작업이다. 반면, Repaint는 요소의 레이아웃에는 영향을 주지 않고 색상이나 그림자 같은 시각적 스타일만 변경될 때 픽셀을 화면에 다시 그리는 과정을 의미한다. 두 과정 모두 브라우저의 성능과 사용자 경험에 큰 영향을 미치므로 최소화하는 최적화 전략이 필수적이다.
+Reflow(리플로우)는 요소의 크기나 위치 등 레이아웃 구조가 변경될 때 브라우저가 문서의 구조를 다시 계산하는 과정이며, Repaint(리페인트)는 레이아웃에 영향을 주지 않는 시각적 속성(색상 등)이 변경될 때 화면을 다시 그리는 작업입니다 [1, 2]. 두 과정 모두 브라우저의 연산 리소스를 많이 소모하므로, 쾌적한 사용자 경험과 웹 성능을 유지하려면 이를 최소화해야 합니다 [1, 3, 4]. 유지보수와 성능을 모두 고려한 CSS 실전 설계에서는 이러한 브라우저 렌더링 파이프라인의 특성을 이해하고 효율적인 스타일링과 애니메이션 전략을 채택해야 합니다 [3, 5].
 
 ## 📖 Core Content
-*   **브라우저 렌더링 파이프라인 내의 역할**
-    브라우저가 HTML과 CSS를 파싱하여 DOM과 CSSOM을 만들고 이를 결합해 렌더 트리(Render Tree)를 생성한 후, 화면에 요소를 그리기 위해 거치는 핵심 단계가 레이아웃(Layout)과 페인트(Paint)이다 [1-3]. 
+*   **개념과 차이점 및 발생 원인**
+    *   **Reflow (Layout)**: 브라우저 창 크기 조절, 폰트 변경, 새로운 DOM 요소 추가/제거, `width`, `height`, `margin`, `padding`, `top` 등 기하학적 형태나 레이아웃에 영향을 주는 속성이 변경될 때 발생합니다 [3, 6, 7]. 한 요소의 Reflow는 자식 및 조상 요소, 그리고 DOM에서 그 뒤에 나타나는 모든 요소의 연쇄적인 Reflow를 유발하므로 매우 큰 비용이 듭니다 [2, 4]. 
+    *   **Repaint**: `color`, `background-color`, `outline`, `visibility` 등 요소의 레이아웃에는 영향을 주지 않으면서 겉모습만 변경될 때 발생합니다 [2, 3, 6]. 
 
-*   **Reflow (레이아웃 재계산)**
-    *   **정의:** 브라우저가 뷰포트 크기와 박스 모델을 기반으로 화면에 표시되는 모든 요소의 정확한 위치와 크기를 계산하는 과정으로, 레이아웃(Layout)이라고도 불린다 [3-5]. 
-    *   **발생 조건 및 비용:** 브라우저 창 크기 조절, DOM 요소 추가/제거, 폰트 크기 변경, 또는 `width`, `height`, `margin`, `padding` 등 레이아웃에 영향을 주는 속성을 수정할 때 발생한다 [6-8]. 렌더 트리의 루트에서 시작하여 아래로 진행되며, 하나의 기하학적 변화가 트리 전체의 연산 캐스케이드를 유발할 수 있어 연산 비용이 매우 높다 [3, 9].
-
-*   **Repaint (화면 다시 그리기)**
-    *   **정의:** 계산된 기하학적 구조와 스타일을 화면의 픽셀로 변환하여 래스터화(Rasterizing)하는 과정이다 [6, 10, 11].
-    *   **발생 조건 및 비용:** 기하학적 구조 변경 없이 `background-color`, `box-shadow`, 텍스트 색상, 투명도 등 시각적 스타일만 변경될 때 발생한다 [6-8]. 기하학적 구조를 다시 계산하지 않으므로 Reflow보다는 연산 비용이 적게 들지만, 애니메이션 도중 과도하게 발생하면 프레임 저하(frame drop)를 유발할 수 있다 [9, 10].
-
-*   **성능 영향 및 최적화 전략**
-    *   **성능 저하 문제:** 빈번한 Reflow와 Repaint는 렌더링 파이프라인을 방해하여 스크롤이나 애니메이션 시 끊김 현상(Jank)을 발생시키고, 모바일 기기에서 CPU와 GPU 사용량을 높여 배터리 수명을 단축시킨다 [12, 13].
-    *   **최적화 방법:** 
-        *   **Reflow 최소화:** 레이아웃 스래싱(layout thrashing)을 피하고 DOM 업데이트를 일괄 처리(batching)해야 한다 [6, 13]. `width`나 `height` 대신 최신 레이아웃 기법인 Flexbox나 Grid를 사용하면 더 효율적이다 [13]. 또한 애니메이션 요소에는 `top`, `left` 대신 `transform` 속성을 사용하면 Reflow를 유발하지 않고 GPU 가속을 활용할 수 있다 [9, 10, 13].
-        *   **Repaint 최소화:** 그림자나 그라데이션 같이 리페인트를 유발하는 속성 사용을 줄이고, 요소를 숨길 때 요소가 공간을 차지하게 두려면 `display: none`(Reflow 유발) 대신 `visibility: hidden`을 사용하여 Reflow 없이 Repaint만 발생하도록 최적화할 수 있다 [14].
+*   **성능 최적화 및 유지보수를 위한 CSS 설계 기법**
+    *   **레이아웃 스래싱(Layout Thrashing) 방지 및 DOM 조작 최소화**: JavaScript를 통해 다수의 인라인 스타일을 설정하면 개별적으로 Reflow가 발생합니다 [5, 8]. 변경 사항을 외부 CSS 클래스에 그룹화하여 한 번의 조작으로 DOM 트리의 클래스 속성을 변경하는 방식이 성능과 유지보수에 훨씬 유리합니다 [8, 9]. DOM을 읽고 쓰는 과정을 철저히 분리하여 레이아웃 스래싱을 방지해야 합니다 [10].
+    *   **클래스 변경의 범위 제한**: Reflow의 파급 범위를 줄이려면 DOM 트리에서 가능한 가장 낮은 위치(하위 노드)에 있는 요소의 클래스를 변경해야 합니다 [5, 11]. 
+    *   **올바른 애니메이션(transition/keyframes) 전략**: `width`, `height`, `box-shadow` 등의 속성을 애니메이션으로 처리하면 지속적으로 Reflow와 Repaint를 유발해 화면이 끊길 수 있습니다 [6, 12, 13]. 대신 레이아웃을 다시 계산하지 않는 `transform`과 `opacity`, `filter` 속성만 사용하여 애니메이션을 작성해야 GPU 가속(Compositing)을 통한 부드러운 렌더링이 가능해집니다 [3, 13, 14].
+    *   **요소의 위치 및 속성 분리**: 애니메이션이 들어간 요소에 `position: fixed` 또는 `absolute`를 적용하면 해당 요소가 문서의 흐름에서 분리되어 주변 요소의 레이아웃에 영향을 주지 않으므로, 비용이 큰 전체 Reflow 대신 Repaint만 발생시킬 수 있습니다 [5, 8, 15]. 
+    *   **선택자 및 레이아웃 구조 단순화**: 다중 경로를 요구하는 복잡한 CSS 선택자를 피하고 [9], 전체 노드의 Reflow를 자주 유발하는 테이블(`table`) 기반의 레이아웃을 피해야 합니다 [5, 16].
 
 ## 🔗 Knowledge Connections
-- **Related Topics:** [[Critical Rendering Path]], [[Render Tree]], [[DOM]], [[CSSOM]], [[GPU 가속(GPU Acceleration)]]
-- **Projects/Contexts:** [[프론트엔드 성능 최적화(Frontend Performance Optimization)]], [[웹 렌더링 최적화(Web Rendering Optimization)]]
-- **Contradictions/Notes:** 소스에 따르면 Reflow는 Repaint에 비해 훨씬 무거운 작업이므로(computationally heavier) 최적화의 1순위 대상이 됩니다 [15]. Reflow가 발생하면 변경된 레이아웃을 다시 그려야 하므로 필연적으로 Repaint가 뒤따르지만, 반대로 Repaint는 Reflow 없이 단독으로 발생할 수 있습니다 [7, 8].
+- **Related Topics:** [[CSS 애니메이션 성능 최적화 (transition / keyframes)]], [[CSS 구조 설계 방식]], [[DOM 렌더링 파이프라인]]
+- **Projects/Contexts:** [[실무에서 CSS 관리하는 방법]], [[유지보수 가능하게 CSS 아키텍처 구축]]
+- **Contradictions/Notes:** 빈번하게 변경되는 요소에 대해 브라우저가 미리 최적화를 준비할 수 있게 하는 `will-change` 속성은 성능 향상에 큰 도움이 됩니다 [10, 17, 18]. 하지만 이 속성을 불필요하게 너무 많은 요소에 남용할 경우 도리어 브라우저의 리소스를 과도하게 소모시켜 성능 저하(Performance issues)를 일으킬 수 있으므로 최후의 수단으로만 신중히 사용해야 합니다 [17, 18].
 
 ---
-*Last updated: 2026-04-25*
+*Last updated: 2026-04-26*