왜 시작했나: AI로 디자인 시스템 적용 자동화하기
변수만 주면 AI가 알아서 해줄 줄 알았다
최근 제품 조직이 AI를 활용해 더 빠르고 안정적으로 UI(화면 인터페이스)를 만들 수 있도록, ‘AI가 이해하고 활용할 수 있는 형태의 디자인 시스템 지침’을 정리하는 작업을 진행했습니다. 목표는 인간 디자이너의 70% 수준으로 화면을 만들어내는 것이었습니다.
기존에도 기본적인 제품 가이드가 있었지만, 관리와 확장 측면에서 완성도가 충분하지 않았습니다. 여러 방향을 비교한 끝에 새 디자인 시스템으로 'Sort UI'를 도입하기로 했는데요. 작업 속도와 결과물 완성도 면에서 장점이 뚜렷했고, 제품 전반의 UI 품질을 한 단계 정리할 수 있는 기준이 될 것 같았습니다.
그런데 곧바로 현실적인 문제에 부딪혔어요.
이 시스템을 수많은 기존 제품에 적용하려면 적지 않은 시간과 리소스가 필요했거든요. 그러다 자연스럽게 이런 이야기가 나왔습니다. "Sort UI 디자인 시스템 적용을 AI로 일부 자동화할 수 없을까?" 그 질문이 이번 작업의 출발점이었습니다.
초반에는 Figma에서 추출한 변수(색상, 간격, 폰트 크기 같은 디자인 기본값)만 잘 정리하면, AI가 그걸 기반으로 UI를 어느 정도 만들어낼 수 있지 않을까 생각했는데요. 그 가정으로 구글 안티그래비티(Antigravity)를 일주일 넘게 테스트했지만, 결과는 기대에 미치지 못했습니다.
변수와 토큰만으로는 부족했던 세 가지 이유
AI에게 재료를 줬지만 판단 기준이 없었다
첫째, Sort UI의 핵심적인 표현 중 하나인 투명도 기반의 중첩 그림자 효과(shadow effect)는 변수만으로 표현하기 어려웠습니다.
Figma 변수는 색상, 숫자, 문자열 같은 단일 값을 다루는 데 적합한데요. Sort UI의 그림자는 여러 레이어가 서로 다른 투명도와 위치(offset)로 겹쳐진 복합 구조였습니다. "얇게 두 번 겹쳐서 공중에 살짝 떠 있는 느낌" — 이런 의도는 토큰(디자인 시스템 전반에서 쓰는 디자인 값의 이름표)만으로는 전달이 안 됐습니다.
둘째, 변수명만으로는 Tab, Button, Input 같은 컴포넌트의 구조를 설명할 수 없었습니다. 컴포넌트는 단순한 스타일 값이 아니라 상태, 조합 방식, 제약 조건, 설정값(prop) 체계까지 포함된 단위이기 때문입니다.
예를 들어 [button]이라는 이름만 있다고 해서 AI가 variant(스타일 종류), size(크기), shape(모양) 같은 세부 설정을 정확히 유추하진 못했습니다.
셋째, 설령 디자인 시스템의 토큰과 컴포넌트를 모두 넘겨줬다고 해도, AI는 이를 하나의 체계가 아니라 조합 가능한 재료 목록처럼 다뤘습니다.
무엇을 쓸 수 있는지는 알아도 언제 무엇을 우선해야 하는지, 어떤 조합이 일관된 결과를 내는지까지는 스스로 판단하지 못한 거죠. 겉으로는 비슷해 보여도 실제로는 시스템이 의도한 결과와 미묘하게 다른 결과물이 반복됐습니다.
결국 AI가 디자인 시스템을 일관된 방식으로 활용하게 하려면 별도의 가이드라인과 판단 기준이 필요했습니다.
신뢰할 수 있는 기준점 찾기
문서는 낡아도 코드는 거짓말을 하지 않는다
컴포넌트의 구조와 의도를 AI가 읽을 수 있는 방식으로 정리하려면, 먼저 신뢰할 수 있는 기준점이 필요했습니다. 개발그룹 RX팀에서 디자인 시스템의 컴포넌트 구조를 Storybook(컴포넌트를 실제 코드 기준으로 문서화하는 개발 도구)으로 구현해주셨고요. 저는 Figma 변수 테이블이 아니라 이 Storybook을 기준으로 삼았습니다.
이유는 TypeScript(코드의 구조를 엄격하게 검사하는 언어)의 강제력 때문입니다.
디자인 문서는 오래되면 현실과 달라지지만, 코드 타입은 틀리면 아예 실행되지 않아요. AI가 임의로 존재하지 않는 설정값을 지어내면 코드 검사기가 바로 잡아줍니다. 잘못된 결과물이 실행 전에 걸러지는 구조입니다.
AI 규칙서 작성부터 검증까지
세부 디자인 요소를 AI 관점으로 정리하기
이번에 정리한 AI 규칙서의 핵심은 두 가지였는데요. 판단 기준을 줄이고, 예외를 통제하는 것이었습니다. AI가 UI를 만들 때 임의로 해석하지 않도록, 우선순위와 기준을 가능한 명확하게 적었습니다.
규칙서는 절대 규칙, UI 제작 결정 트리, 금지 패턴, 허용되는 예외, 모호할 때 사람에게 물어야 하는 기준 등으로 구성됩니다.
먼저, UI를 직접 구현하기 전에 디자인 시스템에 이미 존재하는 컴포넌트가 있는지 확인하도록 했습니다.
색상이나 여백을 결정할 때도 지금 만들고 있는 영역이 레이아웃인지, 일반 콘텐츠인지, 강조 영역인지 먼저 파악하도록 유도했습니다. 허용된 특수 케이스가 아니라면 기존 패턴과 시스템 규칙을 따르도록 기본 원칙도 분명히 했습니다.
또 하나 중요했던 건 금지 규칙을 명시한 부분입니다.
AI는 종종 일반적인 웹 개발 패턴을 바탕으로 임의의 스타일을 만들어내는데요. 예를 들어 bg-gray-100 text-sm rounded-md 같은 코드는 눈으로 보면 멀쩡하지만, 저희 디자인 시스템 기준으로는 한 줄에 규칙 여러 개를 위반한 코드입니다. 이를 막기 위해 사용하면 안 되는 패턴을 따로 정리하고, 시스템 안의 시맨틱 토큰과 정의된 컴포넌트만 사용하도록 범위를 좁혔습니다.
마지막으로, UI 제작 결정 트리도 함께 제공했습니다. 카드 컴포넌트를 만들 경우, 콘텐츠의 성격과 우선순위에 따라 어떤 스타일을 선택해야 하는지 스스로 판단할 수 있도록 구조를 나눴습니다. 다만 모호한 경우에는 무리하게 추론하지 않고 사람에게 질문하도록 기준을 세워, 불필요한 오류를 줄이려 했습니다.
아래는 실제 작성해 본 AI 규칙서의 일부입니다.
# Deskit UI 제작 AI 규칙서
## 0. 목적 및 전제
1. **목표**: Human Designer의 70% 수준을 AI가 신속하게 제작하는 것을 목표로 한다.
2. **역할 분담**: AI는 가이드라인을 준수하여 일관성 있는 베이스 UI를 생성하며, 세부적인 미적 튜닝(Fine-tuning)은 사람이 직접 수행한다.
3. **근거**: 모든 작업은 Storybook에 정의된 컴포넌트와 디자인 시스템 변수(Design Tokens)를 최우선으로 한다. Storybook의 스토리와 TypeScript 인터페이스가 컴포넌트 이름, `variant`, `size`, `shape`의 단일 진실 원본이다.
4. **AI 컴포넌트 사용 원칙**: AI는 DS 컴포넌트를 코드로 작성하기 전에, 반드시 해당 컴포넌트의 TypeScript 인터페이스(Props)나 Storybook 파일을 조회하여 유효한 속성(`variant`, `size` 등)만 사용해야 한다. 임의의 속성 이름(환각)을 지어내지 않는다. Storybook과 문서 예시가 충돌하면 실제 Props 인터페이스를 우선한다.
[foundations/](foundations/README.md)에서 세부 디자인 요소를 참고한다.
---
## 0. 우선순위
항상 아래 순서로 판단한다.
1. DS 컴포넌트 사용 가능 여부
2. 색상 선택은 **영역 판단이 먼저**다.
- 앱 레이아웃 영역(GNB, 사이드바, 대화방, 컴포저, 참조패널, 모달, 검색, 공지 등)이면 **앱 레이아웃 토큰**(`bg-app-*`, `text-app-*`, `border-app-*`) 우선
- 그 외 일반 surface(카드, 패널, 콘텐츠, 리스트 등)는 **DS 시맨틱 토큰**(`bg-default`, `text-subtle`, `border-default` 등) 우선
- 레이아웃 영역 안에 독립 surface가 들어오면, 바깥 껍데기는 `app-*`, 안쪽 독립 surface는 DS 시맨틱 토큰을 사용한다
3. 기존 파일/주변 코드 패턴 유지
4. 특수 케이스에 한해 하드코딩 허용 — **허용 목록은 §4 참조** (단일 진실 원본)
---
(...후략)어떤 AI에게도 통하는 규칙서가 완성됐다
규칙서를 작성하면서 신경 쓴 부분이 두 가지 있었습니다. 첫째는 세부 디자인 요소를 AI 관점으로 작성하는 것이었고, 둘째는 AI 간의 격차를 인정하고 여러 AI로 검증하는 것이었습니다.
Claude, Gemini, Codex 세 AI에게 지침의 강력함과 활용성을 여러 번 체크하며 검증했는데요. 서로 장점이 달라서 Codex가 잡는 걸 Claude가 못 잡기도 했습니다. 모든 AI에게 통하는 규칙이어야 진짜 의미 있는 규칙서라고 생각했습니다.
실제로 "Sort UI + AI 가이드라인 + 니 맘대로 아무거나 만들어봐"를 Codex와 Claude에게 각각 던졌는데, 둘이 만든 화면이 서로 상당히 닮아 있었습니다.
주체가 달라도 같은 시스템에서 나온 것처럼 보이는 것 — 그게 제가 이 규칙서에서 얻고 싶었던 결과였습니다.
마치며: 일관성, AI가 이해하는 언어에서 시작된다
돌이켜보면 이 작업은 AI를 잘 쓰기 위한 작업뿐만이 아니라, 일관성 있는 디자인을 위한 우리 팀의 언어를 더 명확하게 만드는 작업이었던 것 같습니다.
재료만 넘겨줬을 때 AI는 무엇을 쓸지는 알아도 언제 무엇을 써야 하는지를 몰랐고, 판단 기준을 규칙서로 정리하면서 비로소 일관된 결과물이 나오기 시작했습니다.
AI 생성물의 일관성 문제로 고민하고 계신 분이 있다면, AI에게 넘기는 지침부터 한 번 점검해보시길 권해요. 무엇을 허용할지보다 무엇을 쓰면 안 되는지부터 정리하는 것만으로도 생각보다 훨씬 큰 차이를 경험할 수 있습니다.