<aside> 📎

참고 출처

1. User Stories With Examples and a Template — Atlassian — 유저 스토리의 정의, 작성 형식, 활용 방식에 대한 공식 가이드입니다. </aside>

경험 전체(UX)를 설계해야 한다는 것은 알았지만, 막상 무엇부터 적어야 할지 막막합니다. 가장 작은 단위에서 출발하면 됩니다. 바로 '사용자가 무엇을, 왜 원하는가'를 한 문장으로 적는 유저 스토리입니다. 이번 레슨에서는 기획 산출물의 첫 벽돌인 유저 스토리를 쓰는 법을 배웁니다.

유저 스토리와 요구사항 정의

• 유저 스토리는 사용자 관점에서 기능을 비기술적 언어로 서술한 짧은 문장입니다.
  • Atlassian은 유저 스토리를 "최종 사용자 관점에서 쓴 소프트웨어 기능에 대한 비형식적 설명"으로 정의합니다.
• 유저 스토리는 기능 명세서가 아니라 '왜 만드는가'를 담은 대화의 출발점입니다.
  • 개발팀은 유저 스토리를 읽고 무엇을, 왜 만드는지, 어떤 가치를 주는지를 이해합니다.

유저 스토리의 기본 형식

• 표준 형식은 다음과 같습니다.
  • As a [사용자 유형], I want [목표/행동], so that [이유/가치].
  • 한국어로는 "[사용자]로서, [이유/가치]를 위해, [목표/행동]을 원한다"로 옮길 수 있습니다.
• 예를 들어, "신규 가입자로서, 빠르게 서비스를 시작하기 위해, 이메일 없이 소셜 계정으로 로그인하고 싶다"와 같이 작성합니다.
• 세 요소가 각각 누가(Who), 무엇을(What), 왜(Why) 에 대응합니다. 셋 중 하나라도 빠지면 의도가 흐려집니다.

좋은 유저 스토리의 기준: INVEST

• 실무에서는 좋은 스토리를 점검하는 INVEST 기준을 자주 사용합니다.
  • Independent(독립적): 다른 스토리에 얽매이지 않고 따로 다룰 수 있어야 합니다.
  • Negotiable(협상 가능): 세부 구현이 아니라 의도를 담아 논의 여지를 남깁니다.
  • Valuable(가치 있음): 사용자나 비즈니스에 명확한 가치를 줍니다.
  • Estimable(추정 가능): 개발 규모를 가늠할 수 있을 만큼 구체적입니다.
  • Small(작음): 한 번의 작업 주기 안에 끝낼 수 있는 크기입니다.
  • Testable(검증 가능): 완료 여부를 확인할 기준이 있습니다.

수용 기준(Acceptance Criteria)

• 수용 기준은 그 스토리가 '완료'라고 인정되는 조건입니다.
  • 예를 들어 위 소셜 로그인 스토리의 수용 기준은 "카카오 계정으로 로그인 시 5초 이내에 메인 화면이 보인다", "로그인 실패 시 원인을 안내한다" 등이 됩니다.
• 수용 기준이 있어야 스토리가 Testable해지고, 개발과 기획의 '완료 기준'이 일치합니다.

에픽과의 관계

• 큰 목표는 에픽(Epic) 으로 묶고, 그 아래 여러 유저 스토리로 쪼갭니다.
  • 예를 들어 '회원 관리'라는 에픽 아래에 회원가입, 로그인, 비밀번호 재설정 스토리가 들어갑니다.
• 이 구조 덕분에 큰 기능을 작은 단위로 나눠 우선순위를 정하고 점진적으로 만들 수 있습니다.

생성형 AI로 유저 스토리 확장하기