아토믹 디자인으로 디자인시스템 만들기

스위치원의 디자인시스템 만들기 노하우

지난주에 작성한 “디자인시스템으로 업무 생산성을 향상시키자”에서는 제가 디자인시스템을 도입한 이유와 그 효과에 대해 이야기했습니다. 이번 글에서는 디자인시스템의 핵심이 되는 피그마(Figma)를 활용한 디자인시스템 파일 구성과 실제로 이를 어떻게 구현했는지에 대해 다뤄보겠습니다.

‍

아토믹 디자인(Atomic Design)이란 무엇일까?

화학에서 원자(Atoms)는 더 이상 나눌 수 없는 기본 단위이며, 원자들이 결합해 분자(Molecules)를 이루고, 더 나아가 복잡한 유기체(Organisms)를 형성합니다. 이 원리를 UI 디자인 시스템에 적용한 개념이 바로 **아토믹 디자인(Atomic Design)**입니다.

UI도 작은 단위(Atoms)에서 시작해 단계적으로 결합해 큰 구조로 발전할 수 있다는 아이디어를 기반으로 합니다. 이 접근법은 디자인의 재사용성과 일관성을 극대화하며, UI 컴포넌트 간의 관계와 결합이 가져오는 맥락(Context)을 명확히 이해하는 데 도움을 줍니다.

‍

아토믹 디자인의 다섯 단계

아토믹 디자인은 다음의 5단계로 구성됩니다.

1. Atoms (원자): 가장 기본적인 UI 요소. 예: 버튼, 입력 필드 등
2. Molecules (분자): Atoms가 결합해 만들어진 단순한 컴포넌트. 예: 검색창
3. Organisms (유기체): Molecules가 결합해 구성된 복잡한 UI 구조. 예: 네비게이션 바
4. Templates (템플릿): Organisms가 배치된 페이지 레이아웃
5. Pages (페이지): Templates에 실제 콘텐츠가 들어간 최종 화면

이들은 순차적으로 진행되는 단계가 아니라, 동시에 상호작용하며 발전하는 과정입니다.

‍

아토믹 디자인이 왜 필요했는가?

제가 아토믹 디자인을 처음 적용했던 회사는 **Awair(어웨어)**였습니다. 당시 Awair는 3개의 서비스와 하나의 웹사이트를 운영하고 있었습니다.

• Awair Home: B2C 사용자들을 위한 모바일앱
• Awair Business: B2B 사용자들을 위한 모바일앱
• Awair Dashboard: B2B 사용자들을 위한 웹앱
• Awair 홈페이지: 영어 및 한국어 버전

이 모든 플랫폼을 하나의 회사에서 제공하는 서비스라는 점을 일관되게 인식시키는 동시에, 디자인의 효율성을 높이는 것이 목표였습니다. 제가 합류하기 전에도 컴포넌트 기반으로 디자인이 이루어지고 있었지만, 플랫폼마다 사용하는 색상, 폰트, 컴포넌트 형태가 달라 일관성이 부족한 상태였습니다. 이에 저는 Awair Home을 제외한 나머지 세 가지 플랫폼의 디자인시스템을 하나로 통합했습니다.

스위치원에서도 상황은 비슷했습니다. 스위치원 역시 여러 플랫폼을 운영하고 있었기 때문입니다.

• 스위치원 모바일 앱: B2C 사용자들을 위한 환전 앱
• 스위치원 홈페이지
• 스위치플로우: B2B 사용자들을 위한 웹앱
• 스위치플로우 웹사이트

스위치원의 디자인시스템을 구축하며, 모든 플랫폼을 하나의 디자인시스템으로 통합하는 것을 목표로 삼았습니다. 완벽한 통합에는 시간이 더 필요하지만, 현재는 스위치원 홈페이지를 제외한 나머지 플랫폼에서 유의미한 통합을 이루어냈습니다.

‍

아토믹 디자인을 어떻게 활용했는가?

아토믹 디자인은 Atoms, Molecules, Organisms, Templates, Pages 순서의 구성을 따릅니다. 그리고 각각의 컴포넌트들이 어디에 소속되는지가 중요하죠. 어웨어에서 디자인시스템을 만들 때 가장 어려웠던 부분은 Atoms, Molecules, Organisms를 구분하는 일이었습니다. 여러 서비스에 동일하게 적용되는 컴포넌트들인 만큼 다음과 같이 구분하는 것으로 결정했습니다.

• Atoms: 서비스와 관계 없이 공통적으로 사용되는 컴포넌트입니다. 버튼, 텍스트필드 등이 해당합니다.
• Molecules: 특정 서비스에서만 사용하는 컴포넌트입니다. 가령, 모달, 내비게이션 등은 서비스마다 사용하는 형태가 조금 다릅니다.
• Organism: 특정 서비스에서만 사용하는 컴포넌트들이지만, 기능이 매우 구체적으로 정해진 요소입니다.

예를 들어,

• 텍스트 필드나 드롭다운 필드는 Atoms입니다. 플랫폼과 관계없이 공통적으로 사용되기 때문입니다.
• 검색이 가능한 필드는 Molecule입니다. 특정 플랫폼(예: 웹앱)에서만 사용되기 때문입니다.
• 거래 내역 리스트 아이템은 Organism입니다. 특정 플랫폼에서 사용되며, 기능도 특정되어 있기 때문입니다.

이러한 구조를 통해 Atom이 Molecule을 구성하고, Molecule이 Organism으로 결합되는 형태로 컴포넌트를 체계화했습니다.

‍

마스터 파일 만들기

디자인시스템의 원칙을 정립한 후, 이를 피그마 파일로 체계화하는 작업이 필요했습니다. 저는 크게 두 가지로 파일을 나누어 구성했습니다.

• 디자인시스템 파일: Principle(원칙), Asset(에셋), Atom, Molecule을 보관
• 각 플랫폼 별 디자인 파일: Organism, Template, 디자인된 화면을 보관

피그마에 있어 가장 기본이지만, 생각 외로 모르는 사람이 제법 있습니다. 디자인시스템 파일을 만들고 이를 라이브러리로 퍼블리시(Publish) 하는 것입니다. 마스터 파일을 퍼블리시 하기 위해서 프로페셔널 팀 플랜 이상으로 구독하셔야합니다.

‍

원칙(Principle), 에셋(Asset) 추가하기

사실 Atoms, Molecules, Organisms, Templates, Pages의 구조로는 부족한 것이 몇 가지 있습니다. 원칙과 에셋입니다. 이 두 가지를 Atoms와 분리했던 것은 이 둘은 컴포넌트가 아니었기 때문입니다. 또한, 폰트와 컬러는 서비스마다 사용하는 방법이 다소 다를 수 있습니다. 가령, 마케팅을 목적으로 한 플랫폼의 경우, 눈에 띄는 강렬한 색과 폰트를 쓰는 게 좋겠지만, 사람들이 자주 사용하는 앱의 경우, 눈이 편안하도록 덜 강렬한 것들을 사용하는 것이 좋습니다. 임팩트가 강한 것과 눈이 편안한 것은 대조적인 속성이기 때문입니다. 이처럼 원칙은 플랫폼마다 다르게 적용될 수 있기 때문에 구분하여 적용했습니다.

원칙(Principle)에는 컬러, 타이포, 기타 변수들이 플랫폼에 따라 다르게 설정합니다. 기타 변수에는 Margin, Padding 등에 사용되는 치수, 버튼의 높이, R값(버튼을 둥글게 만드는) 등을 정의했습니다. 리브랜딩 등 앱 전반적인 룩앤필을 변경할 때 손쉽게 적용하기 위함이었습니다. 각 변수는 데스크탑과 모바일을 구분하여 정의하였는데요, 이를 통해 반응형디자인에 필요한 시간을 대폭 줄였습니다.

또한, 에셋은 개발자의 입장에서 업로드만 하면 될 뿐, 따로 구현할 필요가 없기에 한곳에 모아두는 게 좋다고 생각했습니다. 예전에는 구글드라이브와 같은 공용 공간에 업로드했다면, 요즘은 피그마에서도 손쉽게 사용하기 위해 피그마에 모아두는 편입니다.

‍

Atom과 Molecule

Atom과 Molecule은 모두 기본 컴포넌트입니다. 앞서 말씀드렸다시피, Atom은 플랫폼 구분 없이 모든 곳에 사용하는 컴포넌트이며, Molecule은 특정 플랫폼에서만 사용합니다. Molecule은 다른 플랫폼에서 사용하지 않더라도 언제든지 Atom에 포함될 수 있기 때문에 공용공간인 마스터 파일에 보관하게 되었습니다. 처음에 Atom이라고 생각했지만, 다른 플랫폼에서 사용하려고보니, 다르게 디자인할 필요가 있을 경우가 있기도 했고요.

가령, 버모달은 Molecule에서 각각 구현했습니다. 플랫폼마다 사용하는 디자인이 달라졌기 때문입니다. 데스크탑을 지원하는 웹앱에서는 간격과 여백이 비교적 넓었고, 모바일앱에서는 반대로 좁았습니다. 또한, 모바일앱에서는 바텀시트라는 별도의 모달 디자인을 하나 더 만들어, 상황에 따라 컴포넌트를 선택해가며 디자인했습니다.

만약 Atom과 Molecule이 각각 다른 파일에 있게 된다면, 디자인시스템에 있는 컴포넌트를 사용하는 디자인 파일에서는 컴포넌트 연결을 유실할 가능성이 높아집니다. Atom 파일에 있는 컴포넌트가 Molecule로 옮겨진다면(잘라내기 후 붙여넣기) 디자인 파일에서는 삭제된 컴포넌트로 인식할 수 있다는 거죠. 이런 변화가 생길 때마다 모든 디자인의 컴포넌트를 다시 설정하는 일이 없도록 하기 위해 두 종류의 컴포넌트들을 한 곳에 보관하게 되었습니다.

‍

Organism 컴포넌트

디자인하다보면 디자인하는 제품에 따라 유독 자주 사용되는 기능이 있습니다. 이런 요소를 컴포넌트화 시키는 경우가 있는데요, 이것들은 기본 컴포넌트에 해당하지 않습니다. 이런 컴포넌트들은 Organism이라는 그룹으로 실제 UX/UI디자인을 진행하는 파일에 모아두었습니다. 가령, 금융앱의 경우, 거래 내역이나 보유하고 있는 자산 리스트를 자주 보여줍니다. 컨텐츠 서비스의 경우, 컨텐츠 리스트, iOT의 경우 등록된 디바이스 리스트를 자주 보여주는데요, 이런 요소들을 Organism 컴포넌트로 설정하면 좋습니다. 스위치원에서는 “기능이 명확하게 특정되어있는” 컴포넌트들을 Organism으로 정리하고 있습니다.

Organism이라는 위상도 100% 확정적인 것은 아니라서, 실제 개발팀에게 Atom, Molecule, Organism을 구분하여 개발할 것을 요청하고 있지는 않습니다. 하지만 각 요소들은 특징이 다르기 때문에 컴포넌트의 이름을 지을 때 영향을 미치긴 합니다.

‍

어떤 것들을 컴포넌트 시켜야할까?

디자인시스템을 만들고 사용하다보면 생각보다 자주 있는 고민입니다. 대개 디자이너는 자주 사용하는 것들을 컴포넌트화 시켜야한다고 생각하기 때문이죠. 하지만 우리는 미래를 예견할 수 없습니다. 즉 디자이너가 디자인할 때, 컴포넌트를 정말로 자주 사용할지는 모른다는 겁니다. 많이 쓸 것 같아서 컴포넌트를 만들었더니 사용하지 않고, 반대로 안 쓸 줄 알았더니 자주 사용하는 경우가 생기는 경우가 생각보다 빈번하게 발생한다는 뜻입니다.

그렇기 때문에 다른 기준을 정하게 되었습니다. 바로 “상태 값”이나 “특성(Property)” 갖는 요소들을 모두 컴포넌트화 시키는 것입니다. 실제로 반복하여 사용하지 않는다고 하더라도, 상태의 차이를 개발팀에게 쉽게 전달할 수 있기 때문에 그 자체로 이점이 있습니다. 또한, 상태를 갖지 않는 요소들은 반복적으로 사용된다고 하더라도, 구현이 단순하기 때문에 컴포넌트로 만들어지지 않아도 생산성에 큰 영향을 주지 않습니다.

하지만 예외는 있습니다. Template에 해당하는 페이지들이죠. 이 요소들은 내부에 있는 컨텐츠만 바뀌지만, 워낙 빈도가 높기 때문에 컴포넌트화 시키는 것이 좋습니다.

‍

마치며…

개발자(또는 엔지니어) 분들에게 종종 이런 이야기를 듣습니다. “피그마를 제대로 다룰 줄 아는 UX/UI디자이너”가 정말 찾기 힘들다고요. 그런데 사실 그 분들이 원하는 디자이너는 단순히 피그마를 잘 다루는 것이 아니라, 프론트엔드 개발 환경의 특징을 잘 알고 있는 사람들입니다. Property 기능을 알지만, 제대로 활용하지 못하는 분들이 정말 많거든요. 개발자 분들이 이런 역량을 갖춘 디자이너를 원하는 이유는 디자이너가 기획 → 디자인 → 개발 → QA → 배포 과정의 생산성을 높이는 데에 핵심적인 역할을 하기 때문입니다. 즉, 함께 일하는 디자이너 또는 디자인팀이 어떻냐에 따라서 비디자인 조직의 생산성이 눈에 띄게 달라질 수 있다는 것입니다.

제가 이 글에서 소개한 아토믹디자인 방식은 풀타임으로 속해있던 3개의 직장, 외주 또는 파트타임으로 진행했던 10여 개의 회사를  거쳐가며 그때마다 생산성을 개선해왔던 결과물이기도 합니다. 이러한 기본 베이스가 있기 때문에 스위치원에서 디자인시스템을 제공하는 데까지 2주가 채 걸리지 않았죠. 한 회사의 디자인을 책임질 수 있는 디자이너라면, 이러한 체계를 빌딩하는 나름의 노하우를 알고 있어야한다고 생각합니다. 디자인시스템을 준비하는 분들에게 제 노하우가 도움이 되길 바랍니다.

‍