---
category: Unified
tags: [auto-consolidated, technical-documentation]
title: [[Reflow and Repaint|Reflow and Repaint]]
last_updated: 2026-05-02
---

# [[Reflow and Repaint|Reflow and Repaint]]

## 📌 Brief Summary
Reflow(리플로우)는 요소의 너비, 높이 등 레이아웃에 영향을 미치는 변경이 발생할 때 브라우저가 페이지의 구조를 다시 계산하는 과정이며, Repaint(리페인트)는 배경색 등 시각적 요소만 변경될 때 레이아웃 계산 없이 화면을 다시 그리는 작업입니다 [1, 2]. 이 두 과정은 비용이 많이 드는 작업으로 브라우저 렌더링 성능에 큰 영향을 미치며, 특히 애니메이션이나 동적 UI를 구현할 때 성능 저하와 버벅거림(Jank)의 주된 원인이 됩니다 [1, 3, 4]. 따라서 유지보수 가능하고 확장성 있는 CSS를 설계하기 위해서는 리플로우와 리페인트를 최소화하는 렌더링 최적화 전략이 필수적입니다 [5-7].

---

리플로우(Reflow)는 브라우저가 화면 내 요소들의 기하학적 위치와 크기를 재계산하는 과정을 의미하며 컴퓨팅 자원을 많이 소모합니다 [1-3]. 반면 리페인트(Repaint)는 레이아웃에 영향을 주지 않는 시각적 스타일 변화(색상, 그림자 등)를 픽셀로 변환하여 화면에 그리는 작업입니다 [1, 4]. 두 과정 모두 웹 페이지의 크리티컬 렌더링 패스(CRP)에서 화면을 업데이트하는 데 필수적이지만, 과도하게 발생할 경우 웹 페이지의 성능을 크게 저하시키므로 이를 최소화하는 것이 프론트엔드 성능 최적화의 핵심입니다 [5-7].

## 📖 Core Content
*   **Reflow와 Repaint의 개념**
    *   **Repaint:** 요소의 가시성(visibility), 배경색(background color), 윤곽선(outline) 등 레이아웃에 영향을 주지 않는 시각적 스킨의 변화가 생길 때 발생합니다 [1, 2]. 브라우저는 DOM 트리에 있는 다른 노드들의 가시성까지 확인해야 하므로 비용이 발생합니다 [2].
    *   **Reflow:** 요소의 크기(width, height), 여백(margin, padding), 위치(left, top 등) 등 레이아웃 기하학이 변경될 때 발생합니다 [3, 8]. 해당 요소뿐만 아니라 자식 요소, 조상 요소, 그리고 DOM 트리에서 그 뒤에 오는 요소들까지 연쇄적으로 리플로우를 유발하므로 전체 페이지를 다시 배치하는 것과 맞먹는 높은 비용이 듭니다 [2, 4].

*   **성능 저하를 유발하는 주요 원인**
    *   창 크기 조절, 폰트 변경, DOM 스크립트 조작, CSS 가상 클래스(`:hover` 등) 활성화, 클래스 속성 변경, `offsetWidth` 및 `offsetHeight` 계산 등 다양한 작업이 리플로우를 유발합니다 [9, 10].
    *   DOM을 읽고 쓰는 작업을 짧은 루프 안에서 연속적으로 실행하면 브라우저가 강제로 동기적 리플로우를 수행해야 하는 레이아웃 스래싱([[Layout Thrashing|Layout Thrashing]])이 발생하여 프레임 속도가 크게 저하됩니다 [11, 12]. 
    *   크기나 여백 같은 레이아웃 속성을 애니메이션으로 처리하면 브라우저가 렌더링 엔진을 매 프레임마다 호출해야 하므로 성능에 치명적입니다 [1, 3].

*   **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].

---

*   **리플로우(Reflow / Layout)의 메커니즘과 영향:**
    *   브라우저가 뷰포트 크기와 박스 모델을 기반으로 렌더 트리 내 모든 가시적 요소의 정확한 위치와 크기(x, y, 너비, 높이)를 계산하는 과정입니다 [3, 8, 9].
    *   주로 창 크기 조절(Resizing), DOM 요소의 추가 및 제거, 마진이나 패딩 등 레이아웃에 영향을 주는 속성이 변경될 때 트리거됩니다 [1, 4, 10].
    *   문서 흐름(Document flow)의 특성상 단일 요소의 기하학적 변화가 렌더 트리 전체의 연쇄적인 재계산(Cascade of recalculations)을 유발할 수 있으므로, 리플로우는 연산 비용이 매우 높은 작업에 속합니다 [2, 7, 8].

*   **리페인트(Repaint / Paint)의 메커니즘과 영향:**
    *   기하학적 구조 계산이 완료된 후, 스타일 정보를 바탕으로 렌더 트리의 각 노드를 실제 화면의 픽셀로 래스터화(Rasterizing)하는 과정입니다 [1, 11, 12].
    *   배경색, 텍스트 색상, 그림자(box-shadow), 가시성 등 레이아웃 수치를 변경하지 않는 시각적 속성 변화가 있을 때만 발생합니다 [1, 4, 10].
    *   리플로우보다는 계산 비용이 상대적으로 적지만, 애니메이션 도중 과도하게 트리거되면 프레임 드랍이나 버벅거림(Jank)을 일으켜 CPU/GPU 사용량을 높이고 모바일 기기의 배터리를 소모시킬 수 있습니다 [2, 6, 11].

*   **성능 최적화 전략 ([[Optimization|Optimization]] Strategies):**
    *   **CSS 속성 최적화:** 리플로우를 유발하는 속성(예: `top`, `left`, `width`, `height`) 대신 `transform` 속성을 활용하여 애니메이션을 구현하면, 새로운 레이아웃이나 페인트 사이클을 유발하지 않고 GPU 가속을 통해 처리할 수 있습니다 [6, 7, 11]. 
    *   **가시성 제어 활용:** 요소를 화면에서 숨길 때 렌더 트리에서 완전히 제거하여 리플로우를 유발하는 `display: none` 대신, 시각적으로만 숨기고 공간을 유지해 리페인트만 유발하는 `visibility: hidden`을 사용하는 것이 유리할 수 있습니다 [13, 14].
    *   **DOM 조작 최소화 및 배치([[Batching|Batching]]) 처리:** 자바스크립트 반복문 내에서의 DOM 조작을 피하고 변경 사항을 일괄 처리해야 합니다 [6, 7]. 또한, React와 같이 가상 DOM([[Virtual DOM|Virtual DOM]])을 사용하는 프레임워크는 변경된 부분만을 계산하여 실제 DOM에 반영함으로써 불필요한 리플로우와 리페인트 횟수를 줄이는 데 도움을 줍니다 [6, 15].

## ⚖️ Trade-offs & Caveats
No trade-offs available.

## 🔗 Knowledge Connections
- **Related Topics:** [[CSS Animations|CSS Animations]], Layout Thrashing, GPU Acceleration (Compositing), [[CSS Architecture|CSS Architecture]]
- **Projects/Contexts:** 애니메이션 (transition / keyframes) 성능 최적화, [[실무에서 CSS 관리하는 방법|실무에서 CSS 관리하는 방법]]
- **Contradictions/Notes:** 브라우저 성능 최적화를 돕는 `will-change` 속성은 유용하지만, 최후의 수단으로만 사용해야 합니다. 이를 성능 문제 예측용으로 무분별하게 너무 많은 요소에 남용할 경우, 과도한 메모리 사용 등 그 자체로 심각한 성능 저하를 초래할 수 있다고 경고하고 있습니다 [19, 20].

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

---

- **Related Topics:** [[Critical Rendering Path (CRP)|Critical Rendering Path (CRP]], Render Tree, Virtual DOM, Document Object Model (DOM), CSS Object Model ([[CSSOM|CSSOM]]), GPU Acceleration
- **Projects/Contexts:** 프론트엔드 웹 렌더링 성능 최적화, React의 컴포넌트 아키텍처 및 렌더링 최적화([[Reconciliation|Reconciliation]])
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (제공된 모든 소스는 리플로우와 리페인트의 특성 및 이를 최소화해야 한다는 최적화 원칙에 대해 모순 없이 일치된 견해를 보입니다.)

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