AI-Native 디자인 시스템 아이데이션 노트: 디자인 토큰을 '코드'가 아니라 '자산'으로 본다면

먼저 이 글의 성격부터 밝힌다. 이건 검증된 제안이 아니라 아이데이션 노트다. 새로운 표준을 발명하자는 게 아니라, 우리가 이미 쓰고 있는 패턴을 다른 형태로 번역해보면 어떻게 생겼는지 손으로 그려본 기록이다. 그리고 결론을 맨 앞에 박아둔다. 이 모든 변환이 만들어내는 "효율"은 중요하지만, 그것은 "디자인의 가치"를 전달하기 위한 수단이지 가치 그 자체가 아니다. 이 둘을 헷갈리지 않는 게 글 전체의 중심이다.

디자인 토큰을 다뤄봤다면, 사실 우리는 이미 세 가지 방식을 쓰고 있다. CSS 커스텀 프로퍼티(var()), SCSS의 맵과 @extend, 그리고 DTCG JSON의 {} 참조. 표현은 달라 보여도 본질은 똑같다. 값을 한 곳에 정해두고(원시값), 이름을 붙여 가져다 쓰고(별칭), 그 참조가 꼬리에 꼬리를 물어 상속처럼 흐른다.

문제는 이 "참조의 연쇄"가 문자열과 문법 관습으로만 존재한다는 점이다. 빌드 도구는 이걸 잘 풀어주지만, 우리가 직접 "이 색을 바꾸면 어디가 영향을 받지?"를 물어보거나(질의), 빠진 사실을 자동으로 채우거나(추론), 규칙 위반을 자동으로 잡아낼(검증) 수는 없다. 이 글은 그 암묵적인 상속 관계를, 컴퓨터가 질문하고 따져볼 수 있는 명시적인 그래프로 올려보면 무엇이 달라지는지를 정리한다.

핵심 질문은 하나다. 디자인 토큰을 "사람이 읽는 코드"가 아니라 "AI 에이전트가 질의·추론·검증할 수 있는 지식 자산"으로 두면 무엇이 가능해질까? 그리고 그 끝에서 한 번 더 못을 박는다. 자산화가 잘 될수록, 그것이 디자인의 가치가 아니라 수단일 뿐이라는 사실이 오히려 더 중요해진다.

이 글에 나오는 RDF/OWL/SHACL 같은 용어가 낯설어도 괜찮다. 디자이너는 "내가 매일 쓰는 토큰 구조를 컴퓨터가 따져볼 수 있게 적는 방식"으로, 개발자는 "지식 그래프 표준 3종 세트"로 읽으면 된다. 용어는 그때그때 풀어 설명한다.

---

1. 사실 우리는 이미 그래프를 쓰고 있다

낯선 이야기로 시작하지 않으려 한다. 아래 셋은 디자인 시스템을 다뤄본 사람이면 매일 보는 코드다.

/* (A) CSS 커스텀 프로퍼티: 변수 + cascade 상속 */
:root {
  --raw-blue-600: #2563EB;             /* 원시값: 실제 색 */
  --color-accent: var(--raw-blue-600); /* 별칭: "강조색 = 저 파랑" */
}
.button { background: var(--color-accent); }  /* 컴포넌트가 가져다 씀 */

// (B) SCSS: map + @extend 상속
$space: (1: 4px, 2: 8px, 3: 16px);
%inset { padding: map-get($space, 2); }
.card { @extend %inset; }

// (C) DTCG JSON: {} 참조 = 사실상의 상속
{ "color": { "accent": { "$value": "{color.blue.600}" } } }

셋 다 구조가 같다. (1) 진짜 값은 한 곳에만 두고, (2) 거기에 이름을 붙여 참조하고, (3) 그 참조가 연쇄되어 위에서 아래로 흐른다. 이게 이미 "그래프"다. 점(토큰)들이 화살표(참조)로 이어진 그림이니까. 단지 그 그림이 var()나 {} 같은 문법 속에 숨어 있어서, 우리가 그림 자체를 꺼내 질문할 수 없을 뿐이다.

그래서 "RDF/OWL로 바꾼다"는 말은 거창한 게 아니다. 숨어 있던 상속 그래프를, 꺼내서 질문할 수 있는 형태로 옮겨 적는 것. 딱 그만큼이다.

---

2. 그래서 정확히 뭘 바꾸나: 한 장짜리 대응표

왼쪽은 우리가 매일 쓰는 것, 오른쪽은 그걸 표준 문법(RDF 1.1 / OWL 2 / SHACL)으로 옮긴 것이다. 새로운 개념은 하나도 없다. 같은 걸 다르게 적었을 뿐이다.

가장 중요한 한 단어는 resolvesTo("~로 풀린다")다. var()나 {}가 하던 일에 이름을 붙인 것뿐인데, 이름이 생기는 순간 양방향으로 따라갈 수 있게 된다. "강조색은 결국 무슨 색이지?"(앞으로)와 "이 색을 쓰는 컴포넌트는 다 어디지?"(거꾸로)를 똑같이 물을 수 있다. 두 번째 질문이 바로 디자인 시스템에서 늘 어려웠던 영향도 분석이다.

---

3. 옮겨보면 이렇게 생겼다: 4층짜리 그림

토큰을 4개 층으로 쌓으면 흐름이 또렷해진다. 새로운 구조가 아니라, 잘 만든 토큰 시스템이 이미 따르는 그 계층이다.

Layer 0  원시값(RAW)   (= CSS의 --raw-*)
   │   예) raw:blue600 = "#2563EB", raw:n8 = 8   ("~의 한 종류다"로 종류를 부여)
   ▼
Layer 1  파운데이션   (= SCSS map / 팔레트)
   │   예) color:blue-600, space:2, radius:md   (resolvesTo = var()/{}로 위를 가리킴)
   ▼
Layer 2  시맨틱(의미)   (= --color-accent 류)
   │   예) sem:accent ("강조색")   (resolvesTo)
   ▼
Layer 3  컴포넌트   (= .button{ var(--..) })
       예) comp:button.bg ("버튼 배경")

이걸 실제 문법으로 적으면 이렇다. 한 줄 한 줄이 "주어 - 서술어 - 목적어" 한 문장이라고 보면 된다.

raw:blue600     a ds:ColorToken   ; ds:hex "#2563EB" ;
                ds:oklch "0.55 0.22 264" ; ds:wcagLargeOK true .  # CSS엔 없던 정보까지
color:blue-600  a ds:PaletteColor  ; ds:resolvesTo raw:blue600 .
sem:accent      a ds:SemanticColor ; ds:resolvesTo color:blue-600 .  # = --color-accent
comp:button.bg  a ds:ComponentToken; ds:resolvesTo sem:accent .      # = .button{ var(--color-accent) }

체인을 따라가 보자. 버튼 배경 → 강조색 → 팔레트의 blue-600 → 진짜 색 #2563EB. 실제 색은 맨 아래 딱 한 번만 적히고, 위층은 전부 "가리키기만" 한다. CSS의 cascade가 하던 일을, 이제는 눈에 보이는 길로 그린 것이다.

여기서 디자이너가 바로 체감할 이득이 하나 있다. CSS에서 --space-2: 8px와 --radius-md: 8px는 우연히 둘 다 8일 뿐, 서로 아무 관계가 없다. 그래프에선 둘 다 raw:n8(같은 8)을 가리키게 만들 수 있다. 그러면 "우리 그리드를 8px에서 6px로 바꾸자"가 노드 하나 수정으로 끝난다. 흩어진 8을 일일이 찾아 고칠 필요가 없다.

---

4. 추론과 검증: 기계가 대신 따져주는 것

여기서부터가 "그냥 변수"와 "지식 자산"이 갈리는 지점이다. 두 가지 새 능력이 생긴다.

(1) 추론: 안 적은 것도 알아낸다. "스페이싱은 숫자 토큰의 한 종류, 숫자 토큰은 토큰의 한 종류"라는 관계만 적어두면, space:2가 스페이싱이라고만 말해도 컴퓨터가 알아서 "그럼 얘는 숫자 토큰이자 토큰이기도 하네"를 채워 넣는다(이 일을 하는 엔진을 리저너라고 부른다). 사람이 모든 사실을 다 적지 않아도 되는 것이다.

(2) 검증: 규칙 위반을 결정적으로 잡는다. 지금까지 Stylelint나 빌드 플러그인으로 하던 토큰 점검을, 그래프용 규칙 검사기(SHACL, 그래프판 린터라고 보면 된다)로 옮긴다. 예를 들어 "컴포넌트 토큰은 반드시 시맨틱만 가리켜야 한다(원시값을 직접 쓰면 안 된다)" 같은 규칙은 이렇게 적는다.

# 층 건너뛰기 금지: 컴포넌트는 시맨틱만 가리킴 (그래야 다크모드 전환이 안전)
ds:ComponentChainShape a sh:NodeShape ;
    sh:targetClass ds:ComponentToken ;
    sh:property [ sh:path ds:resolvesTo ;
        sh:minCount 1 ; sh:maxCount 1 ; sh:class ds:SemanticToken ;
        sh:message "컴포넌트 토큰은 시맨틱만 가리킬 것 (raw·팔레트 직접 참조 금지)" ] .

이게 평범한 린트보다 나은 점은 단 하나, 관계를 따라가며 검사한다는 것이다. 평면적인 JSON/CSS에선 "이 값이 4의 배수인가?" 같은 값 하나짜리 검사가 쉽다. 그래프에선 "버튼 글자색과 배경색의 대비가, 다크모드로 바꿔도 WCAG 기준을 넘는가?"처럼 여러 단계를 건너뛴 관계를 한 줄로 검사할 수 있다. 디자이너가 늘 신경 쓰지만 자동화하기 어려웠던 종류의 점검이다.

---

5. 기존 워크플로는 그대로 둔다 (headless)

여기서 가장 안심해도 되는 부분. 디자이너의 작업 방식은 안 바뀐다. 빌드 파이프라인 구조도 Style Dictionary 때와 똑같다. 달라지는 건 입력이 "검증·추론을 한 번 거친 그래프"라는 것뿐이다.

tokens + 온톨로지 + 규칙  (단일 원천 SSOT, 플랫폼 독립 = headless)
   │
   │  ① 규칙 검사(SHACL)로 일단 걸러내고
   │  ② 리저너로 참조를 전부 풀어둠
   ▼
resolved (각 토큰의 최종 값)
   │
   ├─ tokens.css (:root{})
   ├─ DTCG JSON (Figma 연동)
   ├─ iOS / Android 토큰
   └─ 영향도 질의용 DB

특히 JSON-LD라는 형식이 기존 DTCG JSON과 그래프 사이의 다리가 된다. 덕분에 디자이너는 여전히 익숙한 JSON을 편집하고, 시스템은 그걸 그래프로 읽어 검증·추론을 돌린다. 편집 경험은 그대로, 뒤에서만 똑똑해지는 셈이다.

---

6. 그래서 왜 이 고생을 하나: AI-Native 자산화

여기가 글의 무게 중심이다. 위의 변환이 가치 있는 이유는 "CSS보다 깔끔해서"가 아니다. AI 에이전트가 일하는 환경에서, 디자인 토큰이 비로소 "자산(asset)"이 되기 때문이다. 여기서 자산이란, 다시 쓰고·질문하고·검증하고·쌓아둘 수 있는 형태로 고정된 지식을 말한다.

AI 에이전트 관점에서 이게 무슨 의미인지, 네 장면으로:

• 계약서가 되는 토큰: LLM에게 UI를 맡길 때, "강조색은 신뢰감 있게 써주세요" 같은 모호한 산문 대신 기계가 읽는 계약을 건넨다. "강조색이 뭐야?"라고 물으면 #2563EB라는 값뿐 아니라 *그에 딸린 규칙(팔레트에서 딱 하나, 대비 기준 준수)*까지 한 번에 받는다.
• 영향도 분석이 질문 한 줄이 됨: "이 파랑을 바꾸면 어떤 컴포넌트가 깨지지?"가 resolvesTo를 거꾸로 따라가는 질의 한 방으로 끝난다. 디자인 시스템 운영에서 제일 무서운 "어디가 영향받는지 모르겠음"이 사라진다.
• AI가 만든 결과의 자동 검증: 에이전트가 새 컴포넌트 토큰을 만들어 넣으면, 규칙 검사가 층 건너뛰기·대비 위반·그리드 이탈을 즉시 잡는다. "그럴듯해 보이지만 틀린" 결과가 문 앞에서 멈춘다.
• 다른 지식과 연결됨: 토큰 그래프를 브랜드·제품·컴포넌트 지식과 이어 붙이면, 토큰이 고립된 빌드 부산물이 아니라 조직 지식의 일부가 된다.

다만 비용도 정직하게 적는다. 첫째, 도구 단절: Figma나 Style Dictionary는 그래프를 모른다. JSON-LD 다리를 유지보수해야 한다. 둘째, 추론의 한계: 간단한 추론은 가볍지만, 복잡한 논리는 별도 엔진이 필요하다. 셋째, 검증된 ROI 없음: "왜 아무도 안 했나"에 대한 답이 여전히 "들이는 품에 비해 이득이 불확실해서"일 수 있다. 다시 강조하지만 이건 아이데이션이지 "지금 도입하라"는 권고가 아니다.

---

7. 어디까지 자동화하고, 무엇은 사람이 남기나

이 방식으로 컴포넌트 단위의 국소적 정의는 깔끔하게 된다. 다만 모바일이 아닌 데스크탑 환경의 레이아웃은 복잡성이 한 단계 더 높다. 단적인 예로 Primary를 남발하면 Contrast가 죽고, 결국 Primary가 Primary 구실을 못 한다. 이런 것도 기술적으로 패턴화할 수는 있겠지만, 모든 자동화가 그렇듯 실무에서는 트레이드오프를 따져 "수작업이 나은 영역"의 경계를 잘 긋는 일이 더 중요하다.

개인적인 이야기를 덧붙이면, 나는 MCP가 등장한 초기부터 Claude Desktop과 Obsidian MCP를 연결해 쓰며 여기 Semantic Graph까지 흘러왔다. 시스템이 적성에 맞았다. 그런데 디자인을 좋아하는 사람으로서 여전히 풀리지 않는 의문이 있다. 모든 디자이너가 Semantic Web 언어를 공부해야 하는가?

솔직히 나도 RDF/OWL/SHACL의 문법을 다 알지는 못한다. 그보다는 차라리 기호논리학이나 그래프 이론을 익히는 편이 더 오래 남는다고 본다. 문법은 도구와 함께 바뀌지만 그 아래의 사고방식은 잘 바뀌지 않기 때문이다. 그리고 사람을 만나 공감할 줄 아는 능력에서 나오는 인문학적 소양이나 디자인 해석 능력은, 적어도 지금의 AI로 대체하기 가장 어려운 부분이다.

기술의 무게중심은 계속 옮겨간다. 아이폰의 리퀴드 디스플레이가 나오기 전, PPI(Pixel Per Inch)가 낮던 시절에는 Pixel Perfection을 위한 8x 그리드 패턴이 정말 중요했다. 하지만 지금은 그 정도는 하네스로도 충분히 맞춘다. 그래서 더 중요해지는 질문은 따로 있다. 이 서비스는 누구의 어떤 맥락에서 쓰이는가? 가령 시력이 좋지 않고 디자인 문법에 익숙하지 않은 시니어를 위한 모바일이라면, 그들을 위한 디자인 시스템은 무엇이어야 하는가? 그리고 그 서비스가 사용자에게 진짜 "돌봄"으로 느껴지는가, 아니면 업셀링을 강요하는 다크패턴으로 느껴지는가?

결국 더 중요한 건 토큰 그래프가 얼마나 정교한가가 아니라, 프로덕트가 고객과 사용자의 어느 맥락에서 어떤 형태로 가닿는가다. 자동화는 그 답을 대신 내주지 않는다.

---

8. 효율은 중요하나, 디자인 가치 전달을 위한 수단이다

오해를 막기 위해 분명히 해두자. 효율은 중요하다. 일관성·검증·영향도 추적은 좋은 디자인이 사용자에게 흐트러지지 않고 가닿게 하는 실제 힘이다. 다만 자산화가 똑똑해질수록 함께 또렷이 해둘 게 있다. 이 그래프가 만드는 효율은 디자인의 "가치" 그 자체가 아니라, 그 가치를 전달하기 위한 "수단"이다.

그래프가 담아내는 것은 **결정의 결과(what)**다. "강조색은 blue-600, 패딩은 8px." 담아내지 못하는 것은 **결정의 이유(why)**다. "왜 우리 브랜드는 하필 이 파랑인가? 사용자가 이걸 보고 무엇을 느끼길 바라는가?" 효율은 전자를 빠르고 정확하게 실어 나르지만, 후자를 만들어내지는 못한다.

규칙 검사기는 "규칙을 어겼다"는 말해주지만, **"그 규칙 자체가 틀렸다"**는 절대 말해주지 못한다. 그리고 후자가 바로 디자인의 본령이다. 그래서 효율은 가치를 대체하는 게 아니라 섬길 때 제값을 한다.

그래서 올바른 자리 배치는 이렇다.

[브랜딩]  왜 / 무엇을 느끼게   (사람의 고차원 판단, 자산화 대상이 아님)
   │  결정이 아래로 흐른다
   ▼
[토큰 그래프 자산]  그 판단을 일관·효율·검증가능하게 "집행"
   │  컴파일된다
   ▼
[플랫폼 산출물]  CSS / iOS / Figma   (집행의 말단)

피해야 할 함정 두 가지로 닫는다. 첫째, 토큰 물신화: 그래프는 완벽하고 검사도 다 통과하는데 정작 제품은 아무 감흥이 없는 경우. 효율을 가치로 착각한 것이다. 둘째, 시스템이 브랜드를 가두는 것: 규칙이 너무 빡빡해서, 브랜드가 새로 시도하려는 정서를 규칙 위반으로 막아버리는 경우. 수단이 목표의 발목을 잡은 것이다.

한 발 물러나 비즈니스의 눈으로 보면 이 구분은 더 무겁다. 서비스와 프로덕트를 회계 장부로만 따지면 디자인은 손쉽게 "비용"으로 뭉개진다. 인식이 많이 나아졌다지만, 여전히 디자인을 마케팅이나 프로덕트의 하위 부서쯤으로 여기는 시선이 남아 있어 안타깝다. 한편으로는 그게 비즈니스의 본질이라는 생각도 든다. 비즈니스에서 모든 중요도는 결국 "재무제표로 얼마나 쉽게 치환되는가"에 의존하기 때문이다. 그래서 2026년이 의미심장하다. AX(AI Transformation)의 해이자, 그동안 장부에 잘 잡히지 않던 무형의 가치가 다시 조명받는 변곡점이기도 하다. 모든 부서가 저마다 자신의 가치를 증명하려 애쓰는 지금, 디자인 역시 운영 비용이 아니라 매출 성과로 인정받을 수 있는 구조를 만들어갈 수 있기를 바란다. 토큰을 자산으로 만드는 이 모든 작업도, 끝이 "비용 절감"이 아니라 "가치 증명"으로 이어질 때에야 비로소 제 의미를 갖는다.

한 문장으로 요약하면 이렇다. AI-Native 디자인 시스템은 발명이 아니라 번역이다. 우리가 이미 쓰던 변수·상속 패턴을, 질문하고 추론하고 검증하고 쌓을 수 있는 그래프 자산으로 옮기는 것. 그렇게 얻는 효율은 분명 중요하지만, 어디까지나 디자인의 가치를 전달하기 위한 수단이다. 가치 그 자체는 브랜딩의 몫이며, 끝까지 그래프 바깥에 남는다. 디자인 시스템은 수단이지, 목표가 아니다.

---

출처 노트

이 글이 근거로 삼은 1차 출처는 다음과 같다.

디자인 토큰 · UI 온톨로지

• DTCG 디자인 토큰 명세: W3C 공지, Format 2025.10
• 토큰 레이어링: Contentful, "Design token system"
• UI 온톨로지: UI2Ont (Springer), Ontology-Enhanced UI Survey (IGI), Cameleon Reference Framework (W3C)
• Storybook + LLM: Codrops, "Supercharge your design system with LLMs and Storybook MCP"

그래프 검증 · LLM grounding (SHACL/RDF)

• LLM + SHACL: arXiv 2506.10678, xpSHACL arXiv 2507.08432
• SHACL과 OWL의 역할 구분: spinrdf, "SHACL and OWL"
• 그래프 기반 코드 grounding: SemanticForge arXiv 2511.07584

표준 · 직렬화

• JSON-LD: W3C JSON-LD Syntax
• SPARQL property path → recursive SQL: CEUR Vol-1087

검증 주의: 위 1차 출처 중 일부(designtokens.org·w3.org·일부 학술 호스트)는 수집 당시 HTTP 403으로 본문 직접 확인이 불가해 다중 2차 출처 교차확인으로 라벨링됐다. 2026 arXiv ID 일부는 미피어리뷰다. load-bearing 인용 전 원문 재확인을 권장한다.