☰ 분류

디자인 시스템 감사 프롬프트

UI나 제품 화면을 넣으면 타이포그래피, 간격, 색, 컴포넌트, 인터랙션의 불일치와 디자인 부채를 점수와 함께 받습니다.

분류디자인 › 화면·제품 설계
태그분석검토체크리스트
프롬프트 (영어 본문 · 답은 한국어로 옵니다)
You are a design systems engineer performing a forensic UI audit.

Your objective is to detect inconsistencies, fragmentation, and hidden design debt.

Be specific. Avoid generic feedback.

---

### 1. Typography System
- Font scale consistency
- Heading hierarchy clarity

### 2. Spacing & Layout
- Margin/padding consistency
- Layout rhythm vs randomness

### 3. Color System
- Semantic consistency
- Redundant or conflicting colors

### 4. Component Consistency
- Buttons (variants, states)
- Inputs (uniform patterns)
- Cards, modals, navigation

### 5. Interaction Consistency
- Hover / active states
- Behavioral uniformity

### 6. Design Debt Signals
- One-off styles
- Inline overrides
- Visual drift across pages

---

### Output Format:

**Consistency Score (1–10)**  
**Critical Inconsistencies**  
**System Violations**  
**Design Debt Indicators**  
**Standardization Plan**  
**Priority Fix Roadmap**

어떤 프롬프트인가

디자인 시스템이 화면 전반에서 어긋난 지점을 찾을 때 쓰기 좋다. 1~10점 일관성 점수와 표준화 계획, 우선순위 수정 로드맵을 요구한다.

모델 비교

ChatGPT가 근거와 실행안의 균형이 가장 좋다. Gemini는 구체적이지만 과장과 오류가 있으며, [C]는 답변이 없다.

ChatGPT종합 1위
46/ 50

+ 수치 차이와 구조적 원인을 정확히 연결했다.

- 다소 길고 일부 개선 토큰은 근거가 약하다.

Gemini
36/ 50

+ 클래스별 비교와 개선 코드가 매우 구체적이다.

- 접근성 판정·40px 높이·일정 추정이 부정확하다.

기준ChatGPTGemini앞선 모델
지시 준수109ChatGPT +11%
정확성95ChatGPT +80%
구체성109ChatGPT +11%
구성·가독성98ChatGPT +13%
분량 적정성85ChatGPT +60%

gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-25). 측정값이 아니라 AI 심사 결과입니다.

답 전문 보기

같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.

넣은 입력
[붙여 넣은 자료]
다음은 저희 커머스 어드민 서비스의 컴포넌트 CSS 발췌본입니다.

.btn-primary { padding: 10px 16px; background: #3B82F6; border-radius: 6px; font-size: 14px; }
.btn-submit { padding: 12px 20px; background: #2563EB; border-radius: 4px; font-size: 15px; }
.card { padding: 16px; margin-bottom: 24px; border-radius: 8px; box-shadow: 0 1px 3px rgba(0,0,0,0.1); }
.card-product { padding: 14px; margin-bottom: 20px; border-radius: 12px; box-shadow: 0 2px 4px rgba(0,0,0,0.08); }
.text-heading { font-family: Pretendard; font-size: 22px; font-weight: 700; }
.text-title { font-family: Noto Sans KR; font-size: 20px; font-weight: 600; }
.input-box { border: 1px solid #D1D5DB; padding: 8px 12px; border-radius: 4px; }
.input-search { border: 1px solid #E5E7EB; padding: 10px 14px; border-radius: 8px; }
.error-text { color: #FF3B30; }
.error-msg { color: #DC2626; }

버튼, 카드, 인풋이 페이지마다 조금씩 다른 값으로 재구현되어 있는데 정확히 뭐가 문제인지 정리해 주세요.
gpt-5.6-luna (codex CLI · 에이전트 하네스) · 실행일 2026-09-24

Consistency Score (1–10)
4/10

기본 컴포넌트 구조는 존재하지만, 동일한 역할의 컴포넌트가 페이지별로 별도 구현되어 있어 토큰과 상태 정의가 분리된 상태입니다.

Critical Inconsistencies

  • 버튼의 동일한 기본 역할이 .btn-primary와 .btn-submit으로 분리되어 있습니다.
    • 패딩: 10px 16px vs 12px 20px
    • 배경색: #3B82F6 vs #2563EB
    • 모서리: 6px vs 4px
    • 폰트 크기: 14px vs 15px
  • .card와 .card-product가 카드 변형인지 별도 컴포넌트인지 정의되어 있지 않습니다.
    • 패딩: 16px vs 14px
    • 하단 여백: 24px vs 20px
    • 모서리: 8px vs 12px
    • 그림자 강도도 다릅니다.
  • 입력 필드가 시각적으로 다른 컴포넌트처럼 구현되어 있습니다.
    • 일반 입력: 8px 12px, 4px
    • 검색 입력: 10px 14px, 8px
    • 검색 기능 때문에 크기가 달라져야 한다면 명시적인 size 또는 variant 규칙이 필요합니다.
  • 에러 색상이 두 가지입니다.
    • #FF3B30은 iOS 계열 색상에 가깝고
    • #DC2626은 Tailwind 계열 색상입니다.
    • 같은 오류 의미에 서로 다른 색을 사용해 의미 체계가 분산됩니다.

System Violations

  • 타이포그래피 폰트가 Pretendard와 Noto Sans KR로 혼용됩니다.
    • 한글 렌더링, 글자 폭, 행간, 숫자 정렬이 달라져 페이지 간 인상이 달라질 수 있습니다.
    • 하나를 기본 폰트로 정하고 다른 폰트는 명시적인 예외로 제한해야 합니다.
  • 제목 계층이 명확하지 않습니다.
    • 22px / 700과 20px / 600이 이름만 다르고 계층 관계가 정의되어 있지 않습니다.
    • heading, title이 실제 HTML heading 단계와 연결되어 있지 않습니다.
  • 색상에 토큰이 없습니다.
    • #3B82F6과 #2563EB 모두 파란색 primary 계열이지만 용도가 정의되지 않았습니다.
    • hover, active, disabled, focus 색상이 없습니다.
  • 간격 단위가 체계적으로 관리되지 않습니다.
    • 14px, 16px, 20px, 24px가 각각 어떤 의미인지 알 수 없습니다.
    • 카드 내부 간격과 컴포넌트 간 간격이 같은 체계에 포함되어 있지 않습니다.
  • radius가 4px, 6px, 8px, 12px로 분산되어 있습니다.
    • 컴포넌트 크기별 의도나 공통 규칙이 보이지 않습니다.
  • 그림자도 카드 유형에 따라 임의로 달라집니다.
    • 제품 카드가 일반 카드보다 더 둥글고 그림자는 오히려 약합니다.
    • 정보 계층에 따른 elevation 규칙으로 설명되지 않습니다.

Design Debt Indicators

  • .btn-submit, .input-search, .card-product처럼 페이지 또는 기능 중심의 one-off 클래스가 생성되어 있습니다.
  • 같은 의미의 상태가 .error-text, .error-msg로 나뉘어 있습니다.
  • 색상, 간격, radius, 그림자가 하드코딩되어 있어 전역 변경 비용이 높습니다.
  • 버튼과 입력의 상태 정의가 없습니다.
    • hover
    • focus-visible
    • active
    • disabled
    • loading
  • 컴포넌트 이름이 시각적 역할과 기능적 역할을 혼합합니다.
    • primary는 스타일 변형이고 submit은 사용 목적입니다.
    • 한 컴포넌트의 variant와 type을 분리해야 합니다.
  • 카드가 콘텐츠 유형별로 복제될 가능성이 높습니다. 제품 카드가 일반 카드의 변형이라면 공통 카드 토큰을 상속해야 합니다.

Standardization Plan

  1. 디자인 토큰을 먼저 정의합니다.
:root {
  --font-family-base: "Pretendard", sans-serif;

  --font-size-sm: 14px;
  --font-size-md: 16px;
  --font-size-lg: 20px;
  --font-size-xl: 22px;

  --space-2: 8px;
  --space-3: 12px;
  --space-4: 16px;
  --space-5: 20px;
  --space-6: 24px;

  --radius-sm: 4px;
  --radius-md: 6px;
  --radius-lg: 8px;

  --color-primary: #2563EB;
  --color-primary-hover: #1D4ED8;
  --color-border: #D1D5DB;
  --color-error: #DC2626;
}
  1. 버튼은 하나의 컴포넌트에 variant와 size를 둡니다.
  • variant: primary, secondary, danger
  • size: sm, md, lg
  • type: button, submit, reset

submit을 별도 시각 컴포넌트로 만들지 않고, 필요하면 type="submit"으로 처리합니다.

  1. 카드는 공통 기본값과 명시적인 변형으로 분리합니다.
  • 기본 카드: padding: 16px, radius: 8px
  • 제품 카드가 실제로 달라야 한다면 variant="product"로 정의
  • 단순 복제라면 .card-product를 제거하고 .card를 재사용
  1. 입력은 공통 구조를 사용합니다.
  • input 기본 스타일
  • size: sm, md, lg
  • variant: default, search
  • 오류 상태는 aria-invalid와 공통 .is-error로 통합
  1. 오류 색상은 하나의 semantic token으로 통일합니다.
.text-error,
.input.is-error,
.form-message.is-error {
  color: var(--color-error);
}

Priority Fix Roadmap

  1. 높음: primary 색상과 error 색상 통합
  2. 높음: 버튼, 입력, 카드의 공통 기본 컴포넌트 정의
  3. 높음: hover, focus, disabled 등 공통 상태 추가
  4. 중간: Pretendard 또는 Noto Sans KR 중 기본 폰트 단일화
  5. 중간: spacing, radius, shadow 토큰 도입
  6. 중간: .btn-submit, .error-msg 같은 기능·페이지별 중복 클래스 정리
  7. 낮음: 제품 카드, 검색 입력 등 실제 변형에만 명시적인 variant 부여

핵심 문제는 값이 조금씩 다른 것 자체보다, 그 차이가 “의도된 변형”인지 “페이지별 재구현”인지 구분할 수 없다는 점입니다. Tokens → Base component → Variant → State 순서로 체계를 정리해야 추가적인 시각적 드리프트를 막을 수 있습니다.

같은 분류의 프롬프트

7대7 축구 팀 앱 설계 프롬프트
접근성 감사자 역할을 맡기는 프롬프트
접근성 감사자 역할 프롬프트
접근성 전문가 역할 프롬프트
접근성 테스트 워크플로 프롬프트