let us: Go! 2023 Fall에서 개은님의 디자인 시스템 세션을 정리한다. "디자인 시스템을 이렇게도 쓰는구나" 싶었던 발표였다. 핵심 질문은 UI 프레임워크에 종속되지 않는 디자인 시스템을 어떻게 만들 것인가였다.
디자인 시스템의 구조
발표에서 제시한 구조는 세 층이었다. 디자인 시스템을 이루는 재료를 만들고, 그 재료로 디자인 시스템을 구성하고, 그 위에서 딜러앱과 사용자용 앱 같은 여러 서비스가 디자인 시스템 모듈을 의존해 만들어진다.
STEP 1: 재료 만들기
가장 인상 깊었던 요구사항은 UIKit과 SwiftUI에서 공존할 수 있는 디자인 시스템을 만들고 싶다는 것이었다. 그래서 색상, 이미지 같은 기본 개념을 특정 UI 프레임워크에 묶지 않고 Asset이라는 공통 개념으로 먼저 정의한다.
ColorAsset은 hex, rgb, 이름을 기반으로 초기화할 수 있게 정의한다. 이미지 에셋은 파일 이름, 번들, 포맷(확장자) 정보를 갖고, 자주 쓰는 xcasset에서 파일을 읽어 UIImage로 변환한다. 나중에 다른 확장자를 가진 새로운 이미지 객체가 필요하면 이 구조를 확장하면 되도록 열어둔다. 같은 이미지 에셋이라도 xcasset에서 가져오거나 gif로 정의하는 등 소스를 바꿔 끼울 수 있게 설계한다.
이렇게 재료 단계에서 Asset 종류를 나누면 다음과 같다.
- ColorAsset: 색상
- ImageAsset: 이미지
- FontAsset: 폰트
- ShadowAsset: 그림자
Basic Component
재료 위에 SwiftUI 기반의 기본 컴포넌트를 올린다. 버튼, 토글, 레이블의 구성 요소로 쓰이는 작은 단위를 Icon으로 정의하고, 그 위에 Button 같은 컴포넌트를 조합한다. 색상·이미지·폰트·그림자라는 재료가 프레임워크에 독립적이므로, 그 위에 올라가는 컴포넌트는 UIKit이든 SwiftUI든 같은 재료를 공유할 수 있다.
정리하며
핵심은 디자인 시스템을 UI 프레임워크가 아니라 재료 계층에서 시작한다는 것이다. 색상과 이미지를 UIColor나 Color 같은 특정 타입이 아니라 독립적인 Asset으로 추상화해두면, UIKit에서 SwiftUI로 넘어가는 과도기에도 같은 디자인 언어를 재사용할 수 있다. 디자인 시스템을 컴포넌트 모음이 아니라 의존성 계층으로 바라보는 관점이 오래 남았다.