KRDS 디자인 토큰 채택률, 자동으로 측정할 수 있을까 — 색상 586개·전체 768개를 기준으로

공공 웹이 KRDS 토큰을 '실제로' 얼마나 쓰는지, 우리가 정량 측정을 실험하게 된 이유

---

들어가며 — "우리 사이트, KRDS 토큰 쓰고 있나요?"라는 질문

공공 웹 관련 회의에서 최근 자주 나오는 질문이 있다. "우리 사이트, KRDS 적용했나요?"

이 질문은 생각보다 대답하기 까다롭다. "네, 기획 때 KRDS 가이드를 참고했습니다"라고 말할 수는 있다. 하지만 그게 실제로 화면에 반영됐는지, 색상 값이 KRDS 토큰에 정의된 그대로인지, 간격이나 폰트 크기가 가이드에 맞는지 — 이걸 눈으로 확인하자면 일이 커진다. 가이드 문서를 펼쳐놓고, 디자인 파일을 열고, 구현된 화면을 캡처해 비교하는 수작업이 필요해진다.

그리고 이런 수작업은 대부분 마지막 단계, 즉 "검수"나 "감사" 시점에만 이루어진다. 개발 중에는 바쁘고, 납품 후에는 이미 늦다. 그 사이에 토큰이 아닌 임의의 색상값이 코드 곳곳에 스며들고, 수정 요청이 들어올 때쯤이면 어디를 얼마나 고쳐야 할지 전수 파악 자체가 어려운 상황이 된다.

우리가 ViewCheck LLM 분석에서 'KRDS 디자인 토큰 채택률 측정' 기능을 만들려 한 건 바로 이 문제에서 출발했다. 수작업 비교가 아니라, URL 한 줄을 넣으면 "이 사이트에 KRDS 토큰이 얼마나 채택되어 있는지"를 자동으로 정량 측정해 보여줄 수 있을까.

이 글은 그 실험의 기록이다. 아직 완벽하지 않다. 오히려 "이렇게 시도해봤더니 이런 한계가 있었다"는 이야기를 솔직하게 담으려 한다. 그게 이 시리즈의 톤이기도 하고, 이 주제를 정직하게 다루는 유일한 방법이라고 생각하기 때문이다.

---

디자인 토큰이란 무엇인가 — 토큰 없이 색상을 관리한다는 것

본론으로 들어가기 전에, 디자인 토큰 개념부터 짚고 가자. 이 글의 독자 중에는 이미 잘 아는 분도 있겠지만, 공공 웹 담당자처럼 개발·디자인 배경이 없는 분도 있기 때문이다.

디자인 토큰(Design Token)이란 디자인 결정을 코드가 읽을 수 있는 형태로 표현한 변수다. 가장 쉽게 설명하면 이렇다. #256EF4라는 색상값이 있다. 이걸 코드에 그대로 쓰면, 내일 브랜드 색상이 바뀔 때 그 값을 쓴 모든 파일을 찾아 일일이 고쳐야 한다. 반면 color-primary라는 이름의 토큰에 #256EF4를 한 번만 정의해두면, 코드 어디서든 color-primary를 쓸 수 있고, 나중에 값이 바뀌어도 정의 한 군데만 수정하면 된다.

W3C 산하 디자인 토큰 커뮤니티 그룹(Design Tokens Community Group, DTCG)은 2025년 10월 28일, 디자인 토큰 사양의 첫 번째 안정 버전(2025.10)을 공식 발표했다. 공식 발표문은 이 사양을 "멀티 브랜드 디자인 시스템을 유지하는 팀이 수십 개 혹은 수백 개의 토큰 파일을 수작업으로 관리하다 발생하는 드리프트, 오류, 유지보수 오버헤드를 해결하기 위한, 프로덕션 준비가 된 벤더 중립적 형식"이라고 설명했다(W3C Design Tokens Community Group, 2025). Figma, Penpot, Sketch, Tokens Studio, Style Dictionary 등 주요 도구들이 이 사양을 지지하며, 디자인과 개발 사이의 토큰 교환을 표준화하는 공용어가 탄생한 셈이다.

한국 공공 분야에서는 KRDS가 이 디자인 토큰 개념을 적용하고 있다. KRDS 공식 가이드는 디자인 토큰을 이렇게 정의한다. "디자인 시스템에서 반복적으로 사용되는 디자인 속성을 효율적으로 관리하기 위한 일종의 추상화된 값을 변수로 정의한 코드로, 색상, 글자, 간격, 그림자 등과 같은 스타일의 속성을 정의하고 이를 코드로 변환하여 디자인 시스템 전반에 걸쳐 일관된 스타일을 유지할 수 있게 도와줍니다"(KRDS 공식, style_07.html). KRDS의 디자인 토큰은 세 가지 레벨로 구분된다 — 기본 스타일 속성을 정의하는 Primitive Token, 구체적 의미를 부여한 Semantic Token, 특정 컴포넌트에 적용되는 Component Token.

이 세 레벨의 관계를 조금 더 풀면 이렇다. Primitive Token에서 blue-600 = #256EF4라고 원시값을 정의하고, Semantic Token에서 color-primary = blue-600처럼 의미를 부여하고, Component Token에서 button-bg-primary = color-primary처럼 특정 컴포넌트에 값을 연결한다. 이 계층 구조 덕분에 브랜드 색상이 바뀌어도 Primitive Token 한 곳만 수정하면 시스템 전체에 반영된다. 토큰이 '설계도'이고, 실제 화면은 그 설계도를 따르는 '구현'인 셈이다.

그렇다면 공공 웹 사이트가 이 설계도를 얼마나 잘 따르고 있는지, 어떻게 알 수 있을까. 그게 우리가 연구한 질문이다.

---

KRDS 디자인 토큰의 규모 — 색상 586개·전체 768개

채택률을 측정하려면 먼저 기준을 정확히 알아야 한다. KRDS에 디자인 토큰이 몇 개나 있는지부터.

이 숫자를 두고 인터넷에서 여러 버전이 떠돌고 있다. "1,082개"라는 수치를 어디선가 본 적이 있을 텐데, 우리가 직접 KRDS HTML Kit을 분석해 실측한 결과는 달랐다. 색상 토큰 약 586개, 전체 토큰 약 768개. 이 숫자가 우리 분석의 기준값이다.

왜 차이가 나는지는 완전히 확인하지 못했다. KRDS가 버전업되면서 토큰 수가 조정됐을 수도 있고, 세는 방식에 따라 결과가 달라질 수 있다(예: 다크모드 변수를 별도 토큰으로 세느냐 아니냐). 중요한 건 숫자 자체가 아니라, 실제 소스를 직접 파싱해 기준을 확인했다는 것이다. 추측이 아닌 실측. 이게 우리가 반복해서 강조하는 작업 원칙이다.

768개의 토큰 중 색상이 586개를 차지한다는 건, KRDS 디자인 시스템에서 색상이 얼마나 중요한 위치인지를 보여준다. 실제로 색상 토큰은 KRDS 디자인 준수 여부를 판별하는 데 가장 핵심적인 지표 중 하나다. 사용자가 웹사이트를 봤을 때 "이게 KRDS스러운가?"를 가장 직관적으로 판단하는 근거가 색상이기 때문이다.

KRDS 색상 체계를 조금 살펴보면, 설계 철학이 보인다. 순백 배경(#ffffff) 위에 거의 검정에 가까운 본문(#1E2124), 그리고 신뢰감을 주는 정부 블루(#256EF4)가 핵심 강조색으로 작동한다. 마케팅 브랜드의 화려한 색상과 달리, 공공 서비스는 "도구처럼 보여야 한다"는 설계 원칙이 반영된 팔레트다(KRDS 공식, 디자인 토큰 페이지). 그리고 색약자·색각 이상자를 고려한 색상 체계를 기본으로 내장한다는 점도 중요하다. 단순히 예쁜 색이 아니라 접근 가능한 색을 기본값으로 두는 것이 공공 디자인 시스템의 존재 이유이기도 하다.

768개의 토큰 전체를 카테고리로 나누면 대략 이렇다. 색상(약 586개), 타이포그래피(폰트 크기·줄높이·자간 등), 간격(스페이싱·패딩·마진), 그림자(박스 섀도우·엘리베이션), 반경(border-radius), 그리드(레이아웃 간격). 각 카테고리는 컴포넌트 설계의 언어이자, 사이트가 KRDS를 얼마나 체화했는지 보여주는 지표가 된다.

이 모든 토큰을 하나의 기준표로 만들고, 실제 사이트의 CSS와 비교해 얼마나 일치하는지 측정하는 것 — 그게 우리가 하려는 '채택률 측정'의 핵심이다.

---

왜 채택률을 측정하려 했나 — 문제 의식의 출발

채택률 측정 기능을 만들자는 이야기가 나온 건, 실제 분석 과정에서 맞닥뜨린 작은 의문에서 시작됐다.

여러 공공 사이트를 분석하다 보면, KRDS를 "적용했다"고 밝힌 사이트와 그렇지 않다고 밝힌 사이트 사이에서 눈에 보이는 색상 값이 실제로 얼마나 다른지 궁금했다. 그리고 "KRDS 적용"이라는 선언이 디자인 가이드를 참고한 수준인지, 아니면 실제로 토큰 값 그대로를 코드에 반영한 수준인지 구분할 수 있는 도구가 없다는 것을 느꼈다.

이건 단순히 기술적 궁금증이 아니다. 행정안전부의 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호)은 공공 웹사이트의 품질 기준을 명시하고 있으며, KRDS는 그 기준의 디자인 언어다. 발주 기관이 "KRDS 기반으로 구현해달라"고 요구했을 때, 수행 업체가 그 요구를 제대로 이행했는지를 검수하려면 "토큰이 얼마나 채택됐는지"를 객관적으로 측정할 수단이 있어야 한다.

지금은 그 검수가 대부분 눈대중으로 이루어진다. "색상이 비슷해 보이는가", "레이아웃이 KRDS 가이드와 비슷한가" — 이 수준의 시각적 비교에 머문다. 그리고 눈대중 검수는 검수자에 따라, 기준에 따라 결과가 달라진다. 같은 사이트를 봐도 "충분히 비슷하다"와 "더 수정해야 한다"가 엇갈리는 것이다.

우리가 채택률 측정을 시도한 이유는 바로 이 불명확함에 수치를 붙이고 싶었기 때문이다. "색상 토큰 586개 중 37개가 이 사이트에서 사용됩니다. 채택률 6.3%"처럼. 물론 이 숫자 하나로 모든 걸 판단할 수는 없다. 하지만 수치가 있으면 대화의 출발점이 달라진다. 감이 아니라 데이터로 이야기할 수 있게 된다.

---

어떻게 측정하나 — CSS 추출과 토큰 매핑

측정의 원리를 설명해보자. 다소 기술적이지만, 가능한 한 쉽게 풀어쓰겠다.

웹페이지는 사실 굉장히 솔직한 존재다. 화면에 어떤 색상이 표시되는지, 어떤 폰트 크기가 사용되는지 — 이 정보는 모두 브라우저가 계산한 CSS 값(Computed Style)에 들어 있다. 브라우저 개발자 도구를 열면 "이 요소의 background-color는 #256EF4"처럼 실제 적용된 값을 볼 수 있다. 이 값을 코드로 읽어올 수 있다는 게 출발점이다.

ViewCheck는 Playwright(실제 브라우저를 코드로 제어하는 도구)로 사이트를 방문해 DOM(화면 구조)을 추출한다. 이때 각 요소에 실제로 적용된 CSS 값도 함께 수집한다. 색상(color, background-color, border-color), 폰트(font-size, font-family, line-height, letter-spacing), 간격(padding, margin, gap), 그림자(box-shadow), 반경(border-radius) 등 토큰으로 관리할 수 있는 모든 스타일 속성이 대상이다.

그다음은 KRDS 토큰 매핑이다. KRDS HTML Kit에 정의된 토큰들의 값을 미리 파싱해두고, 사이트에서 추출한 CSS 값과 대조한다. 예를 들어 사이트의 버튼 배경색이 #256EF4라면, 이 값이 KRDS의 color-primary 토큰(값 #256EF4)과 일치하는지 확인한다. 일치한다면 그 요소는 "KRDS 색상 토큰을 채택했다"고 볼 수 있다. 이런 식으로 페이지 전체의 요소들을 훑으며, 몇 개의 KRDS 토큰 값이 실제로 사용되고 있는지를 집계한다.

여기서 중요한 개념이 있다. "직접 토큰 변수를 사용했는가"와 "토큰과 동일한 값을 사용했는가"는 다르다. 이상적으로는 CSS에서 var(--color-primary)처럼 변수로 참조하는 게 맞다. 하지만 실제 공공 사이트 중에는 토큰 변수 시스템 없이, 토큰과 동일한 색상값을 하드코딩한 경우도 있다. 우리 측정은 현재로서는 "값 기준" 비교가 주다. #256EF4가 코드에 있다면, 그게 변수로 참조됐든 하드코딩됐든 일단 "KRDS 토큰 값 채택"으로 카운팅한다. 이게 실제 토큰 기반 구현과 동일하다고는 말할 수 없고, 앞으로 CSS 변수 감지를 추가해 구분할 예정이다.

실제로 이런 방식의 웹 CSS 추출 접근은 이미 여러 도구에서 사용 중이다. Dembrandt처럼 Playwright로 웹사이트의 computed style을 분석해 W3C 디자인 토큰 표준으로 출력하는 오픈소스 CLI가 존재하고, Project Wallace 같은 서비스는 CSS를 정적 분석해 디자인 토큰을 추출한다(GitHub: dembrandt, Project Wallace CSS Design Tokens Analyzer). 우리가 하는 일도 이 맥락 위에 있다. 단, 우리는 추출된 값을 단순 열거하는 것이 아니라, KRDS 기준 토큰과의 매핑 및 채택률 수치화에 초점을 맞춘다는 게 차별점이다.

---

증적: 실제 측정 화면을 보면

실제로 ViewCheck가 어떤 결과를 보여주는지 증적 이미지로 확인해보자.

이 화면에서 볼 수 있는 것이 'DS(Design Style)' 카테고리 분석 결과다. ViewCheck는 KRDS 846개 규칙 중 디자인 스타일(DS) 영역에 해당하는 120개 규칙을 판정하면서, 그 과정에서 추출된 CSS 데이터를 기반으로 토큰 채택률 메타데이터도 함께 계산한다.

화면에 표시되는 정보는 대략 이런 구조다.

• 색상 토큰 채택률: KRDS 색상 토큰(586개 기준)과 비교해, 실제 사이트에서 사용 중인 KRDS 토큰 값의 비율
• 전체 토큰 채택률: 768개 전체 토큰 대비 채택 토큰 수
• 카테고리별 상세: 색상·타이포·간격·기타 카테고리별 채택 현황
• DS 규칙 판정 결과: 통과/미통과/해당없음 분포 (DS 120개 기준)

숫자를 보면 흥미로운 패턴이 보인다. 대부분의 공공 사이트에서 색상 토큰 채택률은 색상 종류 자체가 적을 경우 낮게 나오고, 반대로 정부 블루(#256EF4 계열)를 충실히 쓴 사이트는 핵심 색상 토큰 기준으로는 채택률이 높게 나오는 경향이 있다. 물론 이건 우리가 여러 사이트를 분석하면서 관찰한 경향이고, 통계적으로 검증된 주장은 아니다. 실측 데이터가 더 쌓이면 패턴이 더 선명해질 것이다.

여기서 솔직하게 짚어야 할 게 있다. 채택률 수치는 "이 사이트가 KRDS를 준수했는가"의 최종 판단이 아니다. 특정 색상값을 쓴다고 해서 반드시 KRDS를 의도적으로 적용한 것은 아닐 수 있고(우연의 일치), 반대로 토큰 채택률이 낮아도 전체적 디자인 품질이 낮다고 단정할 수 없다. 이 수치는 "추가 검토가 필요한 신호"를 포착하는 데 유용하지, 그 자체가 판정이 되어서는 안 된다는 것을 우리 스스로 경계하고 있다.

---

DS 120개 규칙과 토큰 채택률의 관계

ViewCheck에서 디자인 토큰 채택률은 DS(Design Style) 카테고리의 120개 규칙 판정과 연동되어 있다. 이 둘의 관계를 조금 더 설명해보자.

DS 카테고리의 120개 규칙은 크게 이런 것들을 다룬다.

구분	내용	예시 규칙
색상	배경·텍스트·보더 색상이 KRDS 기준값에 맞는가	텍스트 색상 대비율, 주요 컬러 사용 여부
타이포그래피	폰트 크기·줄높이·자간이 기준 범위에 있는가	본문 폰트 크기, Pretendard GOV 서체 여부
간격	패딩·마진·컨테이너 폭이 8pt 그리드를 따르는가	주요 여백 단위, 컨테이너 최대폭
레이아웃	그리드 컬럼, 반응형 기준폭이 KRDS 기준에 맞는가	12컬럼 그리드 여부, 브레이크포인트
그림자·반경	box-shadow, border-radius가 공식 값 범위인가	KRDS 그림자 레벨, 컴포넌트 border-radius

이 규칙들은 단순히 "맞다/틀리다"를 판정하는 데서 끝나지 않는다. 판정을 위해 수집된 CSS 데이터가 토큰 채택률 계산에 함께 활용된다. 예를 들어 DS-044 규칙(색상 대비율 기준 준수)을 판정하면서 추출한 color: #1E2124가 KRDS의 color-text-primary 토큰 값과 일치하면, 그 요소는 채택률 카운터에 잡힌다.

즉, DS 규칙 판정은 단순한 통과/미통과 판정이 아니라, KRDS 스타일 데이터 수집 파이프라인이기도 하다. 채택률 측정은 그 파이프라인의 부산물로 만들어진다. 이게 효율적인 이유는, 어차피 DS 규칙 판정을 위해 CSS를 읽어야 하는데 그 데이터를 버리지 않고 토큰 매핑에 재사용하기 때문이다.

반면 한계도 있다. 현재 DS 판정 로직이 커버하는 CSS 속성만 채택률에 잡힌다. 만약 어떤 토큰 카테고리가 DS 판정 규칙에 포함되지 않으면, 그 토큰의 채택 여부는 지금 측정에서 빠진다. 이건 앞으로 보완해야 할 영역이고, 지금도 어느 토큰 카테고리가 빠져 있는지 파악하는 과정 중이다.

---

해외 사례와의 비교 — 공공 디자인 시스템의 토큰 관리 방식

KRDS의 토큰 체계를 이해하는 데 해외 공공 디자인 시스템과 비교하는 게 도움이 된다.

미국의 USWDS(U.S. Web Design System)는 색상 토큰을 세 계층으로 나눠 관리한다. System Color Tokens(25가지 색조 × 10등급 = 약 250개의 원시 색상 팔레트), Theme Color Tokens(base·primary·secondary·accent-warm·accent-cool 5개 패밀리, 각 7등급), State Color Tokens(info·error·warning·success·emergency·disabled 6개 상태, 각 5등급 이하). 이 세 계층이 primitive → semantic → component 구조로 맞물린다(USWDS 공식, designsystem.digital.gov/design-tokens/). 토큰 개수는 KRDS와 다르지만, 계층 설계 철학은 매우 비슷하다.

영국의 GOV.UK Design System은 색상 시스템을 상대적으로 단순하게 유지하는 것으로 유명하다. "GOV.UK 색상 팔레트는 일관성과 접근성 둘 다를 위해 설계됐으며, 모든 컴포넌트와 패턴은 WCAG AA 기준을 충족하도록 검증됐다"는 원칙 아래, 적은 색상 선택지로 높은 접근성을 보장하는 전략이다(GOV.UK Design System 공식, design-system.service.gov.uk/styles/colour/). 최근 2025년 6월에는 GOV.UK 전반의 브랜드 갱신과 함께 프론트엔드 여러 버전을 출시하며 색상 체계도 업데이트했다.

두 해외 사례를 보면 공통적으로 "토큰을 통한 접근성의 기본값화"가 핵심이다. 컴포넌트를 구현할 때 색상 토큰을 쓰면 자동으로 접근성이 보장되는 구조. KRDS도 같은 설계 원칙을 갖는다. 색각 이상자를 고려한 색상 설계가 토큰에 내장되어 있으므로, 토큰을 충실히 사용하면 접근성도 함께 올라간다는 로직이다.

이 관점에서 보면 채택률 측정은 단순히 "KRDS를 따랐는가"를 넘어, "이 사이트의 접근성 기본 토대가 얼마나 갖춰져 있는가"의 간접 지표가 될 수도 있다. 아직 이 관계를 공식화하기엔 데이터가 부족하지만, 흥미로운 연구 방향이라고 생각한다.

---

채택률 측정의 현실적 한계들

솔직하게 이야기하자. 우리가 구현한 채택률 측정은 여러 한계를 가지고 있다. 그 한계를 정직하게 나열하는 게 이 글의 의무라고 생각한다.

한계 1 — 값 기준 비교의 불완전성

앞서 언급했듯, 현재 측정은 "CSS 값이 토큰 정의와 일치하는가"를 본다. #256EF4가 사이트 CSS에 있으면 KRDS color-primary 토큰 채택으로 본다. 하지만 이 #256EF4가 var(--color-primary) 변수를 통해 참조된 건지, 아니면 디자이너가 색상 코드를 우연히 일치하게 입력한 건지는 구분하지 못한다. 전자는 진정한 의미의 토큰 기반 구현이고, 후자는 값이 같을 뿐 토큰 구조를 따른 게 아니다. 이 구분을 하려면 CSS 변수(var(...) 참조 여부)를 별도로 파싱해야 한다. 현재 개발 중인 기능이다.

한계 2 — 동적 값의 측정 어려움

현대 웹사이트는 자바스크립트로 동적으로 스타일을 바꾼다. 다크모드 전환, 테마 변경, 상태에 따른 색상 변화 등이 그 예다. Playwright로 스냅샷을 찍는 시점의 값만 잡으므로, 인터랙션 후에 적용되는 스타일은 측정에서 빠질 수 있다. 예를 들어 포커스 상태의 테두리 색이 토큰을 따르는지 여부는, 실제로 요소에 포커스를 줘봐야 알 수 있다.

한계 3 — 토큰 카테고리 커버리지의 불균일

색상은 비교적 명확한 값(헥스 코드, rgb 값)으로 나타나 매핑이 쉽다. 반면 간격 토큰은 맥락에 따라 달라진다 — 같은 16px라도 어떤 컨텍스트에서 쓰이는지에 따라 "간격 토큰 채택"인지 "임의 값"인지 의미가 다르다. 현재로서는 색상 토큰 채택률이 가장 신뢰도 높은 수치이고, 간격·타이포 같은 카테고리는 정확도가 낮다는 걸 인정해야 한다.

한계 4 — 다중 페이지 집계의 복잡성

ViewCheck는 기본적으로 다중 페이지를 분석한다. 그런데 페이지마다 쓰이는 CSS가 다를 수 있다. 메인 페이지의 채택률과 신청 페이지의 채택률이 다를 수 있고, 전체 사이트 채택률은 이를 어떻게 집계할지가 문제다. 단순 평균인지, 가중 평균인지, 혹은 "전체 사이트에서 등장한 유니크 토큰 값 기준"인지에 따라 숫자가 크게 달라진다. 우리는 지금 여러 집계 방식을 실험 중이다.

한계 5 — 기준 자체의 버전 문제

KRDS는 계속 업데이트된다. 새 버전에서 토큰 값이 바뀌면, 이전 버전 기준으로 "채택"이었던 것이 "미채택"이 될 수 있고 반대도 마찬가지다. 우리가 측정에 사용하는 KRDS HTML Kit 버전을 명시하고, 버전별로 기준을 관리하는 체계가 필요하다. 현재는 가장 최신 버전 기준이지만, 버전 관리 자동화는 아직 과제다.

이 한계들을 나열하면서 우리가 말하고 싶은 건 이것이다. 채택률 수치를 보고 "이 사이트는 KRDS 준수도가 X%"라고 단정 짓는 건 아직 이르다. 대신 "이 정도의 신뢰도로 이 수치를 참고하면 이런 점을 살펴볼 수 있다"는 방향으로 사용하는 게 맞다. 이게 불완전한 도구를 솔직하게 제공하는 방식이라고 생각한다.

---

Supernova 2024 리포트가 보여준 디자인 토큰의 현실

우리만 디자인 토큰 채택과 관리의 어려움을 겪는 게 아니다. Supernova가 200명 이상의 디자이너·개발자를 대상으로 진행한 「State of Design Tokens 2024」 조사(30페이지 이상 분량)는 현업에서 디자인 토큰이 어떻게 쓰이고, 어떤 어려움이 있는지를 잘 보여준다(Supernova, State of Design Tokens 2024 Report).

조사에서 드러난 몇 가지 흥미로운 사실들이 있다.

Figma 변수의 급속한 보급: 2023년 출시된 Figma 변수를 사용한다는 응답이 약 74%에 달했다. 디자이너들이 자신의 도구 안에서 토큰을 관리하고 싶어 한다는 뜻이다. 반면 엔지니어링 팀과의 실질적 연동은 여전히 불충분하다는 것도 이 조사에서 드러났다.

엔지니어링 참여 부족: 디자인 토큰의 진정한 가치는 디자인-개발 사이의 단일 출처(Single Source of Truth)에서 나오는데, 엔지니어링 팀이 충분히 참여하지 않아 토큰이 디자인 도구에서 그치고 코드에 제대로 연결되지 않는 경우가 많다는 게 보고서의 핵심 문제 진단이었다. 패널 참가자들은 "토큰의 성공은 디자인과 엔지니어링 팀의 강한 협업에 달려 있다"고 강조했다.

W3C 사양에 대한 기대: W3C 디자인 토큰 사양이 "디자인과 개발 도구 사이의 공용어가 될 것"이라는 기대가 높았다. 그리고 2025년 10월, 그 사양이 실제로 첫 안정 버전을 출시했다.

이 조사 결과를 공공 영역에 대입하면 상황은 더 복잡하다. 민간 기업보다 빠른 도입이 어렵고, 담당 인력의 기술 배경이 다양하며, 외주 개발 구조로 인해 디자인-개발 협업이 구조적으로 단절되는 경우가 많다. "토큰을 정의했지만 코드에 안 썼다"는 패턴이 공공 웹에서 더 자주 나타날 수 있는 환경이다. 그래서 채택률 측정의 필요성이 오히려 공공 영역에서 더 클 수 있다고 생각한다.

---

디자인 시스템 거버넌스와 채택률의 연관

단순히 "토큰을 정의했는가"에서 나아가, "토큰이 잘 쓰이고 있는가"를 모니터링하는 것이 디자인 시스템 거버넌스의 핵심 과제 중 하나다.

DOOR3의 디자인 토큰 거버넌스 연구는 이 문제를 직접적으로 다룬다. "디자인 토큰은 디자인 시스템에서 일관성, 확장성, 효율성을 유지하기 위한 강력한 도구이지만, 적절한 거버넌스 없이는 그 잠재력이 금방 줄어든다"고 지적하며, 거버넌스의 핵심 실천으로 "정기적인 모든 팀의 피드백 수집"과 "지속적 반복(iterating)을 통한 거버넌스 프로세스 개선"을 꼽는다(DOOR3, Establishing Effective Design Token Governance).

2025년 현재 업계 모범 사례를 보면, 성숙한 디자인 시스템 팀들은 토큰 세트, 값, 별칭(alias)을 모두 추적·감사할 수 있는 버전 관리 시스템을 운영하고, 자동화된 토큰 린팅과 배포 전 검증으로 시각적 회귀를 방지한다(Design System Token Management Tools 2025 연구). AI 기반 토큰 관리가 도입되어 최적 토큰 자동 제안, 실시간 준수 확인이 가능한 도구도 등장했다.

공공 웹에서는 이런 거버넌스 인프라가 거의 전무하다. 각 기관이 KRDS를 받아 독립적으로 구현하고, 구현 후 모니터링은 없다시피 한다. 이 구조에서 채택률 측정은 일종의 외부 감사(audit) 역할을 할 수 있다. 구현을 마친 사이트를 URL 한 줄로 검사해, 토큰이 실제로 쓰이고 있는지 수치로 보여주는 것. 내부 거버넌스가 약한 상황에서 외부 정량 측정이 대안 역할을 하는 셈이다.

물론 이것이 거버넌스 자체를 대신할 수는 없다. 측정이 있어도 개선 의지와 실행 역량이 없으면 수치는 수치로 끝난다. 하지만 "측정 없이는 개선도 없다(What gets measured gets managed)"는 원칙은 공공 웹 품질에도 그대로 적용된다. 채택률이라는 수치가 존재할 때, 그걸 기준으로 "이번 개편에서 채택률을 X%에서 Y%로 높인다"는 목표 설정과 추적이 가능해진다.

---

실제 분석에서 무엇이 보였나 — 관찰 패턴들

여러 공공 사이트를 분석하면서 반복적으로 보이는 패턴들이 있다. 통계적으로 검증된 데이터는 아니고, 어디까지나 현재까지의 관찰 노트다.

패턴 1: 색상 채택률의 양극화

분석 대상 사이트들은 크게 두 그룹으로 나뉘는 경향이 있다. 한쪽은 정부 블루 계열(#256EF4 및 그 변형)을 메인 색상으로 충실히 쓰는 사이트들 — 이 경우 핵심 색상 토큰 기준으로는 채택률이 높게 나온다. 다른 한쪽은 독자적인 기관 브랜드 색상(지자체의 상징색, 공공기관 특유의 색상 등)을 고집하는 사이트들 — 이 경우 KRDS 색상 토큰과의 일치율이 낮아진다. KRDS가 "정부상징을 사용하는" 기관의 시스템임을 감안하면, 기관 브랜드 색상과 KRDS 표준 색상 사이에서 어떻게 균형을 잡는지가 실제 도전 과제다.

패턴 2: 메인 페이지 vs. 내부 페이지의 채택률 격차

메인 페이지는 최근 개편에서 KRDS를 의식해 구성된 경우가 많다. 반면 내부의 신청 페이지, 게시판 상세 등 오래된 화면들은 토큰과 무관한 값이 남아있는 경우가 많다. 메인만 보면 채택률이 괜찮아 보이는데, 다중 페이지로 전체를 보면 평균이 크게 낮아지는 패턴이다. 이게 ViewCheck가 다중 페이지 분석을 기본으로 하는 이유 중 하나다.

패턴 3: 색상은 그런대로, 타이포는 약하다

상대적으로 색상 채택은 의식적으로 신경 쓰는 경향이 있다. 반면 타이포그래피(폰트 크기의 KRDS 기준값 준수, Pretendard GOV 서체 사용 여부)나 간격(8pt 그리드 기반 여백)은 신경을 덜 쓰는 경향이 있다. 개발할 때 색상은 "이 색이 맞는가"를 확인하는 편이지만, "이 폰트 크기가 KRDS 기준인가"는 잘 확인하지 않기 때문인 것 같다.

패턴 4: CSS 변수 사용 여부의 큰 차이

어떤 사이트는 :root { --color-primary: #256EF4; } 같은 CSS 변수를 정의해두고 전체에서 참조한다. 어떤 사이트는 같은 색상값을 수십 개 CSS 파일에 하드코딩해뒀다. 전자는 토큰 구조를 실제로 구현한 것이고, 후자는 값이 우연히 일치하는 것에 가깝다. 앞서 말했듯 현재 측정이 이 둘을 완전히 구분하지 못하는 것은 인정해야 하는 한계다.

이 패턴들을 모아보면, 채택률 측정이 단순 수치 그 이상의 정보를 담고 있다는 걸 알 수 있다. 어떤 카테고리가 약한지, 어떤 페이지 유형이 떨어지는지, 체계적 구현인지 임시방편 구현인지 — 이런 구조적 정보가 수치 속에 녹아있다. 이걸 잘 읽어내는 것이 채택률 분석의 진짜 가치라고 생각한다.

---

'enrichDSWithTokens'라는 이름의 함수 — 기술적으로 어떻게 구현되나

이 글의 독자 중 개발자가 있다면, 조금 더 기술적인 이야기를 해보겠다. ViewCheck 내부에서 디자인 토큰 채택률 계산을 담당하는 함수의 이름은 enrichDSWithTokens다.

이 함수는 DS 규칙 판정이 끝난 직후 호출된다. 입력은 각 요소의 computed style 데이터다. 함수 내부에서는 크게 세 단계가 일어난다.

1. KRDS 토큰 테이블 로드: KRDS HTML Kit에서 파싱해 만든 토큰 사전(키: 토큰 이름, 값: 실제 값). 색상, 타이포, 간격 등 카테고리별로 관리된다.

2. CSS 값 → 토큰 역매핑: 추출된 computed style 값을 토큰 테이블에서 역방향으로 검색한다. #256EF4가 있으면 KRDS color-primary 토큰에 해당한다는 식으로. 허용 오차(tolerance)를 적용해 색상 포맷 변환(hex ↔ rgb) 차이를 흡수한다.

3. 채택률 메타데이터 생성: 카테고리별로 "전체 토큰 중 채택된 토큰 수"를 집계해 비율로 환산한다. 이 메타데이터는 DS 규칙 판정 결과에 부속 정보로 첨부되어, 분석 카드 렌더링 시 표시된다.

enrichDSWithTokens는 흥미롭게도 규칙 판정 결과의 통과/미통과 상태 자체를 바꾸지 않는다. 어디까지나 메타데이터를 추가하는 역할이다. DS 규칙 판정은 DS 규칙 판정대로 if/else 로직으로 돌고, 채택률 수치는 그 과정에서 수집된 CSS 데이터를 재활용해 별도로 계산한다. 이 설계는 "채택률이 낮다고 해서 DS 규칙이 자동으로 미통과가 되는 건 아니다"는 의도적 분리다. 채택률과 규칙 준수는 관련이 있지만 동일하지 않다.

현재 이 함수에서 개선 작업 중인 부분들이 있다. CSS 변수 참조 감지 로직, 다크모드 대응 토큰 처리, 타이포그래피 토큰 매핑 정확도 향상 등이다. "현재 구현이 완성됐다"고는 전혀 말할 수 없는 상황이다. 코드 자체가 지금도 실험 중이다.

---

채택률을 어떻게 읽어야 하나 — 숫자를 해석하는 법

채택률 수치가 나왔을 때, 어떻게 해석해야 할까. 이것도 우리가 계속 고민하는 부분이다.

단순히 "채택률이 높을수록 좋다"고 말하는 건 맞지도 않고 유익하지도 않다. KRDS 디자인 시스템의 구조를 생각해보자. 색상 토큰 586개 중 실제로 한 사이트에서 모두 쓰이는 경우는 없다. 대부분의 토큰은 특정 컴포넌트나 상태(hover, focus, disabled 등)를 위해 정의된 것이라, 그 컴포넌트가 없는 페이지에서는 당연히 등장하지 않는다. 로그인 페이지가 없는 사이트에서 로그인 폼 관련 토큰이 "미채택"으로 나오는 건 당연한 일이다.

그래서 채택률을 볼 때는 몇 가지 맥락이 필요하다.

컴포넌트 존재 여부 기준: 해당 페이지에 어떤 컴포넌트가 있는지 먼저 파악한 다음, 그 컴포넌트에 해당하는 토큰이 채택됐는지를 본다. 버튼이 있다면 버튼 색상 토큰이 맞는지, 폼이 있다면 인풋 색상 토큰이 맞는지. 이게 더 의미있는 채택률이다.

카테고리별 해석: 색상 채택률 37%보다 "핵심 색상 토큰(primary, text, background) 채택률은 82%지만 상태 색상(error, warning, success)은 12%"처럼 나누는 게 더 유용하다. 어느 카테고리가 약한지 보여야 개선 방향이 나온다.

페이지 유형별 해석: 메인 페이지의 채택률과 신청 페이지의 채택률을 분리해서 봐야 한다. 전체 평균이 60%라도 메인은 80%, 신청 페이지는 40%라면 우선 개선 대상이 어디인지 명확해진다.

시계열 비교: 개편 전과 후, 분기별 채택률 변화를 추적하는 것이 단일 시점 수치보다 훨씬 가치 있다. "이번 개편으로 채택률이 23%포인트 올랐다"는 이야기가 "채택률 67%"라는 절대 수치보다 더 의미 있는 정보다.

이 맥락들을 함께 제공하는 것이 ViewCheck 분석 카드의 목표다. 숫자를 던지는 게 아니라, 숫자를 읽는 방법을 함께 제공하는 것. 그게 "채팅으로 묻고 근거 있는 답을 받는" 경험의 일부이기도 하다.

---

토큰 채택률과 KRDS 846규칙의 관계 — 전체 맥락 속에서

ViewCheck LLM 분석의 24가지 분석 기능 중 하나가 디자인 스타일(DS) 분석이고, 채택률은 그 안의 메타데이터다. 전체 맥락에서 이 기능이 어디에 위치하는지 정리해보자.

846개 규칙 중 DS 카테고리의 120개는 색상·타이포그래피·간격·레이아웃·그림자·반경 같은 시각적 스타일의 KRDS 기준 준수를 판정한다. 채택률은 이 120개 규칙 판정의 근거 데이터이자, 규칙 판정을 넘어서는 추가 인사이트를 제공하는 부산물이다.

예를 들어 DS-001(배경색 KRDS 기준 준수) 규칙이 "미통과"로 나왔을 때, "이 페이지의 배경색 토큰 채택률 0%"가 함께 표시되면 "왜 미통과인가"를 더 직관적으로 이해할 수 있다. 반대로 채택률 수치 없이 "DS-001 미통과"만 있으면 "어떻게 고치면 되는가"의 실마리가 덜하다.

또 24개 분석 카드 중 'KRDS 비교' 카드에서는 해외 공공 디자인 시스템(GOV.UK, USWDS 등)과의 비교 맥락도 제공한다. 이때 "우리 사이트가 KRDS 색상 토큰을 37% 채택했다 — GOV.UK는 자체 색상 팔레트를 더 단순화해 접근성을 높인다"처럼 비교 문맥을 연결하면, 단순 수치가 더 풍부한 의미를 갖게 된다.

전체 그림에서 채택률 측정은 "KRDS 규칙을 얼마나 따랐는가"(통과/미통과 수치)와 "KRDS 디자인 언어를 얼마나 사용했는가"(채택률 수치) 두 차원을 동시에 보여주는 시도다. 둘이 다를 수 있다는 게 핵심이다 — 규칙은 통과했지만 토큰은 쓰지 않았거나(값이 우연히 일치), 토큰을 쓰고 있지만 ARIA나 구조 문제로 규칙은 미통과인 경우 등.

---

앞으로의 연구 방향 — 더 정확한 측정을 향해

솔직하게 말하면, 현재의 채택률 측정은 "1차 시도"에 가깝다. 앞으로 개선하고 싶은 방향들이 분명히 있다.

CSS 변수 참조 추적: var(--color-primary) 같은 CSS 변수 참조 여부를 파싱해, 진정한 토큰 기반 구현과 값 우연 일치를 구분한다. 이걸 할 수 있으면 "토큰 변수를 통한 채택률"과 "값 기준 채택률" 두 수치를 함께 보여줄 수 있게 된다.

상태별 측정: 요소의 hover, focus, active, disabled 상태별로 토큰이 올바르게 적용됐는지 측정한다. 지금은 정적 스냅샷 기준이므로, Playwright를 이용해 상태를 트리거한 뒤 스타일을 캡처하는 방식을 실험 중이다.

버전별 토큰 비교: KRDS 버전이 올라갈 때 토큰 값 변경 사항을 추적하고, 이전 버전 토큰을 쓰는 사이트를 식별해 "업데이트 필요한 토큰"을 알려주는 기능. 현재는 최신 버전 기준만 있다.

타이포그래피·간격 매핑 정확도 향상: 색상만큼 명확하지 않은 타이포·간격 토큰 매핑의 정확도를 높이기 위한 컨텍스트 기반 추론. 예를 들어 "이 텍스트 요소의 font-size: 16px"를 본문 영역으로 판단하면 KRDS 기준 본문 폰트 크기와 비교하고, 헤딩 영역으로 판단하면 헤딩 기준과 비교하는 식이다.

다중 사이트 비교 리포트: 같은 기관 유형(시청, 도청, 산하기관 등)끼리의 채택률 비교를 통해 "이 유형의 기관 평균 대비 우리 사이트의 위치"를 보여준다. 이걸 위해서는 충분한 샘플 데이터가 쌓여야 한다.

이 목록을 보면 아직 갈 길이 멀다. 하지만 1차 시도를 통해 "이런 방식이 가능하다"는 것을 확인했고, 그게 다음 단계의 출발점이다. 완성된 기능을 소개하기보다 "이렇게 실험 중이다"를 공유하는 게 이 시리즈의 톤이라고 처음에 말했는데, 채택률 측정이 그 톤에 가장 잘 맞는 주제 중 하나인 것 같다.

---

담당자 관점에서 — "채택률"이라는 숫자가 쓸모 있으려면

다시 공공 웹 담당자의 관점으로 돌아와 보자. 채택률 수치가 실제 업무에서 쓸모 있으려면 어떤 조건이 필요할까.

첫 번째는 이해 가능성이다. "KRDS 색상 토큰 채택률 37%"라는 숫자가 어떤 의미인지 담당자가 이해할 수 있어야 한다. 단순 비율 수치 외에 "KRDS 핵심 색상(정부 블루 계열) 채택률은 85%지만, 오류·경고 등 상태 색상은 거의 미채택(12%)"처럼 구체적 해석이 함께 있어야 실질적으로 도움이 된다.

두 번째는 실행 가능성이다. 채택률이 낮다는 것을 알았을 때, 다음 단계가 무엇인지 보여야 한다. "이 색상(#3a7bd5)을 KRDS color-primary-dark 토큰 값(#1d4dc2)으로 교체하면 해결"처럼 구체적 수정 제안이 있어야 담당자가 개발사에 명확히 요청할 수 있다. 막연한 "채택률을 높이세요"는 담당자에게 부담만 준다.

세 번째는 반복 측정 가능성이다. 한 번의 감사로 끝나는 게 아니라, 개편 전후나 분기별로 다시 측정해 변화를 추적할 수 있어야 한다. URL 한 줄로 재측정이 가능한 ViewCheck의 구조는 이 요건에 잘 맞는다. 다만 결과를 저장하고 이전 측정과 비교하는 이력 관리는 아직 개발 중이다.

네 번째는 신뢰성이다. 이 수치가 왜 나왔는지, 어떤 방법으로 측정했는지를 설명할 수 있어야 한다. "이 색상 값이 KRDS 토큰 테이블과 비교됐으며, 일치 토큰 목록은 다음과 같습니다"처럼 근거가 따라붙어야 담당자가 수치를 신뢰하고 이를 보고서에 인용할 수 있다. 수치만 있고 근거가 없으면 "이 숫자는 어떻게 나온 거냐"는 반문 앞에서 취약해진다.

이 네 가지 조건 중 현재 완전히 충족된 건 사실 많지 않다. 하나씩 채워가는 중이다. 그게 솔직한 현황이다.

---

디자인 토큰의 미래 — W3C 사양과 공공 영역으로의 파급

2025년 10월 W3C 디자인 토큰 커뮤니티 그룹이 첫 안정 사양(2025.10)을 발표한 건, 업계에서 꽤 의미 있는 사건이었다. Figma, Penpot, Sketch, Tokens Studio, Style Dictionary 같은 주요 도구들이 이미 이 사양을 지지하고 있다는 점에서(W3C Design Tokens Community Group, 2025. 10. 28.), 이 사양이 디자인-개발 간 공용어가 되는 건 시간문제로 보인다.

이 사양의 핵심은 "멀티 브랜드 디자인 시스템을 관리하는 팀들이 수십~수백 개의 토큰 파일을 수작업으로 관리하다 발생하는 드리프트, 오류, 유지보수 오버헤드를 해결"하는 데 있다. JSON 기반의 표준 포맷으로 토큰을 정의하면, 어느 도구에서든 읽고 쓸 수 있다. Figma에서 토큰을 정의하면 코드로 자동 변환되고, 코드에서 값을 바꾸면 Figma에 반영되는 양방향 연동이 표준 레벨에서 가능해진다.

공공 영역에서 이 사양의 파급은 조금 느릴 것이다. 기술 도입 속도, 조달 구조, 레거시 시스템 등이 장벽이다. 하지만 KRDS 자체가 Figma 파일로 공개되어 있고, 토큰 체계를 이미 내장하고 있다는 점에서, W3C 사양과의 연결 고리는 이미 형성되어 있다. 앞으로 KRDS HTML Kit이 W3C 표준 포맷으로 배포되거나, KRDS Figma 파일과 코드 연동이 표준화된다면, 채택률 측정의 정확도와 편의성도 함께 높아질 수 있다.

우리는 이 흐름을 지켜보면서, ViewCheck의 채택률 측정도 W3C 사양 기반으로 진화시킬 계획이다. KRDS 토큰이 W3C 표준 JSON으로 제공된다면, 우리가 직접 파싱하는 것보다 훨씬 정확하고 유지보수하기 쉬운 기준을 갖게 된다.

---

왜 토큰 채택률이 KRDS 준수의 '시작'인가

이 글을 마무리하면서 한 가지를 짚고 싶다. 토큰 채택률은 KRDS 준수 여부의 끝이 아니라 시작이다.

KRDS를 충실히 따른다는 것은 여러 레이어를 갖는다. 가장 표면적인 레이어가 "시각적으로 비슷하게 보이는가"이고, 그 아래에 "색상·타이포·간격 값이 기준과 맞는가"(토큰 채택률이 측정하는 영역)가 있다. 그리고 더 아래에는 "컴포넌트 구조와 ARIA 속성이 KRDS 기준에 맞는가"(CP 446개 규칙), "폼과 서비스 흐름이 기준 패턴을 따르는가"(BP 108개, SP 172개 규칙)가 있다.

토큰 채택률은 이 레이어들 중 중간 레이어를 측정한다. 시각적 유사도보다는 객관적이지만, 구조적 접근성보다는 표면적이다. 따라서 채택률이 높아도 컴포넌트 ARIA가 누락되거나 서비스 흐름이 잘못된 경우가 얼마든지 있을 수 있다. 반대로 채택률이 낮아도 구조적으로 탄탄한 사이트가 있을 수 있다.

그래서 ViewCheck는 채택률만 독립적으로 제공하지 않는다. DS 120개 규칙 판정 결과, CP·BP·SP 규칙 결과, 그리고 채택률 메타데이터가 함께 제공될 때 비로소 의미 있는 그림이 만들어진다. 퍼즐 조각 하나가 아니라, 퍼즐 전체를 보여주는 것이 우리의 목표다.

그리고 그 전체를 한 번에 보여주는 것이, URL 한 줄로 시작하는 24개 분석 카드의 역할이다. 채택률은 그중 하나의 카드에 속한 하나의 지표다. 작은 숫자지만, 그 숫자가 가리키는 방향이 크다는 것 — 그게 이 실험을 계속하는 이유다.

---

마무리 — 실측과 실험이 만드는 숫자

정리하자. ViewCheck LLM 분석에서 KRDS 디자인 토큰 채택률 측정은 이렇게 요약된다.

기준: 색상 토큰 586개, 전체 토큰 768개 (KRDS HTML Kit 직접 파싱 기준, 실측값) 방법: Playwright로 사이트 CSS(computed style) 추출 → KRDS 토큰 값과 비교 → 카테고리별 채택률 집계 위치: DS 120개 규칙 판정 과정에서 부산물로 계산되는 메타데이터 한계: 값 기준 비교이므로 CSS 변수 참조 여부 미구분, 동적 상태 미커버, 타이포·간격 정확도 제한 앞으로: CSS 변수 추적, 상태별 측정, 버전 관리, 다중 사이트 비교 방향으로 개선 중

이 숫자 하나를 믿고 "우리 사이트는 KRDS X% 준수"라고 단정하면 곤란하다. 그보다는 "이 수치를 기준으로 어떤 부분을 더 들여다봐야 하는가"의 출발점으로 쓰는 게 맞다.

그리고 그 출발점을 더 신뢰할 수 있게 만드는 일 — 측정 방법을 개선하고, 커버리지를 넓히고, 해석을 도와주는 맥락을 더하는 일 — 이 지금 우리가 하고 있는 연구다. 완성까지는 갈 길이 멀지만, 방향은 분명하다. 추측이 아닌 실측, 수치 없는 감이 아닌 데이터 기반의 대화. 그게 ViewCheck가 공공 웹 KRDS 진단에 기여하고 싶은 방식이다.

다음 편에서 이어가겠다.

---

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 웹 검색으로 검증했다. 가짜 출처나 미확인 인용은 포함하지 않는다. 국내 공식 자료와 해외 연구·기관 자료를 함께 실었다.

국내 — 공식 기준 / 정책자료

1. 행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 국가법령정보센터. https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침
2. KRDS(범정부 UI/UX 디자인시스템) 공식 사이트 — 디자인 토큰 가이드. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/html/site/style/style_07.html
3. KRDS 공식 — 디자인 토큰 전체 보기. https://www.krds.go.kr/html/site/style/style_07_popup.html
4. KRDS 공식 — KRDS 소개. https://www.krds.go.kr/html/site/utility/utility_01.html

해외 — 표준 / 연구 / 기관

5. W3C Design Tokens Community Group, "Design Tokens specification reaches first stable version" (2025. 10. 28). https://www.w3.org/community/design-tokens/2025/10/28/design-tokens-specification-reaches-first-stable-version/
6. W3C Design Tokens Community Group 공식 사이트. https://www.designtokens.org/
7. W3C Design Tokens Format Module 2025.10 (Draft). https://www.designtokens.org/tr/drafts/format/
8. Supernova, "State of Design Tokens 2024" 조사 보고서 (200명 이상 디자이너·개발자 대상). https://www.supernova.io/state-of-design-tokens
9. Supernova, "Navigating the Future of Design Tokens: Insights from Supernova's 2024 Webinar". https://www.supernova.io/blog/navigating-the-future-of-design-tokens-insights-from-supernovas-2024-webinar
10. DOOR3, "Establishing Effective Design Token Governance". https://www.door3.com/blog/design-token-governance
11. U.S. Web Design System (USWDS), Design Tokens 공식 문서. https://designsystem.digital.gov/design-tokens/
12. USWDS, Color Design Tokens (System / Theme / State). https://designsystem.digital.gov/design-tokens/color/system-tokens/
13. GOV.UK Design System 공식 — Colour. https://design-system.service.gov.uk/styles/colour/
14. GOV.UK Design System 공식 메인. https://design-system.service.gov.uk/
15. GitHub: dembrandt/dembrandt — Playwright 기반 웹사이트 디자인 토큰 추출 오픈소스 CLI. https://github.com/dembrandt/dembrandt
16. Project Wallace, CSS Design Tokens Analyzer. https://www.projectwallace.com/design-tokens

---