Menu
사용자 관점에서 제품 요구사항을 정의할 때 INVEST 원칙을 따르는 포괄적인 유저스토리를 작성합니다.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
MVP(Minimum Viable Product) 주제를 정의하고 목표 비즈니스 도메인을 선정합니다. 새 프로젝트 시작, 비즈니스 아이디어 브레인스토밍, 서비스 범위 정의 시 사용하세요.
JTBD(Jobs To Be Done) 프레임워크를 사용하여 타겟 고객 유형을 정의합니다. 고객 세그먼트와 핵심 job을 이해할 때 사용하세요.
MVP 주제와 고객 유형을 바탕으로 프로젝트 팀 구성 및 협업 지침을 작성합니다. 프로젝트 시작 시 사용하세요. (project)
시장 기회, 경쟁, 트렌드를 평가할 때 포괄적인 시장 조사 분석을 수행합니다.
고객유형 대상으로 현재 고객경험 단계를 정의합니다. 고객경험 조사 전 사용하세요.
인터뷰, 관찰, 제품 테스트를 통해 포괄적인 고객 경험 데이터를 생성합니다. 고객 여정 맵 작성 준비 시 사용하세요.
| name | user-stories |
| description | 사용자 관점에서 제품 요구사항을 정의할 때 INVEST 원칙을 따르는 포괄적인 유저스토리를 작성합니다. |
선정된 솔루션과 Event Storming 결과를 기반으로 체계적인 유저스토리를 작성합니다.
think/핵심솔루션.md (solution-selection 결과)define/고객분석.md (customer-analysis 결과)think/es/userflow.pumlthink/es/{순번}-{유저플로우명}.pumlreference/sample_유저스토리.mdEvent Storming 결과에서 유저스토리를 도출하는 가이드입니다.
| Event Storming 요소 | User Story 요소 | 설명 |
|---|---|---|
| 유저플로우(제목) | Epic | 주요 비즈니스 기능 단위 |
| 이벤트 [이벤트] | Story (I want to...) | 사용자가 달성하고 싶은 결과 |
| 커맨드 [커맨드] | 시나리오/Task | 결과를 달성하기 위한 구체적 행동 |
| 정책/규칙 [정책/규칙] | Acceptance Criteria | 비즈니스 규칙 및 제약사항 |
| 데이터 [데이터] | 입력/출력 요구사항 | 필요한 데이터 정의 |
| 참여자 (Actor) | Persona (As a...) | 스토리의 주체 |
핵심 원칙: 사용자는 "버튼을 클릭하고 싶은 것"이 아니라 "결과를 달성하고 싶은 것"입니다.
- 커맨드(Command): How (방법) - 시스템에 요청하는 행동
- 이벤트(Event): What (목표) - 달성하고 싶은 결과/상태변화
각 유저플로우 파일이 하나의 Epic이 됩니다. 예시)
| 파일명 | Epic |
|--------|------|
| `01-회원가입.puml` | Epic 1: 사용자 인증 |
| `02-차량등록및AI검증.puml` | Epic 2: 차량 등록 및 검증 |
변환 공식:
{사용자 유형}으로서 | 나는, {목적}을 위해 | {이벤트/결과}를 원한다.
예시 (01-회원가입.puml 기준):
| 이벤트 | User Story |
|---|---|
[이벤트] 카카오 인증 완료됨 | 사용자로서 | 나는, 복잡한 입력 없이 빠르게 가입하기 위해 | 카카오 계정으로 인증을 완료하고 싶다. |
[이벤트] 이메일 인증 완료됨 | 사용자로서 | 나는, SNS 없이 가입하기 위해 | 이메일 인증을 완료하고 싶다. |
[이벤트] 본인인증 완료됨 | 사용자로서 | 나는, 안전한 거래 환경에 참여하기 위해 | 본인인증을 완료하고 싶다. |
[이벤트] 회원가입 완료됨 | 사용자로서 | 나는, 서비스를 이용하기 위해 | 회원가입을 완료하고 싶다. |
커맨드는 User Story의 시나리오 또는 구현 Task로 변환됩니다.
예시:
### UFR-USER-010: [회원가입] 사용자로서 | 나는, 서비스를 이용하기 위해 | 회원가입을 완료하고 싶다.
- 시나리오 1: 카카오 간편가입
회원가입 화면에서 | [커맨드] 카카오 로그인 버튼을 클릭하면 | 카카오 인증 후 가입이 완료된다.
- 시나리오 2: 이메일 가입
회원가입 화면에서 | [커맨드] 이메일/비밀번호를 입력하고 인증하면 | 이메일 인증 후 가입이 완료된다.
시퀀스 다이어그램의 [정책/규칙] 노트가 Acceptance Criteria(인수조건)가 됩니다.
(E)로 표시된 외부 시스템 연동은 별도 Technical Story로 분리합니다.
Event Storming 결과에서 마이크로서비스를 도출하는 5단계 프로세스입니다.
유저플로우별 이벤트를 비즈니스 개념 기준으로 그룹화합니다.
[방법]
1. 각 .puml 파일에서 [이벤트] 추출
2. 동일 비즈니스 개념 이벤트 묶기
3. 동일 액터가 주로 사용하는 이벤트 확인
[예시]
인증 클러스터: 회원가입 완료됨, 로그인 완료됨, 인증 완료됨
주문 클러스터: 주문 생성됨, 주문 취소됨, 주문 완료됨
이벤트가 변경하는 엔티티와 생명주기를 파악합니다.
| 분석 항목 | 질문 |
|---|---|
| 상태 변경 | 이 이벤트가 어떤 엔티티의 상태를 변경하는가? |
| 생명주기 | 생성-수정-삭제 사이클이 같은 엔티티는? |
| 불변식 | 항상 함께 검증되어야 하는 규칙은? |
[예시]
주문 Aggregate: Order(Root), OrderItem, OrderStatus
회원 Aggregate: Member(Root), Profile, Address
Aggregate와 정책/규칙을 묶어 컨텍스트 경계를 설정합니다.
[경계 설정 기준]
- 유비쿼터스 언어: 같은 용어가 같은 의미로 사용되는 범위
- 정책 귀속: [정책/규칙]이 적용되는 범위
- 팀 책임: 단일 팀이 책임질 수 있는 범위
컨텍스트 간 관계와 통신 패턴을 정의합니다.
| 관계 유형 | 설명 | 통신 패턴 |
|---|---|---|
| Customer-Supplier | 요청-응답 관계 | 동기 호출 |
| Conformist | 상위 서비스 모델 따름 | 동기 호출 |
| Published Language | 표준 이벤트 공유 | 비동기 이벤트 |
| Anti-Corruption Layer | 모델 변환 계층 필요 | 어댑터 패턴 |
아래 기준을 적용하여 최종 마이크로서비스를 도출합니다.
| 기준 | 설명 |
|---|---|
| 차별화 핵심 | 비즈니스 경쟁력 원천 기능 |
| 부하 변동 | 스케일링 패턴이 다름 |
| 변경 빈도 | 배포 주기가 다름 |
| 데이터 소유 | 별도 Aggregate Root 소유 |
| 기준 | 지표 |
|---|---|
| 트랜잭션 경계 | 강한 일관성 필요 |
| 서비스 크기 | 코드 5,000줄 미만 |
| 호출 빈도 | 동기 호출 90% 이상 |
| 운영 복잡도 | 팀당 3-5개 서비스 적정 |
초기에는 운영 복잡도를 낮추기 위해 관련 컨텍스트를 병합하고, 트래픽/복잡도 증가 시 분리합니다.
[병합 예시]
회원 + 알림 → 회원서비스 (분리 트리거: 알림 처리량 > 10,000건/시간)
주문 + 결제 → 거래서비스 (분리 트리거: 결제 기능 복잡화)
유저스토리는 마이크로서비스 단위로 구성합니다:
마이크로서비스는 '마이크로서비스 정의 가이드'에 따라 정의합니다.
'MVP 단계 병합 전략'에 따라 운영 복잡도를 낮추기 위해 관련 컨텍스트는 병합합니다.
각 유저스토리는 다음 형식을 따릅니다:
예시:
UFR-USER-010: [회원가입] 구매자로서 | 나는, 서비스를 이용하기 위해 | 간편하게 회원가입하고 싶다.UFR-CORE-020: [주문하기] 구매자로서 | 나는, 상품을 구매하기 위해 | 쉽게 주문하고 싶다.각 UFR은 다음 구조로 상세화합니다:
{상황 설명} | {조건} | {결과}
[입력 요구사항]
[검증 요구사항]
[처리 결과]
우선순위 표기법:
예시: M/13 → Must Have, 13 포인트
복잡한 구현이 필요한 스토리는 기술 태스크를 분리합니다:
각 역할 정의:
계층 구조 생성:
User Service
├── UFR-USER-010: 회원가입
├── UFR-USER-020: 로그인
└── UFR-USER-030: 프로필 관리
Core Service
├── UFR-CORE-010: [기능 1]
├── UFR-CORE-020: [기능 2]
└── UFR-CORE-030: [기능 3]
[이후 스프린트 계속]
체크리스트:
| UFR ID | 리스크/이슈 | 영향도 | 완화 전략 |
|---|---|---|---|
| UFR-XXX-### | [리스크] | 높음 | [전략] |
유저스토리는 반드시 INVEST를 따라야 함:
유저스토리 예시
# 유저스토리
## User Service
### UFR-USER-010: [회원가입] 사용자로서 | 나는 서비스를 이용하기 위해 | 간편하게 회원가입하고 싶다.
- 시나리오: 신규 회원가입
미로그인 상태에서 회원가입 화면에 접근한 상황에서 | 필수 정보를 모두 입력하고 회원가입 버튼을 클릭하면 | 가입이 완료되고 로그인 화면으로 이동한다.
[입력 요구사항]
- 기본 정보
- 이름: 2자 이상 (한글/영문)
- 이메일: 유효한 이메일 형식
- 비밀번호: 8자 이상, 영문+숫자+특수문자
- 추가 정보
- 닉네임: 2-10자 (선택)
- 프로필 이미지: JPG/PNG, 최대 5MB (선택)
[검증 요구사항]
- 이메일 중복 확인: 기존 회원과 중복 불가
- 비밀번호 강도: 보안 정책 준수
- 필수 입력: 이름, 이메일, 비밀번호
[처리 결과]
- 성공 시
- 회원 정보 DB 저장
- 환영 이메일 발송
- 로그인 화면으로 리디렉션
- 실패 시
- 이메일 중복: "이미 사용 중인 이메일입니다" 메시지
- 유효성 오류: 해당 필드에 오류 메시지 표시
- M/13
---
(다음 스토리 반복)
## 사용자 역할
### 역할 1: {역할명}
- **설명**: {역할 설명}
- **권한**: {권한 목록}
- **목표**: {역할의 주요 목표}
### 역할 2: {역할명}
- **설명**: {역할 설명}
- **권한**: {권한 목록}
- **목표**: {역할의 주요 목표}
## Feature Story Map
\```
User Service
├── UFR-USER-010: 회원가입
├── UFR-USER-020: 로그인
└── UFR-USER-030: 프로필 관리
Core Service
├── UFR-CORE-010: {스토리 제목}
├── UFR-CORE-020: {스토리 제목}
└── UFR-CORE-030: {스토리 제목}
\```
## 우선순위 매트릭스
### Must Have (P0) - 필수
1. UFR-USER-010: 회원가입 - 서비스 이용을 위한 필수 기능
2. UFR-CORE-020: {제목} - {설명}
### Should Have (P1) - 중요
1. UFR-USER-030: {제목} - {설명}
2. UFR-CORE-030: {제목} - {설명}
### Could Have (P2) - 선택
1. UFR-XXX-###: {제목} - {설명}
### Won't Have - 향후 고려
1. UFR-XXX-###: {제목} - {설명}
## 스프린트 계획 (MVP 기준)
### Sprint 1 (1-2주차)
**Sprint 목표**: {스프린트의 핵심 목표}
- [ ] UFR-USER-010: 회원가입 (M/5)
- [ ] UFR-USER-020: 로그인 (M/3)
- [ ] UFR-CORE-010: {제목} (S/2)
**총 Story Points**: 10
**예상 완료일**: {날짜}
### Sprint 2 (3-4주차)
**Sprint 목표**: {스프린트의 핵심 목표}
- [ ] UFR-CORE-020: {제목} (M/8)
- [ ] UFR-USER-030: {제목} (S/5)
**총 Story Points**: 13
**예상 완료일**: {날짜}
(이후 스프린트 계속)
## 비기능적 요구사항
### 성능 요구사항
- **페이지 로드 시간**: 3G 네트워크에서 3초 이내, WiFi에서 1초 이내
- **API 응답 시간**: 200ms 이내
- **동시 사용자 처리**: 1000명 이상
- **트랜잭션 처리량**: 초당 100건 이상
### 보안 요구사항
- **HTTPS 적용**: 모든 통신 암호화
- **인증/권한 관리**: JWT 또는 OAuth 기반
- **데이터 암호화**: 민감 데이터 암호화 저장
- **보안 감사**: 정기적인 보안 점검
### 사용성 요구사항
- **모바일 반응형**: 모든 기기에서 최적화된 화면
- **접근성**: WCAG 2.1 AA 이상 준수
- **다국어 지원**: 최소 2개 언어 지원
- **브라우저 호환성**: Chrome, Safari, Firefox, Edge 최신 2개 버전
### 확장성 요구사항
- **수평 확장**: 트래픽 증가 시 서버 추가 가능
- **클라우드 네이티브**: 클라우드 환경 최적화
- **마이크로서비스**: 서비스 독립 배포 가능
- **캐싱 전략**: Redis 기반 캐싱
## Definition of Done
각 스토리 완료 기준:
### 개발 완료
- [ ] 코드 작성 완료
- [ ] 코드 리뷰 완료 (최소 1명)
- [ ] 코딩 스타일 가이드 준수
- [ ] 기술 부채 최소화
### 테스트 완료
- [ ] 단위 테스트 작성 및 통과 (커버리지 80% 이상)
- [ ] 통합 테스트 통과
- [ ] E2E 테스트 통과 (주요 플로우)
- [ ] 성능 테스트 통과
### 문서화 완료
- [ ] 코드 주석 작성
- [ ] API 문서 업데이트
- [ ] 사용자 가이드 업데이트
- [ ] 변경 사항 로그 작성
### 배포 완료
- [ ] 스테이징 환경 배포
- [ ] QA 검증 완료
- [ ] 프로덕션 배포 승인
- [ ] 프로덕션 배포 완료
## 리스크 및 의존성
### 리스크 관리
| UFR ID | 리스크/이슈 | 영향도 | 발생 가능성 | 완화 전략 | 담당자 |
|----------|-----------|--------|-----------|----------|--------|
| UFR-USER-010 | {리스크 설명} | 높음 | 중간 | {완화 전략} | {담당자} |
| UFR-CORE-020 | {리스크 설명} | 중간 | 높음 | {완화 전략} | {담당자} |
### 의존성 관리
| UFR ID | 의존하는 스토리 | 의존성 타입 | 해결 방법 |
|----------|--------------|-----------|----------|
| UFR-CORE-020 | UFR-USER-010 | 기술적 의존성 | {해결 방법} |
| UFR-XXX-### | UFR-CORE-020 | 비즈니스 의존성 | {해결 방법} |
복잡한 유저스토리 분석과 우선순위 결정이 필요할 때 Sequential MCP를 활용하여 체계적으로 백로그를 구성하세요.
design/userstory.mdUFR 포맷 준수: UFR-{서비스}-{일련번호} 형식 엄격히 사용
일련번호: 각 서비스별로 '010'부터 시작하여 10씩 증가시킴
시나리오 구조 필수: [입력 요구사항], [검증 요구사항], [처리 결과] 모두 작성
우선순위 표기: M/S/C + Story Points (피보나치) 형식 사용
최소 20개 이상: 충분한 UFR로 MVP 범위 정의
Event Storming 연계: ES 결과를 UFR로 체계적 변환
마이크로서비스 구조: 서비스별로 명확히 그룹화
기술 태스크: 복잡한 스토리는 Frontend/Backend/Infrastructure 분리
INVEST 원칙: 독립성, 협상가능성, 가치, 추정가능성, 작은 크기, 테스트가능성
비기능적 요구사항: 성능, 보안, 사용성, 확장성 필수 포함
Definition of Done: 모든 완료 기준 충족 필요
유저스토리 작성 완료 후: