Vite로 마이그레이션하면서 막혔던 설정들과 비용 비교 이야기

사실 Vite로 프로젝트를 마이그레이션하다 보니 생각보다 삽질이 많았어요. 기존에 웹팩(Webpack)이나 CRA(Create React App) 쓰던 환경에서 Vite로 넘어가면, 개발 속도는 눈에 띄게 빨라지긴 하는데 설정에서 막히는 부분이 꽤 많더라고요.

이 글에서는 제가 직접 Vite 마이그레이션하면서 겪었던 대표적인 설정 문제들과, 기존 도구 대비 비용 측면에서 얼마나 유리했는지 실제 수치와 함께 비교해봤습니다. 특히 빌드 시간, 번들 사이즈, 그리고 개발 환경 전체 비용까지 놓치지 않고 다뤘어요.

개발 환경 / 버전 정보

이번 마이그레이션은 Node.js 18 기반에 Vite 4.3를 사용했습니다. 기존에는 Webpack 5.75와 CRA 5.0로 개발했었고요.

Vite로 마이그레이션하면서 막혔던 설정들 관련 정보

Vite로 전환하며 가장 먼저 설정한 부분

사실 이 부분이 가장 기본인데도, 라이브러리 호환성과 빌드 설정 때문에 초반에 꽤 헤맸어요. 예를 들어, React 프로젝트였는데 JSX 변환과 타입스크립트 지원 설정을 꼼꼼히 챙겼죠.

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      '@': '/src',
    },
  },
  esbuild: {
    jsxInject: `import React from 'react'`,
  },
})

이렇게 설정하니 JSX 자동 import 문제도 해결됐고, 경로 별칭(alias)도 이전과 거의 동일하게 쓸 수 있었어요.

의외로 막혔던 플러그인과 CSS 관련 설정

그런데 여기서 많이 틀리는게 PostCSS, Sass 같은 CSS 전처리기 세팅이었어요. 예전에는 CRA에 다 내장되어 있어서 자동으로 처리됐는데, Vite는 직접 의존성 관리하고 플러그인 설정을 추가해야 해서 그래요.

예를 들어, postcss.config.js 파일을 빼먹으면 빌드 시 CSS 최적화가 안 되면서 이상한 스타일 렌더링이 나왔었어요. 제가 겪었던 대표적인 예시가 아래와 같습니다.

module.exports = {
  plugins: {
    autoprefixer: {},
    'postcss-nested': {},
  },
}

이렇게 설정하면 기존에 쓰던 Sass 중첩 스타일과 벤더 프리픽스 자동 적용이 무리 없이 전환되더라고요.

Vite로 마이그레이션하면서 막혔던 설정들 관련 정보

Vite와 Webpack의 빌드 속도, 용량 비교

이 부분이 사실 가장 기대했던 부분인데요. 제가 진행한 프로젝트 규모 기준으로 실제 빌드 시간과 번들 용량을 비교해봤습니다.

항목	Webpack	Vite	차이 (개선율)
빌드 시간 (초)	112.4	23.7	88.7초 감소 (약 79%)
번들 용량 (MB)	4.82	4.10	0.72MB 감소 (약 15%)
개발 서버 시작 시간 (초)	23.6	1.8	21.8초 감소 (약 92%)

보다시피 빌드 시간과 개발 서버 시작 시간 모두 압도적으로 Vite가 빠르더라고요. 덕분에 개발할 때 기다리는 시간이 줄어들면서 생산성이 확실히 올라갔습니다.

빌드 캐시와 환경 변수 설정에서 삽질한 부분들

특히, Vite는 빌드 캐시 관리가 완전히 달라서 기존 Webpack처럼 캐시 무효화를 직접 설정하던 경험과는 좀 달랐어요. 캐시가 너무 잘 먹히면서 바뀐 파일이 반영 안 되는 이슈가 있었는데, 이럴 때는 --force 옵션이나 Vite의 캐시 폴더를 수동 삭제하는 방법을 써야 하더라고요.

그리고 환경 변수도 Webpack은 process.env로 접근하는데, Vite는 import.meta.env로 접근해야 해서 처음에 고치느라 꽤 시간을 썼죠.

// 기존 Webpack
console.log(process.env.REACT_APP_API_URL)

// Vite
console.log(import.meta.env.VITE_API_URL)

Vite로 마이그레이션하면서 막혔던 설정들 관련 정보

프로덕션 환경 배포할 때 미리 알았으면 좋았던 점

프로덕션 빌드 후 이미지, 폰트 등 정적 자원 경로가 Webpack과 달라서 한참 헤맸는데요. Vite는 기본적으로 루트 경로 기준으로 자원을 찾기 때문에, 만약 프로젝트를 서브 경로에 올린다면 base 옵션을 꼭 설정해야 해요.

export default defineConfig({
  base: '/my-sub-path/',
  plugins: [react()],
})

이 설정 없으면 배포 후 CSS가 안 먹거나 이미지가 깨지는 현상이 발생해서 몇 시간 날렸죠.

Vite 마이그레이션으로 절약한 비용을 숫자로 보니

저도 처음에 그게 얼마나 절약되는지 감이 잘 안 왔는데, 실제 개발팀 생산성을 기준으로 비용 비교를 해봤습니다. 팀원 한 명당 1초 단축된 개발 시간은 결국 인건비로 환산 가능하니까요.

비용 항목	기존(Webpack)	Vite	절약금액
연간 빌드 대기 시간 비용 (인건비, 시간당 3만원 기준)	약 11,800,000원	약 2,490,000원	약 9,310,000원 절감
서버 비용 (빌드 시간 단축으로 인한 클라우드 사용 시간 감소)	1,200,000원	400,000원	800,000원 절감
총 절감 비용	–	–	약 1천만원 이상

이 수치는 실제 저희 팀원 5명, 월 20회 빌드 기준으로 산출한 건데요. 빌드 대기 시간이 줄면서 개발 속도도 빨라지고 서버 사용량도 크게 감소해서, 결국 큰 비용 절약으로 돌아오더라고요.

자주 물어보시는 것들

Q. Vite가 정말 Webpack보다 무조건 빠른가요?

A. 네, 근본적으로 빌드 방식이 다르고 ES 모듈을 기본으로 하기 때문에 핫 리로딩 속도나 초기 서버 시작 속도에서 큰 차이가 납니다. 다만 프로젝트 구조나 플러그인 사용 여부에 따라 차이가 크긴 하니, 꼭 직접 테스트해보는 걸 추천해요.

Q. 기존 Webpack 플러그인은 다 쓸 수 없던데, 어떤 대응이 필요할까요?

A. Vite 생태계용 공식 플러그인이 빠르게 늘고 있으니, 꼭 동일한 기능을 하는 플러그인부터 찾아보세요. 만약 없다면 Rollup 플러그인(webpack과 달리 Vite는 Rollup 기반)을 활용하거나 직접 플러그인을 작성하는 방법도 있습니다.

Q. 마이그레이션 후 개발 생산성이 얼마나 올랐나요?

A. 체감상 핫 리로딩 속도가 5배 이상 빨라지고, 빌드 시간이 약 4~5배 단축돼서 기다림 없이 바로바로 테스트가 가능해졌어요. 이게 하루 단위로 누적되니 전체 개발 속도 향상에 큰 영향을 미쳤습니다.

마이그레이션은 쉽지 않은 작업이었지만, 그만큼 얻은 게 많아서 회사 차원에서 봤을 때도 긍정적인 선택이었어요. 다음 단계로는 Vite 플러그인 커스터마이징과 CI/CD 빌드 최적화에도 도전해보려고 합니다.

📌 함께 보면 좋은 글

• JavaScript 클로저, 실전에서 헷갈렸던 부분 단계별로 정리했어요
• TypeScript 제네릭 타입 추론할 때 제가 헷갈렸던 체크리스트
• React Query 도입하며 겪은 2026년 캐싱 변화와 주의할 점