유저스토리 작성

목적

선정된 솔루션과 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이 됩니다. 예시)

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)

• [UFR-XXX-###] - [스토리 제목]

Should Have (P1)

• [UFR-XXX-###] - [스토리 제목]

Could Have (P2)

• [UFR-XXX-###] - [스토리 제목]

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

• [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 검증 완료
• 프로덕션 배포 승인
• 프로덕션 배포 완료

리스크 및 의존성

리스크 관리

의존성 관리

도구 활용

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: 모든 완료 기준 충족 필요

다음 단계

유저스토리 작성 완료 후:

• UI/UX 디자인 (와이어프레임, 디자인 시스템)

• 프로토타입 개발 (기술 스택, 구현)

• 스프린트 실행 및 개발