--- name: brainstorming description: "Structured UX brainstorming with Visual Companion wireframes: context exploration → clarifying questions → 2-3 alternatives with tradeoffs → section-by-section approval → HARD GATE (no code/scaffolding without explicit user approval). Ideal for pre-design UX flow planning." triggers: - "brainstorming" - "브레인스토밍" - "UX 설계" - "ux design" - "아이디어 도출" - "와이어프레임" - "wireframe" - "화면 설계" - "흐름 설계" - "flow design" - "사전 설계" - "대안 검토" usage: "/brainstorming [주제]" --- # /brainstorming — 구조화 브레인스토밍 + Visual Companion > 출처: obra/superpowers 브레인스토밍 스킬 (MIT 라이선스, awesome-claude-skills 생태계) > 우리 시스템에 맞게 커스텀 (한국어 지원, 보험/금융 도메인 특화, 하드 게이트 강화) UX Flow 사전 설계 도구. 구현 전에 방향을 정렬하고, 트레이드오프를 명시적으로 검토하며, 사용자 승인 없이 코드/스캐폴딩을 생성하지 않는다. **모코시(개발6팀 UX/UI 전문가)** 가 이 스킬을 주도한다. --- ## User-invocable 사용자가 `/brainstorming`을 입력하면 이 스킬을 실행한다. --- ## Arguments - `/brainstorming` — 주제 없이 시작. Step 1에서 주제를 파악한다. - `/brainstorming <주제>` — 주제를 명시하여 시작 (예: `/brainstorming 보험 상품 비교 UX`) - `/brainstorming <주제> --visual` — Visual Companion HTML 목업 우선 생성 - `/brainstorming <주제> --spec-review` — spec-document-reviewer 자동 검토 포함 --- ## 절대 규칙 (하드 게이트) > **이 규칙은 어떤 상황에서도 예외 없이 적용된다.** 1. **승인 없는 코드/스캐폴딩 생성 절대 금지**: 사용자가 명시적으로 "구현해주세요" / "코드 작성해주세요" / "진행해주세요"라고 말하기 전까지, 실제 구현 코드나 프로젝트 스캐폴딩을 생성하지 않는다. 2. **섹션별 승인 필수**: 각 Step 완료 후 사용자 승인을 받아야 다음 Step으로 진행한다. 3. **브레인스토밍 산출물은 설계 문서**: HTML 와이어프레임은 시각화 도구이지 구현 산출물이 아니다. 이 둘을 혼동하지 않는다. 4. **추측 기반 진행 금지**: 사용자 의도가 불명확할 때 임의로 방향을 결정하지 않는다. 명확화 질문을 먼저 한다. --- ## 워크플로우 개요 ``` Step 1: 프로젝트 맥락 탐색 ↓ [승인 게이트] Step 2: 명확화 질문 (1개씩 단계적) ↓ [승인 게이트] Step 3: 2~3가지 대안 접근법 제안 ↓ [승인 게이트] Step 4: Visual Companion 와이어프레임 ↓ [승인 게이트] Step 5: spec-document-reviewer 검토 ↓ [승인 게이트] Step 6: ★★ 하드 게이트 — 명시적 승인 요구 ★★ ↓ [명시적 "구현하겠습니다" 확인] Step 7: 구현 핸드오프 (설계 문서 전달) ``` --- ## Step 1: 프로젝트 맥락 탐색 모코시는 브레인스토밍 시작 전에 반드시 프로젝트 컨텍스트를 파악한다. ### 레퍼런스 URL 활용 사용자가 레퍼런스 URL을 제공한 경우: - insane-design 스킬로 생성된 `design.md`가 있으면 참고 자료로 활용 - `design.md`의 §11 Layout Patterns, §06 Colors, §05 Typography Scale을 브레인스토밍 맥락에 반영 - "이 사이트의 레이아웃 패턴을 참고하되, 우리 도메인에 맞게 변형" 식으로 활용 ### 1.1 자동 탐색 (파일/문서 읽기) 다음 경로에서 관련 문서를 탐색한다: ```bash # 기획 문서 탐색 ls /home/jay/workspace/memory/plans/ ls /home/jay/workspace/memory/research/ # 현재 프로젝트 맥락 확인 cat /home/jay/workspace/memory/plans//context-notes.md ``` 탐색할 내용: - 현재 프로젝트 목표 및 제약사항 - 기존 UX 패턴 및 디자인 시스템 - 타겟 사용자 및 도메인 특성 (보험/금융 여부) - 기술 스택 및 구현 제약 ### 1.2 맥락 탐색 결과 출력 형식 ``` ## [브레인스토밍] 맥락 탐색 완료 **주제**: <브레인스토밍 주제> **도메인**: <보험 / 금융 / 기타> **탐색된 문서**: <읽은 파일 목록> ### 파악된 컨텍스트 - 프로젝트 목표: <요약> - 타겟 사용자: <요약> - 기존 패턴: <있으면 기술, 없으면 "새로운 패턴 설계 필요"> - 기술 제약: <있으면 기술> ### 미확인 항목 - <명확화 질문이 필요한 항목들> --- Step 2로 진행할까요? (명확화 질문을 시작합니다) ``` --- ## Step 2: 명확화 질문 (단계적 1개씩) ### 원칙 - **한 번에 1개 질문만 한다.** 여러 질문을 한꺼번에 던지는 것은 사용자를 압도한다. - 답변을 받은 후 다음 질문으로 넘어간다. - 충분한 컨텍스트가 확보되면 질문을 멈추고 Step 3으로 진행한다. - 최대 5개 질문까지만 한다. 넘지 않는다. ### 우선순위 질문 목록 아래 순서로 필요한 질문만 선택한다 (이미 맥락 탐색에서 파악된 항목은 건너뛴다): 1. **사용자 목표**: "이 UX를 통해 사용자가 달성하려는 핵심 목표는 무엇인가요?" 2. **진입/이탈 경로**: "사용자는 어느 화면에서 들어오고, 어디로 이동하나요?" 3. **가장 중요한 제약**: "UI/UX 설계에서 반드시 지켜야 할 제약이 있나요? (예: 모바일 우선, 접근성 등)" 4. **성공 기준**: "이 설계가 성공했다는 것을 어떻게 측정할 수 있나요?" 5. **기존 문제점**: "현재 UX에서 가장 불편한 점이나 개선이 필요한 부분은 무엇인가요?" ### 보험/금융 도메인 특화 추가 질문 도메인이 보험/금융으로 확인된 경우: - "규제 준수 요건이 있나요? (금소법, 전기통신금융사기 방지법 등)" - "보험 상품 비교 시 필수로 보여줘야 할 정보 항목은 무엇인가요?" - "민감 정보(개인정보, 보험료 등)의 표시 방식에 제약이 있나요?" ### 명확화 질문 출력 형식 ``` ## [브레인스토밍] 명확화 질문 (2/5) <질문 내용> (이전 답변 요약: <한 줄>) ``` --- ## Step 3: 2~3가지 대안 접근법 제안 ### 원칙 - 반드시 2개 이상, 3개 이하의 대안을 제안한다. - 각 대안은 서로 다른 트레이드오프를 가져야 한다. 유사한 대안 2개 제안은 금지. - 각 대안에 보험/금융 도메인 예시를 포함한다. - **추천 대안**을 명시하되, 최종 선택은 반드시 사용자가 한다. ### 출력 형식 ``` ## [브레인스토밍] 대안 접근법 제안 ### 대안 A: <접근법 이름> **핵심 아이디어**: <한 줄 요약> **UX 흐름**: 1. <단계 1> 2. <단계 2> 3. <단계 3> **장점**: - <장점 1> - <장점 2> **단점/위험**: - <단점 1> - <단점 2> **적합한 상황**: <이 대안이 최선인 조건> **보험/금융 예시**: <구체적 시나리오> --- ### 대안 B: <접근법 이름> [동일 구조] --- ### 대안 C: <접근법 이름> (선택적) [동일 구조] --- ### 트레이드오프 비교 | 기준 | 대안 A | 대안 B | 대안 C | |------|--------|--------|--------| | 구현 복잡도 | 낮음/중간/높음 | | | | 사용자 학습 곡선 | | | | | 전환율 영향 | | | | | 모바일 적합성 | | | | | 규제 준수 용이성 | | | | **모코시 추천**: 대안 — 이유: <한 줄> --- 어떤 방향으로 진행할까요? (A/B/C 선택 또는 혼합 가능) ``` ### 보험/금융 도메인 예시 시나리오 브레인스토밍 주제가 보험/금융 관련일 때 활용: - **보험 상품 비교 UX**: 실손 vs 종신 vs 정기보험 3단계 필터 → 핵심 보장 항목 카드 비교 → 월 보험료 시뮬레이터 - **보험금 청구 흐름**: 사고 유형 선택 → 필요 서류 체크리스트 → 진행 상태 추적 타임라인 - **보험 가입 온보딩**: 3가지 생애주기 프리셋 (사회초년생/가족형성기/은퇴준비) → 맞춤 추천 - **대출 한도 조회**: 즉각 피드백 방식 vs 단계별 입력 방식 vs 간편 인증 선조회 방식 --- ## Step 4: Visual Companion (HTML 와이어프레임) > **주의**: 이 단계의 HTML은 시각화 도구이다. 실제 구현 코드가 아니다. 브라우저에서 바로 열 수 있는 인터랙티브 목업이다. ### 생성 조건 사용자가 대안을 선택한 후, 또는 `--visual` 플래그가 있을 때 생성한다. ### HTML 와이어프레임 구조 모코시는 아래 빌딩 블록을 조합하여 와이어프레임을 생성한다: ```html
[옵션 A]
[내용]
[CTA]
[장점 목록]
[단점 목록]
[대안 A 화면]
[대안 B 화면]
``` ### 사용자 이벤트 JSON 로그 와이어프레임 내 클릭 이벤트를 추적하여 사용자의 선택 패턴을 파악한다: ```javascript // 이벤트 로그 시스템 const eventLog = []; function logEvent(type, data = {}) { const entry = { timestamp: new Date().toISOString(), type: type, data: data }; eventLog.push(entry); document.getElementById('event-log').textContent = JSON.stringify(eventLog, null, 2); } function selectOption(element, optionId) { // 이전 선택 해제 document.querySelectorAll('.wf-card').forEach(c => c.classList.remove('wf-selected')); element.classList.add('wf-selected'); logEvent('option_selected', { option: optionId }); } ``` ### 와이어프레임 저장 위치 생성된 HTML 파일은 다음 경로에 저장한다: ``` /home/jay/workspace/memory/brainstorming/<주제-kebab>/wireframe-.html ``` ### 와이어프레임 출력 후 안내 메시지 ``` ## [브레인스토밍] Visual Companion 생성 완료 **파일**: /home/jay/workspace/memory/brainstorming/<주제>/wireframe-<날짜>.html **열기**: 브라우저에서 파일을 직접 열면 인터랙티브 목업을 확인할 수 있습니다. 포함된 화면: - <화면 1 이름>: <간략 설명> - <화면 2 이름>: <간략 설명> 이벤트 로그: 각 버튼/카드 클릭 시 하단에 JSON으로 기록됩니다. --- 와이어프레임을 확인하셨나요? Step 5 (spec-document-reviewer 검토)로 진행할까요? ``` --- ## Step 5: spec-document-reviewer 내장 검토 브레인스토밍 결과물(설계 방향 + 와이어프레임)을 5개 차원으로 자동 검토한다. > `--spec-review` 플래그가 없어도, Step 6 하드 게이트 진입 전에 반드시 1회 실행한다. ### 5개 검토 차원 #### 차원 1: 완전성 (Completeness) 설계가 다루어야 할 모든 시나리오를 포함하는가? 체크 항목: - [ ] 정상 흐름(Happy Path) 정의됨 - [ ] 오류/예외 흐름 정의됨 - [ ] 빈 상태(Empty State) 정의됨 - [ ] 로딩 상태 정의됨 - [ ] 모바일/데스크톱 분기 정의됨 - [ ] 보험/금융: 규제 필수 고지사항 포함 여부 #### 차원 2: 일관성 (Consistency) 설계 내부에 모순이나 충돌이 없는가? 체크 항목: - [ ] 네이밍이 일관됨 (같은 기능에 다른 이름 사용 없음) - [ ] 네비게이션 흐름이 순환하지 않음 - [ ] 버튼/CTA 동작이 일관됨 - [ ] 폼 유효성 검사 규칙이 일관됨 #### 차원 3: 명확성 (Clarity) 사용자가 무엇을 해야 하는지 즉시 이해할 수 있는가? 체크 항목: - [ ] 각 화면의 주요 목적이 1개로 명확함 - [ ] CTA가 명확하고 유인 문구가 구체적임 - [ ] 에러 메시지가 사용자 행동을 안내함 - [ ] 진행 단계(Step Indicator)가 표시됨 #### 차원 4: 실현가능성 (Feasibility) 현재 기술 스택과 일정 내에 구현 가능한가? 체크 항목: - [ ] 사용 중인 프레임워크/라이브러리로 구현 가능함 - [ ] 외부 API 의존성이 명확히 파악됨 - [ ] 애니메이션/인터랙션의 구현 비용이 적절함 - [ ] 데이터 모델과 설계 흐름이 일치함 #### 차원 5: 테스트가능성 (Testability) 이 설계가 올바르게 동작하는지 어떻게 검증할 것인가? 체크 항목: - [ ] 각 화면에 대한 핵심 테스트 시나리오가 존재함 - [ ] 성공/실패 상태가 측정 가능함 - [ ] A/B 테스트 가설이 설정 가능함 - [ ] 주요 전환 지점에 이벤트 트래킹이 정의됨 ### spec-document-reviewer 출력 형식 ``` ## [브레인스토밍] spec-document-reviewer 검토 결과 | 차원 | 점수 | 상태 | 주요 이슈 | |------|------|------|---------| | 완전성 | 4/6 | ⚠️ 주의 | 오류 흐름 미정의 | | 일관성 | 5/5 | ✅ 통과 | — | | 명확성 | 3/4 | ⚠️ 주의 | CTA 문구 모호함 | | 실현가능성 | 4/4 | ✅ 통과 | — | | 테스트가능성 | 2/4 | ❌ 보완 필요 | 테스트 시나리오 없음 | ### 보완 권고사항 **[필수 보완]** (하드 게이트 진입 전 해결 권장) - <항목 1>: <구체적 보완 방향> - <항목 2>: <구체적 보완 방향> **[선택 보완]** (구현 중 해결 가능) - <항목>: <간략 설명> --- 보완 후 Step 6(하드 게이트)으로 진행할까요? 또는 필수 보완 항목을 먼저 해결하고 싶으신가요? ``` --- ## Step 6: ★★ 하드 게이트 — 명시적 승인 요구 ★★ > **이 단계를 건너뛰는 것은 절대 금지한다. 사용자가 아무리 급해도, 이 게이트를 통과하지 않으면 어떤 코드도 생성하지 않는다.** ### 하드 게이트 조건 체크 Step 6 진입 전 다음 조건이 모두 충족되어야 한다: | 조건 | 확인 방법 | |------|---------| | 대안 선택 완료 | 사용자가 "A안으로 하겠습니다" 등 명시 | | spec-reviewer 필수 항목 통과 | 모든 [필수 보완] 해결 확인 | | 와이어프레임 검토 완료 | 사용자가 "확인했습니다" 등 명시 | ### 하드 게이트 출력 (승인 요청 메시지) ``` ## [브레인스토밍] ★ 구현 승인 게이트 ★ 지금까지 브레인스토밍 결과를 요약합니다. ### 확정된 설계 방향 - **선택된 대안**: <대안 X — 이름> - **핵심 UX 흐름**: <3줄 이내 요약> - **구현 범위**: <포함/제외 항목> ### 예상 구현 산출물 - <산출물 1> - <산출물 2> - <산출물 3> ### spec-reviewer 검토 결과 - 완전성: <점수> | 일관성: <점수> | 명확성: <점수> - 실현가능성: <점수> | 테스트가능성: <점수> --- ⚠️ **이 단계부터 실제 코드/스캐폴딩을 생성합니다.** 구현을 시작하려면: **"구현 시작해주세요"** 또는 **"진행해주세요"** 라고 입력해주세요. 수정이 필요하면: **"<항목> 수정 후 진행"** 이라고 알려주세요. 브레인스토밍만 저장하려면: **"설계 문서만 저장해주세요"** 라고 입력해주세요. ``` ### 하드 게이트 판정 규칙 | 사용자 입력 | 모코시 행동 | |------------|-----------| | "구현 시작해주세요" / "진행해주세요" | Step 7 진행 | | "수정 후 진행" | 수정 사항 반영 → 게이트 재확인 | | "설계 문서만 저장" | Step 7-B 진행 (코드 없이 문서만 저장) | | 모호한 응답 (예: "좋아요", "괜찮네요") | **진행하지 않음.** "구현을 시작할까요? 명시적으로 확인해주세요." | --- ## Step 7: 구현 핸드오프 ### Step 7-A: 구현 시작 (승인된 경우) 사용자 명시적 승인 후, 모코시는 설계 문서를 담당 구현팀에 전달한다. ``` ## [브레인스토밍] 구현 핸드오프 완료 설계 문서가 저장되었습니다: - 계획서: /home/jay/workspace/memory/plans//plan.md (설계 반영) - 와이어프레임: /home/jay/workspace/memory/brainstorming/<주제>/wireframe-<날짜>.html 담당팀 전달 항목: ✅ 선택된 대안 및 근거 ✅ UX 흐름 단계별 설명 ✅ 와이어프레임 파일 경로 ✅ spec-reviewer 검토 결과 ✅ 보완 권고사항 구현 담당자: <팀명> 다음 단계: /project-kickoff 또는 /tdd-enforcement 스킬 활용 권장 ``` ### Step 7-B: 설계 문서만 저장 (코드 없이) ``` ## [브레인스토밍] 설계 문서 저장 완료 브레인스토밍 결과물만 저장합니다. 코드는 생성되지 않았습니다. 저장된 파일: - /home/jay/workspace/memory/brainstorming/<주제>/brainstorm-<날짜>.md - /home/jay/workspace/memory/brainstorming/<주제>/wireframe-<날짜>.html 나중에 구현을 시작하려면: /brainstorming <주제> — 이전 브레인스토밍 결과를 불러옵니다. ``` --- ## 보험/금융 도메인 특화 가이드 ### UX 설계 원칙 (보험/금융) 1. **신뢰 우선 설계**: 불안감을 줄이는 마이크로카피, 진행 상황 투명 공개 2. **인지 부하 최소화**: 복잡한 보험 정보는 점진적 노출(Progressive Disclosure) 3. **비교 용이성**: 상품 비교 시 핵심 지표 3~5개로 집중 4. **규제 준수 UX**: 필수 고지사항을 방해가 아닌 맥락적 도움말로 통합 5. **오류 비용 인식**: 보험 가입/해지 오류는 재정적 피해로 이어지므로 확인 단계 강화 ### 보험/금융 와이어프레임 패턴 라이브러리 모코시가 자주 활용하는 검증된 패턴: ``` 패턴 1: 상품 비교 카드 [상품명] [월 보험료] [주요 보장 3가지] [더보기] [가입하기] → 비교함 추가 버튼으로 2~3개 상품 나란히 비교 패턴 2: 단계별 가입 진행 표시기 [정보입력 ●] — [상품선택 ○] — [서류제출 ○] — [완료 ○] → 현재 위치 + 예상 소요 시간 표시 패턴 3: 보험료 시뮬레이터 나이: [슬라이더] / 성별: [토글] → 즉각 금액 업데이트 → 실시간 계산 피드백으로 탐색 유도 패턴 4: 청구 상태 타임라인 접수 ✅ → 서류검토 🔄 → 심사 ○ → 지급 ○ → 각 단계 예상 소요일 + 안내 메시지 포함 패턴 5: 마이페이지 보험 요약 [가입 상품 수] [총 보험료] [이번달 공제일] [최근 청구 현황] → 핵심 지표 카드 + 빠른 청구 CTA ``` --- ## 파일 관리 ### 브레인스토밍 산출물 저장 구조 ``` /home/jay/workspace/memory/brainstorming/ └── <주제-kebab-case>/ ├── brainstorm-.md # 브레인스토밍 전체 기록 ├── wireframe-.html # Visual Companion HTML └── spec-review-.md # spec-reviewer 검토 결과 ``` ### 이전 브레인스토밍 재개 동일 주제로 `/brainstorming`을 재실행하면: ```bash ls /home/jay/workspace/memory/brainstorming/<주제>/ ``` 이전 파일이 있으면: "이전 브레인스토밍 기록이 있습니다. 이어서 진행할까요? (Y/N)" --- ## 금지사항 1. **사용자 승인 없이 코드/스캐폴딩 생성 금지** — 이것이 이 스킬의 핵심 가치이다. 2. **한 번에 여러 명확화 질문 금지** — 1개씩 단계적으로 묻는다. 3. **대안 1개만 제안 금지** — 최소 2개, 트레이드오프가 명확해야 한다. 4. **spec-reviewer 생략 금지** — 하드 게이트 진입 전 반드시 실행한다. 5. **모호한 승인 수용 금지** — "좋아요" 수준의 반응은 구현 승인이 아니다. 6. **와이어프레임을 구현 코드로 혼동 금지** — HTML 목업은 설계 도구이다. 7. **도메인 컨텍스트 무시 금지** — 보험/금융 도메인 제약을 항상 고려한다. --- ## 빠른 참조 - **브레인스토밍 산출물**: `/home/jay/workspace/memory/brainstorming/` - **프로젝트 계획서**: `/home/jay/workspace/memory/plans/` - **조직도**: `/home/jay/workspace/memory/organization-structure.json` - **연계 스킬**: `/project-kickoff` (킥오프) → `/brainstorming` (설계) → `/tdd-enforcement` (구현) - **하드 게이트 참조**: `/nuclear-approval` 스킬의 승인 체계와 동일한 철학 --- **스킬 버전**: v1.0 **작성일**: 2026-04-12 **작성자**: 모코시 (개발6팀 UX/UI 전문가) **출처**: obra/superpowers 브레인스토밍 스킬 (MIT 라이선스) 커스텀 **참조**: ship SKILL.md, adversarial-review SKILL.md, project-kickoff SKILL.md, agent-meeting SKILL.md