AI 드리븐

지도 위치 : 1일차 · 디자인 · 과정 전체에 반복되는 원리를 처음 세우는 자리 | 이전: 6차시 디자인 ① 화면 설계 역할 | 다음: 8차시 아키텍처 결정과 근거 기록 키워드 : 만든 자와 검증하는 자의 분리, 권한을 제한한 검증자, 화면 점검

이 차시를 다 읽으면

1. 만든 쪽의 자기 검토가 왜 검증이 아닌지 세 가지 이유 로 설명할 수 있다.
2. 검증 분리의 세 조건(다른 맥락 · 제한된 권한 · 명시적 기준) 을 말하고, 하나가 빠지면 무엇이 무너지는지 말할 수 있다.
3. 검증자 정의 파일에서 tools: 줄만 보고 보고만 하는 역할인지 판정할 수 있다.
4. 코드만 읽는 점검과 실제 화면을 띄워 보는 점검 의 차이를 정적 ↔ 동적 축으로 말할 수 있다.
5. 검증자도 AI라는 문제를 일부러 심은 문제 와 교차 검증으로 다룰 수 있다.

---

0. 이 차시의 판별 축

이 차시가 답하는 질문은 "검증이 언제 의미를 갖는가" 입니다. 앞에서 배운 여섯 기능 중 검증 (2차시 3.2)을 원리로 세우는 자리이고, 디자이너의 "자기 시안의 최종 승인은 하지 않는다"(6차시 4절)를 회수하는 자리입니다. 이 원리는 디자인에서 처음 배우고 코드 리뷰와 동작 검증(13차시), 자동 리뷰(20차시) 에서 그대로 반복됩니다. README 6장 "세 문장"의 두 번째 문장입니다.

---

1. 왜 만든 쪽의 자기 검토는 검증이 아닌가

만든 에이전트에게 "잘 만들었는지 확인해줘"라고 하면 대부분 "잘 만들었다" 고 답합니다. 이유는 셋입니다.

⭐ 코드를 읽는 사람은 검증자가 놓친 것을 직접 잡을 수 있습니다. 코드를 읽지 않으면 검증자가 놓친 것은 그대로 지나갑니다. 그래서 검증 역할을 분리하는 일은 곧 나의 '읽는 눈'을 만드는 일 이고, 과정 전체에서 가장 중요한 원리입니다(README 9.1의 신뢰 근거 ④ 교차 검증).

---

2. ⭐ 분리의 세 조건

2.1 정의

검증 역할의 분리 — [검증 방식]인데, [ 다른 맥락 · 제한된 권한 · 명시적 기준 세 조건을 갖춘 별도 역할이 판정한다 ]는 점에서 만든 쪽이 스스로 하는 자기 검토와 구별된다.

2.2 반례 — 이건 검증 분리가 아닙니다

💡 비유는 마지막에 — 회계 감사입니다. 장부를 쓴 사람이 아닌 감사인이(①), 장부를 고칠 권한 없이 의견만 내고(②), 회계 기준에 따라 판정합니다(③). 셋 중 하나만 빠져도 감사 보고서는 믿을 수 없습니다.

---

3. 권한을 제한한 검증자

# .claude/agents/design-reviewer.md
---
name: design-reviewer
description: 화면 시안이 docs/design.md 규칙을 지키는지 점검한다. 시안 제작 후 반드시 사용.
tools: Read, Grep, Glob
---
너는 디자인 검증자다. 파일을 수정하지 않는다.

## 점검 항목
1. 토큰 외 색상 · 간격 값 사용 여부 (Grep으로 #으로 시작하는 색 값, px 값 탐색)
2. 로딩 / 빈 / 에러 / 경계 상태 포함 여부
3. 컴포넌트 목록 외 새 컴포넌트 사용 여부
4. 문구 규칙 (말투, 에러 문구 형식)
5. 금지 사항 (그라데이션, 이모지, 토큰 외 색상)
6. 접근성: 글자 · 배경 대비, 이미지 대체 텍스트, 버튼 레이블

## 보고 형식
| 심각도(높음/중간/낮음) | 파일:위치 | 위반 규칙 | 근거 | 제안 |
문제가 없으면 "통과"와 함께 확인한 항목 목록과 확인 방법을 쓴다.

🔍 읽는 포인트 : tools: Read, Grep, Glob — Write · Edit이 없습니다. 이 한 줄이 조건 ②를 강제 로 만듭니다. 본문의 "파일을 수정하지 않는다"는 부탁이고, tools: 줄이 장치입니다(앞에서 배운 권한 축의 두 자리, 5차시 3.4).

⚠️ 보고 형식의 "통과일 때도 확인한 항목 목록" 이 중요합니다. 이 줄이 없으면 검증자는 아무것도 확인하지 않고 "통과"라고 쓸 수 있습니다. "통과"는 주장이고, 확인한 항목 목록이 증거입니다.

접근성 — [화면 품질 기준]인데, [ 눈이 잘 안 보이거나 화면 읽기 프로그램을 쓰는 사람도 쓸 수 있는가 ]를 본다는 점에서 보기 좋은가를 보는 심미성과 구별된다. 글자와 배경의 대비, 이미지 설명 글, 버튼 이름이 대표 항목입니다.

---

4. 화면 점검 — 정적 검증과 동적 검증

4.1 정의

정적 검증 — [검증 방식]인데, [ 실행하지 않고 읽어서 판단한다 ]는 점에서 실제로 실행해 확인하는 동적 검증과 구별된다.

동적 검증 — [검증 방식]인데, [ 실제로 실행해 나타난 결과를 보고 확인한다 ]는 점에서 읽어서 판단하는 정적 검증과 구별된다.

⭐ 둘은 대체 관계가 아니라 서로 다른 것을 잡습니다. 화면 점검은 둘 다 합니다.

4.2 브라우저를 연결해 동적으로 점검

• 브라우저 자동화 도구(예: Playwright)를 외부 연결(MCP, 2차시 4.3) 로 붙이면 에이전트가 페이지를 열고 스크린샷을 찍을 수 있습니다.
• 화면 폭을 바꿔 가며 점검합니다: 휴대폰 375px, 데스크톱 1280px .
• 연결 방법과 이름은 도구 버전에 따라 다르니 공식 문서를 확인합니다.

앞으로 다시 만납니다 — 13차시에서 이 축을 코드 에 적용합니다. 코드를 읽는 리뷰(정적)와 실제로 요청을 보내 보는 동작 검증(동적)을 따로 둡니다. 17차시의 자동 테스트는 동적 검증을 매번 자동으로 하는 장치입니다.

---

5. 검증 → 수정 순환과 클래스온

5.1 순환

디자이너: 시안 제작
     ↓
검증자: 위반 목록 보고 (수정 안 함)
     ↓
사람: 어떤 지적을 반영할지 결정 (규칙 자체가 틀렸다면 규칙을 고침)
     ↓
디자이너: 수정
     ↓
검증자: 재점검 → 통과

🔍 읽는 포인트 : 가운데 "사람" 줄입니다. 검증자는 판정 재료를 내고, 반영 여부는 사람이 정합니다. 만드는 자 · 검증하는 자 · 결정하는 자가 모두 다릅니다.

⭐ 같은 위반이 계속 나오면 디자인 규칙 문서가 모호하다는 신호 입니다. 결과물보다 규칙을 고칩니다. 결과물만 고치면 다음 화면에서 같은 위반이 또 나옵니다.

5.2 검증자의 지적이 맞는지 모르겠을 때

디자이너 역할에게 "이 지적에 동의하는지, 반대한다면 근거는 무엇인지" 물어보고, 두 답을 나란히 놓고 결정합니다. 내가 디자인을 몰라도 어느 쪽 근거가 규칙 문서에 붙어 있는지 는 판단할 수 있습니다.

5.3 클래스온에 적용하면

• 6차시에서 만든 design/class-list.html을 design-reviewer에게 넘깁니다.
• 예상되는 지적: "빈 상태 없음", "남은 자리 뱃지 색이 토큰에 없는 #FF0000", "날짜 선택 버튼에 레이블 없음"
• 반영 후 재점검해서 "통과"를 받은 시안만 11차시 프론트엔드 구현의 입력으로 씁니다.

---

6. 검증자를 검증하기

검증자도 AI입니다. 검증자를 어떻게 믿을까요?

⭐ 일부러 심은 문제 는 검증 장치를 검증하는 방법이고, 코드를 몰라도 할 수 있습니다. 답을 내가 이미 아는 문제를 넣고, 검증자가 그 답을 맞히는지 봅니다.

앞으로 다시 만납니다 — 17차시에서 같은 원리로 코드를 일부러 망가뜨려 테스트가 실패하는지 봅니다. 테스트가 실패하지 않으면 그 테스트는 아무것도 검증하지 않는 것입니다.

---

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

지시

1단계 (내가 직접): design/class-list.html을 복사해 design/class-list-planted.html을 만들고,
  아래 세 가지 문제를 일부러 심는다. (AI에게 시키면 어디에 심었는지 검증자에게 맥락이 샐 수 있으니,
  가능하면 내가 직접 하거나 별도 세션에서 시킨다.)
  - 버튼 하나의 색을 #FF0000으로
  - 빈 상태 화면 삭제
  - 날짜 선택 버튼의 레이블 삭제

2단계 (design-reviewer에게):
design-reviewer 역할로 design/class-list-planted.html을 docs/design.md 기준으로 점검해줘.
보고 형식은 정의 파일의 표 그대로. 통과 항목도 확인 방법과 함께 적을 것.
가능하면 브라우저로 375px와 1280px 폭의 스크린샷도 찍어 근거로 붙여줘.
파일은 수정하지 말 것.

받을 증거

• 위반 목록 표 원문 (심각도 | 파일:위치 | 위반 규칙 | 근거 | 제안)
• 통과 항목과 각각의 확인 방법
• (가능하면) 두 폭의 스크린샷

내가 직접 확인할 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 7차시 노트만 근거로 6문제를 내줘. 코드를 모르는 사람 기준으로.
"분리의 세 조건과 각각 빠졌을 때", "tools 줄과 '수정하지 마' 문장의 차이", "정적 검증과 동적 검증", "일부러 심은 문제"는 반드시 포함해줘.
검증이 잘못 설계된 상황 하나를 주고 어느 조건이 빠졌는지 내가 맞히는 문제도 1개 넣어줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.