Work

창 닫기

Study2026

디자인 시스템은 어디로 가는가

UI 라이브러리가 무엇을 사용할 것인가를 정의한다면, 디자인 시스템은 왜, 언제, 어떻게 사용하고 변화시킬 것인가를 정의한다. 그리고 에이전틱 디자인 시스템은 한 걸음 더 나아가, 그 판단을 기계가 조회하고 실행하며 검증할 수 있는 형태로 만든다.

디자인 시스템을 둘러싼 경계가 다시 움직이고 있다.

우리가 오랫동안 UI 라이브러리라고 불러온 것들은 점차 디자인 시스템을 자처하기 시작했다. 대표적으로 shadcn/ui는 자신을 전통적인 컴포넌트 라이브러리가 아니라, 각 조직이 자체 컴포넌트 라이브러리와 디자인 시스템을 구축하기 위한 코드 배포 시스템이자 기반으로 설명한다. 최근에는 프리셋, 레지스트리, CLI 문서 조회, 에이전트용 스킬까지 제공하며 사람이 컴포넌트를 복사하는 도구에서 조직의 UI 규칙을 배포하는 플랫폼으로 범위를 넓히고 있다.

이 변화는 단순한 명칭의 확장이 아니다.

제품을 만드는 주체가 사람에서 사람과 AI 에이전트의 협업 구조로 바뀌면서, 디자인 시스템이 담당해야 할 역할 자체가 달라지고 있기 때문이다.

UI 라이브러리와 디자인 시스템의 차이는 '규칙이 어디에 존재하는가'에 있다

UI 라이브러리는 일반적으로 재사용 가능한 구현물을 제공한다.

버튼
입력 필드
모달
테이블
드롭다운
레이아웃 유틸리티

이것만으로도 개발 속도는 크게 개선된다. 이미 구현된 컴포넌트를 가져다 쓰면 접근성이나 브라우저 이벤트, 기본 스타일을 매번 다시 만들 필요가 없기 때문이다.

그러나 컴포넌트가 존재한다는 사실만으로는 다음 질문에 답하기 어렵다.

한 화면에 Primary Button을 몇 개까지 사용해야 하는가?
Dialog와 별도 페이지 중 어떤 패턴을 선택해야 하는가?
목록을 Card로 표현해야 하는가, Row로 표현해야 하는가?
새로운 색상이 필요할 때 토큰을 추가해야 하는가, 기존 의미 토큰을 재사용해야 하는가?
제품팀의 특수한 요구를 시스템에 편입할 것인가, 로컬에서 해결할 것인가?
컴포넌트 변경이 수십 개 제품에 미치는 영향은 누가 검증할 것인가?

이 질문들은 코드 조각이 아니라 정책, 맥락, 소유권과 운영 방식에 관한 것이다.

따라서 디자인 시스템은 컴포넌트의 집합이라기보다 다음 요소들이 연결된 구조에 가깝다.

계층	역할
Foundation	색상, 간격, 타이포그래피, 모션과 같은 기본 결정
Component	반복되는 행동과 상호작용의 구현
Pattern	여러 컴포넌트를 조합해 문제를 해결하는 방식
Guideline	언제 사용하고 언제 사용하지 말아야 하는지에 대한 기준
Governance	변경, 승인, 배포, 폐기, 버전 관리 방식
Tooling	디자인과 코드, 문서, 테스트를 연결하는 자동화
Knowledge	조직이 축적한 사례와 의사결정의 기록

조직이 작을 때 이러한 규칙은 개인의 경험과 기억으로 유지될 수 있다.

그러나 제품과 조직이 커질수록 개인의 기억에 일관성을 맡길 수 없게 된다. 작은 토큰 변경 하나가 여러 플랫폼과 수십 개 화면에 영향을 주고, 한 팀의 임시 예외가 다른 팀의 선례가 된다.

결국 디자인 시스템은 UI의 재사용을 넘어 조직의 반복적인 의사결정을 저장하고 배포하는 기반 시설이 된다.

국내 디자인 시스템은 이미 '운영 체계'로 진화해 왔다

AI가 등장하기 전에도 국내 대규모 제품 조직은 디자인 시스템을 단순 UI 키트보다 넓은 범위로 다뤄 왔다.

LINE: 원칙과 테마로 다양한 제품을 연결한다

LINE의 LDS는 여러 패밀리 서비스가 공통된 기본 원칙을 공유하면서도, 서비스의 타깃과 목적에 따라 다른 표현을 가질 수 있도록 설계됐다.

색상, 타이포그래피, 형태와 같은 최소 단위의 원칙을 정의하고, 그 위에 기본 컴포넌트와 유니버설 테마를 제공한다. 공통된 구조를 유지하면서 서비스별 특성을 수용하는 방식이다.

이는 디자인 시스템의 중요한 역할을 보여준다.

일관성이란 모든 제품을 똑같이 만드는 것이 아니라, 서로 다른 제품이 같은 원칙에서 출발하도록 만드는 것이다.

쿠팡: 컴포넌트를 비즈니스와 검증 과정까지 연결한다

쿠팡의 Rocket Design System은 디자인 자산을 Elements, Parts, Units로 구분한다.

색상과 타이포그래피 같은 기초 요소에서 시작해 버튼과 칩 같은 기본 컴포넌트를 만들고, 다시 이를 특정 비즈니스 요구에 대응하는 더 큰 단위로 조합한다. 특히 Figma와 Zeplin에서 컴포넌트의 코드 라이브러리, API 명세와 데이터 모델을 확인할 수 있는 별도 도구를 구축해 디자인과 구현 사이의 정보 단절을 줄였다.

또한 컴포넌트 역시 A/B 테스트를 통해 제품 지표에 미치는 영향을 검증한다. 디자인 시스템이 디자인팀의 정적 산출물이 아니라 제품 개발 및 실험 프로세스의 일부로 작동하는 사례다.

배달의민족: 화면이 아니라 반복되는 행동을 추상화한다

우아한형제들의 셀프서비스 디자인 시스템은 디자인 시스템에서 말하는 '시스템'을 구조와 행동을 통제하는 규칙의 집합으로 설명했다.

단순한 UI 템플릿에 머물지 않고 공통 라이프사이클, 이벤트 해제, 로그 수집, 점검 화면, 캐시와 다이얼로그 흐름처럼 반복되는 제품 동작을 추상화했다. 개발자는 공통 동작을 다시 구현하지 않고 비즈니스 로직에 집중할 수 있었다.

컴포넌트 사이의 관계와 화면 구성 규칙까지 정의하고, 매주 워크숍을 통해 시스템을 지속적으로 보완했다는 점도 중요하다.

디자인 시스템의 대상이 시각적 표현만이 아니라 제품을 만드는 방식까지 확장된 것이다.

토스: 시스템의 통제보다 연결을 유지하는 것이 중요하다

토스는 디자인 시스템을 운영하며 발생하는 현실적인 문제를 '시스템과 제품팀 사이의 연결'이라는 관점에서 설명한다.

제품팀이 필요한 형태를 시스템에서 얻지 못하면 Figma 컴포넌트를 분리하거나 패키지를 fork한다. 단기적으로는 빠른 해결이지만, 그 순간부터 해당 구현은 시스템의 업데이트와 접근성 개선을 받지 못한다.

토스는 이 문제를 사용자의 일탈로 보지 않는다. 디자인 시스템 역시 하나의 제품이며, 사용하는 팀의 수요에 대응하지 못하면 자연스럽게 우회가 발생한다고 본다.

따라서 중요한 것은 우회를 금지하는 것이 아니라 우회해야 할 이유를 줄이는 API와 확장 구조를 만드는 것이다.

이 관점은 이후 살펴볼 Astryx의 점진적 커스터마이징 모델과도 맞닿아 있다.

Astryx가 보여주는 에이전틱 디자인 시스템

2026년 Meta가 공개한 Astryx는 이러한 흐름을 보다 직접적인 형태로 보여준다.

Astryx는 Meta 내부에서 8년 동안 발전한 디자인 시스템을 React, TypeScript, StyleX와 최신 웹 플랫폼을 중심으로 다시 구축한 오픈소스 프로젝트다. 현재 베타 단계이며, 160개 이상의 접근 가능한 컴포넌트를 제공한다. 기반이 된 내부 시스템은 13,000개 이상의 Meta 제품과 도구에 사용돼 왔다.

Astryx가 흥미로운 이유는 단순히 컴포넌트가 많기 때문이 아니다.

기존 디자인 시스템이 사람의 사용과 조직의 확장을 지원했다면, Astryx는 여기에 AI 에이전트가 시스템을 조회하고 사용하는 과정을 처음부터 포함한다.

행동은 시스템이, 표현은 테마가 관리한다

Astryx의 핵심 구조는 다음 문장으로 요약할 수 있다.

행동, 접근성, 상호작용과 API는 시스템이 관리하고, 시각적 표현은 테마가 관리한다.

컴포넌트는 사용자의 입력을 처리하는 방식, 키보드 내비게이션, 상태 관리, 접근성, 상호작용을 책임진다.

테마는 다음과 같은 표현 계층을 선언적으로 관리한다.

색상과 명도 모드
타이포그래피 스케일
간격
모서리 반경
그림자
모션 속도
컴포넌트별 스타일
컴포넌트 내부 파트
상태와 Variant

Astryx의 테마는 단순한 CSS 변수 모음보다 넓다. 컴포넌트와 내부 파트의 스타일을 변경하고 조직에 필요한 커스텀 Variant를 추가할 수 있다. 하나의 값을 변경하면 시스템 전반의 컴포넌트가 함께 갱신되며, Light·Dark 모드도 같은 설정에서 다룬다.

이 구조는 브랜드와 제품 행동을 분리한다.

조직은 접근성과 상호작용을 다시 구현하지 않고도 제품의 시각 언어를 변경할 수 있다. 디자인 시스템은 특정 기업의 외형을 강요하는 완제품이 아니라, 여러 브랜드가 사용할 수 있는 행동 기반이 된다.

점진적 커스터마이징과 소스 소유권

대부분의 디자인 시스템은 일관성과 유연성 사이에서 어려움을 겪는다.

중앙 통제를 강화하면 제품팀이 필요한 예외를 구현하기 어렵고, 지나치게 자유롭게 만들면 시스템의 일관성과 업데이트 경로가 사라진다.

Astryx는 이 문제를 하나의 선택으로 해결하지 않고, 통제 수준을 단계적으로 높이는 경로로 설계한다.

text
기본 컴포넌트 사용
        ↓
테마 토큰 및 컴포넌트 스타일 수정
        ↓
className 또는 xstyle 적용
        ↓
공개된 내부 파트와 CSS 활용
        ↓
컴포넌트 소스 추출 및 직접 소유

마지막 단계가 swizzle이다.

컴포넌트의 전체 소스와 내부 모듈을 프로젝트로 가져오면, 이후 해당 프로젝트가 코드를 직접 소유한다. 일반적인 컴포넌트는 Astryx의 업데이트와 접근성 개선을 계속 받고, 강한 차별화가 필요한 일부 컴포넌트만 소스 수준에서 변경할 수 있다.

다만 소스를 가져온 순간부터 업스트림과의 거리는 멀어진다.

통제력이 증가하는 만큼 버그, 접근성, 브라우저 대응과 업데이트를 제품팀이 책임져야 한다. 이는 토스가 지적한 detach와 fork의 문제와도 같다.

따라서 소스 소유권은 자유로운 탈출구라기보다 책임의 이전을 명시하는 계약에 가깝다.

좋은 디자인 시스템은 예외를 금지하지 않는다. 대신 예외의 비용이 어디에서 발생하는지 분명하게 만든다.

Astryx가 업무용 애플리케이션에 잘 맞는 이유

Astryx의 기반은 Meta의 내부 도구 환경이다.

그 결과 일반 소비자용 마케팅 페이지보다 다음과 같은 업무용 제품 패턴이 많이 축적돼 있다.

데이터 테이블
탐색 및 필터링
사이드 내비게이션
다중 패널 레이아웃
인스펙터
설정 화면
커맨드 팔레트
복잡한 폼
관리 콘솔
작업 추적 도구

Astryx는 제품의 유형에 따라 레이아웃 구조를 먼저 선택하도록 안내한다.

예를 들어 이슈 트래커나 CRM은 Row와 Inspector를 중심으로 구성하고, 관측 및 운영 콘솔은 Table과 Dashboard Widget을 조합하며, 메시징 제품은 Card보다 Row와 Bubble을 우선한다.

특히 모든 정보를 Card에 넣는 이른바 '카드 수프(Card Soup)'를 경계한다. 데이터의 성격과 사용자의 스캔 방식에 따라 Table, List, Card를 구분하도록 구체적인 판단 기준을 제공한다.

이 지점에서 디자인 시스템은 컴포넌트 카탈로그를 넘어선다.

Card라는 컴포넌트가 있다는 사실보다, 어떤 정보 구조에서 Card를 선택하지 말아야 하는가를 알려주는 것이 더 중요해진다.

이러한 패턴은 에이전트 인터페이스, 데이터 패널, 백오피스, 개발자 도구와 같은 제품군에도 잘 맞을 가능성이 크다.

문서에서 에이전트 인터페이스로

기존 디자인 시스템의 문서는 사람을 대상으로 한다.

사람은 문서를 훑어보고, 예시의 의도를 해석하고, 현재 작업에 필요한 정보만 선택할 수 있다. 문서에 모호한 부분이 있더라도 경험을 통해 빈칸을 채운다.

LLM 에이전트는 다르다.

컨텍스트에 시스템의 규칙이 없으면 존재하지 않는 컴포넌트를 만들거나, 임의의 색상과 간격을 사용하고, 익숙한 HTML 패턴으로 돌아간다.

따라서 에이전트 시대의 디자인 시스템은 문서 사이트만 제공해서는 충분하지 않다.

에이전트가 다음 정보를 정확하게 조회할 수 있어야 한다.

text
어떤 컴포넌트가 존재하는가
→ 어떤 Props와 상태를 지원하는가
→ 언제 사용해야 하는가
→ 어떤 템플릿에서 사용됐는가
→ 어떤 토큰에 의존하는가
→ 변경하거나 업그레이드할 때 무엇을 확인해야 하는가

프로젝트에 설치된 버전을 기준으로 문서를 제공한다

Astryx의 CLI는 컴포넌트 검색, 문서 조회, 프로젝트 초기화, 테마 생성과 업그레이드를 담당한다.

초기화 과정에서는 프로젝트에 에이전트용 문서와 설정을 추가한다. 중요한 점은 웹사이트의 최신 문서를 무조건 참조하는 것이 아니라, 현재 프로젝트에 실제 설치된 버전을 기준으로 정보를 제공한다는 것이다. Astryx의 마이그레이션 가이드 역시 초기화 후 프로젝트에 테마와 에이전트 문서가 준비되도록 안내한다.

이는 에이전트가 최신 문서를 보고 오래된 API를 사용하는 문제를 줄인다.

사람에게도 버전 불일치는 불편하지만, 에이전트에게는 잘못된 코드를 대량으로 생성하게 만드는 직접적인 원인이 된다.

필요한 정보만 압축해 조회한다

Astryx CLI에서는 컴포넌트의 Props, 예제와 문서를 조회할 수 있다.

--dense 옵션을 사용하면 LLM 컨텍스트에 전달하기 적합한 압축 출력을 얻을 수 있고, 자동화가 필요한 경우 JSON 형식으로 정보를 받을 수 있다.

bash
npx astryx docs migration --dense
npx astryx component Button --json

이 방식은 모든 문서를 프롬프트에 넣는 것보다 효율적이다.

에이전트는 작업을 시작할 때 필요한 규칙만 읽고, 새로운 컴포넌트를 사용할 때 관련 API를 추가로 조회할 수 있다.

컨텍스트를 많이 제공하는 것이 항상 좋은 결과를 만들지는 않는다. 관련 없는 규칙이 많아지면 중요한 지침의 우선순위가 낮아진다.

따라서 에이전트 친화적인 디자인 시스템은 문서를 많이 제공하는 것보다 필요한 정보를 발견하고 단계적으로 읽을 수 있는 구조를 제공해야 한다.

좋은 예제를 먼저 탐색하도록 만든다

LLM은 빈 화면에서 독창적인 UI를 만드는 것보다 기존의 좋은 구조를 조합하는 데 강하다.

Astryx는 이를 전제로 컴포넌트뿐 아니라 페이지와 블록 템플릿을 CLI에 노출한다. 에이전트가 곧바로 임의의 JSX를 만들기보다 다음 순서를 따르도록 유도한다.

text
제품 유형과 가까운 템플릿 탐색
        ↓
레이아웃 골격 확인
        ↓
사용된 컴포넌트 확인
        ↓
각 컴포넌트의 API 조회
        ↓
제품의 데이터와 요구사항에 맞게 조합

Astryx 팀 역시 AI가 좋은 결과물을 만들게 하려면 고품질 템플릿과 실제 컴포넌트 사용 사례를 제공해야 한다고 설명한다. 초기 템플릿에서 일반 div와 임의 스타일의 비중이 높았을 때 에이전트가 Astryx를 제대로 사용하지 못했고, 시스템 컴포넌트를 중심으로 예제를 개선하면서 결과도 나아졌다.

디자인 시스템의 품질은 이제 개별 컴포넌트의 완성도뿐 아니라, 에이전트가 복제할 사례의 품질에도 영향을 받는다.

MCP는 디자인 시스템을 검색 가능한 지식으로 만든다

Astryx는 자연어로 컴포넌트, 템플릿과 문서를 검색하고 특정 항목의 사용법을 조회할 수 있도록 CLI와 MCP를 제공한다. 사람이 보는 문서와 에이전트가 조회하는 정보가 같은 기반에서 생성되도록 해, 서로 다른 문서 체계가 독립적으로 낡아가는 문제를 줄이려는 접근이다.

여기에서 디자인 시스템은 문서 사이트가 아니라 하나의 지식 인터페이스가 된다.

사람은 웹사이트에서 검색하고, 에이전트는 MCP와 CLI를 통해 같은 정보를 조회한다.

인터페이스는 다르지만 원본은 같다.

한국의 에이전틱 디자인 시스템: SEED와 Kraft

이 변화는 해외에만 국한되지 않는다.

당근의 SEED는 현재 국내에서 에이전트 친화적인 디자인 시스템의 방향을 가장 선명하게 보여주는 사례 중 하나다.

SEED는 Figma, Web, Android, iOS가 토큰과 컴포넌트 단위의 통합된 디자인 언어를 공유하도록 구성돼 있다. 문서에는 Foundation, 컴포넌트 가이드와 함께 각 페이지의 LLM 최적화 문서가 제공된다.

또한 SEED는 다음과 같은 AI 통합 계층을 제공한다.

llms.txt
에이전트용 Skill
컴포넌트와 디자인 가이드 조회 CLI
Docs MCP
Rootage 원본 데이터 접근
아이콘 검색
Figma 디자인의 코드 변환

Docs MCP를 이용하면 에이전트가 React 컴포넌트의 설치법과 Props, 디자인 가이드, Foundation, 토큰 원본 데이터와 아이콘을 직접 조회할 수 있다.

특히 SEED의 디자인 토큰 문서는 토큰을 단순 변수로 설명하지 않는다.

디자인 토큰은 디자인 결정을 사람과 기계가 이해할 수 있는 형태로 인코딩한 것이다.

색상값을 저장하는 것이 아니라, 어떤 역할과 의미를 가진 색상인지를 데이터로 표현한다. 역할 기반 색상을 우선하고, 직접적인 팔레트 값은 의미 체계로 해결하기 어려운 예외에서만 사용하도록 안내한다.

AI가 화면을 그리는 것이 아니라 의사결정을 자동화한다

당근이 공개한 Kraft는 SEED를 기반으로 프롬프트에서 화면을 생성하는 도구다.

그러나 목표는 단순한 UI 생성이 아니다.

Kraft는 컴포넌트 선택, 토큰 적용, 레이아웃, 카피, 상태 처리처럼 화면을 만들 때 필요한 여러 결정을 자동화하려 한다.

당근은 이를 다음과 같은 질문으로 전환했다.

"AI로 화면을 만들 것인가?"가 아니라 "어떤 결정을 AI에게 맡길 것인가?"

Kraft는 디자인 시스템 지식을 여러 Skill로 나누고, 에이전트가 현재 단계에 필요한 규칙만 읽도록 한다.

예를 들어 폼 화면을 만들 때는 화면 패턴과 간격 규칙을 먼저 읽고, 카피를 만드는 단계에서 글쓰기 가이드를 추가로 불러온다. 생성된 결과는 시맨틱 토큰 사용 여부와 SEED 규칙 준수 여부를 검증한다.

이 사례는 에이전틱 디자인 시스템의 구조를 잘 보여준다.

text
디자인 시스템의 지식
        ↓
작업별 Skill 선택
        ↓
구조화된 디자인 명세 생성
        ↓
컴포넌트와 토큰 조합
        ↓
규칙 준수 자동 검증
        ↓
디자인 결정 기록

디자인 시스템이 더 이상 생성 도구에 참고 이미지만 제공하는 것이 아니라, 에이전트의 판단 범위를 제한하고 결과를 검증하는 역할까지 맡는다.

앞으로 디자인 시스템은 어떤 방향으로 발전할 것인가

Astryx와 SEED, 그리고 국내외 디자인 시스템 사례를 종합하면 앞으로의 방향은 비교적 분명하다.

1. 컴포넌트 카탈로그에서 컨텍스트 아키텍처로

기존 디자인 시스템의 중심은 컴포넌트였다.

앞으로는 컴포넌트 주변의 맥락이 더 중요해진다.

사용 목적
적합한 사용자 의도
사용해야 하는 상황
사용하지 말아야 하는 상황
함께 조합되는 컴포넌트
필수 상태
접근성 규칙
콘텐츠 원칙
실제 제품 사례
변경 이력
폐기 및 대체 경로

에이전트는 컴포넌트 이름만으로 올바른 UI를 만들 수 없다.

좋은 디자인 시스템은 에이전트가 컴포넌트를 선택할 수 있는 정보 구조를 제공해야 한다.

2. 문서화된 규칙에서 실행 가능한 거버넌스로

문서에만 존재하는 규칙은 권고에 가깝다.

앞으로의 디자인 시스템은 규칙을 자동으로 검증할 수 있어야 한다.

text
하드코딩된 색상 탐지
시맨틱 토큰 사용 검증
금지된 컴포넌트 조합 확인
접근성 상태 누락 검사
폐기된 API 사용 탐지
디자인과 코드의 버전 차이 확인
대표 화면의 시각적 회귀 테스트

AI가 생성 속도를 높일수록 검증 체계의 중요성도 커진다.

화면을 더 빨리 만들 수 있다는 것은 일관성 없는 화면 역시 더 빨리 확산될 수 있다는 뜻이다.

디자인 시스템은 생성기의 입력일 뿐 아니라 품질을 판정하는 평가기가 되어야 한다.

3. 컴포넌트보다 패턴과 템플릿의 중요성이 커진다

에이전트는 Button의 Props를 아는 것보다, 결제 화면이나 설정 화면이 어떤 구조를 가져야 하는지 알 때 더 좋은 결과를 만든다.

따라서 디자인 시스템의 기본 단위는 점차 다음과 같이 올라갈 것이다.

text
Token
  ↓
Component
  ↓
Pattern
  ↓
Block
  ↓
Page Template
  ↓
Product Archetype

컴포넌트는 문법이고, 템플릿과 패턴은 문장에 가깝다.

에이전트에게 문법만 제공하면 문법적으로는 맞지만 제품답지 않은 화면이 만들어진다. 실제 사용 사례와 제품 유형별 구조를 함께 제공해야 조직다운 결과를 만들 수 있다.

4. 중앙 통제보다 점진적인 소유권 모델이 중요해진다

모든 제품 요구를 하나의 중앙 시스템이 예측할 수는 없다.

따라서 미래의 디자인 시스템은 표준과 예외를 이분법적으로 구분하기보다, 통제와 책임을 단계적으로 이전하는 구조를 가져야 한다.

text
표준 컴포넌트
→ 토큰 변경
→ 테마 확장
→ 내부 파트 조합
→ 로컬 확장
→ 소스 직접 소유

중요한 것은 마지막 단계의 존재 여부가 아니다.

어느 단계부터 업스트림 업데이트, 접근성 개선과 버그 수정의 책임이 제품팀으로 이동하는지를 명확하게 알려주는 것이다.

5. 디자인 시스템은 측정되는 내부 제품이 된다

디자인 시스템의 성공을 컴포넌트 개수나 설치 횟수만으로 판단하기는 어렵다.

앞으로는 다음과 같은 운영 지표가 더 중요해질 것이다.

제품팀의 실제 사용률
로컬 컴포넌트와 Fork의 수
시스템 밖 토큰의 사용량
업그레이드에 걸리는 시간
접근성 오류 발생률
에이전트 생성 결과의 컴포넌트 재사용률
디자인 QA에서 반복되는 위반 유형
시스템을 사용해 화면을 완성하는 데 필요한 시간
제품팀이 요청한 기능이 시스템에 반영되기까지 걸리는 시간

Astryx가 사람과 AI가 시스템을 얼마나 잘 사용하는지 평가하는 테스트 체계를 두고, 토스가 디자인 시스템을 수요에 대응해야 하는 제품으로 바라보는 이유도 여기에 있다.

에이전트 시대의 디자인 시스템 구조

조직에서 에이전트 친화적인 디자인 시스템을 구축한다면 다음과 같은 계층을 생각할 수 있다.

text
Design Principles
        ↓
Primitive & Semantic Tokens
        ↓
Accessible Components
        ↓
Composition Rules
        ↓
Patterns & Templates
        ↓
Human Documentation
        ↓
llms.txt · AGENTS.md · Skills
        ↓
CLI · Registry · MCP
        ↓
Lint · Test · Validation · Evaluation
        ↓
회사 공통 디자인 시스템
        ↓
도메인별 컴포넌트와 패턴
        ↓
각 제품

이 구조에서 AGENTS.md, llms.txt, Skill과 MCP는 부가 기능이 아니다.

기존에 사람의 머릿속에 남아 있던 다음의 지식을 새로운 사용자에게 전달하는 인터페이스다.

왜 이러한 결정을 내렸는가
어떤 상황에서 이 패턴을 선택하는가
무엇을 변경해도 되는가
무엇을 변경하면 안 되는가
예외를 만들 때 누가 책임지는가
변경된 시스템을 어떻게 배포하는가

다만 에이전트용 파일 몇 개를 추가했다고 해서 시스템이 자동으로 에이전틱해지는 것은 아니다.

원본 문서와 코드가 일치하지 않고, 토큰에 의미가 없으며, 컴포넌트 API가 예측하기 어렵고, 변경 절차가 존재하지 않는다면 AI는 그 혼란을 더 빠르게 복제한다.

AI는 건강한 디자인 시스템의 영향력을 증폭할 수 있지만, 망가진 운영 구조를 대신 고쳐주지는 않는다.

디자인 시스템의 다음 사용자는 사람만이 아니다

디자인 시스템의 역사는 재사용 범위를 확장해 온 과정이었다.

처음에는 색상과 버튼을 재사용했고, 이후에는 상호작용과 접근성을 재사용했다. 조직이 커지면서 패턴과 프로세스, 의사결정과 운영 지식까지 재사용하기 시작했다.

이제는 그 지식을 사람뿐 아니라 에이전트도 사용할 수 있는 형태로 변환하고 있다.

따라서 앞으로 디자인 시스템의 경쟁력은 컴포넌트의 개수에서 나오지 않을 가능성이 크다.

더 중요한 것은 조직이 축적한 판단을 얼마나 정확하게 구조화하고, 필요한 시점에 전달하며, 실제 결과에서 검증할 수 있는가이다.

디자인 시스템의 진짜 자산은 버튼의 코드가 아니다. 그 버튼을 왜 만들었고, 언제 사용해야 하며, 어떤 변경을 허용할 것인지에 대해 조직이 축적한 판단이다.

UI는 복제할 수 있다.

컴포넌트도 복제할 수 있다.

그러나 수많은 제품을 운영하며 축적한 예외, 실패, 검증 결과와 의사결정의 맥락은 쉽게 복제할 수 없다.

미래의 디자인 시스템은 이 조직적 기억을 저장하는 저장소이자, 사람과 에이전트가 함께 제품을 만들기 위해 사용하는 운영 인터페이스가 될 것이다.

디자인 시스템은 더 이상 완성된 UI를 꺼내 쓰는 선반이 아니다.

좋은 제품이 반복해서 만들어지도록 판단의 범위를 설계하는 시스템이다.

← 전체 프로젝트로 돌아가기