
어느 날 대표님이 말했다. “우리도 토O 같은 앱, 디자인 시스템 만들어 보자.”
대부분의 디자인 시스템 구축 프로젝트는 이렇게 시작된다. 이게 아니라면 ‘해야 할 것 같아서’의 이유로. 어떤 경우든 결국 ‘사실 나도 해보고 싶었다’에 가까울지도 모른다. 디자인 시스템이 뭔지는 대충 알 것 같으니, 피그마를 먼저 켜본다. 컴포넌트를 하나둘 만들고, 피그마 라이브러리로 만들면 뭔가 될 것 같다. 그런데 컴포넌트를 어떻게 만들기 시작해야 하는지 모르겠다.
그러니까 만들 줄은 아는데, 어떻게 만들어야 잘 만드는 건지를 모르겠다. 막연하게 검색을 해본다. 그런데, 디자인 시스템을 처음부터 잘 차근차근 알려주는 자료가 딱히 없다. 막막해졌다. 일단 버튼을 만들어보고 텍스트 필드도 만들어보다가, 이걸 어떻게 해놔야 하는지 도저히 모르겠어서 슬슬 약이 오른다.
약간의 과장은 있지만, 대부분의 주니어 디자이너들은 디자인 시스템에 대해 비슷한 경험이 있을 것이다. 어쩌다 하게 되긴 했는데, 뭘 찾아봐도 속 시원하게 알려주는 자료가 없다. 버튼을 디자인하는 기술적인 방법은 알겠는데, 이게 배리언츠를 어떻게 묶어야 맞는 건지, 어느 정도까지 만들어 놓고 해야 하는지 잘 모르겠다.
실제로 디자인 커뮤니티를 관찰하다 보면, 디자인 시스템을 도입하기로는 했는데 무엇부터 해야 할지 모르겠다며 고민하는 주니어 디자이너들이 많다. 대부분 1인 디자이너거나, 이제 2년이 채 안 되어 피그마가 조금 익숙해지는 시점에 많이 고민하는 듯하다.
디자인 시스템을 천천히 이해하고 작업하기엔 시간이 부족하고, 내용도 복잡하고 어렵다. 머티리얼 디자인과 휴먼 인터페이스 가이드라인을 보면 된다고 하는데, 그건 우리 제품과는 다른 세상 이야기인 것만 같아, 쉽게 적용하기 어렵다. 이번 글에서는 개념이나 원리, 원칙을 따지기에 앞서, 당장 업무를 시작해야 하는 주니어 디자이너에게 실질적으로 도움이 될 만한 디자인 시스템 도입·구축 가이드라인을 공유하고자 한다.
디자인 시스템에서 가장 먼저 할 일은 피그마로 컴포넌트를 만드는 것이 아니다. ‘텍스트 레이어를 만들고, 오토레이아웃을 씌워 패딩을 주고, 모서리를 둥글게 굴린 후 컴포넌트로 변환’하는 건 피그마 기초를 공부하면 다들 할 수 있는 것이다. 가장 먼저 할 일은 우리 제품을 쭉 탐색해 보면서, 보이는 UI들을 한군데에 다 모으는 것이다.
이렇게 모으다 보면, ‘~한 화면에서는 꼭 ~를 썼더라’ 같은 보이지 않는 규칙을 하나씩 발견할 수 있다. 디자인할 때 습관적으로나 무의식적으로 하던 버릇들이 하나의 규칙을 이루는 것이다. 꼭 무의식이 아니라, 디자이너라면 기본적으로 준수해야 하는 사용성이나 UI 원칙이 있을 수도 있다. 그런 부분에 초점을 두고 UI들을 한 군데로 최대한 모아본다.
그다음 모은 UI들을 종류별로 분류한다. 그러면 하나의 제품 안에 다양한 버튼을 사용했다는 걸 깨닫게 된다. 그나마 버튼은 다양해도 어느 정도 통일해서 사용하는데, 일반적이지 않은 UI들은 쓸 때마다 다르게 만든 걸 발견하게 된다.
만약 종류별로 모아봤는데 차이가 크게 없다면 다행이지만, 한 UI의 종류가 수십 가지가 되면 할 일이 많아진다. 그래서 종류별로 분류하면서 그 안에서도 세부 분류를 하면 좋다. 예를 들어, 버튼을 한군데 모아둔다면 버튼의 크기를 나눠서 쓰고 있었는지 살펴보고, 크기를 세부 분류로 나눠서 정리해 둔다. 다른 UI 역시 자세하게 분류하면 도움이 될 것이다.
이때 어떤 종류로 분류해야 하는지 잘 모르는 UI도 있을 텐데, 이때 기억해야 하는 것은 ‘UI는 형태가 아닌 목적’이 중요하다는 것이다. 형태는 각 서비스마다 다 다르게 쓰겠지만, 기능적인 부분은 다르게 쓸 수가 없다. 예를 들어, 버튼의 모양이 모두 다를 순 있어도 ‘누름으로써 핵심 행동을 수행하도록 하는 UI’라는 버튼의 근본 원리가 달라지는 건 아니라는 것이다. 따라서 분류하다가 막히는 부분이 있다면, 형태가 아니라 기능에 초점을 두고 정리해 보자.
이렇게 어느 정도 모으고 분류했다면, 이제 개발자, 다른 디자이너와 함께 모아둔 UI를 보면서 시스템화에 관한 이야기를 나눈다. 여기서 시스템화라는 건, 반복적으로 사용하는 UI 코드를 ‘템플릿’처럼 만들어, 개발자들이 UI를 빠르게 코드로 옮겨낼 수 있도록 만드는 개념이다. 즉, 디자인 시스템을 코드화해서 디자이너가 디자인한 아웃풋을 개발자가 빠르게 코드로 제작해 낼 수 있게 한다는 뜻이다.
이 논의에서 중요한 점은 디자이너의 기획 의도와 코드 구조를 최대한 유사하게 맞추는 것이다. 버튼 안에 아이콘을 넣었다면, 개발에서도 버튼 안에 아이콘이 들어가 있는 구조로 만들어둬야 디자인과 개발의 커뮤니케이션이 간단해진다.
그리고 논의를 진행함과 동시에, 분류해 둔 UI들을 필요에 맞게 적절히 통일하는 것을 병행한다. 정답은 정해져 있지 않고, 필요한 스타일과 개수만큼 정리해 주면 된다. 둥근 버튼, 사각 버튼, 아이콘만 있는 버튼 등이 필요하고, 사이즈로 5개씩 필요하다면 그렇게 해도 된다. 그걸 계속해서 관리하는 것도 나의 몫이라는 것만 기억하면 된다.
만약 우리 제품에 사용할 버튼이 두 종류뿐이라면, 화면을 디자인할 때 고민할 거리가 매우 적을 것이다. 그만큼 빠르게 진행할 수 있지만, 디자인의 세부적인 부분이나 적합한 UX를 만드는 것에서 조금 아쉬울 수 있다. 대신 버튼이 크기로는 네 종류, 스타일로는 세 종류가 있다면, 화면을 디자인할 때 어떤 걸 써야 좋을지 판단하기 어려워진다. 이때는 오래 걸리는 대신, 디자인 자체의 완성도는 높일 수 있다. 스타일 수와 사이즈가 적을수록 디자이너의 판단은 편해진다. 그러나 너무 선택지가 많으면 디자인도 복잡해지니 적당한 타협점을 찾아야 한다.
이러한 논의 과정을 통해 UI를 어느 정도 정리했다면, 수집부터 논의까지 진행하며 찾아낸 것들을 모두 일목요연하게 문서로 남겨본다. 특히 글로는 남아 있지 않지만, 모두가 납득해서 사용하고 있는 규칙이라면 반드시 적어두어야 한다. 예를 들면, 버튼을 사용할 때 암묵적으로 화면 너비에 꽉 채워서 사용하는 것 등이 있다.
디자인 시스템이 어렵다고들 하지만 사실은 별게 아니다. 본질은 이런 암묵적인 규칙들을 명시적으로 문서화하는 것이 핵심이다. 문서로 남길 때는 나름의 순서를 만들어서 작성하는 것이 도움이 된다. 예를 들어, UI의 이름, 뜻 등 규격을 먼저 작성하고, 위치나 레이아웃에서의 배치, 이렇게 쓸 것/쓰지 말 것 같은 규칙 등의 순서를 만들어 작성하면, 놓치는 점 없이 일목요연하게 UI를 설명할 수 있다.
이렇게 수집하고, 분류하고, 정리해서 문서까지 남겨두면 이 문서가 곧 디자인 시스템이 된다. 물론 제대로 된 디자인 시스템이라고 하려면 더 많은 발전이 필요하지만, 단순히 UI를 모아둔 키트에서 더 나아가 실제 문서화까지 마쳐본 것이다.
그리고 이런 작업을 꾸준히 진행해서 축적되면, 그것이 바로 ‘디자인 시스템’이 된다.
우리가 제품을 만드는 건 사용자가 겪는 불편을 해결하기 위함이다. 당근은 동네 중고 거래를, 토스는 간편 송금을 가능하게 했다. 이런 제품들은 사용자의 반응에 빠르게 대응하면서 계속 발전한다. 디자인 시스템 역시 제품이다. 다만 사용자가 밖에 있는 게 아니라, 우리 회사 내부에 있을 뿐이다. 아마 디자인 시스템을 한번 만들면 끝이라고 생각한 사람도 있을 것이다.
그러나 디자인 시스템 역시 제품이라 꾸준히 개선해야 한다. 이 과정을 너무 어렵게 생각하지 않길 바란다. 디자인 시스템을 막연하게 생각하면 어렵고, 복잡하고, 뭐부터 먼저 해야 할지 고민하게 된다. 대신 지금까지 이야기했듯이 디자인 요소를 수집하고, 정리하고, 잘 논의하는 과정에 충실하면 된다. 몇 번 하다 보면 디자인 시스템의 원리가 눈에 들어올 것이다.
우리가 사용자의 문제를 하나씩 해결하면서 앞으로 나아가듯, 디자인 시스템도 그렇게 조금씩 해결하면 된다. 처음부터 큰 덩어리를 해결하려고 끙끙대지 말고, 작게 쪼개서 천천히 정리해 보자. 그러다 보면 어느새 체계적이고 정교한 디자인 시스템을 운영하는 모습을 발견하게 될 것이다.
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.