8장. 유스케이스 & 수용 기준(AC) 카드 작성
Gherkin 라이트 확장
7장 답변을 실행 가능한 유스케이스로 전환하기
7장에서 수집한 인터뷰 답변을 “~할 수 있다” 형식의 유스케이스로 전환하고, 각 기능별로 개발 완료를 판단할 수 있는 수용 기준을 Given–When–Then 구조로 작성한다. 유스케이스는 사용자 관점에서 무엇을, 왜 수행하는지를 설명하며, AC는 전제 조건·행동·결과를 검증 가능한 문장으로 명시한다.
유스케이스 작성 형식
ID와 제목
형식: US-[영역]-[번호] (예: US-BO-001, US-FO-003)
제목은 “누가 무엇을 할 수 있다”로 서술한다.
사용자 역할
BO: 운영자, 마케팅 담당자, CS 담당자
FO: 고객, 비회원
목표
기능을 통해 달성하려는 구체적 목적 또는 해결하고자 하는 문제를 설명한다.
전제 조건 (선택적)
기능 실행 전에 반드시 충족되어야 하는 상태나 권한을 기술한다.
수용 기준(AC)
Given–When–Then 구조로 작성된 2~3개의 시나리오를 포함한다.
정상, 예외, 경계, 비즈니스 로직 케이스를 모두 고려한다.
출처
인터뷰 일자, 담당자, 관련 문서나 이슈를 명시하여 추적성을 확보한다.
담당자
기획자, 개발자, QA 담당자를 명시해 담당 구분을 명확히 한다.
Gherkin 라이트 구조 정의
Given (전제 조건)
기능이 실행되기 전의 상태를 기술한다.
예: “운영자가 BO 상품 관리 화면에 로그인한 상태”
When (행동)
사용자가 수행하는 액션을 기술한다.
예: “CSV 파일을 업로드하고 ‘등록’ 버튼을 클릭한다”
Then (결과)
기대되는 시스템 반응과 검증 가능한 결과를 기술한다.
예: “20개의 상품이 등록되고 ‘등록 완료’ 메시지가 표시된다”
And (추가 조건)
전제, 행동, 결과의 세부 조건을 덧붙일 때 사용한다.
개발팀 기반 유스케이스 예시
US-DEV-001: 고객은 카테고리, 필터, 정렬 기능을 사용하여 상품을 탐색할 수 있다
사용자 역할: 고객
목표: 고객이 원하는 상품을 빠르게 찾도록 탐색 효율을 높인다.
전제 조건: 상품 데이터가 대분류, 중분류, 소분류의 3단계 카테고리로 구성되어 있으며, 색상·가격·브랜드와 카테고리별 속성(의류의 경우 재질과 핏, 뷰티의 경우 피부타입과 용량 등)이 사전에 정의되어 있다.
수용 기준
AC1 정상
Given: 고객이 상품 목록 페이지에 접속하고
And: 카테고리 ‘의류 > 상의 > 티셔츠’를 선택한 상태
When: 색상 ‘블루’, 가격 범위 ‘3만 원부터 5만 원’을 선택하고
And: 정렬 기준을 ‘최근 7일 판매량 기준 인기순’으로 변경한다
Then: 조건에 맞는 상품 목록이 표시된다
And: 적용된 필터와 정렬 기준이 목록 상단 필터 칩과 레이블로 표시된다
AC2 예외
Given: 고객이 특정 카테고리에서 색상 ‘핑크’와 가격 ‘10만 원 이상’을 선택한 상태
When: 필터를 적용한다
Then: “조건에 맞는 상품이 없습니다” 문구가 표시된다
And: 필터 초기화 버튼이 노출되어 전체 목록으로 복귀할 수 있다
출처: 개발팀 인터뷰 2025.10.28 (상품 탐색 스키마, 필터, 정렬, 인기순 기준)
담당자: 기획 박OO / 개발 김OO / QA 이OO
US-DEV-002: 운영자는 카테고리별 상품 속성과 필터 스키마를 관리할 수 있다
사용자 역할: 운영자
목표: 카테고리별로 상이한 필터 항목을 관리하여 고객 탐색의 정확도를 높인다.
전제 조건: 운영자가 관리자 권한으로 로그인한 상태이며, 스키마 관리 화면이 제공된다.
수용 기준
Given: 운영자가 스키마 관리 화면에 접속한 상태
When: ‘의류 > 상의 > 티셔츠’ 카테고리를 선택하고
And: 속성 ‘핏’을 다중 선택 가능으로 추가하고 값을 ‘슬림, 레귤러, 오버’로 저장한다
Then: 해당 속성이 고객용 필터에 즉시 노출된다
And: 다중 선택이 가능하다
출처: 개발팀 인터뷰 2025.01.20 (카테고리 구조, 속성 노출과 선택 방식)
담당자: 기획 최OO / 개발 이OO / QA 송OO
US-DEV-003: 고객은 간편 결제를 사용하여 결제할 수 있다
사용자 역할: 고객
목표: 고객이 선호하는 간편 결제로 결제 편의성을 높인다.
전제 조건: 결제 화면에 네이버페이, 카카오페이 등 사용 가능한 간편 결제 수단이 제공된다.
수용 기준
AC1 정상
Given: 고객이 결제 화면에서 결제 수단으로 ‘네이버페이’를 선택한 상태
When: 결제 버튼을 클릭한다
Then: 결제가 성공적으로 완료되고 주문 완료 페이지가 표시된다
And: 주문 상태가 “결제 완료”로 변경된다
AC2 실패 재시도
Given: 고객이 ‘카카오페이’로 결제를 시도했으나
And: PG 응답 코드가 ‘PW_ERR’로 수신된 상태
When: 시스템이 실패 사유를 표시한다
Then: “비밀번호 오류로 결제가 실패했습니다” 메시지가 노출된다
And: ‘다시 시도’ 버튼을 통해 즉시 재결제를 진행할 수 있다
출처: 개발팀 인터뷰 2025.10.28 (간편 결제 구성, 실패 사유별 문구, 재시도)
담당자: 기획 김OO / 개발 박OO / QA 정OO
US-DEV-004: CS 담당자는 수기 주문을 등록할 수 있다
사용자 역할: CS 담당자
목표: PG 장애 또는 고객 요청에 따라 전화 등으로 접수한 주문을 BO에서 직접 생성한다.
전제 조건: CS 담당자가 BO 주문 관리 권한을 가지고 있다.
수용 기준
Given: CS 담당자가 주문 관리 화면의 ‘수기 주문 등록’ 메뉴에 접속한 상태
When: 고객명, 상품, 수량, 금액, 결제 수단, 연락처를 입력하고 저장을 클릭한다
Then: 주문이 ‘결제 대기’ 상태로 생성된다
And: 담당자명과 등록 시각이 주문 이력에 기록된다
출처: 개발팀 인터뷰 2025.10.28 (백업 플로우로서 수기 주문)
담당자: 기획 송OO / 개발 윤OO / QA 전OO
다 기술하기에는 지면상 지루할 수 있으니 4가지 예시만 들었다. BO에 해당하는 운영팀, 마케팅팀, CS팀도 개발팀의 예시와 같이 작성하고, FO는 고객 입장에서 작성하면 된다. FO 유스케이스 예시는 아래와 같이 BO와 차이가 없다.
FO 공통 유스케이스
US-FO-001: 고객은 옵션을 선택하여 장바구니에 상품을 담을 수 있다
사용자 역할: 고객
목표: 여러 상품을 비교하고 나중에 구매할 수 있도록 장바구니를 활용한다.
전제 조건: 상품에 색상과 사이즈 등 옵션이 정의되어 있다.
수용 기준
Given: 고객이 상품 상세 페이지에 접속한 상태
And: 상품에 색상과 사이즈 옵션이 존재한다
When: 색상 ‘블루’와 사이즈 ‘M’을 선택하고 수량을 ‘2’로 설정한 뒤 장바구니 담기를 클릭한다
Then: 상품이 장바구니에 추가된다
And: 화면 상단의 장바구니 아이콘 배지 숫자가 증가한다
And: “장바구니에 담았습니다” 토스트 메시지가 표시된다
Given: 색상 ‘레드’ 옵션의 재고가 0인 상태
When: 고객이 색상 ‘레드’를 선택하려고 시도한다
Then: 해당 옵션은 비활성화되어 선택할 수 없다
And: 옵션 옆에 “품절” 라벨이 표시된다
And: 다른 색상 옵션은 정상적으로 선택할 수 있다
출처: 비즈니스 목표(장바구니 이탈률 개선)와 운영팀 인터뷰 2025.10.28
담당자: 기획 유OO / 개발 이OO / QA 배OO
카드 관리 방법
상태 태그: 백로그, 준비, 진행, 검증, 완료
우선순위: P0, P1, P2, P3
담당자: 기획자, 개발자, QA 담당자를 명시한다
출처: 인터뷰 일자, 팀, 관련 문서와 이슈 링크를 기록한다 (출처를 남기는 건 중요하다. 나중을 위해서)
버전 이력: 변경 사유와 버전 태그를 함께 기록한다
작성 원칙
하나의 유스케이스는 하나의 기능으로 한정한다.
수용 기준은 UI 변화와 시스템 상태 변화를 모두 검증 가능하게 기술한다.
정상, 예외, 경계, 비즈니스 로직 시나리오를 포함한다.
출처와 담당자를 명확히 기록하여 추적 가능성을 확보한다.
변경 사항이 발생하면 유스케이스 ID는 유지하고 수용 기준에 버전 태그를 추가한다.
유스케이스 문서로 유스케이스 다이어그램(UML)으로 전체 관계도를 그려보는 것도 좋다. 반대로 유스케이스 다이어그램을 만들고 각 관계에 대한 문서화로 진행해도 문제는 없다.
이쯤에서 언제 프로토타입을 만드는지 의문이 생길 수 있다. 프로토타입을 만들기 위한 준비과정인 요구사항 분석은 필요하다. 지금까지 대부분이 요구사항 분석에 해당하는 내용이었다. 요구사항이 명확하면 제작은 빠르게 진행된다. 반대로 명확하지 않으면 제작은 한없이 더디게 진행될 수밖에 없다.
시스템(앱, 웹)을 만드는 과정은 결코 쉽지 않다.
