Atomic Design — 기초, UI의 원자, 분자, 유기체

Atomic Design이란?

Atomic Design은 계층적 인터페이스 시스템을 생성하기 위한 방법론으로, 각 UI 요소는 5가지 레벨 중 하나에 속합니다: 원자(기본 요소), 분자(원자의 조합), 유기체(복잡한 블록), 템플릿(페이지 와이어프레임), 페이지(데이터가 있는 특정 화면). 이 비유는 화학에서 차용되었습니다: 원자가 결합하여 분자가 되고, 분자가 유기체가 되고, 유기체가 템플릿이 되고, 템플릿이 콘텐츠로 채워져 페이지가 됩니다.

이 방법론은 2013년 웹 디자이너 Brad Frost가 "페이지 사고"(기존 컴포넌트를 고려하지 않고 각 새 화면을 처음부터 디자인하는 방식)의 문제에 대한 대응으로 제안했습니다. "Atomic Design"(2016) 책에서 Frost는 대기업(IBM, GE, Starbucks) 프로젝트에서의 방법론 구현을 설명합니다. Nielsen Norman Group(2022)에 따르면, Atomic Design은 기성 컴포넌트의 재사용을 통해 새 화면 디자인 시간을 30~50% 단축합니다.

Atomic Design은 기술이라기보다 UI 조직의 철학입니다. 특정 프레임워크에 얽매이지 않으며 웹(React, Vue)과 모바일 개발(Jetpack Compose, SwiftUI) 모두에 적용 가능합니다. IT Sectr에서는 고객의 디자인 시스템을 구축하기 위해 Atomic Design을 사용합니다: 디자인 단계에서 원자 컴포넌트를 식별하고 이를 Compose/SwiftUI의 코드 컴포넌트로 전환합니다.

5가지 레벨: 원자, 분자, 유기체, 템플릿, 페이지

Atomic Design의 각 레벨은 고유한 문제를 해결하며 엄격한 책임 영역을 가집니다. 원자는 의미를 잃지 않고 더 이상 분해할 수 없는 인터페이스의 가장 작은 구성 요소입니다: 버튼, 텍스트 필드, 아이콘, 레이블, 체크박스. 원자에는 비즈니스 로직이 없으며 컨텍스트에 의존하지 않습니다. 색상, 크기, 간격, 타이포그래피와 같은 기본적인 시각적 특성을 정의합니다.

분자는 두 개 이상의 원자가 결합하여 단순한 기능 단위를 형성하는 것입니다. 레이블과 오류 메시지가 있는 입력 필드는 분자입니다. 이미지, 이름, 가격이 있는 상품 카드는 분자입니다. 분자는 기본 로직(오류 표시/숨기기)을 포함할 수 있지만 비즈니스 프로세스는 포함하지 않습니다. 분자는 컴포넌트가 다른 화면에서 재사용 가능해지는 첫 번째 레벨입니다.

유기체는 분자와 원자로 구성된 복잡한 인터페이스 블록으로, 애플리케이션의 특정 기능을 구현합니다. 로그인 폼(이메일 필드, 비밀번호 필드, 제출 버튼, "비밀번호 찾기" 링크)은 유기체입니다. 로고, 검색, 탐색이 있는 헤더는 유기체입니다. 유기체는 비즈니스 로직을 포함하고 API에 접근할 수 있지만, 자신의 기능 범위 내에서만 가능합니다.

템플릿은 특정 콘텐츠 없이 화면에서 유기체의 배치를 정의하는 페이지 와이어프레임입니다. 템플릿은 그리드, 열, 콘텐츠 영역을 정의합니다 — 코드 수준의 와이어프레임입니다. 템플릿에는 데이터가 없고 플레이스홀더만 있습니다. 콘텐츠를 채우기 전에 페이지 구조를 평가할 수 있습니다.

페이지는 템플릿이 실제 데이터로 채워진 특정 애플리케이션 화면입니다. 이 레벨에서는 실제 콘텐츠(긴 문자열, 데이터 누락, 오류)로 컴포넌트가 어떻게 보이는지 확인합니다. 페이지는 최종 사용자가 보는 유일한 레벨입니다. 페이지 레벨의 변경은 원자, 분자, 유기체에 영향을 주지 않아야 합니다 — 컴포넌트를 변경해야 하는 경우 해당 레벨에서 변경이 이루어지며 페이지가 자동으로 반영합니다.

Atomic Design의 장점과 한계

장점 — Atomic Design의 장점은 인터페이스를 확장할 때 명확해집니다. 단일 컴포넌트 라이브러리는 시각적 일관성을 보장합니다: 버튼은 동일한 원자이므로 모든 화면에서 동일하게 보입니다. Brad Frost(2016)에 따르면, Atomic Design을 구현한 기업은 기성 분자와 유기체의 재사용을 통해 새 화면 개발 시간을 30~50% 단축합니다.

한계 — Atomic Design은 애플리케이션 상태 관리 방법을 설명하지 않습니다. 이 방법론은 "UI 컴포넌트를 어떻게 구성할 것인가"라는 질문에만 답할 뿐 비즈니스 로직, 라우팅, 데이터 관리는 다루지 않습니다. 두 번째 한계는 경계 정의의 어려움입니다: 분자는 어디서 끝나고 유기체는 어디서 시작되나요? 실제로 경계는 모호하며 다른 팀이 동일한 컴포넌트를 다르게 분류할 수 있습니다. 디자인 토큰과 컴포넌트 카탈로그(Storybook, Jetpack Compose Preview)에 규칙을 설정하는 것이 좋습니다.

세 번째 한계는 소규모 프로젝트에 대한 과도한 추상화입니다. 애플리케이션이 5개 화면으로 구성된 경우 원자와 분자의 계층 구조를 만드는 것은 불필요한 작업입니다. Atomic Design은 화면 수가 20개를 초과하고 컴포넌트가 다른 페이지에서 재사용될 때 유용해집니다.

Atomic Design vs Feature-Sliced Design

Atomic Design과 Feature-Sliced Design(FSD)은 다른 문제를 해결하며 함께 사용할 수 있습니다. Atomic Design은 UI 컴포넌트를 구성하기 위한 방법론이고, FSD는 비즈니스 레이어와 애플리케이션 전체를 구성하기 위한 방법론입니다. Atomic Design은 "UI를 재사용 가능한 부분으로 나누는 방법"이라는 질문에 답하고, FSD는 "비즈니스 기능을 중심으로 코드를 구성하는 방법"이라는 질문에 답합니다. 이들은 경쟁하지 않습니다: features와 entities 레이어가 있는 FSD 구조를 가지고 각 레이어 내에서 Atomic Design을 사용하여 UI 컴포넌트를 구성할 수 있습니다.

일반적인 조합: FSD가 애플리케이션의 모듈 구조(레이어, 슬라이스)를 정의하고, Atomic Design이 각 슬라이스 내에서 UI 컴포넌트의 내부 구조를 정의합니다. 예를 들어, feature.auth 슬라이스는 Atomic Design 규칙에 따라 조립된 분자(LoginForm, PasswordInput)와 유기체(AuthPage)를 포함합니다. 공유 레이어는 모든 기능에서 재사용되는 원자(Button, Input, Label)를 포함합니다.

모바일 애플리케이션의 Atomic Design: Compose와 SwiftUI

Jetpack Compose와 SwiftUI는 컴포넌트 구성을 통해 Atomic Design 계층을 자연스럽게 지원합니다. 원자는 Compose에서 기본 @Composable 함수입니다: AppButton, AppTextField, AppCheckbox. 각 함수는 사용자 정의 매개변수(색상, 크기, 상태)를 받으며 비즈니스 로직을 포함하지 않습니다. 원자는 공유 레이어에서 정의되고 UI 키트로 내보내집니다.

분자는 여러 원자를 결합하는 @Composable 함수입니다: LabeledTextField(레이블 + 입력 필드 + 오류 메시지), ProductCard(이미지 + 이름 + 가격). 분자는 기본 상태(필드 유효성)를 포함할 수 있지만 API나 ViewModel에 접근하지 않습니다. 다양한 유기체에서 재사용됩니다.

유기체는 기능 레벨의 @Composable 함수입니다: LoginForm(이메일용 LabeledTextField + 비밀번호용 LabeledTextField + 제출 AppButton + 복구 링크). 유기체는 Intent 함수를 통해 ViewModel과 작동하며 비즈니스 로직을 포함할 수 있습니다. SwiftUI에서는 @ViewBuilder와 사용자 정의 View 구조체를 통해 유사한 계층이 구축됩니다.

SwiftUI에서 원자는 사용자 정의 View 구조체 AppButton이고, 분자는 HStack의 레이블이 있는 입력 필드이며, 유기체는 로그인 폼입니다. 이 구조는 모든 화면에서 컴포넌트를 재사용할 수 있게 합니다 — 원자(버튼 색상)를 변경하면 자동으로 모든 화면에 적용됩니다. Atomic Design과 디자인 시스템의 결합은 각 화면을 수동으로 제어하지 않고도 인터페이스 일관성을 보장합니다.