Menü
사용자 관점에서 제품 요구사항을 정의할 때 INVEST 원칙을 따르는 포괄적인 유저스토리를 작성합니다.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
MVP(Minimum Viable Product) 주제를 정의하고 목표 비즈니스 도메인을 선정합니다. 새 프로젝트 시작, 비즈니스 아이디어 브레인스토밍, 서비스 범위 정의 시 사용하세요.
JTBD(Jobs To Be Done) 프레임워크를 사용하여 타겟 고객 유형을 정의합니다. 고객 세그먼트와 핵심 job을 이해할 때 사용하세요.
MVP 주제와 고객 유형을 바탕으로 프로젝트 팀 구성 및 협업 지침을 작성합니다. 프로젝트 시작 시 사용하세요. (project)
시장 기회, 경쟁, 트렌드를 평가할 때 포괄적인 시장 조사 분석을 수행합니다.
고객유형 대상으로 현재 고객경험 단계를 정의합니다. 고객경험 조사 전 사용하세요.
인터뷰, 관찰, 제품 테스트를 통해 포괄적인 고객 경험 데이터를 생성합니다. 고객 여정 맵 작성 준비 시 사용하세요.
Basierend auf der SOC-Berufsklassifikation
| 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: 모든 완료 기준 충족 필요
유저스토리 작성 완료 후: