Brain💡 핵심 인사이트
사용자 스토리는 애자일 개발에서 요구사항(기능)을 정의할 때 쓰는 아주 짧고 명확한 문장 형식입니다.
개발자(시스템)의 언어가 아니라, 철저하게 **"누가(Who), 무엇을(What), 왜(Why) 원하는가?"**라는 실제 고객의 관점으로 작성하여, 팀 전체가 **'고객이 이 기능을 통해 얻으려는 진짜 가치'**에 집중하게 만듭니다.
Ⅰ. 기존 요구사항 명세서의 문제점
과거 폭포수 시절 기획자는 요구사항 명세서에 이렇게 썼습니다.
- "ID 필드는 VARCHAR(20)로 하고, 패스워드 검증 API 호출 후 Session에 토큰을 구워라." 이 문장은 시스템이 '어떻게(How)' 동작할지는 잘 설명하지만, **"대체 이 기능을 왜 만들어야 하는가?"**에 대한 맥락(Context)이 완전히 빠져 있습니다. 개발자들은 이유도 모른 채 기계처럼 코딩만 하게 되고, 결과적으로 쓸모없는 기능이 만들어집니다.
Ⅱ. 사용자 스토리의 표준 템플릿 (Who, What, Why)
이 문제를 해결하기 위해 애자일은 포스트잇 한 장에 들어갈 만큼 짧은 문장 템플릿을 만들었습니다.
[표준 문법] "나는 [어떤 사용자/Who]로서, [어떤 목적/Why]을 위해, [어떤 기능/What]을 원한다."
훌륭한 작성 예시 (쇼핑몰 개발)
- 나쁜 예: "장바구니에 아이템 삭제 버튼 추가."
- 좋은 사용자 스토리: "나는 [쇼핑몰 VIP 고객]으로서, [결제 전 예산을 맞추기] 위해, [장바구니에서 특정 상품을 쉽게 뺄 수 있는 기능]을 원한다."
왜 이렇게 쓰는가?
저 짧은 문장을 통해 개발자는 기술적인 구현 방법(버튼으로 할지, 스와이프 삭제로 할지)에 대한 재량권을 가지면서도, **"아, 이 기능은 고객이 예산을 맞출 때 편리하게 쓰기 위함이구나"**라는 비즈니스 핵심 가치(Why)를 정확히 이해하고 코딩에 몰입할 수 있습니다.
Ⅲ. 좋은 스토리의 6가지 조건: INVEST 원칙
제품 책임자(PO)가 백로그에 스토리를 적을 때 반드시 지켜야 할 품질 검증 기준입니다. (빌 웨이크가 제안)
- I (Independent, 독립적): 스토리 1번과 2번이 서로 얽혀 있어서 1번이 안 끝나면 2번을 아예 개발할 수 없는 종속성을 피해야 합니다. 각각 독립적으로 배포 가능해야 합니다.
- N (Negotiable, 협상 가능): 스토리는 픽스된 계약서가 아닙니다. 리뷰 회의 때 개발팀과 PO가 대화하며 구현 범위를 유연하게 조정할 수 있어야 합니다.
- V (Valuable, 가치 있는): 이걸 개발했을 때 최종 사용자나 비즈니스에 확실한 가치(이득)를 제공해야 합니다.
- E (Estimable, 추정 가능): "이거 며칠 걸릴까?"를 개발팀이 스토리 포인트로 산정할 수 있을 만큼 명확해야 합니다.
- S (Small, 작은 크기): 한 스프린트(2주) 안에 코딩부터 테스트까지 넉넉히 끝낼 수 있도록 작게 쪼개져 있어야 합니다. (너무 크면 '에픽(Epic)'이라고 부름)
- T (Testable, 테스트 가능): "이 기능이 완료(Done)되었는가?"를 명확히 합격/불합격으로 판정할 수 있는 '인수 조건(Acceptance Criteria)'이 존재해야 합니다.
📢 섹션 요약 비유: 사용자 스토리는 건축가에게 **"시멘트를 10톤 발라서 10미터짜리 벽을 세워라(기존 요구사항)"**라고 지시하는 대신, **"나는 아이의 부모로서(Who), 아이가 마당에서 안전하게 뛰놀게 하기 위해(Why), 튼튼한 울타리(What)를 원한다"**라고 말해주는 것입니다. 그러면 건축가는 꼭 시멘트가 아니더라도 나무나 예쁜 벽돌을 써서 그 목적(가치)에 딱 맞는 완벽한 울타리를 창의적으로 만들어냅니다.