🚀 React Compiler: React 18 서비스 도입 테스트 후기

React 19와 함께 뜨거운 관심을 받고 있는 React Compiler를 현재 운영 중인 React 18 기반의 Coinness 서비스에 직접 적용 테스트를 해보았다.

결론부터 말하자면, 적용하기에는 장점보다 단점이 더 많다. 특히 규모가 큰 코드베이스라면 일괄 적용보다는 점진적인 도입이 필수적이다. 왜 이런 결론을 내렸는지 상세한 후기를 정리해 본다.

⚠️ React 18 환경에서 발견된 주요 단점

마법처럼 모든 것을 최적화해 줄 것 같았지만, React 18이라는 기존 환경에 적용했을 때 무시하기 힘든 단점들이 발견되었다…

추가 라이브러리 설치와 런타임 헬퍼의 개입

React Compiler는 메모이제이션을 위해 내부적으로 useMemoCache라는 훅을 주입한다. 19 버전에는 이미 내장되어 있지만, 18 버전에서는 이를 흉내 내기 위한 별도의 런타임 라이브러리(react-compiler-runtime)와 babel-plugin-react-compiler 설치가 필수적이다.

결국 새로운 의존성이 추가될 뿐만 아니라, 거의 모든 컴포넌트에 최적화 로직과 헬퍼 함수가 들어가면서 전체적인 코드량이 늘어나는 것은 피하기 어렵다.

번들 사이즈의 증가

모든 컴포넌트에 최적화 코드가 삽입되다 보니 전체 코드량이 물리적으로 늘어난다. 서비스 규모가 클수록 이 차이는 더 뚜렷하게 나타난다.

빌드 속도 저하

컴파일러가 정적 분석을 수행하는 단계가 추가되면서 전체적인 빌드 시간이 늘어난다. 대규모 프로젝트에서는 개발 생산성에 영향을 줄 수 있는 수준이다.

`annotation` 모드로 점진적 도입하기

모든 코드를 컴파일러에 맡기는 all 모드보다 개발자가 직접 통제하는 compilationMode: 'annotation' 설정이 훨씬 합리적이라는 결론을 얻었다.

왜 'Annotation' 모드인가?

예측 가능성: 컴파일러가 "마법"처럼 모든 것을 바꾸게 두지 않고, 개발자가 최적화 대상을 직접 통제할 수 있다. 이는 디버깅 시 범위를 좁히는 데 결정적인 역할을 한다.

점진적 도입: 전체를 한꺼번에 바꾸는 리스크 없이, 성능 병목이 발생하는 복잡한 계산 로직이나 무거운 컴포넌트부터 하나씩 적용해 나갈 수 있다.

부작용 최소화: 불필요한 곳에 런타임 헬퍼가 주입되는 것을 막아 번들 사이즈 증가 폭을 효과적으로 억제할 수 있다.

🛠️ 실제 적용 및 설정 예시

React Compiler는 분명 매력적인 도구이지만, React 19 미만 환경의 프로젝트에서는 '통제 가능한 최적화'가 더 중요하다. 무작정 도입하기보다는 annotation 모드를 활용해 리스크를 줄이면서 점진적으로 성능을 개선해 나가는 방향을 추천한다.

🚀 React Compiler: React 18 서비스 도입 테스트 후기

⚠️ React 18 환경에서 발견된 주요 단점

annotation 모드로 점진적 도입하기

`annotation` 모드로 점진적 도입하기