# evidence ledger — 판단의 출처와 한계

조사일: 2026-09-12. 이 목록은 읽을거리 순위가 아니라, 디자인 결정에 쓸 수 있는 근거의 범위다. `normative`는 적합성 조건, `research`는 특정 인간-컴퓨터 상호작용의 경향, `practice`는 설계 절차, `case`는 한 사례 또는 심사 체계, `forecast`는 전망, `bibliography`는 서지 확인만 뜻한다. 사례·전망·서지는 효과나 인과를 증명하지 않는다.

| ID | 출처·날짜 | 종류 | 실제로 지지하는 주장 | 적용 조건 / 잘못된 일반화 | 구체 검증 |
|---|---|---|---|---|---|
| WCAG-22 | [WCAG 2.2](https://www.w3.org/TR/WCAG22/) · 2023-10-05 | normative | A·AA·AAA는 서로 다른 적합성 수준이며 AAA만으로 모두에게 접근 가능해지지는 않는다 | 법·계약 목표는 별도로 확인한다. AA를 자동 법적 보장이라 부르지 않는다 | 요구 수준과 전 과정의 SC를 매핑한다 |
| WCAG-READ | [contrast](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) · [resize](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html) · [reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) · [text spacing](https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html) · 2023 | normative | 일반 텍스트 AA 4.5:1/큰 텍스트 AA 3:1, 200% 확대, 320 CSS px 재배치, 사용자 지정 간격에서의 내용·기능 보존을 각각 요구한다 | 로고·비활성·2차원 배치 같은 예외가 있으며, 이는 단일 ‘좋은 조판’ 수치를 만들지 않는다 | 실제 상태에서 대비, 200% 확대, 320px/400%, W3C text-spacing 주입을 함께 검사한다 |
| WCAG-TARGET | [SC 2.5.8](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) · 2023 | normative | 포인터 입력 대상은 최소 24×24 CSS px(예외 포함)인 AA 기준이 있다 | 44px를 모든 대상의 WCAG AA 요건으로 말하지 않는다 | 실제 clickable box와 인접 대상 간격을 측정한다 |
| WCAG-MOTION | [SC 2.2.2](https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html) · 2023 | normative | 자동으로 시작해 5초 넘게 병행되는 움직임은 멈춤·숨김·일시정지 제어가 필요할 수 있다 | 모든 모션 금지가 아니다 | 자동 콘텐츠마다 제어와 키보드 접근을 시험한다 |
| W3C-REDUCED | [Media Queries 5](https://www.w3.org/TR/mediaqueries-5/#prefers-reduced-motion) · 확인 2026-09-12 | practice | CSS Media Queries 명세는 `prefers-reduced-motion` 질의를 정의한다 | WCAG 성공 기준이나 모든 모션 정책의 적합성 선언이 아니다 | 시스템 설정에서 핵심 상태 피드백이 남는지 확인한다 |
| W3C-FONT | [CSS Fonts 4](https://www.w3.org/TR/css-fonts-4/#font-display-desc) · 확인 2026-09-12 | practice | CSS Fonts 명세는 `font-display`의 로딩 기간 표시 전략을 정의한다 | WCAG 적합성 요건이 아니며, `swap`이 항상 최선이거나 CLS를 반드시 만든다고 단정하지 않는다 | 느린 네트워크에서 FOUT/FOIT·레이아웃을 캡처한다 |
| W3C-SIZE | [CSS Fonts 5](https://www.w3.org/TR/css-fonts-5/#size-adjust-desc) · 확인 2026-09-12 | practice | CSS Fonts Level 5 명세는 `size-adjust` descriptor를 정의한다 | 문서 상태·브라우저 지원을 별도 확인하며, 임의 백분율을 보편 처방으로 복사하지 않는다 | 대상 문자열·실제 폴백으로 줄바꿈과 높이를 비교한다 |
| NNG-HEUR | [10 usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/) · 마지막 검토 2024-01-30 | practice | 최소성은 관련 없는 정보가 관련 정보의 가시성을 경쟁시킨다는 휴리스틱이다 | ‘미니멀=요소 삭제’나 전환 효과의 증명이 아니다 | 핵심 과업별 정보·피드백·복구 가능성을 리뷰한다 |
| NNG-VISUAL | [Principles of visual design](https://www.nngroup.com/articles/principles-visual-design/) · 확인 2026-09-12 | practice | scale, visual hierarchy, balance, contrast, Gestalt principles를 시각 디자인의 검토 차원으로 설명한다 | 특정 크기 비율·색 수·자동 심미성 점수를 처방하지 않는다 | 회색조와 실제 콘텐츠에서 우선순위·묶음·대비를 비교한다 |
| NORMAN-SIGN | [Signifiers, not affordances](https://jnd.org/signifiers-not-affordances/) · 2008 | practice | 사용자가 어디서 어떻게 행동할지 알게 하는 지각 가능한 단서는 signifier로 설명할 수 있다 | 시각적으로 버튼처럼 보이면 이해·접근성이 자동 보장된다는 뜻이 아니다 | 첫 사용자가 라벨·상태·피드백으로 행동을 예측하는지 관찰한다 |
| KRUG | [Don’t Make Me Think Revisited sample](https://sensible.com/downloads/DMMT-Revisited-sample-chapter.pdf) · 확인 2026-09-12 | bibliography | 공개 샘플은 Krug의 저작과 ‘명확한 선택지’라는 교육적 관점을 확인하는 범위다 | 메뉴 수 고정 규칙이나 실험적 성과 증거가 아니다 | 애매한 라벨을 대표 사용자의 과업 탐색으로 시험한다 |
| FITTS | [Fitts’s law](https://doi.org/10.1037/h0055392) · 1954 | research | 목표까지 거리와 이동축의 폭은 조준 시간에 관계한다 | 메뉴 개수 공식이나 모바일 타깃 크기 법규가 아니다 | 자주 쓰는 행동의 실제 거리·hitbox·오입력을 관찰한다 |
| HICK | [Hick](https://doi.org/10.1080/17470215208416600) · 1952 | research | 선택 신호의 정보량과 반응 시간 관계를 실험했다 | ‘7개 이상 메뉴 금지’로 변환하지 않는다 | 사용자 목표별 선택지의 분류·라벨·성공 시간을 테스트한다 |
| MILLER | [Miller](https://doi.org/10.1037/h0043158) · 1956 | research | 단기 기억의 절대적 한계가 아니라 chunking과 과제 맥락을 논의했다 | 7±2를 내비게이션 항목 수 규칙으로 쓰지 않는다 | 회상 대신 과업 완료·오류·도움 요청을 관찰한다 |
| GESTALT | [Wagemans et al.](https://doi.org/10.1037/a0029333) · 2012 | research | 근접성·유사성·공통 영역 같은 grouping 원리와 figure-ground를 현대적으로 검토한다 | 정렬·카드·색 하나만으로 이해·전환이 보장된다는 뜻이 아니다 | 관련 항목의 묶음과 분리, 선택 상태를 회색조·키보드·실제 과업에서 확인한다 |
| COGNITIVE-LOAD | [Sweller](https://onlinelibrary.wiley.com/doi/10.1207/s15516709cog1202_4) · 1988 | research | 문제 해결에서 작업 기억과 문제 구조의 상호작용을 다룬다 | 정보량을 무조건 줄이거나 단일 요소 수 규칙으로 환원하지 않는다 | 처음 하는 과업에서 단계·용어·기억해야 할 상태를 줄이고 오류·완료 시간을 관찰한다 |
| AWWWARDS | [Evaluation system](https://www.awwwards.com/about-evaluation/) · 확인 2026-09-12 | case | 해당 심사는 Design 40 / Usability 30 / Creativity 20 / Content 10으로 채점한다 | 배점 비율이 두 요소의 효과 크기나 사업 성과를 뜻하지 않는다 | 제출 목적일 때 네 차원을 별도 체크한다 |
| WEBBY | [Judging criteria](https://www.webbyawards.com/judging-criteria/) · 확인 2026-09-12 | case | Webby는 콘텐츠·구조/내비게이션·시각 디자인·기능성·상호작용·전반 경험을 심사한다 | 수상은 특정 패턴의 보편적 효율 증거가 아니다 | 사례를 해체하되 과업·접근성·성능을 별도 검증한다 |
| DROPBOX | [Dropbox brand](https://brand.dropbox.com/) · 확인 2026-09-12 | case | 브랜드 사이트가 공개한 자산·원칙의 사례다 | 브랜드의 자체 설명을 사용자 효과로 해석하지 않는다 | 사용할 요소를 렌더·접근성·브리프 적합성으로 다시 판정한다 |
| AREA17 | [AREA 17 × Pentagram](https://area17.com/ideas/area-17-pentagram) · 확인 2026-09-12 | case | 제작사가 프로젝트 접근을 설명하는 사례다 | 제작사 주장은 독립 성과 검증이 아니다 | 구조와 시스템 선택만 참고하고 결과는 직접 비교한다 |
| UNSEEN | [Unseen 2025 wrapped](https://2025.unseen.co/) · 확인 2026-09-12 | case | 시간·문화 맥락이 강한 실험적 웹 표면의 사례다 | 사이트 자체만으로 사용성·전환 효과를 주장하지 않는다 | 모션 off·키보드·모바일에서 핵심 메시지를 검증한다 |
| CSSDA-UNSEEN | [CSS Design Awards listing](https://www.cssdesignawards.com/sites/unseen-studio-2025-wrapped/48957/) · 2026-03-09 | case | CSSDA가 해당 작품을 WOTD로 기록한 사례다 | 단일 수상을 스타일 효과의 일반 증거로 쓰지 않는다 | 작품의 제약과 대상이 현재 브리프와 맞는지 비교한다 |
| CWV | [Web Vitals](https://web.dev/articles/vitals) · 2024-10-31 | practice | CWV의 good 기준은 LCP ≤2.5s, INP ≤200ms, CLS ≤0.1이며 field 75th percentile로 판정한다 | Lighthouse 한 번이나 개발 로컬 측정을 field 적합성이라 부르지 않는다 | RUM/CrUX와 모바일·데스크톱 p75를 기록하고, 로컬은 회귀 proxy로 표기한다 |
| CWV-METHOD | [Threshold methodology](https://web.dev/articles/defining-core-web-vitals-thresholds) · 2025-05-07 | practice | CWV 임계값은 단일 인간 지각값이 아니라 연구·실사용 데이터·달성 가능성을 함께 고려한다 | 한 임계값을 모든 과업의 만족도 원인으로 단정하지 않는다 | 성능 수치와 과업 관찰을 분리 보고한다 |
| IBM-GRID | [Carbon 2x Grid](https://carbondesignsystem.com/elements/2x-grid/usage/) · 확인 2026-09-12 | practice | 제품 UI에서 그리드·gutter·breakpoint를 일관되게 적용하는 방법의 예다 | 모든 브랜드가 Carbon 격자를 써야 한다는 규범이 아니다 | 콘텐츠 폭, 정렬선, 작은 폭의 재배치를 검증한다 |
| IBM-DATA | [IBM data visualization basics](https://www.ibm.com/design/language/data-visualization/design/basics/) · 확인 2026-09-12 | practice | 데이터 표현은 목적·비교·맥락에 맞춰 선택해야 한다 | 장식적 차트나 색만으로 의미가 생긴다고 보지 않는다 | 질문-표현-축/라벨-대체 접근을 연결해 검토한다 |
| IFD-TREND | [iF Design Trend Report 2025](https://ifdesign.com/en/if-magazine/newsroom/if-design-trend-report-2025) · 2025 | forecast | 기관의 거시 디자인 전망이다 | 웹 UI의 검증된 성과나 필수 스타일 목록이 아니다 | 브리프·사용자 조사와 맞을 때만 가설로 쓴다 |
| DC-DIAMOND | [Design Council Double Diamond](https://www.designcouncil.org.uk/resources/the-double-diamond/) · 확인 2026-09-12 | practice | 발견·정의·개발·전달을 오가며 다양한 답을 탐색하고 작은 시험으로 버리거나 개선하는 프레임을 소개한다 | 고정 단계 수나 모든 프로젝트의 의무 절차로 쓰지 않는다 | 불확실성이 큰 결정의 대안·시험·폐기 근거를 기록한다 |
| VA-MOFFAT | [Curtis Moffat: working methods](https://www.vam.ac.uk/articles/curtis-moffat-working-methods) · 2025-09-24 | case | contact sheet, 크롭, 비중심 배치가 작가 작업에서 어떻게 쓰였는지 보여 주는 사례다 | 웹 성과나 보편 구도 규칙의 증거가 아니다 | 이미지 선택·크롭의 목적과 전후 렌더를 비교한다 |
| CH-DESCRIPTION | [Cooper Hewitt image-description guidelines](https://www.cooperhewitt.org/cooper-hewitt-guidelines-for-image-description/) · 확인 2026-09-12 | practice | 중요한 내용을 먼저 두고 공간 순서와 맥락에 맞춰 이미지를 설명하는 방법을 제시한다 | 박물관의 단어 수를 보편 alt 길이 규칙으로 바꾸지 않는다 | 정보성 이미지에서 목적·핵심 내용·대체 설명을 함께 검토한다 |
| LUPTON-POSTERS | [How Posters Work](https://www.cooperhewitt.org/publications/how-posters-work/) · 확인 2026-09-12 | bibliography | Lupton의 책과 포스터를 분석 대상으로 삼는 출판 맥락을 확인하는 출발점이다 | 이 항목은 책 본문을 정독했거나 특정 구성 규칙을 인용했다는 뜻이 아니다 | 판본과 페이지를 확보한 뒤 적용할 개념과 한계를 기록한다 |
| GOV-IMAGES | [GOV.UK Design System: images](https://design-system.service.gov.uk/styles/images/) · 확인 2026-09-12 | practice | 정부 서비스에서 목적에 맞는 사진·도식·대체 설명을 선택하는 지침이다 | 상업 브랜드에 무드 이미지를 금지하는 일반 규칙으로 확대하지 않는다 | 이미지가 과업 정보·맥락·접근성에 기여하는지 확인한다 |
| GOV-TEST | [GOV.UK moderated usability testing](https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing) · 확인 2026-09-12 | practice | 현실적인 중립 과업으로 실제 또는 예상 사용자의 행동과 어려움을 관찰하는 방법을 설명한다 | 특정 참여자 수·시간·성공률을 보편 통과선으로 만들지 않는다 | 과업 문구, 사용 환경, 행동·오류·중단 관찰을 분리 기록한다 |
| NNG-AESTHETIC | [Aesthetic-usability effect](https://www.nngroup.com/articles/aesthetic-usability-effect/) · 2024-02-03, 검토 2026-09-01 | practice | 시각적 호감이 사용성에 대한 지각을 높일 수 있어 실제 과업 결과와 구분해 볼 필요를 해설한다 | 원 논문 전문을 읽었거나 호감이 실제 사용성을 보장한다고 주장하지 않는다 | 취향·첫인상과 과업 행동·오류를 별도 결과로 남긴다 |
| W3C-USER-EVAL | [Involving users in evaluating web accessibility](https://www.w3.org/WAI/test-evaluate/involving-users/) · 2024-04-30 | practice | 사용자 평가는 표준 기반 적합성 평가를 보완하며 둘을 함께 써야 한다고 설명한다 | 적은 표본이나 한 번의 평가를 모든 사용자에게 일반화하지 않는다 | WCAG 평가와 사용자 관찰의 질문·결과를 분리해 기록한다 |
| SWISS-NB | [The International Style 1950–1970](https://www.nb.admin.ch/en/the-international-style-1950-1970) · 확인 2026-09-12 | bibliography | 스위스/국제 타이포그래피의 역사·소장 맥락을 소개한다 | 역사 양식을 기능·전환의 보편 처방으로 바꾸지 않는다 | 그리드·타입 선택의 문화적 근거만 명시한다 |
| BRINGHURST | [The Elements of Typographic Style](https://hartleyandmarks.com/Hartley-%26-Marks-Publishers) · 확인 2026-09-12 | bibliography | Bringhurst 4.0의 서지·출판 정보를 확인하는 출발점이다 | 이 ledger는 책 본문을 읽거나 특정 규칙을 인용했다는 뜻이 아니다 | 판본을 확보한 뒤 페이지 단위로 별도 기록한다 |
| LUPTON | [Thinking with Type, 3rd ed.](https://www.chroniclebooks.com/products/thinking-with-type-1) · 2024 | bibliography | Lupton 저작의 3판 출판 정보를 확인하는 출발점이다 | 이 ledger는 본문 요약이나 보편 수치 근거가 아니다 | 판본을 확보한 뒤 개념·예시 페이지를 별도 기록한다 |
| MULLER-BROCKMANN | [Grid systems in graphic design](https://niggli.ch/en/products/rastersysteme-fur-die-visuelle-gestaltung) · 확인 2026-09-12 | bibliography | Müller-Brockmann 저작의 출판사 서지 정보를 확인하는 출발점이다 | 그리드를 모든 과업의 정답으로 만들지 않는다 | 판본을 확보한 뒤 grid 선택의 목적·예외·검증을 분리 기록한다 |

## 외부 스킬 출처 (2026-09-24 흡수)

조사일: 2026-09-24. 아래는 `docs/design-skills-intake-plan-20260924.md`로 흡수한 외부 디자인 스킬 10종과 better-interface 자매 스킬 7종의 출처 ID다. 저장소·커밋·라이선스 전문은 [THIRD_PARTY_NOTICES.md](../THIRD_PARTY_NOTICES.md)에 있다. 이 스킬들의 종류는 모두 `practice`(실무자가 정리한 설계 절차)이며, "실제로 지지하는 주장"은 그 스킬이 실제로 제공하는 실무 지침·수치 시작값으로 좁혀 쓴다. 공통된 잘못된 일반화는 스킬 저자 개인·소속 팀의 관찰이나 수치를 웹 디자인 전반의 보편 규범으로 확대하는 것이다.

| ID | 출처·날짜 | 종류 | 실제로 지지하는 주장 | 적용 조건 / 잘못된 일반화 | 구체 검증 |
|---|---|---|---|---|---|
| SKILL-FRONTEND-DESIGN | [anthropics/skills — skills/frontend-design](https://github.com/anthropics/skills/tree/34040c9/skills/frontend-design) · 커밋 `34040c9` (2026-09-10) · Apache-2.0 | practice | AI가 생성한 웹 디자인이 반복하는 제네릭 클러스터(색상·타이포·카드·모션 패턴)를 실무자가 정리한 점검표이며, 특정 액센트 hex가 Claude 계열 도구의 지문으로 읽힐 수 있다는 관찰을 포함한다 | 저자가 관찰한 클러스터 분류나 예시를 웹 디자인 전반의 보편 규범으로 확대하지 않는다. 저자 자신의 프로젝트 경험에서 추출한 관찰 후보다 | 지목된 hex·패턴이 실제 렌더에 나타나는지 대조하고, "다른 업종 브리프에도 같은 선택이 그대로 나왔을까"라는 반사실 질문으로 재확인한다 |
| SKILL-APPLE-DESIGN | [emilkowalski/skills — skills/apple-design](https://github.com/emilkowalski/skills/tree/85e8e23/skills/apple-design) · 커밋 `85e8e23` · MIT | practice | Apple 플랫폼의 인터럽트 가능한 제스처·스프링·모멘텀·러버밴드 구현을 정리한 수치 시작값과 구현 패턴이다(damping/response, 속도 인계, 모멘텀 투사 계수, 러버밴드 계수 등) | 저자가 제시한 계수를 물리 법칙이나 플랫폼 표준으로 취급하지 않는다. Apple풍 미학을 모든 브리프의 기본값으로 삼지 않는다(조건부 항목). 원 스킬이 수치에 1차 출처(WWDC 영상·타임스탬프)를 달지 않았다 — 3rd-party 재해석으로 취급하고 옮길 때 그 사실을 밝힌다 | 실제 구현에서 계수를 실측 조정하고, Apple풍이 브리프에 맞는 조건일 때만 적용한다 |
| SKILL-EMIL-DESIGN-ENG | [emilkowalski/skills — skills/emil-design-eng](https://github.com/emilkowalski/skills/tree/85e8e23/skills/emil-design-eng) · 커밋 `85e8e23` · MIT | practice | 모션 구현 실무 지침(사용 빈도별 애니메이션 여부, 트랜지션과 키프레임의 차이, clip-path·드래그·툴팁 구현 레시피, 모션 QA 절차)이다 | "ease-in 절대 금지" 같은 단정을 그대로 규범화하지 않는다. velocity 0.11 같은 매직넘버는 저자의 실측값이지 보편 상수가 아니다 | 레시피를 실제 컴포넌트에 적용해 프레임 단위로 재생해 보고, duration·easing은 프로젝트 토큰(`--dur-*`, `--ease-*`)에 맞춰 재조정한다 |
| SKILL-BEAUTIFUL-SHADOWS | [MengTo/Skills — agent-skills/web-design/beautiful-shadows](https://github.com/MengTo/Skills/tree/a965851/agent-skills/web-design/beautiful-shadows) · 커밋 `a965851` · MIT | practice | 3단(sm/md/lg) 다층 box-shadow 값과 컴포넌트 밀도별 단계 매핑을 제시하는 시작값 세트다 | 레이어 수가 늘수록 값이 커지고 진해지는 이유를 저자도 밝히지 않으므로 그 근거를 인용하지 않는다. Tailwind 임의값 문법은 그대로 쓰지 않고 CSS로 옮겨 쓴다 | 실제 배경·밀도에서 렌더해 과도한 틴팅·중첩을 확인한다 |
| SKILL-WEB-A11Y | [addyosmani/web-quality-skills — skills/accessibility](https://github.com/addyosmani/web-quality-skills/tree/afa8da9/skills/accessibility) · 커밋 `afa8da9` · MIT | practice | Lighthouse·axe 자동 검사 → 실패 노드 국소화 → 수동 검증 → 재감사로 이어지는 증거 우선 접근성 감사 루프와 "자동 점수 100은 준수를 뜻하지 않는다"는 절차 지침이다 | 이 검사 순서를 WCAG 적합성 판정 자체로 착각하지 않는다. 자동화 도구가 잡아내는 범위는 WCAG 성공 기준의 일부일 뿐이다 | DevTools MCP나 axe-core가 있으면 실행하고, 없으면 미검증으로 보고하며 통과로 추정하지 않는다 |
| SKILL-DESIGN-REVIEW | [Superfuture/design-review — design-review/skills/design-review](https://github.com/Superfuture/design-review/tree/d4d2609/design-review/skills/design-review) · 커밋 `d4d2609` · MIT(plugin.json 선언, 저장소에 LICENSE 파일 없음 — THIRD_PARTY_NOTICES.md 참고) | practice | 디자인 리뷰 finding을 What·Why·Fix 3요소와 심각도로 구조화하고, 입력 종류별 진입·자동 적용 화이트리스트를 정리한 리뷰 절차다 | 서체 개수 상한·타입 스케일 단계 수 같은 저자의 규범적 수치는 취향 규칙이지 하드 게이트가 아니다. 텔레메트리·유료 게이팅 요소는 흡수하지 않는다 | finding마다 What·Why·Fix가 모두 채워졌는지, 심각도가 판정 위계와 일치하는지 확인한다 |
| SKILL-SHADCN | [shadcn-ui/ui — skills/shadcn](https://github.com/shadcn-ui/ui/tree/98a1fe6/skills/shadcn) · 커밋 `98a1fe6` · MIT | practice | 기존 컴포넌트 우선·합성 규칙(Dialog Title 필수 등)과 "추측하지 말고 사용자 대신 기본값을 고르지 말라"는 안전 병합 절차다 | CLI 플래그·레지스트리 스키마·Tailwind 매핑 치트시트는 designpaca가 프레임워크를 전제하지 않는다는 원칙과 충돌해 흡수하지 않는다. shadcn 같은 컴포넌트 기반은 브랜드 디자인 시스템 자체가 아니다 | components.json 존재로 감지 여부를 판정하고, 감지했을 때만 component-systems.md 절을 연다 |
| SKILL-IMPECCABLE | [pbakaus/impeccable — skill/reference/adapt.md](https://github.com/pbakaus/impeccable/tree/e0881d2/skill/reference/adapt.md), [skill/reference/adapt.native.md](https://github.com/pbakaus/impeccable/tree/e0881d2/skill/reference/adapt.native.md)(iOS↔Android 관용구 대응표) · 커밋 `e0881d2` · Apache-2.0 | practice | 입력 방식을 화면 크기와 별개 축으로 다루는 pointer·hover 쿼리, 컨테이너 쿼리, 커스텀 컨트롤 제스처 검증(레이아웃 통과 ≠ 제스처 통과)에 대한 구현 코드와 절차, 그리고 iOS↔Android 플랫폼 관용구 대응표다 | 모바일 하단 내비 기본값 같은 저자의 결론은 기각한다(designpaca 결정표가 더 엄밀하다). 빌드 시점 하네스별 본문 컴파일 방식은 흡수하지 않는다 | 실제 포인터·터치 입력에서 코드를 재현하고, 제스처 검증은 레이아웃 검사와 분리해 수행한다 |
| SKILL-BETTER-INTERFACE | [jakubkrehel/skills — skills/better-interface](https://github.com/jakubkrehel/skills/tree/267330e/skills/better-interface) · 커밋 `267330e` · MIT | practice | 에스컬레이션 트리거(규칙 소유·심각도 분리), 저비용 수정 사다리(삭제→플랫폼→재사용→값 교정→추가), 미검증·미점검 구분, 스코프 축소 규율을 제시하는 리뷰 절차다 | "근사가 아니라 정확히 이 값" 같은 규율은 기각한다. finding 상한 같은 수치는 근거가 없어 절차만 채택하고 숫자는 채택하지 않는다 | 리뷰 결과에서 저비용 수정 사다리 순서를 실제로 따랐는지, 미검증 항목이 finding으로 세어지지 않았는지 확인한다 |
| SKILL-BETTER-A11Y | [jakubkrehel/skills — skills/better-accessibility](https://github.com/jakubkrehel/skills/tree/267330e/skills/better-accessibility) · 커밋 `267330e` · MIT | practice | 키보드 위젯 계약(tabindex, roving tabindex, APG 패턴, inert, SPA 라우트 포커스)과 폼 접근성(autocomplete, inputmode, disabled와 aria-disabled 구분) 실무 지침이다 | 고정 하한값이나 "반드시 이 패턴" 같은 단정은 하드 게이트 문맥(WCAG 근거가 있는 것)에만 남기고, 나머지는 프로젝트 계약·관찰 후보로 낮춘다 | 실제 키보드 탐색과 스크린리더로 각 위젯의 계약을 재현한다 |
| SKILL-BETTER-COLORS | [jakubkrehel/skills — skills/better-colors](https://github.com/jakubkrehel/skills/tree/267330e/skills/better-colors) · 커밋 `267330e` · MIT | practice | 색 램프 생성, APCA 참고, 그라디언트 보간 공간, 다크모드 재조정에 대한 실무 절차다 | APCA는 WCAG 2 대비를 대체하는 규범이 아니라 보조 진단으로만 쓴다(APCA-STATUS 참고). 색의 문화적 의미는 원문(주로 서구 관례)을 그대로 쓰지 않고 ko-KR 관례로 다시 쓴다 | 실제 배경·전경 조합에서 WCAG 2 대비를 1차 판정 기준으로 측정한다 |
| SKILL-BETTER-LAYOUT | [jakubkrehel/skills — skills/better-layout](https://github.com/jakubkrehel/skills/tree/267330e/skills/better-layout) · 커밋 `267330e` · MIT | practice | RTL·논리 속성, 그루핑 비율, 점진적 공개 레시피, 컨트롤·정적 텍스트 구별에 대한 레이아웃 실무 지침이다 | 그루핑 비율 같은 수치는 휴리스틱이지 하드 게이트가 아니다. RTL 절은 RTL 로케일일 때만 연다(조건부) | 실제 좁은 폭·RTL 전환에서 레이아웃이 깨지지 않는지 확인한다 |
| SKILL-BETTER-TYPE | [jakubkrehel/skills — skills/better-typography](https://github.com/jakubkrehel/skills/tree/267330e/skills/better-typography) · 커밋 `267330e` · MIT | practice | text-wrap, 밑줄 메트릭, text-box trim, 문장부호, 잘린 텍스트 도달 수단에 대한 조판 실무 지침이다 | 고정 글자 크기·행간 하한 규율은 기각한다. 문장부호는 원문(영어 관례) 그대로 쓰지 않고 ko-KR 문장부호 규정(KO-PUNCT)으로 다시 쓴다 | 실제 다국어·긴 콘텐츠에서 줄바꿈과 밑줄 겹침을 렌더로 확인한다 |
| SKILL-BETTER-UI | [jakubkrehel/skills — skills/better-ui](https://github.com/jakubkrehel/skills/tree/267330e/skills/better-ui) · 커밋 `267330e` · MIT | practice | 아이콘 도메인 일관성, 동심 radius, 광학 정렬, 테두리 대신 그림자, 테마 전환 트랜지션 억제에 대한 UI 마감 실무 지침이다 | 특정 미학을 기본값으로 서술하지 않는다. 동심 radius 공식은 tokens.md의 기존 토큰 이름 체계를 따라 재정의 없이 참조한다 | 실제 컴포넌트 중첩에서 radius·그림자가 시각적으로 어긋나지 않는지 확인한다 |
| SKILL-BETTER-WRITING | [jakubkrehel/skills — skills/better-writing](https://github.com/jakubkrehel/skills/tree/267330e/skills/better-writing) · 커밋 `267330e` · MIT | practice | 용어 일관성, 톤과 위험의 매트릭스, 문장 조각 조립 금지, 오류·빈 상태 문구 내용에 대한 UX 카피 실무 지침이다 | "카피 finding은 소스만으로 충분하다"는 예외는 잘림·줄바꿈에 영향받는 카피(버튼·제목)에는 적용하지 않고 렌더로 확인한다. 문장 조각 조립 규칙은 한국어 조사 처리를 별도로 더해야 한다(원문은 영어 전제) | 실제 렌더에서 버튼·제목 카피가 잘리지 않는지 확인하고, 소스 검토는 나머지 카피에만 1차 판정으로 쓴다 |
| SKILL-INTERFACE-REVIEW | [jakubkrehel/skills — skills/interface-review](https://github.com/jakubkrehel/skills/tree/267330e/skills/interface-review) · 커밋 `267330e` · MIT | practice | diff 스코프 계산, 제거된 쪽 읽기, Introduced·Regression·Pre-existing 구분에 대한 변경 리뷰 절차다 | 파급 범위 컨슈머 5개 같은 고정 수치는 근거가 없어 절차만 채택한다 | 실제 diff에서 제거된 코드를 읽고 회귀 신호가 있는지 확인한다 |
| SKILL-INTERACTION-DESIGN | [wshobson/agents — plugins/ui-design/skills/interaction-design](https://github.com/wshobson/agents/tree/4236bb9/plugins/ui-design/skills/interaction-design) · 커밋 `4236bb9`(출처 미기재라 가장 널리 쓰이는 저장소를 선정) · MIT | practice | 토스트, 스켈레톤 시머, 스와이프, 당겨서 새로고침, 낙관적 업데이트 등 인터랙션 레시피와 스프링 프리셋·cubic-bezier 근사값이다 | 리플 이펙트를 기본값으로 삼지 않고 조건부로만 둔다. "질문 없이 코드 기본값으로 고정"하는 태도는 기각한다. 스프링 프리셋 수치는 실측 조정 시작값이다 | 실제 인터랙션에서 클린업 규율(리스너 해제 등)이 지켜지는지 확인하고, 스프링 값은 프로젝트에서 재조정한다 |

## WCAG 2.2·ARIA·플랫폼 출처 보강 (2026-09-24)

| ID | 출처·날짜 | 종류 | 실제로 지지하는 주장 | 적용 조건 / 잘못된 일반화 | 구체 검증 |
|---|---|---|---|---|---|
| WCAG-INPUT-PURPOSE | [SC 1.3.5 Identify Input Purpose](https://www.w3.org/TR/WCAG22/#input-purposes) · WCAG 2.2, 확인 2026-09-24 | normative | Level AA. 사용자 정보를 수집하는 입력 필드가 Input Purposes 목록에 정의된 목적을 가지면 프로그램적으로 식별 가능해야 한다 | 목록에 없는 임의 입력 필드까지 autocomplete 속성을 요구하는 근거로 확대하지 않는다 | 실제 폼 필드의 autocomplete·name 속성이 목록의 목적과 일치하는지 대조한다 |
| WCAG-NONTEXT | [SC 1.4.11 Non-text Contrast](https://www.w3.org/TR/WCAG22/#non-text-contrast) · WCAG 2.2, 확인 2026-09-24 | normative | Level AA. UI 컴포넌트와 그래픽 객체의 시각적 표현은 인접 색상과 3:1 이상 대비를 가져야 한다(비활성 컴포넌트·필수 로고·장식용 그래픽 등 예외 있음) | 모든 장식 요소에 3:1을 강제하지 않는다. 예외 목록을 먼저 확인한다 | 실제 컴포넌트 테두리·아이콘·포커스 링의 대비를 측정한다 |
| WCAG-HOVER | [SC 1.4.13 Content on Hover or Focus](https://www.w3.org/TR/WCAG22/#content-on-hover-or-focus) · WCAG 2.2, 확인 2026-09-24 | normative | Level AA. 호버·포커스로 나타나는 추가 콘텐츠는 Dismissible·Hoverable·Persistent 세 조건을 만족해야 한다 | 모든 툴팁·팝오버에 세 조건을 기계적으로 적용하기 전에 필수 콘텐츠인지부터 판정한다 | 실제 툴팁을 호버·포커스로 열고 마우스를 이동시켜 세 조건을 재현한다 |
| WCAG-FLASH | [SC 2.3.1 Three Flashes or Below Threshold](https://www.w3.org/TR/WCAG22/#three-flashes-or-below-threshold) · WCAG 2.2, 확인 2026-09-24 | normative | Level A. 웹 페이지는 1초 동안 3회를 초과해 깜빡이는 콘텐츠를 포함하지 않아야 한다(일반 섬광·적색 섬광 임계값 이하는 예외) | "깜빡임 초당 3회 이하"를 스타일 취향이 아니라 하드 게이트로 취급한다 | 자동 재생 애니메이션·로딩 인디케이터의 초당 깜빡임 횟수를 측정한다 |
| WCAG-LINK | [SC 2.4.4 Link Purpose (In Context)](https://www.w3.org/TR/WCAG22/#link-purpose-in-context) · WCAG 2.2, 확인 2026-09-24 | normative | Level A. 링크의 목적은 링크 텍스트만으로, 또는 링크 텍스트와 프로그램적으로 결정 가능한 맥락을 함께 사용해 판단할 수 있어야 한다(일반 사용자에게 모호한 경우는 예외) | "더보기"류 링크 텍스트를 무조건 금지하는 규범으로 확대하지 않는다. 주변 맥락으로 목적이 프로그램적으로 판단 가능하면 허용된다 | 스크린리더의 링크 목록 탐색에서 텍스트만으로 목적을 알 수 있는지 확인한다 |
| WCAG-FOCUS-OBSCURED | [SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum) · WCAG 2.2, 확인 2026-09-24 | normative | Level AA. 키보드 포커스를 받은 컴포넌트는 저자가 만든 콘텐츠(스티키 헤더·모달 등)에 완전히 가려지지 않아야 한다 | 완전 가림만 금지한다(일부 가림까지 금지하는 것은 AAA인 2.4.12다). AA와 AAA를 혼동하지 않는다 | 스티키 헤더·모달이 있는 화면에서 Tab 이동 시 포커스 요소가 완전히 가려지는지 확인한다 |
| WCAG-FOCUS-APPEAR | [SC 2.4.13 Focus Appearance](https://www.w3.org/TR/WCAG22/#focus-appearance) · WCAG 2.2, 확인 2026-09-24 | normative | Level AAA. 보이는 포커스 표시기는 비포커스 상태 대비 2 CSS px 두께 둘레 이상의 면적과 3:1 이상 대비를 가져야 한다(사용자 에이전트 기본 표시기이거나 저자가 수정하지 않은 경우는 예외) | AAA 기준이므로 하드 게이트가 아니라 프로젝트 계약(고대비·접근성 강화 프로젝트)으로 채택한다 | 커스텀 포커스 링의 두께·대비를 실제로 측정한다 |
| WCAG-LABEL-NAME | [SC 2.5.3 Label in Name](https://www.w3.org/TR/WCAG22/#label-in-name) · WCAG 2.2, 확인 2026-09-24 | normative | Level A. 텍스트나 텍스트 이미지를 포함한 라벨을 가진 UI 컴포넌트는 접근 가능한 이름에 시각적으로 표시된 텍스트를 포함해야 한다 | 아이콘 전용 버튼처럼 시각 라벨이 없는 컴포넌트는 적용 대상이 다르다(별도로 aria-label 등을 판단) | 시각 라벨과 스크린리더가 읽는 접근 가능한 이름을 대조한다 |
| WCAG-DRAG | [SC 2.5.7 Dragging Movements](https://www.w3.org/TR/WCAG22/#dragging-movements) · WCAG 2.2, 확인 2026-09-24 | normative | Level AA. 드래그 동작으로 작동하는 모든 기능은 드래그 없이 단일 포인터로도 수행할 수 있어야 한다(드래그가 필수적이거나 사용자 에이전트가 결정하고 저자가 수정하지 않은 기능은 예외) | 브라우저 기본 스크롤·당겨서 새로고침처럼 사용자 에이전트가 결정하는 동작까지 대체 수단을 요구하지 않는다 | 슬라이더·정렬·스와이프 삭제 등 커스텀 드래그 기능에 탭·버튼 등 단일 포인터 대안이 있는지 확인한다 |
| WCAG-HELP | [SC 3.2.6 Consistent Help](https://www.w3.org/TR/WCAG22/#consistent-help) · WCAG 2.2, 확인 2026-09-24 | normative | Level A. 웹 페이지 집합 안에서 반복되는 도움 메커니즘(연락처·챗봇·자가 도움 등)은 사용자가 변경을 시작하지 않는 한 다른 콘텐츠와 상대적으로 같은 순서에 나타나야 한다 | 도움 메커니즘이 아예 없는 사이트에 새로 만들라고 요구하는 기준이 아니다. 이미 있는 도움 메커니즘의 위치 일관성만 요구한다 | 여러 화면에서 고객센터·챗봇 버튼의 상대적 위치가 같은지 확인한다 |
| WCAG-REDUNDANT | [SC 3.3.7 Redundant Entry](https://www.w3.org/TR/WCAG22/#redundant-entry) · WCAG 2.2, 확인 2026-09-24 | normative | Level A. 같은 프로세스에서 이전에 입력했거나 제공된 정보를 다시 입력하도록 요구할 때는 자동으로 채우거나 선택할 수 있게 해야 한다(재입력이 필수적이거나 보안상 필요하거나 정보가 더 이상 유효하지 않은 경우는 예외) | 결제 단계의 보안 재확인처럼 예외에 해당하는 재입력까지 위반으로 판정하지 않는다 | 다단계 폼에서 같은 값을 다시 입력해야 하는 필드가 있는지, 자동 채움이 되는지 확인한다 |
| WCAG-AUTH | [SC 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/TR/WCAG22/#accessible-authentication-minimum) · WCAG 2.2, 확인 2026-09-24 | normative | Level AA. 인증 과정의 어떤 단계도 대안·보조 메커니즘·객체 인식·개인 콘텐츠 인식 중 하나를 제공하지 않는 한 인지 기능 시험(비밀번호 암기, 퍼즐 풀이 등)을 요구해서는 안 된다 | 모든 비밀번호 로그인을 금지하는 기준이 아니다. 브라우저 자동완성·비밀번호 관리자 지원처럼 대안이 있으면 허용된다 | 로그인·본인 확인 흐름에서 붙여넣기 차단이나 자동완성 차단이 있는지 확인한다 |
| WCAG-NRV | [SC 4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG22/#name-role-value) · WCAG 2.2, 확인 2026-09-24 | normative | Level A. 커스텀 UI 컴포넌트의 이름과 역할은 프로그램적으로 결정 가능해야 하고, 사용자가 설정할 수 있는 상태·속성·값은 프로그램적으로 설정 가능해야 하며, 변경 알림이 보조 기술에 제공되어야 한다 | 네이티브 HTML 컨트롤에는 대개 자동으로 충족되며, 커스텀 컴포넌트(div로 만든 버튼 등)에 특히 적용된다. 예외·세부 문구는 Understanding 문서로 재확인 필요 | 스크린리더로 커스텀 컴포넌트의 이름·역할·상태 변경이 공지되는지 확인한다 |
| WCAG-STATUS | [SC 4.1.3 Status Messages](https://www.w3.org/TR/WCAG22/#status-messages) · WCAG 2.2, 확인 2026-09-24 | normative | Level AA. 마크업 언어로 구현된 콘텐츠에서 상태 메시지는 포커스를 받지 않고도 보조 기술이 사용자에게 전달할 수 있도록 role이나 속성으로 프로그램적으로 결정 가능해야 한다 | 포커스를 받는 오류 대화상자 등 4.1.2로 이미 다뤄지는 경우와 겹치지 않게 구분한다(정확한 예외 문구는 Understanding 문서 재확인 필요) | 폼 제출 성공·실패 메시지가 라이브 리전으로 스크린리더에 전달되는지 확인한다 |
| ARIA-APG | [WAI-ARIA Authoring Practices Guide — Patterns](https://www.w3.org/WAI/ARIA/apg/patterns/) · 확인 2026-09-24 | practice | 탭·메뉴버튼·콤보박스·리스트박스·모달 대화상자 등 위젯별 권장 키보드 상호작용(Tab·화살표·Home/End·Escape 동작)을 정의한다 | ARIA role만 붙이고 키보드 동작을 구현하지 않으면 패턴을 따랐다고 할 수 없다. 네이티브 HTML 요소로 같은 동작을 얻을 수 있으면 네이티브를 우선한다 | 실제 키보드만으로 각 위젯 패턴의 상호작용을 재현한다 |
| APCA-STATUS | [APCA-W3 GitHub README](https://github.com/Myndex/apca-w3/blob/master/README.md) · [WCAG 3.0 Working Draft](https://www.w3.org/TR/wcag-3.0/)(2026-09-10) · 확인 2026-09-24 | practice | WCAG 3.0 초안(2026-09-10)은 대비 알고리즘을 아직 정하지 않았다고 명시하며 APCA를 이름으로 언급하지 않는다. APCA 자체는 버전 0.1.9(98G4g)의 베타 상태이며 저장소 README가 "미래 표준을 위해 평가 중"이라고 스스로 밝힌다 | APCA를 이미 채택된 규범적 대비 알고리즘처럼 서술하지 않는다. WCAG 2 대비(4.5:1/3:1)가 여전히 하드 게이트이고 APCA는 보조 진단으로만 쓴다 | 대비 판정은 WCAG 2 공식(WCAG-READ)으로 먼저 하고, APCA 값은 참고 수치로만 병기한다 |
| WWDC-FLUID | [Designing Fluid Interfaces — WWDC 2018, 세션 803](https://developer.apple.com/videos/play/wwdc2018/803/) · Apple Developer, 확인 2026-09-24 | practice | iPhone X 세대 제스처 인터페이스에서 인터럽트 가능성(현재 렌더값에서 재시작), 속도 인계, 멀티모달 피드백을 설계한 Apple 엔지니어의 발표 내용이다 | Apple의 자체 설계 사례를 모든 플랫폼·모든 브리프에 적용해야 할 표준으로 확대하지 않는다. Apple풍 미학이 브리프에 맞을 때만 조건부로 연다 | 발표에서 제시한 구현 아이디어를 실제 코드로 재현한 뒤 체감 반응성을 확인한다 |
| KO-PUNCT | [한글 맞춤법 문장 부호 개정안 — 국립국어원](https://www.korean.go.kr/front/etcData/etcDataView.do?mn_id=46&etc_seq=431) · 고시 2014-12-05 · 시행 2015-01-01 · 확인 2026-09-24 | normative | 문화체육관광부가 고시한 한글 맞춤법 개정으로 마침표·물음표·느낌표·쉼표·가운뎃점·쌍점·빗금·따옴표(2종)·괄호(3종)·낫표(2종)·화살괄호(2종)·줄표·붙임표·물결표 등 문장 부호 용법을 정한다 | 영어 문장부호 관례(예: 세미콜론 용법)를 한국어 카피에 그대로 옮기지 않는다. 이 개정안이 다루지 않는 세부 조항(예: 줄임표 표기 형태)은 별도 확인 없이 단정하지 않는다 | 한국어 UI 카피의 마침표·쉼표·따옴표 사용을 이 개정안 목록과 대조한다 |
| KO-KRDS | [KRDS 컴포넌트 — 버튼 · 행정안전부](https://www.krds.go.kr/html/site/component/component_05_02.html) · 확인 2026-09-24 | practice | 행정안전부 KRDS(Korea Design System) 공식 가이드는 버튼 텍스트 라벨을 원칙적으로 동사형으로 제공하도록 규정하며, "완료·닫기·취소·추가·삭제"처럼 일반적으로 통용되는 경우는 예외로 둔다 | 정부 서비스 가이드를 모든 상업 제품의 카피 규범으로 강제하지 않는다. 이 스킬에서는 버튼 카피의 참고 관례로만 쓴다 | 실제 버튼 라벨이 동사형인지, 예외에 해당하는 일반 동작인지 확인한다 |
| KO-TOSS-WRITING | [토스가 글을 쓰는 방법 — toss.tech](https://toss.tech/article/8-writing-principles-of-toss) · 확인 2026-09-24 | practice | 토스 기술 블로그가 공개한 글쓰기 코어밸류 5가지(Clear·Concise·Casual·Respect·Emotional)와 실행 원칙 8가지(예측 가능한 힌트, 군더더기 제거, 핵심 메시지 집중 등)다 | 한 기업의 브랜드 보이스를 모든 한국어 제품의 보편 톤으로 확대하지 않는다. 톤 슬롯이 다른 브리프(공공·금융 격식체 등)에는 그대로 적용하지 않는다 | 실제 카피가 원칙과 충돌하는지(불필요한 격식체, 숨은 감정 무시 등)를 문장 단위로 대조한다 |
| WEB-BASELINE | [webstatus.dev](https://webstatus.dev/) · [MDN Baseline](https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility) · 확인 2026-09-24 | practice | 특정 CSS·JS 기능이 Limited/Newly available/Widely available 중 어느 지원 상태인지, 각 브라우저가 언제 지원을 시작했는지를 추적한다. Widely available은 Newly available(전 주요 엔진 지원 완료) 시점으로부터 약 30개월이 지나야 붙는다 | 한 번 확인한 지원 상태를 날짜 없이 영구 사실처럼 인용하지 않는다. webstatus.dev와 MDN이 다른 값을 보일 때(예: text-box-trim)는 더 최신 확인일 쪽에 주의 문구를 남긴다 | 기능을 채택하기 전 webstatus.dev나 MDN의 현재 상태와 확인일을 다시 조회한다 |
| PLATFORM-HIG-TARGET | Apple Human Interface Guidelines, Layout(터치 타깃 지침) · developer.apple.com/design/human-interface-guidelines/layout · **URL 미확인** — 2026-09-24 WebFetch로 재확인을 시도했으나 페이지가 클라이언트 사이드 렌더링(SPA)이라 본문을 가져오지 못했고, 이 세션의 WebSearch 예산이 소진돼 대체 인용을 확보하지 못했다 | bibliography | Apple HIG가 iOS 컨트롤의 최소 히트 영역을 44×44pt로 권장한다는 것은 업계에 널리 알려진 수치이지만, 이 세션에서는 1차 문서 원문 문구를 직접 확인하지 못했다 | 브리프가 모바일 앱 수준을 요구할 때만 적용하는 **프로젝트 계약**이며, WCAG AA의 보편 요건(24×24 CSS px, [WCAG-TARGET])으로 확대하지 않는다 | 다음 세션에서 Apple Developer 사이트를 JS 렌더링 가능한 브라우저 도구로 재조회해 정확한 문구·URL을 확정한다 |
| PLATFORM-M3-TARGET | Material 3, Accessible design 또는 Layout 섹션 · m3.material.io · **URL 미확인** — 2026-09-24 WebFetch로 재확인을 시도했으나 페이지가 클라이언트 사이드 렌더링(SPA)이라 본문을 가져오지 못했고, 이 세션의 WebSearch 예산이 소진돼 대체 인용을 확보하지 못했다 | bibliography | Material 3가 터치 타깃 최소 크기를 48×48dp로 권장한다는 것은 업계에 널리 알려진 수치이지만, 이 세션에서는 1차 문서 원문 문구를 직접 확인하지 못했다 | 브리프가 모바일 앱 수준을 요구할 때만 적용하는 **프로젝트 계약**이며, WCAG AA의 보편 요건(24×24 CSS px, [WCAG-TARGET])으로 확대하지 않는다 | 다음 세션에서 m3.material.io를 JS 렌더링 가능한 브라우저 도구로 재조회해 정확한 문구·URL을 확정한다 |

## 사용할 때

결정마다 `출처 ID / 지지 주장 / 적용 조건 / 잘못된 일반화 / 구체 검증 / 예시 결정`을 남긴다. 예: `WCAG-TARGET / 24×24 AA 최소 / 포인터 대상 / 44px 의무라고 확대하지 않음 / 실제 버튼 box 측정 / 작은 아이콘을 24px 이상 hit area로 확장`.

## 교과서 입문·정독 범위

바우하우스·시각디자인 원전의 관점과 확인 범위는 [visual-design-lineage.md](visual-design-lineage.md), 미학·읽기·그래픽 지각 논문의 연구 조건은 [visual-perception-research.md](visual-perception-research.md)에서 질문에 맞는 항목만 읽는다. 두 문서는 출처별 확인 범위와 적용 한계를 보존하는 이 장부의 심화 읽기 경로다. 실무 적용 제안과 원문이 보고한 결과를 구분한다.

다음은 **서지 확인된 읽기 경로**다. 이 목록은 본문을 읽었다거나 특정 페이지의 규칙을 채택했다는 주장이 아니다. 입문에서는 편집·그리드·글자 형태의 어휘를 얻고, 실제 프로젝트에 인용할 때는 확보한 판본과 페이지를 다시 기록한다.

1. Bringhurst, *The Elements of Typographic Style* — 조판 어휘와 본문 리듬의 정독 출발점 [BRINGHURST].
2. Lupton, *Thinking with Type*, 3rd ed. — 타입을 구성·위계·이미지와 연결하는 입문 [LUPTON].
3. Müller-Brockmann, *Grid Systems in Graphic Design* — grid의 역사적·실무적 어휘 [MULLER-BROCKMANN].
4. Meggs 계열의 그래픽 디자인 역사 저작은 별도 판본 서지와 페이지 근거를 확보한 뒤 역사 맥락용으로 추가한다. 이 ledger에서는 미확인 판본의 내용을 인용하지 않는다.