디자인 시스템 제작기 (0)
00. 아토믹...? 알파벳...?
디자인 시스템이라는 용어가 등장한 시간이 꽤 된 것 같은데, 최근 들어 여기저기서 "디자인 시스템"이라는 말들이 많이 오가고 있다고 느껴요. (물론 제가 너무 느린 것도 있겠지만) 운 좋게도 2019년 말, 당시 동아리에서 디자인 시스템을 주제로 팀이 꾸려졌었고, 기초적인 지식을 공부하는 데에 많은 도움을 얻었어요.
그 이후 여러 번 회사를 옮기고, 정리했던 시스템들, 그러면서 배웠던 디자인 시스템에 대한 글을 쓰려고 해요! 저는 디자인 시스템 방법론 중 "아토믹 디자인 시스템"으로 디자인하는 법, 그전에 "아토믹 디자인 시스템"이 도대체 뭐 하는 시스템인지 정리해보려고 합니다. 저는 혼자 공부하고 작업을 해왔어서, 아마 많이 부족할 수 있어요. 제가 알고 있는 게 잘못된 정보라거나, 부족하다거나 한다면 언제든 댓글로 피드백 주시면 수정해서 반영해 놓을게요. 그럼 시작하겠습니다!
00. 서론
디자인 시스템, 요즘 너무 많이 쓰이는 단어 같아요. 특히 프로덕트 디자인을 하고 계신 분이라면 한 번쯤은 들어보셨을 거예요. 뜻과 의미는 사실 다른 유명하신 분들이 굉장히 많이 언급을 했기 때문에 넘어가도록 하고, 저는 이렇게 정의를 하며 작업을 시작했습니다.
효율적인 프로덕트의 제작 및 개선을 위한 시스템
무엇보다 시스템을 왜 잡아가야 하는지, 그리고 이걸 제작했을 때 얻을 수 있는 것들은 무엇이 있을지 많은 고민을 해야 했어요. 사실 아래에서 소개하겠지만, 지금 회사에서는 제가 입사를 했을 당시에도 디자인 시스템의 기초가 잡혀있었고, 전 회사에서 작업자끼리 싱크를 맞춰가던 방법론인 "아토믹 디자인 시스템"을 기준으로 제작해 나갔습니다.
01. 아토믹 디자인 시스템이란?
아토믹 디자인 시스템은 디자인 시스템 방법론 중 가장 유명한 이론이 아닐까 합니다. 해당 사이트 (https://atomicdesign.bradfrost.com/chapter-2/)에서 더 정확하고 자세한 이론 공부를 할 수 있습니다만, 저는 제가 제작하면서 이해한 내용을 바탕으로 우선 정리를 해볼까 합니다.
아토믹 디자인은 시스템 자체를 하나의 유기체로 인식하고 접근하는 방법론이라 생각하기 때문에 디자인 요소 하나하나가 서로에게 영향을 주고 있다고 생각하면 편할 것 같습니다. 그렇기 때문에 아토믹 디자인은 구성요소를 아래의 사진처럼 구분을 짓고 있어요.
출처 : https://atomicdesign.bradfrost.com/chapter-2/예를 들어봅시다. Label이라는 컴포넌트와 Input이라는 컴포넌트, 그리고 마지막으로 Button이라는 컴포넌트들은 더 이상 쪼갤 수 없는 작은 하나의 디자인 요소라고 할 수 있습니다. 물론 Input은 정의하기 나름이겠지만 정보를 입력한다는 기능으로 봤을 때 최소 기능을 가진 Atoms라고 할 수 있죠.
이들은 각각 흩어져있을 때는 디자인적으로 유의미한 결과를 가져오지 못해요. 그렇다면 이 친구들을 "라벨이 붙어있고, 검색할 수 있는 버튼이 달린 인풋창"으로 조합을 해보죠! 풀어서 설명해서 길지만 단순하게 말하면 이건 바로 "검색창"이 되겠네요. 이러한 검색창을 Molecules라고 분류할 수 있어요. Atoms의 조합이니까 말이죠.
그러면 이러한 검색창이 포함된 Molecules들의 조합 중 대표적인 것은 무엇이 있을까요? 바로 페이지 최상단의 Header 요소, 즉 GNB입니다. GNB는 가장 대표적인 Oraganisms의 예시라고 생각해요. 이러한 조합들이 Templates가 되고, 이 친구들에게 GUI 디자인을 입히면 바로 Page가 된다고 볼 수 있겠죠.
즉, 우리가 흔히 생각하는 Checkbox, Radio 등 라벨을 떼어내고 단독적으로 하나의 기능을 담고 있는 요소를 Atoms라고 분류하고 있는 게 아닐까 합니다. 이러한 요소들을 모으고 모아 하나의 작은 카드 컴포넌트를 구성하면 이러한 친구들이 바로 Molecules라고 볼 수 있고, 이러한 카드들이 모여있는 피드의 Body가 Oraganisms가 되는 것이죠.
02. 왜 아토믹이었을까?
우선 디자이너의 관점에서 먼저 살펴보도록 하겠습니다. 모든 디자이너분들이 이렇다는 것은 아니고, 적어도 저는 이렇게 생각하고 디자인을 해왔었습니다.
페이지를 디자인하며 컴포넌트를 쪼개고 구성하는 단계까지는 생각을 해왔지만 이를 통째로 하나의 디자인으로 인식하고 있었습니다. 그러다 보니 하나를 수정하게 되면 다른 페이지에 엮여서 수정이 안 되거나, 수정이 되더라도 다른 페이지에서 사용할 경우 그곳에서 다시 한번 더 수정해야 하는 작업 과정을 거치고 있었죠.
하지만 제가 듣고, 보고 공부했을 때 알게 된 점은 개발자분의 인식은 사진과 같은 구조로 페이지를 이해한다는 점이었습니다. 헤더, 바디, 푸터 등은 이제는 익숙한 단어지만 컴포넌트를 묶어서 관리를 어떻게 하는지에 대한 방식이 저는 완전 주니어 중 주니어였던지라 (물론 지금도 주니어입니다.) 이해하기 힘든 부분이었거든요.
개발자들의 관점에선 하나의 페이지라고 하더라도 사진과 같은 구조화된 컴포넌트 단위로 페이지를 보고 인식하는 것 같았습니다. 카드 컴포넌트라고 해서 통째로 하나의 디자인, 그리고 컴포넌트가 아니라 그 안에서도 관리하는 부분을 따로 구분 짓고, 이를 또 다른 하나의 컴포넌트로 인식하는 것이죠.
이렇게 된다면 하나의 페이지를 수정하고 개선하고, 관리하는 관점에서도 디자이너와 개발자의 인식차이는 존재할 수밖에 없지 않을까요? 주니어 디자이너인 저는 페이지 디자인 중 이 요소 하나만 수정해 주시면 됩니다!라고 생각하고 말을 하고 있었습니다.
하지만 개발자들에게 있어서 디자인 요소의 수정은 사진과 같은 인식을 거쳐 받아들이죠. 그러니까 컴포넌트의 세부 요소인 저 컴포넌트를 수정하면 되겠구나로 이어지는 것인데, 이것이 위의 구조와 별 차이가 없어 보이지만 이러한 접근방식이 저는 굉장히 아토믹 디자인의 기본 개념과 흡사하다고 생각했습니다.
물론 순서는 반대지만 아토믹에서 이야기하는 "Atoms Molecules Organisms Template Page"의 순서와 개발자가 인식하는 페이지 구조인 "Page Template Organisms Molecules Atoms"가 매우 유사하지 않나요?
그렇기 때문에 디자이너와 개발자의 협업에서 가장 중요한 것은 이해 기반의 통일이라고 생각했고, 언어를 통일함에 있어서 공수가 복잡하고 더 들어가는 개발에 맞춰 사고하는 방식을 길러보자고 마음먹었죠. 이 과정에서 개발자들도 디자이너인 저의 입장에서 많은 이해와 배려를 해주셨고, 저 또한 그들의 입장을 많이 이해하려고 노력했습니다.
03. 작업하기 전에 어떤 것들부터 해야 할까?
그렇게 저는 아토믹 디자인 시스템의 기본에는 정말 충실하려고 노력을 했습니다. 그렇기 때문에 기본적인 디자인 요소를 Atoms으로 구분하고, 이들의 조합을 Molecules로, 그다음의 요소를 Organisms로 분류하여 잡아나갔습니다. 그런데 잘 살펴보니 우선적으로 제가 놓치고 있던 부분들이 보이기 시작했어요!
출처 : https://atomicdesign.bradfrost.com/chapter-2/좌측의 사진이 위에서 언급했던 Atoms를, 우측에 있는 두 개의 사진이 각각 Molecules, Organisms의 예시로 설명하고 있는 요소들입니다. 현재처럼 컴포넌트들로 구성된 시스템이 일반화되기 전까지 디자인 시스템 하면 떠오르던 요소들은 바로 Color, Typography, Icon 등이었어요. 사실 제가 처음 디자인을 공부하면서 들었던 시스템의 종류도 저 3가지였거든요.
이제 이러한 요소들을 제작하고 조합하기 전에 제가 놓쳤다고 생각한 부분이 어떤 건지 대충 감이 오시나요? 저는 Foundation이라는 요소를 정의하지 않고, 바로 컴포넌트 제작에 들어간 것이었죠. 사실 순서나 방법은 각자의 취향과 순서가 있다고 생각을 합니다. 저는 하나하나 처음부터 시작하지 않으면 불안해하는 성격이기 때문에 이들부터 먼저 잡아나가고자 마음먹었어요.
어쨌거나 저는 이러한 정의에서 공통된 규칙 언어인 Foundation에 대한 정의가 하나도 이루어지지 않았던 것이죠. 영어를 공부하겠다면서 "알파벳"을 배우지 않고 그다음 단계로 나아가는 것은 불가능하다고 생각했어요. 또 나아간다고 하더라도 큰 의미가 없다고 생각했죠.
저는 회사에서 고민이라고 하던 부분들을 듣고 기억하기 시작했어요. 컬러의 문제점(작업자들이 인식하는 정도), 텍스트 중 사용하지 않는 스타일 등을 먼저 적어나갔고 기존에 진행해야 했던 프로젝트들과는 별개로 스타일을 정리해서 별도로 관리하기 시작했습니다.
04. 마무리
이번 편은 생각보다 조금 더 길어진 것 같아요. 제가 하고 싶은 말은 많은데, 잘 정리를 하지 못한 것 같네요. 개발 쪽의 이야기가 아무래도 100% 맞는 이야기가 아닐지도 모릅니다. 그러니 틀린 정보나 부족한 설명이 있다면 따뜻하게 댓글로 말씀해 주세요. 바로 수정해서 재발행하겠습니다. :)
아마도 다음편부터는 본격적으로 시스템을 들어가기 전에 기초(?)를 닦는 Foundation 편이 이어질 것 같습니다. 목차는 Icon, Typography, Spacing, Color, Design Tokens 순으로 진행될 예정입니다. 제가 가진 작은 성실함이 큰 게으름을 이긴다면 상반기 안에는 꼭 마무리를 해보려고 합니다. 이 글을 읽어주신 모든 분들 감사하고 파이팅입니다!
