2nd/10_Wiki/Topics/Frontend_Mastery/메인 스레드 차단 문제 해결을 위한 React 16의 Fiber 엔진 교체 및 React 18, 19의 동시성 렌더링 적용 사례.md

# [[메인 스레드 차단 문제 해결을 위한 React 16의 Fiber 엔진 교체 및 React 18, 19의 동시성 렌더링 적용 사례|메인 스레드 차단 문제 해결을 위한 React 16의 Fiber 엔진 교체 및 React 18, 19의 동시성 렌더링 적용 사례]]

## 📌 Brief Summary
React 16 이전의 동기적 렌더링 방식은 렌더링 작업이 길어질 경우 메인 스레드를 차단하여 UI 응답성을 떨어뜨리는 한계가 있었습니다. 이를 해결하기 위해 React 16은 렌더링 작업을 잘게 쪼개고 우선순위에 따라 작업을 중단, 재개할 수 있는 Fiber 아키텍처를 도입했습니다. 이를 기반으로 React 18에서는 자동 일괄 처리([[Automatic Batching|Automatic Batching]])와 `useTransition` 등을 활용한 동시성 렌더링 기능을 제공하였고, React 19에 이르러서는 [[React Compiler|React Compiler]]를 통한 자동 메모이제이션과 서버 컴포넌트(RSC)를 도입해 메인 스레드의 부하를 극적으로 줄이며 최적화를 자동화했습니다.

## 📖 Core Content
**메인 스레드 차단 문제와 한계**
React 16 이전의 React는 컴포넌트 트리를 단일 재귀 호출로 동기적으로 처리하는 '스택 재조정자(Stack Reconciler)'를 사용했습니다 [1]. 대규모 애플리케이션의 경우, 이 과정이 16.6ms의 프레임 예산을 초과하면 메인 스레드를 차단하여 사용자 입력 및 애니메이션에 대한 애플리케이션의 응답성이 지연되는 문제가 발생했습니다 [1].

**React 16의 Fiber 엔진 도입**
*   **작업 분할 및 타임 슬라이싱 ([[Time-Slicing|Time-Slicing]]):** 동기적 차단 문제를 해결하기 위해 React 16은 동시성 렌더링을 지원하도록 재조정([[Reconciliation|Reconciliation]]) 엔진을 완전히 재작성한 'Fiber' 아키텍처를 도입했습니다 [2]. Fiber는 렌더링 작업을 'Fiber 노드'라는 작은 작업 단위(Unit of work)로 분할합니다 [1, 3]. 
*   **중단 및 재개 가능한 렌더링:** 작업 루프(Work loop) 내에서 React는 각 작업을 처리한 후 우선순위가 높은 작업(예: 사용자 입력)을 위해 브라우저에 제어권을 양보(Yield)할 수 있습니다 [4]. 렌더링 단계(Render phase)는 중단 및 재개가 가능하며, 실제 DOM에 변경 사항을 적용하는 커밋 단계(Commit phase)는 동기적으로 실행됩니다 [5, 6].
*   **우선순위 레인(Lanes):** 타이핑 및 클릭과 같은 긴급한 상호작용은 '동기(Sync) 레인'에 할당하고, 데이터 페칭은 '기본(Default) 레인'에 할당하는 방식으로 우선순위 기반 시스템을 운용하여 UI의 반응성을 향상시켰습니다 [7-9].

**React 18의 동시성 렌더링 적용 사례**
*   **긴급하지 않은 렌더링 지연:** React 18은 `useTransition` 및 `[[useDeferredValue|useDeferredValue]]` 훅을 통해 동시성 렌더링을 본격적으로 활용합니다 [10]. 긴급한 상호작용(예: 검색어 입력)을 먼저 처리하고, 무거운 연산(예: 수천 개의 목록 필터링)을 `[[startTransition|startTransition]]`으로 감싸 지연시킴으로써 메인 스레드의 차단을 방지합니다 [10-12].
*   **자동 일괄 처리 (Automatic [[Batching|Batching]]):** 이벤트 핸들러 내부뿐만 아니라 Promise, setTimeout, 기본 이벤트 등 비동기 작업에서 발생하는 여러 상태 업데이트를 단일 리렌더링으로 묶어 처리합니다 [13-15]. 이는 [[Virtual DOM|Virtual DOM]]의 Diffing 오버헤드를 줄여 데이터 집약적인 대시보드 환경에서 프레임 속도를 최대 25% 향상시키는 성과를 보였습니다 [12, 13, 16].

**React 19의 성능 자동화 및 메인 스레드 부하 감소 사례**
*   **React Compiler를 통한 자동 메모이제이션:** React 19는 수동으로 작성하던 `useMemo`나 `useCallback`의 인지적 부담을 덜기 위해, 빌드 시점에 AST(추상 구문 트리)를 분석하여 최적의 메모이제이션 경계를 자동으로 삽입하는 React Compiler를 도입했습니다 [17-19]. 이는 미세 조정된 반응성(Fine-Grained Reactivity)을 구현하여 불필요한 연쇄 리렌더링(Re-render cascade)을 획기적으로 방지합니다 [17, 20]. Meta의 내부 테스트에서는 상호작용 속도(INP)가 최대 2.5배 빨라졌습니다 [21].
*   **[[React Server Components (RSC)|React Server Components (RSC]]:** 번들 크기와 하이드레이션(Hydration) 비용을 근본적으로 제거하기 위해, 상호작용이 없는 컴포넌트를 서버에서만 실행하는 방식을 도입했습니다 [22-24]. 이 방식을 통해 브라우저로 전송되는 [[JavaScript|JavaScript]]를 0바이트로 줄여 메인 스레드가 파싱하고 실행해야 할 부담을 최소화했습니다 [22, 24, 25].

## 🔗 Knowledge Connections
- **Related Topics:** [[Virtual DOM|Virtual DOM]], Reconciliation, Fiber Architecture, [[Automatic Batching|Automatic Batching]], React Compiler, [[React Server Components|React Server Components]], [[Time-Slicing|Time-Slicing]], Lane-Based Priority
- **Projects/Contexts:** [[Next.js App Router|Next.js App Router]], Meta's Internal Testing (Quest Store), [[Sanity Studio|Sanity Studio]]
- **Contradictions/Notes:** 컴포넌트의 렌더링 최적화와 관련해 React Compiler의 도입은 개발자가 `useMemo`나 `useCallback`을 사용하여 수동으로 최적화하던 기존 방식의 패러다임을 바꿉니다 [26]. 대부분의 자동 메모이제이션은 컴파일러가 처리하지만, `useEffect`의 의존성 관리나 타사 라이브러리 연동 등 세밀한 제어가 필요한 경우에는 여전히 수동 메모이제이션 방식이 "탈출구(Escape Hatch)"로 유효하다고 소스에서 지적하고 있습니다 [27-29].

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