[React | Vite] CRA 대신 Vite(비트)?

Vite는 '바이트'가 아닌 '비트'라고 발음한다고 합니다. 프랑스어로 '빠르다'라는 뜻이며 정말 빠른 개발을 할 수 있는 도구를 돕기 위해 만들어졌습니다.

 

자바스크립트는 module(모듈)이 없습니다. 처음 탄생했을 때 대형 어플리케이션을 만들 용도로 만들어진게 아니기 때문인데요. 모듈이 없기때문에 파일을 여러 개로 만들어서 개발할 수도 없었습니다. 하나의 파일에서 거대한 코드를 작성한다면 엉망진창이 될 겁니다.

이후, node가 만들어지고 서버에서 js를 사용할 수 있게 되면서 require 함수와 module.export를 쓰는 CommonJS 방식의 모듈이 만들어졌습니다. 당시 js문법에는 import와 같은 표준 모듈 문법이 없었다고 합니다.

// CommonJS 방식
const path = require("path")
module.export = function() { ... }

그리고 npm의 등장으로 만들어진 모듈을 모두가 공유할 수 있게됐고, 이때부터 자바스크립트에서 본격 활용되기 시작했습니다. 

 

브라우저의 모듈은 서버와 다르다.

서버 플그래밍의 특성상 코드를 미리 만들고, 파일에서 코드를 동적으로 불러오면 용량의 제한과 방식의 제한이 없습니다. 

반면 브라우저는 js파일을 저장하지 못하고 매번 불러와야 했기 때문에 언제나 로딩과 비동기를 고려해야 합니다. 스크립트는 순서대로 실행해야 하는데, 로딩이 누가 먼저 될 지 모르기 때문에 비동기가 문제되었습니다.

 

그래서 CommonJS(비동기X)와는 다르게 비동기가 가능한 AMD라는 방식으로 브라우저에서 돌아가는 모듈을 만들어 프로그램의 덩치가 커질 수 있도록 제공하였습니다. 

 

하지만 이 방식은 여러  파일을 로딩해야 했고, 순서를 맞춰야하는 단점이 있기 때문에 널리쓰이진 않았습니다. 하지만 AMD방식은 표준 import 구문을 탄생하는데 영향을 미치게 됩니다. 

 

이후 import 구문을 통해 브라우저에서도 모듈을 쓸 수 있게 되었으나 브라우저 특성상 js파일을 동시에 여러개 호출하면 속도 문제가 발생했습니다. 또 특정 js파일의 로딩이 지연되면 전체가 늦어지는 문제가 있어 이 역시 널리쓰이지 않게 됐습니다. 

브라우저에서는 어떻게 모듈을 사용해야 할까? => 번들러

여러 개의 파일을 비동기로 로딩하는 것이 문제라면 처음부터 파일을 하나로 합쳐서 전달하는 건 어떨까?

결국 많은 도전 끝에 모듈처럼 여러 개의 파일을 나눠서 개발할 수 있도록 모든 파일을 하나로 합친 '하나의 번들'을 만들어냈습니다. 대규모 협업 개발을 가능하게 해준 '번들러'라는 개념이 탄생하는 순간입니다. 

e.g) WebPack

 

번들러의 발전

parcel, webpack, rollup.js 등 더 나은 컨셉과 성능 개선이 된 도구가 만들어졌습니다.

Rollup - 웹팩보다 ES6 지원을 더 잘한다는 장점이 있는 거 같습니다.

Vite는 Rollup 번들러를 사용한다고 하죠. 제가 기존에 사용하던 CRA(Create React App)은 webpack을 사용합니다. 

 

JS 번들러로 본 조선시대 붕당의 이해

위의 링크를 타고 들어가시면 자세한 흐름을 파악하기에 많은 도움이되니 읽어보시길 바랍니다.

"요즘 시대에 니들같은 복잡한 설정은 미친 짓.. 우리는 설정 파일 없이 간다.."-Parcel- 와 같은 주옥같은 대사를 볼 수 있습니다.

 

번들러의 문제점 = 느린 빌드 속도

번들러는 기존 모듈 방식의 문제점을 해결할 수 있었지만, 속도가 문제가 됐습니다. 기존에는 그냥 js를 작성하면 바로 브라우저에서 실행할 수 있었지만, 이제 모든 파일을 하나로 만드는 작업을 선행해야 했기 때문입니다. 수정할 때마다 매번 새롭게 빌드가 필요하고 빌드 속도는 절대로 빠르지 않기 때문에 코드를 수정하면 즉시 반영이 되는 자바스크립트의 장점이 많이 퇴색됐습니다. 

 

기존보다 100배 빠른 빌드 속도 - esbuild

기존 빌드 속도보다 무려 100배나 빠른 도구가 탄생했습니다. 바로 esbuild인데요. 기존 번들러와 달리 JS가 아니라 go언어로 작성되었습니다. 덕분에 스크립트 기반의 느린 js가 아니라 native의 기능을 최대한 이용하여 훨씬 더 빠른 빌드 작성이 가능했습니다. 

 

하지만 esbuild는 그저 빌드 도구이기 때문에 기존에 더 많은 부가 기능을 제공하던 Webpack을 대체하진 못했습니다. 

Webpack은 단순한 빌드 도구가 아니라 DevServer, 각종 Loader를 통한 트랜스 파일, 코드 스플리팅, 트리셰이킹, HMR, CSS, HTML, asset 지원 등 빌드 도구를 넘어서 개발을 할 수 있게 해주는 통합 툴입니다. 

-> 그래서 esbuild를 이용하여 개발이 가능한 것은 보통 바닐라 스크립트 형태의 라이브러리 등이었고(esbuild의 적용 한계), 프레임워크를 기반으로 하는 웹 개발은 기본 번들러를 사용해야만 했습니다.

• Webpack은 빌드 도구를 넘어 통합 툴이다. 그에 비해, esbuild는 단순히 빌드 도구

esbuild를 사용하기 위해 등장한 Snowpack

2020년 위의 문제를 타파하기 위한 새로운 번들러가 탄생하게 됩니다. snowpack은 더 빠른 웹 개발을 위한 최신의 프론트엔드 빌드 도구라고 설명하고 있습니다. 

esbuild는 빠르게 빌드가 가능하지만 모든 기능을 하나로 만들어 통합하지 못했습니다. 그리고 브라우저의 표준 모듈 방식은 각자의 모듈을 동작하도록 가능하게 만들었지만, 실전에서 너무 많은 파일을 로딩하는 문제가 있었습니다.(esbuild의 한계) 

Snowpack은 esbuild를 통해서 개발 모드를 지원하고, 실제 번들은 Webpack을 통해 제공하는 방식(new 방식 + 기존 방식 = 혼합 형태)으로 편리함과 속도라는 두 마리 토끼를 잡을 수 있게 됐습니다. 

 

당시 Svelte 프레임워크의 공식 번들툴로는 Rollup 번들을 사용하였는데, Rollup에서는 HMR을 지원하지 못했습니다. 

 HMR(Hot Moudule Reload): 파일 수 정 시 새로고침을 하지 않고 수정된 파일의 내용만 반영할 수 있는 기능

결국, 스벨트는 Rollup을 버리고 Snowpack을 공식 번들툴로 변경하려는 작업을 진행하게 됐습니다. 

그러나 모든 최신 기술이 그렇듯 Snowpack은 안정적이지 못했습니다. Webpack와 연동해서 사용하는 과정에서 다소 버그들이 생겼고, Webpack의 loader들과 잘 호환되지 못하는 문제가 생겼습니다. 

 

이제 글의 주인공인 Vite가 등장합니다!

Snowpack의 컨셉은 아주 좋았지만, 안정화를 위해선 시간이 필요했습니다. 에반 유*는 Snowpack의 단점을 놓치지 않고 이를 개선하여 Vite를 만들었습니다. 

에반 유는 Vue의 창시자로 기존의 쓰던 제품을 더 간결하고 사용하기 편하게 만드는 것이 특징입니다. 외에 그가 만든 것들은 Vuex from Redux, Nuxt from Next, Vue,js from angular.js , 그리고 Vite from Snowpack 

Vite는 esbuild와 브라우저 모듈을 이용한 개발모드, 개발 서버, 프록시 서버, 번들툴, 코드 스플리팅, HMR등 지금까지 나왔던 snowpack의 컨셉과 다른 번들 도구에서 제공하는 기능을 하나로 모든 프론트엔드 번들 도구였습니다. 

그리고 또 다시, Svelte는 snowpack을 버리고 vite와 통합하게 됩니다. 

 

아직은 Webpack에서만 돌아가는 에코시스템이 있지만 Vite의 에코시스템은 놀랍도록 빠르게 발전하고 있으며 계속 만들어지고 있기 때문에 독자적인 Vite생태계도 생겨나는 중입니다. 아울러 주류 모듈 역시 점차 양쪽 다 지원하는 형태로 발전하고 있어서 빠르고 편리하고 풍부한 자신만의 환경을 구축하고 있습니다. 

 

"2021년 가장 만족도가 높은 번들툴"로 선정된 Vite, 빌드 과정이나 개발하면서 수정사항 반영이 너무 느린 프로젝트가 있다면 시도해보는 것은 어떨까요? 

 

Vite는 Esbuild를 기반으로 만들어진 프론트엔드 빌드툴입니다. 

네이티브 ESmodule활용과 compile-to-native 언어로 작성된 자바스크립트 툴

ES 모듈 활용덕에 JS코드를 모두 번들할 필요없이 브라우저에서 자바스크립트 어플리케이션을 작동시킬 수 있습니다. 

 

핵심은 ES 모듈을 사용하여 브라우저가 필요로 하는 어플리케이션 코드의 일부분만 변환하고 제공하는 것입니다. 

개발 모드로 빌드를 할 때, Vite는 자바스크립트 모듈을 두 가지 카테고리로 나눕니다.

1) 의존성 모듈, 2) 소스 코드

• 의존성 모듈은 node_modules 폴더로부터 import 되는 자바스크립트 모듈이며 개발하는 동안에 자주 바뀌지 않는 편입니다. 이 모듈은 esbuild를 사용하여 처리됩니다. Webpack이 브라우저의 요청 이전에 모든 자바스크립트 모듈을 처리하는 반면, Vite는 브라우저 요청 전에 의존성 모듈만 미리 번들링 합니다.
• 소스코드는 .jsx, .vue, .scss 와 같은 라이브러리 관련 확장자를 포함할 수도 있으며, 자주 수정되는 파일을 말합니다. 또한, 소스코드 전체는 동시에 로드될 필요가 없다는 특징이 있습니다.

Vite는 native ESM을 통해 소스코드를 제공합니다. 이는 브라우저로 하여금 번들러의 작업 일부를 넘겨받게 합니다. Vite는 브라우저의 요청이 있을 시에만 소스코드를 변환하고 제공합니다. 

HMR은 나머지 페이지에 영향을 끼치지 않고, 특정 모듈만 "즉시 반영"될 수 있도록 해줍니다. 그러나 프로젝트의 크기가 커질수록 HMR의 시간 또한 길어지게 되므로 생산성 저하로 이어지게 됩니다. 

Vite는 네이티브 ESM을 기반으로 HMR을 구현하므로 다른 번들링 툴보다 우위에 있다고 할 수 있습니다. 

모듈이 수정되면, Vite는 수정된 모듈과 관련된 부분만을 교체할 뿐이고, 브라우저에서 해당 모듈을 요청하면 교체된 모듈을 전달할 뿐이기에 어플리케이션의 크기와 관계없이 HMR을 언제든 빠르게 이뤄지도록 합니다. 

• Vite는 번들링을 생략하여 개발 서버를 빠르게 구동시킨다.
• Vite는 더 빠른 리로딩과 캐싱을 위해 HTTP 상태 코드를 활용한다.
• HMR을 위해 native ESM을 사용한다. 따라서 앱에 대한 변경사항이 빠르게 반영
• Vite가 설정한 최소한의 config로도 사용할 수 있다.

여담: 

cra 대신 vite를 사용했을 때 빌드가 빠른 점은 확실히 체감할 수 있었습니다. 하지만 CRA에서 Webpack이 기본적으로 제공해주던 기능을 온전히 이해하지 못하고 편하게 사용했기 때문에 Vite로 넘어가게 된다면 어떤 것을 추가적으로 설정해야할 지 아직은 잘 모르겠네요.  

---

all ref: 

왜 Create React App 대신 Vite일까

Vite 이야기(feat. Svelte) | 요즘IT