-
[Vite] 내가 Vite를 사용해야 하는 이유카테고리 없음 2024. 9. 4. 18:12
평소 React로 프로젝트를 진행할 때 가장 많이 사용하는 번들 툴로써 그냥 간단하게 왜 필요한지 사용할 때마다 간단하게 찾아보고 넘어갔던 것 같다. 근데 포트폴리오를 작성하던 중 갑자기 이 Vite라는 것을 내가 왜 사용하는지에 대한 의문에 정확히 답을 못하는 자신을 보고서 사용해야하는 이유 즉 강점에 대해서 한 번 확실하게 분석을 해보고자 생각이 들어서 글을 작성하게 되었다.
💻 Vite의 등장 배경
📦이런 문제점이 있었어요
1. ESM이란 무엇인가?
ES6에서 도입된 모듈 시스템으로 import, export를 사용해서 자바스크립트 파일을 서로 접근하게 해준다.
초기 자바스크립트는 독립적으로 작업을 수행하며, 큰 스크립트가 없었지만 jQuery가 등장하면서 어플리케이션의 규모도 커지고, script파일도 나누고, 파일 간에 변수, 함수 등을 주고 받아야하는 소요가 생김 이러한 복잡해진 구조로 인해서 유지보수가 힘든 문제(전역 오염, 의존성 파악 등등)가 대두되었음. 그렇기에 스코프로 나뉘어 import로 불러올 수 있는 구조의 ES module로 모듈화된 방식으로 Javascrpit를 네이티브 방식으로 처리가 가능해졌다.
2. 번들링이란 무엇인가?
사용자에게 어플리케이션을 제공하기 위해서 여러 코드와 프로그램들을 묶는 행위로 모듈 시스템을 기반으로 브라우저에서 실행 가능한 가장 최적의 파일을 생성하는 과정이다.
각각의 Javascript 파일을 번들링하지 않는다면 브라우저는 각 파일마다 HTTP 요청을 보내 로딩 속도 및 성능에 악영향을 끼치게된다. 번들링은 이러한 여러 파일을 하나로 합쳐 브라우저가 단일 파일을 로드하게 해 HTTP 요청 수를 크게 줄인다.
이러한 번들링은 단순히 파일을 엮는 기능 외에도 다양한 기능을 하는데 이 부분은 참고자료4 [번들링이란?] 를 참고하자
3. 대규모 프로젝트에서의 성능 병목 현상
Webpack과 Rollup과 같은 전통적인 번들러들은 프로젝트의 개발 모드에서도 전체 애플리케이션을 하나로 묶기에 수천 개의 모듈이 존재하는 대규모 프로젝트의 경우 성능 병목 현상이 발생한다.
Vite는 개발 환경에서는 번들링을 아예 하지 않고 브라우저의 네이티브 ESM을 활용하여 파일이 요청될 때만 필요한 모듈을 동적으로 로드하기에 전체 애플리케이션의 번들링하는 과정 없이 개발 서버를 빠르게 실행할 수 있으며, 변경된 모듈에 대해서만 빠르게 업데이트하기에 HMR도 전통적인 번들러에 비해 빠르다.
🐞 정리
어플리케이션의 복잡해지는 구조로 인해 유지보수가 힘들어지기에 모듈 시스템의 도입이 필요해졌다. 다양한 모듈 시스템(CommonJS, AMD..)을 통해 코드를 모듈화하여 관리할 수 있었지만 이는 표준화되고 네이티브한 방식이 아니였고, ESM의 등장 이후 네이티브하게 Javascript 코드를 구조화할 수 있었다.. 이후 모듈로 나눠진 script 파일을 한 번에 묶는 모듈 번들러인 Webpack, Rollup, Parcel을 통해 개발 생산성이 향상되었지만, 대규모 프로젝트의 경우 개발 모드에서 번들링 방식으로 인해 발생하는 성능 병목 현상이 발생하였다.
📦지루할 정도로 길었던 서버 구동
1. Vite의 두 가지 카테고리와 콜드 스타트 방식에서의 서버 구동
외부 라이브러리와 같이 개발 시 내용이 바뀌지 않을 일반적인 소스 코드(Plain) - Dependencies
JSX, CSS, 컴포넌트 등등 컴파일링이 필요하며 수정이 매우 잦은 소스코드(None-plain) - Source codeVite가 개발 환경에서의 여타 번들러에 비해 속도가 빠를 수 있는 이유로 Dependences에 대해서는 사전 번들링을 통해 모든 외부 라이브러리를 미리 번들링하여 ESM 형식으로 변환한다. Source code에 대해서는 번들링하지 않고 브라우저에서 요청될 때 Vite가 해당 모듈을 동적으로 제공하기에 빠른 개발 서버 실행이 가능하다,
2. 사전 번들링이란?
사전 번들링: 처음 Vite를 실행할 때, 자동으로 진행되는 과정으로 CommonJS와 UMD 모듈을 ESM으로 가져오고 여러 디펜던시가 존재하는 ESM 모듈을 하나의 모듈로 변환하여 HTTP 요청을 줄이는 과정
모든 번들러가 사전 번들링을 필수적으로 제공하지 않지만 Vite는 의존성 및 소스코드 관리에 있어서 사전 번들링 기능을 활용한다.
3. EsBuild를 사용하는 Vite
Esbuild: Vite가 사전 번들링 시에 사용하는모듈 번들러이자 Javascript 빌드 도구로 매우 빠르다.
출처: esbuild 공식 홈페이지 🐞 정리
콜드 스타트 방식에서의 서버 구동이 빠른 이유는 사전번들링을 통해서 의존성을 관리하고 소스 코드를 브라우저의 요청이 있을 때 동적으로 제공하기에 전체를 번들링을 해야하는 전통적인 번들러에 비해 빠르게 개발 환경을 제공할 수 있다.
출처: Vite 공식 홈페이지
📦느렸던 소스 코드 갱신
1. HMR이 명확한 해답이 아닌 이유?
코드의 일부를 수정해도 변경된 모듈만을 즉시 반영하는 기술
전통적인 번들러들은 모듈 간의 의존성을 관리하며 HMR 시에도 이러한 관계를 유지하기에 특정 모듈의 변경 시 그와 관련된 많은 모듈들을 다시 로드해야하는 상황이 발생하여 의도와는 다르게 작동할 수 있기에 전통적인 HMR 방식은 의도대로 명확히 동작하지 않는다.
🐞 정리
소스 코드 갱신에 있어 번들러가 아닌 ESM을 이용하여 수정된 모듈 부분만 교체가 가능하기에 Vite의 HMR은 전통적인 번들러들에게서 발생하는 이슈를 해결할 수 있어 매우 빠른 속도를 제공한다.
📦그 외 내용1. 배포 시 번들링 과정이 필요한 이유?
기본적으로 ESM에서 대부분의 환경이 지원되지만 프로덕션 환경에서 최적의 로딩 성능을 얻기 위해서는 트리셰이킹, 지연 로딩 및 청크 파일 분할(코드 스플리팅)을 이용하여 번들링하는 것이 좋다.
2. 번들링 시에는 왜 EsBuild를 사용하지 않나요?
Vite는 번들링 시에 Rollup을 사용하여 번들링하며 이는 Rollup이 가지고 있는 유연한 플러그인 API 및 인프라의 영향을 받아 선정하였다.
🐞 정리
소스 코드 갱신에 있어 번들러가 아닌 ESM을 이용하여 수정된 모듈 부분만 교체가 가능하기에 Vite의 HMR은 전통적인 번들러들에게서 발생하는 이슈를 해결할 수 있어 매우 빠른 속도를 제공한다.
📖 마무리
장점을 알기 위해서는 이에 대한 등장 배경을 아는 것만큼 좋은 게 없는 것 같다.
Vite가 여타 번들러들과의 다른 점을 알 수 있었고, Vite는 ESM을 온전하게 사용하는 좋은 도구라는 생각이 들었다.
아래 글까지 보지 않았더라면 Vite는 Esbuild만을 사전 번들링 단계에서 사용하고 나머지는 최대한 ESM을 사용한다고 느꼈겠지만 글 하단에 Rollup을 통해 번들링하며, 트리셰이킹과 코드 스플리팅 등등 프로덕트 환경에서의 성능을 잡기 위해서는 단순하게 ESM만을 이용하기엔 무리가 있겠다는 생각도 들었다.
이렇게 한 번 공부했으니 이걸로 면접 질문 한 번 받겠지!! ChatGPT 참 많이 물어봤다.📌 Reference