무엇부터 테스트할 것인가, 호텔 시스템의 리스크 기반 테스트

호텔 시스템의 출시 일정은 대개 영업 일정에 묶여 있다. 신규 호텔의 오픈일, 성수기 시작일, 프로모션 개시일은 소프트웨어 개발 사정과 무관하게 정해진다. 그 결과 품질관리 담당자는 거의 언제나 주어진 시간 안에 모든 것을 테스트할 수 없는 상황에 놓인다.

ISTQB의 테스트 원칙 가운데 하나는 모든 경우를 다 테스트할 수는 없다는 것이다. 박건희 소장의 『이제 QA, AI Agent랑 같이 합시다』는 이를 숫자로 보여 준다. 숙박일 1~14박, 인원 1~4명, 객실 타입 3가지, 회원 여부 2가지, 날짜 365일을 모두 조합하면 14 × 4 × 3 × 2 × 365 = 122,640가지가 된다. 문제는 "무엇을 테스트할 것인가"가 아니라 "무엇부터, 얼마나 깊게 테스트할 것인가"다. 이 리포트는 그 질문에 답하는 방법인 리스크 기반 테스트(Risk-based Testing)를 호텔 시스템의 맥락에서 정리한다.

1. 리스크의 정의와 측정

리스크(Risk)는 일어날 수도 있는 나쁜 일이다. 리스크의 크기는 두 가지로 판단한다.

• 가능성(Likelihood): 그 일이 일어날 확률
• 영향(Impact): 일어났을 때의 피해 크기

리스크 수준은 두 값을 곱해 구한다(리스크 수준 = 가능성 × 영향). 리스크에는 일정 지연, 인력 부족, 테스트 서버 장애처럼 프로젝트를 위협하는 프로젝트 리스크와, 계산 오류, 느린 응답, 보안 취약점처럼 제품의 품질을 위협하는 제품 리스크가 있다. 리스크 기반 테스트가 주로 다루는 것은 제품 리스크다.

리스크 관리는 리스크를 찾아내고 크기를 매기는 분석 단계와, 대응책을 정해 실행하고 지켜보는 통제 단계로 이루어진다. 제품 리스크에 대한 대응은 주로 테스트로 줄이는 것이며, 리스크가 큰 기능일수록 더 일찍, 더 깊게, 더 많은 기법으로 테스트한다. 그 밖에 리스크를 그대로 받아들이는 수용, 다른 쪽에 넘기는 전가, 문제가 생겼을 때를 대비하는 비상 계획도 대응 방법이 될 수 있다.

2. 사례: 신규 정산 기능의 리스크 매트릭스

책은 오픈 2주 전 가상 호텔 '큐에이 스테이'에 새 정산 기능이 도입되는 상황을 사례로 든다. 팀은 제품 리스크를 뽑고 가능성과 영향을 각각 1~3점으로 평가했다.

• 할인 적용 후 결제 금액 오계산: 가능성 3, 영향 3, 수준 9. 결정 테이블의 모든 규칙과 경곗값으로 최우선 테스트한다.
• 부분 환불 시 영수증 금액 불일치: 가능성 2, 영향 3, 수준 6. 환불 시나리오에 집중해 2순위로 테스트한다.
• 카드 결제 대행사 응답 지연 시 중복 결제: 가능성 2, 영향 3, 수준 6. 시스템 통합 테스트와 오류 추정으로 대응한다.
• 일 마감 리포트 합계 불일치: 가능성 2, 영향 2, 수준 4. 샘플 데이터 대조로 확인한다.
• 영수증 출력 레이아웃 깨짐: 가능성 2, 영향 1, 수준 2. 체크리스트로 빠르게 확인한다.

이 표의 가치는 계산 자체보다 그것이 만들어 내는 합의에 있다. 표 하나로 "2주 동안 무엇부터, 얼마나 깊게 볼 것인가"에 대한 답과 근거가 생긴다. 담당자가 관리자에게 "영수증 레이아웃은 가볍게 보겠습니다"라고 말할 때, 그것은 게으름이 아니라 근거 있는 판단이 된다.

3. 우선순위를 정하는 세 가지 기준과 의존 관계

책은 테스트 순서를 정하는 대표적인 기준으로 세 가지를 제시한다.

• 리스크 기반: 위험이 큰 것부터
• 커버리지 기반: 적은 테스트로 많은 범위를 덮는 것부터
• 요구사항 기반: 이해관계자가 중요하다고 정한 요구사항부터

다만 순서를 정할 때는 기능 간 의존 관계도 고려해야 한다. 정산 테스트가 가장 중요하더라도 예약 생성이 되지 않으면 정산까지 갈 수 없다. 리스크 순위는 "무엇을 깊게 볼 것인가"를 정하고, 의존 관계는 "무엇을 먼저 실행할 수 있는가"를 정한다.

4. 추정: 며칠이면 되는가

"테스트 며칠이면 돼요?"는 품질관리 담당자가 가장 자주 받는 질문이다. 감으로 답하면 대개 모자란다. 책이 소개하는 방법 가운데 3점 추정은 혼자서도 쓰기 쉽다. 낙관값(a), 가능성 높은 값(m), 비관값(b)을 받아 E = (a + 4m + b) ÷ 6으로 계산한다.

예컨대 낙관 4일, 가능성 높음 6일, 비관 14일이라면 (4 + 24 + 14) ÷ 6 = 7일이다. 가능성 높은 값이 6일이더라도, 테스트 서버 장애나 결함 다수 같은 비관적 상황을 반영하면 7일로 잡는 것이 안전하다는 뜻이다. 리스크 매트릭스와 함께 쓰면, 고위험 기능에 배정할 시간을 근거 있게 요청할 수 있다.

5. 회귀 테스트 범위에 적용하기

리스크 기반 사고는 결함이 수정된 뒤 회귀 테스트(Regression Testing) 범위를 정할 때도 쓰인다. 수정된 결함을 다시 확인하는 확인 테스트는 간단하지만, 수정이 다른 기능을 망가뜨리지 않았는지 보는 회귀 테스트는 "어디까지"가 늘 고민이다.

책은 할인 계산 로직이 수정된 사례에서 기능별 영향도를 분석해 범위를 정한다. 예약 생성, 예약 변경, 예약 취소·환불은 영향 '높음'으로 보고 결정 테이블 전체 재실행, 숙박일 변경 후 재계산, 할인 적용 예약의 환불 금액 확인을 수행한다. 영수증과 일 마감 리포트는 '중간'으로 보고 할인 적용 예약 2건의 금액 반영만 확인한다. 체크인·체크아웃은 '낮음'으로 보고 대표 시나리오 하나로 정상 동작만 확인한다. 이렇게 근거를 적어 두면 나중에 "왜 이 기능은 가볍게 봤는가"라는 질문에 답할 수 있다.

6. 가능성 평가의 근거: VOC와 결함 이력

리스크 평가에서 가장 주관적이 되기 쉬운 부분은 가능성이다. 책은 결함이 일부 기능에 몰리는 경향(결함 집중)을 근거로, 과거 결함이 많았던 곳과 고객 문의(VOC)가 많은 곳을 더 꼼꼼히 보라고 권한다. 책의 VOC 분석 예시에서 변경·취소 기능의 결함 의심 문의가 9건으로 가장 많았고, 정산은 4건으로 적었지만 금액과 관련되어 심각도가 높았다. 이런 데이터는 가능성 점수를 감이 아닌 기록에 기반하게 만든다.

7. 연구소 제안: 호텔 업무에 맞춘 영향 평가 기준

여기서부터는 책의 내용을 바탕으로 한 연구소의 제안이다. 책의 사례가 보여 주듯, 호텔 시스템에서 영향이 가장 큰 리스크는 대체로 금액과 관련된다. 그러나 호텔의 피해는 금액만으로 측정되지 않는다. 703호 이중 배정 사례처럼, 결함은 고객 경험과 직원의 업무, 호텔의 평판으로 번진다. 따라서 영향 점수를 매길 때 다음 네 가지 관점을 함께 검토할 것을 제안한다.

1. 금전 영향: 고객에게 과다 청구되거나 호텔이 매출을 잃는가
2. 고객 경험 영향: 고객이 현장에서 불편이나 불이익을 직접 겪는가
3. 운영 영향: 프런트, 하우스키핑, 정산 업무가 멈추거나 수작업 우회가 필요한가
4. 평판·규정 영향: 온라인 리뷰나 개인정보, 약관 위반으로 이어질 수 있는가

네 관점 중 하나라도 크게 해당하면 영향을 높게 평가하는 방식이다. 이 기준은 서비스품질 연구에서 고객이 지각하는 품질과 조직의 운영 품질을 함께 보는 관점을 테스트 관리에 옮긴 것이다. 호텔 IT 조직이 운영 부서와 함께 리스크 매트릭스를 작성한다면, 개발 조직만으로는 보지 못하는 영향을 우선순위에 반영할 수 있을 것이다.

8. 결론

리스크 기반 테스트의 핵심은 "모든 것을 다 볼 수 없다"는 현실을 인정하고, 그 안에서 가장 아픈 곳을 먼저, 가장 깊게 보는 것이다. 리스크 매트릭스는 그 판단을 팀이 공유할 수 있는 근거로 만들어 준다. 호텔 시스템에서는 금액이 걸린 기능이 대개 가장 위에 오지만, 고객 경험과 운영, 평판까지 영향 평가에 포함할 때 비로소 서비스 산업의 품질관리에 맞는 우선순위가 만들어진다.