esbuild와 swc — JavaScript 밖에서 온 빌드 도구

"가장 빠른 JavaScript 빌드 도구 가운데 둘은 Go와 Rust로 만들었어. Node에서 호출하지만 Node 자체는 아니야. 그 경계가 속도의 원천과 한계를 함께 설명해."

왜 이렇게 빠를까

한동안 JavaScript 도구는 대부분 JavaScript로 만들었어. Babel은 JavaScript로 코드를 변환했고, webpack은 JavaScript로 모듈을 묶었지. 작은 프로젝트에서는 충분히 빨랐지만 프로젝트가 커지면 변환과 번들링 시간이 눈에 띄게 늘었어. 기존 도구의 핵심 작업이 한 프로세스의 JavaScript 실행 경로에 몰리는 경우가 많았기 때문이야.

esbuild는 2020년에 Evan Wallace가 Go로 만든 번들러고, swc는 2019년에 Donny Wang이 Rust로 만든 변환기야. 둘 다 네이티브 코드와 병렬 처리를 적극적으로 활용해서 기존 JavaScript 기반 도구보다 수십 배 빠른 경우가 있어. 그래서 여러 프런트엔드와 서버 도구가 이들을 직접 쓰거나 비슷한 네이티브 처리 계층을 채택했어.

Go로 만든 번들러 esbuild

esbuild는 두 가지 일을 맡아:

• 변환: TS나 JSX를 JS로 바꾸고, 새 JavaScript 문법을 지정한 대상 버전에 맞춰 내려.
• 번들링: import 그래프를 따라가며 파일을 합치고, 쓰지 않는 코드를 덜어 내고, 결과를 압축해.

npm 패키지로 설치하고 Node에서 호출하지만 무거운 작업은 node_modules에 함께 설치된 Go 바이너리가 처리해. Node 쪽 코드는 명령을 전달하고 결과를 받는 얇은 연결 계층이야. esbuild가 빠른 이유는 JavaScript 코드를 특별히 잘 최적화해서가 아니라, Node가 네이티브 프로그램을 지휘하기 때문이야.

Rust로 만든 변환기 swc

swc는 주로 TS와 JSX를 JavaScript로 바꾸는 변환 단계에 집중해. Next.js도 TypeScript와 JavaScript 변환에 swc를 사용해 왔어. esbuild가 변환과 번들링을 함께 맡을 수 있다면, swc의 중심 역할은 빠른 구문 변환이야.

둘 가운데 하나만 골라야 하는 건 아니야. swc로 소스를 변환하고 esbuild로 번들링할 수도 있어. 중요한 건 도구 이름보다 각 단계의 소유권이야. 무엇이 문법을 바꾸고, 무엇이 모듈 그래프를 묶는지 알아야 느려졌을 때 원인을 찾을 수 있어.

속도가 중요하지 않은 경우

플러그인이 다시 느리게 만든다

esbuild와 swc 자체는 빨라도 플러그인이 그 장점을 깎을 수 있어. 특히 변환할 때마다 JavaScript 플러그인으로 왕복하면 Go나 Rust에서 처리하던 빠른 경로가 자꾸 끊겨. 속도를 얻으려고 esbuild를 설치한 뒤 플러그인을 열 개 얹어 예전 webpack 수준으로 돌아가는 일이 흔해. esbuild를 쓰는데도 빌드가 느리다면 플러그인별 실행 시간과 네이티브 경계를 넘는 횟수부터 확인해.

Pippa의 고백