release: v0.11.0
This commit is contained in:
parent
3c39a1731d
commit
45ba92ea82
45 changed files with 1459 additions and 1887 deletions
|
|
@ -33,14 +33,14 @@ description: "웹 디자인 전 과정을 끌고 가는 파이프라인 스킬.
|
|||
|
||||
1. **레퍼런스 없이 시작하지 않는다.** 전체 경로에서 1단계를 건너뛴 디자인은 5단계에서 실패 처리한다. 연장·국소 경로는 `design.md` 가 그 자리를 대신한다 — 그것도 없이 건너뛰면 실패다.
|
||||
2. **모든 시각적 결정에는 브리프로 소급되는 이유가 있어야 한다.** "보통 이렇게 한다"는 이유가 아니다.
|
||||
3. **화려함은 4순위다.** Awwwards 배점이 Design 40 / Usability 30 / Creativity 20 / Content 10이다. 3D를 얹는 것보다 타입 스케일을 정돈하는 게 결과에 두 배 유효하다.
|
||||
4. **대담함은 한 곳에만.** 리스크는 하나다. 나머지는 조용히 받쳐준다. 두 곳에서 소리치면 둘 다 죽는다.
|
||||
3. **화려함만으로 통과하지 않는다.** Awwwards의 공개 평가 비중은 Design 40 / Usability 30 / Creativity 20 / Content 10이다. 이 비중은 해당 어워드의 심사 틀일 뿐, 제품 성과나 특정 기법의 효과를 보장하지 않는다. 출처와 적용 조건은 `references/evidence-ledger.md`에 남긴다.
|
||||
4. **대담함은 의도와 검증을 같이 가진다.** 강한 선택을 채택하면 어떤 사용 과업·브랜드 목표를 돕는지, 어느 화면에서 어떻게 확인할지 적는다. 리스크의 개수는 보편 규칙이 아니라 브리프·표면 밀도·렌더 결과로 판단한다.
|
||||
5. **성능 예산을 넘기면 그 이펙트는 채택하지 않는다.** 예산은 3단계에서 정하고 5단계에서 검증한다. 데모·포트폴리오 브리프면 예산을 올려도 되지만 **올렸다고 말해야 한다**.
|
||||
6. **완료의 정의는 게이트 통과다(자율 검증 폐쇄 루프).** 5단계에서 `tools/design-gate.mjs` 를 프로젝트에 심어 돌리고, 실패 항목이 있으면 4단계로 돌아가 고치고 **전체를 재실행**한다. 게이트 없이 6단계로 넘어가지 않는다. 사용자를 QA 로 쓰지 않는다 — 검증은 기본 내장, 사용자 피드백은 보조다. 상세는 `references/audit-gate.md`. **게이트는 계측이고 계측엔 공백이 있다**(왼쪽 인셋·시각적 무게는 오버플로 검사를 통과한다). 사용자 보고가 오면 방어하지 말라 — 스크린샷을 픽셀 판정으로 해부해 원인을 수치화하고, 그 검사를 게이트에 추가해 재발을 막는다(하니스 규칙 15~17).
|
||||
6. **완료는 기능·프로젝트 계약·렌더 시각 평가가 함께 확인된 상태다(자율 검증 폐쇄 루프).** 5단계에서 변경 영향 범위에 맞는 자동 검사와 실제 렌더 평가를 수행한다. 실패 항목이 있으면 4단계로 돌아가 고치고, 고친 영역과 그에 연결된 회귀 위험을 다시 검사한다. 사용자를 QA 로 쓰지 않는다 — 검증은 기본 내장, 사용자 피드백은 보조다. 상세는 `references/audit-gate.md`. **게이트는 계측이고 계측엔 공백이 있다**(왼쪽 인셋·시각적 무게는 오버플로 검사를 통과한다). 사용자 보고가 오면 방어하지 말라 — 스크린샷을 픽셀 판정으로 해부해 원인을 수치화하고, 그 검사를 게이트에 추가해 재발을 막는다(하니스 규칙 15~17).
|
||||
7. **OS·플랫폼 관습은 조사 없이 바꾸지 않는다.** 내비 구조·뒤로가기·시트·safe area·터치 타깃 같은 관습은 사용자가 이미 OS 전체에서 배운 것이다. "웹에서는 그랬다"를 폰에 옮기면 백 키가 앱을 종료하는 웹앱이 된다(실측 사고). 바꾸기 전에 HIG·M3·NN/g 에서 근거를 찾고, 모바일 앱 수준 브리프면 `references/mobile-app-ux.md` 를 구현 전에 읽는다.
|
||||
8. **언어와 문화권은 컴퓨터 로케일을 기본값으로 삼는다.** 새로 쓰는 UI 카피·메타데이터·빈 상태·오류 문구·장식 텍스트·이미지 안의 글자는 OS 로케일의 언어로 만든다. 영어는 기술 용어·국제 브랜드·짧은 보조 표기처럼 필요한 범위에서만 허용한다. 그 밖의 언어·문자(한국어 로케일에서는 한자·중국어·일본어 포함)와 이를 흉내 낸 인장·세로쓰기·서예·동아시아 이국화 장식은 사용자가 명시적으로 요청하거나 원본 브랜드 자산으로 제공하지 않는 한 만들지 않는다. 원본에 있는 고유명사·인용문은 임의로 고치지 않되, 에이전트가 새 레이블로 증식시키지 않는다.
|
||||
|
||||
**접근성은 예외다. 이것만은 협상하지 않는다.** 키보드·포커스·대비·`prefers-reduced-motion`은 어떤 이펙트보다, 어떤 브리프보다 우선한다. 픽셀은 왜곡해도 DOM은 살린다.
|
||||
**판정 위계를 섞지 않는다.** (1) WCAG·키보드·포커스·대비·감소 모션·진실성처럼 규범 또는 기능에 근거한 항목은 하드 게이트다. (2) 프로젝트의 브리프·`design.md`·토큰·성능 예산은 그 프로젝트의 계약이다. (3) 색·radius·정렬·레이아웃 반복·마퀴·제목 줄 수 같은 스타일 휴리스틱은 관찰 후보일 뿐이다. 후보는 맥락 적합성과 실제 렌더를 보고 채택·수정·유지한다. 픽셀은 왜곡해도 DOM은 살린다.
|
||||
|
||||
## 파이프라인
|
||||
|
||||
|
|
@ -48,11 +48,25 @@ description: "웹 디자인 전 과정을 끌고 가는 파이프라인 스킬.
|
|||
|
||||
참조 문서는 **해당 단계에 들어갈 때 읽는다.** 처음부터 전부 읽지 마라 — 컨텍스트 낭비다.
|
||||
|
||||
### 불확실성 라우팅
|
||||
|
||||
결정이 애매할 때는 감으로 규칙을 더 만들지 말고, 아래에서 **필요한 문서만** 연다. 읽은 근거는 프로젝트의 `design.md` 또는 evidence 기록에 `질문 → 근거/적용 범위 → 결정 → 렌더·과업 검증`으로 남긴다.
|
||||
|
||||
| 판단 질문 | 읽을 문서 | 꺼내 쓸 항목 / 남길 결정 |
|
||||
|---|---|---|
|
||||
| 무엇을 먼저 보이게 하고, 어떤 구도·이미지·크롭이 과업을 돕는가? | `references/art-direction.md` | 콘텐츠 우선순위, 시선·여백·이미지 역할, 크롭 비교와 선택 이유 |
|
||||
| 이 원칙이 보편 규범인가, 특정 사례·실무 지침인가? | `references/design-foundations.md` + `references/evidence-ledger.md` | 주장 종류(원론·규범·실무·사례·전망·서지), 출처의 조건과 적용 여부 |
|
||||
| 이 브리프에 맞는 시각 언어와 피해야 할 관습은 무엇인가? | `references/style-playbook.md` | 스타일의 표현 수단·주의점, 브리프에 맞춘 변형 |
|
||||
| 실제 언어·글꼴·숫자에서 읽히는가? | `references/typography.md` | 실제 카피 proof sheet, 폰트·폭·행간·폴백 결정 |
|
||||
| 무엇을 어떤 범위까지 검사하고 완료라 할 수 있는가? | `references/preflight.md` + `references/audit-gate.md` | 기능·접근성 검사, 같은 조건의 렌더 평가, 영향 범위 |
|
||||
|
||||
자료가 부족하거나 오래됐거나 출처끼리 충돌하면, 권위 있는 원문·공식 규범·해당 분야의 사례를 필요한 범위에서 추가 조사한다. 출처를 많이 모으는 대신 **주장, 적용 범위, 반대 근거, 검증 방법**을 기록한다. 출처와 프로젝트 계약이 충돌하면 기존 우선순위(`사용자 지시 → design.md → 기존 토큰·코드 → 기본값`)를 적용하고, 규범·기능 요구의 적용 수준과 예외를 확인한다. 기능·접근성 요구와 계약이 충돌하면 양쪽을 충족할 대안을 먼저 찾고, 해소되지 않으면 충돌을 명시한다. 취향 휴리스틱으로 필수 요구를 덮지 않는다. 이 과정은 현재 프로젝트의 결정에 쓰는 것이며, 설치된 스킬 자체를 매번 고치는 지시는 아니다.
|
||||
|
||||
---
|
||||
|
||||
### 0단계 — 브리프 게이트
|
||||
|
||||
**먼저 프로젝트 루트에 `design.md` 가 있는지 확인한다.** (프로젝트 루트 = 패키지 매니저 설정 파일이 있는 디렉터리. 모노레포면 **작업 대상 패키지의 루트**를 쓰고, 저장소 루트에도 있으면 둘 다 읽되 가까운 쪽이 이긴다) 있으면 읽고, 그 결정을 이 스킬의 기본값보다 우선한다. 같은 프로젝트를 두 번째로 작업할 때 지난번과 다른 디자인이 나오면 그건 실패다.
|
||||
**먼저 프로젝트 루트에 `design.md` 가 있는지 확인한다.** (프로젝트 루트 = 패키지 매니저 설정 파일이 있는 디렉터리. 모노레포면 **작업 대상 패키지의 루트**를 쓰고, 저장소 루트에도 있으면 둘 다 읽되 가까운 쪽이 이긴다) 있으면 읽고, 그 결정을 이 스킬의 기본값보다 우선한다. 같은 프로젝트는 기존 계약과 사용자의 기대를 유지한다. 다만 사용자가 명시적으로 리디자인을 요청했거나 감사 결과가 방향 변경을 뒷받침하면, 바꾸는 이유·보존할 자산·검증 조건을 기록하고 새 방향으로 진행한다.
|
||||
|
||||
브리프를 세 줄로 압축한다. 세 줄을 못 쓰면 아직 작업을 시작할 수 없다.
|
||||
|
||||
|
|
@ -129,46 +143,35 @@ description: "웹 디자인 전 과정을 끌고 가는 파이프라인 스킬.
|
|||
결과를 크게 바꾸는 축을 골라 **선택지와 함께** 한 화면에 낸다. 각 선택지에는
|
||||
"이걸 고르면 무엇이 달라지는지"를 적어라. 고르는 사람이 결과를 예상할 수 있어야 한다.
|
||||
|
||||
거의 모든 브리프에서 다음이 결과를 가장 크게 바꾼다. **위 넷은 거의 항상 묻는다.**
|
||||
브리프·기존 코드·브랜드 자산에서 답을 확인할 수 없고 결과를 크게 바꿀 때만 아래 항목을 묻는다. 이미 알려진 사실을 다시 묻지 않는다.
|
||||
|
||||
| 축 | 무엇이 달라지는가 | 안 물으면 |
|
||||
|---|---|---|
|
||||
| **업종·성격** | 정보 구조 전체. 같은 "꽃집"도 구독형과 하이엔드 스튜디오는 다른 사이트다 | 카테고리 평균이 나온다 |
|
||||
| **목표 행동** | CTA 의 수와 위치, 어떤 섹션이 필요하고 어떤 게 군더더기인지 | CTA 가 넷이 되고 페이지가 무너진다 |
|
||||
| **톤** | 2단계 프리셋과 감수할 리스크가 여기서 결정된다 | 내 기본 미학이 나온다 |
|
||||
| **고유명사·실제 값** | 이름·지역·가격·연락처 | 지어내면 하드 게이트 11 |
|
||||
| **고유명사·실제 값** | 이름·지역·가격·연락처 | 지어내면 규범·기능 하드 게이트 실패 |
|
||||
| **기존 브랜드 색·로고** | 있으면 3단계 팔레트가 **거기서 시작한다** | 있는 자산을 무시하고 새로 만든다 |
|
||||
| **좁은 화면의 내비** | 항목 5개 이상이면 구조가 달라진다 | 넓은 화면 메뉴를 그대로 접어 두 줄이 된다 |
|
||||
| **좁은 화면의 내비** | 라벨 길이·번역·확대·폭·우선순위·깊이가 구조를 바꾼다 | 넓은 화면 메뉴를 그대로 접어 두 줄이 된다 |
|
||||
|
||||
### 색은 반드시 확인한다 — 없다는 답도 답이다
|
||||
### 색은 이미 알려진 자산부터 확인한다
|
||||
|
||||
**"브랜드 색이 있나요"** 는 결과를 되돌릴 수 없게 바꾸는 질문이다.
|
||||
이미 로고·간판·패키지에 색이 있는데 사이트만 다른 색이면, 잘 만들어도 **틀린 것**이다.
|
||||
로고·간판·패키지·기존 토큰에 브랜드 색이 있으면 그것부터 확인한다. 없는지 또는 피할 색이 필요한지 이미 브리프·자산에서 알 수 있으면 재질문하지 않는다. 정보가 없고 색 선택이 브랜드 정합성을 크게 바꾸는 경우에만 한 번에 묻는다.
|
||||
|
||||
- **있다** → 3단계에서 그 색이 강조색이고, 레퍼런스는 그 색과 어울리는 곳으로 고른다
|
||||
- **없다·상관없다** → 레퍼런스 실측에서 뽑는다. 이때도 **어떤 색을 피해야 하는지**는 물어라
|
||||
(경쟁사가 쓰는 색, 대표가 싫어하는 색은 사용자만 안다)
|
||||
- **기존 색이 있다** → 역할·대비·면적을 검토해 토큰에 반영한다. 반드시 강조색일 필요는 없다.
|
||||
- **없다·상관없다** → 레퍼런스와 과업에서 색 역할을 정한다. 피할 색이 결과를 좌우하고 확인할 근거가 없을 때만 묻는다.
|
||||
|
||||
> 실측 사례: 꽃집 작업에서 색을 묻지 않고 레퍼런스 세 곳의 배경 평균(`#F8F6F0`)으로 정했다.
|
||||
> 결과는 좋았지만 **운이 좋았던 것**이다. 브랜드 색이 있었다면 그걸 무시한 작업이 된다.
|
||||
|
||||
### 좁은 화면의 내비를 미리 정한다
|
||||
|
||||
내비 항목 수는 0단계에서 이미 정해진다(= 섹션 수). **구현 단계에서 발견하면 늦다.**
|
||||
내비 구조는 항목 수만으로 정하지 않는다. 실제 라벨과 번역 길이, 글꼴 확대, 최소 화면 폭, 가장 중요한 이동 경로, 메뉴 깊이, 키보드 포커스 순서를 함께 본다. 한 줄·가로 스크롤·하단 바·여는 메뉴 중에서 그 조건에서 과업을 가장 덜 방해하는 방식을 고르고, 실제 좁은 화면과 확대 상태에서 검사한다.
|
||||
|
||||
| 항목 수 | 좁은 화면 처리 | 비용 |
|
||||
|---|---|---|
|
||||
| 2~4개 | 그대로 한 줄. 자간을 줄이고 `justify-content: space-between` | 0 |
|
||||
| 5~6개 | 가로 스크롤 줄 또는 하단 고정 바 | 낮음 |
|
||||
| 7개 이상 | **여는 메뉴**(햄버거) | `<details>` 로 JS 0바이트 |
|
||||
|
||||
**햄버거를 기본값으로 삼지 마라.** 항목이 넷인데 햄버거를 쓰면 한 번의 탭을 공짜로 뺏는 것이다.
|
||||
반대로 여섯 개를 한 줄에 욱여넣으면 접힌다 — 실측에서 링크가 두 줄(top 46/77)에 걸렸다.
|
||||
|
||||
여는 메뉴가 필요하다고 판단되면 `references/layout.md` 의 **모바일 내비** 절을 본다.
|
||||
여는 메뉴가 필요하다고 판단되면 `references/layout.md` 의 **모바일 내비** 절을 본다. 항목이 적어도 긴 번역·깊은 계층이면 여는 메뉴가 맞을 수 있고, 항목이 많아도 우선순위가 뚜렷하면 일부를 분리할 수 있다.
|
||||
|
||||
넷을 `multiSelect` 로 낼지 단일 선택으로 낼지 구분해라 — **목표 행동은 대개 복수**고,
|
||||
톤과 성격은 하나여야 한다. 둘 다 고르면 방향이 서지 않는다.
|
||||
톤과 성격에는 주된 방향을 두되, 브리프가 요구하면 서로 보완하는 속성을 함께 쓸 수 있다. 어떤 속성이 위계를 이끄는지 기록한다.
|
||||
|
||||
**물어도 되는 것과 물으면 안 되는 것**
|
||||
|
||||
|
|
@ -192,15 +195,17 @@ description: "웹 디자인 전 과정을 끌고 가는 파이프라인 스킬.
|
|||
|
||||
이 단계가 designpaca의 심장이다. 머릿속 기본값이 아니라 **실제로 존재하는 사이트**에서 시작한다. 연장·국소 경로는 0단계에서 이미 이 단계를 건너뛰기로 정했고, 그 근거는 `design.md` 다.
|
||||
|
||||
레퍼런스 **3개**를 서로 **다른 층위**에서 고른다:
|
||||
전체 경로에서는 `references/design-foundations.md`를 읽어 이론을 브리프의 사용 과업·제약으로 번역하고, `references/evidence-ledger.md`에서 출처 ID와 기록 형식을 확인한다. 조사 결과는 패키지 문서에 쓰지 말고 프로젝트의 `design.md` 또는 프로젝트 evidence 기록에 남긴다.
|
||||
|
||||
레퍼런스 슬롯은 구조·톤·디테일을 **분리해 검토하는 장치**다. 새 화면에는 보통 아래 세 슬롯을 채우되, 세 개를 찾았다는 사실이 좋은 합성이나 결과를 보증하지 않는다. 브리프에 맞지 않는 슬롯은 비워 둔 이유와 대체 근거를 남긴다:
|
||||
|
||||
| 슬롯 | 무엇 | 규칙 |
|
||||
|---|---|---|
|
||||
| **R1 — 구조** | 같은 업종/목적의 사이트 | 정보 구조와 흐름을 가져온다 |
|
||||
| **R2 — 톤** | **반드시 다른 업종** | 분위기·재질·타이포 감각을 가져온다 |
|
||||
| **R2 — 톤** | 다른 업종 또는 매체를 우선 검토 | 분위기·재질·타이포 감각을 가져온다 |
|
||||
| **R3 — 디테일** | 어디서든 | 하나의 구체적 기법(모션·타입·인터랙션) |
|
||||
|
||||
R1과 R2를 같은 업종에서 고르면 결과는 그 업종의 평균이 된다. SaaS 구조 + SaaS 톤 = 또 하나의 SaaS 슬롭이다.
|
||||
R1과 R2의 업종이 같아도 평균을 무비판적으로 복제하지 말고, 가져올 원칙·적용 조건·실제 렌더 검증을 분리해 기록한다.
|
||||
|
||||
**목표 시장이 다른 레퍼런스는 자동으로 중립이 되지 않는다.** 단위·용어·문의 방식·사진 조도·신뢰 표지는 문화권의 일부다. 시장 적합성이 중요한 브리프는 R1을 같은 목표 시장에서 우선 찾고, R2는 **같은 문화권의 다른 업종**을 우선한다. 다른 문화권의 R3는 구현 기법 하나만 가져온다. 상세 계약은 `reference-method.md`와, 가상·AI·규제 쇼케이스면 `trustworthy-showcases.md`를 따른다.
|
||||
|
||||
|
|
@ -209,23 +214,24 @@ R1과 R2를 같은 업종에서 고르면 결과는 그 업종의 평균이 된
|
|||
|
||||
**갤러리 목록 페이지가 아니라 원본 사이트를 열어라.** 이미지를 볼 수 없어도 구조는 읽을 수 있다.
|
||||
|
||||
**403·404·타임아웃을 두 번 만나면 텍스트 페처를 버리고 브라우저를 띄워라.**
|
||||
좋은 레퍼런스일수록 봇을 막는다. 대체 갤러리를 찾아 헤매는 것은 시간 낭비이고,
|
||||
찾아낸 대체 소스는 애초에 보려던 것보다 나쁘다. `designpaca tools` 로 설치된
|
||||
**403·404·타임아웃을 두 번 만나면 텍스트 페처만 반복하지 말고 브라우저 또는 다른 정본 출처를 검토한다.**
|
||||
대체 출처는 처음 후보보다 자동으로 열등하지 않다. 출처가 제공하는 관찰 범위·신뢰성·브리프 적합성을 비교해 고른다. `designpaca tools` 로 설치된
|
||||
headed 브라우저가 있으면 스크린샷과 실측값을 바로 받는다 — 방법은 `galleries.md` §5.
|
||||
|
||||
> 통과 조건: R1/R2/R3 각각의 URL과, 그것에서 **무엇을 가져올지** 한 줄씩. 형식은 `reference-method.md` 참조.
|
||||
> 통과 조건: 사용한 슬롯마다 URL·출처 ID·원칙/조건·관찰·결정·검증 계획이 있다. 형식은 `reference-method.md`와 `evidence-ledger.md`를 따른다.
|
||||
|
||||
---
|
||||
|
||||
### 2단계 — 방향 결정
|
||||
|
||||
레퍼런스 3개를 하나의 방향으로 합성한다. 베끼지 않는다. **축을 정하고 그 축 위에서 결정한다.**
|
||||
사용한 레퍼런스 슬롯을 하나의 방향으로 번역한다. 베끼지 않는다. **축을 정하고 그 축 위에서 결정한다.**
|
||||
|
||||
이 단계에서 `references/style-playbook.md`를 읽어 선택한 스타일의 표현 수단·주의점·적용 조건을 검토한다. 이론이나 스타일 이름은 결론이 아니므로, `design.md` 또는 프로젝트 evidence 기록에 출처 ID → 원칙/조건 → 관찰 → 결정 → 검증 계획을 남긴다.
|
||||
|
||||
정해야 할 것:
|
||||
- **한 문장 컨셉** — 이 사이트가 주는 인상을 한 문장으로. ("고급 잡지의 여백", "계기판처럼 정확한", "밤의 스튜디오")
|
||||
- **미학 프리셋** — 아래에서 고르거나, 브리프가 요구하면 새로 정의한다
|
||||
- **감수할 리스크 하나** — 정당화할 수 있는 과감한 선택 하나. 없으면 그 디자인은 안전하고 잊힌다
|
||||
- **표현 리스크** — 과감한 선택을 쓴다면 왜 이 과업에 맞는지와 실제 렌더 검증 방법. 리스크가 없다는 결정도 허용하되 이유를 기록한다
|
||||
- **표면 다이얼** — 랜딩·관리자·가맹처럼 과업이 다른 화면이 함께 있으면 각 표면의 표현성·정보 밀도·모션·증거 노출을 0~3으로 따로 적는다. 공통 토큰은 공유하되 과업 밀도까지 같게 만들지 않는다
|
||||
|
||||
| 프리셋 | 한 줄 | 언제 |
|
||||
|
|
@ -238,7 +244,7 @@ headed 브라우저가 있으면 스크린샷과 실측값을 바로 받는다
|
|||
|
||||
고른 프리셋 파일 **하나만** 읽어라. 다섯 다 읽지 마라. 고르는 기준은 `references/presets/README.md`.
|
||||
|
||||
> 통과 조건: 한 문장 컨셉 + 프리셋 + 리스크 하나가 적혔다.
|
||||
> 통과 조건: 한 문장 컨셉 + 프리셋 + 표현 리스크의 채택/비채택 근거가 적혔다.
|
||||
> **연장 경로는 이 단계를 돌지 않는다.** `design.md` 의 컨셉·프리셋·리스크를 그대로 이어받는다. 바꾸고 싶으면 전체 경로로 올린다.
|
||||
|
||||
---
|
||||
|
|
@ -253,7 +259,7 @@ headed 브라우저가 있으면 스크린샷과 실측값을 바로 받는다
|
|||
|
||||
**성능 예산도 여기서 정한다.** 나중에 정하면 이미 늦는다. 전체 표는 `references/tokens.md` §5 하나뿐이다 — 다른 문서에 예산 표를 만들지 마라.
|
||||
|
||||
기본선: 히어로까지 JS **150KB(gzip)** / 첫 인터랙션 **3초** / 애니메이션은 `transform`·`opacity` 만.
|
||||
기본선: 히어로까지 JS **150KB(gzip)** / 첫 인터랙션 **3초**. `transform`·`opacity`는 저비용 기본 선택이다. 다른 속성 또는 스크롤 기반 로직은 자동 금지가 아니라, 측정한 비용·입력 간섭·감소 모션 경로·프로젝트 예산을 기록하고 실제 기기/브라우저에서 검증한다.
|
||||
브리프가 데모·포트폴리오라면 예산을 올려도 된다. **올린다는 사실과 이유를 명시해라.**
|
||||
|
||||
> 통과 조건: 토큰이 실제 값으로 적혔고, 성능 예산이 숫자로 정해졌다.
|
||||
|
|
@ -266,9 +272,9 @@ headed 브라우저가 있으면 스크린샷과 실측값을 바로 받는다
|
|||
|
||||
**4-0. 이미지 조달** → `references/images.md`
|
||||
자리를 만들기 전에 **무엇을 실을지** 정한다. 나중에 채우면 비율이 안 맞아 레이아웃을 다시 짠다.
|
||||
사용자가 준 사진이 있으면 무조건 그것이고, 없으면 **codex 가 설치돼 있는지 확인해 생성**한다.
|
||||
생성했으면 `design.md` 에 생성물이라고 적는다 — 나중에 실제 사진으로 바꿀 사람이 알아야 한다.
|
||||
히어로·증거 컷·모바일 히어로를 각각 슬롯으로 적은 **이미지 바이블**을 먼저 만든다. 데스크톱 크롭에서 핵심 피사체가 폴드 아래로 밀리면 모바일은 별도 원본을 만든다.
|
||||
사용자가 준 사진·기존 브랜드 자산·직접 제작·라이선스 가능한 자료·생성물 중에서, 이미지 슬롯의 역할과 품질·권리·진실성에 맞는 것을 고른다. 자산이 없다는 사실만으로 자동 생성하지 않는다.
|
||||
생성물을 쓰면 `design.md` 에 생성물과 용도를 적는다 — 나중에 실제 사진으로 바꿀 사람이 알아야 한다.
|
||||
히어로·증거 컷·모바일 히어로를 각각 슬롯으로 적은 **이미지 바이블**을 먼저 만든다. 슬롯별 실제 크롭에서 핵심 피사체와 맥락이 보존되는지 확인하고, 같은 원본의 초점 조정으로 해결되지 않을 때만 별도 자산을 고른다.
|
||||
싣기 전에 반드시 줄인다(실측: 10.1MB → 603KB).
|
||||
|
||||
**4-1. 레이아웃과 타이포그래피** → `references/layout.md` (+ 폰트 적용은 `references/typography.md` §5, §6)
|
||||
|
|
@ -285,7 +291,7 @@ headed 브라우저가 있으면 스크린샷과 실측값을 바로 받는다
|
|||
|
||||
**4-5. 서류로서의 완성** — 프리셋이 서류·원장·콘솔 계열(장부, 시간표, 관리 화면)일 때만 도는 단계다.
|
||||
그 앱이 종이에서 하던 일을 화면이 이어받아야 프로덕션이다. 셋을 검토한다:
|
||||
- **인쇄** — `@media print`. 앱 크롬(내비·툴바·버튼)은 물러나고 활성 화면이 서류가 된다. 모달이 열려 있으면 그 서류만(`body:has(dialog[open])` 로 앱을 숨긴다). 상태색은 `print-color-adjust: exact` 로 보존. 인쇄 버튼을 크롬에 더했다면 **그 줄의 최소폭 합**을 가장 좁은 폭에서 다시 잰다(하드 게이트 5)
|
||||
- **인쇄** — `@media print`. 앱 크롬(내비·툴바·버튼)은 물러나고 활성 화면이 서류가 된다. 모달이 열려 있으면 그 서류만(`body:has(dialog[open])` 로 앱을 숨긴다). 상태색은 `print-color-adjust: exact` 로 보존. 인쇄 버튼을 크롬에 더했다면 프로젝트의 최소 지원 폭에서 실제 조작 가능성을 다시 잰다
|
||||
- **키보드 단축키** — 콘솔의 손가락 문법. 숫자키 뷰 전환, `/` 검색 포커스. `kbd` 물리 키 칩으로 안내하고, 입력 요소에 포커스가 있을 때는 무력화한다
|
||||
- **본연의 도메인 동작** — 학적부는 기록, 시간표는 격자, 주문은 원장. 그 도메인이 종이에서 하던 핵심 동작 하나가 빠져 있으면 그게 곧 '데모 티'다
|
||||
|
||||
|
|
@ -306,54 +312,52 @@ HTML-in-Canvas(`drawElementImage`)는 **폴백을 완성한 뒤에만** 얹는
|
|||
→ `references/preflight.md` (전체 체크리스트)
|
||||
→ `references/antipatterns.md` (슬롭 지문 목록 + grep 검출 + 자가 채점표)
|
||||
|
||||
특히 다음 다섯은 기계적으로 검사할 수 있다. **반드시 돌려라**:
|
||||
다음 항목을 변경 영향과 프로젝트 검증 계약에 맞춰 확인한다. 자동 검사와 렌더 평가는 구분한다:
|
||||
|
||||
1. **슬롭 지문 grep** — 보라 CTA(`#6366f1`·`#8b5cf6` 계열), 전체 대문자 헤드라인, 번호 매긴 1·2·3 단계. 실측 검출률 상위 항목이다
|
||||
1. **스타일 후보 grep** — 보라 CTA, 전체 대문자 헤드라인, 번호 매긴 단계처럼 반복되는 기본값을 찾아 근거 없이 남아 있는지 검토한다. 검출 자체는 실패가 아니며 `antipatterns.md`의 맥락 질문과 실제 렌더로 판정한다
|
||||
2. **카피 경쟁사 치환 테스트** — 제품명을 경쟁사 이름으로 바꿔도 문장이 성립하면, 그 카피는 아무것도 말하지 않았다
|
||||
3. **이펙트 전부 끄기** — CSS 필터·WebGL·애니메이션을 끈 상태에서 페이지가 여전히 읽히는가
|
||||
4. **게이트 실행(폐쇄 루프)** — `tools/design-gate.mjs --init` 으로 설정을 만들고 돌린다. 오버플로·h1·수축·대비·SEO/meta·죽은 선택자·토큰 위생·스케일×폭까지 전 뷰 × 전 폭. L1(단위)·L5(탐색)·L6(시나리오 E2E)는 프로젝트 `tools/` 에 보강해 `npm run verify` 체인으로. **게이트 통과 없이 완료 선언 금지.**
|
||||
4. **게이트 실행(폐쇄 루프)** — `tools/design-gate.mjs --init` 으로 설정을 만들고, 변경 영향과 프로젝트 계약에 맞춘 뷰·폭·상태에서 실행한다. 오버플로·제목 존재/가시성·수축·대비·SEO/meta·죽은 선택자·토큰 위생·스케일×폭을 해당 범위에서 검사한다. 명시한 양의 `h1MaxLines` 계약이 있을 때만 줄 수를 검사한다. L1(단위)·L5(탐색)·L6(시나리오 E2E)는 프로젝트에 필요한 경우 `tools/` 에 보강해 `npm run verify` 체인으로. 자동 검사 결과와 실제 렌더 평가를 함께 기록한다.
|
||||
5. **상태 완결성 스윕** — 입력·파괴·열림이 있는 화면은 실제로 조작해 본다: 수치 입력에 범위 밖 값을 넣고, 파괴적 행동을 되돌려보고, 열린 메뉴를 Esc 로 닫는다. 기준은 `references/preflight.md` §4-1. 통과 못 하면 4단계로
|
||||
6. **상태별 시각 E2E** — URL별 390·1440 기본 화면과 결과·오류·모달 같은 핵심 상태를 캡처한다. 하니스는 개수·규격·0바이트·중복 해시를 단언하고, 캡처를 실제로 열어 목표 시장 적합성·시선 위계·이미지 크롭·반복을 눈으로 판정한다. 구조 PASS를 시각 PASS로 바꾸어 말하지 않는다
|
||||
|
||||
> 게이트가 잡은 실제 사고 목록과 7계층 설계 근거는 `references/audit-gate.md` 다. 자기 검사 스크립트를 매번 새로 쓰지 마라 — 이 게이트를 심고 확장해라.
|
||||
|
||||
#### 하드 게이트 — 전부 "아니오"여야 한다
|
||||
#### 규범·기능 하드 게이트 — 전부 충족해야 한다
|
||||
|
||||
취향이 아니라 **버그**다. 여기엔 오버라이드가 없다. 체크박스가 아니라 질문이니 실제로 검사해라.
|
||||
아래는 취향이 아니라 적용 WCAG·플랫폼 접근성·사용자에게 약속한 기능의 실패다. 프로젝트 계약과 스타일 판단은 다음 절에서 별도 검토한다.
|
||||
|
||||
1. 토큰 밖에 인라인 hex/rgb/oklch 색상값이나 인라인 `font-family` 가 있는가?
|
||||
2. 상태색(성공·경고·오류)을 제외하고, 한 페이지에서 강조색이 2개 이상인가?
|
||||
3. `border-radius` 값이 토큰 밖에 있거나, 서로 다른 값이 3종 이상인가?
|
||||
4. 페이지 중간에 테마(라이트/다크)가 뒤집히는데, 그 반전이 3단계 토큰에 규칙으로 정의돼 있지 않은가?
|
||||
(리듬으로 의도한 반전은 통과다. 정의 없이 섹션마다 다른 것이 실패다)
|
||||
5. 320~1920px 사이 어느 폭에서든 가로 스크롤이 생기는가?
|
||||
6. 버튼 라벨·내비 링크가 2줄로 접히는 폭이 있는가?
|
||||
7. 버튼 텍스트와 배경의 대비가 4.5:1 미만인가?
|
||||
8. `transform`/`opacity` 외의 속성을 애니메이션하는가?
|
||||
9. 풀하이트 섹션에 `100vh` 를 썼는가? (모바일 주소창 때문에 `100dvh` 여야 한다)
|
||||
10. `window.addEventListener('scroll')` 을 썼는가? (`IntersectionObserver` 또는 scroll-driven animation 을 써라)
|
||||
11. **사용자가 주지 않은 수치**(지표·통계·후기·고객 수)가 페이지에 **그럴듯한 값으로** 들어가 있는가?
|
||||
1. 키보드만으로 모든 인터랙티브 요소에 도달하고, 보이는 포커스와 논리적 순서를 유지하는가?
|
||||
2. 텍스트·UI·상태가 적용 WCAG 대비 기준을 충족하고, 의미 있는 이미지·폼·제목 구조·언어가 접근 가능한가?
|
||||
3. 감소 모션 환경에서 움직임 민감도를 낮추면서 콘텐츠·상태·조작을 보존하는가?
|
||||
4. 지원 범위의 뷰포트·글자 확대·입력 방식에서 의도하지 않은 가로 스크롤, 겹침, 조작 불능이 없는가?
|
||||
5. 입력·파괴·열림 상태가 실제로 검증되고, 오류·되돌림·Esc·포커스 복귀가 필요한 곳에서 작동하는가?
|
||||
6. 애니메이션 또는 스크롤 로직이 입력을 방해하지 않고, 정한 성능 예산과 지원 범위를 실제로 검증했는가?
|
||||
7. **사용자가 주지 않은 수치**(지표·통계·후기·고객 수)가 페이지에 **그럴듯한 값으로** 들어가 있지 않은가?
|
||||
걸렸으면 셋 중 하나다: (a) `{{SETUP_TIME}}` 같은 **명시적 placeholder** 로 바꾸고 6단계 `design.md` 미확정 목록에 올린다, (b) 사용자에게 실제 값을 묻고 멈춘다, (c) 그 섹션 자체를 다른 구조로 바꾼다.
|
||||
**placeholder 는 통과다.** 숫자 모양의 구멍은 정직하고, 지어낸 숫자는 슬롭이다.
|
||||
12. `<div>` 로 만든 가짜 스크린샷·가짜 브라우저바·가짜 폰 프레임이 있는가?
|
||||
13. **토큰 체계·프리셋을 바꿨는데 브랜드 표면(theme-color 메타·파비콘·og:image)이 옛 값을 그대로 쓰고 있는가?** 실측 사고: 프리셋 전환 11버전 뒤에 종이 시대 파비콘·theme-color 가 살아 있었다. 토큰 마이그레이션은 이 셋을 갱신하기 전까지 끝난 게 아니다. `theme-color` 는 실제 배경색과 같아야 한다(게이트가 비교한다)
|
||||
14. **HTML·JS 에서 사라진 컴포넌트의 CSS 규칙·JS 함수가 남아 있는가?** 제거는 HTML·CSS·JS 삼위일체다. 게이트의 죽은 선택자 검사가 클래스 사용률을 대조한다
|
||||
15. **현재 로케일 기본값·명시 브리프와 무관한 제3언어 또는 문화권 클리셰를 에이전트가 새로 넣었는가?** 화면·메타·ARIA·예제 데이터·생성 이미지와 세로쓰기·인장·서예성 장식까지 실제 렌더에서 확인한다. 한국어 로케일에서는 한자·중국어·일본어의 신규 사용이 이에 해당한다. 영어와 사용자가 제공한 원문은 예외다.
|
||||
8. 실제 증거로 오인될 수 있는 가짜 스크린샷·브라우저바·폰 프레임을 라벨 없이 만들지 않았는가?
|
||||
|
||||
#### 카운트 규칙
|
||||
#### 프로젝트 계약 — `design.md`와 구현에서 대조한다
|
||||
|
||||
세어봐라. 넘으면 고친다.
|
||||
- 토큰·테마 반전·브랜드 표면(theme-color·파비콘·og:image)·남은 코드가 프로젝트 결정을 반영하는가?
|
||||
- 로케일·문화권·실제 수치·진실 라벨이 브리프와 제공 자산의 범위를 지키는가?
|
||||
- 지원 viewport·성능 예산·상태별 시각 E2E는 프로젝트가 정한 매트릭스와 도구 한계 안에서 보고됐는가? 자동 도구가 측정하지 못한 항목은 통과로 추정하지 말고 수동 평가로 남긴다.
|
||||
|
||||
#### 스타일 휴리스틱 — 계수는 시작점이지 판정이 아니다
|
||||
|
||||
세어보고, 반복이 정보·브랜드·사용성에 맞는지 실제 렌더에서 평가한다. 아래 수치를 넘겼다는 사실만으로 고치거나 통과시키지 않는다.
|
||||
|
||||
- 작은 대문자 라벨(eyebrow) 개수 ≤ `ceil(섹션수 / 3)`
|
||||
- 같은 이미지+텍스트 스플릿 레이아웃 연속 ≤ 2회
|
||||
- 마퀴 ≤ 1개
|
||||
- 마퀴: 반복·자동재생·정지 수단·감소 모션 경로를 검토한다
|
||||
- 섹션이 6개 이상이면 서로 다른 레이아웃 패밀리가 최소 3개
|
||||
- 히어로: 헤드라인 ≤ 2줄, 서브텍스트 ≤ 20단어, 텍스트 요소 ≤ 4개
|
||||
- 히어로: 제목 줄 수·서브텍스트 길이·텍스트 밀도가 목표 행동과 읽기 폭에 맞는지 확인한다. 줄 수를 맞추려고 글자 크기를 줄이지 않는다
|
||||
|
||||
**국소 경로는 카운트를 페이지 전체로 다시 세지 않는다.** 내가 손댄 부분이 기존 카운트를 넘기게 만드는지만 본다.
|
||||
**하드 게이트 15개는 경로와 무관하게 전부 돈다.**
|
||||
**규범·기능 하드 게이트는 경로와 무관하게 전부 돈다.**
|
||||
|
||||
> 통과 조건: 하드 게이트 15개 전부 "아니오", 카운트 규칙 통과, `preflight.md` 체크리스트 통과. 실패 항목이 있으면 4단계로 돌아간다.
|
||||
> 통과 조건: 규범·기능 하드 게이트 충족, 프로젝트 계약 대조 완료. 기능·접근성 자동 검사와 시각 평가(위계·브랜드·타입·구도·이미지·리듬)를 별도 보고하고, 스타일 휴리스틱의 보류·채택·수정 근거를 남긴다. 실패 항목이 있으면 4단계로 돌아간다.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -363,8 +367,9 @@ HTML-in-Canvas(`drawElementImage`)는 **폴백을 완성한 뒤에만** 얹는
|
|||
|
||||
```markdown
|
||||
# design.md
|
||||
브리프 3줄 / 레퍼런스 R1·R2·R3 URL / 한 문장 컨셉 / 프리셋 / 감수한 리스크 하나
|
||||
브리프 3줄 / 레퍼런스 슬롯과 출처 ID / 한 문장 컨셉 / 프리셋 / 표현 리스크의 채택·비채택 근거
|
||||
토큰 전체(타입·색·간격·모션) / 성능 예산과 실측치 / 채택한 이펙트와 그 폴백
|
||||
출처 ID → 원칙·조건 → 관찰 → 결정 → 검증 결과를 프로젝트 evidence 기록에 연결 / 기능·접근성 자동 검사와 시각 평가의 별도 결과
|
||||
의도적으로 하지 않은 것과 그 이유
|
||||
```
|
||||
|
||||
|
|
@ -382,6 +387,9 @@ HTML-in-Canvas(`drawElementImage`)는 **폴백을 완성한 뒤에만** 얹는
|
|||
|---|---|
|
||||
| `references/galleries.md` | 1단계 — 어느 갤러리를 볼지 정할 때 / **1′ — 국소 브리프 표** |
|
||||
| `references/reference-method.md` | 1단계 — 레퍼런스를 뜯어볼 때 |
|
||||
| `references/design-foundations.md` | **1·2단계 — 이론을 프로젝트 조건으로 번역할 때** |
|
||||
| `references/style-playbook.md` | **2·4단계 — 선택한 스타일의 표현 수단과 금기를 검토할 때** |
|
||||
| `references/evidence-ledger.md` | **0·1·2·5·6단계 — 출처와 관찰·결정·검증을 추적할 때** |
|
||||
| `references/presets/README.md` | 2단계 — 미학 방향을 고를 때 (고른 프리셋 하나만 추가로 읽는다) |
|
||||
| `references/tokens.md` | 3단계 — 토큰을 정할 때 |
|
||||
| `references/typography.md` | 3단계 — 폰트를 고를 때 / 4-1 — 적용할 때 |
|
||||
|
|
@ -396,7 +404,7 @@ HTML-in-Canvas(`drawElementImage`)는 **폴백을 완성한 뒤에만** 얹는
|
|||
| `references/preflight.md` | 5단계 — 감사 |
|
||||
| `references/antipatterns.md` | 3·5단계 — 한글 조판 / 슬롭 검출 |
|
||||
| `references/audit-gate.md` | **5단계 — 게이트(폐쇄 루프) 설계·설치·하니스 규칙** |
|
||||
| `tools/design-gate.mjs` | **5단계 — 범용 게이트 실행기(SEO/meta·대비·수축·페이지별 h1 최대 줄 계약·시각·WebKit 옵션)** |
|
||||
| `tools/design-gate.mjs` | **5단계 — 범용 게이트 실행기(SEO/meta·대비·수축·명시한 양의 h1 줄 수 계약·시각·WebKit 옵션)** |
|
||||
|
||||
## 작업 중 지켜야 할 것
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue