陌讯skills聚合平台

user-stories

📁 cna-bootcamp/clauding-guide 📅 Feb 13, 2026
2
总安装量
2
周安装量
#63971
全站排名
安装命令
npx skills add https://github.com/cna-bootcamp/clauding-guide --skill user-stories

Agent 安装分布

amp 2
gemini-cli 2
github-copilot 2
codex 2
kimi-cli 2
cursor 2

Skill 文档

유저스토리 작성

목적

선정된 솔루션과 Event Storming 결과를 기반으로 체계적인 유저스토리를 작성합니다.

사용 시점

  • Event Storming이 완료된 후
  • UI/UX 디자인 전
  • 개발 우선순위를 정의해야 할 때
  • 사용자가 “유저스토리”, “User Story”, “백로그”를 언급할 때

필수 입력

  • 선정된 솔루션: think/핵심솔루션.md (solution-selection ê²°ê³¼)
  • 타겟 고객 정의: define/고객분석.md (customer-analysis ê²°ê³¼)
  • Event Storming ê²°ê³¼ (event-storming ê²°ê³¼):
    • think/es/userflow.puml
    • think/es/{순번}-{유저플로우명}.puml
  • 유저스토리 샘플 참고: reference/sample_유저스토리.md

이벤트스토밍 → 유저스토리 연결 가이드

Event Storming 결과에서 유저스토리를 도출하는 가이드입니다.

1. 매핑 기본 원칙

Event Storming 요소 User Story 요소 설명
유저플로우(제목) Epic 주요 비즈니스 기능 단위
이벤트 [이벤트] Story (I want to…) 사용자가 달성하고 싶은 ê²°ê³¼
커맨드 [커맨드] 시나리오/Task 결과를 달성하기 위한 구체적 행동
정책/규칙 [정책/규칙] Acceptance Criteria 비즈니스 규칙 및 제약사항
데이터 [데이터] 입력/출력 요구사항 필요한 데이터 정의
참여자 (Actor) Persona (As a…) 스토리의 주체

핵심 원칙: 사용자는 “버튼을 클릭하고 싶은 것”이 아니라 “결과를 달성하고 싶은 것”입니다.

  • 커맨드(Command): How (방법) – 시스템에 요청하는 행동
  • 이벤트(Event): What (목표) – 달성하고 싶은 ê²°ê³¼/상태변화

2. 유저플로우 → Epic 변환

각 유저플로우 파일이 하나의 Epic이 됩니다. 예시)

| 파일명 | Epic |
|--------|------|
| `01-회원가입.puml` | Epic 1: 사용자 인증 |
| `02-차량등록및AI검증.puml` | Epic 2: 차량 등록 및 검증 |

3. 이벤트 → User Story 변환

변환 공식:

{사용자 유형}으로서 | 나는, {목적}을 위해 | {이벤트/결과}를 원한다.

예시 (01-회원가입.puml 기준):

이벤트 User Story
[이벤트] 카카오 인증 완료됨 사용자로서 | 나는, 복잡한 입력 없이 빠르게 가입하기 위해 | 카카오 계정으로 인증을 완료하고 싶다.
[이벤트] 이메일 인증 완료됨 사용자로서 | 나는, SNS 없이 가입하기 위해 | 이메일 인증을 완료하고 싶다.
[이벤트] 본인인증 완료됨 사용자로서 | 나는, 안전한 거래 환경에 참여하기 위해 | 본인인증을 완료하고 싶다.
[이벤트] 회원가입 완료됨 사용자로서 | 나는, 서비스를 이용하기 위해 | 회원가입을 완료하고 싶다.

4. 커맨드 → 시나리오/Task 변환

커맨드는 User Story의 시나리오 또는 구현 Task로 변환됩니다.

예시:

### UFR-USER-010: [회원가입] 사용자로서 | 나는, 서비스를 이용하기 위해 | 회원가입을 완료하고 싶다.

- 시나리오 1: 카카오 간편가입
  회원가입 화면에서 | [커맨드] 카카오 로그인 버튼을 클릭하면 | 카카오 인증 후 가입이 완료된다.

- 시나리오 2: 이메일 가입
  회원가입 화면에서 | [커맨드] 이메일/비밀번호를 입력하고 인증하면 | 이메일 인증 후 가입이 완료된다.

5. 정책/규칙 → Acceptance Criteria 변환

시퀀스 다이어그램의 [정책/규칙] 노트가 Acceptance Criteria(인수조건)가 됩니다.

6. 외부 시스템 연동 스토리 분리

(E)로 표시된 외부 시스템 연동은 별도 Technical Story로 분리합니다.

마이크로서비스 정의 가이드

Event Storming 결과에서 마이크로서비스를 도출하는 5단계 프로세스입니다.

1. 이벤트 클러스터링

유저플로우별 이벤트를 비즈니스 개념 기준으로 그룹화합니다.

[방법]
1. 각 .puml 파일에서 [이벤트] 추출
2. 동일 비즈니스 개념 이벤트 묶기
3. 동일 액터가 주로 사용하는 이벤트 확인

[예시]
인증 클러스터: 회원가입 완료됨, 로그인 완료됨, 인증 완료됨
주문 클러스터: 주문 생성됨, 주문 취소됨, 주문 완료됨

2. Aggregate 식별

이벤트가 변경하는 엔티티와 생명주기를 파악합니다.

분석 항목 질문
상태 변경 이 이벤트가 어떤 엔티티의 상태를 변경하는가?
생명주기 생성-수정-삭제 사이클이 같은 엔티티는?
불변식 항상 함께 검증되어야 하는 규칙은? 
[예시]
주문 Aggregate: Order(Root), OrderItem, OrderStatus
회원 Aggregate: Member(Root), Profile, Address

3. 바운디드 컨텍스트 정의

Aggregate와 정책/규칙을 묶어 컨텍스트 경계를 설정합니다.

[경계 설정 기준]
- 유비쿼터스 언어: 같은 용어가 같은 의미로 사용되는 범위
- 정책 귀속: [정책/규칙]이 적용되는 범위
- 팀 책임: 단일 팀이 책임질 수 있는 범위

4. 컨텍스트 맵핑

컨텍스트 간 관계와 통신 패턴을 정의합니다.

관계 유형 설명 통신 패턴
Customer-Supplier 요청-응답 관계 동기 호출
Conformist 상위 서비스 모델 따름 동기 호출
Published Language 표준 이벤트 공유 비동기 이벤트
Anti-Corruption Layer 모델 변환 계층 필요 어댑터 패턴

5. 분할/병합 결정

아래 기준을 적용하여 최종 마이크로서비스를 도출합니다.

분할 기준 (하나 이상 해당 시 분리)

기준 설명
차별화 핵심 비즈니스 경쟁력 원천 기능
부하 변동 스케일링 패턴이 다름
변경 빈도 배포 주기가 다름
데이터 소유 별도 Aggregate Root 소유

병합 기준 (해당 시 통합 고려)

기준 지표
트랜잭션 경계 강한 일관성 필요
서비스 크기 코드 5,000줄 미만
호출 빈도 동기 호출 90% 이상
운영 복잡도 팀당 3-5개 서비스 적정

MVP 단계 병합 전략

초기에는 운영 복잡도를 낮추기 위해 관련 컨텍스트를 병합하고, 트래픽/복잡도 증가 시 분리합니다.

[병합 예시]
회원 + 알림 → 회원서비스 (분리 트리거: 알림 처리량 > 10,000건/시간)
주문 + 결제 → 거래서비스 (분리 트리거: 결제 기능 복잡화)

서비스 정의 체크리스트

  • 모든 유저플로우 이벤트가 서비스에 매핑됨
  • 각 서비스가 단일 Aggregate만 소유함
  • 트랜잭션 경계가 서비스 경계 내에 있음
  • 이벤트 기반 통신 패턴이 정의됨

유저스토리 프레임워크

1. 마이크로서비스

유저스토리는 마이크로서비스 단위로 구성합니다: 마이크로서비스는 ‘마이크로서비스 정의 가이드’에 따라 정의합니다.
‘MVP 단계 병합 전략’에 따라 운영 복잡도를 낮추기 위해 관련 컨텍스트는 병합합니다.

서비스 조직 예시

  • User Service: 사용자 관리 (회원가입, 로그인, 프로필)
  • [Core] Service: 핵심 비즈니스 기능
  • [AI] Service: AI 기반 기능
  • [Integration] Service: 외부 연동 기능

2. UFR (User Functional Requirement) 포맷

각 유저스토리는 다음 형식을 따릅니다:

UFR-{서비스약어}-{번호}: [{유저스토리 제목}] {사용자유형}로서 | 나는, {목적}을 위해 | {액션}을 하고 싶다.

예시:

  • UFR-USER-010: [회원가입] 구매자로서 | 나는, 서비스를 이용하기 위해 | 간편하게 회원가입하고 싶다.
  • UFR-CORE-020: [주문하기] 구매자로서 | 나는, 상품을 구매하기 위해 | 쉽게 주문하고 싶다.

3. 시나리오 기반 상세 요구사항

각 UFR은 다음 구조로 상세화합니다:

– 시나리오: {시나리오명}

{상황 설명} | {조건} | {결과}

[입력 요구사항]

  • 기본 정보
    • {필드명}: {검증 ì¡°ê±´}
    • {필드명}: {검증 ì¡°ê±´}
  • 추가 정보
    • {필드명}: {검증 ì¡°ê±´}

[검증 요구사항]

  • {검증 항목}: {검증 내용}
  • {검증 항목}: {검증 내용}

[처리 결과]

  • 성공 시
    • {ê²°ê³¼ 항목}
    • {ê²°ê³¼ 항목}
  • 실패 시
    • {실패 ì¡°ê±´}: {처리 방법}

– M/{포인트}, S/{포인트}, C/{포인트}

우선순위 표기법:

  • M (Must Have): 필수 구현 기능
  • S (Should Have): 중요 구현 기능
  • C (Could Have): 선택 구현 기능
  • 숫자: Story Points (피보나치: 1, 2, 3, 5, 8, 13, 21)

예시: M/13 → Must Have, 13 포인트

4. 기술 태스크 (복잡한 스토리)

복잡한 구현이 필요한 스토리는 기술 태스크를 분리합니다:

[기술 태스크]

  • Frontend
    • {구현 내용}
    • {구현 내용}
  • Backend
    • API Endpoint: {엔드포인트}
    • Service Layer: {서비스 로직}
    • Repository: {데이터 접근}
  • Infrastructure
    • {인프라 요구사항}

5. 사용자 역할

각 역할 정의:

  • 설명
  • 권한
  • 목표

6. Feature Story Map

계층 구조 생성:

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]

7. 우선순위 매트릭스

Must Have (P0)

  1. [UFR-XXX-###] – [스토리 제목]

Should Have (P1)

  1. [UFR-XXX-###] – [스토리 제목]

Could Have (P2)

  1. [UFR-XXX-###] – [스토리 제목]

Won’t Have (이번 버전에서는)

  1. [UFR-XXX-###] – [스토리 제목]

8. 스프린트 계획 (MVP 기준)

Sprint 1 (1-2주차)

  • UFR-USER-010: [제목] (M/5)
  • UFR-CORE-020: [제목] (M/3)
  • Sprint 목표: [스프린트 목표]
  • 총 SP: 8

[이후 스프린트 계속]

9. 비기능적 요구사항

성능

  • 페이지 로드: 3G에서 <3초, WiFi에서 <1초
  • API 응답: <200ms
  • 동시 사용자: 1000명

보안

  • HTTPS 적용
  • 인증/권한 관리
  • 데이터 암호화

사용성

  • 모바일 반응형
  • WCAG 2.1 접근성 준수
  • 다국어 지원

확장성

  • 수평 확장 가능
  • 클라우드 네이티브
  • 마이크로서비스 아키텍처

10. Definition of Done

체크리스트:

  • 코드 리뷰 완료
  • 단위 테스트 작성 및 통과
  • 통합 테스트 통과
  • 문서화 완료
  • QA 테스트 통과
  • 스테이징 배포 및 검증
  • 프로덕션 배포

11. 리스크 및 의존성

UFR ID 리스크/이슈 영향도 완화 전략
UFR-XXX-### [리스크] 높음 [전략]

INVEST 원칙

유저스토리는 반드시 INVEST를 따라야 함:

  • Independent (독립적): 독립적으로 개발 가능
  • Negotiable (협상 가능): 세부사항 논의 가능
  • Valuable (가치 있음): 사용자에게 가치 제공
  • Estimable (추정 가능): 추정 가능
  • Small (작음): 한 스프린트 내 완료 가능
  • Testable (테스트 가능): 명확한 인수 기준

작성 형식

유저스토리 예시

# 유저스토리

## 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 사용

복잡한 유저스토리 분석과 우선순위 결정이 필요할 때 Sequential MCP를 활용하여 체계적으로 백로그를 구성하세요.

결과 파일

  • 유저스토리.md: design/userstory.md

주의사항

  • UFR 포맷 준수: UFR-{서비스}-{일련번호} 형식 엄격히 사용

  • 일련번호: 각 서비스별로 ‘010’부터 시작하여 10씩 증가시킴

  • 시나리오 구조 필수: [입력 요구사항], [검증 요구사항], [처리 ê²°ê³¼] 모두 작성

  • 우선순위 표기: M/S/C + Story Points (피보나치) 형식 사용

  • 최소 20개 이상: 충분한 UFR로 MVP 범위 정의

  • Event Storming 연계: ES 결과를 UFR로 체계적 변환

  • 마이크로서비스 구조: 서비스별로 명확히 그룹화

  • 기술 태스크: 복잡한 스토리는 Frontend/Backend/Infrastructure 분리

  • INVEST 원칙: 독립성, 협상가능성, 가치, 추정가능성, 작은 크기, 테스트가능성

  • 비기능적 요구사항: 성능, 보안, 사용성, 확장성 필수 포함

  • Definition of Done: 모든 완료 기준 충족 필요

다음 단계

유저스토리 작성 완료 후:

  1. UI/UX 디자인 (와이어프레임, 디자인 시스템)
  2. 프로토타입 개발 (기술 스택, 구현)
  3. 스프린트 실행 및 개발
GitHub 仓库 ↗ ← 返回陌讯 Skills 聚合平台
本页面由 陌讯 Skills 聚合平台 收录整理，数据定期更新。