atomic design 파헤치기

atomic design을 알게 되고 실제로 적용하려고 하니 애매한 부분이 너무 많았습니다.

 

1. html태그당 atom 한개를 만들어야 하는데 그럼 모든 html 태그에 대해서 atom을 만들어야 하는 것 인가? 

2. atom, molecules, organisms등은 재사용의 가능성을 높이기 위해서 컨텍스트를 배제해야 하는가?

(예를들면, UserList라고 하는 molecule이 아니라 User라는 Context를 제외하여 컴포넌트를 List로 작성하는것.)

3. molecule과 organism의 경계는??

4. 어플리케이션의 상태는 어디부터 들어가야하는가?

 

이러한 궁금증을 해결하기 위해 이 개념을 만든 bradfrost가 직접 쓴 글을 번역했습니다.

아토믹 디자인 창시자 bradfrost의 글 발췌

분자는 두개 이상의 원자로 구성된다. 특징을 갖고 있다. 원자보다 좀 더 명확하다.

유기체는 하나의 세포로 구성될 수도 있고, 인간처럼 아주 복잡한 세포의 덩어리로 구성될 수도 있다.

 

우주에 알려진 모든 물질은 atomic elements(주기율표의 원소들)들의 유한 집합으로 표현할 수 있다.

마찬가지로 우리의 인터페이스도 HTML elements의 유한 집합을 표현 할 수 있다. Josh Duck의 HTML 주기율표

HTML 주기율표

이걸 보면서, 아토믹 디자인은 컴포넌트를 조합해서 페이지를 완성하고 페이지를 조합하여 애플리케이션을 완성해나가는데, 컴포넌트를 조합해서 애플리케이션을 만들어 나가는 리액트의 컨셉과도 아주 잘 맞는 개념인것 같다는 생각이 들었다.

아토믹 디자인은 선형 프로세스가 아니다.

아토믹 디자인은 원자, 분자, 유기체, 템플릿, 페이지 5가지의 계층구조로 구분된다. 이 말이 원자를 만들고 원자를 조합해서 분자를 만들고 분자를 조합해서 유기체를 만들고.. 이런 선형적인 절차를 의미하는건 아니다. 우리가 인터페이스를 전체와 부분을 동시에 보게끔 도와주는 멘탈 모델에 더 가깝다.

원자(atom)

자연계의 원자는 고유한 특성이 있다. (예를들어, 수소는 산소보다 가볍다.)

마찬가지로, HTML 원자들도 고유한 특성을 갖고 있다. (예를들어, h1은 기본적으로 굵은 폰트를 갖고, 폰트 사이즈가 크다.)

분자(molecule)

분자는 2개 이상의 원자가 모여 구성되고 고유한 특성을 갖는다. 예를들어, 물분자(H2O)와 과산화수소 분자(H2O2)는 같은 원자 H와 O로 구성되어 있음에도 불구하고 개수가 달라 매우 다르게 동작한다.

 

인터페이스에서 분자란, 상대적으로 간단한 UI elements 그룹이다.

검색칭 분자는 label, input, button 3개의 원자로 구성되어 있다.

아토믹 디자인의 창시자도 분자를 "상대적으로 간단한" 으로 애매하게 정의내리고 있다.

 

원래 아무 의미 없던 3가지 원자들(labe, input, button)이 서로 모여 분자를 형성하자 독특한 역할을 부여 받게 되었다.

 

button 원자: form의 submit 역할

label 원자: input에 대한 정의

input 원자: 검색 키워드 입력

 

분자가 되는 순간 원자들에게 의미가 부여된다. 이제 이 검색창 분자는 독립적으로 동작하며 쉽게 이동될 수 있다.

이렇게 분자의 형태로 간단한 컴포넌트를 만들면, 각 컴포넌트가 단일 책임 원칙에 맞게 구현 되는것이다. 즉 하나의 컴포넌트는 하나의 일만 잘 하면 된다 라는것이다.

 

분자 컴포넌트는 애플리케이션 전체에 통일성, 일관성을 주며 테스트를 더 쉽게 만든다.

유기체(organism)

유기체는 "상대적으로 복잡한" 컴포넌트이고, 원자, 분자, 유기체의 조합으로 만들어질 수 있다. 유기체를 조합해서도 더 복잡한 유기체를 만들 수 있다는것이다. 유기체는 화면을 구분짓는 하나의 단위가 된다. 아까 위에서 살펴봤던 검색창 분자는 헤더라는 유기체의 컨텍스트 안으로 들어가게 된다.

헤더 유기체는 검색창 분자, 로고 원자, 네비게이션 분자로 구성된다.

헤더라는 유기체를 통해서 화면의 일부를 구분지을 수 있게 되었다.

 

While some organisms might consist of different types of molecules, other organisms might consist of the same molecule repeated over and over again.

 

일부 유기체는 같은 종류의 분자로 구성되지만 일부는 다른 종류의 분자로 구성될 수도 있다.(그럼 유기체를 구성하는 요소가 하나라도 바뀌면 새로운 유기체로 봐야하는것이라는 말인가??)

 

Building up from molecules to more elaborate organisms provides designers and developers with an important sense of context.

 

분자로부터 유기체를 만드는것은 디자이너와 개발자에게 컨텍스트에 대한 감각을 제공한다.

 

템플릿(Template)

원자, 분자, 유기체 까지는 컴포넌트를 구성하기 위해 사용되었던 개념들이다. 이제부터는 실제로 클라이언트, 보스, 개발자가 아닌 동료와 같은 사람들에게 좀 더 이해하기 쉬운 계층이 필요하다. 그래서 나온게 템플릿 계층이다. 아토믹 디자인에 관심이 없는 이런 사람들에게 원자 분자 유기체를 얘기한다면 내가 이상하게 보일것이다.

 

템플릿은 페이지 레벨의 객체이다. 우리가 만들었던 원자, 분자, 유기체 컴포넌트들을 템플릿속 레이아웃에 배치하면 된다.

 

위에서 만들었던 header 유기체를 homepage 템플릿에 배치하면 된다.

homepage 템플릿은 레이아웃이 있고 그 레이아웃 안에 유기체와 분자가 들어있다.

템플릿부터는 추상적인 분자와 유기체에 컨텍스트가 부여되기 시작한다.

컴포넌트들이 레이아웃의 맥락(컨텍스트)에서 어떻게 표시되고 작동하는지를 보여주기 시작하는것이다. 템플릿의 또다른 중요한 특징은 페이지의 최종 모습이 아니라 기본 구조를 보여준다는 점이다.

 

예를들어서, homepage의 로고에는 이미지 사이즈가 120x50으로 들어가야 한다던지 헤더에 들어가는 네비게이션 메뉴는 4개가 들어가야하고 제목은 최대 20글자까지만 보여야한다는 식의 기본구조를 말하는것이다.

 

페이지의 스켈레톤(뼈대)을 정의함으로써 동적인 컨텐츠의 다양한 형태를 고려할 수 있다. 결국 템플릿 이라는건 어떤 동적인 컨텐츠에 대한 가드레일 역할을 하는것이다.

TimeInc. 의 Template

TimeInc.의 hompage template 예시이다. 이미지 사이즈는 어때야하고 폰트의 크기는 어떻고 글자수는 37개 까지만 가능하다. 와 같은 정보가 들어간다. 기본적인 컨텐츠의 구조를 설명하고 있다.

이제 뼈에 살만 붙이면 된다.

페이지(page)

템플릿이 스켈레톤이었다면 그 스켈레톤 위에 동적인 컨텐츠가 입혀진 상태가 페이지이다. 예를들어 위에서 예시로 들었던 TimeInc.의 homepage template으로 부터 4개의 서로 다른 컨텐츠가 들어간 페이지를 찍어낼 수 있는것이다. 그 4개의 페이지들은 서로 구조는 같지만 내용물이 다를것이다.

 

페이지가 만들어져야 실제로 그동안 우리가 만들었던 원자, 분자, 유기체, 템플릿이 제대로 잘 만들어졌는지 조합했을때 이상하진 않은지 확인할 수 있게 된다. 만약에 페이지가 마음에 들지 않는다면 우리는 다시 돌아가서 4개의 계층을 수정하면 된다. (loop back)

 

템플릿으로 부터 만들어진 페이지

우리는 재사용이 가능하며 현실 세계를 잘 반영할 수 있는 디자인 시스템을 만들어야 한다.

 

하나의 템플릿으로 부터 다양한 페이지가 나올 수 있다.

• 어떤 유저는 장바구니에 1개만 담았지만 어떤 사람은 10개를 담았다.
• 기본적으로, 대시보드에 최근 활동이 표시되지만 처음 가입한 유저는 표시되지 않는다.
• 어떤 기사는 타이틀의 길이가 340이지만 어떤 기사는 30이다.
• 관리자 계정으로 로그인하면 관리자만 볼 수 있는 버튼이 생긴다.

위 4개의 모든 예제에서 템플릿은 동일하다. 다만 페이지는 컨텍스트(맥락)에 따라 어떤건 보여주고 어떤건 숨길 수 있다. 한마디로 템플릿에는 디자인 풀케이스가 들어가야한다.

 

요약

• 원자는 더이상 쪼개질 수 없는 독립적인 HTML element다.
• 분자는 두개 이상의 원자가 모여 구성된 상대적으로 간단한 컴포넌트이다.
• 유기체는 UI 인터페이스를 구분짓는 상대적으로 복잡한 컴포넌트이다. (원자, 분자, 유기체의 조합)
• 템플릿에서 원자, 분자, 유기체를 레이아웃 안에 적절히 배치한다. (페이지 스켈레톤)
• 페이지에서는 템플릿으로 부터 만들어낸 실제 페이지가 보여진다. context에 따라 템플릿이 조금씩 변형된다.

 

아토믹 디자인의 장점

아토믹 디자인은 효율적이고 신중한 디자인 시스템을 설계하는데 핵심적인 인사이트를 제공한다.

전체와 부분을 보는 능력

아토믹 디자인이 제공하는 가장 큰 장점은, 추상적인것과 구체적인것을 빠르게 변환할 수 있는 능력이다. 아토믹 디자인을 사용하게 되면 어떤 페이지를 봤을때 이 페이지가 어떤 아토믹 요소로 구성되어 있고, 어떻게 조합되는지를 볼 수 있는 능력이 생긴다.

 

그전에는 페이지에 그냥 이런 이런 요소가 있구나 정도로만 느낄 수 있었다면,

이제는 이런 레이아웃속에 이런 독립적인 컴포넌트들이 존재하는구나! 라고 좀 더 깊게 생각할 수 있게 되었다는것이다.

 

즉 전체와 부분을 동시에 보는 능력이 생겼다.

 

The atoms, molecules, and organisms that comprise our interfaces do not live in a vacuum. And our interfaces’ templates and pages are indeed composed of smaller parts. 

 

원자 분자 유기체는 진공상태에서는 살지 않는다. 템플릿과 페이지는 좀 더 작은 부분들로 구성된다.

-> 원자, 분자, 유기체를 재료의 개념으로 보고 템플릿과 페이지는 그 재료를 조합해서 만든 완성본이라고 생각하면 될 것 같다.

 

디자인의 일부는 전체에 영향을 미치고 전체는 일부에 영향을 미친다. 전체와 부분은 서로 얽혀있고 아토믹 디자인은 이 사실을 받아들였다.

위에서도 얘기했지만, 아토믹 디자인은 선형 프로세스가 아니다. 아토믹 디자인의 5단계 stage를 스텝1은 원자, 스텝2는 분자... 와 같이 생각하지 말아라. 각 stage를 mental model(사고 과정)로 생각해야 한다.

 

-> 우리 프로젝트에 아토믹 디자인을 적용할건데, 우리 원자부터 다 만들고 그 다음에 분자 만들고 이런식으로 단계별로 진행하라는게 아니라 최종적인 디자인이 나왔을때 각 디자인 요소들을 어떻게 구분지을것인지에 대해서 아토믹 디자인의 5단계 개념을 적용하라는 뜻인것같다.

 

구조와 컨텐츠의 구분

아토믹 디자인은 UI의 구조와 그 구조에 들어가는 컨텐츠를 잘 구분지어 생각할 수 있도록 도와준다.

Person List Template과 Person List Page

왼쪽에는 사람들의 목록을 보여주는 템플릿이 스켈레톤 형태로 되어있고, 오른쪽에는 그 템플릿의 실제 인스턴스인 페이지가 있다. 각각에는 Person이라고 하는 분자가 리스트 형태로 나열되어있다. 이 상황에서 만약에 어떤 사람의 이름이 너무 길어서 5줄로 줄바꿈 되어야 한다고 하면 우리는 이제 정확히 어떤걸 바꿔줘야 하는지 구분지을 수 있게 되었다. 

 

Person 분자에 들어있는 Title 원자를 수정해야 한다.

 

아토믹 디자인이 적용되지 않았더라면 위 내용은 페이지 단위에서 수정이 되었을것이다. 해당 페이지 내에 있는 유기체에 어떤 매개변수를 전달하냐에 따라 UI가 상황에 따라 변형된다.

네이밍

모듈화된 디자인과 개발은 새로운것이 아니다. 사람들은 내게 왜 이름을 elements, modules, components와 같이 짓지 않았냐고 질문을 한다. 또 어떤 사람은 나에게 base, components, modules로 이름을 짓는게 어떻겠냐고 제안하기도 했었다.

 

하지만, 이런 네이밍은 계층 구조를 잘 나타내지 못하는 문제가 있다. 화학에 대한 기본 지식이 있는 사람에게 원자, 분자, 유기체는 이름만 들어도 계층구조를 예상할 수 있게 만든다.

 

아토믹 디자인은 유저 인터페이스를 위한 것이다.

아토믹 디자인의 창시자는 ui web designer이다. 하지만 아토믹 디자인은 웹 디자인 뿐만 아니라 모든 유저 인터페이스에 적용될 수 있다. 예를들어 인스타그램에 아토믹 디자인 개념을 적용하면 이렇다.

아토믹 디자인이 적용된 인스타그램 예시

• 원자: 아이콘, 텍스트, 두개의 이미지 타입(avatar type, primary type)
• 분자: 실용적인 구성요소인 하단 네비게이션 바, 좋아요와 댓글 버튼이 있는 photo action bar 등이 있다. 또한 아바타와 텍스트 원자를 묶어 타이틀이라는 분자를 구성했다.
• 유기체: 위 분자를 묶어 하나의 Photo 유기체를 구성했다. 이 Photo 유기체는 인스타그램을 사용하는 유저들의 UX에 아주 지대한 영향을 미치는 유기체가 되었다. 
• 템플릿: 유기체들이 레이아웃 속에 모여 스켈레톤이 구성되었다.
• 페이지: 템플릿에 동적인 컨텐츠가 입혀 실제 페이지가 완성되었다.

아토믹 디자인은 위에서 보았듯, 웹에서의 CSS와 Javascript와 같은 특정 기술에 얽매여 있는 개념이 아니다. 그래서 웹이 아닌 모바일 앱으로 예시를 들었다. 아토믹 디자인 자체는 어떤 구현 기술에 얽매여 있지 않은 유저 인터페이스를 설계하기 위한 개념이다.

 

결론

이 글을 번역하고 나서 위에서 했던 질문들에 대한 답변을 달아보도록 하겠습니다.

 

1. html태그당 atom 한개를 만들어야 하는데 그럼 모든 html 태그에 대해서 atom을 만들어야 하는 것 인가?

그렇다. 근데 처음부터 원자를 하나하나 다 만들고 시작하는게 아니라 최종 디자인이 나오고 그걸 통해 원자를 뽑아내는게 맞다.

 

2. atom, molecule, organism등은 재사용의 가능성을 높이기 위해서 컨텍스트를 배제해야 하는가?

아니다. atom은 컨텍스트가 배제되어야 하지만 분자부터는 컨텍스트가 들어가도 된다. 단위가 작아질수록 재활용되기 힘들다.

 

3. molecule과 organism의 경계는??

이건 저자 조차 상대적으로 간단한, 상대적으로 복잡한으로 정의하는 바람에 아직도 애매하다. 정답은 없는 것 같다.

각자의 정의를 내리면 될 것 같다. 

 

다만 아래와 같이 가이드가 있긴 하다.

1. If you have a component that is responsible for the layout or listing of a variable number of components (you may see a {children} or an {array.map(...)} somewhere in your react component's JSX), then you are probably dealing with an organism.
2. If you have a component more complex than an atom that is reused often (such as a product in a list of products, an entry in search results, etc), then you have a molecule.
3. If you are doing a lot of state management in order to orchestrate sub components (a form is a great example), then you have an organism.
4. If you have a component whose only purpose is to give more context to its sub components (like a form field for city, state, and zipcode combined as an AddressField component), then you have a molecule.

 

4. 어플리케이션의 상태는 어디부터 들어가야하는가?

어플리케이션의 상태(리덕스에서 관리하는 비즈니스 로직과 관련된 상태)는 page에서만 들어가야한다. 다만 분자, 유기체, 템플릿등에서 비즈니스 로직을 관리하기 위한 상태가 아닌 컴포넌트를 동작시키기 위한 상태를 관리하는건 상관없다. (input과 onChange를 state로 관리하는등의 상태관리)

아토믹 디자인 분류 참고 사이트

https://demo.patternlab.io/

Pattern Lab

출처

https://medium.com/swlh/atomic-design-for-developers-atomic-engineering-3591af676ef4

https://atomicdesign.bradfrost.com/chapter-2/