Storybook을 세팅했다고 디자인 시스템이 생기지는 않는다.

토큰을 정의했다고 일관성이 생기지도 않는다.

그렇다면 무엇이 있어야 디자인 시스템이라고 부를 수 있을까.

1. 문제 상황

소프트웨어가 커질수록 결정의 수가 늘어난다.

버튼의 색, 간격의 단위, 비활성 상태의 표현 방식. 이것들은 매번 새로 결정되어야 하는 것들이 아니다. 어딘가에서 이미 한 번 결정됐어야 하는 것들이다.

그런데 그 결정이 기록되지 않으면, 팀은 같은 결정을 반복하게 된다. 신입이 들어올 때마다, 새 페이지를 만들 때마다, 다른 플랫폼으로 확장할 때마다.

이것은 디자인의 문제가 아니다. 의사결정의 비효율 문제다.

2. 처음 하는 생각

대부분의 팀은 같은 착각에서 출발한다.

컴포넌트를 잘 만들어두면 일관성이 생길 거라는 것. Button.jsx, Input.jsx, Modal.jsx를 공용 폴더에 넣어두면 팀 전체가 같은 UI를 쓰게 될 거라는 것.

그런데 실제로는 반대 방향으로 흘러가는 경우가 많다. 컴포넌트가 늘어날수록 파편화가 심해진다.

왜 그럴까.

컴포넌트는 산출물이다. 시스템은 구조다. 산출물을 쌓는다고 구조가 생기지는 않는다.

Button.jsx가 열 개여도 “어떤 버튼을 언제 쓰는가”에 대한 기준이 없으면, 열 개의 버튼은 시스템이 아니라 선택지일 뿐이다.

3. 방법론들이 가리키는 곳

이 문제를 풀려는 시도들이 있었다. 각자 다른 층위를 건드렸지만, 방향은 같은 곳을 향하고 있었다.

Atomic Design (Brad Frost, 2013)

컴포넌트를 원자 → 분자 → 유기체 → 템플릿 → 페이지로 분해하는 방법론이다. 건드리려 한 문제는 “컴포넌트를 어떻게 쪼개고 조합할 것인가”였다.

이것이 가리키는 것: 구성의 원칙. UI는 임의로 만드는 게 아니라, 작은 단위로부터 조합된다는 사고방식.

다만 실제 도입 후 공통적으로 겪는 일이 있다. “이게 원자야, 분자야?”를 토론하다 정작 만들어야 할 것을 못 만드는 것. 분류가 목적이 아닌데 분류가 목적이 되어버린다.

디자인 토큰

색상, 간격, 타이포그래피를 변수로 추상화하는 방식이다. #3B82F6이 아니라 --color-action-primary. 어디에 쓰는 값인지를 이름에 담는다.

이것이 가리키는 것: 값의 단일 출처(single source of truth). 같은 값이 여러 곳에 흩어지지 않도록, 하나의 원천에서 파생되게 한다.

그런데 토큰은 값의 일관성은 보장하지만, 사용의 일관성은 보장하지 못한다. 올바른 토큰을 올바른 곳에 쓰는 것은 여전히 사람의 판단이다. 토큰이 있어도 누군가 --color-gray-200을 버튼 배경에 쓰면 그만이다.

Storybook

컴포넌트를 격리된 환경에서 개발하고 문서화하는 도구다. 각 컴포넌트가 어떤 상태를 가질 수 있는지, 어떤 props를 받는지를 보여준다.

이것이 가리키는 것: 살아있는 문서. 코드와 문서가 분리되지 않도록, 컴포넌트 자체가 명세가 되게 한다.

그런데 Storybook이 실제 컴포넌트와 동기화된 상태로 유지되는 팀은 많지 않다. 초반엔 열심히 올리다가, 어느 순간부터 스토리와 컴포넌트가 따로 논다. 도구가 있어도 그걸 유지하는 합의가 없으면 금방 죽는다.

세 방법론은 각자 다른 이름을 붙였지만, 같은 것을 향하고 있었다.

구성의 원칙, 단일 출처, 살아있는 문서. 이것들은 전부 하나의 질문에 대한 답이다.

“팀 안에 공유된 기준이 있는가?“

4. 도구로 풀리지 않는 것

방법론을 도입해도 디자인 시스템이 안 되는 팀이 있다.

Atomic Design을 적용했지만 컴포넌트는 여전히 제각각이고, 토큰을 정의했지만 누구도 그걸 참조하지 않고, Storybook을 세팅했지만 아무도 열지 않는다.

왜 그럴까.

도구는 결정을 담는 그릇이다. 담길 결정이 없으면 그릇은 비어 있다.

Storybook이 살아있으려면, 컴포넌트가 어떤 상태를 가져야 하는지에 대한 합의가 먼저 있어야 한다. 토큰이 쓰이려면, 어떤 맥락에 어떤 값을 쓰는지에 대한 합의가 먼저 있어야 한다.

도구의 문제가 아니다. 팀 안에 합의가 있는가의 문제다.

5. 디자인 시스템이란 결국 무엇인가

두 가지로 정의할 수 있을 것 같다.

하나는 합의의 결정체다. 디자인 시스템 안에 있는 모든 것 — 토큰, 컴포넌트, 문서 — 은 팀이 어느 시점에 나눈 대화와 결정이 굳어진 형태다. 버튼 하나에도 “이 색을 primary로 쓰기로 했다”는 합의가 담겨 있다.

다른 하나는 공유된 언어다. 디자이너가 말하는 “primary 버튼”과 개발자가 만드는 “primary 버튼”이 같은 것을 가리키는 상태. 팀이 같은 단어로 같은 것을 가리킬 수 있을 때, 비로소 소통의 비용이 줄어든다.

이 둘은 별개가 아니다.

합의가 쌓이면 언어가 된다. 언어가 생기면 더 빠른 합의가 가능해진다.

디자인 시스템은 그 순환이다.

Storybook도, 토큰도, Atomic Design도 그 순환을 만들기 위한 서로 다른 시도였다. 도구가 먼저가 아니라, 순환이 먼저다.

그러니까 “우리 디자인 시스템 있어요”라는 말을 들었을 때 확인해야 할 건 Storybook URL이 아니다.

팀 안에서 같은 단어로 같은 것을 가리키고 있는지, 그 합의가 어딘가에 살아있는지다.