목차8개 항목
출처와 참고
테오(teo)의 「Atomic Design Pattern의 Best Practice 여정기」(2022.06)과 Brad Frost의 『Atomic Design』을 바탕으로 재구성한 노트다.
Atomic Design이란
자주 쓰는 부품을 잘 정리해 두면 같은 톤의 결과물을 빠르게 조립할 수 있다. 프로그램에서 이 생각이 프레임워크라면, 디자인에서는 디자인 시스템이다. Brad Frost는 디자인 시스템의 부품 관계를 화학 용어로 설명했다.
| 단계 | 정의 | 예 |
|---|---|---|
| 원자(Atoms) | 더 쪼갤 수 없는 최소 단위 | 버튼, 입력창, 라벨 |
| 분자(Molecules) | 원자를 모아 최소 한 가지 기능을 한다 | 라벨 + 입력창 + 버튼 = 검색 폼 |
| 유기체(Organisms) | 분자·원자를 모아 사용자에게 의미 있는 단위 | 헤더, 상품 목록 |
| 템플릿(Templates) | 데이터 없이 유기체를 배치한 레이아웃 | 페이지 골격 |
| 페이지(Pages) | 템플릿에 실제 데이터가 들어간 최종 화면 | 홈 화면 |
Atomic Design은 선형 프로세스가 아니라 멘탈 모델이다. 인터페이스를 하나의 전체이면서 동시에 부품의 모음으로 보게 돕는 틀이다.
폴더 구조로 써 보면
/components
/atoms
/molecules
/organisms
/templates
/pages장점
- 알파벳 순서가 계층 순서와 맞아 구조가 한눈에 보인다.
- 계층을 의식하게 되어 컴포넌트를 나누려는 시도가 늘고 목적이 선명해진다.
- 의존이 없는 원자와 프로젝트 안에서만 쓰이는 분자·유기체가 구분되어 원자의 독립성과 재사용성을 챙기게 된다.
한계
| 문제 | 내용 |
|---|---|
| 분자냐 유기체냐 | 실제 조립 단계는 다섯보다 훨씬 많다. 분자 안에 분자, 유기체 안에 유기체가 생긴다. 원자·템플릿·페이지만 판단이 쉽다 |
| 계층 하나로만 나눈다 | 실제로는 헤더·푸터 같은 목적, 검색·프로필 같은 영역으로 찾고 싶다. SideContentBar는 이름만으로 계층을 알 수 없다 |
| 데이터 바인딩 위치 | 템플릿/페이지 구분은 Container-Presenter와 같다. 그런데 상태 관리로 분자·유기체에 직접 데이터를 붙이기 시작하면 어느 계층에서 바인딩하는지도 모호해진다 |
| 고민하게 만드는 컨벤션 | 분류를 쉽게 하려고 도입했는데 "어디 넣지"를 매번 고민하게 된다 |
결국 Atomic Design은 개발용도, 폴더 구조용도 아니었다. 디자인 시스템을 이해시키려는 모델이다.
폴더를 없애면 안 되는 이유
"어차피 파일명으로 검색하고 import는 IDE가 해 주니 전부 한 폴더에 두자"는 접근은 작을 때만 편하다. 계층이 안 보이면 진입점을 찾기 어렵고, 기존 컴포넌트를 다른 화면(예: 데스크톱 → 모바일)에 재조립할 때 의존 범위를 코드를 열어 봐야만 안다. 폴더 구조는 책의 목차다. 읽는 동안엔 안 보지만 찾을 때와 전체를 파악할 때 없으면 안 된다. 폴더 구조는 곧 생각의 체계다.
절충안: 이름 붙은 영역 먼저, 그 아래 계층
최상위 축을 무엇으로 둘지 두 안이 있다.
| 안 | 내용 | 결과 |
|---|---|---|
| 1안 | 원자·분자 계층을 최상위로 두고 그 아래를 그룹화 | 커지면 계층 폴더마다 다시 비대해진다 |
| 2안 | 앱을 작은 앱의 집합으로 본다. 사람은 컴포넌트를 계층보다 이름으로 먼저 떠올린다 | 체계가 더 선명하다. 공통 부품은 별도 공통 폴더로 |
폴더 구조를 실제로 보는 때는 코딩 중이 아니라 프로젝트를 처음 파악할 때다. 그래서 코드보다 프로젝트를 이해하기 쉬운 구조가 목표다.
- 기획·디자인이 이미 이름을 붙여 부르는 영역은 그 이름으로 폴더를 만든다. 영문 번역도 고민하지 않고 부르는 용어를 통일한다.
- "그것도 이름을 붙여야 돼요?"라는 답이 나오는 지점부터 Atomic 계층을 쓴다.
분자와 유기체를 가르는 규칙
먼저 컴포넌트를 둘로 나눈 뒤 각각 판단이 필요 없는 기준을 세운다. 아래는 한 가지 예다.
| 뷰(공통) 컴포넌트 | 비즈니스 컴포넌트 | |
|---|---|---|
| 성격 | props로만 동작, 다른 프로젝트에서도 재사용 | 상태 관리 데이터와 결합, 이 프로젝트 전용 |
| 원자 | import가 하나도 없는 컴포넌트 | 외부 의존 없는 아이콘·글자·이 영역 전용 버튼 |
| 분자 | 다른 컴포넌트에 의존 (SelectBox = input + dropdown) | 엔티티를 표현하는 것. 배열의 한 항목으로 렌더되는 컴포넌트 |
| 유기체 | 모달처럼 독립된 덩어리 | 분자가 아닌 나머지 |
템플릿은 레이아웃, 페이지는 권한 없음 같은 상태별 화면 구분에 쓴다.
정리
- Atomic Design은 디자인 시스템을 위한 멘탈 모델이다. 그대로 폴더 규칙으로 쓰면 커질수록 경계가 흐려진다.
- 계층을 의식하는 습관 자체는 좋은 구조를 만든다. 문제는 계층 하나로만 분류하려는 것이다.
- 폴더를 없애는 것은 답이 아니다. 폴더는 목차이고 생각의 체계다.
- 이름 붙은 영역(도메인·화면 구역)으로 먼저 나누고, 그 아래에서 계층을 쓴다. 애매한 경계는 "import가 없으면 원자"처럼 판단이 필요 없는 규칙으로 바꾼다.
- 이후 이 고민은 엔티티·위젯·기능 중심 구조로 이어진다(프론트엔드 폴더 구조의 진화).
관련 노트: 디자인 시스템: 구성, 도입, 구축과 배포, 프론트엔드 폴더 구조의 진화, 프론트엔드에서 관심사의 분리, 컴포넌트와 Props, 제품 언어로서의 디자인 시스템: 토큰, 기능과 형태, 컴포넌트 API