03 — Atomic Design vs Tokens-first

Atomic Design은 컴포넌트의 수직적 분류학(Atoms → Molecules → Organisms → Templates → Pages)이고, Tokens-first는 값의 수평적 정규화(Primitive → Semantic → Component)다. 둘은 경쟁하는 것처럼 보이지만 사실 다른 축이다. 현대 디자인 시스템은 둘을 종합하며, Atomic의 5계층을 Tokens-first의 3계층이 관통한다. 어느 한 쪽만 채택하면 6개월 안에 반대편을 재발명하게 된다.

Why — 왜 비교가 필요한가

신규 디자인 시스템 프로젝트의 첫 의사결정은 거의 항상 어떤 사고법을 따를 것인가다. 이 결정이 6개월 뒤 모든 디렉터리 구조와 토큰 이름을 결정한다.

이 챕터는 두 사고법의 진짜 주장을 명확히 하고, 어느 부분이 동시에 참인지를 보여준다.

How — 두 사고법의 핵심 메커니즘

Atomic Design (Brad Frost, 2013)

Brad Frost의 출발점은 “웹 디자인이 페이지 단위로 끝없이 반복되는 것을 멈추자” 였다. 그의 해법은 화학에서 빌린 비유:

핵심 주장: 디자인은 컴포넌트의 조합이고, 작은 부품(Atom)에서 큰 부품(Page)으로 층 쌓기해야 한다. 한 Atom을 고치면 그것을 포함한 모든 Molecule·Organism이 자동으로 갱신된다.

강점:

• 디자이너에게 직관적. Figma의 nested components와 자연스럽게 맞물림.
• 컴포넌트 재사용성이 시각적으로 명확.
• 새 페이지 만들 때 “어떤 Organism이 필요한가”부터 출발 → 일관성 확보.

약점:

• *값(색·간격)*은 어디에 두는지 침묵. Atom 안에 hex가 박혀버리는 경향.
• “Molecule인가 Organism인가” — 분류가 끝없는 논쟁. SearchBox + 결과 dropdown은 Molecule? Organism?
• 다크모드·멀티 브랜드가 등장하면 Atom마다 분기 코드.

Tokens-first (Salesforce Lightning, 2014)

Jina Anne의 출발점은 정반대다 — “우리는 수천 개의 hex 코드를 갖고 있고, 어느 게 brand blue인지 아무도 모른다.” 해법:

핵심 주장: 디자인은 값의 합의다. 같은 값에 이름을 주고, 컴포넌트는 그 이름만 참조한다. 어떤 컴포넌트인지는 부차적.

강점:

• 값을 한 번에 바꾸면 전체가 따라옴 — 다크모드, 리브랜딩이 거의 무료.
• 다중 플랫폼(웹·iOS·Android) 동기화가 자연스러움 (Style Dictionary).
• W3C DTCG로 표준화됨 (2019~).

약점:

• 컴포넌트의 시각적 계층에 침묵. “Button과 IconButton이 형제인지 부모-자식인지” 토큰만으론 안 보임.
• 디자이너에게 덜 직관적. Figma에서 토큰만 보면 “내 디자인의 전체 구조”가 안 보임.
• 컴포넌트 라이브러리의 폴더 구조에 대한 가이드 없음.

What — 두 사고법의 비교

직접 비교 표

충돌 vs 종합 — 어느 부분이 사실 같은가

두 사고법은 축이 다르기 때문에 충돌이 아니라 교차한다:

현실의 컴포넌트 코드 — 두 축이 동시에 작용한다:

// Button.tsx (Atomic의 'Atom')
import { button } from './recipes'  // Tokens-first의 'Component-level token' 묶음
 
<button className={button({ intent: 'primary' })} />
 
// recipes/button.ts
import { cva } from 'styled-system/css'
export const button = cva({
  base: {
    px: 'space.3',        // Semantic token
    bg: 'primary.default', // Semantic token
  },
})
 
// tokens.json
{
  "space": { "3": { "$value": "12px" } },        // Primitive
  "primary": { "default": { "$value": "{color.blue.500}" } }, // Semantic
  "color": { "blue": { "500": { "$value": "#3370b8" } } }      // Primitive
}

이 한 컴포넌트 안에 Atomic의 Atom과 Tokens-first의 3계층이 동시에 살아 있다.

현대 디자인 시스템의 종합

관찰: 가장 성공적인 디자인 시스템들은 모두 Atomic Design의 어휘는 버렸지만 컴포넌트 폴더의 점진적 조립 사고는 유지한다. 반면 Tokens-first는 어휘 그대로 1급 시민이다.

What-if — 한쪽만 채택했을 때의 실패 모드

1) Atomic만 채택 → “Atom에 hex가 박힌 컴포넌트”

// 잘못된 Atom
const Button = styled.button`
  background: #3370b8;   /* 토큰 없음 */
  padding: 12px 16px;    /* 값 박힘 */
`

• 증상: 1년 뒤 디자이너가 “primary 색 살짝 조정”을 요청 → Button·IconButton·LinkButton·FAB 모두 손봐야 함.
• 원인: Tokens layer 부재. 값의 단일 출처가 없음.
• 대응: 토큰을 지금 도입. tokens.json 만들고 Atom들이 토큰을 참조하도록 리팩토링.

2) Tokens만 채택 → “토큰은 우아한데 컴포넌트가 미궁”

• 증상: tokens.json은 깔끔, 하지만 components/ 폴더에 80개 컴포넌트가 평면으로 흩뿌려짐. 새 디자이너가 “Tag와 Badge의 차이”를 모름.
• 원인: 컴포넌트의 계층 구조에 대한 가이드 부재.
• 대응: 폴더를 역할별로 그룹화 (components/primitives/, components/composites/, components/patterns/). Atomic의 어휘를 안 써도, 조립의 위계는 살려야 한다.

3) Atomic Design의 “Molecule인가 Organism인가” 논쟁 무한 반복

• 증상: PR마다 “이건 Molecule이지 Organism이 아니다” 같은 토론에 30분.
• 원인: Atomic Design의 분류가 의미상 모호함. SearchBox는 Molecule? Organism? 정답이 없다.
• 대응: 분류를 2단계로 단순화 — primitives/(작은 부품) vs composites/(조립된 것). 이름을 바꾸면 논쟁이 가라앉는다.

4) Tokens-first의 “Component 토큰 폭발”

• 증상: button.primary.hover.bg, button.primary.active.bg, button.primary.disabled.bg, button.danger.hover.bg… 토큰 1,000개.
• 원인: 모든 상태·variant마다 별도 토큰을 만들려 함.
• 대응: Component-level 토큰은 극단적으로 줄이고, hover/active는 color-mix() 또는 opacity 변경으로 파생. Semantic 토큰까지만 ~50개 수준 유지.

5) 두 사고법을 둘 다 무시 → “느낌대로 디자인 시스템”

• 증상: 컴포넌트 폴더 구조도, 토큰 구조도 모두 임의. 새 개발자가 들어오면 모든 결정의 근거 없음을 발견.
• 원인: 디자인 시스템 팀의 교육 부재. 가장 흔한 실패.
• 대응: 이 챕터 읽기. 그리고 둘 다 채택 — Atomic의 폴더 직관 + Tokens-first의 값 정규화.

Insight — Brad Frost가 2023년에 했던 자기 비판

“Atomic Design은 2013년에는 옳았지만, 토큰을 충분히 다루지 못했다.”

2023년 Smashing Magazine 인터뷰에서 Brad Frost는 직접 인정했다 — Atomic Design 1판은 컴포넌트의 분류에만 집중했고, 값의 관리는 침묵했다. 그가 2023년에 Atomic Design 2판을 쓴다면 Tokens를 별도 chapter로 깔았을 것이라고 말했다. 이 자기 비판이 흥미로운 이유는, 방법론의 한계는 발명자 본인이 가장 먼저 본다는 것이다.

또 하나, Jina Anne은 Brad Frost를 좋아한다. 2014년 Jina가 Salesforce에서 토큰 개념을 발표할 때, 그녀는 명시적으로 “이건 Atomic Design을 보완하는 것이지 대체하는 게 아니다” 라고 말했다. 두 사고법의 경쟁 서사는 외부에서 만들어진 것이지 발명자들의 의도가 아니었다.

가장 흥미로운 사실 — 2024년 State of Design Systems 설문(약 2,800명 응답)에서 “Atomic Design 어휘를 적극 사용한다” 응답은 18%로 떨어진 반면, “디자인 토큰을 최소 1계층 이상 운용” 응답은 71%다. Atomic은 어휘로서 시들고 있지만 발상으로서 살아남았다(점진적 조립). 반면 Tokens-first는 어휘와 발상 모두 시장을 차지했다. 이게 W3C DTCG가 2023년 Editor’s Draft까지 진행된 시장 압력이다.

마지막으로 — 이 종합은 누가 처음 그렸나? 명시적으로 그린 사람은 없다. 그러나 Storybook의 Component Story Format 3.0(2022)이 사실상 종합을 인코딩했다 — args로 토큰을 주입받고, *.stories.tsx가 컴포넌트의 계층을 표현한다. 도구가 합의를 인코딩하면 사람들은 그 합의를 받아들인다 — 이게 디자인 시스템의 진화 방식이다.

요약 + Mermaid

• Atomic Design = 수직 (작은 컴포넌트 → 큰 컴포넌트).
• Tokens-first = 수평 (Primitive → Semantic → Component 토큰).
• 두 축은 경쟁이 아니라 교차한다. 한 컴포넌트 코드에 둘 다 살아 있다.
• 한쪽만 채택한 디자인 시스템은 6개월 안에 반대편을 재발명한다.
• 어휘는 Tokens-first가, 폴더 구조의 직관은 Atomic이 살아남았다.