ZEN of UX. 28 - 디자인 시스템은 반드시 필요한가.

사실 나는 디자인 시스템을 신봉하는 편이었어.

디자이너라면 모름지기 디자인 시스템까지 해 봐야 진정한 디자이너라고 생각했기 때문에, 나는 에이전시 시절부터 (시스템 가이드가 필요 없어 보이는 경우에도) 꾸역꾸역 디자인 시스템을 만들었었어. 덕분에 국내 유수의(?) 서비스 디자인 시스템들을 만들어 보는 행운도 누렸지. 디자인 가이드, UX 가이드, 디자인 랭귀지, GUI 가이드 등 - 이름과 범위도 다양했고, 그중 몇몇은 수년간 운영, 관리까지 해 보았는데, 개인적으로는 정말 값진 경험이었어.

나뿐만 아니라, 다른 디자이너들도 (디자인 시스템에 대한) 생각은 비슷한 것 같아. 

나는 디자이너를 채용하기도 해서 정말 많은 포트폴리오를 검토하는데, 상당히 많은 아이들이 디자인 시스템을 만들고 운영한 경험을 강하게 어필하더라구. 디자인 시스템을 구축하는 일이 마치 UX 업무의 종착역같고, 모든 디자인을 통제한다는 우월감을 주기도 하잖아. 또 포트폴리오라는 게 대개 새 회사에 지원하기 위해서 만들어지는 물건이다 보니, "디자인 시스템 제작, 총괄"같은 단어가 자신의 몸값을 올려준다고 생각하는 것 같기도 해. 뭔가 뽀대도 나고 말이지. 이해해^^

하지만, 인하우스로 전향한지 7년 정도 지난 지금은 디자인 시스템에 대한 관점이 조금 바뀐 것 같아. 인하우스(또는 스타트업)의 특성상 디자인 시스텡을 구축하는 것이 대기업이나 기성 서비스들, 또는 OS레벨에서의 효용과는 확실히 다르더라구. 그래서 요즘 생각은 - 디자인 시스템은 반드시 필요한 걸까 하는 — 다소 회의적인 입장이야. 

---

이 글을 더 발전시키기 전에, 디자인 시스템이라는 용어를 한 번 짚고 넘어가야 할 것 같아. 내가 앞으로 말하려는 디자인 시스템은 다음과 같아. 

일단, 범위는 UX, UI, GUI로 한정 : 웹과 앱을 중심으로 얘기하겠지만, 일부는 브랜딩 관점도 섞여있을 수 있어. 내가 말하려는 디자인 시스템은 단일 서비스를 위해 만들어진다는 걸 전제하지만, 회사에 따라 여러 개의 앱과 웹은 물론 오프라인 서비스까지 확장할 수 있어. 이건 다음과 같은 요소로 분류할 수 있을 텐데, 서비스의 특성에 따라 이 중에서 몇 개를 빼거나 더할 수도 있다고 생각해. 용어는 분명하게 확정하진 않을 텐데, 디자인 시스템이든 UX 가이드든 디자인 랭귀지든, 그 디테일한 속성을 여기서 얘기할 건 아니니까. 

designsystem.line.me

① UI 구성요소 : 디자인 시스템에서 가장 핵심이 되는 결과야. 아마도 이게 디자인 시스템의 가장 최소 사양일 거야. 주로 버튼, 카드 및 모달, 바텀시트, 팝업 등의 UI를 정의하는데, 여기서 포인트는 다양한 UI들 중에 왜 이것을 선택했고, 저것은 채택하지 않는지, 그리고 어떤 경우에 사용하고, 다른 경우에는 사용하지 말아야 하는지를 정의하는 일이야. 서비스에 일관성을 부여하는 시각적 기초 요소이기 때문에 (활용하는 사람이) 바르게 이해하고 사용할 수 있도록 하는 게 중요해. 여러 서비스의 디자인 시스템을 유심히 살펴 보면, 같은 UI 엘리먼트를 설명할 때도 각자 다른 방식으로 기능과 역할을 설명하는 것을 볼 수 있어.

kakaobusiness.gitbook.io

② 플로우 : 유저가 서비스를 이용할 때의 경험을 시간 순으로 나열할 때, 유저에게 어떤 경험을 제공할지를 고민하기 위해 필요한 게 플로우 정의야. 유저의 직관적인 사용이 중요한 경우에는 단계를 잘 느끼지 못하도록 부드럽게 나열하는 것이 중요하고, 오차가 없이 정교한 작업을 해야 할 때는 중간중간에 유저에게 현재의 상황을 알려주는 형식으로 플로우를 짜야겠지. 그보다 더 중요한 건, 서비스 내 각각의 기능을 최대한 동일한 방식으로 사용할 수 있도록 돕는 일이야. 주로 사용자 경로, 상호 작용 패턴, 탐색 구조 정의등이 포함되는데, 이는 서비스 뿐만 아니라 회사의 개발환경도 참고해야 해.

carbondesignsystem.com

③ 컬러 : 유저가 가장 직관적으로 느끼는 시각적 요소 중 하나야. 당연히 브랜딩 관점에서도 중요한 요소이지만, UI, UX 관점에서는 브랜딩 부서보다 더 많은 것을 고려해야 해. 기본 색상과 보조 색상, 배경, 강조 표현을 위한 색상뿐만 아니라, 가끔은 섀도우와 그라데이션까지 포함하기도 해. 색맹/약자들을 위한 색상의 선택도 필요하고, 유저가 프로덕트를 사용하는 환경 (야외, 밤, 빗 속, 수중 등)도 감안해야 해. 색상의 감각적인 심상도 중요하지만, 기능적인 속성도 충분히 고려해야 하지. 유저의 접근성과 가독성을 최대한 보장하는 방향으로 전개해야 하지만, 유저의 환경(연령, 성별, 사용환경)을 고려해서 유동적으로 결정할 수 있어.

polaris.shopify.com/design

④ 타이포그래피 : 디자인 시스템 중 내가 가장 중요하게 생각하는 부분이야. 폰트와 패밀리, 크기, 자간과 행간, 스타일 등을 말해. 텍스트는 기본적으로 정보 표현이므로 가독성과 지시성, 정보 위계 설정이 제일 중요하고, UX writing과도 직접적인 연결점이 있어. 또한 디바이스 환경을 고려해야 할 때도 있어. (긴 숫자열이 들어가는데 폰의 너비가 한계가 있을 때 condensed 서체를 사용한다던지)

⑤ 간격 및 레이아웃 : 유저가 만나는 모든 화면의 일관성을 부여하고, 새로운 화면을 이질감 없이 받아들이기 위해서 반드시 정의되어야 하는 내용이야. 여백, 패딩, 그리드 시스템, 정렬 방식, 카드 단위의 모듈화 등이 포함되지. (위에서 말한 UI 구성요소에 포함되는 내용이지만, 중요성이 커서 따로 적었어.)

© wolff olins

⑥ 아이콘 및 이미지 : 아이콘의 크기, 스타일, 사용법 측면에서 일관성을 갖도록 해야 하는데, 이것도 어느 정도 브랜딩과 연결되어 있어. 꽤 많은 서비스들이 텍스트와 이미지, 그리고 아이콘으로만 구성되어 있는 상황이라, 서비스 플로우 안에서 브랜드를 느낄 수 있도록 하는 데에는 아이콘만한 게 없지. 반면, 이미지 가이드는 많은 서비스에서 브랜딩이 키를 잡고 가는 경우가 많은데, 29cm처럼 섬네일의 가이드를 분명하게 제한하는 경우는 디자인 시스템에서도 많은 개입이 필요하지. (내 논의에서는 디자인 시스템 안에 브랜딩을 포함시키지 않았어. 사람에 따라 다르게 보겠지만, 나는 마케팅과 브랜딩을 묶어서 한 축으로 보는 편이라서)

⑦ 상호작용 : 애니메이션이나 트랜지션을 말하는데, 서비스 사용에 직접적인 가치를 주지는 않지만, 잘만 쓰면 사용자 경험을 쾌적하게 만드는 데 큰 기여를 해. 프레스, 릴리즈, 호버, 클릭시의 효과, 화면 전환을 포함한 유저의 피드백을 애니메이션으로 강조하거나 안내하는 역할을 해. OS별로 구현 난이도가 서로 다르기 때문에 iOS, aOS를 서로 다르게 만들기도 해. 이것도 개발환경 고려가 필수야.

toss.tech

⑧ 문서화 및 지침 : 디자인 시스템이 일정 규모를 넘어서면, 가이드 자체보다 문서화하는 것, 또는 사용 용례를 제작하는 게 더 중요해지기도 해. 많은 디자인 시스템이 이를 생략하거나 소흘히 생각하는 편인데, 디자인 시스템의 기본 정신을 담아야 하기 때문에 나는 중요도를 아주 높게 여기는 편이야. 구성 요소들의 사용 방법 및 업데이트와 배포의 방법과 가이드, 품질 유지 방안 등을 포함해. 새로운 구성원이나 조직이 디자인 시스템 안으로 들어올 때 온보딩을 담당하기도 하고, 디자인 및 개발 프로세스를 효율적으로 다듬는 데 중요한 역할을 해. 이게 명확하지 않으면 서비스를 확장하거나 발전시키는 데 어려움을 느끼게 될 거야. (위 토스 이미지처럼, 직종에 따라 문서에서 얻어내려는 정보가 다르다보니 문서를 사용하는 패턴도 서로 달라서, 문서의 hierarchy나 탐색 흐름도 고려해야 해. 가이드의 가이드가 필요한 셈이지.^^)

⑨ 개발 환경과의 연동 : 아주 발전된 레벨의 디자인 시스템은 개발 환경과 직접적으로 연동되기도 해. 아예 개발자의 코드까지 문서를 연결해 놓으면, 페이퍼로 간단히 구성한 것을 바로 구현까지 이을 수 있게 되지. 개인적으로는 여기까지는 가보지 못했고, 언젠가는 해보고 싶은 작업이기도 한데, 막상 이렇게 구현해 놓은 다음에는 어떻게 확장, 관리, 변경해야 하는지 생각하면 조금 아득한 느낌이 들기도 해.

---

정리한 내용을 보면, 모두 다 필요해 보이긴 하지만 실제로는 이만큼 구현하는 경우는 별로 없어. 위에 넣은 이미지들은 대부분 대기업 규모의 서비스라 저렇게 리치하게 만드는 게 가능하겠지만, 이 글을 읽는 사람들이라면 (심지어 대기업에서 일하는 사람이라도) 이만큼의 규모를 총괄하는 경우는 없을 거라고 봐. ^^ 실제로 내가 받은 디자이너들의 포트폴리오를 보면, 이 중에서 폰트와 컬러 정도만 담고 '시스템'이라고 부르는 경우가 정말 많고, 조금 더 가는 애들은 아이콘까지. 모듈이나 문서화까지 포함하는 경우는 정말 극소수인 것 같아.  (나 역시도 포폴에는 담지 않았음^^)

자, 그럼 이제 본론 : 디자인 시스템은 반드시 필요한가. 언제 필요하며 왜 필요한가.

위에서 가장 발전된 케이스라고 말한 ⑨ 개발환경과 연동할 수 있게끔 고도화된 디자인 시스템의 경우, 디자이너의 개입 없이도 개발 레벨에서 여러 실험을 할 수 있다는 게 가장 큰 장점이겠지. 목표와 요건이 갖춰지면 시스템에서 필요한 어셋을 확인하고, 기준의 UI를 결합해서 간단하게 목업을 만들 수 있으니까. 빠른 테스트와 실행이 필요한 스타트업에서 가장 필요한 방식이지만, 이런 형태의 시스템을 만들기 위해서는 많은 일정과 인력이 필요하기 때문에 실현 가능성은 떨어져. 

고도화된 시스템이 아니더라도, 시스템은 그 존재만으로 불필요한 고민을 덜어주는 역할을 해. 구성원들이 시스템과 그 산출물을 대충 확인하기만 해도 대충 머릿 속에 구현된 최종 이미지를 상상할 수 있게 되는 거지. 일을 할 때 많이들 느꼈겠지만, 함께 얘기할 그림이 있어야 토론이 활발해지는 법이거든. 딱 맞는 형상이 아니더라도, 우선 함께 얘기할 수 있는 그림이 있는 게 중요해. 그림을 기준으로 컨센서스를 맞춰 나가는 게 훨씬 쉽고, 개념적인 내용을 실체화 하게 되면 보다 현상과 문제가 뚜렷이 드러나는 법이니까. 하지만 이건 장점인 동시에 단점이기도 한 게, 상상력의 제한을 거는 반대 효과도 일어나지. 우리의 ‘어셋’ 안에서만 문제를 찾으려고 하면 새로운 접근법, 즉 낯설지만 유용한 새로운 해결책을 찾는 데 보수적인 태도를 만들기도 해. 각 이해관계자들의 열린 마음, 창의적인 태도가 필요한 부분이야.

확실히, 디자인 시스템은 한 명 이상의 역할을 충분히 하지만, 그 한 사람 몫을 만들어 내야만 하는 건 또 다른 얘기야. 또한, 이렇게 만들어진 한 사람 몫의 역할은 계속 관리해 주지 않으면 서비스의 레가시로 남게 되어서 장애물이 되기도 하거든. 시스템을 관리하는 데에만 한 사람 이상의 인력/시간이 든다면, 차라리 헤드나 시니어가 시스템 역할을 수행하는 게 낫지 않을까? 회사의 규모와 협업 대상자의 규모에 따라 판단할 일이야.

---

UI, UX는 고정된 정답을 제시하는 학문이 아니고, 시간의 지나면서 계속 개선되거나 새로운 기술을 녹여 변형되기도 해. 생각보다 그 주기는 빨라서, 지금보다 3~4년 전 시스템만을 이용해서 디자인하려면 금세 답답함을 느끼거나 불완전함을 느끼게 될 거야.

그래서 디자인 시스템을 만드는 데에는 타이밍이 매우 중요해.

서비스 내적인 상황은 물론, 비즈니스적인 상황까지 맞아떨어질 때를 잘 찾아야 하는데, 그게 어디 쉽나. 나도 그 타이밍을 명확하게 예측하지는 못하고 있지만, 일단 내가 생각하는 적절한 타이밍의 요건은 다음과 같아.

• 서비스가 성숙한 단계에 들어섰는가, 확장이나 피봇의 단계에 있는가 : 서비스는 횡적인 확장을 하기도 하고, 종적으로 성장하기도 하지. 서비스에 새로운 기능이나 개념이 도입되는 시점에 있다면, 확장하기 직전에 시스템을 구축하는 게 좋아. 새로운 걸 하기 전에 한 번 정리를 해 두는 게 확장의 안정성에도 도움이 되지. 때문에 사업의 방향성을 이해하거나 예측하는 능력이 필요해.
  
  
• 기술부채의 양과 영향력 : 기술부채가 많은 상황에서 무리하게 시스템을 구축하려다 보면, 시스템과 함께 기술부채까지 함께 고착되어 버리는 경우가 있어. 엔지니어 부서와 협의를 해야 하겠지만, 기술부채를 털어내는 시점이라면 시스템을 함께 구축하는 것도 좋겠지.
  
  
• 구성원 간의 콘센서스는 어떠한가 : 위 두 경우는 서비스의 안정성이 흔들리는 시점이라고 하면, 이 경우는 내부 구성원들이 바라보는 시선이 서로 다르다고 느껴질 때라서, 내부의 혼란을 잠재우고 중심을 잡기 위함이 가장 큰 목적이 되어야 해. 신규 인력이 많이 유입되었거나, 외주사가 생겼다던지 다른 회사와 병합했다던지 할 때도 마찬가지. 이 경우는 위 두 케이스보다는 조금 더 학구적이어서, ⑧ 문서화나 지침 등을 먼저 진행해야 해. 이를테면 서비스의 모든 부분을 서비스 고유의 방식으로 ‘정의’하는 일이지. 이 때는 당연히 서비스의 핵심가치나 회사의 모토 등까지 고려하여 다시 세팅하는 것이라서 조금 더 큰 규모로 진행해야 해.
  
  
• 시스템 구축의 마일스톤이 세워졌는가 : 디자인 시스템의 속성상 한 번에 짠! 하고 공개하는 게 가장 효과가 좋아. 아무리 수시로 청소를 하더라도 대청소 한 번만 못한 것과 같지. 하지만 실제로 그렇게 에너지를 모아서 한 번에 정리하는 건 실무의 현실상 쉽지 않아. 그래서 대부분은 최소한의 규정 (대개는 컬러와 폰트, 그리고 간단한 모듈레이션까지)을 우선 만들고, 거기에 살을 붙여 가다가 짠! 하고 공개하는 게 현실적이지. 그런데 여기서의 주의점은 합리적인 계획이 있는가야. 아이들이 전신을 그릴 때 머리부터 그리다가 다리가 조막만 해 지는 것 본 적 있지? 시간 날 때마다 조금씩 구축해 나아가는 경우, 맨 마지막 조각을 맞출 때쯤엔 대내외적으로 가치나 방향성이나 목적, 스타일 등이 바뀔 수 있다는 점을 주의해야 해. 그래서 시간이 지나더라도 이 시스템이 어디를 지향하고 있는지를 명확하게 해 두고 진행과정에서 계속 참조할 수 있는 방식을 고민해 보아야 해. (한동안 많은 서비스들이 자사의 디자인 시스템을 일반에게 공개했었는데, 요즘은 하나둘씩 비공개로 전환하고 있어. 한때는 디자인 시스템 페이지가 홍보의 역할도 한다고 믿었던 시절이 있었는데, 이제는 그렇지 않은 모양이야.)

길게 썼지만, 내가 기본적으로 생각하는 시스템의 효용은 다음의 세 가지로 요약할 수 있어. 첫번째, 디자이너들 간의 의사소통을 간결히 하기 위해서. 두번째, 엔지니어들에게 전달하는 내용의 투명성 확보를 위해서. 그리고 마지막으로 서비스와 브랜딩의 일관성을 위해서. 서비스에 따라 이 세 가지를 모두 충족해야만 하는 경우도 있고, 이 중 하나만을 위해서 제작되는 시스템도 가능해. 하지만, 제일 안 좋은 것은, 어떤 목적을 위해서 시스템을 만드는지 분명하지 않은 상태로 제작하는 경우야.

---

우리가 만드는 서비스는 대부분 자본주의제도 안에서 이익을 만들기 위함이고, 이는 필연적으로 확장해야만 하지. 하지만, 디자인 시스템은 확장이 아닌 수렴을 위해서 존재한다는 걸 유념해야 해. 디자인 시스템은 속성 자체가 대상을 정의하는 것, 즉 현재를 정리해서 고정하는 일이니, 지표는 될 순 있어도 목표가 될 순 없어.

시스템에 지속적인 생명성을 부여할 상황이 되지 않거나, 미래가 그렇게 되리라는 긍정적인 신호가 없다면, 굳이 시스템을 만들자고 레거시를 부정하거나, 재논의를 위해서 에너지와 자원을 투자하는 것은 옳지 않다고 봐. 실제로 “그럼에도 불구하고”로 만들어진 시스템은 실제로 시스템을 사용해야 하는 사람들을 설득하기 힘들어.

대부분의 디자이너들이 그리는 판타지는, 마치 시스템이 만들어지면 모두 자세히 시스템을 탐독하고, 순순히 따라 줄 것으로 생각하지만, 겉으로든 속으로든 동의하지 않는 부분들이 있을 거고, 심지어 최악은, 모두의 관심을 받지 못하는 상황도 생길 수 있어. 그러니까, 시스템을 만들기로 결정할 때 위 내용이 참고가 되었으면 좋겠고, 신중하게 생각하길 바라.

많은 사람들이 디자인 시스템을 마냥 있으면 좋은 것으로 생각하는 것 같아서 길게 글을 써 봤어.
이 내용은 절대적으로 개인적인 생각일 뿐이니, 반박시 네 말이 맞음. ^^