소개
Webpack, Babel, Prettier, ESLint처럼 우리가 매일 사용하는 자바스크립트 개발 도구들이 어느 순간부터 Rust 기반으로 빠르게 바뀌고 있습니다.
이 글은 왜 자바스크립트 툴체인이 Rust로 이동하기 시작했는지, SWC부터 Turbopack, Rolldown, Oxc, Biome까지 그 흐름을 짚어봅니다. 특히 2021년에 작성된 글을 2026년에 다시 업데이트하면서, 당시의 예측이 실제로 어떻게 현실이 되었는지도 보여줍니다.
평소 당연하게 사용하던 프론트엔드 도구들이 왜 Rust로 이동하고 있는지, 그 배경과 흐름을 살펴보기에 좋은 글입니다.
팀원들의 의견
Q1. Rspack이나 Oxlint 같은 Rust 기반 도구를 실제로 써보신 적 있으신가요? 써보셨다면 기존 도구(webpack, ESLint 등)랑 비교했을 때 가장 크게 체감된 차이가 뭐였는지 궁금합니다!
💬. 의견 1
요즘은 번들러 자체가 워낙 잘돼있어서 Rust라서 특별히 이득 봤다는 느낌은 크지 않아요. 다만 초기 Turbopack이 Rust 기반 SWC 컴파일러를 내장하면서 확실히 덕을 본 케이스라고 봐요. 로우레벨 도구가 계속 늘어나는 걸 보면 생태계는 앞으로도 커질 것 같아서, 신규 프로젝트에는 Rspack이나 Oxlint를 적극 써보고 싶습니다.
💬. 의견 2
저희 회사에 최근 Oxlint가 도입돼서 써보고 있는데, 아직 며칠 안 돼서 속도 체감은 크게 못했어요. 오히려 저는 속도보다 기존 ESLint 규칙과 설정을 얼마나 안정적으로 대체할 수 있느냐가 더 궁금하더라고요. 아무리 빨라도 팀이 써온 방식이 흔들리면 오히려 비용이 커질 수 있으니, 호환성이랑 유지보수성을 좀 더 지켜보려고 합니다.
Q2. Rust 기반 도구들이 속도 면에서는 확실히 장점이 있는데, 반대로 플러그인 생태계가 아직 기존 도구만큼 성숙하지 않거나, 문제가 생겼을 때 Rust를 모르면 디버깅이 어려워지는 부분도 있을 것 같아요. 이런 트레이드오프에 대해 어떻게 생각하시나요?
💬. 의견 1
말씀하신 대로 플러그인 생태계가 아직 덜 성숙했다면 기존 도구를 완전히 대체하기는 어려울 것 같아요. 다만 빌드나 린트가 병목인 프로젝트라면 일부 기능부터 도입해볼 가치는 충분하다고 봅니다. 그리고 요즘은 AI를 잘 활용할 수 있는 환경이라, Rust를 직접 몰라도 디버깅이 예전만큼 어렵지는 않을 것 같아요.
💬. 의견 2
올해 Rust로 작업을 좀 해봤는데, 언어를 모르는 것 자체는 에이전트 도움으로 어느 정도 커버가 되더라고요. 오히려 힘들었던 건 언어가 아니라 JS만큼 디버깅 환경이나 플러그인, 참고할 만한 문제 해결 사례가 아직 충분하지 않다는 점이었어요. 그래서 저는 성능이 중요하고 자주 안 바뀌는 코어는 Rust로, 설정이나 플러그인처럼 사용자가 직접 만지는 부분은 JS로 열어두는 구조가 현실적인 절충안이 아닐까 싶습니다.
목차
Rust란?
도입 현황
자바스크립트에서 Rust로
SWC
Deno
esbuild
Rome
NAPI
Rust + WebAssembly
Rust를 쓰지 말아야 할 이유
자바스크립트 툴링의 미래
업데이트: 2023년
업데이트: 2026년