안녕하세요.
이베이코리아에서 UI디자이너로 일하고 있는 차해리입니다.
올해 G마켓 애플리케이션 개편과 더불어 회사 내 일하는 방식에 큰 변화가 있었습니다.
과거 디자이너는 새로운 프로젝트마다 일회성 컴포넌트를 디자인(Sketch)하며 개발자는 끊임없이 늘어나는 컴포넌트로 유지 및 보수에 어려움을 겪었습니다. 이에 반해 현재 디자이너는 주어진 프로젝트에 디자이너와 개발자가 동기화한 공통 컴포넌트 라이브러리를 활용해 디자인(Figma)하며 개발자는 이 컴포넌트를 문서(Stroybook)로 관리하여 유지 및 보수에 효율성을 높이고있습니다.
이러한 큰 변화의 중심에는 디자이너와 개발자를 위한 도구, G마켓 디자인 시스템(이하 GDS)이 있습니다. 작년 2분기부터 현재까지 디자이너와 개발자가 모인 Design System Working Group이 디자인 시스템을 담당하여 진행한 과정을 공유하고자 합니다.
디자인 시스템이란
GDS를 소개하기에 앞서 ‘디자인 시스템’은 무엇일까요. 디자인 시스템이란 디자이너와 개발자 간 효율적인 커뮤니케이션 도구로써 원칙 및 가이드라인을 포함한 라이브러리 시스템입니다. 디자인과 프론트가 동기화한 공동 자산으로 디자이너는 일관된 사용자 경험에 집중할 수 있으며, 개발자는 픽셀이 아닌, 애플리케이션 로직에 집중할 수 있습니다.
‘디자인 시스템은 UI Kit이 아닌 산출물의 일부’라는 Dan Mall의 말을 인용하면, 디자인 시스템은 팀 모두가 활용할 수 있는 도구로 정의됩니다. 실례로 UI Kit를 활용했을 때는 디자이너의 작업 시간이 30% 절약에 그쳤지만, 디자인 시스템을 활용했을 때에는 프로덕트 구축 과정에서 팀 전체 작업 시간을 최대 70% 절약할 수 있었습니다.(출처 첨부)
GDS 정의
먼저 GDS를 구축하게 된 배경부터 살펴보겠습니다.
현재 G마켓은 내부적인 이해 수준에 따라 타이포그래피, 컬러 등 최소한의 규칙을 따르고있었습니다. 하지만 이 규칙이 문서로 관리되지않음으로 작업자마다 규칙 또는 규정에 관한 이해 수준이 상이하며, 디자이너와 개발자 간 이해가 동기화되지않는 문제를 지니고 있었습니다. 그에 따라 규정 및 검증되지 않은 컴포넌트로 사용자 경험의 일관성과 관리의 효율성을 저해되는 문제점을 작업자 간 동기화한 규칙 문서를 관리하여 해결하고자 했습니다.
작년 초 G마켓 애플리케이션 개편 프로젝트 시작과 동시에 담당 디자이너와 개발자가 모여 관련 문서화 방식을 ‘디자인 시스템’으로 구체화하게 되었습니다. 자체 디자인 시스템을 구축함으로써 작업자 관점에서 각 컴포넌트단위 ‘Size’ 또는 ‘States’ 패턴에 관해 고민하는 시간을 줄이고, 프로덕트단위로 사용자 경험을 고려하여 일관성과 효율성을 증대할 수 있었습니다. 또한 이 규칙은 개발자와 동기화하여 커뮤니케이션 비용을 감소시켰습니다. 이에 따라 작업자와 프로덕트 및 사용자의 경험이 어우려져 시너지 효과가 발휘될 것으로 기대되었습니다.
이후 이러한 효과를 지닌 디자인 시스템을 G마켓 서비스 규모와 니즈에 따라 구체화하는 작업이 필요했습니다.
GDS Principle
●일관성(Consistency): 브랜드 정체성과 사용성 일관성을 유지합니다.
● 확장성(Scalable): 디자인과 프론트 코드 동기화로 공동 라이브러리(언어) 자산을 확충합니다.
● 효율성(Efficiency): 재사용성과 생산성을 높여 프로덕트 전체적 관점에서 일할 시간을 가집니다.
즉, GDS는 디자이너와 개발자 간 효율적인 커뮤니케이션 도구로써 가이드 라인 및 라이브러리를 공동 자산으로 포함합니다. 재사용 가능한 UI 규칙과 개념을 1차 공동 도큐먼트로 관리하며, 이를 기반으로 디자이너와 디자이너 또는 개발자와 개발자가 논의한 2차 디자인 및 코드 라이브러리 구축 및 적용을 목표로 합니다. 이처럼 정의가 실제 프로덕트 코드에 반영되어 개발 간 유지 및 관리 효율성을 가지고자 합니다.
UI 인벤토리, 패턴 취합
앞 서 언급한 목표에 따라 UI 패턴을 취합하는 과정, UI 인벤토리가 진행되었습니다.
UI 인벤토리란 프로덕트에 적용된 UI 스크린샷을 찍고 목적 기준으로 분류하는 과정입니다. 이 스크린샷을 Keynote 파일에 취합함으로써 당시 사용자 경험의 일관성을 저해하는 컴포넌트를 쉽게 파악하고 공유하고자하였습니다. 작년 5월을 시작으로 개편 이전 및 이후 패턴을 취합하였으며, 그 중 우선적으로 취합한 컬러와 버튼에 관해 살펴보겠습니다.
컬러 취합 및 통일
프로덕트의 가장 기본적인 언어인 컬러가 G마켓 애플리케이션에서 어떻게 사용하고 있었을까요?
우선 G마켓 프로덕트에 적용된 주요 색상인 그린(Green)을 살펴보겠습니다.
당시 프로덕트에 적용된 일부 컬러 ‘그린’ 취합 시 일관성 및 접근성 문제가 있음을 확인할 수 있었습니다. 일관성에 있어 그린은 쿠폰, 할인 금액인 ‘혜택’이라는 쓰임새로 동일하게 사용되고 있었습니다. 하지만 ‘그린’이 각 페이지에 따라 15가지 이상의 색상 코드로 분절되는 문제가 있었습니다. 또한 해당 색상은 디자이너와 개발자가 서로 다른 이름 규칙으로 추후 관리에 문제를 겪을 수 밖에 없었습니다. 접근성에 있어서는 여러 그린 색상이 텍스트 컬러로 사용될 경우 배경(화이트 #FFFFFF)과 색 명암대비가 웹접근성 기준(AAA 4.5:1, WCAG guidelines)에 미달하는 큰 문제를 지니고 있었습니다.
이에 따라 색상과 쓰임새를 규정하는 컬러 시스템 관리가 필요했습니다. 따라서 프로덕트에 쓰이는 색상(Hue)을 10가지로 한정하고, 10가지 색상이 동일한 명도로 관리되도록 50–900, 10단계를 추출(‘ColorBox’ 활용) 했습니다. 그리고 웹 접근성을 고려하여 각 색상과 조합 가능한 색상을 화이트, 블랙으로 정하였습니다. 이처럼 색상에 따라 차이가 있지만 그린 기준으로 50–600단계는 블랙, 700–900 단계는 화이트로 규정하였습니다.
이 외에도 표준화된 색상이 관리됨에 따라 디자이너와 개발자가 색상에 관한 공통된 이름을 관리할 수 있는 기반이 마련되었습니다. 앞 서 색상 10가지 색상은 가장 명확하게 인지할 수 있는 이름으로 관리하고, 이 색상이름과 명도 단계를 조합한 타입(Global tokens)으로 관리하였습니다. 해당 색상 이름이 명확한 맥락 및 목적으로 사용될 시에는 맥락과 목적을 조합한 타입(Alias tokens)으로 관리하였습니다. 이로 인해 디자이너와 개발자가 동기화한 컬러 이름으로 효율화를 더할 수 있습니다.
컴포넌트 취합 및 통일
파운데이션과 달리 컴포넌트는 접근성 외에도 UX 원칙(참고) 반영이 필요했습니다. 대표적인 예로 컴포넌트에서 가장 주요한 CTA요소인 버튼을 살펴보겠습니다.
버튼은 버튼이 지닌 형상(컬러, 사이즈, 내용물)을 기준으로 논의가 이루어졌습니다. 버튼 Background color는 위에서 Active로 규정된 ‘Green-500’을 동일하게 규정했습니다. 이외에도 버튼은 시각적 계층 구조(Primary, Secondary, Tertiary)에 따른 형상 고려가 필요했습니다. 이에 따라 버튼 타입을 전체 시안에 테스트하여 e커머스 특성상 ‘구매’, ‘결제’ 버튼에 명확한 계층 구분을 두기로 의견이 모아졌습니다. 그 결과 Primary Button(주요 버튼)은 ‘Green-500’ 색상으로 페이지 키 액션 버튼으로 사용하되, CTA Button(Call to Action 버튼)은 ‘CTA’ 색상으로 e커머스에서 가장 주요 행동(주문, 결제)을 유도하는 버튼으로 한정 사용하게 되었습니다.
Workflow Process, 동기화 작업
작년 8월 Kick-off 를 시작으로 디자이너, 웹 프론트엔드 개발자, 퍼블리셔가 모여 본격적인 동기화 작업이 진행되었습니다.
이 동기화 작업으로 Discovery에서부터 Release까지 구축 프로세스를 생성했습니다. 이 프로세스 중 가장 고민이 많았던 디자인시스템 단위를 논의하는 ‘Discovery’와 앞 서 단위를 문서로 관리하는 ‘Documentation’를 꼽을 수 있습니다. 두 내용에 한정하여 과정을 자세히 살펴보겠습니다.
Discovery
우선 Discovery 단계에서 ‘단위’에 관해 논의했습니다.
디자인 시스템 단위는 Atomic Design(Brad Frost) 참고하여 디자이너와 개발자가 논의해 UI를 나누고 조합하여 정해나갔습니다. 이 과정으로 단위를 자율성 및 효율성을 고려해 Design Token에서 Component단위까지 포함하되, 템플릿과 페이지는 제외하기로 정해졌습니다. 이렇게 UI에 관한 단위를 규정함으로써 체계적이고 일관된 관리의 시작점이 될 수 있었습니다.
GDS Unit
● Design Token > Foundation > Component > Template > Page
이 단위 중 가장 작은 단위인 디자인 토큰은 디자인 속성을 관리함으로써 시각적 일관성과 관리 효율성 고려할 수 있었습니다. 그럼 디자인 토큰에 관해서는 타이포그래피를 예시로 살펴보겠습니다. 타이포그래피는 Typefaces, Font Sizes, Font Weight, Line Height이란 속성을 디자인 토큰으로 관리하였습니다. 이 토큰과 토큰의 결합은 Mixin단위로 관리하여, 디자이너는 피그마 로컬 스타일로 개발자는 피그마 API를 호출해 JSON형식을 SASS 가공해 관리되었습니다. 이처럼 디자인 속성 관리에 효율성을 향상함으로써 시각적 일관성을 더할 수 있었습니다.
Generate Design Tokens
● Figma File→Figma API→JSON file(Token data base)→Sass
또한 컴포넌트는 BEM 구조로 Component는 Block, Element, Modifier로 관리되었습니다. 이외에도 이 Element와 Component 또는 Component와 Component 조합에 따라 ‘단일’와 ‘복합’, ‘컴포넌트 그룹’ 등으로 기준을 정해나갔습니다. 그럼 컴포넌트에 관해서는 버튼을 예시로 살펴보겠습니다. 버튼은 ‘버튼’이라는 그룹에 포함되며, 그룹 내에는 공존 불가한 속성으로 Button, Action Button, Text Button, Icon Button, Top Button로 나누어 관리됩니다.
Documentation
위 동기화한 GDS단위를 문서로 관리하는 Documentation이 진행됩니다. Documentation에서 디자인과 코드는 별도가 아닌, 공동 내용으로 관리됩니다. 그렇기때문에 문서는 작업자 간 신규 및 기존 규칙 관리 효율성과 추출 용이성을 고려해 피그마로 관리되고있습니다. 그럼 규정한 DS Unit 단위를 문서 구조에 반영하는 부분부터 살펴보겠습니다.
문서 구조에서 파운데이션과 컴포넌트는 파일로 관리됩니다. 이 중 컴포넌트 파일은 컴포넌트단위가 페이지로 분절되며, 분절된 페이지에서는 각 컴포넌트의 가이드라인을 포함합니다. 이 각 컴포넌트 가이드라인 또한 작업자 간 논의한 속성 및 쓰임새 등을 포함함으로 목차 구조 및 이름 규정에 관해 논의한 사례가 있습니다.
해당 목차 중 Option은 컴포넌트 속성을 포함한 리스트로 관리되었습니다. 하지만 Option은 각 컴포넌트가 지닌 속성을 포괄적으로 또는 불명확하게 나타내므로, ‘Variant’이라는 피그마의 컴포넌트 속성 및 값에 따라 그룹핑하는 명칭으로 변경되었습니다.
기존 Option을 Variants로 변경합니다. Variants는 어떤 한 Component가 바뀔 수 있는 형상(버전)들로 Type, Size, State, Label, Icon 등의 Property가 바뀌어 나오는 형상들을 의미합니다. 가이드라인 작성 시에는 Label, Icon과 같이 자유롭게 바뀔 수 있는 Property는 Do&Don’t에서 관리합니다. 그리고 Table of Figma Properties에서 관리하는 것을 정해놓고 한정시킨 Varients만 “Variants”목차에서 관리합니다.
— 회의록 ‘Variants’ 일부
디자인 시스템 핵심은 문서화(Documentation)입니다. 따라서 앞 서 정의한 규칙과 개념이 문서에 녹아들면 에디터(문서 관리자)의 관리 효율성과 사용자(멤버 외 디자이너, 개발자)의 가독성을 향상시킬 수 있습니다. 이처럼 동기화한 문서를 기반으로 디자인과 코드 라이브러리는 피그마와 스토리북(Storybook)으로 분절되어 관리되고있습니다.
Next GDS 소개
그럼, GDS 버전 1.0.0을 시작으로 어디로 나아가야할까요?
첫번째는 도큐먼트 자체 웹사이트(Living Doucmentation) 구축입니다. 앞 서 설명드린 GMKT DS 공동 문서는 관리 효율성을 극대화하여 최신 정보를 담을 수 있어야하지만, 현재 문서는 리소스(Figma)와 코드(Storybook), 이외 논의 사항은 노션으로 분절되어있습니다.
이에 따라 공동 문서에 최적화한 사이트 구축이 필요합니다. 현재 이와 관련한 솔루션으로 Storybook과 zeroheight를 꼽을 수 있지만 이 솔루션은 React에 최적화되어, CSS기반 노출 및 관리 이슈로 자체 웹사이트를 구축하고자합니다. 현재 문서를 일괄 웹사이트로 이전하여 에디터 버전 관리 효율성 뿐 만 아니라 사용자의 탐색 경험 향상을 목표로 1분기 진행될 예정입니다.
두번째는 Sync 2nd를 진행하여 컴포넌트를 확장하고자합니다. 현재 버전 1.0.0에는 컴포넌트 그룹 22가지와 컴포넌트 406가지와 이외에도 스타일 132가지를 포함하고있습니다. 디자인 토큰에서 컴포넌트 외에도 탬플릿 단위를 추가 취합 및 확장하여 유지 및 보수관리 효율성 향상을 목표로 2분기 진행 예정입니다. 디자이너와 개발자의 컴포넌트 라이브러리에 포함된 단위의 재사용성을 높임으로써 gds.css 적용 범위를 확장되길 기대하고 있습니다.
마치며
구축 초기 가장 중요한 건 디자이너와 개발자 간 긴밀한 목표 및 방향성 동기화였습니다. Working Group 멤버는 디자인과 개발 툴부터 구축 환경까지 경험하고 논의하며 의견을 모았습니다. 이 과정으로 디자이너 또는 개발자라는 직군이 아닌, ‘작업자’라는 큰 틀에서 서로를 이해할 수 있었습니다.
이로 인해 디자인 시스템은 디자이너와 개발자 모두를 고려하는 도구로서 방향성을 동기화할 수 있었습니다. 그러나 이 동기화한 내용이 Working Group에 한정되지 않고, 팀 전반에 걸쳐 공감대를 형성하기위해서는 디자인 시스템에 관한 설명회는 필수적이었습니다.
따라서 올해 1월을 시작으로 ‘GDS Meetup’이라는 작업자 전체가 디자인 시스템 방향성을 인지하여, 가이드라인과 라이브러리를 적극적으로 활용할 수 있는 방안을 제시하기도 하였습니다. 현재까지 디자인 시스템 구축으로 인한 작업 프로세스 변화와 파운데이션, 컴포넌트단위에 관한 프로그램으로 나누어 진행되었습니다. 프로그램 이후 설문지와 다른 여러 채널을 통해 사용자인 디자이너와 개발자들에게 얻은 피드백은 추후 버전에 반영하여 도구로서 가치를 발전해 나갈 예정입니다.
아직 나아갈 길은 멀지만, 구축 과정에 관한 글로 다시 한번 더 찾아뵙겠습니다! 그럼 GDS에 관해 궁금한 점 또는 오류 내용은 댓글 부탁드리며, Working Group 멤버에게 감사하다는 인사로 글을 마무리합니다.
긴 글 읽어주셔서 감사하며, 또 다른 스토리가 궁금하다면 아래 G마켓 디자인 가이드라인 사이트를 방문해주세요 :)
© 2021 ebay Korea. All rights reserved.
