Do not index
Do not index
디자인 시스템이란?디자인 시스템의 장단점장점단점Reflection1: 디자인 저장소 설계 능력의 부족플랫폼 별 상이한 Styling 원칙에 대한 잘못된 이해 - Typography관리 불가능한, 불필요한 컴포넌트 선언 - SelectControlNomenclature의 중요성 망각 - Icon외부환경에 구애받지 않는, 확장성 높은 설계의 부족 - ButtonReflection2: 디자인 시스템 이용자들 사이의 교류 부족재사용 가능한 컴포넌트의 범주 정의와 디자인 스타일 확정의 어려움합의된 유비쿼터스 언어의 부재로 소통 비용 증가디자인 시스템도 결국은 사람이 선언하고, 사람이 사용한다
안녕하세요, 오토피디아 서비스개발팀에서 앱과 웹을 개발하고 있는 개발자 황반석입니다. 지난 1년간 회사에서 진행했던 사내 디자인시스템(DrCha Design System, 이하 DDS)개발기에 대한 회고내용을 기록하고, 다른 분들에게도 공유하고자 작성하게 되었습니다. 먼저 디자인 시스템에 대한 간략한 소개를 한 후, 저희의 디자인 시스템 적용 회고를 소개하겠습니다.
디자인 시스템이란?
21세기에 들어서며 컴퓨터와 스마트폰 보급이 더욱 활발해지면서, 사람들은 대부분의 삶을 화면과 함께 보내게 되었습니다. 이에 화면 내 보여지는 다양한 정보를 보고, 상호작용할 수 있는 것에 대해 탐구하는 UX/UI에 관한 연구와 적용도 급속도로 확장되고 있습니다. 디자인시스템은 이 흐름에서 복잡해지는 소프트웨어에서 불필요한 반복을 줄이며 확장성있는 디자인과 개발을 위한 고민에서 탄생했습니다. 이에 더불어, 브랜드 아이덴티티로써 사용자들이 이용하는 소프트웨어에서 일관된 경험을 이루게 해주고, 사용자들이 반복되는 요소 위에서 ‘예상 가능한 기능’을 쉽고 빠르게 연결시켜주고자 하는 목적으로서도 활발히 개발되고 적용되고 있습니다.
UX/UI연구의 선두주자로 알려진 Nielsen Norman Group에서는 디자인 시스템을 아래와 같이 정의합니다.
A design system is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels.
디자인시스템은 확장가능한 디자인을 관리하기 위한 기준들의 모음집이다. 이는 다양한 페이지와 채널에 존재하는 불필요한 중복을 줄이고, 매체를 뛰어넘는 공통된 디자인 언어와 일관된 시각 경험을 제공함으로써 실현된다.
There are two important parts to a design system:
- the design repository
- the people who manage it
디자인 시스템은 디자인 저장소(design repository)와 이를 관리하는 사람들이라는 두가지의 중요한 요소가 있다.
디자인 시스템의 장단점
이어서 Nielsen Norman Group에서 이야기하는 디자인시스템의 장단점에 대해서 짚어봅시다.
장점
- 디자인과 개발 업무가 보다 확장성 있고 빠르게 만들어지고 복제될 수 있다.
디자인 시스템의 가장 큰 이점은 사전정의된 디자인 컴포넌트와 요소들을 기반으로 빠르게 복제하고 생성할 수 있게 해준다는 것에 있다. 팀은 이전에 사용하던 요소들을 계속 사용하면서 추가 디자인을 방지하고, 의도하지 않은 비일관된 요소 창조에 대한 리스크를 관리할 수 있다.
- 디자인 리소스 제작에 대한 부담을 완화하고, 보다 크고 복잡한 문제에 집중할 수 있게 한다.
간단한 UI요소들이 이미 생성되어있고 재사용 가능하기에, 시각적 형태를 이리저리 바꿔보는 것에 디자인 리소스를 사용하지 않고 더더욱 복잡한 문제(정보 우선 순위-information priortization, 워크플로우 최적화-workflow optimization, 고객 여정 관리-journey management)에 집중할 수 있다. 이것은 생성해야될 화면수가 적을 때는 차이가 작게 보일 것이지만, 몇십개의 팀과 몇천개의 스크린과 함께 작업해야할 때는 상당히 중요한 요소가 될것이다.
- 여러 영역의 업무에 걸쳐진 팀들에게 공통된 언어를 제공한다.
공통된 언어(unified language)는 잘못된 의사소통에 의한 디자인 및 개발 리소스 낭비를 줄이는데 이는 물리적으로 팀이 분리되어있거나 업무 절차에 의해 디자인 책임자(또는 팀)이 변경될때에 특히 발휘된다. 예를 들어, 드랍다운 메뉴(dropdown menu)의 기능이나 외관에 대한 내용은 이미 디자인시스템에서 정의된 용어이기에 토론되지 않을 것이다.
- 프로덕트, 채널, 그리고 사일로화될 수 있는 부서들을 뛰어넘는 일관된 시각 경험을 제공한다.
특정 팀이 독립적인 프로덕트 운영으로 인해 사일로에 빠진 상태로 일하는 상황에서, 조직 범용적인 디자인 시스템의 부재는 파편화되고 연관이 없는 브랜드 내 요소들이 보여지면서 일관되지 못한 모습과 시각 경험을 줄 수 있다. 디자인 시스템은 한 근원소스의 컴포넌트, 패턴, 그리고 스타일을 제공함으로써 끊어져있던 경험을 통합하여 시각적으로 결합되고 큰 생태계의 일부로 보여질 수 있게 한다.
- 주니어 레벨의 디자이너들과 콘텐츠 제작자들에게 레퍼런스와 교육자료로 활용될 수 있다.
디자인 시스템 가이드라인으로 작성된 사용법과 설명은 조직의 디자인 시스템 관여자로서의 신규 온보딩이나 기존 이용자들의 리마인드용으로 사용되기 좋다.
단점
- 디자인 시스템을 만들고 유지하는 것은 별도의 팀이 필요한, 시간이 많이 걸리는 업무이다.
아쉽게도 디자인 시스템은 한번-만들고-끝나는 솔루션이 아니다. 이를 사용하는 팀과 지속적인 피드백을 바탕으로 계속 진화해야지 최상의 상태를 유지할 수 있다.
- 다른 구성원들에게 디자인 시스템을 공유하고 교육하는 것에 시간이 걸린다.
어떠한 디자인 시스템이든-설령 그것이 기존에 있는 것을 커스텀해서 사용하는 것일지라도, 사용법에 대한 안내와 설명이 필요하다. 그렇지 않는다면 일관되지 못하고 잘못된 화면들이 팀 전반에 걸쳐서 적용될 리스크가 있다.
- 정적인, 한번 만들고 끝인(one-off creation) 프로젝트에서는 재사용 가능한 구성요소에 대한 고민을 안하는게 맞지 않냐는 인식이 있을 수 있다.
실제로 그런지 여부와 관계 없이, 이런 인식은 여러 프로젝트를 걸쳐 효율을 증대시키고 공통된 전략을 가져는게 부족하다는 시그널이 될 수 있다.
사실 디자인 시스템을 적용한 뒤로 다양한 우여곡절을 겪은 끝에 이 장단점을 보게되었는데, 더욱 공감이 되는 부분이 많았습니다. 돌이켜보면, 디자인 시스템의 가장 중요한 두 파트로 이야기되었던 디자인 저장소와 이를 관리하는 사람들에서 부족한 부분이 많았습니다.
Reflection1: 디자인 저장소 설계 능력의 부족
디자인 시스템은 균일한 브랜드 아이덴티티와 동질감을 주고 개발 생산성을 올려줄 수 있는 장점은 있으나, 이는 잘못하면 디자이너의 상상과 개발자의 손을 옥죄는 족쇄가 될 수 있습니다. 잘못 설계된 컴포넌트는 디자이너와 개발자를 모두 혼란스럽고 답답하게 만듭니다.
플랫폼 별 상이한 Styling 원칙에 대한 잘못된 이해 - Typography
Heading에 marginBottom:16이 기본세팅되어있음Ant Design, MUI와 많은 UI라이브러리에서
Typography를 규격화된 폰트 스타일과 함께 디자인 시스템의 컴포넌트로써 제공합니다. 이에 맞춰 대부분의 디자인 시스템에서도 Heading(또는 Title) 컴포넌트의 경우 HTML의 heading tag들과 동일한 맥락으로 기본 margin이 설정되어있습니다. 저희의 앱용 디자인 시스템에서도 동일하게 상하단 마진을 적용하고 UI라이브러리를 완성한 후 개발을 시작했는데, 문제가 발생했습니다.<Container>
<Heading size={1} style={{marginBottom: 0}}>
Lorem ipsum dolo
</Heading>
<Body size={1}>
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum
dolore eu fugiat nulla pariatur.
</Body>
</Container>HTML의 heading tag는 지금 작성된 이 글과 같은 줄글에서 제목으로써 표기하고자 할때 사용되는 태그인데, 이 목적에 맞춰서 생성한 컴포넌트를 모바일 앱 내부의 다양한 목적으로 큰 글자를 위해 사용하고자 하니 사전에 정의해놓았던 Heading의
margin이 화면마다 달라져 무용지물이 된것입니다.다양한 위치에 다양한 패딩값으로 제목이 등장할 수 있는 모바일 앱 생태계 UI의 특성으로 볼때, 아티클 특성을 중심으로 설계된 웹의 Heading styling은 그대로 대입하기에는 상이한 개념이었던거죠.
올바른 사용을 위해서는 모든
Typography의 기본 margin정의를 하지 않거나, 각 화면마다 등장하는 다양한 사이즈의 글자들은 style guide에서 정의되어있는 font theme을 통해 해결하고 HTML의 근본적인 특성과 동일한 긴 글 내에 등장하는 Heading에 대해서만 Typography를 사용해야 했습니다.관리 불가능한, 불필요한 컴포넌트 선언 - SelectControl
DDS에서는 복수개의 선택 옵션 중에 하나의 요소로 선택되어있게 할 수 있도록 하는 SelectControl이라는 컴포넌트를 선언했습니다. 앱을 제작하기전 디자인 시스템을 설계할때는 텍스트만 있는 것을 생각했는데, 앱 디자인을 시작한 후에는 ‘복수개의 요소 중 하나를 선택’이라는 UI에서 너무 다양한 파생형태가 나오기 시작했습니다.
제목이 있는 경우도 있고, border가 없는 다른 스타일의 UI인 경우도 있으며, 옆에 badge표시가 있는 경우도 있었습니다. SelectControl을 명확히 어디까지 사용할것인가를 합의하지 않았기에 한쪽에서는 SelectControl인지 모른채 이를 사용하지 않고 구현하고 있었으며, 다른쪽에서는 끈임없이 prop들을 추가하고 있었습니다. 결과적으로 SelectControl은 상호합의하에 유지보수되며 이용되지 못했고, 방치되었습니다.
단편적으로만 보면 디자인시스템 유지보수의 문제로 보일 수 있으나, 저는 이를 재사용성 있게 확장될 수 있는 UI가 아님에도 불구하고 무리하게 디자인시스템 컴포넌트화 했던 시도가 잘못된 것이라고 생각했습니다.
Ant Design과 같은 엔터프라이즈용 디자인시스템에서는 원시적인 컴포넌트(Button, Icon 등) 이외의
SelectControl과 비슷한 역할군도 디자인시스템으로서 관리될 수도 있겠지만, 보통의 디자인 시스템에서 이러한 복잡한 컴포넌트를 편입시키는 것은 불필요한 소통비용 증가와, 디자인 가능성을 억제시키는 부채로 작용한다는 것을 느꼈습니다. 
Nomenclature의 중요성 망각 - Icon
모든 업무에서 가장 중요한 것은 소통의 최적화이고, 이를 위해서는 일관된 원칙과 지속가능한 명칭들에 대한 정립이 중요합니다. 디자인 시스템을 정립하고 운영하는 것에서도 구성원들 사이에서 컴포넌트들을 어떤 원칙을 가지고 정의하고 확장해나가야될지에 대한 깊은 논의가 필요했으나, 부족했습니다.
아이콘은 디자인 시스템의 구성 중 하나로써 서비스의 일관된 디자인 정체성을 표현하는데 중요한 요소 중 하나입니다. 오토피디아의 메이커 구성원도 이런 의도에 맞춰 독자적인 아이콘 묶음을 구성했는데 아래의 시행착오들이 있었습니다.
- 명시적이고 확장가능한 이름 짓기를 적용했어야 했다.
같은 형상을 표현하고 있는 아이콘이더라도 특성값(thickness, roundness, filled/outlined)에 따라 보여지는 모습이 많이 다릅니다. 처음 사용할때는 이런 특성값들 중 하나에 해당하는 아이콘만 사용하겠지만, 추후에는 동일한 형상이지만 다른 특성값인 아이콘이 도입될 상황이 충분히 있을 수 있습니다.
추후에 다른 특성값의 아이콘이 들어올때 그리고 어떤 아이콘인지를 명확히 지칭하기 위해 각 아이콘의 명칭에는 이러한 특성값들이 어떠한지 표현되어있어야 했습니다.
동일한 형상 뿐만이 아닌 다른 형상을 가진 아이콘에 대해서도 동일하게 적용됩니다. 언뜻봐서
bag라고 붙이면 될 것 같아 bag라고 붙였다가는, 차후에 들어올 다른 아이콘들에 대한 이름짓기가 곤란해질 수 있습니다.- 사용되는 기능에 의거하지 않은, 모양에 의거한 이름 짓기를 했어야 했다.
디자인 시스템이 적용되는 서비스가 계속 업데이트되고 변화되기 때문에, 디자인 시스템도 이에 발맞춰 계속 업데이트 되기 마련입니다. 하지만, 디자인 시스템은 엄연히 서비스의 의도와는 독립적인 주체로서 기능에 의한 이름짓기보다는 시스템 그 자체로 존재할 수 있는, 모양에 의한 이름 짓기를 적용해야 한다는 것을 깨달았습니다.
위 그림에서 보이는
upvote는 닥터차 서비스 내 댓글의 좋아요 싫어요를 보여주는데 사용했던 아이콘인데, 당시 댓글의 투표기능을 한다고 해서 upvote라고 명명했습니다. 허나 곧 댓글 뿐만이 아닌 다른 곳에서도 따봉~의 의미로서 아이콘을 사용해야되는 순간이 왔는데, 기존의 아이콘 명칭이 vote라는 닥터차 서비스 내 기능에 종속된 목적으로서 부여된 이름이었기에 해당 작업에 참여하지 않았던 구성원은 아이콘이 등록되어있는지 찾기도 어려웠을 뿐더러, 적용한 이후에도 아이콘 명칭은 upvote인데 하는 비즈니스로직은 like에 가까운 기이한 상황이 발생했습니다.만약
upvote가 thumbs_up-outlined였다면, 댓글 투표 기능을 몰랐을 구성원도 좀 더 쉽게 아이콘을 찾을 수 있으며, 다양한 공간에 적재적소로 배치가 되더라도 문맥에 문제가 없었을 것입니다.- 디자이너↔개발자 간의 괴리가 발생하지 않도록 동일한 명명법, 사용법을 정립했어야 했다.
위에서 이야기되었던 아이콘은 실제 적용에서도 문제가 있었습니다. 디자인 조직에서는 피그마에서 모든 아이콘을 넣을때 아이콘을 사이즈별로 다르게 정의하고 바라보는 반면, 개발 조직에서는 아이콘 디자인 시스템 구현체를 적용할때 한 아이콘 이미지 파일을 기준으로 사이즈를 조절하는 관점으로 봤습니다. 시작할때는 작은 차이였지만, 다양한 굵기와 사이즈의 아이콘이 들어가고 적용되는 순간부터 컴포넌트 명칭이 상이한 상황이 발생해 개발자는 개발자대로, 디자이너는 디자이너대로 난처한 상황이 종종 발생했습니다.
더구나 여기서 디자이너의 아이콘 정의 기준과 개발자의 정의 기준이 다르기에 아이콘 명명법도 서로 달라졌고, 결국에는 아이콘 코드 구현체와 디자인 명세서의 괴리가 너무 커져버렸습니다.
개발자들과 디자이너들이 디자인 시스템 개발 과정에서 이런 부분도 계속 소통하여 디자인 파일은 어떻게 정의되어있고, 실제 코드 구현체는 어떠한 방식으로 적용되었는지 등을 교류했다면 이 괴리가 발생하지 않았을 것입니다. 어떤 것들을 아이콘이라고 칭하는지, 아이콘의 명명법은 어떻게 합치시킬지, 아이콘에 outline stroke를 처리하여 사이즈에 대응가능하도록 정의했어야 했는지, 색상값에 대해서는 어떠한 방식으로 적용시켜야될 지 등 많은 의사결정이 디자인시스템 제작과정에서 이루어졌다면 실제 서비스에서의 적용은 훨씬 적은 소통비용으로 작업이 진행될 수 있었을 것입니다.
이러한 인사이트들은 비단
Icon이 아닌 디자인 시스템의 모든 작업과정에서 한번 더 고민하고, 생각해볼 수 있는 요소라고 생각합니다.외부환경에 구애받지 않는, 확장성 높은 설계의 부족 - Button
디자인 시스템은 실제 서비스에서 활용하는 재료들을 구축하는 작업이기에 이 재료들이 어디서 어떻게 적용되더라도 문제없이 활용될 수 있도록 설계하는 것이 중요합니다.
처음
Button 컴포넌트를 선언할때는 뒷 배경색이 흰색일 경우를 기준으로만 생각하고 border-color를 완전 불투명한 고정 색상으로 제작했는데, 버튼이 임의의 배경색을 가지는 화면 위에 올라와야하는 상황이 오자 border-color 가 배경색과 같은 색상인 경우 그리고 유색 배경색에서 묘하게 안어울리는 상황이 발생했습니다. 
이와 비슷한 상황은
onPress 발생 시 버튼 배경색에 변화를 주는 상황에서도 동일하게 발생했습니다. opacity를 변경하는 방식으로 적용하지 않고(ex. onPress 시 opacity 1 → 0.7) 특정 색상으로 변경하는 것만을 생각했는데, 흰색 배경의 화면이 있는 전체상황에서는 문제가 없었으나 유채색 배경이나 사진이 배경으로 들어가는 상황에서는 해당 로직이 적용된 DDS 버튼을 결국 활용하지 못했고, Button 컴포넌트는 점점 방치되었습니다.Reflection2: 디자인 시스템 이용자들 사이의 교류 부족
위에서 언급되었던 여러가지 실수들을 보았을때 디자인 시스템 제작과 운영에 대한 조직의 지식 수준에도 부족함이 있었지만, 시간이 지나고 뒤돌아보니 무엇보다 부족했던 것은 디자인 시스템을 함께 관리해나가는 사람들간의 소통의 부족함이 더욱 문제였음을 체감했습니다.
재사용 가능한 컴포넌트의 범주 정의와 디자인 스타일 확정의 어려움
완성된 서비스를 보고 이야기를 해보기 전까지는 서비스 내에서 일회성으로 사용되는 UI요소들과, 이중 재사용성이 높아 컴포넌트로 빠질 수 있는 UI요소를 명확히 구별하고 확신할 수 없음을 여러번 겪었습니다. 이로서 디자인 시스템 정립과 적용은 범용적인 UX/UI를 만드는 과정으로서, 신규 디자인 프로덕트 런칭이 아닌 기존 디자인의 리펙토링에 가까운 작업임을 알았습니다.
디자인 시스템이 초기에 선언한 그대로 활용될 일은 없고 지속적인 유지보수가 필연적인 상황에서, 끊임없는 소통을 통한 컨텍스트 업데이트가 되어야만 디자인 시스템이 시스템으로서 관리될 수 있겠다는 느낌이 들었습니다.
한번에 완벽할 수 없다. 계속 소통하여, 하나씩 수정하며 발전해나가자.
합의된 유비쿼터스 언어의 부재로 소통 비용 증가
Typography라는 한 컴포넌트를 보는 관점에서도, 피그마의 Font Theme관리법과 코드 구현체에서 선언하고 관리하게될 컴포넌트에는 시선의 차이가 있습니다. 이 시선의 차이가 있음을 서로 인지하고, 합의하여 서로가 디자인 시스템의 한 구현체에 대해 어떤 식으로 생각하고 부르고 있는지에 대한 소통이 없다면 이후 서로 이야기를 할때 서로의 단어의 의미와 문맥을 이해하지 못하게 되고, 혼란을 불러오게 됩니다. 이 혼란을 회피하는 그 순간부터, 디자인 시스템은 무너지기 시작합니다.디자인 시스템도 결국은 사람이 선언하고, 사람이 사용한다
설계의 오류 외에도 우리의 일하는 방식에 뭔가 문제가 있지않았나? 싶었는데, Design Systems 101 글을 통해 결국 중요한건 함께 일하는 사람들에게 있음을 알게되었습니다.
디자인 시스템의 탄생 목적이 조직 차원에서 효율적으로 일할 수 있도록 서포트 해주는 것에 있기에 결국 가장 중요한 것은 이를 활용하는 사람들에게 있습니다. 어떻게 선언된 디자인 시스템을 지속가능하게 유지하고 관리할 수 있을까에 대한 고민을 지속적으로 해나가는 것이 정말 중요하다는 것을 다시 한번 되짚어봅니다.
잘 만드는 것도 중요하지만, 합의한 내용을 잘 숙지하여 규칙에 맞게 사용하도록 관리하는 것이 더 중요하다
디자인시스템을 설계하는 과정에서도 이렇듯 많은 우여곡절이 있었지만, 설계한 디자인시스템을 구현체로 만드는 과정에서도 다양한 문제점과 개선점들이 존재했습니다. Part2에서는 디자인시스템 코드 구현체 관리방법, Atomic Design의 접근법을 차용한 프로젝트 구조에 대한 고찰 등 설계한 디자인시스템을 구현하고 적용하면서 받았던 여러 개발 관점의 인사이트들에 대해 공유하고자 합니다.
글쓴이
