사용자 스토리 작성법, 실무 공식과 예시로 정리
- 사용자 스토리는 기능 명세가 아니라 역할·목표·이유를 담은 한 문장 대화 시작점입니다
- 좋은 스토리인지는 INVEST 6가지 기준으로 점검할 수 있습니다
- 스토리가 너무 크면 SPIDR 기법으로 작더라도 완결된 단위로 쪼갭니다
- 승인 조건을 Given-When-Then으로 함께 적어야 완료 기준 논쟁이 줄어듭니다
사용자 스토리는 ‘무엇을 만들 것인가’가 아니라 ‘누가, 왜 필요한가’를 한 문장으로 적는 요구사항 형식입니다. 기본 공식은 다음과 같습니다: “~로서(As a), 나는 ~를 원한다(I want), 그래야 ~할 수 있기 때문이다(So that)”. 이 세 조각 중 하나라도 빠지면 개발팀은 ‘왜 이걸 만드는지’ 모른 채 기능만 구현하게 되고, 나중에 우선순위 조정이나 범위 축소가 필요할 때 판단 기준이 사라집니다.
사용자 스토리란? 기획서·요구사항 문서와 뭐가 다른가
정의와 3C 구성요소
사용자 스토리는 애자일(Agile, 짧은 주기로 계획-실행-점검을 반복하는 개발 방식) 진영에서 나온 개념으로, 완결된 명세서가 아니라 대화를 위한 메모에 가깝습니다. 이를 3C라고 부릅니다.
- 카드(Card): 역할-목표-이유를 담은 짧은 문장 자체. 상세 스펙을 다 적지 않습니다.
- 대화(Conversation): 카드만으로는 부족한 세부사항을 기획자·개발자·디자이너가 직접 논의해 채웁니다.
- 확인(Confirmation): 대화 결과를 승인 조건(Acceptance Criteria, 이 기능이 완료됐다고 인정할 구체적 조건)으로 문서화합니다.
즉 스토리 카드 한 줄만 보고 바로 개발에 들어가는 것이 아니라, 카드를 계기로 대화를 나누고 그 합의를 확인 조건으로 남기는 3단계가 완성돼야 ‘제대로 쓴’ 사용자 스토리입니다. 이 구조를 모르고 카드 문장만 화려하게 다듬는 데 시간을 쓰는 경우가 실무에서 가장 흔한 오해입니다.
에픽·스토리·태스크 계층 구조
규모가 큰 요구사항은 하나의 스토리로 담기지 않으므로 계층을 나눠 관리합니다.
| 계층 | 범위 | 예시 |
|---|---|---|
| 에픽(Epic) | 여러 스프린트에 걸치는 큰 목표 | 신규 회원 온보딩 개선 |
| 사용자 스토리 | 1~2 스프린트 내 완료 가능한 사용자 가치 단위 | 신규 가입자로서 이메일 인증 없이 소셜 로그인으로 가입하고 싶다 |
| 태스크(Task) | 스토리를 구현하기 위한 기술 작업 | OAuth 연동 API 개발, 로그인 버튼 UI 작업 |
에픽 하나를 여러 스토리로 쪼개는 예시로는 SaaS 온보딩 프로세스 설계처럼 가입-초기설정-첫 성공 경험까지 단계별로 스토리를 나누는 경우가 대표적입니다. 태스크는 개발팀 내부용이라 ‘사용자’가 주어로 오지 않아도 되지만, 스토리는 항상 사용자 관점 문장이어야 한다는 점이 이 둘을 구분하는 핵심입니다.
사용자 스토리 작성 공식과 좋은 예/나쁜 예
기본 템플릿 적용법
공식은 간단하지만 각 자리에 무엇을 넣느냐에 따라 스토리의 쓸모가 완전히 달라집니다. ‘역할’은 페르소나가 아니라 이 기능으로 실제 이득을 보는 사용자 유형이어야 하고, ‘목표’는 화면이나 버튼이 아니라 사용자가 하려는 행동이어야 하며, ‘이유’는 그 행동이 왜 가치 있는지를 설명해야 합니다.
| 구분 | 나쁜 예 | 좋은 예 |
|---|---|---|
| 역할 불명확 | 사용자로서 버튼을 클릭하고 싶다 | 재구매 고객으로서 지난 주문 내역에서 바로 재주문하고 싶다 |
| 목표가 UI 요소 | 관리자로서 파란색 저장 버튼을 원한다 | 관리자로서 작성 중인 내용을 자동으로 저장해 두고 싶다 |
| 이유 누락 | 사용자로서 알림 설정 화면이 필요하다 | 사용자로서 알림 종류를 개별 선택하고 싶다, 그래야 불필요한 푸시를 안 받을 수 있다 |
승인 조건(Acceptance Criteria) 작성법
카드 문장만으로는 ‘완료’의 기준이 모호하므로, 스토리마다 승인 조건을 Given-When-Then 형식으로 덧붙입니다. Given(어떤 상황에서)-When(무엇을 하면)-Then(어떤 결과가 나와야 하는지)을 나열하면 개발자와 QA가 같은 기준으로 완료 여부를 판단할 수 있습니다.
- Given: 로그인하지 않은 사용자가 상품 상세 페이지에 있을 때
- When: 장바구니 담기 버튼을 누르면
- Then: 로그인 페이지로 이동하고, 로그인 후 원래 담으려던 상품이 자동으로 장바구니에 담긴다
화면 흐름이 복잡한 스토리는 문장만으로 전달이 안 되는 경우가 많아, 이럴 때는 와이어프레임을 함께 첨부해 대화(Conversation) 단계를 보완하는 것이 실무에서 자주 쓰이는 방법입니다.
좋은 사용자 스토리의 기준: INVEST 원칙
스토리 작성 후 바로 백로그에 올리기 전에, 아래 여섯 가지로 점검하는 습관을 들이면 스프린트 계획 단계에서 다시 쪼개거나 다시 쓰는 일이 크게 줄어듭니다.
INVEST 원칙: Independent(다른 스토리에 종속되지 않는가), Negotiable(세부 구현은 대화로 조정 가능한가), Valuable(사용자·비즈니스에 실제 가치가 있는가), Estimable(작업량을 추정할 수 있는가), Small(한 스프린트 내 완료 가능한 크기인가), Testable(완료 여부를 검증할 수 있는가)
- Independent — 스토리 A가 끝나야 스토리 B를 시작할 수 있다면 우선순위를 자유롭게 조정하기 어렵습니다. 가능하면 독립적으로 배포 가능한 단위로 나눕니다.
- Negotiable — 카드에 세부 UI까지 못 박으면 대화의 여지가 사라집니다. 큰 방향만 적고 나머지는 논의로 채웁니다.
- Valuable — 기술적으로만 필요한 작업(예: 리팩터링)은 스토리가 아니라 태스크나 기술 부채 항목으로 따로 관리하는 편이 낫습니다.
- Estimable — 팀이 작업량을 가늠할 수 없을 만큼 모호하면, 먼저 조사용 스파이크(아래 SPIDR 참고)로 분리합니다.
- Small — 2주 스프린트 안에 절반도 못 끝낼 크기라면 반드시 쪼갭니다.
- Testable — ‘사용성이 좋아야 한다’처럼 검증 방법이 없는 조건은 승인 조건에서 제외하고 측정 가능한 문장으로 바꿉니다.
스토리가 너무 클 때 쪼개는 법: SPIDR 기법
INVEST의 ‘Small’ 기준에 걸리는 스토리는 무작정 반으로 자르면 안 됩니다. 잘못 쪼개면 각 조각이 사용자에게 아무 가치도 주지 못하는 반쪽짜리 기능이 되기 때문입니다. 이때 쓰는 것이 SPIDR 기법으로, 다섯 가지 관점 중 상황에 맞는 것을 골라 쪼갭니다.
- Spike(스파이크): 기술적으로 불확실한 부분이 있다면, 먼저 조사·검증만 하는 작은 스토리로 분리합니다.
- Path(경로): 정상 흐름과 예외 흐름을 나눕니다. 예를 들어 ‘결제 성공 시 흐름’과 ‘결제 실패 시 흐름’을 별도 스토리로 만듭니다.
- Interface(인터페이스): 같은 기능도 웹과 모바일 앱처럼 플랫폼별로 나눌 수 있습니다.
- Data(데이터): 지원하는 데이터 유형이나 범위를 단계적으로 나눕니다. 예를 들어 ‘이미지 첨부 지원’을 먼저 하고 ‘동영상 첨부 지원’을 다음 스토리로 미룹니다.
- Rules(규칙): 복잡한 비즈니스 규칙 중 핵심 규칙만 먼저 반영하고, 예외 규칙은 별도 스토리로 넘깁니다.
쪼갠 뒤에도 각 조각이 독립적으로 배포·검증 가능해야 한다는 점(Independent, Testable)은 여전히 지켜야 합니다. 쪼갠 조각 중 하나가 여전히 크다면 같은 관점을 한 번 더 적용해도 됩니다.
실무에서 흔한 실수와 주의점
스토리 작성 자체보다 운영 과정에서 반복되는 실수가 팀 생산성을 더 많이 갉아먹습니다. 다음 항목들을 스프린트 회고 때 함께 점검해 보시기 바랍니다.
- 기술 용어로 문장을 시작하는 실수: ‘개발자로서 API를 리팩터링하고 싶다’는 사용자 스토리가 아니라 기술 작업입니다. 사용자에게 어떤 이익이 돌아가는지로 다시 써야 합니다.
- 승인 조건 없이 바로 개발 착수: 대화 없이 카드만 보고 개발하면 완료 시점에 ‘이게 맞나요’라는 논쟁이 반복됩니다.
- 이유(So that) 생략: 이유가 없으면 우선순위 논의 때 이 스토리를 왜 지금 해야 하는지 설득할 근거가 없습니다.
- 에픽을 통째로 스토리 하나에 담기: 스프린트가 끝나도 완료되지 않는 스토리가 계속 이월되는 원인 대부분이 여기 있습니다.
- 완료 후 승인 조건을 소급 작성: 개발이 끝난 뒤에야 조건을 적으면 실제로는 테스트 결과에 조건을 끼워 맞추게 됩니다.
또한 프론트엔드와 백엔드 작업 범위가 뒤섞인 스토리는 담당자가 명확하지 않아 진행 상황 추적이 어려워지므로, 필요하면 Interface 관점으로 나누는 것이 좋습니다.
자주 묻는 질문
Q. 사용자 스토리와 요구사항 명세서는 뭐가 다른가요?
요구사항 명세서는 기능을 상세하게 미리 다 적어두는 문서인 반면, 사용자 스토리는 짧은 문장으로 대화를 시작하고 세부사항은 팀 논의로 채워가는 방식입니다. 변경이 잦은 프로젝트에서는 스토리 방식이 문서 유지보수 부담을 줄여줍니다.
Q. 스토리 포인트는 어떻게 매기나요?
보통 절대적인 시간이 아니라 피보나치 수열(1, 2, 3, 5, 8…) 같은 상대적 척도로 팀원들이 합의해 매깁니다. INVEST의 Estimable 기준을 충족하지 못하는 스토리는 포인트를 매기기 전에 먼저 쪼개거나 스파이크로 조사부터 진행해야 합니다.
Q. 이유(So that)를 도저히 못 채우겠는 스토리는 어떻게 하나요?
비즈니스 가치를 설명할 수 없다면 그 작업이 사용자 스토리로 적합하지 않을 가능성이 큽니다. 인프라 개선이나 기술 부채 해소라면 스토리가 아니라 별도의 기술 작업 항목으로 백로그에 등록하는 편이 더 정확합니다.
Q. 승인 조건은 누가 작성해야 하나요?
정해진 담당자가 있는 것은 아니지만, 기획자나 프로덕트 오너가 초안을 쓰고 개발자·QA가 검토하며 다듬는 방식이 일반적입니다. 3C 중 ‘확인’ 단계는 혼자 쓰기보다 관련자가 함께 확인할 때 누락이 줄어듭니다.
Q. 한 스프린트에 스토리를 몇 개나 넣어야 하나요?
정해진 정답은 없고 팀의 과거 스프린트 완료 실적(벨로시티)에 맞춰 조정합니다. 스토리 크기가 INVEST의 Small 기준에 맞게 일정하게 쪼개져 있어야 벨로시티 기반 계획이 신뢰할 수 있는 예측이 됩니다.
