Sendbird 대시보드의 Vite 마이그레이션

안녕하세요. Web Application 팀 Linus입니다. 이 포스트에선 센드버드 대시보드에서 모듈 번들러를 Webpack에서 Vite로 변경한 이야기를 드리려 합니다.

왜 모듈 번들러를 교체해야 했나요?

모듈의 개수, 의존성이 늘어나면 결과적으로 빌드타임이 늘어나게 됩니다. Chat, Calls, Live, Desk, Notification 등 센드버드의 강력한 기능을 고객들이 자유롭게 사용하실 수 있도록 대시보드는 끊임없이 진화하고 있습니다. 새로운 기능을 늘리려면 필연적으로 모듈의 개수는 늘어나게 됩니다.

센드버드 팀에서 기존에 사용하던 webpack은 dev server를 시작하기 위해서 번들링을 수행합니다. 초기 빌드 기준으로 평균 22초가 걸렸고, HMR은 수 초가 소요되었습니다. 그러면 코드 수정, UI 확인으로 반복되는 과정에서 매번 수초의 딜레이가 발생하게 됩니다.

이에 Native ESM을 활용하여 생산성을 증가시키고자 현재 가장 성숙한 ESM 기반 번들러인 Vite로의 마이그레이션을 고려하게 되었습니다.

기술 과제와 해결 과정

1. 순환 참조

webpack에서는 순환참조 모듈의 레퍼런스를 빈 오브젝트 {} 로 처리합니다. 하지만 ESM에서는 레퍼런스 에러를 얻게 되기에 기존 모듈에 있던 타입 순환 참조를 해결해야 했습니다. 이후에 발생하는 순환 참조에 대해서도 추적이 가능해야 하기에 Madge 를 commit-hook에 포함시켜 항상 검사하도록 구성했습니다.

2. esm 미지원 라이브러리

자바스크립트 모듈을 지원하지 않는 오래된 라이브러리들을 처리해야 했습니다. esm을 지원하는 대안이 있는 경우는 교체하였고, 없는 경우에는 polyfill을 사용하거나 package install 과정에서 모듈 지원을 추가하도록 구성하였습니다.

Patch-package 라이브러리를 이용하면 post-install 과정에서 모듈을 안전하게 수정할 수 있습니다. Global 변수에 접근하는 라이브러리나 mixed output을 가진 라이브러리를 간단한 수정을 통해 처리할 수 있었습니다.

3. Jest

유닛 테스트에 사용하던 Jest는 vite와도 문제없이 동작하지만, webpack, webpack-dev-server에 의존하는 설정과 플러그인들이 존재했습니다. 기존의 Jest와 인터페이스 호환성을 유지하면서 esm 환경에서 동작하도록 Vitest로 구성을 변경하였습니다. 이 과정에서 번들링 순서에 의해 hanging 되는 테스트들을 수정하기 위해서 test sharding / vitest ui를 적극적으로 활용하였습니다.

디버깅 툴을 이용하여 reference error가 발생하는 모듈을 찾거나, 올바르게 작동하지 않는 Mock timer들을 찾아 수정할 수 있었습니다.

제약 사항

1. 빌드 결과물 동일성 보장

웹팩에서 모듈을 resolve 하는 과정에선 수많은 transform이 일어납니다. css-preprocessor, binary file 등을 처리하는 과정에서 변화가 있기에 transform 이후의 결과물이 같도록 많은 테스트를 진행했습니다.

2. 테스트 커버리지 유지

Vitest로 변경하는 과정에서 깨지는 테스트가 최소화되도록 구성해야 했습니다. 1과 마찬가지로 기존의 시스템을 해치지 않는 선에서 마이그레이션하는 일을 최우선 목표로 삼았습니다.

3. Network waterfall

Vite는 production 환경(build output)에서 rollup을 사용합니다. 자유롭게 번들의 개수를 조절할 수 있지만, 개발 환경과의 동일성 추구를 위해서는 dynamic import를 수행하는 모듈들을 esm으로 임포트하도록 구성했습니다. 하지만 모듈의 개수가 기존 수십개에서 수백개로 증가하였기 때문에 모듈 prefetch, http 설정 변경을 통해 network overhead를 최소화 하도록 구성해야 했습니다.

결과

아래 표는 로컬에서 dev server를 콜드 스타트($ vite dev | webpack serve)한 시간을 각 10회 측정한 결과입니다.

마치며

이 글이 Webpack에서 Vite로 마이그레이션을 고민하는 개발자분들에게 도움이 되길 바라며 센드버드 팀의 경험을 공유드립니다. 모듈 번들러 교체는 큰 시스템일수록 부담스러운 작업인게 사실이지만 얻어지는 생산성 향상의 폭이 크고, 증가된 생산성은 다시 고객에게 전달되는 가치의 상승으로 이어지는 좋은 작업이었다고 생각합니다.