디자인 시스템, 이상과 현실 사이의 다리 놓기

취준생 시절, 디자인 시스템을 구현하는 프로젝트를 여러번 진행했다. 처음에는 '그저 공통 컴포넌트를 만드는 일'이라 생각했다. 디자인 시스템이라는 단어가 주는 무게감이 있었지만, 솔직히 그때는 디자인 시스템에 대해 긍정적인 감정을 느낀 적이 거의 없었다. 코드 구현에만 급급했고, 디자이너의 관점을 제대로 이해하려 하지 않았으며, 소통보다는 '내 방식대로' 하려 했다. 그러다 보니 디자인 시스템을 빈번하게 수정해야 했고, 경우에 따라서는 아예 초기부터 다시 설계해야 하는 경우도 빈번했다.

취업 후 디자인 시스템 관련 업무를 다시 맡게 되었을 때는 다른 마음가짐이었다. 단순히 코드 구현을 넘어 디자인 시스템이 가진 진정한 가치와 의미를 이해하고 싶었다. 책임감도 달라졌다. 이번에는 제대로 해보자는 생각에 여러 자료를 찾아보고 공부하기 시작했다.

디자인 시스템은 무엇인가: 단순한 UI 라이브러리를 넘어서

디자인 시스템이란 무엇일까? 위키피디아의 정의에 따르면, 디자인 시스템은 조직 내 디지털 제품 개발을 안내하는 포괄적인 표준, 문서화, 재사용 가능한 컴포넌트 모음이다. 디자이너와 개발자를 위한 단일 진실 원천(single source of truth)으로 작용하여 프로젝트 전반에 걸쳐 일관성과 효율성을 보장한다.

처음에 나는 디자인 시스템을 단순히 공통 UI 라이브러리 정도로만 생각했다. 버튼, 인풋 필드, 카드 등의 컴포넌트를 모아둔 것으로만 여겼던 것이다. 하지만 더 깊이 들어갈수록 디자인 시스템은 단순한 컴포넌트 집합이 아니라 전사적인 차원에서의 디자인 철학과 원칙, 그리고 이를 실현하기 위한 체계적인 접근 방식임을 깨달았다.

디자인 시스템의 역사는 흥미롭게도 1960년대로 거슬러 올라간다. 크리스토퍼 알렉산더(Christopher Alexander)가 NATO 소프트웨어 엔지니어링 컨퍼런스에서 '패턴'이라는 개념을 처음 언급하면서 시작되었다. 그가 나중에 출판한 "A Pattern Language"라는 책은 건축에서의 상호 연결된 패턴을 논의했는데, 이것이 오늘날 우리가 "디자인 시스템"이라고 부르는 개념의 기원이 되었다.

UI 디자인을 위한 패턴 언어에 대한 주류 관심은 2006년 Yahoo! 디자인 패턴 라이브러리가 개설되면서, Yahoo! 사용자 인터페이스 라이브러리(줄여서 YUI 라이브러리)의 도입과 함께 다시 급증했다. 이는 UI 라이브러리가 제공한 단순한 컴포넌트보다 더 체계적인 디자인을 가능하게 하기 위한 것이었다.

2014년 구글의 Material Design은 기업에 의해 "디자인 언어"라고 불린 최초의 것이었다(이전 버전은 "Holo Theme"이라고 불렸다). 곧 다른 기업들도 뒤따랐다.

2010년대에는 대규모 웹 프로젝트의 기술적 도전이 체계적인 접근 방식의 발명으로 이어졌으며, 특히 BEM과 Atomic Design이 주목받았다. Atomic Design에 관한 책은 2016년 이후 "디자인 시스템"이라는 용어를 대중화하는 데 도움을 주었다. 이 책은 디지털 제품 레이아웃을 컴포넌트 기반 방식으로 설계하는 접근법을 설명하면서, 미래 친화적이고 쉽게 업데이트할 수 있게 만들었다.

이미지 출처: https://medium.com/@vigneshwarmkasthuri/history-evolution-of-design-systems-a535179b0eb3

디자인 시스템이 등장한 근본적인 이유는 무엇일까? 소프트웨어 개발과 디자인 분야에서는 종종 일회성 솔루션을 제공해야 하는 상황에 놓인다. 시간적 제약 속에서 작업하거나, 앞으로 나아갈 방향에 대한 합의가 없는 경우도 있다. 이러한 일회성 솔루션들이 본질적으로 나쁜 것은 아니지만, 탄탄한 기반 위에 구축되지 않으면 결국 누적된 기술적 부채와 디자인 부채를 갚아야 하는 상황에 처하게 된다.

참고 자료:

• Understand the basics of design systems, what they are, how they work, and how they can change the way you design.
• Design system(Widipedia)

디자인 시스템의 구성 요소와 전사적 가치

이상적인 디자인 시스템은 조직 내에서 어떤 가치를 창출할까? Airbnb에서는 통합된 디자인 시스템(unified design system)은 더 나은 제품을 더 빠르게 구축하는 데 필수적이라고 말한다. 제품 개발 과정에서 디자인 시스템은 다음과 같은 전사적 가치를 제공한다:

1. 일관된 사용자 경험: 모든 제품과 서비스에서 일관된 경험을 제공함으로써 사용자의 학습 곡선을 줄이고 만족도를 높인다.
2. 개발 효율성 향상: 표준화된 컴포넌트를 재사용함으로써 개발 시간과 비용을 절감한다.
3. 협업 강화: 디자이너와 개발자 간의 공통 언어를 제공하여 소통을 원활하게 한다.
4. 의사결정 간소화: 미리 정의된 패턴과 가이드라인으로 의사결정 과정을 간소화한다.
5. 기술 및 디자인 부채 감소: 일관된 시스템으로 장기적인 유지보수 비용을 절감한다.

디자인 시스템은 단순히 컴포넌트의 모음이 아니라 디자인 토큰, 패턴 라이브러리, 스타일 가이드, 문서화, 그리고 이를 지원하는 도구와 프로세스를 포함한다. 이러한 요소들이 유기적으로 연결되어 조직 전체의 디자인과 개발 프로세스를 지원한다.

And You Thought Buttons Were Easy? 라는 글에서는 디자인 시스템의 필요성을 버튼 컴포넌트를 예시로 설명한다. 아래는 그에 대한 내용 요약이다.

아래와 같은 버튼 하나를 만드는데 필요한 것들은 무엇이 있을까?

아래와 같은 것들이 있다:

1. 텍스트 색상
2. 텍스트 대소문자
3. 텍스트 두께
4. 텍스트 크기
5. 마진
6. 패딩
7. 모서리 둥글기

이것 뿐일까? 다양한 상태도 가져야 한다.

Hover, Active, Disabled 같은 상호작용 상태나

시각적 상태를 나타내는 Primary, Secondary 등이 있다

이외에도 IconButton, SplitButton, GroupButton, MenuButton 등 다양한 타입의 버튼이 필요할 것이다:

간단해 보이는 버튼 하나도 이렇게 많은 명세가 필요하다. 글에서는 디자이너, 엔지니어, QA가 포함된 팀이 이러한 버튼을 구현한다면 2만 달러가 들어가고, 이 버튼을 각각 50개의 팀에서 따로 만든다면 100만 달러의 비용이 들게 된다고 말한다.

개발자 관점에서의 디자인 시스템: 불편함과 그 이유

내 경험에 디자인 시스템은 양날의 검 같았다. 한편으로는 명확한 가이드라인과 재사용 가능한 컴포넌트를 제공하여 개발 효율성을 높이지만, 다른 한편으로는 디자이너와의 협업 과정에서 여러 불편함을 경험하게 되었다.

스웨덴 욘코핑 대학교(Jönköping University)의 엔지니어링 스쿨 소속 Antonia Ziegler와 Yordan Atanasov가 수행한 연구에서 디자인 시스템을 구축할 때 개발자와 디자이너 간의 커뮤니케이션 단절이 발생하는 주요 요인을 다음과 같이 설명한다:

디자이너와 개발자 사이의 커뮤니케이션 붕괴 주요 원인은 서로의 업무에 대한 이해 부족이다. 특히 디자이너가 코드 지식이 없을 때 소통이 어려워진다. 그러나 책임은 한쪽(디자이너나 개발자)에만 있지 않으며, 양측 모두 소통에 기여해야 한다.

공부한 내용과 그간의 경험을 돌이켜보면 실패의 주된 원인이 디자인 시스템 컴포넌트의 명세(specification)를 함께 설계하지 않은것 이었다고 생각한다. 컴포넌트 기능에 대한 명확한 명세가 없으니 구현할 때 의도했던 기능과 다르게 디자인에서 사용되는 경우가 생기고, 그런 경우 설계부터 다시 시작하거나 코드에 이에 대응하기 위한 파라미터나 분기처리가 생기며 코드가 지저분 해지곤 했다.

또 다른 문제는 개발자와 디자이너의 사고방식 차이다. 개발자는 주로 시스템적이고 논리적인 측면에서 접근하는 반면, 디자이너는 시각적 일관성과 사용자 경험에 중점을 둔다. 이러한 차이는 때때로 같은 컴포넌트에 대해 전혀 다른 해석을 낳기도 한다.

피그마와 코드: 도구적 차이와 100% 싱크율의 어려움

디자인 시스템을 구현할 때 가장 큰 도전 중 하나는 디자인 도구(피그마)와 코드 사이의 간극을 메우는 것이다. 많은 글에서 100%의 동기율(싱크율)이 이상적이라고 이야기하지만, 현실에서는 이를 달성하기 어렵다. 그 이유는 무엇일까?

첫째, 피그마와 코드는 추상화 수준이 다르다. 피그마는 시각적 디자인에 최적화된 도구로, 코드처럼 로우 레벨의 도구가 아니다. 피그마는 추상화된 도구이기 때문에 코드와 100% 동일한 인터페이스를 가질 수 없다.

둘째, 두 도구는 목적과 사용자가 다르다. 피그마는 디자이너를 위한 도구로, 시각적 일관성과 사용자 경험에 초점을 맞춘다. 반면 코드는 개발자를 위한 도구로, 재사용성, 유지보수성, 성능 등을 고려한다.

셋째, 구현 현실의 차이가 있다. 피그마에서는 완벽하게 표현할 수 없는 기술적 제약이 있으며, 특히 상호작용 요소는 실제 동작 방식을 피그마에서 완벽히 구현하기 어렵다.

미디엄 글 The Sorry State of States에서는 이러한 차이가 특히 UI 컴포넌트의 '상태(state)' 처리에서 두드러진다고 지적한다. 디자인 도구와 코드에서 상태를 다루는 방식에 근본적인 차이가 있으며, 이는 완벽한 동기화를 어렵게 만든다.

디자이너의 관점에서 버튼의 state에 대해 생각해보자. 아마 다음과 같은 값들이 존재할 수 있을것 같다.

• active
• hover
• disabled
• readonly

코드에서는 어떨까? 아래와 같은 형태가 될거 같다:

<Button 
  appearance="primary"
  disabled={false}
  readonly={false}
  // hover와 active는 CSS로 처리되며 직접적인 prop으로 제어되지 않음
>
  버튼 텍스트
</Button>

disabled, readonly는 개발자가 코드를 통해 직접 설정하는 상태이며 hover, active는 사용자 인터랙션으로 발생하는 상태다. 그렇기에 hover나 active는 내부적으로 CSS를 통해 처리하고 disabled나 readonly는 true, false를 통해 값을 입력받는 인터페이스로 설계하게 된다.

FluentUI 사례 연구: 피그마와 코드의 차이

Microsoft의 FluentUI를 조사한 결과, 버튼 컴포넌트에서 피그마와 코드 구현 사이의 명확한 차이점을 발견할 수 있었다.

피그마에서의 버튼

• style: Primary, Secondary, Outline, Subtle, Transparent
• state: Rest, Hover, Pressed, Selected, Disabled
• focus: true, false (Rest 상태에서만 동작)
• Icon: true, false (무조건 왼쪽에 등장)
• Menu button: true, false
• Label: 버튼의 텍스트

코드에서의 버튼

• appearance: Primary, Secondary(Default), Outline, Subtle, Transparent
• disabled: boolean
• disabledFocusable: boolean
• iconPosition: before, after
• shape: circular, rounded, square
• size: small, medium, large

가장 눈에 띄는 차이점은 상태 관리 방식이다. 피그마에서는 state라는 단일 속성으로 여러 상태(Rest, Hover, Pressed, Selected, Disabled)를 관리하는 반면, 코드에서는 disabled와 같은 개별 불리언 속성으로 상태를 관리한다. 또한 Hover와 Pressed(Active) 상태는 코드에서 직접적인 prop으로 제어되지 않고 CSS를 통해 처리된다. 뿐만 아니라 아이콘 관련 인터페이스도 확연하게 다른것을 확인할 수 있다.

이러한 차이가 발생하는 이유는 무엇일까?

디자이너 관점에서는 시각적 상태를 모두 볼 수 있는 방식이 효율적이다. 피그마에서 단일 state 속성으로 다양한 상태를 전환하면 디자이너가 모든 상태의 시각적 모습을 쉽게 비교하고 일관성을 유지할 수 있다.

개발자 관점에서는 논리적 속성으로 상태를 제어하는 것이 더 적합하다. React에서 disabled={true}와 같은 방식으로 상태를 제어하는 것이 더 직관적이고 HTML 표준에 맞기 때문이다.

도구적 관점에서는 각 도구의 특성과 제약이 반영된 결과다. 피그마는 정적 디자인 도구로, 모든 상태를 시각적으로 표현해야 한다. 반면 코드는 동적이며, 사용자 상호작용에 반응하는 방식으로 상태를 관리한다.

디자인 스펙: 디자인과 코드 사이의 오작교

앞서 본 피그마와 코드 간의 차이는 개발자가 디자인 시스템을 구현할 때 큰 어려움을 야기한다. 이 간극을 메우는 핵심 요소가 바로 디자인 스펙이다.

디자인 스펙은 디자인 의도를 코드로 정확하게 구현하기 위한 상세한 지침이다. 단순히 피그마 파일을 공유하는 것을 넘어, 각 컴포넌트의 모든 상태, 인터랙션, 반응형 동작, 접근성 요구사항 등을 명확하게 문서화해야 한다.

디자인 시스템에서 스펙이 중요한 이유는 다음과 같다:

1. 해석의 모호함 제거: 시각적 디자인만으로는 모든 동작과 상태를 이해하기 어렵다.
2. 효율적인 구현: 명확한 스펙은 개발자가 추가 질문 없이 작업할 수 있게 한다.
3. 일관성 유지: 스펙을 통해 모든 구현이 일관된 방식으로 이루어진다.
4. 향후 참조: 나중에 변경이나 확장이 필요할 때 명확한 기준이 된다.

내 경험에서, 디자인 스펙이 부족했을 때 가장 많은 시간이 소요됐다. 단순한 버튼 하나를 구현하는 데도 여러 번의 소통이 필요했고, 이는 프로젝트 전체의 진행을 지연시켰다.

Fluent UI의 버튼 컴포넌트 명세를 살펴보자. 이 명세는 디자이너와 개발자 사이의 간극을 메꾸기 위한 명세다. 이런 상태값이 필요하며, 이런 인터페이스가 필요하다 와 같이 너무 구체적으로 제공하지 않는다.

문서를 확인해보면 다음과 같은 내용을 확인할 수 있다.

1. 어떤 종류의 버튼이 있는지:

2. 어떻게 동작해야 하는지:

3. 어떻게 사용되어야 하는지:

효과적인 디자인 스펙 정의 워크플로우

그렇다면 효과적인 디자인 스펙을 어떻게 정의할 수 있을까? Crafting Component API, Together에서는 디자이너와 개발자가 함께 컴포넌트 API를 정의하는 프로세스를 제안한다:

1. 계획 단계: 컴포넌트의 목적과 필요성을 논의하고, 기존 라이브러리나 패턴이 있는지 확인한다.
2. API 정의 단계: 디자이너와 개발자가 함께 컴포넌트의 구조(Anatomy), 속성(Properties), 레이아웃(Layout)을 정의한다.
3. 디자인 단계: 정의된 API를 바탕으로 디자이너가 시각적 디자인을 진행한다.
4. 개발 단계: 개발자가 정의된 API와 디자인에 따라 컴포넌트를 구현한다.
5. 문서화 단계: 컴포넌트의 사용법, 속성, 예시 등을 문서화한다.

이 프로세스는 팀의 규모나 상황에 따라 달라질 수 있다:

소규모	대규모

이 프로세스의 핵심은 디자이너와 개발자가 초기 단계부터 함께 참여하여 서로의 제약사항과 요구사항을 이해하는 것이다. 또한 템플릿을 활용하여 모든 컴포넌트가 일관된 방식으로 명세화되도록 한다.

예를들어 아래와 같이 구조(Anatomy)를 정의할 수 있다:

코드 마크업
-----------

<Card metadata="" title="">
  <CardMedia> (extends <Image>)
  <CardDescription>    
    (slot)
  </CardDescription>
  <CardActionsArea>
     (slot to add Button, IconButton, or TextLink)       
  </CardActionsArea>
</Card>

FIGMA 레이어
------------

Card
  ]-[ .Card (as Base Figma component)
    CardImage (extends Image as subcomponent)
    [-] CardContent
      ]-[ TitleArea
        Subtitle
        Title
      Body
      ]-[ Actions
        Button
        Button

그리고 아래처럼 속성(Properties)을 정의할 수 있다:

Figma only:
- State  
  - default  
  - hover? (recommend: include)  
  - focus? (recommend: include)  
  - error  
  - errorHover? (recommend: omit)  
  - disabled  
  - readOnly

Both Figma & code:- required (false - default, true)  
- inlineLabel (false - default, true)  
- helperTextPlacement (right, bottom - default)

Code only:
- ariaLabel  
- disabled (in Figma, use States)  
- error (in Figma, use States)  
- errorEvent  
- errorText (in Figma, update text shown when in State=Error)  
- helperText (in Figma, show/hide and update text)  
- id  
- label (use .Label element)  
- readOnly (false - default, true) (in Figma, use States)  
- width

마지막으로 레이아웃(Layout)을 정의할 수 있다:

Width  
- Desktop: 1440px  
- Desktop/Tablet: 1024px  
- Tablet: 768px  
- Mobile: 368px

글에서는 이러한 템플릿이 컴포넌트마다 상당히 다르고, 템플릿을 확립하는 것이 어려웠다고 한다. 하지만 이렇게 논의하고 메모하는게 유용하다고 느꼈다고 한다.

개발자와 디자이너 간 효과적인 소통 방법

디자인 스펙이 중요하긴 하다. 다만 그보다 더 근본적으로 중용한것은 지속적인 소통을 통해 서로의 간극일 좁혀나가는게 중요하다는 것이다. 그렇다면 어떻게 "잘" 소통할 수 있을까?

개발자가 디자이너와 소통하는 방법

개발자로서 디자이너와 더 효과적으로 소통하기 위한 방법은 다음과 같다:

1. 디자인 용어 이해하기: 타이포그래피, 색상 시스템, 간격(spacing) 등 기본적인 디자인 용어를 이해하라.
2. 기술적 제약 명확히 설명하기: 구현이 어려운 부분이 있다면, "불가능하다"고 말하기보다 구체적인 제약사항과 대안을 제시하라.
3. 질문의 맥락 제공하기: 단순히 "이게 무슨 의미인가요?"라고 묻기보다 "이 컴포넌트의 hover 상태가 disabled 상태일 때도 적용되나요?"와 같이 구체적으로 질문하라.
4. 피드백은 문제 중심으로: "이 디자인은 좋지 않아요"가 아니라 "이 디자인은 모바일에서 공간이 부족할 수 있습니다"와 같이 구체적인 문제를 지적하라.
5. 디자인 도구 기본 이해하기: 피그마의 기본적인 사용법을 알면 디자이너의 작업을 더 잘 이해할 수 있다.

디자이너가 개발자와 소통하는 방법

디자이너가 개발자와 더 효과적으로 소통하기 위한 방법도 있다:

1. 코드의 기본 개념 이해하기: HTML, CSS의 기본 개념과 컴포넌트 기반 개발 방식을 이해하면 더 실현 가능한 디자인을 할 수 있다.
2. 명확한 스펙 제공하기: 모든 상태와 변형에 대한 명확한 시각적 표현과 설명을 제공하라.
3. 개발자 피드백 초기 수용하기: 디자인 초기 단계에서 개발자의 피드백을 받아 기술적으로 구현 가능한 방향으로 조정하라.
4. 일관된 네이밍 사용하기: 컴포넌트와 속성 이름을 일관되게 사용하여 혼란을 줄이라.
5. 디자인 결정의 이유 공유하기: 특정 디자인 결정의 배경과 의도를 공유하면 개발자가 더 정확하게 구현할 수 있다.

결론: 현실적인 디자인 시스템 구축을 위한 균형점

디자인 시스템에서 피그마와 코드 간 100% 동기율은 이상적이지만, 도구의 본질적 차이로 인해 현실적으로 달성하기 어렵다. 이러한 간극을 메우기 위해 우리는 어떤 균형점을 찾아야 할까?

핵심은 완벽한 일치보다 효과적인 소통에 있다. 디자이너와 개발자가 서로의 도구와 워크플로우를 이해하고, 명확한 디자인 스펙을 통해 의도를 전달하는 것이 더 중요하다.

또한, 디자인 시스템은 완성품이 아닌 지속적으로 발전하는 생태계임을 인식해야 한다. 모든 세부사항을 처음부터 완벽하게 정의하려 하기보다, 핵심 요소부터 시작하여 점진적으로 발전시켜 나가는 접근 방식이 더 효과적이다.

결론적으로, 성공적인 디자인 시스템 구축을 위해 가장 중요한 것은 다음과 같다:

1. 상호 이해와 존중: 디자이너와 개발자가 서로의 영역과 제약사항을 이해하고 존중해야 한다.
2. 명확한 커뮤니케이션: 디자인 스펙을 통해 의도를 명확히 전달해야 한다.
3. 공동 책임: 디자인 시스템은 디자이너나 개발자 어느 한쪽의 책임이 아닌 공동의 책임이다.
4. 지속적인 발전: 디자인 시스템은 완성품이 아닌 지속적으로 발전하는 생태계로 접근해야 한다.

디자인 시스템을 통해 우리는 단순히 일관된 UI를 넘어, 더 효율적인 협업과 더 나은 사용자 경험을 만들어갈 수 있다. 이것이 개발자로서 내가 디자인 시스템에 진정한 가치를 느끼게 된 이유다.

참고자료

• https://medium.com/eightshapes-llc/and-you-thought-buttons-were-easy-26eb5b5c1871
• https://medium.com/airbnb-design/building-a-visual-language-behind-the-scenes-of-our-airbnb-design-system-224748775e4e
• https://medium.com/eightshapes-llc/crafting-ui-component-api-together-81946d140371
• https://en.wikipedia.org/wiki/Design_system
• https://www.diva-portal.org/smash/get/diva2%3A1577674/FULLTEXT01.pdf?utm_source=chatgpt.com
• https://medium.com/eightshapes-llc/design-systems-support-6722b6d9a259
• https://medium.com/@nathanacurtis/the-sorry-state-of-states-89dd4668737e
• https://www.figma.com/blog/design-systems-101-what-is-a-design-system/