병아리 디자인시스템 도전하기
Design System
회사가 자리 잡혀 가는 과정에 따라, 또 개발자들과 디자이너들이 많아짐에 따라 디자인 시스템의 필요성, 또 중요성에 대해서 고민하는 회사들이 점점 많아지고 있습니다. 반복되는 작업의 패턴이 인지되고, 처음에는 느끼지 못했던 관리 차원에서의 문제들이 부메랑처럼 또 하나의 일(Work)로 돌아오는 것을 느끼기 때문이죠.
이러한 고민들은 UI를 'Product'의 관점에서 보기 시작하면서 시작되었을 겁니다. 이에 따라 제품(product)을 구성할 요소들에 대해서 발생하는 사람으로 인한 편차를 줄여야 했습니다. 여러 명의 디자이너/개발자가 제품을 같은 이해도 안에서 바라볼 수 있도록 하는 시스템의 필요성이 생긴 거죠. 어떤 제품을 A라는 디자이너가 디자인하고, 그 후에 B라는 디자이너가 입사했을 때 제품에 미치는 디자인적인 영향도가 방대해지면 안 된다는 겁니다.
즉, 사람의 디자인적 특성에서 벗어나 어떤 제품의 고유 디자인적 특성을 별개로 구축하는 일련의 과정이 필요해졌습니다. 이런 문제점을 해결 위해 고안된 방법 중 하나가 디자인 시스템입니다.
TDS - 비바리퍼블리카 토스팀에서 만든 디자인 시스템저희 팀 또한 같은 고민을 하기 시작했습니다. 회사 디자이너는 3명이고, 프로젝트 초기 UI에 대한 고민과 디자인을 하면서 작지만 서로 다른 차이점들이 보이기 시작했습니다. 시안을 받아 든 개발자들은 혼란이 올 수밖에 없겠죠. 기능적으로는 분명 같은 성격의 버튼 타입들이 중구난방이니까요. 개발자들은 디자인팀에 다수 번의 질문을 할 수밖에 없었고 거기서 생기는 효율의 로스(Loss)가 분명 발생하기 시작했습니다.
우리 팀은 고민 끝에 디자인팀과 개발팀 사이의 약속을 정의하기로 했어요. GUI style 가이드를 만들기로 했습니다. 개발자들의 혼란을 줄이고, 디자이너들의 일관된 디자인을 위해서였죠.
우리는 가장 정신없었던 버튼 타입부터 정의하고, 컴포넌트화 시키기로 했습니다. 버튼에 대해서 넓이, 높이부터 margin, padding 등을 정의했어요. 그리고 버튼의 역할과 상태에 따라 컬러와 shadow 속성 등을 정의했죠. 개발자들은 혼선이 줄었고, 명확히 정의된 컴포넌트들을 활용하면서 효율이 상승했어요.
하나둘씩 정의해 나가기 시작한 컴포넌트들그리고 버튼뿐만 아니라 inputbox, combobox, 표, Dialog 등의 컴포넌트에 대해서도 정의하기 시작했죠. 이 과정에서 우리는 어디까지 컴포넌트를 쪼개야 하는가에 대한 고민을 하기 시작했어요. 각 요소들의 성격 차이에서 느껴지는 필요성과 구현의 효율을 반영했죠. 너무 많이 쪼개게 된다면 그것 자체로 오버 엔지니어링이 될 수 도 있고, 최적화된 소스를 짜기 힘들 수도 있기 때문이죠
현재는 정확히 디자인 시스템이 무엇이다 라고 사전적으로 정의되지 않았습니다. 그게 컴포넌트 라이브러리일 수도 있고, 스타일 가이드일 수도, 디자인 원칙일 수도, 콘텐츠 가이드라인 일 수도 있죠. 여러 현재 실무자 499명 대상으로 한 통계에서는 자신의 프로젝트가 포함하고 있는 디자인 시스템에 대해서 다음과 같이 답변했다고 합니다.
출처 figma컴포넌트 라이브러리라고 답변한 실무자가 86프로나 되었지만, 저는 UI 라이브러리가 존재한다고 해서 디자인 시스템을 구축했다고 할 수 있을까에 대한 고민이 필요했어요. 결국 디자인 시스템이라는 것은 디자인에 대한 체계적인 접근 방식이지 컴포넌트 라이브러리와 같은 요소들은 시스템의 산출물일 뿐이라는 거죠. 그래서 무엇보다 중요한 것은 문서화라는 겁니다.
"여러분은 세계 최고의 디자인 시스템을 가지고 있을 수 있지만, 올바른 문서가 없다면 그것은 본질적으로 실패입니다." - Adekunle Oduye
디자인 컴포넌트, 스타일 구조화 → UI KIT
코드로 구현된 UI KIT + 자동 동기화 → Design System
저는 문서화의 일환으로 많은 회사에서 활용하고 있는 Zeplin을 적극 활용해보기로 했습니다. 먼저 Sketch(필자의 회사는 주로 Adobe XD를 사용하지만 zeplin과의 호환이 더 우월한 쪽을 선택)를 통해 컴포넌트들을 정의하고, Zeplin으로 Export 하여 정리하고 문서화 하기 시작했죠.
이 과정에서 저는 버튼 타입을 정의함에 있어서 컬러까지 정의하는 것이 소모적인 일이었다는 것을 깨달았어요. 왜냐하면 컬러는 글로벌하게 Color Palette로 정의해버리면 되기 때문이었어요. 그게 디자이너와 개발자에게 좀 더 유동성을 부여하기 편했죠.
처음부터 완벽하게 디자인 시스템을 만들고 나서 제품을 개발하는 것은 사실상 불가능하다고 생각합니다. 디자인 시스템을 구축했다고 하는 제품의 대부분은 제품이 먼저 만들어지고 디자인 시스템이 만들어졌다고 해요. 처음부터 시스템의 볼륨이나, 성격을 정확하게 판단할 수 없기 때문이죠.
실제로 40%만이 디자인 시스템을 만들면서 제품을 만드는 작업을 수행했다고 합니다.기존 제품으로 디자인 시스템을 구축하는 것이 나으며 임의의 구성요소를 분리하는 대신 실제 활용 사례를 위한 시스템을 만들어야 한다 - Dan Mall
아직 디자인 시스템을 제대로 활용하고 구축한 회사는 거의 없다고 봐도 될 정도로 디자인 시스템은 매우 어렵고, 걸음마 단계라고 해요. 하지만 제품에 대한 패턴을 정의하고 개발적인 측면의 효율적인 접근을 위해서라면 고민의 여지는 충분하고 앞으로 나아가야 할 방향이라고 생각합니다.
유저와의 엔드포인트에서 디자인의 중요성이 부각되는 최근, 디자이너로서 제품 관점으로 UI를 컨트롤하고 제어할 수 있는 여러 가지 방법 중 하나가 아닐까 하는 생각을 해봅니다.
