디자인시스템 101

design system 101 hero image

여태까지 실무에서 총 3번의 디자인시스템을 만들려고 시도했었다. 매번 디자인시스템이 왜 필요한지, 무엇인지 깊이 생각해 보지 않았고 제대로 알지도 못한 채 유명한 레퍼런스만을 따라 하며 만들기 급급했던 것 같다. 결국 3번의 시도들은 아예 빛도 보지 못했거나, 개발팀만을 위한 컴포넌트 라이브러리가 되었거나, 유지보수 인력 부족으로 레거시 프로젝트로 전락했다.

시스템이 만들어지고 적용되는 과정에서 디자인과 개발팀뿐만 아니라 서비스와 연관된 거의 모든 팀에게 영향을 미치기 때문에 사내 전반의 이해가 바탕이 되어야 하는 큰 프로젝트 중 하나임을 뒤늦게 알게 되었다. 디자인 시스템을 정말 제대로 적용한다면, 이는 지금 존재하는 디자인요소뿐만 아니라 앞으로 미래에 개발하게 될 모든 요소들 또한 디자인 시스템을 따른다는 뜻이기도 하다. 일회성으로 끝나는 것이 아니기에 운영에 대한 고려도 충분히 되어야 한다.

이렇게 제대로 된 디자인시스템은 디자인과 개발의 짧은 협업으로 뿅 하고 적용될 수 있는 것이 아니다. 디자인 시스템 하나쯤 있으면 좋아 보이기는 하겠지만 프로젝트의 성격과 조직의 상황에 따라서는 오히려 불필요한 일이 될 수도 있다. 디자인 시스템과 컴포넌트 라이브러리 (혹은 UI 라이브러리)의 차이점을 알고 현재 상황에서 필요한 게 무엇인지 따져본 후에 제작하는 것이 필요하다고 생각한다.

디자인 시스템을 만들기로 했고 개발을 시작한다면 모든 것을 밑바닥부터 제작할 수도 있겠지만 여러 가지 도구를 적극 사용하는 것이 상황에 더 맞을 수도 있다. 표준과 접근성을 모두 고려해서 만들어진 radix와 같은 검증된 프로젝트를 사용해 그 위에 디자인 시스템을 제작한다면 w3c를 참고하며 한 땀 한 땀 개발하지 않아도 되어 많은 시간을 단축할 수 있을 것이다. 반대로 이미 만들어진 UI 프레임워크를 확장해 쓰고자 한다면 항상 접근성과 표준에 대한 작업이 제대로 되어있는지 확인해야 추후에 걷어내고 다시 제작해야 하는 일을 막을 수 있다.

디자인 시스템의 정의

디자인시스템은 제품에 질서과 일관성을 부여한다. 이는 브랜드를 보호하고 사용자 경험을 향상하는 데 도움이 되며 제품을 디자인하고 제작하는 속도와 효율성을 높인다. Laying the foundation
디자인시스템은 제품의 목적을 달성하기 위해 일관되게 구성된 상호 연결된 패턴과 공유 사례의 집합이다. Smashing Magazine Design systems
디자인시스템은 재사용 가능한 컴포넌트와 패턴을 사용하여 대규모 디자인을 관리하기 위한 완전한 표준 세트 Nielsen Norman Group

디자인 시스템의 정의에 대해 여러 리소스를 찾다보면 결국 디자인시스템이란 제품을 구성하는 요소에 규칙과 패턴을 정의하고 이를 바탕으로 재사용 가능한 컴포넌트를 구축하는 것이라고 정리 할 수 있다. 이러한 규칙과 패턴으로 인해 디자인작업 뿐만 아니라 더욱 효율적인 개발 프로세스도 가능해지게 된다.

디자인시스템의 시작

제품이 발달함에 따라 자연스럽게 UI 디자인이 필요한 스크린의 수 또한 증가하게 된다. 이는 다양한 플랫폼과 빠른 확장에 따라 걷잡을 수 없이 늘어나기도 한다. 이 같은 확장으로 인해 많은 조직은 디자인 작업을 체계화해야 할 필요성을 느끼게 되고 이에 따라 디자인의 일관성과 작업의 효율성을 위해 디자인 시스템을 도입하게 된다. 이러한 디자인의 일관성과 효율성은 재사용할 수 있는 컴포넌트와 규칙을 통해 이루어질 수 있다.

개발에서도 재사용이 가능한 컴포넌트 단위의 개발 방법론은 지금은 그리 낯설지만은 않은 개념이다. 하지만 이렇게 된 배경에는 위기 상황이 있었기에 가능했다. 1960년대에 컴퓨터의(하드웨어) 급격한 발전으로 그 기술은 프로그래밍의 속도를 능가하기 시작했다. 이에 따라 컴퓨터의 속도는 빨라졌지만 상대적으로 소프트웨어 개발은 느렸고, 에러가 잦았으며 많은 프로그래머들이 유지보수에 어려움을 느꼈다. 이러한 문제점에 대해 1968년 Nato 컨퍼런스에서는 이를 ‘software crisis’ 라는 용어로 지칭했고 이를 해결하고자 다양한 논의가 진행되었다. 이 컨퍼런스에서 Douglas Mcllroy는 이 딜레마에 대한 해결책으로 컴포넌트 베이스의 개발 방법론을 제시했다. 컴포넌트 베이스의 개발은 코드를 재사용함으로써 프로그래밍의 속도를 향상시키는 방법을 제공했으며 이에 따라 프로그램은 더 효율적이고 쉽게 확장할 수 있었다.

디자인에서도 이와 비슷한 문제 상황을 겪고 있으며 이에 따라 시스템 - 특히 재사용 가능한 컴포넌트에 대한 중요성이 더욱 강조되는 것이다.

무엇이 시스템을 만드는가?

디자인시스템은 단순한 UI 컴포넌트의 모음을 의미하는 것이 아니다. 디자인시스템은 각각의 컴포넌트가 어떻게 쓰여야 하는지에 대한 표준을 정의한 문서인 스타일 가이드를 포함해서 제작되어야 한다.

디자인 시스템은 재사용가능한 컴포넌트를 만드는 것 뿐만 아니라 더 큰 구조와 의미에서의 일관성을 포함한다. Chakra나 Material Design 등의 UI 라이브러리는 재사용가능한 컴포넌트의 다양한 사용성과 확장성을 제공하는 것에 초점을 두고 있다면 디자인시스템에서는 재사용가능한 컴포넌트뿐만 아니라 언제, 어떻게 왜 쓰여야 하는지에 대한 규칙을 정의하는 것을 포함한다. 이러한 표준과 규칙은 스타일가이드의 형식으로 제공될 수 있다.

Atlassian Design System - Button Do and Don't Atlassian 디자인 시스템의 버튼에 대한 사용 가이드 - 디자인뿐만 아니라 사용성에 대한 가이드까지 포함된다.

Primer design system's Button best practices Github의 Primer 디자인 시스템의 버튼의 가이드

예시처럼 거의 모든 디자인시스템 문서에는 컴포넌트의 사용법에 대한 가이드가 명확히 제시됨을 볼 수 있다. Best Practices나 Do & Don’t와 같이 구체적인 사용 방법을 통해 적용될 수 있는 모든 곳에서 일관된 목소리를 내기 위한 규약이다. 디테일 한 가이드가 있다면 컴포넌트 개발에서도 불필요한 고민을 줄일 수 있다.

디자인 토큰

(개발자로써 디자인에서 코딩에서 쓸법한 토큰 개념을 사용하는 것이 나에게는 무척이나 흥미로웠고 팀내에서도 CSS Variables를 사용해 토큰시스템을 간단하게 적용했었다. 개발에서도 디자인 수정이 필요하면 토큰의 값만 바꾸면 되서 굉장히 편리했지만 이를 실제로 작성하는 데는 생각보다 많은 시간이 소요되었고, 컨벤션을 정하는것도 쉽지 않은 일이었다. 또한 디자인팀과의 연계성 없이 개발에서만 사용하다보니 토큰의 장점을 제대로 살리지 못한거 같아서 아쉬웠다.)

재사용 가능한 컴포넌트를 개발하기 위해서는 컴포넌트를 구성하는 기본요소들에 대한 정의가 필요하다. 대체로 이를 Foundation이라고 하는데 그 안에는 타이포그래피, 컬러 파레트, 레이아웃, 그리드 시스템등이 포함될 수 있다. 이러한 다양한 Foundation의 값들을 디자인 토큰이라는 토큰시스템을 통해 관리할 수 있다. 디자인 토큰이란 모든 디자인 결정 값을 데이터로 나타낸것이라고 할 수 있다. 'key-value'의 형태로 구성되며 개발과 디자인 사이의 공통의 데이터셋 역할을 해 보다 원활한 의사소통에 도움을 줄 수 있다. 토큰자체가 얼마 되지 않은 개념이며, w3c에서는 디자인토큰에 대한 표준 가이드를 현재 작성하고 있을 정도로 큰 관심을 얻고 있다. (아직 표준이 없는 만큼 토큰 작성 방식에 있어서도 딱 정답이라고 할 수 있는 틀은 없다.)

그렇다면 디자인토큰이라는 개념이 디자인시스템 왜 나오게 되었을까?

컴포넌트를 이루는 구성요소들 source: https://bootcamp.uxdesign.cc/design-tokens-for-better-design-systems-ab6d833e8d2f

디자인 시스템의 버튼 컴포넌트를 제작한다고 하면 버튼 컴포넌트를 작성하기 위해서는 font-size, background-color, color, line-height, font-weight, border-radius, padding등의 스타일 값이 필요하다. 그리고 이러한 값들은 다양한 컴포넌트 내에서 동일하게 사용되는 경우가 많다. 예를들어, 버튼의 border-radius 값이 4px 이라고 한다면 이 값은 인풋이나 드롭다운 디자인에서도 동일하게 사용하고 있을 수도 있다.

이처럼 시스템 전반에 걸쳐서 일관되게 재사용되는 값들을 디자인과 개발에서 좀 더 쉽게 관리하기 위해 디자인 토큰의 개념이 적용될 수 있다.

토큰은 여러 단계로 작성될 수 있으며 이미 토큰을 사용하고 있는 여러 디자인시스템들 마다 사용하는 명칭과 사용하는 방식은 다 다르다. 대체로 크게 3단계로 나뉠 수 있으며 다음과 같이 나타낼 수 있다.

글로벌 토큰 (Base Token, Primitive Token, Reference Token)
알리아스 토큰 혹은 시스템 토큰
컴포넌트 토큰

Global Token(혹은 Base Token, Primitive Token)

글로벌 토큰, 베이스 토큰, 프리미티브 토큰 모두 최상위의 토큰 개념으로 직접적인 값 - hex, hsla, rgb 값, px, rem 을 나타낼 때 사용된다. 글로벌 토큰은 컴포넌트 작성에 직접적으로 사용되는 경우는 드물고 대체로 알리아스 토큰이나 컴포넌트 토큰으로 다시 맵핑되어 사용된다.

Atlassian의 글로벌 토큰 Atlassian의 컬러 글로벌 토큰도 이렇게 서비스내에서 사용될 수 있는 다양한 컬러에 대한 직접적인 값으로 작성되어 있다.

Tailwind의 컬러파레트

Tailwind를 쓴다면 이미 익숙할 수많은 컬러 값 (폰트, 간격 등 모두)또한 글로벌 토큰의 예라고 할 수 있다. 글로벌 토큰은 이렇게 값에는 직접적인 값을 주는 방식으로 작성된다.

slate: {
  50: '#f8fafc',
  100: '#f1f5f9',
  200: '#e2e8f0'
}, ...

Alias Token(System Token)

알리아스 토큰은 그 뜻 그대로 별칭을 나타내는 토큰으로 이미 정의된 토큰값을 다른 이름으로 나타낼때 사용한다. 주로 토큰에 의미있는 명칭을 주고자 할때 사용되며 이름만으로 어떤 역할을 하는지 알기쉽게 하려는 의도로 사용된다.

가장 쉽게 접할 수 있는 Primary, Secondary, Warning , Success 가 알리아스 토큰의 하나라고 할 수 있고 이때 각각의 토큰 값은 이미 정의된 글로벌 토큰으로 맵핑된다.

Atlassian 디자인 시스템의 예를 살펴보면, color.text라는 Alias token은 Neutral1000이라는 이미 정의된 글로벌 토큰 값을 사용하고 있다. 실제 코드에서 color: Neutral1000 을 쓰는것과 변수 시스템을 사용해 color: var(--color-text) 를 쓰는것 자체로는 큰 차이가 없어 보일 수 있지만 추후에 전체적인 텍스트 컬러를 수정해야한다면 확실히 알리아스 토큰을 쓰는것이 Neutral1000이 쓰인 곳을 모두 찾아 수정하는 수고를 없앨 수 있어 유지보수 관점에서도 편리하다는 것을 알 수 있다.

Carbon 디자인시스템의 알리아스 토큰 IBM의 Carbon Design System의 Background의 토큰들

Component Token

알리아스 토큰은 전반의 스타일에 대한 값을 나타낸다면 컴포넌트 토큰은 컴포넌트에 한정된 토큰을 정의할때 사용된다. 버튼과 같이 다양한 variant와 상태가 사용되는 경우에 유용할 수 있다. 대부분의 디자인시스템은 글로벌토큰과 알리아스 토큰의 2단계 시스템을 많이 사용하고 있고 컴포넌트 토큰까지 작성하는 경우는 많지 않다.

Material 디자인의 토큰 개념 Material 디자인의 컴포넌트 토큰 개념

토큰은 디자인시스템을 이루는 기본이 될 수 있으며 단계나 작성 방식에 따라 복잡도가 높아지는 만큼 어느 단계까지 가져갈지 생각해볼 필요가 있다.

그래서 디자인시스템은 언제 필요한가?

디자인시스템은 디자인과 UI 개발에 있어서 모든 것을 해결해주는 Silver Bullet이 아니다. 제작하는 데만 해도 많은 리소스가 들어가는 일이다 보니 조직에서 디자인시스템이 정말 필요한지 제작에 앞서서 면밀히 고려해 볼 필요가 있다. 때로는 컴포넌트 라이브러리 제작만으로도 충분할 수 있고 때로는 토큰시스템만 필요할수도 있고 오히려 디자인시스템이 없는 것이 더 효율적일 수도 있다.

디자인시스템이 주는 장점

디자인과 개발의 작업 효율성을 높여줌으로써 제품의 빠른 확장을 가능하게 해 준다. 재사용할 수 있는 컴포넌트가 많아지다 보니 작업의 속도를 높여주고 중복 작업을 방지할 수 있다.
다양한 팀 간의 공통의 표준을 만들어 준다. 디자인과 개발의 의사소통을 원활하게 할 수 있다. 개발자는 디자인시스템을 통해 디자인의 의도를 파악할 수 있다.
서비스의 일관된 스타일과 사용성을 보장한다. 한개의 서비스를 이루는 다양한 팀들이 모두 공통의 디자인시스템을 사용하면서 팀에 상관없이 디자인과 UX의 일관성을 유지할 수 있다.
디자인팀내에 작업 자료로 활용되고 온보딩을 빠르게 할 수 있다. 가이드라인의 작성으로 디자이너의 온보딩을 빠르게 할 수 있다.

디자인시스템이 주는 단점

디자인시스템을 만들고 유지하는 데에 시간과 비용이 많이 소요된다. 일회성 작업이 아닌 꾸준한 유지보수가 필요하다. 전담팀이나 작업자가 필요하게 된다.
디자인시스템을 사용하는 방법을 가르치는 데 시간이 필요하다. 연관 팀 내에 교육이 필요할 수도 있다.
컴포넌트나 디자인을 수정할 때마다 디자인시스템을 거쳐야 하고 시간이 걸릴 수 있다. (배포가 필요하거나 협의를 거쳐야 하므로)
디자인시스템을 만들기 위해 디자인과 개발의 밀접한 협업이 필요하다. 디자인과 개발의 협업이 원활하지 않다면 디자인시스템을 만들기 어렵다.

마치며

디자인 시스템은 디자인과 개발의 작업 환경을 최적화하는 데 도움이 될 수 있는 다양한 구성 요소, 패턴, 스타일 및 가이드로 구성된다. 그러나 이러한 것들은 사람이 설계하고, 관리하고, 구현해야 하는만큼 디자인 시스템을 만들 때 고려해야 할 주요 요소는 프로젝트의 규모, 사용 가능한 리소스와 시간이다. 제대로 구현 및 유지 관리되지 않으면 디자인 시스템은 다루기 힘든 레거시 프로젝트가 될 수 있다. 그러나 잘 구현된다면 디자인과 개발팀의 커뮤니케이션과 효율성을 증가시킬 수 있다.

(최근에는 디자인 토큰을 작성하는데 도움을 주는 다양한 디자인툴들이 나오고 있는 만큼 디자인과 개발의 갭을 줄이려는 시도가 계속 되어있고 이 연결점에 디자인 시스템이 있는 것 같다. 언젠가 기회가 되면 제대로 만들어 보고 싶은 바램이 있다.)

도움받은 글들

디자인 시스템 링크