수용 기준 작성법: 결제 전 주문 확인 예시와 Given–When–Then

수용 기준(Acceptance Criteria)은 특정 사용자 스토리가 합의한 범위를 충족하려면 어떤 동작을 제공해야 하는지 설명합니다. 무엇이 표시되는지, 어떤 행동이 가능한지, 행동이 실패하면 어떻게 되는지를 관찰 가능한 조건으로 적습니다. 결제 전 주문 확인이라면 금액, 배송 방식 변경과 오류 상태를 먼저 정해야 합니다.

제품 기획을 위한 공유 작업 공간에 조건을 모으면 제품·디자인·개발·QA가 같은 예시를 보며 검토할 수 있습니다. 아래에서는 주문 확인 스토리의 기준을 작성하고, Given–When–Then 시나리오로 구체화한 뒤 완료 정의와 범위 밖 작업을 구분합니다.

1. 사용자 목표와 범위 정하기

먼저 사용자가 얻으려는 결과를 한 문장으로 적습니다. “재방문 고객으로서, 잘못된 내용을 수정할 수 있도록 결제 전에 주문을 확인하고 싶다.” 이 예시에서는 고객이 로그인했고, 장바구니에 상품이 있으며, 배송 주소가 저장돼 있다고 가정합니다. 기존 결제 흐름의 주문 확인 단계가 범위이며, 계정 생성이나 새 결제 서비스 연동은 포함하지 않습니다.

어떤 수정이 가능한지도 정합니다. 여기서는 사용 가능한 배송 방식을 선택하거나, 이전 단계로 돌아가 장바구니와 주소를 수정할 수 있습니다. 주문 확인 화면에서 상품을 직접 삭제하거나, 할인 코드를 추가하거나, 결제 제공업체를 바꾸는 일은 별도의 결정입니다. 이 경계가 없으면 “오류 수정”에 여러 기능이 포함돼 있다고 각자 다르게 생각할 수 있습니다.

“고객이 모든 내용을 확인할 수 있다”는 초안은 무엇을 보여야 하는지 숨깁니다. “모든 내용”을 실제 필드와 가능한 행동으로 바꾸세요. 데이터 저장 방식을 미리 정하지 않아도, 디자이너는 표현할 내용을, QA는 확인할 결과를 알 수 있습니다.

2. 모호한 말을 관찰 가능한 조건으로 바꾸기

“결제가 쉬워야 한다”는 목표는 사람마다 다르게 해석할 수 있습니다. 이 스토리에서는 다음 다섯 조건을 합의합니다.

1. 주문 요약: 결제로 넘어가기 전에 각 상품의 이름·수량·가격, 상품 소계, 배송비, 세액, 통화와 총액이 표시된다.
2. 배송 방식 변경: 다른 배송 방식을 선택하면 결제로 넘어가기 전에 배송비와 총액이 갱신된다.
3. 불완전한 주소 또는 배송 불가: 필수 주소 정보가 빠졌거나 해당 주소에서 선택한 배송 방식을 이용할 수 없으면, 문제와 주소·배송 방식의 수정 방법을 보여 주고 결제 진행을 막는다.
4. 가격 갱신: 새 배송 가격을 요청하는 중이거나 요청에 실패하면 이전 총액으로 결제를 진행할 수 없다. 실패 시 재시도 방법을 제공하고 장바구니 내용을 유지한다.
5. 수정 후 복귀: 장바구니나 주소를 수정하러 돌아가도 나머지 주문 정보는 유지된다. 주문 확인 단계로 다시 오면 수정된 내용이 요약에 반영된다.

이는 이 예시에서 의도한 동작입니다. 지원하는 배송 방식, 세금 계산, 주소별 배송 가능 여부는 제품팀이 정한 규칙을 참조해야 합니다. 수용 기준을 쓰면서 새로운 세금이나 배송 정책을 만들어서는 안 됩니다.

계산의 해석 차이는 고정된 테스트 데이터로 줄일 수 있습니다. 예시 데이터에서 개당 미화 20달러인 상품 두 개의 소계는 40달러입니다. 일반 배송비는 5달러, 테스트 응답에 포함된 세액은 4달러이므로 총액은 49달러입니다. 빠른 배송의 테스트 응답은 배송비 9달러와 세액 4달러를 반환하므로 총액은 53달러입니다. 이는 세율 규칙이 아니라 고정된 입력값이며, 주문 확인 화면이 반환된 금액을 일관되게 표시하는지 확인하기 위한 것입니다.

3. 수용 기준·완료 정의·제외 범위 구분하기

수용 기준은 지금 논의하는 특정 동작에 적용합니다. 완료 정의(Definition of Done)는 스크럼에서 제품 증분(Increment)에 요구되는 품질 상태를 설명합니다. Scrum.org의 설명(영어)처럼 특정 기능의 조건을 충족했다고 팀의 공통 품질 기준까지 자동으로 충족한 것은 아닙니다.

제외 항목은 스토리 옆에 두되 통과한 수용 기준으로 세지 않습니다. “결제 제공업체 재설계는 범위 밖”이라는 문장은 주문 확인이 작동한다는 증거가 아닙니다. 마찬가지로 “데이터베이스 필드 생성”은 구현 작업일 수 있지만 고객이 무엇을 보게 되는지는 설명하지 않습니다.

선택한 배송 방식을 사용할 수 없는 상황은 제외한 기능과 다릅니다. 현재 흐름 안에서 발생하는 오류 상태이므로 동작을 결정해야 합니다. 이를 범위 밖으로 옮기면 고객의 다음 행동이 정의되지 않습니다. 스토리가 너무 커진다면 사용할 수 있는 흐름을 유지하면서 작업을 나누고, 바뀐 경계를 명시적으로 합의합니다.

4. Given–When–Then 시나리오 작성하기

조건이 특정 상태와 행동에 따라 달라질 때 Given–When–Then이 유용합니다. Cucumber의 Gherkin 안내(영어)는 시작 상황, 발생한 행동이나 이벤트, 관찰 가능한 결과를 구분합니다. 자동 테스트와 연결하기 전에도 이 구조로 팀의 이해를 맞출 수 있습니다.

시나리오 1: 현재 주문 확인

• Given — 전제: 예시 장바구니와 완전한 배송 주소가 있고 일반 배송이 선택돼 있다.
• When — 행동: 고객이 주문 확인 화면을 연다.
• Then — 결과: 상품, 주소, 배송 방식, 소계 40달러, 배송비 5달러, 세액 4달러와 총액 49달러가 표시된다.

시나리오 2: 배송 방식 변경

• Given — 전제: 고객이 일반 배송을 선택한 예시 주문을 확인하고 있다.
• When — 행동: 빠른 배송을 선택하고 가격 요청이 성공한다.
• Then — 결과: 결제로 넘어가기 전에 배송비 9달러와 총액 53달러가 표시된다.

시나리오 3: 누락된 주소 정보 수정

• Given — 전제: 필수 주소 항목이 빠져 있다.
• When — 행동: 고객이 주문 확인 단계에서 다음으로 진행하려 한다.
• Then — 결과: 누락된 항목과 주소 수정 방법이 표시된다. 장바구니를 유지한 채 결제 전 단계에 머문다.

시나리오 4: 가격 갱신 실패 후 재시도

• Given — 전제: 고객이 배송 방식을 바꿨고 새 총액을 기다리고 있다.
• When — 이벤트: 가격 요청이 실패한다.
• Then — 결과: 금액을 갱신하지 못했다는 안내와 재시도 방법을 제공하고, 이전 배송 가격으로 결제를 진행하지 못하게 한다.

시나리오 하나는 질문 하나에 답하도록 씁니다. 장바구니 수정, 주소 변경, 할인 적용과 결제를 모두 묶은 긴 시나리오는 실패했을 때 어떤 규칙의 문제인지 알기 어렵습니다. 고객 이름만 바꿔 같은 조건을 반복하기보다, 다른 규칙을 논의해야 할 때 예시를 추가합니다.

5. 구현 전에 미확정 질문 해결하기

제품 담당자는 의도한 범위인지, 디자이너는 각 상태를 사용자가 어떻게 이해할지, 개발자는 어떤 의존성이 동작을 바꿀 수 있는지, QA는 결과를 어떻게 관찰할지 검토합니다. “저장된 주소가 더는 배송 대상이 아니면 어떻게 되는가?”는 제품 결정이 필요한 질문이지, 테스트 기대값을 임의로 정할 문제가 아닙니다.

미확정 질문은 합의한 기준과 따로 적습니다. 예를 들어 “이전에 선택한 배송 방식을 쓸 수 없게 되면 다른 방식을 미리 선택할 것인가, 고객이 새로 고르게 할 것인가?”에 따라 화면과 테스트가 모두 달라집니다. 결정 후에는 영향을 받는 기준과 시나리오를 함께 수정합니다.

새 정보로 범위가 바뀌면 어려운 조건을 조용히 삭제하지 말고 결정 이유를 남깁니다. 주소 편집을 다른 스토리로 나눠도 주문 확인에서는 그 동작으로 이동하고 돌아오는 길이 명확해야 합니다. 수용 기준을 모두 충족한 뒤에도 팀의 완료 정의는 적용됩니다.

6. Boardmix에 스토리와 예시 연결하기

Boardmix 보드 상단에 스토리를 놓고 아래에 합의한 기준, 구체적인 예시, 미확정 질문, 제외 범위의 네 영역을 만듭니다. 배송 변경을 AC-2처럼 기준 ID로 표시하고 관련 시나리오를 옆에 배치하세요. 어떤 기준에 예시가 빠졌는지, 어떤 질문이 이미 합의한 조건을 바꿀 수 있는지 보기 쉬워집니다.

공통 완료 정의는 매번 시나리오에 복사하지 말고 별도의 참조 영역에 둡니다. 논의 후에는 합의한 기준을 팀의 개발 업무 기록으로 옮기고, 보드에는 규칙·예시·결정 사이의 연결을 남길 수 있습니다.

Boardmix 보드 열기에서 주문 확인 스토리와 네 시나리오를 배치해 보세요. 배송 방식 변경부터 살펴보면 “총액이 갱신된다”를 모두 같은 의미로 이해하는지 확인할 수 있습니다.