이 글은 누구를 위한 것인가
- Cursor, Copilot, v0 같은 AI 개발 도구를 쓰는 팀
- AI가 생성한 UI의 브랜드 일관성 문제를 겪고 있는 디자이너·개발자
- 앞으로 AI 에이전트 시대에 디자인 시스템이 어떻게 변해야 하는지 고민하는 분
들어가며
개발팀이 Cursor AI를 도입했다. 생산성이 올랐다. 그런데 AI가 생성하는 UI를 보니 문제가 있다. 버튼 색상이 우리 브랜드 컬러와 미묘하게 다르고, 폰트 크기 체계도 우리 디자인 시스템과 맞지 않는다. 간격 규칙도 들쭉날쭉하다.
AI가 "비슷하게" 만들어주지만, "정확하게" 우리 시스템대로는 못 한다. 결국 디자이너가 AI 생성 코드를 수동으로 다 검토하고 수정하게 된다. 이러면 AI 도입의 이점이 반감된다.
2026년 현재 이 문제를 해결하는 방향이 분명해졌다. AI가 우리 디자인 시스템을 이해할 수 있도록 시스템 자체를 설계하는 것이다. 단순히 컴포넌트를 만드는 것을 넘어, AI가 읽고 따를 수 있는 규칙과 메타데이터를 갖춘 "AI-ready 디자인 시스템"을 구축해야 한다.
1. AI는 어떻게 UI를 생성하는가
현재 Cursor, GitHub Copilot, Vercel v0 같은 AI 도구들은 UI를 생성할 때 다음을 참고한다.
- 코드베이스에 있는 기존 컴포넌트 패턴
- 프롬프트에 명시된 디자인 지시사항
- AI 학습 데이터에 포함된 일반적인 UI 패턴
문제는 AI가 우리 팀의 특정 규칙을 모른다는 것이다. "버튼은 항상 border-radius: 8px"이라는 규칙, "primary 색상은 반드시 #2D6BE4"라는 규칙을 AI는 추론하지 못한다. 직접 알려주지 않으면.
2. 컴포넌트에 인텐트(Intent) 메타데이터 부여하기
AI-ready 디자인 시스템의 핵심은 컴포넌트에 의도(Intent)를 명시적으로 태깅하는 것이다.
기존 컴포넌트는 "어떻게 생겼는가"만 정의한다. AI-ready 컴포넌트는 "무엇을 위한 것인가"도 정의한다.
// 기존 방식: 스타일만 정의
const Button = styled.button`
background: #2D6BE4;
color: white;
border-radius: 8px;
padding: 12px 24px;
`;
// AI-ready 방식: 인텐트와 컨텍스트도 정의
/**
* @intent primary-action
* @context form-submit, cta, primary-navigation
* @not-for destructive-action, secondary-choice
* @design-token button-background-primary
* @accessibility 클릭 가능 요소, 폼 제출 시 type="submit" 사용
*/
const PrimaryButton = ({ children, ...props }) => (
<button className="btn-primary" {...props}>
{children}
</button>
);
이 주석이 있으면 AI 도구들이 "주요 동작을 유발하는 버튼이 필요하다"는 요청에 PrimaryButton을 선택한다. "삭제 확인 버튼"이 필요할 때는 @not-for destructive-action 태그를 읽고 DangerButton을 선택한다.
3. 시맨틱 토큰으로 AI 오용 방지하기
AI가 가장 자주 실수하는 부분이 색상 선택이다. color-blue-500이라는 Primitive 토큰을 직접 쓰는 대신, color-action-primary 같은 Semantic 토큰을 쓰도록 강제해야 한다.
/* AI가 잘못 쓰는 방식 */
.button {
background-color: var(--color-blue-500); /* Primitive 토큰 직접 사용 */
}
/* 올바른 방식 */
.button {
background-color: var(--color-action-primary); /* Semantic 토큰 사용 */
}
왜 이게 중요한가? --color-blue-500을 직접 쓰면 나중에 브랜드 색상이 파란색에서 다른 색으로 바뀔 때 수동으로 모두 찾아서 바꿔야 한다. --color-action-primary를 쓰면 토큰 값 하나만 바꾸면 된다.
AI 도구에게 "Primitive 토큰은 직접 쓰지 마세요"라는 규칙을 .cursor/rules 파일이나 GitHub Copilot 설정에 명시할 수 있다.
# .cursor/rules
- 항상 Semantic 토큰을 사용하세요 (예: --color-action-primary)
- Primitive 토큰 (--color-blue-500 등)은 직접 사용하지 마세요
- 컴포넌트는 /src/components에 있는 기존 컴포넌트를 우선 활용하세요
- 새 스타일을 인라인으로 추가하지 마세요. 디자인 토큰을 사용하세요
4. Storybook을 AI 학습 소스로 활용하기
Storybook은 컴포넌트를 독립적으로 개발하고 문서화하는 도구인데, AI-ready 시스템에서 또 다른 역할을 한다. Storybook의 스토리 파일이 AI가 "어떻게 쓰는지"를 배우는 예시 코드 역할을 한다.
// Button.stories.tsx
export const PrimaryButtonStory: Story = {
args: {
variant: 'primary',
children: '제출하기',
},
parameters: {
docs: {
description: {
story: '폼 제출, CTA, 주요 동작에 사용. 한 화면에 하나만 배치 권장.',
},
},
},
};
export const DangerButtonStory: Story = {
args: {
variant: 'danger',
children: '삭제하기',
},
parameters: {
docs: {
description: {
story: '되돌릴 수 없는 삭제, 파괴적 동작에만 사용.',
},
},
},
};
Storybook 문서가 자세할수록, 코드베이스를 학습하는 AI 도구들이 더 정확하게 컴포넌트를 활용한다.
5. AI 생성 UI의 브랜드 컴플라이언스 자동 검증
아무리 규칙을 잘 만들어도 AI가 틀릴 수 있다. 그래서 자동화된 검증 도구가 필요하다.
시각적 회귀 테스트로 AI가 생성한 컴포넌트가 기존 디자인 시스템과 어떻게 다른지 자동으로 비교한다.
토큰 사용 린팅으로 코드에서 Primitive 토큰을 직접 사용하거나 하드코딩된 색상값이 있으면 자동으로 에러를 표시한다.
# ESLint 규칙으로 하드코딩된 색상값 탐지
# error: 'color: #2D6BE4' is a hardcoded value. Use design token instead.
CI 파이프라인에 이 검증을 추가하면, AI가 생성한 코드가 PR로 들어올 때 자동으로 디자인 시스템 규칙을 위반했는지 체크된다.
6. 작은 팀에서 시작하는 AI-ready 디자인 시스템 구축 순서
완벽한 시스템을 처음부터 만들 필요는 없다. 단계별로 접근하자.
| 단계 | 목표 | 소요 시간 |
|---|---|---|
| 1단계 | 색상·타이포그래피·간격 토큰 정의 | 1~2주 |
| 2단계 | 핵심 컴포넌트 10개에 인텐트 메타데이터 추가 | 2~3주 |
| 3단계 | .cursor/rules 또는 Copilot 설정에 규칙 문서화 | 1주 |
| 4단계 | Storybook 문서 보강 | 지속적으로 |
| 5단계 | 토큰 사용 린팅 CI 적용 | 1주 |
단계 1부터 차근차근 해도 AI 도구 활용 품질이 눈에 띄게 달라진다.
맺으며
AI가 UI를 만드는 세상에서, 디자인 시스템은 단순한 컴포넌트 라이브러리를 넘어 **AI와 팀이 공유하는 브랜드 규칙의 단일 진실(Single Source of Truth)**이 되어야 한다.
디자인 시스템이 없는 팀에서 AI를 쓰면 어떤 일이 생기는지 이미 많은 팀이 경험하고 있다. AI가 빠르게 만들어주지만, 제각각인 스타일 때문에 결국 사람이 다 뒤를 수습해야 한다. AI를 제대로 활용하려면, AI가 따를 수 있는 명확한 규칙을 먼저 만들어야 한다. 그것이 AI 시대의 디자인 시스템이 해야 할 일이다.