AI가 디자인을 대신하는 시대, 왜 디자인 시스템이 더 중요해질까?

AI가 디자인을 대신한다는 말은 조금 애매하다.
정확히는 AI가 화면 시안을 빠르게 뽑아주는 시대에 가까운 것 같다.

이번 내용은 Hacker News 스타일 국내 개발 뉴스인 GeekNews 글을 보다가 정리해본 내용이다.
원문에서 말하는 핵심은 간단하다. AI가 디자인을 더 많이 만들수록, 오히려 디자인 시스템은 더 중요해진다.

처음에는 저도 반대로 생각했다.
“AI가 알아서 UI를 그려주면 디자인 시스템이 덜 필요하지 않을까?”
그런데 실제로 생각해보면 그렇지 않다.

AI는 많이 만드는 데 강하다.
하지만 제품답게 맞추는 건 아직 별개의 문제다.

AI는 발산에 강하고, 디자인 시스템은 수렴에 강하다

AI 디자인 도구의 장점은 빠른 발산이다.

예를 들어 이런 식이다.

모바일 앱의 온보딩 화면을 만들어줘.
친근하고 깔끔한 느낌이면 좋겠어.

그러면 AI는 꽤 그럴싸한 화면을 여러 개 만들어낸다.
버튼도 있고, 카드도 있고, 일러스트도 있다.

문제는 그 다음이다.

이 화면이 실제 서비스의 버튼 규칙을 따르는가?
색상 토큰은 맞는가?
간격은 기존 컴포넌트와 이어지는가?
다크 모드 상태는 고려했는가?
에러 상태, 로딩 상태, disabled 상태는 있는가?

여기서부터는 단순한 “예쁜 화면” 문제가 아니다.
제품화 가능한 UI인지의 문제다.

나쁜 예는 이런 식이다.

AI가 만든 화면마다 버튼 높이가 다르다.
카드 radius가 매번 다르다.
Primary 색상이 화면마다 조금씩 다르다.
텍스트 스타일이 기존 앱과 맞지 않는다.

좋은 예는 이런 식이다.

버튼은 Button/Primary/Large 규칙을 따른다.
색상은 semantic token의 brand-primary를 사용한다.
간격은 spacing scale 기준으로만 잡는다.
상태는 default, hover, pressed, disabled를 모두 가진다.

결국 AI는 후보를 많이 뽑아주는 역할에 가깝다.
디자인 시스템은 그 후보를 제품의 언어로 수렴시키는 기준이다.

기존 디자인 시스템은 사람을 위한 문서였다

기존 디자인 시스템은 대부분 사람이 읽기 좋게 만들어졌다.

Figma에 컴포넌트가 있고, 옆에 설명이 있다.
디자이너와 개발자가 보고 이해한다.
“이 버튼은 주요 액션에 씁니다” 같은 설명도 있다.

사람에게는 충분하다.

그런데 AI에게는 조금 다르다.
AI는 애매한 약어와 암묵적인 규칙에 약하다.

예를 들어 이런 이름은 사람끼리는 대충 통한다.

Pri
Btn
Txt
Bg
Err

팀에서 오래 일한 사람은 안다.
Pri는 Primary고, Btn은 Button이고, Err는 Error다.

하지만 AI에게는 맥락이 부족하다.
특히 코드 생성까지 이어질 때 이런 약어는 쉽게 흔들린다.

AI 시대의 디자인 시스템은 사람뿐 아니라 기계도 이해할 수 있어야 한다.

시맨틱 네이밍이 더 중요해진다

시맨틱 네이밍은 이름에 의도를 담는 방식이다.

나쁜 예는 짧지만 맥락이 약하다.

Pri
Btn
Bg1
Txt2

좋은 예는 조금 길지만 의미가 분명하다.

Primary
Button
BackgroundDefault
TextSecondary

디자인 시스템에서는 이 차이가 생각보다 크다.

AI에게 다음 두 문장은 다르게 전달된다.

Use Pri Btn.

Use Primary Button component.

두 번째가 훨씬 안정적이다.
사람도 덜 헷갈리고, AI도 덜 헷갈린다.

코드에서도 마찬가지다.

--color-pri: #0066ff;
--btn-bg: var(--color-pri);

이렇게 쓰면 짧긴 하다.
하지만 시스템이 커질수록 의미 추적이 어렵다.

조금 길어도 이렇게 쓰는 편이 낫다.

--color-brand-primary: #0066ff;
--component-button-primary-background: var(--color-brand-primary);

길다고 무조건 좋은 건 아니다.
하지만 AI와 협업할수록 “짧은 이름”보다 “명확한 이름”이 더 중요해진다.

JSON 구조로 의도를 계층화해야 한다

AI가 디자인 시스템을 잘 쓰게 하려면 구조도 중요하다.

대충 한 파일에 색상과 크기와 컴포넌트 규칙을 다 넣으면 금방 엉킨다.

기본 구조는 이렇게 나눠볼 수 있다.

design-system/
  tokens/
    primitive/
      color.json
      size.json
      radius.json
      spacing.json
    semantic/
      brand-primary.json
      text.json
      background.json
  components/
    button.json
    input.json
    card.json
  patterns/
    login-form.json
    dashboard-card.json

Primitive Token은 가장 원시적인 값이다.

{
  "blue-500": "#0066ff",
  "gray-100": "#f5f5f5",
  "radius-8": "8px"
}

Semantic Token은 제품 의도를 담는다.

{
  "color.brand.primary": "{blue-500}",
  "color.background.default": "{gray-100}",
  "radius.component.card": "{radius-8}"
}

Component는 실제 UI 부품의 규칙이다.

{
  "component.button.primary": {
    "background": "{color.brand.primary}",
    "height": "40px",
    "borderRadius": "{radius.component.card}"
  }
}

이렇게 나누면 AI에게도 설명하기 쉬워진다.

Primitive 값은 직접 사용하지 말고,
Semantic Token을 통해 Component를 구성해라.

이 한 줄의 규칙이 꽤 중요하다.
AI가 매번 임의의 색상과 크기를 만들어내는 일을 줄여준다.

md 파일은 AI용 사용 설명서가 된다

사람에게 디자인 가이드 문서가 필요하듯, AI에게도 규칙 문서가 필요하다.

예를 들어 design.md 같은 파일을 둘 수 있다.

# Design System Rules

## Role

You are a UI generator that must follow this design system.

## Core Rules

- Do not create new colors.
- Use only semantic tokens.
- Use existing components before creating new ones.
- Every interactive component must include disabled state.
- Spacing must follow the spacing scale.

## Mandatory Workflow

1. Check available tokens.
2. Check existing components.
3. Compose UI with components.
4. Add missing states.
5. Return code using the approved class names.

이런 파일은 단순 문서가 아니다.
AI에게는 작업 프로토콜에 가깝다.

특히 Claude Code나 Cursor 같은 도구에서 이런 규칙 파일이 있으면 결과물이 달라진다.
AI가 “예쁜 화면”을 만드는 게 아니라, “우리 시스템에 맞는 화면”을 만들 가능성이 올라간다.

Figma에서 코드까지 이어지는 흐름

실무에서는 Figma에 있는 Variables를 코드로 가져오는 흐름이 중요하다.

대략 이런 그림이다.

Figma Variables
    ↓
variables2json
    ↓
tokens.json
    ↓
Tailwind CSS variables
    ↓
AI code generation

예를 들어 Figma에서 색상과 간격을 Variables로 관리한다.
그걸 JSON으로 뽑는다.
그 다음 Tailwind v4의 CSS 변수 형태로 변환한다.

@theme {
  --color-brand-primary: #0066ff;
  --spacing-4: 16px;
  --radius-card: 12px;
}

그러면 AI가 코드를 만들 때 이런 식으로 접근할 수 있다.

<button class="bg-brand-primary rounded-card px-4">
  시작하기
</button>

물론 실제 프로젝트에서는 클래스명, 토큰명, 빌드 파이프라인을 더 꼼꼼히 맞춰야 한다.
여기서 대충 하면 나중에 더 크게 삽질한다.
저도 이런 류의 자동화는 처음에 “JSON만 뽑으면 끝 아닌가?” 하고 봤다가, 네이밍과 계층 구조에서 꽤 막혔던 기억이 있다.

AI 시대의 디자인 시스템은 문서가 아니라 인터페이스다

예전 디자인 시스템은 팀 내부의 약속에 가까웠다.

디자이너가 보고 이해한다.
개발자가 보고 구현한다.
QA가 보고 확인한다.

AI가 들어오면 여기에 하나가 추가된다.

AI가 읽고 생성한다.

이게 꽤 큰 변화다.

디자인 시스템은 이제 사람과 사람 사이의 문서가 아니라, 사람과 AI 사이의 인터페이스가 된다.
API 문서가 모호하면 개발자가 잘못 쓰듯이, 디자인 시스템이 모호하면 AI도 잘못 쓴다.

그래서 앞으로는 이런 기준이 중요해질 것 같다.

사람이 보기 좋은가?
개발자가 구현하기 쉬운가?
AI가 해석하기 쉬운가?
자동화 파이프라인에 태울 수 있는가?

이 네 가지를 같이 봐야 한다.

기본 방식 / 개선 방식

기본 방식은 이렇다.

Figma에 컴포넌트를 만든다.
디자이너가 설명을 붙인다.
개발자가 보고 구현한다.
AI에게는 대충 프롬프트로 요청한다.

이 방식은 작은 팀에서는 돌아간다.
하지만 AI 생성물이 많아지면 금방 흔들린다.

개선 방식은 이렇다.

Figma Variables를 정리한다.
Token을 JSON으로 관리한다.
Semantic Naming을 강제한다.
Component와 Pattern을 계층화한다.
AI용 design.md 규칙을 둔다.
코드 생성 결과를 디자인 시스템 기준으로 검증한다.

핵심은 하나다.
AI에게 자유도를 주되, 제품의 경계선은 명확히 잡아야 한다.

실무에서 먼저 볼 것

처음부터 거창한 디자인 시스템을 만들 필요는 없다.

개인적으로는 아래 순서가 현실적이라고 본다.

1. 색상 토큰 정리
2. 텍스트 스타일 정리
3. spacing scale 정리
4. Button, Input, Card 같은 기본 컴포넌트 정리
5. AI용 규칙 파일 작성
6. 코드 생성 결과를 토큰 기준으로 검증

처음부터 모든 컴포넌트를 다 만들려고 하면 지친다.
버튼 하나라도 제대로 잡는 게 낫다.

특히 Button은 좋은 시작점이다.
색상, 크기, 상태, 접근성, 네이밍 규칙이 거의 다 들어있기 때문이다.

한 줄 요약

AI가 디자인을 많이 만들수록, 디자인 시스템은 더 이상 선택이 아니라 AI가 이해할 수 있는 제품 언어가 된다.