디자인 선택 모드 스킬 (design-selection-mode) — UI 방향을 A/B/C로 고르기

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

사용자가 "디자인선택모드", "디자인 선택 모드", "디자인 선택모드", "디자인 방향 골라보자", "히어로 3시안", "디자인 A/B/C안", "코드 전에 디자인부터", "레퍼런스 보고 시안 잡자", "디자인 퀄리티를 올리자"라고 말할 때 사용한다. 코드를 바로 수정하지 않고, 사용자가 좋아하는 참고 사이트와 싫어하는 스타일을 바탕으로 실질적으로 다른 UI 디자인 방향 3안을 점수화해 고르게 만든다.

사용 방법

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

사용 예:
design-selection-mode 스킬 사용해줘.
이 작업은 design-selection-mode 기준으로 진행해줘.

연관스킬

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

원본 위치

.codex/skills/design-selection-mode/SKILL.md

SKILL.md

---
name: design-selection-mode
description: 사용자가 "디자인선택모드", "디자인 선택 모드", "디자인 선택모드", "디자인 방향 골라보자", "히어로 3시안", "디자인 A/B/C안", "코드 전에 디자인부터", "레퍼런스 보고 시안 잡자", "디자인 퀄리티를 올리자"라고 말할 때 사용한다. 코드를 바로 수정하지 않고, 사용자가 좋아하는 참고 사이트와 싫어하는 스타일을 바탕으로 실질적으로 다른 UI 디자인 방향 3안을 점수화해 고르게 만든다.
---

# 디자인선택모드

## 역할

코드 구현 전에 디자인 방향을 먼저 고르는 스킬이다. 사용자가 디자인 퀄리티에 불만을 말했거나, "멋있게", "OpenAI/Toss/Imweb 느낌", "다른 스타일", "A/B/C 시안"을 요구하면 이 스킬로 전환한다.

이 스킬의 목표는 빠른 구현이 아니라 `눈에 보이는 방향 선택`이다. HTML/CSS/JS를 깊게 수정하기 전에 레퍼런스, 싫은 스타일, 아트디렉션, 시안 범위를 확정한다.

## 작동 원칙

1. 사용자가 명시적으로 `수정 진행해`, `이 안으로 만들어줘`라고 하기 전에는 운영 코드나 프로토타입 파일을 수정하지 않는다.
2. "검정 배경", "큰 글자", "카드"처럼 표면 요소만 바꾸지 않는다. 구조, 타이포, 이미지 사용, 인터랙션, CTA 흐름이 다른 3안을 제시한다.
3. 레퍼런스는 복사하지 않는다. `왜 좋아 보이는지`를 분해해서 이 프로젝트의 브랜드와 목적에 맞게 재조합한다.
4. 사용자가 디자이너처럼 세부 지시를 하지 않아도 된다. 사용자는 좋아하는 URL, 싫은 스타일, 점수, 한 줄 피드백만 주면 된다.
5. 구현보다 먼저 "이 화면이 좋아 보이는가"를 검증한다. 기능은 선택된 방향 뒤에 붙인다.
6. `Toss`, `KakaoTalk`, `OpenAI`, `한국형 UX/UI` 같은 레퍼런스가 나오면 `.codex/skills/eond-design-system-builder/references/korean-product-design-system.md`의 기준으로 번역한다. 색, 둥근 카드, 그라데이션 같은 표면 복제가 아니라 메시지, CTA, 증거, 상태, 모바일, 문구 기준으로 판단한다.

## 먼저 진단할 실패 원인

디자인 결과가 별로라는 피드백이 나오면 방어하지 말고 아래 기준으로 원인을 분해한다.

- 레퍼런스를 실제 구조로 흡수하지 않고 말로만 참조했는가.
- 실제 제품, 화면, 포트폴리오, 서비스 자산이 주인공이 아니라 장식 라벨처럼 보이는가.
- 아트디렉션이 고정되기 전에 HTML/CSS 구현을 시작했는가.
- A/B/C가 색상이나 배치만 다른 유사안이었는가.
- 첫 화면의 주인공, 시선 순서, CTA, 증거가 5초 안에 보이는가.

## 사용자에게 요청할 입력

처음에는 아래 템플릿을 짧게 요청한다. 사용자가 이미 일부를 말했으면 빈칸만 물어본다.

```text
좋아하는 참고 사이트:
1.
2.
3.

싫은 스타일:
1.
2.
3.

이 화면은 이런 느낌이면 좋겠다:
```

예시:

```text
좋아하는 참고 사이트:
1. openai.com/ko-KR/codex - 검정 배경과 작업 화면 느낌
2. toss.im - 쉽게 이해되는 문장과 여백
3. imweb.me - 상업 페이지 흐름

싫은 스타일:
1. 카드만 많이 나열되는 화면
2. 흔한 AI 그라데이션
3. 가짜 대시보드 느낌

이 화면은 이런 느낌이면 좋겠다:
작지만 실력 있고, 직접 만든 제품들이 살아 움직이는 느낌
```

## 레퍼런스 분해 방식

참고 사이트를 받을 때는 "느낌 좋다"로 끝내지 말고 아래 항목으로 분해한다.

- 구도: 첫 화면이 텍스트 중심인지, 제품 중심인지, 작업 화면 중심인지.
- 여백: 넓고 조용한지, 밀도 있고 도구 같은지.
- 타이포: 브랜드명 중심인지, 문제 해결 문장 중심인지, UI 라벨 중심인지.
- 이미지: 실제 제품 화면인지, 추상 비주얼인지, 인터페이스 목업인지.
- 인터랙션: 입력 반응, 스크롤 서사, 마이크로 모션 중 무엇이 핵심인지.
- 전환: 상담, 구매, 사례 확인, 제품 탐색 중 무엇으로 보내는지.
- 시스템: 색/타입/간격/반경/상태/모바일 규칙으로 반복 가능한가.

인터넷 확인이 필요한 최신 사이트나 직접 URL 분석 요청이면 브라우징 또는 로컬 캡처를 사용한다. 단, 분석만 요청받은 단계에서는 파일을 수정하지 않는다.

## 3안 제시 형식

반드시 실질적으로 다른 세 방향을 낸다.

```text
디자인선택모드

현재 목표:
- 페이지:
- 첫 화면에서 전달할 메시지:
- 사용자가 해야 할 다음 행동:

[A안] 방향명 — 00점
- 시각 명제:
- 레퍼런스에서 가져올 원리:
- 5초 메시지:
- 레이아웃:
- 주인공 오브젝트:
- 이미지/자산 사용:
- 모션:
- CTA:
- 디자인 시스템 규칙:
- 상태/모바일:
- 장점:
- 포기하는 것:
- 구현 위험:

[B안] 방향명 — 00점, 추천
...

[C안] 방향명 — 00점
...

추천:
- 추천안:
- 이유:

사용자가 답하면 되는 방식:
`A 60점, B 85점, C 40점. B가 좋은데 더 밝았으면 좋겠어.`
```

## 시안 유형 예시

이름은 상황에 맞게 바꾸되, 세 안은 아래처럼 성격이 달라야 한다.

- Product Proof Stage: 실제 제품·포트폴리오 화면을 크게 보여주는 증거 중심형.
- Work Console: 사용자의 입력과 작업 흐름이 살아 있는 도구·콘솔형.
- Editorial Brand System: 브랜드 문장, 연혁, 철학, 실제 자산을 편집 디자인처럼 묶는 형.
- Commerce Catalog: 상품, 가격, 구매/상담 경로를 명확히 보여주는 상업형.
- Motion Identity: 로고, 키네틱 타이포, 브랜드 원리를 대표 모션으로 설명하는 형.

## 점수 기준

100점 만점으로 점수화한다.

- 첫눈의 완성도 25
- 브랜드 적합성 20
- 실제 증거와 자산 활용 15
- 전환 흐름 15
- 모바일 가능성 10
- 상태·접근성 설계 10
- 구현 가능성 5
- 차별성 5

점수는 사용자가 고르기 위한 판단 도구다. 화려함만 높게 평가하지 않는다.

## 선택 후 진행

사용자가 하나를 고르면 바로 구현하지 말고 한 번 더 좁힌다.

```text
선택안: B안 Work Console

구현 전 확정할 것:
1. 첫 화면만 만들지, 다음 섹션까지 만들지
2. 실제 자산 이미지를 쓸지, 임시 목업을 만들지
3. 모션은 정적/절제형/반응형 중 어디까지 할지

이대로 진행하려면 `수정 진행해`라고 해줘.
```

사용자가 `수정 진행해`라고 승인하면 그때 구현 스킬이나 디자인 구현 작업으로 넘어간다.

## 금지

- 사용자가 디자인 퀄리티를 문제 삼았는데 바로 코드를 고치기.
- A/B/C를 색상, 라운드, 그림자 차이 정도로만 만들기.
- 실제 자산이 필요한 브랜드 화면에 가짜 대시보드만 넣기.
- "OpenAI 느낌"을 단순한 검정 배경과 큰 글자로 해석하기.
- "Toss 느낌"을 단순한 흰 배경과 둥근 카드로 해석하기.
- "카카오톡 느낌"을 노란색, 말풍선, 귀여운 아이콘으로 해석하기.
- 선택 전에 모든 안을 섞어 평균적인 화면으로 만들기.

참고 리소스

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

.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.