Design Style Explorer

Design Style Explorer

도메인 하나를 받아 동일한 콘텐츠를 30가지 스타일로 렌더링한 HTML 시안을 만들고, 비교 → 조합 → 확정 → 디자인 시스템 프롬프트 역추출까지 진행하는 워크플로.

핵심 원칙: 콘텐츠는 고정, 스타일만 변수. 시안 간 내용이 다르면 디자인 비교가 불가능하다.

워크플로

🔧 생성 엔진 — 3층 파이프라인 (기본 · 2026-07 전환)

스타일마다 HTML을 통짜 생성하지 않는다. DOM(스켈레톤)을 고정하고 CSS 3층(base·tokens·signature)만 만들어 assemble.py로 자립 HTML로 조립한다. 콘텐츠 동일성은 스켈레톤이 구조적으로 보장(프롬프트로 "같은 콘텐츠 지켜라" 부탁 불필요), 게이트는 coverage-lint 하나(환각 셀렉터·누락 영역).

• 자산: references/skeletons/ · base/ · tokens/(01~30, 원형 무관·공유) · signature/(구조 강한 스타일만) · assemble.py · coverage-lint.py
• 방법·상세는 반드시 이 문서대로: references/3-layer-pipeline.md
• 아래 2단계 "시안 생성"은 이 파이프라인으로 수행: 스타일당 tokens/style-NN.css(+구조적이면 signature/style-NN--X.css) 생성 → assemble.py 조립 → coverage-lint PASS. HTML 통짜 생성 금지.
• 새 원형 = skeletons/·base/ 2개만 저작(tokens 30 재사용). archetype-lint는 coverage-lint로 교체됨. 다양성은 map.py 좌표로 측정해 빈 코너를 재샘플.
• 세 원형(A 대시보드·B 대화·D 컬렉션) 조립 데모: docs/design-gallery/2026-07-26-{fintech,yeonseo,fashion}-zen/.

1단계 — 도메인 접수 · 콘텐츠 인터뷰 · 스펙 확정

⛔ 대시보드로 직행하지 마라. 대시보드는 11개 원형 중 하나일 뿐이다. 도메인에 안 맞는 원형을 고르면 시안 30개가 아무리 잘 나와도 비교할 수 없는 갤러리가 된다 (references/archetypes.md 서두의 실제 사고 사례). 되는 것만 완성도 있게 — 아무 업종이나 받지 말고, 데이터 근거가 있는 도메인을 선택지로 좁혀 제시한다.

1-A. 도메인 게이트 — 좁힌 선택지로 받는다 (AskUserQuestion 권장, 자유입력 지양): 사용자가 업종을 자유롭게 던지면 아래 세 갈래로 분류부터 한다:

1. 프로젝트 폴더를 줬다 (경로/docs/features/** 존재) → repo 역산으로 간다 (가장 정확, 도메인 제한 없음). 1-B 로.
2. references/domains.md 31칸에 매핑됨 (여행·쇼핑·서비스·정보·엔터의 하위) → 데이터 프리셋으로 간다. "호텔 예약" → Travel > Hotel.
3. 어디에도 안 맞음 (B2B SaaS·개발자도구·백오피스 등 갭) → 진행하되 "이 업종은 데이터 근거가 없어 원형을 질문으로 정합니다(완성도가 프리셋보다 약할 수 있음)" 를 한 줄 고지하고 1-C 인터뷰에 더 기댄다.

업종이 모호하면 31칸 메뉴를 상위 5개로 먼저 좁혀 고르게 한다(여행/쇼핑/서비스/정보/엔터 → 하위). 넓은 자유질문 대신 선택지를 준다.

1-B. rubric + 원형 초안: 브랜드 성격·타겟·1순위 목적(전환/신뢰/차별화)을 한 줄로 잡고(references/decision-framework.md), 게이트 결과에 따라 원형 초안을 만든다:

• repo 역산: 요구사항·코드(docs/features/**/*requirements.md, README, src/)를 읽어 역산. FR 목록이 곧 컴포넌트 목록.
• 프리셋: domains.md 칸의 원형 흐름·대표 사이트·견고성을 초안으로. 출발점이지 정답 아님 — 프리셋이 원형을 강제하면 대화형 핀테크에 대시보드를 이식하는 사고가 재발한다. 1-C 로 확인.

우선순위: repo 역산 > 프리셋 > 인터뷰. 초안이 잡히면 1-C 는 확인 수준으로 줄인다.

1-C. 콘텐츠 인터뷰 — 좁힌 1문항 우선 (references/archetypes.md): 핵심은 이 하나다. 선택지로 준다(자유서술 X):

"이 화면에서 사용자가 하는 단 하나의 행동은?" 훑는다(A) / 대화한다(B) / 읽는다(C) / 고른다(D) / 입력한다(E) / 흘려본다(F) / 만든다(G) / 찾는다(H) / 처음 배운다(I) / 로그인한다(J) / 내 정보를 본다(K)

→ 이 답이 화면 원형을 결정한다(둘 섞이면 주 하나 + 보조 하나). 프리셋/역산으로 이미 원형이 잡혔으면 이 문항으로 확인만 하고 넘어간다. 원형이 애매할 때만 보조 3문항(주인공 요소 / 반복 단위 / 빈 상태)을 하나씩 더 묻는다. 사용자가 "알아서 해줘" 면 원형 기본값으로 채우고 요약에서 확인받는다.

1-D. 스펙 확정: 고른 원형의 컴포넌트 목록(archetypes.md)을 도메인 언어로 채우고, master-prompt.md 의 [콘텐츠 스펙] 두 줄(화면 원형 / 컴포넌트)을 확정한다. 이때:

• 디자인 챌린지 9(archetypes.md)를 전부 만족시킨다 — 정체성·위계·반복 단위·상태 4종·밀도·긴/짧은 극단·결측/빈 상태·액션·내비게이션
• 콘텐츠 견고성: 그 원형의 "견고성 스트레스 포인트"를 섞어 최악 콘텐츠로 스트레스 테스트한다 (references/content-checklist.md)
• 데이터는 현실적인 한국어 더미로 직접 작성 (실존 인물·기업 이름 금지)
• 원형에 없는 컴포넌트를 이식하지 마라 — 대화형에 KPI·도넛, 읽기형에 목표 달성률을 넣는 순간 그 제품이 아닌 것을 비교하게 된다

확정한 스펙을 사용자에게 2~3줄로 요약(원형 + 주인공 + 견고성 포인트)해 보여주고 바로 진행한다. 모든 스타일에서 완전히 동일한 구성·데이터를 유지한다 — 이게 스타일 비교의 전제다.

출력 폴더에 _spec.json 을 남긴다 (2단계 게이트 ②가 읽는다):

{"archetype": "B", "domain": "연서", "note": "대화형(주) + 읽기형(보조)"}

콘텐츠 스펙 본문은 같은 폴더에 _content-spec.md 로 저장해 각 생성 에이전트가 동일하게 읽게 한다.

2단계 — 시안 생성 (3층 파이프라인)

방법은 references/3-layer-pipeline.md 가 정본이다 (최상단 "생성 엔진" 참조). HTML 통짜 생성·per-style 에이전트·병렬 저장 사고는 모두 폐기됐다. 이제 생성은 "조립"이라 거의 즉시·저비용이다(스타일 1개 ≈ CSS 2KB, 조립은 밀리초).

2-A. 스켈레톤 확보 — 이 (원형, 도메인)의 고정 DOM 하나.

• 1단계 콘텐츠 스펙을 스켈레톤 하나에 담는다(원형의 클래스·data-region 계약에 맞춰). references/skeletons/archetype-X.v1.html 가 있으면 그 클래스 계약을 문자 그대로 복제하고 콘텐츠만 이 도메인으로 교체해 새 스켈레톤을 만든다(그래야 base가 그대로 붙는다). 없으면 새 원형이니 2-D.
• 콘텐츠는 여기 한 번만 박는다 → 30장이 자동으로 동일(프롬프트로 "같은 콘텐츠 지켜라" 부탁 불필요).

2-B. 토큰·시그니처 — 스타일당 CSS.

• references/tokens/style-01~30.css 는 이미 있고 원형 무관이라 그대로 재사용(색·형태·밀도). 기본 30 스타일은 새로 만들 필요 없다.
• 구조가 강한 스타일(04 터미널·05 브루탈·07 미니멀·09 픽셀·10 에디토리얼·18 스위스 등)은 references/signature/style-NN--X.css 가 필요 — 없으면 저작(토큰으로 안 되는 구조적 특징만; 색·radius는 tokens 몫). 뭉친/색깔변주 스타일은 시그니처 없이 토큰전용.
• 새 스타일(31번+)을 원하면: map.py 좌표의 빈 코너를 골라 새 tokens(+구조적이면 signature) 하나만 만든다.

2-C. 조립 + 게이트 — NN=01..30 반복:

python3 "${CLAUDE_PLUGIN_ROOT}/skills/design-style-explorer/references/assemble.py" \
  <스켈레톤> OUT/style-NN.html <references/base/archetype-X.css> <references/tokens/style-NN.css> [references/signature/style-NN--X.css]

→ 각 조립물의 <style>을 뽑아 coverage-lint.py 로 검사. PASS 필수. 마지막에 30장 body 바이트 동일 확인(다르면 스켈레톤이 안 고정된 것 = 버그).

2-D. 새 원형 추가 (필요할 때만): references/skeletons/archetype-X.v1.html(고정 DOM·훅) + references/base/archetype-X.css(토큰 먹는 공용) 2개만 저작 → tokens 30 재사용. 원형당 스켈레톤 ~1개(T2), 영역 개수가 다른 스타일만 변형.

비용: 옛 방식은 30개 ≈ 350450만 토큰·57시간이었다. 새 방식은 스켈레톤 1개(신규 도메인) + 없는 signature 몇 개만 저작하고 나머지는 조립(즉시) → 한 자릿수 분·수십만 토큰. 3초컷 퍼널은 불필요(다 뽑는 게 싸다).

게이트 — coverage-lint(archetype-lint 후계자):

python3 "${CLAUDE_PLUGIN_ROOT}/skills/design-style-explorer/references/coverage-lint.py" <조립물.html> <그 조립물의 css>

CSS가 저지를 수 있는 실패의 전 집합을 덮는다 — ① 환각 셀렉터(스켈레톤에 없는 요소 스타일) ② 누락 영역(규칙 안 걸린 data-region). PASS 필수.

• 콘텐츠 동일성은 스켈레톤이 구조적으로 보장 → 별도 검사 불필요(옛 "119건 위반" 사고가 애초에 불가능).
• 원형 적합성은 스켈레톤·base 선택에서 이미 결정 — 대화형 스켈레톤엔 KPI 요소가 없으니 CSS로 KPI를 못 그린다(illegal state 불가능). 그래서 archetype-lint는 폐기·coverage-lint로 교체.
• style-lint(스타일 금칙: 라운드·그림자·그라디언트…)는 tokens/signature 대상으로 축소 존치. [MANUAL] 항목은 크리틱 루프에서 직접 확인.

사용자가 프롬프트 원문 자체를 요청하면 (다른 AI 도구에 쓰려는 경우) master-prompt.md + 해당 스타일 파일의 코드블록을 그대로 제공한다.

파일명: style-{번호}-{스타일명}.html 로 출력 디렉토리(docs/design-gallery/<날짜>-<도메인슬러그>/)에 저장하고 배치마다 사용자에게 제시한다. 각 배치 제시 후 한 줄씩 스타일별 특징을 설명하고 피드백을 받는다.

2.5단계 — 갤러리 자동 생성 (기본 = 심플)

배치가 끝나면 심플 갤러리 gallery.html 을 자동 생성한다 — 꾸미지 말고 시안이 한눈에 보이게:

• 카테고리/패밀리별로 묶은 카드 그리드 + 각 카드에 <iframe> 미리보기 + 새 탭 링크
• self-contained 인라인 CSS, 다크 배경, 반응형

경로를 안내하고 4단계 피드백을 받는다.

(선택) 시안이 많아 결정이 어려운 경우에만 references/decision-framework.md 의 결정 도구(별점·탈락·2-up 비교·rubric)를 갤러리에 얹는다. 사용자가 명시적으로 원할 때만 — 기본은 심플.

3단계 — 공통 기술 요건 (모든 시안에 적용)

• 단일 .html 파일, 순수 HTML/CSS/JS (폰트 CDN만 허용, 차트 라이브러리 금지)
• 한글 폰트: Pretendard CDN https://cdn.jsdelivr.net/gh/orioncactus/pretendard@v1.3.9/dist/web/static/pretendard.min.css
• 스타일별 디스플레이 폰트는 Google Fonts로 로드
• 반응형: 900px 이하에서 1~2열로 접힘
• prefers-reduced-motion 대응: 모든 연출 제거 후 완성 상태 즉시 렌더
• JS는 연출 전용 — 실패해도 HTML만으로 완전한 화면이어야 한다
• 숫자에 tabular-nums, 상태값은 색으로 구분되는 시각 요소로
• 파일 하단 푸터에 STYLE {번호} · {스타일명} 표기
• 콘텐츠·데이터는 1단계에서 확정한 것과 한 글자도 다르지 않게

4단계 — 비교·조합 루프 (퍼널로 좁히기)

퍼널 (references/decision-framework.md): 기본은 30개 전부 생성이라 1라운드(3초컷)가 안 끝난 상태로 여기 옵니다 — 2-A 에서 3초컷을 했을 때만 shortlist 로 좁혀져 있습니다. 4단계는 그 대상(30개 또는 shortlist)에 2라운드 정독(3~5개) → 3라운드 결승(2개 나란히 + 하이브리드) 만 남는다. 한 번에 5개까지만 비교.

사용자 피드백 유형별 대응:

• 조합: "2번 레이아웃 + 8번 컬러" → 축(레이아웃/컬러/타이포/모션)별로 병합한 하이브리드 생성
• 강도 조절: "5번인데 70%만" → 시그니처는 유지하되 금지 완화·효과 절제 버전 생성
• 도메인 재확인: 콘텐츠가 스타일 비교를 방해하면 1단계로 돌아가 콘텐츠만 교체
• 심화: 특정 스타일을 파고들 때는 v2 → v3로 버전을 올리며 프롬프트와 시안을 함께 수정

5단계 — 화면 세트 전개 (스타일 고정, 화면을 늘린다)

1~4단계가 "발산"(화면 1장 × 여러 스타일)이면, 여기는 "수렴"(스타일 1개 × 화면 여러 장)이다. 축이 뒤집힌다.

스타일이 확정되면 그 스타일 하나로 고정하고, 이번엔 화면을 늘린다. 실제 제품은 화면이 여럿이고, domains.md 의 원형 흐름이 이미 그 목록을 알려준다:

domains.md:  Travel > Hotel  =  D → E → A   /  화면 ~6
             → 검색 결과(D) · 예약 폼(E) · 내 예약(A/K)

5-A. 화면 목록 확정 — 프리셋의 원형 흐름을 화면으로 펼치고, 필요하면 공통 화면을 더한다:

• 도메인 고유: 흐름의 주·보조 원형 (호텔이면 D→E→A)
• 공통(어느 도메인에나): J 인증 · I 온보딩 · K 프로필·설정 — 필요할 때만
• 사용자에게 화면 목록을 먼저 확인받는다 (3~6장 권장, 많으면 비싸다)

5-B. _spec.json 에 화면별 원형 기록 — 화면마다 원형이 다르므로 게이트도 화면별로 돌아야 한다:

{"archetype": "D", "domain": "호텔 예약",
 "screens": {"screen-1-search": "D", "screen-2-booking": "E", "screen-3-mybookings": "K"}}

screens 키가 파일명에 포함되면 그 원형으로 검사한다. 파일명은 screen-N-<이름>.html.

5-C. 화면별 콘텐츠 스펙 — 각 화면마다 그 원형의 컴포넌트·견고성으로 스펙을 쓴다. 단 제품 세계관(브랜드명·데이터)은 화면 간 공유한다 — 검색 결과의 "남산 그랜드 호텔"이 예약 폼에도 그대로 나와야 한 제품처럼 보인다.

5-D. 한 스타일로 병렬 생성 — 화면당 1 에이전트, 전부 같은 스타일 프롬프트를 읽는다. 확정 스타일의 시각 언어(색·타이포·간격·시그니처)가 화면마다 흔들리면 세트가 아니다.

5-E. 게이트 — style-lint(전부 같은 스타일이어야) + archetype-lint(화면마다 다른 원형으로). 화면 세트 모드는 자동 인식된다:

python3 "${CLAUDE_PLUGIN_ROOT}/skills/design-style-explorer/scripts/archetype-lint.py" docs/design-gallery/<날짜>-<도메인>-set/
# ℹ️ 화면 세트 모드 — 화면마다 원형을 따로 검사합니다 (3개 정의)

5-F. 세트 갤러리 — 화면을 플로우 순서대로 나열한다(검색→예약→내예약). 스타일 비교 갤러리와 목적이 다르다 — 이건 "한 제품으로 보이나"를 확인하는 것.

6단계 — 확정 및 역추출

3층 파이프라인에선 역추출이 거의 불필요하다. 고른 스타일의 references/tokens/style-NN.css(+ base/archetype-X.css)가 이미 디자인 시스템이다 — 토큰 세트 + 컴포넌트 규칙. 랄프 등에 그대로 넘기면 된다(고른 결과물 = 핸드오프물). 아래 역추출 절차는 (구) HTML 통짜 데모에서 시스템을 뽑아낼 때만.

성공 기준: 이 문서 하나만 주면 다른 사람(또는 다른 AI)이 새 화면을 같은 얼굴로 만들 수 있어야 한다. 시안을 다시 안 봐도 되게.

검증법 (권장) — 역추출 직후 바로 시험한다: 시스템 문서만 주고(기존 시안 HTML 접근 금지) 세트에 없던 원형의 새 화면 1장을 만들게 한 뒤, 컬러 토큰이 얼마나 일치하는지 센다. 실측 사례(호텔 세트 → 로그인 화면): 토큰 19/19 = 100% 일치, 새로 지어낸 값 0개.

부수 효과 — 역추출은 코드 리뷰 역할도 한다. 실제로 이 과정에서 "카운트업 초기값이 0 이라 JS 실패 시 서울 호텔 0곳 노출" 버그가 잡혔다 (마스터 프롬프트의 "JS 실패해도 HTML만으로 완전한 화면" 위반). 시안 간 값이 다르면 그 사실을 적고 다수 값을 채택하되, 규칙 위반이면 올바른 쪽을 정답으로 박제한다.

값을 지어내지 마라 — 실제 파일에 있는 hex/px 만 쓴다. 대비 4.5:1 보정이 있었으면 그 이유까지 기록해 나중에 되돌리지 않게 한다.

스타일이 확정되면 그 시안의 시각 언어를 분석해 디자인 시스템 시스템 프롬프트로 역추출한다. 구조: 기술 스택 → 디자인 토큰(컬러/타이포/스페이싱/보더·그림자, 다크모드 포함) → 컴포넌트 작성 규칙 → 금지 사항 → good/bad 코드 예시 → 출력 전 자체 체크리스트. 이 프롬프트가 이후 해당 제품의 모든 화면 생산 기준이 된다.

품질 기준 (모든 시안 공통)

1. 스타일의 무드가 3초 안에 느껴져야 한다 — 어중간한 절충 금지
2. 시그니처 요소 1개 필수 구현
3. 매력 축에 맞지 않는 기법 이식 금지 (예: 럭셔리에 바운스, 미니멀에 블롭, 공공에 카운트업)
4. 출력 전 해당 스타일의 크리틱 루프를 실제로 수행하고 수정 후 출력

참조 파일

• references/domains.md — 도메인 프리셋 (업종 → 원형 조합·화면 흐름). Mind2Web(136 실사이트·2,022 태스크) 근거 31칸 + 갭 수동 정의. 1단계 1-B 에서 업종만 주어졌을 때 초안 소스. repo 역산 > 프리셋 > 인터뷰 우선순위.
• references/archetypes.md — 화면 원형 11종(A 대시보드 · B 대화 · C 읽기 · D 컬렉션 · E 폼·입력 · F 피드 · G 에디터·캔버스 · H 검색·결과 · I 온보딩 · J 인증 · K 프로필·설정) + 도메인 무관 디자인 챌린지 9. 1단계에서 가장 먼저 읽는다 — 여기서 원형을 잘못 고르면 30개 시안 전부가 무의미해진다.
• references/concepts.md — 설계 원리와 까먹으면 안 되는 개념 (매력 축, 금지 목록 철학, 아키텍처, 로드맵). 스킬을 수정·확장하거나 새 스타일을 추가할 때 반드시 먼저 읽는다.
• references/master-prompt.md — 도메인 파라미터형 공통 프롬프트 원문 (콘텐츠 스펙 규칙 + 기술 요건 + 품질 기준). 세션 시작 시 읽는다. 콘텐츠 스펙은 원형에서 채운다.
• references/prompts/ — 스타일별 완성형 프롬프트 30개. 시안 생성 직전 해당 파일을 반드시 읽고 원문 그대로 실행한다.
• scripts/style-lint.py (플러그인 안) — 스타일별 금지 규칙 자동 검사 (생성 후 게이트 ①). python3 "${CLAUDE_PLUGIN_ROOT}/skills/design-style-explorer/scripts/style-lint.py" <파일 또는 폴더>. FAIL 수정 후 재린트. 모든 스타일 공통 콘텐츠 견고성 WARN(tabular-nums·반응형·reduced-motion) 포함.
• scripts/archetype-lint.py (플러그인 안) — 원형 적합성 자동 검사 (생성 후 게이트 ②). python3 "${CLAUDE_PLUGIN_ROOT}/skills/design-style-explorer/scripts/archetype-lint.py" <폴더> (폴더의 _spec.json 에서 원형을 읽음, 또는 --archetype A~K). style-lint 와 직교 — 스타일이 맞아도 화면이 틀릴 수 있다. FAIL 이면 시안이 아니라 1단계 스펙을 고친다.
• references/content-checklist.md — 콘텐츠 견고성 체크리스트 (큰 숫자·긴 제목·결측·빈 상태·접근성·차트 왜곡). "예쁜 예시 말고 최악 콘텐츠 기준". 생성 직전 + 리뷰 시 점검.
• references/production-quality.md — 실무 프론트 그라운딩 (8px 그리드·타이포 스케일·컴포넌트 상태·CSS 변수·절제된 디테일, 레퍼런스 Linear/Vercel/Stripe/shadcn). AI-generic 티 안 나게 프로덕션급 마감. 시안 생성 시 스타일 프롬프트와 함께 적용.
• references/decision-framework.md — 결정 프레임워크 (여러 시안에서 하나 고르기: rubric → 축 설계 → 한 변수 → 퍼널 → 탈락 먼저 → 결정 갤러리 → 하이브리드). "예쁜 30"이 아니라 "좁혀지는 30". 1단계(기준)·2.5단계(갤러리)·4단계(좁히기)에서 적용.

상태: 30개 전부 v2 완성 (실무 다빈도 15 + 창조·개성 15, 패밀리 6묶음). 병렬 모드 + 린트 게이트(콘텐츠 견고성 WARN 포함) + 갤러리 자동 생성 반영.