Vite 8.0 출시
(vite.dev)- 기존 esbuild + Rollup 이중 구조를 Rust 기반 번들러 Rolldown으로 단일화하여 최대 10~30배 빠른 빌드 성능을 달성
- 새로운 플러그인 레지스트리 가 공개되어 Vite·Rolldown·Rollup 플러그인을 검색·관리 가능
- Vite Devtools, TypeScript 경로 해석, Wasm SSR, 콘솔 포워딩 등 개발 편의 기능이 추가됨
- 이번 릴리스는 Vite 생태계의 가장 큰 구조적 변화로, 향후 통합 툴체인 발전의 기반이 됨
Rolldown 기반의 Vite 8
- Vite 8은 기존 esbuild(개발용) 과 Rollup(프로덕션용) 의 이중 번들러 구조를 Rolldown 단일 번들러로 통합
- Rolldown은 Rust로 작성된 고성능 번들러로, Rollup과 동일한 플러그인 API를 지원
- 기존 Vite 플러그인의 대부분이 별도 수정 없이 작동
- 성능은 Rollup 대비 10~30배 빠르며, 모듈 단위 캐싱, 유연한 청크 분할, Module Federation 등 고급 기능을 지원
Rolldown 도입 과정
- 초기에는
rolldown-vite패키지로 기술 프리뷰를 제공해 커뮤니티 피드백을 수집- 다양한 실제 코드베이스에서 테스트하며 호환성 문제를 해결
- 주요 플러그인과 프레임워크를 대상으로 한 전용 CI 테스트 체계를 구축
- 2025년 12월 Vite 8 베타를 공개하며 Rolldown을 완전 통합
- 베타 기간 동안 Rolldown은 Release Candidate 단계로 발전하며 안정화
실제 성능 개선 사례
- 여러 기업이 빌드 시간 단축 효과를 보고함
- Linear: 46초 → 6초
- Ramp: 57% 단축
- Mercedes-Benz.io: 최대 38% 단축
- Beehiiv: 64% 단축
- 대규모 프로젝트일수록 효과가 두드러지며, Rolldown의 지속적 개선이 예고됨
통합 툴체인과 기술 스택
- Vite 8은 Vite(빌드 도구), Rolldown(번들러), Oxc(컴파일러) 가 긴밀히 협력하는 엔드투엔드 툴체인으로 발전
- 파싱·변환·최적화 전 과정의 일관성 확보
- Oxc의 의미 분석을 활용한 트리 셰이킹 최적화 가능
- 새로운 JS 사양을 빠르게 도입할 수 있는 구조
추가 기능
- Vite Devtools: 개발 서버에서 프로젝트 상태를 시각적으로 분석 가능
- TypeScript 경로(alias) 자동 해석 및 emitDecoratorMetadata 내장 지원
-
Wasm SSR: 서버사이드 렌더링 환경에서
.wasm?init임포트 지원 - 브라우저 콘솔 포워딩: 브라우저 오류를 터미널로 전달해 디버깅 효율 향상
- @vitejs/plugin-react v6: Babel 제거, Oxc 기반 React Refresh 적용, 설치 용량 감소
향후 개발 방향
- Full Bundle Mode(실험적): 개발 중에도 번들링을 수행해 3배 빠른 서버 시작, 40% 빠른 리로드, 10배 적은 네트워크 요청 달성
- Raw AST 전송 및 Native MagicString 변환으로 Rust와 JS 간 성능 격차 축소
- Environment API 안정화를 위한 생태계 협업 진행 중
설치 용량 변화
- Vite 8은 Vite 7보다 약 15MB 증가
- lightningcss(약 10MB): 기본 CSS 압축 기능 제공
- Rolldown 바이너리(약 5MB): 속도 최적화를 위한 크기 증가
- 향후 릴리스에서 용량 최적화 지속 예정
마이그레이션 가이드
- 대부분의 프로젝트는 설정 변경 없이 업그레이드 가능
- 기존
esbuild및rollupOptions설정이 자동 변환
- 기존
- 대형 프로젝트는 2단계 마이그레이션 권장
- Vite 7에서
rolldown-vite로 전환 후, Vite 8로 업그레이드
- Vite 7에서
- 세부 절차는 공식 Migration Guide와 Changelog에서 확인 가능
Rollup과 esbuild에 대한 감사
- Rollup은 Vite의 플러그인 생태계 기반을 제공했으며, Rolldown이 그 API를 계승
- esbuild는 빠른 개발 경험을 가능케 한 핵심 기술로, Rust·Go 기반 툴링 발전의 계기가 됨
- 두 프로젝트의 기여가 Vite의 DNA에 깊이 내재되어 있음
커뮤니티와 협력
- Vite 8 개발은 sapphi-red와 Vite 팀, Rolldown 팀, 그리고 수많은 커뮤니티 기여자들의 협력으로 완성
- VoidZero, Bolt, NuxtLabs가 주요 파트너로 참여 함
Hacker News 의견들
-
업계가 “빌드는 원래 오래 걸리는 것”이라며 아무 의심 없이 써온 비효율적인 툴들에 얼마나 많은 컴퓨팅 자원을 낭비했는지 새삼 생각하게 됨
우리는 그 느린 빌드에 맞춰 일정을 짜고, 휴식 시간을 농담처럼 만들고, 캐시 레이어까지 구축했음
Vite 유지보수자들에게 찬사를 보냄- 느린 JS 번들로 낭비된 자원보다, 비효율적인 런타임과 추상화로 낭비된 비용이 훨씬 큼
대부분의 프로덕션 소프트웨어는 필요한 것보다 수십 배 느림
Electron 앱들이 수 GB의 RAM을 쓰면서도 40년 전 소프트웨어보다 더 버벅이는 현실이 그 증거임 - 나도 같은 생각을 함. ESLint나 Prettier 같은 툴도 Oxc를 알고 나니 비슷한 낭비처럼 느껴짐
- 앞으로 행렬 곱셈에서도 이런 낭비를 되돌아보게 될 날이 올 것 같음
- 빌드 성능은 오래전부터 내 관심사였음
14년 전, 빌드 기다리며 낭비되는 시간을 깨닫고 특히 Java 생태계에서 이 문제가 심각하다고 느낌
예전에 Ruby 프로젝트에서 통합 테스트가 매번 DB를 새로 만드는 데 10분씩 걸렸음
Kotlin/Spring Boot도 컴파일이 느리고, Rust 컴파일러도 빠르진 않음
하지만 테스트는 우리가 통제할 수 있음. 단위 테스트는 밀리초 단위로 끝나야 하고, 통합 테스트는 병렬화와 데이터 랜덤화를 통해 큰 개선이 가능함
나는 MacBook Pro에서 Redis, DB, Elasticsearch를 포함한 수백 개의 스프링 통합 테스트를 40초 안에 돌림
이런 세팅을 한 번 해두면 빠른 피드백 루프가 생기고, 개발의 즐거움이 돌아옴
- 느린 JS 번들로 낭비된 자원보다, 비효율적인 런타임과 추상화로 낭비된 비용이 훨씬 큼
-
내가 Vite 8에 기여한 부분은 Wasm SSR 지원이었음
.wasm?init임포트가 SSR 환경에서도 작동하도록 확장했음
과정은 느렸지만, 팀이 세세하게 도와주고 문서까지 추가해준 점이 인상 깊었음- 이런 비하인드 스토리를 들으니 더 흥미로움
Vite 팀이 단순히 툴을 만드는 게 아니라 기여자 교육과 협업에도 진심이라는 게 느껴짐
- 이런 비하인드 스토리를 들으니 더 흥미로움
-
Electron 시대에 이런 성능 향상을 보게 되어 정말 반가움
내가 오래 유지해온 프로젝트(React hooks 이전부터 시작됨)는 예전엔 Webpack 기반 react-scripts로 빌드에 2분이 걸렸음
지금은 Vite 8로 1초 만에 끝남. 우리가 얼마나 많은 리소스를 낭비해왔는지 보여주는 사례임- 이제는 AI 모델 위에 기계가 쓸 수 있는 인터페이스를 억지로 붙이는 새로운 악몽이 시작된 듯함
- 아이러니하게도 Vite 홈페이지가 A55나 S23FE에서도 렉이 걸림
- 사실 JS는 원래 빌드 과정이 필요 없는 언어였음
브라우저가 그대로 실행할 수 있어야 하고, TypeScript도 타입만 제거하면 바로 실행되도록 설계됐음
이런 빌드 툴의 존재 자체가 잘못된 방향 같음
-
우리 팀은 Vite 8 도입 후 빌드 시간이 4분에서 30초로 줄었음
거의 드롭인 교체 수준이었고, Vite 팀에게 감사함- 우리도 10초에서 1초로 줄었음. 핵심은 Rolldown 덕분임
Vite에 통합되기 전부터 써왔는데 정말 훌륭함 - 4분이라니, 앱 규모가 얼마나 큰지 궁금함
Next보다 빠르다고들 하는데, 그 정도면 엄청난 규모일 듯함 - 우리 프로젝트 중 하나는 12분에서 2분으로 줄었음. 정말 놀라운 변화임
- 우리도 10초에서 1초로 줄었음. 핵심은 Rolldown 덕분임
-
특정 프레임워크에 묶이지 않은 오픈소스 번들링 솔루션을 만든 Vite 팀에게 감사함
(살짝 기침하며 Turbopack 언급) -
멋진 소식임. 하지만 Next.js는 이런 커뮤니티의 성과를 누리지 못할 것 같음
Vercel의 NIH 증후군 때문임- Vercel은 항상 미완성 프리뷰를 몇 년간 운영하는 방식임
Next 13에서 Turbopack 알파를 시작해 Next 16에서야 기본값으로 바꿈
2022년에는 Vite와의 비교 벤치마크도 왜곡됐었음
캐싱 문제, 느린 성능, RSC 보안 취약점, 혼란스러운 앱 라우터, Vercel 외 호스팅의 불편함 등
Next.js 선택은 리스크임
관련 링크: 비교 토론, 캐싱 히스토리, 성능 분석, 보안 CVE, OpenNext - 몇 년 만에 React로 돌아왔는데, Next의 존재 이유를 이해하기 어려움
공식 문서에서도 Next를 기본으로 언급하는 게 이상함
React를 비-SPA로 쓰는 이유가 뭔지 모르겠음 - Next.js는 여러 엔터프라이즈 SaaS 파트너와의 통합 때문에 공식 SDK로 밀어주는 구조임
예: Sitecore Cloud, Sanity, Contentful 등 - 참고로 Cloudflare Vinext도 있음 (직접 써보진 않음)
- Vercel은 항상 미완성 프리뷰를 몇 년간 운영하는 방식임
-
Vite+, Void Cloud, Void Framework 등으로
이제 Vercel과 Void의 대결이 시작될 듯함
특히 PRC(Server Functions) 데모가 흥미로움 — DB부터 UI까지 엔드투엔드 타입 안정성을 보여줌
우리는 Telefunc(tRPC 대안)으로 RPC 설계를 연구 중이며, Void 팀과 협업을 기대함
관련 링크: PRC 데모 영상, Telefunc, Vike- 흥미로운 점은 Vercel이 간접적으로 Void 투자자라는 소문이 있음
Void Cloud는 Cloudflare Workers 위에 구축된 것으로 보이고, 현재 정보는 적음
그래도 Vite+를 MIT 오픈소스로 공개한다는 건 매우 고무적임
Bun이 Anthropic 지원에 집중하느라 OSS에 소홀해지면 경쟁 우위를 잃을 수도 있음
참고: Void Cloud
- 흥미로운 점은 Vercel이 간접적으로 Void 투자자라는 소문이 있음
-
JS 생태계가 혼란스러워도 Vite는 꾸준히 뛰어난 DX와 프로덕션 품질을 보여줌
통합된 Rolldown 번들러로 더 빠르고 유연한 기반이 될 것임
1998년부터 웹 개발을 해온 입장에서 정말 팬임 -
장기 유지보수를 중시해서, 나는 esbuild를 직접 사용함
Vite 같은 래퍼가 내부 변경으로 깨질 때마다 수정하는 게 싫음- 나도 같은 방식으로 esbuild + 간단한 RPC 레이어를 썼음
Zod로 타입 검증을 처리하고, Postgres 타입만 코드 생성함
다음엔 Kysely를 썼을 것 같음 - esbuild는 몇 년이 지나도 깨지지 않은 유일한 JS 툴임
- 다만 아직 코드 스플리팅이 부족함
- Top-level await도 지원 안 하고, 라이브 리로딩이 HMR보다 훨씬 느림
- 나도 같은 방식으로 esbuild + 간단한 RPC 레이어를 썼음
-
tsconfig paths 내장 지원은 정말 좋은 QoL 개선임
설정 중복을 줄일 수 있음- 좋은 소식이지만, Node.js import alias도 시도해볼 만함
프로젝트에 따라 더 단순할 수 있음
- 좋은 소식이지만, Node.js import alias도 시도해볼 만함
사실 JS는 원래 빌드 과정이 필요 없는 언어였음, 브라우저가 그대로 실행할 수 있어야 하고, TypeScript도 타입만 제거하면 바로 실행되도록 설계됐음, 이런 빌드 툴의 존재 자체가 잘못된 방향 같음 -> 이걸 어떻게 해야 정상화 할 수 있을까요;