1. Vite를 사용해야 하는 이유
브라우저에서 ESM(ES Modules)을 지원하기 전까지, JavaScript 모듈화를 네이티브 레벨에서 진행할 수 없었다.
그래서 소스 모듈을 브라우저에서 실행할 수 있는 파일로 크롤링, 처리 및 연결하는 "번들링(Bundling)" 이라는 방법을 사용해야 했다.
하지만 처리해야하는 JavaScript 모듈의 개수가 증가하면서 성능 병목 현상이나 서버를 가동하는데 오랜 시간을 기다려야 하는 등 문제가 발생했다.
vite는 애플리케이션 모듈을 dependencies와 source code 두 가지 카테고리로 나누어 개선했다.
Dependencies
개발 시 그 내용이 바뀌지 않을 일반적인 JavaScript 소스 코드이다.
보통 애플리케이션에서 사용하는 라이브러리나 패키지를 의미한다.
예를 들어, React나 axios 같은 라이브러리들은 개발할 때 거의 수정되지 않고, 한 번 설치한 뒤에는 크게 변하지 않는다.(개발하는 중에 React 자체 코드를 수정할 일은 없다.)
기존 번들러(Webpack, Parcel)들은 이런 라이브러리들을 번들에 포함시켜서 하나의 큰 파일로 만들어서 제공하기 때문에, 애플리케이션 규모가 커질수록 비효율적일 수 밖에 없다.
Vite는 사전 번들링 기능은 개발 시 변경되지 않을 JS 코드들을 Esbuild를 통해 사전 번들링한 후, 이후 개발 서버를 실행할 때는 사전 번들링된 정적인 코드만을 활용한다.
Esbuild는 Go언어로 작성된 초고속 번들러로, JavaScript 기반 번들러(Webpack, Parcel)보다 10~100배 빠른 속도를 제공해 Vite의 개발 서버 초기 로딩을 크게 단축시킨다.
Source code
우리가 직접 개발할 때 작성하는 애플리케이션 코드들을 의미한다.
React 컴포넌트 파일(JSX, TSX), 스타일(CSS) 또는 Vue/Svelte와 같은 프레임워크 컴포넌트 파일들은 개발 중에 수시로 수정되기 때문에, 매번 번들링해서 제공하는 것이 비효율적일 수 있다.
기존 번들러(Webpack, Parcel)은 이 소스 코드들 전부를 한 번에 묶어서 브라우저에 제공하기 때문에 비효율적이다.
한 페이지에서 특정 컴포넌트만 사용하고 있는데, 전체 어플리케이션의 모든 컴포넌트를 번들링해서 제공하는 방식은 불필요한 작업이 많아지기 때문이다.
Vite는 소스 코드를 Native ESM을 이용해 필요한 순간에 로드하기 때문에, 특정 파일을 수정할 때 전체 프로젝트를 다시 번들링할 필요가 없다.
수정된 파일만 다시 로드되어 기존 번들링 방식에 비해 빠르게 반영된다.
번들 기반 개발 서버의 HMR
- 전체 번들 재생성: 번들 기반 개발 서버는 파일이 변경될 때마다 전체 번들을 다시 생성합니다. 즉, 애플리케이션의 모든 파일을 다시 묶어서 하나의 파일로 만들어야 합니다.
- 느린 재로딩: 전체 번들을 다시 생성하고 브라우저에 다시 전달해야 하므로, 파일이 작더라도 상대적으로 느린 재로딩 시간을 경험할 수 있습니다.
Native ESM 기반 개발 서버의 HMR
- 변경된 모듈만 재로딩: Native ESM 기반 개발 서버는 변경된 모듈만 정확하게 찾아서 브라우저에 다시 전달합니다.
- 빠른 재로딩: 전체 번들을 다시 생성할 필요가 없으므로, 매우 빠른 재로딩이 가능합니다. 개발자가 코드를 수정하고 즉시 결과를 확인할 수 있어 개발 생산성을 크게 향상시킵니다.
HMR(Hot Module Replacement)
개발 서버에서 코드를 수정하면 전체 페이지를 새로고침하지 않고, 변경된 모듈만 교체하여 브라우저에 반영하는 기술
작동 방식
1. 파일 감시: 개발 서버는 파일 시스템의 변경 사항을 지속적으로 감시합니다.
2. 모듈 변경 감지: 변경된 파일이 어떤 모듈에 속하는지 파악합니다.
3. 변경된 모듈만 재컴파일: 변경된 모듈만 재컴파일하여 업데이트된 코드를 생성합니다.
4. 브라우저에 업데이트 신호 전달: 브라우저에 변경 사항이 발생했음을 알리고, 변경된 모듈 정보를 전달합니다.
5. 브러우저에서 모듈 교체: 브라우저는 받은 정보를 바탕으로 기존 모듈을 새로운 모듈로 교체합니다. 이때, 애플리케이션의 상태는 유지됩니다.
2. Vite 번들링 과정이 필요한 이유
- 추가 네트워크 요청: 각 모듈마다 별도의 HTTP 요청이 발생하여 로딩 시간이 길어질 수 있습니다.
- 중복 코드: 여러 모듈에서 동일한 코드를 사용하는 경우, 각 모듈마다 코드가 중복되어 전송됩니다.
- 캐싱 효율성 저하: 자주 변경되는 작은 파일들과 함께, 자주 변경되지 않는 라이브러리 파일들이 함께 캐시되면서 캐시 효율성이 떨어질 수 있습니다.
번들링은 이러한 문제를 해결하기 위한 방법입니다. 여러 개의 모듈을 하나의 파일(번들)로 합쳐서 전송함으로써, 네트워크 요청 횟수를 줄이고, 중복 코드를 제거하며, 캐싱 효율을 높일 수 있습니다.
- 개발 환경: 빠른 개발 속도를 위해 HMR, 소스맵 등 개발 편의 기능을 제공하고, 번들 최적화는 생략합니다.
- 프로덕션 환경: 최적의 성능과 안정성을 위해 파일 크기 축소, 트리 쉐이킹, 코드 난독화 등의 최적화 작업을 수행합니다.
Vite 이 과정에서 내부적으로 Rollup 번들러를 사용하여 ESM 기반 코드를 하나의 파일로 묶어 제공하며, 필요한 경우 코드 분할 기능을 통해 사용하지 않는 코드도 제거한다. (*Rollup 또한 ESM 기반 모듈 번들러 중 하나이다.)
'프론트엔드 > React' 카테고리의 다른 글
| [React] 코드 스플리팅 (Code Splitting) (1) | 2024.11.06 |
|---|---|
| [React] 프로젝트 세팅 (0) | 2024.11.05 |
