자바스크립트 빌드가 최근 몇 년 사이 눈에 띄게 빨라졌다. 그 배경엔 esbuild, SWC, 그리고 러스트·Go로 다시 쓴 도구들이 있다. 웹팩 시절 몇 분씩 걸리던 번들링이 이제 초 단위로 끝나는데, 단순히 "새 도구가 나왔다"가 아니라 도구를 만드는 언어 자체가 바뀐 결과다.
나도 처음엔 반신반의했다. 빌드 도구를 바꾼다고 얼마나 빨라지겠나 싶었는데, 실제로 개발 서버 시작이 십몇 초에서 1초 아래로 떨어지는 걸 보고 생각이 바뀌었다. 기다림이 사라지니 작업 흐름 자체가 달라진다.
빌드가 느린 건 자바스크립트로 만든 빌드 도구 탓이었다.
파싱·변환처럼 CPU를 많이 쓰는 일을 네이티브 언어(러스트·Go)로 옮기고 병렬 처리하니, 같은 작업이 수십 배 빨라졌다.
Go·Rust 네이티브로 다시 작성 |
병렬처리 멀티코어를 제대로 활용 |
초단위 분 단위 빌드가 초로 |
통합툴 번들·트랜스파일 한 도구로 |
왜 갑자기 빨라졌나
이유는 단순하다. 번들러가 하는 일 대부분은 소스를 파싱해 추상 구문 트리(AST)로 바꾸고, 변환하고, 다시 문자열로 합치는 CPU 집약적 작업이다. 이걸 자바스크립트로 하면 싱글 스레드에다 인터프리터 오버헤드까지 얹힌다.
esbuild는 이 과정을 Go로, SWC와 그 계열은 러스트로 다시 썼다. 네이티브로 컴파일되니 빠르고, 언어 차원의 병렬성으로 여러 파일을 동시에 처리한다. 여기에 불필요한 일을 안 하는 설계가 더해진다. 개발 중엔 전체를 번들하지 않고 브라우저가 요청한 모듈만 그때그때 변환해 내려주는 식이다.
도구가 하나로 합쳐지는 흐름
또 하나의 변화는 통합이다. 예전엔 트랜스파일러, 번들러, 미니파이어, 린터, 포매터가 다 따로였다. 지금은 이걸 한 네이티브 도구가 묶어서 처리하려는 흐름이 뚜렷하다. 도구 사이를 오가며 같은 파일을 여러 번 파싱하던 낭비가 사라진다.
| 항목 | 네이티브 툴체인 | 기존(JS 기반) |
|---|---|---|
| 구현 언어 | Go·Rust | 자바스크립트 |
| 병렬성 | 멀티코어 활용 | 대체로 싱글 스레드 |
| 개발 서버 시작 | 즉시(요청 시 변환) | 전체 번들 대기 |
| 플러그인 생태계 | 성장 중 | 성숙·방대 |
공짜는 아니다
물론 트레이드오프가 있다. 오랫동안 쌓인 자바스크립트 플러그인 생태계를 네이티브 도구가 아직 다 대체하진 못한다. 러스트/Go로 플러그인을 짜야 하는 경우도 있고, 특정 변환은 여전히 기존 도구가 필요하다. 그래서 현실적으로는 속도가 중요한 핵심 경로는 네이티브로, 나머지는 기존 도구로 섞어 쓰는 구성이 많다.
그럼에도 방향은 분명하다. "빌드 도구는 느린 게 당연하다"는 전제가 깨졌고, 한 번 빠른 맛을 보면 되돌아가기 어렵다. 개인적으로는 이 흐름이 프런트엔드에서 가장 체감이 큰 변화 중 하나라고 본다.
자주 묻는 질문
esbuild와 SWC는 무엇이 다른가요?
esbuild는 Go로, SWC는 러스트로 작성된 번들러/트랜스파일러입니다. 둘 다 네이티브 속도를 내며, 여러 최신 빌드 도구가 내부적으로 이들을 엔진으로 씁니다. 세부 기능과 플러그인 방식에 차이가 있어 도구에 따라 선택이 갈립니다.
기존 웹팩 설정을 당장 버려야 하나요?
아닙니다. 웹팩은 여전히 방대한 플러그인과 세밀한 제어가 강점입니다. 다만 개발 서버 속도가 중요하거나 새 프로젝트라면 네이티브 기반 도구가 체감 이점이 큽니다. 점진적으로 옮기는 팀이 많습니다.
왜 자바스크립트 도구를 자바스크립트로 안 만드나요?
파싱·변환처럼 CPU를 많이 쓰는 작업은 네이티브 언어가 훨씬 빠르고 병렬화도 쉽기 때문입니다. 결과물(번들)은 자바스크립트지만, 그걸 만드는 도구는 다른 언어로 짜는 게 성능상 유리합니다.
댓글 0