703호 이중 배정으로 본 오류·결함·장애, "누구 잘못인가"보다 중요한 질문

토요일 오후 3시, 한 호텔 프런트에서 출장객이 체크인하자 시스템이 703호를 배정했다. 객실 키를 건네는 순간 옆에 있던 가족 여행객이 고개를 갸웃했다. 그들은 금요일에 체크인해 일요일까지 2박을 예약했고, 이미 703호에 묵고 있었다.

박건희 소장의 『이제 QA, AI Agent랑 같이 합시다』는 가상 호텔 '큐에이 스테이'에서 벌어진 이 장면으로 1장을 연다. 직원은 출장객에게 사과하고 비어 있던 스위트룸으로 무료 업그레이드를 제공해 상황을 수습했다. 그러나 호텔은 그날 판매할 수 있었던 스위트룸 하루치 매출을 잃었고, 빈 객실이 없었다면 고객은 다른 호텔로 옮겨야 했을 것이다. 소프트웨어의 작은 결함은 화면 안에서 끝나지 않고 고객 경험과 직원의 하루, 호텔의 매출과 평판으로 번진다.

사건 직후 회의에서 누군가 물었다. "이건 누구 잘못이죠? 개발자인가요, 기획서인가요, 아니면 테스트에서 놓친 건가요?"

하나의 사건, 세 개의 이름

국제소프트웨어테스팅자격위원회(ISTQB)는 이런 상황을 설명하는 용어를 세 단계로 구분한다.

원인을 거슬러 올라가 보니, 개발자가 '예약 가능한 객실'을 찾는 조건을 만들면서 고객이 머무는 마지막 밤을 잘못 계산했다. 금요일에 체크인해 일요일에 체크아웃하는 고객은 금요일 밤과 토요일 밤을 묵는다. 그런데 코드는 체크아웃 날짜에서 하루를 더 빼는 바람에 금요일 밤만 묵는 것으로 계산했고, 토요일 밤의 703호는 빈 방으로 표시되었다.

• 오류(Error): 사람이 저지른 실수다. 이 사례에서는 마지막 밤을 잘못 계산한 개발자의 판단이다. 오류는 개발자만 저지르는 것이 아니며, 기획자가 조건을 빠뜨리거나 테스터가 기대 결과를 잘못 적는 것도 오류다.
• 결함(Defect): 오류가 코드나 문서에 남긴 흠이다. 흔히 '버그'라고 부른다. 기획서의 잘못된 문장도 결함에 해당한다.
• 장애(Failure): 결함이 실행 중에 드러나 시스템이 기대와 다르게 동작하는 현상이다. 2박 이상 고객의 마지막 밤에 같은 객실로 다른 예약이 들어오는 순간이 그것이다.

책은 이 관계에서 두 가지를 강조한다. 첫째, 결함이 있다고 해서 언제나 장애가 나지는 않는다. 703호의 결함은 빈 객실이 많은 평일에는 시스템이 다른 방을 배정해 드러나지 않다가, 객실이 가득 찬 성수기 주말에야 모습을 보였다. 둘째, 장애가 결함 때문에만 생기는 것도 아니다. 서버의 시간대 설정이나 네트워크 단절 같은 환경 조건도 장애를 일으킬 수 있으므로, 장애를 발견하면 "코드가 틀렸다"고 단정하기 전에 어떤 조건에서 일어났는지부터 기록해야 한다.

책임 추궁보다 근본 원인

회의는 "누구 잘못인가"에서 한 걸음 더 들어갔다. 개발자는 왜 그렇게 이해했을까. 기획서를 다시 확인해 보니 '숙박일'이라는 단어만 있을 뿐, 고객이 어느 밤까지 객실을 사용하는지에 대한 정의는 어디에도 없었다. 개발자의 실수 뒤에는 모호한 기획서가 있었던 것이다.

이처럼 문제가 발생한 가장 밑바닥의 이유를 근본 원인(Root Cause)이라고 한다. 코드만 고치면 703호 문제는 사라지지만, 기획서 작성 방식을 고치지 않으면 다른 기능에서 비슷한 문제가 다시 생긴다. 근본 원인을 찾는 목적은 사람을 탓하는 데 있지 않고, 같은 일이 반복되지 않게 하는 데 있다.

결함을 고치는 것은 테스트의 일이고, 결함이 다시 생기지 않게 하는 것은 품질보증의 일이다.

서비스 현장의 질문이 결함을 막는다

이 사례가 호텔 산업에 주는 시사점은 분명하다. 703호 문제를 이해하는 데 필요한 것은 프로그래밍 언어가 아니라 "2박 고객의 마지막 밤은 언제인가"라는 현장의 감각이었다. 책의 에필로그는 사건 이후 큐에이 스테이 호텔 팀이 기획서를 쓸 때 테스터를 부르기 시작했다고 전한다. 테스터가 회의에서 던진 "숙박일은 어떻게 세나요?"라는 질문 하나가 다음 703호를 막았다는 것이다.

ISTQB가 제시하는 테스트 원칙 중 하나는 일찍 테스트할수록 시간과 비용을 아낀다는 것이다. 703호 문제를 기획서 단계에서 발견했다면 문장 하나를 고치는 것으로 끝났을 것이다. 품질을 테스터 한 사람의 책임으로 두지 않고 기획자, 개발자, 테스터가 처음부터 함께 책임지는 전체 팀 접근법(Whole-team Approach)이 강조되는 이유도 여기에 있다.

호텔 IT 시스템의 품질을 높이는 일은 결국 현장을 아는 사람이 개발 초기에 올바른 질문을 던질 수 있는 구조를 만드는 일이다. 고객이 겪은 불편을 "누구 잘못인가"가 아니라 "어디서 생겨났는가"로 묻는 조직이 같은 실수를 반복하지 않는다.