14.6 사용자 스토리(User Story) 작성과 수용 기준(Acceptance Criteria) 정의

1. 사용자 스토리의 개념과 구조

사용자 스토리(User Story)는 소프트웨어 개발에서 기능적 요구 사항을 최종 사용자의 관점에서 간결하게 표현하는 형식이다. Cohn(2004)에 따르면, 사용자 스토리는 “누가(Who), 무엇을(What), 왜(Why)“를 명시하는 짧은 서술로, 개발 팀과 이해관계자 간의 대화(Conversation)를 촉발하는 약속(Promise for a Conversation)의 기능을 수행한다.

사용자 스토리의 표준 형식은 다음과 같다. “As a [사용자 역할], I want [기능/행동] so that [가치/편익].”

이 형식의 세 구성 요소는 각각 고유한 기능을 수행한다. 사용자 역할(Role)은 해당 기능을 필요로 하는 구체적 사용자 유형을 식별한다. 이를 통하여 개발 팀은 누구를 위하여 개발하는가를 명확히 인식한다. 기능/행동(Feature/Action)은 사용자가 수행하고자 하는 구체적 활동을 서술한다. 가치/편익(Value/Benefit)은 해당 기능이 사용자에게 제공하는 가치를 명시한다. 이를 통하여 기능의 존재 이유(Rationale)가 투명해진다.

1.1 Ron Jeffries의 3C 모형

Jeffries(2001)는 사용자 스토리를 Card, Conversation, Confirmation의 세 요소(3C)로 구성되는 것으로 설명하였다. Card는 사용자 스토리의 간결한 서술로, 물리적 또는 디지털 카드에 기록된다. Conversation은 프러덕트 오너와 개발 팀 간의 대화를 통하여 스토리의 세부 사항이 명확화되는 과정이다. Confirmation은 수용 기준(Acceptance Criteria)을 통하여 스토리의 완료가 검증되는 과정이다.

2. 효과적인 사용자 스토리 작성의 원칙

2.1 적절한 세분화 수준(Granularity)

사용자 스토리는 적절한 크기로 세분화되어야 한다. 지나치게 큰 스토리(Epic)는 단일 스프린트 내에 완료하기 어려우며, 지나치게 작은 스토리는 관리 비용이 과도해진다.

에픽(Epic)은 복수의 스프린트에 걸치는 대규모 사용자 스토리이다. 에픽은 실행 가능한 크기의 하위 스토리로 분해(Decomposition)되어야 한다. 스토리 분해의 기법으로는 워크플로 단계별 분해, 사업 규칙별 분해, 데이터 변형별 분해, 그리고 인터페이스별 분해 등이 활용된다.

2.2 사용자 중심적 서술

사용자 스토리는 기술적 구현 방법이 아닌 사용자의 관점에서 서술되어야 한다. “데이터베이스에 인덱스를 추가한다“는 기술적 과업(Technical Task)이지 사용자 스토리가 아니다. “사용자로서 검색 결과를 2초 이내에 확인하고 싶다“가 사용자 스토리의 올바른 서술이다.

딥테크 기업에서는 최종 사용자가 직접 사용하는 기능 외에도, 시스템 관리자, 운영자, 규제 감사자 등 다양한 역할의 사용자를 고려하여야 한다. 또한 비기능적 요구 사항(성능, 보안, 안전, 확장성)도 사용자 스토리 형식으로 표현될 수 있다. “시스템 관리자로서, 시스템 장애 발생 시 5분 이내에 경고를 수신하고 싶다“와 같은 형식이다.

3. 수용 기준(Acceptance Criteria)의 정의

3.1 수용 기준의 개념과 기능

수용 기준(Acceptance Criteria)은 사용자 스토리의 완료를 판정하기 위한 명확하고 검증 가능한 조건의 집합이다. 수용 기준은 프러덕트 오너가 개발 결과물의 인수(Acceptance) 여부를 판단하는 근거이며, 동시에 개발 팀이 구현의 범위와 품질을 이해하는 지침이다.

수용 기준의 핵심 기능은 다음과 같다. 범위의 명확화(Scope Clarification)이다. 수용 기준은 해당 스토리에 포함되는 것과 포함되지 않는 것의 경계를 명확히 한다. 시험의 근거(Basis for Testing)이다. 수용 기준은 인수 시험(Acceptance Testing)의 시험 케이스(Test Case)를 도출하는 직접적 근거가 된다. 완료의 합의(Definition of Done at Story Level)이다. 프러덕트 오너와 개발 팀이 스토리의 완료에 대하여 사전에 합의하는 계약의 기능을 수행한다.

3.2 수용 기준의 작성 형식

수용 기준의 작성에 널리 활용되는 형식은 다음 두 가지이다.

Given-When-Then(GWT) 형식은 행동 주도 개발(Behavior-Driven Development, BDD)에서 유래한 형식이다. Given(전제 조건)은 시스템의 초기 상태를 명시한다. When(행위)은 사용자가 수행하는 행동을 명시한다. Then(기대 결과)은 행위의 결과로 나타나야 하는 시스템의 상태를 명시한다.

규칙 기반(Rule-based) 형식은 충족되어야 하는 조건을 목록 형태로 나열하는 형식이다. 각 조건은 명확하고 검증 가능하여야 한다.

3.3 수용 기준 작성의 원칙

효과적인 수용 기준은 다음 원칙을 준수하여야 한다. 검증 가능성(Testability)이다. 각 기준은 통과/실패(Pass/Fail)로 명확히 판정 가능하여야 한다. 구체성(Specificity)이다. 모호한 표현(“빠르게”, “잘 동작하는” 등)을 피하고, 구체적 수치나 조건으로 명시한다. 독립성(Independence)이다. 각 기준은 다른 기준의 충족 여부와 무관하게 독립적으로 검증 가능하여야 한다. 완전성(Completeness)이다. 해당 스토리의 가치 전달에 필요한 모든 조건이 포함되어야 한다. 간결성(Conciseness)이다. 불필요하게 장황한 서술을 피하고, 핵심 조건에 집중한다.

4. 딥테크 기업에서의 특수 고려 사항

딥테크 기업에서 사용자 스토리와 수용 기준의 작성에는 다음과 같은 특수한 고려 사항이 존재한다.

비기능적 요구 사항의 비중이 높다. 성능(처리 속도, 지연 시간), 안전(결함 허용, 안전 무결성 수준), 보안(암호화, 접근 통제), 그리고 규제 준수(인증 기준 충족) 등 비기능적 요구 사항이 기능적 요구 사항 못지않게 중요하며, 이를 수용 기준에 구체적으로 반영하여야 한다.

기술적 탐색 스토리의 관리이다. 기술적 실현 가능성이 불확실한 항목에 대하여는 탐색 스토리(Spike)를 작성하고, 탐색의 목적, 시간 제한, 그리고 기대되는 산출물(결정 사항, 프로토타입, 기술 보고서 등)을 수용 기준으로 정의한다.

하드웨어-소프트웨어 통합 스토리이다. 하드웨어와 소프트웨어가 결합된 기능에 대한 스토리는 양 영역의 인터페이스 사양을 수용 기준에 포함시켜야 하며, 검증 환경(실제 하드웨어, 시뮬레이터, HIL 환경 등)을 명시하여야 한다.