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

Context

Kitchen 라이브러리는 초기에 UMD + CommonJS 혼합 빌드와 컴포넌트별 패키지 구조로 설계되어 다양한 환경을 지원했으나, 시간이 지나면서 실제 사용은 단일 진입점 기반 ESM 환경으로 수렴했다. 트리셰이킹이 작동하지 않아 일부 컴포넌트만 import해도 전체 코드(1.61MB)가 번들에 포함되었고, 빌드 산출물 기준 참조로 인해 Storybook의 자동 추론, 로컬 개발, 테스트 환경이 복잡화되었다.

Technical Solution

• ESM-only 배포 포맷 도입: UMD/CommonJS 혼합 방식을 버리고 ES Module로 통일하여 번들러가 정적 분석으로 의존성 추적 가능하게 변경
• exports 필드 명시화: package.json의 exports를 명확히 정의하여 번들러가 추가 설정 없이 import 구문만으로 트리셰이킹 수행 가능
• 패키지 구조 단순화: 총 28개의 컴포넌트별 독립 패키지를 단일 packages/kitchen으로 통합하여 개발 단위와 배포 단위 일치
• 소스 코드 기준 참조로 전환: 컴포넌트 간 빌드 산출물 참조를 제거하고 상대 경로 기반 소스 코드 참조로 변경
• foundation 패키지 분리: 디자인 토큰(컬러, 타이포그래피)을 kitchen-foundation으로 분리하여 Desktop/Mobile 디자인 시스템이 공통 자산 단일 책임 기준으로 관리

Impact

• 빌드 시간: 60.93초 → 6.94초 (88.6% 단축, 8.8배 개선)
• 개발 확인 루프(Cold 스타트): 86.34초 → 20.87초 (75.82% 단축, 4.14배 개선)
• HMR 성능: 35.21초 → 즉시 반영
• 번들 내 Kitchen 코드 크기(parsed size): 1.61MB → 162.5KB (89.97% 감소)
• 트리셰이킹 효과: 최소 사용 페이지 1.73KB vs 전체 사용 페이지 136KB 차이 확인
• 코드량: 2만8천 줄 감소

Key Takeaway

디자인 시스템 설계는 "초기 기술 환경"이 아닌 "실제 진화된 사용 방식"을 기준으로 주기적으로 재평가해야 하며, 구조와 운영 단위의 불일치는 개발 생산성과 설계 선택의 자유도를 심각하게 제약한다.