Atomic Design Pattern

seul_velog·2023년 10월 4일
0

컴포넌트와 디자인 시스템

컴포넌트 (Component)

컴포넌트는 재사용 가능한 UI 단위로서, 특정 기능이나 시각적 요소를 담당하는 독립적인 요소이다. 컴포넌트는 웹이나 앱에서 반복적으로 사용될 수 있으며, 일관된 사용자 경험을 제공한다.

  • ✍️ 아토믹 디자인의 각 단계 (원자, 분자, 유기체 등)는 사실상 컴포넌트의 다양한 크기와 복잡성을 나타낸다. 원자는 가장 기본적인 컴포넌트를 의미하며, 분자와 유기체는 여러 컴포넌트들이 조합된 복잡한 구조를 나타낸다.



디자인 시스템 (Design System)

디자인 시스템은 UI 툴킷, 프레임워크, 컴포넌트 라이브러리, 스타일가이드 등의 집합을 넘어 제품을 구성하는 표준 집합이라고 볼 수 있다.
디자인 시스템은 팀 간의 의사소통을 향상시키며, 빠르게 일관된 UI를 구축하는 데 도움을 준다.

  • ✍️ 아토믹 디자인 패턴은 디자인 시스템을 구축하는 방법 중 하나로 볼 수 있다. 아토믹 디자인의 구조화된 접근법은 컴포넌트와 패턴의 재사용성을 증가시키고, 디자인 시스템 내에서의 일관성을 보장한다.

디자인 시스템의 목적

제품을 처음 만들 때는 초기에 세운 규칙들이 잘 이행되고 반영된다. 하지만 시간이 지날수록 이런 규칙들이 어긋나고 점차 사라지는 등의 문제가 발생한다. 새로운 프로젝트 구성원과 팀이 관여하고, 다양한 플랫폼에 걸쳐 프로젝트가 확장되면 이러한 현상이 가속되며 결국 제품의 사용자 경험에 큰 영향을 미칠 수 있다.

이러한 혼란을 방지하고 질서를 세우는 역할을 하는 것이 디자인 시스템이다. 디자인 시스템은 어떤 제품을 만들 때 표준 규칙을 세우고 이에 따라 작업을 효율적이고, 일관되며, 나아가 확장할 수 있도록 한다.


디자인 시스템의 장점

효율성 확보 (Efficiency)
디자인 시스템을 사용하면 반복되는 요소들을 매번 새로 만들 필요가 없어진다. 재사용 가능한 컴포넌트, 패턴 등을 이용해 작업의 효율성을 높일 수 있으며, 전체 제품 개발에 필요한 시간을 단축하여 더욱 빠르게 시장에 제품을 출시할 수 있다.

일관성 있는 사용자 경험 (UX Consistency)
디자인 시스템의 표준 규칙과 원칙에 따라 서로 다른 페이지나 플랫폼을 걸쳐 일관된 사용자 경험을 구축할 수 있다. 반복되는 컴포넌트 제작에 소비되는 시간을 아껴서 사용자에게 더 집중할 기회를 만들 수 있다.

다양한 제품에 대응 (Design at Scale)
디자인 시스템을 통해 효율성과 일관성을 확보함으로써 다양한 규모의 제품들을 빠르고 쉽게 만들 수 있다.

협업에 기여 (Collaboration)
디자인 시스템은 디자이너, 개발자, 프로젝트 매니저 등 프로젝트팀 구성원 사이의 지식 격차를 줄이고 공통의 원칙을 숙지하여 협업에 기여할 수 있다. 이를 통해 프로젝트 구성원이 함께 학습하고 성장할 수 있으며, 결국 프로젝트의 생산성 향상으로 이어진다.





Atomic Design Pattern 이란

디자인 시스템을 구성하는 방식 중 하나로, 웹 인터페이스를 원자, 분자, 유기체, 템플릿, 페이지의 5단계로 나누어 설계하고, 이들 요소들을 조합하여 복잡한 웹 페이지나 애플리케이션을 구축하는 것을 목표로 한다.
즉, Atomic Design은 작은 UI 요소부터 시작하여 점차 큰 단위의 UI 구조를 만들어가는 방식을 제안하는 디자인 패턴이다.

  • Atomic Design을 적용하면, UI 디자인과 개발이 유연하고 일관성 있게 이루어질 수 있다. 또한, 이 방법론을 통해 팀원들 간의 소통도 원활해질 수 있다.😤



등장배경

웹 디자인과 개발 분야는 지속적으로 복잡성이 증가하고 있다. 디자인과 프론트엔드 개발은 더 이상 간단한 페이지 레이아웃을 넘어서, 재사용 가능한 컴포넌트와 유지 보수가 용이한 시스템을 필요로 하게 되었다. 이러한 복잡한 문제에 대응하기 위하여 디자인 시스템과 패턴 라이브러리의 필요성이 생겨났고, Atomic Design은 이러한 문제를 해결하기 위한 방법론 중 하나로 탄생했다.



개념

brad frost의 아토믹 디자인은 화학적 관점에서 영감을 얻은 디자인 시스템이다.

모든 것은 atom(원자)으로 구성되어있고 atom(원자)들이 서로 결합하여 molecule(분자)이 되고, molecule는 더 복잡한 organism(유기체)으로 결합하여 궁극적으로 모든 물질을 생성한다. 아토믹 디자인에서는 이 개념을 차용해서 컴포넌트를 atom, molecule, organism, template, page의 5가지 레벨로 나눈다.

즉, Atomic Design은 자연의 원자와 분자를 모방하여 디자인 시스템을 구성하는 방식이다. 웹 인터페이스는 여러 개의 독립적인 부분으로 나눌 수 있으며, 이 부분들을 조합하여 복잡한 템플릿과 페이지를 구성할 수 있다.



구조

Atomic Design은 5단계의 구성 요소로 나뉜다.

1. Atoms (원자)

가장 기본적인 빌딩 블록. atom은 더 이상 분해할 수 없는 기본 컴포넌트이다.
button, input, 색상, 폰트 등의 UI 요소가 여기에 해당된다.
개별적으로는 큰 의미를 갖지 않지만, 다른 구성 요소와 결합하면 유용한 인터페이스를 형성한다.


2. Molecules (분자)

원자들의 조합으로 만들어진 간단한 UI 구성 요소이다.
예를 들면, label과 input, button이 결합된 검색 폼 이 여기에 해당된다. molecule의 중요한 점은 한 가지 일을 하는 것이다.


3. Organisms (유기체)

분자나 원자들의 복잡한 조합이다. 이것은 atom, molecule, organism으로 구성할 수 있다. atom, molecule에 비해 좀 더 구체적으로 표현되고 컨텍스트를 가지기 때문에 상대적으로 재사용성이 낮아지는 특성을 가진다.

예를 들어 header 라는 컨텍스트에 logo(atom), navigation(molecule), search form(molecule)을 포함할 수 있다. 헤더, 푸터, 사이드바와 같이, 다양한 요소가 결합하여 만들어진 큰 UI 구성 요소가 여기에 해당된다.


4. Templates (템플릿)

유기체, 분자, 원자들이 조합된 페이지 레이아웃 구조이다. 템플릿은 page를 만들 수 있도록 여러 개의 organism, molecule로 구성할 수 있다.

실제 컴포넌트를 레이아웃에 배치하고 구조를 잡는 와이어 프레임으로써, 실제 콘텐츠가 없는 page 수준의 스켈레톤이라고 정의할 수 있다.
즉, 실제 콘텐츠는 포함되지 않고, 어떤 식으로 UI 구성 요소들이 배치될지를 정의한다.


5. Pages (페이지)

page는 유저가 볼 수 있는 실제 콘텐츠를 담고 있다. 템플릿에 실제 콘텐츠와 데이터를 적용한 것이다. (template의 인스턴스라고 할 수 있다.)

예를 들어 장바구니 페이지에 유저가 담은 상품이 없거나 10개를 담는 다양한 template의 인스턴스를 볼 수 있다. 최종 사용자에게 보여지는 디자인의 실체이다.



Atomic Pattern





어떻게 적용할까?

기존 프로젝트의 모든 컴포넌트를 다시 분리하는 것은 어려우므로 천천히 만들고 대체하기위한 components 폴더를 생성한다.

// Atimoc -> Group

/components
 ㄴ atoms
 	ㄴ Button
    ㄴ Heading
    ㄴ Text
    ㄴ ...
 ㄴ molecules
 	ㄴ PageHeader
    ㄴ ProductCard
    ㄴ ...
 ㄴ organisms
 	ㄴ ProductCardGrid
    ㄴ ProductSwiperSlide
    ㄴ ...
 ㄴ templates
 	ㄴ BuyPageTemplate
    ㄴ ...

하지만 개발자마다 molecuels인지 organisms인지 하는 애매모호한 관점이 서로 차이를 갖게 되는 문제가 있을 수도 있고, 프로젝트가 커질수록 오히려 사용하고자 하는 아토믹디자인 패턴의 컴포넌트를 찾기가 어려울 수도 있겠다는 생각이 들었다. 🤔

예를들면 A 페이지에 사용되는 ProductCard component를 사용하려고 하는데 이 컴포넌트가 molecules 폴더에 있을지 organisms 폴더에 있을지 한번 고민을 해보거나 직접 찾아야하는 문제가 생길 수도 있지 않을까?

이때 만약 폴더 구조를 아래와 같이 한다면 문제가 해결될까?

// Group -> Atomic

/components
 ㄴ A
 	ㄴ atoms
    ㄴ molecules
    ㄴ organisms
    ㄴ templates
 ㄴ B
 	ㄴ atoms
    ㄴ molecules
    ㄴ organisms
    ㄴ templates
...

이 경우에는 반대로 A라는 곳에서 사용되는 atoms 구조와 B라는 곳에서 사용되는 atoms가 정확하게 같은 컴포넌트를 가리킨다면 굳이 구분할 필요가 있을지 의심이된다. 즉, 공통 컴포넌트가 너무나도 많이 겹치게 될 것 같다고 생각했다. 또 만약 이를 위해서 공통 컴포넌트 폴더를 따로 만든다면, 이전 경우에서 고민했던 것처럼 결국 다시 어떤 컴포넌트가 어느 폴더에 있을지 한번 더 생각해야 하는 일이 벌어질 것이라고 예상했다.🧐

이경우 협업을 진행할 팀원끼리 서로 공통된 용어를 통해서 정리하고 통일해야 할 것이고, 명확히 분류하기 까다로운 moecules와 organisms의 구분에 있어서 팀원간의 기준을 정확히 해두는 것도 필요할 것이라고 생각했다.

프로젝트가 작을경우 필요한 컴포넌트의 개수는 정해져있거나 혹은 급격하게 늘어날 일은 거의 없을것이라고 생각한다. 이때 아토믹 디자인 패턴을 적용해서 기존보다 선명히 컴포넌트를 분리하고 계층별로 배치하는 것이 컴포넌트 각각의 목적을 뚜렷하게 하고 필요없이 방대해지지 않도록 하는 것에 도움이 될 것이라고 느꼈다.

하지만 프로젝트가 복잡해지고 커짐에따라서 개선해야 할 부분들이 분명히 생겨나고 계속해서 팀원들과의 합의와 결정이 필요해질 것이다. 이때에 같이 고민하며 명확한 규칙을 선정하면서 협업을 이루어나간다면 더욱 좋은 경험을 쌓을 수 있을것이라고 기대한다.😀 (storybook도 활용하면 좋을 것 같다!)


✍️ +) 폴더 구조 예시

src/
|-- assets/
|   |-- images/
|   |-- icons/
|-- components/
|   |-- atoms/
|   |   |-- Button/
|   |   |   |-- Button.js
|   |   |   |-- Button.stories.js
|   |   |   |-- Button.test.js
|   |   |   |-- Button.styles.css
|   |   |-- Input/
|   |   |-- Label/
|   |   |-- ...
|   |-- molecules/
|   |   |-- FormField/
|   |   |-- UserCard/
|   |   |-- SearchBar/
|   |   |-- ...
|   |-- organisms/
|   |   |-- Header/
|   |   |-- Footer/
|   |   |-- ArticleList/
|   |   |-- ...
|   |-- templates/
|   |   |-- DefaultPageLayout/
|   |   |-- ArticlePageLayout/
|   |   |-- ...
|-- pages/
|   |-- HomePage/
|   |-- AboutPage/
|   |-- ContactPage/
|   |-- ...
|-- utils/
|-- services/
|-- styles/
|-- ...

atoms: 가장 기본적인 UI 요소 (버튼, 입력 필드, 레이블 등)
molecules: 여러 아톰을 조합한 비교적 간단한 UI 요소 (서치바, 유저 카드, 폼 필드 등)
organisms: 여러 몰레쿨과 아톰을 조합한 복잡한 UI 요소 (헤더, 푸터, 아티클 리스트 등)
templates: 페이지의 구조나 레이아웃을 정의 (기본 페이지 레이아웃, 아티클 페이지 레이아웃 등)
pages: 실제 사용자에게 보여지는 각 페이지와 연결되는 컴포넌트 (홈페이지, 정보 페이지, 연락처 페이지 등)





reference)
atomic-design
atomic-design2
design-system

profile
기억보단 기록을 ✨

0개의 댓글