호텔 시스템에서 날짜는 왜 자주 틀리는가

호텔 시스템의 결함 보고서를 모아 보면 날짜와 관련된 것이 유난히 많다. 요금이 하루씩 밀려 적용되거나, 자정 이후에 들어온 고객의 체크인이 처리되지 않거나, 월말 매출이 다음 달로 넘어가는 식이다. 개발자의 실수라기보다, 호텔 업무에서 쓰이는 날짜 개념이 일반적인 달력의 날짜와 다르기 때문에 생기는 문제인 경우가 많다.

이 글은 호텔 시스템에서 날짜가 어긋나는 대표적인 지점을 정리하고, 그 경계를 어떻게 테스트할지 제안한다. 특정 제품의 동작이 아니라 호텔 업무 전반에서 흔히 쓰이는 개념을 기준으로 설명하였으며, 실제 규칙은 호텔과 시스템마다 다르므로 각자의 기획서로 확인해야 한다.

1. 달력 날짜와 영업일자는 다르다

호텔은 하루를 자정에 마감하지 않는다. 대부분의 호텔은 야간에 하루 영업을 마감하는 나이트 오디트(Night Audit)를 수행하고, 이 작업이 끝나야 시스템의 영업일자(Business Date)가 다음 날로 넘어간다. 마감 시각은 호텔마다 다르며, 새벽 2시나 3시에 진행하는 경우도 있다.

그 결과 자정과 마감 사이의 몇 시간 동안 달력은 11월 2일인데 시스템의 영업일자는 아직 11월 1일인 상태가 생긴다. 이 시간에 일어나는 일이 날짜 결함의 주요 원천이다.

• 새벽 1시에 도착한 고객의 체크인은 어느 날짜의 예약으로 처리되는가
• 이 시간에 발생한 미니바나 룸서비스 매출은 어느 영업일의 매출로 잡히는가
• 키오스크나 모바일 체크인처럼 시스템이 달력 시각을 기준으로 동작하는 채널은 영업일자와 같은 기준을 쓰는가

특히 마지막 항목은 채널이 늘어날수록 중요해진다. PMS는 영업일자를 기준으로 동작하는데, 연동된 외부 시스템이 서버의 달력 날짜를 기준으로 판단하면 같은 고객의 같은 예약을 두 시스템이 서로 다른 날짜로 보게 된다.

2. 숙박은 밤 단위로 센다

호텔의 숙박은 체크인 날짜부터 체크아웃 날짜 전날까지의 밤 수로 계산된다. 11월 1일 체크인, 11월 3일 체크아웃이면 2박이며, 요금은 11월 1일 밤과 11월 2일 밤에 각각 붙는다. 너무 당연해 보이지만, 날짜를 다루는 코드에서 끝 날짜를 포함하느냐 마느냐는 가장 흔한 실수 가운데 하나이다.

• 요금이 날짜별로 다를 때(주중·주말, 성수기 시작일), 체크아웃 날짜의 요금이 잘못 붙지 않는가
• 연박 할인처럼 박 수에 따라 달라지는 규칙에서 박 수가 하나씩 어긋나지 않는가
• 숙박 날짜를 바꾸는 예약 변경에서 이미 지난 밤의 요금이 다시 계산되지 않는가

요금은 예약한 날짜가 아니라 숙박하는 날짜의 요금을 적용하는 것이 일반적이다. 10월에 예약한 12월 숙박에는 12월의 요금이 적용되어야 한다. 예약일과 숙박일을 혼동하는 결함은 요금 변경이 잦은 성수기 직전에 드러나는 경우가 많다.

3. 같은 시각도 어디서 보느냐에 따라 다르다

해외 온라인 여행사(OTA)나 채널 매니저와 연동하면 시간대(Time Zone) 문제가 생긴다. 외부 시스템이 협정 세계시(UTC)로 시각을 보내고 호텔 시스템이 이를 한국 시각으로 바꾸지 않으면 9시간의 차이가 생긴다. 한국 시각 오전 9시 이전의 예약은 UTC로는 전날이다.

취소 마감 시각에서 이 문제는 금전 문제로 이어진다. "체크인 3일 전 18시까지 무료 취소"라는 규정에서 18시는 호텔 현지 시각인가, 고객이 있는 곳의 시각인가, 서버의 시각인가. 해외 고객의 예약에서 이 기준이 시스템마다 다르면 같은 취소가 한쪽에서는 무료, 다른 쪽에서는 위약금 대상이 된다. 취소 규정과 위약금 계산의 테스트 방법은 호텔 예약 변경·취소 기능 QA 사례 분석에서 자세히 다루었다.

4. 달과 해가 바뀌는 날

월말과 연말은 매출 집계, 정산, 통계가 끊기는 날이다. 월말에 체크인해 다음 달에 체크아웃하는 연박 예약은 매출이 두 달로 나뉘어야 한다. 연말에는 연도가 바뀌면서 예약 번호 체계, 영수증 번호, 연간 누적 통계가 초기화되는 경우가 있어 이 처리가 정확한지 확인해야 한다.

윤년도 빠뜨리기 쉽다. 2월 29일이 있는 해에는 2월의 숙박 일수, 1년 전 같은 날짜와 비교하는 통계, "1년 이내" 같은 기간 계산이 평년과 다르게 동작해야 한다. 다음 윤년은 2028년이다.

테스트 설계: 경계를 목록으로 만든다

날짜 결함은 대부분 경계에서 생긴다. 경곗값 분석(Boundary Value Analysis)을 날짜에 적용하면, 테스트해야 할 시점을 미리 목록으로 만들어 둘 수 있다. 다음은 편집부가 제안하는 날짜 경계 목록이다.

1. 자정 직전과 직후(23:59, 00:00, 00:01)
2. 나이트 오디트 직전과 직후, 그리고 오디트가 진행되는 도중
3. 취소 마감 시각의 직전, 정각, 직후
4. 요금이 바뀌는 날의 전날 밤과 당일 밤
5. 월말 체크인·익월 체크아웃, 연말 체크인·익년 체크아웃
6. 2월 28일, 2월 29일, 3월 1일
7. 외부 채널에서 한국 시각 오전 9시 이전에 들어온 예약

이 시점들을 테스트하려면 시스템 시각을 원하는 시점으로 바꿀 수 있는 테스트 환경이 필요하다. 실제 날짜가 오기를 기다려서는 월말이나 윤년의 결함을 출시 전에 찾을 수 없다. 테스트 환경에서 시각을 조정할 수 있는지는 테스트 계획 단계에서 개발팀과 미리 합의해야 할 사항이다.

프런트 데스크에서 일해 본 사람이라면 자정 이후 도착하는 고객, 월말 마감, 연박 고객의 정산이 얼마나 자주 문제가 되는지 안다. 그 경험이 곧 테스트 조건이다. 현장의 감각을 테스트 설계로 옮기는 방법은 프런트의 "혹시"가 테스트 케이스가 되는 순간에서도 다루었다.