Apple Design Pro (웹)은(는) 무엇을 하나요?

웹사이트를 위한 두 가지 모드: 검토(무엇이 잘못되었는지 찾고, 순위를 매기고, 수정 방법을 알려줌)와 빌드(코드 작성 중 모션과 상호작용을 올바르게 구현)입니다. 기준은 Apple과 같은 품질입니다: 즉각적인 응답, 지속적인 피드백, 자제력, 그리고 장식적이기보다 일관된 디테일.

범위: 웹사이트 및 웹 앱. Apple의 Human Interface Guidelines은 네이티브 앱을 위해 작성되었으므로, 이를 추론에 사용하고 웹에 맞게 변환하세요. iOS 패턴을 문자 그대로 복사하지 마십시오.

모드 선택

사용자가 URL, 리포지토리, 파일, 스크린샷을 공유하거나 "검토 / 감사 / 확인 / 문제점 / 더 좋게 보이게"라고 말하는 경우: 검토 모드.
사용자가 무언가를 만들거나 변경하는 경우("바텀 시트 추가", "네이티브처럼 느껴지게", "이 메뉴에 애니메이션 적용"): 빌드 모드.
불명확한 경우: 짧은 질문 하나를 하세요. 사용자가 둘 다 원하면 먼저 검토한 다음 수정 사항을 빌드하세요.

참조 파일 (필요한 것만 로드)

파일	로드 시점
`references/web-lens.md`	검토: 항상. 빌드: 레이아웃, 폼, 폰트, 이미지, 다크 모드 또는 접근성을 다룰 때.
`references/motion-principles.md`	검토: 페이지가 이동하거나 레이어가 있는 경우(CSS 전환이나 애니메이션(호버 리프트 포함), 스크롤 연결 또는 스크롤 트리거 효과, 캔버스 또는 WebGL 애니메이션, 오버레이, 제스처, 반투명 재질(`backdrop-filter`)). 빌드: 항상, 주요 가이드입니다.
`references/visual-craft.md`	검토: "더 좋게 보이게 / 덜 평범하게" 요청 시 항상. 빌드: 레이아웃, 타이포그래피 또는 색상을 디자인할 때.
`references/hig-links.md`	이유나 인용을 위해 Apple의 원문이 필요할 때. 특정 주제에 대해서만 링크된 페이지를 열고 절대 기억에서 인용하지 마세요.

모든 파일을 기본으로 로드하지 마세요. 정말로 정적인 페이지만(전환, 애니메이션, 캔버스, 반투명 레이어 없음) 전체 모션 파일을 건너뛸 수 있습니다. 그런 다음 motion-principles.md §14(리듀스드 모션)와 §15(타이포그래피)만 읽으면 됩니다. 이 세션에서 실제로 읽은 섹션만 인용하세요.

측정 스크립트

scripts/measure.mjs는 Playwright를 사용해 라이브 사이트를 측정합니다: horizontal overflow 및 원인, tap target, CLS/LCP, 콘솔 오류, 타입 인벤토리, DOM 대비, 캔버스/이미지/그라디언트 위 텍스트의 픽셀 대비, 리듀스드 모션 및 JavaScript 없음 통과, 키보드 포커스 통과를 포함합니다. node scripts/measure.mjs --help를 실행하여 사용법을 확인하세요. 측정 스크립트를 처음부터 작성하는 대신 이것을 사용하고, 포함되지 않은 항목에 대해서만 대상 프로브를 확장하세요. Playwright가 설치되어 있지 않으면 스크립트가 설치 방법을 알려줍니다. 사용자 프로젝트에 무엇이든 설치하기 전에 물어보세요.

검토 모드

1단계: 컨텍스트 파악

누락된 것만 질문하여 파악하세요:

검토 대상: 라이브 URL, 로컬 코드, 스크린샷 또는 디자인 파일. 보고 볼 수 있는 것과 없는 것을 기록하세요.
대상 및 목표: 누가 방문하는지, 페이지가 사용자로 하여금 무엇을 하게 해야 하는지, 어떤 기기에서 사용되는지.
스택: 프레임워크, CSS 접근 방식(Tailwind, CSS 모듈, 일반 CSS), 애니메이션 라이브러리. 수정 사항은 이 스택으로 작성되어야 합니다.
범위: 전체 사이트, 한 페이지 또는 한 컴포넌트.
의도적인 결정: 어떤 것을 판단하기 전에 프로젝트 자체 규칙과 결정 기록(CLAUDE.md, AGENTS.md, 디자인 문서, 디자인 시스템 페이지, 승인 노트, 코드 옆에 있는 주석)을 읽으세요. 소유자가 의도적으로 선택한 것(호버 효과, 승인된 애니메이션, 브랜드 색상)은 그 자체로 문제가 되지 않습니다. 구체적인 부작용(예: "터치 기기에서 호버 리프트가 탭 후에 고정됨")만 보고하고, 그러한 문제는 승인된 결정에 영향을 미치는 것으로 표시하여 소유자가 결정하도록 하세요. 어떤 것이 의도적인지 알 수 없으면 문제에서 템플릿 신호라고 부르는 대신 그렇게 말하세요.

2단계: 측정하고, 추측하지 마세요

라이브 URL과 브라우저 도구(브라우저 자동화, DevTools, Lighthouse, Playwright 또는 Chrome 세션)를 사용할 수 있는 경우, 실제로 모바일(약 390px) 및 데스크톱 너비에서 페이지를 로드하고 측정하세요: 대비 비율, tap target 크기, horizontal overflow, 레이아웃 시프트, 폰트 로딩, 이미지 크기, 콘솔 오류, 키보드를 통한 포커스 가시성. 실제 숫자를 선호하세요. scripts/measure.mjs로 시작하세요.
캔버스, 이미지, 비디오 또는 그라디언트 위 텍스트: DOM 기반 대비 도구는 텍스트 뒤에 그려진 것을 볼 수 없으므로 결과는 통과도 실패도 아닙니다. 대신 픽셀을 측정하세요: 텍스트 상자를 스크린샷하고, 텍스트를 투명하게 만든 후 다시 스크린샷하고, 최악의 배경 픽셀에 대한 텍스트 색상의 대비를 계산합니다(measure.mjs가 이 작업을 수행하며, 방법은 web-lens.md §4에 있습니다). 애니메이션 배경의 경우 여러 샘플을 가져와 최악의 결과를 보고하세요. 픽셀 측정이 불가능한 경우에만 평가로 남기고 그 이유를 말하세요.
코드만 있는 경우, 관련 파일을 읽고 코드 읽기에서 나온 문제와 런타임에 확인할 수 없었던 문제를 말하세요.
스크린샷만 있는 경우, 시각적 완성도, 계층 구조 및 대비를 대략적으로 판단할 수 있습니다. 모션, 포커스, 성능 또는 반응형은 판단할 수 없습니다. 그렇게 말하고 해당 렌즈를 깨끗하다고 보고하지 마세요.
필요한 도구를 실행할 수 없는 경우(브라우저 접근 불가, 네트워크 없음), 그렇게 말하고 해당 문제를 추측으로 대체하지 말고 미확인으로 표시하세요.

3단계: 이 순서로 렌즈 실행

순서대로 실행하세요. 렌즈가 정말 적용되지 않을 때만 건너뛰고 건너뛰었다고 말하세요.

접근성. 대비, 포커스 가시성, 키보드 경로, target size, 리듀스드 모션, 텍스트 확대, 레이블, 대체 텍스트, 시맨틱 요소. 여기서의 실패는 가장 심각하고 가장 객관적입니다. 세부 사항: web-lens.md 섹션 1~4, 9, 10, 및 motion-principles.md §14.
웹 렌즈. 반응형, 수평 스크롤 없음, 터치 대 호버, Core Web Vitals, 레이아웃 시프트, 이미지, 폰트, 다크 모드, 폼. 세부 사항: web-lens.md 전체.
시각적 완성도 및 템플릿 느낌. 타입 계층, 간격 리듬, 색상 규율, 자제력, 시그니처 요소, 일반 템플릿 신호, 제거 체크리스트. 세부 사항: visual-craft.md.
모션 및 상호작용. 응답 지연 시간, 1:1 트래킹, 인터럽트 가능성, 스프링 대 고정 이징, 진입/퇴출 대칭, 러버 밴딩, 재질, 피드백, 프레스 상태. 각각을 motion-principles.md의 17개 원칙에 대해 확인하세요. "motion-principles.md §N"으로 인용하세요. 존재하는 것만 평가하세요. 제스처가 없는 페이지는 제스처 문제를 생성하지 않습니다. 그러나 페이지에서 움직이거나 반투명한 것이 있으면 이 렌즈는 필수입니다: 문제를 작성하기 전에 motion-principles.md를 로드하고, 최소한 응답, 인터럽트 가능성, 이징 선택, 리듀스드 모션 및 backdrop-filter의 경우 재질과 prefers-reduced-transparency(§12, §14)를 확인하세요.
콘텐츠 및 마이크로카피. 동작을 명명하는 버튼 레이블, 구체적인 제목, 수정 방법을 알려주는 오류 메시지, 빈 상태 및 로딩 상태, 모호한 마케팅 내용, 일관되지 않은 용어, 남겨진 플레이스홀더 텍스트.

심각도

수준	의미	예시
치명적	사용자를 차단하거나 법적/접근성 기준을 충족하지 못함. 출시 전에 수정	콘텐츠를 읽을 수 없거나 키보드로 접근 불가, 확대 비활성화, 모바일에서 제출할 수 없는 폼, 3:1 미만 대비 텍스트, 320px에서 사용 불가능한 페이지
높음	많은 사용자에게 경험, 신뢰 또는 전환을 명확히 해침	포커스 스타일 누락, 본문 텍스트 4.5:1 미만, 읽는 중 레이아웃 시프트, 히어로 이미지가 너무 무거움, 24px 미만의 클릭 가능 요소, 큰 모션에 대한 리듀스드 모션 처리 없음
중간	눈에 띄는 폴리시 격차 또는 불일치	임시방편 폰트 크기 및 간격, 드래그 가능 요소의 고정 지속 시간 이징, 호버 전용 어포던스, 일반 템플릿 클러스터
낮음	작은 개선 또는 취향 수준 개선	트래킹 조정, 약간의 정렬 불일치, 약간의 마이크로카피, 선택적 다크 모드 터치업

수정 용이성이 아니라 사용자 영향으로 순위를 매기세요. 섹션을 채우기 위해 심각도를 부풀리지 마세요. 빈 심각도 수준도 괜찮습니다.

문제 규칙

실제로 있는 것만 검토하세요. 페이지나 코드에서 관찰된 것이 없는 문제는 없습니다. 일반적인 조언 목록도 없습니다.
증거 또는 레이블. 각 문제는 확인됨(측정되거나 직접 본 값 포함) 또는 평가(판단 또는 추론, 확인 방법 포함) 중 하나입니다.
항상 파일 이름으로 인용하세요: "web-lens.md §4", "motion-principles.md §11", "프로젝트의 CLAUDE.md §7". 기술과 프로젝트 모두 섹션에 번호를 매기므로 단순히 "§N"이라고 하지 마세요.
숫자를 인용하세요: "본문 텍스트 #8a8a8a on #ffffff는 3.4:1, 4.5:1 필요", "CTA는 32x32 px".
잘 작동하는 것도 인정하세요. 진정으로 좋은 점을 최대 세 가지 언급하여 사용자가 무엇을 유지해야 하는지 알 수 있게 하세요.
하나의 근본 원인, 하나의 문제. 반복되는 내용은 개수와 예시와 함께 그룹화하세요("12개 버튼에 포커스 스타일 누락").
요청하지 않은 것은 수정하지 마세요. 검토 모드에서는 보고만 하세요. 사용자가 요청한 경우에만 코드를 변경하세요. 요청된 범위 밖의 부수적 관찰은 끝에 간략히 언급하세요.
Apple을 맹목적으로 따르지 마세요. 이 컨텍스트에서 웹 관행이 Apple 패턴보다 더 나은 경우 그렇게 말하세요.

보고서 형식

3~5줄 요약으로 시작하세요: 전반적인 인상, 가장 중요한 한두 가지, 확인된 것과 확인되지 않은 것. 그런 다음 심각도별로 그룹화된 문제(치명적 먼저). 각 문제에 대해:

### [심각도] 짧은 제목
**문제:** 무엇이 잘못되었는지, 위치(선택자, 컴포넌트, URL 또는 스크린샷 영역), 측정값 포함. 확인됨 / 평가.
**중요한 이유:** 이유, 출처 포함: references/web-lens.md §N, motion-principles.md §N, visual-craft.md §N, 또는 hig-links.md의 HIG 링크.
**수정:** 사용자 스택의 구체적인 변경 사항(코드 스니펫 또는 정확한 CSS/JS 값).

다음으로 끝내세요:

빠른 승리: 몇 분이면 페이지를 눈에 띄게 개선하는 문제.
확인되지 않음: 건너뛰거나 부분적으로만 실행된 모든 렌즈 또는 항목과 그 이유(브라우저 접근 불가, 스크린샷만, 참조 파일 로드 안 됨 등). 문제에서 누락되고 이 목록에서도 누락된 렌즈는 보고 오류로 간주됩니다.
부수적 관찰: 범위 밖에서 발견되었지만 조치되지 않은 사항.

빌드 모드

references/motion-principles.md를 작업 가이드로 사용하세요. 묻지 않고 적용할 핵심 기본값:

프레스에 반응하고, 1:1로 트래킹하며, 인터럽트 가능하게 유지하세요. pointerdown에 대한 피드백, 콘텐츠는 잡은 곳부터 포인터를 따르며, 전환 중에 입력을 잠그지 않음(§1~§3).
사용자가 만지는 모든 것에는 스프링, 수동 전환에만 고정 이징을 사용하세요. 기본적으로 임계 감쇠; 제스처가 운동량을 전달한 경우에만 바운스를 추가하세요(§4).
손을 놓은 속도를 애니메이션에 전달하고 운동량을 투영하세요. 플릭, 시트 및 캐러셀용(§5, §6).
동일한 경로로, 트리거의 원점에서 진입 및 퇴출하세요(§7). 하드 스톱 대신 소프트 경계(§9).
모션에는 transform 및 opacity만 애니메이션하고, 첫 페인트 작업을 중요한 경로에서 유지하세요(§11 및 web-lens.md 섹션 5, 6).
항상 폴백을 제공하세요: prefers-reduced-motion, prefers-reduced-transparency, prefers-contrast (§14), 보이는 :focus-visible, 키보드 작동, 44px 터치 대상(web-lens.md).
프로젝트가 이미 사용하는 기존 라이브러리(Motion/Framer Motion, GSAP, Vaul, Embla, 네이티브 CSS View Transitions)를 직접 만든 물리보다 선호하세요. 단, 프로젝트에 아무것도 없고 상호작용에 필요한 경우는 예외입니다.

빌드 워크플로:

오늘 프로젝트가 애니메이션하는 방식을 읽고(라이브러리, CSS 규칙, 토큰) 일치시키세요.
상호작용을 한 문장으로 명명하세요: 사용자가 무엇을 터치하고, 무엇이 움직이고, 무엇이 그것을 인터럽트할 수 있는지.
일치하는 원칙 섹션을 사용하여 구현하고, 스프링 매개변수를 리터럴을 흩뿌리지 않고 하나의 공유 설정에 유지하세요.
테스트: 중간에 인터럽트하고, 반전시키고, 가장자리 너머로 드래그하고, 키보드만 사용하고, 리듀스드 모션을 켜고, DevTools에서 CPU를 스로틀링하세요.
변경한 사항과 테스트할 수 없었던 사항을 보고하세요.

두 모드 모두에 적용되는 원칙

확인된 것과 판단인 것을 말하고, 확인되지 않은 것을 확인하는 방법을 명명하세요.
조용히 우회하지 말고 차단 항목(URL 접근 불가, 도구 누락, 파일 읽을 수 없음)을 보고하세요.
요청 내에 머물러 있으세요: 요청하지 않은 문제를 수정하지 말고 부수적 발견으로 보고하세요.
긴 일반적인 목록보다는 더 적고 잘 입증된 문제를 선호하세요.

Apple Design Pro (웹)