호텔 예약 변경·취소 기능 QA 사례 분석, 기획서 리뷰에서 완료 보고까지

예약 변경과 취소는 호텔 시스템에서 고객 불만과 금전 분쟁이 가장 자주 발생하는 기능 가운데 하나다. 위약금 규정은 체크인까지 남은 기간에 따라 달라지고, 변경이 일어나면 요금과 할인을 다시 계산해야 하며, 취소 후에는 객실이 즉시 판매 가능한 상태로 돌아가야 한다. 어느 한 곳이라도 잘못되면 고객에게 과다 청구되거나 호텔이 매출을 잃는다.

이 리포트는 박건희 소장의 『이제 QA, AI Agent랑 같이 합시다』 12장에 수록된 종합 실습을 사례로 삼아, 하나의 기능이 기획서에서 출시 판단에 이르기까지 품질관리 활동이 어떻게 이어지는지 분석한다. 사례는 가상 호텔 '큐에이 스테이'를 배경으로 하며, 객실 요금은 계산을 단순화하기 위해 디럭스룸 1박 100,000원으로 고정되어 있다.

1. 프로젝트 개요

큐에이 스테이 호텔은 '예약 변경·취소' 기능을 새로 개발한다. QA 담당자에게 주어진 기간은 2주이며, 다음 다섯 가지 산출물을 만들어야 한다.

1. 요구사항 리뷰 결과(기획자에게 보낼 질문 목록)
2. 테스트 계획 요약
3. 테스트 케이스와 추적성 매트릭스
4. 결함 보고서
5. 테스트 완료 보고서

기획서(v0.9)의 핵심 요구사항은 다섯 가지다. 고객은 체크인 2일 전까지 날짜, 객실 타입, 인원을 변경할 수 있다(C-01). 변경하면 요금과 할인을 다시 계산하고, 변경 후 예약도 인원과 숙박일 규칙을 따른다(C-02). 취소 위약금은 체크인 7일 전까지 무료, 3~6일 전 50%, 2일 전부터 당일까지 100%다(C-03). 체크인 당일까지 도착하지 않으면 노쇼로 처리하고 100%를 부과한다(C-04). 취소되면 객실 상태는 공실이 되고 취소 확인 메일을 발송한다(C-05).

2. 요구사항 리뷰: 테스트는 기획서에서 시작된다

이 사례에서 첫 번째 품질관리 활동은 테스트 실행이 아니라 기획서 리뷰다. 담당자는 먼저 혼자 기획서를 검토해 현장 관점의 질문을 적고, AI 에이전트에게 모호함·누락·모순을 찾게 한 뒤, 두 결과를 합쳐 기획자에게 보낼 질문 목록을 확정한다.

확정된 질문은 다음과 같은 성격을 띤다.

• 기준의 모호함: "2일 전"은 날짜 기준인가, 체크인 시각 기준 48시간인가. "당일까지"는 자정인가, 프런트 마감 시각인가.
• 규칙 간 충돌: 날짜를 변경해 성수기로 바뀌면 할인이 사라지는가. 그 차액은 고객에게 어떻게 안내하는가.
• 계산 기준의 누락: 위약금의 기준 금액은 할인 전 금액인가, 할인 후 결제 금액인가. 날짜를 변경한 뒤 취소하면 원래 날짜와 변경된 날짜 중 무엇을 기준으로 하는가.
• 범위의 불명확성: 여러 객실을 묶은 예약에서 일부만 취소할 수 있는가.

기획자는 일수를 날짜 기준으로 세고, 위약금은 할인 후 결제 금액을 기준으로 하며, 변경 후 취소는 변경된 체크인 날짜를 기준으로 하고, 부분 취소는 이번 범위에서 제외한다고 답했다.

주목할 점은 이 질문들 가운데 상당수가 프런트와 정산 업무를 경험한 사람만 떠올릴 수 있는 것이라는 사실이다. 특히 위약금의 기준 금액은 실제 고객 분쟁에서 가장 먼저 쟁점이 되는 부분인데, 기획서 v0.9에는 이 기준이 빠져 있었다. 이 누락은 프로젝트 마지막의 '배운 점'으로 다시 등장한다.

3. 테스트 계획: 금액이 걸린 기능이 먼저다

테스트 계획은 목적, 범위, 접근법, 리스크 우선순위, 진입·완료 조건, 일정으로 구성된다. 범위에는 변경, 요금 재계산, 취소 위약금, 노쇼, 객실 상태, 메일이 포함되고, 부분 취소와 결제 대행사의 실제 환불 처리는 제외된다.

리스크 우선순위는 다음 순서로 정해졌다.

1. 위약금 금액 오계산
2. 변경 후 할인 재계산 오류
3. 취소 후 객실 상태 미반영

책은 금액이 걸린 기능이 가장 위에 오는 것이 호텔 시스템 QA의 기본이라고 설명한다. 완료 조건은 테스트 케이스 100% 실행, 심각도 '높음' 이상 결함 0건, 미해결 결함에 대한 대응 합의다. 이처럼 완료 조건을 미리 정해 두면 출시 직전에 "언제 테스트를 끝낼 것인가"를 두고 감정적으로 논쟁할 필요가 줄어든다.

4. 테스트 설계: 네 가지 기법의 조합

4.1 위약금 구간의 경곗값 분석

체크인 날짜에서 취소일 날짜를 뺀 값을 D라고 하면, 위약금 규칙은 네 개의 파티션으로 나뉜다. D가 7 이상이면 무료, 3~6이면 50%, 0~2이면 100%이고, 0 미만이면 이미 체크인 날짜가 지났으므로 취소 버튼이 비활성화되고 노쇼 규칙이 적용된다.

경계는 6과 7, 2와 3, -1과 0 사이의 세 곳이다. 2값 경곗값 분석으로 고른 테스트 값은 7, 6, 3, 2, 0, -1의 여섯 개다. 같은 방식으로 변경 가능 여부(C-01)는 D가 2 이상이면 가능, 1 이하면 불가이므로 2와 1을 테스트한다.

4.2 변경 후 할인의 결정 테이블

큐에이 스테이의 할인 규칙은 회원 10%, 3박 이상 연박 5%이며, 두 조건에 모두 해당하면 큰 할인 하나만 적용하고 성수기에는 할인이 없다. 변경으로 숙박일이나 날짜가 바뀌면 이 규칙을 다시 통과해야 한다. 사례에서는 세 가지 변경을 중점적으로 확인한다.

• 비회원 3박을 2박으로 변경: 연박 할인 5%가 사라져 285,000원에서 200,000원이 되어야 한다.
• 회원 2박을 4박으로 변경: 할인이 10%로 유지되어 180,000원에서 360,000원이 되어야 하며, 중복 적용(15%)되지 않아야 한다.
• 비회원 3박의 날짜를 성수기로 변경: 할인이 사라져 285,000원에서 300,000원이 되어야 한다.

4.3 예약 상태의 상태 전이

예약은 확정, 취소됨, 투숙, 노쇼, 완료의 상태를 오간다. 확정 상태에서 변경하면 확정 상태가 유지되며 요금이 재계산되고, 취소하면 취소됨 상태가 되며 위약금이 계산되고 객실이 공실로 바뀐다. 허용된 전이와 함께 '취소됨 상태에서 변경', '노쇼 상태에서 체크인', '투숙 상태에서 취소' 같은 무효 전이가 막히는지도 확인한다.

4.4 오류 추정

기법으로 체계화하기 어려운 상황은 경험 기반의 오류 추정(Error Guessing)으로 보완한다. 취소 버튼을 빠르게 두 번 누르는 경우, 두 직원이 같은 예약을 동시에 변경·취소하는 경우, 연말을 걸쳐 날짜를 변경하는 경우가 여기에 해당한다. 프런트 현장에서 실제로 일어나는 장면들이다.

이 설계를 바탕으로 AI 에이전트가 테스트 케이스 초안을 작성하고, 담당자가 이를 검증해 대표 24건을 포함한 46건의 테스트 케이스를 완성한다. 검증 포인트는 위약금 경곗값 여섯 개가 모두 있는지, 위약금을 할인 전 금액으로 잘못 계산하지 않았는지다. 예컨대 회원 3박(270,000원)을 D=4에 취소하면 위약금은 할인 후 금액의 50%인 135,000원이어야 한다.

5. 실행과 결함 관리: 경계에서 발견된 결함

테스트 실행과 함께 60분짜리 탐색적 테스트 세션이 진행되었다. 같은 예약의 날짜를 세 번 변경한 뒤 취소하거나, 객실 타입을 바꿨다가 원래대로 되돌리는 식으로 요금·위약금·객실 상태가 꼬이는 상황을 탐색했다. 이 세션에서 낮은 심각도의 표시 결함 1건과 기획자에게 확인할 질문 2건이 나왔다.

사례에서 가장 주목할 결함은 위약금 경계에서 발견되었다. 체크인 11월 20일, 디럭스 1박 100,000원 예약을 11월 14일(D=6)에 취소하자, 기대 결과인 위약금 50,000원(50%) 대신 위약금 0원과 전액 환불 안내가 표시되었다. D=7과 D=3은 정상이었고 D=6만 무료로 처리되었다. '7일 이내'의 경계 처리 오류로 추정되는 결함이다.

책은 경곗값 분석이 없었다면, 예컨대 5일 전 취소만 테스트했다면 이 결함은 그대로 출시되었을 것이라고 지적한다. 실제 운영에서 이 결함은 체크인 6일 전에 취소한 모든 고객에게 위약금을 받지 못하는 매출 손실로 이어졌을 것이다.

두 번째 결함은 변경 후 할인 재계산에서 나왔다. 비회원 3박(285,000원)을 2박으로 변경했는데 연박 할인 5%가 유지되어 200,000원이 아닌 190,000원이 표시되었다. 두 결함 모두 심각도 '높음'으로 등록되었고, 수정 후에는 위약금 경곗값 여섯 개 전체와 노쇼 처리, 변경 결정 테이블 전체와 예약 생성 할인 규칙을 회귀 테스트 범위에 포함했다.

6. 완료 보고와 프로세스 개선

완료 보고에 따르면 46건의 테스트 케이스가 모두 실행되어 44건이 통과하고 2건이 실패했으며, 실패한 2건은 결함 수정 후 재테스트에서 통과했다. 결함은 높음 2건(해결), 보통 1건(해결), 낮음 2건(1건은 다음 배포로 연기 합의)이었고, 담당자는 출시 가능으로 판단했다. 남은 리스크로는 부분 취소 미지원에 따른 단체 예약 운영의 불편과, 결제 대행사 실제 환불 연동에 대한 별도 통합 테스트의 필요성이 기록되었다.

보고서의 마지막 항목인 '배운 점'은 이 사례의 핵심이다. 위약금 기준 금액처럼 금액과 직결되는 규칙이 기획서에 없었다는 사실을 근거로, 금액 관련 기획서 리뷰 체크리스트에 해당 항목을 추가하자고 제안한 것이다. 책은 이것을 "테스트가 QA가 되는 순간"이라고 부른다. 이번에 발견한 결함을 고치는 데서 끝나지 않고, 다음 기획서에서는 같은 빈틈이 처음부터 생기지 않도록 과정을 개선하는 것이다.

7. 시사점

이 사례에서 호텔 시스템 품질관리에 대해 세 가지 시사점을 도출할 수 있다.

첫째, 금액이 걸린 경계는 반드시 경곗값으로 테스트해야 한다. 위약금, 할인, 무료 취소 기한처럼 규칙이 바뀌는 지점은 개발자의 부등호 실수가 집중되는 곳이며, 그 결함은 곧바로 매출 손실이나 고객 분쟁으로 이어진다.

둘째, 현장 경험은 기획 단계에서 가장 큰 가치를 낸다. 위약금 기준 금액, 노쇼와 당일 취소의 구분, 단체 예약의 부분 취소 같은 질문은 프런트와 정산 업무를 아는 사람이 던질 수 있다. 호텔 IT 조직이 운영 경력자를 기획 리뷰에 참여시켜야 하는 이유다.

셋째, AI 에이전트는 작성을, 사람은 판단을 맡는다. 사례 전반에서 AI 에이전트는 모호한 표현 찾기, 테스트 케이스 표 작성, 보고서 초안 정리를 맡았고, 사람은 기법 선택과 경곗값 설계, 금액 검산, 심각도 결정, 출시 판단을 맡았다. 이 역할 분담은 AI 도구가 확산되는 호텔 IT 현장에서 품질관리 조직을 설계할 때 참고할 수 있는 기준이 된다.