05 — Success Criteria
디자인 시스템의 성공은 컴포넌트 수가 아니라 adoption rate(시스템 채택률)로 측정한다. 부차 지표는 time-to-component(새 화면 만드는 데 걸리는 시간)와 brand consistency score(다른 제품 사이의 시각적 일관성). 측정하지 않으면 반드시 폐기된다 — Sparkbox 2022 설문에 따르면 디자인 시스템 프로젝트의 약 40%가 성공 지표를 정의하지 못함을 핵심 실패 요인으로 꼽았다.
Why — 왜 “디자인 시스템 성공”을 측정해야 하나
디자인 시스템 팀의 1년차 리뷰에서 가장 흔한 질문은 다음과 같다:
“디자인 시스템에 6명을 1년간 투입했는데, 그래서 회사가 얻은 게 뭡니까?”
이 질문에 컴포넌트 80개를 만들었습니다로 답하면 프로젝트는 사형선고를 받는다. 컴포넌트 수는 비용이지 가치가 아니다. 가치는 그 컴포넌트가 얼마나 쓰이는가, 얼마나 빠르게 화면을 조립하게 했는가, 얼마나 일관성을 보장했는가다.
| 지표 | 비유 |
|---|---|
| 컴포넌트 수 | 도서관의 책 수 |
| Adoption rate | 도서관의 대출 건수 |
| Time-to-component | 도서관에서 원하는 책을 찾는 시간 |
| Brand consistency | 도서관 주제 분류의 정확성 |
책이 100만 권 있어도 대출이 0건이면 그건 창고지 도서관이 아니다. 디자인 시스템도 같다 — 채택되지 않으면 그건 자료실이지 시스템이 아니다.
또 하나 — 측정 가능한 지표는 조직적 정당성을 만든다. CFO에게 “ROI 보고서”를 줄 수 있는 디자인 시스템 팀만 다음 분기 예산을 받는다. 측정 없는 시스템은 호의에 의존하고, 호의는 해 바뀌면 사라진다.
How — 무엇을 어떻게 측정하나
핵심 지표 3가지 + 보조 지표
1) Adoption Rate (채택률) — 최상위 지표
정의: 전체 프로덕트 코드에서 디자인 시스템 컴포넌트가 차지하는 비율.
계산:
adoption_rate = (시스템 컴포넌트 import 수) / (전체 UI 컴포넌트 import 수)측정 방법 — AST 스캔:
// scripts/measure-adoption.ts
import { Project } from 'ts-morph'
const project = new Project({ tsConfigFilePath: './tsconfig.json' })
let systemImports = 0
let totalImports = 0
for (const file of project.getSourceFiles('src/**/*.tsx')) {
for (const imp of file.getImportDeclarations()) {
const mod = imp.getModuleSpecifierValue()
const isUiImport =
mod === 'react' ? false :
/^(@company\/ui|react-bootstrap|@mui\/material|antd|chakra-ui)/.test(mod)
if (isUiImport) {
totalImports += imp.getNamedImports().length
if (mod.startsWith('@company/ui')) {
systemImports += imp.getNamedImports().length
}
}
}
}
console.log(`Adoption: ${(systemImports / totalImports * 100).toFixed(1)}%`)벤치마크:
| Adoption rate | 단계 | 의미 |
|---|---|---|
| < 20% | 미정착 | 시스템이 외면당함. 폐기 위험. |
| 20~50% | 성장 | 일부 팀만 채택. 영업·교육 필요. |
| 50~80% | 정착 | 메인스트림. 신규 코드는 시스템 강제. |
| 80%+ | 인프라 | 시스템이 기본. 예외만 비-시스템 사용. |
GitHub Primer는 GitHub UI 코드의 약 90% 이상이 Primer 컴포넌트(2023 Primer team blog). 이 수치가 10년 수명의 비결.
2) Time-to-Component (새 화면 만드는 시간)
정의: 신규 화면 1개를 디자인 시안부터 배포까지 만드는 평균 시간.
측정:
- JIRA/Linear의 디자인 시안 첨부 → PR merge 기간.
- 분기마다 무작위 10개 화면을 샘플링.
벤치마크:
| Time | 단계 |
|---|---|
| 2주+ | 시스템 없음 — 매번 처음부터 |
| 1주 | 초기 시스템 — 기본 컴포넌트만 있음 |
| 2~3일 | 성숙 시스템 — Recipe·Theme 갖춤 |
| 1일 이하 | 우수 — Storybook·Figma 동기화 |
Shopify는 Polaris로 어드민 신규 화면을 평균 2일 안에 조립한다고 발표(2021). 이게 수익으로 직결 — 신규 기능 출시 속도.
3) Brand Consistency Score (브랜드 일관성)
정의: 다른 제품(웹/모바일/마케팅) 사이의 시각적 동일성.
측정 방법 — 자동 + 수동 혼합:
# 자동: 색·간격·폰트의 사용된 hex/px 종류 카운트
npx design-system-audit \
--tokens=@company/tokens \
--scan='src/**/*.{tsx,css}' \
--output=audit.json
# 결과 예시
{
"uniqueColors": 23, # 토큰은 12개인데 23개 사용 → 11개가 비-시스템
"tokenCoverage": "52%", # 사용된 색 중 52%만 토큰
"outliers": [
{ "file": "src/Page.tsx", "line": 42, "color": "#3371b9", "nearestToken": "color.primary.500 (#3370b8)" }
]
}수동 측정 — 디자이너 audit:
- 분기마다 제품 화면 30개를 캡쳐.
- 디자인 시스템 팀 + 외부 디자이너가 일관성 점수를 1~10으로 평가.
- 7점 이하 항목은 왜 일관성이 깨졌는지 root cause 분석.
보조 지표 4가지
| 지표 | 측정 | 의미 |
|---|---|---|
| Contributor Diversity | 분기당 시스템에 PR 낸 사람 수 | 단일 팀 의존성 vs 페더레이션 |
| Deprecation Velocity | 마이그레이션 평균 기간 | 계약 준수 능력 |
| Token Stability Index | 6개월간 이름 변경 토큰 비율 | 신뢰도 |
| Designer Satisfaction | 분기 NPS (디자이너 대상) | 디자인 측 수용도 |
What — 구체적 측정 표·계산 예시
분기별 보고서 템플릿
# Design System Q3 2025 Report
## 핵심 지표
| 지표 | Q2 | Q3 | 목표 | 상태 |
|------|----|----|------|------|
| Adoption rate | 47% | 56% | 60% | ⚠ 근접 |
| Time-to-component | 3.2일 | 2.8일 | 2일 | ⚠ 진행 |
| Brand consistency | 7.1 / 10 | 7.4 / 10 | 8.0 | ⚠ 개선 |
## 보조 지표
| 지표 | Q2 | Q3 |
|------|----|----|
| Contributor diversity | 8명 | 14명 |
| Deprecation velocity | 5.8주 | 4.2주 |
| Token stability | 98% | 99% |
| Designer NPS | +12 | +18 |
## 주요 인사이트
- Mobile 팀 채택률이 80% 돌파 (Q2 35%).
- Marketing 팀은 여전히 24% — 별도 가이드 필요.
- 신규 컴포넌트 5개 추가, 그러나 채택률 30% 미만 컴포넌트 3개는 deprecation 검토.Adoption rate 측정의 함정 회피
naive 측정의 문제:
// 위험한 측정 — 모든 import를 셈
const adoption = systemImports / totalImports // 분모에 react, 라이브러리 등이 다 들어감올바른 측정:
// UI 컴포넌트 import만 분모로
const adoption = systemUiImports / (systemUiImports + nonSystemUiImports)더 좋은 측정 — JSX element 카운트:
import { TsxParser } from '@ast-grep/napi'
const allJsxElements = countAllJsxElements('src')
const systemJsxElements = countJsxElementsFromPackage('@company/ui')
// 실제 화면을 그리는 element 중 몇 %가 시스템인가
const adoption = systemJsxElements / allJsxElementsTime-to-Component 측정 자동화
# JIRA workflow
- 디자인 시안 첨부 = T0
- PR merged = T1
- 평균 (T1 - T0) = Time-to-Component
# Linear 자동 export
# - 매주 cron으로 Linear API → BigQuery
# - Looker 대시보드에 시간 분포 히스토그램Brand Consistency 자동 audit 도구
| 도구 | 측정 |
|---|---|
| Project Wallace | CSS 분석 — 사용된 색·폰트·셀렉터 카운트 |
| Specificity Graph | specificity 분포 |
| 커스텀 ts-morph 스크립트 | 토큰 적용률·outlier 추출 |
| Chromatic / Percy | 시각 회귀 + 컴포넌트 카탈로그 시각 일관성 |
What-if — 측정의 함정·실패 모드
1) 컴포넌트 수를 추적 → “양 vs 질”의 함정
- 증상: 분기마다 “신규 컴포넌트 10개” 보고. 실제 채택률은 정체.
- 원인: KPI가 컴포넌트 수. 팀이 덜 쓰는 컴포넌트를 양산함.
- 대응: KPI를 adoption rate로. 채택률 30% 미만 컴포넌트는 deprecation 정책.
2) Adoption rate가 너무 빨리 높아짐
- 증상: 1년 만에 95% 채택. 그러나 디자이너 NPS는 -10.
- 원인: 시스템이 강제 — 개발자가 시스템에 없는 디자인은 임의 변형해서 끼워 맞춤.
- 대응: NPS·designer satisfaction도 같이 추적. 강제 채택은 우회 패턴을 낳는다.
3) Time-to-Component이 떨어지지 않음
- 증상: 시스템 1년 사용, time-to-component이 그대로 (3주).
- 원인: 시스템이 낮은 레벨 부품만 갖춤. 조립 시간은 그대로.
- 대응: Patterns (Polaris 용어) 또는 Recipes (Atomic 용어)를 추가. 즉 고수준 합성 컴포넌트 (예:
<DataTable>,<EmptyState>).
4) Brand Consistency가 측정되지 않음
- 증상: 디자이너가 “여기저기 다 다르다”고 불평. 데이터는 없음.
- 원인: 수동 audit조차 안 함. 주관적인 불만만 누적.
- 대응: 분기 디자인 audit을 공식 프로세스로. 30개 화면 캡쳐 → 1~10 점수.
5) “측정만 하고 행동 안 함”
- 증상: 보고서는 매분기 나옴. 그러나 Adoption < 30% 컴포넌트는 계속 살아있음.
- 원인: 측정과 deprecation 결정이 분리됨.
- 대응: 자동 deprecation 정책 — “Adoption < 20%, 6개월 이상 = 자동 deprecation 후보”.
6) Designer satisfaction을 무시
- 증상: 개발자는 시스템 좋아함. 디자이너는 Figma에서 시스템 쓰기 싫어함.
- 원인: Figma 측 워크플로 부재. 토큰이 Figma Variables에 동기화 안 됨.
- 대응: Tokens Studio 또는 Figma Variables 동기화. 디자이너 NPS를 분기 KPI에.
Insight — 측정이 디자인 시스템의 생존을 결정한다
“Sparkbox 2022 Design Systems Survey — 디자인 시스템 폐기의 1번 원인은 기술이 아니라 ‘예산 삭감’이었다.”
그리고 예산 삭감의 1번 원인은 “투자 대비 효과를 증명할 수 없음” 이었다. 흥미로운 함의 — 디자인 시스템의 수명은 기술적 우수성이 아니라 ROI 증명 능력이 결정한다.
성공한 디자인 시스템 팀들의 공통점 — 모두 ROI 보고서를 분기마다 만든다:
- Shopify Polaris — “Polaris로 신규 화면 평균 제작 시간 -70%” 라는 수치를 임원 발표에서 사용.
- GitHub Primer — adoption rate를 분기 KPI로 발표. 90%+ 유지.
- Atlassian Design System — 외부 디자인 시스템 운영 비용 보고서를 공개. 비용 정당화 사례 연구.
반면 조용히 폐기된 디자인 시스템들의 공통점 — 지표가 없음. 컴포넌트 수만 자랑하고 사용률은 모름.
또 하나 — “Goodhart’s Law”가 디자인 시스템에도 적용된다. “측정이 목표가 되면 그것은 더 이상 좋은 측정이 아니다.” Adoption rate를 KPI로 두면 팀이 adoption rate를 조작하는 방향으로 움직인다 — 가령 기존 컴포넌트 강제 wrap 같은 무의미한 채택. 그래서 복수 지표가 필요 — adoption + designer NPS + time-to-component + brand consistency. 한 지표를 조작하면 다른 지표가 떨어진다.
마지막으로, “디자인 시스템의 ROI를 직접 측정한 가장 유명한 사례” — IBM Carbon의 2018년 보고서. Carbon 도입 후 디자인-개발 전환 시간 40% 단축, 디자인 일관성 점수 30% 상승, 디자이너 만족도 50% 상승. 이 보고서가 IBM 내부 디자인 시스템 예산을 3배로 늘린 결정적 근거였다. 측정이 예산을 만든다.
요약 + Mermaid
- 핵심 3지표: Adoption Rate (시스템 채택률) > Time-to-Component > Brand Consistency.
- 컴포넌트 수는 비용이지 가치가 아니다. 측정하지 마라.
- Adoption rate 측정은 AST 스캔 자동화. 분기마다.
- 측정 없는 디자인 시스템은 반드시 폐기된다 (Sparkbox 2022).
- Goodhart’s Law — 복수 지표로 조작 방지.
- ROI 보고서가 예산을 만든다. IBM Carbon 2018 사례.