7. Vite — 개발 서버와 빌드의 분리

Vite는 번들러가 아니라 “개발 서버 + 빌드 명령”의 묶음이다 — 이 구분이 이해의 열쇠다

이 장에서 처음 나오는 말4개

개발 서버Dev Server

pnpm dev로 뜨는 로컬 서버. 코드를 고치면 즉시 반영해 주는, 개발 중에만 쓰는 서버다. 배포물과는 별개다.

HMRHot Module Replacement

코드 수정 시 페이지 전체를 새로고침하지 않고 바뀐 모듈만 갈아 끼우는 것. 입력하던 폼, 열어 둔 모달이 유지된 채 화면만 바뀐다.

네이티브 ESMNative ES Modules

브라우저가 import를 직접 이해하고 필요한 파일을 스스로 요청하는 것. 2018년 이후 모든 주요 브라우저가 지원한다 — Vite의 발상이 성립하는 전제다.

Rolldown

Rust로 만든 차세대 번들러. Vite 8(2026년 3월)부터 기본 번들러가 됐다.

Vite 이전 — dev 서버가 느렸던 이유

webpack 시절의 dev 서버는 시작하려면 일단 전부 번들해야 했다.

프로젝트가 크면 dev 한 번에 수십 초~분 단위. 수정 반영도 느려졌다. 개발 중에는 어차피 지금 보는 화면의 모듈만 필요한데, 전체를 묶고 있었던 것이다.

Vite의 발상 — dev에선 번들하지 않는다

Vite(프랑스어로 “빠르다”, “비트”라 읽는다)는 순서를 뒤집었다. 서버를 먼저 띄우고, 브라우저의 네이티브 ESM이 import를 따라 파일을 요청하면 그 파일만 그때 변환해서 준다.

• 시작이 빠르다 — 전체 앱 번들을 먼저 만들지 않고 요청된 모듈을 중심으로 처리한다
• HMR이 빠르다 — 파일 하나를 고치면 그 모듈만 갈아 끼운다. 전체 재번들이 없다
• 의존성은 예외적으로 최적화한다 — node_modules의 패키지는 파일 수가 많고 CJS(4장)가 섞여 있어, Rolldown 기반 파이프라인이 사전 처리해 캐시한다. 첫 실행이 잠깐 걸릴 수 있는 이유다

그리고 배포용 빌드(vite build)는 6장의 결론대로 제대로 묶는다 — 트리셰이킹·미니파이·코드 스플리팅 전부. dev와 build가 서로 다른 전략을 쓰는 게 Vite의 정체다.

핵심

dev = 안 묶고 즉석 변환(빠른 피드백), build = 묶고 다이어트(빠른 서비스). Vite는 이 두 얼굴의 묶음이고, vite.config.ts 하나로 양쪽을 설정한다.

Vite 8 — 두 얼굴의 통합

두 얼굴에는 부작용이 있었다 — dev(esbuild)와 build(Rollup)가 다른 엔진이라 가끔 “dev에선 됐는데 build에서 깨지는” 불일치가 났다.

Vite 8(2026년 3월)이 이걸 정리했다. Rust로 만든 번들러 Rolldown이 dev와 build를 모두 담당하는 단일 엔진이 됐다 —

• 빌드 속도가 프로젝트에 따라 수 배~수십 배 빨라졌다
• dev/build 불일치의 큰 원인 하나였던 서로 다른 번들러가 사라졌다
• 모듈 단위 캐시, 유연한 청크 분할 같은 기능이 단일 엔진 위에서 가능해졌다

기존 설정과 플러그인은 호환 계층 덕분에 대부분 그대로 돈다. 다만 dev는 여전히 요청 기반, build는 번들 기반이라 환경 변수·청크·플러그인 훅 차이까지 전부 사라진 것은 아니다.

왜 다들 Vite 위에 있는가

Vite는 프레임워크가 아니지만, 프레임워크들이 그 위에 집을 짓는다.

Vite 위에 있는 것	무엇인가
Astro	콘텐츠 사이트 프레임워크 — 지금 읽는 이 사이트
SvelteKit / Nuxt / SolidStart	각 UI 라이브러리의 메타 프레임워크
React Router (구 Remix)	React 메타 프레임워크
Vitest	Vite 설정을 그대로 쓰는 테스트 러너 (8장)
Storybook, Tauri, …	컴포넌트 개발 환경, 데스크톱 앱 — 계속 는다

이유는 단순하다 — 라우팅과 서버 렌더링은 프레임워크마다 다르지만, “TS·JSX를 변환하고, dev 서버를 띄우고, 배포용을 묶는” 일은 전부 같다. 그 공통 기반을 Vite가 표준화했고, 프레임워크는 자기 고유 가치에만 집중하게 됐다. 예외는 Next.js다 — 자체 번들러 Turbopack으로 같은 문제를 따로 푼다.

손으로 확인하기

프로젝트 만들기

pnpm create vite my-app       # 프레임워크·TS 여부를 물어본다
cd my-app && pnpm install
pnpm dev                      # 뜨는 속도를 체감해 본다

React를 골랐다면 이게 3장의 “조합 ② 사내 도구”의 뼈대다.

dev — 안 묶는 것 보기

dev 서버를 띄운 채 DevTools Network 탭을 열면 —

localhost:5173/
├── /src/main.tsx          ← 소스 파일이 낱개로 온다
├── /src/App.tsx           ← 확장자는 tsx인데 내용은 변환된 JS
└── /node_modules/.vite/deps/react.js   ← 사전 번들된 의존성

번들이 없다. 소스 구조가 요청 목록에 그대로 보인다.

build — 묶는 것 보기

pnpm build && ls dist/assets
# index-D3xK9f2a.js    ← 전부 하나로 묶이고 미니파이됨
# index-B7pQ1x0c.css

파일명의 해시(D3xK9f2a)는 내용이 바뀌면 같이 바뀐다 — HTML은 짧게 캐시하고 해시 자산에는 긴 immutable 캐시를 주는 배포 전략이 가능해진다.

함정

dev에서만 확인하고 배포하지 않는다. dev와 build는 전략이 다른 만큼 환경 변수 처리, 코드 스플리팅 경계 등에서 차이가 날 수 있다. 배포 전 pnpm build && pnpm preview(빌드 결과물을 로컬 서빙)로 한 번 확인하는 습관이 이 간극을 막는다.

7장 요약

• Vite의 정체 — dev 서버(안 묶고 즉석 변환) + build 명령(묶고 다이어트)의 묶음
• 발상의 핵심: 브라우저의 네이티브 ESM에 모듈 해석을 맡기고, 요청된 파일만 그때 변환한다
• Vite 8부터 Rolldown(Rust)이 단일 번들러 — 더 빠르고, dev/build 불일치의 원인 하나가 줄었다
• Astro·SvelteKit·Vitest가 전부 Vite 위에 있다 — 공통 기반의 표준화. 예외는 Next.js(Turbopack)
• 배포 전 pnpm preview로 build 결과물을 확인하는 습관을 들인다

참고 자료

• Vite 8 발표 — Rolldown 통합, 성능 범위, 호환 계층과 남은 실험 기능
• Vite 8 마이그레이션 가이드 — esbuild·Rollup에서 Rolldown·Oxc로 바뀐 범위

8. 품질 도구 — 타입 · 린트 · 포맷 · 테스트사람이 안 봐도 잡히게 만드는 네 겹의 그물.