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

Kitchen은 실제 사용 방식에 맞춰 구조를 다시 설계했다. 기존에는 kitchen-core의 re-export 구조와 UMD/CJS 혼합 빌드 때문에 트리셰이킹이 되지 않았고, 일부 컴포넌트만 써도 전체 코드가 번들에 들어갔다.

문제를 키운 건 성능 자체보다 구조와 사용 방식의 불일치였다. 컴포넌트 간 참조를 빌드 산출물 기준으로 하면서 Storybook 추론, 로컬 실행, 테스트 모킹이 복잡해졌고, 새 컴포넌트를 만들 때도 번들 영향이 먼저 고려되는 상황이 이어졌다.

개선의 기준은 세 가지였다.

• 실제 사용 방식과 구조를 일치시킬 것
• 번들러가 정적으로 분석할 수 있을 것
• 단기 성능보다 중장기 유지보수성을 우선할 것

이에 따라 배포 포맷을 ESM 기반(dist/esm) 으로 전환하고 exports를 명시해, import된 것만 번들에 포함되도록 바꿨다. 또 컴포넌트별 멀티 패키지를 걷어내고 packages/kitchen 단일 패키지 구조로 정리해 소스 코드 기준 의존 관계를 명확하게 만들었다.

공통 자산은 kitchen-foundation 으로 분리해 디자인 토큰 관리 기준도 정리했다. Desktop과 Mobile이 같은 foundation을 바라보게 하면서 토큰 변경의 중복 작업과 누락 위험을 줄이려 했다.

성과도 분명했다. 빌드 시간은 60.93초에서 6.94초로 88.6% 단축됐고, Cold 개발 확인 루프는 86.34초에서 20.87초로 줄었다. 측정 서비스 기준 Kitchen 코드 포함량도 1.61MB에서 162.5KB로 감소해, 컴포넌트 추가가 더 이상 성능 리스크로 먼저 인식되지 않게 됐다.