사용자 스토리 작성법 (예시와 인수 조건 포함)

사용자 스토리는 사용자 관점에서 본 기능을 짧게 적은 설명입니다. “[사용자 유형]으로서, [목표]를 원한다, 그래야 [이유]이기 때문이다.” 그 아래에 인수 조건을 적습니다. 인수 조건은 이 스토리가 완료되었다고 볼 수 있도록 참이어야 하는 몇 가지 구체적인 조건입니다. 각 스토리는 한 번에 만들고 테스트할 수 있을 만큼 작게 유지하고, 누구나 확인할 수 있도록 조건을 적으세요.

사용자 스토리는 애자일 소프트웨어 팀에서 널리 쓰이게 되었지만, AI 앱 빌더로 혼자 만들 때도 똑같이 유용합니다. 좋은 스토리는 곧 좋은 프롬프트입니다.

형식

사용자 스토리는 세 부분으로 이루어집니다:

~로서 [누가], ~을 원한다 [무엇을], 그래야 ~하기 때문이다 [왜].

• 누가는 구체적인 사용자 유형입니다. 처음 방문한 사람, 유료 회원, 병원 접수 직원, 관리자처럼요. ‘사용자’라고만 쓰지 마세요.
• 무엇을은 사용자가 하고 싶은 일을 그들의 말로 적은 것입니다. 화면이 어떻게 동작해야 하는지가 아닙니다.
• 왜는 사용자가 신경 쓰는 결과입니다. 사람들이 자주 빠뜨리는 부분이지만, 잘못된 것을 만드는 일을 막아 주는 부분이기도 합니다.

예시:

~로서 헬스장 회원, 나는 휴대폰에서 수업 예약을 취소하기를 원한다, 그래야 대기자가 내 자리를 가져가고 노쇼 수수료도 내지 않기 때문이다.

‘왜’ 부분은 ‘무엇’만으로는 알 수 없는 두 가지를 알려 줍니다. 휴대폰에서 동작해야 한다는 것, 그리고 대기자 목록과 수수료 규칙이 관련되어 있다는 것입니다.

인수 조건

스토리는 원하는 것을 말하고, 인수 조건은 언제 완료인지를 말합니다. 두 사람이 봤을 때 각 조건을 통과했는지 같은 결론에 이를 만큼 구체적이어야 합니다.

흔히 Given / When / Then으로 씁니다:

• Given 시작 상황
• When 사용자가 무언가를 함
• Then 이런 결과가 나타남

위 헬스장 예약 스토리의 경우:

1. Given 12시간 이상 남은 예약이 있고, when 취소를 누른 뒤 확인하면, then 예약이 삭제되고 “예약이 취소되었습니다”가 보인다.
2. Given 예약을 취소했는데 수업에 대기자가 있고, when 취소가 저장되면, then 대기자 맨 앞 사람이 자리를 받고 이메일을 받는다.
3. Given 12시간 안에 있는 예약이고, when 취소를 누르면, then 확인하기 전에 늦은 취소 수수료가 적용된다는 안내가 보인다.
4. Given 휴대폰 너비의 화면에서, then 취소 버튼은 좌우로 스크롤하지 않아도 보인다.

단순한 체크리스트도 괜찮습니다. 각 항목을 검증할 수 있기만 하면 됩니다. “취소하기가 쉬워야 한다”는 검증할 수 없습니다. “예약 목록에서 두 번 탭하면 취소할 수 있다”는 검증할 수 있습니다.

단계별로 좋은 스토리 쓰기

1단계: 실제 사용자와 실제 문제에서 시작하기

사용자 유형 하나와 그들이 지금 겪고 있는 어려움 하나를 고르세요. 고객 인터뷰를 해 봤다면 그들의 말을 그대로 쓰세요. “취소하는 걸 자꾸 잊어서 요금이 청구돼요”가 “취소 기능 추가”보다 좋은 출발점입니다.

2단계: 한 줄짜리 스토리 쓰기

템플릿을 채우세요. 설득력 있는 ‘그래야 ~하기 때문이다’를 쓸 수 없다면, 이 기능이 정말 필요한지부터 물어보세요.

3단계: 인수 조건 3~6개 추가하기

가장 중요한 성공 케이스를 먼저 다루고, 그다음 중요한 변형들을 적으세요. 다른 역할, 빈 상태, 한도, 오류 같은 경우입니다. 여섯 개가 넘는다면 스토리가 너무 큰 것입니다.

4단계: 범위 밖 항목 적기

한 줄만 적어도 많은 왔다 갔다를 줄일 수 있습니다. “범위 밖: 유료 수업 환불, 관리자가 회원 대신 취소하기.” 이렇게 적어 두면 만드는 도중에 스토리가 커지는 것을 막을 수 있습니다.

5단계: INVEST로 점검하기

INVEST는 좋은 스토리를 점검하는 흔한 체크리스트입니다. 좋은 스토리는 다음과 같아야 합니다:

모든 스토리에 점수를 매길 필요는 없습니다. 스토리가 뭔가 이상하게 느껴지고 그 이유를 알고 싶을 때 가장 유용합니다.

좋은 예와 나쁜 예

너무 큰 스토리 쪼개는 법

큰 스토리 때문에 프로젝트가 멈추는 경우가 많습니다. 흔한 쪼개기 방법은 다음과 같습니다:

• 사용자 역할별로. 회원은 자기 예약을 취소하고, 직원은 누구의 예약이든 취소한다.
• 흐름의 단계별로. 수업 둘러보기, 수업 예약하기, 알림 받기.
• 간단한 경우 먼저. 무료 수업 취소를 지금 만들고, 수수료와 환불은 나중 스토리에서 다룬다.
• 데이터 변형별로. 지점 하나를 먼저 지원하고, 여러 지점은 나중에 지원한다.
• 정상 경로 먼저, 그다음 오류. 먼저 제대로 동작하게 만들고, 정원이 꽉 찼을 때나 이용권이 만료됐을 때 등의 처리를 나중에 추가한다.

쪼갠 조각 하나하나는 여전히 사용자가 쓸 수 있고 알아차릴 수 있는 것이어야 합니다.

사용자 스토리를 프롬프트로 쓰기

인수 조건이 붙은 사용자 스토리는 AI 앱 빌더에 주는 좋은 프롬프트와 매우 비슷합니다. AI에게 누구를 위한 것인지, 무엇이 필요한지, 왜 필요한지, 그리고 완료의 기준을 알려 주기 때문입니다. 메시지 한 번에 스토리 하나를 보내세요:

헬스장 회원으로서, 휴대폰에서 수업 예약을 취소하고 싶다. 그래야 대기자가 내 자리를 가져갈 수 있기 때문이다. 인수 조건:

1. 내 예약 목록의 각 예약에 취소 버튼이 있고, 확인 단계가 있다.
2. 수업 12시간 전보다 이전에 취소하면 예약이 그냥 삭제된다.
3. 12시간 안에 취소하면, 확인하기 전에 “늦은 취소 수수료 5달러가 적용됩니다”를 보여 주고, 예약에 수수료를 기록한다.
4. 수업에 대기자가 있으면, 맨 앞 사람이 자리를 받고 이메일을 받는다.
5. 휴대폰 너비 화면에서 동작한다. 범위 밖: 환불, 직원이 회원 대신 취소하기. 이것을 만든 다음, 미리보기에서 각 조건을 확인하고 어떤 조건이 통과했는지 알려 줘.

AI에게 대략적인 아이디어로부터 스토리 초안을 만들게 한 뒤 직접 고칠 수도 있습니다:

제 앱 아이디어는 다음과 같습니다: [두세 문장]. 첫 버전을 위한 사용자 스토리를 사용자 유형별로 묶어서 써 주세요. 각 스토리에는 Given/When/Then 형식의 인수 조건을 3~5개씩 붙여 주세요. 출시에 꼭 필요한 것과 나중에 해도 되는 것을 표시해 주세요.

결과는 항상 읽고 직접 고치세요. AI는 여러분의 사용자를 모릅니다. 여러분은 압니다.

인수 조건은 테스트 계획의 역할도 합니다. 스토리가 만들어지면 각 조건을 직접 하나씩 확인하세요. 출시 전에 앱 테스트하기 가이드가 이 내용을 바탕으로 합니다.

사용자 스토리가 다른 문서와 맞물리는 방식

• **제품 요구사항 문서(PRD)**는 제품 전체를 설명합니다. 문제, 사용자, 범위를 다룹니다. 사용자 스토리는 그 안에 들어가는 세부 항목입니다. AI로 PRD 쓰는 법을 참고하세요.
• 버그 리포트는 이미 만들어진 스토리와 달리 동작하는 것을 설명합니다. 좋은 버그 리포트 쓰는 법을 참고하세요.
• MVP는 핵심 가치를 전달하는 최소한의 스토리 집합입니다. MVP란 무엇인가를 참고하세요.

흔한 실수

• “사용자로서…” 너무 모호합니다. 실제 사용자 유형을 적으세요.
• ‘그래야 ~하기 때문이다’ 생략. 이유가 없으면 합리적인 절충안을 고를 수 없습니다.
• 필요가 아니라 해법을 쓰기. “드롭다운이 있었으면 좋겠다”는 아무도 생각해 보기 전에 설계를 정해 버립니다.
• 검증할 수 없는 조건. “쉬운”, “빠른”, “직관적인”은 바람일 뿐 조건이 아닙니다.
• 실제로는 에픽인 스토리. “계정 관리”는 스토리 열 개입니다.
• 모든 스토리를 미리 한꺼번에 쓰기. 다음 몇 개만 자세히 쓰고, 나머지는 한 줄짜리로 두었다가 그때 가서 구체화하세요.

Mythex에서의 스토리

Mythex에서 Plan(계획) 모드는 아이디어를 스토리로 바꾸기 좋은 곳입니다. 에이전트가 파일을 고치기 전에 접근 방식을 먼저 논의합니다. 스토리가 준비되면 **Build(빌드)**로 바꾸고 한 번에 스토리 하나씩 붙여넣으세요. 각 응답이 끝나면 /test로 미리보기를 클릭하며 흐름을 확인할 수 있고, 잘못된 방향으로 갔다면 어느 응답이든 이 시점으로 되돌리기로 되돌릴 수 있습니다. 효과적인 프롬프트 문서와, AI 앱 빌더용 프롬프트 쓰기 가이드를 참고하세요.

사용자 스토리 체크리스트

• 구체적인 사용자 유형을 명시한다
• 디자인이 아니라 필요를 설명한다
• 실제 ‘그래야 ~하기 때문이다’ 이유가 있다
• 검증 가능한 인수 조건이 3~6개 있다
• 예외 상황이나 오류를 최소 하나 다룬다
• 범위 밖 항목을 명시한다
• 한 번에 만들고 테스트할 수 있을 만큼 작다
• 만든 뒤 인수 조건을 하나씩 확인했다

자주 묻는 질문