러스트로 다시 쓴 React 컴파일러, Vite에 네이티브로 들어오다

프런트엔드 빌드 도구의 무게중심이 자바스크립트에서 러스트로 넘어가는 흐름이 React 컴파일러까지 도달했다. oxc 팀이 2026년 8월 4일 러스트 기반 React 컴파일러에 대한 공식 지원을 내놓으면서, 기존 Babel 위에서 돌아가던 컴파일 단계를 러스트 네이티브로 대체할 수 있게 됐다. 웹사이트 빌더 Outlyne 팀은 1,036개 파일 규모의 React Router 코드베이스를 이 새 컴파일러로 전환했고, 컴파일 구간에서 약 17.6배의 속도 향상을 확인했다고 밝혔다.

속도라는 헤드라인

수치는 구체적이다. Babel로 처리할 때 14.3초 걸리던 컴파일 단계가 러스트 네이티브에서 0.81초로 줄었다. 단일 스레드 기준이라는 점을 감안하면 상당한 폭이다. oxc 프로젝트 리드인 보센(Boshen)은 예비 벤치마크에서 Babel보다 10배 이상 빠르다고 언급했는데, 실제 대규모 코드베이스에서는 그보다 더 큰 격차가 나온 셈이다.

다만 이 속도 향상은 어디까지나 빌드 과정 중 '컴파일러 부분'에만 해당한다. 실제 빌드에는 번들링을 비롯한 다른 작업이 많이 섞여 있어서 전체 빌드 시간의 개선 폭은 훨씬 완만하다. Outlyne의 경우 전체 빌드는 22.1초에서 9.3초로 약 2.4배 빨라졌다. 컴파일 단계만 떼어 본 17배와 전체 2.4배 사이의 간극은, 벤치마크 수치를 실무 체감으로 옮길 때 반드시 구분해야 하는 지점이다. 그럼에도 에이전트 기반 개발로 커밋과 CI 실행 빈도가 늘어난 환경에서는, GitHub Actions 분당 과금과 대기 시간이 실질적인 비용이 되기 때문에 이 정도 단축도 의미가 크다.

속도보다 중요한 것: 최신 컴파일러라는 점

글쓴이는 오히려 속도보다 최신 React 컴파일러 위에 올라선다는 점을 더 강조한다. Babel 기반 컴파일러 1.0 정식판에는 자바스크립트 지원에 여러 한계가 남아 있었는데, 러스트 버전은 이미 그중 일부를 해결했다. 대표적으로 try/catch 블록 안의 조건 분기 지원은 초기 1.0의 발목을 잡던 문제였다. 또 구조 분해로 받은 컴포넌트 prop을 재할당한 뒤 중첩 클로저에서 사용하는 패턴, 그리고 계산된 객체 프로퍼티 키(computed property key)도 이제 정상 처리된다. Outlyne 앱에서는 이 개선들 덕에 컴파일 대상 함수가 일곱 개 늘었다. try/catch 개선으로 다섯 개, 계산된 프로퍼티 키로 두 개다.

물론 한계는 남아 있다. try 블록 내부에서의 throw, 그리고 논리 할당 연산자(??=, &&=, ||=)를 쓰는 코드는 여전히 컴파일러가 최적화를 건너뛴다. 핵심은 러스트 컴파일러 위에 있으면 이런 문제들이 고쳐질 때 그 수정을 계속 받아볼 수 있다는 점이다. 사실상 개발이 멈춘 Babel 기반 컴파일러에 머물러 있으면 기대하기 어려운 부분이다.

툴체인 일관성이라는 숨은 이점

또 하나 주목할 만한 이유는 툴체인 전체가 동일한 버전의 React 컴파일러를 쓰게 된다는 점이다. 글쓴이는 빌드는 옛 버전, 린트는 Oxlint를 쓰던 시점에 실제로 혼란을 겪었다. 구조 분해 prop 재할당 패턴이 빌드에서는 최적화되지 않으면서도 린트 오류는 나지 않아, 린터와 컴파일러 출력이 어긋난 것으로 오인하고 oxc에 잘못된 이슈를 제출했던 것이다. 원인은 Oxlint가 해당 패턴을 지원하는 oxc-transform-react 0.145.0을 쓰고 있었던 반면, 빌드 테스트는 0.144.0이었다는 버전 차이였다. 이제 린터와 빌드가 같은 컴파일러를 공유하므로, 최적화되지 않은 컴포넌트가 프로덕션 빌드에 조용히 섞여 들어갈 걱정이 줄어든다.

전환 방법과 실무적 고려

적용 자체는 대체로 설정을 덜어내는 방향이다. 전제 조건은 Vite v8 이상이며, @vitejs/plugin-react v6.1.0부터 플러그인에 { compiler: true }를 넘기는 실험적 네이티브 지원이 들어왔다. 일반적인 React Vite 빌드라면 전환은 곧 설정 간소화를 뜻하고, dev 의존성에서 @rolldown/plugin-babel도 제거할 수 있다. Outlyne처럼 React Router를 프레임워크 모드로 쓰는 경우에는 Vite React 플러그인 대신 React Router 자체 플러그인을 써야 하므로 방식이 조금 다르다. 이때는 @acusti/vite-plugin-react-compiler 같은 최소 플러그인을 도입하고, vite-plugin-babel과 babel-plugin-react-compiler, @babel/preset-typescript를 통째로 걷어낼 수 있다.

정리하면, 이번 변화는 단순한 속도 자랑을 넘어 컴파일 파이프라인에서 Babel 의존성을 걷어내고 린트와 빌드를 하나의 최신 컴파일러로 수렴시키는 작업에 가깝다. 다만 '실험적' 지원이라는 꼬리표와 Vite v8 이상이라는 전제, 그리고 여전히 남아 있는 미지원 패턴은 도입 전에 각자의 코드베이스에서 확인해야 할 몫이다.