Antigravity Agent
56 lines
8.1 KiB
Markdown
56 lines
8.1 KiB
Markdown
---
|
|
category: Unified
|
|
tags: [auto-consolidated, technical-documentation]
|
|
title: [[React Compiler|React Compiler]]
|
|
last_updated: 2026-05-02
|
|
---
|
|
|
|
# [[React Compiler|React Compiler]]
|
|
|
|
## 📌 Brief Summary
|
|
React Compiler는 개발자가 수동으로 적용해야 했던 메모이제이션(memoization) 작업을 빌드 타임에 자동으로 처리해 주는 React의 새로운 최적화 도구이다 [1-3]. 기존의 `useMemo`, `useCallback`, `React.memo`와 같은 수동 메모이제이션의 번거로움과 오류 발생 가능성을 없애주며, 일반 [[JavaScript|JavaScript]]와 React의 규칙(Rules of React)을 이해하여 작동하므로 기존 코드를 재작성할 필요가 없다 [1, 4, 5]. 2025년 말에 안정화(stable) 버전으로 출시되었으며, 데이터 흐름을 분석하여 필요한 곳에만 지능적으로 메모이제이션을 삽입함으로써 애플리케이션의 렌더링 성능을 극대화한다 [3, 5, 6].
|
|
|
|
---
|
|
|
|
React 컴파일러(React Compiler, 이전 명칭 'React Forget')는 빌드 타임에 React 애플리케이션을 자동으로 최적화해주는 도구이다 [1-4]. 개발자가 수동으로 작성하던 `useMemo`, `useCallback`, `React.memo` 등의 메모이제이션 작업을 컴파일러가 코드를 분석하여 필요한 곳에 자동으로 삽입한다 [2, 3]. 이를 통해 불필요한 리렌더링을 방지하고 코드의 가독성을 높이며, 메모이제이션 누락이나 오용으로 인한 성능 저하를 효과적으로 해결한다 [4-6].
|
|
|
|
## 📖 Core Content
|
|
* **작동 방식 및 아키텍처:**
|
|
React Compiler는 빌드 단계에서 동작하는 정적 분석 도구로, Babel 또는 SWC 플러그인 형태로 작동한다 [7, 8]. 작동 과정은 크게 세 단계로 나뉜다. 첫째, 컴포넌트 코드를 추상 구문 트리(AST, Abstract Syntax Tree)로 파싱하고 데이터 흐름을 분석하는 '분석([[Analysis|Analysis]]) 단계', 둘째, 값이 정적인지, props나 상태에 의존하는 반응형(reactive)인지, 파생된 값인지 판별하는 '추론(Inference) 단계', 셋째, 최적의 지점에 메모이제이션 경계를 삽입하는 '변환(Transformation) 단계'이다 [9, 10].
|
|
* **세밀한 반응성(Fine-Grained Reactivity):**
|
|
컴파일러는 표현식 수준에서 메모이제이션을 수행하여, 특정 입력이 변경될 때만 컴포넌트가 리렌더링되도록 한다 [9, 11]. 이를 통해 연쇄적인 리렌더링(cascading re-renders)을 방지하고 불필요하고 비용이 많이 드는 계산을 건너뛰게 만들어 준다 [11, 12].
|
|
* **도입 효과 및 실제 사례:**
|
|
Meta의 내부 테스트 결과 초기 로드 시간 12% 단축, 사용자 상호작용 속도 2.5배 향상, 리렌더링 횟수 60% 감소 효과를 보였다 [13]. 콘텐츠 에디터인 [[Sanity Studio|Sanity Studio]]는 렌더링 시간을 20~30% 단축했으며, Wakelet은 LCP를 25%, INP를 47% 향상시켰다 [14, 15]. 이는 수동 메모이제이션에서 발생하는 인지적 과부하, 과도한 메모이제이션, 의존성 배열 오류 등의 문제를 해결하면서 얻은 괄목할 만한 성능 개선이다 [4].
|
|
* **설정 및 점진적 도입:**
|
|
[[React 19|React 19]] 이상, Node.js 18+ 환경에서 사용 가능하며 Vite, Next.js(15.3.1 이상), Expo 등 주요 빌드 도구 및 프레임워크와 호환된다 [7, 16]. 기존 코드베이스에서는 한 번에 모든 것을 바꾸기보다 특정 디렉터리부터 시작하거나 컴포넌트 파일 상단에 `'use compiler'` 지시어를 추가하여 점진적으로 도입하는 전략이 권장된다 [17, 18]. ESLint 플러그인(`eslint-plugin-[[React-Hooks|React-Hooks]]`)을 활용해 컴파일러에 적합하지 않은 코드를 사전에 점검할 수도 있다 [18, 19].
|
|
* **주의사항 및 예외 처리:**
|
|
React Compiler는 렌더링 중 발생하는 부수 효과(side effects)나 외부 변형(external mutation)을 지원하지 않으므로, React의 규칙을 철저히 준수해야 한다 [19-21]. 컴파일러가 최적화할 수 없는 패턴에 직면하면 컴파일을 포기(Bailout)하고 기존의 표준 React 동작으로 돌아간다 [21, 22].
|
|
|
|
---
|
|
|
|
- **작동 원리**: React 컴파일러는 Babel 또는 SWC 플러그인 형태로 동작하며 빌드 단계에서 코드를 변환한다 [7-9]. Abstract Syntax Tree(AST)를 분석하여 데이터 흐름을 추적하고, 각 값을 정적(Static), 반응형(Reactive), 파생(Derived)으로 분류한 뒤 최적의 위치에 메모이제이션 경계를 자동으로 삽입한다 [1, 10, 11]. 단순히 전체 컴포넌트를 캐싱하는 것을 넘어, 개별 JSX 요소와 내부 계산 작업까지 세밀하게(granular) 최적화하는 것이 특징이다 [12, 13].
|
|
- **주요 장점**: 수동 메모이제이션이 유발하는 개발자의 인지적 부담과 '의존성 배열 지옥(Dependency Array Hell)'을 제거하여 코드를 깔끔하게 유지할 수 있다 [2, 6, 13]. 실제 프로덕션 환경(Meta, [[Sanity Studio|Sanity Studio]], Wakelet 등)에서 적용한 결과 초기 로드 시간 단축, 상호작용 지연 시간(INP) 개선, 리렌더링 횟수 60% 감소 등의 괄목할 만한 성능 향상이 입증되었다 [14-16].
|
|
- **단점 및 한계**: 일부 서드파티 라이브러리(예: TanStack Query 등 렌더링마다 의도적으로 새로운 객체를 반환하는 훅)와 호환성 문제가 발생하여 컴파일러의 최적화가 무력화될 수 있다 [17]. 또한, 내부 동작이 블랙박스처럼 처리되어 예기치 않은 리렌더링 발생 시 원인 규명과 디버깅이 더 까다로워질 수 있으며, React의 기본 원칙(Rules of React)을 다수 위반한 레거시 코드베이스에서는 곧바로 도입하기 어렵다 [18-20].
|
|
- **도입 및 마이그레이션 전략**: 모든 코드에 일괄 적용할 필요 없이 특정 디렉터리부터 시작하거나 `'use compiler'` 지시어를 사용하여 파일 단위로 점진적인 도입이 가능하다 [21, 22]. 컴파일러 적용 전 [[ESLint|ESLint]] 플러그인을 사용하여 React 규칙 위반 사항을 식별하고 수정하는 것이 적극 권장된다 [18, 22].
|
|
- **수동 메모이제이션의 잔존 필요성**: 컴파일러가 대부분의 최적화를 자동으로 처리하지만, 이펙트(Effect)의 의존성 제어나 안정적인 참조가 필수적인 서드파티 라이브러리 연동 등 명시적인 제어가 필요한 상황(Escape Hatch)에서는 여전히 `useMemo` 및 `useCallback`을 사용해야 한다 [23-26].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
No trade-offs available.
|
|
|
|
## 🔗 Knowledge Connections
|
|
- **Related Topics:** Memoization, Abstract Syntax Tree (AST), Fine-Grained Reactivity, Rules of React, Re-render Cascade
|
|
- **Projects/Contexts:** [[React 19|React 19]], Babel, SWC, [[Next.js|Next.js]], Vite
|
|
- **Contradictions/Notes:** React Compiler가 모든 수동 메모이제이션을 완벽히 대체하는 것은 아니다. 90% 이상의 최적화 작업을 자동으로 수행하지만 [2], 이펙트 의존성(effect dependency)을 제어해야 하거나 참조 안정성(stable [[Reference|Reference]]s)을 요구하는 특정 서드파티 라이브러리(예: TanStack Query의 `useMutation()`)와 연동할 때는 여전히 개발자가 `useMemo`와 `useCallback`을 사용한 수동 제어를 병행해야 한다고 소스들은 명시하고 있다 [23-26].
|
|
|
|
---
|
|
*Last updated: 2026-04-25*
|
|
|
|
---
|
|
|
|
- **Related Topics:** 메모이제이션 (Memoization), 빌드 타임 최적화 (Build-Time [[Optimization|Optimization]]), 리렌더링 (Re-rendering)
|
|
- **Projects/Contexts:** Meta 프로덕션 앱 (Instagram, Quest Store), [[Sanity Studio|Sanity Studio]], [[Next.js|Next.js]] 및 Vite 통합
|
|
- **Contradictions/Notes:** 소스에 따르면 React 컴파일러가 적용된 컴포넌트는 React DevTools에서 `Memo ✨` 배지가 표시되지만, 이것이 항상 최적화의 성공을 의미하는 것은 아니다 [17, 27]. 속성에 인라인 객체나 함수 등 불안정한 참조가 전달될 경우, 배지가 있더라도 부모 컴포넌트 업데이트 시 여전히 리렌더링이 발생할 수 있으므로 주의해야 한다 [17].
|
|
|
|
---
|
|
*Last updated: 2026-04-25*
|