예약 기능 개발, 사례와 함께 보는 시간 기준과 검수 항목

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

• 예약 시각이 어느 지역의 시간인지 화면과 데이터에 함께 남깁니다.

• 정해진 시각의 반복 예약과 일정 시간 간격을 구분합니다.

• 일정 변경과 날짜 경계를 실제 화면에서 검수합니다.

예약 화면을 개발할 때 달력과 시간 선택 칸만 있으면 충분할지 고민되실 텐데요. 해외 고객이 참여하거나 정기 예약을 지원하면 같은 날짜와 시간을 보더라도 서로 다른 약속으로 이해할 수 있습니다. 관리자는 맞게 입력했다고 생각하는데 고객 안내에는 다른 시간이 표시되는 문제도 생깁니다.

개발을 마친 뒤 안내 문구만 고쳐서는 이런 차이를 해결하기 어려울 수 있습니다. 오늘은 예약 기능 개발을 맡기기 전에 합의할 시간 기준과 검수 항목을 알아보겠습니다.

1. 예약 시각의 기준 지역을 정해야 합니다.

예약 시간이 장소를 기준으로 하는지, 사용자가 있는 지역을 기준으로 하는지부터 정합니다.

국내 매장 방문 예약이라면 매장의 한국 시간을 안내하는 방식이 자연스럽습니다. 여러 나라에서 참여하는 온라인 상담은 같은 예약을 각 참여자의 현지 시간으로 보여줄 수 있습니다. 어느 쪽이든 사용자가 화면의 시각을 어떻게 이해해야 하는지 분명해야 합니다.

가령 한국에서 진행하는 상담에 해외 고객이 참여한다고 가정해 보겠습니다.

확인 화면에 오후 몇 시인지만 쓰기보다 기준 시간대를 함께 표시하고, 현지 시간으로 바꿔 보여준다면 그 사실을 알려주는 편이 좋습니다. 고객 화면과 운영자 화면에 숫자가 다르게 보여도 같은 약속인지 대조할 수 있어야 합니다.

개발사와는 어떤 정보를 보관할지 논의해 보세요.

예약이 발생하는 순간과 사용자가 고른 날짜·시각, 선택한 시간대를 나눠 살펴보면 좋습니다. UTC는 여러 지역의 시각을 비교할 때 쓰는 기준 시간입니다. 저장된 UTC 값만 보는 것과 사용자가 원래 어느 지역의 시간을 골랐는지 아는 것은 다르므로 필요한 정보를 구분해서 설명합니다.

시간대는 단순한 시차 숫자로만 다루지 않는 편이 좋습니다. 일부 지역은 계절에 따라 시계를 조정하는 일광 절약 시간제를 적용합니다. 따라서 해외 예약을 지원한다면 지역별 시간대 식별자를 사용할지, 시간대 규칙이 달라졌을 때 미래 예약을 어떻게 확인할지도 검토 대상입니다.

똑똑한개발자팀은 고객과 운영자가 같은 예약을 서로 대조할 수 있는지가 시간 표시의 중요한 기준이라고 생각합니다. 날짜 선택 화면뿐 아니라 예약 확인, 관리자 목록, 안내 메시지까지 함께 비교하면 화면마다 기준이 달라지는 문제를 찾기 쉽습니다.

2. 반복 예약의 의미를 구분해야 합니다.

매일 오전에 시작하는 예약과 일정 시간마다 실행되는 작업은 다릅니다.

앞의 예약은 해당 지역의 시계에 맞추고, 뒤의 작업은 이전 실행 이후 얼마나 지났는지를 기준으로 삼습니다. 한국 시간만 지원할 때는 차이가 잘 드러나지 않아도 해외 시간대가 들어오면 결과가 달라질 수 있습니다.

AWS EventBridge Scheduler는 지역 시간대를 기준으로 하는 일정에서 일광 절약 시간제 전환을 반영합니다. 시계가 앞으로 이동해 지정한 시간이 사라지면 해당 실행을 건너뛰고, 뒤로 이동해 같은 시간이 반복돼도 한 번 실행합니다. 반면 일 단위 간격은 24시간으로 계산합니다.

이처럼 정해진 현지 시각과 경과 시간의 차이를 구체적으로 이해하고 싶다면 AWS의 일정 유형과 시간대 안내를 참고해 보세요. 개발사에는 우리 서비스가 시간이 사라지거나 반복되는 날에 예약을 건너뛸지, 다른 시각을 제안할지, 운영자 확인을 받을지 설명할 수 있어야 합니다.

반복 예약을 수정하는 범위도 정합니다.

고객이 다음 예약 하나를 바꾸려는지, 앞으로 남은 모든 예약을 바꾸려는지 화면에서 구별해 보세요. 이미 끝난 예약은 그대로 두고 미래 일정만 수정할 수 있는지도 확인합니다. 반복 규칙을 바꾼 뒤 이전에 개별 수정했던 예약을 유지할지까지 합의하면 구현 범위를 더 정확히 정할 수 있습니다.

3. 날짜 경계와 변경 결과를 검수해야 합니다.

검수표에는 평범한 낮 시간 외에 날짜가 바뀌는 예약을 넣어보세요.

한 지역에서는 오늘이고 다른 지역에서는 내일인 경우, 월말에서 다음 달로 넘어가는 경우가 대상입니다. 해외 시간대를 지원한다면 일광 절약 시간제 전환 전후도 확인합니다. 이런 예시가 실제 제공 범위에 포함되는지 기획서와 먼저 맞춥니다.

예약을 옮긴 뒤 확인 화면만 보지 말고 운영자 목록, 캘린더 연동, 발송 대기 중인 알림까지 이어서 살펴봅니다. 취소한 예약의 알림이 남거나 바뀌기 전 시간이 메시지에 들어가면 고객은 어느 안내를 따라야 할지 혼란스럽습니다. 이미 발송한 안내와 아직 보내지 않은 안내를 구분해서 처리할 방법도 정합니다.

똑똑한개발자팀은 예약 검수에서 입력한 시간과 최종 안내가 일치하는지 끝까지 확인하는 편이 낫다고 봅니다. 저장 결과만 확인하면 사용자에게 전달된 내용을 놓칠 수 있기 때문입니다. 시각을 바꾼 직후 목록을 새로 열거나 다른 기기에서 확인해 보는 테스트도 포함해 보세요.

개발사에는 테스트할 기준 시각, 사용자 시간대, 기대하는 화면 표시를 한 묶음으로 전달하면 좋습니다.

결과가 다르면 저장할 때 생긴 오류인지 화면에 표시할 때 생긴 오류인지 구분합니다. 이를 확인할 수 있도록 원래 선택값과 변환 결과를 담은 자료를 요청하세요. 오류를 찾은 뒤에는 같은 조건으로 다시 확인해 수정 여부를 판단합니다.

4. 운영 정책을 개발 범위에 담아야 합니다.

견적을 비교할 때는 예약 기능 포함이라는 표현을 조금 더 풀어보세요.

지원할 시간대, 단건·반복 예약, 개별 일정 변경, 알림 갱신, 외부 캘린더 연동이 각각 어디까지 포함되는지 확인합니다. 모든 기능을 처음부터 넣을 필요는 없지만 지원하지 않는 조건은 운영자가 안내할 수 있어야 합니다.

똑똑한개발자는 웹·앱과 관리자 시스템을 기획·디자인·개발·운영해온 경험을 바탕으로 사용자 화면과 운영 흐름을 함께 살펴봅니다. 예약 시간을 선택하는 고객과 일정을 관리하는 직원이 같은 기준으로 업무를 처리하도록 기능 범위와 검수 조건을 연결해 설계할 수 있습니다.

에어로케이는 항공사의 정체성을 담은 웹사이트를 기획부터 디자인·개발까지 진행한 사례인데요. 제공된 화면에는 출발지와 도착지, 여행 날짜를 선택하는 영역이 담겨 있습니다. 이처럼 예약과 연결되는 웹사이트는 브랜드를 보여주는 화면과 고객이 일정을 선택하는 흐름을 함께 살펴볼 필요가 있습니다.

예약 기능의 시간 기준과 운영 조건을 함께 정리하고 싶다면 아래 똑똑한개발자 링크로 개발 상담을 문의해 주세요. 감사합니다. :)