Initial commit
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
BIN
.claude/.DS_Store
vendored
Normal file
BIN
.claude/.DS_Store
vendored
Normal file
Binary file not shown.
560
.claude/commands/README.appkit.md
Normal file
560
.claude/commands/README.appkit.md
Normal file
@@ -0,0 +1,560 @@
|
||||
# AppKit Framework
|
||||
|
||||
**아이디어를 고객 가치로 변환하는 논리적 사고 프레임워크**
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Overview
|
||||
|
||||
AppKit은 막연한 아이디어를 고객 중심으로 구체화하여 MVP부터 세일즈까지 설계하는 프레임워크입니다.
|
||||
|
||||
**핵심 철학**:
|
||||
1. 고객 가치 우선 → 기능이 아닌 고객의 문제 해결 중심
|
||||
2. 논리적 사고 연습 → 큰 작업을 작은 단계로 쪼개기
|
||||
3. 스토리텔링 기반 → 고객의 하루와 고민을 이해하고 설득
|
||||
4. MVP 중심 실행 → 최소한의 범위로 최대한의 검증
|
||||
|
||||
---
|
||||
|
||||
## 📋 Complete Workflow (논리적 사고 7단계)
|
||||
|
||||
```
|
||||
아이디어 구체화 7단계:
|
||||
1. /appkit.new → 아이디어 스케치 (어떤 서비스인지?)
|
||||
2. /appkit.spec → 기능 구체화 (뭐가 필요할까? 누가 쓸까?)
|
||||
3. /appkit.customer → 고객 스토리 (고객의 하루, 고민, 해결)
|
||||
4. /appkit.sales → 세일즈 랜딩 구성 (어떻게 설득할까?)
|
||||
5. /appkit.mvp → MVP 범위 정하기 (최소한으로 검증하려면?)
|
||||
6. /appkit.merge → 기획 정돈 (흩어진 기획 통합)
|
||||
7. /appkit.design → 개발 준비 (API, ERD, 기술 스펙)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Commands
|
||||
|
||||
### 1. `/appkit.new` - 아이디어 스케치
|
||||
|
||||
**Purpose**: 막연한 아이디어를 서비스 컨셉으로 구체화
|
||||
|
||||
**Input**:
|
||||
```
|
||||
/appkit.new Tennis court booking app with coupons and promotions
|
||||
```
|
||||
|
||||
**Output**:
|
||||
- `docs/appkit/overview.md` - 서비스 컨셉 & 핵심 가치
|
||||
- `docs/appkit/specs/001-user/spec.md` - 빈 템플릿
|
||||
- `docs/appkit/specs/002-venue/spec.md` - 빈 템플릿
|
||||
- `docs/appkit/specs/003-booking/spec.md` - 빈 템플릿
|
||||
- ...
|
||||
|
||||
**Key Features**:
|
||||
- 서비스 본질 파악 (무슨 문제를 해결하나?)
|
||||
- 예상 고객군 추론 (누가 쓸까?)
|
||||
- 핵심 가치 제안 (왜 써야 할까?)
|
||||
- 경쟁 차별점 식별 (다른 서비스와 뭐가 다른가?)
|
||||
|
||||
---
|
||||
|
||||
### 2. `/appkit.spec` - 기능 구체화
|
||||
|
||||
**Purpose**: 필요한 기능을 도출하고 사용자 관점에서 구체화
|
||||
|
||||
**Input**:
|
||||
```
|
||||
/appkit.spec 003-booking "search courts from main screen"
|
||||
/appkit.spec 003-booking "time deal 30% discount within 2 days"
|
||||
/appkit.spec 003-booking "cancel 24h+ before for 100% refund"
|
||||
```
|
||||
|
||||
**Output**:
|
||||
- `docs/appkit/specs/003-booking/spec.md` 업데이트 (증분식 누적)
|
||||
|
||||
**Key Questions for Each Feature**:
|
||||
- **뭐가 필요할까?** → 필요한 기능들 도출
|
||||
- **누가 쓸까?** → 타겟 사용자 프로파일
|
||||
- **언제 쓸까?** → 사용 시나리오와 상황
|
||||
- **왜 쓸까?** → 해결하려는 문제나 욕구
|
||||
- **어떻게 쓸까?** → 구체적인 사용 플로우
|
||||
- **가치는?** → 사용자가 얻는 이익
|
||||
|
||||
**중요**: 기술 구현보다 사용자 가치에 집중!
|
||||
|
||||
---
|
||||
|
||||
### 3. `/appkit.customer` - 고객 스토리
|
||||
|
||||
**Purpose**: 타겟 고객을 명확히 하고 그들의 하루와 고민을 스토리로 구성
|
||||
|
||||
**Input**:
|
||||
```
|
||||
/appkit.customer
|
||||
/appkit.customer "30대 직장인 주말 운동"
|
||||
```
|
||||
|
||||
**Output**:
|
||||
- `docs/appkit/customer-persona.md` - 고객 페르소나
|
||||
- `docs/appkit/customer-journey.md` - 고객 여정 지도
|
||||
|
||||
**What it does**:
|
||||
1. **페르소나 구성**:
|
||||
- Demographics: 나이, 직업, 소득, 거주지
|
||||
- Psychographics: 라이프스타일, 가치관, 관심사
|
||||
- Pain Points: 현재 겪는 문제와 불편함
|
||||
- Goals: 달성하고 싶은 목표
|
||||
|
||||
2. **고객의 하루 스토리텔링**:
|
||||
```
|
||||
07:00 - 출근 준비하며 "오늘도 운동 못하겠네..."
|
||||
09:00 - 회사 도착 "주말엔 꼭 테니스 쳐야지"
|
||||
12:00 - 점심시간 "코트 예약하려니 전화해야 하네..."
|
||||
18:00 - 퇴근 "주말 코트 풀부킹이라니..."
|
||||
21:00 - 집 도착 "내일 아침 일찍 전화해야겠다"
|
||||
```
|
||||
|
||||
3. **문제 해결 시나리오**:
|
||||
- Before: 복잡한 예약 과정, 불확실한 가능 시간
|
||||
- After: 앱으로 간편 예약, 실시간 확인, 할인까지
|
||||
|
||||
**중요**: 고객 중심 사고의 핵심 - 기능이 아닌 고객의 삶을 이해!
|
||||
|
||||
---
|
||||
|
||||
### 4. `/appkit.sales` - 세일즈 랜딩 구성
|
||||
|
||||
**Purpose**: 고객을 설득하는 세일즈 메시지 구성
|
||||
|
||||
**Input**:
|
||||
```
|
||||
/appkit.sales
|
||||
/appkit.sales "time-saving for busy professionals"
|
||||
```
|
||||
|
||||
**Output**:
|
||||
- `docs/appkit/sales-landing.md` - 세일즈 랜딩 구조
|
||||
- `docs/appkit/value-proposition.md` - 가치 제안
|
||||
|
||||
**Landing Structure**:
|
||||
1. **Hook (문제 공감)**:
|
||||
- "매번 전화로 테니스 코트 예약하느라 지치셨나요?"
|
||||
|
||||
2. **Problem Agitation (문제 심화)**:
|
||||
- 전화 대기 시간 평균 15분
|
||||
- 원하는 시간대 이미 만석
|
||||
- 가격 비교 불가능
|
||||
|
||||
3. **Solution (해결책 제시)**:
|
||||
- 3초 만에 실시간 예약
|
||||
- 모든 코트 가격 한눈에 비교
|
||||
- 자동 할인 적용
|
||||
|
||||
4. **Social Proof (사회적 증명)**:
|
||||
- "이미 5,000명의 테니스 동호인이 사용 중"
|
||||
- 사용자 후기와 평점
|
||||
|
||||
5. **CTA (행동 유도)**:
|
||||
- 첫 예약 30% 할인
|
||||
- 지금 가입하고 혜택받기
|
||||
|
||||
**중요**: 기능 나열이 아닌, 고객 문제 해결 스토리!
|
||||
|
||||
---
|
||||
|
||||
### 5. `/appkit.mvp` - MVP 범위 정의
|
||||
|
||||
**Purpose**: 최소한의 기능으로 최대한의 검증
|
||||
|
||||
**Input**:
|
||||
```
|
||||
/appkit.mvp
|
||||
/appkit.mvp "2-week validation"
|
||||
```
|
||||
|
||||
**Output**:
|
||||
- `docs/appkit/mvp-scope.md` - MVP 범위 정의
|
||||
- `docs/appkit/mvp-metrics.md` - 검증 지표
|
||||
|
||||
**MVP Scoping Process**:
|
||||
1. **핵심 가치 파악**:
|
||||
- 고객이 가장 원하는 ONE thing은?
|
||||
- 없으면 서비스 의미가 없는 기능은?
|
||||
|
||||
2. **Phase 분류**:
|
||||
```
|
||||
Phase 0 (MVP - 2주):
|
||||
- 코트 검색/예약 (핵심)
|
||||
- 간단한 결제
|
||||
|
||||
Phase 1 (MVP+ - 1개월):
|
||||
- 사용자 리뷰
|
||||
- 할인 쿠폰
|
||||
|
||||
Phase 2 (확장 - 3개월):
|
||||
- 커뮤니티 기능
|
||||
- 코칭 매칭
|
||||
```
|
||||
|
||||
3. **검증 지표 설정**:
|
||||
- Success Metrics: 주간 예약 10건
|
||||
- Learning Metrics: 이탈 구간, 불만 사항
|
||||
- Next Decision: Phase 1 진행 여부
|
||||
|
||||
**MVP 원칙**:
|
||||
- ❌ "있으면 좋을" 기능 제외
|
||||
- ✅ "없으면 안되는" 기능만 포함
|
||||
- 목표: 빠른 시장 검증, not 완벽한 제품
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 🌊 Workflow Example (고객 중심 논리적 사고)
|
||||
|
||||
### Example: Tennis Court Booking App
|
||||
|
||||
```bash
|
||||
# Step 1: 아이디어 스케치 - "어떤 서비스인지?"
|
||||
$ /appkit.new Tennis court booking with coupons and time deals
|
||||
|
||||
Claude:
|
||||
📋 서비스 컨셉:
|
||||
- 문제: 테니스 코트 예약이 번거롭고 비싸다
|
||||
- 해결: 모바일로 간편 예약 + 자동 할인
|
||||
- 타겟: 주말 운동을 원하는 30-40대 직장인
|
||||
- 가치: 시간 절약, 비용 절감
|
||||
|
||||
주요 기능 분류:
|
||||
- 001-user: 사용자 인증
|
||||
- 002-venue: 코트 관리
|
||||
- 003-booking: 예약/결제
|
||||
- 004-promotion: 할인/쿠폰
|
||||
- 005-review: 리뷰
|
||||
|
||||
✅ Created service concept & 5 feature specs
|
||||
|
||||
# Step 2: 기능 구체화 - "뭐가 필요할까? 누가 쓸까?"
|
||||
$ /appkit.spec 003-booking "search courts from main screen"
|
||||
|
||||
💡 사용자 가치 분석:
|
||||
- 뭐가 필요? → 실시간 코트 검색 기능
|
||||
- 누가? → 퇴근 후 피곤한 직장인
|
||||
- 언제? → 지하철/버스에서 이동 중
|
||||
- 왜? → 빠르게 주말 운동 계획 세우기
|
||||
- 어떻게? → 원터치로 가까운 코트 찾기
|
||||
- 가치? → 5초 만에 예약 가능 확인
|
||||
|
||||
✅ User value added to spec
|
||||
|
||||
$ /appkit.spec 003-booking "time deal 30% within 2 days"
|
||||
|
||||
💡 사용자 가치 분석:
|
||||
- 뭐가 필요? → 시간 기반 자동 할인 시스템
|
||||
- 누가? → 유연한 시간대 가능한 프리랜서
|
||||
- 언제? → 갑자기 시간이 생겼을 때
|
||||
- 왜? → 저렴하게 운동하고 싶어서
|
||||
- 가치? → 정가의 70%로 즉시 예약
|
||||
|
||||
✅ Features defined with user value
|
||||
|
||||
# Step 3: 고객 스토리 - "고객의 하루, 고민, 해결"
|
||||
$ /appkit.customer
|
||||
|
||||
🎯 Primary Persona: 김대리 (35세, IT 기업)
|
||||
|
||||
하루 스토리:
|
||||
07:00 - "오늘도 운동 못하겠네..." (죄책감)
|
||||
12:00 - "주말엔 테니스 쳐야지" (결심)
|
||||
18:00 - "코트 예약 전화... 귀찮다" (좌절)
|
||||
19:00 - [앱 발견] "3초 만에 예약?" (희망)
|
||||
19:02 - "토요일 오전 예약 완료!" (만족)
|
||||
토요일 - "운동 후 상쾌한 주말" (성취)
|
||||
|
||||
✅ Customer persona & journey mapped
|
||||
|
||||
# Step 4: 세일즈 랜딩 구성 - "어떻게 설득할까?"
|
||||
$ /appkit.sales
|
||||
|
||||
📢 Landing Message:
|
||||
|
||||
[Hook]
|
||||
"매주 테니스 치고 싶은데, 예약이 너무 번거로우신가요?"
|
||||
|
||||
[Problem]
|
||||
- 전화 대기 15분
|
||||
- 원하는 시간 항상 만석
|
||||
- 비싼 정가
|
||||
|
||||
[Solution]
|
||||
"3초 예약, 자동 할인, 실시간 공석 확인"
|
||||
|
||||
[Proof]
|
||||
"이미 5,000명이 매주 사용 중"
|
||||
|
||||
[CTA]
|
||||
"지금 가입하고 첫 예약 30% 할인받기"
|
||||
|
||||
✅ Sales landing created
|
||||
|
||||
# Step 5: MVP 범위 - "최소한으로 검증하려면?"
|
||||
$ /appkit.mvp
|
||||
|
||||
🎯 MVP Scope (2주 검증):
|
||||
|
||||
Phase 0 (핵심만):
|
||||
- 코트 검색/예약
|
||||
- 간단 결제
|
||||
목표: 주 10건 예약
|
||||
|
||||
Phase 1 (1개월):
|
||||
- 할인 쿠폰
|
||||
- 사용자 리뷰
|
||||
목표: 재방문율 30%
|
||||
|
||||
Phase 2 (3개월):
|
||||
- 커뮤니티
|
||||
- 코칭 매칭
|
||||
|
||||
✅ MVP phases defined
|
||||
|
||||
# Step 6: 기획 정돈 - "기획이 일관적인가?"
|
||||
$ /appkit.merge
|
||||
|
||||
🔄 Planning Consolidation:
|
||||
|
||||
용어 통일성 확인:
|
||||
- "예약" vs "부킹" → "예약"으로 통일
|
||||
- "사용자" vs "유저" → "사용자"로 통일
|
||||
|
||||
기능 중복 제거:
|
||||
- spec 3개소에서 발견된 "실시간 알림" → 하나로 통합
|
||||
- customer journey와 sales의 메시지 일관성 확보
|
||||
|
||||
고객 여정 - 기능 매핑:
|
||||
✅ "주말 운동 계획" → 검색 기능
|
||||
✅ "간편한 예약" → 원터치 예약
|
||||
✅ "비용 절감" → 자동 할인
|
||||
|
||||
✅ Planning consolidated
|
||||
|
||||
# Step 7: 개발 준비 - "어떻게 만들까?"
|
||||
$ /appkit.design
|
||||
|
||||
🏗️ Technical Design:
|
||||
|
||||
ERD 설계:
|
||||
- User, Venue, Booking, Payment 엔티티
|
||||
- 관계 정의 및 제약조건
|
||||
|
||||
API 엔드포인트:
|
||||
- POST /bookings (예약 생성)
|
||||
- GET /venues?location=... (코트 검색)
|
||||
- POST /payments (결제 처리)
|
||||
|
||||
기술 정책:
|
||||
- Rate Limiting: 시간당 100회
|
||||
- Error Handling: 재시도 3회
|
||||
- Content Safety: 필터 규칙
|
||||
|
||||
✅ 아이디어 구체화 완료!
|
||||
이제 개발을 시작할 수 있습니다.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6. `/appkit.merge` - 기획 정돈
|
||||
|
||||
**Purpose**: 흩어진 기획 문서들을 통합하고 일관성 확보
|
||||
|
||||
**Input**:
|
||||
```
|
||||
/appkit.merge
|
||||
/appkit.merge "용어 통일 중점"
|
||||
```
|
||||
|
||||
**Output**:
|
||||
- `docs/appkit/merge/concept-map.md` - 통합 컨셉 맵
|
||||
- `docs/appkit/merge/journey-feature-map.md` - 고객 여정 - 기능 매핑
|
||||
- `docs/appkit/merge/terminology.md` - 표준 용어 사전
|
||||
- `docs/appkit/merge/consolidated-specs.md` - 통합된 기능 명세
|
||||
|
||||
**What it does**:
|
||||
1. **용어 통일성 확인**:
|
||||
- spec, customer, mvp의 용어 비교
|
||||
- 표준 용어 사전 생성
|
||||
|
||||
2. **기능 중복 제거**:
|
||||
- 여러 문서에 흩어진 동일 기능 통합
|
||||
- 기획 레벨에서 중복 해소
|
||||
|
||||
3. **고객 가치 일관성**:
|
||||
- customer journey와 sales 메시지 일관성
|
||||
- 핵심 가치 제안 명확화
|
||||
|
||||
**중요**: MVP 범위 정의 후, 개발 준비 전에 실행!
|
||||
|
||||
---
|
||||
|
||||
### 7. `/appkit.design` - 개발 준비
|
||||
|
||||
**Purpose**: 개발에 필요한 기술 스펙 생성 (ERD, API, 정책)
|
||||
|
||||
**Input**:
|
||||
```
|
||||
/appkit.design
|
||||
/appkit.design "RESTful API 중점"
|
||||
```
|
||||
|
||||
**Output**:
|
||||
- `docs/appkit/design/entities.md` - ERD 및 데이터 모델
|
||||
- `docs/appkit/design/apis.md` - API 엔드포인트 설계
|
||||
- `docs/appkit/design/tech-policies.md` - 기술 정책
|
||||
- `docs/appkit/design/screen-api-map.md` - 화면-API 매핑
|
||||
|
||||
**What it does**:
|
||||
1. **ERD 설계**:
|
||||
- 엔티티 및 관계 정의
|
||||
- Mermaid 다이어그램 생성
|
||||
|
||||
2. **API 엔드포인트 설계**:
|
||||
- RESTful API 명세
|
||||
- Request/Response 예시
|
||||
|
||||
3. **기술 정책 정의**:
|
||||
- Rate Limiting
|
||||
- Error Handling
|
||||
- Content Safety
|
||||
- Data Management
|
||||
|
||||
**중요**: merge 완료 후 개발 직전에 실행!
|
||||
|
||||
---
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 🎓 논리적 사고 7단계와 명령어
|
||||
|
||||
| 단계 | 질문 | 명령어 |
|
||||
|------|------|--------|
|
||||
| 1. 아이디어 스케치 | 어떤 서비스인가? | `/appkit.new` |
|
||||
| 2. 기능 구체화 | 뭐가 필요할까? 누가/어떻게 쓸까? | `/appkit.spec` |
|
||||
| 3. 고객 스토리 | 고객의 하루, 고민, 해결은? | `/appkit.customer` |
|
||||
| 4. 세일즈 구성 | 어떻게 설득할까? | `/appkit.sales` |
|
||||
| 5. MVP 범위 | 최소한으로 검증하려면? | `/appkit.mvp` |
|
||||
| 6. 기획 정돈 | 기획이 일관적인가? | `/appkit.merge` |
|
||||
| 7. 개발 준비 | 어떻게 만들까? | `/appkit.design` |
|
||||
|
||||
---
|
||||
|
||||
## 💡 Best Practices (논리적 사고 연습)
|
||||
|
||||
### 1. 고객부터 시작하기
|
||||
- 기능이 아닌 고객의 문제부터 생각하세요
|
||||
- "누가 쓸까?" 질문을 계속하세요
|
||||
|
||||
### 2. 작은 단계로 쪼개기
|
||||
- 큰 작업을 7-10개 작은 단계로 나누세요
|
||||
- 각 단계가 명확한 결과물을 갖도록 하세요
|
||||
|
||||
### 3. 스토리텔링으로 검증
|
||||
- 고객의 하루를 그려보세요
|
||||
- Before/After 시나리오를 구성하세요
|
||||
|
||||
### 4. MVP 먼저, 완벽은 나중에
|
||||
- "없으면 안되는" 기능만 Phase 0에
|
||||
- "있으면 좋은" 기능은 Phase 1+로
|
||||
|
||||
### 5. 세일즈 관점 유지
|
||||
- 기능 설명이 아닌 가치 설명
|
||||
- 고객이 얻는 이익 중심으로
|
||||
|
||||
### 6. 빠른 검증, 빠른 피벗
|
||||
- 2주 안에 MVP 검증
|
||||
- 실패해도 빠르게 방향 전환
|
||||
|
||||
### 7. 측정 가능한 목표
|
||||
- 모든 Phase에 구체적 지표 설정
|
||||
- 정성적 + 정량적 지표 균형
|
||||
|
||||
---
|
||||
|
||||
## 📂 Generated File Structure
|
||||
|
||||
```
|
||||
docs/appkit/
|
||||
├── overview.md # 1. 서비스 컨셉 (/appkit.new)
|
||||
├── specs/
|
||||
│ ├── 001-search/
|
||||
│ │ └── spec.md # 2. 기능 구체화 (/appkit.spec)
|
||||
│ ├── 002-booking/
|
||||
│ │ └── spec.md
|
||||
│ └── ...
|
||||
├── customer-persona.md # 3. 타겟 고객 (/appkit.customer)
|
||||
├── customer-journey.md # 3. 고객 스토리 (/appkit.customer)
|
||||
├── sales-landing.md # 4. 세일즈 메시지 (/appkit.sales)
|
||||
├── value-proposition.md # 4. 가치 제안 (/appkit.sales)
|
||||
├── mvp-scope.md # 5. MVP 범위 (/appkit.mvp)
|
||||
├── mvp-metrics.md # 5. 검증 지표 (/appkit.mvp)
|
||||
├── merge/ # 6. 기획 정돈 (/appkit.merge)
|
||||
│ ├── concept-map.md # 통합 컨셉 맵
|
||||
│ ├── journey-feature-map.md # 고객 여정 - 기능 매핑
|
||||
│ ├── terminology.md # 표준 용어 사전
|
||||
│ └── consolidated-specs.md # 통합된 기능 명세
|
||||
└── design/ # 7. 개발 준비 (/appkit.design)
|
||||
├── entities.md # ERD 및 데이터 모델
|
||||
├── apis.md # API 엔드포인트 설계
|
||||
├── tech-policies.md # 기술 정책
|
||||
└── screen-api-map.md # 화면-API 매핑
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Quick Start
|
||||
|
||||
```bash
|
||||
# 1. 아이디어 스케치
|
||||
/appkit.new "당근마켓처럼 중고거래 앱"
|
||||
|
||||
# 2. 기능 구체화
|
||||
/appkit.spec 001-search "위치 기반 상품 검색"
|
||||
/appkit.spec 002-chat "구매자와 판매자 채팅"
|
||||
|
||||
# 3. 고객 스토리
|
||||
/appkit.customer "20-30대 중고거래 선호"
|
||||
|
||||
# 4. 세일즈 메시지 구성
|
||||
/appkit.sales "편리함과 신뢰 강조"
|
||||
|
||||
# 5. MVP 범위 정의
|
||||
/appkit.mvp "2주 내 출시 목표"
|
||||
|
||||
# 6. 기획 정돈
|
||||
/appkit.merge
|
||||
|
||||
# 7. 개발 준비
|
||||
/appkit.design
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 📖 Philosophy (논리적 사고 철학)
|
||||
|
||||
> "아이디어는 고객의 문제에서 시작되고, 논리적 단계로 구체화된다."
|
||||
|
||||
AppKit은 다음을 믿습니다:
|
||||
|
||||
1. **고객 문제 우선**: 기능보다 고객의 Pain Point 해결
|
||||
2. **논리적 분해**: 큰 작업을 작은 단계로 쪼개기
|
||||
3. **스토리텔링**: 고객의 하루를 이해하고 공감
|
||||
4. **빠른 검증**: MVP로 시장 반응 먼저 확인
|
||||
5. **가치 중심**: 기술이 아닌 고객 가치로 설득
|
||||
6. **측정과 학습**: 모든 단계에서 배우고 개선
|
||||
|
||||
---
|
||||
|
||||
**Built with ❤️ for Product Managers, Designers, and Developers**
|
||||
|
||||
**Version**: 5.0.0 (7-Step Logical Thinking)
|
||||
**Last Updated**: 2025-11-20
|
||||
**Key Update**: 논리적 사고 7단계로 재구성, merge(기획 정돈)와 design(개발 준비) 분리
|
||||
279
.claude/commands/appkit.customer.md
Normal file
279
.claude/commands/appkit.customer.md
Normal file
@@ -0,0 +1,279 @@
|
||||
# appkit.customer
|
||||
|
||||
**타겟 고객을 명확히 하고 그들의 스토리를 구성하는 명령어**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**This is Step 3 of the logical thinking 7-step workflow**:
|
||||
|
||||
```
|
||||
논리적 사고 7단계:
|
||||
1. /appkit.new → 아이디어 스케치 (어떤 서비스인지?)
|
||||
2. /appkit.spec → 기능 구체화 (뭐가 필요할까? 누가 쓸까?)
|
||||
3. /appkit.customer → 고객 스토리 (고객의 하루, 고민, 해결) ← YOU ARE HERE
|
||||
4. /appkit.sales → 세일즈 랜딩 구성 (어떻게 설득할까?)
|
||||
5. /appkit.mvp → MVP 범위 정하기 (최소한으로 검증하려면?)
|
||||
6. /appkit.merge → 기획 정돈 (흩어진 기획 통합)
|
||||
7. /appkit.design → 개발 준비 (API, ERD, 기술 스펙)
|
||||
```
|
||||
|
||||
## Purpose
|
||||
|
||||
타겟 고객을 구체화하고 그들의 일상과 문제를 스토리텔링으로 풀어내어,
|
||||
서비스가 어떤 가치를 제공하는지 명확히 합니다.
|
||||
|
||||
**핵심 질문**: "누가, 왜 이 서비스를 쓸까?"
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- `/appkit.spec`으로 기능들을 구체화한 후 (Step 2 완료 후)
|
||||
- 타겟 고객이 여전히 모호할 때
|
||||
- 고객의 구체적인 사용 시나리오가 필요할 때
|
||||
- 세일즈 메시지 작성 전 고객 이해가 필요할 때
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/appkit.customer
|
||||
/appkit.customer "30대 직장인 주말 운동"
|
||||
/appkit.customer "persona: busy professional"
|
||||
/appkit.customer "journey: from problem to solution"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What I'll Do
|
||||
|
||||
### 1. 고객 페르소나 구성 (Customer Persona)
|
||||
|
||||
**Primary Persona** (주요 고객):
|
||||
```markdown
|
||||
## Primary Persona: [이름] ([나이], [직업])
|
||||
|
||||
### Demographics (인구통계)
|
||||
- 나이: 30-40대
|
||||
- 직업: IT 기업 직장인
|
||||
- 소득: 연 5000-8000만원
|
||||
- 거주지: 서울/경기 아파트
|
||||
- 가족: 기혼, 자녀 1-2명
|
||||
|
||||
### Psychographics (심리/행동)
|
||||
- 라이프스타일: 워라밸 추구, 건강 관심 증가
|
||||
- 가치관: 시간 효율성, 편의성 중시
|
||||
- 관심사: 주말 운동, 가족과 시간
|
||||
- 기술 친숙도: 높음, 모바일 앱 일상화
|
||||
|
||||
### Pain Points (현재 고민)
|
||||
1. 운동하고 싶은데 시간이 없다
|
||||
2. 코트 예약이 너무 번거롭다
|
||||
3. 원하는 시간대는 항상 만석
|
||||
4. 가격 비교가 어렵다
|
||||
|
||||
### Goals (달성하고 싶은 것)
|
||||
- 규칙적인 주말 운동
|
||||
- 스트레스 없는 예약 과정
|
||||
- 합리적인 가격으로 운동
|
||||
- 가족/친구와 함께하는 시간
|
||||
```
|
||||
|
||||
**Secondary Personas** (보조 고객):
|
||||
- 프리랜서 (시간 유연, 가격 민감)
|
||||
- 대학생 (저렴한 가격 선호)
|
||||
- 주부 (평일 낮 시간 활용)
|
||||
|
||||
### 2. 고객 여정 맵 (Customer Journey Map)
|
||||
|
||||
**하루의 스토리텔링**:
|
||||
|
||||
```markdown
|
||||
## 김대리의 하루 (현재 - Problem State)
|
||||
|
||||
### 평일
|
||||
07:00 😴 "오늘도 운동 못하겠네..." (죄책감)
|
||||
08:30 🚇 지하철에서 "주말엔 꼭 테니스 쳐야지" (다짐)
|
||||
12:00 🍽️ 점심시간 "코트 예약하려니... 전화해야 하나?" (귀찮음)
|
||||
15:00 ☎️ "예약 전화... 통화중이네" (짜증)
|
||||
18:00 😔 "주말 코트 다 찼대..." (실망)
|
||||
21:00 🏠 "내일 아침 일찍 전화해볼까?" (미룸)
|
||||
|
||||
### 주말
|
||||
토요일 오전 - 결국 운동 못함
|
||||
일요일 - 가족과 시간 보내느라 포기
|
||||
|
||||
---
|
||||
|
||||
## 김대리의 하루 (미래 - Solution State)
|
||||
|
||||
### 평일
|
||||
07:00 📱 침대에서 앱 열기 (3초)
|
||||
07:01 ✅ "토요일 오전 10시 예약 완료!" (만족)
|
||||
12:00 💰 "타임딜 30% 할인 알림" (기쁨)
|
||||
18:00 👥 "동료들도 같이 예약할까?" (공유)
|
||||
|
||||
### 주말
|
||||
토요일 10:00 - 테니스 코트에서 운동 중
|
||||
토요일 12:00 - "운동 후 상쾌해!" (성취감)
|
||||
일요일 - 가족과 여유롭게 시간 보내기
|
||||
```
|
||||
|
||||
### 3. 문제-해결 시나리오
|
||||
|
||||
**Before (현재 상황)**:
|
||||
```
|
||||
1. 예약하려면 → 전화해야 함 (15분 대기)
|
||||
2. 가격 확인 → 일일이 물어봐야 함
|
||||
3. 시간대 확인 → 전화로만 가능
|
||||
4. 취소/변경 → 또 전화
|
||||
5. 결과 → 포기하거나 비싼 값 지불
|
||||
```
|
||||
|
||||
**After (서비스 사용 후)**:
|
||||
```
|
||||
1. 예약 → 앱에서 3초 (실시간)
|
||||
2. 가격 → 한눈에 비교 (투명)
|
||||
3. 시간대 → 달력으로 확인 (직관적)
|
||||
4. 취소/변경 → 클릭 한 번 (간편)
|
||||
5. 결과 → 규칙적 운동 + 30% 절약
|
||||
```
|
||||
|
||||
### 4. 감정 곡선 (Emotional Journey)
|
||||
|
||||
```
|
||||
현재 경험:
|
||||
기대 → 검색 → 좌절 → 포기
|
||||
😊 → 😐 → 😤 → 😔
|
||||
|
||||
서비스 경험:
|
||||
발견 → 시도 → 성공 → 만족 → 추천
|
||||
😐 → 😊 → 😃 → 😍 → 🎉
|
||||
```
|
||||
|
||||
### 5. 고객 인사이트 도출
|
||||
|
||||
**핵심 인사이트**:
|
||||
1. **시간이 돈보다 중요**: 15분 기다리느니 조금 더 내고 앱 사용
|
||||
2. **즉시성 중요**: "지금 당장" 예약 확정 받고 싶음
|
||||
3. **투명성 요구**: 가격, 시간, 위치 한번에 보고 싶음
|
||||
4. **Social Proof**: 다른 사람들도 쓰는지 궁금
|
||||
5. **습관 형성**: 규칙적 운동을 원하지만 예약이 방해물
|
||||
|
||||
---
|
||||
|
||||
## Output Files
|
||||
|
||||
### 생성될 파일들:
|
||||
|
||||
1. **`docs/appkit/customer-persona.md`**
|
||||
- Primary & Secondary 페르소나
|
||||
- Demographics & Psychographics
|
||||
- Pain Points & Goals
|
||||
|
||||
2. **`docs/appkit/customer-journey.md`**
|
||||
- 현재 vs 미래 하루 스토리
|
||||
- 감정 곡선
|
||||
- 터치포인트 분석
|
||||
- 기회 영역 식별
|
||||
|
||||
---
|
||||
|
||||
## Integration Points
|
||||
|
||||
### 다른 명령어와의 연계:
|
||||
|
||||
- **From `/appkit.spec`**: 기능별 사용자 프로파일 수집
|
||||
- **To `/appkit.sales`**: 페르소나별 메시지 구성
|
||||
- **To `/appkit.mvp`**: 핵심 고객의 핵심 문제 우선 해결
|
||||
- **To `/appkit.design`**: 사용자 플로우 설계 기초
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: 테니스 예약 앱
|
||||
```bash
|
||||
$ /appkit.customer
|
||||
|
||||
🎯 Target Customer Analysis
|
||||
|
||||
Primary: 30-40대 직장인
|
||||
- Pain: 전화 예약 번거로움
|
||||
- Want: 빠른 예약, 주말 운동
|
||||
- Value: 시간 절약 > 비용 절약
|
||||
|
||||
Journey Highlights:
|
||||
- Morning: 운동 계획 (의지)
|
||||
- Lunch: 예약 시도 (좌절)
|
||||
- Evening: 포기 (실망)
|
||||
- Weekend: 운동 못함 (죄책감)
|
||||
|
||||
Key Insight:
|
||||
"예약 friction이 운동 의지를 꺾는다"
|
||||
|
||||
✅ Generated customer-persona.md
|
||||
✅ Generated customer-journey.md
|
||||
```
|
||||
|
||||
### Example 2: 추가 페르소나 정의
|
||||
```bash
|
||||
$ /appkit.customer "freelancer flexible schedule"
|
||||
|
||||
🎯 Secondary Persona Added
|
||||
|
||||
프리랜서 (28세):
|
||||
- Pain: 비싼 prime time 가격
|
||||
- Want: 평일 낮 할인
|
||||
- Value: 가격 > 시간대
|
||||
|
||||
Opportunity:
|
||||
"평일 낮 유휴 시간 + 가격 민감 고객 매칭"
|
||||
|
||||
✅ Updated customer-persona.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
### 고객 이해의 원칙:
|
||||
|
||||
1. **공감 먼저, 기능 나중**: 고객의 감정을 이해하라
|
||||
2. **구체적 스토리**: "30대 직장인"이 아닌 "김대리의 하루"
|
||||
3. **Before/After 대비**: 변화를 명확히 보여주기
|
||||
4. **감정 추적**: 각 단계에서 고객이 느끼는 감정
|
||||
5. **인사이트 도출**: 데이터가 아닌 행동 패턴 발견
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
### 효과적인 페르소나 작성:
|
||||
|
||||
1. **이름을 붙여라**: "User A"가 아닌 "김대리"
|
||||
2. **하루를 그려라**: 아침부터 저녁까지 구체적으로
|
||||
3. **감정을 표현하라**: 😊😔😤 이모지 활용
|
||||
4. **대화체 사용**: "아, 또 만석이네..." 실제 혼잣말
|
||||
5. **숫자로 구체화**: "많이"가 아닌 "15분 대기"
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### 이 명령어 실행 후:
|
||||
|
||||
**📍 다음 단계: Step 4 - `/appkit.sales`** (세일즈 랜딩 구성)
|
||||
- 고객 페르소나와 스토리를 기반으로 설득 메시지 작성
|
||||
- 고객의 문제와 해결책을 중심으로 구성
|
||||
|
||||
---
|
||||
|
||||
## Version
|
||||
|
||||
- **Version**: 1.0.0
|
||||
- **Created**: 2025-11-19
|
||||
- **Philosophy**: "기능이 아닌 고객의 삶을 디자인하라"
|
||||
785
.claude/commands/appkit.design.md
Normal file
785
.claude/commands/appkit.design.md
Normal file
@@ -0,0 +1,785 @@
|
||||
# appkit.design
|
||||
|
||||
**개발 준비 - API, ERD, 기술 스펙 설계**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**This is Step 7 of the logical thinking 7-step workflow**:
|
||||
|
||||
```
|
||||
논리적 사고 7단계:
|
||||
1. /appkit.new → 아이디어 스케치 (어떤 서비스인지?)
|
||||
2. /appkit.spec → 기능 구체화 (뭐가 필요할까? 누가 쓸까?)
|
||||
3. /appkit.customer → 고객 스토리 (고객의 하루, 고민, 해결)
|
||||
4. /appkit.sales → 세일즈 랜딩 구성 (어떻게 설득할까?)
|
||||
5. /appkit.mvp → MVP 범위 정하기 (최소한으로 검증하려면?)
|
||||
6. /appkit.merge → 기획 정돈 (흩어진 기획 통합)
|
||||
7. /appkit.design → 개발 준비 (API, ERD, 기술 스펙) ← YOU ARE HERE
|
||||
```
|
||||
|
||||
## Purpose
|
||||
|
||||
merge에서 정돈된 기획을 기반으로, 실제 개발에 필요한 **기술 스펙**을 생성합니다.
|
||||
기획 레벨(merge)과 구현 레벨(개발) 사이의 다리 역할을 합니다.
|
||||
|
||||
**핵심 질문**: "개발자에게 뭘 전달해야 하나? 어떻게 만들까?"
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- `/appkit.merge`로 기획을 정돈한 후 (Step 6 완료 후)
|
||||
- 개발 시작 직전
|
||||
- 기술 스펙이 필요할 때
|
||||
- ERD, API 설계가 필요할 때
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/appkit.design
|
||||
/appkit.design "persona 도메인 집중"
|
||||
/appkit.design "API 우선"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What I'll Do
|
||||
|
||||
### 1. 소스 문서 읽기
|
||||
|
||||
**읽을 파일들**:
|
||||
- `docs/appkit/merge/concept-map.md` (통합 컨셉)
|
||||
- `docs/appkit/merge/consolidated-specs.md` (통합 스펙)
|
||||
- `docs/appkit/merge/journey-feature-map.md` (기능 매핑)
|
||||
- `docs/appkit/mvp-scope.md` (MVP 범위)
|
||||
|
||||
### 2. 데이터 엔티티 설계 (ERD)
|
||||
|
||||
**Output**: `docs/appkit/design/entities.md`
|
||||
|
||||
```markdown
|
||||
# Data Entity Design (ERD)
|
||||
|
||||
*생성 기준: concept-map.md, consolidated-specs.md*
|
||||
*생성일: 2025-11-20*
|
||||
|
||||
---
|
||||
|
||||
## Entity Relationship Diagram
|
||||
|
||||
```mermaid
|
||||
erDiagram
|
||||
Persona ||--o{ Content : generates
|
||||
Content ||--|| Post : becomes
|
||||
Schedule ||--o{ Post : manages
|
||||
|
||||
Persona {
|
||||
int id PK
|
||||
string name
|
||||
int age
|
||||
string personality
|
||||
string tone
|
||||
string language
|
||||
json style_rules
|
||||
datetime created_at
|
||||
}
|
||||
|
||||
Content {
|
||||
int id PK
|
||||
int persona_id FK
|
||||
string topic
|
||||
string image_url
|
||||
text caption
|
||||
json hashtags
|
||||
enum status
|
||||
datetime generated_at
|
||||
}
|
||||
|
||||
Post {
|
||||
int id PK
|
||||
int content_id FK
|
||||
string platform
|
||||
datetime scheduled_at
|
||||
datetime posted_at
|
||||
enum status
|
||||
}
|
||||
|
||||
Schedule {
|
||||
int id PK
|
||||
time execution_time
|
||||
bool is_active
|
||||
json target_personas
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Entity Details
|
||||
|
||||
### Entity: Persona
|
||||
|
||||
**Purpose**: 캐릭터별 페르소나 정보 저장
|
||||
|
||||
**Table Name**: `personas`
|
||||
|
||||
**Fields**:
|
||||
|
||||
| Field | Type | Constraints | Description |
|
||||
|-------|------|-------------|-------------|
|
||||
| id | INT | PK, AUTO_INCREMENT | 페르소나 고유 ID |
|
||||
| name | VARCHAR(100) | NOT NULL | 캐릭터 이름 |
|
||||
| age | INT | NOT NULL | 캐릭터 나이 |
|
||||
| personality | TEXT | NOT NULL | 성격 설명 |
|
||||
| tone | VARCHAR(50) | NOT NULL | 말투 (밝은/전문가/친근한) |
|
||||
| language | VARCHAR(10) | NOT NULL | 언어 (ko/en/ja) |
|
||||
| style_rules | JSON | NULL | 스타일 규칙 (이모티콘, 반말/존댓말) |
|
||||
| created_at | DATETIME | NOT NULL, DEFAULT NOW() | 생성 시간 |
|
||||
|
||||
**Relationships**:
|
||||
- `Persona.id` → `Content.persona_id` (1:N)
|
||||
|
||||
**Business Rules**:
|
||||
- 한 페르소나는 여러 콘텐츠 생성 가능
|
||||
- 페르소나 삭제 시 생성된 콘텐츠는 보존 (FK: RESTRICT)
|
||||
|
||||
**Sample Data**:
|
||||
```json
|
||||
{
|
||||
"id": 1,
|
||||
"name": "밝은 20대 여성",
|
||||
"age": 25,
|
||||
"personality": "긍정적이고 친근한 성격",
|
||||
"tone": "밝은",
|
||||
"language": "ko",
|
||||
"style_rules": {
|
||||
"emoji_frequency": "high",
|
||||
"formality": "casual",
|
||||
"hashtag_style": "trendy"
|
||||
},
|
||||
"created_at": "2025-01-01T10:00:00Z"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Entity: Content
|
||||
|
||||
**Purpose**: AI가 생성한 콘텐츠 저장
|
||||
|
||||
**Table Name**: `contents`
|
||||
|
||||
**Fields**:
|
||||
|
||||
| Field | Type | Constraints | Description |
|
||||
|-------|------|-------------|-------------|
|
||||
| id | INT | PK, AUTO_INCREMENT | 콘텐츠 고유 ID |
|
||||
| persona_id | INT | FK → personas.id, NOT NULL | 생성한 페르소나 |
|
||||
| topic | VARCHAR(200) | NOT NULL | 주제 |
|
||||
| image_url | VARCHAR(500) | NOT NULL | 이미지 URL (Midjourney) |
|
||||
| caption | TEXT | NOT NULL | 캡션 (GPT 생성) |
|
||||
| hashtags | JSON | NULL | 해시태그 배열 |
|
||||
| status | ENUM | NOT NULL | draft, approved, posted |
|
||||
| generated_at | DATETIME | NOT NULL, DEFAULT NOW() | 생성 시간 |
|
||||
|
||||
**Enums**:
|
||||
- `status`: `draft` (생성됨), `approved` (검토 완료), `posted` (포스팅됨)
|
||||
|
||||
**Relationships**:
|
||||
- `Content.persona_id` → `Persona.id` (N:1)
|
||||
- `Content.id` → `Post.content_id` (1:1)
|
||||
|
||||
**Business Rules**:
|
||||
- 하나의 콘텐츠는 하나의 포스트로 변환
|
||||
- 캡션 길이: 최소 50자, 최대 2200자 (Instagram 제한)
|
||||
|
||||
---
|
||||
|
||||
### Entity: Post
|
||||
|
||||
**Purpose**: 실제 포스팅 기록
|
||||
|
||||
**Table Name**: `posts`
|
||||
|
||||
**Fields**:
|
||||
|
||||
| Field | Type | Constraints | Description |
|
||||
|-------|------|-------------|-------------|
|
||||
| id | INT | PK, AUTO_INCREMENT | 포스트 고유 ID |
|
||||
| content_id | INT | FK → contents.id, UK, NOT NULL | 연결된 콘텐츠 |
|
||||
| platform | VARCHAR(50) | NOT NULL | instagram, twitter, etc |
|
||||
| scheduled_at | DATETIME | NOT NULL | 예약 시간 |
|
||||
| posted_at | DATETIME | NULL | 실제 포스팅 시간 |
|
||||
| status | ENUM | NOT NULL | pending, posted, failed |
|
||||
|
||||
**Enums**:
|
||||
- `status`: `pending` (대기), `posted` (완료), `failed` (실패)
|
||||
|
||||
**Relationships**:
|
||||
- `Post.content_id` → `Content.id` (1:1)
|
||||
|
||||
**Business Rules**:
|
||||
- 하나의 콘텐츠는 하나의 포스트
|
||||
- 포스팅 실패 시 재시도 로직 필요
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
- **Total Entities**: 4 (Persona, Content, Post, Schedule)
|
||||
- **Total Relationships**: 3 (1:N, 1:1)
|
||||
- **Foreign Keys**: 3
|
||||
|
||||
**Entity Dependencies** (구현 순서):
|
||||
1. **No dependencies**: Persona, Schedule (먼저 구현)
|
||||
2. **Depends on 1**: Content (needs Persona)
|
||||
3. **Depends on 2**: Post (needs Content)
|
||||
```
|
||||
|
||||
### 3. API 엔드포인트 설계
|
||||
|
||||
**Output**: `docs/appkit/design/apis.md`
|
||||
|
||||
```markdown
|
||||
# API Endpoint Design
|
||||
|
||||
*생성 기준: entities.md, consolidated-specs.md*
|
||||
*API Style: RESTful*
|
||||
*Base URL: `/api/v1`*
|
||||
|
||||
---
|
||||
|
||||
## 1. Persona APIs
|
||||
|
||||
### 1.1 Create Persona
|
||||
|
||||
**Endpoint**: `POST /personas`
|
||||
|
||||
**Description**: 새로운 페르소나 생성
|
||||
|
||||
**Request Body**:
|
||||
```json
|
||||
{
|
||||
"name": "밝은 20대 여성",
|
||||
"age": 25,
|
||||
"personality": "긍정적이고 친근한 성격",
|
||||
"tone": "밝은",
|
||||
"language": "ko",
|
||||
"style_rules": {
|
||||
"emoji_frequency": "high",
|
||||
"formality": "casual"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Success Response** (201 Created):
|
||||
```json
|
||||
{
|
||||
"persona": {
|
||||
"id": 1,
|
||||
"name": "밝은 20대 여성",
|
||||
"age": 25,
|
||||
"tone": "밝은",
|
||||
"created_at": "2025-01-01T10:00:00Z"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Error Responses**:
|
||||
- 400 Bad Request: Validation failed
|
||||
|
||||
**Related Spec**: 001-persona/spec.md
|
||||
**Related Entity**: Persona
|
||||
|
||||
---
|
||||
|
||||
### 1.2 List Personas
|
||||
|
||||
**Endpoint**: `GET /personas`
|
||||
|
||||
**Description**: 모든 페르소나 조회
|
||||
|
||||
**Success Response** (200 OK):
|
||||
```json
|
||||
{
|
||||
"personas": [
|
||||
{
|
||||
"id": 1,
|
||||
"name": "밝은 20대 여성",
|
||||
"age": 25,
|
||||
"tone": "밝은"
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"name": "전문가 30대 남성",
|
||||
"age": 32,
|
||||
"tone": "전문가"
|
||||
}
|
||||
],
|
||||
"total": 2
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Content APIs
|
||||
|
||||
### 2.1 Generate Content
|
||||
|
||||
**Endpoint**: `POST /contents/generate`
|
||||
|
||||
**Description**: AI로 콘텐츠 자동 생성
|
||||
|
||||
**Request Body**:
|
||||
```json
|
||||
{
|
||||
"persona_id": 1,
|
||||
"topic": "오늘의 운동 루틴",
|
||||
"auto_post": false
|
||||
}
|
||||
```
|
||||
|
||||
**Success Response** (201 Created):
|
||||
```json
|
||||
{
|
||||
"content": {
|
||||
"id": 101,
|
||||
"persona_id": 1,
|
||||
"topic": "오늘의 운동 루틴",
|
||||
"image_url": "https://midjourney.com/...",
|
||||
"caption": "오늘도 열심히 운동했어요! 💪...",
|
||||
"hashtags": ["운동", "헬스", "루틴"],
|
||||
"status": "draft",
|
||||
"generated_at": "2025-01-01T07:00:00Z"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Business Logic**:
|
||||
1. persona_id로 페르소나 정보 조회
|
||||
2. Midjourney API 호출 (이미지 생성)
|
||||
3. GPT API 호출 (캡션 생성, 페르소나 톤 반영)
|
||||
4. 생성된 콘텐츠 DB 저장 (status: draft)
|
||||
5. auto_post = true면 자동 포스팅 예약
|
||||
|
||||
**Error Responses**:
|
||||
- 404 Not Found: Persona not found
|
||||
- 502 Bad Gateway: Midjourney/GPT API 실패
|
||||
- 503 Service Unavailable: API rate limit 초과
|
||||
|
||||
**Related Spec**: 002-content/spec.md
|
||||
**Related Entity**: Content, Persona
|
||||
|
||||
---
|
||||
|
||||
### 2.2 List Contents
|
||||
|
||||
**Endpoint**: `GET /contents`
|
||||
|
||||
**Query Parameters**:
|
||||
```
|
||||
?persona_id=1 // Filter by persona
|
||||
&status=draft // Filter by status
|
||||
&date=2025-01-01 // Filter by generation date
|
||||
&limit=20
|
||||
&page=1
|
||||
```
|
||||
|
||||
**Success Response** (200 OK):
|
||||
```json
|
||||
{
|
||||
"contents": [
|
||||
{
|
||||
"id": 101,
|
||||
"persona_id": 1,
|
||||
"topic": "오늘의 운동 루틴",
|
||||
"image_url": "https://...",
|
||||
"status": "draft",
|
||||
"generated_at": "2025-01-01T07:00:00Z"
|
||||
}
|
||||
],
|
||||
"pagination": {
|
||||
"total": 45,
|
||||
"page": 1,
|
||||
"limit": 20
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Schedule APIs
|
||||
|
||||
### 3.1 Create Schedule
|
||||
|
||||
**Endpoint**: `POST /schedules`
|
||||
|
||||
**Description**: 자동 생성 스케줄 등록
|
||||
|
||||
**Request Body**:
|
||||
```json
|
||||
{
|
||||
"execution_time": "07:00",
|
||||
"target_personas": [1, 2, 3],
|
||||
"is_active": true
|
||||
}
|
||||
```
|
||||
|
||||
**Success Response** (201 Created):
|
||||
```json
|
||||
{
|
||||
"schedule": {
|
||||
"id": 1,
|
||||
"execution_time": "07:00",
|
||||
"target_personas": [1, 2, 3],
|
||||
"is_active": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Business Logic**:
|
||||
- Cron job 생성 (매일 07:00 실행)
|
||||
- 실행 시 target_personas의 각 페르소나로 콘텐츠 생성
|
||||
- 생성 후 자동 포스팅
|
||||
|
||||
**Related Spec**: 003-schedule/spec.md
|
||||
**Related Entity**: Schedule
|
||||
|
||||
---
|
||||
|
||||
## 4. Post APIs
|
||||
|
||||
### 4.1 Create Post
|
||||
|
||||
**Endpoint**: `POST /posts`
|
||||
|
||||
**Description**: 콘텐츠를 포스팅으로 예약
|
||||
|
||||
**Request Body**:
|
||||
```json
|
||||
{
|
||||
"content_id": 101,
|
||||
"platform": "instagram",
|
||||
"scheduled_at": "2025-01-01T12:00:00Z"
|
||||
}
|
||||
```
|
||||
|
||||
**Success Response** (201 Created):
|
||||
```json
|
||||
{
|
||||
"post": {
|
||||
"id": 201,
|
||||
"content_id": 101,
|
||||
"platform": "instagram",
|
||||
"scheduled_at": "2025-01-01T12:00:00Z",
|
||||
"status": "pending"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Business Logic**:
|
||||
1. content_id로 콘텐츠 조회
|
||||
2. 포스트 생성 (status: pending)
|
||||
3. scheduled_at 시간에 Instagram API 호출
|
||||
4. 성공 시 status = posted, 실패 시 status = failed
|
||||
|
||||
**Related Spec**: 003-schedule/spec.md (포스팅)
|
||||
**Related Entity**: Post, Content
|
||||
|
||||
---
|
||||
|
||||
## API Summary
|
||||
|
||||
| Domain | Endpoints | Description |
|
||||
|--------|-----------|-------------|
|
||||
| Persona | 3 (create, list, update) | 페르소나 관리 |
|
||||
| Content | 2 (generate, list) | 콘텐츠 생성 |
|
||||
| Schedule | 2 (create, list) | 스케줄 관리 |
|
||||
| Post | 2 (create, list) | 포스팅 관리 |
|
||||
|
||||
**Total Endpoints**: 9
|
||||
|
||||
---
|
||||
|
||||
## Error Response Format
|
||||
|
||||
**Standard Error Response**:
|
||||
```json
|
||||
{
|
||||
"error": {
|
||||
"code": "API_RATE_LIMIT",
|
||||
"message": "Midjourney API rate limit exceeded",
|
||||
"details": {
|
||||
"limit": 50,
|
||||
"current": 51,
|
||||
"reset_at": "2025-01-01T08:00:00Z"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Error Codes**:
|
||||
- `VALIDATION_ERROR`: 입력 검증 실패
|
||||
- `API_RATE_LIMIT`: API 제한 초과
|
||||
- `GENERATION_FAILED`: 콘텐츠 생성 실패
|
||||
- `NOT_FOUND`: 리소스 없음
|
||||
```
|
||||
|
||||
### 4. 기술 정책 정의
|
||||
|
||||
**Output**: `docs/appkit/design/tech-policies.md`
|
||||
|
||||
```markdown
|
||||
# Technical Policies
|
||||
|
||||
*기술 구현 관련 정책*
|
||||
|
||||
---
|
||||
|
||||
## API Rate Limiting
|
||||
|
||||
### Midjourney API
|
||||
- **Limit**: 시간당 50회
|
||||
- **동시 처리**: 최대 3개
|
||||
- **초과 시**: 429 에러, 다음 시간까지 대기
|
||||
- **Queue**: FIFO 방식
|
||||
|
||||
### OpenAI GPT-4 API
|
||||
- **Limit**: 분당 60회
|
||||
- **토큰**: 일 500,000 제한
|
||||
- **초과 시**: 429 에러
|
||||
- **Retry**: Exponential backoff (1s, 2s, 4s)
|
||||
|
||||
### Instagram Graph API
|
||||
- **Limit**: 하루 200개 포스트
|
||||
- **시간당**: 25회
|
||||
- **초과 시**: 403 에러
|
||||
|
||||
**구현 방안**:
|
||||
- Rate Limiter 모듈 구현
|
||||
- 우선순위 큐 시스템
|
||||
- API 호출 로그 기록
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
### 재시도 정책
|
||||
|
||||
**API 실패**:
|
||||
- 재시도 횟수: 3회
|
||||
- 방식: Exponential backoff
|
||||
- 대기 시간: 1s, 2s, 4s
|
||||
|
||||
**생성 실패**:
|
||||
- 재시도 횟수: 2회
|
||||
- 방식: 즉시 재시도
|
||||
- 실패 시: 에러 로그 기록, 알림
|
||||
|
||||
**품질 불량**:
|
||||
- 판단 기준: 이미지 해상도 < 1080x1080
|
||||
- 처리: 자동 재생성 (1회)
|
||||
|
||||
### 로깅
|
||||
|
||||
**로그 종류**:
|
||||
- `error.log`: 모든 에러
|
||||
- `api-calls.log`: API 호출 기록
|
||||
- `generation.log`: 콘텐츠 생성 기록
|
||||
|
||||
**로그 레벨**:
|
||||
- ERROR: 시스템 오류
|
||||
- WARN: API 제한 근접
|
||||
- INFO: 정상 실행
|
||||
|
||||
---
|
||||
|
||||
## Content Safety
|
||||
|
||||
### 브랜드 안전성
|
||||
- 성인 콘텐츠: GPT moderation API로 자동 차단
|
||||
- 폭력/혐오: 필터 적용
|
||||
- 저작권: 학습 데이터 외 참조 금지
|
||||
|
||||
### 품질 검증
|
||||
- 이미지: 최소 1080x1080
|
||||
- 캡션: 최소 50자, 최대 2200자
|
||||
- 해시태그: 5-30개
|
||||
|
||||
---
|
||||
|
||||
## Data Management
|
||||
|
||||
### 저장 위치
|
||||
- 페르소나: Database (personas table)
|
||||
- 콘텐츠: Database (contents table)
|
||||
- 이미지: S3 (Midjourney URL 저장)
|
||||
- 로그: `logs/` directory
|
||||
|
||||
### 백업
|
||||
- DB 백업: 일 1회 (자정)
|
||||
- S3 백업: 자동 (versioning)
|
||||
- 로그 보존: 90일
|
||||
```
|
||||
|
||||
### 5. 화면-API 매핑
|
||||
|
||||
**Output**: `docs/appkit/design/screen-api-map.md`
|
||||
|
||||
```markdown
|
||||
# Screen to API Mapping
|
||||
|
||||
*UI 화면과 API 호출 매핑*
|
||||
|
||||
---
|
||||
|
||||
## Flow: 콘텐츠 자동 생성
|
||||
|
||||
### Screen 1: 페르소나 설정
|
||||
|
||||
**User Actions**:
|
||||
- 페르소나 목록 조회
|
||||
- 새 페르소나 생성
|
||||
|
||||
**API Calls**:
|
||||
```
|
||||
1. GET /personas
|
||||
→ Returns: 페르소나 리스트
|
||||
|
||||
2. (On create) POST /personas
|
||||
→ Returns: 생성된 페르소나
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Screen 2: 스케줄 설정
|
||||
|
||||
**User Actions**:
|
||||
- 스케줄 등록
|
||||
- 실행 시간 설정
|
||||
- 대상 페르소나 선택
|
||||
|
||||
**API Calls**:
|
||||
```
|
||||
1. GET /personas
|
||||
→ Returns: 선택 가능한 페르소나
|
||||
|
||||
2. (On save) POST /schedules
|
||||
→ Returns: 생성된 스케줄
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Screen 3: 콘텐츠 확인
|
||||
|
||||
**User Actions**:
|
||||
- 생성된 콘텐츠 조회
|
||||
- 승인/거부
|
||||
|
||||
**API Calls**:
|
||||
```
|
||||
1. GET /contents?status=draft
|
||||
→ Returns: Draft 콘텐츠 목록
|
||||
|
||||
2. (On approve) PATCH /contents/{id}
|
||||
→ Body: { "status": "approved" }
|
||||
→ Returns: 업데이트된 콘텐츠
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Complete Sequence Diagram
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
actor User
|
||||
participant UI
|
||||
participant API
|
||||
participant Midjourney
|
||||
participant GPT
|
||||
participant Instagram
|
||||
|
||||
User->>UI: 스케줄 등록
|
||||
UI->>API: POST /schedules
|
||||
API-->>UI: Schedule created
|
||||
|
||||
Note over API: 매일 07:00 Cron 실행
|
||||
|
||||
API->>API: GET /personas (target)
|
||||
loop Each Persona
|
||||
API->>Midjourney: Generate Image
|
||||
Midjourney-->>API: Image URL
|
||||
API->>GPT: Generate Caption
|
||||
GPT-->>API: Caption Text
|
||||
API->>API: Save Content (draft)
|
||||
end
|
||||
|
||||
User->>UI: 콘텐츠 확인
|
||||
UI->>API: GET /contents?status=draft
|
||||
API-->>UI: Content List
|
||||
|
||||
User->>UI: 승인
|
||||
UI->>API: PATCH /contents/{id}
|
||||
API->>Instagram: Post Content
|
||||
Instagram-->>API: Success
|
||||
API-->>UI: Posted
|
||||
```
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Files
|
||||
|
||||
### 생성될 파일들:
|
||||
|
||||
```
|
||||
docs/appkit/design/
|
||||
├── entities.md # ERD 및 데이터 모델
|
||||
├── apis.md # API 엔드포인트 설계
|
||||
├── tech-policies.md # 기술 정책
|
||||
└── screen-api-map.md # 화면-API 매핑
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Integration Points
|
||||
|
||||
### 다른 명령어와의 연계:
|
||||
|
||||
- **From `/appkit.merge`**: concept-map.md 사용
|
||||
- **To 개발팀**: 설계 문서 전달
|
||||
- **To `/appkit.verify`**: 설계 완성도 체크 (향후)
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
### 설계 원칙:
|
||||
|
||||
1. **Planning only, no code**: 설계 문서만 생성, 코드 작성 안 함
|
||||
2. **Entity-first approach**: 데이터 모델부터 설계
|
||||
3. **API follows entity**: API는 엔티티 관계에서 도출
|
||||
4. **Traceability**: 모든 설계는 spec과 연결
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### 이 명령어 실행 후:
|
||||
|
||||
**📍 7단계 완료!**
|
||||
- 기획부터 설계까지 모든 문서 완성
|
||||
- 개발팀에게 전달 가능
|
||||
- MVP Phase 0 개발 시작
|
||||
|
||||
---
|
||||
|
||||
## Version
|
||||
|
||||
- **Version**: 1.0.0
|
||||
- **Created**: 2025-11-20
|
||||
- **Philosophy**: "설계는 기획과 구현 사이의 다리"
|
||||
506
.claude/commands/appkit.merge.md
Normal file
506
.claude/commands/appkit.merge.md
Normal file
@@ -0,0 +1,506 @@
|
||||
# appkit.merge
|
||||
|
||||
**기획 정돈 - 흩어진 기획 문서를 일관되게 통합**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**This is Step 6 of the logical thinking 7-step workflow**:
|
||||
|
||||
```
|
||||
논리적 사고 7단계:
|
||||
1. /appkit.new → 아이디어 스케치 (어떤 서비스인지?)
|
||||
2. /appkit.spec → 기능 구체화 (뭐가 필요할까? 누가 쓸까?)
|
||||
3. /appkit.customer → 고객 스토리 (고객의 하루, 고민, 해결)
|
||||
4. /appkit.sales → 세일즈 랜딩 구성 (어떻게 설득할까?)
|
||||
5. /appkit.mvp → MVP 범위 정하기 (최소한으로 검증하려면?)
|
||||
6. /appkit.merge → 기획 정돈 (흩어진 기획 통합) ← YOU ARE HERE
|
||||
7. /appkit.design → 개발 준비 (API, ERD, 기술 스펙)
|
||||
```
|
||||
|
||||
## Purpose
|
||||
|
||||
MVP 범위가 정해지면, 이제 지금까지 만든 기획 문서들을 정리할 차례입니다.
|
||||
spec, customer, mvp를 각각 만들다 보면 AI가 맥락을 놓치고 일관성 없이 생성합니다.
|
||||
**기획 레벨**에서 흩어진 내용을 통합하고, 중복과 충돌을 해소합니다.
|
||||
|
||||
**핵심 질문**: "기획이 일관적인가? 중복은? 용어가 통일됐나?"
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- `/appkit.mvp`로 MVP 범위를 정한 후 (Step 5 완료 후)
|
||||
- spec, customer, mvp 결과물이 준비되었을 때
|
||||
- 기획 문서 간 중복이나 충돌이 보일 때
|
||||
- 용어와 컨셉을 통일해야 할 때
|
||||
- 개발 준비(design) 전 기획을 정돈하고 싶을 때
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/appkit.merge
|
||||
/appkit.merge "특히 spec과 customer 용어 통일"
|
||||
/appkit.merge "MVP 범위 기반으로 우선순위 재조정"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What I'll Do
|
||||
|
||||
### 1. 소스 문서 수집
|
||||
|
||||
**읽을 파일들**:
|
||||
- `docs/appkit/specs/*/spec.md` (모든 기능 스펙)
|
||||
- `docs/appkit/customer-persona.md` (타겟 고객)
|
||||
- `docs/appkit/customer-journey.md` (고객 여정)
|
||||
- `docs/appkit/mvp-scope.md` (MVP 범위)
|
||||
- `docs/appkit/mvp-metrics.md` (검증 지표)
|
||||
|
||||
### 2. 기획 일관성 분석
|
||||
|
||||
**분석 항목**:
|
||||
|
||||
#### A. 용어 통일성
|
||||
```markdown
|
||||
## 용어 충돌 발견
|
||||
|
||||
❌ **Spec에서**: "페르소나 설정"
|
||||
❌ **Customer에서**: "캐릭터 프로필"
|
||||
❌ **MVP에서**: "인물 정보"
|
||||
|
||||
✅ **통일 제안**:
|
||||
→ 표준 용어: "페르소나"
|
||||
→ 모든 문서에 일관되게 적용
|
||||
```
|
||||
|
||||
#### B. 기능 중복 확인
|
||||
```markdown
|
||||
## 중복 기능 발견
|
||||
|
||||
❌ **001-persona/spec.md**:
|
||||
- 이미지 생성 기능 언급
|
||||
|
||||
❌ **002-content/spec.md**:
|
||||
- 이미지 생성 기능 중복 설명
|
||||
|
||||
✅ **통합 제안**:
|
||||
→ 002-content에서 통합 관리
|
||||
→ 001-persona는 002-content 참조
|
||||
```
|
||||
|
||||
#### C. 고객 가치 일관성
|
||||
```markdown
|
||||
## 가치 제안 충돌
|
||||
|
||||
❌ **Spec**: "100명 자동 관리"
|
||||
❌ **Customer**: "15시간 → 1시간 시간 절약"
|
||||
❌ **Sales**: "월 1억 수익"
|
||||
|
||||
✅ **핵심 가치 통일**:
|
||||
→ Primary Value: "시간 절약 (15시간 → 1시간)"
|
||||
→ Secondary Value: "확장성 (100명 관리)"
|
||||
→ Ultimate Goal: "월 1억 수익 달성"
|
||||
```
|
||||
|
||||
### 3. MVP 범위 기반 우선순위 조정
|
||||
```markdown
|
||||
## MVP 범위 재확인
|
||||
|
||||
**Phase 0 (MVP - 2주)**:
|
||||
✅ 페르소나 관리 (001-persona)
|
||||
✅ 콘텐츠 자동 생성 (002-content)
|
||||
✅ 스케줄링 (003-schedule)
|
||||
❌ 성과 분석 (004-analytics) → Phase 1로 이동
|
||||
❌ 수익화 관리 (005-monetize) → Phase 2로 이동
|
||||
|
||||
**우선순위 조정**:
|
||||
1. **Must Have** (없으면 MVP 불가):
|
||||
- 001-persona, 002-content, 003-schedule
|
||||
|
||||
2. **Should Have** (있으면 좋음):
|
||||
- 004-analytics (Phase 1)
|
||||
|
||||
3. **Nice to Have** (나중에):
|
||||
- 005-monetize (Phase 2)
|
||||
|
||||
→ Spec 문서에서 Phase 0 외 기능은 "Future" 섹션으로 이동
|
||||
```
|
||||
|
||||
### 4. 컨셉 맵 생성
|
||||
|
||||
**Output**: `docs/appkit/merge/concept-map.md`
|
||||
|
||||
```markdown
|
||||
# Concept Map (통합 컨셉 맵)
|
||||
|
||||
*생성 기준: spec, customer, mvp 통합*
|
||||
*생성일: 2025-11-20*
|
||||
|
||||
---
|
||||
|
||||
## 핵심 컨셉 정의
|
||||
|
||||
### 서비스 컨셉
|
||||
"AI 인플루언서 100명을 자동으로 운영하는 시스템"
|
||||
|
||||
### 핵심 가치 (통일)
|
||||
1. **Primary**: 시간 절약 (15시간 → 1시간)
|
||||
2. **Secondary**: 확장성 (100명 자동 관리)
|
||||
3. **Ultimate Goal**: 월 1억 수익
|
||||
|
||||
### 타겟 사용자
|
||||
- **Primary**: 본인 (AI 인플루언서 운영자)
|
||||
- **Pain Point**: 수동 작업 불가능
|
||||
- **Goal**: 완전 자동화
|
||||
|
||||
---
|
||||
|
||||
## 기능 통합 맵
|
||||
|
||||
### Phase 0 (MVP - 2주)
|
||||
|
||||
**001-persona** (페르소나 관리)
|
||||
- 정의: 캐릭터별 성격, 톤앤매너 설정
|
||||
- 입력: 캐릭터 정보 (이름, 나이, 성격)
|
||||
- 출력: 페르소나 DB 저장
|
||||
- 의존성: 없음
|
||||
|
||||
**002-content** (콘텐츠 자동 생성)
|
||||
- 정의: 페르소나 기반 이미지 + 캡션 자동 생성
|
||||
- 입력: 페르소나 ID, 주제
|
||||
- 출력: 이미지 (Midjourney), 캡션 (GPT)
|
||||
- 의존성: 001-persona (필수)
|
||||
|
||||
**003-schedule** (스케줄링)
|
||||
- 정의: 매일 아침 7시 자동 생성 실행
|
||||
- 입력: 스케줄 설정
|
||||
- 출력: Cron job 실행
|
||||
- 의존성: 002-content (필수)
|
||||
|
||||
---
|
||||
|
||||
## 용어 사전 (통일된 표현)
|
||||
|
||||
| 개념 | 표준 용어 | 금지 용어 |
|
||||
|------|-----------|-----------|
|
||||
| 캐릭터 정보 | 페르소나 | 캐릭터 프로필, 인물 정보 |
|
||||
| 자동 생성 | 콘텐츠 생성 | 포스트 제작, 글쓰기 |
|
||||
| 예약 실행 | 스케줄링 | 타이머, 자동 실행 |
|
||||
| 성과 추적 | 분석 | 통계, 모니터링 |
|
||||
|
||||
---
|
||||
|
||||
## 데이터 흐름
|
||||
|
||||
```
|
||||
[페르소나 DB] → [콘텐츠 생성] → [Instagram API]
|
||||
↑ ↑ ↑
|
||||
001-persona 002-content 003-schedule
|
||||
```
|
||||
|
||||
**데이터 엔티티** (기획 레벨):
|
||||
1. Persona (페르소나 정보)
|
||||
2. Content (생성된 콘텐츠)
|
||||
3. Schedule (스케줄 설정)
|
||||
4. Post (포스팅 기록)
|
||||
|
||||
*상세 데이터 모델은 /appkit.design에서 생성*
|
||||
```
|
||||
|
||||
### 5. 고객 여정과 기능 매핑
|
||||
|
||||
**Output**: `docs/appkit/merge/journey-feature-map.md`
|
||||
|
||||
```markdown
|
||||
# 고객 여정 - 기능 매핑
|
||||
|
||||
*Customer Journey → Feature Mapping*
|
||||
|
||||
---
|
||||
|
||||
## 현재 상황 (Before)
|
||||
|
||||
**새벽 6시**: "100개 콘텐츠 어떻게 만들지..." (막막)
|
||||
→ **해결 기능**: 없음 (수동 작업)
|
||||
|
||||
**오전 9시**: 20개째 이미지 생성 중 (지침)
|
||||
→ **해결 기능**: 002-content (자동 생성)
|
||||
|
||||
**오후 3시**: 50개째 캡션 작성 중 (번아웃)
|
||||
→ **해결 기능**: 002-content (자동 생성)
|
||||
|
||||
**저녁 9시**: 결국 20개 못 올림 (좌절)
|
||||
→ **해결 기능**: 003-schedule (자동 포스팅)
|
||||
|
||||
---
|
||||
|
||||
## 미래 상황 (After - MVP 적용)
|
||||
|
||||
**전날 밤 11시**: 내일 주제만 설정 (5분)
|
||||
→ **사용 기능**: 001-persona (주제 입력)
|
||||
|
||||
**아침 7시**: 시스템이 100개 자동 생성 (무인)
|
||||
→ **사용 기능**: 003-schedule → 002-content
|
||||
|
||||
**아침 8시**: 커피 마시며 퀄리티 체크 (30분)
|
||||
→ **사용 기능**: 004-analytics (Phase 1)
|
||||
|
||||
---
|
||||
|
||||
## 기능별 고객 가치
|
||||
|
||||
**001-persona**:
|
||||
- Pain 해소: "매번 캐릭터 설정 반복" → "한번 설정, 계속 사용"
|
||||
- 시간 절약: 10분/캐릭터 → 1분 (첫 설정)
|
||||
|
||||
**002-content**:
|
||||
- Pain 해소: "100개 수동 생성 불가능" → "100개 자동 생성"
|
||||
- 시간 절약: 10시간 → 0시간
|
||||
|
||||
**003-schedule**:
|
||||
- Pain 해소: "아침마다 실행 필요" → "자동 실행"
|
||||
- 시간 절약: 5분/일 → 0분
|
||||
```
|
||||
|
||||
### 6. 통합 후 구조 재정의
|
||||
|
||||
**Before (분산)**:
|
||||
```
|
||||
docs/appkit/
|
||||
├── specs/
|
||||
│ ├── 001-persona/spec.md (용어 불일치)
|
||||
│ ├── 002-content/spec.md (중복 설명)
|
||||
│ └── 003-schedule/spec.md
|
||||
├── customer-persona.md (용어 다름)
|
||||
├── customer-journey.md
|
||||
├── mvp-scope.md (우선순위 모호)
|
||||
└── mvp-metrics.md
|
||||
```
|
||||
|
||||
**After (통합)**:
|
||||
```
|
||||
docs/appkit/merge/
|
||||
├── concept-map.md # 핵심: 통합 컨셉 맵
|
||||
├── journey-feature-map.md # 고객 여정 - 기능 매핑
|
||||
├── terminology.md # 표준 용어 사전
|
||||
├── consolidated-specs.md # 통합된 기능 명세
|
||||
└── mvp-priority.md # 재조정된 우선순위
|
||||
```
|
||||
|
||||
**구조 설명**:
|
||||
- `concept-map.md`: 모든 문서의 컨셉을 하나로 통합
|
||||
- `journey-feature-map.md`: 고객 여정과 기능 매핑
|
||||
- `terminology.md`: 통일된 용어 사전
|
||||
- `consolidated-specs.md`: 중복 제거된 기능 명세
|
||||
- `mvp-priority.md`: MVP 기반 우선순위
|
||||
|
||||
### 7. 충돌 해결
|
||||
|
||||
**충돌 패턴 식별**:
|
||||
|
||||
```markdown
|
||||
## Conflicts Detected
|
||||
|
||||
⚠️ **Conflict #1**: 이미지 생성 해상도
|
||||
- 001-persona: 512x512
|
||||
- 002-content: 1080x1080
|
||||
→ **해결**: content-safety.md에 용도별 최소 해상도 정의
|
||||
|
||||
⚠️ **Conflict #2**: API 호출 우선순위
|
||||
- 001: persona 우선
|
||||
- 002: content 우선
|
||||
→ **해결**: rate-limiter.md에 우선순위 큐 정의
|
||||
|
||||
⚠️ **Conflict #3**: 에러 시 재시도 횟수
|
||||
- 001: 5회
|
||||
- 002: 3회
|
||||
→ **해결**: error-handling.md에 통일 (3회)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Files
|
||||
|
||||
### 생성될 파일 구조:
|
||||
|
||||
```
|
||||
docs/appkit/merge/
|
||||
├── specs/ (통합된 개별 기능)
|
||||
│ ├── 001-persona/
|
||||
│ ├── 002-content/
|
||||
│ ├── 003-schedule/
|
||||
│ └── 004-posting/
|
||||
├── common/ (공통 모듈 & 정책)
|
||||
│ ├── 001-image-generation/
|
||||
│ ├── 002-rate-limiter/
|
||||
│ ├── 003-error-handler/
|
||||
│ ├── 004-content-safety/
|
||||
│ ├── 005-api-limits/
|
||||
│ └── 006-data-management/
|
||||
├── overview.md (전체 통합 요약)
|
||||
└── dependencies.md (의존성 그래프)
|
||||
```
|
||||
|
||||
### 파일별 상세:
|
||||
|
||||
1. **`merge/specs/00X-*/spec.md`**
|
||||
- 원본 specs에서 중복 제거
|
||||
- common 모듈 참조 추가
|
||||
- 의존성 명시
|
||||
|
||||
2. **`merge/common/001-image-generation/module.md`**
|
||||
- Midjourney API 통합 로직
|
||||
- 이미지 생성 공통 인터페이스
|
||||
- 사용 예시
|
||||
|
||||
3. **`merge/common/002-rate-limiter/module.md`**
|
||||
- API별 제한 정책
|
||||
- 우선순위 큐 시스템
|
||||
- 재시도 로직
|
||||
|
||||
4. **`merge/common/003-error-handler/module.md`**
|
||||
- 통일된 에러 처리
|
||||
- 로깅 정책
|
||||
- 알림 규칙
|
||||
|
||||
5. **`merge/common/004-content-safety/policy.md`**
|
||||
- 브랜드 안전성 필터
|
||||
- 콘텐츠 검증 규칙
|
||||
- 언어/문화 가이드
|
||||
|
||||
6. **`merge/common/005-api-limits/policy.md`**
|
||||
- Midjourney: 시간당 50회
|
||||
- OpenAI: 분당 60회
|
||||
- Instagram: 일 200개
|
||||
|
||||
7. **`merge/common/006-data-management/policy.md`**
|
||||
- 저장 위치 및 구조
|
||||
- 보존 기간
|
||||
- 백업 정책
|
||||
|
||||
8. **`merge/overview.md`**
|
||||
- 중복 제거 요약
|
||||
- 통합된 기능 목록
|
||||
- common 모듈 목록
|
||||
|
||||
9. **`merge/dependencies.md`**
|
||||
- 기능 간 의존성 그래프
|
||||
- 실행 순서
|
||||
- 순환 의존성 체크
|
||||
|
||||
---
|
||||
|
||||
## Integration Points
|
||||
|
||||
### 다른 명령어와의 연계:
|
||||
|
||||
- **From `/appkit.mvp`**: MVP Phase 0에 포함될 기능들
|
||||
- **From `/appkit.spec`**: 각 기능별 스펙 파일
|
||||
- **To 개발팀**: 정리된 스펙과 공통 모듈로 구현 시작
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: 기본 통합
|
||||
|
||||
```bash
|
||||
$ /appkit.merge
|
||||
|
||||
🔄 Spec Consolidation Analysis
|
||||
|
||||
**중복 기능 발견**: 2개
|
||||
✅ image-generation 모듈로 통합
|
||||
|
||||
**공통 정책 추출**: 6개
|
||||
✅ 001-image-generation (모듈)
|
||||
✅ 002-rate-limiter (모듈)
|
||||
✅ 003-error-handler (모듈)
|
||||
✅ 004-content-safety (정책)
|
||||
✅ 005-api-limits (정책)
|
||||
✅ 006-data-management (정책)
|
||||
|
||||
**의존성 정리**: ✅ 순환 없음
|
||||
|
||||
**충돌 해결**: 3개
|
||||
✅ 이미지 해상도 통일
|
||||
✅ API 우선순위 정의
|
||||
✅ 재시도 횟수 통일
|
||||
|
||||
✅ Created docs/appkit/merge/
|
||||
✅ Generated merge/specs/ (4개)
|
||||
✅ Generated merge/common/ (6개)
|
||||
✅ Generated merge/overview.md
|
||||
✅ Generated merge/dependencies.md
|
||||
```
|
||||
|
||||
### Example 2: 특정 영역 집중
|
||||
|
||||
```bash
|
||||
$ /appkit.merge "API 통합 중점"
|
||||
|
||||
🔄 API Integration Focus
|
||||
|
||||
**API 통합 분석**:
|
||||
- Midjourney: 2곳에서 호출 → 통합
|
||||
- OpenAI: 3곳에서 호출 → 통합
|
||||
- Instagram: 1곳 (통합 불필요)
|
||||
|
||||
**Rate Limiting 정책**:
|
||||
✅ common/005-api-limits/policy.md 생성
|
||||
- Midjourney: 시간당 50회
|
||||
- OpenAI: 분당 60회
|
||||
- 우선순위 큐 필요
|
||||
|
||||
✅ Generated merge/common/001-image-generation/
|
||||
✅ Generated merge/common/002-rate-limiter/
|
||||
✅ Updated merge/specs/ (중복 제거)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
### Merge 원칙:
|
||||
|
||||
1. **DRY (Don't Repeat Yourself)**: 중복 코드/정책 제거
|
||||
2. **Single Source of Truth**: 하나의 정의, 여러 참조
|
||||
3. **Explicit Dependencies**: 암묵적 의존성 명시화
|
||||
4. **Policy Centralization**: 정책은 한 곳에서 관리
|
||||
5. **Conflict Resolution**: 충돌은 즉시 해결
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
### 효과적인 통합을 위해:
|
||||
|
||||
1. **작은 단위로 시작**: 2-3개 기능부터 통합
|
||||
2. **정책 우선**: 공통 규칙부터 정리
|
||||
3. **의존성 체크**: 순환 의존성 방지
|
||||
4. **문서화**: 통합 이유와 결정사항 기록
|
||||
5. **점진적 리팩토링**: 한번에 다 바꾸지 말기
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### 이 명령어 실행 후:
|
||||
|
||||
**📍 다음 단계: Step 7 - `/appkit.design`** (개발 준비)
|
||||
- 기획이 정돈되었으니 이제 개발 준비 단계로
|
||||
- ERD, API 엔드포인트 설계
|
||||
- 기술 정책 정의
|
||||
- 개발팀에게 전달할 최종 기술 스펙 완성
|
||||
|
||||
---
|
||||
|
||||
## Version
|
||||
|
||||
- **Version**: 1.0.0
|
||||
- **Created**: 2025-01-20
|
||||
- **Philosophy**: "AI는 맥락을 놓친다. 사람이 통합하라."
|
||||
404
.claude/commands/appkit.mvp.md
Normal file
404
.claude/commands/appkit.mvp.md
Normal file
@@ -0,0 +1,404 @@
|
||||
# appkit.mvp
|
||||
|
||||
**최소한의 기능으로 최대한의 검증을 하는 MVP 범위 정의 명령어**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**This is Step 5 of the logical thinking 7-step workflow**:
|
||||
|
||||
```
|
||||
논리적 사고 7단계:
|
||||
1. /appkit.new → 아이디어 스케치 (어떤 서비스인지?)
|
||||
2. /appkit.spec → 기능 구체화 (뭐가 필요할까? 누가 쓸까?)
|
||||
3. /appkit.customer → 고객 스토리 (고객의 하루, 고민, 해결)
|
||||
4. /appkit.sales → 세일즈 랜딩 구성 (어떻게 설득할까?)
|
||||
5. /appkit.mvp → MVP 범위 정하기 (최소한으로 검증하려면?) ← YOU ARE HERE
|
||||
6. /appkit.merge → 기획 정돈 (흩어진 기획 통합)
|
||||
7. /appkit.design → 개발 준비 (API, ERD, 기술 스펙)
|
||||
```
|
||||
|
||||
## Purpose
|
||||
|
||||
핵심 가치만 구현하여 빠르게 시장 검증을 하기 위한 MVP 범위를 정의합니다.
|
||||
"있으면 좋은" 기능을 제외하고 "없으면 안되는" 기능만 선별합니다.
|
||||
|
||||
**핵심 질문**: "최소한으로 검증하려면 뭐가 필요할까?"
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- `/appkit.sales`로 가치 제안을 정의한 후 (Step 4 완료 후)
|
||||
- 개발 시작 전 범위를 정해야 할 때
|
||||
- 리소스가 제한적일 때
|
||||
- 빠른 시장 검증이 필요할 때
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/appkit.mvp
|
||||
/appkit.mvp "2-week validation"
|
||||
/appkit.mvp "budget: 500만원"
|
||||
/appkit.mvp "target: early adopters only"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What I'll Do
|
||||
|
||||
### 1. MVP 정의 프레임워크
|
||||
|
||||
```markdown
|
||||
## MVP Definition Framework
|
||||
|
||||
### The ONE Thing Test
|
||||
"만약 딱 하나의 기능만 만들 수 있다면?"
|
||||
→ 그것이 진짜 핵심 가치
|
||||
|
||||
### Concierge MVP vs Product MVP
|
||||
- Concierge: 수동으로 서비스 제공 (검증용)
|
||||
- Product: 자동화된 제품 (확장용)
|
||||
|
||||
### MLP (Minimum Lovable Product)
|
||||
- Minimum: 최소 기능
|
||||
- Viable: 사용 가능
|
||||
- Lovable: 사랑받을 만한
|
||||
→ MVP도 완성도는 있어야 함
|
||||
```
|
||||
|
||||
### 2. Phase별 기능 분류
|
||||
|
||||
```markdown
|
||||
## MVP Phases
|
||||
|
||||
### Phase 0: Core MVP (2주)
|
||||
"없으면 서비스가 성립 안 되는 기능"
|
||||
|
||||
#### Must Have (핵심)
|
||||
✅ 코트 검색/조회
|
||||
✅ 실시간 예약
|
||||
✅ 간단 결제
|
||||
✅ 예약 확인
|
||||
|
||||
#### 구현 수준
|
||||
- UI: 기본 모바일 웹 (앱 개발 X)
|
||||
- 백엔드: 최소 API (5-7개)
|
||||
- 결제: 간편결제 1종 (카드)
|
||||
- 인증: 소셜 로그인 1종 (카카오)
|
||||
|
||||
#### 제외할 것
|
||||
❌ 회원 등급 시스템
|
||||
❌ 리뷰/평점
|
||||
❌ 쿠폰/포인트
|
||||
❌ 푸시 알림
|
||||
❌ 커뮤니티
|
||||
|
||||
#### 검증 목표
|
||||
- 주간 예약 10건 달성
|
||||
- 사용자 10명 확보
|
||||
- 핵심 플로우 검증
|
||||
|
||||
|
||||
### Phase 1: Enhanced MVP (1개월)
|
||||
"사용자 만족도를 높이는 기능"
|
||||
|
||||
#### Should Have (개선)
|
||||
✅ 할인/쿠폰 시스템
|
||||
✅ 사용자 리뷰
|
||||
✅ 예약 변경/취소
|
||||
✅ 다중 결제 수단
|
||||
|
||||
#### 검증 목표
|
||||
- 재방문율 30%
|
||||
- 주간 예약 50건
|
||||
- NPS 40 이상
|
||||
|
||||
|
||||
### Phase 2: Growth (3개월)
|
||||
"성장과 확장을 위한 기능"
|
||||
|
||||
#### Nice to Have (확장)
|
||||
✅ 커뮤니티 기능
|
||||
✅ 코칭 매칭
|
||||
✅ 토너먼트 개최
|
||||
✅ 장비 대여
|
||||
|
||||
#### 검증 목표
|
||||
- MAU 1,000명
|
||||
- 월 매출 1,000만원
|
||||
- 바이럴 계수 1.2
|
||||
```
|
||||
|
||||
### 3. MVP 검증 지표 설정
|
||||
|
||||
```markdown
|
||||
## MVP Metrics
|
||||
|
||||
### 1️⃣ Success Metrics (성공 지표)
|
||||
"목표 달성 여부"
|
||||
|
||||
#### Quantitative (정량)
|
||||
- 주간 활성 사용자 (WAU): 10명
|
||||
- 주간 예약 건수: 10건
|
||||
- 전환율: 방문자의 10% 예약
|
||||
- 결제 성공률: 90%
|
||||
|
||||
#### Qualitative (정성)
|
||||
- "편리하다" 피드백 70%
|
||||
- "다시 쓸 것" 응답 80%
|
||||
- 추천 의향 (NPS): 30+
|
||||
|
||||
|
||||
### 2️⃣ Learning Metrics (학습 지표)
|
||||
"무엇을 배울 것인가"
|
||||
|
||||
#### User Behavior
|
||||
- 이탈 구간: 어디서 포기하나?
|
||||
- 사용 시간대: 언제 가장 활발한가?
|
||||
- 검색 패턴: 뭘 찾고 있나?
|
||||
- 실패 케이스: 왜 예약 안 하나?
|
||||
|
||||
#### Product-Market Fit Signals
|
||||
- Organic Growth: 자연 유입 있나?
|
||||
- Retention: 다시 오나?
|
||||
- Referral: 추천하나?
|
||||
- Payment: 돈을 내나?
|
||||
|
||||
|
||||
### 3️⃣ Pivot Indicators (피벗 신호)
|
||||
"방향 전환이 필요한 시점"
|
||||
|
||||
🚨 Danger Signals
|
||||
- 2주 후 WAU < 5명
|
||||
- 전환율 < 3%
|
||||
- NPS < 0
|
||||
- 일일 사용 시간 < 1분
|
||||
|
||||
→ Action: 가치 제안 재검토
|
||||
```
|
||||
|
||||
### 4. MVP 개발 우선순위 매트릭스
|
||||
|
||||
```markdown
|
||||
## Priority Matrix
|
||||
|
||||
High Impact ↑
|
||||
|
||||
[P0: 코트 예약] | [P1: 할인 시스템]
|
||||
Must Do Now | Do Next
|
||||
__________________|__________________
|
||||
|
|
||||
[P3: 푸시 알림] | [P2: 리뷰 시스템]
|
||||
Don't Do | Do Later
|
||||
|
|
||||
→ High Effort
|
||||
|
||||
### Priority Scoring
|
||||
Impact (영향도) x Confidence (확신도) / Effort (노력)
|
||||
|
||||
예시:
|
||||
- 코트 예약: 10 x 10 / 3 = 33.3 (P0)
|
||||
- 커뮤니티: 5 x 3 / 8 = 1.9 (P3)
|
||||
```
|
||||
|
||||
### 5. MVP 실행 로드맵
|
||||
|
||||
```markdown
|
||||
## Execution Roadmap
|
||||
|
||||
### Week 1-2: Build Phase 0
|
||||
Day 1-3: 기본 UI/UX
|
||||
- 검색 화면
|
||||
- 예약 화면
|
||||
- 확인 화면
|
||||
|
||||
Day 4-7: 핵심 백엔드
|
||||
- 예약 API
|
||||
- 결제 연동
|
||||
- 알림 발송
|
||||
|
||||
Day 8-10: 통합 테스트
|
||||
- End-to-end 테스트
|
||||
- 결제 테스트
|
||||
- 부하 테스트
|
||||
|
||||
Day 11-14: Soft Launch
|
||||
- 베타 사용자 10명
|
||||
- 피드백 수집
|
||||
- 긴급 수정
|
||||
|
||||
|
||||
### Week 3-4: Validate & Iterate
|
||||
- 지표 측정
|
||||
- 사용자 인터뷰
|
||||
- 개선사항 반영
|
||||
- Phase 1 결정
|
||||
|
||||
|
||||
### Week 5-8: Build Phase 1
|
||||
(If Phase 0 validated)
|
||||
- 할인 시스템
|
||||
- 리뷰 기능
|
||||
- UX 개선
|
||||
```
|
||||
|
||||
### 6. MVP 체크리스트
|
||||
|
||||
```markdown
|
||||
## MVP Checklist
|
||||
|
||||
### Before Launch
|
||||
□ 핵심 가치 명확한가?
|
||||
□ 타겟 사용자 명확한가?
|
||||
□ 성공 지표 정의했나?
|
||||
□ 실패 기준 정의했나?
|
||||
□ 2주 안에 가능한가?
|
||||
|
||||
### During Development
|
||||
□ Scope creep 발생하지 않았나?
|
||||
□ "하나 더" 유혹 거부했나?
|
||||
□ 핵심 플로우만 집중했나?
|
||||
|
||||
### After Launch
|
||||
□ 정량 지표 달성했나?
|
||||
□ 정성 피드백 긍정적인가?
|
||||
□ 다음 단계 명확한가?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Files
|
||||
|
||||
### 생성될 파일들:
|
||||
|
||||
1. **`docs/appkit/mvp-scope.md`**
|
||||
- Phase별 기능 목록
|
||||
- 포함/제외 기능
|
||||
- 우선순위 매트릭스
|
||||
|
||||
2. **`docs/appkit/mvp-metrics.md`**
|
||||
- 성공 지표
|
||||
- 학습 지표
|
||||
- 피벗 기준
|
||||
|
||||
---
|
||||
|
||||
## Integration Points
|
||||
|
||||
### 다른 명령어와의 연계:
|
||||
|
||||
- **From `/appkit.customer`**: Primary 페르소나의 핵심 문제
|
||||
- **From `/appkit.sales`**: 검증할 핵심 가치
|
||||
- **To `/appkit.merge`**: MVP Phase 0 기능의 구현 준비
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: 2주 검증 MVP
|
||||
```bash
|
||||
$ /appkit.mvp "2-week validation"
|
||||
|
||||
🎯 MVP Scope Defined
|
||||
|
||||
Phase 0 (2 weeks):
|
||||
✅ Search (location-based)
|
||||
✅ Booking (real-time)
|
||||
✅ Payment (simple)
|
||||
✅ Confirmation (email)
|
||||
|
||||
Excluded:
|
||||
❌ Reviews (Phase 1)
|
||||
❌ Discounts (Phase 1)
|
||||
❌ Community (Phase 2)
|
||||
|
||||
Success Criteria:
|
||||
- 10 bookings/week
|
||||
- 10 active users
|
||||
- NPS > 30
|
||||
|
||||
✅ Generated mvp-scope.md
|
||||
✅ Generated mvp-metrics.md
|
||||
```
|
||||
|
||||
### Example 2: 예산 제약 MVP
|
||||
```bash
|
||||
$ /appkit.mvp "budget: 500만원"
|
||||
|
||||
💰 Budget-Constrained MVP
|
||||
|
||||
Concierge MVP Approach:
|
||||
- Manual booking process
|
||||
- WhatsApp/Kakao for communication
|
||||
- Google Forms for payment
|
||||
- Spreadsheet for management
|
||||
|
||||
Tech Investment: Phase 1
|
||||
- After validation
|
||||
- 500만원 = 2 developer weeks
|
||||
|
||||
✅ Updated mvp-scope.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
### MVP 원칙:
|
||||
|
||||
1. **Maximize Learning**: 최소 투자로 최대 학습
|
||||
2. **Ship Fast**: 완벽보다 속도
|
||||
3. **Core Value Only**: 핵심 가치만 구현
|
||||
4. **Real Users**: 실제 사용자로 검증
|
||||
5. **Metrics-Driven**: 감이 아닌 데이터로 결정
|
||||
|
||||
### MVP Anti-Patterns:
|
||||
|
||||
❌ **Feature Creep**: "이것도 있으면 좋겠는데..."
|
||||
❌ **Perfectionism**: "조금만 더 다듬고..."
|
||||
❌ **Assumption**: "사용자는 당연히..."
|
||||
❌ **Vanity Metrics**: 의미 없는 지표 추적
|
||||
❌ **Premature Scaling**: 검증 전 확장
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
### 성공적인 MVP를 위해:
|
||||
|
||||
1. **Time Box**: 2주를 넘기지 마라
|
||||
2. **User Cap**: 10-100명으로 시작
|
||||
3. **Manual First**: 자동화는 나중에
|
||||
4. **Talk to Users**: 매일 사용자와 대화
|
||||
5. **Kill Features**: 과감하게 빼라
|
||||
|
||||
### MVP 실패 신호:
|
||||
|
||||
- 2주 지나도 출시 못함
|
||||
- 기능이 계속 추가됨
|
||||
- 사용자 피드백 없음
|
||||
- 지표 측정 안 함
|
||||
- "좀 더 완벽하게" 반복
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### 이 명령어 실행 후:
|
||||
|
||||
**📍 다음 단계: Step 6 - `/appkit.merge`** (기획 정돈)
|
||||
- MVP 범위가 정해졌으니 이제 기획 정돈 단계로
|
||||
- 용어 통일, 기능 중복 제거
|
||||
- 고객 가치 일관성 확보
|
||||
|
||||
---
|
||||
|
||||
## Version
|
||||
|
||||
- **Version**: 1.0.0
|
||||
- **Created**: 2025-11-19
|
||||
- **Philosophy**: "If you're not embarrassed by v1, you launched too late"
|
||||
480
.claude/commands/appkit.new.md
Normal file
480
.claude/commands/appkit.new.md
Normal file
@@ -0,0 +1,480 @@
|
||||
---
|
||||
description: 아이디어 스케치 - 막연한 아이디어를 서비스 컨셉으로 구체화
|
||||
---
|
||||
|
||||
## User Input
|
||||
|
||||
```text
|
||||
$ARGUMENTS
|
||||
```
|
||||
|
||||
User input **must** be considered (if not empty).
|
||||
|
||||
## Overview
|
||||
|
||||
The text following `/appkit.new` is the app description. Assume `$ARGUMENTS` is always available in this conversation even if shown as-is. Don't ask again unless the user provides an empty command.
|
||||
|
||||
**This is Step 1 of the logical thinking 7-step workflow**:
|
||||
|
||||
```
|
||||
논리적 사고 7단계:
|
||||
1. /appkit.new → 아이디어 스케치 (어떤 서비스인지?) ← YOU ARE HERE
|
||||
2. /appkit.spec → 기능 구체화 (뭐가 필요할까? 누가 쓸까?)
|
||||
3. /appkit.customer → 고객 스토리 (고객의 하루, 고민, 해결)
|
||||
4. /appkit.sales → 세일즈 랜딩 구성 (어떻게 설득할까?)
|
||||
5. /appkit.mvp → MVP 범위 정하기 (최소한으로 검증하려면?)
|
||||
6. /appkit.merge → 기획 정돈 (흩어진 기획 통합)
|
||||
7. /appkit.design → 개발 준비 (API, ERD, 기술 스펙)
|
||||
```
|
||||
|
||||
Based on the app description, perform the following:
|
||||
|
||||
## Execution Flow
|
||||
|
||||
### 1. 아이디어 스케치 (고객 중심 대화)
|
||||
|
||||
**Input**: User's natural language app description (e.g., "Tennis court booking app with promotions and coupons")
|
||||
|
||||
**Step 1: 고객 문제 파악**
|
||||
1. **무슨 문제를 해결하나?**:
|
||||
- 현재 고객이 겪는 불편함
|
||||
- 기존 솔루션의 한계
|
||||
- 해결되지 않은 니즈
|
||||
|
||||
2. **누가 이 문제를 겪나?**:
|
||||
- 주요 타겟 고객군
|
||||
- 그들의 특성과 행동 패턴
|
||||
- 문제의 심각도
|
||||
|
||||
**Step 2: 서비스 컨셉 제시**
|
||||
|
||||
Present customer-centric summary in this format:
|
||||
|
||||
```markdown
|
||||
## 📋 서비스 컨셉
|
||||
|
||||
**서비스명**: [추론한 이름 또는 사용자 입력]
|
||||
|
||||
### 🎯 핵심 문제와 해결책
|
||||
|
||||
**고객이 겪는 문제**:
|
||||
- "테니스 치고 싶은데 코트 예약이 너무 번거로워요"
|
||||
- "전화로 일일이 확인해야 하고, 대기 시간도 길어요"
|
||||
- "가격도 제각각이라 비교가 어려워요"
|
||||
|
||||
**우리의 해결책**:
|
||||
- 3초 만에 실시간 예약
|
||||
- 모든 코트 가격 한눈에 비교
|
||||
- 자동 할인으로 30% 저렴하게
|
||||
|
||||
### 👥 타겟 고객
|
||||
|
||||
**Primary (핵심 고객)**:
|
||||
- 30-40대 직장인
|
||||
- 주말 운동을 원하지만 시간이 없는 사람
|
||||
- 편의성과 시간 절약을 중시
|
||||
|
||||
**Secondary (보조 고객)**:
|
||||
- 프리랜서 (시간 유연, 가격 민감)
|
||||
- 대학생 (저렴한 가격 선호)
|
||||
|
||||
### 💎 핵심 가치 (왜 써야 하나?)
|
||||
|
||||
1. **시간 절약**: 15분 대기 → 3초 예약
|
||||
2. **비용 절감**: 자동 할인으로 평균 30% 저렴
|
||||
3. **확실한 예약**: 실시간 확인, 즉시 확정
|
||||
|
||||
### 🚀 차별점 (경쟁사와 뭐가 다른가?)
|
||||
|
||||
- 기존: 전화 예약, 불확실, 정가
|
||||
- 우리: 앱 예약, 실시간, 자동 할인
|
||||
|
||||
### 📦 주요 기능 (고객 가치 중심)
|
||||
|
||||
1. **001-search**: 빠른 코트 검색
|
||||
- 위치 기반 자동 추천
|
||||
- 실시간 예약 가능 확인
|
||||
|
||||
2. **002-booking**: 간편 예약/결제
|
||||
- 3초 예약 완료
|
||||
- 원터치 결제
|
||||
|
||||
3. **003-discount**: 스마트 할인
|
||||
- 타임딜 자동 적용
|
||||
- 쿠폰 자동 추천
|
||||
|
||||
4. **004-manage**: 예약 관리
|
||||
- 예약 변경/취소
|
||||
- 알림 설정
|
||||
|
||||
5. **005-social**: 커뮤니티
|
||||
- 파트너 찾기
|
||||
- 리뷰/평점
|
||||
|
||||
### 💰 수익 모델
|
||||
|
||||
- 예약 수수료 (5-10%)
|
||||
- 프리미엄 멤버십 (우선 예약권)
|
||||
- 제휴 광고 (장비, 레슨)
|
||||
|
||||
---
|
||||
|
||||
이렇게 이해한 것이 맞나요? 수정하거나 추가하고 싶은 내용이 있나요?
|
||||
|
||||
특히:
|
||||
- 핵심 고객이 맞나요?
|
||||
- 해결하려는 문제가 정확한가요?
|
||||
- 더 중요한 기능이 있나요?
|
||||
```
|
||||
|
||||
**Step 3: Receive User Feedback**
|
||||
|
||||
Wait for user response:
|
||||
- "Good", "Yes", "Proceed" → Move to Step 4
|
||||
- Modification request → Update content and return to Step 2
|
||||
- Additional features → Add to feature list and return to Step 2
|
||||
|
||||
**Example Dialog**:
|
||||
```
|
||||
User: "Lesson booking is important too. And we need instructor rating feature"
|
||||
|
||||
Claude:
|
||||
Got it! I'll update as follows:
|
||||
|
||||
**Major Feature Specs (Updated)**:
|
||||
1. 001-user: User authentication and profile management
|
||||
2. 002-venue: Court information management
|
||||
3. 003-lesson: Lesson information and instructor management (newly added)
|
||||
4. 004-booking: Booking and payment system (courts + lessons)
|
||||
5. 005-promotion: Coupons and promotions
|
||||
6. 006-review: Facility and instructor reviews/ratings (instructor rating added)
|
||||
|
||||
Shall we proceed with this?
|
||||
```
|
||||
|
||||
**Step 4: Final Confirmation**
|
||||
|
||||
When user confirms with "Good", "Proceed", etc.:
|
||||
|
||||
```
|
||||
✅ App structure confirmed!
|
||||
|
||||
Creating files now...
|
||||
```
|
||||
|
||||
### 2. Script Execution (After User Confirmation)
|
||||
|
||||
Execute only after user confirmation:
|
||||
|
||||
**Script**: `.app/scripts/init-app.sh --json --app-name "tymatch"`
|
||||
|
||||
**Script Actions**:
|
||||
- Create `docs/appkit/` directory
|
||||
- Create `docs/appkit/specs/` directory
|
||||
- Create subdirectories for each confirmed spec (`001-user/`, `002-venue/`, ...)
|
||||
- JSON output:
|
||||
```json
|
||||
{
|
||||
"SPECS_DIR": "docs/appkit/specs",
|
||||
"APP_OVERVIEW": "docs/appkit/overview.md"
|
||||
}
|
||||
```
|
||||
|
||||
**Important**:
|
||||
- **No file creation before user confirmation**
|
||||
- Script only handles directory creation and path output
|
||||
- Natural language analysis and dialogue handled by Claude
|
||||
|
||||
### 3. Service Overview Document Creation
|
||||
|
||||
**File**: `docs/appkit/overview.md`
|
||||
|
||||
**Content**: Use **user-confirmed content** with customer focus
|
||||
|
||||
```markdown
|
||||
# [Service Name] Service Concept
|
||||
|
||||
## 🎯 서비스 본질
|
||||
[한 문장으로 서비스 정의]
|
||||
예: "직장인의 주말 운동을 쉽게 만드는 테니스 코트 예약 서비스"
|
||||
|
||||
## 🔥 해결하는 문제
|
||||
[User-confirmed problems]
|
||||
- 번거로운 전화 예약 (15분 대기)
|
||||
- 불투명한 가격 정보
|
||||
- 원하는 시간대 확인 어려움
|
||||
|
||||
## 👥 타겟 고객
|
||||
[User-confirmed target customers]
|
||||
|
||||
### Primary Persona
|
||||
- 김대리 (35세, IT기업)
|
||||
- Pain: "주말 운동하고 싶은데 예약이 너무 번거로워"
|
||||
- Want: 빠른 예약, 확실한 시간 확보
|
||||
|
||||
### Secondary Personas
|
||||
- 프리랜서: 평일 낮 저렴한 시간대 활용
|
||||
- 대학생: 그룹 예약으로 할인 받기
|
||||
|
||||
## 💎 핵심 가치 제안
|
||||
[User-confirmed value propositions]
|
||||
1. **시간 절약**: 15분 → 3초
|
||||
2. **비용 절감**: 자동 할인 30%
|
||||
3. **확실성**: 실시간 확인 & 즉시 확정
|
||||
|
||||
## 📦 주요 기능 (고객 가치 중심)
|
||||
[User-confirmed features with customer value]
|
||||
- **001-search**: 3초 만에 찾는 완벽한 코트
|
||||
- **002-booking**: 클릭 한 번으로 예약 완료
|
||||
- **003-discount**: 자동으로 적용되는 최저가
|
||||
- **004-manage**: 언제든 변경 가능한 유연함
|
||||
- **005-social**: 함께 운동할 파트너 찾기
|
||||
|
||||
## 🚀 MVP 로드맵
|
||||
Phase 0 (2주): 핵심 예약 기능
|
||||
Phase 1 (1개월): 할인 & 리뷰
|
||||
Phase 2 (3개월): 커뮤니티 & 확장
|
||||
|
||||
## 💰 비즈니스 모델
|
||||
[User-confirmed business model]
|
||||
- 예약 수수료 (5-10%)
|
||||
- 프리미엄 멤버십
|
||||
- 제휴 마케팅
|
||||
|
||||
## 📊 성공 지표
|
||||
- Week 1: 10명 사용자 확보
|
||||
- Week 2: 10건 예약 달성
|
||||
- Month 1: NPS 30+ 달성
|
||||
```
|
||||
|
||||
**Important**: Use content presented in Step 2 and confirmed by user **as-is**
|
||||
|
||||
### 4. Individual Spec Draft Creation (Based on Overview.md)
|
||||
|
||||
Create **initial draft** `spec.md` file in each spec directory based on overview.md content:
|
||||
|
||||
**Important**: This creates **first draft**, not empty templates. Extract relevant information from overview.md for each feature.
|
||||
|
||||
**Approach**:
|
||||
1. Read the feature description from overview.md (주요 기능 section)
|
||||
2. Extract customer value, target user, and workflow hints
|
||||
3. Create initial draft with inferred content
|
||||
4. Mark sections that need `/appkit.spec` for further detailing
|
||||
|
||||
**File**: `docs/appkit/specs/001-persona/spec.md`
|
||||
|
||||
**Content**: Draft with overview-based initial content
|
||||
|
||||
```markdown
|
||||
# Spec: 001-persona
|
||||
|
||||
## Feature Name
|
||||
페르소나 생성 및 관리
|
||||
|
||||
## User Value (고객 가치)
|
||||
[Extract from overview.md's feature description]
|
||||
- 100가지 다양한 스타일로 브랜드 노출 확대
|
||||
- 카테고리별 최적화된 인플루언서 확보
|
||||
|
||||
## Target User (누가 쓸까?)
|
||||
[Infer from overview.md's 타겟 고객 section]
|
||||
- Primary: 서비스 관리자
|
||||
- Use case: 초기 셋업 시 다양한 페르소나 생성
|
||||
|
||||
## User Journey & Screen Flow
|
||||
[Extract workflow from overview.md's 핵심 워크플로우]
|
||||
|
||||
### 1. 페르소나 생성 화면
|
||||
- **UI Elements**: 카테고리 선택, 개수 설정, 생성 버튼
|
||||
- **CTA**: "100명 자동 생성" 버튼
|
||||
- **Next**: 페르소나 목록 화면
|
||||
|
||||
### 2. 페르소나 목록 화면
|
||||
- **UI Elements**: 페르소나 카드 그리드 (이름, 카테고리, 상태)
|
||||
- **CTA**: 미드저니 프롬프트 export, 프로필 이미지 업로드
|
||||
- **Next**: 개별 페르소나 상세
|
||||
|
||||
## Business Rules
|
||||
[Extract from overview.md's feature description]
|
||||
- 카테고리별 페르소나 자동 생성 (Beauty 25명, Fashion 25명, etc.)
|
||||
- 미드저니용 프롬프트 export 기능
|
||||
- 프로필 이미지 업로드 시스템
|
||||
|
||||
## Edge Cases
|
||||
[Initial inference - needs /appkit.spec for details]
|
||||
- 페르소나 생성 실패 시 재시도 로직
|
||||
- 중복 페르소나 체크
|
||||
|
||||
## Dependencies
|
||||
[Infer from overview.md workflow]
|
||||
- None (initial setup feature)
|
||||
|
||||
---
|
||||
|
||||
💡 **더 구체화하려면**:
|
||||
```
|
||||
/appkit.spec 001-persona "카테고리별 비율 조정 기능"
|
||||
/appkit.spec 001-persona "페르소나별 톤앤매너 설정"
|
||||
```
|
||||
```
|
||||
|
||||
**Content Generation Strategy**:
|
||||
|
||||
For each spec (001-010), extract from overview.md:
|
||||
|
||||
1. **Feature Name**: Use Korean name from 주요 기능 section
|
||||
2. **User Value**: Extract from 핵심 가치 제안 or feature description
|
||||
3. **Target User**: Infer from 타겟 고객 (관리자 vs 광고주)
|
||||
4. **User Journey**: Extract from 핵심 워크플로우 section
|
||||
5. **Business Rules**: Extract explicit rules from feature description
|
||||
6. **Edge Cases**: Basic inference (mark as "needs detailing")
|
||||
7. **Dependencies**: Infer from workflow order
|
||||
|
||||
**Example Mapping** (from AI Influencer Network overview.md):
|
||||
|
||||
```
|
||||
001-persona →
|
||||
- Extract: "100명의 다양한 인플루언서 생성"
|
||||
- User Value: 카테고리별 최적화된 인플루언서 풀 확보
|
||||
- Journey: 카테고리 선택 → 자동 생성 → 미드저니 export
|
||||
|
||||
003-content-composer →
|
||||
- Extract: "크롤링 요소 조합으로 빠른 제작"
|
||||
- User Value: 검증된 요소 조합으로 시행착오 최소화
|
||||
- Journey: 크롤링 갤러리 → 요소 선택 → 나노바나나 생성
|
||||
|
||||
006-brand-site →
|
||||
- Extract: "광고주가 쉽게 의뢰"
|
||||
- User Value: 빠른 캠페인 실행, 다양한 타겟층 공략
|
||||
- Journey: 브랜드 등록 → 카테고리 선택 → 캐릭터 추천
|
||||
```
|
||||
|
||||
**Files to Create** (with overview-based drafts):
|
||||
- `docs/appkit/specs/001-persona/spec.md`
|
||||
- `docs/appkit/specs/002-reference-crawl/spec.md`
|
||||
- `docs/appkit/specs/003-content-composer/spec.md`
|
||||
- `docs/appkit/specs/004-caption-generator/spec.md`
|
||||
- `docs/appkit/specs/005-approval/spec.md`
|
||||
- `docs/appkit/specs/006-brand-site/spec.md`
|
||||
- `docs/appkit/specs/007-ad-content/spec.md`
|
||||
- `docs/appkit/specs/008-posting/spec.md`
|
||||
- `docs/appkit/specs/009-engagement/spec.md`
|
||||
- `docs/appkit/specs/010-analytics/spec.md`
|
||||
|
||||
### 5. Completion Report
|
||||
|
||||
Report to user:
|
||||
|
||||
```
|
||||
✅ 서비스 컨셉 정의 & 기능 초안 생성 완료!
|
||||
|
||||
📁 생성된 파일:
|
||||
- docs/appkit/overview.md (서비스 컨셉)
|
||||
- docs/appkit/specs/001-search/spec.md (검색 - 초안 생성됨 ✨)
|
||||
- docs/appkit/specs/002-booking/spec.md (예약 - 초안 생성됨 ✨)
|
||||
- docs/appkit/specs/003-discount/spec.md (할인 - 초안 생성됨 ✨)
|
||||
- docs/appkit/specs/004-manage/spec.md (관리 - 초안 생성됨 ✨)
|
||||
- docs/appkit/specs/005-social/spec.md (커뮤니티 - 초안 생성됨 ✨)
|
||||
|
||||
✨ 변경사항: 빈 템플릿이 아닌 overview.md 기반 **초안**이 생성되었습니다!
|
||||
각 spec에는 이미 다음 내용이 포함되어 있습니다:
|
||||
- User Value (고객 가치)
|
||||
- Target User (타겟 고객)
|
||||
- User Journey (기본 화면 흐름)
|
||||
- Business Rules (핵심 규칙)
|
||||
- Dependencies (의존성)
|
||||
|
||||
🎯 핵심 가치:
|
||||
- 시간 절약: 15분 → 3초
|
||||
- 비용 절감: 30% 자동 할인
|
||||
- 확실한 예약: 실시간 확정
|
||||
|
||||
👥 타겟 고객:
|
||||
- Primary: 30-40대 직장인
|
||||
- Secondary: 프리랜서, 대학생
|
||||
|
||||
📝 다음 단계 (논리적 사고 흐름):
|
||||
|
||||
**Step 2 - 기능 구체화 (/appkit.spec)**
|
||||
이미 초안이 있으니, 더 구체적인 시나리오를 추가하세요:
|
||||
/appkit.spec 001-search "위치 기반으로 가까운 코트 찾기, 거리순 정렬"
|
||||
/appkit.spec 002-booking "퇴근길 지하철에서 3초 예약, 원터치 결제"
|
||||
/appkit.spec 003-discount "타임딜 자동 적용, 중복 쿠폰 불가"
|
||||
|
||||
**Step 3 - 고객 스토리 (/appkit.customer)**
|
||||
타겟 페르소나의 하루와 문제 해결 스토리:
|
||||
/appkit.customer
|
||||
|
||||
**Step 4 - 세일즈 랜딩 (/appkit.sales)**
|
||||
광고주를 설득하는 랜딩 페이지:
|
||||
/appkit.sales
|
||||
|
||||
📍 현재 위치: Step 1/7 완료 (아이디어 스케치 + 초안 생성)
|
||||
📍 다음 단계: Step 2 - /appkit.spec (기능 구체화)
|
||||
|
||||
💡 Tip: 각 spec 파일을 열어보세요. 이미 기본 구조가 채워져 있어서
|
||||
`/appkit.spec`으로 추가 디테일만 넣으면 됩니다!
|
||||
```
|
||||
|
||||
## Important Notes
|
||||
|
||||
### 🔴 Mandatory Requirements
|
||||
|
||||
1. **Interactive process required**:
|
||||
- **Never create files immediately**
|
||||
- Always present summary in Step 2
|
||||
- Create files only after user confirmation
|
||||
|
||||
2. **Handle user feedback**:
|
||||
- "Good", "Yes", "Proceed" → Proceed with file creation
|
||||
- Modification request → Update and re-present
|
||||
- Additional features → Update list and re-present
|
||||
- If uncertain, ask additional questions
|
||||
|
||||
3. **Iterate before confirmation**:
|
||||
- Repeat Steps 2-3 until user is satisfied
|
||||
- Don't rush, have thorough dialogue
|
||||
|
||||
### 🟡 Analysis Guidelines
|
||||
|
||||
1. **Natural language analysis**:
|
||||
- Carefully analyze user input
|
||||
- Infer domain and business model
|
||||
- Derive reasonable major features (5-8)
|
||||
- Fill gaps with questions
|
||||
|
||||
2. **Numbering system**:
|
||||
- Use 3-digit numbers (001, 002, 003, ...)
|
||||
- Sort in logical order (auth → core features → supplementary features)
|
||||
|
||||
3. **Feature names**:
|
||||
- Short and clear (user, venue, booking, promotion)
|
||||
- Use lowercase English with hyphens
|
||||
|
||||
### 🟢 Technical Details
|
||||
|
||||
1. **Script execution**:
|
||||
- Execute only after user confirmation
|
||||
- If script doesn't exist, create directories manually
|
||||
- Parse JSON output to confirm paths
|
||||
|
||||
2. **Incremental detailing**:
|
||||
- This stage creates **structure only**
|
||||
- Details added with `/appkit.spec` command
|
||||
|
||||
## Example Flow
|
||||
|
||||
```
|
||||
User: /appkit.new Tennis court booking app
|
||||
|
||||
Claude: [Presents Step 2 summary]
|
||||
|
||||
User: Add lesson booking too
|
||||
|
||||
Claude: [Presents updated summary]
|
||||
|
||||
User: Good!
|
||||
|
||||
Claude: ✅ Confirmed! Creating files...
|
||||
[Executes file creation]
|
||||
```
|
||||
370
.claude/commands/appkit.sales.md
Normal file
370
.claude/commands/appkit.sales.md
Normal file
@@ -0,0 +1,370 @@
|
||||
# appkit.sales
|
||||
|
||||
**고객을 설득하는 세일즈 랜딩 메시지를 구성하는 명령어**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**This is Step 4 of the logical thinking 7-step workflow**:
|
||||
|
||||
```
|
||||
논리적 사고 7단계:
|
||||
1. /appkit.new → 아이디어 스케치 (어떤 서비스인지?)
|
||||
2. /appkit.spec → 기능 구체화 (뭐가 필요할까? 누가 쓸까?)
|
||||
3. /appkit.customer → 고객 스토리 (고객의 하루, 고민, 해결)
|
||||
4. /appkit.sales → 세일즈 랜딩 구성 (어떻게 설득할까?) ← YOU ARE HERE
|
||||
5. /appkit.mvp → MVP 범위 정하기 (최소한으로 검증하려면?)
|
||||
6. /appkit.merge → 기획 정돈 (흩어진 기획 통합)
|
||||
7. /appkit.design → 개발 준비 (API, ERD, 기술 스펙)
|
||||
```
|
||||
|
||||
## Purpose
|
||||
|
||||
타겟 고객의 문제와 욕구를 기반으로 설득력 있는 세일즈 메시지를 구성합니다.
|
||||
기능 나열이 아닌, 고객 가치와 변화 스토리로 설득합니다.
|
||||
|
||||
**핵심 질문**: "어떻게 고객을 설득할까?"
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- `/appkit.customer`로 타겟 고객을 정의한 후 (Step 3 완료 후)
|
||||
- 랜딩 페이지나 마케팅 메시지가 필요할 때
|
||||
- 투자자나 팀에게 가치 제안을 설명할 때
|
||||
- MVP 출시 전 메시지 테스트가 필요할 때
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/appkit.sales
|
||||
/appkit.sales "time-saving for busy professionals"
|
||||
/appkit.sales "price-sensitive students"
|
||||
/appkit.sales "landing: premium positioning"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What I'll Do
|
||||
|
||||
### 1. 세일즈 프레임워크 선택
|
||||
|
||||
**상황별 최적 프레임워크**:
|
||||
|
||||
```markdown
|
||||
## Framework Selection
|
||||
|
||||
### PAS (Problem-Agitate-Solution)
|
||||
✅ Best for: 명확한 문제가 있는 경우
|
||||
- Problem: 고객이 겪는 문제 공감
|
||||
- Agitate: 문제를 더 심각하게 느끼게
|
||||
- Solution: 우리 서비스가 해결책
|
||||
|
||||
### AIDA (Attention-Interest-Desire-Action)
|
||||
✅ Best for: 새로운 카테고리 창출
|
||||
- Attention: 놀라운 통계나 질문
|
||||
- Interest: 흥미로운 가능성 제시
|
||||
- Desire: 갖고 싶게 만들기
|
||||
- Action: 지금 행동하게 만들기
|
||||
|
||||
### StoryBrand
|
||||
✅ Best for: 복잡한 서비스 설명
|
||||
- Character: 고객이 주인공
|
||||
- Problem: 겪고 있는 문제
|
||||
- Guide: 우리가 안내자
|
||||
- Plan: 명확한 해결 단계
|
||||
- Success: 성공 스토리
|
||||
```
|
||||
|
||||
### 2. 랜딩 페이지 구조 (PAS 기준)
|
||||
|
||||
```markdown
|
||||
## Landing Page Structure
|
||||
|
||||
### 1️⃣ Hero Section (Hook - 3초 승부)
|
||||
---
|
||||
[Headline - 핵심 가치]
|
||||
"테니스 코트 예약, 이제 3초면 충분합니다"
|
||||
|
||||
[Subheadline - 구체적 혜택]
|
||||
"전화 대기 없이, 실시간 예약, 자동 할인까지"
|
||||
|
||||
[CTA Button]
|
||||
"지금 시작하기 →"
|
||||
|
||||
[Hero Image]
|
||||
스마트폰으로 예약하는 모습
|
||||
|
||||
|
||||
### 2️⃣ Problem Section (공감대 형성)
|
||||
---
|
||||
"이런 경험, 해보셨나요?"
|
||||
|
||||
❌ 전화 예약하려다 15분 대기
|
||||
❌ 원하는 시간대는 항상 만석
|
||||
❌ 가격 비교는 불가능
|
||||
❌ 취소하려면 또 전화
|
||||
|
||||
"매주 테니스 치고 싶은데,
|
||||
예약이 너무 번거로워 포기하신 적 있으시죠?"
|
||||
|
||||
|
||||
### 3️⃣ Agitation Section (문제 심화)
|
||||
---
|
||||
[통계로 문제 심화]
|
||||
"직장인 73%가 운동 부족"
|
||||
"운동 포기 이유 1위: 번거로운 예약(42%)"
|
||||
|
||||
[감정 자극]
|
||||
"주말마다 '이번엔 꼭 운동해야지' 다짐하지만,
|
||||
복잡한 예약 과정에 지쳐 결국 포기하고 있지 않나요?"
|
||||
|
||||
|
||||
### 4️⃣ Solution Section (해결책 제시)
|
||||
---
|
||||
"3초 예약 시스템"
|
||||
|
||||
[Step 1] 📍 위치 선택
|
||||
가까운 코트 자동 추천
|
||||
|
||||
[Step 2] 📅 시간 선택
|
||||
실시간 예약 가능 시간 확인
|
||||
|
||||
[Step 3] 💳 결제 완료
|
||||
원터치 결제, 자동 할인 적용
|
||||
|
||||
"복잡한 과정은 우리가 해결했습니다"
|
||||
|
||||
|
||||
### 5️⃣ Benefits Section (구체적 혜택)
|
||||
---
|
||||
[시간 절약]
|
||||
⏰ 평균 15분 → 3초
|
||||
"매주 1시간 절약"
|
||||
|
||||
[비용 절감]
|
||||
💰 자동 할인 적용
|
||||
"평균 30% 저렴"
|
||||
|
||||
[편의성]
|
||||
📱 언제 어디서나
|
||||
"지하철에서도 예약 가능"
|
||||
|
||||
|
||||
### 6️⃣ Social Proof Section (신뢰 구축)
|
||||
---
|
||||
[숫자로 증명]
|
||||
"5,000명이 매주 사용 중"
|
||||
"월 10,000건 예약 처리"
|
||||
"평균 평점 4.8/5.0"
|
||||
|
||||
[고객 후기]
|
||||
"김OO (37세, 직장인)"
|
||||
"퇴근길 지하철에서 예약 완료!
|
||||
주말 운동이 규칙적으로 바뀌었어요"
|
||||
|
||||
"박OO (29세, 프리랜서)"
|
||||
"평일 낮 할인으로 30% 절약!
|
||||
시간도 자유롭고 가격도 저렴해요"
|
||||
|
||||
|
||||
### 7️⃣ CTA Section (행동 유도)
|
||||
---
|
||||
[긴급성 생성]
|
||||
"🎁 지금 가입하면 첫 예약 30% 할인"
|
||||
"⏰ 이번 주말 예약 마감 임박"
|
||||
|
||||
[3단계 CTA]
|
||||
1. "무료로 시작하기" (부담 제거)
|
||||
2. "1분 만에 가입" (간편함 강조)
|
||||
3. "첫 예약 30% 할인" (즉각 혜택)
|
||||
|
||||
[보증]
|
||||
"예약 수수료 없음"
|
||||
"언제든 취소 가능"
|
||||
```
|
||||
|
||||
### 3. 가치 제안 캔버스 (Value Proposition Canvas)
|
||||
|
||||
```markdown
|
||||
## Value Proposition
|
||||
|
||||
### Customer Jobs (고객이 해결하려는 일)
|
||||
- 주말 운동 계획
|
||||
- 건강 관리
|
||||
- 스트레스 해소
|
||||
- 사회적 교류
|
||||
|
||||
### Pain Relievers (고통 해결)
|
||||
- 전화 대기 → 즉시 예약
|
||||
- 불확실성 → 실시간 확인
|
||||
- 비싼 가격 → 자동 할인
|
||||
- 복잡한 과정 → 3단계 간소화
|
||||
|
||||
### Gain Creators (이익 창출)
|
||||
- 시간 절약 (주당 1시간)
|
||||
- 비용 절감 (30% 할인)
|
||||
- 규칙적 운동 습관
|
||||
- 운동 仲間 찾기
|
||||
```
|
||||
|
||||
### 4. 메시지 A/B 테스트 제안
|
||||
|
||||
```markdown
|
||||
## A/B Testing Suggestions
|
||||
|
||||
### Headline Variations
|
||||
A: "테니스 코트 예약, 이제 3초면 충분합니다"
|
||||
B: "매주 테니스 치고 싶다면? 앱으로 3초 예약"
|
||||
C: "전화 대기는 그만, 실시간 코트 예약"
|
||||
|
||||
### CTA Variations
|
||||
A: "지금 시작하기"
|
||||
B: "무료로 예약하기"
|
||||
C: "30% 할인받기"
|
||||
|
||||
### Value Prop Variations
|
||||
A: "시간 절약" 중심
|
||||
B: "비용 절감" 중심
|
||||
C: "편의성" 중심
|
||||
```
|
||||
|
||||
### 5. 채널별 메시지 최적화
|
||||
|
||||
```markdown
|
||||
## Channel-Specific Messages
|
||||
|
||||
### Instagram Ad (비주얼 중심)
|
||||
[Image: 테니스 치는 행복한 모습]
|
||||
"주말 테니스, 3초 예약 ✨"
|
||||
#테니스 #주말운동 #코트예약
|
||||
|
||||
### Google Ads (검색 의도 명확)
|
||||
"테니스 코트 예약 | 실시간 예약 | 30% 할인"
|
||||
"전화 대기 없이 바로 예약. 지금 시작하기"
|
||||
|
||||
### Email (스토리텔링)
|
||||
Subject: "김대리님, 이번 주말 테니스 어떠세요?"
|
||||
"매번 예약 때문에 포기하셨다면..."
|
||||
[Full story + CTA]
|
||||
|
||||
### 카톡 채널 (친근한 톤)
|
||||
"테니스 예약 때문에 스트레스 받으셨죠? 😅
|
||||
이제 카톡하듯 쉽게 예약하세요!"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Files
|
||||
|
||||
### 생성될 파일들:
|
||||
|
||||
1. **`docs/appkit/sales-landing.md`**
|
||||
- 전체 랜딩 페이지 구조
|
||||
- 섹션별 메시지
|
||||
- CTA 전략
|
||||
|
||||
2. **`docs/appkit/value-proposition.md`**
|
||||
- 핵심 가치 제안
|
||||
- Pain-Gain 매트릭스
|
||||
- 차별화 포인트
|
||||
|
||||
---
|
||||
|
||||
## Integration Points
|
||||
|
||||
### 다른 명령어와의 연계:
|
||||
|
||||
- **From `/appkit.customer`**: 페르소나별 Pain Points
|
||||
- **From `/appkit.spec`**: 핵심 기능과 혜택
|
||||
- **To `/appkit.mvp`**: 검증할 핵심 가치
|
||||
- **To `/appkit.design`**: 사용자 온보딩 플로우
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: B2C 서비스
|
||||
```bash
|
||||
$ /appkit.sales
|
||||
|
||||
📢 Sales Landing Generated
|
||||
|
||||
Framework: PAS (Problem-Agitate-Solution)
|
||||
|
||||
Hero: "3초 예약 혁명"
|
||||
Problem: 복잡한 예약 과정
|
||||
Agitate: 73% 운동 포기
|
||||
Solution: 원터치 시스템
|
||||
Proof: 5,000명 사용 중
|
||||
CTA: "지금 30% 할인"
|
||||
|
||||
✅ Generated sales-landing.md
|
||||
✅ Generated value-proposition.md
|
||||
```
|
||||
|
||||
### Example 2: 특정 페르소나 타겟
|
||||
```bash
|
||||
$ /appkit.sales "price-sensitive students"
|
||||
|
||||
📢 Student-Focused Message
|
||||
|
||||
Hero: "학생 90% 할인"
|
||||
Problem: 비싼 코트 가격
|
||||
Solution: 그룹 예약 할인
|
||||
Proof: "서울대 테니스 동아리 공식 앱"
|
||||
CTA: "학생증 인증하고 90% 할인"
|
||||
|
||||
✅ Updated sales-landing.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
### 세일즈 메시지 원칙:
|
||||
|
||||
1. **Features ❌ Benefits ✅**: "실시간 예약"이 아닌 "대기 시간 제로"
|
||||
2. **You, not We**: "당신은" 중심, "우리는" 최소화
|
||||
3. **Specific Numbers**: "많이"가 아닌 "73%"
|
||||
4. **Emotional + Rational**: 감정 자극 + 논리적 근거
|
||||
5. **Clear Next Step**: 모호한 CTA는 전환율 킬러
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
### 고전환율 랜딩 페이지:
|
||||
|
||||
1. **Above the Fold**: 스크롤 없이 핵심 가치 전달
|
||||
2. **One Message**: 한 페이지, 하나의 메시지
|
||||
3. **Social Proof**: 숫자 > 로고 > 후기 순으로 배치
|
||||
4. **Urgency**: "지금" 행동해야 할 이유
|
||||
5. **Risk Reversal**: 무료 체험, 환불 보장
|
||||
|
||||
### 카피라이팅 공식:
|
||||
|
||||
- **Headline**: 혜택 + 숫자 + 시간
|
||||
- **CTA**: 동사 + 혜택 + 긴급성
|
||||
- **Testimonial**: 이름 + 나이 + 직업 + 구체적 결과
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### 이 명령어 실행 후:
|
||||
|
||||
**📍 다음 단계: Step 5 - `/appkit.mvp`** (MVP 범위 정의)
|
||||
- 세일즈 메시지에서 약속한 핵심 가치만 구현
|
||||
- 최소한의 기능으로 시장 검증
|
||||
|
||||
---
|
||||
|
||||
## Version
|
||||
|
||||
- **Version**: 1.0.0
|
||||
- **Created**: 2025-11-19
|
||||
- **Philosophy**: "Sell the hole, not the drill"
|
||||
430
.claude/commands/appkit.spec.md
Normal file
430
.claude/commands/appkit.spec.md
Normal file
@@ -0,0 +1,430 @@
|
||||
---
|
||||
description: 기능 구체화 - 각 기능을 사용자 가치 관점에서 구체화
|
||||
---
|
||||
|
||||
## User Input
|
||||
|
||||
```text
|
||||
$ARGUMENTS
|
||||
```
|
||||
|
||||
User input **must** be considered.
|
||||
|
||||
## Overview
|
||||
|
||||
**This is Step 2 of the logical thinking 7-step workflow**:
|
||||
|
||||
```
|
||||
논리적 사고 7단계:
|
||||
1. /appkit.new → 아이디어 스케치 (어떤 서비스인지?)
|
||||
2. /appkit.spec → 기능 구체화 (뭐가 필요할까? 누가 쓸까?) ← YOU ARE HERE
|
||||
3. /appkit.customer → 고객 스토리 (고객의 하루, 고민, 해결)
|
||||
4. /appkit.sales → 세일즈 랜딩 구성 (어떻게 설득할까?)
|
||||
5. /appkit.mvp → MVP 범위 정하기 (최소한으로 검증하려면?)
|
||||
6. /appkit.merge → 기획 정돈 (흩어진 기획 통합)
|
||||
7. /appkit.design → 개발 준비 (API, ERD, 기술 스펙)
|
||||
```
|
||||
|
||||
User inputs in format: `/appkit.spec <spec-id> "<natural language description>"`
|
||||
|
||||
Examples:
|
||||
- `/appkit.spec 003-booking "search and book courts from main screen"`
|
||||
- `/appkit.spec 003-booking "time deal 30% discount, within 2 days of booking date"`
|
||||
- `/appkit.spec 004-promotion "no duplicate coupon use, max 40% discount"`
|
||||
|
||||
**Core Concepts**:
|
||||
- **Incremental detailing**: Don't write everything at once
|
||||
- **Preserve existing content**: Previous content + new content added
|
||||
- **Natural language input**: User inputs comfortably in natural language
|
||||
|
||||
**Note**: As you detail multiple specs, concepts may overlap or conflict. This is expected! The `/appkit.merge` command (Step 3) will consolidate these later.
|
||||
|
||||
## Execution Flow
|
||||
|
||||
### 1. Input Parsing
|
||||
|
||||
**Format**: `/appkit.spec <spec-id> "<natural language description>"`
|
||||
|
||||
**Parsing**:
|
||||
```
|
||||
Example: /appkit.spec 003-booking "searchable from main screen"
|
||||
|
||||
Extract:
|
||||
- spec-id: 003-booking
|
||||
- natural language description: "searchable from main screen"
|
||||
```
|
||||
|
||||
**Validation**:
|
||||
- Error if spec-id is empty
|
||||
- Error if natural language description is empty
|
||||
|
||||
### 2. Script Execution
|
||||
|
||||
**Script**: `.app/scripts/get-spec-path.sh --json --spec-id "003-booking"`
|
||||
|
||||
**Example Output**:
|
||||
```json
|
||||
{
|
||||
"SPEC_FILE": "docs/appkit/specs/003-booking/spec.md",
|
||||
"SPEC_DIR": "docs/appkit/specs/003-booking"
|
||||
}
|
||||
```
|
||||
|
||||
**Error Handling**:
|
||||
- If spec directory doesn't exist: "Spec 003-booking does not exist. Run /appkit.new first."
|
||||
|
||||
### 3. Load Existing Spec
|
||||
|
||||
**Read File**: `docs/appkit/specs/003-booking/spec.md`
|
||||
|
||||
**Check Status**:
|
||||
1. **Empty template**:
|
||||
- Not yet detailed with `/appkit.spec`
|
||||
- All sections have `[This section will be filled...]`
|
||||
|
||||
2. **Partially written**:
|
||||
- Some sections filled
|
||||
- Some sections still empty
|
||||
|
||||
3. **Fully written**:
|
||||
- Most sections filled
|
||||
- Can add/modify
|
||||
|
||||
### 4. Natural Language Analysis with User Value Focus
|
||||
|
||||
**Input Analysis**: "search and book available courts from main screen at once"
|
||||
|
||||
**고객 가치 분석**:
|
||||
```
|
||||
핵심 질문:
|
||||
- 누가? → 퇴근길 직장인, 시간이 없는 사람
|
||||
- 언제? → 이동 중, 짬날 때
|
||||
- 왜? → 빠르게 주말 운동 계획 세우려고
|
||||
- 어떻게? → 한 화면에서 모든 것 해결
|
||||
- 가치? → 시간 절약 (15분 → 3초)
|
||||
|
||||
Map to sections:
|
||||
- User Value: 3초 만에 예약 완료
|
||||
- User Journey:
|
||||
- 앱 열기 → 날짜/시간 선택 → 예약 → 완료
|
||||
- 총 소요 시간: 3초
|
||||
- Pain Points Solved:
|
||||
- 전화 대기 없음
|
||||
- 여러 코트 동시 확인
|
||||
- 즉시 확정
|
||||
|
||||
Business Rules (고객 관점):
|
||||
- 실시간 업데이트 (놓치지 않게)
|
||||
- 가격 투명 공개 (비교 가능)
|
||||
- 즉시 확정 알림 (안심)
|
||||
```
|
||||
|
||||
**Input Analysis 2**: "time deal within 2 days of booking date, 30% discount"
|
||||
|
||||
**고객 가치 분석**:
|
||||
```
|
||||
핵심 질문:
|
||||
- 누가? → 시간 유연한 프리랜서, 학생
|
||||
- 언제? → 갑자기 시간 생겼을 때
|
||||
- 왜? → 저렴하게 운동하고 싶어서
|
||||
- 어떻게? → 자동으로 할인 적용
|
||||
- 가치? → 30% 비용 절감
|
||||
|
||||
Map to sections:
|
||||
- User Value: 정가의 70%로 운동
|
||||
- User Scenario:
|
||||
- "내일 시간 비었네?" → 앱 확인 → "30% 할인!" → 즉시 예약
|
||||
- Emotional Journey:
|
||||
- 발견 (😮) → 기쁨 (😊) → 만족 (😍)
|
||||
|
||||
Business Rules (고객 이익):
|
||||
- 자동 적용 (따로 쿠폰 입력 안 해도 됨)
|
||||
- 명확한 조건 표시 (언제 할인되는지 투명)
|
||||
- 다른 할인과 비교 (가장 이득인 것 자동 선택)
|
||||
```
|
||||
|
||||
### 5. Spec Update (Incremental)
|
||||
|
||||
**Principles**:
|
||||
1. **Preserve existing content**: Never delete
|
||||
2. **Add new content**: Add natural language analysis results to relevant sections
|
||||
3. **Prevent duplicates**: Don't add already existing content
|
||||
4. **Maintain consistency**: Keep existing format and tone
|
||||
|
||||
**Update Example**:
|
||||
|
||||
**Before** (empty template):
|
||||
```markdown
|
||||
## User Journey & Screen Flow
|
||||
[This section will be filled by /appkit.spec command]
|
||||
|
||||
## Business Rules
|
||||
[This section will be filled by /appkit.spec command]
|
||||
```
|
||||
|
||||
**After** (first `/appkit.spec` execution):
|
||||
```markdown
|
||||
## User Journey & Screen Flow
|
||||
|
||||
### 1. Main Screen
|
||||
- **UI Elements**: Search bar (date, time), recommended court list
|
||||
- **CTA**: "Search" button
|
||||
- **Next**: Search results screen
|
||||
|
||||
### 2. Search Results Screen
|
||||
- **UI Elements**: Filters (price, distance, rating), court cards (image, name, price, distance)
|
||||
- **CTA**: Click court card
|
||||
- **Next**: Court detail screen
|
||||
|
||||
### 3. Court Detail Screen
|
||||
- **UI Elements**: Court info, reviews, available time slots
|
||||
- **CTA**: "Book" button
|
||||
- **Next**: Payment screen
|
||||
|
||||
## Business Rules
|
||||
### Search Criteria
|
||||
- Date: After today
|
||||
- Time slot: Selectable
|
||||
- Results: Show only available courts
|
||||
```
|
||||
|
||||
**After** (second `/appkit.spec` execution - "sort by price and distance"):
|
||||
```markdown
|
||||
## User Journey & Screen Flow
|
||||
|
||||
### 1. Main Screen
|
||||
- **UI Elements**: Search bar (date, time), recommended court list
|
||||
- **CTA**: "Search" button
|
||||
- **Next**: Search results screen
|
||||
|
||||
### 2. Search Results Screen
|
||||
- **UI Elements**: Filters (price, distance, rating), sort options (price/distance), court cards # Updated
|
||||
- **CTA**: Click court card
|
||||
- **Next**: Court detail screen
|
||||
|
||||
### 3. Court Detail Screen
|
||||
- **UI Elements**: Court info, reviews, available time slots
|
||||
- **CTA**: "Book" button
|
||||
- **Next**: Payment screen
|
||||
|
||||
## Business Rules
|
||||
### Search Criteria
|
||||
- Date: After today
|
||||
- Time slot: Selectable
|
||||
- Results: Show only available courts
|
||||
|
||||
### Sort Options # Added
|
||||
- By price: Lowest first
|
||||
- By distance: Closest first
|
||||
- Default: By price
|
||||
```
|
||||
|
||||
**After** (third `/appkit.spec` execution - "time deal 30% discount"):
|
||||
```markdown
|
||||
## Pricing & Promotion Logic
|
||||
### Time Deal # New section added
|
||||
- Condition: Within 2 days of booking date
|
||||
- Discount rate: 30%
|
||||
- Application: Automatic
|
||||
```
|
||||
|
||||
### 6. Auto-Completeness Check (고객 가치 중심)
|
||||
|
||||
After updating spec, automatically check customer value completeness:
|
||||
|
||||
**Check Sections**:
|
||||
- ✅ User Value (고객이 얻는 가치)
|
||||
- ✅ Target User (누가 쓸까?)
|
||||
- ✅ User Scenario (언제/어떻게 쓸까?)
|
||||
- ⏳ Pain Points Solved (해결되는 문제)
|
||||
- ❌ Success Metrics (어떻게 성공 측정?)
|
||||
- ⚠️ Edge Cases (예외 상황)
|
||||
|
||||
**Report to User**:
|
||||
```markdown
|
||||
✅ Spec 002-booking 고객 가치 업데이트!
|
||||
|
||||
💡 핵심 가치 분석:
|
||||
- 누가: 30대 직장인 (퇴근길)
|
||||
- 언제: 이동 중 짬날 때
|
||||
- 왜: 주말 운동 예약
|
||||
- 가치: 15분 → 3초 시간 절약
|
||||
|
||||
📝 업데이트된 내용:
|
||||
- User Value: 3초 예약으로 시간 절약
|
||||
- User Scenario: 퇴근길 지하철 예약 시나리오
|
||||
- Pain Points: 전화 대기, 불확실성 해결
|
||||
|
||||
📋 완성도 체크:
|
||||
- ✅ User Value (명확)
|
||||
- ✅ Target User (구체적)
|
||||
- ✅ User Scenario (생생함)
|
||||
- ⏳ Pain Points (더 추가 가능)
|
||||
💡 제안: "주말 만석으로 운동 못함" 추가
|
||||
- ❌ Success Metrics (미작성)
|
||||
💡 제안: "평균 예약 시간 3초 이하"
|
||||
- ⚠️ Edge Cases (미흡)
|
||||
💡 제안: "동시 예약 충돌 처리"
|
||||
|
||||
💡 다음 단계:
|
||||
더 많은 사용자 시나리오 추가:
|
||||
/appkit.spec 002-booking "프리랜서가 평일 낮 할인받기"
|
||||
/appkit.spec 002-booking "대학생 그룹 예약으로 절약"
|
||||
|
||||
📄 전체 spec 보기: docs/appkit/specs/002-booking/spec.md
|
||||
|
||||
📍 다음 단계: Step 4-5 - /appkit.customer (타겟 고객 정의 & 스토리텔링)
|
||||
```
|
||||
|
||||
### 7. Completeness Check Criteria
|
||||
|
||||
**Section Status**:
|
||||
- ✅ **Well-written**: Section has concrete content, no ambiguity
|
||||
- ⏳ **Partially written**: Section exists but lacks details
|
||||
- ⚠️ **Vague**: Section has content but vague or missing key parts
|
||||
- ❌ **Not written yet**: Section is empty or only has placeholder
|
||||
|
||||
**Required Sections** (at minimum):
|
||||
1. User Journey & Screen Flow (with screen details)
|
||||
2. Business Rules
|
||||
3. Dependencies
|
||||
|
||||
**Recommended Sections** (depending on spec type):
|
||||
- Pricing & Promotion Logic (if pricing/discounts involved)
|
||||
- Payment Flow (if payments involved)
|
||||
- Cancellation & Refund (if cancellations possible)
|
||||
- Edge Cases (always recommended)
|
||||
|
||||
## Section Mapping Guide (고객 가치 중심)
|
||||
|
||||
Natural language input → Customer value section mapping:
|
||||
|
||||
### User Value Related
|
||||
**Keywords**: "절약", "빠른", "편리한", "쉬운", "자동", "한번에"
|
||||
**Examples**:
|
||||
- "3초 만에 예약" → User Value: 시간 절약
|
||||
- "자동 할인 적용" → User Value: 비용 절감
|
||||
- "원터치 결제" → User Value: 편의성
|
||||
|
||||
### Target User Related
|
||||
**Keywords**: "직장인", "학생", "프리랜서", "주부", "시니어"
|
||||
**Examples**:
|
||||
- "바쁜 직장인을 위한" → Target User: 30-40대 직장인
|
||||
- "학생 할인" → Target User: 대학생
|
||||
|
||||
### User Scenario Related
|
||||
**Keywords**: "퇴근길", "점심시간", "주말", "갑자기", "급하게"
|
||||
**Examples**:
|
||||
- "퇴근길 지하철에서" → User Scenario: 이동 중 예약
|
||||
- "주말 아침 급하게" → User Scenario: 당일 예약
|
||||
|
||||
### Payment Flow Related
|
||||
**Keywords**: "payment", "fee", "payment method", "card", "cash", "bank transfer"
|
||||
**Examples**:
|
||||
- "online payment 5% fee" → Payment Flow
|
||||
- "cash payment no fee" → Payment Flow
|
||||
|
||||
### Cancellation & Refund Related
|
||||
**Keywords**: "cancel", "refund", "change", "modify"
|
||||
**Examples**:
|
||||
- "100% refund 24h before" → Cancellation & Refund
|
||||
- "1 booking change allowed" → Cancellation & Refund
|
||||
|
||||
### Edge Cases Related
|
||||
**Keywords**: "fail", "error", "concurrent", "duplicate", "timeout", "when empty", "exceed"
|
||||
**Examples**:
|
||||
- "first-come-first-served for concurrent bookings" → Edge Cases
|
||||
- "rollback booking on payment failure" → Edge Cases
|
||||
|
||||
### Dependencies Related
|
||||
**Keywords**: "need", "depend", "integrate", "reference"
|
||||
**Inference**: When using data or functionality from other specs
|
||||
|
||||
## Important Notes
|
||||
|
||||
### 🔴 Mandatory Requirements
|
||||
|
||||
1. **Incremental update**:
|
||||
- Never delete existing content
|
||||
- Only add new content
|
||||
- Prevent duplicates
|
||||
|
||||
2. **Natural language analysis**:
|
||||
- Carefully analyze user input
|
||||
- Map to appropriate sections
|
||||
- If inference is ambiguous, add to most relevant section
|
||||
|
||||
3. **Maintain consistency**:
|
||||
- Keep existing format and tone
|
||||
- Consistent markdown style
|
||||
- Unified terminology
|
||||
|
||||
4. **Auto-completeness check**:
|
||||
- Check completeness after every update
|
||||
- Provide next step suggestions
|
||||
- Point out vague or missing parts
|
||||
|
||||
### 🟡 Analysis Guidelines
|
||||
|
||||
1. **Multiple section updates**:
|
||||
- Single natural language input can affect multiple sections
|
||||
- Update all relevant sections
|
||||
|
||||
2. **Inference and expansion**:
|
||||
- Don't just add explicit content
|
||||
- Include reasonable inferences
|
||||
- Example: "search" → search criteria, result display, empty result handling
|
||||
|
||||
3. **Cross-reference**:
|
||||
- Specify in Dependencies if related to other specs
|
||||
- Mention policy references if related to policies
|
||||
|
||||
### 🟢 Screen Flow Details
|
||||
|
||||
When updating User Journey & Screen Flow, include:
|
||||
|
||||
**For each screen**:
|
||||
1. **Screen name**: Clear, descriptive name
|
||||
2. **UI Elements**: Key visual elements users see
|
||||
3. **CTA (Call-to-Action)**: Main buttons or actions
|
||||
4. **Next**: Which screen comes next
|
||||
|
||||
**Example**:
|
||||
```markdown
|
||||
### 2. Search Results Screen
|
||||
- **UI Elements**:
|
||||
- Filter bar (price range, distance, rating)
|
||||
- Sort dropdown (price/distance/rating)
|
||||
- Court cards with: thumbnail, name, price, distance, rating
|
||||
- "No results" message (when empty)
|
||||
- **CTA**:
|
||||
- Click court card → Court detail
|
||||
- Adjust filters → Refresh results
|
||||
- **Next**: Court detail screen or refined results
|
||||
```
|
||||
|
||||
## Example Flow
|
||||
|
||||
```
|
||||
# First execution
|
||||
User: /appkit.spec 003-booking "search courts from main screen"
|
||||
Claude: ✅ User Journey & Screen Flow, Business Rules updated
|
||||
📋 Payment Flow, Cancellation missing
|
||||
💡 Next: Add payment policy
|
||||
|
||||
# Second execution
|
||||
User: /appkit.spec 003-booking "sort by price and distance"
|
||||
Claude: ✅ User Journey, Business Rules updated (preserved + added)
|
||||
📋 Payment Flow, Cancellation still missing
|
||||
|
||||
# Third execution
|
||||
User: /appkit.spec 003-booking "time deal 30% discount"
|
||||
Claude: ✅ Pricing & Promotion Logic added (new section)
|
||||
📋 Payment Flow, Cancellation still missing
|
||||
|
||||
# Fourth execution
|
||||
User: /appkit.spec 003-booking "online payment 5% fee"
|
||||
Claude: ✅ Payment Flow added (new section)
|
||||
📋 Only Cancellation missing now
|
||||
💡 Almost complete! Just add cancellation policy
|
||||
```
|
||||
224
.claude/commands/docs.md
Normal file
224
.claude/commands/docs.md
Normal file
@@ -0,0 +1,224 @@
|
||||
---
|
||||
description: Create documentation for existing implemented features from a natural language description.
|
||||
---
|
||||
|
||||
## User Input
|
||||
|
||||
```text
|
||||
$ARGUMENTS
|
||||
```
|
||||
|
||||
You **MUST** consider the user input before proceeding (if not empty).
|
||||
|
||||
## Outline
|
||||
|
||||
The text the user typed after `/speckit.document` in the triggering message **is** the feature description (summarized by the user). Assume you always have it available in this conversation even if `$ARGUMENTS` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
|
||||
|
||||
Given that feature description, do this:
|
||||
|
||||
1. **Generate a concise document name** (2-4 words):
|
||||
- Analyze the feature description and extract the most meaningful keywords
|
||||
- Create a 2-4 word name that captures the essence of the feature
|
||||
- Use noun format when possible (e.g., "cart-feature", "payment-system", "user-authentication")
|
||||
- Preserve technical terms and acronyms (OAuth2, API, JWT, etc.)
|
||||
- Keep it concise but descriptive enough to understand the feature at a glance
|
||||
- Examples:
|
||||
- "장바구니 기능입니다" → "cart-feature"
|
||||
- "결제 시스템 구현" → "payment-system"
|
||||
- "사용자 인증 OAuth2" → "oauth2-authentication"
|
||||
- "리뷰 포인트 시스템" → "review-points-system"
|
||||
|
||||
2. **Determine output location** (NO script execution, NO branch creation):
|
||||
- Create docs directory if needed: `docs/` or `.specify/docs/`
|
||||
- Generate filename: `[document-name].md` (e.g., `cart-feature.md`)
|
||||
- Full path example: `docs/cart-feature.md`
|
||||
|
||||
3. Load `.specify/templates/docs-template.md` to understand required sections.
|
||||
|
||||
4. Follow this execution flow:
|
||||
|
||||
1. Parse user description from Input
|
||||
If empty: ERROR "No feature description provided"
|
||||
2. Extract key information from description:
|
||||
- Feature overview and purpose
|
||||
- Business policies mentioned
|
||||
- Main logic flows
|
||||
- Implemented features
|
||||
- API endpoints (if mentioned)
|
||||
- Known issues or improvements
|
||||
- Related files (if mentioned)
|
||||
3. For unclear aspects:
|
||||
- Make informed guesses based on context and industry standards
|
||||
- Only mark with [NEEDS CLARIFICATION: specific question] if:
|
||||
- The choice significantly impacts documentation completeness
|
||||
- Multiple reasonable interpretations exist with different implications
|
||||
- No reasonable default exists
|
||||
- **LIMIT: Maximum 3 [NEEDS CLARIFICATION] markers total**
|
||||
- Prioritize clarifications by impact: business policy > logic flow > feature details
|
||||
4. Fill all mandatory sections:
|
||||
- Overview
|
||||
- Business Policy (policies with reasons)
|
||||
- Main Logic
|
||||
- Feature List (completed and incomplete)
|
||||
- API List (if applicable)
|
||||
- Issues/Improvements
|
||||
- Related Files
|
||||
5. Return: SUCCESS (documentation ready)
|
||||
|
||||
5. Write the documentation to the determined file path using the template structure, replacing placeholders with concrete details derived from the feature description while preserving section order and headings.
|
||||
|
||||
6. **Documentation Quality Validation**: After writing the initial docs, validate it against quality criteria:
|
||||
|
||||
a. **Create Documentation Quality Checklist**: Generate a checklist file at `docs/checklists/[document-name]-quality.md` (or `.specify/docs/checklists/[document-name]-quality.md`) with these validation items:
|
||||
|
||||
```markdown
|
||||
# Documentation Quality Checklist: [FEATURE NAME]
|
||||
|
||||
**Purpose**: Validate documentation completeness and quality
|
||||
**Created**: [DATE]
|
||||
**Feature**: [Link to docs.md]
|
||||
|
||||
## Content Completeness
|
||||
|
||||
- [ ] Overview clearly explains the feature purpose
|
||||
- [ ] All business policies documented with reasons
|
||||
- [ ] Main logic flows are described
|
||||
- [ ] Feature list includes both completed and incomplete items
|
||||
- [ ] API list is complete (if feature has APIs)
|
||||
- [ ] Issues/improvements are identified
|
||||
- [ ] Related files are listed
|
||||
|
||||
## Policy Documentation
|
||||
|
||||
- [ ] No [NEEDS CLARIFICATION] markers remain
|
||||
- [ ] Each policy includes the reason/background
|
||||
- [ ] Policies are clear and unambiguous
|
||||
- [ ] Missing policies are identified in Issues/Improvements
|
||||
|
||||
## Documentation Quality
|
||||
|
||||
- [ ] Written in clear, understandable language
|
||||
- [ ] Technical terms are used appropriately
|
||||
- [ ] Examples are provided where helpful
|
||||
- [ ] Document is well-structured and easy to navigate
|
||||
|
||||
## Notes
|
||||
|
||||
- Items marked incomplete require docs updates or clarification
|
||||
```
|
||||
|
||||
b. **Run Validation Check**: Review the docs against each checklist item:
|
||||
- For each item, determine if it passes or fails
|
||||
- Document specific issues found (quote relevant sections)
|
||||
|
||||
c. **Handle Validation Results**:
|
||||
|
||||
- **If all items pass**: Mark checklist complete and proceed to step 7
|
||||
|
||||
- **If items fail (excluding [NEEDS CLARIFICATION])**:
|
||||
1. List the failing items and specific issues
|
||||
2. Update the docs to address each issue
|
||||
3. Re-run validation until all items pass (max 3 iterations)
|
||||
4. If still failing after 3 iterations, document remaining issues in checklist notes and warn user
|
||||
|
||||
- **If [NEEDS CLARIFICATION] markers remain**:
|
||||
1. Extract all [NEEDS CLARIFICATION: ...] markers from the docs
|
||||
2. **LIMIT CHECK**: If more than 3 markers exist, keep only the 3 most critical (by policy/logic/feature impact) and make informed guesses for the rest
|
||||
3. **CRITICAL - Korean Communication**: Present all questions in Korean to the user
|
||||
4. For each clarification needed (max 3), present options to user in this format:
|
||||
|
||||
```markdown
|
||||
## 질문 [N]: [주제]
|
||||
|
||||
**문맥**: [문서의 관련 섹션 인용]
|
||||
|
||||
**알아야 할 내용**: [NEEDS CLARIFICATION 마커의 구체적 질문]
|
||||
|
||||
**제안 답변**:
|
||||
|
||||
| 옵션 | 답변 | 문서화 영향 |
|
||||
|------|------|-------------|
|
||||
| A | [첫 번째 제안 답변] | [문서화에 미치는 영향] |
|
||||
| B | [두 번째 제안 답변] | [문서화에 미치는 영향] |
|
||||
| C | [세 번째 제안 답변] | [문서화에 미치는 영향] |
|
||||
| 직접입력 | 직접 답변 제공 | [사용자가 직접 입력하는 방법 설명] |
|
||||
|
||||
**선택**: _[사용자 응답 대기]_
|
||||
```
|
||||
|
||||
5. **CRITICAL - Table Formatting**: Ensure markdown tables are properly formatted:
|
||||
- Use consistent spacing with pipes aligned
|
||||
- Each cell should have spaces around content: `| Content |` not `|Content|`
|
||||
- Header separator must have at least 3 dashes: `|--------|`
|
||||
- Test that the table renders correctly in markdown preview
|
||||
6. Number questions sequentially in Korean (질문1, 질문2, 질문3 - max 3 total)
|
||||
7. Present all questions together before waiting for responses
|
||||
8. Wait for user to respond with their choices for all questions (e.g., "질문1: A, 질문2: 직접입력 - [상세내용], 질문3: B")
|
||||
9. Update the docs by replacing each [NEEDS CLARIFICATION] marker with the user's selected or provided answer
|
||||
10. Re-run validation after all clarifications are resolved
|
||||
|
||||
d. **Update Checklist**: After each validation iteration, update the checklist file with current pass/fail status
|
||||
|
||||
7. Report completion with document file path, checklist results, and any identified issues/improvements.
|
||||
|
||||
**NOTE:** This command does NOT create branches or run scripts - it only creates documentation files.
|
||||
|
||||
## General Guidelines
|
||||
|
||||
## Quick Guidelines
|
||||
|
||||
- Focus on documenting **WHAT is implemented**, **WHY (business reasons)**, and **HOW (main logic)**.
|
||||
- Include both completed and incomplete features.
|
||||
- Identify issues and improvements discovered during documentation.
|
||||
- Written for both technical and non-technical stakeholders.
|
||||
|
||||
### Section Requirements
|
||||
|
||||
- **Mandatory sections**: Must be completed for every feature
|
||||
- **Optional sections**: Include only when relevant to the feature (e.g., API List)
|
||||
- When a section doesn't apply, remove it entirely (don't leave as "N/A")
|
||||
|
||||
### For AI Generation
|
||||
|
||||
When creating this documentation from a user prompt:
|
||||
|
||||
1. **Make informed guesses**: Use context, industry standards, and common patterns to fill gaps
|
||||
2. **Document what's known**: Focus on information explicitly provided by the user
|
||||
3. **Limit clarifications**: Maximum 3 [NEEDS CLARIFICATION] markers - use only for critical information that:
|
||||
- Significantly impacts documentation completeness
|
||||
- Has multiple reasonable interpretations with different implications
|
||||
- Lacks any reasonable default
|
||||
4. **Prioritize clarifications**: business policy > logic flow > feature details
|
||||
5. **Think practically**: Document what exists, flag what's missing in Issues/Improvements
|
||||
6. **Common areas needing clarification** (only if no reasonable default exists):
|
||||
- Business policy reasons (why this implementation was chosen)
|
||||
- Missing or unclear logic flows
|
||||
- Incomplete feature status (implemented vs planned)
|
||||
|
||||
**Examples of reasonable defaults** (don't ask about these):
|
||||
|
||||
- Standard CRUD operations: If basic endpoints are mentioned, assume standard patterns
|
||||
- Common business policies: Industry-standard practices unless specified otherwise
|
||||
- File organization: Standard Rails/project conventions unless specified
|
||||
- Error handling: Standard error responses unless specified
|
||||
|
||||
### Documentation Structure Guidelines
|
||||
|
||||
Documentation should be:
|
||||
|
||||
1. **Clear**: Use simple language, avoid jargon unless necessary
|
||||
2. **Complete**: All mandatory sections filled appropriately
|
||||
3. **Accurate**: Based on user's description, not assumptions
|
||||
4. **Actionable**: Issues/improvements are specific and practical
|
||||
|
||||
**Good examples**:
|
||||
|
||||
- "재고 차감 시점: 장바구니 추가 시 (이유: 한정 수량 선점 방지)"
|
||||
- "만료 정책: 30일 후 자동 만료 (이유: 데이터 누적 방지)"
|
||||
- "[ ] [P1] 재고 복구 배치 작업 미구현 (현재 재고가 복구되지 않음)"
|
||||
|
||||
**Bad examples**:
|
||||
|
||||
- "정책 있음" (not specific)
|
||||
- "잘 작동함" (no business reason)
|
||||
- "개선 필요" (not actionable)
|
||||
516
.claude/commands/market.channel.md
Normal file
516
.claude/commands/market.channel.md
Normal file
@@ -0,0 +1,516 @@
|
||||
# market.channel
|
||||
|
||||
**채널별 알고리즘 최적화 및 성과 극대화 전략 명령어**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**This is the third step of the 4C Marketing Framework**:
|
||||
|
||||
```
|
||||
저비용 마케팅 4C:
|
||||
1. /market.customer → 고객 세분화 & 채널 추천 (누구에게, 어디서?)
|
||||
2. /market.contents → 콘텐츠 전략 & 재활용 (무엇을 만들까?)
|
||||
3. /market.channel → 채널별 최적화 전략 (어떻게 최적화할까?) ← YOU ARE HERE
|
||||
4. /market.communicate → 바이럴 & 커뮤니티 전략 (어떻게 퍼뜨릴까?)
|
||||
```
|
||||
|
||||
## Purpose
|
||||
|
||||
각 플랫폼의 **알고리즘과 사용자 행동**을 이해하고,
|
||||
동일한 콘텐츠를 채널별로 최적화하여 **도달과 전환을 극대화**합니다.
|
||||
|
||||
**핵심 질문**: "같은 메시지도 플랫폼마다 어떻게 다르게 포장해야 할까?"
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- `/market.contents`로 콘텐츠를 기획한 후
|
||||
- 채널별 성과가 기대에 못 미칠 때
|
||||
- 알고리즘 변화에 대응해야 할 때
|
||||
- 채널 추가를 고려할 때
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/market.channel
|
||||
/market.channel "focus: 유튜브 + 인스타"
|
||||
/market.channel "네이버 SEO 집중"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What I'll Do
|
||||
|
||||
### 1. 채널별 알고리즘 이해
|
||||
|
||||
```markdown
|
||||
## Platform Algorithm Breakdown
|
||||
|
||||
### 유튜브 (YouTube)
|
||||
**알고리즘 핵심**: CTR (클릭률) × Retention (시청 지속률) × Session Time
|
||||
|
||||
#### 최적화 요소
|
||||
|
||||
**1. 썸네일 + 제목 (CTR 결정)**
|
||||
- CTR 8%+ 목표 (평균 4-5%)
|
||||
- 썸네일: 사람 얼굴 클로즈업 + 텍스트 3단어 이내
|
||||
- 제목: 40자 이내, 숫자 + 결과 + 타겟
|
||||
- 예: "테니스 코트 예약 30분→3초로 줄인 법"
|
||||
|
||||
**2. 첫 30초 (Retention 결정)**
|
||||
⚠️ 알고리즘 생존 구간
|
||||
- 0-5초: 충격/질문으로 시작 (인사 X)
|
||||
- 5-15초: 즉시 가치 제시 (구독 요청 X)
|
||||
- 15-25초: 콘텐츠 로드맵 제시
|
||||
- 25-30초: 감정 훅 (궁금증/공감)
|
||||
|
||||
**3. 평균 시청 지속률 (AVD)**
|
||||
- 목표: 50%+ (10분 영상 → 5분 시청)
|
||||
- 3분/5분/7분 마다 retention hook 삽입
|
||||
- 예: "⚠️ 다음 내용 놓치면 손해"
|
||||
|
||||
**4. 세션 시간**
|
||||
- 재생목록 활용
|
||||
- 끝 화면 (End Screen)에 다음 영상 유도
|
||||
- "이것도 보세요" 카드 삽입
|
||||
|
||||
**5. 업로드 최적 시간**
|
||||
- 타겟 시청 시간대 2-3시간 전
|
||||
- 직장인 타겟: 목/금요일 18:00 업로드 (퇴근 후 시청)
|
||||
- 주부 타겟: 월/수요일 14:00 업로드 (오후 시간)
|
||||
|
||||
**6. 해시태그 & 챕터**
|
||||
- 해시태그 3개 (너무 많으면 역효과)
|
||||
- 챕터 5-7개 (타임라인 분할)
|
||||
|
||||
**성과 지표**:
|
||||
- CTR: 8%+ (바이럴 가능)
|
||||
- AVD: 50%+
|
||||
- 구독 전환율: 2%+
|
||||
|
||||
|
||||
### 인스타그램 (Instagram)
|
||||
**알고리즘 핵심**: Engagement (좋아요/댓글/저장) × Relationship × Timeliness
|
||||
|
||||
#### 릴스 최적화
|
||||
|
||||
**1. 첫 3초 법칙**
|
||||
- 스크롤 방지: 즉시 시각적 충격
|
||||
- 텍스트 오버레이: 큰 글씨 (모바일 가독성)
|
||||
- 음악: 트렌딩 사운드 사용 (검색 용이)
|
||||
|
||||
**2. 길이**
|
||||
- 최적: 7-15초 (완주율 높음)
|
||||
- 최대: 30초 (긴 건 유튜브로)
|
||||
|
||||
**3. 해시태그 전략**
|
||||
- 총 15-20개
|
||||
- 대형 (100만+): 2개 - #테니스 #운동
|
||||
- 중형 (10-50만): 5개 - #테니스레슨 #테니스동호회
|
||||
- 소형 (1-5만): 8개 - #테린이 #주말테니스
|
||||
- 니치 (<1만): 5개 - #서울테니스코트 #코트예약
|
||||
|
||||
**4. 스토리 활용**
|
||||
- 하루 5-10개 업로드 (알고리즘 부스트)
|
||||
- 스티커 사용 (투표/질문/퀴즈)
|
||||
- 하이라이트로 FAQ/가이드 정리
|
||||
|
||||
**5. 캐러셀 저장률**
|
||||
- 마지막 슬라이드에 "저장해서 나중에 보세요"
|
||||
- 체크리스트/가이드 형식 (저장 유도)
|
||||
|
||||
**6. 업로드 최적 시간**
|
||||
- 출퇴근 시간: 07:00-09:00, 18:00-20:00
|
||||
- 점심시간: 12:00-13:00
|
||||
- 주말: 10:00-12:00 (브런치 타임)
|
||||
|
||||
**성과 지표**:
|
||||
- 도달률: 팔로워의 30%+
|
||||
- 저장률: 5%+
|
||||
- 프로필 클릭률: 2%+
|
||||
|
||||
|
||||
### 네이버 블로그 (Naver Blog)
|
||||
**알고리즘 핵심**: SEO (키워드) × 체류 시간 × 이웃 수 × 방문자 수
|
||||
|
||||
#### SEO 최적화
|
||||
|
||||
**1. 키워드 전략**
|
||||
- 메인 키워드: 제목에 1회, 본문에 3-5회
|
||||
- 롱테일 키워드: "테니스 코트 예약 방법"
|
||||
- LSI 키워드: 관련 검색어 (서울, 할인, 시간)
|
||||
|
||||
**2. 제목 공식**
|
||||
- 패턴: [키워드] + [숫자/형용사] + [혜택]
|
||||
- 예: "테니스 코트 예약 방법 총정리 (2025년 최신)"
|
||||
- 길이: 25-30자 (모바일 노출 최적)
|
||||
|
||||
**3. 본문 구조**
|
||||
- 서론: 공감 + 문제 제기 (300자)
|
||||
- 본론: 단계별 솔루션 + 스크린샷 (1,500자)
|
||||
- 결론: 요약 + CTA (200자)
|
||||
- 총 2,000-3,000자 (체류 시간 3분+ 유도)
|
||||
|
||||
**4. 이미지 최적화**
|
||||
- 개수: 7-10장
|
||||
- 파일명: "테니스-코트-예약-방법.jpg" (SEO)
|
||||
- Alt 텍스트: 키워드 포함
|
||||
- 세로 이미지 선호 (모바일 최적)
|
||||
|
||||
**5. 내부 링크**
|
||||
- 내 다른 포스트 2-3개 링크
|
||||
- 체류 시간 증가 → 검색 순위 상승
|
||||
|
||||
**6. C-Rank 전략**
|
||||
- 경쟁 낮은 키워드로 시작
|
||||
- 상위 노출 후 상위 키워드 도전
|
||||
- 예: "XX지역 테니스 코트" → "테니스 코트 예약"
|
||||
|
||||
**성과 지표**:
|
||||
- 검색 유입: 50%+
|
||||
- 체류 시간: 3분+
|
||||
- 이웃 추가: 주 5명+
|
||||
|
||||
|
||||
### 네이버 카페 (Naver Cafe)
|
||||
**알고리즘 핵심**: 커뮤니티 규칙 준수 × 게시글 품질 × 회원 참여
|
||||
|
||||
#### 커뮤니티 마케팅
|
||||
|
||||
**1. 가입 전략**
|
||||
- 타겟 카페 10-20개 가입
|
||||
- 활동 1주일 후 게시 (신뢰 구축)
|
||||
- 프로필: 전문성 어필 (광고 아님)
|
||||
|
||||
**2. 게시글 전략**
|
||||
- 광고 금지 → 진짜 경험담
|
||||
- 제목: 질문형 OR 공감형
|
||||
- 예: "[후기] 동호회 예약 관리 이렇게 해결"
|
||||
- 본문: 문제 → 시도 → 해결 → 결과
|
||||
|
||||
**3. 댓글 참여**
|
||||
- 질문 글에 먼저 답변 (Give First)
|
||||
- 자연스럽게 제품 언급
|
||||
- 링크는 DM으로 (댓글 X)
|
||||
|
||||
**4. 신뢰 구축**
|
||||
- 2-3주 꾸준히 활동
|
||||
- 유용한 정보 공유
|
||||
- 매니저와 관계 형성
|
||||
|
||||
**성과 지표**:
|
||||
- 게시글 조회수: 500+
|
||||
- DM 문의: 5+
|
||||
- 실제 전환: 3+
|
||||
|
||||
|
||||
### 블라인드 (Blind)
|
||||
**알고리즘 핵심**: 공감 수 × 댓글 수 × 신고 회피
|
||||
|
||||
#### 직장인 커뮤니티 전략
|
||||
|
||||
**1. 게시 전략**
|
||||
- 게시판: "직장 생활", "이직/커리어"
|
||||
- 톤: 동료에게 말하듯 자연스럽게
|
||||
- 금지: 직접적 광고, 링크 도배
|
||||
|
||||
**2. 제목**
|
||||
- 공감형: "OO 맡았다가 퇴근 늦어본 적 있나요?"
|
||||
- 질문형: "OO 업무 효율화 어떻게 하시나요?"
|
||||
|
||||
**3. 본문**
|
||||
- 진짜 고민 공유
|
||||
- 해결 방법 언급 (제품은 자연스럽게)
|
||||
- 마지막에 질문으로 마무리
|
||||
|
||||
**4. 댓글 관리**
|
||||
- 질문에 성실히 답변
|
||||
- 광고 논란 시 "광고 아니고 진짜 써본 후기"
|
||||
|
||||
**성과 지표**:
|
||||
- 공감 수: 10+
|
||||
- 댓글 참여: 5+
|
||||
- DM 문의: 3+
|
||||
|
||||
|
||||
### 유튜브 쇼츠 (YouTube Shorts)
|
||||
**알고리즘 핵심**: 완주율 × 리플레이 × 공유
|
||||
|
||||
#### 쇼츠 최적화
|
||||
|
||||
**1. 길이**
|
||||
- 최적: 15-30초 (완주율 최대)
|
||||
- 최대: 60초
|
||||
|
||||
**2. Hook (첫 3초)**
|
||||
- 텍스트: "이거 모르면 손해"
|
||||
- 비주얼: 극적 Before/After
|
||||
- 음악: 긴장감/리듬감
|
||||
|
||||
**3. 자막 필수**
|
||||
- 85% 무음 시청
|
||||
- 큰 글씨 (모바일 가독성)
|
||||
- 색상 대비 (흰 글씨 + 검은 테두리)
|
||||
|
||||
**4. CTA 위치**
|
||||
- 마지막 3초: "자세한 내용은 고정 댓글"
|
||||
- 댓글에 링크 (바이오 아님)
|
||||
|
||||
**성과 지표**:
|
||||
- 완주율: 70%+
|
||||
- 조회수: 1,000+ (48시간 내)
|
||||
- 구독 전환: 1%+
|
||||
```
|
||||
|
||||
### 2. Channel-Specific Content Adaptation
|
||||
|
||||
```markdown
|
||||
## Same Message, Different Packaging
|
||||
|
||||
### Core Message (공통)
|
||||
"테니스 코트 예약 30분 → 3초로 단축"
|
||||
|
||||
### 유튜브 버전 (10분)
|
||||
**제목**: "테니스 코트 예약 30분 걸리는 사람 vs 3초 끝내는 사람 차이"
|
||||
|
||||
**썸네일**:
|
||||
- Before: 😤 (전화 통화 중 짜증난 표정)
|
||||
- After: 😄 (폰 들고 웃는 표정)
|
||||
- 텍스트: "30분 vs 3초"
|
||||
|
||||
**스크립트 구조**:
|
||||
0:00 - Hook: "매주 토요일 아침 7시에 일어나서 5개 코트에 전화하던 제가..."
|
||||
0:30 - Problem: 기존 예약의 3가지 문제
|
||||
2:00 - Discovery: 이 앱을 알게 된 계기
|
||||
4:00 - Demo: 실제 사용 화면
|
||||
7:00 - Result: 4주 사용 후기
|
||||
9:00 - CTA: 첫 예약 할인
|
||||
|
||||
|
||||
### 인스타 릴스 버전 (15초)
|
||||
**Hook**: "주말마다 이러시죠?"
|
||||
|
||||
**화면**:
|
||||
[0-3초] Before: 전화기 들고 대기 중 (⏰ 30분 텍스트)
|
||||
[4-6초] Transition: 화면 전환 이펙트
|
||||
[7-12초] After: 앱으로 탭탭탭 (⚡ 3초 텍스트)
|
||||
[13-15초] CTA: "링크는 바이오에"
|
||||
|
||||
**음악**: 트렌딩 사운드 (빠른 템포)
|
||||
|
||||
**해시태그**: #테니스 #테린이 #코트예약 #꿀팁 #운동
|
||||
|
||||
|
||||
### 네이버 블로그 버전 (2,500자)
|
||||
**제목**: "테니스 코트 예약 방법 총정리 (2025년 최신) - 할인 받는 법까지"
|
||||
|
||||
**목차**:
|
||||
1. 테니스 코트 예약 3가지 방법 비교
|
||||
2. 전화 예약 vs 앱 예약 장단점
|
||||
3. 추천 예약 앱 Top 3 (객관적 비교)
|
||||
4. [OO 앱] 사용 가이드 (스크린샷)
|
||||
5. 할인받는 꿀팁 3가지
|
||||
6. 자주 묻는 질문 (FAQ)
|
||||
|
||||
**SEO 키워드** (본문 5회 삽입):
|
||||
- 테니스 코트 예약
|
||||
- 테니스 코트 할인
|
||||
- 서울 테니스 코트
|
||||
|
||||
|
||||
### 네이버 카페 버전 (800자)
|
||||
**제목**: "[후기] 동호회 예약 관리 이렇게 해결했어요"
|
||||
|
||||
**본문**:
|
||||
```
|
||||
안녕하세요, 25명 동호회 운영 중인 회원입니다.
|
||||
|
||||
[문제]
|
||||
매주 토요일 코트 예약이 제일 큰 스트레스였어요.
|
||||
- 5개 코트 전화 (30분)
|
||||
- 회원들 일정 조율 (카톡 100통)
|
||||
- 예약 실패하면 욕먹음
|
||||
|
||||
[해결]
|
||||
OO 앱 써봤는데 진짜 편하더라고요.
|
||||
(광고 아니고 4주 써본 진짜 후기)
|
||||
|
||||
[효과]
|
||||
- 예약 시간: 30분 → 3분
|
||||
- 회원 만족도 UP
|
||||
- 자동 할인 30% (회비 절감)
|
||||
|
||||
혹시 비슷한 고민 있으신 분들 참고하세요!
|
||||
```
|
||||
|
||||
**톤**: 동료에게 말하듯, 광고 아님 강조
|
||||
|
||||
|
||||
### 블라인드 버전 (500자)
|
||||
**제목**: "동아리 간사 맡았다가 예약 업무로 스트레스 받는 사람?"
|
||||
|
||||
**본문**:
|
||||
```
|
||||
직장 테니스 동아리 간사 맡았는데
|
||||
분기별 코트 예약이 업무보다 힘듭니다 ㅠㅠ
|
||||
|
||||
전화 10통 + 엑셀 정리 + 입금 확인...
|
||||
퇴근 후 2시간 날리는 중
|
||||
|
||||
혹시 효율적으로 하는 법 아시는 분?
|
||||
|
||||
[추가]
|
||||
댓글로 OO 앱 추천 받아서 써봤는데
|
||||
진짜 10분 만에 끝나네요... 진작 쓸걸
|
||||
|
||||
링크 궁금하신 분 DM 주세요
|
||||
(회사 정보 공개 안 돼서 여기 못 남김)
|
||||
```
|
||||
|
||||
**전략**: 고민 공유 → 댓글로 자연스럽게 해결
|
||||
|
||||
|
||||
### 유튜브 쇼츠 버전 (30초)
|
||||
**자막 (큰 글씨)**:
|
||||
[0-5초] "매주 이러시는 분?"
|
||||
[6-10초] 전화 예약 장면 (30분 ⏰)
|
||||
[11-15초] "이제 이렇게 하세요"
|
||||
[16-25초] 앱 예약 장면 (3초 ⚡)
|
||||
[26-30초] "자세한 건 고정 댓글"
|
||||
|
||||
**고정 댓글**: "앱 이름: OO / 첫 예약 30% 할인 코드: SHORTS2025"
|
||||
```
|
||||
|
||||
### 3. Channel Performance Dashboard
|
||||
|
||||
```markdown
|
||||
## Weekly Performance Tracking
|
||||
|
||||
### 주간 체크리스트
|
||||
|
||||
#### 유튜브
|
||||
- [ ] CTR: 8% 이상 유지
|
||||
- [ ] AVD: 50% 이상 유지
|
||||
- [ ] 구독 전환율: 2% 이상
|
||||
- [ ] 댓글 10개 이상 달림
|
||||
- [ ] 업로드 시간 최적화 확인
|
||||
|
||||
**Pivot Signal**:
|
||||
- CTR < 5%: 썸네일/제목 A/B 테스트
|
||||
- AVD < 40%: 첫 30초 개선
|
||||
- 구독 < 1%: CTA 위치 변경
|
||||
|
||||
|
||||
#### 인스타그램
|
||||
- [ ] 도달률: 팔로워 30% 이상
|
||||
- [ ] 저장률: 5% 이상
|
||||
- [ ] 프로필 클릭: 2% 이상
|
||||
- [ ] 스토리 10개 이상 업로드
|
||||
- [ ] 해시태그 15개 최적화
|
||||
|
||||
**Pivot Signal**:
|
||||
- 도달률 < 20%: 해시태그 변경
|
||||
- 저장률 < 2%: 콘텐츠 형식 변경 (캐러셀로)
|
||||
- 클릭 < 1%: 바이오 CTA 개선
|
||||
|
||||
|
||||
#### 네이버 블로그
|
||||
- [ ] 검색 유입: 50% 이상
|
||||
- [ ] 체류 시간: 3분 이상
|
||||
- [ ] 이웃 추가: 주 5명
|
||||
- [ ] 댓글: 3개 이상
|
||||
- [ ] C-Rank 상승 확인
|
||||
|
||||
**Pivot Signal**:
|
||||
- 검색 < 30%: 키워드 재선정
|
||||
- 체류 < 2분: 본문 구조 개선
|
||||
- 이웃 < 2명: 내부 링크 강화
|
||||
|
||||
|
||||
#### 커뮤니티 (카페/블라인드)
|
||||
- [ ] 게시글 조회수: 500+
|
||||
- [ ] DM 문의: 5+
|
||||
- [ ] 댓글 참여: 10+
|
||||
- [ ] 신고 없음
|
||||
- [ ] 신뢰 구축 (답변 활동)
|
||||
|
||||
**Pivot Signal**:
|
||||
- 조회 < 200: 제목 개선
|
||||
- 문의 < 2: 본문 CTA 개선
|
||||
- 신고 발생: 톤 조정 (덜 광고스럽게)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Files
|
||||
|
||||
### 생성될 파일들:
|
||||
|
||||
1. **`docs/market/channel-playbook.md`**
|
||||
- 채널별 알고리즘 분석
|
||||
- 최적화 체크리스트
|
||||
- 성과 지표 및 Pivot 기준
|
||||
|
||||
2. **`docs/market/content-adaptation-guide.md`**
|
||||
- 동일 메시지의 채널별 변주
|
||||
- 포맷별 예시
|
||||
- 톤앤매너 가이드
|
||||
|
||||
3. **`docs/market/performance-dashboard.md`**
|
||||
- 주간 성과 트래킹 템플릿
|
||||
- KPI 및 목표 설정
|
||||
- 개선 액션 플랜
|
||||
|
||||
---
|
||||
|
||||
## Integration Points
|
||||
|
||||
### 다른 명령어와의 연계:
|
||||
|
||||
- **From `/market.contents`**: 콘텐츠 → 채널별 최적화
|
||||
- **To `/market.communicate`**: 성과 좋은 채널 → 바이럴 전략
|
||||
- **Feedback to `/market.customer`**: 채널 성과 → 타겟 재조정
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
### Channel Optimization:
|
||||
|
||||
1. **Platform Native**: 각 채널의 언어로 말하기
|
||||
2. **Algorithm First**: 사용자 전에 알고리즘 통과
|
||||
3. **Test & Iterate**: 2주마다 A/B 테스트
|
||||
4. **Data-Driven**: 감 말고 지표로 결정
|
||||
5. **Consistent Voice**: 채널은 다르되 브랜드는 일관
|
||||
|
||||
### Channel Anti-Patterns:
|
||||
|
||||
❌ **Copy-Paste**: 유튜브 영상을 인스타에 그대로
|
||||
❌ **Algorithm Ignorance**: 알고리즘 무시하고 원하는 대로
|
||||
❌ **Vanity Metrics**: 팔로워만 보고 전환율 무시
|
||||
❌ **Impatience**: 1주 만에 판단
|
||||
❌ **Over-Optimization**: 알고리즘만 보고 사용자 무시
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### 이 명령어 실행 후:
|
||||
|
||||
**📍 다음 단계: `/market.communicate`** (바이럴 & 커뮤니티)
|
||||
- 채널 최적화 완료 후 바이럴 전략
|
||||
- 사용자 참여 유도 및 입소문
|
||||
- 커뮤니티 구축
|
||||
|
||||
---
|
||||
|
||||
## Version
|
||||
|
||||
- **Version**: 1.0.0
|
||||
- **Created**: 2025-11-20
|
||||
- **Philosophy**: "Don't fight the algorithm. Dance with it."
|
||||
738
.claude/commands/market.communicate.md
Normal file
738
.claude/commands/market.communicate.md
Normal file
@@ -0,0 +1,738 @@
|
||||
# market.communicate
|
||||
|
||||
**바이럴 마케팅 & 커뮤니티 구축 전략 명령어**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**This is the fourth step of the 4C Marketing Framework**:
|
||||
|
||||
```
|
||||
저비용 마케팅 4C:
|
||||
1. /market.customer → 고객 세분화 & 채널 추천 (누구에게, 어디서?)
|
||||
2. /market.contents → 콘텐츠 전략 & 재활용 (무엇을 만들까?)
|
||||
3. /market.channel → 채널별 최적화 전략 (어떻게 최적화할까?)
|
||||
4. /market.communicate → 바이럴 & 커뮤니티 전략 (어떻게 퍼뜨릴까?) ← YOU ARE HERE
|
||||
```
|
||||
|
||||
## Purpose
|
||||
|
||||
사람들이 **자발적으로 공유하고 추천**하게 만들고,
|
||||
**충성 커뮤니티**를 구축하여 지속 가능한 성장 엔진을 만듭니다.
|
||||
|
||||
**핵심 질문**: "어떻게 하면 사람들이 알아서 우리 제품을 퍼뜨릴까?"
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- `/market.channel`로 기본 최적화를 마친 후
|
||||
- 초기 고객 10-100명을 확보한 후
|
||||
- 바이럴 계수를 높이고 싶을 때
|
||||
- 커뮤니티 구축이 필요할 때
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/market.communicate
|
||||
/market.communicate "focus: 바이럴"
|
||||
/market.communicate "커뮤니티 구축 중점"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What I'll Do
|
||||
|
||||
### 1. 바이럴 루프 설계 (Viral Loop)
|
||||
|
||||
```markdown
|
||||
## Viral Loop Framework
|
||||
|
||||
### 바이럴 계수 (K-Factor) 이해
|
||||
**공식**: K = i × c
|
||||
- i (Invites): 사용자 1명이 초대하는 평균 인원
|
||||
- c (Conversion): 초대받은 사람 중 실제 가입하는 비율
|
||||
|
||||
**목표**: K > 1 (자가 성장)
|
||||
- K = 1.2: 100명 → 120명 → 144명 (성장)
|
||||
- K = 0.8: 100명 → 80명 → 64명 (소멸)
|
||||
|
||||
**Example: 테니스 코트 예약 앱**
|
||||
- i = 3명 (동호회 회원에게 공유)
|
||||
- c = 40% (초대받은 사람 중 가입)
|
||||
- K = 3 × 0.4 = 1.2 ✅
|
||||
|
||||
|
||||
### 바이럴 루프 4단계
|
||||
|
||||
#### Stage 1: Trigger (트리거 - 공유 동기)
|
||||
"왜 공유하고 싶을까?"
|
||||
|
||||
**내재적 동기 (Intrinsic)**
|
||||
- 도움주고 싶어서: "친구들도 편해질 것 같아"
|
||||
- 자랑하고 싶어서: "나 이런 거 찾았어"
|
||||
- 정체성 표현: "나는 이런 걸 쓰는 사람"
|
||||
|
||||
**외재적 동기 (Extrinsic)**
|
||||
- 리워드: "친구 초대하면 할인"
|
||||
- 필요성: "초대해야 기능 해금"
|
||||
- 경쟁: "추천 순위 1위 되기"
|
||||
|
||||
**테니스 앱 예시**:
|
||||
✅ 내재적: "우리 동호회 회원들 편하게 해주고 싶다"
|
||||
✅ 외재적: "친구 초대 1명당 1회 예약 무료"
|
||||
|
||||
|
||||
#### Stage 2: Sharing Mechanism (공유 메커니즘)
|
||||
"어떻게 쉽게 공유할까?"
|
||||
|
||||
**One-Click Sharing**
|
||||
- 카톡 공유: "우리 동호회 단톡방에 공유" 버튼
|
||||
- URL 복사: 자동으로 할인 코드 포함
|
||||
- 인스타 스토리: 예약 완료 시 "스토리 공유" 버튼
|
||||
|
||||
**Pre-filled Message**
|
||||
```
|
||||
[카톡 메시지 템플릿]
|
||||
"나 이 앱으로 테니스 코트 예약하는데 진짜 편함!
|
||||
3초 만에 예약되고 자동 할인까지 받아.
|
||||
|
||||
이 링크로 가입하면 첫 예약 30% 할인
|
||||
→ [링크 + 내 추천 코드]"
|
||||
```
|
||||
|
||||
**Social Proof Display**
|
||||
- "이미 500명이 이 앱으로 예약했어요"
|
||||
- "OO님 외 25명이 사용 중"
|
||||
|
||||
|
||||
#### Stage 3: Landing (랜딩 - 초대받은 사람 경험)
|
||||
"초대받은 사람이 뭘 보나?"
|
||||
|
||||
**전용 랜딩 페이지**
|
||||
```
|
||||
[화면]
|
||||
🎾 OO님이 추천한 테니스 코트 예약 앱
|
||||
|
||||
"OO님처럼 3초 만에 예약하고
|
||||
첫 예약 30% 할인받으세요"
|
||||
|
||||
[버튼] 지금 시작하기 (할인 자동 적용)
|
||||
|
||||
[하단]
|
||||
이미 500명이 사용 중 ⭐⭐⭐⭐⭐
|
||||
```
|
||||
|
||||
**Trust Signal**
|
||||
- 추천인 이름 표시 (신뢰 구축)
|
||||
- 할인 혜택 명확히 (즉시 가치)
|
||||
- 사회적 증거 (안심)
|
||||
|
||||
|
||||
#### Stage 4: Hook (훅 - 다시 공유하게 만들기)
|
||||
"가입한 사람도 또 공유하게"
|
||||
|
||||
**First Use Magic Moment**
|
||||
- 첫 예약 완료 시: "친구에게도 알려주시겠어요?"
|
||||
- 할인 받았을 때: "친구도 30% 할인 받게 공유"
|
||||
|
||||
**Gamification**
|
||||
- 추천 리더보드: "이번 달 Top 10 추천인"
|
||||
- 배지 시스템: "5명 초대 → 골드 회원"
|
||||
- 단계별 리워드: "3명/10명/30명 달성 시 보상"
|
||||
|
||||
|
||||
### 바이럴 전략 유형
|
||||
|
||||
#### 1. Incentivized Referral (인센티브 추천)
|
||||
**Dropbox 모델**: "너도 좋고 나도 좋고"
|
||||
|
||||
**Example: 테니스 앱**
|
||||
```
|
||||
친구 초대 프로그램:
|
||||
- 초대한 사람: 무료 예약권 1회
|
||||
- 초대받은 사람: 첫 예약 30% 할인
|
||||
|
||||
초대 10명 달성 시:
|
||||
- 1개월 무료 프리미엄
|
||||
```
|
||||
|
||||
**Pro**: 빠른 확산
|
||||
**Con**: 인센티브 중독 (질 낮은 사용자)
|
||||
|
||||
|
||||
#### 2. Product-Driven Virality (제품 기반 바이럴)
|
||||
**Calendly 모델**: "제품 쓰면 자동으로 노출"
|
||||
|
||||
**Example: 테니스 앱**
|
||||
```
|
||||
예약 확인 메시지 (카톡):
|
||||
"OO 코트 예약 완료! 🎾
|
||||
토요일 10:00 / 2코트
|
||||
|
||||
Made with [앱 이름]
|
||||
→ 간편 예약: [링크]"
|
||||
```
|
||||
|
||||
**Pro**: 자연스러운 노출
|
||||
**Con**: 느린 확산
|
||||
|
||||
|
||||
#### 3. Content Virality (콘텐츠 바이럴)
|
||||
**BuzzFeed 모델**: "재미/유용해서 공유"
|
||||
|
||||
**Example: 테니스 앱**
|
||||
```
|
||||
공유하고 싶은 콘텐츠:
|
||||
- "테니스 코트 가성비 순위 Top 10"
|
||||
- "서울 테니스 코트 지도 (할인 정보)"
|
||||
- "동호회 운영 꿀팁 체크리스트 PDF"
|
||||
```
|
||||
|
||||
**Pro**: 자연스러운 브랜드 노출
|
||||
**Con**: 콘텐츠 제작 비용
|
||||
|
||||
|
||||
#### 4. Social Currency (사회적 화폐)
|
||||
**Tesla 모델**: "쓰는 것 자체가 자랑"
|
||||
|
||||
**Example: 테니스 앱**
|
||||
```
|
||||
Status Symbol 만들기:
|
||||
- "얼리어답터 배지" (초기 100명)
|
||||
- "VIP 회원" (추천 10명 이상)
|
||||
- "동호회 오피셜" (단체 가입)
|
||||
|
||||
→ SNS에 인증하고 싶게 만들기
|
||||
```
|
||||
|
||||
**Pro**: 충성도 높은 사용자
|
||||
**Con**: 포지셔닝 필요
|
||||
```
|
||||
|
||||
### 2. 커뮤니티 구축 (Community Building)
|
||||
|
||||
```markdown
|
||||
## Community Strategy
|
||||
|
||||
### 커뮤니티 성장 4단계
|
||||
|
||||
#### Phase 1: Seed (씨앗 뿌리기)
|
||||
**목표**: 첫 10-50명의 슈퍼팬 확보
|
||||
|
||||
**전략**:
|
||||
1. **Hand-Pick Early Members**
|
||||
- 가장 열성적인 사용자 직접 초대
|
||||
- DM으로 1:1 관계 형성
|
||||
- "VIP 베타 커뮤니티" 느낌
|
||||
|
||||
2. **Private Space 제공**
|
||||
- 오픈채팅방 OR 디스코드
|
||||
- 운영진과 직접 소통 가능
|
||||
- 제품 개선에 의견 반영
|
||||
|
||||
3. **Exclusive Benefits**
|
||||
- 신기능 미리 체험
|
||||
- 피드백 즉시 반영
|
||||
- 특별 할인/이벤트
|
||||
|
||||
**Example: 테니스 앱**
|
||||
```
|
||||
[DM 메시지]
|
||||
"OO님, 앱 자주 이용해주셔서 감사합니다!
|
||||
|
||||
혹시 '테니스 매니아 VIP 톡방'에 초대해드려도 될까요?
|
||||
- 신기능 미리 체험
|
||||
- 피드백 즉시 반영
|
||||
- 회원 전용 이벤트
|
||||
|
||||
선착순 50명 한정입니다.
|
||||
관심 있으시면 답장 주세요 :)"
|
||||
```
|
||||
|
||||
|
||||
#### Phase 2: Nurture (성장시키기)
|
||||
**목표**: 50-500명으로 확장
|
||||
|
||||
**전략**:
|
||||
1. **Valuable Content**
|
||||
- 주 2회 유용한 정보 공유
|
||||
- 예: "이번 주 할인 코트 Top 5"
|
||||
- 회원만 볼 수 있는 독점 정보
|
||||
|
||||
2. **Member Spotlight**
|
||||
- 매주 "이주의 멤버" 소개
|
||||
- 동호회 운영 사례 공유
|
||||
- 서로 배우고 연결
|
||||
|
||||
3. **Events & Challenges**
|
||||
- "30일 테니스 챌린지"
|
||||
- 오프라인 모임 (분기 1회)
|
||||
- 토너먼트 개최
|
||||
|
||||
**Example: 테니스 앱 커뮤니티**
|
||||
```
|
||||
[주간 루틴]
|
||||
월: 이주의 할인 코트 정보
|
||||
수: 멤버 스포트라이트 (동호회 소개)
|
||||
금: 주말 테니스 팁
|
||||
토: 커뮤니티 오프라인 모임 공지
|
||||
```
|
||||
|
||||
|
||||
#### Phase 3: Empower (권한 부여)
|
||||
**목표**: 커뮤니티가 스스로 운영되게
|
||||
|
||||
**전략**:
|
||||
1. **Member-Generated Content**
|
||||
- 회원들이 팁/후기 직접 작성
|
||||
- 베스트 게시글 선정 (리워드)
|
||||
- 공식 블로그에 전재
|
||||
|
||||
2. **Ambassador Program**
|
||||
- 지역별 앰버서더 (서울/경기/부산)
|
||||
- 오프라인 모임 주최 권한
|
||||
- 특별 혜택 (무료 프리미엄)
|
||||
|
||||
3. **Sub-Communities**
|
||||
- 지역별 채널 (#서울 #경기 #부산)
|
||||
- 레벨별 채널 (#초보 #중급 #고급)
|
||||
- 주제별 채널 (#동호회운영 #장비)
|
||||
|
||||
**Example: 앰버서더 프로그램**
|
||||
```
|
||||
[모집 공고]
|
||||
"테니스 앱 지역 앰버서더 모집 (서울/경기/부산)"
|
||||
|
||||
역할:
|
||||
- 지역 테니스 커뮤니티 리드
|
||||
- 월 1회 오프라인 모임 주최
|
||||
- 신규 회원 온보딩 도움
|
||||
|
||||
혜택:
|
||||
- 프리미엄 무료 (1년)
|
||||
- 앰버서더 배지
|
||||
- 분기별 앰버서더 미팅 (회식)
|
||||
|
||||
신청: [구글 폼]
|
||||
```
|
||||
|
||||
|
||||
#### Phase 4: Scale (확장)
|
||||
**목표**: 500명+ 자가 성장하는 커뮤니티
|
||||
|
||||
**전략**:
|
||||
1. **Flywheel Effect**
|
||||
- 커뮤니티 → 콘텐츠 생산
|
||||
- 콘텐츠 → 신규 유입
|
||||
- 신규 유입 → 커뮤니티 강화
|
||||
|
||||
2. **Multi-Channel Presence**
|
||||
- 디스코드: 실시간 소통
|
||||
- 페이스북 그룹: 정보 아카이브
|
||||
- 오픈채팅: 라이트 유저
|
||||
|
||||
3. **Self-Governance**
|
||||
- 커뮤니티 운영 규칙 회원이 결정
|
||||
- 모더레이터 선출
|
||||
- 운영진은 가이드 역할만
|
||||
|
||||
|
||||
### 커뮤니티 유형별 전략
|
||||
|
||||
#### 1. 정보 공유형 (Information)
|
||||
**목적**: 유용한 정보 교환
|
||||
|
||||
**Example: 테니스 코트 DB 커뮤니티**
|
||||
- 전국 코트 리뷰 DB
|
||||
- 지역별 코트 추천
|
||||
- 할인 정보 공유
|
||||
|
||||
**Engagement**:
|
||||
- 리뷰 작성 시 포인트
|
||||
- 베스트 리뷰 선정 (월간)
|
||||
- 정보 기여도 배지
|
||||
|
||||
|
||||
#### 2. 네트워킹형 (Networking)
|
||||
**목적**: 사람과 사람 연결
|
||||
|
||||
**Example: 테니스 메이트 찾기**
|
||||
- 지역별 파트너 매칭
|
||||
- 동호회 모집 게시판
|
||||
- 레슨 선생님 추천
|
||||
|
||||
**Engagement**:
|
||||
- 월간 오프라인 모임
|
||||
- 레벨별 매칭 이벤트
|
||||
- 성공 매칭 후기 공유
|
||||
|
||||
|
||||
#### 3. 학습형 (Learning)
|
||||
**목적**: 함께 배우고 성장
|
||||
|
||||
**Example: 테니스 실력 향상 커뮤니티**
|
||||
- 주간 테니스 팁
|
||||
- 영상 분석 & 피드백
|
||||
- 온라인 코칭 세션
|
||||
|
||||
**Engagement**:
|
||||
- 30일 챌린지 (매일 연습)
|
||||
- 전후 비교 영상 공유
|
||||
- 실력 향상 인증
|
||||
|
||||
|
||||
#### 4. 지지형 (Support)
|
||||
**목적**: 서로 격려하고 응원
|
||||
|
||||
**Example: 테니스 라이프 커뮤니티**
|
||||
- 운동 일지 공유
|
||||
- 목표 달성 축하
|
||||
- 슬럼프 극복 격려
|
||||
|
||||
**Engagement**:
|
||||
- 주간 목표 공유 스레드
|
||||
- 달성 시 축하 댓글
|
||||
- 슬럼프 극복 스토리
|
||||
```
|
||||
|
||||
### 3. 바이럴 트리거 (Shareability)
|
||||
|
||||
```markdown
|
||||
## What Makes Content Shareable?
|
||||
|
||||
### STEPPS Framework (Jonah Berger)
|
||||
|
||||
#### 1. Social Currency (사회적 화폐)
|
||||
"공유하면 나도 멋져 보여"
|
||||
|
||||
**전략**:
|
||||
- 인사이더 정보: "아는 사람만 아는"
|
||||
- 희소성: "선착순 100명"
|
||||
- 성취감: "나 이거 성공했어"
|
||||
|
||||
**Example**:
|
||||
❌ "테니스 코트 예약 완료"
|
||||
✅ "숨은 가성비 코트 발견! (일반인 출입금지 구역)"
|
||||
|
||||
|
||||
#### 2. Triggers (트리거)
|
||||
"자주 생각나게 만들기"
|
||||
|
||||
**전략**:
|
||||
- 일상과 연결: "주말마다"
|
||||
- 반복 노출: "매주 토요일 알림"
|
||||
- 장소 연동: "코트 근처 가면 알림"
|
||||
|
||||
**Example**:
|
||||
- 금요일 저녁 푸시: "내일 테니스 치시나요? 😊"
|
||||
- 위치 기반: "OO 코트 근처에 계시네요. 예약하시겠어요?"
|
||||
|
||||
|
||||
#### 3. Emotion (감정)
|
||||
"강한 감정을 유발"
|
||||
|
||||
**High-Arousal Emotions** (공유 ↑):
|
||||
- 경외 (Awe): "와... 이런 게 있었어?"
|
||||
- 흥분 (Excitement): "대박! 30% 할인!"
|
||||
- 분노 (Anger): "이 사실 아무도 안 알려줬어?"
|
||||
- 불안 (Anxiety): "이거 놓치면 손해"
|
||||
|
||||
**Low-Arousal Emotions** (공유 ↓):
|
||||
- 슬픔 (Sadness)
|
||||
- 만족 (Contentment)
|
||||
|
||||
**Example**:
|
||||
❌ "편리한 예약 앱입니다" (Low)
|
||||
✅ "왜 진작 이걸 안 만들었지? 10년 손해봤네" (Anger → 공유)
|
||||
|
||||
|
||||
#### 4. Public (공개성)
|
||||
"남들이 쓰는 게 보여야 함"
|
||||
|
||||
**전략**:
|
||||
- 브랜딩 명확히: 예약 확인서에 로고
|
||||
- 공개적 사용: SNS 공유 유도
|
||||
- Observable: "이미 500명 사용 중"
|
||||
|
||||
**Example**:
|
||||
- 인스타 스토리 공유 시 자동 배경 템플릿
|
||||
- "OO님이 [앱 이름]으로 예약했어요" (친구 피드)
|
||||
|
||||
|
||||
#### 5. Practical Value (실용적 가치)
|
||||
"진짜 도움이 되니까 공유"
|
||||
|
||||
**전략**:
|
||||
- 돈 절약: "30% 할인"
|
||||
- 시간 절약: "30분 → 3초"
|
||||
- 문제 해결: "만석 스트레스 해결"
|
||||
|
||||
**Example**:
|
||||
✅ "친구야, 이거 쓰면 한 달에 1만원 아낀다"
|
||||
✅ "우리 동호회 예약 관리 이걸로 하자"
|
||||
|
||||
|
||||
#### 6. Stories (스토리)
|
||||
"이야기 속에 자연스럽게 녹이기"
|
||||
|
||||
**전략**:
|
||||
- Before/After 스토리
|
||||
- 실패담 → 성공담
|
||||
- 유머러스한 에피소드
|
||||
|
||||
**Example**:
|
||||
```
|
||||
"지난주 토요일 아침 7시.
|
||||
5개 코트에 전화했지만 전부 만석.
|
||||
|
||||
결국 테니스 못 치고 집에서 넷플릭스...
|
||||
|
||||
그런데 친구가 이 앱 알려줘서 이번 주엔
|
||||
3초 만에 예약 성공! 🎾
|
||||
|
||||
토요일 아침 상쾌하게 운동 다녀왔습니다 ㅎㅎ"
|
||||
```
|
||||
|
||||
→ 스토리 자체가 재미있어서 공유됨
|
||||
```
|
||||
|
||||
### 4. Growth Hacking Tactics (저비용 고효율)
|
||||
|
||||
```markdown
|
||||
## Tactical Playbook
|
||||
|
||||
### Tactic 1: Launch on Product Hunt
|
||||
**Cost**: $0
|
||||
**Effort**: 중
|
||||
**Impact**: 중-고
|
||||
|
||||
**How**:
|
||||
1. Product Hunt 계정 생성
|
||||
2. 출시일 2주 전 커뮤니티 참여 (신뢰 구축)
|
||||
3. 출시 당일 00:01 (PST) 등록
|
||||
4. 첫 6시간이 승부 (친구들에게 Upvote 부탁)
|
||||
5. 댓글에 성실히 답변
|
||||
|
||||
**Goal**: Daily Top 5 → 트래픽 1,000+
|
||||
|
||||
|
||||
### Tactic 2: Guest Posting
|
||||
**Cost**: $0
|
||||
**Effort**: 고
|
||||
**Impact**: 중
|
||||
|
||||
**How**:
|
||||
1. 타겟 블로그/미디어 10개 리스트업
|
||||
2. 그들의 독자가 원하는 주제 리서치
|
||||
3. 가치 있는 게스트 포스트 작성
|
||||
4. 자연스럽게 제품 언급 (광고 X)
|
||||
|
||||
**Example**:
|
||||
- Medium: "동호회 운영 자동화하는 5가지 방법"
|
||||
- 브런치: "주말 운동 루틴 만들기"
|
||||
- 네이버 포스트: "테니스 초보 가이드"
|
||||
|
||||
|
||||
### Tactic 3: Micro-Influencer Outreach
|
||||
**Cost**: 저 (무료 체험 제공)
|
||||
**Effort**: 중
|
||||
**Impact**: 중-고
|
||||
|
||||
**How**:
|
||||
1. 팔로워 1만-5만 마이크로 인플루언서 찾기
|
||||
2. 진짜 테니스 하는 사람 선별 (광고만 하는 사람 X)
|
||||
3. DM: 무료 체험 제공 (광고 요청 X)
|
||||
4. 자발적 리뷰 기대
|
||||
|
||||
**Target**:
|
||||
- 인스타: #테니스 #테린이 해시태그 상위 포스터
|
||||
- 유튜브: 테니스 레슨 채널 (구독자 1-10만)
|
||||
|
||||
|
||||
### Tactic 4: Community Takeover
|
||||
**Cost**: $0
|
||||
**Effort**: 고 (시간 소요)
|
||||
**Impact**: 고
|
||||
|
||||
**How**:
|
||||
1. 타겟 커뮤니티에서 가장 도움 되는 사람 되기
|
||||
2. 3-4주 동안 질문에 성실히 답변
|
||||
3. 신뢰 구축 후 자연스럽게 제품 언급
|
||||
4. 광고 아닌 "진짜 도움" 제공
|
||||
|
||||
**Example**:
|
||||
- 네이버 카페: 매일 질문 3개 답변
|
||||
- 블라인드: 동아리 운영 팁 공유
|
||||
- 레딧: r/tennis에서 활동
|
||||
|
||||
|
||||
### Tactic 5: Controversy Marketing (안전한 논란)
|
||||
**Cost**: $0
|
||||
**Effort**: 중
|
||||
**Impact**: 고 (리스크 있음)
|
||||
|
||||
**How**:
|
||||
1. 업계 통념에 반대 의견 제시
|
||||
2. 논란 유발 (하지만 사실 기반)
|
||||
3. 댓글로 토론 유도
|
||||
4. 제품으로 해결책 제시
|
||||
|
||||
**Example**:
|
||||
```
|
||||
[제목] "테니스 코트 전화 예약이 더 빠르다는 건 거짓말입니다"
|
||||
|
||||
[본문]
|
||||
"앱 예약이 느리다"는 말 많이 들었습니다.
|
||||
실제로 측정해봤습니다.
|
||||
|
||||
전화 예약:
|
||||
- 대기 시간: 평균 7분
|
||||
- 통화 시간: 3분
|
||||
- 재확인 전화: 2분
|
||||
→ 총 12분
|
||||
|
||||
앱 예약:
|
||||
- 검색: 30초
|
||||
- 선택: 10초
|
||||
- 결제: 20초
|
||||
→ 총 1분
|
||||
|
||||
12배 차이입니다.
|
||||
|
||||
[데이터 그래프 첨부]
|
||||
|
||||
아직도 전화가 빠르다고 생각하시나요?
|
||||
```
|
||||
|
||||
→ 논란 → 댓글 폭발 → 바이럴
|
||||
|
||||
|
||||
### Tactic 6: Waitlist + FOMO
|
||||
**Cost**: $0
|
||||
**Effort**: 하
|
||||
**Impact**: 중
|
||||
|
||||
**How**:
|
||||
1. 정식 출시 전 "대기자 명단" 운영
|
||||
2. "선착순 100명만" 메시지
|
||||
3. 실시간 카운터: "현재 73/100"
|
||||
4. 소셜 증거: "OO님 외 72명 대기 중"
|
||||
|
||||
**Psychology**: 희소성 + 사회적 증거 → 즉시 가입
|
||||
|
||||
|
||||
### Tactic 7: Challenge/Event
|
||||
**Cost**: 저 (경품)
|
||||
**Effort**: 중
|
||||
**Impact**: 중-고
|
||||
|
||||
**How**:
|
||||
1. 30일 챌린지 기획
|
||||
2. SNS 인증 유도 (#OO챌린지)
|
||||
3. 우수 참가자 경품 (앱 내 혜택)
|
||||
4. 참가자들이 자연스럽게 바이럴
|
||||
|
||||
**Example**:
|
||||
```
|
||||
"30일 주말 테니스 챌린지"
|
||||
|
||||
참여 방법:
|
||||
1. 앱으로 코트 예약
|
||||
2. 테니스 인증샷 인스타 업로드
|
||||
3. #주말테니스챌린지 태그
|
||||
|
||||
우수 참여자 (5명):
|
||||
- 3개월 프리미엄 무료
|
||||
- 테니스 용품 세트
|
||||
```
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Files
|
||||
|
||||
### 생성될 파일들:
|
||||
|
||||
1. **`docs/market/viral-loop-design.md`**
|
||||
- 바이럴 계수 계산
|
||||
- 4단계 바이럴 루프
|
||||
- 전략 유형별 실행 계획
|
||||
|
||||
2. **`docs/market/community-playbook.md`**
|
||||
- 커뮤니티 성장 4단계
|
||||
- 유형별 커뮤니티 전략
|
||||
- 앰버서더 프로그램 설계
|
||||
|
||||
3. **`docs/market/growth-hacking-tactics.md`**
|
||||
- 7가지 저비용 전술
|
||||
- 실행 체크리스트
|
||||
- 성과 측정 방법
|
||||
|
||||
---
|
||||
|
||||
## Integration Points
|
||||
|
||||
### 다른 명령어와의 연계:
|
||||
|
||||
- **From `/market.channel`**: 성과 좋은 채널 → 바이럴 전략 집중
|
||||
- **From `/market.contents`**: 콘텐츠 → 공유 가능하게 변형
|
||||
- **Feedback to all**: 바이럴/커뮤니티 인사이트 → 전략 개선
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
### Viral Marketing:
|
||||
|
||||
1. **Built-in, Not Bolted-on**: 제품에 바이럴 메커니즘 내장
|
||||
2. **Incentive Alignment**: 공유자와 피공유자 모두 이득
|
||||
3. **Frictionless Sharing**: 클릭 1-2번으로 공유 가능
|
||||
4. **Social Proof**: 이미 많은 사람이 쓴다는 증거
|
||||
5. **FOMO > FOJI**: 놓치기 싫음 > 참여하고 싶음
|
||||
|
||||
### Community Building:
|
||||
|
||||
1. **Start Small**: 10명의 슈퍼팬 > 100명의 관심러
|
||||
2. **Exclusive First**: VIP 느낌으로 시작
|
||||
3. **Give Before Ask**: 가치를 먼저 제공
|
||||
4. **Empower Members**: 권한 위임 → 주인의식
|
||||
5. **Long-term Game**: 6개월-1년 호흡
|
||||
|
||||
### Anti-Patterns:
|
||||
|
||||
❌ **Spam**: 무분별한 홍보
|
||||
❌ **Fake Scarcity**: 거짓 희소성 ("선착순 100명" 실제론 무제한)
|
||||
❌ **Forced Sharing**: 공유 안 하면 기능 제한 (역효과)
|
||||
❌ **Ignoring Community**: 만들고 방치
|
||||
❌ **Only Incentives**: 돈으로만 유도 (진짜 팬 안 생김)
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### 이 명령어 실행 후:
|
||||
|
||||
**🎯 4C Marketing 완성!**
|
||||
|
||||
이제 다음을 실행하세요:
|
||||
1. **Week 1-2**: `/market.customer` 기반으로 타겟 채널 진입
|
||||
2. **Week 3-4**: `/market.contents` 기반으로 콘텐츠 제작 & 배포
|
||||
3. **Week 5-6**: `/market.channel` 기반으로 성과 측정 & 최적화
|
||||
4. **Week 7-8**: `/market.communicate` 기반으로 바이럴 & 커뮤니티 시작
|
||||
|
||||
**📍 다음 체크포인트**: 4주 후
|
||||
- 첫 100명 확보했나?
|
||||
- 바이럴 계수 K > 1인가?
|
||||
- 커뮤니티 활성화되고 있나?
|
||||
|
||||
---
|
||||
|
||||
## Version
|
||||
|
||||
- **Version**: 1.0.0
|
||||
- **Created**: 2025-11-20
|
||||
- **Philosophy**: "The best marketing doesn't feel like marketing. It feels like a friend's recommendation."
|
||||
589
.claude/commands/market.contents.md
Normal file
589
.claude/commands/market.contents.md
Normal file
@@ -0,0 +1,589 @@
|
||||
# market.contents
|
||||
|
||||
**하나의 핵심 메시지를 10가지 콘텐츠로 재활용하는 전략 명령어**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**This is the second step of the 4C Marketing Framework**:
|
||||
|
||||
```
|
||||
저비용 마케팅 4C:
|
||||
1. /market.customer → 고객 세분화 & 채널 추천 (누구에게, 어디서?)
|
||||
2. /market.contents → 콘텐츠 전략 & 재활용 (무엇을 만들까?) ← YOU ARE HERE
|
||||
3. /market.channel → 채널별 최적화 전략 (어떻게 최적화할까?)
|
||||
4. /market.communicate → 바이럴 & 커뮤니티 전략 (어떻게 퍼뜨릴까?)
|
||||
```
|
||||
|
||||
## Purpose
|
||||
|
||||
하나의 **핵심 가치 메시지**를 파악하고, 이를 다양한 채널과 포맷으로 변주하여
|
||||
**최소 노력으로 최대 콘텐츠**를 생성합니다.
|
||||
|
||||
**핵심 질문**: "우리 제품의 ONE 메시지는 뭐고, 이걸 10가지 방법으로 어떻게 말할까?"
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- `/market.customer`로 타겟 채널을 정한 후
|
||||
- 콘텐츠 제작 리소스가 부족할 때
|
||||
- 채널마다 다른 콘텐츠를 만들어야 할 때
|
||||
- 일관된 브랜드 메시지가 필요할 때
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/market.contents
|
||||
/market.contents "핵심 메시지: 3초 만에 코트 예약"
|
||||
/market.contents "focus: 시간 절약"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What I'll Do
|
||||
|
||||
### 1. Core Message 추출
|
||||
|
||||
```markdown
|
||||
## Core Message Extraction
|
||||
|
||||
### Input Sources
|
||||
- `docs/appkit/value-proposition.md` → 핵심 가치
|
||||
- `docs/appkit/sales-landing.md` → 메인 메시지
|
||||
- `docs/market/customer-segments.md` → 고객 Pain Point
|
||||
|
||||
### The ONE Thing
|
||||
"만약 고객이 5초 안에 우리 제품을 설명해야 한다면 뭐라고 할까?"
|
||||
|
||||
#### Example: 테니스 코트 예약 앱
|
||||
Before (기능 나열):
|
||||
❌ "코트 검색, 예약, 결제, 할인, 리뷰가 가능한 앱"
|
||||
|
||||
After (가치 중심):
|
||||
✅ "매주 30분 걸리던 코트 예약, 3초로 단축"
|
||||
|
||||
### Message Framework: Before/After Bridge
|
||||
|
||||
**Before (고객의 현재 고통)**
|
||||
- 주말마다 5개 코트에 전화 (평균 30분)
|
||||
- 원하는 시간 만석일 때 허탈함
|
||||
- 비싼 정가로 결제
|
||||
|
||||
**After (제품 사용 후 변화)**
|
||||
- 앱으로 3초 예약 완료
|
||||
- 실시간 공석 확인
|
||||
- 자동 할인 30%
|
||||
|
||||
**Bridge (제품의 핵심 메커니즘)**
|
||||
→ "실시간 통합 예약 시스템 + AI 자동 할인"
|
||||
```
|
||||
|
||||
### 2. Content Pyramid (1→10 변주 시스템)
|
||||
|
||||
```markdown
|
||||
## Content Pyramid: 1 Core → 10 Formats
|
||||
|
||||
### Level 1: Pillar Content (기둥 콘텐츠)
|
||||
"가장 심층적이고 완전한 형태"
|
||||
|
||||
#### 형식: 유튜브 롱폼 (10분)
|
||||
**제목**: "테니스 코트 예약 30분→3초로 줄인 방법 (실제 사용 후기)"
|
||||
|
||||
**구성**:
|
||||
0:00-0:30 - Hook: "매주 토요일 아침 7시, 5개 코트에 전화하던 제가..."
|
||||
0:30-2:00 - Problem: 기존 예약 방식의 3가지 문제
|
||||
2:00-7:00 - Solution: 앱 사용 실제 데모 + 3가지 핵심 기능
|
||||
7:00-9:00 - Results: Before/After 비교, 실제 절약 시간 계산
|
||||
9:00-10:00 - CTA: 첫 예약 할인 안내
|
||||
|
||||
**산출물**: 1개 영상 (하지만 여기서 10개 콘텐츠 파생)
|
||||
|
||||
|
||||
### Level 2: Derivative Content (파생 콘텐츠)
|
||||
"Pillar에서 조각내기"
|
||||
|
||||
#### 2-1. 유튜브 쇼츠 3개 (각 60초)
|
||||
**쇼츠 #1: Problem Focused**
|
||||
- 제목: "주말마다 코트 예약 전화 30분씩 하는 사람?"
|
||||
- 내용: 0:30-2:00 구간 재편집
|
||||
- Hook: 공감 유도 → 문제 제시
|
||||
|
||||
**쇼츠 #2: Solution Demo**
|
||||
- 제목: "코트 예약 3초 컷 (실제 화면)"
|
||||
- 내용: 2:00-7:00 중 핵심 20초
|
||||
- Hook: 빠른 데모 → 놀라움
|
||||
|
||||
**쇼츠 #3: Result Proof**
|
||||
- 제목: "이 앱으로 한 달에 2시간 절약함"
|
||||
- 내용: 7:00-9:00 중 숫자 강조
|
||||
- Hook: 구체적 결과 → 신뢰
|
||||
|
||||
|
||||
#### 2-2. 인스타그램 릴스 2개 (각 30초)
|
||||
**릴스 #1: Before/After**
|
||||
- 영상: 전화 예약 vs 앱 예약 비교
|
||||
- 음악: 트렌딩 사운드
|
||||
- 텍스트 오버레이: "Before: 30분 / After: 3초"
|
||||
|
||||
**릴스 #2: 3 Tips**
|
||||
- 제목: "코트 예약 꿀팁 3가지"
|
||||
- 내용: 할인받는 법 / 빠른 예약 법 / 취소 꿀팁
|
||||
|
||||
|
||||
#### 2-3. 블로그 포스트 1개 (SEO 최적화)
|
||||
**제목**: "테니스 코트 예약 방법 총정리 (2025년 최신)"
|
||||
|
||||
**목차**:
|
||||
1. 전통 방식 vs 앱 예약 비교
|
||||
2. 추천 앱 3가지 (객관적으로 보이되 우리 앱 1위)
|
||||
3. 단계별 예약 가이드 (스크린샷)
|
||||
4. 할인받는 법 (쿠폰 코드 삽입)
|
||||
5. FAQ
|
||||
|
||||
**SEO 키워드**:
|
||||
- 테니스 코트 예약
|
||||
- 서울 테니스 코트
|
||||
- 테니스 코트 할인
|
||||
|
||||
**길이**: 2,000-3,000자 (구글 상위 노출 목표)
|
||||
|
||||
|
||||
#### 2-4. 트위터 쓰레드 1개 (5-7개 트윗)
|
||||
**오프닝 트윗**:
|
||||
"매주 토요일 아침 테니스 코트 예약하느라 30분 날리던 제가,
|
||||
이제 3초 만에 끝냅니다. 어떻게? (thread 👇)"
|
||||
|
||||
**쓰레드 구성**:
|
||||
1/ 문제: 전화 예약의 고통
|
||||
2/ 발견: 이 앱을 알게 된 계기
|
||||
3/ 사용: 실제 사용 후기
|
||||
4/ 결과: 한 달 사용 후 변화
|
||||
5/ 팁: 할인 받는 법
|
||||
6/ CTA: 링크 + 첫 예약 할인
|
||||
|
||||
|
||||
#### 2-5. 링크드인 포스트 1개 (전문가 관점)
|
||||
**톤**: 캐주얼보다 전문적
|
||||
|
||||
**제목**: "테니스 동호회 운영진이 알아야 할 디지털 전환 사례"
|
||||
|
||||
**내용**:
|
||||
- 배경: 25명 동호회 운영의 어려움
|
||||
- 문제: 수작업 예약 관리의 비효율
|
||||
- 솔루션: 디지털 예약 시스템 도입
|
||||
- 결과: 관리 시간 80% 감소
|
||||
- 인사이트: "작은 커뮤니티도 디지털 전환 필요"
|
||||
|
||||
|
||||
#### 2-6. 네이버 카페 게시글 1개 (진짜 경험담)
|
||||
**제목**: "[후기] 동호회 예약 관리 이렇게 해결했습니다"
|
||||
|
||||
**톤**: 광고 아님, 진짜 도움
|
||||
|
||||
**내용**:
|
||||
```
|
||||
안녕하세요, XX 동호회 운영 중인 김OO입니다.
|
||||
|
||||
저희 동호회 회원이 25명인데요,
|
||||
매주 코트 예약이 제일 큰 스트레스였어요.
|
||||
|
||||
[문제]
|
||||
- 토요일 오전 5개 코트 전화 (30분 소요)
|
||||
- 회원들 일정 조율 카톡 100통
|
||||
- 예약 실패하면 욕먹음 ㅠㅠ
|
||||
|
||||
[해결]
|
||||
OO 앱 써보니까 진짜 편하더라고요.
|
||||
(광고 아니고 진짜 써본 후기입니다)
|
||||
|
||||
[효과]
|
||||
- 예약 시간: 30분 → 3분
|
||||
- 회원들 만족도 UP
|
||||
- 자동 할인까지 받음
|
||||
|
||||
혹시 동호회 운영하시는 분들 참고하세요!
|
||||
```
|
||||
|
||||
|
||||
#### 2-7. PDF 다운로드 자료 (리드 수집용)
|
||||
**제목**: "테니스 동호회 운영자를 위한 예약 관리 체크리스트"
|
||||
|
||||
**내용**:
|
||||
- [ ] 시즌별 선호 시간대 파악
|
||||
- [ ] 단골 코트 3곳 확보
|
||||
- [ ] 예약 앱 3개 비교 (기능/가격)
|
||||
- [ ] 회원 결제 시스템 구축
|
||||
- [ ] 예약 취소 정책 수립
|
||||
- [ ] 비 올 때 Plan B
|
||||
|
||||
**CTA**: PDF 마지막 페이지에 앱 설치 링크
|
||||
|
||||
|
||||
#### 2-8. 인스타 캐러셀 10장 (인포그래픽)
|
||||
**제목**: "코트 예약 30분→3초 줄이는 법"
|
||||
|
||||
**슬라이드 구성**:
|
||||
1. 표지: "주말마다 코트 예약 스트레스?"
|
||||
2. 문제 1: 전화 대기 15분
|
||||
3. 문제 2: 원하는 시간 만석
|
||||
4. 문제 3: 비싼 정가
|
||||
5. 솔루션: 실시간 예약 앱
|
||||
6. 기능 1: 3초 예약
|
||||
7. 기능 2: 자동 할인
|
||||
8. 기능 3: 실시간 공석
|
||||
9. Before/After 비교
|
||||
10. CTA: 바이오 링크
|
||||
|
||||
|
||||
#### 2-9. 커뮤니티 댓글/답변 (자연스러운 노출)
|
||||
**상황**: 네이버 카페 질문글
|
||||
"주말 코트 예약 어떻게 하시나요?"
|
||||
|
||||
**답변**:
|
||||
```
|
||||
저는 예전엔 전화로 했는데 너무 번거로워서
|
||||
요즘은 OO 앱 써요.
|
||||
|
||||
장점:
|
||||
- 실시간으로 빈 코트 확인
|
||||
- 가격 비교 가능
|
||||
- 자동 할인도 적용됨
|
||||
|
||||
단점:
|
||||
- 아직 모든 코트가 등록된 건 아님
|
||||
|
||||
근데 제가 다니는 주요 코트는 다 있어서 만족 중입니다.
|
||||
(광고 아니고 진짜 쓰는 사람 후기)
|
||||
```
|
||||
|
||||
**전략**: 광고처럼 보이면 역효과, 진짜 도움말처럼
|
||||
|
||||
|
||||
#### 2-10. 오픈채팅 / 밴드 공유 (바이럴 유도)
|
||||
**상황**: 테니스 동호회 단톡방
|
||||
|
||||
**메시지**:
|
||||
```
|
||||
[공유] 이번 주 토요일 예약 완료했어요~
|
||||
|
||||
다들 이 앱 써보셨어요?
|
||||
실시간으로 코트 예약 되고 할인도 받아서 좋더라고요.
|
||||
|
||||
저희 동호회 회원들 쓰면 예약 총무 일 진짜 줄어들 것 같아요 ㅎㅎ
|
||||
|
||||
링크: [...]
|
||||
(첫 예약 할인 코드: TENNIS2025)
|
||||
```
|
||||
|
||||
**전략**: 도움되는 정보 공유 → 자연스러운 바이럴
|
||||
```
|
||||
|
||||
### 3. Content Calendar (4주 계획)
|
||||
|
||||
```markdown
|
||||
## 4-Week Content Plan
|
||||
|
||||
### Week 1: Awareness (인지도)
|
||||
"우리 제품이 존재한다는 걸 알리기"
|
||||
|
||||
| 요일 | 채널 | 콘텐츠 | 목표 |
|
||||
|------|------|--------|------|
|
||||
| 월 | 유튜브 | 롱폼 영상 업로드 | 조회수 500 |
|
||||
| 화 | 블로그 | SEO 포스트 발행 | 유입 시작 |
|
||||
| 수 | 인스타 | 릴스 #1 (Before/After) | 도달 1,000 |
|
||||
| 목 | 네이버 카페 | 경험담 게시글 5개 | 댓글 10+ |
|
||||
| 금 | 유튜브 쇼츠 | 쇼츠 #1 (Problem) | 조회수 1,000 |
|
||||
| 토 | 링크드인 | 전문가 포스트 | 연결 요청 5+ |
|
||||
| 일 | 휴식 | 주간 성과 분석 | - |
|
||||
|
||||
|
||||
### Week 2: Engagement (참여 유도)
|
||||
"관심있는 사람들과 대화 시작"
|
||||
|
||||
| 요일 | 채널 | 콘텐츠 | 목표 |
|
||||
|------|------|--------|------|
|
||||
| 월 | 인스타 | 릴스 #2 (3 Tips) | 저장 50+ |
|
||||
| 화 | 트위터 | 쓰레드 발행 | 리트윗 10+ |
|
||||
| 수 | 네이버 카페 | 질문글에 답변 10개 | 신뢰 구축 |
|
||||
| 목 | 유튜브 쇼츠 | 쇼츠 #2 (Demo) | 조회수 2,000 |
|
||||
| 금 | 인스타 | 캐러셀 10장 | 저장 30+ |
|
||||
| 토 | 밴드 | 동호회에 공유 | 가입 5+ |
|
||||
| 일 | 이메일 | PDF 다운로드자 대상 | 오픈율 30% |
|
||||
|
||||
|
||||
### Week 3: Conversion (전환 유도)
|
||||
"실제 사용자 확보"
|
||||
|
||||
| 요일 | 채널 | 콘텐츠 | 목표 |
|
||||
|------|------|--------|------|
|
||||
| 월 | 전 채널 | 할인 이벤트 공지 | 가입 20+ |
|
||||
| 화 | 유튜브 쇼츠 | 쇼츠 #3 (Result) | 전환 5+ |
|
||||
| 수 | 네이버 카페 | 베타 테스터 모집 | 신청 10+ |
|
||||
| 목 | 블로그 | 사용 가이드 포스트 | 체류 3분+ |
|
||||
| 금 | 인스타 스토리 | 카운트다운 (이벤트 마감) | FOMO 유도 |
|
||||
| 토 | 오픈채팅 | 사용자 커뮤니티 개설 | 참여 10+ |
|
||||
| 일 | 휴식 | 전환율 분석 | - |
|
||||
|
||||
|
||||
### Week 4: Retention (재방문 유도)
|
||||
"기존 사용자 만족도 높이기"
|
||||
|
||||
| 요일 | 채널 | 콘텐츠 | 목표 |
|
||||
|------|------|--------|------|
|
||||
| 월 | 이메일 | 사용 팁 뉴스레터 | 재방문 유도 |
|
||||
| 화 | 유튜브 | 고급 기능 튜토리얼 | 활성 사용자 증가 |
|
||||
| 수 | 인스타 | 사용자 후기 리그램 | 사회적 증명 |
|
||||
| 목 | 네이버 카페 | 성공 사례 공유 | 입소문 |
|
||||
| 금 | 블로그 | 업데이트 소식 | SEO 유지 |
|
||||
| 토 | 커뮤니티 | 오프라인 모임 기획 | 충성도 UP |
|
||||
| 일 | 회고 | 4주 성과 정리 & Next | - |
|
||||
```
|
||||
|
||||
### 4. Content Hook Generator (감각적 첫 문장)
|
||||
|
||||
```markdown
|
||||
## Hook Formula Library
|
||||
|
||||
### Formula 1: Shocking Number (충격적 숫자)
|
||||
"매주 [시간]을 [지루한 작업]에 쓰고 있다는 걸 아시나요?"
|
||||
|
||||
**Example**:
|
||||
- "매주 30분을 코트 예약 전화에 쓰고 있다는 걸 아시나요?"
|
||||
- "한 달에 4시간을 예약 때문에 낭비하고 있습니다"
|
||||
|
||||
|
||||
### Formula 2: Relatable Pain (공감되는 고통)
|
||||
"[상황] 때문에 [부정적 감정] 느껴본 적 있으신가요?"
|
||||
|
||||
**Example**:
|
||||
- "주말 코트 예약 실패해서 허탈했던 적 있으신가요?"
|
||||
- "테니스 치고 싶은데 예약이 귀찮아서 포기한 적 있나요?"
|
||||
|
||||
|
||||
### Formula 3: Before/After (극명한 대비)
|
||||
"[Before] → [After]로 바뀐 방법"
|
||||
|
||||
**Example**:
|
||||
- "30분 전화 예약 → 3초 앱 예약으로 바뀐 방법"
|
||||
- "만석 스트레스 → 실시간 확인으로 바뀐 이유"
|
||||
|
||||
|
||||
### Formula 4: Curiosity Gap (호기심 갭)
|
||||
"[결과]를 한 비법, [일반 상식]이 아닙니다"
|
||||
|
||||
**Example**:
|
||||
- "코트 예약 10초 컷, 전화 말고 OO 쓰세요"
|
||||
- "할인받는 법, 쿠폰 말고 OO 하세요"
|
||||
|
||||
|
||||
### Formula 5: Question Hook (질문 훅)
|
||||
"왜 아직도 [구시대 방법]으로 [작업]하세요?"
|
||||
|
||||
**Example**:
|
||||
- "왜 아직도 전화로 코트 예약하세요?"
|
||||
- "왜 정가 내고 예약하세요?"
|
||||
|
||||
|
||||
### Formula 6: Social Proof (사회적 증거)
|
||||
"이미 [숫자]명이 [행동]했습니다. 당신은?"
|
||||
|
||||
**Example**:
|
||||
- "이미 500명이 앱으로 예약합니다. 당신은?"
|
||||
- "우리 동호회 회원 25명 모두 쓰는 이유"
|
||||
|
||||
|
||||
### Formula 7: FOMO (놓치기 싫은 심리)
|
||||
"[기회]를 놓치면 [손해]합니다"
|
||||
|
||||
**Example**:
|
||||
- "이 할인 놓치면 정가로 평생 예약합니다"
|
||||
- "선착순 100명만 30% 할인 (현재 73명)"
|
||||
|
||||
|
||||
### Formula 8: Contrarian (반대 의견)
|
||||
"[일반 통념]은 틀렸습니다. 진짜는 [반전]입니다"
|
||||
|
||||
**Example**:
|
||||
- "전화 예약이 더 빠르다? 틀렸습니다. 앱이 10배 빠릅니다"
|
||||
- "비싼 코트가 좋다? 아닙니다. 시간대가 중요합니다"
|
||||
```
|
||||
|
||||
### 5. Content Repurposing Checklist
|
||||
|
||||
```markdown
|
||||
## Repurposing Workflow
|
||||
|
||||
### Step 1: Create Pillar (1개 제작)
|
||||
✅ 유튜브 롱폼 1개 (10분)
|
||||
- 대본 작성
|
||||
- 촬영/편집
|
||||
- 업로드
|
||||
|
||||
### Step 2: Chop into Shorts (조각내기)
|
||||
✅ 유튜브 쇼츠 3개
|
||||
- 타임라인에서 핵심 60초 추출
|
||||
- 세로 포맷 (9:16) 재편집
|
||||
- 자막 추가
|
||||
|
||||
✅ 인스타 릴스 2개
|
||||
- 쇼츠와 동일하되 30초로 압축
|
||||
- 트렌딩 음악 추가
|
||||
- 해시태그 15개
|
||||
|
||||
### Step 3: Transform to Text (텍스트 변환)
|
||||
✅ 블로그 포스트
|
||||
- 영상 대본 → 글로 변환
|
||||
- SEO 최적화 (키워드 5개 삽입)
|
||||
- 스크린샷 5-7장 추가
|
||||
|
||||
✅ 트위터 쓰레드
|
||||
- 핵심 메시지 7개로 압축
|
||||
- 각 트윗 280자 이내
|
||||
- 첫 트윗에 훅 집중
|
||||
|
||||
✅ 링크드인 포스트
|
||||
- 전문가 톤으로 재작성
|
||||
- 인사이트 중심
|
||||
- 1,000-1,500자
|
||||
|
||||
### Step 4: Design Visuals (비주얼 제작)
|
||||
✅ 인스타 캐러셀 10장
|
||||
- 캔바 템플릿 활용
|
||||
- 핵심 메시지 1장 1문장
|
||||
- 브랜드 컬러 일관성
|
||||
|
||||
✅ PDF 다운로드
|
||||
- 체크리스트/가이드 형식
|
||||
- 5-10페이지
|
||||
- 마지막 페이지 CTA
|
||||
|
||||
### Step 5: Community Seeding (커뮤니티 배포)
|
||||
✅ 네이버 카페 게시글
|
||||
- 광고 느낌 제거
|
||||
- 진짜 경험담처럼
|
||||
- 5-10개 카페
|
||||
|
||||
✅ 커뮤니티 댓글
|
||||
- 자연스럽게 언급
|
||||
- 도움 되는 정보 공유
|
||||
- 링크는 마지막에만
|
||||
|
||||
### Total Output: 1 Pillar → 20+ Content Pieces
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Files
|
||||
|
||||
### 생성될 파일들:
|
||||
|
||||
1. **`docs/market/core-message.md`**
|
||||
- ONE 핵심 메시지
|
||||
- Before/After/Bridge
|
||||
- 고객 Pain Point 연결
|
||||
|
||||
2. **`docs/market/content-pyramid.md`**
|
||||
- Pillar Content 기획
|
||||
- 10가지 파생 콘텐츠
|
||||
- 포맷별 제작 가이드
|
||||
|
||||
3. **`docs/market/content-calendar.md`**
|
||||
- 4주 콘텐츠 캘린더
|
||||
- 채널별 발행 스케줄
|
||||
- 목표 지표
|
||||
|
||||
4. **`docs/market/hook-library.md`**
|
||||
- 8가지 훅 공식
|
||||
- 제품별 예시
|
||||
- A/B 테스트용
|
||||
|
||||
---
|
||||
|
||||
## Integration Points
|
||||
|
||||
### 다른 명령어와의 연계:
|
||||
|
||||
- **From `/market.customer`**: 타겟 채널 → 콘텐츠 포맷 결정
|
||||
- **From `/appkit.sales`**: 핵심 메시지 → 콘텐츠 주제
|
||||
- **To `/market.channel`**: 콘텐츠 → 채널별 최적화
|
||||
- **To `/market.communicate`**: 콘텐츠 → 바이럴 전략
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: B2C 앱
|
||||
```bash
|
||||
$ /market.contents
|
||||
|
||||
🎯 Core Message Extracted
|
||||
|
||||
ONE Message:
|
||||
"매주 30분 걸리던 코트 예약, 3초로 단축"
|
||||
|
||||
Content Pyramid Generated:
|
||||
|
||||
1 Pillar:
|
||||
✅ 유튜브 롱폼 (10분) - "예약 시간 90% 줄인 법"
|
||||
|
||||
10 Derivatives:
|
||||
✅ 유튜브 쇼츠 3개
|
||||
✅ 인스타 릴스 2개
|
||||
✅ 블로그 포스트 1개
|
||||
✅ 트위터 쓰레드 1개
|
||||
✅ 링크드인 포스트 1개
|
||||
✅ 네이버 카페 글 1개
|
||||
✅ 인스타 캐러셀 1개
|
||||
|
||||
4-Week Calendar:
|
||||
Week 1: Awareness (인지도)
|
||||
Week 2: Engagement (참여)
|
||||
Week 3: Conversion (전환)
|
||||
Week 4: Retention (재방문)
|
||||
|
||||
✅ Generated content-pyramid.md
|
||||
✅ Generated content-calendar.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
### Content Efficiency:
|
||||
|
||||
1. **One to Many**: 1개 제작 → 10개 배포
|
||||
2. **Core Message First**: 메시지 먼저, 포맷은 나중
|
||||
3. **Platform Native**: 각 채널의 언어로 번역
|
||||
4. **Hook Obsession**: 첫 3초가 전부
|
||||
5. **Batch Production**: 한 번에 여러 개 제작
|
||||
|
||||
### Content Anti-Patterns:
|
||||
|
||||
❌ **Spray and Pray**: 일관성 없이 막 올리기
|
||||
❌ **Perfectionism**: 완벽한 1개보다 괜찮은 10개
|
||||
❌ **Platform Blindness**: 유튜브 영상을 인스타에 그대로
|
||||
❌ **Message Dilution**: 채널마다 다른 메시지
|
||||
❌ **No Repurposing**: 매번 새로 만들기
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### 이 명령어 실행 후:
|
||||
|
||||
**📍 다음 단계: `/market.channel`** (채널별 최적화)
|
||||
- 만든 콘텐츠를 각 채널에 맞게 최적화
|
||||
- 플랫폼별 알고리즘 이해
|
||||
- 성과 측정 및 개선
|
||||
|
||||
---
|
||||
|
||||
## Version
|
||||
|
||||
- **Version**: 1.0.0
|
||||
- **Created**: 2025-11-20
|
||||
- **Philosophy**: "Create once, distribute everywhere. But make it native to each platform."
|
||||
434
.claude/commands/market.customer.md
Normal file
434
.claude/commands/market.customer.md
Normal file
@@ -0,0 +1,434 @@
|
||||
# market.customer
|
||||
|
||||
**MVP에 맞는 타겟 고객 세분화 및 채널 추천 명령어**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**This is the first step of the 4C Marketing Framework**:
|
||||
|
||||
```
|
||||
저비용 마케팅 4C:
|
||||
1. /market.customer → 고객 세분화 & 채널 추천 (누구에게, 어디서?) ← YOU ARE HERE
|
||||
2. /market.contents → 콘텐츠 전략 & 재활용 (무엇을 만들까?)
|
||||
3. /market.channel → 채널별 최적화 전략 (어떻게 최적화할까?)
|
||||
4. /market.communicate → 바이럴 & 커뮤니티 전략 (어떻게 퍼뜨릴까?)
|
||||
```
|
||||
|
||||
## Purpose
|
||||
|
||||
MVP 제품의 특성을 분석하여 **가장 효과적인 타겟 고객 세그먼트**를 찾고,
|
||||
그들이 실제로 있는 **채널**을 추천합니다.
|
||||
|
||||
**핵심 질문**: "누가 가장 먼저 우리 제품을 써줄까? 그들은 지금 어디 있을까?"
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- `/appkit.mvp`로 MVP 범위를 정의한 후
|
||||
- 제품 출시 전 마케팅 전략 수립 시
|
||||
- 광고비 없이 초기 고객을 확보해야 할 때
|
||||
- 채널 선택이 불명확할 때
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/market.customer
|
||||
/market.customer "테니스 코트 예약 앱"
|
||||
/market.customer "직장인 대상 SaaS 툴"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What I'll Do
|
||||
|
||||
### 1. 제품 맥락 분석
|
||||
|
||||
```markdown
|
||||
## Product Context Analysis
|
||||
|
||||
### Input Sources
|
||||
- `docs/appkit/overview.md` → 서비스 본질 파악
|
||||
- `docs/appkit/customer-persona.md` → 기존 페르소나 활용
|
||||
- `docs/appkit/mvp-scope.md` → MVP 핵심 가치 확인
|
||||
|
||||
### Key Questions
|
||||
- 이 제품은 무엇을 해결하는가?
|
||||
- 가장 급한 문제를 가진 사람은 누구인가?
|
||||
- 돈을 낼 만한 가치가 있는 사람은?
|
||||
- 입소문을 낼 만한 사람은?
|
||||
```
|
||||
|
||||
### 2. 고객 세그먼트 우선순위화
|
||||
|
||||
```markdown
|
||||
## Customer Segmentation Matrix
|
||||
|
||||
### Early Adopters (최우선 타겟)
|
||||
"제품이 완벽하지 않아도 먼저 써줄 사람들"
|
||||
|
||||
#### Segment 1: 테니스 동호회 운영진 (Primary)
|
||||
**Why First?**
|
||||
- Pain Point 강도: ⭐⭐⭐⭐⭐ (매주 예약 전화 30통)
|
||||
- 구매력: ⭐⭐⭐⭐ (회비로 결제 가능)
|
||||
- 입소문 파급력: ⭐⭐⭐⭐⭐ (회원 20-50명에게 즉시 전파)
|
||||
- 접근 용이성: ⭐⭐⭐⭐ (네이버 카페, 밴드에 집중)
|
||||
|
||||
**Demographics**
|
||||
- 나이: 35-55세
|
||||
- 직업: 회사원, 자영업
|
||||
- 소득: 중상위
|
||||
- 지역: 수도권
|
||||
|
||||
**Psychographics**
|
||||
- 가치관: "우리 회원들 편하게 해주고 싶다"
|
||||
- 관심사: 동호회 활성화, 효율적 운영
|
||||
- 정보 습득: 네이버 카페, 밴드, 카톡 단톡방
|
||||
- 구매 결정: 실용성 > 가격 (회원들이 좋아하면 OK)
|
||||
|
||||
**Where Are They?**
|
||||
1. 네이버 카페: "테니스 동호회", "XX지역 테니스"
|
||||
2. 밴드: 지역별 테니스 밴드
|
||||
3. 카카오톡: 동호회 단톡방 (접근 어려움)
|
||||
4. 오프라인: 주말 아침 코트장
|
||||
|
||||
**First Touch Strategy**
|
||||
→ 네이버 카페 "운영진 고민" 게시판에 진짜 경험담 작성
|
||||
→ "저희 동호회 예약 관리 이렇게 해결했어요" (광고 X)
|
||||
|
||||
|
||||
#### Segment 2: 직장 내 테니스 동아리 간사 (Secondary)
|
||||
**Why Second?**
|
||||
- Pain Point: ⭐⭐⭐⭐ (분기별 예약 업무 스트레스)
|
||||
- 구매력: ⭐⭐⭐ (동아리 예산 있음)
|
||||
- 입소문: ⭐⭐⭐ (다른 직장 동아리로 전파 가능)
|
||||
- 접근: ⭐⭐⭐ (링크드인, 직장인 커뮤니티)
|
||||
|
||||
**Where Are They?**
|
||||
1. 블라인드: "직장 생활" 게시판
|
||||
2. 링크드인: 직장인 그룹
|
||||
3. 사내 게시판: 접근 어려움
|
||||
4. 오픈 채팅방: "XX기업 테니스"
|
||||
|
||||
|
||||
#### Segment 3: 개인 열성 플레이어 (Tertiary)
|
||||
**Why Third?**
|
||||
- Pain Point: ⭐⭐⭐ (개인 예약 번거로움)
|
||||
- 구매력: ⭐⭐⭐⭐ (개인 결제)
|
||||
- 입소문: ⭐⭐ (개인적 추천)
|
||||
- 접근: ⭐⭐⭐⭐⭐ (인스타, 유튜브)
|
||||
|
||||
**Where Are They?**
|
||||
1. 인스타그램: #테니스 #테린이 #테니스레슨
|
||||
2. 유튜브: 테니스 레슨 영상 댓글란
|
||||
3. 테니스용품 쇼핑몰: 커뮤니티 게시판
|
||||
```
|
||||
|
||||
### 3. Channel Recommendation Matrix
|
||||
|
||||
```markdown
|
||||
## Channel Priority by Customer Segment
|
||||
|
||||
### Tier 1: Immediate Action (이번 주부터)
|
||||
"Early Adopters가 있는 곳"
|
||||
|
||||
| Channel | Segment | Cost | Effort | Expected Result |
|
||||
|---------|---------|------|--------|-----------------|
|
||||
| 네이버 카페 | 동호회 운영진 | 무료 | 중 | 첫 10명 확보 |
|
||||
| 밴드 | 동호회 | 무료 | 중 | 첫 단체 고객 |
|
||||
| 블라인드 | 직장 동아리 | 무료 | 하 | 피드백 수집 |
|
||||
|
||||
**Action Plan (Week 1-2)**
|
||||
1. 네이버 카페 10개 가입
|
||||
- "서울 테니스 동호회"
|
||||
- "경기 테니스 모임"
|
||||
- "주말 테니스"
|
||||
2. 운영진 고민 게시판에 진짜 경험담 작성
|
||||
3. DM으로 베타 테스터 모집 (광고 아님)
|
||||
|
||||
|
||||
### Tier 2: Medium-term Growth (2-4주)
|
||||
"인지도 확산"
|
||||
|
||||
| Channel | Segment | Cost | Effort | Expected Result |
|
||||
|---------|---------|------|--------|-----------------|
|
||||
| 인스타그램 | 개인 플레이어 | 저 | 중 | 브랜드 인지도 |
|
||||
| 유튜브 쇼츠 | 일반 대중 | 저 | 고 | 자연 유입 |
|
||||
| 블로그 SEO | 검색 유입 | 무료 | 중 | 장기 자산 |
|
||||
|
||||
**Content Ideas**
|
||||
- 인스타 릴스: "테니스 코트 예약 꿀팁"
|
||||
- 유튜브 쇼츠: "동호회 총무가 알려주는 예약 비법"
|
||||
- 블로그: "서울 테니스 코트 예약 가이드"
|
||||
|
||||
|
||||
### Tier 3: Scale (4주+)
|
||||
"매스 마케팅 준비"
|
||||
|
||||
| Channel | Segment | Cost | Effort | Expected Result |
|
||||
|---------|---------|------|--------|-----------------|
|
||||
| 네이버 광고 | 검색 유입 | 중 | 하 | 빠른 확장 |
|
||||
| 인플루언서 | 대중 | 중-고 | 중 | 바이럴 |
|
||||
| 제휴 (코트) | 장소 기반 | 무료 | 고 | Win-win |
|
||||
|
||||
**Note**: Tier 3는 Tier 1-2 검증 후 진행
|
||||
```
|
||||
|
||||
### 4. Persona-Channel-Message Mapping
|
||||
|
||||
```markdown
|
||||
## Integrated Marketing Map
|
||||
|
||||
### Early Adopter Journey
|
||||
|
||||
#### Persona: 김회장 (45세, 테니스 동호회 회장)
|
||||
|
||||
**현재 상황**
|
||||
- 매주 토요일 아침 예약을 위해 5개 코트에 전화
|
||||
- 회원 25명 일정 조율이 가장 큰 스트레스
|
||||
- 네이버 카페에서 "이번 주 예약 완료" 공지 작성
|
||||
|
||||
**Where**: 네이버 카페 "서울 테니스 동호회" (회원 3,500명)
|
||||
|
||||
**Message Hook**:
|
||||
"동호회 회장님들, 매주 코트 예약 전화 30통 거는 거 지치지 않으세요?"
|
||||
|
||||
**Offer**:
|
||||
"저희 동호회는 이 앱으로 예약 관리 10분으로 줄였습니다"
|
||||
→ 무료 베타 테스터 모집 (선착순 10개 동호회)
|
||||
|
||||
**Conversion Path**:
|
||||
1. 카페 게시글 작성 (진짜 경험담)
|
||||
2. 댓글로 문의 → DM으로 안내
|
||||
3. 카톡 오픈채팅방 초대
|
||||
4. 사용 가이드 제공
|
||||
5. 후기 작성 부탁 (인센티브: 1개월 무료)
|
||||
|
||||
|
||||
#### Persona: 박간사 (32세, 직장 테니스 동아리 간사)
|
||||
|
||||
**Where**: 블라인드 "직장 생활" 게시판
|
||||
|
||||
**Message Hook**:
|
||||
"테니스 동아리 간사 맡았다가 예약 업무로 퇴근 늦어본 적 있으신가요?"
|
||||
|
||||
**Offer**:
|
||||
"3분 만에 분기 예약 완료하는 법"
|
||||
→ 체크리스트 PDF 다운로드 (이메일 수집)
|
||||
|
||||
**Conversion Path**:
|
||||
1. 블라인드 게시글
|
||||
2. PDF 다운로드 (랜딩 페이지)
|
||||
3. 이메일로 앱 소개
|
||||
4. 7일 무료 체험
|
||||
```
|
||||
|
||||
### 5. Channel Testing Framework
|
||||
|
||||
```markdown
|
||||
## Channel Validation Checklist
|
||||
|
||||
### Week 1-2: Hypothesis Testing
|
||||
각 채널에서 최소 실험 진행
|
||||
|
||||
#### Test 1: 네이버 카페
|
||||
**Hypothesis**: 동호회 운영진이 실제 사용할까?
|
||||
|
||||
**Experiment**:
|
||||
- 5개 카페에 경험담 게시
|
||||
- 베타 테스터 10명 모집 목표
|
||||
|
||||
**Success Metrics**:
|
||||
- 게시글 조회수: 500+
|
||||
- DM 문의: 5+
|
||||
- 실제 가입: 3+
|
||||
|
||||
**Pivot Signal**:
|
||||
- 조회수 < 100: 메시지 변경
|
||||
- 문의 < 2: 채널 변경
|
||||
|
||||
|
||||
#### Test 2: 블라인드
|
||||
**Hypothesis**: 직장인들이 관심 가질까?
|
||||
|
||||
**Experiment**:
|
||||
- "직장 생활" 게시판 2건 작성
|
||||
- PDF 다운로드 20건 목표
|
||||
|
||||
**Success Metrics**:
|
||||
- 공감 수: 10+
|
||||
- 댓글: 5+
|
||||
- PDF 다운로드: 20+
|
||||
|
||||
**Pivot Signal**:
|
||||
- 공감 < 5: 타겟 불일치
|
||||
- 다운로드 < 5: 오퍼 변경
|
||||
|
||||
|
||||
### Week 3-4: Double Down
|
||||
검증된 채널에 집중
|
||||
|
||||
**If 네이버 카페 wins**:
|
||||
→ 10개 → 30개 카페로 확대
|
||||
→ 성공 사례 스토리텔링
|
||||
|
||||
**If 블라인드 wins**:
|
||||
→ 다른 직장인 커뮤니티 확대 (당근 동네생활, 에브리타임)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Files
|
||||
|
||||
### 생성될 파일들:
|
||||
|
||||
1. **`docs/market/customer-segments.md`**
|
||||
- Early Adopter 우선순위
|
||||
- 세그먼트별 특성 및 Pain Point
|
||||
- Where they are (구체적 채널)
|
||||
|
||||
2. **`docs/market/channel-recommendations.md`**
|
||||
- Tier 1/2/3 채널 우선순위
|
||||
- 채널별 비용/노력/기대효과
|
||||
- 주차별 실행 계획
|
||||
|
||||
3. **`docs/market/persona-channel-map.md`**
|
||||
- 페르소나별 고객 여정
|
||||
- 채널-메시지 매칭
|
||||
- 전환 경로 설계
|
||||
|
||||
---
|
||||
|
||||
## Integration Points
|
||||
|
||||
### 다른 명령어와의 연계:
|
||||
|
||||
- **From `/appkit.customer`**: Primary Persona 활용
|
||||
- **From `/appkit.mvp`**: MVP 핵심 가치 → 메시지 훅
|
||||
- **To `/market.contents`**: 채널별 콘텐츠 아이디어
|
||||
- **To `/market.channel`**: 선택된 채널의 최적화 전략
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: B2C 모바일 앱
|
||||
```bash
|
||||
$ /market.customer "테니스 코트 예약 앱"
|
||||
|
||||
🎯 Customer Segmentation Complete
|
||||
|
||||
Early Adopters (우선순위):
|
||||
1. 테니스 동호회 운영진 (Primary)
|
||||
→ 네이버 카페, 밴드
|
||||
2. 직장 테니스 동아리 간사 (Secondary)
|
||||
→ 블라인드, 링크드인
|
||||
3. 개인 열성 플레이어 (Tertiary)
|
||||
→ 인스타그램, 유튜브
|
||||
|
||||
Tier 1 Channels (이번 주):
|
||||
✅ 네이버 카페 10개
|
||||
✅ 밴드 5개
|
||||
✅ 블라인드 "직장생활"
|
||||
|
||||
Week 1-2 Goal:
|
||||
- 첫 10명 Early Adopters 확보
|
||||
- 채널별 A/B 테스트
|
||||
- 검증된 채널에 집중
|
||||
|
||||
✅ Generated customer-segments.md
|
||||
✅ Generated channel-recommendations.md
|
||||
✅ Generated persona-channel-map.md
|
||||
```
|
||||
|
||||
### Example 2: B2B SaaS 툴
|
||||
```bash
|
||||
$ /market.customer "직장인 일정 관리 SaaS"
|
||||
|
||||
🎯 Customer Segmentation Complete
|
||||
|
||||
Early Adopters:
|
||||
1. 스타트업 팀장 (5-10명 팀)
|
||||
→ 링크드인, 스타트업 커뮤니티
|
||||
2. 프리랜서 PM/기획자
|
||||
→ 브런치, 퍼블리
|
||||
|
||||
Tier 1 Channels:
|
||||
✅ 링크드인 (전문가 네트워킹)
|
||||
✅ 디스콰이엇 (스타트업)
|
||||
✅ 브런치 (콘텐츠 마케팅)
|
||||
|
||||
Week 1-2 Goal:
|
||||
- 베타 고객 5팀 확보
|
||||
- 사용 사례 확보
|
||||
- 추천 바이럴 유도
|
||||
|
||||
✅ Generated files
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
### Customer-First Marketing:
|
||||
|
||||
1. **Segment Before Scale**: 대중보다 틈새 시장 먼저
|
||||
2. **Go Where They Are**: 새 채널 만들지 말고 기존 공간에 들어가기
|
||||
3. **Earn Trust First**: 광고하지 말고 진짜 가치 제공
|
||||
4. **Manual Initially**: 자동화 전에 직접 대화
|
||||
5. **Quality > Quantity**: 1000명보다 진짜 좋아하는 10명
|
||||
|
||||
### Channel Anti-Patterns:
|
||||
|
||||
❌ **Spray and Pray**: 모든 채널 동시 시도
|
||||
❌ **Vanity Metrics**: 팔로워 수에 집착
|
||||
❌ **Ad Dependence**: 광고비 없으면 고객 못 모으는 구조
|
||||
❌ **Broadcasting**: 일방적 홍보
|
||||
❌ **Impatience**: 첫 주에 결과 기대
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
|
||||
### 성공적인 Early Adopter 확보를 위해:
|
||||
|
||||
1. **Micro-Segment**: 작고 구체적인 세그먼트부터
|
||||
- "테니스 좋아하는 사람" ❌
|
||||
- "주말 아침 테니스 동호회 운영진" ✅
|
||||
|
||||
2. **Real Pain Only**: 진짜 아픈 문제만 타겟
|
||||
- "있으면 좋을 것 같은데" ❌
|
||||
- "이거 없으면 진짜 힘들어" ✅
|
||||
|
||||
3. **Community First**: 개인보다 커뮤니티
|
||||
- 개인 1명 전환 < 동호회 회장 1명 전환 (20명 동반)
|
||||
|
||||
4. **Earn Your Way In**: 스팸하지 말고 신뢰 쌓기
|
||||
- "우리 제품 써주세요" ❌
|
||||
- "제가 이런 고민 해결했는데 도움 될까요?" ✅
|
||||
|
||||
5. **Test Fast, Pivot Faster**: 2주 안에 검증
|
||||
- 반응 없으면 과감히 채널/메시지 변경
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### 이 명령어 실행 후:
|
||||
|
||||
**📍 다음 단계: `/market.contents`** (콘텐츠 전략)
|
||||
- 타겟 채널이 정해졌으니 어떤 콘텐츠를 만들지 기획
|
||||
- 하나의 핵심 메시지를 10가지 포맷으로 재활용
|
||||
- 채널별 최적 콘텐츠 형식 제안
|
||||
|
||||
---
|
||||
|
||||
## Version
|
||||
|
||||
- **Version**: 1.0.0
|
||||
- **Created**: 2025-11-20
|
||||
- **Philosophy**: "Find the smallest viable audience that loves you, not the largest possible audience that's indifferent."
|
||||
195
.claude/skills/README.md
Normal file
195
.claude/skills/README.md
Normal file
@@ -0,0 +1,195 @@
|
||||
# AI_잡돌이 Skills Overview
|
||||
|
||||
이 디렉토리는 프로젝트 전용 AI 스킬들을 포함합니다. 각 스킬은 특정 콘텐츠 제작 작업에 최적화되어 있습니다.
|
||||
|
||||
## 📚 Available Skills
|
||||
|
||||
### 1️⃣ YouTube Narration Coach
|
||||
**디렉토리**: `youtube-narration-coach/`
|
||||
**목적**: 유튜브 나레이션 대본 분석 및 개선
|
||||
|
||||
**주요 기능**:
|
||||
- 7단계 프레임워크 기반 분석 (HOOK→PROBLEM→AGITATE→SOLUTION→VALUE→PROOF→CTA)
|
||||
- 한국 시청자 심리 트리거 체크
|
||||
- 섹션별 체크리스트 제공
|
||||
- 구체화 질문을 통한 코칭 방식
|
||||
- 완주율 최적화 피드백
|
||||
|
||||
**사용 방법**:
|
||||
```
|
||||
"이 대본 분석해줘"
|
||||
"유튜브 스크립트 피드백 필요해"
|
||||
"프레임워크 적용해서 봐줘"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ Landing Page Copywriter
|
||||
**디렉토리**: `landing-page-copywriter/`
|
||||
**목적**: 고전환율 랜딩페이지 카피 생성
|
||||
|
||||
**주요 기능**:
|
||||
- PAS/AIDA/StoryBrand 프레임워크 적용
|
||||
- Hero, Problem, Solution, CTA 섹션 생성
|
||||
- A/B 테스트 제안
|
||||
- 전환 최적화 팁
|
||||
- 사회적 증거 구조화
|
||||
|
||||
**사용 방법**:
|
||||
```
|
||||
"이 제품으로 랜딩페이지 카피 써줘"
|
||||
"PAS 프레임워크로 세일즈 페이지 만들어줘"
|
||||
"CTA 최적화해줘"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ PPT Slide Extractor ✨
|
||||
**디렉토리**: `ppt-slide-extractor/`
|
||||
**목적**: 유튜브 나레이션 대본에서 영상 송출용 PPT 장표 추출
|
||||
|
||||
**핵심 컨셉**:
|
||||
- 유튜브 시청자가 나레이션과 함께 보는 시각 자료
|
||||
- 복잡한 설명을 단순화해서 전달
|
||||
- 오프라인 발표 자료 아님 (발표자 노트, 제스처 가이드 X)
|
||||
|
||||
**주요 기능**:
|
||||
- 6가지 장표 타입 자동 분류 (Title/Problem/Process/Comparison/Data/CTA)
|
||||
- 핵심 키워드 추출 (5개 이하)
|
||||
- 이미지 제안 (간단히 1-2줄)
|
||||
- 타임스탬프 연동
|
||||
|
||||
**핵심 원칙**:
|
||||
- **1장 = 1메시지**: 한 슬라이드에 하나의 핵심만
|
||||
- **3초 룰**: 시청자가 3초 안에 파악 가능
|
||||
- **Less is More**: 텍스트 최소화, 키워드 중심
|
||||
- **나레이션 보조**: 슬라이드는 말하는 내용의 시각적 보조
|
||||
|
||||
**장표 타입**:
|
||||
1. **타이틀**: 영상 시작, 섹션 전환
|
||||
2. **문제 제시**: 고통 포인트 시각화
|
||||
3. **프로세스**: 단계별 워크플로우 (1→2→3→4)
|
||||
4. **비교**: Before/After, A vs B
|
||||
5. **데이터**: 숫자, 통계, 사회적 증거
|
||||
6. **CTA**: 행동 유도 (3단계 깔때기)
|
||||
|
||||
**출력 구조** (심플):
|
||||
```
|
||||
SLIDE #N: [타입]
|
||||
├─ ⏰ [0:00-0:15]
|
||||
├─ 제목: [5-8단어]
|
||||
├─ 내용: [키워드 3-5개]
|
||||
└─ 이미지: [간단한 설명 1-2줄]
|
||||
```
|
||||
|
||||
**사용 방법**:
|
||||
```
|
||||
"이 나레이션으로 PPT 만들어줘"
|
||||
"대본에서 장표 뽑아줘"
|
||||
"영상용 슬라이드 필요해"
|
||||
"유튜브 PPT 추출해줘"
|
||||
```
|
||||
|
||||
**예상 장표 수**:
|
||||
- 10분 영상: 8-12장
|
||||
- 15분 영상: 12-18장
|
||||
- 평균: 1-1.5분당 1장
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Skills Usage Workflow
|
||||
|
||||
### Workflow 1: 대본 작성 → 장표 추출
|
||||
```
|
||||
1. YouTube Narration Coach로 대본 작성/개선
|
||||
↓
|
||||
2. 프레임워크 기반 완성도 검증
|
||||
↓
|
||||
3. PPT Slide Extractor로 장표 자동 추출
|
||||
↓
|
||||
4. 디자이너에게 전달 or 직접 PPT 제작
|
||||
```
|
||||
|
||||
### Workflow 2: 제품 → 랜딩페이지 → 발표 자료
|
||||
```
|
||||
1. Landing Page Copywriter로 제품 카피 작성
|
||||
↓
|
||||
2. YouTube Narration Coach로 발표 대본 변환
|
||||
↓
|
||||
3. PPT Slide Extractor로 피치덱 생성
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📁 Directory Structure
|
||||
|
||||
```
|
||||
.claude/skills/
|
||||
├── README.md (이 파일)
|
||||
├── youtube-narration-coach/
|
||||
│ └── SKILL.md (스킬 정의)
|
||||
├── landing-page-copywriter/
|
||||
│ └── SKILL.md
|
||||
└── ppt-slide-extractor/
|
||||
└── SKILL.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔧 How Skills Work
|
||||
|
||||
### Activation
|
||||
스킬은 다음 상황에서 자동 활성화됩니다:
|
||||
1. **키워드 감지**: 특정 단어/구문 감지 시
|
||||
2. **파일 확장자**: `.md`, `.txt` 대본 파일 제공 시
|
||||
3. **명시적 요청**: "~해줘" 형태의 직접 요청
|
||||
|
||||
### Coordination
|
||||
여러 스킬이 동시에 필요한 경우, Claude가 자동으로 조율합니다:
|
||||
- **순차 실행**: 대본 작성 → 분석 → 장표 추출
|
||||
- **병렬 실행**: 랜딩페이지 카피 + PPT 슬라이드 동시 생성
|
||||
- **반복 개선**: 피드백 → 수정 → 재추출
|
||||
|
||||
---
|
||||
|
||||
## 💡 Best Practices
|
||||
|
||||
### For YouTube Narration Coach
|
||||
- 대본 초안 단계부터 활용
|
||||
- 섹션별 순차 개선 (한 번에 다 고치기 X)
|
||||
- 프레임워크 질문에 구체적으로 답변
|
||||
|
||||
### For Landing Page Copywriter
|
||||
- 제품/서비스 정보 구체적으로 제공
|
||||
- 타겟 청중 명확히 정의
|
||||
- A/B 테스트 제안 적극 활용
|
||||
|
||||
### For PPT Slide Extractor
|
||||
- 대본 완성도 70% 이상일 때 사용
|
||||
- 장표 스타일 미리 선택 (미니멀/정보형/혼합)
|
||||
- 추출 후 특정 슬라이드만 수정 가능
|
||||
- 디자인 가이드라인을 디자이너에게 전달
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Coming Soon
|
||||
|
||||
### Planned Skills
|
||||
- **Video Script Analyzer**: 영상 편집 타임라인 생성
|
||||
- **Thumbnail Copy Generator**: 썸네일 텍스트 추출
|
||||
- **SEO Optimizer**: 제목/태그/설명 최적화
|
||||
- **A/B Test Generator**: 다양한 버전 자동 생성
|
||||
|
||||
---
|
||||
|
||||
## 📞 Feedback
|
||||
|
||||
스킬 개선 제안이나 버그 리포트:
|
||||
- 프로젝트 이슈 트래커 사용
|
||||
- 또는 CLAUDE.md에 피드백 섹션 추가
|
||||
|
||||
---
|
||||
|
||||
**Last Updated**: 2025-11-08
|
||||
**Total Skills**: 3
|
||||
**Latest Addition**: PPT Slide Extractor v1.0
|
||||
554
.claude/skills/beginner-friendly-script-improver/skill.md
Normal file
554
.claude/skills/beginner-friendly-script-improver/skill.md
Normal file
@@ -0,0 +1,554 @@
|
||||
---
|
||||
name: beginner-friendly-script-improver
|
||||
description: 비개발자 대상 대본 개선 전문가. 기술 용어 → 쉬운 설명 변환, 추상 개념 → 구체적 비유, 전문 용어 첫 등장 시 괄호 설명 자동 추가. 이해도 95% 유지하며 접근성 극대화.
|
||||
---
|
||||
|
||||
# Beginner-Friendly Script Improver
|
||||
|
||||
비개발자도 쉽게 이해할 수 있도록 기술/개발 관련 대본을 개선하는 전문가입니다.
|
||||
|
||||
## Core Principles (핵심 원칙)
|
||||
|
||||
### 🎯 Mission
|
||||
**"개발 지식 제로인 사람도 95% 이해할 수 있게"**
|
||||
|
||||
- 기술 용어 → 일상 언어
|
||||
- 추상 개념 → 구체적 비유
|
||||
- 전문 용어 → 즉시 설명
|
||||
- 복잡한 개념 → 단계적 설명
|
||||
|
||||
### ✅ DO (반드시 해야 할 것)
|
||||
1. **첫 등장 용어는 즉시 설명**
|
||||
- "LLM" → "LLM(ChatGPT, Claude 같은 대규모 AI 언어 모델)"
|
||||
- "API" → "API(프로그램들끼리 대화하는 통로)"
|
||||
|
||||
2. **비유로 설명**
|
||||
- "로컬 설치" → "내 집에 요리사 고용하는 것"
|
||||
- "웹 UI" → "식당에 가서 주문하는 것"
|
||||
|
||||
3. **구체적 예시 추가**
|
||||
- "Skills" → "마치 엑셀 함수처럼, 입력 넣으면 결과가 나옴"
|
||||
|
||||
4. **비교표로 정리**
|
||||
- 복잡한 차이점은 표로 시각화
|
||||
|
||||
### ❌ DON'T (절대 하지 말 것)
|
||||
1. **전문 용어 나열**
|
||||
- ❌ "LLM을 로컬에 설치해서 API로 연동"
|
||||
- ✅ "AI를 내 컴퓨터에 설치해서 사용"
|
||||
|
||||
2. **설명 없는 영문 약어**
|
||||
- ❌ "MCP를 통해"
|
||||
- ✅ "MCP(AI에게 외부 정보를 연결해주는 플러그인)를 통해"
|
||||
|
||||
3. **당연하다고 가정**
|
||||
- ❌ "VS Code에서" (설명 없이)
|
||||
- ✅ "VS Code(코드 편집 프로그램, 무료)에서"
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Analysis Framework (분석 체계)
|
||||
|
||||
대본을 분석할 때 다음 항목을 체크:
|
||||
|
||||
### 1️⃣ 전문 용어 스캔
|
||||
|
||||
**체크리스트**:
|
||||
- [ ] 기술 용어 (LLM, API, JSON, IDE, CLI, Git 등)
|
||||
- [ ] 개발 도구 (VS Code, Node.js, npm 등)
|
||||
- [ ] 프로그래밍 개념 (함수, 변수, 클래스, 객체 등)
|
||||
- [ ] 비즈니스 용어 (SaaS, MVP, PMF, KPI 등)
|
||||
- [ ] 프레임워크/라이브러리 이름
|
||||
- [ ] 영문 약어 (모든 약어)
|
||||
|
||||
**분석 질문**:
|
||||
1. "이 용어가 처음 등장하는가?"
|
||||
2. "비개발자가 이 용어를 알고 있을까?"
|
||||
3. "설명 없이 넘어가도 이해 가능한가?"
|
||||
|
||||
### 2️⃣ 추상 개념 스캔
|
||||
|
||||
**체크리스트**:
|
||||
- [ ] 로컬 vs 클라우드
|
||||
- [ ] 프론트엔드 vs 백엔드
|
||||
- [ ] 동기 vs 비동기
|
||||
- [ ] 객체지향, 함수형 프로그래밍
|
||||
- [ ] 워크플로우, 파이프라인
|
||||
- [ ] 아키텍처, 인프라
|
||||
|
||||
**개선 방법**:
|
||||
- 일상 비유로 변환
|
||||
- 시각적 비교 (표, 도식)
|
||||
- 단계별 분해
|
||||
|
||||
### 3️⃣ 컨텍스트 부족 스캔
|
||||
|
||||
**체크리스트**:
|
||||
- [ ] "이걸 왜 해야 하는가?" 설명 필요
|
||||
- [ ] "이게 뭔가?" 정의 필요
|
||||
- [ ] "어떻게 생긴 건가?" 시각적 설명 필요
|
||||
- [ ] "실제로는 어떤 건가?" 예시 필요
|
||||
|
||||
---
|
||||
|
||||
## 📚 용어 변환 사전
|
||||
|
||||
### 개발 도구 & 환경
|
||||
|
||||
| 전문 용어 | 쉬운 설명 | 비유/예시 |
|
||||
|----------|----------|----------|
|
||||
| LLM | ChatGPT, Claude 같은 대규모 AI 언어 모델 | - |
|
||||
| 로컬 설치 | 내 컴퓨터에 직접 설치 | 내 집에 요리사 고용 |
|
||||
| 웹 UI | 웹사이트 화면 | 식당에 가서 주문 |
|
||||
| API | 프로그램들끼리 대화하는 통로 | 전화선 |
|
||||
| VS Code | 코드 편집 프로그램 (무료) | 메모장의 강력 버전 |
|
||||
| IDE | 개발 도구 프로그램 | - |
|
||||
| CLI | 명령어 입력 창 | - |
|
||||
| JSON | 데이터를 정리해서 저장하는 텍스트 형식 | 엑셀을 텍스트로 |
|
||||
| Git | 버전 관리 시스템 | 문서 변경 이력 추적 |
|
||||
| Node.js | JavaScript 실행 프로그램 | - |
|
||||
|
||||
### 프로그래밍 개념
|
||||
|
||||
| 전문 용어 | 쉬운 설명 | 비유/예시 |
|
||||
|----------|----------|----------|
|
||||
| 함수 | 특정 작업을 수행하는 명령어 묶음 | 자판기 (입력→결과) |
|
||||
| 변수 | 값을 저장하는 상자 | 이름표 붙은 바구니 |
|
||||
| 객체 | 관련 정보를 묶어놓은 것 | 프로필 카드 |
|
||||
| 클래스 | 객체를 만드는 설계도 | 붕어빵 틀 |
|
||||
| 워크플로우 | 업무 흐름, 작업 순서 | 요리 레시피 |
|
||||
| 파이프라인 | 여러 작업이 순차적으로 진행되는 과정 | 공장 조립 라인 |
|
||||
|
||||
### AI/ML 용어
|
||||
|
||||
| 전문 용어 | 쉬운 설명 | 비유/예시 |
|
||||
|----------|----------|----------|
|
||||
| 프롬프트 | AI에게 주는 지시문 | 직원에게 주는 업무 지시 |
|
||||
| 컨텍스트 | AI가 이해하는 상황 정보 | 대화의 앞뒤 맥락 |
|
||||
| 토큰 | AI가 처리하는 텍스트 단위 | 단어 조각 |
|
||||
| 파인튜닝 | AI를 특정 목적에 맞게 재학습 | 신입사원 직무 교육 |
|
||||
| MCP | AI에게 외부 정보를 연결해주는 플러그인 | 스마트폰 앱 |
|
||||
|
||||
### 비즈니스 용어
|
||||
|
||||
| 전문 용어 | 쉬운 설명 | 비유/예시 |
|
||||
|----------|----------|----------|
|
||||
| SaaS | 구독형 웹 서비스 | 넷플릭스, 멜론 |
|
||||
| MVP | 최소 기능 제품 | 프로토타입 |
|
||||
| PMF | 제품-시장 적합성 | 제품이 시장에 딱 맞는 상태 |
|
||||
| KPI | 핵심 성과 지표 | 목표 달성률 |
|
||||
| AGI | 인간 수준 범용 AI | 모든 일을 사람처럼 하는 AI |
|
||||
| AX | AI로 모든 게 바뀌는 시대 | - |
|
||||
|
||||
---
|
||||
|
||||
## 🎨 개선 패턴 라이브러리
|
||||
|
||||
### Pattern 1: 첫 등장 용어 → 괄호 설명
|
||||
|
||||
**Before**:
|
||||
```
|
||||
LLM을 로컬에 설치하면 API를 통해 작업됩니다.
|
||||
```
|
||||
|
||||
**After**:
|
||||
```
|
||||
LLM(ChatGPT, Claude 같은 대규모 AI 언어 모델)을
|
||||
내 컴퓨터에 직접 설치하면
|
||||
API(프로그램들끼리 대화하는 통로)를 통해 작업됩니다.
|
||||
```
|
||||
|
||||
### Pattern 2: 추상 개념 → 구체적 비유
|
||||
|
||||
**Before**:
|
||||
```
|
||||
로컬 LLM과 웹 UI의 차이는...
|
||||
```
|
||||
|
||||
**After**:
|
||||
```
|
||||
내 컴퓨터에 설치한 AI와 웹사이트의 차이는 이렇습니다:
|
||||
|
||||
| 구분 | 웹사이트 | 내 컴퓨터 |
|
||||
|------|---------|----------|
|
||||
| 비유 | 식당 주문 | 내 집 요리사 |
|
||||
| 맥락 이해 | 매번 설명 필요 | 내 상황 완전 파악 |
|
||||
```
|
||||
|
||||
### Pattern 3: 기술 설명 → 일상 비유
|
||||
|
||||
**Before**:
|
||||
```
|
||||
Skills는 입출력이 정해진 함수이고,
|
||||
SubAgent는 판단 로직을 가진 에이전트입니다.
|
||||
```
|
||||
|
||||
**After**:
|
||||
```
|
||||
Skills(자동 도구) → 자판기
|
||||
- 버튼(입력) 누르면 커피(결과)가 나옴
|
||||
- 매번 똑같은 결과
|
||||
|
||||
SubAgent(AI 직원) → 바리스타
|
||||
- "달달한 거 주세요" 하면 상황 보고 판단
|
||||
- 내 취향 기억하고 추천
|
||||
```
|
||||
|
||||
### Pattern 4: 코드/기술 → "실제 화면" 안내
|
||||
|
||||
**Before**:
|
||||
```javascript
|
||||
Command: /콘텐츠-제작-파이프라인
|
||||
```
|
||||
|
||||
**After**:
|
||||
```
|
||||
이런 식으로 자동으로 돌아갑니다 (실제 진행 과정):
|
||||
|
||||
Command: /콘텐츠-제작-파이프라인
|
||||
```
|
||||
|
||||
### Pattern 5: 복잡한 차이 → 비교표
|
||||
|
||||
**Before**:
|
||||
```
|
||||
웹 UI는 매번 맥락을 설명해야 하고 파일 접근이 안 되지만,
|
||||
로컬 설치는 내 상황을 파악하고 파일을 자유롭게 읽습니다.
|
||||
```
|
||||
|
||||
**After**:
|
||||
```
|
||||
| 구분 | 웹사이트 (ChatGPT) | 내 컴퓨터 (Claude Code) |
|
||||
|------|-------------------|------------------------|
|
||||
| 비유 | 식당에 가서 주문 | 내 집에 요리사 고용 |
|
||||
| 맥락 이해 | 매번 설명 필요 | 내 상황 완전 파악 |
|
||||
| 파일 접근 | 불가능 | 내 파일 자유롭게 읽기 |
|
||||
| 자동화 | 불가능 (내가 계속 지시) | 가능 (한 번 명령으로 전체 실행) |
|
||||
```
|
||||
|
||||
### Pattern 6: 영문 약어 → 한글 + 괄호 설명
|
||||
|
||||
**Before**:
|
||||
```
|
||||
MCP, JSON, SaaS 같은 것들...
|
||||
```
|
||||
|
||||
**After**:
|
||||
```
|
||||
MCP(AI에게 외부 정보를 연결해주는 플러그인),
|
||||
JSON(데이터를 정리해서 저장하는 텍스트 형식),
|
||||
SaaS(구독형 웹 서비스) 같은 것들...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔄 개선 프로세스
|
||||
|
||||
### Step 1: 스캔 (Scan)
|
||||
|
||||
**전체 대본을 읽고 다음을 식별**:
|
||||
- [ ] 비개발자가 모를 용어 리스트업
|
||||
- [ ] 설명 없이 등장하는 개념 표시
|
||||
- [ ] 추상적인 설명 부분 체크
|
||||
- [ ] 비유가 필요한 부분 표시
|
||||
|
||||
**Output**:
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
📊 용어 분석 결과
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
|
||||
🔴 즉시 개선 필요 (난이도 ★★★):
|
||||
- LLM (66줄): 설명 없이 등장
|
||||
- API (68줄): 기술 용어 그대로
|
||||
- VS Code (227줄): 정체 불명
|
||||
|
||||
🟡 개선 권장 (난이도 ★★☆):
|
||||
- 워크플로우 (104줄): 외래어
|
||||
- JSON (243줄): 비개발자 생소
|
||||
- MCP (243줄): 약어만 있음
|
||||
|
||||
🟢 개선 선택 (난이도 ★☆☆):
|
||||
- AGI (130줄): 맥락상 이해 가능
|
||||
- SaaS (198줄): 비즈니스 용어
|
||||
```
|
||||
|
||||
### Step 2: 우선순위 (Prioritize)
|
||||
|
||||
**난이도별 분류**:
|
||||
- 🔴 ★★★ 필수: 이해 불가능 (LLM, API, VS Code)
|
||||
- 🟡 ★★☆ 권장: 이해 어려움 (워크플로우, JSON)
|
||||
- 🟢 ★☆☆ 선택: 맥락상 추론 가능 (AGI, SaaS)
|
||||
|
||||
### Step 3: 개선 (Improve)
|
||||
|
||||
**각 용어별 개선안 제시**:
|
||||
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
🔧 개선안
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
|
||||
1. LLM (66줄) 🔴
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
Before:
|
||||
"llm을 로컬에 설치해서 사용해야합니다."
|
||||
|
||||
After:
|
||||
"LLM(ChatGPT, Claude 같은 대규모 AI 언어 모델)을
|
||||
내 컴퓨터에 직접 설치해서 사용해야합니다."
|
||||
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
이유: 첫 등장 시 반드시 설명 필요
|
||||
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
|
||||
2. API (68줄) 🔴
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
Before:
|
||||
"api를 통해 작업되는건데"
|
||||
|
||||
After:
|
||||
"API(프로그램들끼리 대화하는 통로)를 통해 작업되는건데"
|
||||
|
||||
또는 더 쉽게:
|
||||
"인터넷을 통해 GPT와 연결되는 건데"
|
||||
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
이유: 기술 용어를 일상 언어로 변환
|
||||
```
|
||||
|
||||
### Step 4: 검증 (Validate)
|
||||
|
||||
**개선된 대본 체크리스트**:
|
||||
- [ ] 모든 전문 용어 첫 등장 시 설명됨
|
||||
- [ ] 비유가 적절하고 이해하기 쉬움
|
||||
- [ ] 비교표가 명확함
|
||||
- [ ] 원래 의미의 95% 이상 유지
|
||||
- [ ] 문장이 자연스러움 (설명 때문에 어색하지 않음)
|
||||
|
||||
---
|
||||
|
||||
## 📋 Output Format
|
||||
|
||||
### 개선안 제시 형식
|
||||
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
📊 비개발자 대상 대본 개선 분석
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
## 1️⃣ 난이도 분석
|
||||
|
||||
🔴 즉시 개선 필요 (이해 불가능): [N개]
|
||||
🟡 개선 권장 (이해 어려움): [N개]
|
||||
🟢 개선 선택 (맥락상 추론 가능): [N개]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
## 2️⃣ 개선 우선순위
|
||||
|
||||
### 🔴 필수 개선 항목
|
||||
|
||||
**1. [용어명] (줄 번호)**
|
||||
현재: [원문]
|
||||
문제: [왜 어려운가]
|
||||
개선안: [구체적 수정안]
|
||||
비유: [선택적]
|
||||
|
||||
**2. [용어명] (줄 번호)**
|
||||
...
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
### 🟡 권장 개선 항목
|
||||
|
||||
[같은 형식]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
### 🟢 선택 개선 항목
|
||||
|
||||
[같은 형식]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
## 3️⃣ 비유 추가 제안
|
||||
|
||||
**[개념/섹션]에 비유 추가 권장**
|
||||
- 현재: [추상적 설명]
|
||||
- 비유 제안: [구체적 비유]
|
||||
- 예시: [실제 작성 예시]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
## 4️⃣ 비교표 추가 제안
|
||||
|
||||
**[섹션]에 비교표 추가 권장**
|
||||
이유: 복잡한 차이점을 시각적으로 정리
|
||||
|
||||
[표 예시]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
## 5️⃣ 종합 의견
|
||||
|
||||
✅ 잘된 부분:
|
||||
- [...]
|
||||
|
||||
⚠️ 개선 필요:
|
||||
- [...]
|
||||
|
||||
💡 추가 제안:
|
||||
- [...]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
## 🚀 다음 단계
|
||||
|
||||
1. 🔴 필수 항목부터 개선
|
||||
2. 🟡 권장 항목 검토
|
||||
3. 비유/표 추가
|
||||
4. 전체 흐름 재확인
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Coaching Principles
|
||||
|
||||
### 분석 시 원칙
|
||||
|
||||
1. **비개발자 관점으로 읽기**
|
||||
- "이 용어 처음 들으면?"
|
||||
- "왜 이게 필요한지 모르겠다면?"
|
||||
- "이게 뭔지 상상이 안 간다면?"
|
||||
|
||||
2. **난이도 정확히 평가**
|
||||
- 🔴 필수: 이해 0%
|
||||
- 🟡 권장: 이해 30-60%
|
||||
- 🟢 선택: 이해 70-90%
|
||||
|
||||
3. **구체적 개선안 제시**
|
||||
- "더 쉽게" (X) → 구체적 수정안 (O)
|
||||
- "비유 추가" (X) → 실제 비유 예시 (O)
|
||||
|
||||
### 개선 시 원칙
|
||||
|
||||
1. **원래 의미 95% 이상 유지**
|
||||
- 쉽게 만들려다 의미 왜곡 금지
|
||||
- 정확성 > 쉬움
|
||||
|
||||
2. **자연스러운 문장**
|
||||
- 괄호 설명이 어색하면 문장 재구성
|
||||
- "A(B)입니다" 보다 "A, 즉 B입니다" 선호
|
||||
|
||||
3. **비유의 적절성**
|
||||
- 너무 유치하지 않게
|
||||
- 정확한 비유 (90% 일치)
|
||||
- 보편적 경험 기반
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Advanced Techniques
|
||||
|
||||
### 기법 1: 단계적 설명
|
||||
|
||||
**복잡한 개념은 3단계로**:
|
||||
1. 일상 언어로 정의
|
||||
2. 구체적 예시
|
||||
3. 기술적 정의 (선택)
|
||||
|
||||
**예시**:
|
||||
```
|
||||
API는 뭘까요?
|
||||
|
||||
1. 일상 언어: 프로그램들끼리 대화하는 통로
|
||||
2. 예시: 배달앱이 식당에 주문 전달하는 것
|
||||
3. 기술적: Application Programming Interface (선택)
|
||||
```
|
||||
|
||||
### 기법 2: 점진적 복잡도
|
||||
|
||||
**쉬운 표현 → 정확한 표현으로 전환**:
|
||||
```
|
||||
처음: "AI를 내 컴퓨터에서 쓰는 거예요"
|
||||
↓
|
||||
중간: "AI를 내 컴퓨터에 설치해서 파일과 연결하는 거예요"
|
||||
↓
|
||||
나중: "LLM을 로컬 환경에 설치하고 파일 시스템과 통합하는 거예요"
|
||||
```
|
||||
|
||||
### 기법 3: 질문 유도
|
||||
|
||||
**독자가 스스로 깨닫게**:
|
||||
```
|
||||
Before:
|
||||
"로컬 설치와 웹 UI는 다릅니다."
|
||||
|
||||
After:
|
||||
"웹사이트에서 쓰는 거랑 뭐가 다를까요?
|
||||
핵심은 딱 하나입니다.
|
||||
AI가 내 컴퓨터의 파일을 직접 읽을 수 있다는 것."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ✅ Quality Checklist
|
||||
|
||||
개선 완료 후 체크:
|
||||
|
||||
### 이해도 검증
|
||||
- [ ] 중학생도 이해 가능한 수준
|
||||
- [ ] 전문 용어 0개 (또는 모두 설명됨)
|
||||
- [ ] 비유가 적절하고 정확함
|
||||
- [ ] 원래 의미 95% 이상 유지
|
||||
|
||||
### 문장 품질
|
||||
- [ ] 자연스러운 한국어
|
||||
- [ ] 괄호 설명이 어색하지 않음
|
||||
- [ ] 문장 길이 적절 (20-30자)
|
||||
- [ ] 읽기 쉬운 흐름
|
||||
|
||||
### 구조 품질
|
||||
- [ ] 비교표가 명확함
|
||||
- [ ] 단계별 설명이 논리적
|
||||
- [ ] 예시가 구체적
|
||||
- [ ] 시각적 요소 적절
|
||||
|
||||
---
|
||||
|
||||
## 📌 Important Notes
|
||||
|
||||
### 주의사항
|
||||
|
||||
1. **과도한 단순화 금지**
|
||||
- ❌ "AI는 똑똑한 로봇이에요"
|
||||
- ✅ "AI는 대량의 데이터로 학습한 소프트웨어예요"
|
||||
|
||||
2. **유치한 비유 피하기**
|
||||
- ❌ "AI는 아기처럼 배워요"
|
||||
- ✅ "AI는 신입사원처럼 훈련이 필요해요"
|
||||
|
||||
3. **정확성 최우선**
|
||||
- 쉽게 만들려다 의미 왜곡하지 않기
|
||||
- 불확실하면 원문 유지
|
||||
|
||||
### 용어 사용 가이드
|
||||
|
||||
**사용 가능한 기술 용어**:
|
||||
- 웹사이트, 프로그램, 앱, 파일, 폴더
|
||||
- 설치, 실행, 클릭, 입력
|
||||
- 인터넷, 브라우저, 컴퓨터
|
||||
|
||||
**설명 필요한 기술 용어**:
|
||||
- AI/ML 관련 (LLM, 프롬프트, 토큰)
|
||||
- 개발 도구 (IDE, CLI, Git)
|
||||
- 프로그래밍 (함수, 객체, API)
|
||||
- 인프라 (클라우드, 서버, 로컬)
|
||||
|
||||
---
|
||||
|
||||
**Version**: v1.0
|
||||
**Last Updated**: 2025-01-10
|
||||
**Target Audience**: 비개발자 (개발 지식 제로)
|
||||
**Goal**: 이해도 95% 유지하며 접근성 극대화
|
||||
199
.claude/skills/landing-page-copywriter/SKILL.md
Normal file
199
.claude/skills/landing-page-copywriter/SKILL.md
Normal file
@@ -0,0 +1,199 @@
|
||||
---
|
||||
name: landing-page-copywriter
|
||||
description: Write high-converting landing page copy using proven frameworks like PAS (Problem-Agitate-Solution), AIDA, and StoryBrand. Creates headlines, value propositions, CTAs, and full page sections optimized for conversion. Use when users need landing page copy, sales page content, or marketing website text.
|
||||
---
|
||||
|
||||
# Landing Page Copywriter
|
||||
|
||||
Create high-converting landing page copy using proven copywriting frameworks.
|
||||
|
||||
## Instructions
|
||||
|
||||
When a user needs landing page copy or marketing website content:
|
||||
|
||||
1. **Gather Product/Service Information**:
|
||||
- What product/service are you selling?
|
||||
- Who is your target audience?
|
||||
- What problem does it solve?
|
||||
- What makes it unique (competitive advantage)?
|
||||
- What action do you want visitors to take?
|
||||
- Any social proof, testimonials, or data points?
|
||||
|
||||
2. **Choose Copywriting Framework**:
|
||||
|
||||
**PAS (Problem-Agitate-Solution)**:
|
||||
- Identify the pain point
|
||||
- Amplify the consequences
|
||||
- Present your solution
|
||||
|
||||
**AIDA (Attention-Interest-Desire-Action)**:
|
||||
- Grab attention with bold claim
|
||||
- Build interest with details
|
||||
- Create desire with benefits
|
||||
- Prompt action with CTA
|
||||
|
||||
**StoryBrand**:
|
||||
- Hero (customer) has a problem
|
||||
- Meets a guide (you)
|
||||
- Who gives them a plan
|
||||
- Calls them to action
|
||||
- That results in success/avoids failure
|
||||
|
||||
3. **Generate Landing Page Sections**:
|
||||
|
||||
**Hero Section**:
|
||||
- Headline (value proposition in 10 words or less)
|
||||
- Subheadline (expand on the value)
|
||||
- Primary CTA button text
|
||||
- Trust indicators (used by X companies, Y reviews)
|
||||
|
||||
**Problem Section**:
|
||||
- Identify the pain point your audience feels
|
||||
- Use emotional language
|
||||
- 2-3 specific scenarios
|
||||
|
||||
**Solution Section**:
|
||||
- How your product solves the problem
|
||||
- 3-5 key features with benefit-focused descriptions
|
||||
- Why it's better than alternatives
|
||||
|
||||
**How It Works**:
|
||||
- 3-4 simple steps
|
||||
- Each step has icon concept + description
|
||||
- End with CTA
|
||||
|
||||
**Social Proof**:
|
||||
- Testimonial structure (quote + name + role + company)
|
||||
- Case study snippet
|
||||
- Trust badges or metrics
|
||||
|
||||
**Pricing/Plans** (if applicable):
|
||||
- Feature comparison
|
||||
- Recommended plan highlighting
|
||||
- Money-back guarantee copy
|
||||
|
||||
**FAQ**:
|
||||
- 5-7 common objections
|
||||
- Clear, confident answers
|
||||
|
||||
**Final CTA**:
|
||||
- Urgency or scarcity element
|
||||
- Risk reversal (guarantee)
|
||||
- Button text that reinforces value
|
||||
|
||||
4. **Format Output**:
|
||||
```
|
||||
🎯 LANDING PAGE COPY
|
||||
Product/Service: [Name]
|
||||
Framework: [PAS/AIDA/StoryBrand]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
🏆 HERO SECTION
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Headline: [Powerful 10-word value proposition]
|
||||
|
||||
Subheadline: [2-sentence expansion]
|
||||
|
||||
CTA Button: "[Action-oriented text]"
|
||||
|
||||
Trust Bar: [Social proof element]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
😤 PROBLEM SECTION
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
[Problem description with emotional resonance]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
✅ SOLUTION SECTION
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
[How your product solves it]
|
||||
|
||||
Feature 1: [Benefit-focused description]
|
||||
Feature 2: [Benefit-focused description]
|
||||
Feature 3: [Benefit-focused description]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
🔄 HOW IT WORKS
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Step 1: [Simple action]
|
||||
Step 2: [Simple action]
|
||||
Step 3: [Simple action]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
⭐ SOCIAL PROOF
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
[Testimonial quotes with attribution]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
❓ FAQ
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Q: [Common objection]
|
||||
A: [Clear, confident answer]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
🚀 FINAL CTA
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
[Urgency/scarcity element]
|
||||
[Risk reversal]
|
||||
Button: "[Action text]"
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
💡 OPTIMIZATION NOTES
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
A/B Test Ideas:
|
||||
• [Headline variation]
|
||||
• [CTA variation]
|
||||
|
||||
Conversion Tips:
|
||||
• [Specific recommendation]
|
||||
```
|
||||
|
||||
5. **Copywriting Best Practices**:
|
||||
- Use active voice, present tense
|
||||
- Focus on benefits, not features
|
||||
- Include specific numbers and data
|
||||
- Address objections directly
|
||||
- Create urgency without being pushy
|
||||
- Use power words (proven, guaranteed, instant, effortless)
|
||||
- Keep sentences short and scannable
|
||||
- Use "you" language (customer-focused)
|
||||
- Include multiple CTAs throughout page
|
||||
|
||||
6. **CTA Button Best Practices**:
|
||||
- Start with action verb
|
||||
- Be specific about outcome
|
||||
- Use first person when appropriate ("Start My Free Trial" vs "Start Your Free Trial")
|
||||
- Create urgency ("Get Instant Access")
|
||||
- Avoid generic text ("Submit", "Click Here")
|
||||
|
||||
## Example Triggers
|
||||
|
||||
- "Write landing page copy for a B2B SaaS tool"
|
||||
- "Create sales page content using PAS framework"
|
||||
- "Generate hero section copy for my product"
|
||||
- "Write conversion-optimized CTAs"
|
||||
- "Help me with landing page headlines"
|
||||
|
||||
## Output Quality
|
||||
|
||||
Ensure all copy:
|
||||
- Leads with value, not features
|
||||
- Addresses target audience pain points
|
||||
- Uses emotional and logical appeals
|
||||
- Has clear, compelling CTAs
|
||||
- Includes social proof elements
|
||||
- Handles objections proactively
|
||||
- Creates urgency appropriately
|
||||
- Is scannable and easy to read
|
||||
- Uses proven copywriting frameworks
|
||||
- Follows conversion optimization best practices
|
||||
|
||||
Generate professional, high-converting landing page copy that turns visitors into customers.
|
||||
545
.claude/skills/ppt-slide-extractor/SKILL.md
Normal file
545
.claude/skills/ppt-slide-extractor/SKILL.md
Normal file
@@ -0,0 +1,545 @@
|
||||
---
|
||||
name: ppt-slide-extractor
|
||||
description: 유튜브 나레이션 대본에서 영상 송출용 PPT 장표를 추출. 각 장표마다 제목, 핵심 내용, 이미지 제안만 심플하게 제공. 시청자가 나레이션과 함께 보면서 내용을 이해할 수 있도록 시각적 보조 자료 생성. 결과는 새로운 md 파일로 저장. Use when users need YouTube video presentation slides.
|
||||
---
|
||||
|
||||
# PPT Slide Extractor (유튜브 영상용 장표 추출기)
|
||||
|
||||
유튜브 나레이션 대본에서 영상에 삽입할 PPT 장표를 자동 추출하고 별도의 md 파일로 저장합니다.
|
||||
|
||||
## 📁 Templates & Output
|
||||
|
||||
**Template Location**: `.specify/templates/`
|
||||
- `ppt-slides-output.md`: 전체 출력 구조 템플릿
|
||||
- `ppt-slide-template.md`: 개별 슬라이드 템플릿
|
||||
|
||||
**Output File Naming**: `[원본파일명]_PPT장표.md`
|
||||
- 예: `아무도 알려주지 않은 AI 수익화.md` → `아무도 알려주지 않은 AI 수익화_PPT장표.md`
|
||||
|
||||
**Output Location**: 원본 파일과 동일한 디렉토리
|
||||
|
||||
## 🎯 Core Purpose
|
||||
|
||||
**유튜브 영상 송출용 PPT 장표**
|
||||
- 시청자가 나레이션 들으면서 보는 시각 자료
|
||||
- 복잡한 설명을 단순화해서 전달
|
||||
- 핵심 키워드와 이미지로 이해도 향상
|
||||
|
||||
**NOT for**:
|
||||
- 오프라인 발표 자료 (X)
|
||||
- 발표자 노트나 제스처 가이드 (X)
|
||||
- 상세한 디자인 시안 (X)
|
||||
|
||||
---
|
||||
|
||||
## 📐 장표 추출 원칙
|
||||
|
||||
### 1장 = 1메시지
|
||||
- 한 장표에 하나의 핵심만
|
||||
- 텍스트는 최소한으로 (키워드 중심)
|
||||
- 시청자가 3초 안에 파악 가능해야 함
|
||||
|
||||
### 영상 길이별 장표 수
|
||||
- 10분 영상: 8-12장
|
||||
- 15분 영상: 12-18장
|
||||
- 평균: 1-1.5분당 1장
|
||||
|
||||
### 장표 필요 구간 vs 나레이션만 구간
|
||||
- **장표 필수**: 숫자/데이터, 프로세스, 비교, 핵심 개념
|
||||
- **나레이션만**: 스토리 전개, 개인적 경험담, 전환 멘트
|
||||
|
||||
---
|
||||
|
||||
## 🎨 장표 타입 (6가지)
|
||||
|
||||
### Type 1: 타이틀 슬라이드
|
||||
**언제**: 영상 시작, 큰 섹션 전환
|
||||
**구성**: 임팩트 제목 + 부제 (선택)
|
||||
**예시**:
|
||||
```
|
||||
제목: AI로 월 300만원 버는 법
|
||||
부제: 집에서 쉽게 시작하는 수익화
|
||||
이미지: 노트북 + 돈 아이콘, 상승 그래프
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Type 2: 문제 제시
|
||||
**언제**: 고통 포인트 강조
|
||||
**구성**: 문제 키워드 3개
|
||||
**예시**:
|
||||
```
|
||||
제목: 이런 고민 있으신가요?
|
||||
|
||||
❌ 3개월째 AI 공부 미루는 중
|
||||
❌ 유료 결제했는데 안 씀
|
||||
❌ "AI로 돈 번다는데?" 막막함
|
||||
|
||||
이미지: 고민하는 사람, 물음표, 복잡한 화면
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Type 3: 프로세스
|
||||
**언제**: 단계별 방법 설명
|
||||
**구성**: 단계 번호 + 핵심 행동
|
||||
**예시**:
|
||||
```
|
||||
제목: AI 자동화 4단계
|
||||
|
||||
1️⃣ 태스크 나열
|
||||
2️⃣ 그룹핑
|
||||
3️⃣ 워크플로우 연결
|
||||
4️⃣ AI 인수인계
|
||||
|
||||
이미지: 플로우차트, 화살표 다이어그램
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Type 4: 비교
|
||||
**언제**: Before/After, A vs B
|
||||
**구성**: 좌우 또는 상하 대비
|
||||
**예시**:
|
||||
```
|
||||
제목: Web UI vs Claude Code
|
||||
|
||||
좌측: Web UI 우측: Claude Code
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
매번 맥락 설명 프로젝트 이해
|
||||
범용적 답변 맞춤형 답변
|
||||
일관성 깨짐 지속 일관성
|
||||
|
||||
이미지: 좌측 혼란, 우측 깔끔 / VS 기호
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Type 5: 데이터
|
||||
**언제**: 숫자, 통계, 사회적 증거
|
||||
**구성**: 큰 숫자 + 보조 데이터
|
||||
**예시**:
|
||||
```
|
||||
제목: 실제 사용자 성과
|
||||
|
||||
[대형 숫자]
|
||||
300만원
|
||||
(평균 월 수익)
|
||||
|
||||
👤 500명+ 실행
|
||||
⏱️ 평균 2주 첫 수익
|
||||
⭐ 만족도 4.8/5.0
|
||||
|
||||
이미지: 상승 그래프, 성공 아이콘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Type 6: CTA
|
||||
**언제**: 행동 유도 구간
|
||||
**구성**: 3단계 깔때기
|
||||
**예시**:
|
||||
```
|
||||
제목: 지금 바로 시작하세요
|
||||
|
||||
🎁 영상 저장 + 구독
|
||||
💎 무료 PDF 다운
|
||||
🚀 1:1 컨설팅 (선착순)
|
||||
|
||||
⏰ 이번 주 한정
|
||||
|
||||
이미지: 시작 버튼, 화살표, 밝은 미래
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🤖 추출 프로세스
|
||||
|
||||
### Step 1: 대본 분석
|
||||
```
|
||||
사용자가 대본 제공 →
|
||||
1. 원본 파일명 추출 (확장자 제거)
|
||||
2. 타임스탬프로 전체 길이 파악
|
||||
3. 섹션 구조 인식 (HOOK, PROBLEM, VALUE 등)
|
||||
4. 장표 필요 구간 마킹
|
||||
5. 예상 장표 수 계산 (1-1.5분당 1장)
|
||||
```
|
||||
|
||||
### Step 2: 장표 추출
|
||||
```
|
||||
각 구간 순회하며:
|
||||
1. 핵심 메시지 추출
|
||||
2. 장표 타입 분류
|
||||
3. 제목 생성 (5-8단어)
|
||||
4. 키워드/내용 추출 (3-5개)
|
||||
5. 이미지 제안 (간단히)
|
||||
```
|
||||
|
||||
### Step 3: 파일 생성
|
||||
```
|
||||
1. 출력 파일명 생성: [원본파일명]_PPT장표.md
|
||||
2. 템플릿 변수 치환:
|
||||
- {{VIDEO_TITLE}}: 영상 제목
|
||||
- {{VIDEO_LENGTH}}: 영상 길이
|
||||
- {{GENERATION_DATE}}: 생성 일시
|
||||
- {{TOTAL_SLIDES}}: 총 장표 수
|
||||
- {{TABLE_OF_CONTENTS}}: 목차
|
||||
- {{SLIDES_CONTENT}}: 모든 슬라이드 내용
|
||||
- {{SOURCE_FILE}}: 원본 파일명
|
||||
3. Write 도구로 md 파일 생성
|
||||
4. 생성된 파일 경로 사용자에게 안내
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📋 출력 포맷
|
||||
|
||||
### 전체 구조
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
📊 PPT 장표 추출 결과
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
영상: [제목]
|
||||
길이: [10분]
|
||||
장표: [10장]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
📑 목차
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
#1 [0:00-0:15] 타이틀
|
||||
#2 [0:15-0:45] 문제 제시
|
||||
#3 [0:45-1:30] 실패 이유
|
||||
#4 [2:00-3:00] 솔루션 비교
|
||||
#5 [3:00-5:00] 프로세스
|
||||
#6 [5:00-6:00] 실전 예시 1
|
||||
#7 [6:00-7:00] 실전 예시 2
|
||||
#8 [8:00-9:00] 데이터
|
||||
#9 [9:00-9:30] 요약
|
||||
#10 [9:30-10:00] CTA
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 각 슬라이드 포맷
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
📊 SLIDE #[번호]: [타입]
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
⏰ [0:00-0:15]
|
||||
|
||||
제목: [5-8단어 임팩트]
|
||||
|
||||
내용:
|
||||
[키워드 3-5개 OR 프로세스 단계 OR 비교 내용]
|
||||
|
||||
이미지:
|
||||
[간단한 이미지 설명 1-2줄]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 💡 키워드 추출 로직
|
||||
|
||||
### 우선순위
|
||||
1. **동사**: "시작하다", "분석하다" (행동 유도)
|
||||
2. **숫자**: "300만원", "3단계" (구체성)
|
||||
3. **대조**: "Before vs After", "X → O"
|
||||
4. **감정**: "쉽게", "빠르게", "확실하게"
|
||||
|
||||
### 예시
|
||||
```
|
||||
대본:
|
||||
"업무를 태스크로 나누고, 비슷한 것끼리 그룹핑한 다음,
|
||||
워크플로우로 연결해서 AI에게 문서화하여 인수인계합니다."
|
||||
|
||||
추출 키워드:
|
||||
1️⃣ 태스크 나열
|
||||
2️⃣ 그룹핑
|
||||
3️⃣ 워크플로우 연결
|
||||
4️⃣ AI 인수인계
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🖼️ 이미지 제안 가이드
|
||||
|
||||
### 타입별 이미지
|
||||
| 장표 타입 | 이미지 방향 |
|
||||
|-----------|-------------|
|
||||
| 타이틀 | 강렬한 단일 이미지 (로켓, AI 로봇) |
|
||||
| 문제 제시 | 고통/혼란 (미로, 물음표) |
|
||||
| 프로세스 | 단계적 흐름 (화살표, 계단) |
|
||||
| 비교 | 대조 쌍 (어두움↔밝음) |
|
||||
| 데이터 | 신뢰 구축 (그래프, 별점) |
|
||||
| CTA | 행동 촉구 (시작 버튼, 빛) |
|
||||
|
||||
### 제안 방식
|
||||
- 구체적이되 간결하게
|
||||
- 1-2줄로 요약
|
||||
- 여러 옵션 나열하지 않음
|
||||
|
||||
---
|
||||
|
||||
## 💬 사용자 인터랙션
|
||||
|
||||
### 1️⃣ 대본 입력
|
||||
```
|
||||
사용자: "아무도 알려주지 않은 AI 수익화.md 파일로 PPT 만들어줘"
|
||||
|
||||
에이전트:
|
||||
"📋 대본 분석 중...
|
||||
|
||||
원본 파일: 아무도 알려주지 않은 AI 수익화.md
|
||||
영상 길이: 10분
|
||||
예상 장표: 10-12장
|
||||
출력 파일: 아무도 알려주지 않은 AI 수익화_PPT장표.md
|
||||
|
||||
추출을 시작할까요?"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ 추출 진행 및 파일 생성
|
||||
```
|
||||
"🔄 장표 추출 중...
|
||||
✅ 11장 추출 완료
|
||||
📝 파일 생성 중...
|
||||
|
||||
✨ 완료!
|
||||
|
||||
생성된 파일:
|
||||
/Users/.../아무도 알려주지 않은 AI 수익화_PPT장표.md
|
||||
|
||||
파일을 열어서 확인하시겠어요?"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ 수정 요청
|
||||
```
|
||||
사용자: "SLIDE #5 너무 복잡해. 파일 수정해줘"
|
||||
|
||||
에이전트:
|
||||
"💡 SLIDE #5 단순화 중...
|
||||
|
||||
변경사항:
|
||||
현재: 4단계
|
||||
개선: 3단계로 통합
|
||||
|
||||
1️⃣ 업무 쪼개기
|
||||
2️⃣ 순서 정리
|
||||
3️⃣ AI에게 맡기기
|
||||
|
||||
✅ 파일 업데이트 완료!"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 실전 예시
|
||||
|
||||
### Input: 대본 샘플
|
||||
```
|
||||
## [2:00-4:00] SOLUTION INTRO
|
||||
|
||||
제가 두 그룹으로 나눠볼게요.
|
||||
|
||||
첫 번째 그룹: "가끔 쓰는 사람들"
|
||||
- ChatGPT 가끔 질문
|
||||
- 귀찮은 거만 부탁
|
||||
|
||||
두 번째 그룹: "지금 만드는 사람들"
|
||||
- 매일 AI와 협업
|
||||
- 내 맥락을 학습시킴
|
||||
|
||||
차이는? 첫 번째는 AI를 도구로 보고,
|
||||
두 번째는 AI를 팀원으로 봅니다.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Output: 추출 결과
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
📊 SLIDE #4: 비교
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
⏰ [2:00-4:00]
|
||||
|
||||
제목: AI 시대, 당신은 어느 그룹?
|
||||
|
||||
내용:
|
||||
그룹 1: 가끔 쓰는 사람 | 그룹 2: 지금 만드는 사람
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
🔧 AI = 도구 | 👥 AI = 팀원
|
||||
가끔 질문 | 매일 협업
|
||||
귀찮은 것만 | 맥락 학습
|
||||
|
||||
이미지:
|
||||
좌측은 어둡게 (계산기), 우측은 밝게 (팀 협업)
|
||||
중앙에 VS 또는 화살표
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ✅ 품질 기준
|
||||
|
||||
모든 장표는:
|
||||
- ✅ 1장 = 1메시지
|
||||
- ✅ 키워드 5개 이하
|
||||
- ✅ 3초 안에 파악 가능
|
||||
- ✅ 나레이션과 싱크
|
||||
- ✅ 이미지 제안 간결
|
||||
|
||||
---
|
||||
|
||||
## 🚫 하지 말아야 할 것
|
||||
|
||||
### DON'T ❌
|
||||
1. 대본 전체를 장표에 복사
|
||||
2. 복잡한 차트나 그래프
|
||||
3. 작은 글씨로 텍스트 많이
|
||||
4. 애니메이션 효과 제안
|
||||
5. 디자인 세부사항 (색상, 폰트 크기 등)
|
||||
6. 발표자 노트, 제스처 가이드
|
||||
|
||||
### DO ✅
|
||||
1. 핵심 키워드만 추출
|
||||
2. 즉시 이해 가능한 구조
|
||||
3. 나레이션 보조 역할
|
||||
4. 시각적 메타포 활용
|
||||
5. 심플하고 깔끔하게
|
||||
|
||||
---
|
||||
|
||||
## 📌 Activation Triggers
|
||||
|
||||
다음 요청 시 자동 활성화:
|
||||
- "이 나레이션으로 PPT 만들어줘"
|
||||
- "대본에서 장표 뽑아줘"
|
||||
- "영상용 슬라이드 필요해"
|
||||
- "유튜브 PPT 추출해줘"
|
||||
|
||||
파일 형식:
|
||||
- `.md`, `.txt` (나레이션 대본)
|
||||
|
||||
---
|
||||
|
||||
## 🔧 실행 가이드 (Agent Implementation)
|
||||
|
||||
### 파일 생성 프로세스
|
||||
|
||||
```python
|
||||
# Pseudo-code for implementation
|
||||
|
||||
# 1. 대본 파일 읽기
|
||||
source_file = "아무도 알려주지 않은 AI 수익화.md"
|
||||
source_content = Read(source_file)
|
||||
|
||||
# 2. 장표 추출
|
||||
slides = extract_slides(source_content)
|
||||
# returns: [{number, type, timestamp, title, content, image}, ...]
|
||||
|
||||
# 3. 메타데이터 생성
|
||||
video_title = extract_title(source_content)
|
||||
video_length = calculate_length(slides)
|
||||
generation_date = current_datetime()
|
||||
total_slides = len(slides)
|
||||
|
||||
# 4. 목차 생성
|
||||
toc = generate_toc(slides)
|
||||
# format: "#1 [0:00-0:15] 타이틀\n#2 [0:15-0:45] 문제 제시\n..."
|
||||
|
||||
# 5. 슬라이드 콘텐츠 생성
|
||||
slides_content = ""
|
||||
for slide in slides:
|
||||
slides_content += f"""
|
||||
## SLIDE #{slide.number}: {slide.type}
|
||||
|
||||
**타임스탬프**: {slide.timestamp}
|
||||
|
||||
### 제목
|
||||
{slide.title}
|
||||
|
||||
### 내용
|
||||
{slide.content}
|
||||
|
||||
### 이미지
|
||||
{slide.image}
|
||||
|
||||
---
|
||||
"""
|
||||
|
||||
# 6. 최종 출력 파일 생성
|
||||
output_filename = source_file.replace(".md", "_PPT장표.md")
|
||||
output_content = f"""# {video_title}
|
||||
|
||||
**영상 길이**: {video_length}
|
||||
**추출 일시**: {generation_date}
|
||||
**장표 수**: {total_slides}장
|
||||
|
||||
---
|
||||
|
||||
## 📑 목차
|
||||
|
||||
{toc}
|
||||
|
||||
---
|
||||
|
||||
{slides_content}
|
||||
|
||||
---
|
||||
|
||||
## 💡 사용 가이드
|
||||
|
||||
### PPT 제작 시
|
||||
1. 각 슬라이드의 **제목**을 슬라이드 상단에 배치
|
||||
2. **내용**을 중앙에 큰 글씨로 (키워드는 bullet point)
|
||||
3. **이미지** 설명을 참고하여 배경 또는 우측에 배치
|
||||
4. 텍스트는 최소화, 시청자가 3초 안에 파악 가능하도록
|
||||
|
||||
### 영상 편집 시
|
||||
- 각 슬라이드의 **타임스탬프**를 참고하여 나레이션과 싱크
|
||||
- 슬라이드 전환은 부드럽게 (0.3-0.5초)
|
||||
- 애니메이션은 최소화 (필요시 페이드 인만)
|
||||
|
||||
---
|
||||
|
||||
**Generated by**: PPT Slide Extractor v3.0
|
||||
**Source**: {source_file}
|
||||
"""
|
||||
|
||||
# 7. 파일 쓰기
|
||||
Write(output_filename, output_content)
|
||||
|
||||
# 8. 사용자에게 안내
|
||||
print(f"✨ 완료!\n\n생성된 파일:\n{output_filename}")
|
||||
```
|
||||
|
||||
### 중요 구현 노트
|
||||
|
||||
1. **파일명 생성**: 원본 파일명에서 `.md` 제거 후 `_PPT장표.md` 추가
|
||||
2. **경로 유지**: 원본 파일과 동일한 디렉토리에 생성
|
||||
3. **Write 도구 사용**: Claude의 Write 도구로 파일 생성
|
||||
4. **절대 경로**: Write 도구에 절대 경로 전달 필요
|
||||
5. **인코딩**: UTF-8 인코딩 사용 (한글 지원)
|
||||
|
||||
### 에러 처리
|
||||
|
||||
- 원본 파일 없음: "파일을 찾을 수 없습니다" 안내
|
||||
- 파일 쓰기 실패: 권한 확인 또는 경로 확인 안내
|
||||
- 대본 구조 이상: "타임스탬프를 찾을 수 없습니다" 안내
|
||||
|
||||
---
|
||||
|
||||
**Version**: v3.0 (Template-based File Output)
|
||||
**Last Updated**: 2025-11-08
|
||||
**Focus**: 유튜브 영상 송출용 심플 장표 + 자동 파일 생성
|
||||
840
.claude/skills/youtube-narration-coach/SKILL.md
Normal file
840
.claude/skills/youtube-narration-coach/SKILL.md
Normal file
@@ -0,0 +1,840 @@
|
||||
---
|
||||
name: youtube-narration-coach
|
||||
description: 개발자적 사고방식 기반 유튜브 나레이션 코칭. 탑다운 명확성 + 시원시원한 전개 + 인식전환 심화 설명. 7단계 프레임워크로 대본 분석, 군더더기 제거, 핵심 강조.
|
||||
---
|
||||
|
||||
# YouTube Narration Coach
|
||||
|
||||
개발자적 사고방식으로 유튜브 대본을 분석하고 개선하는 코치입니다.
|
||||
|
||||
## Core Principles (사용자 선호도)
|
||||
|
||||
### 🎯 작성 스타일
|
||||
1. **탑다운 명확성**: 결론부터, 구조부터, 핵심부터
|
||||
2. **시원시원한 전개**: 뜸들이기 제거, 불필요한 수식어 삭제
|
||||
3. **개발자적 화법**: 논리적, 구조적, 증거 기반
|
||||
4. **비즈니스 관점**: 기술 + 실용성 병행
|
||||
|
||||
### ❌ 절대 금지
|
||||
- 과장된 HOOK ("놀랍게도", "믿기지 않겠지만")
|
||||
- 군더더기 수식어 ("정말 굉장한", "엄청난")
|
||||
- 감정적 과장 ("반드시!", "꼭!")
|
||||
- 뜸들이기 전개 (결론을 나중에 공개)
|
||||
|
||||
### ✅ 반드시 포함
|
||||
- **인식전환 구간**: 충분한 설명 + 구체적 예시
|
||||
- **핵심 강조 구간**: 명확한 근거 + 논리적 전개
|
||||
- **예시 필요 구간**: 실전 사례 + 구체적 숫자
|
||||
|
||||
---
|
||||
|
||||
## Instructions
|
||||
|
||||
### 🎯 Core Role
|
||||
|
||||
**Primary Function**:
|
||||
- 대본을 7단계 프레임워크로 분석
|
||||
- 탑다운 방식으로 피드백 (결론 → 이유 → 예시)
|
||||
- 뜸들이기, 과장, 군더더기 제거
|
||||
- 인식전환/강조 구간은 충분히 설명
|
||||
|
||||
**Never Do**:
|
||||
- 요청 없이 대본 대신 작성
|
||||
- 감정적/과장된 표현 사용
|
||||
- 모호한 피드백 ("더 구체적으로")
|
||||
- 프레임워크 없는 즉흥 조언
|
||||
|
||||
---
|
||||
|
||||
## 📺 Title Recommendations (제목 추천 가이드)
|
||||
|
||||
### 2-Track 제목 전략
|
||||
|
||||
유튜브 제목은 **두 가지 목적**을 동시에 달성해야 합니다:
|
||||
1. **SEO (검색 엔진 최적화)**: 검색 결과 상위 노출
|
||||
2. **CTR (클릭률 최적화)**: 썸네일 클릭 유도
|
||||
|
||||
따라서 **항상 2가지 버전**을 제공합니다.
|
||||
|
||||
---
|
||||
|
||||
#### 🔍 SEO용 제목 (검색 최적화)
|
||||
|
||||
**목적:**
|
||||
- 유튜브/구글 검색 결과 상위 노출
|
||||
- 검색 의도에 정확히 매칭
|
||||
- 키워드 기반 유입 극대화
|
||||
|
||||
**체크리스트:**
|
||||
- [ ] 핵심 키워드 3-5개 포함
|
||||
- [ ] 60자 이내 (YouTube 권장)
|
||||
- [ ] 명확한 주제 전달
|
||||
- [ ] `|`로 주제 구분 (선택)
|
||||
- [ ] (괄호)로 타겟 명시 (선택)
|
||||
|
||||
**키워드 선정 기준:**
|
||||
- 메인 키워드: 영상 주제 핵심 (예: "AI 수익화", "Claude Code")
|
||||
- 서브 키워드: 방법/도구 (예: "아이디어 구체화", "실전 사용법")
|
||||
- 타겟 키워드: 대상 명시 (예: "비개발자", "초보자")
|
||||
- 롱테일 키워드: 구체적 검색어 (예: "VS Code 튜토리얼")
|
||||
|
||||
**좋은 예시:**
|
||||
```
|
||||
AI 수익화 아이디어 구체화 방법 | Claude Code 실전 사용법 (비개발자 가능)
|
||||
```
|
||||
**분석:**
|
||||
- 핵심 키워드: AI 수익화, 아이디어 구체화, Claude Code
|
||||
- 서브 키워드: 방법, 실전 사용법
|
||||
- 타겟 키워드: 비개발자
|
||||
- 길이: 41자 ✅
|
||||
- 검색 의도: "AI로 돈 벌고 싶은데 어떻게 시작하지?" ✅
|
||||
|
||||
**나쁜 예시:**
|
||||
```
|
||||
❌ "이거 하나면 끝" (키워드 없음)
|
||||
❌ "AI로 진짜 돈 버는 비밀 공개합니다" (과장, 키워드 부족)
|
||||
❌ "Claude Code Advanced Tutorial for Professional Developers" (65자 초과)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 🎯 썸네일용 제목 (강한 HOOK)
|
||||
|
||||
**목적:**
|
||||
- 썸네일 클릭률 극대화
|
||||
- 호기심/감정 자극
|
||||
- 시각적 임팩트
|
||||
|
||||
**체크리스트:**
|
||||
- [ ] 강한 HOOK 요소 포함
|
||||
- [ ] 2줄 구성 권장 (시각적 임팩트)
|
||||
- [ ] 30자 이내 (썸네일 가독성)
|
||||
- [ ] 과장 없는 역설/대비/문제제기
|
||||
- [ ] 감정 자극 (호기심, 공감, 놀라움)
|
||||
|
||||
**HOOK 요소 (우선순위):**
|
||||
|
||||
1. **역설적 명령** (강력함 ★★★★★)
|
||||
- "AI로 돈 버는 아이디어, 당장 실행하지 마세요"
|
||||
- "ChatGPT 쓰지 마세요 (이걸 쓰세요)"
|
||||
- 효과: "왜?" 자동 질문 생성
|
||||
|
||||
2. **독점 정보** (강력함 ★★★★☆)
|
||||
- "아무도 모르는 AI 수익화 비밀"
|
||||
- "개발자들만 쓰는 자동화 방법"
|
||||
- 효과: "나만 모르는 건가?" FOMO 유발
|
||||
|
||||
3. **문제 제기** (강력함 ★★★★☆)
|
||||
- "수익화 아이디어만 있고 실행 못하는 이유"
|
||||
- "ChatGPT 별로였던 진짜 이유"
|
||||
- 효과: "내 얘기야" 공감대 형성
|
||||
|
||||
4. **대비/비교** (강력함 ★★★☆☆)
|
||||
- "ChatGPT vs Claude Code"
|
||||
- "월 300만원 vs 월 3000만원 차이"
|
||||
- 효과: 명확한 차별점 인식
|
||||
|
||||
5. **구체적 숫자** (강력함 ★★★☆☆)
|
||||
- "10초 만에 아이디어 → 시스템"
|
||||
- "AI 인플루언서 100명 운영법"
|
||||
- 효과: 즉각성, 규모감
|
||||
|
||||
**2줄 구성 권장:**
|
||||
```
|
||||
AI로 돈 버는 아이디어,
|
||||
당장 실행하지 마세요
|
||||
```
|
||||
**이유:**
|
||||
- 1줄: 관심 유발 (AI로 돈 버는 아이디어)
|
||||
- 2줄: 호기심 폭발 (당장 실행하지 마세요)
|
||||
- 시각적 임팩트 극대화
|
||||
- 썸네일 가독성 향상
|
||||
|
||||
**좋은 예시:**
|
||||
```
|
||||
아무도 모르는
|
||||
AI 수익화 구체화 비밀
|
||||
|
||||
수익화 아이디어만 있고
|
||||
실행 못하는 이유
|
||||
|
||||
ChatGPT가 절대 못하는
|
||||
진짜 AI 자동화
|
||||
```
|
||||
|
||||
**나쁜 예시:**
|
||||
```
|
||||
❌ "AI 수익화 방법" (HOOK 없음)
|
||||
❌ "정말 놀라운 비밀 대공개!" (과장)
|
||||
❌ "이거 하나면 월 천만원 버는 방법" (과장)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 🎨 제목 생성 프로세스
|
||||
|
||||
**Step 1: 대본 핵심 파악**
|
||||
- 영상의 핵심 메시지 1가지 추출
|
||||
- 타겟 시청자 명확화
|
||||
- 핵심 키워드 5개 나열
|
||||
|
||||
**Step 2: SEO용 제목 작성**
|
||||
```
|
||||
[핵심 키워드] [방법/도구] | [구체적 방법] ([타겟])
|
||||
```
|
||||
- 예: AI 수익화 아이디어 구체화 방법 | Claude Code 실전 사용법 (비개발자 가능)
|
||||
|
||||
**Step 3: 썸네일용 제목 작성**
|
||||
```
|
||||
[HOOK 요소]
|
||||
[핵심 메시지]
|
||||
```
|
||||
- 예: AI로 돈 버는 아이디어, / 당장 실행하지 마세요
|
||||
|
||||
**Step 4: A/B 테스트 준비**
|
||||
- SEO용 1개 + 썸네일용 3개 옵션 제공
|
||||
- HOOK 요소 다르게 적용 (역설, 독점, 문제제기)
|
||||
|
||||
**Step 5: 제목 검증**
|
||||
- [ ] SEO: 핵심 키워드 모두 포함
|
||||
- [ ] SEO: 60자 이내
|
||||
- [ ] 썸네일: 강한 HOOK 포함
|
||||
- [ ] 썸네일: 30자 이내, 2줄 구성
|
||||
- [ ] 둘 다: 과장 표현 없음
|
||||
- [ ] 둘 다: 대본 핵심과 일치
|
||||
|
||||
---
|
||||
|
||||
#### 📋 제목 추천 Output Format
|
||||
|
||||
제목을 추천할 때는 항상 이 형식을 사용:
|
||||
|
||||
```
|
||||
## 📊 [영상명] 제목 추천 (2-Track)
|
||||
|
||||
### 🔍 SEO용 제목 (검색 최적화)
|
||||
|
||||
**핵심 키워드:** [키워드 5개]
|
||||
|
||||
#### 1순위
|
||||
[제목]
|
||||
**검색 키워드:** [실제 검색 의도]
|
||||
**길이:** [글자 수]
|
||||
|
||||
#### 2순위
|
||||
[제목]
|
||||
**검색 키워드:** [실제 검색 의도]
|
||||
**길이:** [글자 수]
|
||||
|
||||
#### 3순위
|
||||
[제목]
|
||||
**검색 키워드:** [실제 검색 의도]
|
||||
**길이:** [글자 수]
|
||||
|
||||
---
|
||||
|
||||
### 🎯 썸네일용 제목 (강한 HOOK)
|
||||
|
||||
**HOOK 전략:** [역설/독점/문제제기 등]
|
||||
|
||||
#### 1순위
|
||||
```
|
||||
[2줄 제목]
|
||||
```
|
||||
**HOOK 요소:** [상세 설명]
|
||||
|
||||
#### 2순위
|
||||
```
|
||||
[2줄 제목]
|
||||
```
|
||||
**HOOK 요소:** [상세 설명]
|
||||
|
||||
#### 3순위
|
||||
```
|
||||
[2줄 제목]
|
||||
```
|
||||
**HOOK 요소:** [상세 설명]
|
||||
|
||||
---
|
||||
|
||||
## 💡 최종 추천 조합
|
||||
|
||||
**SEO용:** [1순위 제목]
|
||||
**썸네일용:** [1순위 제목]
|
||||
|
||||
**선정 이유:**
|
||||
- SEO: [이유]
|
||||
- 썸네일: [이유]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎬 YouTube Algorithm Survival Guide
|
||||
|
||||
### Critical Success Metrics
|
||||
|
||||
**CTR (Click-Through Rate) = 생존 지표**
|
||||
- **8% 이상**: 바이럴 가능성 (알고리즘 적극 추천)
|
||||
- **5-7%**: 안정적 성장 (정상 분배)
|
||||
- **3% 미만**: 제거 위험 (알고리즘 회피)
|
||||
|
||||
**목표**: 썸네일 + 제목이 **정보 전달이 아닌 감정적 반응** 유발
|
||||
|
||||
---
|
||||
|
||||
### 첫 30초 = 알고리즘 심판 구간
|
||||
|
||||
**생존 법칙**:
|
||||
- 첫 30초 이탈 = 알고리즘 거부 신호
|
||||
- 인사, 구독 요청, 반복적 인트로 = 즉시 이탈 유발
|
||||
|
||||
**필수 4요소** (순서대로):
|
||||
1. **도발적 질문 또는 공감 진술** (0-5초)
|
||||
- "AI로 돈 벌겠다고 ChatGPT만 쓰고 계신가요?"
|
||||
- "아이디어는 있는데 실행이 안 되는 이유 아시나요?"
|
||||
|
||||
2. **즉각적 가치 제안** (5-15초)
|
||||
- "오늘 10분이면 아이디어 → 자동화 시스템으로 만듭니다"
|
||||
- "비개발자도 30분 안에 AI 직원 만드는 법"
|
||||
|
||||
3. **콘텐츠 로드맵** (15-25초)
|
||||
- "오늘 배울 3가지: 도구 설치, 첫 명령어, 자동화 테스트"
|
||||
- "1부: 문제, 2부: 해결, 3부: 실전 사례"
|
||||
|
||||
4. **감정적 훅** (25-30초)
|
||||
- 서스펜스: "7분 후 여러분은 충격받을 겁니다"
|
||||
- 공감: "저도 3개월 전까지 똑같았습니다"
|
||||
- 호기심: "이 방법, 개발자들만 쓰는 이유가 있습니다"
|
||||
|
||||
**30초 체크리스트**:
|
||||
- [ ] 인사 없음
|
||||
- [ ] 구독 요청 없음
|
||||
- [ ] 4요소 모두 포함
|
||||
- [ ] 과장 없는 구체적 약속
|
||||
- [ ] 감정적 연결 성공
|
||||
|
||||
---
|
||||
|
||||
### 채널 성장 최소 요구사항
|
||||
|
||||
**5개 비디오 법칙**:
|
||||
- YouTube는 최소 5개 영상으로 채널 신뢰도 평가
|
||||
- 1-2개 영상 = 알고리즘 지원 거의 없음
|
||||
- 일관성 있는 메시지, 톤, 주제 필수
|
||||
|
||||
**일관성 체크리스트**:
|
||||
- [ ] 타겟 시청자 일관 (비개발자, AI 입문자 등)
|
||||
- [ ] 톤앤매너 일관 (개발자적 화법, 탑다운 등)
|
||||
- [ ] 주제 연결성 (시리즈 흐름)
|
||||
- [ ] 영상 간 참여율 비슷한 수준 유지
|
||||
|
||||
---
|
||||
|
||||
### 실패 분석 프레임워크
|
||||
|
||||
**YouTube Studio 필수 분석 항목**:
|
||||
|
||||
1. **이탈 포인트 분석**
|
||||
- 어느 시점에서 대량 이탈?
|
||||
- 해당 구간의 문제: 지루함? 기대 불일치? 너무 어려움?
|
||||
|
||||
2. **참여 구간 분석**
|
||||
- 시청자가 집중한 구간은?
|
||||
- 무엇이 효과적이었나? (비유, 예시, 인식전환?)
|
||||
|
||||
3. **감정적 공감대 분석**
|
||||
- 댓글/좋아요 반응 구간
|
||||
- 어떤 메시지가 울림을 줬나?
|
||||
|
||||
**실패 → 개선 프로세스**:
|
||||
```
|
||||
실패 영상 분석 (Studio)
|
||||
↓
|
||||
이탈 구간 3곳 파악
|
||||
↓
|
||||
각 구간별 가설 설정 (왜 이탈했나?)
|
||||
↓
|
||||
다음 영상에 개선안 적용
|
||||
↓
|
||||
A/B 테스트 (이전 vs 개선)
|
||||
```
|
||||
|
||||
**실패는 데이터다**:
|
||||
- 성과 낮은 영상 = 가장 중요한 학습 자료
|
||||
- 이탈 포인트 = 다음 영상 개선 포인트
|
||||
- 5개 영상 후 패턴 파악 가능
|
||||
|
||||
---
|
||||
|
||||
## 📐 7-Section Framework (개선판)
|
||||
|
||||
### SECTION 1: HOOK (0:00-0:30) ⚠️ 생존 구간
|
||||
|
||||
**원칙**: 첫 30초 알고리즘 심판 통과 + 명확한 가치 제시
|
||||
|
||||
**최우선 체크** (알고리즘 생존):
|
||||
- [ ] **0-5초**: 도발적 질문 또는 공감 진술 (인사 금지!)
|
||||
- [ ] **5-15초**: 즉각적 가치 제안 (구독 요청 금지!)
|
||||
- [ ] **15-25초**: 콘텐츠 로드맵 명확히
|
||||
- [ ] **25-30초**: 감정적 훅 (서스펜스/공감/호기심)
|
||||
|
||||
**콘텐츠 체크** (시리즈 맥락):
|
||||
- [ ] 시리즈 흐름 제시 (오늘은 N단계, 다음은 뭐)
|
||||
- [ ] 오늘 배울 구체적 내용 나열
|
||||
- [ ] 사전 지식 vs 본 수업 구분 명확
|
||||
- [ ] 과장 표현 없음 (❌ "놀랍게도", "반드시")
|
||||
|
||||
**분석 질문**:
|
||||
1. "첫 5초에 시청자가 멈추는가?" (도발/공감)
|
||||
2. "15초 안에 '오늘 뭘 얻지' 명확한가?" (가치)
|
||||
3. "30초까지 감정적으로 연결되었나?" (훅)
|
||||
4. "시리즈 맥락을 이해하는가?" (전체 흐름)
|
||||
|
||||
**좋은 예시** (알고리즘 + 시리즈 통합):
|
||||
```
|
||||
[0-5초: 도발적 질문]
|
||||
"AI 업무 매뉴얼 없이 그냥 질문만 하고 계신가요?"
|
||||
|
||||
[5-15초: 즉각적 가치]
|
||||
"오늘 30분이면 AI가 여러분 업무를 기억하는 시스템 만듭니다.
|
||||
지난 영상에서 Claude Code 설치했죠? 이제 진짜 써봅니다."
|
||||
|
||||
[15-25초: 콘텐츠 로드맵]
|
||||
"오늘 배울 3가지:
|
||||
1. VS Code와 Claude Code가 뭔지 (5분)
|
||||
2. 왜 ChatGPT 웹이 아닌 로컬 도구인지 (3분)
|
||||
3. 첫 CLAUDE.md 파일 만들기 (5분)"
|
||||
|
||||
[25-30초: 감정적 훅]
|
||||
"이거 한 번 만들어두면, AI가 매번 여러분 맥락을 기억합니다.
|
||||
복붙 지옥 끝납니다."
|
||||
```
|
||||
|
||||
**나쁜 예시** (알고리즘 거부 유발):
|
||||
```
|
||||
❌ "안녕하세요 여러분! 오늘도 찾아와주셔서 감사합니다!" (0-5초 인사)
|
||||
❌ "구독과 좋아요 먼저 부탁드립니다!" (0-5초 구독 요청)
|
||||
❌ "오늘은 VS Code를 배웁니다" (가치 제안 없음)
|
||||
❌ "다음 영상부터 본격적으로..." (오늘은 예고편?)
|
||||
❌ "여러분! 정말 놀라운 비밀을 공개합니다!" (과장)
|
||||
```
|
||||
|
||||
**핵심**:
|
||||
- 첫 5초에 멈추게 하기 (도발/공감)
|
||||
- 30초 안에 가치 + 로드맵 + 감정 훅 완성
|
||||
- 시청자가 "전체 여정의 어디쯤 와있는지" 알게 하기
|
||||
|
||||
---
|
||||
|
||||
### SECTION 2: PROBLEM (0:30-0:45)
|
||||
|
||||
**원칙**: 감정 공감 중심, HOOK과 내용 중복 금지
|
||||
|
||||
**체크리스트**:
|
||||
- [ ] 감정적 두려움/불안 공감 (이성적 문제 나열 아님)
|
||||
- [ ] HOOK에서 다룬 내용 반복 금지
|
||||
- [ ] 간결하고 임팩트 있게 (나열식 제거)
|
||||
- [ ] "대부분 여기서 포기한다" 같은 강한 공감
|
||||
|
||||
**분석 질문**:
|
||||
1. "HOOK과 내용이 중복되는가?" (중복이면 수정 필요)
|
||||
2. "감정적으로 공감하는가? 아니면 단순 나열인가?"
|
||||
3. "지루한 전개 없이 임팩트 있는가?"
|
||||
|
||||
**좋은 예시** (감정 공감):
|
||||
```
|
||||
대부분의 비개발자가 여기서 포기합니다.
|
||||
|
||||
검은 화면만 봐도 겁이 나고,
|
||||
잘못 건드려서 망가질까 봐 손이 안 가죠.
|
||||
|
||||
그런데 솔직히 말씀드리면:
|
||||
오늘 배울 내용은 파워포인트보다 쉽습니다.
|
||||
|
||||
바로 시작하겠습니다.
|
||||
```
|
||||
|
||||
**나쁜 예시** (HOOK 중복 또는 지루한 나열):
|
||||
```
|
||||
❌ "VS Code가 뭔가요?" (HOOK에서 이미 다룸)
|
||||
❌ "Claude Code는 또 뭐고요?" (HOOK에서 이미 다룸)
|
||||
❌ "오늘 영상 끝나면:
|
||||
- VS Code 이해됨
|
||||
- Claude Code 이해됨
|
||||
- 사용할 수 있음" (지루한 나열)
|
||||
```
|
||||
|
||||
**핵심**: HOOK은 무엇을 배울지, PROBLEM은 왜 어려운지(감정)
|
||||
|
||||
---
|
||||
|
||||
### SECTION 3: AGITATE (0:45-1:45)
|
||||
|
||||
**원칙**: ChatGPT가 별로였던 **구조적 이유** 설명
|
||||
|
||||
**체크리스트**:
|
||||
- [ ] "왜 별로였는지" 구조적 한계 3가지
|
||||
- [ ] 감정이 아닌 논리로 설명
|
||||
- [ ] "내 잘못이 아니다" 재인식
|
||||
|
||||
**분석 질문**:
|
||||
1. "구조적 한계가 명확한가?"
|
||||
2. "감정적 표현 없이 논리적인가?"
|
||||
3. "시청자가 '내 탓이 아니구나' 느끼는가?"
|
||||
|
||||
**좋은 예시** (논리적, 구조적):
|
||||
```
|
||||
ChatGPT 웹사이트의 구조적 한계:
|
||||
|
||||
한계 1: 맥락을 매번 설명해야 함
|
||||
→ 복붙 반복 → 귀찮아서 안 씀
|
||||
|
||||
한계 2: 범용 답변만 나올 수밖에 없음
|
||||
→ 내 상황을 모르니까
|
||||
|
||||
한계 3: 대화 길어지면 앞 내용 까먹음
|
||||
→ 일관성 깨짐
|
||||
```
|
||||
|
||||
**나쁜 예시**:
|
||||
```
|
||||
❌ "정말 답답하셨죠?"
|
||||
❌ "엄청 실망스러우셨을 거예요"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### SECTION 4: 인식전환 (1:45-3:15) ⭐ 핵심
|
||||
|
||||
**원칙**: 충분한 설명 + 구체적 대비
|
||||
|
||||
**체크리스트**:
|
||||
- [ ] 두 그룹 명확한 대비
|
||||
- [ ] 구체적 행동 차이 제시
|
||||
- [ ] "왜 이게 중요한가" 논리적 설명
|
||||
- [ ] 충분한 시간 할애 (90초)
|
||||
|
||||
**분석 질문**:
|
||||
1. "두 그룹의 차이가 명확한가?"
|
||||
2. "추상적 태도가 아닌 구체적 행동인가?"
|
||||
3. "왜 중요한지 논리적으로 설명했는가?"
|
||||
|
||||
**좋은 예시** (충분한 설명):
|
||||
```
|
||||
두 그룹으로 나눕니다.
|
||||
|
||||
첫 번째: "AI를 도구로 보는 사람"
|
||||
- "가끔 질문하면 되지"
|
||||
- "범용 답변이면 그냥 참고만"
|
||||
- "정리되면 그때 배우지"
|
||||
|
||||
두 번째: "AI를 직원으로 만드는 사람"
|
||||
- "범용 답변? 당연하지, 맥락을 안 줬으니까"
|
||||
- "어떻게 학습시킬까?" 끊임없이 고민
|
||||
- "지금 도구로 시스템 만들기"
|
||||
|
||||
핵심 차이:
|
||||
첫 번째는 AI를 계산기처럼 봅니다.
|
||||
두 번째는 AI를 신입직원처럼 훈련시킵니다.
|
||||
|
||||
[90초 동안 충분히 설명]
|
||||
```
|
||||
|
||||
**나쁜 예시** (너무 짧거나 추상적):
|
||||
```
|
||||
❌ "마인드셋이 다릅니다" (추상적)
|
||||
❌ 30초 만에 급하게 넘어감 (불충분)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### SECTION 5: 핵심 열쇠 공개 (3:15-4:00)
|
||||
|
||||
**원칙**: 탑다운으로 바로 공개
|
||||
|
||||
**체크리스트**:
|
||||
- [ ] "비밀은 이겁니다" 바로 공개
|
||||
- [ ] 로컬 LLM vs Web UI 구조적 차이
|
||||
- [ ] Claude Code 소개
|
||||
|
||||
**분석 질문**:
|
||||
1. "비밀을 바로 공개했는가?"
|
||||
2. "구조적 차이가 명확한가?"
|
||||
3. "뜸들이지 않았는가?"
|
||||
|
||||
**좋은 예시** (탑다운):
|
||||
```
|
||||
두 번째 그룹의 비밀 공개합니다.
|
||||
|
||||
LLM을 로컬에 설치해서 사용합니다.
|
||||
|
||||
핵심 차이:
|
||||
AI가 내 컴퓨터 파일을 직접 읽습니다.
|
||||
|
||||
이게 왜 중요한가?
|
||||
- Web UI: 맥락 매번 복붙
|
||||
- 로컬 LLM: 프로젝트 전체 이해
|
||||
|
||||
대표 사례: Claude Code
|
||||
```
|
||||
|
||||
**나쁜 예시**:
|
||||
```
|
||||
❌ "그럼 비밀이 뭘까요? 조금만 기다려주세요..."
|
||||
❌ "먼저 배경부터 설명하면..."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### SECTION 6: 비전 제시 (4:00-4:45)
|
||||
|
||||
**원칙**: 구체적 사례 + 실현 가능성
|
||||
|
||||
**체크리스트**:
|
||||
- [ ] 3가지 구체적 결과물
|
||||
- [ ] 과장 없는 실제 사례
|
||||
- [ ] "천재 아냐?" 우려 해소
|
||||
|
||||
**좋은 예시**:
|
||||
```
|
||||
만들 수 있는 것:
|
||||
|
||||
1. 초지능 비서 (맥락 완벽 이해)
|
||||
2. 전담 에이전트 (업무별 담당자)
|
||||
3. AI 조직 (에이전트 협업)
|
||||
|
||||
실제 사례:
|
||||
개발자 1명이 AI로 월 1억 SaaS 혼자 운영
|
||||
|
||||
"천재들 이야기 아냐?"
|
||||
아닙니다. 핵심은 "맥락 학습 방법"입니다.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### SECTION 7: VALUE DELIVERY (4:45-7:30)
|
||||
|
||||
**원칙**: 실행 가능한 단계별 가이드, 기초부터 차근차근
|
||||
|
||||
**체크리스트**:
|
||||
- [ ] 도구가 뭔지부터 설명 (정의 → 이유 → 사용법 순서)
|
||||
- [ ] 비유/비교로 쉽게 이해시키기
|
||||
- [ ] 갑자기 파일 구조 설명 금지 (도구 이해 먼저)
|
||||
- [ ] 각 단계마다 구체적 실행 방법
|
||||
|
||||
**분석 질문**:
|
||||
1. "도구가 뭔지 정의부터 시작했는가?"
|
||||
2. "비개발자가 이해할 수 있는 비유가 있는가?"
|
||||
3. "전개가 논리적인가? (도구 소개 → 사용법 → 파일 구조)"
|
||||
|
||||
**좋은 예시** (기초부터):
|
||||
```
|
||||
## VALUE DELIVERY 1: VS Code가 뭔지 이해하기
|
||||
|
||||
VS Code = Visual Studio Code
|
||||
- 마이크로소프트가 만든 무료 프로그램
|
||||
- 텍스트 편집기의 고급 버전
|
||||
|
||||
쉽게 비유하면:
|
||||
- 워드/한글 = 문서 작성 도구
|
||||
- VS Code = 코드/파일 작성 도구
|
||||
|
||||
왜 이걸 써야 하나?
|
||||
1. 파일 관리가 편함
|
||||
2. Claude와 연동됨
|
||||
3. 무료
|
||||
|
||||
[이후 화면 구성, 사용법 설명]
|
||||
|
||||
## VALUE DELIVERY 2: Claude Code가 뭔지 이해하기
|
||||
|
||||
Claude Code = VS Code에서 작동하는 Claude AI
|
||||
|
||||
웹 Claude와의 차이:
|
||||
[표로 비교]
|
||||
|
||||
왜 Claude Code를 써야 하나?
|
||||
[예시로 이해시키기]
|
||||
|
||||
[이후 실행 방법]
|
||||
```
|
||||
|
||||
**나쁜 예시** (갑작스러운 전개):
|
||||
```
|
||||
❌ "CLAUDE.md 파일을 만드세요" (VS Code가 뭔지도 모르는데?)
|
||||
❌ "rules/ 폴더를 만들고..." (Claude Code가 뭔지도 모르는데?)
|
||||
❌ "프로젝트 폴더 개념입니다" (VS Code 설명 생략?)
|
||||
```
|
||||
|
||||
**핵심**: 도구가 뭔지 → 왜 필요한지 → 어떻게 쓰는지 순서
|
||||
|
||||
---
|
||||
|
||||
### SECTION 8: CTA (9:00-10:00)
|
||||
|
||||
**원칙**: 명확한 다음 행동 3가지
|
||||
|
||||
**체크리스트**:
|
||||
- [ ] 오늘 할 일 3가지
|
||||
- [ ] 다음 영상 예고
|
||||
- [ ] 과장 없는 현실적 약속
|
||||
|
||||
**좋은 예시**:
|
||||
```
|
||||
오늘 할 일 3가지:
|
||||
|
||||
1. Claude Code 설치 (링크 확인)
|
||||
2. 첫 프로젝트 폴더 만들기
|
||||
3. 업무 태스크 적어보기
|
||||
|
||||
다음 영상:
|
||||
Custom Commands, SubAgents, Skills
|
||||
→ 실전 AI 에이전트 만들기
|
||||
|
||||
구독 + 알림 설정
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 💬 Coaching Flow
|
||||
|
||||
### 1️⃣ 대본 접수
|
||||
|
||||
```
|
||||
[탑다운 분석]
|
||||
|
||||
전체 구조:
|
||||
- HOOK: [상태]
|
||||
- 인식전환: [상태]
|
||||
- 핵심 공개: [상태]
|
||||
|
||||
가장 시급한 개선:
|
||||
1. [구체적 문제]
|
||||
2. [구체적 문제]
|
||||
|
||||
질문 3가지:
|
||||
[...]
|
||||
```
|
||||
|
||||
### 2️⃣ 섹션별 피드백
|
||||
|
||||
```
|
||||
[섹션명] 분석
|
||||
|
||||
현재 상태:
|
||||
[사용자 작성 내용]
|
||||
|
||||
문제:
|
||||
[구조적 이유]
|
||||
|
||||
개선 방향:
|
||||
[구체적 질문 3개]
|
||||
```
|
||||
|
||||
### 3️⃣ 반복 개선
|
||||
|
||||
한 섹션씩 완성 → 다음 섹션
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Output Format
|
||||
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
📊 대본 분석
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
|
||||
🎯 전체 구조:
|
||||
HOOK: ✅/⚠️/❌
|
||||
인식전환: ✅/⚠️/❌
|
||||
핵심 공개: ✅/⚠️/❌
|
||||
VALUE: ✅/⚠️/❌
|
||||
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
⚠️ 시급한 개선 (우선순위)
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
|
||||
1. [섹션]: [문제] → [이유]
|
||||
2. [섹션]: [문제] → [이유]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
🤔 구체화 질문
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Q1. [...]
|
||||
Q2. [...]
|
||||
Q3. [...]
|
||||
|
||||
━━━━━━━━━━━━━━━━━━
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚫 Coaching Principles
|
||||
|
||||
### DO ✅
|
||||
1. **탑다운 피드백**: 결론 → 이유 → 예시
|
||||
2. **구체적 질문**: "타겟이 누구인가?" (명확)
|
||||
3. **논리적 설명**: "왜 문제인지" 구조적 이유
|
||||
4. **개발자적 화법**: 증거 기반, 논리적
|
||||
5. **비즈니스 관점**: 실용성, 실행 가능성
|
||||
|
||||
### DON'T ❌
|
||||
1. **과장 표현**: "놀랍게도", "반드시"
|
||||
2. **감정적 피드백**: "정말 좋아요!"
|
||||
3. **뜸들이기**: 결론을 나중에 공개
|
||||
4. **모호한 조언**: "더 구체적으로"
|
||||
5. **프레임워크 무시**: 즉흥 조언
|
||||
|
||||
---
|
||||
|
||||
## 📌 사용자 선호도 체크리스트
|
||||
|
||||
모든 피드백은 다음 기준으로:
|
||||
|
||||
- [ ] 탑다운 명확성 (결론부터)
|
||||
- [ ] 시원시원한 전개 (뜸들이기 없음)
|
||||
- [ ] 개발자적 화법 (논리적, 구조적)
|
||||
- [ ] 비즈니스 관점 (실용성)
|
||||
- [ ] 과장 표현 제거
|
||||
- [ ] 인식전환 구간 충분한 설명
|
||||
- [ ] 강조 구간 명확한 근거
|
||||
- [ ] 예시 구간 구체적 사례
|
||||
|
||||
---
|
||||
|
||||
**Version**: v2.3 (YouTube Algorithm Survival Guide 추가)
|
||||
**Last Updated**: 2025-01-18
|
||||
|
||||
---
|
||||
|
||||
## 🆕 v2.3 주요 개선 사항 (Algorithm Update)
|
||||
|
||||
### 1. YouTube Algorithm Survival Guide 섹션 신규 추가
|
||||
- **CTR 기준 명확화**: 8% = 바이럴, 3% = 위험
|
||||
- **첫 30초 생존 전략**: 4요소 체크리스트 (도발→가치→로드맵→훅)
|
||||
- **5개 비디오 법칙**: 채널 신뢰도 평가 기준
|
||||
- **실패 분석 프레임워크**: YouTube Studio 활용법
|
||||
|
||||
### 2. HOOK 섹션: 알고리즘 최적화 강화
|
||||
- 첫 30초를 "생존 구간"으로 재정의
|
||||
- 0-5초, 5-15초, 15-25초, 25-30초 세부 구간 체크리스트
|
||||
- 알고리즘 거부 유발 요소 명확화 (인사, 구독 요청)
|
||||
- 도발적 질문 + 즉각적 가치 + 감정적 훅 통합 예시
|
||||
|
||||
### 3. 데이터 기반 개선 프로세스
|
||||
- YouTube Studio 필수 분석 항목 (이탈, 참여, 감정)
|
||||
- 실패 → 개선 사이클 프로세스
|
||||
- "실패는 데이터다" 마인드셋
|
||||
|
||||
---
|
||||
|
||||
## 🔄 v2.2 개선 사항 (유지)
|
||||
|
||||
### HOOK/PROBLEM 중복 제거
|
||||
- HOOK은 무엇을 배울지, PROBLEM은 왜 어려운지(감정)
|
||||
- 시리즈 컨텍스트 명확화
|
||||
|
||||
### VALUE DELIVERY 논리적 전개
|
||||
- 도구 정의 → 이유 → 사용법 순서
|
||||
- 비유/비교로 비개발자 이해도 향상
|
||||
BIN
.specify/.DS_Store
vendored
Normal file
BIN
.specify/.DS_Store
vendored
Normal file
Binary file not shown.
115
.specify/templates/spec-template.md
Normal file
115
.specify/templates/spec-template.md
Normal file
@@ -0,0 +1,115 @@
|
||||
# Feature Specification: [FEATURE NAME]
|
||||
|
||||
**Feature Branch**: `[###-feature-name]`
|
||||
**Created**: [DATE]
|
||||
**Status**: Draft
|
||||
**Input**: User description: "$ARGUMENTS"
|
||||
|
||||
## User Scenarios & Testing *(mandatory)*
|
||||
|
||||
<!--
|
||||
IMPORTANT: User stories should be PRIORITIZED as user journeys ordered by importance.
|
||||
Each user story/journey must be INDEPENDENTLY TESTABLE - meaning if you implement just ONE of them,
|
||||
you should still have a viable MVP (Minimum Viable Product) that delivers value.
|
||||
|
||||
Assign priorities (P1, P2, P3, etc.) to each story, where P1 is the most critical.
|
||||
Think of each story as a standalone slice of functionality that can be:
|
||||
- Developed independently
|
||||
- Tested independently
|
||||
- Deployed independently
|
||||
- Demonstrated to users independently
|
||||
-->
|
||||
|
||||
### User Story 1 - [Brief Title] (Priority: P1)
|
||||
|
||||
[Describe this user journey in plain language]
|
||||
|
||||
**Why this priority**: [Explain the value and why it has this priority level]
|
||||
|
||||
**Independent Test**: [Describe how this can be tested independently - e.g., "Can be fully tested by [specific action] and delivers [specific value]"]
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
||||
2. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - [Brief Title] (Priority: P2)
|
||||
|
||||
[Describe this user journey in plain language]
|
||||
|
||||
**Why this priority**: [Explain the value and why it has this priority level]
|
||||
|
||||
**Independent Test**: [Describe how this can be tested independently]
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - [Brief Title] (Priority: P3)
|
||||
|
||||
[Describe this user journey in plain language]
|
||||
|
||||
**Why this priority**: [Explain the value and why it has this priority level]
|
||||
|
||||
**Independent Test**: [Describe how this can be tested independently]
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
||||
|
||||
---
|
||||
|
||||
[Add more user stories as needed, each with an assigned priority]
|
||||
|
||||
### Edge Cases
|
||||
|
||||
<!--
|
||||
ACTION REQUIRED: The content in this section represents placeholders.
|
||||
Fill them out with the right edge cases.
|
||||
-->
|
||||
|
||||
- What happens when [boundary condition]?
|
||||
- How does system handle [error scenario]?
|
||||
|
||||
## Requirements *(mandatory)*
|
||||
|
||||
<!--
|
||||
ACTION REQUIRED: The content in this section represents placeholders.
|
||||
Fill them out with the right functional requirements.
|
||||
-->
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST [specific capability, e.g., "allow users to create accounts"]
|
||||
- **FR-002**: System MUST [specific capability, e.g., "validate email addresses"]
|
||||
- **FR-003**: Users MUST be able to [key interaction, e.g., "reset their password"]
|
||||
- **FR-004**: System MUST [data requirement, e.g., "persist user preferences"]
|
||||
- **FR-005**: System MUST [behavior, e.g., "log all security events"]
|
||||
|
||||
*Example of marking unclear requirements:*
|
||||
|
||||
- **FR-006**: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]
|
||||
- **FR-007**: System MUST retain user data for [NEEDS CLARIFICATION: retention period not specified]
|
||||
|
||||
### Key Entities *(include if feature involves data)*
|
||||
|
||||
- **[Entity 1]**: [What it represents, key attributes without implementation]
|
||||
- **[Entity 2]**: [What it represents, relationships to other entities]
|
||||
|
||||
## Success Criteria *(mandatory)*
|
||||
|
||||
<!--
|
||||
ACTION REQUIRED: Define measurable success criteria.
|
||||
These must be technology-agnostic and measurable.
|
||||
-->
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: [Measurable metric, e.g., "Users can complete account creation in under 2 minutes"]
|
||||
- **SC-002**: [Measurable metric, e.g., "System handles 1000 concurrent users without degradation"]
|
||||
- **SC-003**: [User satisfaction metric, e.g., "90% of users successfully complete primary task on first attempt"]
|
||||
- **SC-004**: [Business metric, e.g., "Reduce support tickets related to [X] by 50%"]
|
||||
Reference in New Issue
Block a user