통합 디자인 시스템

하나의 진입점으로 모든 디자인 영역을 커버합니다.

리소스 로딩 규칙

시작할 때 레지스트리를 로드합니다. 각 단계에서는 해당 단계의 리소스를 필요에 따라 로드합니다. 사용자 선호도 프로필을 통해 생성하지 않습니다. 스킬 아키텍처는 skill-architecture.html, 실행 경로는 skill-workflow.html, 버전 변경 사항은 CHANGELOG.md를 참조하세요.

시작 시 로드

리소스	이유
`manifest.md`	어떤 영역과 리소스가 있는지 파악

로딩 예산(엄격한 상한선)

이 스킬은 125개의 파일을 포함합니다. 모든 파일을 다 읽은 후 작업을 시작하면 임무 실패입니다.

제약 조건	값
시작 로드(예산 미포함)	`manifest.md`——레지스트리는 필수, 할당량 미차감
메인 파일 외 규칙 파일 최대 추가 로드	4개
이 파일들의 총합	≤1200줄(실제 총 제한)
단일 파일 >400줄	지목된 `§` 절만 읽고, 전체 파일은 읽지 않음

왜 4개인가: 실제 비용은 파일 수가 아니라 줄 수입니다(웹 라인의 필수 3개가 1200줄의 37%만 차지). 파일 수 제한은 '여기저기 조금씩 읽는 것'을 방지하기 위한 휴리스틱입니다——4개 × 평균 300줄 ≈ 1200줄로, 두 제약이 서로 일치합니다. 네 번째 할당량을 기본 여유분으로 생각하고 함부로 사용하지 마십시오. 사용하기 전에 아래의 배치 결정을 먼저 수행하세요.

예산은 다음 순서로 사용됩니다: ① 영역 메인 파일(domains/web/distilled-playbook.md / domains/poster/MODE.md / domains/brand/MODE.md) ② 해당 영역에서 '필수'로 표시된 파일(예: domains/web/anti-slop/MODE.md) ③ 특정 값이 반드시 필요할 때만 shared/의 해당 § 절을 읽습니다.

현재 구조에서 한 번의 웹 작업에 필수로 읽어야 할 파일은 3개입니다: distilled-playbook.md + domains/web/anti-slop/MODE.md + references/flow.md. 소재 등급, 로컬 폰트 목록, 엔지니어링 함정 P1–P11은 모두 이 파일에 포함되어 있으므로 더 깊이 내려갈 필요가 없습니다. 네 번째 할당량의 설계 용도: 단계 ④에서 shared/react-bits-assets.md(§0 + §3, 1626줄 전체 읽기 금지)를 읽습니다. 그 외의 경우에는 여유분입니다 (네 번째 파일이 반드시 필요할 때 사용, '새 규칙 배치 위치' 참조).

영역 원칙은 도메인별로 분할됩니다(참조용, 필수 읽기 할당량 미포함): 전 영역 공통 핵심 shared/design-principles.md(§1.1–§1.12) + 영역별 서브셋 shared/design-principles-web.md / shared/design-principles-brand.md / shared/design-principles-poster.md. 로드 방식: 현재 영역에 해당하는 서브셋만 로드하고, 필요에 따라 사용합니다(예: 웹 작업의 단계① 경쟁사 분석 / ③ 기억점 디자인 시에만 design-principles-web.md의 해당 절을 읽음). 참조용, 필수 3개 할당량에 포함되지 않음, 공통 핵심 전체를 다 읽을 필요는 없습니다.

references/gates.md와 constraints.md는 선택적 참조(판단 기준 세부 사항 / 경계 상황)에 해당하며, 이 3개의 할당량에 포함되지 않습니다——필요할 때 확인하고, 필요 없으면 건너뜁니다.

금지: '전체 그림 이해'를 위해 지목된 모든 파일을 통독하는 행위; shared/react-bits-assets.md(1626줄; 컴포넌트 선택은 §3 분류 / §5 상세 설명 참조) 또는 shared/design-philosophies.md(철학 선택은 §선택 가이드 참조) 전체 읽기; 4개 이상의 파일을 연속으로 읽고도 작업을 시작하지 않는 행위.

새 규칙 배치 위치(배치 결정, 예산 사용 전에 먼저 수행)

새 규칙을 추가할 때는 다음 순서로 판단하세요. 처음 세 단계에서 해당되면 새 파일을 만들지 마십시오:

모든 영역, 모든 작업에 필요한가? → 메인 파일에 배치합니다(메인 파일은 예산 미차감——필수 규칙의 적절한 비용: 매번 사용해야 하므로 매번 함께 로드되어야 합니다). 판단 기준: 포스터 작업과 웹 작업 모두 이 규칙 없이는 잘못될 것입니다.
특정 영역의 프로세스에만 해당하는가? → 해당 영역의 기존 필수 파일에 통합합니다(예: 웹의 경우 distilled-playbook.md에 통합), 새 파일을 만들지 않습니다. SSoT: 새 파일을 만드는 대신 소제목으로 구획을 나누는 것이 좋습니다.
단지 값/세부 규칙/조회 테이블인가? → shared/의 해당 파일에 배치하고, 참조 수준으로 유지합니다(필수 읽기 할당량 미포함, 필요할 때만 조회). 메인 파일과 관련이 있으면 한 줄의 포인터를 남깁니다.
위의 어디에도 해당하지 않고, 실제로 매번 필수로 사용되어야 하는가? → 그때서야 새 필수 파일을 추가할 수 있습니다. 이 경우 '영역별 빠른 참조'에 해당 영역 라인에 속한다고 등록하고, 1200줄 총 제한이 여전히 유효한지 확인합니다(현재 웹 라인은 439/1200 사용).

메인 파일 경계선: ≤400줄. 초과 시 '매번 필수는 아닌' 내용을 판단 기준에 따라 먼저 references로 내리고(한 줄의 판단 기준 남김), 계속 부풀리지 마십시오——메인 파일이 한 줄 늘어나면 모든 작업이 그 비용을 지불합니다.

예산 소진 시 중단: 읽은 내용으로 결과물을 생성하고, 전달 시 'X(로딩 예산) 건너뜀'을 한 줄로 명시합니다. 3개 파일 기반의 완전한 솔루션이 10개 파일을 읽고 결과물이 없는 것보다 낫습니다.

전달 전 자체 검증(로딩 예산 미포함)

HTML을 생성한 후, 한 번은 헤드리스 브라우저 렌더링(npx playwright screenshot / 로컬 Chrome·Edge --headless --screenshot)을 실행하고, 최소 1440과 390 두 가지 너비에서 각각 스크린샷을 찍어 세 가지를 확인하는 것을 권장합니다:

초기 화면이 비어 있지 않은가——애니메이션이 JS/IntersectionObserver에 의존해야만 나타나는 경우, 느린 기기와 스크린샷 상황에서 모두 흰색으로 보일 수 있습니다. 초기 화면 콘텐츠는 직접 볼 수 있어야 합니다.
가로 오버플로우 또는 텍스트가 가장자리에 붙어 있는가——블록의 padding 단축 속성이 컨테이너의 좌우 안쪽 여백을 덮고 있는지 확인합니다.
제목이 오버플로우되는가——데스크톱 너비에서 제목이 3줄을 초과하면 clamp() 상한 또는 글꼴 크기가 잘못된 것입니다.

문제를 발견하면 즉시 수정하고, 렌더링되지 않은 페이지를 전달하지 마십시오. 코드만 보고서는 이 세 가지 유형의 문제를 찾을 수 없습니다.

자체 검증 예산(상한 있음, 자체 검증이 무한 수정으로 이어지는 것을 방지) : 최대 2라운드, 각 라운드 2장(1440 / 390), 단일 라운드 ≤90초. 2라운드 후에도 문제가 있으면 중단하고, 남은 문제를 전달 설명에 기록합니다——자체 검증은 세 가지 유형의 구조적 문제를 발견하는 수단일 뿐, 페이지를 완벽하게 조정하는 것이 아닙니다.

7가지 핵심 디자인 원칙

이 7가지 원칙은 디자인의 영혼 가이드입니다. 체크리스트가 아니라 사고 방향입니다.

원칙	핵심 질문	의미
근거 있음	누구를 위해 디자인하는지, 어떤 문제를 해결하는지 아는가	작업을 시작하기 전에 파악하세요: 대상 사용자는 누구인가? 페이지를 본 후 사용자가 무엇을 하기를 바라는가? 전달해야 할 핵심 정보 한 가지는 무엇인가? 근거 없는 디자인 = 자기만족
영혼 있음	모든 결정이 하나의 통일된 톤앤매너를 따르는가	"이 페이지가 사람이라면, 어떤 기품을 가졌을까?" 한 단어로 정의하세요(예: "정교함"/"힘"/"반항"). 이후의 색상, 글꼴, 간격, 애니메이션은 모두 이 단어를 중심으로 전개됩니다
시스템 있음	모든 요소가 동일한 시각적 문법을 따르는가	색상, 글꼴, 간격, 애니메이션 지속 시간, 상호 작용 피드백 — 통일된 규칙을 수립한 후, 각각의 새 요소는 이 시스템을 자동으로 상속받아 개별 결정이 필요 없습니다. 자세한 내용은 `shared/system-design.md` §2 디자인 시작점 선택 + §3 3가지 매개변수 영향 매트릭스 참조
기억점 있음	최소한 하나는 사람들이 멈춰서 볼 만한 것이 있는가	독특한 상호 작용 방식, 재질감, 텍스트 처리 방식, 공간 관계 등이 될 수 있습니다. 복잡할 필요는 없습니다 — 정교하게 실행된 하나의 단순한 아이디어가 열 개의 조잡하고 복잡한 효과보다 낫습니다
온기 있음	정보를 나열하는 것 이상으로 감정을 전달하는가	페이지가 주는 느낌은 무엇인가요? 조용함, 활기, 따뜻함, 신비로움, 기술적 감각, 자연스러움? 감정은 장식이 아니라 디자인의 근본적인 동력입니다
품질 있음	결과물이 완전하고 사용 가능해야 하며, 반제품이 아니어야 하는가	모든 상태가 처리되어야 함(loading/empty/error/success), 모바일 적응 완벽, prefers-reduced-motion 지원, CSS 변수 사용
장인 정신 있음	이 디자인을 진지하게 대했는가?	중요한 내용을 빠뜨리지 않고, 대충하지 않으며, 저품질로 좋은 척하지 않고, 함부로 만들지 않습니다. 모든 세부 사항을 진지하게 다루고, 최선을 다하며, 대충하지 않습니다

단일 진실 공급원 계약(SSoT · 본 파일을 수정하기 전에 반드시 읽을 것)

본 파일의 과거 주요 실패 모드: 동일한 규칙이 3~4군데에 복사됨——프로세스 표에 한 번, 하드 체크포인트에 한 번, 품질 게이트에 한 번, 제약 조건에 또 한 번. 결과는 '더 안전함'이 아니라 반복되는 빈 체크박스로 취급됨입니다: 한 군데 체크하면 통과로 간주되어 규칙이 실제로는 무효화됩니다. 이것이 바로 '문서상 준수 ≠ 코드 수준 준수'의 메커니즘 원인입니다.

계층별 책임(새로운 내용은 이에 따라 배치해야 하며, 잘못 배치되면 결함으로 간주):

계층	위치	무엇만 넣을 것인가	무엇을 넣지 말아야 하는가
정의 계층	「작업 방식 제약」 제약0–9, 「공통 최소 기준」	규칙의 유일한 정의	—
프로세스 계층	적응형 디자인 프로세스 각 단계 표	언제 무엇을 하는지 + 어떤 파일을 참조할지 + 포인터('제약X에 따름')	제약 정의를 다시 서술하는 것을 금지
게이트 계층	네 번째 단계 실행 게이트, 품질 게이트, 엔지니어링 함정 게이트	검증 동작 / PASS 임계값 / 체크리스트 질문	제도적 정의를 재확인하는 것을 금지

배치 테스트(규칙 추가 시 반드시 질문): 이 규칙은 정의하는 것인가, 아니면 검증하는 것인가? → 정의는 정의 계층으로, 검증은 게이트 계층으로, 둘 중 한 곳에만 배치해야 합니다. → 더 나아가: 판단 유형(취향/일관성/풍부함, 기계적으로 판단 불가)은 품질 게이트로; 사실 유형(grep/ls/어설션으로 검증 가능)은 엔지니어링 함정 게이트로. 계층을 잘못 배치하면 이 규칙은 무효화됩니다.

디자인 프로세스(6단계)

단계	수행할 작업	산출물
① 리서치 및 요구사항	잠재적 요구사항 추출, 영역 판단, 세 가지 매개변수 결정	요구사항 재진술(CP1 용) + 세 가지 매개변수
①.5 능동적 추론	한 줄 요구사항을 완전한 브리프로 확장	확장된 브리프
② 영감 고정	1개의 최고급 방향을 직접 고정(4축 중 하나)	방향 + 핵심 장력(CP2 용)
③ 구상 및 내러티브	정보 아키텍처, 스크롤 내러티브, 의도 맵	Intention Map(필수, 미산출 시 ④로 진입 불가)
④ 시스템 디자인	디자인 문법, 애니메이션 인벤토리, 기능 인벤토리; 애니메이션/인터랙션 컴포넌트는 먼저 `shared/react-bits-assets.md` §0(이행 상태: 11개 로컬 ✅, 나머지 🌐는 네트워크 필요) + §3 예비 선정을 확인하고, ✅ 또는 자체 제작한 동등한 것만 사용	시스템 디자인 표 + 기능 목록 ≥8–10개(컴포넌트 출처 표기 필수: react-bits ✅ / 🌐 / 자체 제작)
⑤ 시각적 구현	글꼴 / 색상 / 타이포그래피 / 소재 적용	페이지 산출물(HTML/CSS/JS, 형태는 `shared/code-generation-strategy.md` §3.1 참조; 글꼴 및 소재의 적용 또는 다운그레이드 선언 포함)
⑥ 인터랙션 및 전달	인터랙션, 성능, 3가지 게이트	게이트 통과 완제품(CP4 용) + `usage-log.md`에 한 줄 추가(날짜 / 작업 / 시드 / 마우스 계열 / 컴포넌트)

어느 단계에 도달했는지에 따라 references/flow.md의 해당 절만 읽으십시오——전체를 읽을 필요는 없습니다. 각 절에는 '수행할 작업 / 구체적 내용 / 참조할 사항'의 세 가지 열이 포함되어 있습니다.

영역 분기(중요): 위의 7단계는 웹의 완전한 프로세스입니다. 다른 두 영역은 자체 라인을 따르며, 웹의 단계와 게이트를 적용하지 마십시오:

포스터 → domains/poster/MODE.md §8의 5단계: 크기 결정 → 주장 결정 → 패밀리 선택 → 3계층 배치 → 썸네일 자체 점검
브랜드 → domains/brand/MODE.md의 B1–B5: 전략(9가지 질문법) → 시각적 패턴 → 로고 → 브랜드 보드 → 산출물

비디오 → domains/video/MODE.md: 먼저 사용해야 하는지 판단(§1) → 역할과 볼륨 결정(§2) → 경로 선택(§3) → 퓨전 수행(§4, 어색함의 90%는 이음새) → V1–V9 전달 점검 통과.

도구는 우회로이며, 메인 루프에 속하지 않습니다: PPT / 비디오 내보내기 / 리디자인 감사 / 디자인 씽킹은 각각 독립적으로 트리거되며(영역별 빠른 참조 참조), 6단계와 병렬로 실행되며 단계 번호를 차지하지 않습니다.

작업 방식 제약 0–9(빠른 참조)

#	규칙	판단 기준 / 예외
0	사용자 명시적 지시 > 일반 기본값	하드 규칙과 충돌 시 지적하고 대안 제시; 사용자가 고집하면 따름
1	최고급 방향을 직접 고정하고, 평행 옵션을 제시하지 않음	4축 중 하나(극도의 절제 / 밀도 / 움직임 / 재질)를 끝까지 수행; 구현 난이도를 다운그레이드 이유로 사용하지 않음(난이도는 구현 경로에만 영향을 미치고, 솔루션에는 영향을 주지 않음)
2	= 제약1의 시나리오 확장	"아무거나"→1개 솔루션; "2–3개 비교해 줘"일 때만 여러 솔루션
3	한 번에 한 가지 질문만 하기	여러 질문 = 사용자가 원인을 추적할 수 없음
4	정교함이 속도보다 우선	동기에 없는 애니메이션 / 리듬이 완전히 평평함 / 상태 누락 → 멈추고 수정
5	섹션 수는 계획에 따라 결정	<5인 경우 '왜 미니멀이 이 브리프에 적합한지' 명시; 숫자 채우기, 게으름 금지
6	패턴은 시드이지, 뼈대가 아님	'스타일 선택→뼈대 적용' 금지, 즉시 재구성해야 함
7	시드 기반 일관성 계약	각 차원이 시드와 공진하거나, '의도적으로 생략함'을 명시해야 함
8	반-보수적 생성 규율	≥3가지 기술 언어 사용; 인터랙션은 실제여야 함; 텍스트도 움직여야 함
9	소재 라이브러리 사용 규율	먼저 시드 고정 → 같은 계열 본 페이지 ≤1 → 사용 선언 작성
10	솔루션 동결, 기성품을 가져오는 행위 금지	먼저 '솔루션에 필요한 것'을 나열한 후 '가지고 있는 것'을 확인; 교체는 '원래 계획 / 실제 구현 / 동등하지 않은 이유'를 반드시 작성해야 하며, 묵시적 교체 = 실패

전체 규칙, 경계 상황 및 원리(제약 0의 충돌 중재 세부 사항 포함)는 references/constraints.md를 참조하세요. 제약 0의 우선순위가 가장 높으며, 다른 제약 및 게이트보다 우선합니다(엔지니어링 최소 기준 제외).

게이트 빠른 참조(전달 전 반드시 통과)

게이트	시기	확인 사항	통과하지 못하면 어떻게 하나
실행 게이트	⑤ 진입 전	기능 목록 ≥8–10개(반드시 포함: ≥1 텍스트 애니메이션 / ≥1 WebGL·Canvas / ≥1 GSAP·스크롤 연출); 동일 계열 반복은 시드 이유를 명시해야 함(`usage-log.md` 확인); 네트워크 획득 기록(무엇을 가져왔는지→어디서→결과, A3); 전달 형태가 제한될 때는 도달 가능한 최대치를 제공하고 제한 이유를 명시해야 하며, 허위 생성 또는 묵시적 누락 금지	목록을 보충한 후 진입
품질 게이트 7가지	⑤ 말기 · ⑥ 전	전달 시 PASS/HOLD 결정을 제공해야 함(`taste-rules.md` §8, '전체적으로 괜찮음'식 통과 금지); critique 10차원 + 미디어/애니메이션/레이아웃이 '절제되었으면서도 풍부한지' + 시드 일관성 + 반-보수적 7가지 질문	해당 단계로 돌아가 수정, 반제품 상태로 전달 금지
엔지니어링 함정 게이트 P1–P11	전달 전	grep / ls 기계적 검증: 글꼴 적용, CDN 폴백, 가로 오버플로우, 기울임꼴 디센더…	PASS될 때까지 수정, FAIL 상태로 전달 금지

실행 게이트와 품질 게이트의 판단 기준 세부 사항은 references/gates.md를 참조하세요. 엔지니어링 함정 P1–P11은 다음과 같으며, 매번 필수로 사용되므로 더 이상 내리지 않습니다.

엔지니어링 함정 게이트 P1–P11(전달 전 항목별 실행)

위의 품질 게이트와의 역할 구분(중요): 품질 게이트는 '좋은가 나쁜가'를 판단합니다——취향/일관성/풍부함, 이는 판단 유형에 속하며 미적 감각에 의존하고 기계적으로 판단할 수 없습니다. 본 게이트는 '고장 났는가'를 판단합니다——사용성/시각적 품질에 실제로 해를 끼치는 알려진 엔지니어링 결함으로, 사실 유형에 속하며 검증에 의존합니다. 포함 원칙: grep / ls / 런타임 어설션으로 기계적으로 검증할 수 있는 항목만 포함합니다. 판단 유형 규칙은 절대 본 게이트로 들어오지 않습니다(품질 게이트에 남음). 그렇지 않으면 '자체 준수 증명'의 빈 체크박스로 퇴화됩니다. 실행: 전달 전에 항목별로 실행하며, 하나라도 FAIL → 수정 후 재검증, FAIL 상태로 전달 금지.

#	함정(실제로 겪었던 것)	검증 방식	PASS 조건
P1	배경만 움직이고, 콘텐츠는 움직이지 않음(가장 흔하고, '통일감'을 가장 해침)	각 콘텐츠 섹션의 스크롤 애니메이션 바인딩을 grep	콘텐츠 컨테이너에 scroll-linked `translateZ`/`scale`/`rotate`가 존재하고, `opacity`/`clip-path`만 있는 것이 아님; 배경과 콘텐츠가 동일한 progress로 구동됨
P2	깊이감/장식 레이어가 콘텐츠를 가림	`z-index` 스택 + `pointer-events` 확인	근경/장식/노이즈 레이어의 `z-index`가 콘텐츠 레이어 보다 낮고, 모두 `pointer-events:none`
P3	전환 깜빡임/번쩍임이 눈에 거슬림	깜빡이는 요소의 `opacity` 피크 값과 `duration` 확인	피크 값 ≤ .4이고 지속 시간 ≥ .3s(정량화 가능한 임계값, 초과 시 눈에 거슬림)
P4	`prefers-reduced-motion`이 실제로 다운그레이드되지 않음	해당 미디어 쿼리 분기를 grep	분기가 존재하고, 그 안에서 WebGL/무거운 애니메이션/깜빡임이 비활성화되어 있으며, 단순히 지속 시간만 단축한 것이 아님
P5	글꼴/JS를 참조했지만 파일이 물리적으로 없음	`ls` 산출물 디렉토리 `assets/fonts/` 및 `.js`	`@font-face`의 `src`, `<script src>`가 가리키는 파일이 물리적으로 존재함(단일 파일 전달 예외: 전달물에 `@font-face` 스니펫 + TTF 목록이 제공되었는지 확인); `interactive-editing.js`를 사용한 경우, 해당 파일도 존재하고 페이지가 CSS 변수를 완전히 사용 중이어야 함(그렇지 않으면 패널이 매개변수를 조정할 수 없음)(품질 게이트 6과 동시 검사, 여기서는 검증 동작)
P6	CDN 의존성에 폴백이 없어, 라이브러리가 없으면 흰 화면/커서 없음 발생	CDN `<script>`에 폴백 분기가 있는지 grep	주요 라이브러리 로드 실패 시 페이지를 여전히 읽을 수 있고, 커서가 사라지지 않음(시스템 커서 숨기기는 JS가 준비 상태를 확인한 후에만 가능)
P7	애니메이션이 GPU 속성이 아닌 것을 움직임	`transition`/`animation`/GSAP 속성을 grep	`transform`/`opacity`/`filter`(및 카메라 매개변수)만 움직이고, `width`/`top`/`left`는 없음
P8	모바일에서 다운그레이드되지 않음	중단점에서의 WebGL 스위치 확인	≤820px에서 무거운 WebGL 비활성화, CSS 3D 다운그레이드 사용
P9	AI-slop 글꼴과 충돌	`font-family` / `@font-face`를 grep	표시 글꼴이 Inter / Fraunces / Instrument Serif가 아님(이 세 가지는 남용되었으므로, anti-slop `MODE.md` 참조)
P10	애니메이션 속도 단계 초과 / 곡선 계열 위반	`grep -oE "transition:[^;][0-9]+m?s"` 및 `grep -oE "cubic-bezier\([^)]\)"`; `transition: all`이 나타나면 문제 기록	모든 지속 시간이 `motion-rules.md` §1의 4단계 내에 있고, 곡선 ⊆ §2의 4개 계열에 속하며, `all` 없음
P11	포커스가 보이지 않음 / 컨트롤 의미 체계 누락	Tab으로 한 번 이동(또는 헤드리스 `page.keyboard.press("Tab")` 후 스크린샷); grep `outline:none`, `role="dialog"`(`aria-modal` 필수), `<th`(`scope` 필수)	각 요소에 focus-visible(≥2px, 대비 3:1); 모달 창 포커스 트랩 + Esc; 테이블 헤더에 scope/caption 있음(WCAG 2.4.7 / 1.3.1)

침전 루프(게이트가 스스로 진화하도록 함): 엔지니어링 함정을 수정할 때마다, 그 자리에서 이를 한 줄의 검증 가능한 어설션으로 전환하여 이 표에 추가합니다(검증 방식 + PASS 임계값 명확히 기록). 단순히 '다음에는 주의'라고만 쓰지 마십시오. 판단 유형의 교훈은 품질 게이트에, 사실 유형의 교훈은 본 게이트에 기록합니다——분류가 잘못되면 이 규칙은 무효화됩니다.

알려진 한계(정직하게 표기): 본 게이트는 알려져 있고 검증 가능한 함정만 차단할 수 있으며, 취향 실패 및 새로운 함정은 차단할 수 없습니다. 취향은 품질 게이트 + 사람의 눈으로 검수합니다; 새로운 함정은 위의 침전 루프를 통해 점진적으로 편입합니다.

전달 후: 피드백 → 어느 단계로 돌아갈 것인가

이것은 폐쇄 루프의 가장자리입니다. 먼저 '어느 계층이 잘못되었는지'를 판단한 후, 몇 칸을 되돌릴지 결정하십시오——처음부터 다시 하는 것이 가장 비용이 많이 드는 방법입니다.

사용자 피드백	진짜 문제의 위치	돌아갈 단계
"내가 원하는 게 아니야 / 이해가 잘못됐어"	요구사항	① 재정렬
"평범해 / 너무 보수적이야 / 템플릿 같아"	방향 결정 부족	② 최고급 방향 재고정(4축 중 하나)
"구조가 엉망이야 / 어디를 봐야 할지 모르겠어"	정보 아키텍처와 내러티브	③ Intention Map 재작성
"어울리지 않아 / 각 부분이 한 세트가 아니야"	시스템 디자인(문법 불일치)	④ 디자인 문법 재구축
"그냥 안 예뻐"	시각적 실행	⑤ 글꼴/색/타이포그래피/소재 조정
"다시 해 / 다시 시작 / 리디자인 / 다른 안으로 바꿔줘"	명확히 새 버전 요청	완전히 처음부터 다시(아래 세 가지 하드 규칙 참조)

색상/글꼴/간격만 변경 → 단계로 돌아갈 필요 없이, 직접 수정하고 ④ 실행 게이트를 건너뜁니다(references/gates.md의 D조 참조).

여러 번의 미세 조정(동일 작업 연속): 첫 번째 전달 후 사용자가 '다시 조정해 줘 / 다른 느낌으로 바꿔 줘'라고 하면, 동일 작업의 연속에 해당합니다——해당 단계로 직접 진입합니다(색상 조정→⑤, 방향 변경→② 재고정), ①을 다시 거칠 필요도 CP1을 반복할 필요도 없습니다; 여러 번의 변경 사항을 통합한 후 한 번에 전달하여, 매번 재확인으로 사용자를 귀찮게 하는 것을 피합니다.

도중에 큰 방향 변경(③ 이후): 사용자가 '스타일을 바꿔 줘 / 방향이 잘못됐어'라고 말함 → ②로 돌아가 재고정(요구사항은 변하지 않고 방향만 잘못된 경우, ①로 돌아가지 않음); 이미 작성된 코드는 새 방향으로 리팩터링해야 하지, 수정(패치)해서는 안 됩니다, 잘못된 방향에서 계속 세부 사항을 쌓는 것을 금지합니다('방향이 너무 평범함'을 '시각적으로 안 예쁨'으로 착각하고 글꼴 크기를 조정하면, 열 번을 고쳐도 맞지 않습니다).

잘못 판단했을 때의 비용: '방향이 너무 평범함'을 '시각적으로 안 예쁨'으로 착각하고 글꼴 크기를 조정하면, 열 번을 고쳐도 맞지 않습니다——먼저 원인을 분석한 후, 작업을 시작하십시오.

재시작 vs 수정(세 가지 하드 규칙)

① 명시적으로 재시작 요청 → 반드시 완전히 새 버전으로, 외관만 바꾸는 것 금지 사용자가 '재시작 / 다시 시작 / 리디자인 / 다른 안으로 바꿔 줘'라고 말할 때:

반드시 새로운 시드를 다시 선택(제약 7), Intention Map을 다시 작성하고, 이전 버전의 코드 구조를 재사용하지 않음
전달 설명에 반드시 '이전 버전 문제 목록'을 포함: 이전 버전이 어떤 항목에서 잘못되었는지 → 본 버전에서 어떻게 방지했는지, 동일한 솔루션에 색상만 바꾼 것이 아님을 증명
판단 기준: 새 버전과 이전 버전의 '타이포그래피 패밀리 / 애니메이션 레이어 수 / 글꼴 역할' 세 항목 중 두 가지가 동일함 → 이번은 수정이지 재시작이 아니므로, 다시 해야 함

② '불합격'이지만 구체적으로 지적하지 않음 → 세 가지 중에서 선택하게 하고, 개방형 질문 금지 사용자가 '불합격 / 마음에 안 들어 / 안 돼'라고만 말할 때, '어떤 느낌을 원하세요?'라고 묻지 마십시오(사용자가 대답할 수 없음). 세 가지 옵션을 주어 지적하게 하십시오:

방향이 잘못됨(분위기가 틀림) → ②로 돌아가 시드 재고정
구조가 잘못됨(봐야 할 것을 볼 수 없음) → ③으로 돌아가 정보 아키텍처와 내러티브 재작성
실행이 부족함(방향은 맞지만, 세밀하게 하지 못함) → ⑤로 돌아가 shared/taste-rules.md §1의 6개 변수를 항목별로 조정

한 번에 이 질문 하나만 하십시오(제약 3). 사용자가 지적하면 해당 단계로 직접 진입합니다.

③ 수정 상한: 2라운드 최대, 초과 시 강제 재시작 동일 페이지의 수정이 누적 2라운드 후에도 여전히 '불합격' → 세 번째 수정은 금지하고, 반드시 재시작으로 업그레이드해야 함. 이유: 두 번의 수정으로도 해결되지 않았다면, 문제는 방향 또는 구조 계층에 있으며, 계속 시각적 요소를 조정하는 것은 소모적일 뿐입니다——'평범한 것을 안 예쁜 것으로 착각하고 열 번 수정'은 이미 기록된 실패 패턴입니다.

🛑 CHECKPOINT(해야 할 질문만 하기)

이 스킬은 기본적으로 방향을 묻지 않습니다(제약 1). 그러나 다음 5개 노드에서는 반드시 멈춰야 합니다. 그 외에는 중간에 보고하지 마십시오——잦은 중단은 또 다른 직무 유기입니다.

#	노드	멈추는 이유	사용자에게 무엇을 제공해야 하는가	해서는 안 되는 일
CP1	요구사항 해석 완료 후	이해 오류의 비용이 가장 높음	한 문장 재진술: 페이지 유형 + 대상 사용자 + 톤앤매너 + 세 가지 매개변수(또는 기본 8/6/5)	사용자에게 2–3개의 방향 중에서 선택하게 함(제약 1 위반)
CP2	최고급 방향 고정 후	방향이 잘못되면 이후 모두 허사	1개 방향의 구체적인 설명(≤3문장), '이 방향이 맞습니까?'라고 물음	전문 용어(글꼴 이름/색상 값)만 보고, 사용자가 이해할 수 없음
CP3	사용자가 변경 요청 시	한 번에 여러 군데 수정 = 원인 추적 불가	한 번에 한 가지 질문만 하고, 확인 후 다음 질문(제약 3)	한 번에 5가지 질문을 쏟아냄
CP4	전달 전	게이트를 통과하지 않으면 전달 불가	품질 게이트 7가지 + 엔지니어링 게이트 P1–P11의 검증 결과(어느 항목 PASS, 어느 항목 건너뛰었는지 및 이유)	구두로 '확인했습니다'라고 말하고 결과를 제공하지 않음
CP5	사용자가 '됐어요 / 괜찮아요'라고 말할 때	그만둬야 할 때	한 문장 마무리 + 부족한 점(있는 경우)	계속 덧붙이거나, 스스로 다음 최적화 라운드를 시작함

위반 신호(자체 점검): 3단계 연속으로 사용자 입력이 한 번도 없고, CP1/CP2에서 멈춘 적이 없음 —— 사용자를 대신해 결정을 내리고 있음을 의미하므로, CP1으로 되돌아갑니다.

체크포인트가 아닌 것(물으면 오히려 나쁨): 어떤 글꼴을 선택할지, 어떤 색상 값을 사용할지, 섹션을 몇 개나 넣을지, 어떤 애니메이션 컴포넌트를 사용할지 —— 이것들은 당신의 판단이지, 사용자의 업무가 아닙니다.

사용자 의도 라우팅

사용자가 말하는 것	시작점	설명
"페이지/컴포넌트를 작성해 줘"(요구사항 명확)	① 요구사항 해석 → ② 방향 고정 → ③ Intention Map → ④ 시스템 디자인 → 전달	brief는 사용자의 명확한 요구사항을 기준으로 함; 일반 제약(제약 8 포함)은 사용자가 지정하지 않은 차원에 대해서만 적용되며, 명시적 지시를 덮어쓰지 않음(제약 0)
「빨리 결과물 원해」「기존 테마 써 줘」「테마/스타일 변경」	테마 빠른 라인: `assets/themes/README.md` 빠른 참조 표(명암→시나리오→강조색 3단계)에서 1개 선택 → 해당 `:root` 변수 복사 → 브랜드에 맞게 `--accent` 미세 조정 → 전달	사용자가 능동적으로 요청하거나 명시적으로 시간이 부족하다고 할 때만 이 라인 사용; 이 경우 제약 6을 명시적으로 면제(제약 0 근거: 사용자 지시 > 일반 기본값). 전달 시 어떤 테마를 사용했는지, 어떤 변수를 변경했는지 명시. 플래그십 작업은 기본적으로 이 라인을 사용하지 않음
"랜딩 페이지 디자인 좀 도와줘"(방향 탐색 필요)	①② 이후 바로 최고급 방향 고정 후 계속	사용자에게 방향 확인을 요구하지 않음
"이 페이지 스타일 좀 고쳐 줘"(이미 코드 있음)	⑤ 시각적 디자인부터 시작	진단 + 최소한의 수정; 애니메이션 추가/교체 시 '부분 Intention Map 동기 테이블'(변경된 섹션만 커버) 보충 필요; 순수 색상/글꼴/간격 수정은 ④ 실행 게이트 면제(`references/gates.md`의 D조 참조)
"어떤 스타일로 할지 모르겠어"	①②에서 바로 최고급 방향 솔루션 제시	2–3개의 평행 방향을 나열하여 사용자가 선택하게 하지 않음(제약 1)
"브랜드 디자인 해 줘" / "포스터 만들어 줘"	해당 영역 파일 로드	브랜드 → `domains/brand/MODE.md`; 포스터 → `domains/poster/MODE.md`
"배경 비디오 추가해 줘 / hero에 비디오 넣어 줘"	`domains/video/MODE.md` 로드	먼저 §1 통과(비디오가 반드시 필요한가) → §2 역할 및 볼륨 상한 → §4 퓨전 → §9 V1–V9 점검
"백엔드 / 관리자 페이지 / 데이터 대시보드 만들어 줘"	먼저 뼈대와 테이블을 결정하고, 대시보드부터 만들지 않음	`design-patterns.md` §6.4 전달 순서: 뼈대 → 테이블 필터 → 폼 모달 → 대시보드
확실하지 않음	사용자에게 물음	처음부터 디자인 / 기존 수정 / 스타일 제안 필요

영역별 빠른 참조

도구 클래스(리뷰 / 리디자인 / 씽킹 / 슬라이드 / 비디오 내보내기)의 개요 및 선택은 tools/README.md를 참조하세요.

영역	트리거 단어	로드 경로
Web 페이지	landing page / 공식 사이트 / 마케팅 페이지	`domains/web/distilled-playbook.md`(추론 계층, 먼저 읽음) + `domains/web/anti-slop/MODE.md`(반-AI 기준선); `domains/web/integrated-rules.md`(규칙 인덱스 → shared/) + `domains/web/common-exceptions.md`(예외 판결); 정확한 값은 `shared/` 참조, CSS는 `domains/web/design-patterns.md` / `shared/css-patterns.md` 참조
백엔드 / 관리자 페이지	백엔드 / 관리자 페이지 / dashboard / 데이터 대시보드 / CRM	`domains/web/design-patterns.md` §4 컨트롤 사양 + §6 백엔드 인터페이스(뼈대/4가지 템플릿/밀도) + `domains/web/integrated-rules.md` §4 토큰 계약 + `shared/interaction-rules.md` §7 키보드 효율
브랜드 디자인	Logo / 브랜드 보드 / 브랜드 디자인	`domains/brand/MODE.md` + `domains/brand/brand-protocol.md` + `domains/brand/logo-concept-methods.md` + `domains/brand/visual-modes.md`
포스터 디자인	포스터 / poster / 홍보 이미지 / 전시대	`domains/poster/MODE.md`(먼저 크기 결정 §1 → 주장 결정 → 패밀리 선택 §3 → 3계층 배치 §4)
Web 내장 비디오	배경 비디오 / hero 비디오 / 제품 데모 비디오 / 스크롤 비디오	`domains/video/MODE.md`(먼저 §1 판단: 비디오를 사용해야 하는가 → §2 역할 → §3 경로 → §4 퓨전 → §9 전달 점검)
디자인 리뷰	review / critique / 리뷰	`tools/critique.md`

...

[내용 생략됨 - 번역을 위해 잘림]

zh110/统一设计-unified-design-z

统一设计-unified-design-z란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서