Rspack webpack 호환 마이그레이션 비용 해부

Rspack으로 옮기면 webpack 설정은 얼마나 다시 써야 하나?

결론부터 말하면, 설정 파일 자체를 다시 쓰는 비용은 낮다. 진짜 비용은 babel-loader를 builtin:swc-loader로 바꾸는 트랜스파일 체인 재구성과, webpack 전용 플러그인·로더를 Rspack 내장 기능으로 치환하는 작업에 몰려 있다. 반면 캐시와 HMR이 주는 이득은 전환 직후부터 바로 체감된다.

이 글은 webpack v5 프로젝트를 Rspack 1.x~2.0으로 옮기는 경우로 범위를 못박는다. 다루는 계층은 ①설정 파일 문법 호환, ②로더/트랜스파일 체인, ③플러그인 생태계, ④캐시·증분 빌드 성능 네 가지다. 도입 여부의 사업적 판단은 이 매체의 관심사가 아니다.

• 설정 마이그레이션 자체는 문법 호환 덕분에 손이 적게 간다
• 실질 비용은 babel-loader → builtin:swc-loader 전환에 집중된다
• HtmlWebpackPlugin, CSS 추출 플러그인 등은 개별적으로 치환해야 한다
• 캐시 활성 시 1.4초, HMR 118ms — Rspack 2.0 공식 벤치마크 기준
• 설정을 거의 그대로 옮긴 사례에서도 평균 52% 빌드 시간 단축이 관측됐다

설정 파일 자체는 왜 이전 비용이 낮을까?

module.rules, resolve, output 같은 핵심 옵션 키가 대부분 그대로 동작하기 때문이다. Rspack 1.0은 webpack v5와 호환되도록 설계됐고, 공식 블로그는 "smooth migration"을 명시적 목표로 걸었다 Rspack 공식 블로그. 문법 레벨에서의 재작성 비용이 낮다는 것이지, 동작 결과가 100% 동일하다는 뜻은 아니다.

트랜스파일 체인은 왜 가장 큰 비용 지점이 될까?

공식 마이그레이션 문서가 babel-loader 대신 builtin:swc-loader를 쓰라고 권고하는 대목이 이 지점이다 Rspack 마이그레이션 가이드. 이는 패키지 이름 하나 바꾸는 작업이 아니라, .babelrc의 프리셋·플러그인 설정을 SWC 옵션 스키마로 다시 매핑하는 작업이다. 데코레이터, 커스�터 바벨 플러그인, 매크로에 의존하는 프로젝트일수록 이 변환에 걸리는 시간이 늘어난다.

플러그인·로더 생태계는 어디서 막히나?

HtmlWebpackPlugin import 경로 변경, CSS 추출 플러그인의 Rspack 내장 기능 대체처럼 표준 구성 요소는 문서가 예시를 제공한다. 문제는 webpack 컴파일러 훅에 직접 의존해 작성된 커스텀 플러그인이다. 이런 플러그인은 Rust 코어로 이식돼 있지 않으면 대체재를 찾거나 새로 작성해야 하며, 이 부분이 실제 견적에서 가장 예측하기 어려운 변수로 남는다.

실측 수치는 이 비용을 정당화할 만큼 큰가?

조건을 붙이면 그렇다. Rspack 2.0 공식 릴리스 벤치마크는 1.7 대비 전체 성능 약 10% 개선, 1.0 대비 최대 100% 개선을 보고하며, production build는 캐시 없이 3.1초, 캐시 있을 때 1.4초, HMR은 118ms로 제시한다.

이 벤치마크는 "with cache" 항목을 따로 분리해 증분 빌드 효과를 독립적으로 보여준다는 점이 특징이다 Rspack 2.0 릴리스 노트. 별도의 공개 벤치마크 페이지는 dev cold start 기준 Rspack 3.79초, webpack(swc) 31.25초, webpack(babel) 42.61초, production cold start는 각각 22.353초, 75.054초, 160.059초를 제시한다. 다만 이 수치는 특정 프로젝트 구조에서 얻은 값이므로 재현 조건이 있는 비교 자료로만 받아들이는 편이 안전하다. Yelp의 2026년 사례는 webpack 설정을 거의 그대로 옮긴 뒤 여러 최적화를 추가해 통합 빌드 시간을 평균 약 52% 줄였는데, 이는 1차 전환 비용과 2차 최적화 비용을 분리해서 봐야 한다는 뜻이다.

무엇을 얻고 무엇을 내주는가?

얻는 것은 캐시 기반 증분 빌드와 HMR의 체감 단축이다. 내주는 것은 webpack 생태계에 맞춰 최적화된 순정 플러그인·Babel 파이프라인의 즉시 재사용성이다. 전환 초기에는 두 빌드 시스템의 출력 결과를 병행 검증해야 하는 기간이 필요하고, 이 기간은 코드베이스 규모와 커스텀 로더 수에 비례해 늘어난다. 속도를 얻는 대신 검증 공수를 지불하는 구조다.

언제 옮기고 언제 미뤄야 하나?

css-loader, style-loader, babel-loader 수준의 표준 로더와 표준 플러그인 위주 구성이라면 전환 비용은 낮고 이득은 바로 나타난다. 반대로 webpack 컴파일러 훅에 직접 의존하는 커스텀 플러그인, 특수한 멀티 컴파일러 구성, Babel 매크로에 강하게 의존하는 프로젝트라면 SWC 호환성 검증에 별도 시간을 배정해야 하며, 이 검증이 끝나기 전까지는 전환을 미루는 편이 안전하다. 2026년 기준으로도 이 판단 기준은 크게 달라지지 않았다.

핵심 정리

• Rspack 마이그레이션 비용의 중심은 설정 이전이 아니라 babel-loader → builtin:swc-loader 전환이다
• HtmlWebpackPlugin, CSS 추출 플러그인 등은 개별 치환이 필요하고, 컴파일러 훅 의존 플러그인이 가장 큰 리스크다
• Rspack 2.0 공식 벤치마크: 캐시 있을 때 1.4초, HMR 118ms, 1.0 대비 최대 100% 개선
• 공개 벤치마크 기준 dev cold start는 Rspack 3.79초 vs webpack(babel) 42.61초로 차이가 크지만 재현 조건부 수치로 다뤄야 한다
• Yelp 사례처럼 설정을 그대로 옮긴 1차 전환만으로도 평균 52% 단축이 가능하나, 총비용은 2차 최적화 여부에 따라 갈린다

더 알아보기

빌드·번들 툴체인 완전 가이드: 증분성·캐시·병렬성의 측정 — 이 주제의 종합 가이드