예약 시스템은 왜 달력만 만들면 실패할까: 노쇼·예약금·알림톡 설계 [2026]

예약 시스템이 달력만 만들면 실패하는 이유는 “빈 시간”이 저장값이 아니라 자원·서비스·정책·홀드·확정 예약을 계산한 결과이기 때문입니다. 슬롯을 서버에서 원자적으로 선점하고 결제와 예약을 별도 상태로 대사해야 이중 예약과 결제 후 미확정을 복구할 수 있습니다.

가용 시간은 정책 엔진이 계산한다#

같은 담당자도 서비스마다 소요시간과 준비·정리 시간이 다를 수 있습니다. 영업시간, 휴무, 개인 일정, 공간·장비, 동시 수용량, 예약 간격을 입력으로 받아 후보 슬롯을 계산하세요. 결과 슬롯에는 계산에 사용한 정책 버전과 시간대를 연결합니다.

조회·홀드·결제·확정을 분리한다#

사용자가 본 슬롯은 그 순간의 스냅숏일 뿐입니다. 신청할 때 서버가 다시 검증해 제한 시간 홀드를 만들고, 결제 성공 뒤 홀드를 확정 예약으로 전환합니다. 만료 작업과 결제 웹훅이 동시에 와도 한 번만 상태가 바뀌도록 멱등 키와 조건부 갱신을 사용합니다.

실무 시나리오: 결제 성공 뒤 홀드가 만료될 때#

결제 응답이 늦어 홀드 만료 작업이 먼저 실행됐고 곧이어 결제 성공 웹훅이 도착했다고 가정하겠습니다. 슬롯을 무조건 되살리면 다른 고객의 예약과 충돌할 수 있습니다. 결제 거래를 미확정 예외로 격리하고 슬롯이 아직 가용하면 승인된 절차로 복구하며, 이미 배정됐다면 대체 시간 제안과 즉시 환불 중 정책에 맞는 처리를 실행합니다.

외부 캘린더는 교환 형식과 내부 원장을 분리한다#

RFC 5545 iCalendar 표준은 서로 다른 시스템이 일정·할 일·free/busy 정보를 교환하는 형식을 정의합니다. 시간대와 반복 규칙을 표현할 수 있지만 예약금, 홀드, 자원 수용량을 보장하는 예약 원장은 아닙니다. 외부 이벤트 ID와 내부 예약 ID, 동기화 버전을 별도로 연결하세요.

노쇼 정책은 고지·알림·변경 경험과 함께 설계한다#

예약금과 취소 비용은 서비스 유형과 계약에 맞춰 결제 전에 명확히 제시하고 적용한 정책 버전을 예약에 저장합니다. 알림 발송 성공만 보지 말고 고객이 확인했는지, 변경 링크가 유효한지, 취소된 슬롯이 대기자에게 재배정됐는지를 측정하세요.

시간대·경합·중복 웹훅을 인수한다#

자정과 일광절약시간이 있는 지역, 반복 휴무 변경, 마지막 한 자리 동시 신청, 결제 웹훅 중복·역순, 예약 변경 중 신규 신청, 알림 실패를 시험하세요. 비용 범위는 예약 시스템 개발 비용, 결제 상태는 결제 연동 개발, 회원 권한은 회원 관리 시스템과 함께 검토할 수 있습니다.