디자인 가이드를 넘어 비로소 시스템으로, 우아한공방 코어시스템 #우아콘2024 #우아한형제들

우아한형제들의 기술조직 이야기를 전하는 우아한테크입니다.

우아한형제들 https://www.woowahan.com/
우아한테크 Facebook https://www.facebook.com/woowahanTech
우아한형제들 기술블로그 https://techblog.woowahan.com

우아한테크

디자인 시스템은 가이드라인과 컴포넌트 목록을 넘어, 유기적으로 진화하며 우리만의 일하는 방식을 정의하는 '체계'가 되어야 한다.

코어 시스템은 스타일링 없는 순수 기능의 베이스 컴포넌트를 제공하여, 클레이(서비스별 시스템)와 몰드(특정 도메인 시스템) 계층이 각각의 역할에 집중하고 시스템 복잡성을 줄이며 유연한 확장을 가능하게 한다.

시스템 디자이너는 단순히 컴포넌트를 정리하는 것을 넘어, 의사결정의 기준과 원칙을 수립하고 모순을 검토하여, 팀의 커뮤니케이션 효율을 높이고 업무 방식을 학습시키는 역할을 해야 한다.

우아한형제들 디자인 시스템 팀의 유 엔지니어와 인터랙션 디자이너 허준입니다. 오늘 발표의 주제는 **우아한형제들의 디자인 시스템인 '우아한공방'의 코어 시스템**입니다. 본 발표에서는 코어 시스템이 무엇인지, 설계 이유는 무엇이며, 어떻게 구성되는지를 설명합니다.

이번 발표는 단순히 디자인 시스템의 기능 소개를 넘어, **시스템 디자이너와 엔지니어가 디자인 시스템을 만들어가며 마주했던 깊은 고민과 인사이트를 공유**하는 자리가 되고자 합니다. 즉, 디자인 시스템 자체보다는 '좋은 시스템 그 자체'에 대한 이야기를 나누고자 합니다.

과거에는 디자인 시스템 도입의 필요성을 역설하던 시기도 있었으나, 이제는 **디자인 시스템이 우리에게 당연한 존재**가 되었습니다. 이번 발표에서는 화려한 컴포넌트 이미지 대신, 클린 아키텍처와 타이디 퍼스트의 인용들을 통해 디자인 시스템에서 디자인을 뺀 '시스템' 자체에 집중하여 논의합니다.

디자인 시스템의 목적은 일관성 있는 고품질의 사용 경험을 제공하고 디자인, 개발, 커뮤니케이션 효율을 높이는 것이지만, 이는 **정의가 아닌 목적과 효과**입니다. 저는 디자인 시스템이 우리 서비스 제품과 함께 호흡하며 진화하는 유기적인 프레임워크이자, 곧 우리가 일하는 방법이어야 한다고 생각합니다.

디자인 시스템이 창의성을 해치지 않고 유연성과 확장성을 고민해야 한다는 생각은, 오히려 **디자인 시스템이 창의성을 위한 체계이자 효율적인 변화 대응을 위해 설계되어야 함**을 간과한 것일 수 있습니다. 이러한 고민을 해보셨다면, 여러분의 디자인 시스템은 진정한 '시스템'이 아니었을지도 모릅니다.

우아한공방의 탄생 배경과 구조

우아한형제들의 프론트엔드 개발자 수는 4년 전 15명에서 현재 100명 이상으로 **급격히 성장**했습니다. 초기에는 신규 서비스 론칭과 비즈니스 성공이 우선이었고, 효율적인 작업을 위해 서비스 단위의 컴포넌트 라이브러리가 운영되었습니다.

하지만 비즈니스 규모가 커지고 서비스가 늘어나면서, **기존의 분산된 구조는 한계**에 부딪혔습니다. 제품 전반의 사용 경험에 문제가 발생하고 중복 작업이 빈번해지자, 2022년에 일관성과 효율을 위해 라이브러리를 중앙화된 디자인 시스템으로 통합하기 시작했습니다.

여러 컴포넌트를 한곳에 모으는 과정에서 **제약과 복잡성이 증가**했고, 특히 시스템의 높은 장벽과 폐쇄적인 구조로 인해 엔지니어들의 사용 기피 문제가 발생했습니다. 이에 따라 우아한형제들의 업무 문화와 환경에 맞는 새로운 디자인 시스템 구조가 필요해졌으며, 이것이 바로 '우아한공방'입니다.

우아한형제들은 다양한 플랫폼과 서비스, 유연한 조직 변화, 잦은 UI 개편, 그리고 **각 프로덕트와 팀에서 독자적으로 발생하는 디자인 변경이라는 독특한 환경 조건**을 가지고 있습니다. 이러한 환경에 맞춰 우아한공방은 '쉬운 적용', '보수적 변경', '커뮤니케이션', '빠른 대응'이라는 네 가지 키워드를 바탕으로 계층형 구조로 설계되었습니다.

우아한공방은 크게 **클레이, 몰드, 코어 랭귀지 세 계층**으로 나뉩니다. 클레이 계층은 실제 디자인 시스템으로 불리며, 배민 앱을 위한 '민트'와 사장님 서비스를 위한 '블루'로 분류됩니다. 몰드 계층은 각 클레이 하위에 존재하며, 음식배달이나 B마트 같은 도메인 특수성을 담은 패턴과 컴포넌트 라이브러리를 포함합니다.

코어 랭귀지 계층은 컬러, 타이포그래피, 스페이싱 등 디자인 파운데이션 및 엔지니어링 파운데이션 요소로 이루어져 있으며, **클레이의 기반이 됩니다.** 이전까지 이 코어 랭귀지 계층은 구체화된 적이 없었지만, 오늘의 주제인 코어 시스템은 바로 이 코어 랭귀지 계층을 시스템으로서 구체화한 것입니다.

코어 시스템의 도입은 불필요하게 두 개로 나뉘었던 시스템을 하나로 통합하는 의미를 가집니다. 이를 통해 각 클레이는 하나의 메인 시스템에 기반을 둔 하위 시스템으로 역할이 전환되며, **시스템 인터페이스의 일관성을 확보하고 계층 간 경계를 명확히** 나눌 수 있게 됩니다.

코어 시스템은 컨텍스트와 비즈니스 로직이 없는 **순수한 컴포넌트의 상호작용과 형태 구성을 위한 인터페이스**를 갖춥니다. 클레이 계층은 토큰 기반으로 각 서비스의 디자인 언어를 생성하고 공통 컨텍스트 및 컴포넌트 조합을 고차 컴포넌트로 만듭니다. 몰드 계층은 서비스 특수성과 비즈니스 로직을 담은 구체화된 라이브러리가 됩니다.

코어 시스템 설계의 필요성: '시스템'의 부재

제가 코어 시스템을 설계한 가장 중요한 이유는 말장난 같지만, **'시스템이 없었기 때문'**입니다. 이전에 존재했던 클레이는 시스템이라기보다는 가이드라인과 컴포넌트 목록에 불과했다고 생각합니다.

가이드라인과 컴포넌트 목록은 디자인 시스템의 필수 요소지만, 그 자체만으로는 디자인 시스템이 될 수 없습니다. 이는 **어지러운 집을 청소하는 것과 물건을 정리하는 기준 및 원칙 체계를 구축하는 것의 차이**와 같습니다. 전자는 일시적 해결에 불과하며, 어지럽히는 원인이 제거되지 않는 한 문제는 반복됩니다.

디자인 시스템과 가이드라인의 차이는 **'체계의 유무'**에 있습니다. 우리의 디자인 시스템이 체계를 갖추고 운영되는지 확인하기 위해 유저 보이스를 살펴보겠습니다. 우아한공방은 작년 10월 1.0 정식 버전 출시 당시 생산성 향상, QA 시간 단축 등 호평 일색이었습니다.

그러나 출시 1년 후 서베이 결과, **프로덕트 대응 및 디자인 스타일 유연성 불만족이 45.7%**에 달했고, 생산성 불만족도 33.3%였습니다. 이는 클레이의 시스템 복잡성이 증가하고 사용성이 저하되었으며, 운영 및 대응에 더 오랜 시간이 필요해졌다는 것을 보여줍니다. 그 이유는 바로 '원칙과 기준, 즉 체계의 결여' 때문입니다.

여기서 말하는 기준과 원칙이란 **의사결정 및 가치 판단의 기준과 원칙**입니다. 우아한공방은 능력 있는 디자이너와 엔지니어들의 노력으로 만들어졌지만, 기준과 원칙 체계가 없으면 아무리 유능한 인재라도 훌륭한 제품을 만들기 어렵습니다.

클레이 제작 과정에서 각 디자이너는 연결된 서비스를 독립적으로 분석하고 정리했습니다. 이후 공유 및 논의 과정에서 각자의 의견은 타당했지만, **서로 알지 못하는 영역이어서 강제하기 어려웠고 시간도 부족**했습니다. 이러한 상황은 클레이뿐만 아니라 각 컴포넌트 내부에서도 반복되었습니다.

업무 영역을 효율적으로 분리하고 존중하며 진행했음에도 불구하고, 결과적으로 **클레이 민트와 블루는 완벽하게 다른 인터페이스와 컴포넌트 분류 체계**를 가지게 되었습니다. 피그마에서 컴포넌트가 구성된 방법마저 달랐습니다.

컴포넌트 인터페이스의 차이는 도메인 특수성이 아니며, **얻을 수 있는 이익이 전혀 없습니다.** 이는 조직 변경 시 학습 부담을 늘리고, 불필요하게 두 벌의 코드가 작성되게 만듭니다. 이는 '쉬운 적용, 빠른 대응, 커뮤니케이션'이라는 우아한공방의 핵심 키워드에 반하는 결과입니다.

소프트웨어 설계는 '요소들을 유익하게 관계 맺는 일'이며, 마치 작은 하위 요소들로 거대한 수프를 만드는 작업과 같습니다. 우리가 만들어야 했던 것은 각각의 클레이가 아닌, **코어 랭귀지에 기반한 '우아한공방'이라는 하나의 큰 수프**였습니다.

기준과 원칙 체계가 없는 세분화된 팀은 무질서 상태와 같아, **참조할 레퍼런스가 너무 많고 개인의 선호에 따른 의사결정이 빈번**해집니다. 만약 코어 랭귀지를 먼저 구체화하고 기준과 원칙을 수립한 후 클레이를 만들었다면, 레퍼런스 범위가 줄고 목적이 명확해져 정제된 의견을 모을 수 있었을 것입니다.

시스템 기반 디자인의 기본은 **정책을 만들고 세부 사항에 적용하며, 문제 발견 시 정책을 개선하고 재적용하는 유기적인 과정**입니다. 예를 들어, 자동차 핸들 위치를 결정할 때 영국과 미국을 벤치마킹하는 것이 아니라, 우리의 도로 정책이 무엇인가를 살펴봐야 합니다. 핸들 위치는 단순히 기호의 문제가 아니라 차선, 주차장, 톨게이트 등 모든 것에 연결됩니다.

좌핸들/우핸들이 공존하는 세상은 무질서하고 사용자 모두에게 불편하며, 생산 공정에도 비효율을 초래합니다. **상대적인 가치 판단들은 정책으로 존재할 때 불필요한 고민과 공정을 제거**할 수 있습니다. 엉클 밥의 클린 아키텍처는 소프트웨어 시스템을 '정책을 기술한 것'이라고 정의합니다.

우리는 가이드라인에 정답과 오답을 다루려 하지만, **실제로 업무를 방해하는 것은 명백히 틀린 상황이 아니라 '정책과 기준이 없어 판단될 수 없는 정답과 정답 간의 논쟁'**입니다. 이는 우리의 시간을 가장 많이 소모하는 커뮤니케이션입니다.

시스템 디자이너의 역할은 단순히 컴포넌트를 아름답게 정리하는 것을 넘어, **사용자를 힘들게 하는 커뮤니케이션을 살피고 기준과 원칙을 만드는 역할**입니다. 정책 간 모순을 끊임없이 검토하고 요소 간 유익한 관계를 맺어 생태계를 구성하며, 사용자 중심으로 유래를 해석하여 가치 판단이 필요한 요소에 대한 의사결정을 이끄는 주체가 되어야 합니다.

이러한 선택들은 곧 우리가 일하는 기준이 되고 방법이 됩니다. 컴포넌트는 단지 **우리가 일하는 방식을 학습하고 이해할 수 있는 매개체**일 뿐입니다. 원칙과 기준이 해결해 주는 것은 바로 의사결정과 커뮤니케이션이라는 가장 큰 어려움입니다.

우리의 디자인 시스템 목적은 중요한 문제에 집중하고 업무 효율을 높이며 커뮤니케이션을 원활하게 하는 것이지만, 우리는 대부분의 시간을 컴포넌트와 쉬운 가이드라인 작성에 치중하고 있습니다. 디자인 시스템의 사용자들은 전문가이기에, 그들이 궁금해하는 것은 **'당신들이 어떻게 일하는지, 무엇을 기준으로 하는지'**입니다.

백종원, 안성재 셰프처럼 뚜렷한 가치관을 가진 심사위원들이 존재하는 '흑백 요리사' 쇼처럼, **명확한 가치관이 없다면 창작자는 힘든 상황**에 놓이게 됩니다. 클레이 제작 과정에서 의사결정 기준이 없었기 때문에 디자인과 코드에 저자에 대한 강한 의존성이 생겼습니다.

이는 시스템 디자이너조차 시스템을 학습하고 예측하기 어렵게 만들며, **각각의 저자가 각각의 시스템**이 되는 상황을 초래합니다. 디자인 가이드라인과 실제 코드 구현이 일치한다는 보장이 없어 코드 분석이 필수적이고, 운영 과정의 대응이 복잡해져 과제 일정에 영향을 미칩니다.

주관적인 의사결정은 시스템 구조 전반에 영향을 미쳐, 시스템이 폐쇄적인 인터페이스를 가지게 됩니다. 이로 인해 엔지니어는 시스템 업데이트를 기다려야만 컴포넌트 구현이 가능해지는 경우도 생깁니다. 결과적으로 **몰드는 의미가 퇴색되고, 비즈니스 로직과 도메인 특수성이 클레이로 몰려 컴포넌트가 점점 복잡**해집니다.

클린 아키텍처의 솔리드 원칙을 디자인 시스템에 대입해 보면, 모든 팀이 사용하는 클레이에 개별 컨텍스트와 비즈니스 로직이 반영되는 것은 **단일 책임 원칙에 위반**됩니다. 이는 컴포넌트의 변경 주기를 다르게 만들고, 아예 다른 분류의 컴포넌트가 될 가능성을 높입니다. 사용자 입장에서도 학습 부담과 의도치 않은 사용이 발생할 수 있습니다.

코어 시스템이 필요한 또 다른 기준은 **'검증 기준'**입니다. 의사결정 및 구현 방법의 부재로 클레이에 비즈니스 특수성이 담긴 컴포넌트가 업데이트되는 것은 매우 치명적입니다. 프로덕트 팀에서 만든 아직 검증되지 않은 컴포넌트, 즉 사용자 피드백이나 지표 기반으로 변경될 여지가 있는 컴포넌트가 시스템에 등록되는 것은 전 제품에 적용 가능함을 의미합니다.

켄트의 타이디 퍼스트에 따르면, '되돌릴 수 있는 결정'과 '되돌릴 수 없는 결정'은 다르게 취급해야 합니다. 아직 검증되지 못한 컴포넌트가 시스템에 등록되어 사용되기 시작하면, **개선에 막대한 공수가 필요**합니다. 구글의 머터리얼 디자인조차 특정 제품에 특화된 정책을 기반 가이드라인에 함부로 업데이트하지 않습니다. 우리는 검증된 컴포넌트와 그렇지 못한 컴포넌트를 구분하고, 무엇이 어디에 위치해야 하는지에 대한 기준이 필요합니다.

결론적으로 **의사결정 및 가치 판단의 기준, 컴포넌트 설계 및 구성 규칙, 운영 규칙 및 프로세스, 시스템 운영 원칙**이 필요했습니다. 이러한 기준과 원칙의 부재는 저자의 의존성을 만들고, SOLID 원칙을 위반하며, 컴포넌트와 시스템의 복잡성을 증가시키고 계층형 시스템의 경계를 불분명하게 만들었습니다.

제가 코어 시스템을 설계한 이유는 **기존 디자인 시스템을 갈아엎지 않고도 원래의 컨셉과 목적을 달성할 수 있는 방법**이었기 때문입니다. 코어 시스템은 위에 언급된 대부분의 문제들을 해결할 수 있습니다.

코어 시스템 설계를 시작하며, 해결해야 할 문제와 달성해야 할 목표를 상기했습니다. 첫째, 유연한 조직 변경에도 새로운 학습이 필요 없도록 **시스템 인터페이스를 통합하고 학습 곡선을 완만**하게 하는 일관성과 예측성 확보. 둘째, 프로덕트 UI 변경을 바로 구현하고 모듈에 가둘 수 있는 구조. 셋째, **디자인 시스템 엔지니어/디자이너와 제품 디자이너/엔지니어의 역할 경계를 명확히** 하는 것입니다.

시스템의 물리적 구조 변경이 필요했습니다. 기존 디자인 시스템은 디자이너의 피그마에서 시작하여 각 플랫폼에 전달되었는데, 피그마는 완벽하지 않은 도구이며 토큰 이해에 어려움을 주었습니다. 따라서 피그마를 **생성 및 관리 주체가 아닌 '시스템과 연결된 하나의 채널'**로 다루고자 합니다.

코어 시스템과 각 채널 사이에는 **'파운데이션 API'**가 존재합니다. 이는 피그마에서 구현 불가능한 여러 기능과 각 플랫폼을 존중하는 편의 도구들로 구성됩니다. 초기에는 조악했지만 현재는 웹프론트 팀의 고도화를 거쳐 깃랩과 연동되어 잘 작동하고 있으며, 앞으로도 피그마의 한계와 플랫폼별 필요한 요소들을 담아 확장될 예정입니다.

2. 베이스 컴포넌트 (Base Component)

코어 시스템의 가장 핵심적인 요소는 **'베이스 컴포넌트'**입니다. 베이스 컴포넌트는 스타일링이 없는 순수한 기능만을 담은 헤드리스 UI로, 기능과 형태를 분리하여 관심사를 분리하고 최상위 코어 시스템에서 제공합니다. 이는 SOLID 원칙 중 단일 책임, 리스코프 치환, 개방 폐쇄, 인터페이스 분리 원칙과 직접적으로 연결됩니다.

베이스 컴포넌트를 통해 시스템 컴포넌트의 복잡성을 낮추고, 시스템 계층별 컴포넌트 역할 및 디자이너/엔지니어의 역할을 명확히 할 수 있습니다. 또한 최하위 몰드에서 직접 사용 가능하므로, **긴 운영 검토 반영 프로세스를 기다릴 필요가 없어집니다.**

베이스 컴포넌트는 각 클레이에서 토큰과 팀을 기반으로 스타일을 입혀 고차 컴포넌트로 제공됩니다. 이를 통해 우아한공방의 **'보수적 변경' 키워드를 지킬 수** 있습니다. 몰드 계층에서는 실제 비즈니스 맥락이 담긴, 더 이상 확장될 필요 없는 컴포넌트로 정의되거나 더 복잡한 컴포넌트 조합을 정의할 수 있습니다.

더 쉬운 언어로 표현하면, 코어 컴포넌트는 **색이 없는 레고 블록**과 같습니다. 클레이는 블록에 약속된 언어로 색을 입히고 검증된 조합을 제공합니다. 몰드에서는 실제 레고 블록을 조합하고 구체적인 맥락을 주입하여 완성된 테마의 레고 제품(제품에 직접 연결되는 컴포넌트)을 만드는 구성으로 존재합니다.

이러한 구조를 통해 다양한 테마의 레고 제품을 만들더라도 **클레이와 코어의 복잡성을 증가시키지 않고, 다양성이 발생한 부분을 몰드 안에 가둘 수** 있습니다.

현재 가장 큰 과제이자 즐거움은 **선언적인 패러다임에 적합한 UI 디자인**을 어떻게 할 것인가에 대한 고민입니다. 웹, 안드로이드, iOS 세 플랫폼 모두 리액트, 제트팩 컴포즈, 스위프트 UI를 사용하여 선언적인 패러다임을 추구하기 때문입니다. 이에 따라 작고 단순한 기능의 컴포넌트로부터 점진적으로 조합하여 설계하는 원칙을 세우고, 조합 가능성과 하위 컴포넌트의 관계를 검증하고 있습니다.

우리는 **'보이는 그대로 만들 수 있고, 설계자와 구현자 모두 저자 의존성 없이 신뢰할 수 있는 디자인'**을 구체적인 목표로 삼았습니다. 이를 위해 구현 주체인 엔지니어의 멘탈 모델에 부합하는 약속된 컴포넌트 디자인 규격을 만들기 시작했습니다.

단순한 컴포넌트라도 피그마에서 그리는 방법이나 코드 구현 방식이 너무 많습니다. 디자이너에 따라 해석과 표현이 다르고, 이에 따라 구현도 달라집니다. 이는 **열어보지 않으면 신뢰할 수 없는 구조**이며, 확인을 강제하여 클레이 운영 과정에서 가장 큰 시간을 소모하게 만든 원인이었습니다.

우리의 약속된 컴포넌트 디자인은 작고 큰 컴포넌트를 구성하는 패턴들을 나누어 **모든 컴포넌트에서 사용할 수 있는 레이어로 모드를 구성하고 동일한 원칙으로 설계**합니다. 주요 레이어로는 UI 크기/도형 면을 다루는 '컨테이너 레이어', 마우스/터치 상호작용에 사용되는 '스테이트 레이어', 컴포넌트 내부 배치/간격을 조정하는 '콘텐츠 레이어', 조합/관심사 분리의 핵심인 '슬롯', 아이콘 표에 특화된 '셰이프 레이어'가 있습니다.

각 레이어는 고유의 토큰과 속성을 가지며 겹치는 역할이 없습니다. 이는 코어 컴포넌트 디자인 관점에서 **문제를 해결하는 방법을 하나로 가정하여 컴포넌트 스펙, 구현, 관리 측면에서 효율을 높이기 위함**입니다. 코어 시스템의 컴포넌트 화면 구성은 슬롯 기반 레이아웃과 컴포즈/스위프트 UI 레이아웃 프리미티브에 기반해 배열 및 배치를 위한 인터페이스 기준을 세웠습니다.

특히 수직/수평 방향성이 고정된 컴포넌트에는 **기명 슬롯을 채택하여 맥락을 구체화**했습니다. 또한 컴포넌트가 가질 수 있는 슬롯 구성을 단순화하고 규격화하여 조합 과정에서 발생할 수 있는 설계 불일치를 방지합니다. 예를 들어 칩과 아이콘 버튼이 조합된 '리무버블 칩' 같은 고차 컴포넌트는 약속된 규격의 청사진을 통해 직관적으로 코드와 연결될 수 있습니다.

컴포넌트와 모듈 구성 방식에도 변화가 있습니다. 기존 클레이는 하나의 컴포넌트가 모달리티, 모바일/데스크탑 변환 등 **모든 로직을 포함**했습니다. 바텀 시트처럼 구현 세부 사항과 내부 동작이 숨겨져 있고, 정의된 동작에 제한이 있었으며, 페이지 시트와 같이 유사 로직을 공유하는 컴포넌트와 관심사가 겹쳐 단일 책임 원칙에 위배되었습니다.

반면 새로운 컴포넌트 규칙은 **각 부분이 무엇인지 명확히 선언**되어 있으며, 더 작은 단위의 합성도 가능합니다. 또한 컴포넌트 내부에서 주변 요소에 영향을 주던 스페이싱 요소를 전부 삭제했습니다. 이를 통해 '컴포넌트가 어떻게 생겼는가'와 '레이아웃 프리미티브가 어떻게 배치되는가'라는 관심사를 완벽하게 분류하고, 코드의 선언적인 의도를 명확히 하며, 조합 시 발생했던 유지보수 문제를 줄일 수 있습니다.

새로운 컴포넌트 구현 프로세스

프로덕트 엔지니어들은 새로운 컴포넌트 구현 시 두 가지 선택지를 갖습니다. 단일 컴포넌트의 미세한 변화나 몰드의 특정 영역 업데이트 시 **클레이 컴포넌트의 컴포넌트 토큰 오버라이드를 활용**할 수 있습니다. 혹은 완전히 새로운 스타일의 독립적인 컴포넌트를 구현할 경우, **베이스 컴포넌트를 직접 사용해 속성과 토큰 기반의 구현**을 할 수 있습니다.

이는 과제 진행 중 시스템 대응을 막연히 기다리는 상황을 피하고, 클레이 입장에서는 **검증되지 않은 로컬 컴포넌트를 시스템에 담지 않고 몰드에 고립**시킬 수 있게 합니다. 만약 몰드의 일관성 있는 변경이 필요하면, 클레이의 팀(컴파운드 토큰과 시멘틱 토큰)을 오버라이드하여 특정 몰드의 독립적인 일관성을 만들 수도 있습니다.

마지막으로 형태 구현이 아닌 **인터페이스 확장**의 경우, 클레이에서 베이스 컴포넌트의 확장이 필요할 때는 코어로 각 시스템 간 명확히 구분된 경계에 맞춰 요청하는 프로세스를 가지게 됩니다.

결론: 더 나은 협업을 위한 시스템

좋은 코드를 작성할 수 있는 디자인을 하고, 창의적인 디자인을 할 수 있는 코딩을 하는 것은 적은 노력으로도 쉽게 시작할 수 있다고 생각합니다. 멋진 디자인과 깨끗한 코드가 항상 비즈니스 성공을 보장하지는 않겠지만, **매일 그것을 다루는 디자이너와 엔지니어에게 행복과 자긍심을 보장하며, 예상치 못한 상황에 더 유연하게 대응**할 수 있게 합니다.

디자이너가 코딩을 배우고 엔지니어가 디자인을 배울 필요는 없으며, 오히려 얕은 지식은 해가 될 수 있습니다. 하지만 **서로가 사용하는 도구, 언어, 프레임워크, 그리고 추구하는 철학을 배우려는 작은 관심과 시간**은 함께 일하는 동료와 같은 수준의 대화를 가능하게 할 것입니다.

우아한형제들이 '우아한공방' 디자인 시스템을 재설계하게 된 주요 동기와 이전 시스템의 한계점은 무엇인가요?

기존 디자인 시스템 운영 시 발생했던 주요 문제점들을 사용자들의 피드백을 통해 어떻게 확인했으며, 이러한 문제점들이 코어 시스템 도입의 필요성과 어떻게 연결되나요?

코어 시스템에서 '베이스 컴포넌트'의 역할과 중요성은 무엇이며, 이것이 기존 클레이 계층 및 몰드 계층과 어떻게 상호작용하여 시스템의 복잡성을 해결하고 효율성을 높일 수 있나요?

코어 시스템이 제안하는 컴포넌트 설계 구성 및 규칙(컨테이너 레이어, 스테이트 레이어, 콘텐츠 레이어 등)은 디자이너와 엔지니어 간의 협업 및 신뢰할 수 있는 디자인 제작에 어떤 긍정적인 영향을 미칠 것으로 예상되나요?

궁극적으로 코어 시스템이 추구하는 '좋은 시스템'이란 무엇이며, 이것이 디자이너와 엔지니어에게 어떤 가치를 제공하고 업무 방식을 어떻게 변화시킬 수 있다고 생각하나요?

서론: 발표자 소개 및 우아한공방 코어 시스템 소개

발표자인 유 엔지니어와 허준 인터랙션 디자이너가 우아한형제들의 디자인 시스템 팀에서 코어 시스템을 담당하고 있음을 소개.

발표 주제는 우아한형제들의 디자인 시스템인 '우아한공방'의 코어 시스템.

발표 순서는 코어 시스템의 정의, 설계 이유, 구성 방식.

단순한 시스템 소개보다 시스템 디자이너와 엔지니어가 겪었던 고민과 인사이트를 공유하고 싶다는 발표 의도.

디자인 시스템에서 '디자인'을 뺀 '시스템' 자체에 집중하여 이야기할 것임을 강조.

디자인 시스템의 정의와 필요성

일관성과 효율성 제공은 디자인 시스템의 목적이지 정의가 아니라고 설명.

디자인 시스템은 서비스 제품과 함께 진화하는 유기적인 프레임워크이자 일하는 방식이어야 한다고 재정의.

디자인 시스템이 창의성을 해치지 않아야 한다는 고민 자체가 시스템이 아니었을 수 있음을 지적.

우아한공방의 탄생 배경 및 구조

2020년 15명이었던 프론트엔드 디벨로퍼가 현재 100명이 넘는 등 짧은 시간에 팀 규모가 급격히 성장했음을 언급.

초기에는 신규 서비스 론칭과 비즈니스 성공이 우선이었으며, 서비스 단위로 컴포넌트 라이브러리가 운영되었음.

비즈니스 규모 성장으로 기존 구조는 한계를 맞이하고, 제품 전반의 사용 경험 문제 및 중복 패턴 발생.

2022년에 일관성과 효율을 위해 중앙화된 디자인 시스템을 구성했으나, 높은 장벽과 폐쇄적인 구조로 엔지니어들이 사용을 지양하는 문제 발생.

기존 시스템을 벗어나 우아한형제들의 업무 문화와 환경에 맞는 새로운 계층형 디자인 시스템인 '우아한공방'의 필요성 제기.

우아한형제들의 환경 조건: 다양한 플랫폼과 서비스, 유연한 조직 변경, 잦은 UI 개편, 프로덕트 및 팀별 독자적인 디자인 변경.

우아한공방은 쉬운 적용, 보수적 변경, 커뮤니케이션, 빠른 대응의 네 가지 키워드를 가지고 계층형 구조로 설계됨.

우아한공방의 계층 구조: 클레이 (디자인 시스템 본체, B2C/B2B), 몰드 (클레이 하위, 도메인 특수성), 코어 랭귀지 (클레이 기반).

코어 랭귀지는 컬러, 타이포그래피, 스페이싱 등 디자인 및 엔지니어링 파운데이션 요소로 구성.

코어 랭귀지 계층이 구체화된 적이 없었으며, 코어 시스템은 이 코어 랭귀지 계층을 시스템으로서 구체화한 것.

코어 시스템은 불필요하게 나뉘었던 두 개의 시스템을 하나로 통합하는 역할.

코어 시스템의 존재로 각 클레이가 하나의 메인 시스템에 기반한 하위 시스템으로 전환되고, 시스템 인터페이스 일관성 및 계층 경계 명확화.

코어 시스템은 컨텍스트와 비즈니스 로직이 없는 순수한 상호작용 및 형태 구성을 위한 인터페이스 제공.

클레이 계층은 디자인 언어와 토큰 기반으로 공통 컨텍스트 및 고차 컴포넌트 생성, 몰드 계층은 서비스 특수성과 비즈니스 로직 담은 라이브러리.

코어 시스템 설계 이유: '시스템 부재'와 '체계의 중요성'

코어 시스템을 설계한 이유는 '시스템이 없었기 때문'.

이전의 클레이는 시스템이 아닌 가이드라인과 컴포넌트 목록에 불과했음.

가이드라인과 컴포넌트 목록만으로는 디자인 시스템이 될 수 없으며, 체계의 유무가 핵심.

정리 수납 전문가 비유를 통해 일시적인 정리와 원칙 체계 구축의 차이 설명.

디자인 시스템과 가이드라인의 차이는 '체계의 유무'임을 강조.

우아한공방의 유저 보이스 분석 및 문제점

우아한공방 1.0 정식 버전 출시 1년 후 유저 보이스 변화.

출시 초기에는 생산성 향상, QA 시간 단축 등 호평 일색.

1년 후 서베이 결과: 프로덕트 대응 만족도 및 유연성 불만족 45.7%, 생산성 불만족 33.3% 등 부정적인 결과.

클레이의 복잡성 증가, 사용성 저하, 운영 및 대응 시간 증가의 원인은 '원칙과 기준, 즉 체계의 부재'.

기준과 원칙의 부재로 인한 문제점

필요한 기준과 원칙은 '의사결정 및 가치 판단의 기준과 원칙'.

우아한공방은 구성원 노력의 산물이나, 기준과 원칙 체계 없이는 훌륭한 제품 만들기 어렵다.

클레이(민트, 블루) 제작 과정에서 각자 분석, 분류, 정리 후 공유 및 논의했지만, 서로 다른 의견과 영역에 대한 강제 어려움.

클레이 내 컴포넌트 설계 및 구현 과정에서도 담당자별 논의를 거쳐 독립적으로 고도화.

결과적으로 클레이 민트와 블루는 완벽하게 다른 인터페이스를 가지며, 컴포넌트 분류 체계 및 Figma 구성 방식마저 다름.

이러한 차이는 이익이 없으며, 조직 변경 시 학습 비용 발생 및 코드 중복 발생.

이는 우아한공방의 쉬운 적용, 빠른 대응, 커뮤니케이션 키워드에 반함.

기준과 원칙 체계 없이 세분화된 팀은 무질서 상태와 같고, 개인의 선호와 취향에 의사결정이 그침.

코어 랭귀지를 구체화하고 기준과 원칙을 수립했더라면 레퍼런스 범위가 줄고 명확한 목표 설정, 의견 정제가 가능했을 것.

시스템 기반 디자인의 기본은 정책을 만들고 적용, 문제 발견 시 개선하는 유기적인 과정.

자동차 핸들 위치 비유를 통해 정책의 중요성과 시스템적 사고 강조.

소프트웨어 시스템은 정책을 기술한 것이며, 정책과 기준 없는 논쟁은 가장 소모적인 커뮤니케이션.

시스템 디자이너의 역할과 원칙 기준의 해결점

시스템 디자이너는 컴포넌트 정리 역할뿐 아니라, 기준과 원칙을 만들고 정책 모순 검토, 생태계 구성의 주체.

사용자 중심으로 결론을 내고, 가치 판단이 필요한 요소를 선별하여 의사 결정과 선택을 받는 주체.

이러한 선택들이 우리가 일하는 방법이 되며, 컴포넌트는 그 방법을 학습하고 이해하는 매개체.

원칙과 기준이 해결해 주는 가장 큰 어려움은 '의사결정'과 '커뮤니케이션'.

디자인 시스템의 목적은 중요한 문제에 집중, 업무 효율 증대, 원활한 커뮤니케이션.

시스템 사용자(디자이너, 엔지니어)는 전문가이며, 이들이 궁금해하는 것은 '어떻게 일하는지', '무엇을 기준으로 하는지'.

백종원, 안성재 셰프 비유를 통해 명확한 가치관과 기준의 중요성 설명.

클레이 제작 과정에서 의사결정 기준 부재로 디자인과 코드 저자에 대한 강한 의존성 발생.

시스템 디자이너도 시스템 학습 및 예측 어려움, 각 저자가 각각의 시스템이 되는 문제.

디자인 가이드라인과 실제 코드 구현 불일치로 코드 분석 필요, 운영 대응 복잡화 및 시간 소모.

주관적 의사결정은 시스템 구조 전반에 영향 미쳐 폐쇄적 인터페이스, 몰드의 의미 퇴색, 클레이로 비즈니스 로직 집중.

컴포넌트 복잡성 증가, Figma 베리언트 및 코드 조건절 증가, 가이드라인 장황화.

SOLID 원칙 위반: 클레이에 개별 컨텍스트 및 비즈니스 로직 반영은 단일 책임 원칙 위반.

코어 시스템 필요한 또 다른 기준은 '검증 기준'.

검증되지 못한 컴포넌트가 시스템에 업데이트되는 것은 치명적.

작은 지역구 임시 정책을 전체 도시에 적용하는 것과 같은 문제.

되돌릴 수 없는 결정은 면밀히 검토해야 하며, 검증되지 못한 컴포넌트 시스템 등록은 큰 공수 요구.

Material Design 사례를 통해 특정 제품 정책을 기반 가이드라인에 업데이트하면 안됨을 강조.

검증된 컴포넌트와 그렇지 못한 컴포넌트의 위치 기준 필요.

엣지 케이스는 시스템에 정의하지 않고, 시스템에 없다는 것 자체가 엣지 케이스를 의미한다고 생각.

필요한 원칙과 기준: 의사결정 및 가치 판단, 컴포넌트 설계 및 구성 규칙, 운영 규칙 및 프로세스, 시스템 운영 원칙.

기준과 원칙 부재로 인한 문제 요약: 저자 의존성, SOLID 원칙 위반, 복잡성 증가, 모듈 의미 퇴색, 계층 경계 불분명.

코어 시스템 설계 이유는 기존 디자인 시스템을 갈아엎지 않고도 원래 컨셉과 목적 달성, 대부분의 문제 해결 가능.

코어 시스템 설계 목표: 유연한 조직 변경에도 학습 불필요, 시스템 인터페이스 통합, UI 변경 즉시 구현, 역할 경계 명확화.

코어 시스템 구성 첫 번째는 '구조' 변경.

Figma를 시스템과 연결된 채널로 다루고, 코어 시스템과 채널 사이에 '파운데이션 API' 존재.

파운데이션 API는 Figma에서 불가능한 기능 및 각 플랫폼 존중 편의 도구로 구성.

코어 시스템 구성 두 번째이자 핵심은 '베이스 컴포넌트'.

베이스 컴포넌트는 스타일링 없는 순수한 기능만 담은 헤드리스 UI.

기능과 형태 분리로 SOLID 원칙(단일 책임, 리스코프 치환, 개방 폐쇄, 인터페이스 분리)과 직접 연결.

시스템 컴포넌트 복잡성 낮추고 역할 명확화, 몰드에서 직접 사용 가능해 긴 프로세스 회피.

베이스 컴포넌트는 각 클레이에서 토큰과 팀 기반 스타일 입혀 고차 컴포넌트로 제공, 보수적 변경 키워드 유지.

몰드 층에서는 비즈니스 맥락 담긴 컴포넌트 정의 또는 복잡한 컴포넌트 조합 정의.

레고 블록 비유를 통해 코어, 클레이, 몰드 계층의 역할 설명.

코어 구성 세 번째는 '컴포넌트 설계 구성과 규칙'.

선언적 패러다임(React, Jetpack Compose, Swift UI)에 적합한 UI 디자인 고민.

작고 단순한 기능 컴포넌트로부터 점진적으로 조합 설계 원칙 수립, 조합 가능성 및 하위 컴포넌트 관계 검증.

저자 의존성 없는 신뢰할 수 있는 디자인 및 엔지니어 멘탈 모델에 부합하는 약속된 컴포넌트 디자인 규격 목표.

동일 컴포넌트라도 디자이너/개발자에 따라 해석 및 표현 방식이 달라 신뢰할 수 없는 구조 문제 지적.

약속된 컴포넌트 디자인: 컨테이너, 스테이트, 콘텐츠, 슬롯, 셰이프 레이어로 구성되며 고유 토큰 및 속성 가짐.

각 레이어가 문제를 해결하는 방법을 하나로 가정하여 효율 증대.

슬롯 기반 레이아웃과 Compose/Swift UI 레이아웃 프리미티브 기반으로 배열 및 배치 인터페이스 기준 수립.

수직/수평 방향성 고정 컴포넌트는 기명 슬롯 채택, 슬롯 구성 단순화 및 규격화로 설계 불일치 방지.

칩과 아이콘 버튼 조합 예시를 통해 약속된 규격으로 디자인이 직관적으로 코드와 연결됨을 설명.

컴포넌트와 모듈 구성 방식 변화: 기존 클레이는 하나의 컴포넌트가 모든 로직 포함, 새로운 규칙은 각 부분 명확히 선언.

컴포넌트 내부의 스페이싱 요소 전부 삭제하여 관심사를 완벽하게 분류하고 유지보수 감소.

프로덕트 엔지니어의 새로운 컴포넌트 구현 프로세스: 토큰 오버라이드 활용 또는 베이스 컴포넌트 직접 사용.

시스템 대응 대기 상황 회피 및 검증되지 않은 로컬 컴포넌트 몰드에 고립 가능.

디자인 가이드를 넘어 비로소 시스템으로, 우아한공방 코어시스템 #우아콘2024 #우아한형제들

스크립트