[Jira] Epic / Story / Task / Bug

• Epic / Story / Task / Bug의 역할을 명확히 구분하고
• 실제 온라인 서비스 주문 처리 시스템을 예제로
• 스토리를 잘 쪼개는 기준 체크리스트까지 정리한다

---

Epic / Story / Task / Bug 역할 정리

구분	역할
Epic	세계관, 문제 정의, 목표
Story	사용자 관점의 기능
Task	설계 · 구현 · 리팩터링
Bug	의도와 다른 동작

한 줄 요약하면 다음과 같다.

• Epic: 왜 이 일을 하는가
• Story: 사용자가 무엇을 할 수 있는가
• Task: 어떻게 구현하는가
• Bug: 의도와 실제의 차이

---

예제 도메인: 온라인 서비스의 주문 처리 시스템

상황 설명

• 하나의 주문에는 여러 개의 상품이 포함될 수 있다
• 주문 처리 과정에서 일부 상품만 실패할 수 있다
• 실패해도 다른 상품의 처리는 계속될 수 있다

현재 문제

• 주문을 단일 단위로만 처리
• 일부 상품 실패 시:
  • 주문 상태가 불명확
  • 어떤 상품이 실패했는지 알기 어려움
  • 재처리가 매우 까다로움

---

Epic 정의

Epic

주문 처리 중 부분 실패 대응 체계 구축

Epic 설명 (세계관 / 문제 정의)

하나의 주문에는 여러 개의 상품이 포함될 수 있으며,
주문 처리 과정에서 일부 상품이 실패하더라도
다른 상품의 처리는 계속 진행될 수 있다.

현재 시스템은 주문을 단일 단위로만 처리하여
일부 상품 실패 시 전체 주문의 상태가 불명확해지고
재처리가 어렵다.

Epic 목표

• 상품 단위의 처리 상태를 명확히 관리한다
• 부분 실패가 발생해도 주문 전체 진행 상황을 파악할 수 있다
• 실패한 상품만 선택적으로 재처리할 수 있다
• 처리 이력과 실패 사유를 명확히 남긴다

---

Story 정의

Story 1

상품 단위로 주문 처리 상태를 관리한다

사용자 관점 설명
운영자는 하나의 주문에 포함된 각 상품의 처리 상태를
개별적으로 확인할 수 있어야 한다.

Acceptance Criteria

• 하나의 주문에 N개의 상품이 포함될 수 있다
• 각 상품은 독립적인 처리 상태를 가진다
• 특정 상품이 실패해도 다른 상품의 처리는 계속된다

---

Story 2

상품 처리 결과를 기반으로 주문의 최종 상태를 계산한다

사용자 관점 설명
운영자는 주문 전체가 현재 어떤 상태인지
한 눈에 파악할 수 있어야 한다.

Acceptance Criteria

• 주문 상태는 개별 상품 상태의 집합으로 계산된다
• 모든 상품이 성공한 경우 주문은 성공 상태가 된다
• 일부 상품이 실패한 경우 주문은 부분 실패 상태가 된다

링크

• is blocked by → 상품 단위 주문 처리 상태 관리

---

Story 3

상품 처리 실패 시 실패 사유를 기록한다

사용자 관점 설명
운영자는 상품이 왜 실패했는지
원인을 확인할 수 있어야 한다.

Acceptance Criteria

• 실패한 상품에 대해 사유 코드와 메시지를 저장한다
• 실패 사유는 처리 이력과 함께 조회 가능해야 한다

링크

• relates to → 상품 단위 주문 처리 상태 관리

---

Story 4

실패한 상품만 선택적으로 재처리할 수 있다

사용자 관점 설명
운영자는 주문 전체를 다시 처리하지 않고
실패한 상품만 재처리할 수 있어야 한다.

Acceptance Criteria

• 실패 상태의 상품만 재처리 대상이 된다
• 성공한 상품은 재처리 대상에서 제외된다
• 재처리 시 기존 처리 이력은 유지된다

링크

• is blocked by → 상품 처리 이력 관리

---

Story 5

상품 처리 이력을 상품 단위로 관리한다

사용자 관점 설명
운영자는 각 상품의 처리 시도 내역을
시간 순으로 확인할 수 있어야 한다.

Acceptance Criteria

• 상품별로 여러 번의 처리 이력을 저장할 수 있다
• 각 이력은 처리 상태와 시점을 포함한다

---

Story 6

상품별 처리 상태를 조회할 수 있다

사용자 관점 설명
운영자는 주문 상세 화면에서
상품별 처리 상태를 확인할 수 있어야 한다.

Acceptance Criteria

• 주문 상세 화면에서 상품 목록과 상태를 조회할 수 있다
• 상태 정보는 최신 처리 결과를 반영한다

링크

• is blocked by → 상품 단위 주문 처리 상태 관리

---

Task 예시 (Story 하위)

Task

상품 처리 상태 저장 구조 설계

• 상태 enum 정의
• 상태 전이 규칙 정리
• 상태 저장 테이블 설계

Task

상품 처리 이력 저장 구조 구현

• 이력 테이블 생성
• 이력 insert 로직 구현
• 조회 API 구현

👉 Task는 사용자 가치가 아니라 구현 방법이다.

---

Bug 예시

Bug

재처리 시 정상 처리된 상품의 상태가 초기화되는 문제

설명

실패 상품 재처리 시
이미 정상 처리된 상품의 상태가
다시 대기 상태로 변경된다.

링크

• is caused by → 상품 처리 이력 초기 생성 로직 변경

---

스토리를 잘 쪼개는 기준 체크리스트

0. 전제

• Epic은 이미 세계관과 문제 정의가 끝난 상태
• 지금 하는 일은
  👉 Epic을 구현 가능한 Story로 나누는 것

---

1. 이건 Story인가, Task인가?

Story 체크 질문

• 사용자가 할 수 있는 행동이 하나 늘어나는가?
• 화면 / API / 결과물 중 인지 가능한 변화가 있는가?
• 성공/실패를 명확히 판단할 수 있는가?

Task 체크 질문

• 설계, 리팩터링, 구조 변경인가?
• 사용자 입장에서 기능 차이가 없는가?
• 다른 Story를 위한 준비 작업인가?

---

2. 스토리 1개에 사용자 목표는 하나인가?

체크

• “사용자로서 나는 … 할 수 있다” 문장이 하나로 끝나는가?
• 제목이나 설명에 “그리고”, “또는”, “또한”이 반복되는가?

판단

• 사용자 목표가 2개 이상 → 쪼갠다

예

❌ 나쁜 예

주문 상태를 조회하고 실패 상품을 재처리할 수 있다

✅ 좋은 예

• 주문 상태를 조회할 수 있다
• 실패한 상품을 재처리할 수 있다

---

3. 완료 기준(AC)이 명확한가?

체크

• 이 스토리가 끝났는지 Yes / No로 판단 가능한가?
• QA가 질문 없이 검증 가능한가?

위험 신호

• “적절히”, “가능하면”, “문제없게”
• 구현 방식만 있고 결과가 없음

👉 AC는 결과 중심, 설계는 숨긴다

---

4. 다른 스토리 없이 단독으로 설명 가능한가?

체크

• 이 스토리만 읽어도 맥락을 이해할 수 있는가?

판단

• 이해 불가 → Epic 설명을 보강하거나 Story 재정의

---

5. 선후 관계가 필요한가?

체크

• 이 스토리를 시작하려면 반드시 필요한 다른 스토리가 있는가?

판단

• Yes → is blocked by
• No → relates to 또는 독립

⚠️ “같이 하면 편하다” ≠ blocked

---

6. 크기가 한 스프린트에 들어가는가?

체크

• 개발 + 테스트 + 리뷰까지 가능한가?

판단

• 너무 크다 → 기능 단위로 분리
• 너무 작다 → Task로 내린다

---

7. 실패 / 예외가 사용자 가치인가?

판단

• 사용자가 직접 다뤄야 한다 → Story
• 내부 처리다 → Task 또는 AC

---

8. 조회와 변경이 섞여 있는가?

원칙

• Read와 Write는 가능하면 분리

예

• 상태를 조회할 수 있다
• 상태를 변경할 수 있다

---

9. 제목만 봐도 무엇을 하는지 알 수 있는가?

좋은 Story 제목 공식

“[주체]가 [행동]할 수 있다”

예

• 운영자가 상품별 처리 상태를 조회할 수 있다
• 운영자가 실패한 상품만 재처리할 수 있다

---

10. 이 Story가 없어지면 Epic 목표가 흔들리는가?

판단

• Yes → 핵심 Story
• No → 보조 Story 또는 후순위

---

실무 요약 규칙

• Story는 사용자 가치 단위
• 설계 / 구조 / 리팩터링은 Task
• AC는 결과, 구현은 숨긴다
• blocked는 최소화, relates는 맥락 공유용
• 헷갈리면 쪼개고, 너무 작으면 내린다