Vite를 사용하는 이유

 

 

오늘은 Vite에 대해 이야기해보려고 한다.

 

 

 

✅ 왜 Vite를 사용해야 할까?

우선, 기존 개발 환경의 문제점부터 알아보자.

 

번들링의 등장과 한계

 

브라우저에서 ES Modules을 지원하기 전까지, JavaScript 코드는 모듈화를 브라우저 레벨에서 직접 수행할 수 없었다. 그래서 등장한 개념이 바로 번들링(Bundling)이다.

 

Webpack, Rollup, Parcel 같은 도구들이 이 번들링 도구들의 대표적인 예시인데, 이것들은 개발자의 생산성을 높이는데 기여하긴 했지만 애플리케이션 규모가 커질수록 새로운 문제가 발생하기 시작했다...!

 

🔍 1. 모듈의 개수 증가

모두가 느끼듯이 요즘의 웹은 꽤나 복잡하고 많은 기능을 수행하고 있다. 이런 복잡한 웹을 만들다 보면, 하나의 코드로 보기 힘들기 때문에 코드를 여러 개의 작은 파일로 나누는 것이 일반적인데, 이를 모듈화라고 부른다.

 

<모듈화의 장점>

1. 코드 재사용성
   한 번 만든 모듈은 여러 곳에서 재사용할 수 있다. 예를 들어, 버튼을 눌렀을 때 특정 이벤트가 작동하는 코드를 하나만 작성해두어도 여러 곳에서 쓰일 수있다는 것!
2. 코드 가독성 향상
   하나의 큰 파일로 작성된 코드보다, 기능별로 나뉜 모듈은 읽고 관리하기 쉽다. 여러분도 JAVASCRIPT.INFO 글이 카테고리로 안 나누어져 있고 하나의 페이지에 모두 담겨있다면 부분별로 읽기도 힘들고, 코드에 적용시켜보기도 힘든 것 처럼...!
3. 협업에 용이
   팀원이 각각 다른 모듈을 작업할 수 있으므로 협업도 편리해진다!

그러나!

프로젝트가 점점 커지면 모듈의 개수가 수백, 심지어 수천 개에 이를 수 있다.....🤮

• 예를 들어, 컴포넌트 라이브러리를 사용하는 React 프로젝트만 생각해 봐도 페이지별 컴포넌트, 상태 관리 로직, 유틸리티 함수 등으로 모듈의 양이 금방 불어나는 것 처럼..

이처럼 모듈의 개수가 많아지면, 번들러는 이 모든 파일을 읽고 처리하는 데 많은 시간과 리소스를 소모하게 된다.

 

 

 

 

🔍 2. 성능 병목 현상

(1) 개발 서버 구동 속도

번들러(Webpack, Parcel 등)는 웹을 실행하기 전에 모든 모듈을 읽고, 분석하고, 번들링한다. = 프로젝트가 커질수록 첫 번째 서버 실행 속도가 느려진다.

 

왜냐하면 서버를 처음 실행할 때는 번들러가 모든 작업(탐색, 분석, 최적화)을 처음부터 끝까지 처리하기 때문이다. 처음이 아닌 이후 코드를 수정 할 땐 수정된 파일만 재처리하면 되지만, 처음에는 모든 작업이 돌아가기 때문...!

 

만약 팀 프로젝트에서 매일 서버를 여러 번 재시작해야 한다면...? 기다리다 지치고... 생산성에 큰 영향을 미치게 된다...

 

 

 

(2) 코드 수정 후 반영 속도

코드를 수정하면 개발 서버는 수정된 내용을 즉각적으로 브라우저에 반영해줘야한다. 이를 HMR(Hot Module Replacement)라고 부르는데, HMR은 번들러가 아래 작업을 수행하며 적용된다.

1. 수정된 파일 감지: 수정된 파일을 탐지.
2. 재번들링: 이 파일이 다른 모듈과 연결된 경우, 관련된 모든 모듈을 다시 번들링.
3. 브라우저로 전송: 새로 번들링된 결과물을 브라우저에 전달해 변경 사항을 반영.

프로젝트가 작을 때는 이 과정이 빠르게 끝나지만, 대규모 프로젝트에서는 수정된 코드와 연결된 모듈이 많아질수록 재번들링 속도가 기하급수적으로 느려진다..

 

버튼 스타일을 살짝 바꿨을 뿐인데, 변경 사항이 브라우저에 반영되는 데 10초 이상 걸린다면...? 이는 개발자의 인내심을 시험하는 일이 되겠죠....?

 

 

🔍3. 개발자 스트레스 증가

결국 모듈의 개수 증가와 번들링 병목 현상이 맞물리면서 개발자가 느끼는 대기 시간은 크게 늘어난다.

이는 '개발자의 스트레스 증가' 라는 아주 큰 문제로 돌아오게 된다.

번들링만 10초 걸리는 웹을 보는 FE 개발자의 뇌

 

 

 

 

 

✅ 이 때, 마법같이 Vite 등장...!

Vite는 위 문제들을 해결하기 위해 등장했다...!

 

1. 빠른 서버 구동

Vite는 모듈을 크게 두 가지로 나눠서 처리한다.

 

1️⃣ Dependencies (외부 라이브러리)

 

React, Lodash 같은 라이브러리들을 Vite는 Esbuild라는 도구를 사용해 외부 라이브러리를 미리 번들링해둔다. Esbuild는 이 전의 방식보다 훨씬 빠르다...! 최대 100배 더 빠르다고 할 정도!!

 

2️⃣ Source Code (내가 작성하는 코드)

 

개발자가 직접 작성한 코드! 즉, 우리가 자주 수정하고 실시간으로 확인하고 싶은 부분을 Vite는 Native ESM (모듈 시스템)을 이용하여 브라우저가 필요한 파일만 그때그때 요청해서 가져간다. Vite는 이 과정에서 필요한 최소한의 코드 변환만 해주기 때문에 좀 더 빠른 서버 구동이 가능한 것이다!

 

출처 : Vite 공식 info

 

 

 

 

2. 빠른 코드 갱신

기존 번들러에서는 위에서 설명한 내용과 같이, 코드 수정 시 전체 웹의 번들링 과정을 다시 거쳐야 했다. 이 과정은 프로젝트 규모에 따라 매우 오래걸리기도 했었다.

 

하지만 Vite는???

• 수정된 모듈만 교체
• 관련된 부분만 브라우저에 전달
• 브라우저는 수정된 모듈을 다시 요청

위와 같이 똑똑하고 효율적으로 ESM 기반으로 모든 과정이루어진다. 때문에 애플리케이션이 아무리 커져도 HMR 속도가 느려지지는 않게 된다.

 

 

✅ 배포 환경에서 번들링은 왜 필요한가?

Vite는 개발 중에는 번들링을 건너뛴다. 그 대신 필요한 파일만 즉시 브라우저로 내보내기 때문에 개발 속도가 빠른 거다.

 

하지만 배포할 때는 번들링이 꼭 필요하다...! 왜냐하면

 

1️⃣ 네트워크 통신을 줄여야 함

 

배포된 사이트에서 파일이 번들링되지 않으면 브라우저가 각각의 import를 전부 요청해야 한다.

 

예를 들어, 파일 1에서 파일 2, 파일 3, ... 식으로 중첩된 import가 많으면 요청 수도 기하급수적으로 늘어난다.

네트워크 요청이 많아지면 당연히 페이지 로딩 속도가 느려지겠죠?

 

그렇기 때문에 번들링을 통해 파일을 하나로 묶어서 네트워크 요청 수를 줄이는거다!

브라우저는 한 번에 큰 파일 하나만 받아오면 끝!!

 

2️⃣ 최적화

 

우리가 작성한 코드에는 실제로 사용하지 않는 부분도 있을 수 있다. 이런 불필요한 코드는 페이지를 느리게 한다.

그렇기 때문에 아래 두 가지의 방법으로 최적화 시켜주는 것이 좋다.

• 트리 셰이킹(Tree Shaking): 사용하지 않는 코드를 자동으로 제거한다.
• 코드 스플리팅(Code Splitting): 필요한 부분만 여러 작은 파일로 나눠서, 사용자가 필요할 때만 가져오게 한다.

이렇게 하면 최소한의 코드로 효율적으로 작동하게된다. 이게 바로 최적화~

 

✅ 왜 Vite인가? 정리

 

마지막으로 왜 Vite를 사용하는지를 간단하게 정리해보자면 아래와 같다.

 

1️⃣ 빠른 속도

• Vite는 Esbuild와 Native ESM 덕분에 엄청 빠르게 동작한다.
• 특히 개발 중에 페이지를 새로고침할 때 속도 차이가...!

2️⃣ 생산성 향상

• 번들링 없이 필요한 파일만 처리하니까, 개발 중에는 기다릴 필요가 없다.
• 작업할 때 개발자의 스트레스 감소 효과.

3️⃣ HMR (Hot Module Replacement)

• HMR은 코드 수정 후 바로 결과를 확인할 수 있게 해주는 기능인데, Vite는 큰 프로젝트에서도 HMR이 빠르고 즉각적이다.

 

 

 

 

 

 

 

---

[참고]

 

Vite

 

 

 

 

 

 

 

 

 

썸네일