# [[React가 빠른 이유]]

## 📌[[ brief]] Summary
React는 실제 DOM을 직접 조작할 때 발생하는 비용(Reflow 및 Repaint)을 최소화하기 위해 가상 DOM([[Virtual DOM]])과 효율적인 재조정([[Reconciliation]]) 알고리즘을 사용합니다 [1]. 또한 Fiber 아키텍처를 도입하여 렌더링 작업을 잘게 쪼개고 우선순위에 따라 동시성(Concurrent) 렌더링을 처리함으로써 UI의 반응성을 극대화합니다 [2-4]. 최근 버전에서는 자동 배칭([[Automatic Batching]])과 [[React Compiler]]의 자동 메모이제이션을 통해 불필요한 재렌더링을 획기적으로 줄여 더욱 빠르고 최적화된 성능을 제공합니다 [5-8].

## 📖 Core Content
*   **가상 DOM(Virtual DOM)과 재조정(Reconciliation):** 실제 DOM을 직접 수정하는 작업은 브라우저 렌더링 경로(CRP)에서 레이아웃(Reflow)과 페인트(Repaint) 과정을 유발하여 본질적으로 느립니다 [1]. React는 메모리 내에 가벼운 UI 표현인 가상 DOM을 유지합니다 [1, 9, 10]. UI 상태가 변경되면 새로운 가상 DOM을 생성하고 이전 상태와 비교(Diffing)한 뒤, 실제 DOM을 최소한으로만 업데이트(Patch)하는 재조정 과정을 거쳐 불필요한 연산을 방지합니다 [1, 9, 10].
*   **O(n) 휴리스틱 Diffing 알고리즘:** 두 트리를 비교하는 일반적인 알고리즘은 $O(n^3)$의 복잡도를 가지므로 실시간 애플리케이션에 부적합합니다 [11, 12]. React는 서로 다른 타입의 요소는 전혀 다른 트리를 생성한다고 가정하고, 개발자가 제공하는 'Key'를 통해 요소를 식별하는 방식을 사용하여 복잡도를 $O(n)$으로 낮춘 휴리스틱 알고리즘을 사용합니다 [11, 12]. 이를 통해 기존 DOM 노드를 최대한 보존하며 속도를 높입니다 [2, 13].
*   **Fiber 아키텍처와 동시성(Concurrent) 렌더링:** 과거 React의 스택 재조정자(Stack Reconciler)는 동기적으로 전체 트리를 처리하여 메인 스레드를 차단하는 문제가 있었습니다 [3]. React 16부터 도입된 Fiber 아키텍처는 렌더링 작업을 '작업 단위(Unit of work)'로 분할합니다 [3, 14]. 우선순위 차선(Lane) 모델과 타임 슬라이싱([[Time-Slicing]])을 사용하여 높은 우선순위의 작업(예: 사용자 입력)이 들어오면 기존의 렌더링을 일시 중지하고 양보(Yield)한 뒤 나중에 재개할 수 있도록 해 UI 차단을 방지합니다 [3, 4, 15, 16].
*   **자동 배칭(Automatic [[Batching]]):** [[React 18]]은 브라우저 이벤트뿐만 아니라 Promise나 setTimeout과 같은 비동기 작업 내에서 발생하는 여러 상태 업데이트를 단일 재렌더링으로 묶어 처리합니다 [5, 17, 18]. 결과적으로 가상 DOM Diffing 과정과 CPU 작업이 줄어들어 렌더링 횟수가 급감하고 프레임 속도가 향상됩니다 [5, 7, 19, 20].
*   **React Compiler에 의한 자동 메모이제이션:** [[React 19]]에 도입된 컴파일러는 빌드 시점에 추상 구문 트리(AST)를 분석하여 컴포넌트와 훅 내의 계산 비용이 높은 작업에 자동으로 메모이제이션 경계를 삽입합니다 [6, 21-23]. 이는 개발자의 수동 메모이제이션(useMemo, useCallback 등) 부담을 없애고, 입력값이 변경될 때만 세밀하게 재렌더링을 유도하여 폭포수 같은 연쇄 재렌더링 성능 저하를 방지합니다 [6, 8, 23, 24].

## 🔗 Knowledge Connections
- **Related Topics:** `[[Virtual DOM]]`, `[[Reconciliation]]`, `[[Fiber Architecture]]`, `[[Automatic Batching]]`, `[[React Compiler]]`, `[[Reflow & Repaint]]`
- **Projects/Contexts:** `[[프론트엔드 렌더링 최적화(Rendering [[Optimization]])]]`, `[[브라우저 렌더링 파이프라인([[Critical Rendering Path]])]]`
- **Contradictions/Notes:** 상태 트리를 비교할 때 발생하는 기존 알고리즘의 O(n³) 복잡도 한계를 O(n)으로 해결한 것이 속도의 주요 기반입니다 [11, 12]. 또한, Fiber 아키텍처에서 렌더링(Render) 단계는 중단하고 재개할 수 있는 순수 계산 과정이지만, 커밋(Commit) 단계는 DOM을 실제로 조작해야 하므로 동기식으로 차단되어 실행된다는 점이 아키텍처의 핵심적인 구분입니다 [25-27].

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