디자인 토큰 거버넌스: 색상·간격·타이포그래피를 제품 규모에서 유지하는 방법
토큰은 변수 파일이 아니라 의사결정 체계다
디자인 시스템을 만들 때 색상, 간격, 폰트 크기를 변수로 분리하는 일은 비교적 쉽습니다. 어려운 부분은 시간이 지나도 그 값들이 일관된 의미를 유지하게 만드는 것입니다. 프로젝트가 커지면 임시 색상, 예외 spacing, 화면 전용 font-size가 조금씩 늘어납니다. 처음에는 빠른 해결처럼 보이지만 몇 달 뒤에는 어떤 값이 제품 표준인지, 어떤 값이 실험 잔재인지 알기 어렵게 됩니다.
디자인 토큰 거버넌스는 토큰을 추가하고 변경하고 제거하는 기준을 정하는 일입니다. 디자이너와 개발자가 같은 이름을 쓰고, 같은 의미로 이해하며, 제품 변경이 코드와 디자인 파일에 안정적으로 반영되도록 만드는 운영 방식입니다. 토큰은 단순한 상수가 아니라 제품 UI 언어의 계약입니다.
1. 원시 값과 의미 토큰을 분리한다
토큰을 잘 관리하려면 원시 값과 의미 토큰을 구분해야 합니다. 원시 값은 blue-500, spacing-4, font-16처럼 팔레트와 스케일의 기본 재료입니다. 의미 토큰은 color-action-primary, color-surface-muted, space-card-padding, font-body-md처럼 UI에서의 역할을 표현합니다. 컴포넌트는 가능하면 의미 토큰을 사용해야 합니다.
이 분리가 없으면 브랜드 색상이 바뀔 때 모든 컴포넌트를 뒤져야 합니다. 반대로 의미 토큰이 있으면 primary action의 색상만 재매핑할 수 있습니다. 다크 모드, 고대비 모드, 브랜드 테마도 같은 구조에서 처리하기 쉬워집니다. 원시 값은 디자인 언어의 재료이고, 의미 토큰은 제품 의도입니다.
의미 토큰 이름은 추상적이되 모호하지 않아야 합니다. blue-button은 색상과 컴포넌트가 섞여 확장성이 낮고, nice-color는 의미가 없습니다. color-button-primary-bg, color-button-primary-fg, color-border-danger처럼 역할과 상태가 드러나는 이름이 낫습니다. 이름이 길어져도 의도가 명확하면 유지보수 비용이 줄어듭니다.
2. 토큰 추가에는 기준이 필요하다
새 토큰은 "한 화면에서 필요하다"는 이유만으로 추가하면 안 됩니다. 기존 토큰으로 표현할 수 없는 새로운 의미인지, 여러 컴포넌트에서 재사용될 가능성이 있는지, 접근성 대비 기준을 만족하는지 확인해야 합니다. 단발성 예외는 컴포넌트 내부 값으로 둘 수도 있지만, 반복되는 패턴이라면 토큰으로 승격합니다.
토큰 제안 과정은 가벼워야 합니다. 무거운 승인 절차는 사람들이 우회 값을 만들게 합니다. 대신 제안 템플릿에 사용 사례, 대체 가능한 기존 토큰, 접근성 검증, 예상 적용 범위를 적게 하면 충분합니다. 디자인 리뷰와 코드 리뷰에서 같은 기준으로 판단할 수 있어야 합니다.
변경은 추가보다 더 조심해야 합니다. 토큰 값 하나가 수십 개 화면에 영향을 줄 수 있기 때문입니다. 변경 PR에는 시각 diff, 영향 컴포넌트 목록, 마이그레이션 계획이 포함되어야 합니다. 큰 변경은 deprecated 토큰을 두고 점진적으로 교체합니다. 바로 삭제하면 제품 곳곳에서 예기치 않은 회귀가 생깁니다.
3. 코드와 디자인 파일의 동기화가 핵심이다
디자인 토큰은 Figma와 코드가 다르면 신뢰를 잃습니다. 디자이너가 쓰는 토큰과 개발자가 import하는 토큰이 다른 이름이나 다른 값을 갖는 순간, 시스템은 문서가 아니라 추측에 의존하게 됩니다. 가능한 한 단일 소스에서 토큰을 생성하고, CSS 변수, TypeScript 객체, JSON, 디자인 도구 입력 포맷으로 변환하는 파이프라인을 둡니다.
토큰 빌드 산출물은 사람이 직접 수정하지 않게 해야 합니다. 원본 토큰 파일만 리뷰하고, 생성된 파일은 자동화로 갱신합니다. 이렇게 하면 값이 어긋나는 일을 줄일 수 있습니다. CI에서는 토큰 빌드 결과가 최신인지, 중복 이름이 없는지, 필수 테마가 모두 같은 토큰 키를 갖는지 검사합니다.
문서도 자동 생성할 수 있습니다. 색상 swatch, spacing scale, typography sample, 사용 예시를 토큰 소스에서 만들어내면 문서가 오래되지 않습니다. 다만 문서는 값 목록만 보여주면 부족합니다. 언제 어떤 의미 토큰을 써야 하는지, 사용하면 안 되는 조합은 무엇인지, 접근성 대비가 필요한 배경은 무엇인지 함께 적어야 합니다.
4. 제거와 정리가 거버넌스의 절반이다
토큰은 추가보다 제거가 어렵습니다. 오래된 캠페인, 종료된 실험, 더 이상 쓰지 않는 컴포넌트가 토큰을 붙잡고 있을 수 있습니다. 그래서 사용량 추적이 필요합니다. 코드 검색, stylelint rule, 디자인 파일 감사, Storybook 컴포넌트 메타데이터를 활용해 토큰 참조를 주기적으로 확인합니다.
deprecated 토큰에는 대체 토큰과 제거 예정 버전을 명시합니다. 코드에서는 lint warning을 띄우고, 새 코드에서 사용하지 못하게 막습니다. 기존 사용처는 작은 PR로 나눠 교체합니다. 한 번에 모두 바꾸면 회귀 확인이 어렵습니다. 특히 색상 토큰은 시각적 영향이 크므로 screenshot diff를 함께 보는 편이 좋습니다.
거버넌스는 도구만으로 해결되지 않습니다. 팀이 예외를 어떻게 처리할지 합의해야 합니다. 제품 특성상 일회성 마케팅 페이지나 외부 임베드 화면에는 시스템 밖 값이 필요할 수 있습니다. 중요한 것은 예외를 금지하는 것이 아니라, 예외임을 표시하고 수명을 관리하는 것입니다. 예외가 표준처럼 퍼지는 순간 디자인 시스템은 약해집니다.
5. 접근성 기준은 토큰 단계에서 강제한다
색상 토큰은 미적인 선택이면서 접근성 계약입니다. 버튼 배경과 텍스트, 오류 메시지와 배경, 비활성 상태와 주변 UI의 대비가 기준을 만족하지 않으면 컴포넌트마다 뒤늦게 보정해야 합니다. 그래서 색상 토큰을 만들 때부터 대비 조합을 함께 정의하는 편이 좋습니다. color-button-primary-bg와 color-button-primary-fg처럼 쌍으로 쓰이는 토큰은 단독 값이 아니라 조합으로 검증해야 합니다.
다크 모드에서는 같은 이름의 의미 토큰이 다른 원시 값으로 매핑됩니다. 이때 단순히 밝기만 반전하면 위험합니다. 그림자, border, focus ring, disabled 상태, skeleton 배경처럼 미묘한 요소가 다크 모드에서 사라질 수 있습니다. 테마별 토큰은 모든 상태를 같은 키로 제공하고, 누락된 키가 있으면 빌드가 실패하게 만드는 것이 안전합니다.
타이포그래피 토큰도 접근성과 연결됩니다. 본문 글자 크기, 줄 높이, 제목 계층, 버튼 텍스트 크기가 임의로 흔들리면 읽기 경험이 나빠집니다. 특히 한국어와 영어가 섞인 기술 블로그나 SaaS 화면에서는 긴 영문 식별자와 한글 문장이 함께 들어갑니다. 토큰은 실제 콘텐츠 길이를 기준으로 검증해야 합니다. 샘플 문구만 예쁜 토큰은 제품 화면에서 쉽게 무너집니다.
6. 컴포넌트 토큰은 너무 빨리 만들지 않는다
모든 컴포넌트에 전용 토큰을 만들면 시스템이 복잡해집니다. button-primary-bg, card-border, modal-title-font처럼 컴포넌트 토큰은 명확한 장점이 있지만, 초기에 과도하게 늘리면 실제로는 같은 의미의 값이 여러 이름으로 복제됩니다. 먼저 의미 토큰을 충분히 사용하고, 컴포넌트가 독립적인 테마나 상태 조합을 필요로 할 때 컴포넌트 토큰으로 승격하는 편이 낫습니다.
컴포넌트 토큰이 필요한 대표 사례는 브랜드 테마, 제품군별 스킨, 외부 임베드, 고대비 모드입니다. 같은 Button 컴포넌트라도 관리자 도구와 공개 랜딩 페이지에서 역할이 다르다면 컴포넌트 토큰이 유용합니다. 반대로 단순히 한 화면에서 카드 padding을 조금 줄이고 싶다는 이유라면 layout prop이나 container query로 해결하는 편이 더 단순할 수 있습니다.
토큰 계층은 문서화되어야 합니다. 원시 토큰은 직접 사용 금지, 의미 토큰은 일반 제품 UI에서 사용, 컴포넌트 토큰은 해당 컴포넌트 내부에서만 사용처럼 규칙을 정합니다. lint rule로 원시 색상값이나 금지된 토큰 사용을 막으면 리뷰 부담이 줄어듭니다. 도구가 규칙을 지켜줄수록 리뷰는 더 중요한 제품 판단에 집중할 수 있습니다.
7. 변경 영향은 시각 회귀로 확인한다
토큰 변경은 작은 diff처럼 보여도 제품 전체에 넓게 퍼집니다. space-4를 16px에서 14px로 바꾸면 카드, 폼, 모달, 테이블, 내비게이션이 모두 달라질 수 있습니다. 코드 리뷰만으로는 이 영향을 판단하기 어렵습니다. Storybook, Playwright screenshot, Percy 같은 시각 회귀 도구를 활용해 대표 컴포넌트와 핵심 화면을 비교해야 합니다.
시각 회귀 기준은 너무 넓어도 문제입니다. 모든 픽셀 차이를 실패로 보면 폰트 렌더링과 OS 차이 때문에 잡음이 늘어납니다. 대신 토큰 변경 PR에서는 영향이 예상되는 컴포넌트 세트를 명확히 선택하고, 차이를 사람이 검토할 수 있게 합니다. 색상과 간격 변경은 before/after 캡처가 가장 빠른 커뮤니케이션 수단입니다.
릴리스 노트도 중요합니다. 토큰 변경이 디자인 시스템 패키지 버전으로 배포된다면 어떤 토큰이 추가·변경·폐기되었는지, 소비 프로젝트가 해야 할 작업은 무엇인지 기록합니다. 특히 deprecated 토큰은 대체 토큰과 제거 예정 버전을 함께 명시해야 합니다. 토큰 거버넌스는 변경을 숨기지 않고 예측 가능하게 만드는 일입니다.
8. 운영 리듬을 정해야 시스템이 산다
디자인 토큰은 한 번 정리했다고 계속 깨끗하게 유지되지 않습니다. 매월 또는 분기마다 토큰 사용량을 점검하고, 새로 추가된 예외 값과 deprecated 토큰의 잔여 사용처를 확인해야 합니다. 디자인 시스템 팀이 따로 없다면 프론트엔드와 디자인 담당자가 짧은 정기 리뷰를 가져도 충분합니다. 핵심은 토큰 부채를 방치하지 않는 리듬입니다.
리뷰에서는 세 가지를 봅니다. 첫째, 새 화면에서 원시 색상값이나 임의 spacing이 생겼는지 확인합니다. 둘째, 기존 토큰의 이름과 실제 쓰임이 여전히 맞는지 봅니다. 셋째, 제거 예정 토큰이 계획대로 줄고 있는지 확인합니다. 이 세 가지가 관리되면 시스템은 조금씩 더 단단해집니다.
교육도 필요합니다. 새 팀원이 디자인 시스템을 사용할 때 어떤 토큰을 골라야 하는지 알 수 있어야 합니다. 문서에는 "이 토큰을 쓰세요"뿐 아니라 "이 상황에서는 쓰지 마세요"가 있어야 합니다. 좋은 거버넌스는 승인 절차를 늘리는 것이 아니라 올바른 선택을 쉽게 만드는 것입니다.
9. 제품 지표와 연결하면 설득력이 생긴다
토큰 정리는 내부 품질 작업처럼 보이기 쉽지만 실제로는 제품 속도와 사용자 경험에 영향을 줍니다. 같은 버튼 색상과 간격을 매번 다시 결정하지 않으면 화면 제작 시간이 줄고, 접근성 기준을 토큰에 반영하면 개별 화면에서 대비 오류를 찾는 비용도 낮아집니다. 디자인 시스템 투자를 설명할 때는 "일관성이 좋아진다"보다 "릴리스마다 반복되는 UI 결정과 회귀를 줄인다"는 식으로 연결하는 편이 설득력이 있습니다.
측정 가능한 지표도 둘 수 있습니다. 원시 색상값 사용 건수, deprecated 토큰 잔여 수, 토큰 변경 후 시각 회귀 발생 건수, 신규 화면에서 디자인 리뷰 반려 사유 중 스타일 불일치 비율을 추적하면 개선 효과가 보입니다. 완벽한 수치가 아니어도 방향을 보는 데 충분합니다. 거버넌스는 감각이 아니라 반복 가능한 운영으로 증명될 때 오래 갑니다.
10. 검증 노트: 표준 포맷과 내부 규칙을 구분한다
W3C Design Tokens Community Group과 Design Tokens Format Module은 디자인 토큰 데이터를 도구 사이에서 교환하기 위한 표준화된 형식을 다룹니다. 이 글에서 말하는 거버넌스는 그 위에 얹히는 조직 운영 규칙입니다. 즉, 표준 포맷은 토큰을 어떻게 표현하고 교환할지에 가깝고, 거버넌스는 어떤 토큰을 만들고 바꾸고 제거할지에 가깝습니다.
이 차이를 혼동하면 문제가 생깁니다. DTCG 형식에 맞는 JSON을 만들었다고 해서 제품 UI가 자동으로 일관되지는 않습니다. 반대로 내부 이름 규칙이 좋아도 도구 간 교환 형식이 제각각이면 Figma, 코드, 문서가 쉽게 어긋납니다. 그래서 실무에서는 표준 포맷과 내부 의미 체계를 함께 설계해야 합니다.
본문의 원시 토큰, 의미 토큰, 컴포넌트 토큰 구분도 이 관점에서 검증할 수 있습니다. 원시 값은 팔레트와 스케일을 제공하고, 의미 토큰은 제품 역할을 표현하며, 컴포넌트 토큰은 특정 컴포넌트의 상태 조합을 캡슐화합니다. 이 계층이 있어야 테마 변경, 접근성 보정, 브랜드 확장, deprecated 토큰 제거가 예측 가능해집니다.
결론: 일관성은 자동으로 유지되지 않는다
디자인 토큰은 UI 일관성을 위한 강력한 기반이지만, 파일 하나로 끝나는 일이 아닙니다. 이름 규칙, 추가 기준, 변경 절차, 도구 동기화, 제거 정책이 함께 있어야 제품 규모에서 유지됩니다. 토큰 거버넌스는 디자이너와 개발자가 같은 언어로 UI 결정을 내리게 만드는 운영 체계입니다.
좋은 토큰 시스템은 빠른 제작과 일관성을 동시에 돕습니다. 새 화면을 만들 때 매번 색상과 간격을 고민하지 않아도 되고, 브랜드나 접근성 정책이 바뀔 때 제품 전체에 안정적으로 반영할 수 있습니다. 토큰을 변수보다 계약으로 다루는 순간 디자인 시스템은 더 오래 버틸 수 있습니다.