디자인 컴포넌트 라이브러리를 ‘실제 사용 방식’에 맞게 다시 설계한 이야기

React 기반 디자인 시스템 라이브러리 Kitchen은 UMD·CommonJS 혼합 빌드와 전체 컴포넌트 re-export 구조 때문에 일부 컴포넌트만 사용해도 전체 코드가 번들에 포함됐고, 개발·테스트 환경도 복잡해졌습니다. 사용처가 웹 번들러 기반 React 환경으로 바뀐 점을 반영해 ESM-only 배포와 명시적 exports를 도입하고, 28개 컴포넌트 패키지를 단일 패키지로 통합했으며 공통 디자인 토큰은 foundation으로 분리했습니다. 그 결과 빌드 시간은 60.93초에서 6.94초로 줄고, 측정 서비스의 공통 번들에 포함된 Kitchen 코드는 1.61MB에서 162.5KB로 감소했습니다. 구조 개선은 기술 선택 자체보다 실제 사용 방식과 개발자의 작업 흐름에 맞춰 라이브러리를 설계하는 것이 중요하다는 점을 보여줍니다.

• 라이브러리의 패키지 경계와 배포 단위는 실제 소비 방식에 맞춰야 한다.
• 트리셰이킹을 기대한다면 번들러가 의존성을 정적으로 분석할 수 있도록 ESM과 명시적인 exports를 제공한다.
• 빌드 산출물 대신 소스 코드에서 컴포넌트 간 의존성을 표현하면 Storybook과 테스트에서 직접 다루기 쉬워진다.
• 공통 디자인 토큰은 여러 시스템에서 반복 관리하지 않도록 단일 책임의 foundation으로 분리할 수 있다.