Atomic Design이 우리 팀에서 실패한 이유

LXDS v 1.1 구축기

 

---

 

◾️ 디자인 시스템을 다시 정리했습니다

 

정확히 말하면 정리라기보다는 재설계에 가까웠습니다.

 

입사 후 첫 프로젝트로 세무 운영 관리 SaaS 서비스를 위한 디자인 시스템을 구축하게 되었습니다.

이번 작업의 목표는 단순했습니다.

 

실제로 사용하는 디자인 시스템을 만드는 것 

 

생각보다 많은 디자인 시스템이 정리는 잘 되어 있지만 실무에서 사용율이 높지 않습니다.

LXDS 역시 이를 포함한 많은 문제를 가지고 있었습니다.

 

그래서 이번 v1.1에서는

• 구조 재정비
• Color System 정리
• Design Token 설계
• UI 밀도 개선
• 가이드 강화

까지 포함한 전반적인 리빌드 작업을 진행했습니다.

 

 

---

◾️ 우리가 가지고 있던 문제

 

기존 디자인 시스템은 Atomic Design 구조를 기반으로 만들어져 있었습니다.

 

Atomic Design 자체는 매우 좋은 개념입니다.

하지만 실제 서비스 운영 환경에서는 몇 가지 문제가 발생했습니다.

대표적인 문제는 다음과 같았습니다.

 

AS - IS

1. 실무에 맞지 않는 Atomic 기준 카테고리
2. 가시성이 떨어지는 Color System
3. 과도한 여백으로 낭비되는 UI 영역
4. Component와 Module의 혼재된 관리
5. 개발 환경과 맞지 않는 Sync 구조

 

결과적으로 디자이너들은 디자인 시스템을 사용하는 대신 기존 화면을 복사해서 작업하는 방식을 사용하기 시작했습니다.

디자인 시스템이 있지만 실제로는 사용되지 않는 시스템이 된 것입니다.

 

 

 

---

 

◾️ 왜 Atomic Design이 실무에서 어려웠을까

 

Atomic Design은 UI를 구조적으로 분석하는 방법론입니다.

 

 

이 구조는 컴포넌트가 어떻게 조합되어 화면을 이루는지 설명하기에는 매우 명확한 개념입니다.

하지만 문제는 이 개념을 그대로 디자인 시스템의 카테고리 구조로 사용했을 때 발생합니다.

 

 

 

디자인 시스템의 목적은 이렇습니다.

디자이너가 필요한 UI 요소를 빠르게 찾고 올바르게 사용 할 수 있도록 하는 것.

 

 

 

하지만 Atomic 구조를 그대로 적용하면 다음과 같은 상황이 생깁니다.

예를 들어 디자이너는 보통 UI를 이렇게 인식합니다.

 

즉 UI 단위 기준입니다.

 

하지만 Atomic Design 기준에서는 이 요소들이 Molecule인지 Organism인지 판단하기 애매한 경우가 많습니다.

예를 들어 Table을 생각해 보면 아래와 같은 여러 요소로 구성되어 있습니다.

 

때문에 어떤 기준에서는 Organism이 될 수도 있고, 어떤 기준에서는 Molecule로 분류될 수도 있습니다.

결국 디자이너마다 다른 기준으로 판단하게 됩니다.

 

이처럼 Atomic Design은 구조를 설명하는 개념이기 때문에 이를 그대로 디자인 시스템의 탐색 구조로 사용하면

디자인 시스템 구조 vs 실제 UI 설계 방식사이에 간극이 생기게 됩니다.

 

결국 디자이너는 Atomic 기준이 아니라 UI 기준으로 컴포넌트를 찾게 됩니다.

 

 

그래서 LXDS v1.1에서는 이런 방향을 선택했습니다.

Atomic 개념 을 기반으로 한 UI 단위 의 디자인 시스템 구조로 설계

 

 

---

◾️ LXDS 구조 재정의

LXDS v1.1의 구조는 다음과 같습니다.

01_Brand
- Logo
- Legal

02_Foundation
- Color
- Typography
- Layout
- Shape
- Elevation
- Icon

03_Component
- Navigation
- Button
- Field
- Select
- Dropdown
- Modal
- Indicator
- Feedback

04_Module
- Table
- Card

05_Mobile

 

 

핵심은 단순합니다.

UI 단위 기준 으로 구조를 정리하는 것.

 

Component는 작은 UI 단위입니다.

반면 Module은 화면을 구성하는 큰 UI 블록입니다.

 

이렇게 분리함으로써

• 컴포넌트 재사용 구조 명확화
• UI 구조 이해도 개선
• 디자인 시스템 탐색 속도 개선

이라는 효과를 만들 수 있었습니다.

 

 

다만 LXDS에서는 Atomic Design 개념을 완전히 배제한 것은 아닙니다.

 

디자인 시스템의 분류 기준은 UI 단위로 정리했지만,
컴포넌트 내부 구조를 설계할 때는 Atomic Design의 구조 개념을 참고하고 있습니다.

 

특히 여러 요소가 결합되는 컴포넌트의 경우, Atomic 구조를 통해 구성 요소의 관계를 명확하게 정의할 수 있기 때문입니다.

 

예를 들어 Dropdown 컴포넌트를 보면 다음과 같은 구조를 가지고 있습니다.

 

즉, Dropdown은 단일 요소가 아니라 입력 영역(Field), 리스트 항목(List Item)과 같은 작은 요소들이 결합되어 만들어지는 구조입니다.

 

이러한 내부 구조는 Atomic Design 관점에서 정리해두고,

디자인 시스템에서는 Dropdown이라는 하나의 UI 컴포넌트로 제공하는 방식입니다.

 

결과적으로 LXDS는 다음과 같은 기준으로 시스템을 설계했습니다.

 

이 방식은

디자인 시스템은 직관적 으로 만들면서
컴포넌트 구조 설계는 체계적 으로 유지할 수 있다는 장점이 있습니다.

 

 

 

---

◾️ Design Token 구조 설계

이번 LXDS v1.1에서 가장 큰 변화 중 하나는 Design Token 구조 정비입니다.

기존 디자인 시스템에서도 Figma Variables를 사용하고 있었습니다.
하지만 변수들이 체계적인 토큰 구조로 관리되고 있지는 않았습니다.

예를 들어 spacing 변수의 경우 다음과 같은 방식으로 정의되어 있었습니다.

gap-1 = 2px
gap-2 = 4px
gap-3 = 8px

 

이 방식은 변수 자체는 존재하지만
실제 값이 무엇인지 직관적으로 파악하기 어렵다는 문제가 있습니다.

 

디자인 작업 중에는

• 해당 spacing이 실제로 몇 px인지?
• 기존 화면에서 어떤 값이 사용되고 있는지?

를 빠르게 판단해야 하는 경우가 많습니다.

 

하지만 변수명이 단순한 순번 기반으로 구성되어 있으면

gap-3 = ?
gap-4 = ?
gap-5 = ?

 

이 값들이 몇 px인지 매번 확인해야 하는 상황이 발생하고,

"이 값이 몇 px였지?" 

 

를 확인하기 위해 Variables 패널을 계속 확인하게 됩니다.

 

 

그래서 LXDS v1.1에서는 실무에서 값을 직관적으로 이해할 수 있도록 토큰 명명 규칙을 재정비했습니다.

예를 들어 spacing token은 다음과 같이 변경되었습니다.

gap-4 = 4px
gap-8 = 8px
gap-12 = 12px
gap-16 = 16px

 

이 방식은

• 변수 이름만 보고도 실제 값을 바로 이해할 수 있고
• 개발과의 커뮤니케이션에서도 혼동이 줄어들며
• 디자인 리뷰 시 spacing 규칙을 빠르게 판단할 수 있다는 장점이 있습니다.

즉 이번 토큰 정비는

Variables를 사용하는 것에서 끝나는 것이 아니라
실제 실무에서 사용 가능한 Token 구조 로 재설계하는 작업이었습니다.

 

 

 

---

 

▫️ Token Architecture Diagram

 

   1     Primitive Token

Primitive Token은 가장 기본적인 값을 정의합니다.

이 단계에서는 의미를 부여하지 않고 순수한 값만 정의합니다.

 

Primitive 단계의 목적은 단순합니다.

모든 디자인 값의 출발점을 하나 로 만드는 것.

 

 

   2     Semantic Token

Semantic Token은 Primitive 기반으로 UI 의미를 정의합니다.

이 구조 덕분에 단순한 컬러가 아니라 UI 역할 기준으로 관리할 수 있습니다.

 

이렇게 Semantic Token을 사용하면 컬러 값이 아니라 UI의 역할 기준으로 색상을 관리할 수 있습니다.

예를 들어 아래와 같은 방식입니다.

gray/700 → text/title

 

이 구조 덕분에 컬러 팔레트가 변경되더라도

Semantic Token만 수정하면 전체 UI가 함께 업데이트됩니다.

 

 

   3     Responsive Token

LXDS는 SaaS 제품이며 내부사정 상 디바이스 대응보다 UI 규칙 정리가 더 중요했습니다.

그래서 추후 mobile / desktop 같은 디바이스 토큰으로도 확장 가능이 필요한 요소를 기준으로 1차적인 설계를 했습니다.

 

Typography

display
heading
title
body
caption

 

Layout

page
side-panel
dialog

 

 

   4     Theme Token

Text Button / Tag / Progress bar 등의 컴포넌트는 여러 컬러 팔레트를 사용합니다.

컴포넌트 내부에서 컬러를 직접 관리하면 구조가 무거워지기 마련입니다.

그래서 Theme Token을 통해 구조를 단순화했습니다.

설정한 토큰값을 기준으로 color mode를 손쉽게 변경할 수 있습니다.

 

 

---

◾️ 구체적으로 무엇을 개선했는가

 

   1     Color System 개선

기존 시스템에서는 몇 가지 문제가 있었습니다.

• 텍스트 컬러 사용 기준 부재
• 유사한 UI 요소에서 서로 다른 컬러 사용
• 컬러 팔레트의 명도·채도 간격 불균형

특히 텍스트 컬러의 경우 같은 역할의 텍스트에서도 서로 다른 컬러가 사용되는 상황이 발생했습니다.

그래서 LXDS v1.1에서는 컬러 값을 늘리는 대신 사용 규칙을 정리하는 방향으로 시스템을 정비했습니다.

 

먼저 유사한 UI 요소에서 동일한 컬러가 사용될 수 있도록 텍스트 유형 기준의 Color Token을 정의했습니다.
(상단 semantic token 예시 사진 참고)

 

또한 기존 컬러 팔레트는 Gray를 포함한 전체 컬러의 명도·채도 간격이 일정하지 않은 문제가 있었기 때문에
각 컬러 단계의 값을 다시 조정하여 일관된 스케일로 재정비했습니다.

 

결과적으로 이번 작업의 핵심은

컬러 사용 규칙을 명확하게  만드는 것

이었습니다.

 

 

   2     Layout / Spacing 개선

기존 UI는 전반적으로 여백이 넓은 편이었습니다.

하지만 Saas 제품에서는 여백이 많다고 항상 좋은 것은 아닙니다.

데이터 중심 화면에서는

정보 밀도 가 가장 중요하기 때문입니다.

 

 

그래서 다음 요소들을 중심으로 여백 구조를 다시 정리했습니다.

• 상하좌우 패딩
• 컴포넌트 간 Gap
• Table 영역

결과적으로 데이터 가독성이 더 좋아진 UI로 개선되었습니다.

 

 

   2     Guide 강화

이번 LXDS 작업에서 의외로 많은 시간을 사용한 부분이 있습니다.

바로 가이드 문서입니다.

 

디자인 시스템은 UI Kit처럼 단순히 컴포넌트를 만드는 것이 아니라

사용 규칙 을 만드는 작업

 

이라고 생각했습니다.

 

그래서 다음 가이드들을 시스템 내에 함께 정리했습니다.

이 가이드는 디자인 시스템의 사용성을 높이는 핵심 요소였습니다.

Token 별 사용 Guide

Module성 UI 설계 Guide

 

 

---

◾️ LXDS는 아직 진행 중입니다.

디자인 시스템은 정리가 아니라 운영이다

 

이번 작업을 하면서 한 가지 생각이 계속 들었습니다.

 

디자인 시스템은

정리하는 작업이 아니라 운영하는 시스템

이라는 점입니다.

 

디자인 시스템이 실제로 사용되려면

• 찾기 쉬워야 하고
• 실무 구조와 맞아야 하며
• 개발과 연결될 수 있어야 합니다.

그래야 정말로 사용되는 디자인 시스템이 됩니다.

 

LXDS 역시 앞으로 계속 개선될 예정입니다.

언젠가는 이 시스템이 제품 전체를 지탱하는 Design OS 가 되는 것이 목표입니다.