AI 드리븐

지도 위치 : 1일차 · 디자인 · 감각을 측정 가능한 규칙으로 | 이전: 5차시 AI 역할 정의의 원리 | 다음: 7차시 디자인 ② 검증 역할의 분리 키워드 : 디자인 결정을 언어로 정의, 재사용 규칙, 시안 제작

이 차시를 다 읽으면

1. 디자인 토큰 을 유와 종차로 정의하고, "따뜻하게", "깔끔하게" 같은 감각적 표현을 토큰으로 바꿀 수 있다.
2. 토큰 다음 단계인 컴포넌트 와 화면 상태 를 정의하고, 모든 화면이 갖춰야 할 상태를 말할 수 있다.
3. 와이어프레임 → 시안 → 검증 → 구현으로 이어지는 흐름에서 시안을 단일 HTML로 만드는 이유 를 말할 수 있다.
4. 디자이너 역할을 네 축(5차시)으로 정의하고, "자기 시안의 최종 승인"을 하지 않는 일에 넣는 이유를 말할 수 있다.
5. 시안을 코드 없이 브라우저로 직접 검수 할 수 있다(상태 전환, 좁은 화면).

---

0. 이 차시의 판별 축

이 차시가 답하는 질문은 "감각을 어떻게 AI가 지키고 남이 판정할 수 있는 규칙으로 바꾸는가" 입니다. 앞에서 배운 "모호함 ↔ 측정 가능"(3차시 3절)을 기능 대신 화면 에 적용합니다. 3차시에서 "빠르게"를 "500ms"로 바꿨듯, 여기서는 "따뜻하게"를 색 값으로 바꿉니다. 0절 축 3은 3차시의 "정상 경로 ↔ 실패 경로"가 화면에서 나타나는 모습입니다.

---

1. ⭐ 디자인 결정을 언어로 — 디자인 토큰

1.1 정의

디자인 토큰 — [디자인 규칙]인데, [ 색 · 글꼴 · 간격 같은 시각 결정을 이름과 값의 쌍으로 고정한다 ]는 점에서 "따뜻하게" 같은 감각적 지시와 구별된다.

AI는 "세련되게"를 이해하지 못하고 세상의 평균값 을 냅니다(앞에서 배운 'AI가 만든 티', 5차시 1절). 감각적 표현을 이름과 값 으로 바꾸면 AI가 일관된 화면을 만들 수 있습니다.

🔍 읽는 포인트 : #C2410C처럼 #으로 시작하는 여섯 글자는 색을 숫자로 적은 것 이고, px는 화면의 크기 단위(픽셀) 입니다. --color-primary가 이름, #C2410C가 값입니다. 값을 몰라도 이름이 붙어 있는가 만 보면 됩니다.

⭐ 토큰이 있으면 두 가지가 가능해집니다. AI가 매번 같은 값을 쓰고 , 7차시의 검증자가 "토큰에 없는 값을 썼는가"를 기계적으로 판정 할 수 있습니다. 기준 없는 검증은 취향 싸움이 됩니다.

1.2 반례 — 이건 디자인 토큰이 아닙니다

---

2. 재사용 규칙 — 컴포넌트와 상태

2.1 컴포넌트

컴포넌트 — [화면 부품]인데, [ 한 번 정의해 여러 화면에서 같은 모양 · 동작으로 다시 쓴다 ]는 점에서 화면마다 새로 그리는 일회성 요소와 구별된다.

새 화면을 만들 때 이 목록에서 고르고, 새로 만들지 않습니다.

Button(primary / secondary / ghost), Card, Badge, Input, DatePicker, Modal, Toast

🔍 읽는 포인트 : 괄호 안은 같은 부품의 변형 입니다. 버튼이 세 종류뿐이라는 뜻입니다.

2.2 ⭐ 모든 화면이 갖춰야 할 상태

화면 상태 — [화면의 모습]인데, [ 같은 화면이 데이터 사정(불러오는 중 · 없음 · 실패)에 따라 다르게 보이는 각각의 경우 ]라는 점에서 다른 화면으로 넘어가는 화면 전환과 구별된다.

AI가 가장 자주 빠뜨리는 부분 입니다. 정상 상태만 그리고 끝냅니다.

⭐ 이 표는 3차시의 실패 시나리오 가 화면에 나타난 모습입니다. 3차시에서 "자리가 없으면 '마감되었어요'가 보인다"고 쓴 나용 기준(3차시 4.4)이 여기서 경계 상태 로 그려집니다.

---

3. 시안 제작 흐름

3.1 와이어프레임에서 구현까지

와이어프레임 — [화면 설계 산출물]인데, [ 색 · 글꼴 없이 무엇이 어디에 놓이는지만 정한다 ]는 점에서 디자인 규칙을 입힌 시안과 구별된다.

시안 — [화면 설계 산출물]인데, [ 디자인 규칙을 적용해 실제와 비슷하게 보이지만 서버와 연결되지 않는다 ]는 점에서 실제로 동작하는 구현 화면과 구별된다.

요구사항 · 화면 목록 → 와이어프레임(배치만) → 규칙 적용 시안(HTML) → 검증(7차시) → 구현(11차시)

🔍 읽는 포인트 : 화살표 네 번째의 "검증(7차시)" 가 구현보다 앞에 있다는 것만 보면 됩니다. 고치기 가장 싼 때에 검증합니다.

3.2 말로 어려우면 이미지를 준다

"따뜻한 느낌"을 토큰으로 바꾸기 어렵다면, 좋아하는 서비스 화면을 캡처해 design/references/에 넣고 이렇게 시킵니다.

design/references/의 이미지들을 보고 공통점을 디자인 토큰으로 정리해줘.
[토큰 이름 | 값 | 어느 이미지에서 근거를 찾았나] 표로.

🔍 읽는 포인트 : 마지막 열 "어느 이미지에서 근거를 찾았나"가 AI가 지어내지 않게 하는 장치입니다.

정리된 토큰 표를 보고 "이 색은 너무 어둡다" 같은 판단을 하는 일은 코드 없이 내가 할 수 있습니다.

---

4. 디자이너 역할 정의 (네 축 적용)

# .claude/agents/designer.md
---
name: designer
description: 디자인 규칙을 정의하고 화면 시안을 만든다.
tools: Read, Write, Edit, Glob
---
## 책임
- docs/design.md의 토큰 · 컴포넌트 · 상태 규칙 관리
- 화면 시안(design/*.html) 제작
- 하지 않는 일: 서버 코드, API 변경, 자기 시안의 최종 승인

## 맥락
- docs/requirements.md, docs/design.md, design/references/의 참고 이미지

## 권한
- docs/design.md, design/ 폴더만 수정

## 완료 조건
- 토큰 외의 색 · 간격 값을 쓰지 않는다
- 화면마다 로딩 / 빈 / 에러 상태를 포함한다
- 시안 상단에 상태 전환 버튼(정상 / 로딩 / 빈 / 에러)을 달아 브라우저에서 바로 바꿔 볼 수 있게 한다
- 보고: 만든 화면 목록, 새로 추가한 규칙(있다면 이유)

🔍 읽는 포인트 : tools:에 Write · Edit이 있으니 고칠 수 있는 역할 입니다(앞에서 배운 tools 읽기, 2차시 3.1). 그리고 "하지 않는 일"의 "자기 시안의 최종 승인" .

⭐ "자기 시안의 최종 승인"을 하지 않는 일에 넣은 것이 7차시로 이어지는 다리 입니다. 만든 쪽이 스스로 "잘 만들었다"고 판정하지 못하게 해 두고, 판정은 다른 역할에게 넘깁니다.

💡 완료 조건의 "상태 전환 버튼" 줄은 코드를 읽지 않는 사람을 위한 장치입니다. 이 버튼이 있으면 코드를 열지 않고도 상태별 화면을 눌러 볼 수 있습니다.

💡 비유는 마지막에 — 디자인 토큰은 브랜드 가이드북의 색상표 입니다. 디자이너가 바뀌어도 로고 색이 바뀌지 않는 이유가 그 표 때문입니다.

---

5. 클래스온에 적용하면

docs/design.md 구성:

⚠️ 금지 사항 을 꼭 적습니다. AI가 습관처럼 쓰는 스타일(보라색 그라데이션, 이모지)은 명시적으로 막아야 나오지 않습니다. 4차시의 "이번엔 안 함" 목록과 같은 원리입니다.

화면 목록: 클래스 목록, 클래스 상세(날짜 선택), 예약 확인 · 결제, 결제 완료, 내 예약

앞으로 다시 만납니다 — 7차시에서 검증자가 이 docs/design.md를 점검 목록 으로 씁니다. 11차시에서 프론트엔드 역할이 검증을 통과한 시안을 실제 화면으로 옮깁니다.

---

6. 실습 — 맡기고 검수하기

화면은 코드를 몰라도 직접 검수할 수 있는 몇 안 되는 산출물입니다. 시안 HTML 파일을 브라우저로 열어 보는 것만으로 충분합니다.

지시

designer 역할로 두 가지를 해줘.
1. design/references/의 이미지를 근거로 docs/design.md를 만들어줘.
   토큰 표는 [토큰 이름 | 값 | 근거 이미지] 형식. 금지 사항 절을 반드시 포함.
2. design/class-list.html 시안을 만들어줘. 가짜 데이터로, 서버 연결 없이.
   - docs/design.md의 토큰 외 색 · 간격 값은 쓰지 말 것
   - 상단에 [정상 | 로딩 | 빈 | 에러 | 경계] 전환 버튼
   - 경계 상태: 제목이 50자인 클래스, 남은 자리 0인 클래스 포함
보고: 만든 파일 목록 + docs/design.md 원문 + 시안을 여는 방법 한 줄.

받을 증거

• docs/design.md 원문 (토큰 표, 금지 사항)
• 시안 파일 경로와 여는 방법

내가 직접 확인할 것

💡 여기서 찾은 문제를 바로 디자이너에게 고치라고 하기 전에, 7차시의 검증자에게 같은 것을 찾아내는지 먼저 시켜 보세요. 내가 이미 답을 아는 문제는 검증자를 시험하는 좋은 재료입니다(7차시 6절).

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 6차시 노트만 근거로 5문제를 내줘. 코드를 모르는 사람 기준으로.
"디자인 토큰의 정의와 반례", "화면 상태 다섯 가지", "와이어프레임과 시안", "자기 시안 승인을 하지 않는 이유"는 반드시 포함해줘.
감각적 표현 하나를 주고 내가 토큰으로 바꿔 보는 문제도 1개 넣어줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.