사람이 인터페이스를 볼 때, 버튼, 간격, 색상, 그리고 레이아웃의 전반적인 분위기와 같은 이미지를 봅니다. 우리는 그것에 대해 거의 생각하지 않습니다. 그림을 통해 디자인을 인지하는 것은 완전히 자연스럽게 느껴지기 때문입니다.

언어 모델 (Language Model)에게는 그러한 채널이 없습니다. 모델은 결코 화면을 보지 않습니다. 그리고 그 사실은 여러분이 모델에게 디자인을 제공하는 방식의 거의 모든 것을 변화시킵니다.

모든 것은 숫자가 된다

현대의 멀티모달 (Multimodal) 모델들이 이 문제를 해결한다고 생각하기 쉽습니다. 모델이 이미지로 작업할 수 있으므로, 단순히 모델에게 스크린샷을 제공하면 인간이 하는 방식대로 디자인을 볼 수 있을 것이라고 말이죠.

하지만 멀티모달리티 (Multimodality)가 핵심은 아닙니다. 텍스트, 이미지, 소리 등 여러분이 모델에게 무엇을 제공하든, 내부적으로는 모두 숫자가 됩니다. 모델은 이미지를 이미지로서 다루지 않습니다. 이미지의 수치적 표현 (Numeric representation)을 다룹니다.

따라서 질문은 모델이 디자인을 "보느냐"가 아닙니다. 모델이 최종적으로 어떤 수치적 표현을 갖게 되느냐가 핵심입니다.

그리고 바로 이 지점에서 스크린샷은 한계를 드러냅니다. 이미지는 픽셀을 설명하는 숫자가 됩니다. 여기는 더 밝고, 저기는 더 어둡고, 여기에는 경계선이 있다는 식입니다. 이를 통해 모델은 간격이 약 16픽셀이고 색상이 어떤 종류의 파란색이라는 것을 대략적으로 추측할 수 있습니다. 하지만 그것은 이미지로부터 얻은 추측일 뿐, 디자인에 대한 지식은 아닙니다.

정확히 어떤 숫자인가

그 차이는 대략 책 페이지를 찍은 사진과 책의 텍스트 자체 사이의 차이와 같습니다.

텍스트 역시 사진 속에 들어있습니다. 하지만 텍스트를 사용하려면 먼저 글자를 인식하고, 단어를 다시 조합하며, 문단이 어디서 시작되는지, 어디가 단순히 페이지 위의 그림자인지를 파악해야 합니다. 텍스트를 직접 다루는 것은 이러한 모든 추측 과정을 건너뜁니다.

디자인도 마찬가지입니다. 스크린샷이나 스타일이 포함된 HTML은 모델이 형태 (Form)로부터 의도 (Intent)를 재구성하게 만듭니다. 하지만 여러분은 명시적으로 기술된 의도를 모델에게 직접 전달할 수 있습니다. 그것이 바로 디자인 토큰 (Design tokens)이 하는 역할입니다.

디자인 토큰 (Design token)은 픽셀이나 CSS의 한 줄이 아닙니다. 그것은 이름을 가진 의미 있는 값입니다. 예를 들어, 주요 동작 색상 (primary action color), 표면 배경 (surface background), 카드 내부의 패딩 (padding), 패널의 모서리 반경 (corner radius) 같은 것들입니다. 토큰은 팀이 디자인에 대해 대화하는 방식 그대로 디자인을 설명합니다. 즉, "바로 여기 있는 이 파란색"이 아니라, "주요 동작이 있는 모든 곳에 사용되는 주요 동작 색상"이라고 말하는 것입니다.

공교롭게도, 언어 모델 (Language model)의 기본 단위 또한 토큰 (token)이라고 불립니다. 이 둘은 같은 것은 아닙니다. 모델 토큰은 텍스트의 덩어리이고, 디자인 토큰은 이름이 붙여진 디자인 값입니다. 하지만 이 둘은 동일한 지점에서 만납니다. 둘 다 의미를 기계가 처리할 수 있는 구조로 변환하는 것에 관한 것이기 때문입니다.

HTML과 CSS가 노이즈인 이유

여러분은 이렇게 반론할 수도 있습니다. HTML과 CSS도 텍스트이며, 모델은 그것들을 아주 잘 읽는다고 말이죠. 실제로 그렇습니다. 문제는 모델이 CSS를 이해하지 못하는 것이 아닙니다. 문제는 HTML과 CSS가 디자인과 아무런 관련이 없는 것들로 가득 차 있다는 점입니다.

마크업 (Markup), 중첩 (nesting), 유틸리티 클래스 (utility classes), 레이아웃 래퍼 (layout wrappers), 그리고 목업 (mockup)에서 수동으로 반복해서 복사해 온 색상 값들까지. 디자인이 그 안에 들어있긴 하지만, 노이즈 속에 파묻혀 있습니다. 서로 다른 세 곳에 있는 동일한 색상이 사실은 하나의 "주요 색상 (primary color)"라는 것을 알아내기 위해, 모델은 매번 처음부터 다시 추측해야 합니다.

토큰은 이러한 노이즈를 제거합니다. 남는 것은 오직 디자인과 그 구성 요소들 사이의 관계뿐이며, 모델은 더 이상 아무것도 재구성할 필요가 없습니다.

실험: 하나의 작업, 두 가지 경로

추상적인 논쟁을 하기보다, 우리는 작은 블라인드 테스트 (blind experiment)를 진행했습니다.

우리는 동일한 모델에서 실행되는 여러 독립적인 에이전트 (agents)들에게 작업을 부여했으며, 이들을 두 그룹으로 나누었습니다. 디자인 작업은 모두에게 동일했습니다. 바로 제품 카드 (product card)를 만드는 것이었습니다. 오직 프롬프트 (prompt)만 달랐습니다.

첫 번째 그룹은 직접적인 과제를 받았습니다:

이미지, 제목, 가격, 별점, 그리고 구매 버튼이 포함된 제품 카드를 생성하세요.
HTML과 별도의 CSS 파일을 반환하세요.

두 번째 그룹은 정확히 동일한 작업을 받았지만, 한 가지 요구 사항이 추가되었습니다. 디자인을 먼저 토큰으로 설명하라는 것이었습니다.

이미지, 제목, 가격, 별점, 그리고 구매 버튼이 포함된 제품 카드(product card)를 만드세요. HTML과 별도의 CSS 파일을 반환하세요.

...

두 그룹 사이에는 다른 점이 전혀 없었습니다. 어느 그룹도 다른 접근 방식에 대해 알지 못했으며, 결과가 비교될 것이라는 사실도 몰랐습니다. 차이점은 정확히 한 가지였습니다. 모델이 디자인 어휘(design vocabulary)를 먼저 구축해야 하는지, 아니면 마크업 (markup)으로 바로 넘어갈 수 있는지의 여부였습니다.

경로 1: HTML과 CSS로 직행

첫 번째 관찰 결과는 우리의 예상을 빗나갔습니다. 직접 모드 (direct mode)에서도 현대적인 모델은 속성 (properties)에 색상을 바로 작성하지 않습니다. 모델은 스스로 값을 CSS 변수 (CSS variables)로 추출합니다:

:root {
  --color-surface: #ffffff;
  --color-accent: #4f46e5;
...

따라서 모델은 "변수 대 매직 넘버 (variables versus magic numbers)" 논쟁을 스스로 상당 부분 해결합니다. 하지만 자세히 살펴보면 직접적인 접근 방식이 여전히 부족한 부분이 보입니다.

첫째, 각 변수는 이중 역할을 수행합니다. --color-accent는 팔레트(palette)의 특정 색상이면서 동시에 "주요 동작 (primary action)" 역할을 합니다. 하나의 이름이 "이것은 어떤 색인가"와 "이것은 무엇을 위한 것인가"라는 두 가지 별개의 질문에 답합니다. 이 질문들이 융합되어 있는 한, 하나를 건드리지 않고 다른 하나에 답할 수 없습니다. 팔레트에서 브랜드 색상을 변경하면 그 역할도 함께 변경됩니다. 역할을 다른 색상으로 재할당하면 다시 동일한 이름을 편집하게 됩니다. 또한 코드의 어떤 부분도 특정 색상과 그 호버 (hover) 변형이 하나의 브랜드 색상과 그 명도(shade)라는 사실을 알려주지 않습니다. 그 연결 고리는 오직 그것을 작성한 사람의 머릿속에만 존재합니다.

둘째, 일부 값은 여전히 컴포넌트 (components) 내에 하드코딩 (hardcoded)되어 있었습니다. 여기서는 반지름 변수 옆에 border-radius: 12px가 놓여 있고, 저기서는 아무 곳과도 연결되지 않은 독립적인 rgba(...)로 작성된 outline 색상이 나타납니다.

셋째, 그리고 이것이 가장 중요한 점인데, 독립적인 실행 결과들이 서로 일치하지 않았습니다. 서로 다른 변수 이름(--color-accent 대 --color-primary), 서로 다른 반경(18px 대 16px), 어떤 생성 결과에는 버튼 그림자(shadow)가 추가되었지만 다른 결과에는 포함되지 않았습니다. 각 에이전트(agent)는 자신만의 어휘를 새로 만들었습니다. 공유된 언어는 나타나지 않았습니다.

두 번째 경로: 토큰 우선 (Tokens First)

두 번째 방식은 다릅니다. 컴포넌트 스타일(component styles)에는 원시 값(raw values)이 전혀 없으며, 오직 토큰(tokens)에 대한 참조만 존재합니다:

.card {
  background: var(--component-card-default-background);
  border-radius: var(--component-card-default-radius);
...

이러한 이름들 뒤에는 직접적인 방식(direct version)이 하나로 합쳐버렸던 두 가지 질문을 분리하는 구조가 자리 잡고 있습니다. "이것은 어떤 색인가"는 프리미티브(primitives)에 존재합니다. "이것은 무엇을 위한 것인가"는 시맨틱(semantics)에 존재합니다. 원시 값은 프리미티브에 정확히 한 번만 나타나며, 그 이후의 모든 것은 참조(references)입니다:

{
  "primitive": {
    "color": {
...

이 형식은 명시적이고 모호하지 않습니다. 모든 토큰은 자신의 유형(type)을 명시하며, 다른 토큰에 대한 참조는 인간과 도구 모두에게 명확합니다. 모델은 이러한 형식을 오독 없이 파싱(parse)할 수 있는데, 이는 더 이상 추측할 것이 남아있지 않기 때문입니다.

하지만 개별 파일 자체가 흥미로운 부분은 아닙니다. 독립적인 실행들 사이에서 어떤 일이 일어났는지가 핵심입니다. 이 모드에서의 모든 에이전트는 거의 동일한 구조를 구축했습니다. 세 가지 계층: primitive, semantic, component. 동일한 역할: 배경을 위한 surface, 주요 동작을 위한 action, 텍스트를 위한 text-primary 및 text-secondary, 평점을 위한 rating. 팔레트(palettes)는 달랐지만, 골격(skeleton)은 동일했습니다.

서로 다른 에이전트, 동일한 작업, 그리고 그 결과로 일관된 디자인 어휘가 도출되었습니다. 직접적인 방식(direct mode)은 결코 그 단계에 도달하지 못했습니다.

실험이 보여준 것

이 실험은 카드가 더 "예쁘게" 나오는지 여부를 측정한 것이 아닙니다. 모든 변형(variants)은 괜찮아 보였습니다. 실험은 다른 것을 측정했습니다. 모델이 디자인을 얼마나 안정적이고 일관되게 설명하는지를 측정했습니다.

직접 모드 (direct mode)에서 모델은 값을 변수로 가져오지만, 변수 이름은 색상과 그 역할을 함께 담고 있으며, 실행할 때마다 어휘 (vocabulary)가 다르게 나타납니다. 토큰 모드 (token mode)에서는 색상과 역할이 별도의 계층에 위치하며, 컴포넌트는 원시 값 (raw values)을 가지지 않고, 독립적인 실행들이 하나의 어휘로 수렴합니다.

그 이유는 위에서 이미 다룬 것과 같습니다. 토큰은 모델에게 생각하는 방식을 제공합니다: 기본 값 (base values)을 먼저, 그다음 역할 (roles), 그리고 사용처 (usage) 순서로 말이죠. 이는 어쨌든 모델이 데이터와 작동하는 방식에 더 가깝기 때문에, 결과가 더 예측 가능하게 나옵니다.

형식 (format)에 관한 한 가지 더 얻을 수 있는 교훈이 있습니다. 모델은 구조를 자신 있게 구축하지만, DTCG 자체의 세부 사항에서는 실수를 합니다. 단 한 번의 토큰 실행도 첫 시도에 유효하지 않았습니다. 어떤 실행에서는 차원 (dimensions)이 값-및-단위 (value-and-unit) 쌍 대신 문자열로 작성되었고, 다른 실행에서는 기본 그룹 (primitive groups)이 유형별로 그룹화되지 않았습니다. 하지만 이는 바로 도구 (tooling)가 처리하는 종류의 문제입니다 (Design Token Kit 참조).

디자인 라이프사이클: 토큰이 있을 때와 없을 때

이 차이는 어느 한 순간에 나타나는 것이 아니라, 디자인의 전체 생애 주기 (life)를 관통하며 나타납니다.

생성 (Creating). 토큰이 없으면 모델은 코드 전체에 값을 흩뿌리거나, 색상과 역할이 융합된 변수 목록을 통해 값을 생성하며, 실행할 때마다 동기화가 어긋나게 됩니다. 토큰이 있으면 디자인 어휘를 먼저 설정한 다음 이를 활용하므로, 결정 사항들이 새로 발명되는 대신 재사용됩니다.

변경 (Changing). 토큰이 없으면 "브랜드 색상을 더 어둡게 만들어줘"라는 요청은 프로젝트 전체를 뒤지는 작업이 됩니다. 토큰이 있으면 기본 요소 (primitives)의 한 줄만 수정하면 되며, 변경 사항은 이를 참조하는 모든 곳으로 흘러 들어갑니다.

테마 (Theming). 토큰이 없으면 다크 테마는 종종 거의 처음부터 다시 작성되어야 합니다. 토큰이 있으면 테마는 단지 동일한 역할에 대한 다른 값들의 집합일 뿐이며, 구조는 그대로 유지됩니다.

확인해 봅시다. 토큰이 없다면 무엇이 오류로 간주되는지조차 말하기 어렵습니다. 토큰이 있다면 규칙은 명확합니다. 참조(reference)가 아무 곳도 가리키지 않거나, 타입(type)이 일치하지 않거나, 컴포넌트(component)가 의미론(semantics)을 건너뛰고 원시 값(primitive)에 직접 접근하는 경우 등입니다. 이 모든 것들은 자동으로 검사될 수 있습니다.

모든 단계에서 토큰은 모델에게 동일한 것을 제공합니다. 즉, 형태(form)로부터의 추측 대신 명시적인 구조(explicit structure)를 제공하는 것입니다.

토큰 형식 (Token Formats)

동일한 토큰을 하나 이상의 형식으로 작성할 수 있습니다. 이들은 의미 면에서는 다르지 않으며, 단지 표기법(notation)이 무엇에 최적화되어 있는지만이 다릅니다.

DTCG (Design Tokens Community Group)는 W3C 내의 동일한 이름의 그룹에 의해 토큰을 기술하기 위한 산업 표준으로서 개발되었습니다. 사양(spec)에 대한 작업이 여전히 진행 중임에도 불구하고, 이미 사실상의 표준(de facto reference)으로 자리 잡았습니다. 주요 목적은 상호 운용성(interoperability)입니다. 즉, 동일한 토큰을 서로 다른 도구들이 이해할 수 있어야 하며, 이를 기반으로 테마(theme)를 구축할 수 있어야 합니다. 해당 형식의 사이트에서 설명하듯, DTCG JSON은 도구 간의 상호 운용성과 테마 설정을 가능하게 합니다. 이는 DTCG를 공통 언어로 만들어 주며, DTCG로 작성된 디자인은 다시 작성할 필요 없이 에디터, 빌드 단계, 문서 사이를 이동할 수 있습니다. 이것이 우리가 실험에서 모델에게 제공한 형식입니다.

HRDT (Human-Readable Design Tokens)는 design-token-kit의 저자들이 만든 것으로, 동일한 토큰을 YAML로 수동 작성할 수 있는 더 읽기 쉬운 방식입니다. DTCG보다 더 압축적이며 손실 없이 DTCG로의 왕복(round-trips)이 가능하므로, YAML에서 편집한 후에도 공유된 DTCG를 통해 도구 간에 토큰을 이동할 수 있습니다.

DESIGN.md는 Google에서 유래되었습니다. YAML 프론트매터(frontmatter)에 토큰을 포함하는 마크다운(Markdown) 형식으로, design-token-kit이 이를 지원합니다. 이는 디자인의 일부 하위 집합(색상, 타이포그래피, 간격, 코너 반경, 컴포넌트)을 다루며, 문서 옆에 시스템에 대한 짧은 설명을 유지하는 데 유용합니다. 그림자(shadows)나 그라데이션(gradients)과 같은 더 풍부한 타입(richer types)은 이 범위를 벗어납니다.

design-token-kit

토큰을 다룬다는 것은 단순히 토큰을 작성하는 것 이상의 의미를 갖습니다. 구조를 확인하고, 깨진 참조(broken references)를 찾아내며, 토큰을 CSS로 변환하고, 그 결과를 확인해야 합니다. Design Token Kit은 이 모든 과정을 처리합니다.

이 도구는 토큰을 검사하고, 변환하며, 쇼케이스(showcase)를 구축합니다. 실험에서 사용된 DTCG 토큰들이 바로 이 도구를 통해 실행된 대상입니다.

토큰 검사:

dtokens check tokens.json

CSS로 변환:

dtokens convert --outform css --out tokens.css tokens.json

쇼케이스 페이지 생성:

dtokens showcase --out showcase.html tokens.json

형식 간 변환:

dtokens convert --inform dtcg --outform hrdt --out tokens.yaml tokens.json

결론

사람은 이미지를 통해 디자인을 받아들입니다. 모델은 숫자를 통해 디자인을 받아들이며, 유일한 질문은 그 숫자들이 얼마나 의미 있는가 하는 것입니다.

스크린샷이나 깔끔한 CSS조차도 모델에게는 값(value)과 그 의미가 융합되어 있고, 연결 고리가 작성자의 머릿속에만 존재하는 디자인을 전달할 뿐입니다. 반면 디자인 토큰(Design tokens)은 대신 구조를 전달합니다. 한쪽에는 값이, 다른 한쪽에는 역할(role)이 있으며, 그들 사이에는 명시적인 참조(explicit references)가 존재합니다. 이러한 형태에서 모델은 디자인을 훨씬 더 일관되게 설명하며, 이것이 바로 실험이 보여준 결과입니다.

디자인 토큰은 단지 사람만을 위한 것이 아닙니다. 모델에게도 매우 적합하다는 것이 밝혀졌습니다. 그리고 Design Token Kit은 번거로운 작업 없이도 그 언어를 쉽게 구사할 수 있게 해줍니다.

링크