사용자 스토리 작성법: 인수 조건까지 명확하게 쓰는 실무 예시

사용자 스토리 작성법을 처음 배우면 사용자로서, 무엇을 원한다는 문장만 잘 쓰면 된다고 생각하기 쉽다. 하지만 실무에서는 누가 왜 필요한지 설명하는 사용자 스토리와 어떤 결과여야 통과인지 정하는 인수 조건이 함께 있어야 개발·디자인·QA의 해석이 맞아진다. 이번에는 초보 PM이 바로 복사해 쓸 수 있는 템플릿과 좋은 예·나쁜 예, Given-When-Then 작성법까지 한 번에 정리해 보았다!

사용자 스토리란 무엇인가?

사용자 스토리는 기능 목록을 사용자 관점의 목표와 가치로 바꾸어 적은 짧은 설명이다. 보통 다음 형식을 많이 쓴다.

[사용자]로서, [목표]하고 싶다. 왜냐하면 [얻고 싶은 가치] 때문이다.

Atlassian의 사용자 스토리 안내는 사용자 스토리를 사용자의 관점에서 가치가 어떻게 전달되는지 설명하는 비공식적이고 일반적인 기능 설명으로 정리한다. 표준적인 문장 형태도 As a [user], I want [goal] so that [reason]이다.

여기서 중요한 점은 화면이나 기술 구현을 먼저 고정하지 않는 것이다.

• 사용자: 이 기능의 결과를 실제로 사용하는 사람은 누구인가?
• 목표: 사용자가 해결하려는 일은 무엇인가?
• 가치: 그 일을 해결하면 어떤 이익이 생기는가?

나쁜 사용자 스토리와 좋은 사용자 스토리

나쁜 예

결제수단 변경 팝업과 저장 API를 만든다.

해야 할 개발 작업은 보이지만 누가 왜 필요한지 알 수 없다. 팝업과 API라는 해결책도 너무 일찍 고정되어 있다.

좋은 예

유료 구독자로서, 다음 결제일 전에 결제 카드를 변경하고 싶다. 결제 실패로 구독이 중단되는 일을 막기 위해서다.

사용자, 목표, 가치가 드러나므로 팀은 팝업·별도 화면·인라인 편집 중 더 적절한 해결 방식을 논의할 수 있다.

사용자 스토리와 인수 조건은 무엇이 다를까?

사용자 스토리는 왜, 누구를 위해, 무엇을 만들지 방향을 제시한다. 인수 조건은 그 방향을 개발과 테스트에 사용할 수 있도록 무엇이 충족되면 받아들일지 구체화한다.

구분	사용자 스토리	인수 조건
핵심 질문	누가 왜 무엇을 원하는가?	어떤 결과이면 요구를 충족했다고 판단하는가?
역할	사용자 가치와 목표 정렬	범위·동작·예외·통과 기준 정렬
문장 수준	짧고 의도 중심	구체적이고 검증 가능
예시	구독자가 결제 카드를 변경하고 싶다	유효한 카드 저장 시 새 카드 끝 4자리와 완료 안내가 보인다

Atlassian은 사용자 스토리의 3C를 Card, Conversation, Confirmation으로 설명한다. 카드에 적힌 짧은 문장만으로 끝나는 것이 아니라, 팀의 대화로 세부 내용을 맞추고, 인수 조건으로 완료 여부를 확인해야 한다는 뜻이다.

인수 조건 작성법: 목록형과 Given-When-Then

인수 조건은 팀이 읽고 같은 테스트 결과를 예상할 수 있어야 한다. 크게 두 가지 방식이 실무에서 편하다.

규칙 목록형

기능이 단순하거나 여러 업무 규칙을 한눈에 확인할 때 좋다.

- 현재 사용 중인 카드의 브랜드와 끝 4자리를 표시한다.
- 카드번호, 유효기간, 보안코드가 유효할 때만 저장할 수 있다.
- 저장 성공 후 새 카드 끝 4자리와 완료 안내를 표시한다.
- 저장 실패 시 기존 결제수단을 유지하고 재시도 방법을 안내한다.

Given-When-Then 시나리오형

조건과 행동, 결과의 관계가 중요하거나 예외 케이스가 많을 때 유용하다. Cucumber의 Gherkin 공식 문서는 Given을 초기 맥락, When을 사건이나 행동, Then을 기대 결과로 설명한다. 특히 Then은 내부 DB 상태보다 사용자가 관찰할 수 있는 화면·메시지·보고서 같은 결과를 적도록 권한다.

시나리오: 유효한 카드로 결제수단 변경 성공
  Given 유료 구독자가 로그인해 있고 기존 결제카드가 등록되어 있다
  When 유효한 새 카드 정보를 입력하고 저장한다
  Then 새 카드의 브랜드와 끝 4자리가 표시된다
  And "결제수단이 변경되었습니다" 안내가 보인다

시나리오: 유효하지 않은 카드 저장 실패
  Given 유료 구독자가 결제수단 변경 화면에 있다
  When 유효하지 않은 카드 정보를 입력하고 저장한다
  Then 잘못된 입력 항목 가까이에 오류 안내가 보인다
  And 기존 결제카드는 변경되지 않는다

Gherkin을 실제 자동화 테스트에 쓰지 않더라도, 이 구조는 PM·개발자·QA가 같은 조건과 결과를 읽게 하는 데 도움이 된다. 다만 모든 문장을 억지로 Given-When-Then으로 바꾸기보다 분기와 상태가 중요한 케이스에 선택적으로 쓰자.

좋은 인수 조건을 만드는 6가지 기준

1. 사용자가 관찰할 수 있는 결과를 쓴다

DB에 카드 정보가 저장된다보다 새 카드의 브랜드와 끝 4자리가 표시된다가 사용자 관점에서 검증하기 쉽다. 내부 구현 확인이 꼭 필요하다면 별도의 기술 작업이나 테스트 항목으로 분리한다.

2. 모호한 표현을 숫자나 상태로 바꾼다

• 나쁜 예: 빠르게 결과를 보여 준다.
• 좋은 예: 저장 요청 중 버튼을 비활성화하고 진행 표시를 노출한다.

성능 목표처럼 수치가 필요한 항목은 팀에서 실제 기준을 합의해 {{응답 시간 기준 — 실제 데이터로 교체}}처럼 남긴다. 근거 없는 숫자를 임의로 만들지는 말자.

3. 정상·예외·경계값을 나눈다

성공 케이스 하나만 있으면 QA가 실패 처리까지 추측해야 한다. 최소한 다음 질문을 확인한다.

• 입력값이 비어 있거나 형식이 틀리면?
• 사용 권한이 없거나 구독 상태가 바뀌면?
• 중복 클릭하거나 네트워크가 끊기면?
• 저장 직전에 다른 기기에서 정보가 변경되면?
• 가장 짧거나 긴 허용값에서는?

4. 구현 방식보다 업무 결과를 적는다

React 모달을 연다, POST API를 호출한다는 구현 상세다. 사용자 스토리의 인수 조건에는 변경 전 카드와 새 카드를 구분할 수 있다처럼 결과를 적고, 기술 제약은 개발 작업이나 설계 문서에 연결한다.

5. 한 조건에는 하나의 판단을 둔다

저장되고 알림이 오고 로그가 남고 관리자도 조회할 수 있다처럼 여러 결과를 한 줄에 묶으면 일부만 실패했을 때 판정하기 어렵다. 독립적으로 통과·실패를 판단할 수 있게 나눈다.

6. 개발 시작 전에 함께 확인한다

인수 조건은 PM 혼자 확정하는 정답지가 아니다. 백로그 정제나 스프린트 계획에서 디자이너·개발자·QA와 빠진 상태, 구현 제약, 테스트 가능성을 확인한다. Atlassian도 인수 조건을 명확하고 간결하며 객관적으로 검증 가능한 문장으로 작성하도록 안내한다.

사용자 스토리·인수 조건 실무 작성 순서

1. 사용자 문제를 한 문장으로 확인한다

문의, 인터뷰, 데이터, 현업 요청 중 무엇이 근거인지 남긴다. “카드 변경 메뉴가 필요하다”보다 “결제 실패로 구독이 중단되는 사용자가 직접 카드를 바꿀 수 없다”처럼 문제를 먼저 고정한다.

2. 사용자·목표·가치를 채운다

사용자를 회원처럼 너무 넓게 잡지 않는다. 권한이나 상황이 결과를 바꾼다면 유료 구독자, 조직 관리자, 초대받은 멤버처럼 구분한다.

3. 업무 규칙을 질문으로 꺼낸다

• 누가 접근할 수 있는가?
• 언제 변경할 수 있는가?
• 어떤 값이 유효한가?
• 성공 후 무엇이 달라지는가?
• 실패하면 기존 상태는 어떻게 되는가?

4. 인수 조건을 목록형으로 먼저 쓴다

정상 동작과 업무 규칙을 빠짐없이 목록으로 정리한다. 이후 조건·행동·결과가 얽힌 항목만 Given-When-Then으로 바꾸면 작성 부담이 줄어든다.

5. 예외와 경계값을 추가한다

빈 값, 최대 길이, 권한 없음, 중복 요청, 통신 오류처럼 자주 빠지는 케이스를 확인한다. 모든 예외를 한 스토리에 넣어 너무 커진다면 사용자 가치가 유지되는 단위로 나눈다.

6. 스토리 크기와 완료 기준을 점검한다

한 스프린트 안에 끝내기 어려울 만큼 크다면 스토리를 나눈다. 사용자 스토리별 인수 조건과 팀 전체에 적용되는 Definition of Done도 구분한다.

인수 조건과 Definition of Done 차이

둘 다 완료 판단에 쓰이지만 적용 범위가 다르다.

• 인수 조건: 특정 사용자 스토리나 기능이 충족해야 할 개별 조건
• Definition of Done: 모든 제품 증분에 공통으로 적용할 품질 기준

예를 들어 유효한 카드 저장 후 끝 4자리를 표시한다는 결제수단 변경 스토리의 인수 조건이다. 코드 리뷰 완료, 필수 자동화 테스트 통과, 사용자 문서 갱신은 팀의 공통 완료 기준에 가깝다. Atlassian의 Definition of Done 안내도 인수 조건은 특정 스토리나 기능에 적용하고, DoD는 제품 증분의 전반적인 품질과 완료를 판단하는 기준으로 구분한다.

바로 복사해 쓰는 사용자 스토리 템플릿

## [US-000] 사용자 스토리 제목

### 사용자 스토리
- [사용자/페르소나]로서,
- [목표/하려는 일]하고 싶다.
- 왜냐하면 [사용자 가치/문제 해결] 때문이다.

### 배경과 근거
- 문제 상황:
- 사용자 근거:
- 관련 요구사항·화면 ID:
- 범위에 포함하지 않는 것:

### 인수 조건
- AC-01:
- AC-02:
- AC-03:

### Given-When-Then 시나리오
시나리오:
  Given [초기 조건]
  When [사용자 행동 또는 사건]
  Then [관찰 가능한 결과]

### 확인할 예외·경계값
- 빈 값:
- 권한 없음:
- 중복 요청:
- 통신 오류:
- 최소·최대값:

### 연결 항목
- 디자인:
- 개발 티켓:
- 테스트케이스:
- 의사결정 로그:

사용자 스토리 검토 체크리스트

• 실제 사용자 또는 역할이 구체적으로 적혀 있다.
• 기능 이름보다 사용자가 달성할 목표가 중심이다.
• 왜 필요한가에 해당하는 가치가 보인다.
• 구현 기술이나 특정 UI를 불필요하게 고정하지 않았다.
• 인수 조건이 짧고 명확하며 객관적으로 검증 가능하다.
• 정상, 예외, 경계값이 구분되어 있다.
• Then이 사용자가 관찰할 수 있는 결과로 적혀 있다.
• 조건마다 통과·실패를 판정할 수 있다.
• 인수 조건과 팀 공통 Definition of Done을 섞지 않았다.
• 디자이너·개발자·QA가 개발 전에 함께 검토했다.
• 한 스프린트 안에 완료할 수 있는 크기다.
• 관련 화면·요구사항·테스트 항목이 연결되어 있다.

사용자 스토리 작성법 FAQ

사용자 스토리는 PM이 혼자 작성하나요?

PM이나 프로덕트 오너가 초안을 만들 수 있지만, 대화를 통해 완성하는 문서에 가깝다. 디자이너는 사용자 흐름과 상태를, 개발자는 구현 제약과 의존성을, QA는 검증 가능한 조건과 누락된 예외를 확인해야 한다.

인수 조건은 몇 개가 적당한가요?

정해진 개수보다 스토리의 핵심 성공과 주요 예외를 모두 판정할 수 있는지가 중요하다. 조건이 계속 늘어나고 서로 다른 사용자 목표가 섞인다면 하나의 큰 스토리를 여러 개로 나눌 신호일 수 있다.

모든 인수 조건을 Given-When-Then으로 써야 하나요?

아니다. 단순한 업무 규칙은 목록형이 읽기 쉽고, 상태·행동·결과의 조합이나 예외 흐름은 Given-When-Then이 유리하다. 팀이 빠르게 이해하고 검증할 수 있는 방식을 고르면 된다.

사용자 스토리가 요구사항 정의서를 대신하나요?

완전히 대신하지는 않는다. 사용자 스토리는 사용자 가치와 대화를 촉진하는 가벼운 단위다. 법적 요구, 상세 데이터 규칙, 비기능 요구사항, 외부 연동 계약처럼 별도 관리가 필요한 내용은 요구사항 정의서나 관련 명세에 남기고 ID로 연결하자.

사용자 스토리 작성법 핵심 정리

사용자 스토리 작성법의 핵심은 한 줄 문법을 예쁘게 맞추는 데 있지 않다. 사용자·목표·가치를 짧게 정리하고, 팀의 대화로 세부 사항을 맞춘 뒤, 검증 가능한 인수 조건으로 확인하는 것이 중요하다. 정상 흐름만 적지 말고 예외와 경계값까지 확인하자. Given-When-Then을 활용할 때는 구현 내부보다 사용자가 관찰할 수 있는 결과를 쓰면 개발과 테스트의 해석 차이를 훨씬 줄일 수 있다~

참고한 최신 출처

• Atlassian Agile Coach: User Stories with Examples and a Template
• Atlassian: What is Acceptance Criteria?
• Cucumber: Gherkin Reference
• Atlassian: What is the Definition of Done in Agile?