feat: strengthen design skill and refresh all showcases

packages/skill/CHANGELOG.md

@@ -1,5 +1,11 @@
 # CHANGELOG
 
+## 0.12.0
+
+### Minor Changes
+
+- 시각 디자인 원전과 인지 연구를 적용 질문·한계와 함께 연결하고, 실제 재료로 구도·타입·색을 판단하는 절차를 추가했다. 구조 대안·기각 조건은 `design.md`에 기록하며, 규범·기능 검사와 시각·과업 판정은 별도로 보고한다.
+
 ## 0.11.0
 
 ### Minor Changes

packages/skill/SKILL.md

@@ -54,6 +54,8 @@ description: "웹 디자인 전 과정을 끌고 가는 파이프라인 스킬.
 
 | 판단 질문 | 읽을 문서 | 꺼내 쓸 항목 / 남길 결정 |
 |---|---|---|
+| 바우하우스·타이포그래피 대가의 관점을 이 화면에 어떻게 적용하는가? | `references/visual-design-lineage.md` | 원전·기관 해설의 확인 범위, 서로 다른 관점, 현재 매체·언어에 맞는 적용 질문 |
+| 미적 호감·복잡성·읽기·정보표현에 실험 근거가 있는가? | `references/visual-perception-research.md` | 논문의 과업·측정 대상·표본 한계, 선호와 실제 성능의 구분 |
 | 무엇을 먼저 보이게 하고, 어떤 구도·이미지·크롭이 과업을 돕는가? | `references/art-direction.md` | 콘텐츠 우선순위, 시선·여백·이미지 역할, 크롭 비교와 선택 이유 |
 | 이 원칙이 보편 규범인가, 특정 사례·실무 지침인가? | `references/design-foundations.md` + `references/evidence-ledger.md` | 주장 종류(원론·규범·실무·사례·전망·서지), 출처의 조건과 적용 여부 |
 | 이 브리프에 맞는 시각 언어와 피해야 할 관습은 무엇인가? | `references/style-playbook.md` | 스타일의 표현 수단·주의점, 브리프에 맞춘 변형 |
@@ -228,6 +230,8 @@ headed 브라우저가 있으면 스크린샷과 실측값을 바로 받는다
 
 이 단계에서 `references/style-playbook.md`를 읽어 선택한 스타일의 표현 수단·주의점·적용 조건을 검토한다. 이론이나 스타일 이름은 결론이 아니므로, `design.md` 또는 프로젝트 evidence 기록에 출처 ID → 원칙/조건 → 관찰 → 결정 → 검증 계획을 남긴다.
 
+새 방향이면 [art-direction.md](references/art-direction.md) §3의 **구도·타입·색 결정표**를 실제 재료로 세 축 모두 채운다. 국소 변경이면 영향받는 축만 채운다. 표의 관찰 → 가능한 원리 → 작은 대안 → 채택 근거/기각 조건 → 역할 토큰 기록을 이 단계의 결정 근거로 쓴다.
+
 정해야 할 것:
 - **한 문장 컨셉** — 이 사이트가 주는 인상을 한 문장으로. ("고급 잡지의 여백", "계기판처럼 정확한", "밤의 스튜디오")
 - **미학 프리셋** — 아래에서 고르거나, 브리프가 요구하면 새로 정의한다
@@ -257,6 +261,8 @@ headed 브라우저가 있으면 스크린샷과 실측값을 바로 받는다
 - **폰트를 고르고 싣는 법** → `references/typography.md`. 폰트는 값이 아니라 결정이다. 로딩·폴백 메트릭·라이선스가 여기 있다
 - 한글이 들어가면 → `references/antipatterns.md` 의 한글 조판 섹션을 **반드시** 읽어라. 서구 레퍼런스에는 이 정보가 없다
 
+2단계에서 비교한 실제 렌더를 초기값으로 삼아 역할 토큰을 확정한다. 숫자·색상값·서체 이름만 모으지 말고, 각 토큰이 어떤 정보 역할과 좁은 폭·상태에서의 관찰을 해결하는지 기록한다.
+
 **성능 예산도 여기서 정한다.** 나중에 정하면 이미 늦는다. 전체 표는 `references/tokens.md` §5 하나뿐이다 — 다른 문서에 예산 표를 만들지 마라.
 
 기본선: 히어로까지 JS **150KB(gzip)** / 첫 인터랙션 **3초**. `transform`·`opacity`는 저비용 기본 선택이다. 다른 속성 또는 스크롤 기반 로직은 자동 금지가 아니라, 측정한 비용·입력 간섭·감소 모션 경로·프로젝트 예산을 기록하고 실제 기기/브라우저에서 검증한다.
@@ -321,6 +327,8 @@ HTML-in-Canvas(`drawElementImage`)는 **폴백을 완성한 뒤에만** 얹는
 5. **상태 완결성 스윕** — 입력·파괴·열림이 있는 화면은 실제로 조작해 본다: 수치 입력에 범위 밖 값을 넣고, 파괴적 행동을 되돌려보고, 열린 메뉴를 Esc 로 닫는다. 기준은 `references/preflight.md` §4-1. 통과 못 하면 4단계로
 6. **상태별 시각 E2E** — URL별 390·1440 기본 화면과 결과·오류·모달 같은 핵심 상태를 캡처한다. 하니스는 개수·규격·0바이트·중복 해시를 단언하고, 캡처를 실제로 열어 목표 시장 적합성·시선 위계·이미지 크롭·반복을 눈으로 판정한다. 구조 PASS를 시각 PASS로 바꾸어 말하지 않는다
 
+전후 증거는 같은 viewport·상태·카피·자산으로 보존한다. [art-direction.md](references/art-direction.md) §7처럼 질서·표현성·완성도를 각각 강점·문제·스크린샷 근거로 판정하고, 대표 실제 과업 시나리오로 회귀를 확인한다. 참여자 측정이 없으면 사용자 속도·이해도·전환은 미측정으로 남긴다.
+
 > 게이트가 잡은 실제 사고 목록과 7계층 설계 근거는 `references/audit-gate.md` 다. 자기 검사 스크립트를 매번 새로 쓰지 마라 — 이 게이트를 심고 확장해라.
 
 #### 규범·기능 하드 게이트 — 전부 충족해야 한다

packages/skill/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@designpaca/skill",
-  "version": "0.11.0",
+  "version": "0.12.0",
   "private": true,
   "description": "designpaca 스킬 원본 — SKILL.md 와 참조 문서",
   "scripts": {

packages/skill/references/art-direction.md

@@ -55,6 +55,14 @@
 색만 바꾼 안은 별도 구조안이 아니다. 사진 위 텍스트는 대비만 보지 말고, 피사체·캡션·행동이 같은 의미를 말하는지 확인한다.
 수치·상태·가격·주소처럼 수정 가능하고 사실 검증이 필요한 정보는 이미지 안에 굽지 않는다.
 
+### 3-1. 구도·타입·색 결정표
+
+| 결정 축·관점 | 실제 재료와 렌더 확인 | 기록 한 행 예시 |
+|---|---|---|
+| 구도 — [Arnheim·Hofmann](visual-design-lineage.md) | 큰 면·정렬·군집이 주정보를 어떻게 지지하는지 실제 콘텐츠, 좁은 폭, 회색조 경계에서 본다. 이유 없는 비대칭이나 여백을 자동으로 선호하지 않는다. | 관찰: 제목과 증거가 경쟁함 → 원리 후보: 면적·군집 → 작은 대안: 증거를 제목 아래로 이동 → 채택: 좁은 폭과 회색조에서도 순서가 유지됨 / 기각: 증거 맥락이 사라짐 → 역할 토큰: `surface.evidence` |
+| 타입 — [Warde·Ruder](visual-design-lineage.md), [Wallace](visual-perception-research.md) | display의 표현과 본문의 읽기 역할을 나누고, 실제 한글·숫자·긴 라벨을 proof 한다. 서체 비교 때 크기·폭·행간 차이는 고정하거나 기록한다. 같은 CSS px가 같은 광학 크기는 아니며 원인이 불명확하면 속도 효과를 주장하지 않는다. | 관찰: 긴 한국어 상태가 버튼을 밀어냄 → 원리 후보: 폭·행간·계층 → 작은 대안: 본문 폭과 보조 계층 조정 → 채택: 실제 상태에서 줄바꿈과 조작이 유지됨 / 기각: 숫자 열 비교가 흐려짐 → 역할 토큰: `type.status` |
+| 색 — [Albers](visual-design-lineage.md) | 같은 전경색을 배경·면적·상태 조합에 놓고 역할 구분과 실제 대비를 함께 확인한다. 채도나 색 수를 일률적으로 정하지 않는다. | 관찰: 비활성 상태가 사진 위에서 활성과 섞임 → 원리 후보: 맥락색·상태 역할 → 작은 대안: 상태 surface와 전경 조합 변경 → 채택: 실제 합성에서 구분·대비가 유지됨 / 기각: 경고 역할과 충돌함 → 역할 토큰: `color.state.disabled` |
+
 ## 4. 이미지는 원본과 배포 크롭을 함께 검토한다
 
 이미지의 품질은 원본 파일만으로 판정하지 않는다. 원본, 데스크톱 배포 크롭, 모바일 배포 크롭을 나란히 놓고 슬롯별로 아래를 기록한다.
@@ -95,10 +103,14 @@ proof sheet는 멋의 순위를 매기는 카드가 아니라, 이 프로젝트
 
 리듬을 바꾸는 이유는 새 배경색이나 카드 모양이 아니라 독자의 질문과 과업이 바뀌었기 때문이다.
 
-## 7. 실제 화면에서 한 번에 하나씩 비평한다
+## 7. 실제 화면에서 비평한다
 
 소스 코드나 모형을 보고 완성도를 선언하지 않는다. 같은 viewport, 상태, 카피, 자산에서 전후 렌더를 비교한다.
 
+실험적으로 원인을 추적할 때만 한 번에 한 원인 가설을 바꾼다. 전체 리디자인은 여러 변경을 함께 묶을 수 있지만, 그 결과만으로 각 변경의 인과를 분리할 수는 없다.
+
+원인추적 경로일 때만 아래 순서로 진행한다.
+
 1. **관찰**: 무엇이 먼저 읽히는지, 어디에서 시선·행동·관계가 끊기는지 적는다.
 2. **원인 후보**: 구도, 카피 길이, 크롭, 위계, 상태 밀도 중 가능한 원인을 좁힌다.
 3. **한 가지 수정**: 한 번에는 한 원인 가설만 바꾼다.
@@ -106,14 +118,15 @@ proof sheet는 멋의 순위를 매기는 카드가 아니라, 이 프로젝트
 
 비평은 아래 세 관점에서 따로 적는다.
 
-| 관점 | 확인 질문 | 주장하지 말 것 |
+| 관점 | 강점·문제와 스크린샷 근거 | 주장하지 말 것 |
 |---|---|---|
-| 독창성 | 이 브랜드·과업·자산에서만 나올 이유가 보이는가 | 낯선 효과 하나가 고유성을 증명한다 |
-| 완성도 | 정렬, 타입, 크롭, 여백, 상태가 같은 규칙으로 끝까지 유지되는가 | 자동 심미 점수가 품질을 증명한다 |
-| 과업 | 사용자가 다음 정보와 행동을 예측·완료·복구할 수 있는가 | 시각 점수만으로 성공률이나 전환 인과를 증명한다 |
+| 질서 | 정렬·타입·크롭·여백·상태가 주정보를 지지한 강점과 끊긴 문제를 같은 조건의 캡처에 표시한다 | 100점식 임의 순위가 품질을 증명한다 |
+| 표현성 | 이 브랜드·과업·자산에서만 나올 이유와 과장·혼동 문제를 캡처로 적는다 | 낯선 효과 하나가 고유성을 증명한다 |
+| 완성도 | 반복 규칙과 예외 처리가 끝까지 유지된 강점·문제를 캡처로 적는다 | 자동 심미 점수가 품질을 증명한다 |
 
 완료 판정은 세 갈래로 분리한다: 사용성·접근성 규범, 프로젝트의 기능·성능 계약, 시각 평가.
 한 갈래의 통과가 다른 갈래의 통과를 대신하지 않는다.
+대표 실제 과업 시나리오로 회귀를 확인한다. 참여자 측정이 없으면 사용자 속도·이해도·전환은 미측정이며, 시각 판정으로 이를 주장하지 않는다.
 
 ## 8. 같은 규칙도 화면에 따라 다르게 쓴다
 

packages/skill/references/evidence-ledger.md

@@ -50,6 +50,8 @@
 
 ## 교과서 입문·정독 범위
 
+바우하우스·시각디자인 원전의 관점과 확인 범위는 [visual-design-lineage.md](visual-design-lineage.md), 미학·읽기·그래픽 지각 논문의 연구 조건은 [visual-perception-research.md](visual-perception-research.md)에서 질문에 맞는 항목만 읽는다. 두 문서는 출처별 확인 범위와 적용 한계를 보존하는 이 장부의 심화 읽기 경로다. 실무 적용 제안과 원문이 보고한 결과를 구분한다.
+
 다음은 **서지 확인된 읽기 경로**다. 이 목록은 본문을 읽었다거나 특정 페이지의 규칙을 채택했다는 주장이 아니다. 입문에서는 편집·그리드·글자 형태의 어휘를 얻고, 실제 프로젝트에 인용할 때는 확보한 판본과 페이지를 다시 기록한다.
 
 1. Bringhurst, *The Elements of Typographic Style* — 조판 어휘와 본문 리듬의 정독 출발점 [BRINGHURST].

packages/skill/references/images.md

@@ -90,15 +90,15 @@ printf '%s' "\$imagegen $PROMPT" \
 [개별] Overhead flat-lay on a worn wooden workbench: cut stems, florist shears, twine.
 ```
 
-- **3단계에서 정한 배경색을 프롬프트에 그대로 넣어라.** 사진이 페이지 배경과 이어진다
-- 크기는 양변 16의 배수: `1152x1536`(3:4) · `1536x1152`(4:3) · `2048x1152`(16:9)
+- 사진과 페이지 표면의 연결이 필요하면 3단계 배경색·재질을 프롬프트에 넣고, 자산의 실제 맥락이 더 중요하면 그 맥락을 우선한다
+- 크기·비율은 슬롯의 배포 크롭과 생성 모델의 지원 범위를 근거로 정한다. `1152x1536`(3:4) · `1536x1152`(4:3) · `2048x1152`(16:9)는 지원될 때의 예시다
 - 사람 얼굴은 피하는 쪽이 안전하다. 손·뒷모습·부분은 잘 나오고 얼굴은 어색해지기 쉽다
 - `No text` 를 넣어라. 넣지 않으면 간판·라벨에 뭉개진 글자가 생긴다
 
 ### 생성물은 반드시 눈으로 본다
 
 `Read` 로 열어 확인한 뒤에만 쓴다. 특히 **공간 사진**(작업실·매장)이 어색해지기 쉽다.
-주제가 안 맞으면 프롬프트를 **한 번에 한 가지만** 바꿔 다시 만든다.
+원인을 분리하려는 비교에서는 프롬프트를 한 번에 한 가지씩 바꾼다. 전체 방향이 맞지 않으면 관련 요소를 함께 고칠 수 있지만, 그 결과로 각 변경의 인과를 분리해 주장하지 않는다.
 
 ### 여러 화면이면 이미지 바이블부터 만든다
 

packages/skill/references/layout.md

@@ -6,7 +6,7 @@
 
 ## 1. 그리드를 먼저 정한다
 
-### 하나의 그리드에서 모든 것이 나온다
+### 공통 정렬선과 역할별 폭
 
 ```css
 .page {
@@ -23,15 +23,14 @@
 .page > .full { grid-column: full; }
 ```
 
-**`main` 폭에 고정값을 쓰지 마라.** `--measure` 는 3단계에서 언어와 폰트에 맞춰 정한 값이다.
-여기에 60rem 같은 숫자를 넣으면 본문이 measure 를 넘어가 이 문서의 통과 조건을 스스로 어긴다.
+`main`의 읽기 폭은 3단계에서 언어와 폰트에 맞춰 정한 `--measure` 토큰으로 둔다. `60rem` 같은 값이 그 본문 조건을 넘으면 대표 문단의 줄 길이와 확대 상태에서 다시 검증한다. `wide`·표·작업대는 별도 역할 토큰과 실제 사용 장면으로 검증한다.
 `ch`는 선택한 글꼴의 메트릭에 의존한다. 한글과 라틴의 실제 줄 길이는 글꼴·언어·내용으로 달라지므로, 예시 폭을 보편 수치로 쓰지 말고 대표 문단을 렌더해 확인한다.
 
-이 한 번의 정의로 **본문 폭 · 넓은 블록 · 전체 폭**이 전부 정렬된다. 섹션마다 `max-width` 와 `padding` 을 다시 쓰면 반드시 어긋난다.
+이 공통 레일은 **본문 폭 · 넓은 블록 · 전체 폭**의 정렬 기준이다. 본문 읽기 폭, 증거·표, 작업대는 역할별 컨테이너 토큰(`--measure`, `--container-wide`, `--workbench-wide`)을 써도 된다. 각 역할의 폭·padding을 토큰으로 이름 붙이고 공통 레일과의 관계를 렌더에서 확인한다.
 
 ### 비대칭을 두려워하지 마라
 
-12열 중앙 정렬은 안전하고 잊힌다. 실제로 기억되는 레이아웃은 **의도적으로 한쪽으로 몰려 있다**. 다만 비대칭에도 규칙이 있어야 한다 — 아무 데나 놓는 것은 비대칭이 아니라 사고다.
+중앙 정렬과 비대칭은 모두 선택지다. 초점, 균형, 내용 군집, 작은 폭에서의 읽기를 실제 콘텐츠로 비교해 고른다. 비대칭에도 규칙이 있어야 한다 — 아무 데나 놓는 것은 비대칭이 아니라 사고다.
 
 - 텍스트 블록을 그리드의 2/3 지점에서 끊고 나머지를 비워두기
 - 이미지를 화면 밖으로 흘려보내기(`full` 을 넘어 `margin-inline: calc(var(--space-4) * -1)`)
@@ -52,7 +51,7 @@
 
 1. 첫 화면이 대표 과업에 필요한 정체성·가치·다음 행동을 충분히 설명하는지 확인한다. 세 요소는 흔한 점검 틀이지 모든 화면의 최대 항목 수가 아니다
 2. 위계는 크기·굵기·색·여백·위치의 조합으로 만든다. 어떤 두 변수를 반드시 바꿔야 한다는 공식보다, 회색조와 실제 콘텐츠에서 우선순위가 읽히는지를 본다
-3. **시선을 한 번은 멈춰라** — 전부 같은 리듬으로 흐르면 아무것도 강조되지 않는다. 섹션 하나는 리듬을 깨야 한다
+3. 강조하거나 역할을 전환해야 할 때는 리듬·크기·여백·색의 차이로 시선을 머물게 할 수 있다. 모든 섹션의 리듬을 일부러 깨야 하는 것은 아니다
 4. 스크롤 뒤에도 새 정보나 과업 진전이 있는지 확인한다. 반복 카드가 이탈을 만든다는 보편 증거는 없으므로, 실제 콘텐츠와 사용자 행동으로 판단한다
 
 ### 의미가 다르면 섹션 토폴로지도 달라야 한다

packages/skill/references/motion.md

@@ -27,6 +27,8 @@
 | **피드백** | "내 입력이 접수됐나?" | 프레스, 토글, 검증 실패 |
 | **주의** | "지금 어디를 봐야 하나?" | 오류 필드로의 이동 |
 
+모든 인터랙션에는 입력 결과를 알 수 있는 피드백이 필요하다. 다만 모션은 상태 변화의 이해를 도울 때만 쓰며, 즉시 바뀌는 값·텍스트·포커스도 피드백이 될 수 있다.
+
 다섯 번째 **"멋있어서"는 이유가 아니다.** 예외는 브랜드 표현이 브리프의 명시적 요구일 때뿐이고, 그때도 (a) 사용자가 스크롤·호버로 통제하거나 (b) 1회성이며 (c) `prefers-reduced-motion`에서 완전히 사라져야 한다.
 
 **넣지 말아야 할 곳**: 고빈도 반복 작업(폼·표·필터) · 오류 복구 경로 · 결과가 이미 예측되는 전환(탭) · **첫 화면**(콘텐츠는 즉시 읽혀야 한다) · 숫자가 계속 바뀌는 곳.
@@ -38,7 +40,7 @@
 | 애니메이션 때문에 콘텐츠가 **읽히기까지 지연**됨 | 첫 화면은 모션 없이 즉시 표시. 리빌은 스크롤 이후 |
 | 스크롤 리빌이 위아래로 오갈 때 **매번 재생** | `both` / `once` / `unobserve()` |
 | 애니메이션 중 **레이아웃 시프트** | 레이아웃·입력·CLS를 실제로 측정하고 프로젝트 예산과 비교 |
-| **동시에 3개 이상** 독립 애니메이션 | 시선이 분산된다. 순차화하거나 통합 |
+| 독립 애니메이션이 대표 과업의 시선·입력을 분산시킴 | 실제 과업에서 동시성·입력 지연을 확인하고 순차화·통합·정지 중 선택 |
 | 400ms 넘게 **사용자를 막는** 전환, 인터럽트 불가 | 줄이고, 애니메이션 중에도 입력을 받아라 |
 | 무한 반복되는 **큰 면적** 움직임 | 전정기관 자극. 정지 수단을 주거나 제거 |
 | 이징이 전부 `ease`·`linear`거나, 진입과 퇴장 duration이 같음 | 방향을 구분하지 않았다. §1로 |
@@ -75,7 +77,7 @@
 :root { --stagger: 60ms; --shift-sm: 8px; --shift-lg: 24px; }
 ```
 
-**stagger 상한**: `(항목수 − 1) × --stagger + duration ≤ 800ms`. 넘으면 `--stagger`를 줄이거나 첫 화면 항목에만 건다. 12개를 넘으면 stagger를 쓰지 않는다. 방향은 읽기 방향(좌→우, 상→하)과 일치시킨다.
+**stagger 시작값 예시**: 이 프로젝트에서는 `(항목수 − 1) × --stagger + duration ≤ 800ms`, 12개 이하를 초기 예산으로 둘 수 있다. 목적·입력 지연·전체 소요·감소 모션에 맞춰 계약을 정하고 실제 렌더에서 확인한다. 방향은 읽기 방향(좌→우, 상→하)과 일치시킨다.
 
 ---
 
@@ -83,30 +85,30 @@
 
 **`transform`/`opacity`는 저비용 기본 선택이다.** 다른 속성의 애니메이션은 자동 실패가 아니다. 다만 비용·CLS·입력 간섭·감소 모션·지원 범위를 측정해 프로젝트 예산과 비교하고, 목적이 더 단순한 정적 상태로 충족되는지도 먼저 검토한다.
 
-| 하고 싶은 것 | 하지 마라 | 대신 |
-|---|---|---|
-| 배경색이 바뀐다 | `transition: background-color` | 목표 색을 칠한 `::before`를 깔고 그 **`opacity`** 전환 |
-| 그림자가 짙어진다 | `transition: box-shadow` | 짙은 그림자를 가진 `::after`를 미리 만들고 **`opacity`** 전환. 그림자 재계산이 사라져 더 빠르다 |
-| 테두리가 나타난다 | `transition: border-color` | `::after`에 `border`를 두고 **`opacity`** 전환. 레이아웃도 안 흔들린다 |
-| 글자색이 바뀐다 | `transition: color` | 전환하지 말고 즉시 바꿔라. 100ms짜리 색 변화는 아무도 못 본다 |
-| 진행 바가 찬다 | `transition: width` | `transform-origin: left` + **`scaleX()`** |
-| 이미지가 흐려진다 | `transition: filter` | 선명본과 미리 블러된 사본을 겹치고 **`opacity`** 크로스페이드 |
-| 그라디언트가 회전한다 | `@property`로 각도 애니메이션 | 원뿔 그라디언트 레이어를 **`rotate`** |
-| 마스크가 열린다 | `transition: clip-path` | `overflow: hidden` 래퍼 안에서 자식을 **`translate`** |
-| 숫자가 올라간다 | `@property --count` | 자릿수 스트립을 **`translate`** (§3 코드 G) |
-| 패널 높이가 자란다 | `transition: height`·`max-height` | 아래 |
+| 비용을 확인할 선택 | 저비용 대안 |
+|---|---|
+| 배경색 전환 | 목표 색을 칠한 `::before`의 **`opacity`** 전환 |
+| 그림자 전환 | 짙은 그림자를 가진 `::after`의 **`opacity`** 전환 |
+| 테두리 전환 | `::after`의 `border`와 **`opacity`** 전환 |
+| 글자색 전환 | 즉시 변경 또는 목적·입력 간섭·프레임 비용을 기록한 전환 |
+| 진행 바 너비 전환 | `transform-origin: left` + **`scaleX()`** |
+| 이미지 `filter` 전환 | 선명본과 미리 블러된 사본의 **`opacity`** 크로스페이드 |
+| 그라디언트 각도 전환 | 원뿔 그라디언트 레이어의 **`rotate`** |
+| `clip-path` 전환 | `overflow: hidden` 래퍼 안 자식의 **`translate`** |
+| 숫자 속성 전환 | 자릿수 스트립의 **`translate`** (§3 코드 G) |
+| 패널 `height`·`max-height` 전환 | 아래 대안과 비교한 뒤 측정·계약 근거를 기록 |
 
-**높이.** `transition: height`는 매 프레임 레이아웃을 돌리고 형제를 밀어 CLS를 만든다. 순서대로 시도해라.
+**높이.** `transition: height`는 매 프레임 레이아웃 비용을 낸다. 구조에 따라 형제의 시각 이동·입력 간섭이 생길 수 있으므로, 실제 상태와 프로젝트 예산에서 확인한다. 순서대로 검토해라.
 
 1. **구조를 바꾼다.** 정말 인라인으로 자라야 하는가? 모달·팝오버로 만들면 높이 문제가 사라지고 스케일+페이드로 끝난다
-2. **높이는 즉시 확정하고 내용만 전환한다.** 래퍼를 `display: grid; grid-template-rows: 0fr` ↔ `1fr`로 만들되 **`grid-template-rows`에 transition을 걸지 않는다.** 자식의 `opacity`·`translate`만 전환하면 게이트를 완전히 통과한다
-3. `grid-template-rows`에 transition을 거는 관용구가 널리 쓰이지만 **그건 여전히 레이아웃 애니메이션이고 게이트 #8 grep에 걸린다.** `max-height`보다 정확할 뿐 합성 가능하지는 않다. 굳이 쓰겠다면 `design.md`에 예외로 적어라
+2. **높이는 즉시 확정하고 내용만 전환한다.** 래퍼를 `display: grid; grid-template-rows: 0fr` ↔ `1fr`로 만들고 자식의 `opacity`·`translate`를 전환하는 방식을 먼저 비교한다. 실제 레이아웃 이동과 입력 간섭을 확인한다
+3. `grid-template-rows` 전환은 레이아웃 비용이 생길 수 있다. 필요하면 다른 대안과 비교하고 비용·입력 간섭·감소 모션·예산을 실제로 측정해 `design.md`에 근거를 남긴다
 
-**오해 방지 — 게이트 #8이 허용하는 것**
+**도구 한계와 저비용 선택**
 
-- `translate` / `rotate` / `scale` **개별 속성은 transform 계열이다. 통과다.** 축약형보다 낫다(속성끼리 안 덮어쓴다)
-- `display`·`overlay`를 `transition-behavior: allow-discrete`로 거는 것은 **통과다.** 보간되지 않고 전환 종료까지 값을 유지시킬 뿐이라 프레임당 계산이 없다. 예외는 이 둘뿐이다
-- View Transitions의 기본 애니메이션은 브라우저가 만든다. **저자 키프레임은 `opacity`와 transform 계열만** 쓴다
+- `translate` / `rotate` / `scale`은 transform 계열인 저비용 기본 선택이다. 축약형보다 속성 충돌을 줄일 수 있다
+- `display`·`overlay`의 `transition-behavior: allow-discrete`는 보간하지 않는 선택지다. 다른 속성도 자동 금지가 아니며, 정적 게이트 검출은 측정·계약 검토가 필요한 후보를 알릴 뿐이다
+- View Transitions의 저자 키프레임은 `opacity`와 transform 계열을 먼저 검토한다. 다른 속성은 목적·비용·입력 간섭·감소 모션·예산을 실제로 확인한 근거가 있을 때만 채택한다
 
 ---
 
@@ -126,7 +128,7 @@
 
 ### 코드 A — 버튼·링크 마이크로 인터랙션
 
-> 언제: 모든 인터랙티브 요소. 선택이 아니라 기본이다. 색과 그림자를 전부 `opacity`로 바꾼 것이 요점이다.
+> 언제: 움직임이 입력 피드백이나 상태 변화를 더 분명하게 할 때. 모든 인터랙션에는 피드백이 필요하지만 모션 자체가 필수는 아니다. 색과 그림자를 `opacity`로 바꾼 것은 저비용 대안의 예다.
 
 ```css
 .btn {
@@ -295,7 +297,7 @@ filterBtn.addEventListener('click', () => transition(() => renderList(filterBtn.
 ```
 
 ```css
-/* 저자 키프레임은 opacity와 transform 계열만 쓴다. 위치·크기 보간은 브라우저가 한다 */
+/* 저자 키프레임은 저비용 기본 선택을 쓴다. 위치·크기 보간은 브라우저가 한다 */
 ::view-transition-group(*) { animation-duration: var(--dur-slow); animation-timing-function: var(--ease-soft); }
 ::view-transition-old(root) { animation: calc(var(--dur-slow) * 0.65) var(--ease-in) both vt-out; }
 ::view-transition-new(root) { animation: var(--dur-slow) var(--ease-out) both vt-in; }
@@ -719,11 +721,11 @@ const progress = clamp01((start - rect.top) / travel);
 
 **반대**: 스크롤은 사용자가 기대하는 기기 고유의 물리다. 바꾸는 건 시스템 관습 침해다. 관성이 붙으면 **정확한 위치에 멈추기 어렵고** 운동 장애가 있는 사용자에게 치명적이다. 지연은 모든 사용자에게 인지 비용이다.
 
-**찬성**: Lenis는 구식 스크롤 재킹이 아니다. **네이티브 `scrollTop`을 이징할 뿐**이라 스크롤바·앵커·`position: sticky`·스크린리더 탐색이 그대로 작동한다. WebGL↔DOM 동기화는 스크롤을 메인 스레드에서 통제해야만 드리프트가 사라진다.
+**찬성**: Lenis는 구식 스크롤 재킹과 다른 구현을 목표로 한다. 버전·통합 방식에 따라 스크롤바·앵커·`position: sticky`·스크린리더 탐색에 미치는 결과를 실제로 검증해야 한다. WebGL↔DOM 동기화에 도움이 될 수 있으나, 그 효과는 프로젝트에서 측정한다.
 
-**판단**: 대시보드·관리도구·문서·커머스·폼 → **쓰지 않는다**(`scroll-behavior: smooth`로 충분). 콘텐츠 사이트·블로그·뉴스 → **쓰지 않는다**(읽기를 방해한다). 브랜드 랜딩·포트폴리오·캠페인 → 조건 충족 시 쓸 수 있다. WebGL↔DOM 동기화 → 사실상 필수.
+**판단**: 기본은 네이티브 스크롤이다. 브랜드 표현이나 WebGL↔DOM 동기화처럼 특별한 요구가 있을 때만 도입 후보로 삼고, 입력 지연·키보드·포커스·앵커·감소 모션·예산을 실제로 검증한다.
 
-쓴다면 전부 지켜라: `respectReducedMotion: true` 명시 · `duration` 1.2 이하 · `syncTouch: false` · 모달 열릴 때 `lenis.stop()` · 내부 스크롤 요소(코드 블록·지도)에 `data-lenis-prevent` · **키보드 스크롤(Space·PageDown·Home·End)을 실제로 눌러보고 확인**.
+쓴다면 터치 동작·모달과 내부 스크롤의 상호작용을 프로젝트 계약으로 정하고, Space·PageDown·Home·End·포커스 이동·앵커를 실제로 확인한다. `prefers-reduced-motion`에서는 네이티브 경로 또는 불필요한 보간 제거가 실제로 적용되는지 확인한다. 측정된 입력 지연과 모션 예산을 `design.md`에 남긴다.
 
 ---
 
@@ -743,8 +745,8 @@ const progress = clamp01((start - rect.top) / travel);
 - [ ] scroll-driven을 쓴 곳에 `@supports` 가드가 있고 **초기 상태가 그 블록 안에** 있다. Firefox에서 백지가 되지 않는다
 - [ ] 스크롤 리빌이 위아래로 오갈 때 재생되지 않는다 (`both` / `unobserve()`)
 - [ ] 첫 화면 콘텐츠가 애니메이션 없이 즉시 읽힌다
-- [ ] 퇴장 duration이 진입의 0.65배다. `(항목수 − 1) × --stagger + duration ≤ 800ms`
-- [ ] 한 시점에 움직이는 독립 요소가 3개 미만이고, 애니메이션 중에도 클릭·키 입력이 먹는다
+- [ ] 퇴장 duration과 stagger 총 소요가 프로젝트 계약에 맞고, 입력 지연·감소 모션을 실제로 확인했다
+- [ ] 대표 과업에서 동시 모션이 시선·클릭·키 입력을 방해하지 않는지 실제로 확인했다
 
 **접근성 — 타협 없음**
 - [ ] `prefers-reduced-motion: reduce`를 켜고 실제로 확인했다. **전부 꺼지지 않고** 위치 이동·시차·루프만 죽고 페이드·상태 변화·진행 표시는 남는다
@@ -757,8 +759,8 @@ const progress = clamp01((start - rect.top) / travel);
 
 **성능**
 - [ ] 모션 라이브러리 추가분이 `tokens.md` §5 예산 안이다. 넘겼으면 올린 이유를 명시했다
-- [ ] `will-change`가 상시 걸린 요소가 10개 미만이다
-- [ ] Lenis를 썼다면 §4의 조건 6개를 전부 충족했고 키보드 스크롤을 실제로 테스트했다
+- [ ] 상시 `will-change` 요소의 레이어 메모리와 실제 기기 성능이 프로젝트 예산 안임을 확인했다
+- [ ] Lenis를 썼다면 §4의 입력·키보드·포커스·앵커·감소 모션·예산 검증을 실제로 마쳤다
 - [ ] 6단계 `design.md`에 **채택한 모션 · 안 쓰기로 한 모션과 그 이유**를 적었다
 
 > 근거: research/motion/01~03 (조사일 2026-08-20)

packages/skill/references/presets/editorial.md

@@ -6,15 +6,15 @@
 
 - 콘텐츠(글·사진·작업물)가 실제로 있고 그것이 설득의 주체일 때
 - 브랜드·미디어·포트폴리오·럭셔리·문화 기관
-- **쓰지 마라**: 기능이 많은 제품, 전환이 목적인 랜딩, 데이터 밀도가 높은 화면
+- 기능이 많은 제품·전환 랜딩·데이터 밀도 화면도 콘텐츠의 읽기 리듬과 인쇄 어휘가 과업을 돕는지 검토한다. 정보 입력·비교·반복 행동이 주역이면 이 프리셋의 여백·서체·이미지 비중을 그 역할에 맞게 줄이거나 다른 구조를 택한다.
 
 ## 결정
 
 ### 타이포그래피
 - 세리프 또는 고대비 산세를 주역 후보로 둔다. 대상 언어의 glyph·작은 크기·긴 읽기에서 더 잘 작동하는 쪽을 선택한다.
-- 비율 **1.333~1.618** — 헤드라인과 본문의 차이를 크게 벌린다
+- 비율 **1.333~1.618**은 헤드라인과 본문 차이를 검토하는 출발 후보다. 실제 언어·폭·위계에서 필요한 차이를 확인해 정한다.
 - 본문 `--measure`는 상대적으로 좁은 값에서 시작하고, 라틴 60~68자·한글 25~35자는 후보 범위로만 쓴다. 글꼴·언어·확대 상태의 실제 문단으로 확정한다.
-- 웨이트는 2개면 충분(Regular + 하나). 굵기로 소리치지 않는다
+- Regular + 하나는 관리하기 쉬운 시작점이다. 역할·언어·실제 위계가 더 많은 웨이트를 요구하면 전송량과 렌더를 확인해 추가한다.
 
 | 슬롯 | 무료 | 유료 | 한글 |
 |---|---|---|---|
@@ -24,11 +24,11 @@
 ### 색
 - 종이 같은 따뜻한 배경과 순백 모두를 콘텐츠·이미지·브랜드 대비로 비교한다. `#fbfaf8`, `#f7f5f0`은 출발값 후보일 뿐이다.
 - 잉크는 순흑과 근접색을 실제 대비·주변 이미지·긴 읽기에서 비교한다.
-- 강조 역할이 필요하면 **한 색을 작게** 쓴다. 강조색이 없어도 되며, 링크·인용·페이지 번호의 구분은 대비·밑줄·위치로도 만들 수 있다.
+- 강조색의 면적은 역할과 실제 대비로 정한다. 넓은 specimen field나 이미지 배경도 브랜드·위계·접근성을 지지하면 쓸 수 있으며, 링크·인용·페이지 번호는 대비·밑줄·위치로도 구분할 수 있다.
 
 ### 간격
 - **여백이 콘텐츠다.** 섹션 간격을 본문 간격의 5~6배까지 벌려도 된다
-- 비대칭을 적극적으로 — 본문을 그리드 왼쪽 2/3에 두고 오른쪽을 비우거나, 캡션을 여백에 흘린다
+- 초점·균형·내용 군집에 도움이 될 때 비대칭을 검토한다 — 본문을 그리드 왼쪽 2/3에 두고 오른쪽을 비우거나, 캡션을 여백에 흘릴 수 있다
 - 이미지는 본문 폭을 넘어가게(`wide`/`full`) 두어 리듬을 만든다
 
 ### 재질 (`svg-filters.md`)
@@ -43,13 +43,13 @@
 
 ## 흔한 실패
 
-1. **세리프를 썼는데 여백이 좁다** → 세리프는 숨 쉴 공간이 없으면 그냥 답답해진다
-2. **강조색을 넓게 칠했다** → 에디토리얼의 색은 점이지 면이 아니다
-3. **모든 이미지를 같은 크기로 넣었다** → 크기 차이가 리듬이다
-4. **본문 폭이 넓다** → 이 프리셋에서 가장 자주 나오는 실패
-5. **한글에 라틴 세리프만 지정** → 한글이 시스템 기본으로 떨어져 전부 무너진다
+1. **세리프의 실제 글자·행간·정보 밀도를 보지 않고 여백만 좁혔다** → 대표 문단과 캡션에서 획·속공간·줄 추적을 확인한다
+2. **색면이 본문·행동과 경쟁하거나 대비를 깨뜨린다** → 면적·인접색·읽기 상태에서 다시 비교한다
+3. **이미지 역할을 보지 않고 같은 크기만 반복했다** → 시퀀스·비교·크롭의 역할을 확인해 크기 변주가 필요한지 정한다
+4. **본문 폭이 넓어 줄 추적이 어려워진다** → 실제 문단·언어·확대 상태에서 measure를 다시 정한다
+5. **한글 fallback을 확인하지 않았다** → 의도한 fallback인지 glyph·위계·줄바꿈을 실제 렌더에서 확인한다
 
-## 리스크 후보 (2단계에서 하나 고른다)
+## 리스크 후보 (2단계에서 필요할 때 하나 고른다)
 
 - 히어로에 이미지 없이 **타이포그래피만**
 - 본문 폭을 극단적으로 좁히고 여백에 주석을 흘리기

packages/skill/references/tokens.md

@@ -45,12 +45,12 @@
 
 | 토큰 | 규칙 |
 |---|---|
-| `--leading-tight` | 1.1~1.2 — 디스플레이/헤드라인 |
-| `--leading-normal` | 1.5~1.6 — 본문 (라틴) / **1.6~1.8 (한글)** |
-| `--measure` | 한 줄 길이. 라틴 60~75자, **한글 25~40자** |
+| `--leading-tight` | 1.1~1.2부터 검토 — 디스플레이/헤드라인 |
+| `--leading-normal` | 1.5~1.6(라틴), **1.6~1.8(한글)**부터 검토 — 본문 |
+| `--measure` | 한 줄 길이의 시작 범위. 라틴 60~75자, **한글 25~40자** |
 | 자간 | 큰 라틴 디스플레이에서만 작은 음수 자간을 후보로 두고 실제 렌더로 확인. 한글은 글꼴·크기·문맥별로 시험하며, 음수값을 기본 처방이나 절대 금지로 두지 않는다 |
 
-폰트 수는 전송량·언어 범위·위계·라이선스를 함께 보고 예산으로 정한다. 두 텍스트 패밀리와 필요 시 모노는 흔한 시작점이지만, 세 번째 패밀리가 무조건 실패라는 뜻은 아니다.
+행간과 measure 범위는 시작값이다. 한글 서체·문자·폭·실제 문단을 렌더하고 확대 상태까지 확인해 정한다. 폰트 수는 전송량·언어 범위·위계·라이선스를 함께 보고 예산으로 정한다. 두 텍스트 패밀리와 필요 시 모노는 흔한 시작점이지만, 세 번째 패밀리가 무조건 실패라는 뜻은 아니다.
 
 > **어떤 폰트를 어떻게 고르고 싣는지는 `typography.md` 가 정본이다.** 여기서는 스케일 값만 정한다.
 > 로딩 전략, 폴백 메트릭 보정, OpenType 기능, 한글 서브셋, 라이선스 확인이 그 문서에 있다.
@@ -78,7 +78,7 @@
 ### 규칙
 
 1. 강조 역할은 한 색에서 시작해 경쟁 여부를 검증한다. 여러 강조 역할이 필요할 수 있으며, 그때는 행동·상태·정보 목적을 역할 토큰으로 구분한다. 수만으로 위계 실패를 판정하지 않는다
-2. **채도가 높은 색은 면적을 좁게.** 넓은 면적에 쓰면 눈이 피로하고 싸구려로 보인다
+2. 색 맥락 관찰은 [visual-design-lineage.md](./visual-design-lineage.md)를 참고한다. 이 스킬에서는 브랜드 강도·정보 위계·접근성의 근거로 색을 고르고, 실제 상태·면적·인접색에서 텍스트 대비와 판독성을 별도로 검증한다
 3. **중성색도 색이다.** 순수 회색과 색조를 띤 중성색을 모두 후보로 두고, 표면·브랜드·상태색과의 관계를 비교한다
 4. **대비를 측정해라.** 본문 4.5:1, 큰 글자 3:1. 눈으로 판단하지 마라
 

packages/skill/references/typography.md

@@ -39,6 +39,8 @@
 
 이름과 인상으로 고르지 마라. 다음 넷을 본다.
 
+실제 proof에는 패밀리, 계산된 크기, 행간, 본문 폭을 따로 기록한다. 같은 CSS px도 글꼴의 x-height·획·글자틀에 따라 같은 광학 크기로 보이지 않는다. 선호와 읽기 성능도 같은 값이 아니므로 [Wallace et al.](./visual-perception-research.md#wallace-et-al-2022)의 조건처럼 실제 독자·문자 체계·과업에서 분리해 확인한다.
+
 - **x-height 비율** — 소문자 높이와 본문 크기의 관계. 단일 임계값으로 가독성을 판정하지 말고 실제 크기·언어·렌더링에서 확인한다
 - **대비** — 획 굵기 차이. 큰 크기에서만 살아나는 폰트가 있다
 - **웨이트 범위** — 필요한 웨이트가 실제로 있는가. 없는 웨이트를 브라우저가 합성하면 뭉개진다
@@ -93,7 +95,7 @@ h1 { font-optical-sizing: auto; }
 
 ### 애니메이션
 
-가변 축은 애니메이션할 수 있지만 **레이아웃을 다시 계산한다.** 하드 게이트 8이 금지하는 종류다. 글자 굵기를 움직이고 싶으면 `opacity` 로 두 겹을 교차시켜라.
+가변 축 애니메이션은 레이아웃 계산 비용을 만들 수 있다. 자동 금지가 아니라, 3단계의 성능 예산 안에서 비용·입력 간섭·감소 모션 경로·상태 피드백을 실제 기기와 브라우저에서 측정해 채택한다. 글자 굵기 변화가 필요하지만 그 조건을 충족하지 못하면 `opacity`로 두 겹을 교차시키는 대안을 검토한다.
 
 ---
 

packages/skill/references/visual-design-lineage.md

@@ -0,0 +1,39 @@
+# visual-design-lineage — 시각 디자인 원전의 적용 경계
+
+확인일: 2026-09-12. 이 문서는 원전 전체를 읽었다는 주장이 아니다. 링크에서 확인 가능한 기관 해설·공식 소개·공개 본문·서지의 범위만 적고, 아래의 실무 번역은 모두 **이 스킬의 적용 제안**이다.
+
+## 언제 읽는가
+
+- 1단계에서 레퍼런스의 색·재질·그리드·타입 관찰을 언어로 설명할 때
+- 2단계에서 스타일 이름 대신 시각적 목적과 검증 방법을 정할 때
+- 5단계에서 대비·읽기성·위계의 자동 검사와 시각 평가를 구분할 때
+
+브랜드 자산·`design.md`·접근성 기준보다 우선하지 않는다. 바우하우스는 단일 스타일이 아니며, 이 문서는 황금비·Swiss sans·라틴 연구를 한글 화면에 자동 적용하지 않는다.
+
+## 관점·확인 범위·실무 질문·한계·출처
+
+| 관점 | 링크에서 확인한 범위 | 이 스킬의 적용 제안과 질문 | 한계·출처 |
+|---|---|---|---|
+| Itten | 재료·질감·색을 다루는 교육 맥락 | 재료의 질감·명암·색을 관찰하고, 브리프에 필요할 때만 표면 실험으로 번역해 작은/큰 화면의 위계와 읽기를 비교한다 | 효과나 선호의 보편 법칙이 아니다. [Getty 기관 해설](https://www.getty.edu/research/exhibitions_events/exhibitions/bauhaus/new_artist/matter_materials/itten/) |
+| Albers, *Interaction of Color* (1963) | 색이 주변 맥락에서 다르게 지각되는 교육 실험 | 같은 텍스트·버튼을 실제 surface·상태·이미지 위에서 비교한다 | 알버스의 지각 실험은 WCAG 대비 판정이 아니다. [Albers Foundation 해설](https://www.albersfoundation.org/alberses/teaching/interaction-of-color) |
+| Kandinsky | 바우하우스의 분석적 드로잉과 교육 맥락 | 도형·색을 쓸 때 장식 이름이 아니라 정보 역할·시선 흐름·실제 렌더를 기록한다 | 색-도형 대응은 당시 이론이며 과학적 보편 법칙이 아니다. [Bauhaus Kooperation 기관 해설](https://bauhauskooperation.de/wissen/das-bauhaus/lehre/unterricht/unterricht-wassily-kandinsky) |
+| Tschichold, *The New Typography* (1928) | 비대칭, sans-serif, 사진을 둘러싼 역사적 맥락 | 비대칭·사진·sans를 채택하면 과업·언어·이미지 근거와 작은 폭 읽기성을 함께 검증한다 | 현재 제품의 전환·접근성 규칙이 아니다. [Yale 출판사 연구 해설](https://yalebooks.yale.edu/2019/04/15/the-avant-garde-and-the-new-typography/) |
+| Ruder, *Typography* (1967) | 공식 소개는 구조·그리드·가독성, 타입의 리듬·비례를 다룬다고 설명한다 | 그리드·타입의 관계를 살필 독서 경로로 쓰고, 구조·가독성·리듬·비례의 선택을 같은 콘텐츠·viewport에서 비교한다 | 소개 범위 밖의 본문 규칙을 인용하지 않는다. [Niggli 공식 소개](https://niggli.ch/en/products/typographie) |
+| Hofmann, *Graphic Design Manual* (1965) | 공식 소개는 point·line·plane, contrast·rhythm·composition을 다룬다고 설명한다 | 점·선·면과 대비·리듬·구도의 대안을 스케치한 뒤 같은 콘텐츠로 렌더 비교한다 | 소개 범위 밖의 본문 규칙을 인용하지 않는다. [Typotheque 공식 소개](https://www.typotheque.com/books/graphic-design-manual) |
+| Warde, “The Crystal Goblet” (1930) | 공개 강연 본문 | 정보 전달이 우선인 표면은 읽기·탐색·오류 복구를 먼저, 표현적 표면은 그 목적과 비용을 별도 기록한다 | 투명성이 모든 화면의 미학적 의무는 아니다. [공개 본문 PDF](https://openlab.citytech.cuny.edu/langecomd3504fa2020-monday/files/2018/10/Warde_CrystalGoblet.pdf) |
+| Arnheim, *Art and Visual Perception* | 공식 소개는 시각 재료가 심리적으로 조직되는 방식을 설명한다 | 균형·긴장·형태를 관찰 언어로 사용하고, 화면의 묶음·구도 판단은 실제 렌더에서 한다 | 책 본문이나 실험 결과를 여기서 인용하지 않는다. [UC Press 소개](https://www.ucpress.edu/books/art-and-visual-perception-second-edition/epub-pdf) |
+| Dondis, *A Primer of Visual Literacy* (1973) | 공식 소개는 시각 문해를 위한 교육적 체계를 제시한다 | 대비·리듬·구도를 설명할 어휘로 사용하고, 학습 효과나 보편 수치는 주장하지 않는다 | 원문을 정독하거나 성과를 검증했다는 뜻이 아니다. [MIT Press 소개](https://mitpress.mit.edu/9780262540292/a-primer-of-visual-literacy/) |
+| Bertin, *Semiology of Graphics* (1967) | 서지 소개 | 데이터 표현은 질문·비교·라벨·대체 접근을 먼저 정한다 | 웹 차트의 자동 처방이나 원문 인용이 아니다. [Esri Press 서지](https://www.esri.com/en-us/esri-press/browse/semiology-of-graphics-diagrams-networks-maps) |
+
+## 기존 출처 원장과 연결
+
+다음 서지는 중복 행을 만들지 않고 [evidence-ledger.md](evidence-ledger.md)의 기존 ID를 따른다: `MULLER-BROCKMANN`, `BRINGHURST`, `LUPTON`. 모두 서지 확인 범위이며, 판본·페이지를 확보하기 전에는 본문 규칙으로 인용하지 않는다.
+
+## 상충 관점 적용 예시
+
+1. **질감 대 투명성**: Itten의 재료 관찰은 브랜드의 표면 선택에 쓸 수 있고, Warde의 투명성은 정보 전달 표면에 쓸 수 있다. 제품 비교 표에는 읽기·탐색을 우선하고, 캠페인 히어로에는 질감을 채택할 수 있다. 둘 다 모션 off, 대비, 좁은 폭의 위계로 검증한다.
+2. **색 맥락 대 접근성**: Albers식 비교는 버튼이 배경·사진·상태에 따라 달라 보인다는 관찰이다. 적용 전후에는 실제 합성 배경에서 WCAG를 별도로 계산한다. 지각 실험으로 대비 실패를 정당화하지 않는다.
+3. **표현적 조판 대 정보 표면**: Tschichold·Hofmann의 비대칭이나 강한 타입은 브랜드 진입점에 맞을 수 있다. Warde의 관점은 양식 금지가 아니라 표·폼·오류 화면에서 메시지와 조작을 가리지 말라는 질문이다. 같은 콘텐츠·viewport·상태·자산의 전후 렌더로 판단한다.
+4. **그리드 대 예외**: Müller-Brockmann의 그리드는 정렬선의 이유를 설명하는 출발점이다. 이미지 크롭·증거 패널·한글 줄바꿈이 더 중요한 경우에는 예외를 `design.md`에 기록하고, 읽기 폭·묶음·접근성에 미치는 결과를 확인한다.
+
+기록 형식: `출처 또는 기존 ID → 확인 범위 → 이 스킬의 적용 제안 → 프로젝트 관찰 → 결정 → 같은 viewport/state/assets의 검증`. 수상·취향·시각적 호감만으로 사용자 성과의 인과를 주장하지 않는다.

packages/skill/references/visual-perception-research.md

@@ -0,0 +1,73 @@
+# 시각 지각 연구: 적용 질문과 한계
+
+확인일: 2026-09-12. 이 문서는 화면을 진단할 때 무엇을 묻고 어디까지 말할 수 있는지 정리한다. 정적 화면의 호감은 실제 읽기·전환·접근성을 뜻하지 않고, 에이전트의 진단도 사용자 척도 검증이 아니다. 원척도를 임의 한국어 번역하거나 몇 문항만 추출한 평가는 원척도와 동일하게 검증된 평가라고 부르지 않는다.
+
+## 언제 읽는가
+
+- 첫 화면의 시각적 인상, 질서와 독창성의 긴장, 복잡성과 친숙함을 **사용자 평가로 조사할지** 결정할 때 심미성 연구를 읽는다.
+- 차트에서 비율·차이·순위를 얼마나 정확히 읽는지가 질문일 때 그래프 지각 연구를 읽는다.
+- 글꼴 선택이 읽기 성능에 미치는 영향을 주장하려 할 때 읽기 연구를 읽는다.
+- 색 수, 제목 줄 수, 카드 수를 자동 합격 규칙으로 만들거나 정적 스크린샷만으로 효과를 선언할 때는 이 연구들을 근거로 쓰지 않는다.
+
+## 연구별 확인 범위와 적용 질문
+
+### Lavie & Tractinsky (2004)
+
+- 서지: [Assessing dimensions of perceived visual aesthetics of web sites](https://doi.org/10.1016/j.ijhcs.2003.09.002), *International Journal of Human-Computer Studies* 60(3), 269–298.
+- 확인 범위: [대학 연구 포털 초록](https://cris.bgu.ac.il/en/publications/assessing-dimensions-of-perceived-visual-aesthetics-of-web-sites-2/)만 확인했다. 네 연구로 지각된 웹 심미성 측정 도구를 개발했고, 탐색·확인 요인분석에서 classical aesthetics와 expressive aesthetics를 구분했다고 보고한다. 각 차원은 5문항이다.
+- 측정 대상: 질서·명료함과 관련된 classical, 창의성·독창성·관습 이탈과 관련된 expressive라는 지각된 심미성 차원이다.
+- 적용 질문: “정돈됨”과 “표현의 독창성”을 하나의 좋고 나쁨으로 합치지 않고 각각 사용자 평가가 필요한가?
+- 한계: 원문 표본·조건은 여기서 확인하지 못했다. 이 척도를 임의 한국어 번역하거나 일부 문항만 떼어 쓴 평가는 원척도와 동일하게 검증된 평가가 아니다.
+
+### Moshagen & Thielsch (2010)
+
+- 서지: [Facets of visual aesthetics](https://doi.org/10.1016/j.ijhcs.2010.05.006), *International Journal of Human-Computer Studies* 68(10), 689–709. [저자 공개 PDF](https://www.uni-muenster.de/OWMS/uploads/drafts_thielsch/pdf/moshagen_2010.pdf).
+- 확인 범위: 초록 확인 범위다. 7개 연구에서 simplicity, diversity, colorfulness, craftsmanship의 네 facet을 보고한다. 각 표본의 수와 조건은 확인하지 못했다.
+- 측정 대상: 웹 인터페이스의 지각된 시각 심미성을 여러 facet으로 나눈 평가다.
+- 적용 질문: 색채·완성도·다양성·단순성을 같은 점수로 뭉개지 말고, 이번 브리프에서 어느 facet을 관찰·사용자 평가할지 분리할까?
+- 한계: 이 결과는 “단순할수록 좋다”는 강제가 아니며, 임의 문항 추출·번역은 원척도 검증이 아니다. 이를 검증된 VisAWI라고 부르지 않는다.
+
+### Tuch et al. (2012)
+
+- 서지: [The role of visual complexity and prototypicality regarding first impression of websites](https://doi.org/10.1016/j.ijhcs.2012.06.003), *International Journal of Human-Computer Studies* 70(11), 794–811.
+- 확인 범위: 출판사 초록의 검색 색인 범위다. 첫 연구는 119개 웹사이트 스크린샷을 사용했고, 두 연구는 50/500/1000ms와 17/33/50ms 노출을 다뤘다. 낮은 visual complexity와 높은 prototypicality의 심미 선호를 보고한다.
+- 측정 대상: 실제 과업 수행 전, 짧은 노출에서의 첫 심미 평정과 visual complexity·prototypicality의 관계다.
+- 적용 질문: 첫 화면에서 낯선 구조가 필요한 이유가 있는가, 아니면 핵심 범주와 행동을 더 빨리 식별할 수 있게 해야 하는가?
+- 한계: 이 밀리초는 통과선이나 모든 화면의 고정 노출 시간으로 쓰지 않는다. 실제 읽기·전환·접근성 과업과 첫 인상은 별도 측정이다.
+
+### Cleveland & McGill (1984)
+
+- 서지: [Graphical Perception: Theory, Experimentation, and Application to the Development of Graphical Methods](https://doi.org/10.1080/01621459.1984.10478080), *Journal of the American Statistical Association* 79(387), 531–554. [공개본](https://faculty.washington.edu/aragon/classes/hcde511/s12/readings/cleveland84.pdf).
+- 확인 범위: 공개본의 서론·실험 설명 일부를 확인했다. 전체 본문을 정독하거나 원자료를 재분석하지 않았다. 정량 비율을 추정하는 그래픽 채널의 정확도를 실험으로 비교한다.
+- 측정 대상: 사람이 그래프에서 수량 관계를 읽을 때의 지각 정확도다.
+- 적용 질문: 정확한 비교가 목표인 차트에서 면적·각도·위치·길이 중 무엇을 쓰며, 축·라벨·값으로 오독을 어떻게 확인할까?
+- 한계: 모든 UI의 미학 법칙이 아니다. 브랜딩·서사 사진·버튼 표면의 우열이나 사용자 만족도를 이 연구만으로 판정하지 않는다.
+
+### Heer & Bostock (2010)
+
+- 서지: [Crowdsourcing Graphical Perception: Using Mechanical Turk to Assess Visualization Design](https://idl.uw.edu/papers/crowdsourcing-graphical-perception), CHI 2010, 203–212, DOI [10.1145/1753326.1753357](https://doi.org/10.1145/1753326.1753357).
+- 확인 범위: [공식 초록](https://idl.uw.edu/papers/crowdsourcing-graphical-perception)을 직접 확인했다. 기존 spatial encoding·luminance contrast 실험을 재현하고, 직사각형 면적·차트 크기·그리드 간격을 추가로 시험하며, Mechanical Turk 방법의 타당성·비용·성능을 보고한다.
+- 측정 대상: 시각화 지각 실험을 크라우드소싱으로 수행하는 방법과 특정 그래픽 조건의 비교다.
+- 적용 질문: 표본·과제·품질 통제를 명시해 우리 차트 가설을 재현 가능한 사용자 실험으로 만들 수 있는가?
+- 한계: 크라우드 실험 가능성은 현재 제품의 사용자 경험이 좋다는 증거가 아니다. 재현 연구의 방법론과 디자인 결론을 구분한다.
+
+### Wagemans et al. (2012)
+
+- 서지·확인 범위: 기존 [evidence ledger의 GESTALT 항목](./evidence-ledger.md)을 따른다.
+- 측정 대상: 시각 요소가 묶이고 전경·배경으로 분리되는 지각 원리의 현대적 검토다.
+- 적용 질문: 근접성·유사성·공통 영역·figure-ground가 현재 화면에서 관련 정보와 선택 상태를 구별하게 하는가?
+- 한계: 정렬이나 카드, 단일 색만으로 이해·전환이 보장되지는 않는다. 회색조·키보드·실제 과업으로 따로 확인한다.
+
+### Wallace et al. (2022)
+
+- 서지: [Towards Individuated Reading Experiences: Different Fonts Increase Reading Speed for Different Individuals](https://doi.org/10.1145/3502222), *ACM TOCHI* 29(4), Article 38. [저자 공개본](https://jeffhuang.com/papers/Readability_TOCHI22.pdf).
+- 확인 범위: 저자 공개본의 검색 색인에서 방법 5.1.4/5.2와 결과 일부를 확인했다. 전문을 정독하지 않았다. 정제 뒤 352명의 18–71세 성인이 원격으로 영어 지문을 읽었고, 선호·WPM·이해도를 분리했다.
+- 측정 대상: 개인별 글꼴에 따른 영어 읽기 속도, 선호, 이해도의 관계다. 가장 빠르거나 느린 글꼴이 개인마다 달랐고, 선호와 읽기 성능이 일치하지 않을 수 있다고 보고한다.
+- 적용 질문: 실제 독자·문자 체계·과업으로 글꼴 후보의 속도, 이해, 선호를 분리 측정할 필요가 있는가?
+- 한계: 효과량을 여기서 임의 수치로 옮기지 않는다. 영어 원격 읽기 결과를 한글, 장문, 저시력 독자, 다른 장치에 자동 일반화하지 않으며 선호를 성능의 대리값으로 쓰지 않는다.
+
+## 사용 예시
+
+1. 대시보드에서 정확한 비율 비교가 목표면 Cleveland & McGill로 채널 선택 가설을 세우고, 라벨을 포함한 실제 데이터 과업의 정확도·시간·오류를 측정한다.
+2. 랜딩 첫 화면을 검토할 때는 Tuch의 첫 인상 범위만 참고해 복잡성·친숙함을 관찰하고, 다음 단계에서 실제 탐색·설치·문의 과업을 별도로 시험한다.
+3. 활자 변경을 제안할 때는 Wallace를 근거로 “개인·성능·선호가 다를 수 있다”까지만 말하고, 한국어 독자와 실제 본문으로 읽기·이해·선호를 분리해 측정한다.