"할인 이상함, 확인 바람"은 결함 보고서가 아니다
개발자가 한 번에 재현하는 보고서의 구조와, 따로 판단해야 하는 심각도와 우선순위

호텔 예약 시스템의 요금 계산 기능을 테스트하던 담당자가 이상한 결과를 발견했다. 회원 계정으로 디럭스룸 3박을 계산했더니 기대한 금액과 다른 숫자가 나온 것이다. 마음이 급한 담당자는 개발팀에 이렇게 메모를 남긴다. "회원으로 3박 하니까 할인 이상함. 15% 나옴. 확인 바람."
메모를 받은 개발자는 되물을 수밖에 없다. 어떤 객실이었는지, 성수기였는지, 어느 버전이었는지, 15%가 왜 틀렸다는 것인지. 질문과 답이 오가는 사이 하루가 지나간다. 박건희 소장의 『이제 QA, AI Agent랑 같이 합시다』 10장은 이 장면에서 출발해, 결함을 "발견하는 것"만큼 "전달하는 것"이 중요하다는 점을 보여 준다.
무엇이 틀렸는지 숫자로 말하기
책의 가상 호텔 '큐에이 스테이'에는 다음과 같은 할인 규칙이 있다. 회원은 10%, 3박 이상 연박은 5% 할인을 받으며, 두 조건에 모두 해당하면 큰 할인 하나만 적용한다. 디럭스룸 요금은 1박 100,000원으로 고정되어 있다.
이 규칙에 따르면 회원이 디럭스룸에 3박하는 경우 정가는 300,000원이고, 큰 할인인 10%만 적용되어 270,000원이 나와야 한다. 그런데 화면에는 두 할인이 합쳐진 15%, 255,000원이 표시되었다. "할인 이상함"이라는 메모는 이 핵심을 전혀 전달하지 못한다.
좋은 결함 보고서의 세 기둥
책은 개발자가 문제를 재현하는 데 결정적인 세 항목을 꼽는다.
- 재현 절차: 번호를 붙이고 한 단계에 한 동작만 적는다. 누가 따라 해도 같은 결과가 나와야 한다.
- 기대 결과: 요구사항 문서의 근거를 밝혀 무엇이 나와야 하는지 적는다. 위 사례라면 "할인 10%, 270,000원(할인 규칙 요구사항)"이다.
- 실제 결과: 실제로 나온 숫자와 메시지, 화면 상태를 그대로 적는다.
제목은 '[화면 또는 기능] 조건 + 현상'의 형식으로 쓴다. "할인 오류" 대신 "[예약 생성] 회원이 3박 이상 예약 시 할인 15%가 중복 적용됨"이라고 쓰면, 제목만 읽어도 어디서 어떤 조건에 무슨 일이 일어났는지 알 수 있다. 여기에 버전과 환경, 인원과 성수기 여부 같은 사전 조건을 더하면 개발자는 질문 없이 바로 재현에 들어갈 수 있다.
AI 에이전트가 쓴 보고서도 검증해야 한다
책은 급한 메모를 AI 에이전트에게 주고 표준 보고서로 다듬게 하는 방법을 소개한다. 다만 그 결과를 그대로 쓰지 않고 검증하는 과정을 함께 보여 준다. 책에 실린 예시에서 AI 에이전트는 메모에 없던 "쿠폰 코드 입력란을 비운 채"라는 단계를 재현 절차에 끼워 넣었다. 큐에이 스테이의 화면에는 그런 입력란이 없었다. AI가 일반적인 예약 화면을 상상해 그럴듯한 단계를 추가한 것이다. 또한 할인 규칙에 영향을 주는 인원과 성수기 여부가 사전 조건에서 빠져 있었다.
이 사례가 주는 교훈은 단순하다. 보고서가 완성되었는지 확인하는 가장 확실한 방법은, AI가 정리한 재현 절차를 테스터가 직접 한 번 더 따라 해 보는 것이다. 그 절차대로 결함이 재현될 때 보고서가 완성된다.
심각도와 우선순위는 따로 판단한다
결함 보고서에는 흔히 심각도와 우선순위가 함께 적히지만, 두 기준은 성격이 다르다.
심각도(Severity)는 결함이 시스템과 업무에 주는 영향의 크기로, 주로 테스터가 판단한다. 책은 호텔 시스템을 예로 다음과 같은 단계를 제시한다.
- 치명: 핵심 업무 중단, 데이터 손실이나 보안 문제. 예컨대 체크인 불가, 결제 금액 이중 청구
- 높음: 주요 기능 오동작, 금전적 손실. 예컨대 할인 중복 적용, 객실 이중 배정
- 보통: 기능은 되지만 불편하고 우회 방법이 있음
- 낮음: 버튼 문구 오타 같은 사소한 표시 문제
우선순위(Priority)는 얼마나 빨리 고쳐야 하는지로, 일정과 고객, 사업 상황을 고려해 관리자나 제품 책임자가 결정한다.
두 기준이 늘 함께 움직이지는 않는다. 1년에 한 번 쓰는 연말 정산 리포트의 오류는 심각도가 높아도 연말 전까지만 고치면 되므로 우선순위는 낮을 수 있다. 반대로 첫 화면의 호텔 이름 오타는 기능에 영향이 없어 심각도는 낮지만, 다음 날 오픈 행사가 있다면 가장 먼저 고쳐야 한다. 두 기준을 나눠 적어야 팀이 합리적으로 수정 순서를 정할 수 있다.
결함 보고는 "누가 잘못했다"가 아니라 "이런 조건에서 이렇게 동작한다"는 정보의 전달이다.
서비스 현장의 보고 습관과 닮은 점
호텔 현장에서 일해 본 사람이라면 이 원칙이 낯설지 않을 것이다. 좋은 인수인계 메모는 "703호 손님 불만 있음"이 아니라 "703호 고객, 21시 룸서비스 주문 누락으로 항의, 디저트 제공으로 1차 응대, 내일 조식 시 확인 필요"처럼 쓰인다. 사실과 조건, 기대와 결과를 분리해 전달하는 습관은 서비스 현장과 품질관리 현장에서 똑같이 신뢰를 만든다.
참고문헌
- 박건희 (2026). 이제 QA, AI Agent랑 같이 합시다. 부크크. 6장, 10장.
- ISTQB. Certified Tester Foundation Level (CTFL) Syllabus, v4.0.1.
© 관광서비스품질연구소. 이 글의 무단 전재 및 재배포를 금지한다.