디자인 시스템을 AI 친화적으로 설계하기

디자인 시스템은 사람만 보는 규칙이 아니다

디자인 시스템은 버튼 색상표나 컴포넌트 모음만 뜻하지 않는다. 화면을 만들 때 반복해서 쓰는 규칙의 집합이다. 버튼은 어떤 상태를 가지는지, 카드 안에는 어떤 정보가 들어가는지, 모달은 언제 닫히는지, HUD의 숫자는 어떤 우선순위로 보여야 하는지까지 포함한다.

AI와 함께 작업할 때 디자인 시스템의 역할은 더 중요해진다. 사람은 화면을 보고 "이 버튼은 위험 행동이니까 빨간색이어야 한다"고 추론할 수 있다. 하지만 AI는 규칙이 명시되어 있지 않으면 비슷해 보이는 버튼을 임의로 만들거나, 화면마다 다른 간격과 이름을 사용할 수 있다.

AI 친화적인 디자인 시스템은 기계가 읽을 수 있어야 한다. 여기서 기계가 읽을 수 있다는 말은 복잡한 자동화 포맷을 반드시 써야 한다는 뜻이 아니다. 컴포넌트 이름, 상태, 토큰, 사용 조건, 엔진 매핑이 일관된 문장과 표로 정리되어 있으면 된다.

중요한 원칙은 하나다. Figma에서 만든 규칙이 Unity와 Unreal에서 같은 의미로 해석되어야 한다.

AI 생성 이미지

컴포넌트는 모양이 아니라 역할과 상태로 정의한다

AI가 일관된 UI를 만들게 하려면 컴포넌트를 "파란 버튼"처럼 설명하면 부족하다. 버튼의 역할, 상태, 변형을 함께 정의해야 한다.

예를 들어 게임 UI에서 자주 쓰는 컴포넌트는 다음처럼 정리할 수 있다.

이 표에서 중요한 것은 상태와 변형을 분리하는 것이다. 상태는 사용자의 입력이나 게임 상황에 따라 바뀐다. pressed, disabled, selected, critical이 여기에 해당한다. 변형은 같은 컴포넌트의 용도 차이다. 크기, 정보량, 슬롯 종류처럼 처음 배치할 때 결정되는 값이다.

이 구분이 없으면 AI는 상태를 새 컴포넌트처럼 만들기 쉽다. 예를 들어 Button_Primary_Disabled라는 별도 컴포넌트를 계속 만들면, 개발자는 버튼 하나의 상태 전환으로 처리할 수 있는 일을 여러 프리팹이나 위젯으로 나누어 구현하게 된다. 반대로 Button/Primary 안에 state=disabled, size=medium처럼 규칙을 두면 Figma의 변형이 Unity의 스타일 클래스나 Unreal의 위젯 상태 처리로 이어지기 쉽다.

토큰은 엔진으로 옮겨질 값의 이름이다

디자인 토큰은 색상, 글꼴 크기, 간격, 둥근 모서리 같은 값을 이름으로 관리하는 방식이다. #3A7CFF보다 color.action.primary가 낫다. 숫자 자체보다 의미가 남기 때문이다.

기본 토큰은 너무 많이 만들지 않는 편이 좋다. 처음에는 다음 네 가지면 충분하다.

8px 간격 규칙은 실무에서 다루기 쉽다. 모든 값을 8의 배수로만 쓰라는 뜻은 아니다. 작은 아이콘과 텍스트 사이에는 4px이 필요할 수 있다. 대신 기본 흐름은 4, 8, 16, 24, 32, 48처럼 제한해 AI가 임의의 13px, 27px 같은 값을 만들지 않게 한다.

Unity UI Toolkit을 쓴다면 Figma 토큰을 USS 변수로 옮길 수 있다. Unity의 USS 커스텀 프로퍼티는 --color-primary: red;처럼 정의하고 var(--color-primary)로 참조할 수 있으며, 변수가 바뀌면 이를 참조하는 스타일도 함께 갱신된다¹. 예를 들면 다음과 같다.

:root {
  --color-action-primary: #3A7CFF;
  --color-text-primary: #FFFFFF;
  --space-2: 8px;
  --radius-md: 8px;
}

.button-primary {
  background-color: var(--color-action-primary);
  color: var(--color-text-primary);
  padding: var(--space-2);
  border-radius: var(--radius-md);
}

Unreal UMG에서는 같은 토큰을 그대로 CSS처럼 쓰지는 않는다. 대신 Widget Blueprint, 스타일 데이터, Slate Brush, 머티리얼 파라미터, 데이터 테이블 같은 형태로 옮겨야 한다. 핵심은 이름을 유지하는 것이다. color.action.primary가 Figma에서는 변수이고, Unreal에서는 버튼 브러시 색이나 머티리얼 파라미터가 되더라도 이름이 같으면 AI와 개발자가 같은 값을 추적할 수 있다.

이름은 Figma와 엔진을 연결하는 주소다

AI 자동화는 이름에 크게 의존한다. 이름이 Group 12, Rectangle 8이면 AI는 역할을 추론해야 한다. 이름이 InventorySlot/Icon, InventorySlot/QuantityText이면 구조를 바로 이해할 수 있다.

팀은 Figma 레이어, Unity 프리팹, Unreal UMG 위젯 이름을 연결하는 네이밍 컨벤션을 하나로 정해야 한다.

규칙은 단순해야 한다. Figma에서는 슬래시(/)로 계층을 표현하고, Unity와 Unreal에서는 각 엔진의 관습에 맞게 접두어를 붙인다. Unreal에서 WBP_는 Widget Blueprint를 구분하기 위한 팀 규칙으로 사용할 수 있다. Unity에서는 uGUI 프리팹을 쓴다면 Prefab_UI_, UI Toolkit을 쓴다면 UXML 이름과 USS 클래스 이름을 함께 정리한다.

레이어 하위 이름도 중요하다.

Slot/Inventory
- Background
- Icon
- QuantityText
- RarityFrame
- NewBadge
- FocusRing

이 구조는 Unity에서 자식 오브젝트나 VisualElement 이름으로 옮길 수 있고, Unreal에서는 위젯 트리의 하위 요소 이름으로 옮길 수 있다. AI에게 "QuantityText는 아이템 개수가 2개 이상일 때만 표시한다"고 지시하면, 디자인과 구현이 같은 대상을 가리킨다.

자동 변환은 통제된 구조에서 더 잘 작동한다

Figma에서 엔진으로 UI를 가져오는 도구들은 대체로 정해진 컴포넌트 구조를 기대한다. Microsoft의 MRTK Figma Bridge는 Figma Toolkit의 레이아웃을 Unity의 대응 프리팹으로 인스턴스화하는 방식으로 동작한다². Unity AI Assistant의 Figma UI 생성 흐름도 Figma 프로젝트 링크와 접근 토큰을 바탕으로 디자인 데이터를 가져오고, 선택된 화면의 이미지 에셋, 참조 이미지, UXML 같은 UI 관련 파일을 생성한다³.

이 사례들이 말해 주는 점은 분명하다. 자동화는 아무 레이어나 잘 해석하는 기술이 아니다. 정해진 컴포넌트, 예측 가능한 이름, 명확한 상태가 있을 때 결과가 안정된다.

Unreal에서도 마찬가지다. 일부 Figma-to-UMG 도구는 Figma 프레임과 컴포넌트를 Widget Blueprint로, 인스턴스를 부모 컴포넌트를 참조하는 UUserWidget으로, Default, Hovered, Pressed, Disabled 같은 변형 상태를 버튼 상태로 매핑한다⁴. 물론 도구마다 지원 범위와 전제 조건은 다르다. 이 기능을 그대로 쓰지 않더라도 원리는 참고할 만하다. 상태 이름이 엔진의 상태 모델과 가까울수록 구현 비용이 줄어든다.

AI에게 줄 Guidelines 문서는 짧고 구체적이어야 한다

AI 프롬프트마다 모든 규칙을 다시 쓰면 누락이 생긴다. 그래서 팀 공통 Guidelines 문서를 만들어 두고, AI에게 작업을 맡길 때 함께 제공하는 편이 좋다. 문서는 길 필요가 없다. 처음에는 다음 구성으로 충분하다.

1. 프로젝트 UI 원칙

• 플랫폼: PC, 콘솔, 모바일 중 무엇을 우선하는가

• 입력 방식: 마우스, 터치, 게임패드 지원 여부

• 기준 해상도: 예를 들어 1920x1080, 16:9

• 접근성 기준: 최소 글자 크기, 대비, 색상만으로 상태를 표현하지 않기

• 분위기: 장르와 톤. 단, "멋지게"보다 "어두운 배경에서도 정보가 먼저 보이게"처럼 판단 기준을 쓴다.

2. 토큰 목록

• 색상 토큰과 사용처

• 타이포그래피 스케일

• 8px 기반 간격 규칙

• 라운드 값과 사용 범위

• 금지 값: 임의 색상, 임의 폰트 크기, 불규칙 간격

3. 컴포넌트 설명

각 컴포넌트는 다음 양식으로 정리한다.

Component: Slot/Inventory
Purpose: 인벤토리에서 아이템 하나를 표시한다.
Variants: small, large, equipment
States: empty, filled, selected, disabled, new
Required children: Background, Icon, QuantityText, RarityFrame, NewBadge, FocusRing
Rules:
- empty 상태에서는 Icon과 QuantityText를 숨긴다.
- selected 상태에서는 FocusRing을 표시한다.
- new 상태에서는 NewBadge를 표시하되 selected보다 시각 우선순위가 낮다.
Engine mapping:
- Unity: Prefab_UI_Slot_Inventory 또는 UXML SlotInventory
- Unreal: WBP_Slot_Inventory

4. 네이밍 규칙

• Figma 컴포넌트: Category/Name

• Figma 하위 레이어: 역할 기반 PascalCase

• Unity 프리팹: Prefab_UI_Category_Name

• Unity USS 클래스: .category-name, .category-name--state

• Unreal 위젯: WBP_Category_Name

• 상태명: default, hover, pressed, disabled, focused, selected처럼 제한된 목록 사용

프롬프트에는 목표, 규칙, 검증 기준을 함께 넣는다

AI에게 디자인 시스템을 활용시키려면 "이 스타일로 만들어 줘"보다 구체적인 작업 지시가 필요하다.

목표:
Figma의 Slot/Inventory 컴포넌트를 기준으로 RPG 장비 인벤토리 화면을 확장한다.

사용 규칙:
- 색상, 간격, 라운드는 Guidelines의 토큰만 사용한다.
- 슬롯은 새 컴포넌트를 만들지 말고 Slot/Inventory의 variant와 state로 표현한다.
- 레이어 이름은 Background, Icon, QuantityText, RarityFrame, NewBadge, FocusRing을 유지한다.
- 기준 간격은 8px 시스템을 따른다.

엔진 매핑:
- Unity 프리팹 이름은 Prefab_UI_Slot_Inventory로 가정한다.
- Unreal 위젯 이름은 WBP_Slot_Inventory로 가정한다.

검증 기준:
- empty, selected, disabled, new 상태가 모두 표현되어야 한다.
- 임의 색상과 임의 폰트 크기를 만들지 않는다.
- 게임패드 포커스 위치가 FocusRing으로 확인되어야 한다.

이런 지시는 AI의 자유도를 없애는 것이 아니다. 반복되는 판단을 줄여 사람이 더 중요한 결정을 보게 만든다. 화면의 정보 위계가 적절한지, 게임 조작 흐름이 자연스러운지, 특정 장르의 감각과 맞는지는 여전히 사람이 판단해야 한다.

작은 시스템부터 만들고 계속 갱신한다

처음부터 완벽한 디자인 시스템을 만들 필요는 없다. 오히려 버튼, 카드, 모달, HUD, 인벤토리 슬롯처럼 자주 쓰는 컴포넌트 다섯 개를 먼저 정리하는 편이 낫다. 각 컴포넌트에 상태와 변형을 붙이고, 토큰 이름을 맞추고, Unity와 Unreal 이름을 연결한다.

그다음 AI로 화면을 만들 때마다 결과를 검토한다. 새 값이 생겼다면 토큰에 추가할지, 기존 토큰으로 바꿀지 결정한다. 새 컴포넌트가 필요하다면 역할과 상태를 먼저 정의한다. 이렇게 디자인 시스템은 문서로 끝나는 것이 아니라 제작 루프 안에서 조금씩 정확해진다.

AI 친화적인 디자인 시스템의 목표는 자동 생성을 늘리는 데 있지 않다. 팀이 같은 언어로 말하게 만드는 데 있다. Figma의 컴포넌트, Unity의 프리팹과 USS, Unreal의 UMG 위젯이 같은 이름과 규칙을 공유하면 AI는 더 적은 추측으로 작업할 수 있다. 그리고 사람은 결과를 더 빠르게 검증할 수 있다.

참고

¹Unity Manual Create USS variables

²MRTK Figma Bridge for Unity Beta

³Unity AI Assistant Create UI from a Figma design

⁴ViewportUI Figma to Unreal Engine UMG Plugin