수용 기준(Acceptance Criteria)과 요구사항의 관계

개념

요구사항과 수용 기준의 관계

요구사항은 "무엇이 필요한가"를 넓게 말한다. **수용 기준(Acceptance Criteria, AC)**은 그 요구사항이 "언제 완료로 인정되는가"를 구체적인 통과/실패 조건으로 쪼갠 것이다. 레슨 2에서 배운 "테스트 가능성"을 실제로 문서 형태로 만든 결과물이 AC라고 볼 수 있다.

요구사항: 사용자는 이메일과 비밀번호로 회원가입할 수 있다.

수용 기준:

• 유효한 이메일 형식과 8자 이상 비밀번호를 입력하면 가입이 완료된다
• 이미 가입된 이메일이면 "이미 가입된 이메일입니다" 메시지를 보여준다
• 비밀번호가 8자 미만이면 가입 버튼이 비활성화된다
• 가입 완료 시 인증 메일이 발송된다

하나의 요구사항에서 여러 개의 AC가 나온다. AC 하나하나가 "이 조건이 충족됐는가?"를 명확히 판단할 수 있는 문장이어야 한다 — 그래서 레슨 2의 테스트 가능성 기준을 그대로 만족해야 한다.

Given-When-Then 형식

AC를 쓸 때 자주 쓰는 형식이 Given-When-Then이다. "어떤 상황에서(Given), 무엇을 하면(When), 어떻게 되어야 한다(Then)"를 구조화한다.

Given 사용자가 회원가입 페이지에 있고
When  유효한 이메일과 8자 이상 비밀번호를 입력하고 가입 버튼을 누르면
Then  계정이 생성되고 인증 메일이 발송된다

Given 사용자가 회원가입 페이지에 있고
When  이미 가입된 이메일을 입력하면
Then  "이미 가입된 이메일입니다" 메시지가 표시되고 가입은 진행되지 않는다

이 형식이 좋은 이유는 하나의 AC가 정확히 하나의 시나리오만 다루도록 강제하기 때문이다. "그리고(and)"로 여러 조건을 욱여넣고 싶어지는 유혹을 구조 자체가 막아준다. 이 형식은 모듈 7에서 다룰 BDD(Behavior-Driven Development)와 Cucumber 같은 도구에서 실행 가능한 테스트로 그대로 이어진다 — 지금 잘 써두면 나중에 자동화까지 재사용할 수 있다.

AC와 테스트 케이스는 다르다

AC는 "무엇을 확인해야 완료인가"의 경계를 정의한다. 테스트 케이스는 그 AC를 검증하기 위한 구체적인 실행 절차다. AC 하나에서 여러 테스트 케이스가 나올 수 있다 — 예를 들어 "8자 이상 비밀번호" AC 하나에서도 경계값 분석(모듈 3에서 배운다)을 적용하면 7자, 8자, 9자를 각각 테스트하는 여러 케이스가 나온다.

누가 쓰는가

이상적으로는 기획자·개발자·QA 세 역할이 함께 AC를 만든다("three amigos"라고도 부른다). QA만 혼자 쓰면 실제 구현 제약을 놓칠 수 있고, 기획자만 쓰면 테스트 가능성이 떨어질 수 있다. 함께 쓰는 과정 자체가 이전 레슨들에서 다룬 모호함과 누락을 미리 걸러내는 효과가 있다.

실무에서 왜 필요한가

"이 기능, 완료된 거 맞나요?"라는 질문에 대한 논쟁은 실무에서 자주 일어난다. AC가 명확히 있으면 이 논쟁은 사실 확인만으로 끝난다 — "AC 3번 조건이 아직 안 됐으니 완료가 아니다"처럼. AC가 없으면 "제 생각엔 이 정도면 된 것 같은데요"식의 주관적 공방이 된다. AC는 QA와 개발, 기획 사이의 객관적인 합의 기준을 만든다는 점에서 실무 갈등을 줄이는 가장 실용적인 도구 중 하나다.

실습 과제

과제 1 — AC 작성하기 (15분)

다음 요구사항에 대해 Given-When-Then 형식으로 AC를 3개 이상 작성한다.

"사용자는 장바구니에서 상품 수량을 변경할 수 있다. 단, 재고 수량을 초과할 수 없다."

과제 2 — AC에서 테스트 케이스 도출하기 (10분)

과제 1에서 작성한 AC 중 하나를 골라, 그 AC를 검증할 구체적인 테스트 케이스를 2~3개 적는다. (힌트: 경계값을 생각해본다 — 재고가 정확히 남은 만큼일 때는?)

자가 체크리스트

• 요구사항과 수용 기준의 관계를 "넓은 것 vs 구체적인 통과 조건"으로 설명할 수 있다
• Given-When-Then 형식으로 AC를 직접 작성할 수 있다
• 하나의 AC에서 여러 테스트 케이스가 나올 수 있다는 것을 이해한다
• AC를 세 역할(기획·개발·QA)이 함께 쓰는 것이 왜 유리한지 설명할 수 있다

흔한 실수

• AC 하나에 여러 시나리오를 욱여넣는다. "Given ... When A 또는 B를 하면 ... Then ..." 식으로 조건을 여러 개 섞으면 통과/실패 판단이 애매해진다. 시나리오마다 AC를 나눈다.
• AC를 테스트 케이스와 똑같이 취급한다. AC는 "무엇이 충족되어야 하는가"의 경계이고, 테스트 케이스는 그걸 확인하는 구체적 절차다. AC만 보고 "이 정도면 테스트 다 됐다"고 착각하면 안 된다.
• AC를 QA 혼자 사후에 작성한다. 개발이 다 끝난 뒤에 AC를 쓰면, 이미 구현된 방식에 AC를 끼워 맞추게 되어 원래 목적(사전에 기준을 합의하는 것)이 무색해진다.

참고 자료

• Dan North, "What's in a Story?" — Given-When-Then 형식(Gherkin)의 대중화에 기여한 글
• Atlassian — Acceptance Criteria: Examples and Best Practices — 실무 작성 팁