# Vite 8.0 출시

> Clean Markdown view of GeekNews topic #27485. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27485](https://news.hada.io/topic?id=27485)
- GeekNews Markdown: [https://news.hada.io/topic/27485.md](https://news.hada.io/topic/27485.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-14T09:53:40+09:00
- Updated: 2026-03-14T09:53:40+09:00
- Original source: [vite.dev](https://vite.dev/blog/announcing-vite8)
- Points: 13
- Comments: 5

## Summary

**Vite 8.0**은 기존 *esbuild + Rollup* 이중 구조를 **Rust 기반 번들러 Rolldown**으로 통합해 빌드 속도를 최대 30배까지 끌어올렸습니다. Rolldown은 Rollup과 동일한 플러그인 API를 유지하면서도 모듈 캐싱과 유연한 청크 분할 등 고급 기능을 지원합니다. 또한 새 **플러그인 레지스트리**와 **Vite Devtools**, **TypeScript 경로 자동 해석** 등 개발 편의 기능이 추가되어, Vite 생태계가 하나의 통합 툴체인으로 진화하는 기반을 마련했습니다.

## Topic Body

- 기존 **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로 업그레이드  
- 세부 절차는 공식 **Migration Guide**와 **Changelog**에서 확인 가능  
  
### Rollup과 esbuild에 대한 감사  
- **Rollup**은 Vite의 플러그인 생태계 기반을 제공했으며, Rolldown이 그 API를 계승  
- **esbuild**는 빠른 개발 경험을 가능케 한 핵심 기술로, Rust·Go 기반 툴링 발전의 계기가 됨  
- 두 프로젝트의 기여가 **Vite의 DNA에 깊이 내재**되어 있음  
  
### 커뮤니티와 협력  
- Vite 8 개발은 **sapphi-red와 Vite 팀**, **Rolldown 팀**, 그리고 수많은 커뮤니티 기여자들의 협력으로 완성  
- **VoidZero**, **Bolt**, **NuxtLabs**가 주요 파트너로 참여 함

## Comments



### Comment 52994

- Author: neo
- Created: 2026-03-14T09:53:40+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47360730) 
- 업계가 “빌드는 원래 오래 걸리는 것”이라며 아무 의심 없이 써온 **비효율적인 툴들**에 얼마나 많은 컴퓨팅 자원을 낭비했는지 새삼 생각하게 됨  
  우리는 그 느린 빌드에 맞춰 일정을 짜고, 휴식 시간을 농담처럼 만들고, 캐시 레이어까지 구축했음  
  Vite 유지보수자들에게 찬사를 보냄
  - 느린 JS 번들로 낭비된 자원보다, **비효율적인 런타임과 추상화**로 낭비된 비용이 훨씬 큼  
    대부분의 프로덕션 소프트웨어는 필요한 것보다 수십 배 느림  
    Electron 앱들이 수 GB의 RAM을 쓰면서도 40년 전 소프트웨어보다 더 버벅이는 현실이 그 증거임
  - 나도 같은 생각을 함. ESLint나 Prettier 같은 툴도 [Oxc](https://oxc.rs/)를 알고 나니 비슷한 낭비처럼 느껴짐
  - 앞으로 **행렬 곱셈**에서도 이런 낭비를 되돌아보게 될 날이 올 것 같음
  - 빌드 성능은 오래전부터 내 관심사였음  
    14년 전, 빌드 기다리며 낭비되는 시간을 깨닫고 특히 **Java 생태계**에서 이 문제가 심각하다고 느낌  
    예전에 Ruby 프로젝트에서 통합 테스트가 매번 DB를 새로 만드는 데 10분씩 걸렸음  
    Kotlin/Spring Boot도 컴파일이 느리고, Rust 컴파일러도 빠르진 않음  
    하지만 테스트는 우리가 통제할 수 있음. 단위 테스트는 밀리초 단위로 끝나야 하고, 통합 테스트는 병렬화와 데이터 랜덤화를 통해 큰 개선이 가능함  
    나는 MacBook Pro에서 Redis, DB, Elasticsearch를 포함한 수백 개의 스프링 통합 테스트를 40초 안에 돌림  
    이런 세팅을 한 번 해두면 **빠른 피드백 루프**가 생기고, 개발의 즐거움이 돌아옴  

- 내가 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](https://rolldown.rs/) 덕분임  
    Vite에 통합되기 전부터 써왔는데 정말 훌륭함
  - 4분이라니, 앱 규모가 얼마나 큰지 궁금함  
    Next보다 빠르다고들 하는데, 그 정도면 엄청난 규모일 듯함
  - 우리 프로젝트 중 하나는 12분에서 2분으로 줄었음. 정말 놀라운 변화임

- 특정 프레임워크에 묶이지 않은 **오픈소스 번들링 솔루션**을 만든 Vite 팀에게 감사함  
  (살짝 기침하며 Turbopack 언급)

- 멋진 소식임. 하지만 Next.js는 이런 커뮤니티의 성과를 누리지 못할 것 같음  
  **Vercel의 NIH 증후군** 때문임
  - Vercel은 항상 **미완성 프리뷰를 몇 년간 운영**하는 방식임  
    Next 13에서 Turbopack 알파를 시작해 Next 16에서야 기본값으로 바꿈  
    2022년에는 Vite와의 비교 벤치마크도 왜곡됐었음  
    캐싱 문제, 느린 성능, RSC 보안 취약점, 혼란스러운 앱 라우터, Vercel 외 호스팅의 불편함 등  
    Next.js 선택은 **리스크**임  
    관련 링크: [비교 토론](https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussions/8), [캐싱 히스토리](https://nextjs.org/blog/our-journey-with-caching), [성능 분석](https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rendered-nextjs-site-handle), [보안 CVE](https://nextjs.org/blog/CVE-2025-66478), [OpenNext](https://opennext.js.org/)
  - 몇 년 만에 React로 돌아왔는데, Next의 존재 이유를 이해하기 어려움  
    공식 문서에서도 Next를 기본으로 언급하는 게 이상함  
    React를 **비-SPA**로 쓰는 이유가 뭔지 모르겠음
  - Next.js는 여러 **엔터프라이즈 SaaS 파트너**와의 통합 때문에 공식 SDK로 밀어주는 구조임  
    예: Sitecore Cloud, Sanity, Contentful 등
  - 참고로 [Cloudflare Vinext](https://github.com/cloudflare/vinext)도 있음 (직접 써보진 않음)

- **Vite+**, **Void Cloud**, **Void Framework** 등으로  
  이제 Vercel과 Void의 대결이 시작될 듯함  
  특히 PRC(Server Functions) 데모가 흥미로움 — DB부터 UI까지 **엔드투엔드 타입 안정성**을 보여줌  
  우리는 Telefunc(tRPC 대안)으로 RPC 설계를 연구 중이며, Void 팀과 협업을 기대함  
  관련 링크: [PRC 데모 영상](https://www.youtube.com/watch?v=BX0Xv73kXNk), [Telefunc](https://telefunc.com), [Vike](https://vike.dev)
  - 흥미로운 점은 Vercel이 **간접적으로 Void 투자자**라는 소문이 있음  
    Void Cloud는 Cloudflare Workers 위에 구축된 것으로 보이고, 현재 정보는 적음  
    그래도 **Vite+를 MIT 오픈소스로 공개**한다는 건 매우 고무적임  
    Bun이 Anthropic 지원에 집중하느라 OSS에 소홀해지면 경쟁 우위를 잃을 수도 있음  
    참고: [Void Cloud](https://void.cloud/)

- JS 생태계가 혼란스러워도 **Vite는 꾸준히 뛰어난 DX와 프로덕션 품질**을 보여줌  
  통합된 Rolldown 번들러로 더 빠르고 유연한 기반이 될 것임  
  1998년부터 웹 개발을 해온 입장에서 정말 팬임

- 장기 유지보수를 중시해서, 나는 **esbuild를 직접 사용**함  
  Vite 같은 래퍼가 내부 변경으로 깨질 때마다 수정하는 게 싫음
  - 나도 같은 방식으로 **esbuild + 간단한 RPC 레이어**를 썼음  
    Zod로 타입 검증을 처리하고, Postgres 타입만 코드 생성함  
    다음엔 Kysely를 썼을 것 같음
  - esbuild는 몇 년이 지나도 **깨지지 않은 유일한 JS 툴**임
  - 다만 아직 **코드 스플리팅**이 부족함
  - **Top-level await**도 지원 안 하고, 라이브 리로딩이 HMR보다 훨씬 느림

- **tsconfig paths 내장 지원**은 정말 좋은 **QoL 개선**임  
  설정 중복을 줄일 수 있음
  - 좋은 소식이지만, **Node.js import alias**도 시도해볼 만함  
    프로젝트에 따라 더 단순할 수 있음

### Comment 52998

- Author: aer0700
- Created: 2026-03-14T12:56:33+09:00
- Points: 2
- Parent comment: 52994
- Depth: 1

사실 JS는 원래 빌드 과정이 필요 없는 언어였음, 브라우저가 그대로 실행할 수 있어야 하고, TypeScript도 타입만 제거하면 바로 실행되도록 설계됐음, 이런 빌드 툴의 존재 자체가 잘못된 방향 같음 -> 이걸 어떻게 해야 정상화 할 수 있을까요;

### Comment 53228

- Author: carnoxen
- Created: 2026-03-17T16:21:27+09:00
- Points: 1
- Parent comment: 52998
- Depth: 2

브라우저에서만 돌리던 걸 서버에서 직접 돌리게 되었으니 어쩔 수 없는 수순인 것 같아요

### Comment 53043

- Author: ahiou
- Created: 2026-03-15T11:29:24+09:00
- Points: 1
- Parent comment: 52998
- Depth: 2

저는 웹앱이 고도화되면서 생긴 자연스러운 현상이라고 생각합니다

### Comment 53009

- Author: savvykang
- Created: 2026-03-14T14:30:34+09:00
- Points: 1
- Parent comment: 52998
- Depth: 2

아마 플래시 버리듯 브라우저 JS를 버려야 하지 않을까요? 그런데 JS는 버릴 기미가 안 보입니다