예약 성공은 끝이 아니라 이후 운영의 시작입니다. 고객이 선택한 조건과 현재 공급사 상태, 결제와 전달, 변경 이력을 같은 맥락에서 확인할 수 있어야 예약 시스템이 실제로 운영됩니다.
실무 가이드
왜 중요한가
성공 메시지 뒤에는 재확인, 변경, 취소, 전달, 고객 문의가 이어질 수 있습니다. 이 흐름을 출시 뒤에 붙이면 팀은 불완전한 기록과 기억을 조합해 예약을 설명하게 됩니다.
예약 데이터
주문, 탑승객 또는 고객 정보, 티켓, 좌석, 가격 스냅샷, 상태, 공급사 참조값, 결제, 전달, 이력은 각각 다른 질문에 답합니다. 이 값들은 느슨한 필드 모음이 아니라 예약 당시의 결정을 설명하는 하나의 기록으로 연결돼야 합니다.
상태 관리
CREATED, PENDING, CONFIRMED, FAILED, CANCELLED, CHANGED는 이해를 돕는 예시일 뿐 SORADA의 고정 표준은 아닙니다. 제품마다 공급사 동작과 고객 약속에 맞춰 상태를 정의해야 합니다.
각 상태에 담당자, 가능한 다음 행동, 고객에게 보여 줄 설명이 있는지가 핵심입니다.
스냅샷이 필요한 이유
나중에 상품이 바뀌어도 예약 당시 가격, 상품 조건, 좌석, 고객에게 보인 설명이 사라지면 안 됩니다. 스냅샷은 현재 상품 정보를 과거의 예약 계약으로 오해하지 않게 합니다.
기술적 관점
상태 변화는 이력으로 남기고, 공급사 원본 상태와 고객에게 전달한 상태를 구분하는 편이 좋습니다. 중복 처리, 참조값 보존, 결제·전달 경계는 예외 처리의 안정성을 좌우합니다.
제품·UX 관점
확인 화면은 지금 확정된 사실, 이후 전달될 정보, 다시 찾을 수 있는 기록을 알려야 합니다. 공급사 결과가 PENDING인데 최종 확정처럼 말해서는 안 됩니다.
운영 관점
운영자는 고객에게 보인 정보, 공급사 상태, 변경 이력, 다음 조치를 한 화면에서 확인해야 합니다. 예외 처리는 예약 비용과 고객 신뢰가 만나는 지점이므로 초기에 설계해야 합니다.
SORADA의 관점
K-Booking과 K-Operations는 결제 뒤에 남는 기록에서 만납니다. 선택, 결과, 이후 작업을 같은 팀이 읽을 수 있게 만드는 것이 예약 아키텍처의 기준입니다.
핵심 정리
다음 설계에서 바로 확인할 항목.
- 예약은 오래 남는 운영 기록으로 설계합니다.
- 상태의 의미와 담당을 명확히 합니다.
- 예외 처리를 급해지기 전에 만듭니다.
확인 목록
- 예약 당시 가격과 조건을 기록으로 볼 수 있는가?
- 공급사 상태와 고객 노출 상태가 구분되는가?
- 운영자가 이력과 다음 조치를 함께 확인할 수 있는가?
- 대기·변경·취소 경로가 출시 전에 설계됐는가?
흔한 실수
- 확인 화면을 설계의 종점으로 보는 일
- 현재 상품 데이터로 과거 예약 사실을 덮어쓰는 일
- 고객 맥락 없이 공급사 참조값만 운영자에게 주는 일
