디자인 시스템은 어떻게 만들었어요?(3) - Tree Shaking과 구형 브라우저 대응

YDS v2 같은 외부 라이브러리는 서비스 번들 크기와 브라우저 호환성에 직접적인 영향을 준다. 요기요 FE 팀은 이를 해결하기 위해 Tree Shaking 최적화와 구형 브라우저 대응을 각각 별도 과제로 다뤘다.

Tree Shaking을 제대로 작동시키려면 단순히 Next.js에 맡기는 것으로는 부족하다. 라이브러리는 ESM으로 배포하고, package.json의 **sideEffects**를 명시해 번들러가 안전하게 미사용 코드를 제거할 수 있게 해야 한다.

여기서 핵심은 모듈 경계 유지다. 모든 코드를 하나의 파일로 묶거나, barrel file과 복잡한 재-export 구조에 의존하면 서비스 번들러가 정적 분석을 보수적으로 수행해 불필요한 코드까지 포함할 수 있다.

이를 줄이기 위해 라이브러리 빌드에서는 **preserveModules: true**로 원본 모듈 구조를 유지하거나, Multi-entry 방식으로 공개 진입점을 명시한다. 또한 외부 의존성은 external로 분리해 라이브러리와 서드파티 코드를 한 파일에 섞지 않도록 설계한다.

이 구조는 서비스 측 최적화에도 이어진다. Subpath Exports와 함께 쓰면 필요한 모듈만 직접 import할 수 있고, Next.js의 실험 기능인 **optimizePackageImports**를 활용하면 barrel import를 유지하면서도 direct import에 가까운 효과를 낼 수 있다.

실험 결과도 이를 뒷받침한다. Next.js 기본 환경에서 **yds2-react**를 설치하고 SingleBadge 하나만 사용했을 때, 메인 페이지 First Load JS와 Next Bundle Analyzer 기준 Total Size가 크게 줄어들었고, 1.58 MB 수준이던 점유 크기를 29 kB까지 낮출 수 있었다.

구형 브라우저 대응에서는 Compile, Transpile, Polyfill을 구분하는 것이 출발점이다. 문법 변환은 Transpile, 실행 환경에 없는 기능을 보완하는 것은 Polyfill이며, Next.js의 기본 제공 폴리필만으로는 모든 브라우저 차이를 해결할 수 없다.

특히 Next.js의 기본 폴리필은 Chrome 64 미만을 중심으로 로드되거나 제한적인 범위만 지원하므로, **Promise.allSettled()**처럼 더 최신 브라우저에서만 지원되는 API는 사각지대가 생길 수 있다. 그래서 라이브러리 자체에 폴리필을 넣는 대신, 서비스 애플리케이션이 자신의 타겟 브라우저에 맞춰 책임지는 방식을 택했다.

이 전략을 구현하려면 browserslist로 타겟 브라우저를 명확히 두고, 필요한 경우 외부 라이브러리까지 포함해 트랜스파일해야 한다. 결국 핵심은 설정 하나가 아니라, ESM 배포, sideEffects, external 분리, 모듈 구조 유지, 타겟 브라우저 기준의 transpile/polyfill을 함께 설계하는 데 있다.