‘관리자가 주문을 승인할 수 있게 해주세요.’ 문장만 보면 간단합니다. 개발팀은 승인 버튼을 만들고, 고객은 승인이 끝나면 ERP에 반영되고 담당자에게 통보되며 중복 승인은 막힐 것이라고 기대할 수 있습니다. 양쪽 모두 같은 요구사항에 동의했다고 생각하지만 완료의 기준은 다릅니다. 인수 기준은 이 간극을 개발이 끝난 뒤가 아니라 시작 전에 드러내는 도구입니다.
기능 이름보다 사용자의 목적부터 쓴다
‘승인 버튼’은 구현 요소입니다. 사용자의 필요는 ‘승인 권한이 있는 관리자가 검토한 주문만 후속 처리로 넘어가게 한다’일 수 있습니다. 누가, 어떤 상황에서, 무엇을 얻으려 하는지 확인하면 기능 범위가 달라집니다. GOV.UK의 사용자 필요 가이드도 해결책을 먼저 정하기보다 실제 사용자의 목적과 제약을 조사하라고 권합니다.
하나의 요구사항이 너무 크면 검수할 수 있는 단위로 나눕니다. 승인 대상 조회, 승인 실행, ERP 전송, 실패 후 재처리, 기록 조회는 각각 다른 성공 조건을 가집니다. 반대로 버튼 색상이나 내부 테이블 구조처럼 고객이 관찰할 수 없는 구현 선택을 인수 기준으로 박아 넣으면 필요한 변경을 어렵게 만듭니다.
‘완료’는 관찰 가능한 결과로 표현한다
좋은 기준은 테스트하는 사람이 같은 조건에서 같은 결론을 내릴 수 있어야 합니다. ‘빠르게 승인된다’는 모호합니다. ‘승인 권한이 있는 사용자가 대기 주문을 승인하면 상태가 승인으로 바뀌고 승인자와 시각이 기록된다’는 확인할 수 있습니다. 성능이 중요하다면 대상 데이터 규모와 측정 환경을 함께 적어야 숫자가 의미를 가집니다.
Azure Boards의 사용자 스토리 가이드는 작업 시작 전 고객 인수 기준을 분명히 하고 이를 인수 테스트의 바탕으로 쓰도록 설명합니다. 즉 인수 기준은 개발팀이 나중에 만든 결과를 정당화하는 문서가 아니라, 고객과 팀이 함께 기대를 맞추는 대화의 기록입니다.
정상 흐름 하나로 끝내지 않는다
시나리오는 최소한 정상, 권한 없음, 중복·충돌, 외부 연동 실패를 살펴봅니다. 예를 들어 승인 버튼을 두 번 누르면 주문이 두 번 전송되는지, 이미 취소된 주문은 어떻게 보이는지, ERP가 응답하지 않으면 화면에 무엇을 보여주는지 정합니다. 모든 예외를 처음부터 구현할 필요는 없지만 미정인 사항은 미정이라고 표시해야 합니다. 침묵을 ‘고객이 동의했다’로 해석하면 나중에 분쟁이 됩니다.
Cucumber의 Gherkin 참고 문서는 Given·When·Then을 각각 전제 조건, 행동, 관찰 가능한 결과로 설명합니다. 형식을 반드시 써야 하는 것은 아니지만 ‘주어진 상황에서 어떤 행동을 하면 무엇이 확인되는가’를 짧게 쓰는 습관은 도움이 됩니다. 내부 구현보다 사용자에게 보이는 결과를 중심에 둡니다.
인수 테스트는 마지막 날 처음 보여주는 행사가 아니다
개발 전에 대표 시나리오를 고객과 검토하고, 개발 중에는 샘플 데이터와 권한 계정으로 실행해 봅니다. 실제 운영 데이터에는 개인정보나 복잡한 예외가 있어 테스트 환경과 다를 수 있습니다. 그래서 인수 테스트에는 어떤 환경과 데이터로 검증할지, 외부 시스템이 연결되는지, 누가 최종 확인할지 명시합니다.
변경 요청이 생기면 기존 기준 중 무엇이 달라지는지 표시합니다. 작은 문구 변경처럼 보여도 알림 대상이나 정산 결과가 바뀔 수 있습니다. 변경 전·후의 기대 결과와 일정·비용 영향을 함께 검토하면 ‘요구사항은 그대로인데 구현만 조금 바뀐다’는 착시를 줄일 수 있습니다.
회의에서 인수 기준을 쓰기 어렵다면 실제 데이터를 한 건 고르는 것이 도움이 됩니다. 대기 주문 하나, 승인 권한이 없는 직원 하나, 응답하지 않는 외부 시스템 하나를 놓고 화면에 무엇이 보여야 하는지 말해 봅니다. 이해관계자가 서로 다른 답을 한다면 바로 그 지점이 아직 합의되지 않은 요구사항입니다. 이 차이를 개발 전에 발견하는 것이 문서 작성 자체보다 값집니다.
작성 체크리스트
- 사용자의 목적과 성공 결과가 구분돼 있는가?
- 누가 어떤 조건에서 어떤 행동을 하는지 적었는가?
- 정상·권한·중복·연동 실패의 기대 결과를 검토했는가?
- 테스트 환경, 데이터, 검수 담당이 정해져 있는가?
- 변경 요청 시 기준과 영향이 함께 업데이트되는가?
좋은 인수 기준은 문서를 길게 만드는 기술이 아닙니다. 고객과 개발팀이 같은 장면을 떠올리고, 같은 결과를 보고 ‘끝났다’고 말할 수 있게 만드는 약속입니다.
#인수기준 #요구사항정의 #사용자스토리 #시나리오테스트 #UAT #업무시스템개발 #프로젝트관리 #완료기준 #테스트설계 #고객검수
