원문은 mauriciojuba.com에서 처음 게시되었습니다.

에세이 · 디자인 시스템 (Design Systems) × AI

디자인 시스템의 주요 소비자가 종(species)을 바꾸었습니다. 그리고 대부분의 디자인 팀은 이를 알아차리지 못했습니다.

지난 10년 동안 저는 인간 엔지니어를 위해 디자인 토큰 (Design Tokens)을 작성해 왔습니다. 2026년, 디자인 시스템의 주요 소비자가 종을 바꾸었습니다.

과거의 계약

디자인 토큰은 언제나 하나의 계약이었습니다: _이것_이 우리가 의도한 블루이며, _이것_이 간격 리듬(spacing rhythm)이라는 약속입니다. 그리고 이를 데이터로 제공함으로써, 디자이너가 자리에 없더라도 코드가 이를 소비할 수 있게 했습니다.

Dell에서 저는 정확히 그 아이디어를 중심으로 디자인 시스템의 토큰 아키텍처 (token architecture)를 재구축했습니다. 당시 시스템은 정체되어 있었습니다. 기반은 탄탄했지만, 블랙박스 (black box)처럼 운영되고 있었죠. 경영진이 의심했던 것처럼 거버넌스 (governance)가 진짜 문제였던 것은 아니었습니다. 진짜 문제는 토큰이 디자이너에 의해, 디자이너를 위해 명명되었으며, 내보내기 파이프라인 (export pipeline)이 없었다는 점이었습니다. 토큰을 실제로 소비하는 사람들인 프론트엔드 엔지니어 (front-end engineers)는 명명 규칙에서 소외되어 있었습니다.

우리는 이를 뒤집었습니다: 단순화된 코어 (core) + 시맨틱 계층 구조 (semantic hierarchy), 라이트 모드와 다크 모드를 구축하여 모든 dell.com 접점에 JSON 및 CSS로 배포했습니다. 그 이후로 제가 반복해 온 교훈은 이것입니다: 명명 (naming)은 제품 결정 (product decision)입니다. 작성자가 아닌 실제 소비자에 맞춰 최적화하십시오.

다만, 실제 소비자가 이렇게 빨리 다시 바뀔 것이라고는 예상하지 못했습니다.

무엇이 변했는가

2026년에 이르러, 새로운 UI 코드의 상당 부분은 기계에 의해 생성됩니다. 설문에 참여한 디자이너의 절반은 AI가 생성한 코드를 프로덕션에 배포했다고 답했습니다. Claude Design은 코드베이스에서 팀의 디자인 시스템을 직접 읽고 이를 적용합니다. Figma는 네이티브 AI 디자인 에이전트 (native AI design agent)를 출시합니다. 모든 제품 팀은 루프 어딘가에 코딩 에이전트 (coding agent)를 두고 있으며, 이들은 디자인 리뷰가 검사할 수 없는 속도로 컴포넌트 (components)를 생성해 내고 있습니다.

그리고 생성된 UI는 특정한 실패 모드(failure mode)를 가집니다: 바로 **기억 없는 속도(speed without memory)**입니다. 각 세션, 각 모델, 각 프롬프트는 자신만의 패딩(paddings), 자신만의 회색(grays), 자신만의 테두리 반경(border radii)을 만들어냅니다. 개별적으로는 그럴듯해 보이지만, 집합적으로는 일관성이 없습니다(incoherent). 과거에는 이러한 드리프트(drift)가 조직의 분기(quarters) 단위로 발생했다면, 이제 에이전트 군단(agent fleet)은 이를 단 한 오후 만에 일으킵니다.

figure

여러분의 로드맵을 재설정해야 할 부분이 여기 있습니다: 에이전트가 UI를 생성할 때, 에이전트는 여러분의 Figma 라이브러리를 읽지 않습니다. 에이전트는 여러분의 저장소(repo), 토큰(tokens) 파일, 컴포넌트 시그니처(component signatures), 그리고 파싱(parse) 가능한 형식으로 되어 있다면 여러분의 문서(docs)를 읽습니다. Figma가 자체적인 Dev Mode MCP server를 설명하는 방식은, 출력 품질이 시스템이 얼마나 '연결(connected)'되어 있는지에 따라 결정된다는 것입니다. 문서화된 실패 모드는 시스템이 기계가 읽을 수 없는(machine-legible) 상태일 때 하드코딩된 값(hard-coded values)이 몰래 끼어드는 것입니다.

figure

디자인 시스템의 기계 대응 접점(machine-facing surface)이 이제 주요 인터페이스가 되었습니다. 토큰 파일은 더 이상 내보내기 결과물(export artifact)이 아닙니다. 그것은 프롬프트(prompt)가 되었습니다.

관습은 침식되지만, 컴파일러는 그렇지 않습니다.

토큰이 프롬프트라면 새로운 문제가 나타납니다: 프롬프트는 제안(suggestions)이라는 점입니다. 모델들은 — 바쁜 인간들처럼 — 프롬프트를 따르다가도 어느 순간 따르지 않게 됩니다.

제가 작업해 온 모든 디자인 시스템은 관습(convention)에 의한 거버넌스(governance)를 가지고 있었습니다: 가이드라인, 리뷰 의식, 그리고 누군가가 가끔씩 "색상을 하드코딩하지 마세요"라고 올리는 Slack 채널 같은 것들 말입니다. 하지만 관습은 침식됩니다. 언제나 그렇습니다. 신규 입사자는 위키(wiki)를 읽지 않고, 마감 기한은 가이드라인을 압도하며, 이제 에이전트들은 통계적으로 가능성이 높다는 이유로 그럴듯한 헥스(hex) 값을 환각(hallucinate)해냅니다.

침식되지 않는 유일한 강제 지점(enforcement point)은 빌드(build)뿐입니다.

figure

저는 이 가설을 고된 방식으로 테스트했습니다. 저의 개인적인 툴링 프로젝트인 Rust 기반의 저작 IDE(authoring IDE)를 위해, egui용으로 shadcn/ui 디자인 언어를 네이티브로 재구축했습니다. 60개 이상의 컴포넌트를 토큰 우선(token-first) 방식으로 구현했습니다. 그리고 이 법칙을 테스트(test)로 인코딩했습니다. 토큰 레이어(token layer) 상단 어디에서든 실제 색상(literal color), 폰트 크기(font size) 또는 간격(spacing)을 직접 사용하는 경우 빌드(build)가 실패하도록 했습니다. 오직 최하위 레이어만이 페인터(painter)에 접근할 수 있습니다. 탈출구(escape hatches)는 존재하지만, 명시적이며 grep으로 검색 가능합니다. grep으로 찾을 수 있는 예외는 문서화(documentation)이고, 찾을 수 없는 예외는 부패(rot)입니다.

그 후 몇 주 동안 매일 코딩 에이전트(coding agent)와 협업하며 대부분의 컴포넌트 작업을 수행했습니다. 결과는 저조차 놀라게 했습니다. 시스템이 표류(drift)하지 않았습니다. 모델이 규율을 잘 지켰기 때문이 아니라, 빌드(build)가 규율을 지켰기 때문입니다.

figure

이것이 하나의 루프(loop)로 요약된 전체 가설입니다. 저는 기계의 취향을 검토(review)하지 않았습니다. 대신 컴파일 타임(compile time)에 취향을 협상 불가능한 것으로 만들었습니다.

토큰은 쉬운 부분이었습니다

"LLM 컨텍스트(context)로서의 디자인 토큰"은 진입점일 뿐이지만, 가치가 상승하는 자산은 더 큽니다. 만약 제가 오늘 디자인 시스템 팀을 운영한다면, 이것이 로드맵이 될 것입니다:

figure

제 분야에서 불편한 부분

저는 디자이너들이 AI의 물결을 도구의 이야기, 즉 어떤 프롬프트(prompt)를 배워야 하는지, 어떤 플러그인(plugin)을 설치해야 하는지로 취급하는 것을 보아왔습니다. 하지만 구조적인 이야기는 더 거대합니다. 결과물(deliverable) 자체가 이동하고 있습니다. 목업(mockup)은 결코 제품이 아니었습니다. 이제는 컴포넌트 라이브러리(component library)조차 제품이 아닙니다. 제품은 생성된 수천 개의 화면이 여전히 당신의 것임을 알아볼 수 있게 유지해 주는 제약 시스템(constraint system)입니다.

그 작업은 디자인 작업입니다. 그것은 취향(taste), 계층 구조(hierarchy), 의도(intent)입니다. 하지만 그것은 토큰(tokens), 테스트(tests), 타입(types), 그리고 문서(docs)의 형태로 전달됩니다. 이 계층을 작성할 수 있는 디자이너들은 조직 내에서 가장 레버리지(leverage)가 높은 사람이 되어가고 있습니다. 하나의 훌륭한 제약 시스템은 코드베이스(codebase)를 건드리는 모든 에이전트(agent)를 영구적으로 규율합니다.

브랜드 가이드라인 PDF는 두 번 죽었습니다. 첫 번째는 토큰(tokens)이 그것을 대체했을 때였습니다. 인간에게는 산문(prose)이 아닌 데이터(data)가 필요했기 때문입니다. 이제 기계와 마주하는 인터페이스(machine-facing surface)가 주가 됨에 따라, 그 산문(prose)마저 다시 죽어가고 있습니다.

디자인 토큰(design tokens)은 이제 프롬프트(prompts)입니다. 빌드(build)가 곧 리뷰어(reviewer)입니다. 그에 맞춰 작성하십시오.

구축을 통한 증명

여기에 설명된 디자인 시스템은 오픈 소스입니다: ouroboros-ui — 거버넌스(governance) 테스트가 실패하면 빌드가 중단되는 60개 이상의 컴포넌트(components)로 구성되어 있으며, 브라우저에서 실행되는 라이브 스토리북(live storybook)을 제공합니다.

참고 문헌 — Anthropic, Claude Design · Figma, Config 2026 & design systems + MCP · W3C Design Tokens Community Group (포맷 모듈이 첫 번째 안정 버전에 도달함, 2025년 10월) · AI in Design Report 2026.