방향 — 톤을 정하고, 다른 구조를 먼저 보고, 제품끼리 다르게

작업규칙 · 조립 패턴 · 슬롭 지문을 다 지켜도 같은 디자인 시스템으로 만든 제품은 한곳으로 모인다 — 부품과 간격이 같으므로, 아무도 고르지 않으면 색만 다르다. 화면 하나하나는 흠잡을 데가 없어서 노드 검사(design-self-check)와 크리틱 (figma-quality-rubric.md)으로는 이 수렴이 보이지 않는다. 이 문서는 그 수렴을 막는 세 자리를 정한다 — 저작 전에 방향을 정하고 화면 결정으로 옮기는 자리(§D1 · §D2), 핵심 화면의 다른 구조를 먼저 보는 자리(§D3), 제품 사이를 비교하는 자리(§D4). 방향에는 핵심 행동을 하는 순간 사람이 확인해야 하는 사실(결정 정보 — §D1 ④)도 들어간다 — 구조를 고르는 동안 그 사실이 빠지지 않게 하는 자리다.

읽는 법 — 변주안 개수, 비교할 제품 수, 달라야 할 축 수는 초기값이다. 장부가 쌓이면 실측으로 고친다.

• 규칙 — 첫 화면을 그리기 전에 네 가지(하우스 스타일 서비스는 ⑤ 고유 요소까지 다섯 가지)를 정해 브리프(figma-brand-selection.md §1)에 적는다. ① 대상 — 구체적인 사람과 상황('소규모 필라테스 스튜디오의 저녁반 회원'). '사용자' · '누구나'는 대상이 아니다. ② 핵심 행동 — 이 제품에서 가장 중요한 행동 하나('오늘 저녁 수업 한 자리 예약'). 기능 목록이 아니라 하나다. ③ 톤 — 반대 방향이 분명한 구체적 이미지. 예: 고요한 인쇄물 · 정밀한 계기판 · 다정한 놀이 · 대담한 포스터 — 예시일 뿐이고, 어휘는 브랜드와 디자이너가 정한다. '깔끔한 · 모던한 · 심플한 · 세련된 · 직관적인'은 톤이 아니다 — 어느 제품에나 참이라 아무것도 고르지 않는다. ④ 결정 정보 — 핵심 행동을 하는 그 순간 사람이 확인해야 하는 사실의 목록. 핵심 행동에 질문 다섯을 던져 뽑는다 — 무엇을 · 얼마에 · 언제 · 누구에게(어디로) · 무엇이 줄어드나. 답이 없는 질문은 건너뛰고, 질문 밖이라도 그 순간 보이지 않으면 행동을 망설이거나 되돌리게 되는 사실이면 넣는다.
  • 형태 — 사실마다 화면이 보일 구체적 형태로 적는다: '도착 예정'이 아니라 '도착 날짜와 요일', '수강권'이 아니라 '차감될 수강권과 남는 횟수', '받는 사람'이 아니라 '받는 사람 이름과 나라'. 주제 낱말만 적은 칸은 아무것도 고정하지 않는다 — 주제가 화면에 있는지만 보게 되고, 값의 형태(날짜인지 기간인지)는 아무도 보지 않는다.
  • 값과 출처 — 사실마다 값을 같이 적는다. 출처는 스펙 인용(스펙이 그 값을 준다)이거나 스펙 값에서 유도(스펙의 값과 규칙만으로 답이 하나로 정해진다 — 기준 시각이 목요일 09:00 이고 '도착 예정 1영업일'이면 도착 날짜는 그다음 날 금요일)다. 유도는 입력(스펙 인용) · 계산 · 결과를 DDR 에 적는다. 스펙에 없는 가정(공휴일 달력 같은)이 답을 바꿀 수 있으면 그 가정도 적고 신뢰도를 low 로 둔다.
  • 지표 수치 규칙과의 경계 — 유도는 지어낸 수치가 아니다: 같은 스펙을 읽은 사람은 같은 값을 얻는다. 결정 정보의 값은 대개 날짜 · 개수 · 금액 · 이름이라 figma-slop-tells.md §S7 의 대상(출처 없는 지표 수치 — 비율 · 배수 · 증감 · 평점 · 누적 이용자)이 아니다. 결정 정보가 지표 수치면(이번 송금 뒤의 한도 사용률 같은) 스펙 수치 체크리스트의 결정 행(design.md Step 1)이 그 유도의 DDR 을 가리킬 때만 §S7 대조에서 '체크리스트에 있는 값'이다 — 가리키지 않으면 지어낸 수치다. 인용도 유도도 안 되면 날짜 · 개수 · 이름 같은 샘플 값은 figma-composition-patterns.md §C10 ② 로 채우고 출처를 샘플 로 적는다. 지표 수치는 §C10 ③ 대로 — 와 '수치 확인 필요'를 그린다. 어느 쪽이든 사실의 자리는 그린다 — 값이 없다고 사실을 빼지 않는다.
  • 어디에 — 결정 화면에 그린다: 핵심 행동 흐름의 첫 화면(§D3 ① 의 그 화면)과, 핵심 행동을 일으키는 CTA(예약 · 신청 · 송금 · 결제 · 제출처럼 누르면 그 행동이 일어나는 주 버튼)가 있는 화면. 흐름에 들어가기만 하는 버튼(홈의 '송금하기'가 견적 화면을 여는 것)이 있는 화면은 결정 화면이 아니다 — 그 화면이 흐름의 첫 화면이 아닌 한. ⑤ 고유 요소 — 하우스 스타일 서비스는 필수, 그 밖은 권장. 이 서비스에서만 의미 있는 요소 셋 — 다른 서비스 화면으로 옮기면 어색해지는 것이다. 도메인 데이터의 모양 · 이 서비스에만 있는 흐름이나 상태 · 도메인 용어와 시각 단서 중에서 고르고(cc-designer:critique-specificity §1 의 표), 요소마다 어느 화면이 맡는지를 적는다 — 하나는 결정 화면(④)이 맡는다. 로고 · 브랜드 색 · 앱 이름 · 부품 자체 · 어느 서비스에나 있는 문구(로그인 · 설정 · 더 보기)는 고유 요소가 아니다.
  • 어디서 오나 — 스펙의 도메인 데이터와 사용 장면에서 뽑는다. 사람이 준 것(--direction · 스펙의 명시 · 답변)이 앞선다. 뽑을 수 없으면 추론하고 추론함 + DDR low 로 적는다. 대화형이면 위 한 질문에 뽑은 셋을 같이 보여 사람이 고칠 수 있게 한다.
  • 왜 — 하우스 스타일은 깊이 · 강조 등의 바닥선이 있어 아무도 고르지 않으면 부품 기본값만 남는다. 고유성 렌즈(design.md Step 4 크리틱)는 그리고 난 뒤에야 보므로, 그리기 전에 셋을 약속해 둔다.
  • 확인 — 크리틱의 고유성 렌즈가 댄 셋과 약속한 셋을 대조한다. 약속한 셋 중 크리틱이 대지 못한 것은 보고에 '그려지지 않음'으로 적고, 고치는 자리는 방향이 아니라 그 화면이다(figma-quality-rubric.md §2).
• 어디서 오나 — 우선순위는 --direction > 스펙의 명시 > 묻기(대화형) > 추론(무인).
  • 대화형(사람이 이 대화에서 커맨드를 직접 불렀다) — 빈 칸만 저작 전에 한 번 묻는다. 세 칸을 한 질문에 담고, 스펙에서 추론한 안을 권고안으로 먼저 보인다.
  • 무인(다른 파이프라인이 문서 절차로 수행한다 — 예: cc-product-auto) — 스펙에서 추론하고 묻지 않는다. 추론한 칸은 보고 첫 줄에 추론함 으로 적고 DDR 신뢰도를 low 로 둔다. 스펙이 방향을 '추론함'으로 표시해 넘겼으면(--direction 으로 받았더라도) 그 표시를 그대로 옮긴다 — 앞 단계의 추론도 추론이다.
  • --frames 증분이고 같은 파일의 방향 DDR 이 있으면 그것을 쓴다 — 다시 묻지 않는다.
  • 결정 정보는 묻지 않는다 — 정해진 핵심 행동과 스펙에서 뽑는다(--direction 으로도 받지 않는다). 대화형이면 세 칸을 묻는 그 한 질문에 뽑은 목록을 같이 보여 사람이 고칠 수 있게 한다. 핵심 행동이 바뀌면 다시 뽑는다.
• 왜 — 관점이 없는 브리프(무엇을 내세울지 정하지 않은 화면)는 도구가 풀 수 없다. 도구가 할 수 있는 일은 그 질문을 피하지 못하게 만드는 데까지다. 추론은 가장 흔한 답으로 흐른다 — 근거를 들어 고른 답은 대개 그 카테고리의 평균이다. 그래서 사람이 정한 방향이 앞서고, 추론한 방향은 사람이 바로 고칠 수 있게 맨 앞에 드러낸다. 방향은 디자인 판단이 아니라 저작의 입력이므로 cc-designer:design-decision 의 '되묻지 않는다' 대상이 아니다. 다만 묻는 것은 저작 전 한 번이다. 결정 정보가 방향에 있는 이유 — 스펙 대조는 스펙이 못박은 값만 보고, 크리틱은 빠진 사실을 다듬기(P3)로 둘 수 있어서, 행동에 꼭 필요한 사실이 어느 검사에도 걸리지 않고 빠진다. 실제로 송금 견적 시안이 스펙 값 그대로 '도착 예정 1영업일'만 그리고 달력 날짜와 받는 나라를 빠뜨린 채 스펙 대조를 통과했고, 수업 상세의 차감 안내에서 남는 횟수가 빠진 것을 크리틱이 P3 로 두어 그대로 출하됐다. 같은 스펙을 다르게 그린 시안은 그 사실들을 그렸고, 블라인드 평가자 한 명은 바로 그 이유로 그쪽을 출시할 시안으로 골랐다(다른 평가자들도 그 차이를 짚었다). 핵심 행동에서 뽑아 형태까지 적어 두면 저작 · 스펙 대조 · 크리틱이 같은 목록을 본다.
• 확인 — 브리프에 네 칸과 출처(--direction · 스펙 · 답변 · 추론함)가 있고, 톤 칸이 비어 있지 않으며 위 금지 어휘가 아니다. 하우스 스타일 서비스는 고유 요소 셋과 담당 화면도 있다. 결정 정보는 사실마다 형태 · 값 · 출처(스펙 인용 · 유도 · 샘플 · 수치 확인 필요)가 있고 결정 화면이 정해져 있다. 결정 화면에 값이 그 형태로 그려졌는지는 design-self-check 9번이 노드 값으로 본다.

• 규칙 — 톤에서 아래 레버의 값을 정해 DDR 한 건으로 남긴다. 레버는 색보다 먼저 정한다 — 브리프의 '색 방향'은 톤과 키워드에서 나온다.

라이브러리 preset은 출발점이다. 전체 테마와 특정 컴포넌트 스타일을 모두 설계할 수 있으며 없는 컬렉션/스타일도 제품에 정의한다. 현재 코드가 지원하지 않는 속성은 디자인에 표현하고 구현 gap으로 남긴다. cc-designer:coui-product-style의 브랜드 테마 절차가 적용 범위와 상속을 정한다.

• 왜 — 톤이 레버로 옮겨지지 않으면 브리프는 문장으로만 남고 화면은 기본값으로 그려진다. Figma 에서 움직이는 레버(위의 '사용')로 톤이 화면을 바꾸게 하고, 미지원 속성의 구현 gap을 남겨 디자인과 코드 사이에 필요한 확장을 추적한다.
• 확인 — DDR 에 레버 값마다 톤에서 나온 이유가 한 줄씩 있다. '카테고리 경향' · '레퍼런스 평균'은 이유가 아니다 — 평균을 근거로 고르면 평균이 나온다. 하우스 스타일 서비스는 덮어쓰지 않은 미리 채운 레버(밀도 · 깊이 · 강조 면적 · 형태 · 재질 · 서체 역할)의 이유가 「하우스 스타일」 한 줄이면 충분하고, 덮어쓴 레버는 톤에서 나온 이유가 있어야 하며, 위계 · 구성 단위는 톤(하우스 무드)과 핵심 행동에서 나온 이유를 적는다.

• 규칙 — ① 대상 화면 — 진입 화면(홈)과 핵심 행동 흐름의 첫 화면, 최대 두 화면. 둘이 같으면 하나다. ② 안 — 화면마다 2–3안, Mobile Default 프레임 하나씩만 그린다(상태 · Web 은 고른 뒤 본 저작에서). 안끼리 위계 · 구성 단위 · 밀도 · 내비 구조 중 두 축 이상 달라야 한다 — 색이나 간격만 다른 안은 변주가 아니다. 하우스 스타일에서도 소비자 앱·사이트의 내비 구조는 사용자 작업으로 선택할 수 있다. 운영 도구처럼 셸과 밀도가 실제로 고정된 경우에는 위계 · 구성 단위 둘 다 달라야 한다. 모든 안은 §D1 의 방향을 지킨다(방향 안에서 구조를 고르는 일이다). 결정 화면(§D1 ④)의 안은 모두 결정 정보를 그린다 — 결정 정보는 안끼리 다르게 할 축이 아니다. 사실을 빼서 가벼워진 안은 변주가 아니라 누락이다. ③ 어디에 — _explore 페이지(검사 대상 밖 — figma-workflow.md §1)의 섹션 방향 — {화면} 에, 프레임 이름 {가|나|다} · {한 줄 요약}. 고른 안이 본 화면의 출발점이 되므로 본 저작과 같은 규칙(라이브러리 인스턴스 · 선택 컬렉션 · brand-bind 마지막)으로 그린다. ④ 고르기 — 대화형이면 사람에게 한 번 묻는다(안마다 한 줄 요약, 권고안을 먼저). 무인이면 기준을 적고 고른다 — 결정 정보를 다 그린 안 중에서 핵심 행동이 가장 가까운 안 (진입부터 핵심 행동까지의 탭 수, 첫 시선이 닿는 자리). 동률이면 장부(§D4)의 최근 제품과 더 많이 다른 안. ⑤ 기록 — 고른 안 · 고른 이유 · 버린 안과 버린 이유를 DDR 한 건으로 남긴다. 버린 안은 지우지 않는다 — 나중에 바꿀 수 있게 _explore 에 둔다. ⑥ 따르기 — 나머지 화면은 고른 안의 위계 · 구성 단위 · 밀도 · 내비 구조를 따르고, 공통 요소(design.md Step 1.7)가 이 결정을 받는다. 본 저작은 고른 안을 복제해 그 섹션의 Mobile-Default 로 시작해도 된다 — 원본은 _explore 에 남긴다.
• 건너뛰는 경우 — --frames 증분 · 스펙이 화면 구조(와이어프레임 · 구성)를 이미 못박음 · 같은 파일에 고른 방향의 DDR 이 이미 있음. 건너뛴 사유를 보고에 적는다.
• 왜 — 첫 안을 그대로 받아들이면 그 안이 기본값이 된다. 다른 구조가 가능했다는 것을 보지 못했기 때문이다. 안을 나란히 놓아야 고를 수 있고, 고른 이유가 남아야 다음 제품이 같은 선택을 되풀이하는지 볼 수 있다. 화면과 프레임 수를 묶어 두는 이유는 구조가 Default 에서 정해지기 때문이다 — 상태 프레임은 고른 구조를 따르기만 하므로 안마다 그릴 필요가 없다(최대 프레임 여섯 개).
• 확인 — 보고의 변주안 줄에 화면마다 안 이름 · 서로 다른 축 · 고른 안 · 이유가 있고, _explore 에 버린 안이 남아 있다.

• 축 기록 — 제품마다 한 줄이다. 값은 아래 어휘에서 고르고, 고르지 않은 칸은 기본 이다.

{"product": "<제품 이름>", "date": "YYYY-MM-DD", "tone": "고요한 인쇄물",
 "palette": {"family": "자홍", "chroma": "차분", "hue": 318},
 "structure": "시간축", "hierarchy": "다음 행동 하나", "density": "여유", "depth": "평면",
 "accent": "기본", "shape": "기본", "type": "단독", "surface": "기본"}

• 어디에 — 제품의 축 기록은 제품 저장소의 디자인 기록(예: docs/brand.md 의 「축 기록」)에 두고 보고에도 싣는다. 여러 제품의 기록을 모은 장부 (위 형식의 JSON Lines — 한 줄에 한 제품, 파일 순서가 시간 순서)는 조직이 정한 곳에 두고 --ledger {path} 로 넘긴다. 이 저장소에는 두지 않는다 — 제품 이름이 들어간다.
• 판정 — 레버를 정한 직후, 첫 화면을 그리기 전에 장부에서 이 제품을 뺀 마지막 다섯 줄과 비교한다. 각 줄과 '센다' 축 중 두 개 이상 달라야 한다. 같은지는 값을 글자 그대로 비교한다. 서페이스 스타일 하나가 모서리와 재질을 함께 정하므로, shape 과 surface 가 같은 스타일 이름이면 둘이 달라도 한 축으로 센다 — 스타일 하나를 바꾼 것으로 두 축을 채우지 않는다. 미달이면 저작 전에 레버를 바꾼다 — 지금 움직이는 레버(§D2 '사용')에서. 바꾸지 않기로 하면 L1 이고, 사유는 "이 제품이 그 제품과 같아야 하는 이유" 한 줄이다(같은 제품군이라 같은 셸을 쓴다 등). 두 제품이 모두 하우스 스타일이면 하우스 값 그대로인 축은 비교에서 뺀다 — depth · accent 는 늘 하우스 값(고정)이고, density · shape · type · surface 는 덮어쓴 제품이 있을 때만 센다. 세는 축은 structure · hierarchy 에 덮어쓴 축을 더한 것이고 그중 두 개 이상 달라야 한다 — 덮어쓴 축이 없으면 둘 다 달라야 하므로 하나라도 같으면 미달이다. 미달이면 위계 · 구성 단위를 바꾸고, 바꾸지 않으면 위와 같이 L1 이다. 하우스 스타일의 형태 · 재질 defaultStyle 은 라이브러리 기본 모드라 기본 과 같은 모습이다 — 축 기록의 shape · surface 에 기본 으로 적어, 하우스가 아닌 제품과 비교할 때 이 두 칸이 다른 값으로 세어지지 않게 한다.
• 갱신 — 저작이 끝나면 실제로 그려진 값으로 축 기록을 다시 쓴다(변주안에서 고른 구조 포함). 장부가 쓸 수 있는 로컬 파일이면 같은 제품의 줄을 바꾸거나 한 줄을 더한다. 다른 저장소에 있으면 쓰기 허용이 명시된 때만 쓰고, 아니면 더할 줄을 보고에 싣는다.
• 장부가 없으면 — 비교를 건너뛰고 보고에 '장부 없음' 한 줄을 적는다. 축 기록은 그래도 남긴다 — 다음 제품의 비교 대상이 된다.
• 왜 — 같은 디자인 시스템으로 만든 제품은 부품과 간격이 같아서, 고르지 않으면 색만 다르다. 화면 하나하나는 흠잡을 데가 없으므로 이 수렴은 화면 단위 검사로는 보이지 않고 제품을 나란히 놓아야 보인다 — 기록이 없으면 나란히 놓을 수도 없다. 앱 안의 화면끼리는 반대로 같아야 한다. 그것이 일관성이고, 장부는 제품 사이만 본다.
• 확인 — 보고에 축 기록 한 줄과 비교 결과(비교한 제품 수 · 미달 제품과 처리, 또는 '장부 없음')가 있다.