YKSS
리액트 컴파일러 v1.0
React Compiler v1.0 은 *수동 메모이제이션*(useMemo / useCallback / React.memo) 을 자동화한다. Babel 플러그인이지만 본질은 React 코드를 HIR 로 분석하는 최적화 컴파일러.
핵심 요약
v1.0 의 핵심은 다섯 가지.
- 자동 메모이제이션: HIR 분석으로 조건부 return 이후 같은 useMemo 가 못 가던 영역도 메모이제이션 — 사람이 짠 것보다 정밀할 수 있음
- 린트 통합:
eslint-plugin-react-hooks@latest의 recommended 프리셋에 컴파일러 기반 규칙 포함 - 점진 도입: 게이팅/호환성 검사 가이드 — 큰 앱도 안전하게 일부터 켤 수 있음
- 신규 앱 기본 활성화: Expo SDK 54+, Vite/Next.js 의 create 템플릿에서 활성 옵션
- 하위 호환: React 17/18 도
react-compiler-runtime으로 지원
Meta Quest Store 측정값: 초기 로드/페이지 전환 최대 12% 빨라짐, 일부 상호작용 2.5x, 메모리는 동일.
npm install --save-dev --save-exact babel-plugin-react-compiler@latest
npm install --save-dev eslint-plugin-react-hooks@latest
컴파일러를 "메모이제이션을 손으로 안 짠다" 가 아니라 "규칙을 어기지 않은 코드가 자동으로 최적이 된다" 로 본다. 핵심은 React 의 규칙(Rules of React) 을 컴파일러가 검증·전제하는 점이다. 따라서 진짜 변화는 최적화 자동화 가 아니라 "규칙 준수가 곧 성능" 이라는 새 계약이다.
면접에서 "메모이제이션 헬퍼 차이" 는 단골이지만, 컴파일러 시대에는 질문이 한 단계 위로 올라간다.
- 컴파일러가 있는데 useMemo 가 왜 남아 있나?
- 어떤 코드가 컴파일러로 자동 최적화 안 되나?
- Rules of React 위반이 어떻게 성능에 영향을 주는가?
이걸 답할 수 있으려면 컴파일러가 어떤 가정 위에 동작하는지(순수성, 불변성) 와 어떤 코드가 위반인지 를 같이 이해해야 한다. v1.0 은 그 질문이 일반적인 면접에 들어오는 분기점이다.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
컴파일러는 *Rules of React* 를 신뢰한다
자동 메모이제이션이 가능한 이유는 React 의 규칙 — 순수 컴포넌트, 동일 입력 → 동일 출력, hooks 호출 순서 고정 — 을 전제로 깔기 때문이다.
규칙을 어긴 코드는:
- 외부 변수를 직접 변이 (mutation)
- 렌더 도중 부수효과 실행
- 조건부 hook 호출
이런 코드는 컴파일러가 분석 결과를 뒤집을 수 있어 결과가 예측 불가가 된다. 따라서 v1.0 은 동시에 린트 강화 를 한다 — 위반을 빨리 잡아야 컴파일러의 가정이 깨지지 않는다.
"컴파일러가 다 알아서 한다" 라는 인식. 실제로는 규칙 준수가 사전 조건 이라 위반 코드에 대해선 컴파일러가 손을 떼는 편이 안전한 코드 패스를 택한다.
useMemo / useCallback / React.memo 가 *완전히는* 사라지지 않는다
남는 자리:
- 이펙트 의존성 안정화: 메모이제이션된 값이
useEffect의 의존성으로 쓰일 때, 의미 있는 변경이 아니면 이펙트 재실행을 막아야 함 — 이건 컴파일러의 렌더 최적화 와 별개 - 외부 라이브러리 인터페이스: 콜백을 props 로 넘길 때 참조 동등성 을 요구하는 외부 컴포넌트
- 세밀 제어: 특정 비싼 계산을 명시적으로 메모이제이션하고 싶을 때
새 코드: 컴파일러 디폴트 + 필요할 때만 명시. 기존 코드: 그대로 두고 충분한 테스트 후 정리. 메모이제이션 헬퍼가 나쁜 코드 가 된 건 아니다.
도입 직후 모든 useMemo/useCallback 을 제거 하는 것. 이펙트 의존성 안정화는 컴파일러가 책임지지 않는 영역 이다.
swc/oxc 와의 미래 — Babel 의 종착점이 아니다
v1.0 은 Babel 플러그인이지만, 본질은 Babel 과 분리된 HIR 기반 컴파일러 다. swc 팀과 협업해 swc 플러그인 개발 중이고, oxc 도 지원 추가 작업.
실무 의미:
- Next.js 15.3.1+ 에서 swc 통합으로 빌드 성능 향상
- Vite 사용자: 당장은 vite-plugin-react + babel 플러그인, rolldown-vite 출시 후 마이그레이션 안내 예정
즉 컴파일러는 빌드 도구 변화의 통과 지점 이다 — 어떤 빌드 도구를 쓰든 자동 메모이제이션은 살아남는 형태로 진화한다.
"Babel 이 느려서 못 쓰겠다" 며 도입을 미루는 것. swc 지원 이 가까이 와 있어 단기 비용을 감수할 가치가 있다.
읽는 순서
- 1이론
React 공식 문서의 Rules of React 와 컴파일러 README 를 함께 읽고, 위반 패턴 5가지를 컴파일러가 어떻게 fallback 하는가 와 짝지어 표로 만드세요.
- 2구현
작은 페이지 하나에 컴파일러를 켜고, React DevTools Profiler 로 리렌더 횟수 를 전/후 비교.
useMemo를 일부 제거해 회귀가 없는지 확인합니다. - 3실무
eslint-plugin-react-hooks@latestrecommended 프리셋으로 업그레이드, flat config 적용. lint 경고 카운트와 컴파일러 fallback 비율(빌드 로그)을 KPI 로 둡니다. - 4설명
팀에 10분 발표 — '컴파일러는 왜 항상 더 빠른 게 아닌가'. Rules of React 전제 / 이펙트 의존성 / 측정 세 축으로 한계와 효용을 같이 설명합니다.
면접 연결 질문
[감점 답변] 'React 코드라서'. [좋은 답변] (1) 컴포넌트 순수성 — 같은 입력에 같은 출력. (2) hook 호출 규칙 — 호출 순서/조건이 일정. 이 두 가정이 깨지면 컴파일러는 분석을 보수적으로 멈추거나 최적화 안 된 fallback 코드를 낸다. 그래서 v1.0 은 린트 강화 를 같이 가져왔다.
[감점 답변] '관성으로 남긴다'. [좋은 답변] (1) 이펙트 의존성 안정화 — 의미 있는 변경이 아니면 이펙트가 재실행되지 않도록. 이건 렌더 최적화 가 아니라 동기화 의도 제어 라 컴파일러 영역이 아님. (2) 외부 라이브러리/컴포넌트 인터페이스 — 콜백 props 의 참조 동등성을 요구하는 외부 코드. (3) 명시적 비싼 계산 — 의도를 코드에 박고 싶을 때.
[감점 답변] '한 번에 켠다'. [좋은 답변] 네 단계.
- lint 먼저:
eslint-plugin-react-hooks@latest로 규칙 위반을 정리 - target 고정: React 17/18 이라면
react-compiler-runtime추가 - 부분 활성화(gating): 디렉터리/플래그 단위로 켜고 e2e 테스트 회귀 모니터링
- 버전 고정:
--save-exact— 메모이제이션 휴리스틱 변경이 과/미실행 useEffect 를 만들 수 있어 업그레이드는 수동/테스트 후
자기 점검
"컴파일러가 자동으로 고쳐준다" 는 환상. 실제로는 분석을 포기하고 보수적인 코드를 낸다.
"전부 제거 가능" 이라는 인식. 이펙트 의존성/외부 인터페이스 자리는 별도 의미를 가진다.
벤치마크의 상한 을 내 앱의 평균으로 가정하는 것. 우리 앱이 이미 잘 메모이제이션돼 있으면 추가 이득이 작을 수 있다.