Vite란 무엇일까? (이론)

 

 프로젝트를 할 당시 한 팀원이 Vite란 build 도구를 가져왔다. 이게 뭔지 몰라서, 왜 쓰는 거냐고 물어봤었는데 배포할 때 빨라진다고 들었었다. 그땐 개발이 너무 힘들어서 그렇구나 하고 넘어갔는데, 내 프로젝트에 활용되었으니 어떤건지 정확히 알아봐야 할 거 같아서 정리를 해보고자 한다. 

 그리고 최근, 프론트 엔드 프레임워크에서 자주 언급되는 것 같은데 어떤건지 더 궁금해지기도 했음!!

 

 

 

 

 

빠르고 간결한 모던 웹 프레젝트 개발 경험에 초점을 맞춰 탄생한 빌드 도구

 

---

Vite의 컨셉

• 개발 시 Native ES Module을 넘어 더욱 다양한 기능을 제공한다. ex) Hot Module Replacement (HRM) 
• 번들링 시, Rollup 기반의 다양한 빌드 커맨드를 제공한다. 높은 수준으로 최적화된 정적(Static) 리소스들을 배포할 수 있게끔 하며, 미리 정의된 설정(Pre-configured)를 제공한다. 

위는 Vite 공식 페이지 가장 처음에 나와있는 문구인데, 딱 보면 눈에 보이는 문구가 몇 개 있다. 

ESM, 번들링, 빌드....

딱 읽어보면 ESM에서 번들링과 빌드를 쉽게 해주는 빌드 도구라는 거다.

그러니까.. 뭔지 이해하려면 이거부터 알고가야한다는 뜻 ㅋ;;

---

등장 배경 (Vite는 왜 필요했을까?)

Vite 등장 배경

 

ESM(ES Modules)를 지원하기 전까지, JS에서는 require.js 라이브러리나 IIFE 같은 것을 사용하지 않으면 모듈화를 네이티브 레벨에서 진행할 수 없었다.( CJS를 의미 : 간혹 파일을 import 할 떄, require('')로 되어있는 게 있는데 그걸 뜻하는 것이다 ㅇㅇ. 아직까지도 속성을 추가해줘야 한다.)

 

그래서, 소스 모듈을 브라우저에서 실행할 수 있는 파일로 크롤링, 처리 및 연결하는 번들링을 했어야 했다.

이 번들링을 하기 위한 도구로 Webpack, Rollup, Rarcel 를 사용해서 생산성을 향상 시켰다.

 

하지만, 애플리케이션이 점점 더 발전함에 따라 처리해야 하는 JS 모듈 개수도 극적으로 증가했다. (심지어 수천..) 이런 상황에서 JavaScript 기반 도구는 성능 병목 현상이 발생했고, 종종 개발 서버를 가동하는 데 비합리적으로 오랜 시간을 기다리거나 HMR을 사용해도 변경되 파일이 적용될 때 까지 수 초 이상 소요되곤 했다. 

 

지루할 정도로 길었던 서버 구동

 콜드 스타트 방식으로 서버를 구동할 때, 번들러 기반 도구는 모든 소스 코드에 대해 크롤링 및 빌드 작업을 마쳐야지만 했다. ( 콜드 스타트는 최초로 실행되어 이전에 캐싱한 데이터가 없는 경우를 의미합니다. - 옮긴이)

 

Vite는 애플리케이션 모듈을 dependencies와 source code 두가지 카테고리로 나누어 개발 서버 시작 시간을 개선한다.

• Dependencies : 개발 시 그 내용이 바뀌지 않을 일반적인 JS 소스 코드. 
  기존 번들러로는 컴포넌트 라이브러리와 같이 몇 백 개의 JS 모듈을 갖고 있는 매우 큰 디펜더시에 대한 번들링 과정이 매우 비효율적이었고 많은 시간을 필요로 했다. 
  Vite의 사전 번들링 기능은 Go언어로 작성된 ESbuild를 사용한다. Esbuild는 Webpack, Parcel과 같은 기존 번들러 대비 10-100배 빠른 속도를 제공한다.

esbuild에서 제공한 10개의 three.js 복사본의 번들러를 생성하는 최소 소요 시간.

 

• Source code : JSX, CSS 또는 Vue/Svelete 컴포넌트와 같이 컴파일링이 필요하고, 수정 또한 매우 잦은 Non-plain JS 소스코드는 어떻게 해야하나?
  vite는 Native ESM을 이용해 소스 코드를 제공한다. 이것은 본질적으로 브라우저가 번들러의 작업의 일부를 차지할 수 있도록 한다. vite는 브라우저가 요청하는 대로 소스 코드를 변환하고 제공하기만 하면 된다. 조겅부 동적 import 이후의 코드는 현재 화면에서 실제로 사용되는 경우에만 처리한다. 
   

왼쪽이 bundler, 오른쪽이 Vite 겠죠? 

위 그림에서 보이는 대로 기존에는 웹 애플리케이션을 구성하는 수많은 파일들을 하나의 파일로 병함 및 압축해 주는 동작과정인 번들링을 했다.. 
번들러란 필요한 의존성을 추적해 해당하는 의존성들을 그룹핑해주는 도구이고 대표적인 도구가 웹팩.( 웹팩 이야기도 재밌으니 한 번 찾아보세용)

 

하지만, Native ESM based dev server, 형식을 사용하면(Vite) 어떨까?

로컬에서 개발할 때 번들링을 사용하지 않고 ESM 방식을 사용한다. 웹팩은 처음 로컬 서버를 시작할 때 관련있는 모듈들을 번들링 해서 메모리에 적재하지만, 비트는 번들링을 하지 않고 바로 서버를 실행하기 때문에 명령어를 실행함과 동시에 서버가 바로 구동된다. 

 

이게 무슨 차이가 있을까?
- 기존 번들러는 소스 코드 업데이트 시 번들링 과정을 다시 거쳐야 했다. 일부는 메모리에서 작업을 수행해 실제로 갱신에 영향을 받는 파일들만 새롭게 번들링하도록 했지만, 결국 처음에는 모든 파일을 번들링해야했다. 
>> 대안으로 HRM(Hot Module Replacement)가 나왔지만, 해답은 되지 못함.

- vite는 번들러가 아니라 ESM을 사용하기 때문에, 어떤 모듈이 수정되면 vite는 그저 수정된 모듈과 관련된 부분만을 교체할 뿐이고, 브라우저에서 해당 모듈을 요청하면 교체된 모듈을 전달할 뿐이다.
 
vite는 HTTP 헤더를 활용해 전체 페이지의 로드 속도를 높인다. 필요에 따라 소스 코드는 304 Not modified, cache-control: max-age=315360000, immutable을 이용해 캐시 된다. 
>>요청 횟수를 최소화 해 페이지 로딩을 빠르게 만들어 줌.

 

++ 서비스 규모가 매우 큰 경우에는 선택적으로 번들링하는 게 이득일 수도 있다고 합니다 >> rollup사용.

 

---

결론과 정리

이 글을 정리하면서도 헷갈렸던 부분은, ESM 모드를 사용한다 해서 번들링을 하지 않는다고? 라는 거였는데, 

번들링을 하지 않는건 개발 모드(로컬)에서 개발을 할 때만 그렇다고 합니다. 

그 땐, 필요한 모듈만 선택적으로 불러와 브라우저가 직접 로드하게 된다고 하네요. 

 

프로덕션 빌드(배포) 과정에선 결국 번들링을 한다고 하네요! 하지만 개발 과정에서 줄어드는 것 만이라도 충분히 효율적일 것 같습니다 ㅎㅎ 

 

그리고 배경을 정리해 보면, Vite는 결국 Common JS에서 ESM으로 변경되면서 자연스럽게 등장한 개발 도구라는 생각이 듭니다 .

 

다음엔 Vite 실습편으로 돌아오겠습니다! 

 

혹시 글을 보면서 생긴 의문점이나 잘못된 정보는 댓글로 남겨주세요! 언제든 환영합니다~

 

 

 

 

https://khys.tistory.com/31

[JS] 비트(Vite)란? - 비트 알아보기

https://ko.vitejs.dev/guide/why.html

Vite

https://ko.vitejs.dev/guide/

Vite