디자인 시스템의 세 축, 하나라도 빠지면

"일단 버튼부터 만들죠."

팀에서 디자인 시스템 얘기가 나오면 거의 이렇게 시작해요. 저도 그랬거든요. 버튼 하나 만들고, 인풋 하나 만들고, 얼추 공통 컴포넌트 폴더에 밀어 넣으면 시스템이 되는 줄 알았어요.

6개월 뒤 광경은 매번 비슷합니다. Button, PrimaryButton, ButtonV2, NewButton이 공존하고, 팔레트에는 파란색만 네 가지가 있고, 아무도 어떤 회색을 써야 하는지 몰라요. 코드는 쌓였는데 화면의 일관성은 오히려 나빠졌죠.

원인은 컴포넌트가 부족해서가 아니에요. 컴포넌트부터 만들었기 때문이에요. 디자인 시스템은 버튼 하나를 갈아 끼우는 일이 아니라, 세 개의 축을 동시에 정렬하는 일이거든요. 토큰, 컴포넌트 계층, 팀 운영 모델. 하나라도 빠지면 시스템은 오너 없는 CSS 모음집으로 퇴화해요.

축 1. 디자인 토큰

색·간격·타이포를 '값'이 아니라 '의사결정'으로 관리하는 계약이에요.

축 2. 컴포넌트 계층

부분과 전체를 오가는 사고 모델이에요. 엄격한 분류 체계가 아니고요.

축 3. 팀 운영 모델

누가 주인이고, 누가 리뷰하고, 누가 고치는지를 정하는 거예요.

축 1. 디자인 토큰, 값이 아니라 의사결정

토큰을 "파란색 #3b82f6이라는 값"으로 이해하면 절반만 맞아요. 토큰의 본질은 "우리는 primary를 이 파란색으로 쓰기로 정했다"는 의사결정 자체입니다. 값은 언제든 바뀔 수 있지만, 결정은 팀의 계약이에요.

이런 계약을 표준 포맷으로 나누자는 취지에서 W3C 산하 Design Tokens Community Group이 만들어졌어요. 색·타이포·간격은 브랜드 테마와 다크 모드, 플랫폼(iOS·안드로이드·웹)에 따라 다르게 변주되죠. 값이 다르더라도 "같은 결정"임을 알아볼 수 있어야 해요. 그래서 W3C 포맷은 $value·$type, 다른 토큰을 가리키는 별칭(alias), 테마 레이어, Oklch 같은 현대적 색 표현까지 염두에 두고 있어요.

{
  "color": {
    "brand": {
      "blue-500": { "$value": "oklch(62% 0.19 255)", "$type": "color" }
    },
    "primary": { "$value": "{color.brand.blue-500}", "$type": "color" },
    "surface": { "$value": "oklch(98% 0 0)", "$type": "color" }
  },
  "spacing": {
    "md": { "$value": "16px", "$type": "dimension" }
  }
}

여기서 핵심은 primary가 brand.blue-500을 가리킨다는 점이에요. 리브랜딩이 오면 원시 값 하나만 바꾸고 primary의 의미는 그대로 두면 돼요. 그래서 토큰은 값이 아니라 결정이에요.

토큰이 없으면 스타일링 기술을 아무리 잘 골라도 소용이 없습니다. Tailwind든 CSS-in-JS든, 값이 유한해야 가드레일이 되거든요. 이 지점은 이전 글 스타일링, 취향이 아니라 기준에서 다뤘어요. 거기서 선택의 핵심축은 "디자인 토큰이 이미 있는가"였죠. 토큰이 빠진 팀의 스타일링 논쟁은 매번 원점으로 돌아가요.

토큰 추출을 시작할 때 "쓸 값"보다 "안 쓰기로 한 값"을 먼저 정리하는 게 더 효과적이에요. 회색 다섯 종류를 세 종류로 줄이는 그 결정이 곧 토큰이거든요.

축 2. 컴포넌트 계층, Atomic Design에서 살릴 것만

Brad Frost가 Atomic Design에서 정리한 다섯 단계는 이제 프런트엔드 상식이 됐죠. atoms는 버튼·인풋 같은 최소 단위, molecules는 그것들이 모인 폼 필드, organisms는 molecules가 모여 의미를 갖는 헤더·카드, templates는 페이지 골격, pages는 실제 데이터가 얹힌 화면이에요.

근데 이 계층이 팀에 도입되자마자 벌어지는 일이 있어요. "이 검색바가 molecule이야 organism이야?"를 두고 PR에서 싸우는 거예요. 본 적 있다면 고개가 끄덕여질 거예요.

Brad Frost는 원문에서 이 논쟁을 정면으로 잘라요. Atomic Design은 **"엄격한 분류 체계가 아니라 부분과 전체를 오가며 사고하는 비선형적 정신 모델"**이라고요. 분류 자체가 목적이 아니라, 큰 화면과 작은 단위를 동시에 보게 만드는 사고 보조 도구라는 뜻이에요.

실무에서 이 말이 주는 교훈은 간단합니다. 계층은 문서 사이트 카테고리 정도로만 쓰고, 팀은 평소에 "버튼, 인풋, 카드, 모달" 같은 이름으로 부르면 돼요. components/molecules/ 같은 폴더 구조에 강박 가질 필요 없어요. 분류는 지도일 뿐 지형이 아니거든요.

"이 컴포넌트가 atom이냐 molecule이냐"로 PR 코멘트가 3개 넘어가면, 그건 시스템이 아니라 분류 체계에 팀 에너지가 빠지고 있다는 신호예요.

축 3. 팀 운영 모델, 누가 주인인가

세 번째 축은 코드가 아니라 사람에 관한 거예요. Nathan Curtis는 "Team Models for Scaling a Design System"에서 디자인 시스템 운영 방식을 세 가지로 분류합니다.

Solitary 모델

한 팀이 자기 제품 필요로 시스템을 만들고, 다른 팀이 가져다 쓰는 구조예요. 초기 비용이 낮고 시작이 빠르지만, 주인 팀의 우선순위에 나머지가 종속되죠.

Centralized 모델

디자인 시스템 전담팀을 두고 전 제품이 공용으로 쓰는 구조예요. 일관성은 가장 강하지만, 전담팀이 실제 제품 맥락에서 멀어지면 '누구도 안 쓰는 완벽한 시스템'이 나오기 쉬워요.

Federated 모델

여러 제품팀 대표가 모여 함께 결정하는 구조예요. 대표성은 가장 크지만 합의 속도가 느리고 운영 오버헤드가 커요.

Nathan Curtis는 조직 규모에 따른 권고를 분명히 남겨요. 초기 스타트업에는 Solitary, 중견 기업에는 Centralized, 대규모의 성숙한 조직에는 Federated가 자연스럽다고요. "전담팀을 꾸려 Centralized로 가는 게 정답"이라는 업계 통념은 조직 규모를 무시한 단순화예요.

저도 10명 남짓한 팀에서 처음부터 전담 조직을 만들자고 했다가, 결국 아무도 본업을 내려놓지 못해서 흐지부지된 적 있어요. 그때 Solitary부터 시작했더라면 훨씬 나았을 거예요.

팀 모델을 정하지 않으면 토큰과 컴포넌트가 아무리 예뻐도 6개월 뒤 방치돼요. PR을 누가 리뷰하는지, 토큰을 누가 추가하는지, 깨진 토큰을 누가 고치는지가 정해지지 않은 저장소는 오너 없는 코드가 되거든요.

현실적인 시작 순서

세 축을 동시에 세우라는 말이 "처음부터 완벽하게 설계하라"는 뜻은 아니에요. 기존 프로젝트에 얹는다면 순서는 대체로 이렇습니다.

토큰 추출

지금 코드에서 쓰이는 색·간격·타이포를 기계적으로 뽑아 카운트하세요. 상위 5~10개만 남기고 primary, surface, spacing.md 같은 이름을 붙이면 돼요. '쓰지 않기로 한 값'을 함께 정리하는 게 더 중요해요.

토큰 위에 핵심 컴포넌트 3~5개

버튼, 인풋, 카드, 모달 정도면 충분해요. 규칙은 하나예요. 이 컴포넌트는 오직 토큰만 참조하고, 원시 값은 금지입니다.

팀 모델 합의

이 저장소의 주인이 누구인지, 토큰을 추가하려면 누구의 승인이 필요한지, 버그는 어디에 리포트하는지를 문서화하세요. 이 합의 없이 컴포넌트만 만들면 저장소는 누구의 것도 아닌 채로 썩어요.

문서 사이트

Storybook이든 간단한 MDX 페이지든 상관없어요. '지금 쓸 수 있는 것'의 목록이 반드시 한곳에 있어야 해요.

서론의 "버튼부터 만들지 마라"는 이 순서로 다시 쓸 수 있어요. 토큰 없는 컴포넌트부터 만들지 마세요. 토큰 위에 얹은 컴포넌트는 시스템이지만, 토큰 없는 컴포넌트는 CSS 모음집이에요. 둘의 차이는 파일 수가 아니라 결정의 공유 여부에서 나와요.

디자인 시스템은 빈 제품 위에 먼저 지어 올리는 게 아닙니다. 제품에서 이미 반복되는 것, 팀이 암묵적으로 합의해둔 것을 토큰과 컴포넌트라는 이름으로 회수하는 일이에요. 회수할 게 없다면 시스템도 필요 없어요. 회수할 게 쌓이고 있다면, 지금이 세 축을 세울 때예요.