- 개발 초기에는 빌드 시간이 30초 정도로 괜찮았지만, 점점 기능이 추가되면서 빌드 시간이 1분 10초까지 증가함
- 긴 빌드 시간은 개발 과정을 느리게 만들고, 새로운 개발자의 온보딩 시간을 늘리며, 일상적인 작업에서 집중하기 어렵게 만듦
해커톤을 통한 개선 시도
- 1월에 데이터를 수집하고, 해커톤 프로젝트 제안서를 작성하며, 기존 빌드 시스템에 대한 이해를 높이고 프로파일링 방법을 모색함
- OpenTelemetry와 Jaeger를 활용하여 전체 빌드 프로세스를 프로파일링함
- 프로파일링 결과, Webpack/Rollup 실행이 대부분의 빌드 시간을 차지하고 있음을 확인
- 작은 의존성들이 하나씩 빌드되고 있어 병렬 처리의 기회가 많음을 발견
- 초기에 일부 핫한 작업들이 필요 이상으로 오래 걸려 나머지 빌드 프로세스를 지연시키고 있음을 확인
- 해커톤 기간 동안 esbuild를 활용하여 번들링 시간을 단축하는데 집중
- Webpack/Rollup의 로더로 esbuild를 사용하여 성능을 크게 개선 (Rollup의 경우 80% 단축)
- esbuild를 Webpack/Rollup를 완전히 대체하는 번들러로 사용하여 번들링 시간을 90% 단축
- 해커톤 프로젝트 결과, 확장 프로그램 빌드 시간을 70% 이상 단축하여 15초 수준으로 개선
프로덕션 적용을 위한 작업
- 해커톤 프로젝트에서는 임시 방편이 많이 사용되었기 때문에, 프로덕션에 적용하기 위해서는 실제 솔루션으로 대체해야 함
- Webpack과 Rollup 사용을 완전히 esbuild로 전환
- 빌드 프로세스를 하나의 위치로 통합
- 그래픽 에셋 처리 문제 해결
- TypeScript 타입 검사를 빌드 프로세스에 다시 추가
- 프로덕션 빌드 테스트 및 크기, 기능 비교
- 내부 의존성 변경사항 반영
- Sentry 빌드 단계 등 이전 빌드 시스템의 다른 측면 재현
- 비 Chrome 브라우저, 폴리필, 스토어별 빌드 요구사항 처리 추가
- 타입 검사와 번들 크기 최적화에 중점을 둔 작업 수행
esbuild에 타입 검사 추가
- tsc는 느리기 때문에 esbuild의 빠른 빌드 프로세스와 함께 사용하기 어려움
- esbuild-plugin-typecheck 커뮤니티 플러그인을 사용하여 tsc를 worker 스레드에서 실행하고 증분 컴파일을 활용
- 자체적으로 간단한 타입 검사 플러그인을 구현하여 각 패키지 루트마다 병렬로 tsc CLI 프로세스를 실행
- tsc 컴파일 진단 메시지를 esbuild 네이티브 형식으로 변환하여 가독성 개선
- tsc --listFilesOnly 플래그와 esbuild의 Metafile을 활용하여 모든 빌드 입력이 타입 검사되었는지 자동으로 검증
프로덕션 번들 크기 개선
- esbuild의 번들 크기 분석기를 활용하여 프로덕션 번들 분석
- UI 컴포넌트 라이브러리의 ESM과 CJS 빌드가 모두 번들에 포함되는 문제 발견
- 내부 라이브러리의 잘못된 설정을 수정하여 번들 크기 축소 (3.3MB -> 2.1MB)
- 여러 엔트리포인트에 걸쳐 파일 크기 감소 효과 확인
영향과 결론
- 프로덕션 구현 결과, 웜 빌드 시간이 90% 이상 단축되어 5초 수준으로 개선
- watch 모드에서는 TypeScript 파일 변경 시 1초 이내에 리빌드 가능
- 개발자들이 새로운 빌드 시스템으로 인해 작업 효율성이 크게 향상되었다고 피드백
- QA 팀과 개발자 volunteers의 노력으로 새로운 빌드 시스템으로의 전환이 원활히 이루어짐
- 개발자 만족도 조사 결과, 빌드 시간에 대한 불만족이 97%에서 5%로 크게 감소
- esbuild는 훌륭한 도구이며, 해커톤 프로젝트는 이런 작업에 최고임