182. 에픽 (Epic) - 거시적 스토리 집합

핵심 인사이트: 애자일에서 한 번의 스프린트(Sprint) 안에 다 끝낼 수 없는 거대한 요구사항 덩어리를 '에픽(Epic)'이라고 부른다. 이 거대한 바윗덩어리는 개발을 시작하기 전, 반드시 작고 소화 가능한 여러 개의 '유저 스토리(User Story)'로 쪼개져야만 한다.

Ⅰ. 에픽 (Epic)의 개념

애자일 소프트웨어 개발 방법론(Scrum 등)에서, 단일 스프린트(보통 1~4주) 내에 개발을 완료할 수 없을 만큼 규모가 큰 최상위 수준의 요구사항이나 기능의 집합을 의미합니다. 아직 구체적인 세부 사항이 결정되지 않은 '큰 그림'의 요구사항입니다.

Ⅱ. 애자일 요구사항의 계층 구조 (Theme - Epic - Story)

[ 테마 (Theme) ]  ─▶ 가장 넓은 비즈니스 목표 (예: "결제 편의성 강화")
       │
       ▼
[ 에픽 (Epic) 1 ] ─▶ 큼직한 기능 덩어리 (예: "애플페이 간편 결제 도입")
       │
       ├─▶ [ 유저 스토리 (Story) A ] "사용자로서 애플페이 카드를 등록할 수 있다." (3일 소요)
       ├─▶ [ 유저 스토리 (Story) B ] "사용자로서 지문 인증으로 결제를 완료할 수 있다." (5일 소요)
       └─▶ [ 유저 스토리 (Story) C ] "사용자로서 애플페이 결제 내역을 조회할 수 있다." (2일 소요)

Ⅲ. 에픽의 주요 특징

구분	설명
분할의 대상	에픽 자체로는 너무 커서 개발할 수 없으므로, 백로그 정제(Backlog Refinement) 회의를 통해 여러 개의 작은 유저 스토리로 분해(Split)되어야 합니다.
추정(Estimation)	세부 사항이 부족하므로 스토리 포인트(Story Point)나 티셔츠 사이즈(S, M, L, XL)처럼 거시적인 수준에서 개발 기간을 추정합니다.
진행(Progress)	에픽에 속한 모든 하위 유저 스토리들이 완료(Done)되어야만 해당 에픽이 완료된 것으로 간주합니다.

Ⅳ. 왜 에픽을 사용하는가? (효과)

처음부터 모든 요구사항을 잘게 쪼개어 상세하게 적으려 하면(폭포수 방식), 엄청난 문서화 비용이 발생하고 변화에 대응할 수 없습니다. 따라서 초기 기획 단계에서는 거시적인 에픽 형태로 아이디어를 담아두고, 실제 개발이 임박한 시점(스프린트 시작 전)에만 에픽을 작은 스토리로 분해(Just-in-Time)하여 유연성과 효율성을 극대화합니다.

📢 섹션 요약 비유: 에픽은 '추석맞이 대청소'라는 커다란 목표 덩어리입니다. 하루 만에 다 할 수는 없으니, 이 덩어리를 쪼개어 '오늘(스프린트)은 창틀 닦기(스토리 1)와 화장실 청소(스토리 2)만 하자'라고 작게 나누어야 비로소 실행에 옮길 수 있습니다.