피드로 돌아가기
강남언니 공식 블로그Frontend
원문 읽기
개발자 여러분, 디자인시스템 지금 바로 도입하세요!
강남언니가 기존 오픈소스 UI 라이브러리 기반에서 Welchis 자체 UI 라이브러리로 전환해 4개 제품의 디자인 일관성 관리 및 API 확장성 문제 해결
AI 요약
Context
기존 Bootstrap, Materialize, Element UI 같은 오픈소스 라이브러리를 사용할 때 디자인 변경 시 4개 제품 코드를 각각 수정해야 하는 번거로움이 발생했다. API가 Welchis 디자인 시스템과 맞지 않아 icon-after 같은 커스텀 속성을 추가할 때마다 원본 라이브러리에 의존성이 생기고 관리 포인트가 증가했으며, 라이브러리 코어 버그 업데이트 시 diff를 수동으로 처리해야 했다.
Technical Solution
- Welchis 전용 UI 라이브러리 자체 개발: 4개 제품(Cell, Welchis)의 플랫폼별 요구사항(모바일 바텀시트 vs PC 팝업/테이블)을 반영하기 위해 기성 라이브러리 대신 처음부터 구축
- 컴포넌트 기반 API 설계: Multi Select와 Toggle을 결합한 커스텀 컴포넌트 등 기성 라이브러리에 없는 형태를 자유롭게 구현하고, icon-after 같은 일관된 속성명으로 표준화
- Storybook을 통한 컴포넌트 문서화 및 공유: 디자이너가 구현 결과를 즉각 확인하고, 개발자가 API를 일관되게 참조하도록 중앙화
- 두 벌 디자인 시스템 분리: Cell(모바일 iOS/Android/Mobile Web)과 Welchis(PC) 각각 플랫폼과 사용자 가치에 맞게 설계
- Welchis Editor 개발 준비 중: 디자이너가 드래그 앤 드롭으로 프로토타이핑하고 사용된 컴포넌트를 코드로 자동 변환하는 도구 구현 예정
Key Takeaway
자체 UI 라이브러리 개발은 기성 라이브러리의 API 제약에서 벗어나 비즈니스 요구사항에 정확히 맞는 컴포넌트 설계를 가능하게 하며, 멀티 프로덕트 환경에서 단일 변경 지점으로 관리 포인트를 획기적으로 줄일 수 있다.
실천 포인트
2개 이상의 제품을 관리하는 팀이 오픈소스 UI 라이브러리를 사용 중이라면, 커스텀 속성 확장이 반복되고 라이브러리 버그 업데이트 관리가 부담이 될 때 자체 라이브러리 개발을 검토해야 한다. 특히 플랫폼별(모바일/PC) 또는 사용자별(고객/관리자) UX 차이가 크면 여러 벌의 전문화된 디자인 시스템으로 분리해 각 플랫폼의 최적 패턴을 구현하고, Storybook으로 중앙화된 컴포넌트 레지스트리를 운영하면 디자이너-개발자 간 커뮤니케이션 비용을 크게 줄일 수 있다.