React Compiler 완벽 가이드: 자동 메모이제이션으로 성능 최적화 90%를 해결하는 방법

혹시 여러분도 useMemo, useCallback, React.memo의 미로 속에서 길을 잃어본 적 있으신가요? 앱이 버벅거리는 원인을 찾으려고 리렌더링을 쫓아다녔던 경험, 다들 한 번쯤은 있으실 거예요. 이 고통, 저만 겪은 게 아니었네요.

그 시대가 끝나가고 있습니다.

2025년 말에 정식 출시된 React Compiler는 우리가 React 성능 최적화를 생각하는 방식 자체를 완전히 바꿔놓았습니다. 이제 메모이제이션이 필요한 모든 함수와 값에 일일이 어노테이션을 달 필요가 없어요. 컴파일러가 빌드 타임에 코드를 분석해서 실제로 최적화가 필요한 곳에 자동으로 메모이제이션을 삽입해줍니다.

이 가이드에서는 React Compiler가 어떻게 동작하는지 깊이 파헤쳐보고, 자동 메모이제이션의 원리를 살펴보고, 기존 코드베이스 마이그레이션 전략, 그리고 실제 프로덕션 환경에서의 성능 벤치마크도 확인해볼 거예요. 이 글을 다 읽으시면 React Compiler를 어떻게 사용하는지뿐만 아니라, 왜 이것이 Hooks 이후 React 역사상 가장 중요한 변화인지 이해하실 수 있을 겁니다.

---

React Compiler가 해결하는 성능 문제

해결책을 살펴보기 전에, 먼저 이게 어떤 문제를 해결하는지 근본적으로 이해해볼까요?

리렌더링 세금

React의 선언적 모델은 정말 강력합니다. UI가 어떻게 생겨야 하는지 설명만 하면, React가 DOM을 어떻게 업데이트할지 알아서 파악하니까요. 하지만 이 강력함에는 대가가 따릅니다 — React는 상태가 변경될 때마다 컴포넌트를 리렌더링하고, 그 리렌더링이 컴포넌트 트리 아래로 연쇄적으로 퍼져나가거든요.

function ParentComponent() {
  const [count, setCount] = useState(0);
  
  // 이 객체는 매 렌더링마다 새로 생성됩니다
  const config = { theme: 'dark', locale: 'ko' };
  
  // 이 함수도 매 렌더링마다 새로 생성됩니다
  const handleClick = () => {
    console.log('clicked');
  };
  
  return (
    <div>
      <Counter count={count} setCount={setCount} />
      {/* ChildComponent는 config/handleClick이 "실제로" 변하지 않아도 리렌더링됩니다 */}
      <ChildComponent config={config} onClick={handleClick} />
    </div>
  );
}

이 예제에서 count가 변경될 때마다, ChildComponent는 새로운 객체와 함수 참조를 받게 됩니다 — 실제 값은 동일한데도 말이죠. React의 기본 동작은 참조 동등성 관점에서 props가 "변경"되었기 때문에 ChildComponent를 리렌더링하는 거예요.

전통적인 메모이제이션 춤

전통적인 해결책은 수동 메모이제이션이었습니다:

function ParentComponent() {
  const [count, setCount] = useState(0);
  
  // 객체를 메모이제이션
  const config = useMemo(() => ({ theme: 'dark', locale: 'ko' }), []);
  
  // 콜백을 메모이제이션
  const handleClick = useCallback(() => {
    console.log('clicked');
  }, []);
  
  return (
    <div>
      <Counter count={count} setCount={setCount} />
      {/* ChildComponent도 React.memo로 감싸야 합니다 */}
      <MemoizedChildComponent config={config} onClick={handleClick} />
    </div>
  );
}

const MemoizedChildComponent = React.memo(ChildComponent);

이 방법은 작동하긴 하지만, 여러 문제가 생깁니다:

1. 머리가 복잡해짐: 개발자는 계속해서 참조 동등성과 언제 메모이제이션해야 하는지 생각해야 해요
2. 과도한 메모이제이션: 확신이 없으면 모든 걸 감싸버리는 경향이 생겨서 불필요한 복잡성이 추가됩니다
3. 부족한 메모이제이션: 하나라도 메모이제이션을 놓치면 전체 최적화 체인이 무너집니다
4. 의존성 배열 지옥: 의존성 배열을 잘못 설정하면 오래된 클로저가 생기거나 불필요한 재계산이 발생합니다
5. 유지보수 부담: 코드가 발전함에 따라 메모이제이션 패턴도 함께 업데이트해야 합니다

Meta(구 Facebook)의 추정에 따르면, 그들의 코드베이스에서 **성능 이슈의 60-70%**가 누락되었거나 잘못된 메모이제이션과 관련이 있었다고 해요. React 팀은 React를 발명한 엔지니어들도 이런 문제를 겪는다면, 더 넓은 커뮤니티에게는 감당할 수 없는 부담이라는 걸 깨달았습니다.

---

React Compiler는 어떻게 동작할까요?

React Compiler는 마법이 아닙니다 — 빌드 프로세스 중에 실행되는 정교한 정적 분석 도구예요. 실제로 어떻게 동작하는지 분석해 볼까요?

아키텍처 개요

컴파일러는 빌드 단계에서 React 코드를 변환하는 Babel 플러그인(또는 더 빠른 빌드를 위한 SWC 플러그인)으로 작동합니다. 전체적인 흐름은 다음과 같아요:

소스 코드 → 파서 → AST → 컴파일러 분석 → 최적화된 코드 → 번들

컴파일러는 세 가지 주요 단계를 수행합니다:

1. 분석 단계: 컴포넌트 코드를 Abstract Syntax Tree(AST)로 파싱하고 데이터 흐름을 분석합니다
2. 추론 단계: 어떤 값이 반응형(props/state에 의존)이고 어떤 값이 정적인지 결정합니다
3. 변환 단계: 최적의 지점에 메모이제이션 경계를 삽입합니다

리액티비티 모델

컴파일러의 핵심은 리액티비티 모델이에요. 컴포넌트의 모든 표현식을 다음 중 하나로 분류합니다:

• 정적(Static): 렌더링 사이에 절대 변하지 않는 값 (상수, imports 등)
• 반응형(Reactive): props, state, 또는 context에 의존하는 값
• 파생(Derived): 다른 반응형 값으로부터 계산된 값

function ProductCard({ product, discount }) {
  // 정적: 이 값들은 절대 변하지 않습니다
  const formatter = new Intl.NumberFormat('ko-KR');
  const MAX_TITLE_LENGTH = 50;
  
  // 반응형: 직접적인 prop 의존성
  const price = product.price;
  const name = product.name;
  
  // 파생: 반응형 값들로부터 계산됨
  const finalPrice = price * (1 - discount);
  const displayTitle = name.slice(0, MAX_TITLE_LENGTH);
  
  return (
    <div className="product-card">
      <h3>{displayTitle}</h3>
      <span>{formatter.format(finalPrice)}</span>
    </div>
  );
}

컴파일러는 자동으로 다음을 파악합니다:

• formatter와 MAX_TITLE_LENGTH는 컴포넌트 외부로 호이스팅될 수 있음
• finalPrice는 price나 discount가 변경될 때만 재계산이 필요함
• displayTitle은 name이 변경될 때만 재계산이 필요함

메모이제이션 삽입

분석 결과를 바탕으로, 컴파일러는 전략적인 지점에 메모이제이션을 삽입합니다. 컴파일된 출력이 어떤 모습일지 간략하게 살펴보면:

// 컴파일러 출력 (개념적, 실제 문법 아님)
function ProductCard({ product, discount }) {
  // 컴파일러가 컴포넌트 외부로 호이스팅
  const formatter = $static(() => new Intl.NumberFormat('ko-KR'));
  const MAX_TITLE_LENGTH = $static(() => 50);
  
  // 반응형 의존성으로 메모이제이션
  const finalPrice = $memo(() => product.price * (1 - discount), [product.price, discount]);
  const displayTitle = $memo(() => product.name.slice(0, MAX_TITLE_LENGTH), [product.name]);
  
  // JSX 요소도 가능하면 메모이제이션
  return $memo(() => (
    <div className="product-card">
      <h3>{displayTitle}</h3>
      <span>{formatter.format(finalPrice)}</span>
    </div>
  ), [displayTitle, finalPrice]);
}

핵심 인사이트는 컴파일러가 그냥 맹목적으로 모든 것을 메모이제이션하는 게 아니라는 거예요 — 어디에서 메모이제이션이 실제 이점을 제공하는지에 대해 지능적인 결정을 내립니다.

Fine-Grained Reactivity (세밀한 리액티비티)

React Compiler의 가장 강력한 기능 중 하나는 Fine-Grained Reactivity예요. 예제를 한번 볼까요:

function UserDashboard({ user }) {
  const { name, email, preferences, stats } = user;
  
  return (
    <div>
      <Header name={name} />
      <EmailSettings email={email} preferences={preferences} />
      <StatsPanel stats={stats} />
    </div>
  );
}

컴파일러는 다음을 이해합니다:

• Header는 name에만 의존
• EmailSettings는 email과 preferences에 의존
• StatsPanel은 stats에만 의존

만약 stats만 변경되면, 컴파일된 코드는 Header와 EmailSettings의 리렌더링을 완전히 건너뜁니다 — 수동 React.memo 래퍼 없이도요.

---

React Compiler 설정하기

이제 동작 원리를 이해했으니, 실제 프로젝트에 설정해볼까요?

사전 요구사항

React Compiler는 다음을 필요로 합니다:

• React 19 이상
• Node.js 18+
• Babel이나 SWC 플러그인을 지원하는 빌드 도구 (Vite, Next.js, Webpack 등)

Vite 프로젝트에 설치하기

Vite 프로젝트의 경우, 설치가 간단합니다:

npm install -D babel-plugin-react-compiler @babel/core @babel/preset-react

vite.config.ts를 생성하거나 업데이트하세요:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [
    react({
      babel: {
        plugins: [
          ['babel-plugin-react-compiler', {
            // 컴파일러 옵션
            runtimeModule: 'react/compiler-runtime',
          }],
        ],
      },
    }),
  ],
});

Next.js 프로젝트에 설치하기

Next.js 16+ 버전부터는 React Compiler를 퍼스트 파티로 지원합니다. next.config.js에 다음을 추가하세요:

/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    reactCompiler: true,
  },
};

module.exports = nextConfig;

Next.js 15.3.1 이상에서는 디렉티브를 사용해서 파일별로도 활성화할 수 있어요:

'use compiler';

export default function OptimizedComponent() {
  // 이 컴포넌트는 컴파일됩니다
}

Expo 프로젝트에 설치하기

Expo SDK 54 이상 버전에서는 React Compiler가 기본으로 활성화되어 있습니다. 이전 SDK를 사용하신다면, babel.config.js를 업데이트하세요:

module.exports = function (api) {
  api.cache(true);
  return {
    presets: ['babel-preset-expo'],
    plugins: [
      ['babel-plugin-react-compiler', {
        runtimeModule: 'react/compiler-runtime',
      }],
    ],
  };
};

설치 확인하기

컴파일러가 제대로 동작하는지 확인하려면, 아무 컴포넌트에나 이걸 추가해보세요:

function TestComponent() {
  // 컴파일러는 컴파일된 컴포넌트에 특별한 프로퍼티를 추가합니다
  console.log(TestComponent.$$typeof); // 컴파일러 마커가 표시되어야 합니다
  
  return <div>테스트</div>;
}

React DevTools Profiler도 사용할 수 있어요 — 컴파일된 컴포넌트는 리렌더 카운트가 눈에 띄게 줄어든 것을 확인할 수 있습니다.

---

기존 코드베이스 마이그레이션 전략

React Compiler 도입이 반드시 전부 아니면 전무(all-or-nothing) 방식일 필요는 없어요. 점진적 마이그레이션을 위한 검증된 전략들을 소개합니다.

전략 1: 디렉토리별 점진적 도입

가장 혜택이 큰 특정 디렉토리부터 시작하세요:

// babel-plugin-react-compiler 설정
{
  sources: (filename) => {
    // dashboard 디렉토리의 컴포넌트만 컴파일
    return filename.includes('src/components/dashboard');
  },
}

이 접근법의 장점:

1. 코드 일부분에서 컴파일러를 검증할 수 있음
2. 조정이 필요한 패턴을 식별할 수 있음
3. 독립적으로 성능 향상을 측정할 수 있음

전략 2: 파일별 옵트인

수술적인 정밀도로 도입하려면 'use compiler' 디렉티브를 사용하세요:

'use compiler';

// 이 파일은 컴파일됩니다
export function HighPerformanceList({ items }) {
  return items.map(item => <ListItem key={item.id} item={item} />);
}

반대로, 특정 파일은 옵트아웃할 수도 있어요:

'use no compiler';

// 이 파일은 컴파일되지 않습니다 (리팩토링이 필요한 레거시 코드)
export function LegacyComponent() {
  // 컴파일러를 혼란스럽게 하는 복잡한 뮤테이션 패턴
}

전략 3: ESLint 우선 준비

컴파일러를 활성화하기 전에, 업데이트된 ESLint 규칙으로 코드베이스를 준비하세요:

npm install -D eslint-plugin-react-hooks@latest

.eslintrc를 업데이트하세요:

{
  "plugins": ["react-hooks"],
  "rules": {
    "react-hooks/rules-of-hooks": "error",
    "react-hooks/exhaustive-deps": "error",
    "react-compiler/react-compiler": "error"
  }
}

react-compiler/react-compiler 규칙은 컴파일에 안전하지 않은 패턴을 플래그합니다:

// ❌ ESLint가 이걸 플래그함: 렌더 중 뮤테이션
function BadComponent({ items }) {
  const sorted = items.sort(); // 원본 배열을 뮤테이션!
  return sorted.map(item => <Item key={item.id} item={item} />);
}

// ✅ 수정됨: 새로운 정렬된 배열 생성
function GoodComponent({ items }) {
  const sorted = [...items].sort();
  return sorted.map(item => <Item key={item.id} item={item} />);
}

수동 메모이제이션 정리하기

컴파일러가 활성화되고 안정화되면, 수동 메모이제이션을 안전하게 제거할 수 있어요:

// Before: 수동 최적화
function BeforeComponent({ data, onSelect }) {
  const processedData = useMemo(() => 
    data.map(item => ({ ...item, processed: true })),
    [data]
  );
  
  const handleSelect = useCallback((id) => {
    onSelect(id);
  }, [onSelect]);
  
  return (
    <MemoizedList 
      items={processedData} 
      onItemSelect={handleSelect} 
    />
  );
}

const MemoizedList = React.memo(List);

// After: 컴파일러에게 맡기기
function AfterComponent({ data, onSelect }) {
  const processedData = data.map(item => ({ ...item, processed: true }));
  
  const handleSelect = (id) => {
    onSelect(id);
  };
  
  return (
    <List 
      items={processedData} 
      onItemSelect={handleSelect} 
    />
  );
}

"After" 버전이 더 깔끔하고, 읽기 쉬우며, 컴파일러가 메모이제이션을 자동으로 처리하기 때문에 성능도 동일합니다.

---

실제 성능 벤치마크

프로덕션 애플리케이션에서의 실제 성능 데이터를 살펴볼까요?

Meta의 내부 테스트

Meta는 공개 출시 전에 전체 애플리케이션 생태계에서 React Compiler를 실전 테스트했습니다. 주요 발견사항:

지표	개선
초기 로드 시간	12% 빨라짐
사용자 인터랙션 속도	2.5배 빨라짐
리렌더 횟수	60% 감소
번들 크기	중립 (런타임으로 인한 약간의 증가)

Meta Quest Store에서 가장 극적인 개선이 있었고, 복잡한 제품 페이지가 눈에 띄게 빨라지고 인터랙션이 즉각적으로 느껴졌다고 해요.

Sanity Studio 사례 연구

실시간 협업 콘텐츠 에디터인 Sanity Studio의 보고:

• 렌더 시간 20-30% 감소
• 복잡한 폼 에디터에서 상당한 지연시간 개선
• 엔지니어링 팀의 즉각적인 생산성 향상 (성능 디버깅 시간 감소)

그들의 엔지니어링 팀은 이전에 세심한 수동 메모이제이션이 필요했던 깊이 중첩된 업데이트 패턴을 가진 컴포넌트가 컴파일러를 사용하면 "그냥 동작한다"고 말했습니다.

Wakelet Core Web Vitals

콘텐츠 큐레이션 플랫폼 Wakelet은 컴파일러 도입 전후로 Core Web Vitals를 추적했습니다:

지표	이전	이후	개선
LCP (Largest Contentful Paint)	2.4초	1.8초	25% 빨라짐
INP (Interaction to Next Paint)	180ms	95ms	47% 빨라짐
CLS (Cumulative Layout Shift)	0.05	0.03	40% 개선

INP 개선이 특히 주목할 만합니다 — 이 지표는 사용자 인터랙션에 대한 반응성을 직접 측정하는데, 정확히 자동 메모이제이션이 최적화하는 부분이거든요.

직접 벤치마킹하기

React DevTools Profiler를 사용해서 여러분의 애플리케이션에 컴파일러가 미치는 영향을 벤치마킹할 수 있어요:

// React DevTools Profiler API를 사용한 자동화된 벤치마킹
import { Profiler } from 'react';

function onRenderCallback(
  id, phase, actualDuration, baseDuration, startTime, commitTime
) {
  console.log({
    component: id,
    phase,
    actualDuration: `${actualDuration.toFixed(2)}ms`,
    baseDuration: `${baseDuration.toFixed(2)}ms`,
  });
}

function App() {
  return (
    <Profiler id="App" onRender={onRenderCallback}>
      <YourApplication />
    </Profiler>
  );
}

컴파일러 활성화 전후로 actualDuration을 비교해보세요 — 복잡한 prop 의존성이 있는 컴포넌트에서 즉각적인 개선을 볼 수 있을 거예요.

---

고급 컴파일러 패턴

React Compiler는 대부분의 일반적인 패턴을 자동으로 처리하지만, 고급 패턴을 이해하면 처음부터 컴파일러 친화적인 코드를 작성하는 데 도움이 됩니다.

패턴 1: 정적 계산 추출하기

컴파일러는 정적 값을 자동으로 호이스팅하지만, 코드를 명확하게 구조화하면 도움이 될 수 있어요:

// ❌ 정적 로직과 반응형 로직이 섞임
function ProductPage({ product }) {
  const formatPrice = (price) => {
    const formatter = new Intl.NumberFormat('ko-KR', { 
      style: 'currency', 
      currency: 'KRW' 
    });
    return formatter.format(price);
  };
  
  return <span>{formatPrice(product.price)}</span>;
}

// ✅ 정적 포매터 추출 - 컴파일러가 호이스팅 가능
const priceFormatter = new Intl.NumberFormat('ko-KR', { 
  style: 'currency', 
  currency: 'KRW' 
});

function ProductPage({ product }) {
  return <span>{priceFormatter.format(product.price)}</span>;
}

패턴 2: 렌더에서 사이드 이펙트 피하기

컴파일러는 렌더가 순수하다고 가정합니다. 렌더 중 사이드 이펙트는 이 가정을 깨뜨려요:

// ❌ 렌더 중 사이드 이펙트 - 컴파일러를 혼란스럽게 함
function AnalyticsWrapper({ children, pageId }) {
  trackPageView(pageId); // 사이드 이펙트!
  
  return <div>{children}</div>;
}

// ✅ useEffect에서 사이드 이펙트
function AnalyticsWrapper({ children, pageId }) {
  useEffect(() => {
    trackPageView(pageId);
  }, [pageId]);
  
  return <div>{children}</div>;
}

패턴 3: 조건부 렌더링 최적화

컴파일러는 조건부 렌더링 패턴을 이해합니다:

function ConditionalComponent({ showDetails, user }) {
  // 컴파일러가 이 조건을 이해함
  if (!showDetails) {
    return <Summary name={user.name} />;
  }
  
  // 이 비싼 계산은 showDetails가 true일 때만 실행됨
  const detailedStats = computeDetailedStats(user);
  
  return <DetailedProfile user={user} stats={detailedStats} />;
}

컴파일러는 각 분기에 대해 별도의 메모이제이션 경계를 생성하여, showDetails가 false일 때 computeDetailedStats가 완전히 스킵되도록 합니다.

패턴 4: 배열 연산

배열 뮤테이션에 주의하세요 — 컴파일러는 데이터 흐름을 추적합니다:

// ❌ 뮤테이션 패턴 - 컴파일러 가정을 깨뜨림
function SortedList({ items }) {
  const sorted = items;
  sorted.sort((a, b) => a.name.localeCompare(b.name)); // 뮤테이션!
  return sorted.map(item => <Item key={item.id} {...item} />);
}

// ✅ 불변 패턴 - 컴파일러 친화적
function SortedList({ items }) {
  const sorted = [...items].sort((a, b) => a.name.localeCompare(b.name));
  return sorted.map(item => <Item key={item.id} {...item} />);
}

// ✅ 더 좋음: toSorted (ES2023+)
function SortedList({ items }) {
  const sorted = items.toSorted((a, b) => a.name.localeCompare(b.name));
  return sorted.map(item => <Item key={item.id} {...item} />);
}

패턴 5: Ref 올바르게 다루기

Ref는 변경 가능하기 때문에 특별한 주의가 필요합니다:

function InputWithFocus({ onSubmit }) {
  const inputRef = useRef(null);
  
  const handleSubmit = () => {
    // ref.current 접근은 괜찮음 - 컴파일러가 ref 패턴을 이해함
    const value = inputRef.current?.value;
    onSubmit(value);
  };
  
  return (
    <form onSubmit={handleSubmit}>
      <input ref={inputRef} />
      <button type="submit">제출</button>
    </form>
  );
}

컴파일러는 inputRef.current가 렌더 중에 변경되는 게 아니라 접근만 된다는 것을 올바르게 식별합니다.

---

언제 여전히 수동 메모이제이션을 사용할까요?

컴파일러가 대부분의 케이스를 처리하지만, 수동 최적화가 여전히 적절한 시나리오가 있습니다:

탈출구: 명시적 의존성

이펙트 의존성에 대한 명시적 제어가 필요할 때:

function DataFetcher({ userId, options }) {
  // 이펙트 의존성을 위해 여전히 useCallback을 원할 수 있음
  const fetchData = useCallback(async () => {
    const response = await fetch(`/api/users/${userId}`);
    return response.json();
  }, [userId]); // 명시적으로 options 무시
  
  useEffect(() => {
    fetchData();
  }, [fetchData]);
}

탈출구: 서드파티 라이브러리 통합

일부 라이브러리는 안정적인 참조를 요구합니다:

function ChartComponent({ data }) {
  // D3.js는 안정적인 스케일 함수를 요구함
  const xScale = useMemo(() => 
    d3.scaleLinear().domain([0, d3.max(data)]).range([0, 500]),
    [data]
  );
  
  // 라이브러리가 안정적인 콜백을 기대함
  const handleZoom = useCallback((event) => {
    xScale.domain(event.transform.rescaleX(xScale).domain());
  }, [xScale]);
}

탈출구: 크리티컬 성능 경로

밀리초 단위가 중요한 코드 경로:

function VirtualizedList({ items, height }) {
  // 가상화를 위해, 안정적인 키 추출자가 중요함
  const keyExtractor = useCallback((item) => item.id, []);
  
  // 스크롤 시 실행되는 비싼 계산을 메모이제이션
  const visibleRange = useMemo(() => 
    calculateVisibleRange(items, height, scrollOffset),
    [items, height, scrollOffset]
  );
}

---

일반적인 함정과 디버깅

컴파일러를 사용해도 문제가 발생할 수 있어요. 디버깅하는 방법을 알아봅시다.

함정 1: 컴파일러 베일아웃

컴파일러는 특정 패턴에서 표준 React 동작으로 폴백하며 베일아웃될 수 있습니다:

// ❌ 동적 프로퍼티 접근 - 컴파일러가 베일아웃할 수 있음
function DynamicComponent({ data, fieldName }) {
  return <span>{data[fieldName]}</span>;
}

// ✅ 명시적 프로퍼티 - 컴파일러가 분석 가능
function ExplicitComponent({ data }) {
  return <span>{data.name}</span>;
}

빌드 경고에서 컴파일러 베일아웃 메시지를 확인하세요:

Warning: React Compiler skipped optimizing DynamicComponent: 
  Dynamic property access cannot be statically analyzed

함정 2: 외부 뮤테이션

props에 대한 외부 뮤테이션은 컴파일러 가정을 깨뜨립니다:

// ❌ 부모 컴포넌트가 배열을 직접 뮤테이션
function Parent() {
  const items = [1, 2, 3];
  
  const addItem = () => {
    items.push(4); // 뮤테이션!
    setTrigger(x => !x);
  };
  
  return <Child items={items} />;
}

// ✅ 적절한 상태 관리
function Parent() {
  const [items, setItems] = useState([1, 2, 3]);
  
  const addItem = () => {
    setItems(prev => [...prev, 4]);
  };
  
  return <Child items={items} />;
}

함정 3: 컴파일된 출력 디버깅

컴파일러가 생성하는 내용을 보려면, 디버그 옵션을 사용하세요:

// vite.config.ts
{
  plugins: [
    ['babel-plugin-react-compiler', {
      debug: true, // 컴파일 분석 결과 출력
    }],
  ],
}

이것은 각 컴포넌트에 대한 상세한 분석을 로깅합니다:

[ReactCompiler] Analyzing: ProductCard
  - Variables: 5 total (2 static, 2 reactive, 1 derived)
  - Memoization points: 3
  - JSX fragments: 2 (1 optimized)
  Estimated re-render reduction: 78%

---

React 성능의 미래

React Compiler는 패러다임 전환을 대표하지만, 이건 시작에 불과합니다.

시그널 기반 반응성

컴파일러의 세분화된 반응성 모델은 시그널 기반 프리미티브로 가는 첫 단계입니다. 미래 React 버전에서는 네이티브 시그널이 도입될 수 있어요:

// 잠재적 미래 API (추측)
function Counter() {
  const count = useSignal(0);
  
  return (
    <button onClick={() => count.value++}>
      Count: {count.value}
    </button>
  );
}

Server Components 통합

컴파일러는 React Server Components와 원활하게 작동하도록 설계되었습니다. 서버 컴포넌트는 컴파일러를 완전히 건너뛰고 (클라이언트 사이드 반응성이 필요 없음), 클라이언트 컴포넌트는 전체 최적화를 받습니다.

생태계 적응

컴파일러가 성숙해짐에 따라 기대되는 것들:

• UI 라이브러리들이 수동 메모이제이션 요구사항을 제거
• 테스팅 도구들이 컴파일된 컴포넌트를 더 잘 이해
• DevTools가 컴파일러별 프로파일링 제공

---

결론

React Compiler는 단순한 성능 도구가 아니에요 — React가 최적화를 다루는 방식 자체가 바뀌는 거예요. 이제 개발자가 메모이제이션을 직접 관리할 필요 없이, React가 알아서 최적의 성능을 보장해줍니다.

핵심 포인트:

1. 컴파일러는 빌드 타임에 동작하며, 코드를 분석하고 실제 이점을 제공하는 곳에 메모이제이션을 삽입합니다
2. 마이그레이션은 점진적일 수 있습니다 — 높은 영향을 주는 디렉토리나 개별 파일부터 시작하세요
3. 컴파일러 친화적인 코드를 작성하세요 — 렌더 타임 사이드 이펙트와 뮤테이션을 피하세요
4. 수동 메모이제이션도 여전히 자리가 있습니다 — 특정 시나리오를 위한 탈출구로
5. 성능 향상은 실제입니다 — 코드 변경 없이 리렌더가 20-60% 줄어들 것을 기대하세요

useMemo와 useCallback 불안의 시대가 끝나가고 있습니다. React Compiler와 함께라면, 정말 중요한 것 — 훌륭한 사용자 경험 만들기 — 에 집중할 수 있어요.

오늘 컴파일러를 실험해보세요. 미래의 여러분이 — 그리고 사용자들이 — 감사할 거예요.