개요
SWC는 Rust로 작성된 초고속 TypeScript/JavaScript 컴파일러 겸 트랜스파일러 동일한 작업을 수행하는 Babel이나 tsc 대비 10~20배 수준의 성능 향상이 보고됨 Rust로 구현되어 JS 런타임 기반 도구 대비 낮은 오버헤드와 높은 병렬 처리 효율 확보
핵심 개념
목적 TS/JS 소스 코드를 목표 런타임에서 실행 가능한 코드로 빠르게 변환 특징 타입 체크 미포함, 변환에 집중해 극단적 속도 추구 적용 범위 컴파일 단계와 테스트 실행, 개발 서버 부팅, CI 빌드 가속에 유효 채택 사례 Next.js에 기본 통합됨, 서버 프레임워크에서도 선택지로 확산 중
왜 SWC인가
기존 파이프라인의 병목
- tsc 타입 체크와 컴파일을 한 번에 수행해 대규모 코드베이스에서 지연 증가
- Babel 변환 유연성은 높지만 TS 처리와 플러그인 조합이 무거워질수록 느려짐
SWC의 이점
- 타입 체크 제외 변환만 빠르게 처리해 빌드 시간을 단축
- Rust 구현 대규모 모노레포에서도 안정적인 처리량과 짧은 레이턴시 확보
- 생태계 통합 Next.js가 컴파일러로 채택, 서버 사이드 프로젝트에서도 선택 폭 확대
동작 원리와 구조
- 파서 TS와 최신 JS 문법을 빠르게 AST로 변환
- 트랜스폼 타깃 환경에 맞춰 문법 다운레벨링 및 최적화 수행
- 코드 생성 모듈 시스템과 타깃 버전에 맞춰 결과 코드 출력
- 병렬화 Rust 스레딩과 효율적인 메모리 사용으로 빌드 시간 단축
타입 체크는 별도 도구로 분리하는 설계 철학을 가짐
- 정적 분석과 컴파일 속도는 상충 관계에 가까움
- 팀 필요에 따라 tsc –noEmit 또는 타입 전용 CI 단계로 분리 운영 권장
NestJS에서 SWC를 쓰는 이유
서버 프로젝트는 규모가 커질수록 ts-node 실행과 빌드 시간이 선형에 가깝게 증가하기 쉬움 SWC 도입 시 다음 영역에서 체감 이득 발생
- 개발 서버 부팅 시간 단축
- 테스트 러너의 트랜스파일 단계 가속
- 프로덕션 빌드 시간 단축과 CI 대기 시간 감소
Nest 10 이후 버전에서 SWC 사용을 쉽게 구성할 수 있는 옵션이 제공되며 실무에서도 권장되는 선택지로 자리 잡는 중 프로젝트 특성에 따라 esbuild 등 대안과 비교 후 채택 권장
언제 특히 유리한가
- 패키지 수와 코드량이 많은 모노레포
- CI 대기열이 길고 빌드 병목이 빈번한 파이프라인
- 핫 리로드가 느려 개발 피드백 루프가 길어진 환경
- ts-node 기반 재시작이 답답한 개발 서버
Next.js와의 조합은 프론트엔드에서, NestJS와의 조합은 백엔드에서 DX를 개선하는 안전한 선택지로 평가됨
주의사항과 한계
- 타입 체크 미포함 런타임 전 품질 보증을 위해 분리된 타입 검사 단계 필요
- 플러그인 생태계 Babel 대비 생태계 성숙도 차이가 존재할 수 있음
- 트랜스폼 호환성 특정 고급 트랜스폼이나 실험적 문법은 별도 설정 또는 제한 가능성
- 디버깅 소스맵 품질은 계속 개선 중이며 환경별 설정 점검 필요
베스트 프랙티스
- 로컬 개발은 SWC로 속도 확보, CI에서 tsc –noEmit로 타입 보증
- 변환 타깃과 모듈 타입을 런타임 환경에 맞춰 최소화 설정
- 캐시 디렉터리와 스레드 수는 CI 실행기 스펙에 맞춰 조정
간단 적용 예
기본 .swcrc 예시
{
"jsc": {
"target": "es2019",
"parser": { "syntax": "typescript", "decorators": true }
},
"module": { "type": "commonjs" },
"sourceMaps": true
}CLI로 src를 dist로 변환하는 예
npx swc src -d dist타입 검사는 분리 실행
npx tsc --noEmit마무리
SWC는 타입 검사와 변환을 분리해 빌드 병목을 줄이는 전략에 최적화된 도구 대규모 코드베이스와 긴 CI 파이프라인, 느린 개발 서버 피드백 루프에서 체감 이득이 큼 프레임워크 통합이 성숙해지는 추세로 안전하게 도입 가능한 시점 타입 품질 게이트를 분리하고 최소 설정으로 시작해 점진 적용 권장