디자인 시스템, 복잡도 다루기
#Design, #Design System · 2024. 5. 27
flex 제품팀의 첫 플랫폼 디자이너로 입사해서 디자인 시스템과 제품을 만들게 된 지 이제 2년 반 조금 넘어간다. 국내에 디자인 시스템을 구성하는 게 필요하다는 이야기가 2018년쯤부터 적극적으로 나왔던 걸로 기억한다. 당시 디자인 스펙트럼에서 에어비앤비, 라인, 토스 디자인 시스템 관련 주제를 들었으니까 말이다. 물론 이전부터 활용했던 조직들도 있었겠지만 적극적으로 활용하는 유행이 시작했던 것은 그 어느쯤이라고 생각된다.
내가 디자인 시스템을 설계하기 전에 가장 착각했던 것은 `디자인 시스템 = 여러 개의 UI 컴포넌트 묶음` 정도라는 생각이었다. 정말 그럴까? 내가 경험하고 있는 것은 전혀 다른 것으로 느껴지기도 한다. '미리 디자인된' 레고 블록을 조립할 수 있도록 설계하는 것이 디자인 시스템의 기본은 맞지만 이건 일부분이다.
더 본질적인 이해로 내려간다면 오히려 'User Interface를 정교하게 시스템화한다'에 가까워진다. 따라서 디자인 '시스템'은 복잡한 Interface를 공통화하고 구체적으로 정의하기 위한 개념이며 우리가 디자인 시스템을 설계하면서 고민하는 추상화와 동작 정의, 패턴화 등은 복잡함을 체계화하는 과정이라고 할 수 있다.
또한 디자인 시스템은 일종의 방법론 혹은 수단이다. 디자인 시스템 설계의 목적은 제품을 만드는 데 있어 효율성과 일관성을 유지할 수 있도록 도움에 있다. 제품이 단순하고 작다면 시스템도 작고 단순하다. 제품이 크고 복잡하다면 당연히 시스템도 크고 복잡해진다. 시스템은 복잡할수록 관리가 어려우며 다양한 용례를 담기 위해서 추상과 구체성의 레이어를 넘나들어야 한다. 이 에세이는 복잡한 제품에서 복잡한 디자인 시스템을 다루기 위한 레이어에 대한 이야기다.
해당 내용들은 지극히 개인적인 의견이나 내 배움을 기준으로 작성했다. 글의 내용은 내 소속 집단의 의견을 대표하지 않는다. 디자인 시스템을 어떻게 구성해야 하는가는 피그마 블로그에 친절하게 안내되어있다.
본격적으로 시작하기 전에 오늘의 가장 중요한 개념, 디자인 시스템이란 무엇인지 먼저 정의한다. 디자인 + 시스템의 합성어로 창의적인 사고를 기반으로 하는 '디자인'과 수렴적인 사고를 기반으로 하는 '시스템'의 결합은 어색하게 느껴지기도 한다. 우선 디자인 시스템에 가장 지대한 영향을 끼친 Figma와 UX 개념을 제일 잘 정의하는 Nielsen Norman Group 정의를 살펴보자.
세부적인 내용은 다르지만 맥락으로는 거의 동일하다. 기본적인 개념은 '디자인 시스템은 복잡해진 디지털 제품에서 많은 디자이너, 엔지니어가 빠르게 일관된 동작과 형태를 설계할 수 있도록 도움으로서 사용자가 어떤 상태에서도 동일한 경험을 할 수 있도록 한다.'로 정의할 수 있다.
세부적인 내용은 다르지만 맥락으로는 거의 동일하다. 기본적인 개념은 '디자인 시스템은 복잡해진 디지털 제품에서 많은 디자이너, 엔지니어가 빠르게 일관된 동작과 형태를 설계할 수 있도록 도움으로서 사용자가 어떤 상태에서도 동일한 경험을 할 수 있도록 한다.'로 정의할 수 있다.
위에서 설명한 구성은 가장 일반적인 형태다. 화면을 구성하기 위해서 필수적인 UI 요소들이 우선 포함되는 게 일반적이지만 간과하지 말아야 할 것은 디자인 시스템은 제품, 조직을 위해서 존재한다는 점이다. 따라서 디자인 시스템은 제품에 종속되는 관계이기 때문에 만들고 있는 제품의 성격, 도메인 영역, 비즈니스의 안정성, 조직의 성향과 규모, 사용처의 역량 등 온갖 요소에 영향을 받으며 반드시 제품의 모습에 따라서 전혀 다른 형태로 발전하게 된다.
이야기를 하다 보면 의외로 간과되는 경우가 꽤 빈번하다. 단순하게 제품의 파편화를 막기 위해서 실제 효용성이 제대로 고려되지 않은 UI Kit 수준으로 제공한다거나, 어떤 논리도 없이 디자인 시스템 유행하니 필요할 것 같아서 제작하는, 수단이 목적으로 둔갑하는 경우도 있다.
디자인 시스템은 추상화된 형태로 제공되는 것을 전제로 하며, 대부분은 Primitive 한 요소(Button, TextField, Swtich...)를 갖고 조합해서 구성하는 방식을 취한다. 가장 흔한 예시로 '카카오톡 친구 목록 아이템'을 예시로 본다면 Avatar, Meta, Tag의 조합으로 만들어진다.
더 자세한 추상화 레이어를 해부하면 List라는 Component가 존재하고 RightChild, LeftChild가 존재하며 ChildSlot에 Avatar 같은 Component를 조합하는 형태로 제공될 것이다. 추상화는 복잡한 것을 쉽게 만들기 위해서 제공하지만 역설적으로 복잡한 제품에서 이런 조합을 활용하는 방식은 어떤 시점까지만 유효하다.
소수 인원으로 제품 팀이 결성된 지 얼마 안 되었고 제품도 아직 PMF(Product Market Fit)을 찾고 있는 단계다. 팀은 더 빠르게 검증하면서도 제품의 품질을 포기하고 싶지 않아서 디자인 시스템을 제작했다.
이 시점의 디자인 시스템은 기초적인 Button, Form, Control, List, Dialog, Tabs 같은 Component들로 구성되어 있을 가능성이 매우 높다. 그렇다면 다행이다. 디자인 시스템은 아주 특수한 경우가 아니라면 제품의 거의 대부분의 요구사항과 사용례를 현재 제작된 Component의 조합을 통해서 충분히 감당할 수 있다. 또한 제품의 크기에 비례하는 복잡도를 갖고 있기 때문에 예측 가능한 요구사항 반영과 소규모 기여를 통해서도 충분히 유지 보수가 가능하다.
제품의 규모가 작다면 이 단계에서는 오히려 디자인 시스템 주도로 제품이 설계된다. 거의 대부분의 사용례를 감당할 수 있기 때문에 디자인 시스템 입장에서는 오히려 미래를 준비할 시간을 벌 수 있다. 아직 구체적인 필요성이 없지만 근 시일 내 필요할 것 같은 Component, Pattern을 미리 준비할 수 있고, 사용처와 커뮤니케이션 과정이 덜 복잡하기 때문에 필요한 요소들 바로 제작할 수 있다.
제품은 작고 큰 성공과 실패를 하면서 점차 영역을 확장하는 시점에 접어들었다. 제품 팀은 이제 여러 조직으로 구성되었고, 제품 안에 여러 도메인과 공통 기능들이 생겼다. 각 도메인과 기능은 서로 연결되거나 완전히 독립된 형태로 설계되었다. 또한 도메인마다 PMF를 찾은 곳도 있고 아닌 곳도 있다.
제품은 품고 있는 도메인과 조직이 커진 만큼 복잡해졌다. 디자인 시스템도 비례해서 커졌고 여전히 많은 디자이너들과 FE 엔지니어들은 디자인 시스템을 갖고서 제품을 설계하려고 노력한다. 하지만 현재 Component, Pattern으로는 더 많이, 더 복합적으로 요구되는 사용처의 요구사항을 감당하기 벅차다.
이 시점에 제품 팀은 시스템을 유지 보수할 수 있는 전담 조직을 구성한다. 하지만 일시적인 방편에 가까울 수 있다. 시스템을 유지 보수하는 리소스는 한정적이지만 제품 팀과 제품의 규모는 더 커져버렸기 때문이다. 여전히 많아진 도메인과 기능만큼 요구되는 Spec, Component, Pattern, Template들을 적절한 시점에 제공할 수 없게 되고 제품 팀들은 필요한 것들을 자체적으로 해결하거나 디자인 시스템을 아주 많이 변형해서 사용하는 양상이 나타나기 시작한다.
동시로 발생하는 파편화와 요구사항, 사용방식에 대한 문의, 우선순위 설정 등 다양한 맥락의 일을 동시에 처리해야 하는 디자인 시스템 플랫폼 팀 입장에서는 아주 고통스럽다. 이제 선제적인 대응은 거의 대부분 상황에서 불가능하며 도메인과 제품 팀의 사용례를 보면서 사후 대응으로 설계 패러다임이 전환된다. 따라서 제품안에서 디자인 시스템이 존속되고 목적을 유지하기 위해서는 새로운 방법을 찾아야 한다.
비즈니스가 실패하지 않는다면 제품은 계속해서 커지고 복잡해진다. 단일 디자인 시스템 또는 보편적인 UI Component, Pattern 등만 다루는 디자인 시스템으로 더는 복잡도를 다룰 수 없다. 콘웨이 법칙에 따라서 제품과 디자인 시스템을 본다면 이제 복잡함을 단순하게 다루기 위해서 노력하기보다는 복잡도를 인정하고 잘 다루기 위해서 노력해야 한다.
꾸준히 이야기하지만 디자인 시스템은 추상화를 담보로 설계된다. 추상화는 복잡한 것을 잘 다루기 위한 개념이고 실제로 디자인을 할 때, 코드를 구성할 때 더 많은 기능을 효과적으로 담는데 충분히 유효하다. 그렇다면 앞선 이야기들과 대치된다. 나는 디자인 시스템은 추상화된 형태로 제공하지만 그걸로는 복잡도를 담을 수 없다고 이야기하고 있다.
여기서 빠져있는 요인은 '조직' 혹은 '도메인'이다. 제품을 설계할 때와 다르게 제품 팀, 도메인 입장에서는 차이가 있을 수 있다. A 조직은 훨씬 더 구체적인 것이 필요할 수 있고, B 조직은 모바일 플랫폼을 위한 것이 필요할 수 있다. 또는 똑같은 List Component를 다루더라도 상충되는 기능을 포함하거나 엄청나게 구체적인 형태를 만들어내고 싶어 할 수 있다.
디자인 시스템은 일관성을 유지하는데 가장 큰 목적이 있기 때문에 기조에 따라서 모든 요구사항을 대응하지 않기도 한다. 따라서 디자인 시스템의 추상화는 제품을 직접 만들 때는 필요한 개념이지만 조직과 조직 또는 도메인과 도메인 사이의 역학 관계에서 그 장점을 발휘하기 어려울 수 있다.
디자인 시스템은 말 그대로 '시스템'이다. 복잡도가 커졌다면 디자인 시스템은 이제 미시적인 관점에서 User Interface를 체계화하는 것을 넘어서 거시적인 관점으로 제품, 조직과 디자인 시스템의 복잡한 관계를 추상화하고 시스템화하는 방향으로 진화해야 한다.
우리의 곁에 이미 복잡함을 추상화하고 다루는 방식의 예시가 있고, 심지어 우리가 직접 다루기도 한다. 디자인 시스템 처럼 Component를 추상화해서 사용처와 연결하는 것. 또는 추상화된 API를 제공해서 사용처의 요구사항을 충분히 대응할 수 있도록 하는 방식, Headless 라이브러리, Styling 라이브러리들을 이용해서 구체적인 시스템을 만드는 것, 필요하다면 외부 기능 라이브러리와 조합하거나 새로운 것을 만드는 것이 그 예시다.
디자인 시스템의 ‘레이어’는 이러한 형태로 제품 팀과 도메인 구조를 대응할 수 있도록 제공된다. 전체 제품을 관통하고 가장 추상화된 API를 제공하는 Core 한 시스템 레이어를 두고 필요에 따라서, 도메인 맥락과 기능, 조직의 위계에 따라서 각자의 레이어를 둘 수 있다. 로컬 시스템, 프로덕트 시스템이라고 하는 방향이다. 이런 방식은 Component를 추상화해서 제공하는 것이 아니라 시스템 자체를 추상화해서 제공하려는 것에 가깝다.
시스템의 레이어는 Core 시스템을 기반으로 설계되어도 도메인의 지엽적인 맥락, 기능, 구체적인 형태를 포함할수록 구체적이면서 범용성이 낮아지게 된다. 레이어 계층을 구체적으로 본다면 아래와 같을 수 있다. 가장 최근에 구체적인 사례를 공유했던 Spotify의 예시를 본다면 아래와 같이 구성될 것이다.
모든 제품과 팀에 이러한 복잡한 레이어가 필요한 것은 아니다. 상황에 따라서 팀 구성, 비즈니스 구조가 복잡하더라도 필요 없는 경우가 있다. 예를 들면 패션 커머스 제품을 만드는 팀의 구조는 복잡할 수 있지만 제품 자체에서 개별 도메인 레이어가 불필요할 수 있다. 아주 단순하게 여성, 남성, 홈, 액세서리 카테고리를 개별 도메인으로 보면, 서로 완전히 다른 Component나 기능을 필요로 하지 않을 것이다.
이제 복잡함을 다루는 실제 경험을 이야기해보자. flex는 HR 도메인을 다루는 제품이다. 크게 본다면 HR이지만 HR 안에는 근태 관리, 전자결재, 성과관리, 급여 정산 등 온갖 크고 작은 도메인이 포함되어 있다. 또한 개별 제품 팀, 플랫폼 조직을 보유하고 있으며 커뮤니케이션 구조도 복합적이다.
flex도 Core 디자인 시스템 만으로 구성되었던 시점이 있었고 개별 도메인의 복잡도, 전체 제품의 복잡도가 증가하면서 자연스럽게 점차 레이어를 구성할 수 있도록 발전했다. flex는 Core 시스템을 기준으로 Component Package, Extension Layer, Common Feature Layer, Local Layer로 구성된다. 각 도메인이나 공통 기능은 필요에 따라서 구체적인 레이어를 두고 있거나 아닐 수 있다.
위에서 설명된 레이어는 칼같이 분리된 계층이 아니다. 도메인이 많아지고 제품 팀이 늘어나면 제품 안에서 새로운 Pattern과 Component가 유행하거나, 엄청 유행하다가 갑자기 팍 식어버리는 재미있는 경우가 있다. flex Design System은 각 레이어를 완전 분리하지 않았기 때문에 이런 상황을 꽤 유연하게 대응 가능한 기조를 갖을 수 있다. 예를 들면 각 레이어는 필요한 경우 서로가 만든 Component를 수출하기도 하고, Local에서 제작된 Component가 기준에 따라서 Core 시스템으로 승격되기도 한다.
근래에 경험을 이야기하면 제품 안에서 Coach Mark를 사용해서 안내하는 패턴이 유행했고, 개별 도메인에서 각자 구성하거나 서로 만든 것을 활용하기도 했다. 플랫폼 팀은 Local 레이어에서 Coach Mark가 유행하는 것을 지속적으로 감지하다가 제품 안에서 충분한 사용례와 요구사항을 파악하고나서 Extension 레이어로 승격시키고 Extension Component로 제작했다.
Coach Mark 사례를 보면서 생각하면, 서로 참조하는 관계라고 칭한 것은 각 디자인 시스템 레이어를 분리했다고 독립적으로 운영하면 훨씬 더 큰 파편화를 만들 수 있기 때문이다. 완전히 분리된 제품이 아닌 이상 디자인 시스템 레이어도 커다란 하나의 제품안에 포함된 개념으로 이해해야 한다. 조직과 제품의 성장, 새로운 UX 패턴의 유행, 사용처의 문제... 등을 유연하게 대응하기 위해서는 참조, 분리, 추상화 개념을 디자인 시스템에 적용해야하며 언제나 각 레이어의 관계를 잘 유지할 수 있도록 노력해야 한다.
근래에 디자인 시스템 설계에 대한 경험을 이야기할 때, 디자인 시스템을 제작하는 방법에 치중되는 것은 아쉬운 지점인 것 같다. 디자인 시스템도 일종의 제품이며 제품 안에 있는 유기체에 가까운 개념이다. 디자인 시스템을 제작하는게 중요한게 아니라, 제품의 품질을 유지하면서 빠르게 만들기 위한 여러 가지 수단 중 하나임을 잊으면 안 된다.
디자인 시스템의 생애 주기를 본다면 필연적으로 제품과 비즈니스 도메인들의 구체적인 요구사항을 반영해야 하는 시점이 찾아오거나 더 이상 복잡도를 다룰 수 없는 상황에 놓일 수 있다. 이런 상황에서 디자인 시스템은 개별 Component의 추상화도 중요하지만 더 크고 복잡한 것을 다룰 수 있도록 충분히 그리고 필요한 만큼의 유연함을 추구해야 한다.
여기서 이야기하는 유연함은 제품 팀의 구조와 복잡한 도메인들의 관계를 충분히 반영할 수 있는 구조를 이야기 하며 이 에세이에서 그 해결책으로 디자인 시스템 레이어를 이야기 했다. 제시된 방법은 정답이 아니다. 나는 여전히 시행착오를 겪고 있으며 아직도 의견을 좁히기 위해서 팀원들과 Core와 Extension 레이어의 차이에 대해 토론하기도 한다. 복잡함, 제품, 조직들 사이의 관계를 디자인 시스템이 다룰 수 있는 훨씬 더 좋은 방법은 충분히 있을 수 있으며, 나도 그 방법을 계속해서 찾고 싶다.