brunch

You can make anything
by writing

C.S.Lewis

by designsystemguy Feb 26. 2023

아토믹디자인과 도메인주도 설계가 바탕이되는 디자인시스템

이전 포스팅에서 아토믹 디자인 방법론에 대해 이야기하였습니다. 개념과 실제 적용에 있어 고민이 필요한 지점에 대해 썼었는데요. 이번에는 이전 글에 대한 생각을 토대로 확장한 제 경험을 공유하려 합니다. 이전 글을 안보신분들은 꼭 이전 글부터 읽고 오시는 것을 추천드립니다.

제목을 통해 알 수 있듯, ‘아토믹디자인’과 ‘도메인주도설계’의 사고방식을 토대로 이루어진 디자인시스템을 말씀드리고 싶었습니다. 제가 적용한 방법을 이해하려면 두가지 개념을 모두 이해해야 합니다. 두 개념 모두 익숙치 않으신 분들을 위해 먼저 개념 설명을 드리고, 제가 프로덕트에 적용해나간 과정을 말씀드리겠습니다.

아토믹 디자인 (Atomic Design)

바로 이전 글에서 아주 짧게 설명되어 있고, 인터넷 많은 글에서 아주 잘 설명되어있습니다. 간단하게 말하자면, ‘공통이 되는 UI 패턴을 아주 작은 단위부터 정의해가며 재사용하자’는 사고방식입니다. 이건, 실생활 예시를 들며 짧게 설명드릴게요.

식재료로 비유하자면 아래와 같은 분류로 나누어 생각할 수 있어요.

Tier 1 : 고춧가루/설탕/소금/쌀/물

Tier 2 : 고추장/된장/간장/식초/떡

Tier 3 : 떡볶이/어묵탕/간장계란밥/된장찌개

Tier 2 고추장은 Tier 1 재료들(고춧가루,물, 간장)의 조합으로 이루어져있어요. Tier 3 떡볶이는 Tier 2 재료들(고추장, 간장, 떡)과 Tier 1 재료들(고춧가루, 설탕, 물)의 조합으로 이루어져있어요.

Tier 1, 2는 쟁여놓으면 어느 음식에서든 재사용할 수 있어요. 그래서 어떤 요리든 일관된 맛으로 빠르게 만들 수 있게되죠. 이걸 UI에 대입해서 생각하는 사고방식이 아토믹디자인이라고 보시면 됩니다. 쉽죠? ㅎㅎ

도메인 주도 설계(Domain Driven Design)

도메인 주도 설계를 이해하기 위해 도메인의 의미부터 살펴보자면, 도메인은 사전적으로 ‘영토’, ‘범위’를 뜻해요. 도메인 주도 설계는 ‘도메인’에 따라 즉, 유사한 업무 묶음별로 나누어서 작업하는 방식인 것이죠.

생겨난 배경에 대해서 말씀드리자면 도메인 주도 설계 방식은 현실의 문제를 잘아는 사람(도메인전문가)과 그것을 실제 코드로 구현하는 사람간의 간극 때문에 생겨나는 문제를 극복하고자 생겨났다고 합니다.

몇몇 서비스를 도메인별로 나누어보자면 아래처럼 나누어 볼 수 있을 것 같아요. (예시일 뿐입니다.)

배달 : 탐색 / 주문(결제) / 배달 / 회원 / …

여행 : 탐색 / 결제 / 회원 / …

금융 : 주식 / 송금 / 지원 / ...

중고거래 : 탐색 / 거래 / 회원 / …

스트리밍 : 탐색 / 구독 / 플레이 / 회원 / …

도메인주도설계는 더 깊고 방대한 이야기를 품고있지만, 이 글은 디자인시스템에 관한 글이기 때문에 여기까지만 이해하고 넘어가도록 하죠.

디자인시스템에 적용하기

위 두가지 사고방식을 토대로 디자인시스템에 적용하고 구축한 경험을 3 Phase에 걸쳐 말씀드려볼게요.

잠깐! 디자인시스템은 프로덕트의 방향 및 상황 등을 고려하여 그에 맞는 구조로 설계해나가야 합니다. 아래 내용을 무작정 따라하시지는 마세요.

Phase 1. Single UI Kit

하나의 UI Kit에 스타일과 컴포넌트를 모두 넣어 관리하는 구조로 관리하던 적이 있었습니다. UI적으로 High Coupling 되어도 크게 리스크가 없었기에 선택할 수 있었고, 파일 하나에서만 관리하기 때문에 관리 난이도로만 치면 제일 쉬웠죠.

시간이 지나 UI Kit이 한 파일 안에서 여러 주제단위로 한꺼번에 관리하기에는 너무 많은 내용을 포함하게되었고, 테마 변경과 같은 확장성에 유연해야한다는 순간에 도달하게 되었어요. 그래서 Style(Foundation)과 Component 정도는 나누어 관리하는 것이 깔끔하다는 결론을 내렸었습니다.

Phase 2. Multi-Tiered Design System

프로덕트가 조금만 커져도 컴포넌트는 다양해지고 많아져요. 그에 따라 컴포넌트 라이브러리도 구분이 필요했죠. 이 때, 아토믹 디자인 사고방식에 기반하여 디자인 시스템을 펼쳐 나갈 수 있었어요.

Styles (Foundation) : 타이포그래피, 컬러, 쉐도우, 레이아웃 그리드 등 디자인의 기반이 되는 요소 모음

Icon Library : 아이콘 모음

Low Level Component Library : 작은 단위, 서비스 전역에 걸쳐 사용되는 컴포넌트 모음

High Level Component Library : Low Level Component의 조합 또는 큰 덩어리 컴포넌트들의 모음

설계된 방식은 아래 그림처럼 티어를 나눠 하위 라이브러리가 상위 라이브러리를 참조하는 형태로 이루어져 있었어요.

Phase 3. Multi-Tiered Design System with Domain Components

2 Phase와 같이 디자인시스템을 운영하다보면 High Level Component에 어떤 것을 넣어야할지, 누가 넣어야할지 의사결정이 애매해지는 구간이 있었어요. 그러다가 마침 조직이 도메인 단위로 스쿼드를 나누기 시작했고, 더불어 도메인 주도 설계를 접하게 되면서 디자인 시스템을 발전시키게 됩니다.

라이브러리는 아래 그림과 같이 재구성하여, 제가 관리하기에도 사용하는 사람들에게도 용이하도록 재인식시켰습니다.

Styles (Foundation) : 타이포그래피, 컬러, 쉐도우, 레이아웃 그리드 등 디자인의 기반이 되는 요소 모음

Icons: 아이콘 모음

Illustrations (Images) : 프로덕트에 사용되는 일러스트, 이미지 모음

Core Components : 서비스 전역에 걸쳐 사용하는 컴포넌트 모음.

Domain Components : 도메인별로 반복적으로 나타나 재사용하기 위해 모아놓은 컴포넌트 모음.

Helper : 시스템 UI, 마우스, 도큐먼트용 컴포넌트

위와 같이 구성하니 두가지 효과를 볼 수 있었습니다.

1. 각 라이브러리가 갖는 목적 명확화

2. 디자인 시스템을 제작하고 사용하는 사람들 간의 R&R 명확화

라이브러리는 저마다 갖는 목적이 명확해야 했어요. 명확하지 않는 목적으로 관리되는 라이브러리는 어디에 속해야할지부터 고민해야했기 때문이에요. 그래서 위처럼 라이브러리의 목적에 따라 분류했어요.

코어 컴포넌트 라이브러리와 도메인 컴포넌트 라이브러리를 비교했을 때, 가장 큰 차이는 ‘Generic하냐/Contextual하냐’였어요. 그 분류에 따라 개발팀에는 Generic한 코어 컴포넌트만 리액트로 코드화 시키기를 기대했었고, 도메인 컴포넌트는 개발되거나 안되거나 크게 신경쓰지 않았어요. 코어 컴포넌트보다는 수명이 비교적 짧기도 했고, 도메인 컴포넌트는 코어 컴포넌트보다 자유롭게 생산 가능하도록 지향했거든요.

이 부분에서 사실 제 디자인시스템 철학이 녹아들어있긴 해요. 디자인시스템은 모두가 기여할 수 있어야 오랫동안 지속가능하고 프로덕트와 함께 성숙해나갈 수 있다고 이런 저런 글과 영상들을 보며 배워왔고 믿고있거든요. 이와 관련해서는 나중에 별도로 포스팅하겠습니다.

각 라이브러리의 Owner와 Editor, User로 나누었어요. 기존에 디자인시스템 관리자를 저 한명으로 두었을 때, 디자인시스템이 성장하지 않고 멈추어있는 경향을 느꼈거든요. 프로덕트내 동일한 패턴의 UI는 많은데, 더 이상 생산되지 않는 컴포넌트와 프로덕트 디자이너에게는 뭔가 벽처럼 느껴지는 라이브러리에 대한 관념을 깨고 싶었어요.

역할마다 할 수 있는 일은 다음과 같아요.

Owner : 파일의 전반적인 관리 주체. 퍼블리시 권한 있음.

Editor : 컴포넌트 수정권한을 가짐. 퍼블리시 권한 있음. 수정 시 Owner에게는 리뷰를 받아야 함.

User : 파일을 들여다보거나 Import할 권한이 있음.

제가 지향하는 바는 위 이미지와 같지만 프로덕트 사정에 따라 완벽히 지키고 있지는 않아요. 하지만, 변화 이후 모호했던 라이브러리 편집과 사용권한이 명확해졌어요. 프로덕트 디자이너에게는 참여의 기회가 열렸고, 그를 통해 (개인적인 생각이지만) 각 프로덕트 디자이너에게 디자인시스템적 사고 향상과 역량 강화에 한발짝 나아갈 수 있도록 도움을 줄 수 있었어요.

정리

1년을 넘도록 제가 주도했던 디자인시스템은 단일 라이브러리로 시작해 수직 확장을 통해 한단계 성장하고, 수평확장을 통해 한번 더 성장할 수 있었어요. 전편(아토믹 디자인에 대한 고찰)부터 시작하여 구조적인 측면에서 디자인 시스템 이야기를 다루어 봤는데요. 앞으로 할 이야기들이 많이 있어요. 저를 통해 독자분들이 실질적인 도움이 될 수 있으면 좋겠습니다. 그럼 안녕~!