Vite와 Turbopack 빌드 성능 비교와 전환 판단

"빌드가 느리다"는 말은 개발 서버 시작이 느린 것인지, 파일을 저장한 뒤 화면이 갱신되기까지가 느린 것인지, 아니면 배포용 프로덕션 빌드가 오래 걸리는 것인지에 따라 원인과 해법이 전혀 다르다. Vite와 Turbopack은 이 세 가지 지점에서 서로 다른 설계를 갖고 있어, 어느 쪽이 "항상 빠르다"고 단정하기 어렵다. 이 글은 두 도구의 구조 차이를 짚고, 프로젝트 특성에 따라 무엇을 기준으로 전환을 판단할지 정리한다.

빌드 도구를 바꿀 만한 신호

먼저 전환이 정말 필요한지 판단한다. 다음 신호가 뚜렷하지 않다면 지금 도구를 튜닝하는 편이 비용이 낮다.

• 개발 서버 콜드 스타트가 반복적으로 수십 초 이상 걸려 작업 리듬이 끊긴다.
• 파일 저장 후 HMR 반영까지 체감 지연이 커서 저장과 확인 사이에 대기가 생긴다.
• 프로덕션 빌드가 CI 시간을 지배해 배포 주기를 제한한다.
• 콜드 캐시 환경(CI, 신규 클론)에서 성능 저하가 특히 심하다.

개발 서버·HMR 체감 차이

Vite 공식 가이드에 따르면 Vite(vite.config.ts)의 개발 서버는 브라우저의 네이티브 ESM을 기반으로 요청된 모듈만 변환해 내려보내고 의존성은 node_modules/.vite에 사전 번들링한다. 의존성은 사전 번들링으로 묶고, 소스 코드는 브라우저가 요청할 때 변환한다. 그래서 앱 전체를 미리 묶지 않아도 첫 화면이 뜨고, 수정한 모듈 경계를 따라 갱신 범위가 좁다. Turbopack은 Next.js 생태계에서 쓰이는 증분 번들러로, 변경 지점을 기준으로 재계산 범위를 좁히고 결과를 캐시하는 데 초점을 둔다.

체감 차이는 프로젝트 형태에 좌우된다. 페이지 수가 많고 라우트 경계가 명확한 Next.js 앱이라면 증분 캐시의 이점이 크다. 반대로 프레임워크 없이 조립한 SPA나 라이브러리라면 Vite의 요청 기반 변환이 더 단순하고 예측 가능하다.

프로덕션 빌드 성능과 캐시

개발 서버가 빠르다고 프로덕션 빌드도 빠른 것은 아니다. 프로덕션 빌드는 트리 셰이킹, 코드 분할, 압축, 청크 최적화까지 수행하기 때문이다. Vite의 프로덕션 빌드는 롤업 계열 번들러를 사용하고, Turbopack은 next.config.ts와 통합되어 함수·모듈 단위 증분 컴파일 결과를 .next/cache에 재사용한다. 타입 검사 병목을 함께 줄이려면 TypeScript 7.0 네이티브 컴파일러 전환 분석에서 다룬 컴파일 파이프라인 분리도 함께 검토한다.

측정 지표와 측정 방법

"빠르다"를 논하려면 지표와 측정 조건을 고정해야 한다. 최소한 다음 세 가지를 같은 조건에서 잰다.

측정할 때는 워밍업 라운드를 버리고 중앙값을 본다. 한 번의 측정값은 캐시 상태나 백그라운드 작업에 쉽게 흔들린다.

플러그인·생태계 의존성 점검

전환 비용의 대부분은 플러그인 호환에서 나온다. Vite는 자체 플러그인 API를 중심으로 생태계가 넓고, Turbopack은 Next.js 설정과 통합되는 범위에서 지원된다. 다음을 확인한다.

• 커스텀 번들 플러그인이 Vite 전용 API에 의존하는지, Turbopack에서 대응 기능이 있는지.
• CSS 전처리기·에셋 처리 방식이 같은 결과를 내는지.
• 소스맵 생성 방식과 에러 스택 해석이 동일한지. 소스맵 품질이 달라지면 운영 중 디버깅이 어려워진다.

Next.js 프로젝트라면 빌드 설정 변경이 라우팅·이미지 최적화와 얽히므로 Next.js 마이그레이션 글의 확인 항목과 함께 점검하는 편이 좋다.

전환 비용과 되돌리기 전략

전환은 보통 "설정 한 줄 교체"로 끝나지 않는다. 빌드 도구는 플러그인, 환경 변수 주입, 에셋 경로 규칙에 영향을 준다. 되돌리기 전략은 간단하다. 별도 브랜치에서 시도하고, 같은 화면 집합에 대해 스크린샷과 번들 크기를 비교한 뒤, 지표가 유의미하게 개선되지 않으면 병합하지 않는다.

# 설정을 바꾼 뒤 동일 조건에서 비교
rm -rf node_modules/.vite .next/cache
time npm run build
ls -lh dist/assets | sort -k5 -h

전환을 보류해야 하는 경우

다음 상황에서는 지금 도구를 유지하는 편이 낫다. 첫째, 곧 프레임워크 전환이나 대규모 리팩터링이 예정되어 있어 빌드 도구 교체가 그 위에 겹치는 경우다. 둘째, 빌드 파이프라인이 사내 보안 정책이나 배포 시스템과 강하게 결합되어 있어 도구 교체가 검증 범위를 넓히는 경우다. 셋째, 문제의 원인이 도구가 아니라 플러그인 설정이나 캐시 무효화 규칙에 있는 경우다. 이때는 도구를 바꾸기 전에 캐시 입력과 플러그인 옵션을 먼저 점검한다. 빌드 도구는 한 번 바꾸면 플러그인·소스맵·에셋 규칙까지 따라 바뀌므로, 원인이 명확하지 않은 상태에서 교체를 서두르면 문제만 하나 더 얹는다.

또한 빌드 도구는 개발자 경험에 직결되므로, 전환 여부를 결정할 때 팀원의 로컬 환경(운영체제, 하드웨어)까지 고려한다. 특정 환경에서만 캐시가 잘 동작하거나 파일 감시가 누락되는 문제가 있으면, 평균 성능보다 최악의 경우를 기준으로 판단해야 한다.

결정을 문서화하는 기준

도구 선택은 취향 문제로 남기 쉽다. 그래서 팀 차원에서는 "무엇을 재서 무엇 때문에 골랐는지"를 한 장으로 남긴다. 측정 조건, 기준 지표, 임계값, 되돌리기 조건을 적어 두면 다음 사람이 같은 논쟁을 반복하지 않는다. 결론적으로 개발 서버 체감과 프레임워크 통합이 중요하면 Turbopack, 유연한 생태계와 예측 가능한 파이프라인이 중요하면 Vite가 잘 맞는다.