아토믹 디자인 도입기

 

프로젝트에 아토믹 디자인 도입하기

 

치스톡 프로젝트를 재개하면서 가져가려했던 목적 3가지가 있었다.

그 중 하나가 바로 디자인 시스템을 통한 효율적인 프론트엔드 개발이었는데

이의 연장 선상으로 아토믹 디자인을 치스톡에 적용해보려한다.

 

이전에 진행했던 프로젝트에서 야심차게 CDD^[각주:1]를 도입했다가 야심차게(?) 실패했던 적이 있다.

CDD는 작은 컴포넌트부터 만들기 시작해서 이를 조립해 하나의 커다란 페이지를 만드는 상향식 개발 방법론이다.

때문에 먼저 디자인이 나오고, 이를 바탕으로 컴포넌트를 분류한 뒤에 개발해서 짜올리는 방식으로 진행해야하는 것이 쉬운데

당시에는 이를 모르기도 했고 개발자가 디자인과 개발을 병행하다보니 너무 혼란스러워 제대로 진행되지 못했었다.

(그래서 이번에는 디자인부터 차근차근 체계적으로 하려고 했다.)

 

먼저, 아토믹 디자인(Atomic Design)이란?

 

아토믹 디자인은 페이지의 요소들을

Atom(원자) - Molecule(분자) - Organism(유기체) - Template(템플릿) - Page(페이지)

라는 계층으로 나누어 페이지를 구성하는 방법이다.

각 계층의 이름처럼 화학에서 영감을 받아 원자들을 결합하여 하나의 페이지를 만드는 것을 핵심 내용으로 한다.

 

주의해야하는 부분은 아토믹 디자인은 선형적인 프로세스가 아니라는 점이다.

원자를 결합해서 페이지로 완성한다는 점이 하나의 선형적인 과정으로 보일 수도 있지만,

각 단계를 마치고 다음 단계로 나아가는게 아닌 그저 유저 인터페이스에 대한 이해를 돕기 위한 멘탈 모델일 뿐이라고 하는데...

이를 그대로 따르기보다는 이해를 돕기 위한 분류 기준 정도로만 삼으라는 말로 이해했다.

 

아토믹 디자인의 각 단계의 역할은 아래와 같다.

 

- Atom(원자)

인터페이스를 구성하는 가장 기본적인 요소를 말함.

label, input, button과 같은 기본적인 HTML 태그 요소들이나, 기능상으로 더 이상 나누어지지 않는 요소들을 포함함.

'목적'을 가지지 않음.

- Molecule(분자)

하나의 단위로 함께 작동하는 단순한 UI 요소를 말함. (예: label, input, button을 결합해 만든 검색창)

'목적'을 가짐.

- Organism(유기체)

Atom, Molecule, Organism이 결합해 만들어진 비교적 복잡한 UI 요소들을 말함.

인터페이스 내에서 독립적인 섹션(레이아웃)을 형성함.(예: Header, Navigation Bar)

Atom, Molecule, Organism 중 재사용성이 가장 낮음.

- Template

컴포넌트를 배치하고, 디자인의 골격을 표현하는 페이지 수준의 객체

데이터가 바인딩 되지 않은 스켈레톤 UI 요소

- Page

템플릿의 특정 인스턴스로 실제 콘텐츠가 배치된 UI의 모습

데이터 바인딩이 완료되어 유저와 상호작용할 수 있는 UI

 

 

언뜻 보기에 이론상으로 완벽하고 굉장히 깔끔한 체계이다.

 

아토믹 디자인은 개발 방법론이 아니다

 

치스톡의 디자인은 디자인 시스템을 통해 나름 체계화되어있는 상태이다.

그렇게 디자인이 나온 상태이기 때문에 이를 분해해서 각 단계에 맞는 요소들을 뽑아내면 잘 되겠지 생각했다.

그런데 이게 생각보다 쉽지가 않았다.

 

사실 대부분의 글에서는 Molecule와 Organism을 구분하는 것을 어려워한다.

그런데 나는... 아니었다. 치스톡 디자인 특성상 각 타일을 기준으로 섹션이 명확하게 나뉘었기 때문이다.

각 타일을 뽑아내어 이를 Organism으로 정의하면 되는 끝이었다.

 

그렇게 정의된 유기체들...

 

문제는 Atom에서 나왔다.

아토믹 디자인에서의 Atom은 button이나 input과 같은 html 태그 혹은 기능상으로 더 이상 나뉘어지지 않는 단위를 말한다.

그런데 이는 Typography나 Color와 같은 디자인 토큰 요소 역시도 포함한다.

 

이를 바탕으로 처음에는 Typography라는 디자인 토큰을 Text라는 컴포넌트로 만들면 되겠지라고 생각했다.

그런데 컴포넌트를 만들려고 옮기다보니 디자인 토큰을 어떤 식으로 컴포넌트로 만들어야할지도 애매했고,

디자인 토큰과 실제로 사용되는 컴포넌트(태그)가 Atom이라는 동일한 단계에 존재하는게 너무 어색했다.

그래서 실제 개발에 들어가기 앞서 Atom 밑에 Token이라는 단계를 하나 추가했다.

 

 

Token이라는 단계는 컴포넌트 혹은 UI라고 부를 수 없을 정도의 원시적인 시각적인 요소를 의미한다.

기존에 Atom에 button, input과 같은 html 태그와 혼재되어있던 디자인 토큰을 Token이라는 하위 단계로 내린 것이다.

예를 들어, 디자인 토큰인 Typograpy와 Atom인 Text 컴포넌트를 비교해보자.

 

 

위의 Typography를 보면, Typography는 UI 요소가 아닌 디자인 상에서 사용되는 글자의 굵기, 크기, 줄 높이 등을 의미한다.

이를 xs부터 2xl까지의 단계로 정의했다.

다시 한 번 말하지만, 이 자체는 UI가 될 수 없고 글자의 시각적인 요소일 뿐이다.

 

이제 이 디자인 토큰을 활용해 만들어진 컴포넌트인 Text 컴포넌트를 보자.

Text 컴포넌트의 성분을 보면 앞서 보았던 Typography라는 디자인 토큰을 size라는 속성을 통해 적용하는 것을 알 수 있다.

이와 비슷하게 Color라는 디자인 토큰 역시도 Text라는 컴포넌트의 속성으로 들어갔다.

 

즉, 실제 개발에 빗대어보면 Token은 css 속성 1개이고,

Atom은 이 css들과 html 태그를 합쳐 화면 상에 활용할 수 있도록 만든 UI 컴포넌트 단위가 된 것이다.

아토믹 디자인은 개발을 염두해 나온 방법론이 아니고, 디자인 요소를 이해하기 쉽게 만들기 위해 나온 모델이기 때문에

이를 개발에 그대로 적용하면서 발생한 실수라는 결론을 내렸다.

 

마무리

분류된 토큰, 원자, 분자, 유기체

 

위와 같은 사고의 결과............. 디자인 요소들을 뽑아내어 성공적으로 분류할 수 있었다. 👏👏👏

이제 이를 바탕으로 각 컴포넌트를 코드화해서 실제 개발에 사용할 수 있도록 컴포넌트로 만드는 일이 남았다.

 

사실 아토믹 디자인은 위에서도 말했 듯 멘탈 모델이기 때문에 그 자체에 명확한 기준을 제시하고 있지 않다.

때문에 각자가 생각하는 기준이 다르고, 같은 기준을 세웠어도 다르게 분류한 사람, 아에 다른 기준으로 세운 사람도 존재할 것이다.

다만 이 글에서는 나는 이런 생각을 했고, 그래서 이렇게 분류했다라는 정도로 가볍게 읽어주면 좋을 것 같다.

 

 

 

Reference

Atomic Design Methodology | Atomic Design by Brad Frost

아토믹 디자인을 활용한 디자인 시스템 도입기 | 카카오엔터테인먼트 FE 기술블로그

 

1. CDD(Component Driven Development) : 컴포넌트 주도 개발 [본문으로]