designpaca/packages/skill/references/design-foundations.md

# design foundations — 근거를 결정으로 바꾸는 법

교과서 요약집이 아니다. 각 원칙은 실제 과업에서 무엇을 확인할지 정하는 도구다. 출처의 상세 범위는 [evidence ledger](evidence-ledger.md)를 따른다.

## 1. 먼저 성공 과업을 한 문장으로 적는다

`누가 / 어떤 맥락에서 / 무엇을 / 어떤 위험 없이 끝내야 하는가`를 쓴다. 시각 방향은 그 뒤에 고른다. 첫 화면의 주장은 이름, 가치, 다음 행동을 모두 억지로 넣는 공식이 아니라 이 과업의 다음 결정을 충분히 설명하는지로 판정한다.

| 원칙 | 지지 주장 | 적용 조건 | 잘못된 일반화 | 구체 검증 | 예시 결정 |
|---|---|---|---|---|---|
| 관련성 | 불필요한 정보는 관련 정보의 가시성과 경쟁한다 [NNG-HEUR] | 첫 선택과 오류 복구가 중요한 화면 | 요소 수가 적을수록 좋다 | 대표 과업에서 필요한 정보가 같은 화면에 있는지 본다 | 가입 전 가격 세부는 요약+상세 링크로 분리 |
| 위계 | 크기·명도·위치·여백은 함께 작동해 시선을 만든다 [NNG-VISUAL] | 스캔이 필요한 랜딩·목록 | h1:h2 비율 하나로 판정 가능 | 회색조 캡처를 짧게 보고 제목·주요 행동·본문의 읽는 순서를 기록한다 | CTA만 색 대비, 섹션 제목은 공간 대비 |
| 근접성·유사성·공통 영역 | 가까움, 공통 외곽, 유사한 표식은 관계를 읽히게 할 수 있다 [GESTALT] | 반복 모듈과 복잡한 정보 | 모든 영역이 12열 중앙 정렬이거나 카드여야 한다 | 카드·표·CTA의 묶음·분리·선택 상태를 회색조와 실제 과업에서 본다 | 사양과 가격은 한 group, 관련 도움말은 다음 group |
| 정렬과 그리드 | 일관된 column·gutter·breakpoint는 제품 UI의 정렬 기준을 제공한다 [IBM-GRID] | 여러 화면의 반복 표면 | Carbon 격자나 특정 열 수가 보편 정답이다 | 콘텐츠 폭, 정렬선, 작은 폭의 재배치를 검증한다 | 읽는 surface와 비교 surface에 다른 폭 토큰을 둔다 |
| 직접 조작 | 멀수록 작을수록 조준이 느리고 오류가 늘 수 있다 [FITTS] | 빈번한 포인터 행동 | 모든 버튼을 크게 만들면 해결된다 | 실제 hitbox, 거리, 인접 오탭을 관찰한다 | 아이콘만 누르게 하지 않고 라벨까지 클릭 가능하게 |
| 단서와 선택 설계 | 행동 단서는 지각 가능해야 하고, 선택 비용은 선택지 수만 아니라 구분·라벨·목표에 좌우된다 [NORMAN-SIGN, HICK, KRUG] | 내비·필터·설정 | 7±2로 메뉴 수를 제한한다 | 사용자가 목표 항목을 찾는 시간·오류를 본다 | 9개 항목을 사용자 과업별 3개 묶음으로 재분류 |
| 기억보다 인지 | 화면의 상태·다음 행동·되돌림을 드러내면 기억 부담을 낮춘다 [NNG-HEUR, MILLER] | 다단계·파괴적 행동 | 모든 것을 항상 보여야 한다 | 뒤로가기·오류·재진입에서 상태가 복구되는지 시험한다 | 업로드 후 파일명·교체·삭제를 같은 표면에 노출 |
| 인지 부하 | 과업에 필요 없는 기억·변환·탐색 단계를 줄이면 문제 해결 부담을 낮출 수 있다 [COGNITIVE-LOAD] | 낯선 절차·설정·비교 | 모든 정보를 숨기거나 단계를 줄이면 더 쉽다 | 첫 사용자 과업의 오류·되돌림·완료 시간을 비교한다 | 설정 값을 군집화하고 선택 결과를 바로 옆에 보인다 |
| 간결함 ≠ 미니멀리즘 | 목적을 드러내는 것이 목표이지 요소를 지우는 것 자체가 목표가 아니다. 모든 것을 한 곳에 파묻으면 미니멀해 보여도 단순하지 않다 [SKILL-APPLE-DESIGN] | 정보 밀도를 낮추는 리디자인 전반 | 요소 수를 줄이면 항상 더 쉬워진다 | 핵심 과업에 필요한 정보·컨트롤이 실제로 남아 위계로 정리됐는지 확인한다 | 옵션을 숨기지 않고 흔한 경로를 먼저, 고급 옵션은 한 단계 더 깊이 배치 |
| 구체적 라벨 | 직접적이고 구체적인 라벨이 안전하고 일반적인 라벨보다 예측 가능하다 — 내비는 내용물로 짓고("진행 상황", "보관함") "홈" 같은 우산 용어를 피한다 [SKILL-APPLE-DESIGN] | 내비·탭·섹션 이름 짓기 | 라벨은 길고 설명적일수록 항상 낫다 | 사용자가 라벨만 보고 도착 화면을 예측할 수 있는지 시험한다 | "홈" 대신 그 화면이 실제로 보여주는 것으로 탭 이름을 정함 |

구체적 라벨 규칙을 내비 구조에 적용하는 방법은 [layout.md](layout.md)를 참조한다.

## 2. 접근성은 시각 스타일과 독립된 통과선이다

WCAG는 A·AA·AAA의 테스트 가능한 성공 기준이다. 제품의 목표 수준과 적용 법규·계약을 먼저 정하고, 장식적 선택이 그 기준을 넘어서는지 확인한다. AA는 일반적인 목표가 될 수 있지만, 이것만으로 모두에게 적합하다는 보증은 아니다 [WCAG-22].

- 텍스트 대비, 200% 확대, 320 CSS px reflow, 사용자 text-spacing, 포인터 target, 자동 움직임을 핵심 화면·상태별로 시험한다 [WCAG-READ, WCAG-TARGET, WCAG-MOTION].
- 모션 감소 선호에서는 움직임을 줄이되, 로딩·선택·오류 같은 상태 신호를 다른 방식으로 남긴다 [W3C-REDUCED].
- 스크린샷은 이 기준을 증명하지 못한다. 키보드·줌·사용자 스타일·보조기술 테스트를 별도 기록한다.

## 3. 성능 수치의 이름을 바르게 쓴다

Core Web Vitals 적합성은 실제 사용자의 field data에서 모바일·데스크톱별 75th percentile로 판단한다. 로컬 Lighthouse/DevTools/테스트 장비 수치는 개발 회귀를 잡는 lab proxy이며 field 판정이 아니다 [CWV, CWV-METHOD].

| 주장 | 필요한 증거 |
|---|---|
| “개발 빌드가 이전보다 가벼워졌다” | 같은 환경·시나리오의 bundle/전송량 또는 lab 결과 |
| “CWV good” | RUM 또는 CrUX의 LCP·INP·CLS p75, 기간·트래픽 분리 |
| “사용자가 더 빨리 끝낸다” | 실제 과업 시간·성공률·오류/중단의 전후 비교 |
| “이 디자인이 더 아름답다” | 동일 브리프에서의 렌더 비교와 근거 있는 리뷰; 자동 점수로 단정하지 않음 |

## 4. 비교는 같은 조건에서 한다

브랜드 고유성, 시각 위계, 구도·리듬, 이미지 품질은 실제 렌더에서 비교한다. 평가자는 같은 브리프·폭·상태·콘텐츠에서 다음을 적는다: 무엇이 첫 번째로 읽히는가, 어떤 근거가 이 브랜드에만 맞는가, 반복이 정보 구조를 드러내는가, 이미지의 크롭·해상도·대체 텍스트가 목적을 지지하는가. 심미성 자동점수, 상 수상, 단일 클릭 수로 전환 인과를 주장하지 않는다 [AWWWARDS, WEBBY].

## 5. 필요할 때: 평가의 네 증거선을 분리한다

예쁘다는 평가와 실제 과업 결과가 엇갈리거나, 변경이 개선 효과를 냈다고 주장하려 할 때 이 절을 연다. 평가 종류가 답하는 질문은 다르다. 첫인상·취향, 실제 과업 행동, 접근성 적합성, 전문가의 시각 검토를 한 PASS로 합치지 않는다. 보기 좋은 표면이 사용성 평가를 좋게 느끼게 할 수 있으므로, 호감과 과업 결과도 따로 적는다 [NNG-AESTHETIC].

| 증거선 | 답하는 질문 | 최소 기록 | 다른 증거로 대체할 수 없는 것 |
|---|---|---|---|
| 첫인상·취향 | 무엇이 먼저 읽히고 어떤 인상을 주는가 | 같은 렌더 조건, 관찰, 해석 | 실제 과업 성공·접근성 적합성 |
| 실제 과업 행동 | 사람이 목표를 달성하며 어디에서 멈추거나 오류를 내는가 | 현실적인 중립 과업, 행동·발화·막힌 지점 | 표준 적합성·전문가 미감 판정 |
| 접근성 적합성 | 정한 WCAG 수준과 제품 계약을 충족하는가 | 기준, 상태, 키보드·확대·보조기술 결과 | 사용자 경험 전체 |
| 전문가 시각 검토 | 위계·타입·구도·이미지·리듬이 브리프와 맞는가 | 같은 조건의 전후 렌더, 관찰, 변경 근거 | 실제 사용자 연구 |

불확실하거나 영향이 큰 과업이면 실제 또는 예상 사용자가 현실적인 목표를 중립적 과제로 수행하게 하고, 답을 암시하지 않은 채 행동을 관찰한다 [GOV-TEST]. 실제 사용자 검증이 없으면 그 한계를 결과에 적고, 과업 효과를 확정적으로 주장하지 않는다. 사용자 평가는 표준 적합성 평가를 보완하며 대체하지 않는다 [W3C-USER-EVAL]. 일반적인 구현에 사용자 모집을 필수 게이트로 만들지 않는다. 에이전트 walkthrough는 정해진 시나리오의 회귀 점검일 뿐 실제 사용자 연구가 아니다.

수정은 `관찰 → 원인 가설 → 한 가지 변경 → 같은 조건의 재비교`로 남긴다. 필요하면 여러 구조적 대안을 탐색하고 작은 범위에서 시험해 버리거나 다듬는다는 Double Diamond의 프레임을 참고한다 [DC-DIAMOND]. 이 절차는 출처가 보장한 단일 방법이 아니라, 위 근거를 스킬 작업에 맞게 합성한 절차다. 고정된 관찰 시간·참여자 수·성공률 하나를 보편 통과선으로 쓰지 않는다.

## 6. 결정 기록 템플릿

```markdown
- 출처 ID: WCAG-TARGET
- 지지 주장: 포인터 대상의 AA 최소 크기는 24×24 CSS px이다.
- 적용 조건: 모바일에서 빈번한 아이콘 행동.
- 잘못된 일반화: 모든 컨트롤에 44px가 법적 필수라는 말.
- 구체 검증: 390px에서 실제 클릭 영역과 인접 대상 간격을 측정한다.
- 예시 결정: 삭제 아이콘의 보이는 glyph는 16px, 클릭 영역은 28px로 둔다.
```

## 7. 조건부: 개인화와 AI 기능의 책임

### 개인화 — 조건부

언제: 웹앱 UI(대시보드·설정 화면처럼 반복해서 쓰는 도구)일 때만 연다. 랜딩 페이지·포트폴리오·마케팅 사이트에는 대체로 해당하지 않는다.

**관찰 후보**: 단일 레이아웃이 모든 사용자에게 맞지 않을 때는 컨트롤 재배치·안 쓰는 기능 숨기기 같은 개인화 여지를 설계 후보로 검토한다[SKILL-APPLE-DESIGN]. 개인화 자체를 기본값으로 강제하지 않는다 — 브리프나 사용자 조사가 요구할 때만 연다.

### AI 기능이 있는 브리프의 책임

언제: 브리프에 AI 기반 기능(추천·생성·자동완성·챗봇 등)이 있을 때 연다.

**프로젝트 계약**: 오남용과 피해를 미리 예측한다 — 예를 들어 알레르기를 인지하는 레시피 기능은 유해한 재료를 제안하면 안 된다. 적절한 자리에 미리보기(실행 전에 결과를 확인하게 하기)·확인 단계·면책 조항을 두고, 위험이 가치를 넘는 기능은 잘라낸다[SKILL-APPLE-DESIGN]. AI 산출물을 실제 데이터처럼 보여줄 때의 진실 계약은 [trustworthy-showcases.md](trustworthy-showcases.md) §7("AI는 답이 아니라 검토 가능한 기록이다")을 따른다.