초기 디자인 시스템 개발
디자인 시스템을 개발할 때 처음부터 작게 만들 것이냐, 각잡고 완벽하게 만들 것이냐 선택을 해야 한다. 개발자라면 누구나 각잡고 완벽하게 만들고 싶을 것이다.
하지만, 우리가 처한 상황은 빠르게 디자인 시스템을 개발한 후에 리뉴얼을 하면서 성과를 내야 했기 때문에 검증 기간을 포함하여 디자인 시스템 개발을 1달안에 끝내야 했다. 1달안에 완수하기 위해서는 요구되는 각 상태별 디자인들을 꼼꼼히 반영하고, basic한 기능을 제공하고, 검증할 수 있는 환경을 구축하는 것이 최선이었다.
기본적인 컴포넌트들은 그래도 많은 부분을 신경쓸 수 있었지만 select, menu, dropdown 어떤 형태가 나올지 모르는 리스트형 컴포넌트는 다양한 변수에 대응하기 위해 사용처에서 상황에 따라 조립해서 사용할 수 있는 Atomic한 설계방식을 채택했다.
Atomic 한 방식은 처음에는 잘 돌아가는 듯 보였다.
하지만, 시간의 흐름에 따라서 Dropdown의 경우 더 많은 요구사항이 들어오게 되었는데 Select와 Dropdown과 Menu가 하나로 결합된듯한 이 형태의 디자인 시스템은 많은 복잡도를 야기시켰고, 결국 사용처마다 다른 사용방식을 불러오게 되었다. 이는 개발자의 DX를 떨어트리는 원인이 되었다. 패착이었다.
디자인 시스템을 점검해야 할 때
디자인 시스템을 손 봐야겠다고 생각하고 있던차에 다른 팀과 합쳐지면서 여러개의 디자인 시스템이 존재하게 되었다. DX를 위해서 디자인 시스템을 통합하고 점검하는 시간이 주어져서 이번에는 기획자와 많은 소통을 거쳐 조금 더 Strict한 디자인 시스템을 설계하기로 했다.
기존에 반쪽짜리 Token들도 재점검하기로 했다. 예를 들어, font나 Dimension을 토큰화 시켜놓고 기획서에서 Token에 없는 수치를 갑자기 요구하는 경우도 많아서 혼란을 유발하기도 했다. 또한 Token값을 보고 정확히 어떤 값인지 기억하는 것도 쉽지 않았다. 예를 들어, font의 경우 b1 이번에 합친 B디자인 시스템에서는 18px인데 기존에 사용하고 있던 A디자인 시스템 16px이기도 해서 대혼란이 발생했다. Dimension도 마찬가지였다. 모바일일 경우 저렇게 설정된 값을 사용하다가 일괄 변경하는 것이 의미 있을수는 있지만 데스크탑 환경에서 수십 페이지에 사용하는 경우는 무의미하다고 생각했다. 모두 효과대비 불편한 사용성에서 공감하여 Dimension은 제거하고 Font는 Token네이밍에 직접 폰트 크기를 적는 방식으로 변경하기로 했다.
디자인 시스템 지금도 직접 하나하나 다 만들어야 할까?
이번에 개선하는 디자인 시스템 컴포넌트들은 Headless UI인 RadixUI를 일부 사용해보기로 건의했고, 발탁됐다. 디자인 시스템을 만드는데 왜 갑자기 컴포넌트 라이브러리를 사용하는지 의문이 들 수 있다. RadixUI는 접근성, Uncontrolled/Controlled 지원, 스타일만 입히면 바로 사용할 수 있는 이점 등 잘 적용하기만 하면 굉장히 파워풀 할 것이라고 생각했다. 또한, 현재는 대중적으로 공인된 디자인 시스템이 많은데, 우리가 내부적으로 새로 만드는 것은 최대한 신경을 쓰려고 하더라도 디자인 시스템을 전담하는 팀이 아닌 이상 전 세계적으로 사용하는 디자인 시스템만큼 완벽하게 만들기는 어렵다는 판단을 했다.
조만간 RadixUI, base UI로 디자인 시스템 일부를 고도화해보고 사용 후기를 또 작성할 것 같다.