디자인 감각을 검사 가능한 수치로

1. 한 장 요약

LLM에게 디자인을 시키면 실패하는 지점이 정해져 있습니다. 모바일에서 안 보이는 작은 글씨, 텍스트만 빽빽한 세로 페이지, 지어낸 후기와 법정문구, 아무 데나 박히는 그림자. 이 스킬은 그 실패를 하나씩 측정 가능한 조건으로 바꿔 완료 직전에 전수 대조하게 만듭니다.

반려가 오면 피드백을 결정 슬롯(색 / 조형·배치 / 타이포 / 카피 / 사진)으로 분류해 해당 단계로만 되돌아갑니다. 입력 자체가 바뀌었으면 인터뷰까지 올라갑니다. "다시 만들어줘"를 통짜로 받지 않고 어디를 고칠지부터 정하는 구조입니다.

2. 라우터로 설계된 문서 13개

스킬을 열면 가장 먼저 눈에 띄는 문장이 이겁니다.

1,867줄을 통째로 컨텍스트에 밀어 넣으면 정작 작업할 여력이 없습니다. 그래서 SKILL.md(113줄)는 상황 → 열 문서 매핑 표와 절대 규칙만 들고 있고, 나머지는 필요할 때 열립니다. 스킬을 여러 개 쓰는 사람이라면 이 구조 자체가 배울 점입니다.

각 문서 서두에 "이 문서는 딱 하나의 관심사만 다룬다"는 선언이 붙어 있고, 다른 관심사는 링크로 넘깁니다. 소프트웨어의 단일 책임 원칙을 프롬프트 문서에 그대로 적용한 형태입니다.

3. 패턴과 값을 갈라놓은 2층 구조

이 스킬의 재사용성이 나오는 자리입니다.

예를 들어 색은 3층 역할 구조로만 서술됩니다 — ① 중립축(저채도, 본문·바탕 글자), ② 액센트(고채도 + 브랜드 색조, 제목·강조·CTA), ③ 의미색(색조가 의미를 인코딩, 긍정·경고). 브랜드가 바뀌면 ①은 미세 조정, ②는 교체, ③은 색조 관용 유지.

대비 규칙도 값이 아니라 조건으로 적혀 있습니다. 밝은 배경에서는 명도차가 잘 안 생기니 채도 대비로 위계를 만들고, 사진·어두운 배경에서는 색 대비가 안 통하니 고명도(크림/화이트)로 명도 대비를 쓴다. 어느 브랜드에 갖다 놔도 성립하는 서술입니다.

값이 안 정해진 슬롯은 "미정"으로 표기하고 그 부분의 제작을 보류합니다. 전체를 멈추지 않고 그 슬롯만 멈추는 게 핵심입니다 — "부분 진행은 되지만, 부분 추측은 안 된다."

4. 하드 게이트 13개 — 이 스킬의 진짜 심장

문서 어딘가에 흩어져 있던 수치를 한 표로 모아놓고 정본(SSOT)이라 선언합니다. 불일치가 생기면 이 표가 이깁니다. 그리고 이건 참고값이 아니라 매 섹션 자가검증에서 get_metadata+스크린샷으로 전수 대조하는 통과 조건입니다.

눈여겨볼 건 기준을 절대 px이 아니라 비율·면적으로 잡았다는 점입니다. "본문 39px"이 아니라 "캔버스폭의 4.5%"라서 아트보드 폭이 바뀌어도 규칙이 그대로 성립합니다. 히어로 텍스트 점유를 세로가 아니라 면적으로 잡은 이유도 문서에 적혀 있습니다 — 폭 좁은 텍스트가 세로로만 길면 세로 기준으로는 20%를 채워도 화면은 휑하기 때문입니다.

5. 인터뷰는 취향조사가 아니다

인터뷰를 "고객 취향 물어보기"가 아니라 함수의 인자 채우기로 정의한 게 이 문서의 성취입니다. 그래서 질문 목록이 "무엇을 묻나 → 그 답이 무슨 규칙을 정하나" 두 칸으로 되어 있습니다. 제품 대표색을 모르면 제목·강조·번호·CTA에 무슨 색을 쓸지가 정의되지 않기 때문에 묻는 겁니다.

• 추측한 값은 결함으로 취급. 확인 안 된 항목은 "미확인"으로 명시하고 진행 보류.
• 기획서가 있으면 거기서 답이 나온 슬롯은 재질문 금지. 이미 답한 걸 또 묻지 않습니다.
• 독립인 미확인 항목은 한 메시지에 몰아서. 한 항목씩 여러 턴으로 끄는 걸 금지합니다.
• 리뷰 자산 수가 곧 댓글박스 개수. 자산이 0이면 리뷰 섹션 자체를 뺍니다.
• 레퍼런스가 주어지면 눈대중 금지. get_metadata로 구조를, 스크린샷으로 대표 섹션 5~8장을 실측해 디자인 언어를 해독합니다. "레퍼런스는 구조·리듬을 빌리는 것이지 브랜드 색을 덮어쓰는 게 아니다."

그리고 절대 추측 금지 3종에는 이유가 달려 있습니다.

LLM이 placeholder를 그럴듯한 문장으로 채우는 습성을 정확히 겨냥한 조항입니다. 펀딩 페이지 변주에는 한술 더 떠 "거짓 희소성 금지 — 'N명 한정'은 실제 수용량 확정 후에만", "미구현 기능은 약속 카피 금지, FAQ에서 정직하게 계획 단계임을 밝힌다(이게 오히려 신뢰 신호)"까지 적혀 있습니다.

6. 세로 길이를 정하는 최상위 판단

상세페이지에서 가장 흔한 실패 — 텍스트로만 가득 찬 세로 페이지 — 를 막는 장치입니다. 원인 진단이 정확합니다: 텍스트를 먼저 다 채우고 이미지를 남는 자리에 끼우기 때문이라는 것.

판정은 Q1(실물성) · Q2(감각 의존도) · Q3(비주얼 자산) 중 2개 이상 YES면 감각형. 여기서 Q2를 다루는 방식이 특히 좋습니다.

주관적 판단을 관찰 가능한 신호의 체크리스트로 환원하고, 그래도 애매하면 어느 쪽으로 기울지까지 정해둡니다 — "애매하면 감각형으로 기운다. 히어로 자리를 안 잡는 false negative가 훨씬 손해다." 불확실성을 없애는 대신 기울일 방향을 미리 결정해 두는 이 방식은 다른 도메인에도 그대로 옮길 만합니다.

판정이 끝나면 공간 예약 원칙이 발동합니다: 시각 히어로 구간의 세로를 먼저 예약하고, 그다음 텍스트 섹션을 그 사이 리듬에 채웁니다. 순서를 뒤집는 것 자체가 금지 사항으로 명시돼 있습니다.

7. 실패에서 뽑아낸 T1~T15

troubleshooting.md는 이 저장소에서 가장 값진 86줄입니다. Figma Plugin API를 에이전트로 두들기다 실제로 터진 증상을 증상 → 원인 → 해법 색인으로 축적했고, 항목마다 "실측 검증"이라고 표시돼 있습니다. 몇 개만 옮기면:

figma-mcp.md(31줄)의 API 규칙도 같은 성격입니다. 읽기는 get_metadata → 필요한 노드만 get_design_context 2단계로만, 파일 전체를 한 번에 덤프하지 않기. 쓰기는 폰트 로딩 완료 후에만, appendChild 먼저 그다음 layoutSizing, 색상은 0–1 범위, 한 호출당 논리 연산 10개 이하로 분할.

"즉시 재시도 금지"는 에이전트 운용 규칙으로서 정확합니다. 실패를 읽지 않고 같은 걸 다시 던지는 건 senpi 정책의 산탄총 디버깅 금지와 같은 실패를 겨냥합니다.

8. 감독과 빌더 — 병렬 제작의 규율

섹션이 13개쯤 되면 순차 제작이 버겁습니다. 그래서 orchestration.md는 감독-빌더 패턴을 정의합니다. 여기 규칙들이 멀티 에이전트 운용의 교과서에 가깝습니다.

1. 섹션 = 독립 프레임 = 빌더 1명

   웨이브당 4~5명 병렬. 빌더는 자기 프레임 안에서만 작업하고 다른 프레임 수정·이동은 절대 금지.

2. 충돌 해소는 빌더가 아니라 감독이

   프레임 겹침은 웨이브가 끝날 때마다 감독이 재배치 스니펫으로 일괄 정리합니다(소수점 높이 정수화 포함 — T5).

3. 감독은 빌더의 자가검증 보고를 믿지 않는다

   "감독이 모든 섹션을 스크린샷으로 직접 검수한다(빌더 자가검증 보고만 믿지 않는다)."

4. 착수 전 1회 준비로 반복 낭비를 없앤다

   폰트 전수 검증을 감독이 한 번 해서 결과를 모든 빌더 프롬프트에 명기합니다. 실측 사례가 적혀 있습니다 — 손글씨 폰트 미보유를 여러 섹션에서 각각 재발견한 것이 최대 토큰 낭비였다고.

5. 카피 소스를 고정한다

   기획서 경로와 "원문 그대로, 창작·의역 금지"를 프롬프트에 박고, 미확정 값은 빈 슬롯으로 남기게 합니다.

6. 보고 없이 종료 금지

   "'반드시 보고'를 강조하지 않으면 빌더가 무보고 idle로 빠진다(강조 후 전원 보고로 개선됨). 무보고 idle이 와도 당황하지 말 것 — 대개 작업은 완료돼 있으니 프레임을 직접 스크린샷으로 확인한다."

마지막 항목은 서브에이전트를 실제로 굴려본 사람만 쓸 수 있는 문장입니다. 워커가 조용히 멈추는 현상과 그때의 대응까지 문서에 남겨둔 건 드뭅니다.

9. 세 해부의 공통점 (+ 비판)

이걸로 가재코드, senpi에 이어 세 번째 해부입니다. 도메인은 코딩 에이전트 둘과 디자인 스킬 하나로 완전히 다른데, 같은 두 문장이 세 곳 모두에 있습니다.

결론은 하나입니다. LLM에게 일을 시킬 때 위험한 건 능력이 아니라 "빈칸을 그럴듯하게 메우는 성향"이고, 잘 만들어진 도구는 전부 그 성향을 추측 금지 + 완료 전 실측 대조 두 축으로 묶습니다. 도메인이 코드든 디자인이든 처방이 같다는 게 이 시리즈에서 얻은 결론입니다.

비판

• 강제력이 가장 약합니다. 코드가 0줄이라 규칙 위반을 막는 런타임이 없습니다. 하드 게이트를 "전수 대조"할지는 결국 모델 성실성에 달려 있고, 스킬은 그걸 절차로 반복해 상기시키는 방식으로만 방어합니다.
• 외부 베타에 얹혀 있습니다. Figma 공식 MCP의 use_figma가 베타라 결과를 항상 스크린샷으로 재검증해야 합니다. 스킬이 그 절차를 강제하지만, 근본 리스크는 남습니다.
• 한국 커머스 관습에 맞춰져 있습니다. 860px 세로 스크롤 캔버스, 폭 대비 4.5% 본문 — 국내 상위 상세페이지 실측에서 나온 값이라 강력하지만, 데스크톱 랜딩이나 서구권 이커머스에 그대로 옮기면 안 맞습니다.
• 진입 문턱. Claude Code + Figma 계정 + MCP 등록 + OAuth까지 통과해야 첫 프레임이 나옵니다.
• 스타 21개의 1인 프로젝트. 문서 밀도는 규모에 비해 이례적으로 높지만, 커뮤니티 검증은 아직입니다.

그럼에도 이건 "스킬을 이렇게 쓰는 거구나"의 좋은 예입니다. 프롬프트 몇 줄로 톤을 바꾸는 수준이 아니라, 한 도메인의 실측 지식을 라우터·SSOT·체크리스트·트러블슈팅 색인으로 구조화했습니다. 자기 분야가 있는 사람이라면 이 형식을 그대로 빌려 자기 도메인 스킬을 만들 수 있습니다.

10. 직접 확인해보기

git clone https://github.com/HarinJin/KEZ-ProductPage-skill.git
cp -r KEZ-ProductPage-skill/detail-page-core ~/.claude/skills/

# Figma 공식 원격 MCP 등록 (최초 1회, 첫 사용 시 브라우저 OAuth)
claude mcp add --scope user --transport http figma https://mcp.figma.com/mcp

cd ~/.claude/skills/detail-page-core

cat SKILL.md                          # 라우터 + 하드 게이트 13개 (여기부터)
cat references/00-interview.md        # 인터뷰를 "인자 수집"으로 정의한 문서
cat references/troubleshooting.md     # T1~T15 실측 함정 색인
cat references/orchestration.md       # 감독-빌더 병렬 제작
cat references/design-dna/05-page-purpose.md   # 아키타입 판정 + 섹션 카탈로그