이 글은 생성형 AI를 활용해 디자인 시스템의 핵심 산출물인 토큰, 컴포넌트 정의, 상태 표를 한 번에 뽑아내는 프롬프트 구조를 정리한다. 목표는 팀마다 다른 용어와 형식을 프롬프트 단계에서 표준화해 재작업을 줄이고, 변수 변경과 상태 정의를 빠르게 문서화하는 것이다. 각 소제목은 개념과 특징, 장단점, 적용 예시, 주의점을 한 문단 안에서 이어가며 실무에 바로 적용할 수 있도록 구성했다.
토큰 설계 프롬프트
토큰 프롬프트의 핵심은 컬렉션, 네이밍, 모드 축을 먼저 고정하는 것이다. 컬렉션은 foundations, component, brand처럼 목적 중심으로 나누고, 네이밍은 의미 기반 계층을 유지한다. 색은 brand.primary.fg, 배경은 surface.card.bg처럼 읽는 순간 역할과 단계가 보이게 정의한다.
장점은 테마 전환과 제품 확장 시 유지 비용이 낮다는 점이다. 반면 초기 정의가 과도하면 관리가 복잡해질 수 있다. 따라서 색과 간격부터 시작하고 반경, 그림자, 크기 같은 항목은 소수 단계로 출발해 운영 부담을 줄인다.
프롬프트에는 역할, 맥락, 제약을 한 세트로 넣는다. 역할은 디자인 토큰 아키텍트, 맥락은 라이트 다크 모드와 웹iOS Android 지원, 제약은 명도 대비 기준 통과와 단계 수 제한처럼 적는다. 예시 문장 구조는 다음과 같다. 토큰 컬렉션과 모드 축을 정의하고, 색 간격 반경 그림자를 우선 표준화한다. 각 토큰은 이름, 용도, 예시 값, 접근성 근거를 포함한다. 단계 수는 색 7, 간격 8 이하로 제한한다.
별칭 규칙을 미리 명시해 상위 토큰 변경이 하위 컴포넌트에 자동 전파되도록 한다. 다만 컬렉션 간 교차 참조는 최소화한다. 이렇게 하면 색상 교체나 밀도 변경 같은 요구가 와도 프롬프트 재실행만으로 최신 표를 빠르게 갱신할 수 있다.
예시:
역할: 너는 디자인 토큰 아키텍트다.
목표: 우리 제품의 토큰 체계를 라이트/다크 + Web/iOS/Android에서 일관되게 쓰도록 표준안으로 산출하라.
맥락:
- 컬렉션: foundations, component, brand
- 우선 토큰: color, space, radius, elevation
- 모드: theme(light, dark), platform(Web, iOS, Android)
- 접근성: WCAG AA 텍스트 대비 준수
제약:
- color 단계 7, space 단계 8, radius 단계 4, elevation 단계 3
- 모든 값은 상수값이 아닌 참조 기반(alias) 구조 권장
- 컬렉션 간 교차 참조 최소화, 별칭 체인은 2단 이내
출력 형식:
1) 컬렉션/토큰/이름/용도/값(light)/값(dark)/별칭/비고(대비근거) 컬럼의 마크다운 표
2) 별칭 규칙과 네이밍 규칙(예: brand.primary.fg, surface.card.bg, space.md) 6줄 요약
3) 대비 미달 항목이 있을 경우 대안(명도 조정 또는 레이어 변경) 제안 3줄
검증:
- 표 마지막에 대비 검증 실패 항목 리스트업
- 모드 전환 시 깨질 수 있는 리스크 3가지와 회피책 3가지 제시
컴포넌트 정의 프롬프트
컴포넌트 프롬프트는 슬롯, 레이아웃, 변형 축을 분리해 지시하는 것이 핵심이다. 슬롯은 아이콘, 레이블, 서브텍스트 같은 내용 단위를 뜻하고, 레이아웃은 오토 레이아웃의 패딩, 갭, 정렬 규칙을 의미한다. 변형 축은 사이즈, 타입, 모드처럼 소수로 제한해 조합 폭은 넓고 관리 개수는 적게 만든다.
장점은 재사용성과 학습 속도가 동시에 높아진다는 점이다. 단점은 초기 축 설정이 빈약하면 후반 확장에 무리가 생길 수 있다는 점이다. 따라서 공통 상태와 공통 크기부터 합의해 두고 예외는 별도 규칙으로 관리한다.
프롬프트에는 과업을 명확히 적는다. 버튼, 입력, 카드의 슬롯 레이아웃 변형 축을 표로 산출하라처럼 구체화한다. 구현 제약도 함께 건다. 아이콘 유무는 Boolean 속성, 텍스트 교체는 Text 속성, 아이콘 교체는 Instance Swap으로 처리 같은 방식이 안정적이다.
예시는 다음과 같이 구성한다. 버튼 컴포넌트의 size(sm, md, lg), type(primary, secondary), state(default, hover, pressed, disabled)를 정의하라. 각 조합별 최소 최대 너비, 라벨 줄바꿈 규칙, 포커스 링 범위를 포함하라. 오류 상태와 빈 상태 같은 예외 화면을 별도 컴포넌트로 분리할지, 동일 컴포넌트의 속성으로 관리할지는 기준 문장으로 고정한다.
예시:
역할: 너는 컴포넌트 시스템 설계자다.
목표: 버튼, 입력, 카드 3종의 슬롯 레이아웃 변형 축을 표준화하고 구현 제약까지 명시하라.
맥락:
- 슬롯: icon, label, helper(옵션)
- 레이아웃: Auto Layout(패딩/갭/정렬), min/max width, 줄바꿈 규칙
- 변형 축: size(sm, md, lg), type(primary, secondary), mode(light, dark)
제약:
- 아이콘 유무는 Boolean, 아이콘 교체는 Instance Swap, 텍스트 교체는 Text 속성으로 처리
- Variant 축은 3개 이내, 조합 폭은 24 이내
- 포커스 링은 토큰 참조로 지정, 터치 타깃 최소 44pt
출력 형식:
1) 컴포넌트/슬롯/필수여부/설명 표
2) 컴포넌트/AutoLayout(패딩 갭 정렬)/min–max/줄바꿈 표
3) 컴포넌트/변형축/값/비고(접근성 플랫폼 특이점) 표
4) 예외 처리 기준: 오류 상태, 빈 상태를 별도 컴포넌트로 분리할지 혹은 속성으로 관리할지 결정 문장 5줄
검증:
- 조합 수 계산과 과도 조합 경고
- iOS/Android 네이티브 패턴과 충돌하는 지점 3곳 지적
상태 표 자동 산출 프롬프트
상태 표 프롬프트는 제품 공통 상태를 최소셋으로 정의하는 원칙이 중요하다. 기본, 호버, 프레스, 포커스, 비활성, 로딩, 에러처럼 사용 빈도가 높은 상태만 남기고, 상태마다 색, 테두리, 그림자, 포커스 인디케이터, 커서, 애니메이션을 속성별로 나열한다.
장점은 리뷰와 QA에서 체크리스트로 바로 사용할 수 있다는 점이다. 단점은 상태가 많아질수록 유지 비용이 늘어난다는 점이다. 불필요한 상태는 과감히 합치고, 플랫폼 특화 상태는 주석으로 범위를 명확히 한다.
프롬프트에는 다음 제약을 추가한다. 각 상태의 시각, 동작, 접근성 규칙을 표로 산출하고, 모든 값은 토큰 참조로 표기하라. 예시 열 구성은 state, bg, border, text, helper, icon, focus ring, keyboard, aria, motion이다. WCAG 대비 기준을 넘지 못하는 항목이 있으면 대안을 제안하도록 요구한다.
키보드 탐색과 스크린 리더 라벨링 같은 비시각 규칙을 함께 포함해 개발 협업의 누락을 줄인다. 상태 간 전이 모션의 지속 시간과 이징은 범위로 정의해 플랫폼별 조정 여지를 남긴다. 이렇게 표준 템플릿을 고정하면 새 컴포넌트가 추가될 때도 프롬프트 재실행만으로 일관된 상태 표를 확보할 수 있다.
예시:
역할: 너는 UX 품질 접근성 감수자다.
목표: 입력 필드(Text Field) 상태 표를 제품 공통 최소셋으로 산출하라.
맥락:
- 필수 상태: default, hover, focus, filled, error, disabled, loading
- 속성 축: bg, border, text, helper, icon, focus ring, cursor, motion
- 키보드 스크린리더: Tab 순서, Enter/ESC 동작, aria-* 규칙
제약:
- 모든 시각 값은 토큰 참조로 표기(hex 금지)
- WCAG AA 대비 미달 시 대안 색/두께/레이어 조정안 제시
- 모션 지속시간 120–200ms, 이징은 표준 2종(enter/exit)만 사용
출력 형식:
1) state/bg/border/text/helper/icon/focus ring/cursor/motion/aria/keyboard 컬럼의 마크다운 표
2) 상태 간 전이(예: default focus, error default) 모션 스펙 5줄
3) 접근성 테스트 항목 6개 체크리스트
검증:
- 대비 경고 목록과 수정 권고안
- 키보드 포커스 미노출 위험 시나리오 2개와 대응
실무 도입은 토큰부터 시작해 컴포넌트, 상태 표 순으로 확장하는 것이 안정적이다. 첫 주에는 색 간격 토큰을 표준화하고, 둘째 주에 버튼 입력 카드 같은 고빈도 컴포넌트를 정의한다. 셋째 주에 상태 표를 산출해 QA와 접근성 점검 루틴으로 연결한다.
프롬프트가 장황해지면 초점이 흐른다. 역할, 맥락, 제약의 세 줄 구조를 지키고, 결과를 릴리즈 노트로 기록해 버전 관리한다. 팀 합의 없이 프롬프트를 개별 수정하면 표준이 무너질 수 있으므로 변경은 주기별로 묶어 배포하고 스냅샷 페이지로 회귀를 검증한다.
이렇게 작은 기준을 문서화하면 프롬프트 한 번으로 디자인 시스템의 핵심 산출물을 재현 가능하게 생산할 수 있다. 결과적으로 재작업은 줄고, 팀 간 전달 손실은 감소하며, 릴리즈 속도와 일관성이 함께 오른다.