[React] 아토믹 디자인 패턴React] 아토믹 디자인 패턴 (Atomic Design Pattern)

아토믹 디자인 패턴

 

---

 

목차

 

들어가며

아토믹 디자인 패턴이란?

아토믹 디자인 패턴구조(5단계)

아토믹 디자인 패턴의 문제점

아토믹 디자인 패턴의 장단점

아토믹 디자인 패턴 예시

마무리

 

 

---

 

---

[들어가며]

프론트엔드 멘토링을 하면서 멘토링 프로젝트를 진행하게 되었다.

프로젝트를 진행하면서 협업 효율성과 유지보수성을 높이기 위해 디자인 패턴을 도입하게 되었다.

컴포넌트 구조를 명확히 정의하고 역할과 복잡도에 따라 체계적으로 분리할 수 있다는 점, 그리고 일관된 UI를 빠르게 구현할 수 있다는 점에서 아토믹 디자인 패턴을 선택하게 되었다.

 

---

[아토믹 디자인 패턴(Atomic Design Pattern)이란?]

프로젝트가 점점 커지면서 유지보수가 어려워지거나 코드가 복잡해지는 경우가 발생하기도 하였다.

페이지마다 폰트 크기, 색상, 테두리 스타일, 여백 등 디테일이 수정되면서 UI의 일관성이 무너져 사용자 경험이 저하되는 문제가 생기기도 한다.

 

<원인>

• 컴포넌트의 파편화 : 디자이너난 개발자들이 각자 따로 버튼을 만들게 됨
  • 버튼마다 폰트 크기, 색상, 모양(테두리 둥글기), 등이 페이지마다 다르게 만들어진다.
• 명확한 컴포넌트 설계 기준 미비 : 팀원들 마다 컴포넌트를 나누는 기준이 다름

<발생하는 문제점>

• 불필요한 대화 시간이 길어지고 소통에 오류가 생겨 유지보수가 힘들어진다.
• 많음 컴포넌트로 재사용이 어렵거나 확장하기 어려운 구조가 생긴다.
• 코드 리뷰가 어렵다.

 

이러한 문제를 해결할 수 있도록 아토믹 디자인 패턴이 생겨났다.

<디자인 시스템>

• 어떤 조직이 디지털 인터페이스를 디자인하고 구축하는 방식
• 버튼의 크기, 색
• 폰트 크기
• 여백
• 디자인 시스템을 잘 구성하면 컴포넌트들이 통일되고 유지보수가 쉽다.

 

<아토믹 디자인 패턴(Atomic Design Pattern)>

: 원자(Atom), 분자(Molecule), 유기체(Organism), 템플릿(Template), 페이지(Page)가 동시에 함께 작동하여 효과적인 인터페이스 디자인 시스템을 만드는 것

아토믹 디자인 패턴의 구성

• 디자인 시스템을 만드는 방법론
• 화학에서 원자(Atom) → 분자(Molecule) → 유기체(Organism) 순서로 점점 복잡한 구조로 쌓아가는 개념이다.

단계	설명	예시
Atom	가장 작은 단위	버튼, 라벨, 텍스트 입력 창
Molecule	Atom 여러개를 합친 것	검색 창(입력창 + 버튼)
Organism	여러 Molcule/Atom을 묶은더 큰 덩어리	헤더(로고 + 메뉴 + 검색창)
Template	실제 페이지 구조를 잡는 뼈대	상품 상세페이지 레이아웃
Page	실제 데이터가들어간 완성된 화면	진짜 사용자가 보는 장바구니 페이지

 

이렇게 컴포넌트를 나누면 컴포넌트를 체계적으로 재사용성 높게 만들 수 있다.

 

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

UI 응집력을 있는 전체와 구성요소들의 집합으로 이해하는 데 도움이 되는 하나의 사고 모델이다.

원자, 분자, 유기체, 템플릿, 페이지로 이어지는 다섯 단계는 인터페이스 디자이 시스템의 계층 구조 안에서 각각 중요한 역할을 한다.

아토믹 디자인 패턴의 폴더 구조

아토믹 디자인 패턴을 사용하는 프로젝트의 폴더 구조이다.

Atoms → ㅡMolecules → Organisms → Template → Pages 순으로 구성되며, 컴포넌트의 추상화 수준에 따라 계층적으로 나뉜다.

하지만 대부분의 IDE에서는 폴더가 알파벳 순으로 정렬되기 때문에 Atoms → Molecules → Organisms → Template → Pages 순서로 폴더를 구성하더라도 Pages 폴더가 Tamplates보다 먼저 나오는 문제가 발생합니다.

그래서 저는 정렬 문제를 해결하고 의도한 계층 구조를 명확히 드러내기 위해 Pages를 제외한 폴더들(Atoms , Molecules, Organisms , Templates) 앞에 _(언더바)를 붙여주었습니다.

 

---

[아토믹 디자인 패턴 구조(5단계)]

원자(Atoms)

• 사용자 인터페이스를 구성하는 기본 구성 요소
• 더 이상 분해할 수 없는 기본 컴포넌트
• 모든 기본 스타일을 한눈에 보여준다.
• ex) Label, Input, Button
• 기본 HTML element 태그, 글꼴, 애니메이션, 컬러 팔레트, 레이아웃과 같이 추상적인 요소도 포함

 

분자(Molecules)

• 하나의 단위로 함께 기능하는 비교적 단순한 UI 요소의 집합
• 여러 Atom을 결합하여 최소 한 가지 기능을 수행한다.
• 단일 책임 원칙(SRP : Sigle Responsibillity Principle)을 준수
  • 한 가지 일을 잘하라는 사고방식을 장려하는 오래된 컴퓨터 과학 원칙
• 재사용이 가능한 컴포넌트가 생긴다.
• molecule의 SRP는 재사용성과 UI에서의 일관성, 테스트하기 쉬운 장점을 가지고 있다.
• [단점] 단일 패턴에 너무 많은 복잡성을 부여하면 소프트웨어가 다루기 어려워진다.

 

유기체(Organisms)

• Molecules + Atoms을 모아서 만들며 사용자에게 의미와 역할이 존재하는 단위
• Atom이나 Molecule보다 더 복잡하다.
• 재사용 가능하지만 재사용성은 Atom/Molecule보다 낮다.
  • 특정한 컨텍스트와 목적에 맞춰 구성되기 때문
• 서비스에서 표현될 수 있는 명확한 영역과 특정 컨텍스트를 가진다.
• 단순한 기능 이상의 구체적인 목적과 맥락을 가진 UI 덩어리다.
• 인터페이스의 각 부분을 구성하며 명확한 기능과 의미를 가진 독립적인 영역이다.
• 특정 페이지나 인터페이스에서 반복적으로 사용될 수 있는 패턴 단위로 작동

 

템플릿(Template)

• 여러 개의 organism, molecule로 구성
• 레이아웃에 실제 콘텐츠나 데이터 없이 컴포넌트를 배치해 page 구조를 설계
• 페이지의 뼈대와 기본 콘텐츠 구조를 정의
• 콘텐츠 구조를 명확히 하는 것이 중요

 

페이지(page)

• 템플릿에 실제 data가 결합이 되어 사용자에게 전달이 되는 최종 디자인의 형태
• 유저가 볼 수 있는 실제 콘텐츠를 담고 있다.
• template의 인스턴스
• page template에 대표 텍스트, 이미지, 미디어를 추가하여 실제 콘텐츠가 어떻게 동작하는지 보여줄 수 있다.

 

<요약>

• Atom : 더 이상 쪼갤 수 없는 디자인의 최소 단위
• Molecule : Atoms를 모아서 만들어진다. 최소 한 가지 기능을 수행한다.
• Organism : Molecule + Atom을 모아서 만들며 사용자에게 의미와 역할이 존재하는 단위
• Template : 아직 데이터는 연결되어있지 않은 최종 레이아웃의 형태, 여러 개의 Organism으로 구성된다.
• Page : 템플릿에 실제 data가 결합이 되어 사용자에게 전달이 되는 최종 디자인의 형태

 

---

[아토믹 디자인 패턴의 문제점]

1. 컴포넌트 분류 기준의 모호함
2. 유사한 UI 변형으로 인한 중복 또는 과도한 props
3. Organism 책임 범위의 정의 재정립

 

1. 컴포넌트 분류 기준의 모호함

<문제점>

Atom, Molecule, Organism의 구분 기준이 명확하지 않아 팀원마다 해석이 달라지고 설계 일관성이 떨어진다.

팀 내 컴포넌트 리뷰나 재사용 시 오해가 발생한다.

카카오 페이지 웹에서 실제로 작성한 molecule, organism 컴포넌트

 

<원인>

SRP(single Responsibility Principle)에 기반하지 않은 직관적 분류

명확한 기준 없이 직관적으로 분류하다 보니 컴포넌트가 의도치 않게 중복되거나 역할 범위가 애매해진다.

특히 Molecule과 Organism의 구분이 자주 헷갈림

 

<해결책>

• Atom
  • 더 이상 쪼갤 수 없는 UI 단위
  • ex) 텍스트, 버튼, 아이콘 등
• Molecule
  • Atom으로 구성된 UI적 요소
  • 재사용하기 쉬움
  • context 없음
  • ex) 버튼 크룹, 입력 박스
• Organism
  • Atom, Molecule, Organism으로 구성된 Layout 중심의 블록
  • context 포함
  • ex) 댓글 목록 영역, 툴바 등
• 모호한 경우 Organism으로 작성한 후에 코드 리뷰로 조정한다.

 

 

2. 유사한 UI 변형으로 인한 중복 또는 과도한 props

<문제점>

비슷한 디자인이지만 구조가 다른 경우 중복된 컴포넌트 생성 또는 props 남용

댓글과 디자인이 비슷하지만 약간 다른 대댓글 디자인

 

<원인>

기존 해결 방안

• 새 컴포넌트 만들기 → 중복되는 컴포넌트가 많아지고 중복 코드가 많아진다.
• 기존 컴포넌트에 props를 계속 추가하기 → props가 점점 많아져서 쓰기 복잡해 유지보수성이 떨어진다.

아토믹 디자인 구조에서는 고정된 컴포넌트 구조에 다양한 UI 변형을 대응하기 어렵다.

 

<해결법>

• Compound 컴포넌트 패턴 사용

<Comment>
  <div>
    <Comment.ProfileImage />
    <Comment.Name />
    <Comment.Info />
  </div>
  <Comment.Content />
  <div>
    <Icon type={IconType.Heart} />
    ...
  <div />
</Comment>

• 필요한 부분만 조합해서 사용 가능
• 컴포넌트 수와 props 수를 동시에 줄임
• Organism 구조를 다시 정의
• atom/molecule 단위로 더 쪼개서 재조

 

 

 

 

3. Organism 책임 범위의 정의 재정립

<문제점>

Organism을 어디까지 묶어야 할지 명확하지 않아 과도하게 크거나 작은 단위로 분리되는 문제가 발생 → 팀원 간 기준이 달라 정리와 협업에 어려움이 생김

카카오 페이지의 댓글

 

<원인>

역할의 경계가 불분명

Layout 기분만으로 Organism을 정의하면 기능적 책임이 불분명해질 수 있고 네이밍이나 구조도 일관성을 잃기 쉽다.

<해결법>

Orgnism은 단순히 시각적으로 나뉜 영역이 아닌 의미 있는 기능적 책임을 갖는 UI 단위로 정의해야 한다.

• Layout 책임 단위로 정의
• Layout에서 명확히 나뉘는 영역을 기준으로 Oragnism 분할
• 하나의 UI 책임 단위를 기준으로 묶기(ex: 댓글 툴바, 댓글 리스트 등)
• 기능 중심 네이밍보다는 역할 중심 네이밍 사용

<판단 기준>

• UI 상에서 명확히 구분되는 영역 : 페이지에서 시각적으로 독립된 UI 블록을 기준으로 나눈다.(ex: 댓글 영역, 추천 콘텐츠 영역)
• 기능적 책임 : 해당 UI가 하나의 기능을 독립적으로 수행하는가? (ex: 댓글 작성, 댓글 리스트 출력 등)
• 컨텍스트 포함 여부 : 도메인 데이터나 비즈니스로직(이벤트 처리 등)을 내부에서 다루고 있는가?
• 너무 작게 나누지 않고 컴포넌트가 적절한 수준의 책임을 갖도록 구성되어 있는가?

 

<예시>

• CommentListToolBar : 댓글 데이터를 정렬, 필터 하는 기능이 있는 Organism
• CommentList : 각 댓글의 레이아웃을 구성하며, 댓글 아이템을 리스트로 나열하고 spacing을 관리

 

---

[아토믹 디자인 패턴의 장단점]

<장점>

1. 부분과 전체를 모두 고려한 설계 가능
   • UI를 원자, 분자, 유기체, 템플릿, 페이지 단위로 나누어 구성
   • 각 컴포넌트 단위의 품질뿐만 아니라 전체 맥락에서의 일관성과 기능성 확인 가능
2. 구조와 콘텐츠 분리로 유연한 디자인
   • 콘텐츠와 레이아웃 구조를 분리해 다양한 상황에 대응 가능
   • 예 : 템플릿에서 콘텐츠 구조만 설정, 페이지 단계에서 실제 데이터 주입
3. 협업 효율성 증가
   • 디자이너와 동일한 용어(피그마와 코드 네이밍 일치) 사용
   • UI 모델링을 공동으로 진행하며 명확한 기준을 마련
4. 컴포넌트 재사용성과 유지보수 용이
   • UI 상태나 로직은 외부에서 주입(props활용)
   • 레이아웃 관련 스타일은 컴포넌트 밖에서 처리
   • 결과적으로 컴포넌트는 더 순수해지고, 테스트와 관리가 쉬워짐
5. 멘탈 모델로서의 유용성
   • 단계 간 계층 구조를 쉽게 이해할 수 있어 팀원 같 커뮤니케이션에 효과적
   • 원자-분자-유기체처럼 이름만으로도 구조 이해가능

 

<단점>

1. 컴포넌트 분류 기준의 모호함
2. 유사한 UI 변형으로 인한 중복 또는 과도한 props
3. Organism 책임 범위의 정의 재정립
4. 과도한 분해로 복잡성 증가
   • 너무 작은 단위까지 나누다 보면 오히려 컴포넌트 간 연결 관계가 복잡해짐.
   • 결과적으로 유지보수가 오히려 어려워질 수 있음
5. 설계 초기 비용 증가
   • UI를 구조적으로 나누고 모델링하는 데 초기 시간이 많이 소요됨
   • 빠른 MVP 단계에서는 부담이 될 수 있음
6. 조직과 팀마다 다른 해석 가능
   • "원자, 분자, 유기체" 용어가 명확해 보여도 조직마다 의미 해석이 다를 수 있음
   • 문서 내에서도 GE 팀처럼 자체 분류법을 따르는 사례가 나옴 → 표준화 어려움
7. 정적 구조에 치중할 위험
   • 디자인 시스템이 너무 구조 중심으로 고정되면 콘텐츠나 상호작용의 다양성을 반영하기 어려움
   • 예 :유연한 인터렉션이 많은 UI에는 부적합할 수 있음

 

 

---

[아토믹 디자인 패턴 예시]

Atomic design applied to the native mobile app Instagram.

 

1. 원자(Atom)
   • 인스타그램 UI
   • 아이콘, 텍스트 수준의 요소로 두 가지 이미지 유형( 게시글이미지, 프로필 이미지)으로 구성
2. 분자(Molecule)
   • 간단하고 실용적인 구성요소를 형성
   • 아이콘 그룹으로 만들어진 Navbar
   • 사용자가 사진에 좋아요를 누르거나 댓글을 달 수 있는 사진 작업 바
   • 텍스트 + 이미지 조합으로 만들어진 프로필 바
3. 유기체(Organism)
   • 유기체가 형성되는 복합 구성으로 인스타그램 전체 경험의 초석이 된다.
   • 사용자 정보, 이미지, 사진과 관련된 동작, 좋아요 수 등 사진 관련 정보로 구성
4. 템플릿(Template)
   • 레이아웃의 맥락에서 구성요소들이 어떻게 결합되는지 확인할 수 있다.
   • 인스타그램의 콘텐츠 골격을 보여준다.
   • 사용자 아이디, 아바타, 사진, 좋아요 수 같은 동적 콘텐츠 강조
5. 페이지(Page)
   • 실제 콘텐츠가 주입된 최종 제품
   • 기본 디자인 시스템이 함께 모여 기능적인 UI를 형성

 

 

---

[마무리 : 나의 생각]

아토믹 디자인 패턴을 공부하면서 의문이 생겼다.

"파란색 기본 버튼이 atom이라면 빨간색 취소 버튼은 뭐지?", "아이콘이 들어간 버튼은 atom일까 molecule일까?"

처음엔 버튼의 변형들을 Molecule이라고 생각했다.

atom 단계에서는 버튼의 기본 형태만 만들고 빨간색 취소 버튼이나 아이콘이 들어간 버튼처럼 디자인이 바뀌거나 기능이 추가된 형태는 Molecule이라고 생각했다.

즉 atom은 단순 베이스 역할을 하고 실제로 사용하는 molecule에서 만든다는 논리라고 생각했다.

<내가 생각한 아토믹 디자인 패턴>

• atom : 기본 버튼, 기본 텍스트, 컬러 같은 기본 단위 만들기
• molecule : 기본 버튼, 취소 버튼, 아이콘 버튼, 제목 텍스트, 설명 텍스트 등
• organism : molecule들을 조합해서 organism으로 만들기
• template : organism들을 레이아웃에 배치
• page : template에 실제 데이터를 넣은 것

아토믹 디자인 패턴을 공부하면서 내가 잘못 이해하고 있었다는 것을 알게되었다.

버튼은 여전히 atom이다.

버튼의 색상, 텍스트, 아이콘 유무 같은 것은 props로 조절되는 속성일 뿐이다.

즉 파란색이든 빨간색이든 텍스트만 있던 아이콘이 있든 기능적으로 버튼이라는 역할을 하고 있다면 여전히 atom이라는 것이다.

Molecule은 서로 다른 Atom이 조합되어 새로운 의미를 가지는 경우에 해당한다.

예를 들어 text와 input 필드가 함께 있는 FormField 같은 것이 대표적이다.

서로 독립적으로 사용될 수 있는 Atom들이 조합되어 하나의 유의미한 UI 조각을 이룰 때 그것이 Molecule이 되는 것이다.

결국 내가 처음에 헷갈렸던 이유는 "디자인이 다르면 다른 단위로 나워야 한다"라는 생각 때문이었다.

하지만 아토믹 디자인에서는 스타일이 아닌 역할과 조합 방식이 기준이다.

이걸 깨닫고 나니 atomic design을 조금 더 명확하게 이해할 수 있었다.

같은 컴포넌트라도 기능과 조합 구조를 기준으로 나누어야 하고 스타일이나 변형은 컴포넌트 안에서 props로 유연하게 처리하면 되는 것이다.

이렇게 이해하고 나닌 컴포넌트를 나누는 기준을 알게 되었고 스타일기준이 아닌 기능과 조합이 기준이라는 것을 알게 되었다.

 

 

---

잘못된 정보는 댓글에 남겨주시면 감사하겠습니다!😊

댓글과 좋아요는 큰 힘이 됩니다!

 

[ 참고자료 ]

 

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

Atomic Design Methodology | Atomic Design by Brad Frost

 

 

https://tech.kakaoent.com/front-end/2022/220505-how-page-part-use-atomic-design-system/

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

 

https://slash.tistory.com/14

Atomic Design 예시

 

https://yozm.wishket.com/magazine/detail/1531/

Atomic Design Pattern의 Best Practice 여정기 | 요즘IT