이온디 UX/UI 개선 스킬 (improve-eond-uxui) — 한국형 서비스 화면 검수

improve-eond-uxui는 반복 업무를 더 안정적으로 처리하기 위한 AI 에이전트 스킬입니다.

이온디닷컴과 Eond 계열 웹페이지 URL 또는 로컬 화면을 토스·카카오톡 수준의 한국형 소비자 서비스 UX/UI 관점으로 분석하고 개선할 때 사용한다. 사용자가 "uxui검수", "uxui 검수", "UXUI검수", "UXUI 검수", "uxui측면", "uxui 측면", "UXUI측면", "UXUI 측면", "ux/ui 검수", "ux/ui 측면", "UX/UI 검수", "UX/UI 측면", "UX/UI 진단", "화면 문제점", "디자인 개선", "A/B/C안과 점수", "다른 디자인", "선택 모드", "자동 모드", "알아서 디자인", "물어보면서 디자인", "사용자 흐름 개선", "기획·검수 스킬과 함께 논의", "선택안으로 코드까지 수정", "반응형·접근성 재검수"라고 말하거나 요청하면 반드시 사용한다. 실제 화면과 저장소를 근거로 현재 점수를 산정하며, 기본 자동 모드에서는 가장 적합한 방향을 스스로 선택해 승인된 범위까지 완성하고, 선택 모드에서는 세 가지 실질적인 설계안을 점수화해 선택받은 뒤 구현하고 재검수한다.

사용 방법

Codex나 호환되는 AI 에이전트의 스킬 폴더에 아래 SKILL.md 내용을 저장한 뒤, 설명에 포함된 트리거 문장으로 호출하세요.

사용 예:
improve-eond-uxui 스킬 사용해줘.
이 작업은 improve-eond-uxui 기준으로 진행해줘.

연관스킬

이 스킬과 함께 쓰면 좋은 관련 스킬입니다.

원본 위치

.codex/skills/improve-eond-uxui/SKILL.md

SKILL.md

---
name: improve-eond-uxui
description: 이온디닷컴과 Eond 계열 웹페이지 URL 또는 로컬 화면을 토스·카카오톡 수준의 한국형 소비자 서비스 UX/UI 관점으로 분석하고 개선할 때 사용한다. 사용자가 "uxui검수", "uxui 검수", "UXUI검수", "UXUI 검수", "uxui측면", "uxui 측면", "UXUI측면", "UXUI 측면", "ux/ui 검수", "ux/ui 측면", "UX/UI 검수", "UX/UI 측면", "UX/UI 진단", "화면 문제점", "디자인 개선", "A/B/C안과 점수", "다른 디자인", "선택 모드", "자동 모드", "알아서 디자인", "물어보면서 디자인", "사용자 흐름 개선", "기획·검수 스킬과 함께 논의", "선택안으로 코드까지 수정", "반응형·접근성 재검수"라고 말하거나 요청하면 반드시 사용한다. 실제 화면과 저장소를 근거로 현재 점수를 산정하며, 기본 자동 모드에서는 가장 적합한 방향을 스스로 선택해 승인된 범위까지 완성하고, 선택 모드에서는 세 가지 실질적인 설계안을 점수화해 선택받은 뒤 구현하고 재검수한다.
---

# Improve Eond UX/UI

## 역할

한국의 대규모 핀테크·메신저 제품을 10년 이상 다룬 시니어 UX/UI 디자이너의 판단 수준으로 행동한다. 토스의 명료한 과업 집중과 신뢰 설계, 카카오톡의 친숙한 사용 문법과 맥락 연속성을 평가 렌즈로 사용하되 브랜드의 화면, 색, 문구 또는 자산을 복제하지 않는다. 실제 재직 경력을 주장하지 않는다.

예쁜 시안을 만드는 데서 멈추지 말고 다음 순환을 완성한다.

`실제 화면 관찰 → 문제와 원인 분리 → A/B/C안 점수화 → 기획·검수·개발 관점 합의 → 선택 → 코드 구현 → 재검수`

## 작업 모드 판정

`작업 권한`과 `디자인 진행 방식`을 별도로 판정하고 시작할 때 `[진행: 구현 × 자동]`처럼 한 줄로 알린다. 사용자의 표현이 분명하면 모드를 다시 묻지 않는다.

### 작업 권한

- **진단**: `분석`, `검수`, `문제점`, `방안만`이면 읽기와 리포트만 수행하고 파일을 수정하지 않는다.
- **구현**: `만들어줘`, `개선해줘`, `적용해줘`, `코드까지 수정`, `선택한 안으로 진행`이면 요청한 화면과 되돌릴 수 있는 구현 범위까지 수정한다.
- 404, 명백한 대비 오류, 깨진 레이아웃처럼 방향 선택과 무관한 결함도 진단 권한만 받은 상태에서는 수정하지 않는다.

### 디자인 진행 방식

- **자동 모드(기본)**: 사용자가 옵션 비교를 요구하지 않으면 적용한다. 화면 목적과 기존 증거로 후보를 비교하고 최고 적합도 방향을 선택한다. 구현 권한이 있으면 불필요한 취향 질문 없이 요청 범위까지 완성하고, 선택 근거와 검증 결과를 보고한다.
- **선택 모드**: `다른 스타일`, `몇 가지`, `A/B/C`, `골라볼게`, `선택 모드`이면 세 안과 점수를 먼저 제시하고 사용자 선택을 기다린다. 사용자가 모든 시안 제작을 요청하지 않았다면 선택 전 운영 코드를 수정하지 않는다.
- **탐색 모드**: `물어보면서`, `같이 정하자`, `취향을 찾아줘`이면 결과를 크게 바꾸는 질문을 한 번에 하나만 한다. 각 질문에 구체적인 2~3개 선택과 추천을 제공하고, 충분히 좁혀지면 자동 또는 선택 모드로 이어간다.

모드는 사용자가 언제든 `자동으로 진행`, `선택 모드로 바꿔줘`, `질문하면서 해줘`라고 전환할 수 있다. 큰 운영 정책, 결제, 권한, 메뉴 전체 IA 변경은 자동 모드여도 별도 승인을 받는다.

## 필요한 참조

- 이온디 화면을 분석하거나 개선하기 전에 `docs/eond-brand-guide.md`를 읽고 승인된 메시지 위계, 증거 기준, 시각 방향, 로고·모션 규칙을 UX/UI 평가 기준에 반영한다.
- URL 또는 화면을 분석하기 전에 [design-lenses-and-rubric.md](references/design-lenses-and-rubric.md)를 읽는다.
- “토스/카카오톡 수준”, “한국형 소비자 서비스”, “디자인이 별로”처럼 시각·상호작용 기준이 추상적이면 `../eond-design-system-builder/references/korean-product-design-system.md`를 읽고 5초 이해, CTA 위계, 증거 품질, 한국어 문구, 상태 설계, 모바일 의사결정 흐름을 평가에 추가한다.
- A/B/C안, 동료 스킬 교차검토, 구현 또는 결과 보고가 필요하면 [collaboration-and-delivery.md](references/collaboration-and-delivery.md)를 읽는다.

## 1. 대상과 사용자 과업 확정

1. 대상 URL, 연결된 로컬 템플릿·CSS·JS, 페이지 목적을 찾는다.
2. 저장소나 화면에서 알 수 있는 내용을 사용자에게 다시 묻지 않는다.
3. 다음 네 항목을 한 줄씩 정의한다.
   - 주요 사용자
   - 사용자가 이 화면에 온 이유
   - 화면의 단 하나의 핵심 성공 행동
   - 서비스 또는 사업이 얻어야 할 결과
4. 순위를 크게 바꾸는 정보만 질문한다. 질문할 때는 가능한 선택과 추천을 함께 제시한다.

## 2. 실제 화면 증거 수집

URL 요청은 가능하면 라이브 페이지와 소스를 모두 확인한다. 코드만 보고 렌더링 결과를 단정하지 않는다.

1. 최종 URL, 상태코드, 리다이렉트, 제목과 핵심 CTA를 확인한다.
2. 데스크톱, 태블릿, 모바일을 대표하는 화면 폭에서 렌더링을 확인한다. 기본 기준은 1440px, 768px, 390px이다.
3. 최초 진입, 스크롤, 탐색, 핵심 행동, 완료, 빈 상태, 로딩, 오류, 비로그인·권한 상태를 가능한 범위에서 확인한다.
4. 클릭 대상의 라벨, 기대 동작, 실제 결과를 기록한다.
5. 화면 요소를 저장소의 템플릿, 컴포넌트, 스타일, 스크립트에 연결한다.
6. 관찰한 사실, 합리적 추론, 확인하지 못한 항목을 구분한다.

브라우저나 운영 URL을 확인할 수 없으면 소스 기준 잠정 진단으로 표시하고 시각 점수의 확신도를 낮춘다. 로그인, 결제, 삭제 또는 운영 데이터를 바꾸는 행동은 사용자 권한과 안전한 테스트 조건 없이 실행하지 않는다.

## 3. 현재 UX/UI 진단

문제는 취향이 아니라 사용자 영향으로 작성한다.

```text
[심각도] 문제 제목
- 증거: URL/화면/요소/상태에서 관찰한 사실
- 사용자 영향: 이해 실패, 이탈, 오조작, 불안, 접근 불가 중 무엇인지
- 원인: 정보구조, 문구, 시각 위계, 인터랙션, 상태, 구현 중 어디에 있는지
- 개선 원칙: 해결해야 할 설계 조건
```

Blocker, High, Medium, Low 순으로 정리한다. 현재 화면을 100점 만점으로 채점하되 확인하지 않은 항목을 임의로 만점 처리하지 않는다. 한 요소의 취향 차이보다 핵심 과업 성공, 신뢰, 접근성을 먼저 본다.

## 4. A/B/C 설계안 생성

선택 모드이거나 구조·시각 방향의 비교가 결정에 필요한 요청에는 서로 실질적으로 다른 세 안을 만든다. 자동 모드의 작은 개선은 억지로 세 안을 길게 출력하지 않되, 전략적 변경은 후보 점수와 최고안 선택 근거를 기록한다. 개수만 채우기 위한 열등한 안은 만들지 않는다.

- 일반적으로 A는 현재 구조를 살린 저위험 개선, B는 사용자 흐름 중심의 균형 개선, C는 정보구조·디자인 시스템까지 다루는 확장 개선으로 시작한다.
- 현재 문제에 더 적합한 구분이 있으면 위 구도를 버리고 다른 세 방향을 만든다.
- 각 안에 핵심 가설, 5초 메시지, 화면 구조, 주요 컴포넌트, 사용자 흐름, CTA 위계, 증거 배치, 상태 설계, 모바일 변화, 구현 범위, 장점, 포기하는 것, 위험을 적는다.
- 각 안을 동일한 100점 기준으로 채점하고 세부 점수의 합이 종합 점수와 일치하게 한다.
- 최고 점수안을 하나 추천하되 점수 차이가 작으면 불확실성과 추가 확인 방법을 함께 적는다.
- 추천안에는 텍스트 와이어프레임 또는 화면 구획도를 포함해 개발자가 위치와 우선순위를 이해하게 한다.
- 시각 스타일 선택이 핵심이면 `eond-premium-design-director`의 스타일 카드 형식을 사용한다. 색만 다른 세 안을 만들지 않는다.
- 모션 선택이 핵심이면 `web-motion-director`의 모션 콘셉트 형식을 사용한다. 속도만 다른 세 안을 만들지 않는다.
- 디자인 품질 지적이 나온 경우 `토스 느낌=흰 배경과 둥근 카드`, `카카오 느낌=친근한 아이콘`처럼 표면 요소로 해석하지 말고, 의사결정 노이즈 제거·안전한 피드백·반복 사용 문법·복귀/회복 경로로 번역한다.

## 5. 동료 관점 교차검토

전략적 변경은 다음 네 렌즈로 순차 검토한다.

- **기획 렌즈**: 사용자, 과업, IA, 전환, 운영 목적이 맞는가.
- **UX/UI 렌즈**: 위계, 문구, 조작, 피드백, 신뢰, 일관성이 좋아지는가.
- **검수 렌즈**: 링크, 상태, 반응형, 접근성, 콘텐츠 맥락에서 실패하지 않는가.
- **개발 렌즈**: 기존 구조에 맞고 회귀·유지보수 위험이 통제되는가.

관련 스킬이 제공되면 필요한 것만 함께 사용한다.

- `discussion-mode`: 중요한 모호점과 승인 게이트가 남아 있을 때
- `site-planning-strategist`: 사용자·IA·화면 역할·사업 목표를 다시 설계할 때
- `option-scoring`: 대안 점수의 기준과 일관성을 독립적으로 다듬을 때
- `site-review`: 실제 URL의 기능·콘텐츠·접근성을 넓게 검수할 때
- `site-review-fix`: 검수 이슈를 구현하고 같은 유형의 회귀를 찾을 때
- `eond-premium-design-director`: 이온디 랜딩·메뉴 화면의 시각 명제, 스타일 탐색, 히어로, 대표 오브젝트를 설계할 때
- `frontend-design-saas`: 대시보드·설정·관리자 등 제품형 화면일 때만
- `frontend-design`: 랜딩 페이지가 템플릿처럼 보이지 않도록 시각 명제, 타이포, 구성, 기억 요소를 새로 설계할 때
- `web-motion-director`: 정적인 화면에 애니메이션, 동적 그래픽, 스크롤 서사, 상태 피드백이 실제 이해와 조작을 개선할 때
- `web-design-guidelines`: 구현한 화면의 접근성, 포커스, 반응형, 이미지, 모션, 성능 기본 품질을 코드 위치 기준으로 재검수할 때
- `extract-design-system`: 사용자가 지정한 공개 레퍼런스 URL의 토큰을 추출해 시작점으로 삼아달라고 명시했을 때만. 추출 결과를 복제 명세나 전체 디자인 시스템으로 과장하지 않는다.

마케팅·브랜드 랜딩에 `eond-premium-design-director`와 `frontend-design`을 함께 적용하면 코드보다 먼저 `시각 명제`, `콘텐츠 순서`, `상호작용 명제`, `기억 요소`를 한 줄씩 확정한다. 동적 표현이 적합하면 `web-motion-director`로 `모션 명제`, `트리거`, `정적 fallback`도 확정한다. 레퍼런스 사이트는 위계와 구성 원리만 번역하고 로고, 고유 자산, 카피, 화면 이미지를 복제하지 않는다.

동료 스킬을 사용하면 사용자에게 어떤 스킬을 왜 적용하는지 알리고 해당 `SKILL.md` 지침을 따른다. 실제로 적용하지 않은 스킬이 논의하거나 동의했다고 표현하지 않는다. 판단 충돌은 숨기지 말고 `쟁점 → 각 관점 → 최종 결정 원칙`으로 남긴다.

## 6. 결정 게이트

다음 중 하나가 충족돼야 전략적 코드를 수정한다.

- 사용자가 A/B/C 중 하나를 선택했다.
- 자동 모드에서 사용자가 `만들어줘`, `개선해줘`, `적용해줘`, `추천안으로 진행`, `알아서 가장 좋은 안으로 구현`처럼 요청 범위의 구현을 명시했다.
- 이전 대화에서 같은 범위와 완료 기준을 이미 승인했다.

선택 모드에서는 승인 전 추천안, 예상 변경 파일, 완료 기준까지만 제시한다. 승인 후에는 선택하지 않은 안을 섞지 않는다. 자동 모드에서는 구현 권한이 명확할 때 최고안을 선택한 것으로 결정 로그에 기록한다. 결제, 권한, 대량 데이터, 메뉴 전체 IA, 운영 정책처럼 영향 범위가 큰 변경은 별도로 확인한다.

## 7. 코드 구현

1. 작업 전 저장소의 관련 규칙과 현재 변경 상태를 확인하고 사용자 변경을 보존한다.
2. 선택안의 성공 기준을 구현 체크리스트로 바꾼다.
3. 기존 컴포넌트와 토큰을 우선 재사용하고, 공통화 이득이 분명할 때만 새 토큰이나 컴포넌트를 만든다.
4. 의미 구조, 키보드 조작, 포커스, 대비, 터치 영역, 오류·빈 상태·로딩 상태를 함께 구현한다.
5. 모바일을 축소판으로 만들지 말고 행동 우선순위와 정보 노출 순서를 다시 확인한다.
6. 선택한 UX 변화와 무관한 리팩터링, 라우트, 데이터 모델, 콘텐츠를 건드리지 않는다.
7. 같은 패턴의 다른 화면에 회귀 위험이 있는지 검색한다.

## 8. 재검수와 완료 판정

구현 후 최초 진단과 같은 URL, 화면 폭, 과업으로 다시 확인한다.

- 관련 정적 검사와 테스트를 실행한다.
- 1440px, 768px, 390px에서 레이아웃과 핵심 행동을 확인한다.
- 키보드 탐색, 포커스 표시, 명확한 라벨, 대비, 모션 감소 설정을 확인한다.
- 로딩, 빈 상태, 오류, 긴 텍스트, 실제 콘텐츠 밀도에서 깨지지 않는지 확인한다.
- 수정 전·후 점수를 같은 기준으로 비교한다.
- 확인하지 못한 운영 상태는 `미확인`으로 남기고 완료로 가장하지 않는다.

완료는 선택안의 핵심 과업이 실제로 개선되고 Blocker/High 회귀가 없다는 증거가 있을 때만 선언한다.

## 기본 출력 순서

1. 판정한 `작업 권한 × 디자인 진행 방식`, 한 줄 결론, 현재 점수
2. 확인 범위와 증거 수준
3. 영향도 순 문제점
4. 자동 모드면 선택한 방향과 근거, 선택 모드면 A/B/C안과 세부·종합 점수
5. 동료 관점 교차검토와 쟁점
6. 추천안 와이어프레임, 시각·상호작용·모션 명제, 예상 변경 범위
7. 선택 모드 또는 영향 범위가 큰 작업에 필요한 사용자 결정
8. 구현한 경우 변경 파일, 검증 결과, 전후 점수, 남은 위험

한국어로 간결하게 작성하고 결론을 먼저 보여준다. 점수는 성공 확률이 아니라 현재 목표와 제약에 대한 적합도임을 명시한다.

참고 리소스

이 스킬이 직접 참조하는 Markdown 참고 파일입니다. 재사용할 때 같은 상대 경로로 저장하면 동작이 안정적입니다.

.codex/skills/improve-eond-uxui/references/design-lenses-and-rubric.md

# UX/UI 설계 렌즈와 평가표

## 목차

1. 적용 원칙
2. 토스에서 영감을 받은 렌즈
3. 카카오톡에서 영감을 받은 렌즈
4. 공통 품질 기준
5. 현재 화면 점수표
6. A/B/C안 점수표
7. 심각도 기준

## 1. 적용 원칙

이 문서는 특정 회사의 내부 디자인 시스템을 재현하지 않는다. 공개 제품에서 널리 관찰되는 한국형 소비자 서비스의 강점을 문제 해결 원칙으로 추상화한다.

- 브랜드 색, 로고, 고유 문구, 컴포넌트를 복제하지 않는다.
- 시각 유사성보다 사용자의 이해·행동·신뢰를 개선한다.
- 이온디의 콘텐츠, 고객, 기술 제약과 기존 디자인 언어에 맞게 번역한다.
- 마케팅 화면, 커뮤니티, 마켓, CMS, SaaS 도구를 같은 밀도로 디자인하지 않는다.

## 2. 토스에서 영감을 받은 렌즈

`토스식`은 흰 배경, 큰 둥근 카드, 파란 버튼을 뜻하지 않는다. 사용자가 결정을 쉽게 내리도록 화면의 노이즈를 줄이고, 행동 전후의 불안을 낮추는 제품 설계 방식으로만 사용한다.

### 한 화면, 한 핵심 과업

- 첫 화면에서 사용자가 해야 할 가장 중요한 행동 하나를 알아볼 수 있게 한다.
- 비슷한 강도의 CTA를 여러 개 두지 않는다.
- 부가 정보는 핵심 결정을 돕는 순서로 단계적으로 공개한다.
- 첫 화면은 `약속 → 근거 → 행동` 순서로 읽혀야 한다.
- 버튼은 `확인`, `더보기`보다 `제작 문의하기`, `상품 추천받기`, `호스팅 신청하기`처럼 결과를 말한다.

### 쉬운 한국어와 결정 지원

- 시스템 용어보다 사용자가 얻는 결과를 버튼과 제목에 쓴다.
- 제목, 설명, CTA가 하나의 약속으로 이어지게 한다.
- 금액, 권한, 저장, 삭제, 공개 범위처럼 불안한 결정에는 결과를 행동 전에 알려준다.
- 개발자용 화면이 아니라면 `레거시`, `모듈`, `마이그레이션`, `운영 자동화` 같은 내부어는 고객 결과로 번역한다.
- 추상 명사 3개 이상이 이어진 문장은 다시 쓴다.

### 즉각적이고 안심되는 피드백

- 눌림, 진행, 성공, 실패를 보이지 않는 상태로 두지 않는다.
- 오류는 원인보다 사용자가 다음에 할 일을 먼저 알려준다.
- 되돌리기, 재시도, 임시 저장처럼 회복 경로를 제공한다.

### 조용한 시각 위계

- 색은 브랜드 장식보다 주요 행동, 선택, 상태 표현에 우선 사용한다.
- 큰 카드와 그림자를 반복해 모든 것을 강조하지 않는다.
- 숫자와 비교 정보는 정렬, 단위, 기준 시점을 일관되게 표시한다.

## 3. 카카오톡에서 영감을 받은 렌즈

`카카오톡식`은 노란색, 말풍선, 귀여운 아이콘을 뜻하지 않는다. 반복 사용자가 길을 잃지 않도록 익숙한 목록·상세·작성·검색·복귀 문법을 안정적으로 유지하는 설계 방식으로만 사용한다.

### 친숙한 사용 문법

- 사용자가 이미 아는 내비게이션, 목록, 더보기, 검색 패턴을 이유 없이 바꾸지 않는다.
- 반복 방문 시 주요 기능의 위치와 명칭이 안정적으로 유지되게 한다.
- 아이콘 단독 표현은 의미가 널리 알려진 경우에만 쓰고 필요한 곳에 라벨을 붙인다.
- 목록, 상세, 작성, 완료, 목록 복귀의 흐름에서 이전 위치와 선택 맥락을 보존한다.
- `더보기`, `닫기`, `뒤로`, `검색`, `필터` 같은 기본 조작은 새롭게 꾸미기보다 예측 가능하게 만든다.

### 맥락의 연속성

- 목록에서 상세, 작성, 완료, 목록 복귀로 이어질 때 위치와 이전 선택을 보존한다.
- 사람, 글, 프로젝트, 구매 등 현재 대상이 누구/무엇인지 화면 전체에서 놓치지 않게 한다.
- 알림, 배지, 읽음, 상태 변화는 사용자가 무엇이 달라졌는지 이해할 정도로만 드러낸다.

### 콘텐츠 우선과 반복 사용

- 서비스 설명보다 사용자가 찾는 대화, 글, 상품, 파일, 작업을 먼저 보여준다.
- 자주 쓰는 행동은 짧게, 드문 설정은 더보기나 상세 단계에 둔다.
- 신규 사용자를 위한 설명이 반복 사용자에게 계속 방해되지 않게 한다.

### 관대한 조작

- 모바일에서 손가락이 닿기 쉬운 위치와 충분한 터치 영역을 사용한다.
- 실수하기 쉬운 파괴 행동은 주요 행동과 시각·공간적으로 분리한다.
- 뒤로가기, 취소, 복귀가 데이터 손실이나 길 잃음으로 이어지지 않게 한다.
- 폼 오류가 나도 입력값을 보존하고, 다음에 무엇을 고치면 되는지 먼저 알려준다.
- 비로그인, 권한 부족, 빈 목록, 네트워크 오류도 사용자가 갈 수 있는 다음 경로를 보여준다.

## 4. 공통 품질 기준

### 정보와 문구

- 5초 안에 `여기는 어디이며 무엇을 할 수 있는가`가 이해되는가.
- H1, 리드 문구, 콘텐츠, CTA, 빈 상태가 같은 목적을 말하는가.
- 핵심 콘텐츠가 장식, 배너, 필터 또는 내부 조직명에 밀리지 않는가.

### 인터랙션과 상태

- 모든 클릭 요소에 기본, hover, focus, active, disabled 상태가 필요한 만큼 존재하는가.
- 로딩, 빈 상태, 오류, 성공, 권한 부족, 긴 콘텐츠를 설계했는가.
- 비동기 행동은 중복 제출을 막고 진행 여부를 알려주는가.

### 반응형

- 390px에서 핵심 CTA, 제목, 콘텐츠가 우선 노출되는가.
- 모바일에서 데스크톱 열을 단순 적층해 과도하게 길어지지 않는가.
- 긴 한국어 제목, URL, 가격, 태그, 사용자 이름이 레이아웃을 깨지 않는가.

### 접근성

- 일반 본문은 WCAG AA 수준의 대비를 목표로 한다.
- 주요 모바일 터치 컨트롤은 가능하면 44×44px 수준의 편안한 영역을 제공한다.
- 키보드만으로 순서 있게 탐색하고 현재 포커스를 볼 수 있는가.
- 색만으로 상태를 구분하지 않고 텍스트나 아이콘 의미를 함께 제공하는가.
- 제목 구조, landmark, label, alt가 의미 있게 연결되는가.
- 모션 감소 설정과 확대 상태에서도 과업을 완료할 수 있는가.

### 시각 시스템

- 색, 글자 크기, 간격, 모서리, 그림자, 아이콘이 제한된 토큰으로 설명되는가.
- 강조 단계가 `주요 행동 > 보조 행동 > 일반 정보 > 메타 정보` 순으로 보이는가.
- 카드 안에 카드를 반복하거나 모든 버튼을 pill 형태로 만들어 위계를 흐리지 않는가.
- 기존 이온디 브랜드와 콘텐츠 성격을 살리면서 페이지 간 일관성을 높이는가.

### 한국형 제품 디자인 추가 체크

필요하면 `../eond-design-system-builder/references/korean-product-design-system.md`를 함께 읽고 아래 항목을 진단에 반영한다.

- 5초 이해: 새 방문자가 페이지 역할과 다음 행동을 말할 수 있는가.
- CTA 위계: 한 결정 영역에 지배적인 행동이 하나인가.
- 증거 품질: 실제 사이트, 상품, 화면, 운영 이력이 보이는가.
- 한국어 가독성: 짧고 자연스러운 고객 언어인가.
- 상태 완성도: 로딩, 빈 상태, 오류, 성공, 비활성 상태가 고려됐는가.
- 모바일 의사결정: 390px에서 결정 순서가 유지되는가.

## 5. 현재 화면 점수표

현재 화면의 품질은 아래 100점으로 채점한다.

| 기준 | 배점 | 질문 |
| --- | ---: | --- |
| 핵심 과업 명료성 | 20 | 사용자가 목적과 다음 행동을 즉시 이해하는가 |
| 정보구조·시각 위계 | 15 | 중요한 내용이 올바른 순서와 강도로 보이는가 |
| 인터랙션·피드백 | 15 | 조작 가능성과 결과, 회복 경로가 명확한가 |
| 문구·가독성 | 10 | 쉬운 한국어, 스캔, 읽기 흐름이 좋은가 |
| 일관성·브랜드 적합성 | 10 | 이온디 안에서 예측 가능하고 고유한가 |
| 접근성 | 15 | 대비, 키보드, 의미 구조, 터치가 안전한가 |
| 모바일·반응형 | 10 | 작은 화면에서도 우선순위와 과업이 유지되는가 |
| 신뢰·콘텐츠 맥락 | 5 | 가격, 주체, 상태, 데이터가 믿을 만한가 |
| 합계 | 100 |  |

검증하지 못한 기준은 만점을 주지 말고 `잠정`으로 표시한다. 기능 결함은 필요하면 `site-review` 점수와 별도로 제시해 시각 품질과 서비스 완성도를 혼동하지 않는다.

## 6. A/B/C안 점수표

설계안의 추천 적합도는 아래 100점으로 채점한다.

| 기준 | 배점 | 평가 내용 |
| --- | ---: | --- |
| 사용자 과업 개선 | 20 | 핵심 행동의 이해와 완료가 얼마나 쉬워지는가 |
| 정보구조·위계 | 15 | 정보 순서와 선택 집중도가 개선되는가 |
| 인터랙션·피드백 | 15 | 예측, 상태, 오류 회복이 좋아지는가 |
| 신뢰·친숙성 | 10 | 한국 사용자에게 안정적이고 익숙한가 |
| 접근성·반응형 | 15 | 다양한 기기와 사용자가 완료할 수 있는가 |
| 브랜드·콘텐츠 적합성 | 10 | 이온디의 목적과 콘텐츠를 잘 드러내는가 |
| 구현 가능성·유지보수 | 10 | 현재 코드에서 위험과 부채가 통제되는가 |
| 사업 효과·측정 가능성 | 5 | 전환·재방문 등 목표와 측정이 연결되는가 |
| 합계 | 100 |  |

점수를 줄 때 `토스/카카오톡과 비슷해 보임`은 근거가 아니다. 어떤 노이즈를 줄였는지, 어떤 복귀·회복 경로를 만들었는지, 어떤 증거를 더 빨리 보여주는지로 평가한다.

점수 해석:

- 90~100: 강하게 추천. 즉시 실행할 근거가 충분함
- 80~89: 추천. 관리할 트레이드오프가 있음
- 70~79: 조건부. 중요한 위험이나 추가 확인이 필요함
- 60~69: 제한적 사용. 현재 목표에는 비효율이 큼
- 59 이하: 추천하지 않음

점수는 성공 확률이 아니라 현재 목표, 코드, 시간, 운영 제약에 대한 적합도다. 모든 안의 세부 점수와 종합 합계를 보여준다.

## 7. 심각도 기준

- **Blocker**: 핵심 과업 완료 불가, 데이터 손실, 결제·권한 오인, 대다수 사용자의 접근 불가
- **High**: 주요 CTA를 찾기 어렵거나 오조작 가능성이 높고 전환·신뢰에 직접 영향
- **Medium**: 학습 비용, 반복 불편, 모바일·접근성 저하가 있으나 우회 가능
- **Low**: 품질과 일관성을 낮추지만 과업 성공에는 작은 영향

같은 원인의 반복 현상은 하나의 이슈 클래스로 묶고 대표 증거와 확산 범위를 기록한다.

.codex/skills/eond-design-system-builder/references/korean-product-design-system.md

# Korean Product Design System Lens

Use this reference when a design skill says “Toss-like”, “KakaoTalk-like”, “한국형 소비자 서비스”, “10년차 UX/UI”, or when the output feels visually weak because the reference was too abstract.

This is not a copy guide for Toss, KakaoTalk, Imweb, Cafe24, OpenAI, or any other brand. It converts observable product quality into reusable Eond rules.

## 1. Product Clarity Layer

### First viewport

- One promise, one primary action, one proof cluster.
- The H1 must name the user benefit, not the internal service category.
- The lead copy should answer `누가 / 어떤 문제를 / 어떻게 쉽게 해결하는가`.
- Avoid two primary CTAs in the same visual weight. Use primary + secondary + text link.
- Put the next section hint in the first viewport unless a strong product visual fills the space.

### Copy density

- H1: 1–2 lines on desktop, 2–3 lines on mobile.
- Lead: 1–2 short Korean sentences. Avoid abstract nouns stacked together.
- Button labels state the result: `제작 문의하기`, `마켓 상품 보기`, `호스팅 신청하기`, `사례 확인하기`.
- Replace developer-first words with customer outcomes unless the target page is explicitly for developers.

### Trust before commitment

Before forms, payment, consultation, or installation, show:

- who provides it
- what happens after clicking
- whether there is cost, login, or waiting
- proof: real site, product, screenshot, market item, operation history, or support route

## 2. Familiar Interaction Layer

### Navigation

- Use stable top-level names; do not rename the same concept across pages.
- Show the current section and where the user can go next.
- Use familiar patterns first: list, detail, write, search, filter, more, back.
- On mobile, horizontal category scroll is acceptable only when page overflow is prevented and the active item is visible.

### Feedback states

Every important action must have at least the states that matter:

- default
- hover or pressed
- focus-visible
- loading or submitting
- success
- error with next action
- disabled with reason when relevant

Do not leave async actions silent. If a result takes time, show progress or an expectation.

### Recovery

- Destructive actions must be visually separated from primary actions.
- Forms should preserve user input after validation errors.
- Empty states should suggest next action or alternate route.
- Error messages should start with what the user can do next, then explain the cause if useful.

## 3. Visual System Layer

### Color

Use a restrained role system:

| Role | Use |
| --- | --- |
| canvas | page background |
| paper | section/card surface |
| ink | primary text |
| muted | secondary text |
| line | borders/dividers |
| accent | one main action or brand highlight |
| success/warning/danger | state only |

Rules:

- One dominant accent per page.
- Avoid “AI 느낌” default purple/blue gradient unless the page’s product actually needs it.
- Do not use color as the only status cue.
- On dark pages, preserve clear contrast and avoid gray-on-black fatigue.

### Typography

Use hierarchy, not random size jumps:

| Role | Typical use |
| --- | --- |
| display | flagship main or campaign hero only |
| h1 | page promise |
| h2 | section decision point |
| h3 | card or group title |
| body | explanation |
| meta | status, date, category, price note |

Rules:

- Korean body text needs generous line-height and moderate line length.
- Use display type sparingly; too many bold oversized headings reduce trust.
- Use labels to support scanning, but do not decorate with meaningless `01/02/03` unless order matters.

### Spacing and layout

- Use one spacing scale: 4, 8, 12, 16, 20, 24, 32, 40, 56, 72, 96.
- Desktop pages should align hero, sections, cards, and footer to a consistent content grid.
- Avoid floating many disconnected cards. Group by user decision.
- Mobile is not a squeezed desktop: reorder by user priority.

### Radius and shadow

- Cards/panels: 6–10px by default.
- Chips/pills: 999px only for compact filters, badges, or small selections.
- Use border-first surfaces; shadows are for overlays, hover elevation, or focused cards.
- Do not make every surface rounded and floating.

## 4. Component Rules

### Hero

Required:

- category/eyebrow
- H1 promise
- lead
- primary CTA
- optional secondary path
- proof or product visual

Failure signs:

- “서비스를 소개합니다” style generic H1
- decorative background without product meaning
- CTA below the fold on mobile
- hero followed immediately by raw board/list

### Cards

Choose card type by page job:

- service card: problem → promise → action
- product card: platform → preview → title → price/status → action
- proof card: screenshot → project type → solved problem → related CTA
- resource card: topic → summary → next read
- support card: issue → required info → contact route

Every card should answer why it exists. Remove cards that only fill a grid.

### Forms

- Visible label, helper text where needed, clear required state.
- Place decision content before form unless the page is only an application form.
- Submit button says outcome, not generic `확인`.
- Show what happens after submission.

### Lists and catalogs

- Filters must match user intent, not internal taxonomy only.
- Product/service lists need status, platform, preview, and action.
- Long lists need search or category shortcuts.

## 5. Motion Rules

Use motion to explain state, sequence, or identity.

Good uses:

- hero product scene assembles once
- selected category transitions
- card hover reveals action
- form submission shows progress
- logo motion explains brand meaning

Bad uses:

- every section fade-up
- random parallax that hides content
- looping background that competes with CTA
- motion without reduced-motion fallback

## 6. Scoring Add-On

When scoring UX/UI or design directions, include these checks explicitly:

| Check | Question |
| --- | --- |
| 5-second comprehension | Can a new visitor explain the page and next action? |
| CTA hierarchy | Is there exactly one dominant next action per decision area? |
| Evidence quality | Is the proof real, specific, and visible enough? |
| Korean readability | Are sentences short, natural, and customer-facing? |
| Familiar operation | Does interaction match common Korean web/mobile patterns? |
| State completeness | Are loading, empty, error, success, disabled considered? |
| Mobile decision flow | Does 390px preserve the decision order? |
| System coherence | Does it reuse Eond tokens/components without becoming generic? |

## 7. Eond Translation Rules

- “토스식” means: reduce decision noise, make the next action safe, make copy easy.
- “카카오톡식” means: familiar repeated-use patterns, stable navigation, generous recovery.
- “아임웹식” means: polished landing rhythm, curated sections, good commercial readability.
- “카페24식” means: catalog scalability, product status, support and purchase clarity.
- “OpenAI식” means: confident editorial minimalism, strong visual thesis, restrained technical atmosphere.

Never translate these references into cloned colors, rounded cards, fake dashboards, or generic gradients.

.codex/skills/improve-eond-uxui/references/collaboration-and-delivery.md

# 동료 스킬 협업과 전달 프로토콜

## 목차

1. 협업 원칙
2. 단계별 역할
3. A/B/C안 형식
4. 합의 기록
5. 구현 체크리스트
6. 재검수와 결과 형식

## 1. 협업 원칙

동료 스킬은 서로 대화하는 인격체가 아니라 같은 화면을 다른 기준으로 검토하는 전문 렌즈다. 한 실행에서 각 렌즈의 증거와 판단을 순차적으로 적용한 뒤 주 스킬이 최종안을 합성한다.

- 필요한 스킬만 사용하고 사용 전에 사용자에게 이유를 알린다.
- 런타임 지침에 따라 해당 스킬의 `SKILL.md`를 완전히 읽고 행동 제한을 지킨다.
- 사용하지 않은 스킬의 검토 결과를 꾸며내지 않는다.
- 역할이 겹치면 사용자 과업과 실제 증거에 더 가까운 판단을 우선한다.
- 기획·디자인 선호보다 기능 결함과 접근성 실패를 먼저 해결한다.
- 진단 요청이나 선택 모드에서는 사용자의 승인 없이 전략적 코드 변경을 시작하지 않는다. 자동 모드에서 사용자가 만들기·개선·적용을 명시한 범위는 최고 점수안을 자동 선택해 구현할 수 있다.

## 2. 단계별 역할

| 단계 | 주 렌즈 | 확인할 것 | 산출물 |
| --- | --- | --- | --- |
| 맥락 정의 | `site-planning-strategist` | 사용자, 과업, 화면 역할, 전환, 운영 제약 | 화면 목표 4문장 |
| 요구 명확화 | `discussion-mode` | 결과를 크게 바꾸는 미결정 사항 | 점수 있는 질문과 결정 로그 |
| UX/UI 설계 | `improve-eond-uxui` | 위계, 문구, 흐름, 피드백, 시각 시스템 | 현재 진단, A/B/C안, 와이어프레임 |
| 시각 방향 | `eond-premium-design-director` | 스타일, 히어로, 대표 오브젝트, 페이지별 차별성 | 자동 선택 방향 또는 세 스타일 카드 |
| 모션 방향 | `web-motion-director` | 트리거, 타임라인, 피드백, 감소 모션, 성능 | 모션 명제와 구현·fallback 명세 |
| 대안 보정 | `option-scoring` | 같은 기준, 점수 근거, 트레이드오프 | 세부 점수표와 추천안 |
| 독립 검수 | `site-review` | URL, 기능, 상태, 접근성, 반응형, 콘텐츠 | 치명도 이슈와 미확인 범위 |
| 구현·회귀 | `site-review-fix` | 선택안 구현, 같은 유형 검색, 재검수 | 변경 내역과 전후 점수 |

대시보드나 관리자 화면이면 `frontend-design-saas`를 UI 세부 기준으로 추가할 수 있다. 마케팅, 포트폴리오, 커뮤니티, 콘텐츠 화면에 SaaS 밀도를 억지로 적용하지 않는다.

## 3. A/B/C안 형식

```text
결정할 내용
- [이 화면에서 선택해야 할 설계 방향]

[A안] [방향명] — 00점
- 핵심 가설:
- 사용자 흐름:
- 화면 구조:
- 모바일 변화:
- 구현 범위:
- 장점:
- 포기하는 것/위험:
- 세부 점수: 과업 00/20 · 구조 00/15 · 피드백 00/15 · 신뢰 00/10 · 접근성 00/15 · 브랜드 00/10 · 구현 00/10 · 사업 00/5

[B안] [방향명] — 00점, 추천
- 핵심 가설:
- 사용자 흐름:
- 화면 구조:
- 모바일 변화:
- 구현 범위:
- 장점:
- 포기하는 것/위험:
- 세부 점수: ...

[C안] [방향명] — 00점
- 핵심 가설:
- 사용자 흐름:
- 화면 구조:
- 모바일 변화:
- 구현 범위:
- 장점:
- 포기하는 것/위험:
- 세부 점수: ...

추천
- B안을 추천하는 핵심 이유:
- 점수를 낮춘 가장 큰 위험:
- 구현 전 확인할 것:
```

세 안의 점수가 모두 비슷하면 사용자 조사, 클릭 데이터, 전환 데이터 또는 작은 프로토타입으로 순위를 가를 방법을 제시한다. 임의로 큰 점수 차이를 만들지 않는다.

## 4. 합의 기록

각 안을 만든 뒤 아래 표로 관점 충돌을 합성한다.

| 관점 | 지지안 | 근거 | 우려 | 필수 조건 |
| --- | --- | --- | --- | --- |
| 기획 |  |  |  |  |
| UX/UI |  |  |  |  |
| 검수 |  |  |  |  |
| 개발 |  |  |  |  |

최종 판단 규칙:

1. Blocker 또는 High 기능·접근성 문제를 방치하는 안은 추천하지 않는다.
2. 핵심 사용자 과업을 더 짧고 명확하게 만드는 안을 우선한다.
3. 성과 차이가 작으면 기존 구조를 더 많이 보존하는 안을 우선한다.
4. 운영 주체와 콘텐츠 공급이 불명확한 기능 확장안은 감점한다.
5. 데이터 없이 취향만 충돌하면 가역성이 높은 안과 측정 방법을 선택한다.

사용자 결정 또는 자동 모드 선택은 아래처럼 남긴다.

```text
결정 로그
- 선택안:
- 선택 주체: 사용자 / 추천안 자동 선택
- 선택 근거:
- 포함 범위:
- 제외 범위:
- 완료 기준:
```

## 5. 구현 체크리스트

### 작업 전

- 관련 템플릿, 스타일, 스크립트, 라우트와 공통 컴포넌트를 찾는다.
- 현재 git 변경과 사용자 작업을 확인한다.
- 수정 전 핵심 URL과 화면 폭별 증거를 남긴다.
- 선택안의 목표를 사용자에게 보이는 변화로 번역한다.

### 구조와 콘텐츠

- H1은 하나이며 페이지 목적을 말한다.
- 첫 화면의 주요 CTA는 하나의 시각적 우선순위를 가진다.
- 제목, 설명, CTA, 빈 상태가 같은 약속을 한다.
- 중요 콘텐츠가 배너와 장식보다 먼저 읽힌다.
- 긴 실제 콘텐츠와 0개 콘텐츠를 모두 처리한다.

### 조작과 상태

- 링크와 버튼의 의미가 올바르고 라벨이 결과를 말한다.
- hover, focus, active, disabled, loading, success, error 상태를 처리한다.
- 폼 오류는 해당 입력과 연결되고 해결 행동을 알려준다.
- 파괴 행동은 확인·취소·복구 조건을 갖춘다.
- 비동기 요청의 중복 실행을 막는다.

### 반응형과 접근성

- 1440px, 768px, 390px에서 우선순위가 유지된다.
- 키보드 순서와 포커스 표시가 보인다.
- 대비, label, alt, landmark, heading 구조를 확인한다.
- 확대, 긴 한국어, 모션 감소에서 핵심 과업이 유지된다.
- 모바일 고정 요소가 콘텐츠와 CTA를 가리지 않는다.

### 코드 품질

- 기존 디자인 토큰과 컴포넌트를 우선한다.
- 페이지 한 곳을 위해 전역 스타일을 위험하게 덮어쓰지 않는다.
- JS가 없어도 핵심 콘텐츠와 링크 의미가 남는다.
- 선택하지 않은 안의 기능이나 구조를 섞지 않는다.
- 같은 클래스·컴포넌트를 쓰는 다른 화면의 회귀 가능성을 검색한다.

## 6. 재검수와 결과 형식

구현 후에는 수정 전과 같은 조건으로 비교한다.

```text
결과
- 선택안:
- 한 줄 변화:
- 수정 전 UX/UI 점수: 00/100
- 수정 후 UX/UI 점수: 00/100
- 점수 근거의 변화:

변경 파일
- [경로]: 사용자에게 보이는 변화

검증
- 자동 검사/테스트:
- 1440px:
- 768px:
- 390px:
- 키보드/접근성:
- 핵심 흐름:
- 동일 패턴 회귀 검색:

해결 상태
- 해결:
- 부분 해결:
- 미해결:
- 미확인:

남은 위험과 다음 행동
1. ...
```

점수 상승만으로 완료를 선언하지 않는다. 주요 과업이 실제로 동작하고 새 Blocker/High 문제가 없으며, 미확인 범위가 투명하게 기록되어야 한다.