프런트의 "혹시"가 테스트 케이스가 되는 순간

경험 많은 프런트 직원은 예약 화면을 볼 때 "혹시"라는 말을 자주 떠올린다. 혹시 체크아웃 날짜가 체크인 날짜보다 앞서 있지는 않은가, 혹시 취소된 예약으로 체크인을 시도하면 어떻게 되는가. 고객의 불편을 미리 막으려는 이 질문들은 소프트웨어 품질보증(QA, Quality Assurance)에서 테스트 케이스를 설계하는 사고방식과 구조가 같다.

박건희 소장의 『이제 QA, AI Agent랑 같이 합시다』는 이 연결에 주목한다. 이 글은 책이 다루는 테스트 기법 가운데 호텔 업무와 맞닿은 세 가지를 골라, 서비스 현장의 감각이 어떻게 체계적인 테스트 설계로 바뀌는지 살펴본다. 사례는 책의 가상 호텔 '큐에이 스테이'의 규칙을 바탕으로 한다.

숙박일 규칙으로 보는 동등 분할

큐에이 스테이 호텔에는 다음과 같은 규칙이 있다.

• 숙박은 1박부터 14박까지 예약할 수 있다.
• 3박 이상 연박하면 객실 요금을 5% 할인한다.

1박부터 14박까지 모든 경우를 하나씩 확인하는 것은 비효율적이다. 동등 분할(Equivalence Partitioning)은 시스템이 같은 방식으로 처리할 것으로 예상되는 값들을 하나의 묶음(파티션)으로 나누고, 파티션마다 대표값을 골라 확인하는 기법이다. 위 규칙의 숙박일은 다음과 같이 나뉜다.

• 유효 파티션: 1~2박(연박 할인 없음), 3~14박(연박 할인 5%)
• 무효 파티션: 0박 이하, 15박 이상

파티션마다 하나씩, 예컨대 0박, 2박, 5박, 20박을 확인하면 네 개의 테스트로 모든 파티션을 한 번씩 거칠 수 있다. 프런트 직원이 "할인 없는 짧은 숙박, 할인되는 숙박, 그리고 받을 수 없는 숙박"으로 상황을 나눠 생각하는 것과 같은 방식이다. 책은 무효 값을 한 테스트에 하나씩만 넣으라고 강조한다. 숙박일과 인원에 동시에 잘못된 값을 넣으면, 오류 메시지가 떴을 때 어느 쪽 때문인지 알 수 없기 때문이다.

결함은 경계에 산다: 경곗값 분석

현장에서 문제가 자주 생기는 곳은 규칙이 바뀌는 지점이다. "14박 이하"를 개발자가 "14박 미만"으로 잘못 쓰는 것처럼 부등호 하나를 빠뜨리는 실수는 매우 흔하다. 이 경우 14박 고객은 예약을 할 수 없게 되지만, 대표값 5박만 확인해서는 이 결함을 찾을 수 없다.

경곗값 분석(Boundary Value Analysis)은 이런 결함을 겨냥한다. ISTQB CTFL 실라버스가 제시하는 2값 경곗값 분석은 각 파티션의 가장자리 값과, 이웃한 파티션에서 가장 가까운 값을 함께 확인한다. 위 규칙에서 파티션이 맞닿는 경계는 세 곳이므로, 확인할 값은 다음 여섯 개다.

• 0박과 1박: 예약 불가와 예약 가능의 경계
• 2박과 3박: 연박 할인 없음과 5% 할인의 경계
• 14박과 15박: 예약 가능과 예약 불가의 경계

저자는 프롤로그에서 14박까지만 예약되는 규칙이 있으면 14박과 15박을 꼭 넣어 보던 현장의 습관이 바로 경곗값 분석이었다는 것을, 테스트를 공부하며 비로소 알게 되었다고 회고한다. "3박이면 할인이 되던가?"라는 프런트 직원의 확인 질문도 경곗값 분석을 손으로 수행하는 셈이다.

예약의 생애를 따라가는 상태 전이 테스트

예약은 시간에 따라 상태가 바뀐다. 단순화하면 '예약 확정'에서 '체크인'을 거쳐 '체크아웃'으로 이어지고, 중간에 '취소'나 '노쇼(No-show)'로 갈라질 수 있다. 상태 전이 테스트(State Transition Testing)는 허용된 전이가 제대로 일어나는지와 함께, 허용되지 않은 전이가 막히는지를 확인한다.

서비스 품질의 관점에서 더 중요한 것은 후자다. 취소된 예약으로 체크인이 처리되거나, 이미 체크아웃한 예약이 다시 체크인 상태로 돌아가는 오류는 객실 배정과 정산 전체를 흔든다. 현장 직원이 "이미 취소된 예약인데 왜 체크인 버튼이 눌리지?"라고 느끼는 순간이 바로 무효 전이에 대한 테스트가 필요한 지점이다.

AI 에이전트 시대, 남는 역할은 검증이다

최근에는 AI 에이전트에게 기획서를 주고 테스트 조건과 테스트 케이스를 만들게 하는 방식이 확산되고 있다. 책의 3부도 이 과정을 다루며, AI가 내놓은 결과를 검증하고 고치는 단계까지 함께 보여 준다.

위의 숙박일 사례에 적용하면 검증의 관점은 분명해진다. AI가 만든 테스트 케이스 목록에 경곗값 0, 1, 14, 15와 할인 경계인 2박·3박이 모두 들어 있는지, 무효 값이 한 테스트에 하나씩만 들어갔는지, 취소 상태에서의 체크인 같은 무효 전이가 다뤄졌는지를 확인하는 일이다. 테스트 기법을 알고 있어야 무엇이 빠졌는지 알아볼 수 있다.

테스트를 만드는 일은 AI에게 맡길 수 있어도, 그 테스트가 충분한지 판단하는 일은 여전히 사람의 몫이다.

시사점

호텔 서비스 인력이 쌓아 온 현장 감각은 디지털 전환 속에서 사라지는 역량이 아니라, 시스템 품질을 지키는 역량으로 옮겨 갈 수 있다. 다만 그 감각이 체계적인 테스트 설계로 이어지려면 동등 분할, 경곗값 분석, 상태 전이 같은 공통의 언어가 필요하다. 호텔 IT 조직과 교육기관이 서비스 경력자를 QA 인력으로 육성하는 경로를 설계할 때, 이 언어를 가르치는 일과 AI가 만든 결과를 검증하는 훈련을 함께 고려할 필요가 있다.