designpaca/packages/skill/references/critique.md

critique — 리뷰 경로와 발견 보고 형식

리뷰 경로(SKILL.md 0단계 경로 표의 0 → 5′ 감사 → 보고)와 5단계 프리플라이트의 최종 보고에서 읽는다. 이 문서는 두 경로가 공유하는 하나의 규약이다 — "무엇을 검사하는가"는 preflight.md·audit-gate.md가 정하고, 이 문서는 "발견한 것을 어떤 형식·어떤 심각도·어떤 톤으로 사용자에게 보여주는가"만 정한다. 자동 게이트의 범주별 집계 양식(audit-gate.md 리포트 양식)과는 별개로, 개별 발견 하나하나를 사람이 읽을 보고서로 옮길 때 이 문서를 따른다.

diff·PR·커밋 범위처럼 변경분을 지목받았다면 스코프 계산과 Introduced/Regression 구분은 change-review.md가 맡고, 그 산출물도 이 문서의 finding 형식·심각도·톤으로 보고한다.

이 문서를 읽는 법

상황	읽을 곳
스크린샷·코드·URL 중 무엇을 받았는지에 따라 어떻게 시작할지	§1
히어로·폼처럼 표면 종류에 따라 얼마나 깊이 볼지	§2
화면의 시각 품질을 축별로 판정할 때(첫인상·위계·타이포·리듬·카피·구분성 등)	§2-1
자기 결과물을 스크린샷으로 평가하는 순서	§2-2
finding 하나를 어떻게 적을지	§3
심각도를 어떻게 매길지, 무엇이 자동으로 심각도를 끌어올리는지	§4
템플릿 같다·브리프와 따로 논다·첫인상이 없다 같은 결함을 어떻게 판정할지	§4 Direction
수정안을 어떤 순서로 고를지	§5
같은 문제가 여러 곳에서 나왔을 때, 또는 문제가 하나도 없을 때	§6
요청 범위가 너무 넓을 때	§7
확인을 못 한 항목을 어떻게 표시할지	§8
시각 증거와 코드 증거를 섞어 단정하지 않는 법	§9
보고서를 강점으로 마무리하는 법	§10
톤	§11
리뷰 중 자동으로 고쳐도 되는 항목	§12
리뷰 보고 템플릿	§13
구현을 끝내고 사용자에게 납품을 보고한다	§13-b

---

0. 언제, 이 문서가 다루는 범위

리뷰 경로는 재구현이 목적이 아니다. 사용자가 "이 화면 어때?", "이 코드 리뷰해줘", "여기 스크린샷 봐줘"처럼 평가만 요청했을 때 0단계에서 범위·입력을 확인한 뒤 곧장 5′(감사)로 가고, 4단계(구현)를 거치지 않는다. 고쳐 달라는 요청으로 바뀌면 그때 SKILL.md 0-2 표로 경로를 다시 판정한다(대개 국소·연장).

5단계 프리플라이트에서도 이 문서를 쓴다. preflight.md §0~§5의 체크가 끝난 뒤, 실패·관찰 항목을 사용자에게 보고할 때 §3의 finding 형식과 §4의 심각도를 쓴다. preflight §5의 시각 판정은 이 문서 §2-1 루브릭으로 한다. 두 경로의 차이는 깊이와 입구뿐이다. 리뷰 경로는 구현이 없으니 입력(스크린샷·코드·URL)에서 바로 시작하고(§1), 프리플라이트는 자기 구현물을 대상으로 이미 렌더된 상태에서 시작한다.

이 문서는 designpaca가 내리는 판정의 근거인 판정 위계(하드 게이트 / 프로젝트 계약 / 스타일 휴리스틱, SKILL.md)를 그대로 쓴다. §4가 하는 일은 그 3층을 리뷰 보고서의 언어로 옮기는 것이다 [SKILL-DESIGN-REVIEW]. 단 하나, 프로젝트 계약 중 방향(브리프의 한 문장 컨셉·톤·고유성)은 Direction이라는 별도 심각도로 뗀다. 이 결함은 기술 검사가 모두 통과한 상태에서도 생기고, 다른 계약 위반과 섞어 두면 "취향 문제"로 낮춰 보고되기 쉽기 때문이다. 근거는 SKILL.md 핵심 규칙 2(모든 시각적 결정은 브리프로 소급된다)와 "어떤 클라이언트의 것과도 혼동될 수 없다"는 약속이다.

---

1. 입력별 진입

받은 입력의 종류로 시작 방법이 갈린다. 종류를 섞어 짐작하지 않는다.

입력	진입 방법
스크린샷·이미지	바로 시각 판단으로 들어간다. 렌더가 이미 있으므로 추가 확보가 필요 없다
코드 파일(컴포넌트·스타일시트)	파일을 읽되 그 파일만 보지 않는다. 관련 CSS·토큰(tokens.md 역할 이름)까지 함께 열어 finding의 위치를 path/to/file:line으로 인용할 수 있게 한다
URL만	텍스트만 가져오는 페치 도구는 마크업·CSS는 가져와도 렌더링은 보지 못한다. 브라우저 도구가 있으면 390·1440 두 폭에서 직접 캡처한다(도구 목록은 harness.md §6). 브라우저 도구가 없으면 데스크톱·모바일 스크린샷을 사용자에게 요청한다
diff·PR·커밋 범위	change-review.md로 넘긴다. 스코프 해석과 Introduced/Regression 구분은 거기서 하고, finding 자체는 이 문서 §3~§4를 그대로 쓴다

시각 판단이 걸린 리뷰인데 스크린샷도 렌더도 브라우저 도구도 없으면 추측하지 않는다. 코드만 읽고 "아마 이렇게 보일 것"이라고 단정하는 것은 §9의 증거 방향성 위반이다. 질문 수단은 SKILL.md 인터뷰 게이트의 규칙 3(기계적 판정)을 그대로 따른다 — 구조화 질문 도구가 있으면 그것으로, 없으면 평문으로 스크린샷을 요청하고 턴을 끝낸다.

diff·PR 리뷰는 멈추지 않는다. 변경분 리뷰는 코드로 확정되는 finding을 먼저 보고하고, 시각 주장은 미검증으로 남긴 뒤 보고 끝에서 "스크린샷이나 프리뷰 주소를 주시면 시각 평가를 이어서 하겠습니다"를 한 번 청한다(change-review.md). 위의 "요청하고 턴을 끝낸다"는 화면 전체의 시각 평가만 요청받았고 볼 것이 하나도 없을 때다. diff를 준 사용자가 바라는 것은 대개 "확실히 말할 수 있는 것부터"이기 때문이다.

---

2. 표면별 깊이

모든 표면을 같은 깊이로 훑지 않는다. 표면 종류를 먼저 식별하고, 그 종류가 가장 잘 무너지는 축을 더 깊이 본다.

표면	더 깊이 볼 것
마케팅 히어로	모션(motion.md)·타이포(typography.md)·구도, 반사실 제네릭 검증
폼	상태 완결성(입력 검증·오류·disabled)·접근성(accessibility.md)
대시보드·관리 화면	밀도·데이터 정합·표(숫자 정렬, 관계 보존)
내비게이션	도달성(키보드·터치)·현재 위치 신호·좁은 화면 축약

이것은 다른 축을 생략해도 된다는 뜻이 아니다. 하드 게이트는 표면 종류와 무관하게 전부 돈다(SKILL.md 규범·기능 하드 게이트 목록). 깊이 배분은 스타일 휴리스틱·프로젝트 계약 층의 시간 배분 문제다.

---

2-1. 시각 비평 루브릭

접근성·계약 검사를 모두 통과해도 화면이 평범하거나 템플릿처럼 보일 수 있다. 이 루브릭은 그런 결함을 판정할 언어다. 품질을 증명하는 점수가 아니라 납품할 수 있는 최저선이다. 높은 합계가 좋은 디자인을 보장하지 않지만, 통과선 아래는 납품하지 않는다.

언제 쓰는가. 전체·연장 경로의 5단계에서 자기 결과물에 반드시 쓴다. 리뷰 경로에서는 시각 판단이 요청에 포함될 때 쓴다. 국소 경로는 손댄 영역이 걸친 축만 채점한다.

척도. 축마다 0·1·2 중 하나를 준다.

• 0 = 실패: 그 축의 실패 신호 중 하나라도 캡처에서 관찰된다.
• 1 = 보통: 실패 신호는 없지만 강 신호를 모두 갖추지는 못했다. 자기 결과물의 시작값은 1이다.
• 2 = 강: 강 신호를 모두 관찰했고, 각각의 근거를 적었다.
• N/A: 그 축의 대상이 화면에 없다(예: 사진·그림이 하나도 없는 운영 화면의 R6). 이유를 한 줄 적는다.

표면 유형에 따라 축을 다르게 읽는다. 아래 표는 마케팅 표면(랜딩·소개·포트폴리오)을 기준으로 쓰였다. 제품 표면(로그인 뒤 화면·설정·목록·폼·관리자)에 그대로 대면 R1·R8·R10이 구조적으로 0~1점이 나오고, 점수를 맞추려고 앱 화면에 히어로와 브랜드 요소를 넣게 된다. 제품 표면은 다음 질문으로 바꿔 읽는다.

축	제품 표면에서의 질문
R1	3초 안에 "지금 어디이고, 무엇을 할 수 있고, 다음에 무엇을 누르는가"를 한 문장으로 쓸 수 있는가
R6	사진·그림이 없으면 N/A
R7	라벨·오류·빈 상태 문구가 product-copy.md §2·§4~§7을 지키는가(히어로 표제 기준은 적용하지 않는다)
R8	같은 제품의 다른 화면과 토큰·컴포넌트·용어가 일관되고, 컴포넌트 라이브러리의 기본값(기본 radius·그림자·색)이 그대로 남아 있지 않은가. 반사실 치환은 적용하지 않는다
R10	390에서 이 화면의 주 과업을 끝낼 수 있는가(제목·주 행동·이동 수단이 보인다)

제품 표면의 통과선 2는 "R1과 R2 중 적어도 하나가 2점"이다.

축	0 — 실패 신호 (하나라도 있으면)	2 — 강 신호 (모두 있어야)
R1 첫인상 (3초)	첫 화면 캡처만 3초 보고 "누구이고, 무엇이며, 왜 좋은가"를 한 문장으로 쓸 수 없다 / 첫 화면의 주된 문장이 면책 문구나 메타 서술("이 페이지는 ~를 보여 줍니다")이다 / 첫 화면에 브랜드와 제목 중 하나가 없다	3초 문장이 2단계 한 문장 컨셉의 핵심 명사·동사와 맞는다 / 1440과 390 첫 화면 모두에서 성립한다
R2 위계·읽기 순서	회색조·흐림 캡처에서 첫 시선이 목표 행동이나 핵심 주장이 아니다 / 같은 시각 무게의 요소 셋 이상이 첫 시선을 다툰다	회색조·흐림 캡처의 시선 순서 1→2→3이 design.md에 적은 의도와 같다 / 주요 위계 단계가 크기·굵기·색·여백 중 두 가지 이상의 차이로 구분된다
R3 묶음·정렬	한 화면의 주요 왼쪽 시작선이 넷 이상이고 그 차이를 의미로 설명할 수 없다 / 관련 없는 요소끼리가 관련 요소끼리보다 가깝다(근접 역전)	주요 시작선이 셋 이하이고 각 선이 역할(제목·본문·수치 등)을 가진다 / 묶음 사이 간격이 묶음 안 간격보다 분명히 크다. 시작선 x 좌표를 실제로 쟀다
R4 타이포 품질	합성 이탤릭·합성 볼드가 렌더된다 / 음수 자간으로 한글 글자가 닿는다 / 표제 마지막 줄에 한 어절만 남는다 / 한글에 고정폭 글꼴을 써서 글자 사이가 벌어진다 / 본문 측정폭이 typography.md 정본 범위를 벗어난다	제목과 본문이 크기 외에 굵기·색·서체 중 하나 이상으로도 대비된다 / 본문 문단의 회색 농도가 고르다 / 왼쪽 실패 신호가 1440·390 어디에도 없다. 데스크톱 제목 대 본문 크기 비가 2.5배 이상이면 시작 신호로 보되 통과선은 아니다
R5 여백 리듬·긴장	섹션 간격이 전부 같아 정보 전환이 보이지 않거나, 간격 변주가 정보 관계와 반대다 / 요소가 헤더·패널 테두리에 여백 0으로 붙는다 / 스케일·명암·여백 어느 축에도 의도된 극단이 없다(전부 중간값)	간격의 변주가 정보 전환과 일치한다 / 스케일·명암·여백 중 하나 이상에서 design.md에 적은 의도된 극단(긴장)이 화면에서 보인다
R6 이미지	이미지가 사업·브리프와 무관하다 / 크롭에서 주피사체가 사라진다 / 노출·색 보정이 어긋나 같은 페이지 사진이 서로 다른 세계처럼 보인다 / 같은 사진이 한 페이지에서 반복된다 / 컨셉이 "사진이 주연"인데 390 첫 화면에 사진이 없다	슬롯마다 역할이 적혀 있다 / 데스크톱·모바일 크롭 모두에서 주피사체가 안전 영역에 남는다 / 조도·색이 하나의 세계로 읽힌다(art-direction.md §4)
R7 카피 목소리	헤드라인이나 히어로 본문이 경쟁사 이름으로 바꿔도 그대로 성립한다 / 상투어(침묵·"말이 없다" 은유, "시간이 흘러도 변치 않는", 메타 서술)가 있다 / 표제·히어로 문단·섹션 제목에 product-copy.md §13-c 지문이 있다 — 번역체(무생물 주어+사람 동사, ~를 통해·당신의·여정·재정의), 무엇을 파는지 안 나오는 명사 종결 수수께끼 표제, 선언·잠언형 과장(~는 ~보다 먼저 기록됩니다), ~가 아니라 ~다 대구 둘 이상, 감성 어휘(결·온도·숨·머무는·스미는·깃든) 반복, 내용 없는 영문 장식 라벨 / 진실 라벨·면책 문구가 히어로의 목소리를 대신한다 / 한 화면에서 해요체와 합니다체가 섞인다	소리 내 읽으면 한 화자가 말하고, 그 업종 대표가 손님에게 직접 할 말로 들린다 / 헤드라인에 이 브리프에만 있는 구체 재료(제품·장소·수치·행동)가 들어 있고, 경쟁사 치환에서 문장이 깨진다 / 은유는 페이지에 한 곳 이하다
R8 구분성 (반사실·수렴)	art-direction.md §3-2 반사실 점검에서 실패한다 / 같은 저장소·세션의 다른 산출물과 구성 수렴 5축(히어로) 중 셋 이상, 또는 페이지 수렴 6축 중 넷 이상이 같다(art-direction §3-2 B-1·B-2)	다른 클라이언트에게 그대로 옮기면 어색해지는 요소가 첫 화면에 둘 이상 있고 그 이름을 적었다 / 수렴 5축 중 같은 것이 하나 이하다
R9 디테일 마감	아이콘과 텍스트의 광학 정렬이 어긋난다 / 캡션·라벨이 테두리에 여백 0으로 붙는다 / 숫자 열이 정렬되지 않는다 / 반복 컴포넌트끼리 radius·간격이 다르다 / 자리표시 그래픽이 실물처럼 남아 있다	1440·390 캡처를 200%로 확대해 훑어도 왼쪽 신호가 하나도 없다
R10 모바일 완성도	390 첫 화면에 브랜드·컨셉 증거(대표 사진·데모)·제목·다음 행동 네 요소 중 둘 이하만 보인다 / 주요 섹션으로 가는 수단(내비 또는 메뉴 버튼)이 보이지 않는다 / h1이 첫 화면 밖에서 시작한다	네 요소가 모두 보이거나, 셋이 보이고 빠진 하나의 이유를 적었다 / 이동 수단이 보인다 / 데스크톱을 줄인 화면이 아니라 순서·크롭이 좁은 화면에 맞게 다시 편집됐다

통과선. 셋을 모두 만족해야 한다.

1. 0점 축이 없다(N/A 제외).
2. R1과 R8 중 적어도 하나가 2점이다.
3. 합계가 적용한 축 만점의 70% 이상이다(10축이면 14점 이상). 모든 축이 1점인 화면은 실패 신호가 없을 뿐 고유한 것도 없는 화면이다.

통과선 미달은 §4의 심각도로 옮긴다. R1·R2·R7·R8의 0점과 통과선 2·3 미달은 Direction이다. 그 밖의 축(R3·R4·R5·R6·R9·R10)의 0점은 Important다. 1점 축은 finding으로 올리지 않아도 되지만, 가장 큰 효과를 낼 변경(§10)의 후보로 본다.

자기 채점 편향 대응

AI가 자기 결과물을 채점하면 후하게 매기는 경향이 있다. 의도를 알고 보면 의도한 것이 보이기 때문이다. 아래를 지킨다.

1. 근거 없는 점수는 쓰지 않는다. 점수마다 캡처 파일·화면 영역·관찰 사실(측정값 또는 화면 문장 인용)을 붙인다. 근거를 적을 수 없는 축은 점수 대신 미검증으로 둔다. "좋아 보인다", "균형 잡혀 있다"는 근거가 아니다.
2. 가장 약한 축부터 쓴다. 보고와 design.md 기록 모두 점수 오름차순으로 적는다. 강점은 §10 마무리에서만 쓴다.
3. 의도를 가리고 먼저 본다. R1·R2는 design.md와 코드를 열기 전에 캡처만 보고 채점한다. 의도와의 대조는 그다음이다.
4. 2점에는 반례를 찾는다. 2점을 준 축마다 "이 점수를 깎을 수 있는 관찰"을 하나 찾아 적는다. 찾지 못했으면 "찾지 못함"이라고 쓴다.
5. 비교 기준을 옆에 둔다. 1단계 레퍼런스(R1~R3) 캡처 하나를 같은 배율로 나란히 놓고 같은 축을 채점한다. 레퍼런스보다 높게 준 축에는 근거를 한 줄 더 적는다.
6. 독립 검토가 가능하면 쓴다. 다른 맥락의 검토자(서브에이전트 등, harness.md §5)를 쓸 수 있으면 의도 문서 없이 캡처와 이 표만 주고 채점시킨다. 두 점수가 다른 축은 낮은 쪽을 채택한다.
7. 승인은 채점이 아니다. 사용자가 방향을 승인했어도 루브릭은 따로 돈다(audit-gate-rules.md G22).

---

2-2. 스크린샷 기반 자기 평가 절차

루브릭은 실제 렌더 캡처로만 채점한다. 코드를 읽고 "이렇게 보일 것"이라고 채점하지 않는다(§9).

1. 캡처한다. 1440×900 첫 화면, 390×844 첫 화면, 두 폭의 전체 페이지를 찍는다. 지원하는 테마가 둘이면 두 테마를 각각 찍고 루브릭은 약한 쪽 점수를 쓴다. 화면이 여럿이면 대표 화면과 과업이 다른 화면을 채점하고, 같은 틀을 쓰는 화면은 캡처만 열어 본다(layout.md §4-m) — 무엇을 대표로 삼았는지 보고에 적는다. 폰트·이미지가 준비되고 등장 모션이 끝난 뒤에 찍는다(audit-gate.md 렌더 측정 계약). 결과·오류·모달 같은 핵심 상태가 있으면 그 상태도 찍는다.
2. 회색조·흐림 사본을 만든다. 두 첫 화면 캡처를 회색조 + 약한 흐림(예: filter: grayscale(1) blur(6px)를 주입해 다시 찍거나 이미지를 처리)으로 한 장씩 더 만든다.
3. 파일을 실제로 연다. 이미지 보기 수단으로 캡처를 연다(도구는 harness.md §6). 열 수 없으면 루브릭 전체를 미검증으로 두고 §1처럼 사용자에게 캡처를 요청한다. 저장했다는 사실은 본 것이 아니다.
4. 3초 문장을 쓴다. 첫 화면 원본만 보고 "누구이고, 무엇이며, 왜 좋은가"를 한 문장으로 쓴다. 그다음 2단계 한 문장 컨셉과 대조한다(R1).
5. 시선 순서를 쓴다. 회색조·흐림 사본에서 먼저 보이는 것 1→2→3을 적고, design.md의 의도와 대조한다(R2).
6. 축별로 채점한다. 이제 design.md를 열고 나머지 축을 채점한다. 가장 약한 축부터 근거와 함께 적는다.
7. 반사실·수렴 점검을 돈다. art-direction.md §3-2 절차를 그대로 따른다(R8).
8. 기록한다. design.md의 시각 평가 표에 축 | 점수 | 근거(파일·영역·관찰) | 다음 행동을 남긴다. 통과선 미달은 §4 심각도로 finding을 만든다.

---

3. finding 형식 — What·Why·Fix

발견 하나마다 세 요소를 강제한다. 셋 중 하나라도 없으면 finding이 아니라 인상이다.

• 무엇(What): 요소를 인용하거나 path/to/file:line을 인용한다. 스크린샷만 있으면 화면 영역과 컴포넌트 이름으로 특정한다.
• 왜(Why): 한 줄로 위계 3층 중 어디에 해당하는지 밝히고, 규범·근거가 있으면 출처 ID를 붙인다. "이상해 보여서"는 이유가 아니다.
• 고침(Fix): 정확한 값이나 선택자를 준다. "늘려라", "더 낫게" 같은 방향만 있는 지시는 finding이 아니다 [SKILL-DESIGN-REVIEW]. 단, 구도·위계·방향 결함(Direction, 루브릭 R2·R5·R8 등)은 한 값으로 고쳐지지 않는다. 이때는 구조가 다른 대안 2개와 채택 기준(무엇을 보면 어느 쪽을 고르는가)을 Fix로 쓴다.

표로 묶어 보고한다. 컬럼은 심각도·위치·무엇·왜·고침이다.

| 심각도 | 위치 | 무엇 | 왜 | 고침 |
|---|---|---|---|---|
| Blocking | `Button.tsx:42` | 아이콘 전용 버튼에 접근성 이름 없음 | 하드 게이트 — 스크린리더가 컨트롤 목적을 못 읽음 [WCAG-NRV] | `aria-label="검색"` 추가 |
| Important | `Card.module.css:18` | 같은 카드 역할인데 radius가 4px·8px·12px로 파일마다 다름 | 프로젝트 계약 — `design.md`가 역할 토큰 체계(`--radius-surface` 등, [tokens.md](tokens.md) §3-b)로 확정 | 카드는 `--radius-surface`(8px)로 통일 |
| Polish | 히어로 이미지 좌측 | 섹션 간 여백이 위 48px(`--space-12`)·아래 64px(`--space-16`)로 비대칭 | 스타일 휴리스틱 — 리듬 관찰 후보, 브리프 근거가 없으면 대칭이 시작값 [SKILL-BETTER-LAYOUT] | 상하 모두 `--space-16`(64px)으로 통일 검토 |

UI 코드 자체의 수정 전/후를 비교하는 리뷰(모션 커브 교체, 트랜지션 재조준 등)에는 위 표 대신 Before | After | Why 3열 표를 쓴다. 목록형으로 "Before:"와 "After:"를 줄바꿈해 나열하지 않는다 — 나란히 비교해야 차이가 보인다 [SKILL-EMIL-DESIGN-ENG].

| Before | After | Why |
|---|---|---|
| `transition: transform 300ms ease-in` | `transition: transform 300ms var(--ease-out)` | 진입 모션에 `ease-in`을 쓰면 시작이 굼떠 보인다. `--ease-in`은 퇴장 전용이다 |

두 표는 병행 가능하다 — 구조 finding은 첫 표, 코드 수정 대안은 두 번째 표로 보조한다.

---

4. 심각도

판정 위계를 4단계 언어로 옮긴다. 하드 게이트·프로젝트 계약·스타일 휴리스틱에 이름을 붙이고, 프로젝트 계약 중 방향 계약만 Direction으로 뗀다(§0).

심각도	판정 위계	기준
Blocking	하드 게이트 위반	WCAG·키보드·포커스·대비·감소 모션·진실성처럼 규범·기능에 근거한 항목의 실패. 출시를 막는다
Direction	프로젝트 계약 중 방향 계약 위반	화면이 브리프의 한 문장 컨셉·톤·고유성을 증명하지 못한다. 아래 "Direction 판정 기준" 중 하나 이상이 근거와 함께 관찰될 때만 매긴다. 납품을 막는다 — 접근성 검사와 별개의 축이라, 하드 게이트를 모두 충족해도 Direction이 열려 있으면 완료가 아니다
Important	프로젝트 계약 위반 또는 과업 방해	브리프·design.md·토큰·성능 예산과 어긋나거나, 계약 위반이 아니어도 사용자가 과업을 완수하지 못하게 막음. 루브릭(§2-1)에서 방향 축이 아닌 축의 0점도 여기다
Polish	스타일 휴리스틱 관찰(관찰 후보)	색·radius·정렬·리듬 같은 취향 후보의 다듬기. 통과·보류·채택은 맥락과 렌더로 판단한다

보고 순서는 Blocking → Direction → Important → Polish다. Blocking과 Direction은 서로 대체하지 않는다. 하나를 해결했다고 다른 하나가 풀리지 않는다.

전부 나열하지 않는다. 중요한 순으로 소수만 앞세운다. 몇 개까지인지 숫자로 정하지 않는다 — §7의 스코프 규율을 따른다.

Direction 판정 기준 — 관찰할 수 있는 것만

Direction은 취향 판정이 아니다. 아래 중 하나 이상을 캡처·인용·측정으로 보여줄 수 있을 때만 매긴다. "내 취향과 다르다", "더 세련될 수 있다"는 Direction이 아니라 Polish 후보다.

ID	결함	관찰 기준
D1	반사실 실패 — 다른 클라이언트에게도 맞는다	art-direction.md §3-2 반사실 점검의 실패 조건에 걸린다
D2	수렴 — 이전 결과물·템플릿과 혼동된다	같은 저장소·세션의 다른 산출물과 나란히 놓았을 때 구성 수렴 5축(구도, 표제 서체, eyebrow 문법, CTA 형태, 캡션 문법) 중 셋 이상, 또는 페이지 수렴 6축(섹션 흐름, 히어로 글 묶음, 내비, 푸터, 이미지 비율·처리, 모션 문법) 중 넷 이상이 같다(art-direction §3-2)
D3	첫인상 실패	루브릭 R1이 0점이다
D4	첫 시선 배반	루브릭 R2가 0점이다. 회색조·흐림 캡처에서 첫 시선이 목표 행동이나 핵심 주장이 아니다
D5	컨셉 부재	2단계 한 문장 컨셉의 핵심 명사가 1440 또는 390 첫 화면에서 시각적으로 증명되지 않는다(예: 컨셉이 "사진이 주연"인데 390 첫 화면에 사진이 없다)
D6	톤 불일치	브리프의 톤 형용사마다 화면 증거를 하나씩 짝지었을 때 반대 증거가 있는 형용사가 하나 이상이다(예: "따뜻한"인데 냉색 단색과 대문자 고정폭 eyebrow). 또는 루브릭 R7이 0점이다(번역체·과장 카피로 인한 0점 포함 — What에 해당 문장을 그대로 인용하고, Fix의 대안마다 product-copy.md §13-c 기준으로 고친 문장을 넣는다)
D7	평균 수렴	루브릭 통과선 2(R1·R8 중 2점 하나 이상) 또는 3(합계 70%)에 미달한다

Direction finding의 What·Why·Fix. What에는 D 번호와 캡처 영역을 쓴다. Why에는 위배된 브리프 문장(한 문장 컨셉·톤 형용사·목표 행동)을 인용한다. Fix는 §3의 예외대로 구조가 다른 대안 2개와 채택 기준을 쓴다.

해제 조건. Direction은 둘 중 하나로만 닫힌다.

1. 2단계(방향)로 돌아가 다시 만든 뒤, 같은 캡처 조건에서 같은 기준으로 재평가해 사라졌다. 재작업 시도는 audit-gate.md "루프와 재작업 상한"의 3회 상한을 따른다.
2. 사용자가 캡처와 finding을 보고 그 방향을 명시적으로 수용했다. 수용 문장과 날짜를 design.md에 남긴다. 취향·방향의 최종 승인권자는 사용자다. 사용자의 불만이 반복되는 경우의 절차는 feedback-loop.md를 따른다.

연장·국소 경로의 Direction. 이 경로에서 방향은 design.md(또는 확인받은 현행 계약 요약)가 이미 정했다. Direction은 "산출물이 그 계약과 어긋난다"일 때만 매기고, 고칠 곳은 2단계가 아니라 3·4단계다. 계약 자체가 이 화면에 맞지 않는다고 판단되면 고치지 말고 사용자에게 승격을 확인받는다(SKILL.md 2단계 통과 조건).

에이전트가 스스로 "의도한 것"이라며 Direction을 닫지 않는다. 의도였다면 그 의도를 브리프 문장과 함께 사용자에게 보이고 2번을 거친다.

에스컬레이션 트리거 — 확인되면 표면이 사소해도 낮추지 않는다

아래 항목은 확인되는 즉시 표에 적힌 위계로 매긴다(대부분 Blocking). "화면 전체는 괜찮으니 평균 내면 Important"처럼 다른 항목과 평균을 내어 낮추지 않는다 — 트리거는 심각도만 정할 뿐 새 하드 게이트를 만들지는 않는다. 실제 하드 게이트 정의는 SKILL.md·accessibility.md가 갖고 있고, 이 표는 그 정의를 리뷰 시점에 놓치지 않기 위한 점검표다 [SKILL-BETTER-INTERFACE].

트리거	위계 근거	이미 있는 designpaca 규칙
인터랙티브 컨트롤에 접근성 이름이 없음	하드 게이트 — 스크린리더가 목적을 읽지 못함 [WCAG-NRV]	accessibility.md의 접근 가능한 이름 규칙
키보드로 도달은 되지만 포커스가 다른 요소에 완전히 가려짐	하드 게이트 — 포커스가 있어도 안 보이면 무의미 [WCAG-FOCUS-OBSCURED]	preflight.md §1 포커스 표시 항목의 보강 사례
포커스 인디케이터가 인접 색과 구별되지 않음(대비 3:1 미만 등)	하드 게이트 — 상태를 식별하는 시각 정보라 비텍스트 대비 기준을 받는다 [WCAG-NONTEXT]. 인디케이터의 면적(2px 둘레 기준)까지 요구하는 것은 AAA 이므로 프로젝트가 표방할 때만 계약으로 본다 [WCAG-FOCUS-APPEAR]	preflight.md §1 포커스 표시
포인터로만 조작되는 컨트롤(키보드 경로 없음)	하드 게이트	SKILL.md 규범·기능 하드 게이트 1번
prefers-reduced-motion을 무시하고 위치 이동·시차가 그대로 재생	하드 게이트	motion.md, SKILL.md 하드 게이트 3번
320px 폭 또는 200% 확대에서 콘텐츠·컨트롤이 잘리거나 도달 불가	하드 게이트	preflight.md §3 반응형
텍스트·UI 대비가 적용 WCAG 기준 미달	하드 게이트	preflight.md §1 대비
색만으로 상태·의미를 전달하고 다른 단서(아이콘·라벨·패턴)가 없음	하드 게이트 — 색맹·흑백 인쇄·저채도 화면에서 정보 유실	color.md
파괴적 행동에 확인·실행취소·구분된 처리가 없음	하드 게이트	preflight.md §4-1
잘린(ellipsis 처리된) 콘텐츠에 전체 값으로 가는 경로가 없음	하드 게이트 — 정보 접근 수단 자체가 없음	SKILL.md 규범·기능 하드 게이트 4번, typography.md
스크롤 경계나 접힘 뒤에 시각적 단서 없이만 도달하는 컨트롤	관찰 후보(다듬기) — 다만 그 컨트롤이 필수 과업의 유일한 경로면 과업 방해로 중요(Important)	layout.md 점진적 공개 절과 같은 층
입력 오류에서 고칠 방법이 알려져 있는데 제시하지 않음	하드 게이트(WCAG 3.3.3)	[WCAG-22]
그 밖의 오류 문구에 다음 행동이 없음	프로젝트 계약	product-copy.md §6
시맨틱 색 토큰을 의미와 반대로 사용(예: 위험색을 기본 CTA에)	프로젝트 계약 위반 — 토큰의 의미 계약을 깼다. 동시에 그 오용이 사용자에게 잘못된 위험 신호로 읽히면 하드 게이트로 올린다	color.md, tokens.md
상태 변화가 모션으로만 전달되고, 모션이 꺼지거나 생략돼도 남는 색·아이콘·라벨이 없음	하드 게이트 — 감소 모션 환경에서 상태 자체가 사라짐	motion.md

이 표에 없는 항목이라도 같은 논리(정보·조작 수단 자체의 유무)가 성립하면 같은 방식으로 Blocking을 매기고 근거를 적는다. 표는 닫힌 목록이 아니다.

---

5. 저비용 수정 사다리

Fix를 쓸 때 다섯 단계를 순서대로 검토한다. 더 비싼 단계로 고쳤는데 더 싼 단계가 가능했다면, 그 수정 자체가 별개의 finding이다 [SKILL-BETTER-INTERFACE].

1. 삭제 — 불필요한 구분선, 과도한 인터랙션 위 애니메이션, 아무도 쓰지 않는 토큰·ARIA 속성은 지우는 것이 가장 싼 수정이다
2. 플랫폼 활용 — 커스텀 컴포넌트 대신 네이티브 엘리먼트·포커스 링·컨트롤로 대체할 수 있는가
3. 재사용 — 새 값을 만들기 전에 기존 토큰·간격·모션 커브가 이미 있는가
4. 값 교정 — 소유 문서(색은 color.md, 그림자는 elevation.md 등)가 주는 정확한 값으로 바꾼다
5. 추가 — 위 넷으로 안 될 때만 새 토큰·wrapper·미디어쿼리·ARIA 속성을 만든다

---

6. 병합과 패딩 금지

같은 근본 원인에서 나온 반복 위반은 하나의 finding으로 묶고, 확인된 모든 위치를 그 행에 나열한다. 발생마다 행을 나누지 않는다 [SKILL-BETTER-INTERFACE].

항목 수를 채우려고 같은 문제를 쪼개 보고하지 않는다. 리뷰가 짧아도 되고, "발견 없음"도 유효한 결과다. 억지로 Polish를 만들어내는 것은 신뢰를 깎는다.

---

7. 스코프 규율

요청 범위가 신뢰성 있게 점검하기에 너무 넓으면, 요청이 중심으로 삼는 한 흐름(사용자가 실제로 거치는 진입 경로 하나)으로 좁히고 그 경계를 보고 서두에 명시한다. 어디까지 봤고 무엇을 뺐는지 말하지 않고 넘어가지 않는다.

점검하지 않은 표면을 점검한 것처럼 암시하지 않는다. "전체적으로 괜찮다"는 문장은 실제로 전체를 본 뒤에만 쓴다. 숫자 상한(finding 몇 개까지, 화면 몇 개까지)은 두지 않는다 — 상한은 근거 없는 수치이고, 스코프를 좁히는 판단이 상한보다 먼저다.

---

8. 미검증·미점검

실행할 수 없는 체크는 finding이 아니다. 두 상태를 구분해 따로 나열한다.

• 미검증: 시도했지만 도구·권한·환경 제약으로 확인하지 못했다(예: 실기기가 없어 제스처 QA 불가). 통과로 추정하지 않는다.
• 미점검: §7에서 스코프를 좁히며 의도적으로 뺀 표면이다. "확인 안 함"이라고 명시한다.

둘 다 finding 개수·심각도 집계에 넣지 않는다. 통과한 체크와 나란히, 별도 목록으로 둔다.

미검증은 충족이 아니다. 하드 게이트가 미검증이면 그 항목을 충족으로 세지 않고, 보고 첫 줄을 하드 게이트: 충족 N / 미검증 M / 차단 K 형식으로 쓴다. M이 0이 아니면 "모두 통과", "완료" 같은 말을 쓰지 않는다. 집계 규칙과 재작업 상한(같은 결함 3회)은 audit-gate.md를 따른다. 캡처를 열 수 없어 루브릭(§2-1)을 채점하지 못한 경우도 미검증이다.

---

9. 증거 방향성

런타임 동작이 결과를 좌우할 때는 방향을 섞지 않는다.

• 시각(스크린샷)만으로 코드-레벨 finding을 단정하지 않는다. "이 여백은 padding이 아니라 margin일 것"처럼 소스를 안 보고 구현 방식을 추측하지 않는다.
• 소스코드만으로 시각적 finding을 단정하지 않는다. CSS가 의도한 값이어도 폰트 로딩·동적 콘텐츠·다른 규칙과의 캐스케이드로 실제 렌더가 다를 수 있다.

한쪽 증거만 있으면 그 증거가 답할 수 있는 범위까지만 쓰고, 나머지는 §8의 미검증으로 남긴다.

---

10. 마무리 — 강점과 최고 레버리지 변경

지적으로만 끝내지 않는다. 보고서 끝에 Strengths 2~4개를 적는다 — 잘 되고 있는 부분 위에 비판이 쌓이게 하는 문화적 장치다 [SKILL-DESIGN-REVIEW]. 지어낸 칭찬이 아니라 실제로 확인한 것만 적는다.

유용하면 가장 큰 효과를 낼 변경 하나를 선택으로 덧붙인다. 여러 Important 중 하나를 고치면 나머지가 함께 해결되거나, 사용자 인지에 가장 크게 걸리는 항목이 후보다.

---

11. 톤

모호한 지적을 하지 않는다. "더 나아 보이게", "좀 깔끔하게" 같은 방향만 있는 문장은 쓰지 않는다. 항상 §3의 정확한 Fix와 짝짓는다.

동료의 작업을 리뷰하듯 직접적이고 정중하게 쓴다. 문제는 정확하고 모호하지 않게 말하되, 사람이 아니라 결과물을 평가한다.

---

12. 리뷰 중 자동 적용 범위

자동 적용도 국소 경로다 — 수정을 시작하는 순간 리뷰(읽기 전용) 경로를 벗어난다. 손댄 섹션 수로 경로를 다시 판정하고, 5단계 하드 게이트와 6단계 한 줄 추기를 생략하지 않는다(change-review.md §1-1).

사용자가 리뷰와 함께 수정 적용을 요청했을 때(--apply류 의도), 안전하게 자동 적용 가능한 범주와 확인이 필요한 범주를 구분한다.

자동 적용 가능	확인 필요
대비 토큰 교체(이미 있는 역할 토큰으로)	주관적 판단이 들어가는 변경(색감, 레이아웃 재배치)
간격 토큰 교체	구조 변경(컴포넌트 분리·합치기, 정보 구조 재배열)
포커스 스타일 보강	카피 톤·메시지 변경
prefers-reduced-motion 대응 추가	새 컴포넌트·새 패턴 도입
시맨틱 태그로 교체(div → button 등)	—
alt 텍스트 추가	—

자동 적용 가능 범주도 수정 후 대비·값을 재검증한다. 고쳤다고 선언만 하고 재측정을 생략하지 않는다 [SKILL-DESIGN-REVIEW].

---

13. 리뷰 보고 템플릿

한국어 예다. 다른 언어로 보고할 때는 같은 구조로 옮긴다(용어의 영어 대응은 audit-gate).

<검증 줄 — 형식의 정본은 audit-gate.md "완료 보고 첫 줄 — 정본">

## 리뷰 범위

- 대상: <URL/파일/스크린샷>
- 본 흐름: <한 흐름으로 좁혔다면 그 경로>
- 뺀 것: <미점검으로 둔 표면과 이유>
- 증거: <스크린샷/실제 렌더/소스코드, 뷰포트·엔진명>

## 발견

| 심각도 | 위치 | 무엇 | 왜 | 고침 |
|---|---|---|---|---|
| ... | ... | ... | ... | ... |

발견 없음이면: "이 흐름에서 Blocking·Direction·Important 발견 없음. Polish 관찰 후보는 <있으면 나열, 없으면 없음>."

## 시각 루브릭 (§2-1, 약한 축부터)

| 축 | 점수 | 근거(캡처·영역·관찰) | 다음 행동 |
|---|---|---|---|
| ... | 0/1/2/N/A | ... | ... |

3초 문장: <첫 화면만 보고 쓴 한 문장> · 시선 순서: <1→2→3>
반사실·수렴: <art-direction §3-2 결과>

## 미검증 · 미점검

- 미검증: <시도했으나 확인 못 한 항목과 이유>
- 미점검: <스코프에서 뺀 표면>

## 기존 결함 (이번 변경·요청 범위 밖, 집계 제외)

- <위치 — 기준 — 제안. 없으면 절을 뺀다>

## 잘된 점

- <강점 1>
- <강점 2>

## 가장 큰 효과를 낼 변경 (선택)

<하나, 이유 한 줄>

이 템플릿은 뼈대다. 리뷰 규모가 작으면 섹션을 생략할 수 있지만(예: 발견이 없으면 "미검증" 섹션도 빈 채로 명시), 거짓으로 채우지는 않는다. 시각 판단이 요청에 없는 코드 리뷰라면 시각 루브릭 섹션은 "범위 밖"이라고 적고 뺀다. 렌더가 없는 리뷰에서는 시각 루브릭 절을 "미검증 — 렌더 없음" 한 줄로 쓰고 표를 비운 채 두지 않는다.

13-b. 납품 보고 (구현 경로)

구현을 끝낸 보고는 감사 집계가 아니라 무엇을 만들었고 어떻게 보는지로 시작한다. 사용자가 긴 작업 끝에 처음 읽는 줄이 내부 집계이면 정작 필요한 정보(여는 법, 정해야 할 것)를 찾지 못한다.

<무엇을 만들었는지 한 문장. 고른 방향 카드 이름을 쓴다>
<방향을 위임받아 직접 골랐으면: 고른 카드 이름 — 브리프·레퍼런스에서 온 이유 한 문장. "design.md 참고"로 대신하지 않는다>

**보는 법**: <명령 한 줄과 주소, 또는 파일 경로> · 캡처: <1440·390 파일 경로 또는 첨부>
**정해 주셔야 할 것**: <placeholder·가정 목록(이름 · 어디에 보이는지). 없으면 "없음">
**검증**: <검증 줄 — 정본은 audit-gate.md "완료 보고 첫 줄 — 정본">
- 미검증 M건: <항목 — 무엇이 있으면 확인되는지>
**하지 않은 것**: <의도적으로 뺀 것과 이유 한 줄씩>
**기존 결함**: <범위 밖에서 본 것. 없으면 생략>

• 검증 줄의 형식과 규칙은 audit-gate 그대로다. 위치만 첫 줄에서 넷째 줄로 옮긴다.
• 보는 법: 정적이면 파일 경로나 정적 서버 명령 한 줄, 프레임워크면 프로젝트의 dev 명령이다. 서버를 띄워 둔 채 끝내면 그렇다고 적는다.
• 국소 경로는 첫 문장, 보는 법, 검증 줄(하드 게이트만), design.md 한 줄 추기까지만 쓴다. 루브릭은 손댄 축에 0점이 있을 때만 적는다 — hover 하나를 고친 보고에 열 축 표를 붙이면 읽히지 않는다.
• 미검증이 사람·실기기가 있어야만 확인되는 항목뿐이면 "에이전트가 확인할 수 있는 범위는 전부 충족, 사람 확인 필요 M건"이라고 쓴다. 도구가 있었는데 돌리지 않은 미검증과 구분하기 위해서다.