사용자 스토리(user story)를 위한 강력한 수락 기준(acceptance criteria) 작성하기

수락 기준(acceptance criteria): 버그를 가장 싸게 잡는 곳은 스토리입니다

QA에서 발견된 버그는 스토리 리파인먼트(refinement) 단계에서 예방했을 때 비용의 약 한 자릿수가 더 들고, 프로덕션에서 발견된 버그는 또 한 자릿수 더 비싸집니다. 수락 기준 — 스토리가 스프린트(sprint)에 진입하기 전에 작성하는 테스트 가능한 통과/실패 조건 — 은 그 예방이 실제로 일어나는 지점입니다. 이를 건너뛰거나 스프린트 시작 시점에 테스트 케이스로 갈음하는 팀은 코드 리뷰에서 범위를 논쟁하고 릴리즈 주에 트리아지(triage)하게 됩니다. Agile Alliance와 Atlassian, Aha!를 비롯한 프로덕트 조직은 같은 패턴을 20년 동안 기록해 왔습니다 — 엔지니어링과 프로덕트가 '완료'에 대해 이견을 가질 때, 그 이견은 늦고 비싸게 표면화됩니다.

ESI International의 자주 인용되는 산업 조사는 그 수치를 50%로 제시했습니다 — 프로젝트 실패의 절반이 주로 잘못된 요구사항 계획과 커뮤니케이션 이슈에서 비롯됩니다. 연구마다 수치는 다르지만 정성적 결론은 일관됩니다 — 릴리즈에서 딜리버리(delivery) 문제처럼 보이는 대부분은 실제로는 리파인먼트 단계의 요구사항 문제입니다.

테스트 케이스는 수락 기준의 대체재가 아닙니다

많은 팀은 스프린트 초반에 테스트 케이스를 일찍 작성하고 이를 수락 기준의 보완재로 다룹니다. 두 산출물은 내용이 겹치지만 역할이 다릅니다. 테스트 케이스는 QA가 동작을 어떻게 검증할지를 기술합니다 — QA의 소유물이고 절차서처럼 읽힙니다. 수락 기준은 스토리를 수락하기 위해 팀이 무엇이 참이어야 한다고 합의했는지를 기술합니다 — 프로덕트와 팀 전체의 소유물이고 계약서처럼 읽힙니다. 차이는 세 시점에서 의미를 가집니다:

• 스프린트 플래닝: 엔지니어는 추정의 근거가 될 계약이 필요하지, 아직 쓸 수 없는 테스트 계획이 필요한 것이 아닙니다. 수락 기준은 추정을 시작하게 만들고, 테스트 케이스는 추정이 끝났음을 가정합니다.
• 코드 리뷰: 리뷰어는 범위 확장을 막기 위해 합의된 범위가 필요합니다. 테스트 케이스는 무엇이 테스트되었는지를 알려줄 뿐, 무엇이 만들어졌어야 하는지를 알려주지 않습니다.
• QA 핸드오프: QA는 수락 기준에서 테스트 케이스를 도출하며 합의된 동작 위에 검증 로직을 덧입힙니다. 수락 기준 단계를 건너뛰면 QA는 검증기를 작성하면서 동시에 계약을 발명해야 합니다 — 범위 누수와 뒤늦은 모호함의 알려진 원인입니다.

Agile Alliance 용어집은 수락 기준을 사용자 또는 이해관계자(stakeholder)가 스토리를 수락하기 위해 충족해야 하는 조건으로 정의합니다. Definition of Done 항목은 기능과 무관하게 스토리가 통과해야 하는 상시 기준선입니다. 둘은 함께 작동합니다 — 스토리별 AC와 팀 차원의 DoD — 어느 한쪽이 다른 쪽을 대체하지 않습니다.

Write strong acceptance criteria for a user story Prompt 작동 방식

프롬프트는 6단계로 진행됩니다. Step 1은 스토리 자체의 형식을 검증합니다. "As a [user], I want [capability] so that [outcome]"에서 user, capability, outcome 중 어느 하나가 모호하면 스토리부터 수정합니다. 약한 수락 기준의 대부분은 약한 기저 스토리에서 비롯되며, 프롬프트는 그 원천을 가리지 않습니다.

Step 2는 6–10개 조건의 규칙 기반 체크리스트를 만듭니다. 프롬프트가 강제하는 세 가지 규율은 — 각 조건은 독립적으로 통과/실패해야 하고(두 테스트가 한 항목에 숨지 않도록), 공유 어휘를 사용해야 하며, HOW가 아닌 WHAT을 기술해야 한다는 것입니다. ProductPlan의 수락 기준 용어집은 같은 함정을 지적합니다 — 기준이 구현 세부로 새면 엔지니어링을 과하게 제약하고 동작은 적게 명세하게 됩니다.

Step 3은 가장 위험도가 높은 2–3개 경로에 Given/When/Then 시나리오를 추가합니다. Given/When/Then은 두 표준 양식 중 더 엄밀한 쪽입니다 — 전제 조건, 액션, 관찰 가능한 결과를 강제하기 때문에 실행 가능한 테스트로 직접 매핑됩니다. Aha!의 요구사항 가이드는 상태 변화의 타이밍이나 순서가 중요한 시나리오에는 Given/When/Then을, 그 외에는 규칙 기반 체크리스트를 권장합니다. 비자명한 스토리에는 대부분 두 가지가 모두 필요하므로 프롬프트는 둘 다 사용합니다.

Step 4는 엣지 케이스와 부정 기준을 표면화합니다 — 빈 입력, 경계 최댓값, 권한 거부 경로, 네트워크 단절, 동시 편집. QA가 해피 패스만 테스트했을 때 프로덕션에서 발목을 잡는 시나리오들입니다. 명시적인 "out-of-scope" 항목 2–3개를 요구하는 이유는, 실무에서 명확한 out-of-scope 목록이 충실한 in-scope 목록보다 더 많은 버그를 막기 때문입니다. 무엇을 만들지 않아야 하는지 아는 엔지니어는 그것을 만들지 않습니다.

Step 5는 스토리를 팀의 상시 Definition of Done에 교차 검증합니다 — 테스트 작성, 문서 업데이트, 텔레메트리 출시, 접근성 점검. 수락 기준은 스토리별이고 DoD는 상시 기준선입니다. Aha!의 비교 페이지는 그 계층을 설명합니다 — 스토리가 AC를 충족했는데도 테스트가 없다면 DoD에 실패할 수 있습니다. 둘을 한 산출물로 다루는 것(가장 흔한 혼동)은 둘 중 하나가 조용히 빠지도록 만듭니다.

Step 6은 스토리가 스프린트에 진입하기 전에 합의해야 하는 사람을 지정합니다 — 엔지니어링 리드, 디자이너, QA, 스토리의 user 역할에 언급된 모든 이해관계자. 이 단계가 산출물을 문서에서 계약으로 전환하는 순간입니다. 사인오프가 없으면 기준은 PM 한 사람의 위시리스트로 기능합니다.

양식 선택: 규칙 기반 vs Given/When/Then vs 하이브리드

Atlassian의 사용자 스토리 가이드는 수락 기준을 스토리가 완료로 간주되기 위한 필요 조건으로 기술합니다. 어떤 양식을 쓸지에 대해서는 침묵하는데, 양식 선택이 맥락 의존적이기 때문입니다:

• 규칙 기반 체크리스트는 작고 독립적인 조건이 많은 스토리에 가장 적합합니다(설정 패널, 검증 규칙, 리스트 뷰).
• Given/When/Then 시나리오는 분기 동작이나 상태 전이가 있는 스토리에 가장 적합합니다(체크아웃 흐름, 비동기 잡, 권한 경계).
• 하이브리드는 현실적인 기본값입니다 — 조건의 폭은 체크리스트로, 정합성을 시점/순서가 결정하는 2–3개 시나리오는 Given/When/Then으로.

한 양식을 도그마처럼 고수하는 팀은 과·과소 명세를 반복하는 경향이 있습니다. 프롬프트는 대부분의 스토리가 둘 다 필요하다고 보고 둘 다 요구합니다. Mountain Goat Software의 사용자 스토리 템플릿 글은 같은 메시지를 기저 스토리 차원에서 반복합니다 — 양식 결정은 user, capability, outcome에 대한 명료함 다음에 옵니다.

When to Use It

• 팀이 스프린트 시작 시점에 수락 기준 대신 테스트 케이스를 작성하고 있고, QA 또는 릴리즈에서 그 비용을 체감했습니다.
• 신규 PM이 합류 중이고, 드리프트(drift)가 시작되기 전에 리파인먼트 표준을 설치하고 싶습니다.
• 복잡한 스토리가 프로덕션에서 늦은 엣지 케이스를 반복적으로 표면화합니다 — 그 종류의 작업에 대한 AC가 너무 얇습니다.
• 디자이너, 엔지니어, QA가 함께하는 크로스 펑셔널(cross-functional) 팀이고, 각 역할이 함께 읽는 단일 산출물이 필요합니다.
• 벤더(vendor) 주도 스펙 프로세스에서 프로덕트 소유 스토리 리파인먼트로 이동 중입니다.

Common Pitfalls

• 복합 기준. "사용자가 저장할 수 있고 저장이 세션 간에 유지된다"는 한 항목으로 위장된 두 조건입니다. 분리하세요 — 각 조건은 독립적으로 통과/실패해야 합니다.
• 위장된 구현. "300ms 디바운스로 API를 호출한다"는 WHAT이 아닌 HOW를 기술합니다. 수락 기준은 관찰 가능한 동작을 기술하고, 구현은 엔지니어링의 영역입니다.
• out-of-scope 목록 부재. out-of-scope가 없는 10줄짜리 in-scope 목록은 엔지니어링이 조용히 스토리를 확장하도록 허용합니다. out-of-scope 목록은 모양을 정의하는 음의 공간입니다.

Sources

• User stories with examples and a template — Atlassian
• What are acceptance criteria? — Aha!
• Acceptance criteria vs definition of done — Aha!
• Acceptance criteria glossary — ProductPlan
• Acceptance criteria glossary entry — Agile Alliance
• Definition of Done glossary entry — Agile Alliance
• Advantages of the user story template — Mountain Goat Software