SWC: Babel을 밀어내는 Rust 컴파일러, 왜 지금 JS 인프라의 공통 엔진이 됐나
하루 +163스타·GitHub 33K 프로젝트가 현대 빌드 파이프라인의 핵심 부품이 된 이유와 5분 시작 가이드

2026년 중반, 프론트엔드 빌드 생태계의 지각이 다시 흔들리고 있다. Rust 기반 컴파일러 SWC가 하루에 별 163개를 받으며 GitHub 트렌딩에 재진입했다. 누적 별 3만 3천 개. 숫자보다 중요한 건 이 프로젝트가 이미 당신의 프로젝트 어딘가에서 조용히 돌아가고 있을 가능성이 높다는 점이다.
이게 뭔가
SWC(Speedy Web Compiler)는 TypeScript·JavaScript 코드를 변환(트랜스파일)하는 컴파일러다. 쉽게 말해, 최신 JS 문법으로 쓴 코드를 구형 브라우저도 읽을 수 있도록 바꿔 주는 도구다. 10년 가까이 이 역할을 독점해 온 것이 Babel이다. SWC는 똑같은 일을 Rust로 구현했다. 공식 벤치마크 기준, 단일 스레드에서 Babel보다 약 20배, 4코어에서는 약 70배 빠르다.
왜 지금 뜨는가
SWC 자체는 2019년부터 존재했다. 지금 다시 트렌딩에 오르는 이유는 단독 성장이 아니라 생태계 동반 성장 때문이다.
- Next.js는 v12(2021)부터 SWC를 기본 컴파일러로 탑재했다.
- Vercel의 Turbopack과 Rspack 모두 SWC를 핵심 파서로 채택한다.
- Deno가 TypeScript 처리에 SWC를 쓴다.
- Vite의 번들러 백엔드로 Rolldown이 안착하면서 Rust 기반 툴체인 전체가 주류가 됐다.
결과적으로 SWC는 하나의 도구가 아니라 현대 JS 인프라의 공통 부품이 됐다. 의존하는 프로젝트가 많아질수록 이슈·기여·관심도 함께 오른다.
핵심 기능
- 트랜스파일: ES2015+ → ES5, JSX → JS, TypeScript → JS
- 미니파이: 코드 압축 및 최적화
- WASM 플러그인: 커스텀 변환 로직을 WebAssembly로 확장
- 번들링: 실험적 지원 (
@swc/cli연동) - Rust 크레이트:
swc_ecma_parser로 AST를 직접 다루는 저수준 API 제공
누구에게 쓸모 있나
| 대상 | 실익 |
|---|---|
| Next.js 사용자 | 이미 내장 — 별도 설정 없이 혜택 중 |
| Vite / Rspack 팀 | SWC 플러그인으로 파서 교체 가능 |
| 빌드 병목을 겪는 CI/CD 팀 | 트랜스파일 단계 즉각 단축 |
| Rust 생태계 개발자 | swc_ecma_parser 크레이트로 AST 직접 활용 |
시작하기
Node v10 이상이면 바로 설치된다. (공식 설치 문서 참조)
# 핵심 라이브러리와 CLI 설치
npm install --save-dev @swc/core @swc/cli
프로젝트 루트에 .swcrc 설정 파일을 생성한다.
{
"jsc": {
"parser": { "syntax": "typescript", "tsx": true },
"target": "es2020"
},
"module": { "type": "commonjs" }
}
사용 예시
① TypeScript 파일 단일 변환 — src/index.ts를 JS로 출력한다.
npx swc src/index.ts -o dist/index.js
② 디렉터리 전체 감시 모드 — 파일 저장 시 자동으로 재변환한다.
npx swc src -d dist --watch
③ Node.js API로 코드 내 직접 변환 — 빌드 스크립트·도구 제작 시 유용하다.
const { transformSync } = require('@swc/core');
const result = transformSync(`const x: number = 42;`, {
filename: 'input.ts',
jsc: { parser: { syntax: 'typescript' } },
});
console.log(result.code); // "const x = 42;"
한계·주의
SWC는 타입 검사를 수행하지 않는다. 코드를 변환할 뿐이므로, 타입 오류를 잡으려면 tsc --noEmit을 반드시 별도로 실행해야 한다. Babel 플러그인에 강하게 의존하는 프로젝트라면 동등한 SWC 플러그인이 없을 수 있어 마이그레이션 전 호환성 검토가 필수다. 번들링 기능은 공식적으로 실험 단계이므로 프로덕션 번들은 Vite·Webpack과 병용하는 것이 안전하다.
결론: SWC는 이미 당신의 스택 어딘가에 들어와 있다. 직접 쓰지 않더라도 Next.js나 Rspack이 대신 쓰고 있다. 직접 빌드 파이프라인을 구성하는 팀이라면 Babel을 SWC로 교체하는 것이 현시점에서 가장 비용 대비 효과가 높은 성능 최적화 중 하나다.
출처
- swc-project/swc GitHub 레포지토리 — GitHub
- SWC 공식 문서 — swc.rs
댓글 0
첫 댓글을 남겨보세요.
