API 응답이 정상이라고 해서 고객이 바로 예약할 수 있는 것은 아닙니다. 여행 서비스는 공급사 데이터에 제품의 의미를 더하고, 고객이 이해할 수 있는 약속으로 바꾸며, 예약 뒤에도 설명 가능한 기록을 남겨야 합니다.
실무 가이드
왜 중요한가
공급사 API는 재고와 규칙을 전달하지만 고객의 판단 순서까지 설계하지는 않습니다. 예약 가능 여부, 가격, 상품 조건이 도착하는 방식과 고객이 확인해야 하는 방식은 다를 수 있습니다.
처음 연동이 성공했을 때는 이 간극이 잘 보이지 않습니다. 변경과 취소, 대기 상태, 고객 문의가 시작되면 그때부터 제품의 책임이 드러납니다.
여행 기술 서비스에서 생기는 문제
인증 방식과 API 호출 제한, 상품 메타데이터, 가격 기준 시점, 예약 가능 여부, 예약 상태, 오류 응답, 취소·변경 규칙은 서로 다른 시간과 신뢰도로 움직입니다. 조회 가능이 곧 확정 가능을 뜻하지 않는 경우도 있습니다.
필드명은 있어도 고객에게 어떤 의미인지 분명하지 않을 수 있습니다. 공급사 오류 문구를 그대로 보여 주면 고객은 다음 행동을 알기 어렵고, 운영자는 확인 기준을 잃기 쉽습니다.
기술적 관점
원본 응답, 서비스용 정규화 데이터, 고객에게 보여 준 설명을 같은 것으로 취급하지 않는 편이 안전합니다. 재시도와 중복 요청, 캐시와 확정 직전 재확인, 오류 대응은 예약 결과에 영향을 주므로 명확한 규칙이 필요합니다.
PENDING, CONFIRMED, FAILED 같은 상태는 개념 예시일 뿐입니다. 중요한 것은 각 상태가 고객에게 무엇을 뜻하고 누가 어떤 다음 행동을 할 수 있는지 정하는 일입니다.
제품·UX 관점
검색 화면에서 후보를 제시하고 상품·일정 화면에서 조건을 해석하며 좌석·옵션과 가격 화면에서 선택의 제약을 알립니다. 결제 뒤 예약 결과 화면은 단순한 성공 화면이 아니라 현재 상태와 이후 안내를 전달하는 화면이어야 합니다.
운임, 시간대, 선택 조건처럼 결정을 바꾸는 정보는 결제 이후가 아니라 결제 전에 보이는 것이 맞습니다.
운영 관점
예약 후에는 상태 확인, 변경, 취소, 고객 문의, 공급사 재확인이 이어집니다. 운영 화면에는 고객에게 보인 정보, 공급사 상태, 이력, 다음 조치가 함께 있어야 설명을 처음부터 다시 만들지 않아도 됩니다.
SORADA의 관점
글로벌 API 작업은 공급사 규칙과 고객 약속 사이의 간격을 제품으로 다루기 시작할 때 여행 기술이 됩니다. 그 지점에서 데이터, 예약 UX, 현지화, 운영이 만납니다.
핵심 정리
다음 설계에서 바로 확인할 항목.
- 공급사 상태를 서비스 의미로 다시 정의합니다.
- 예약 결과를 운영 기록으로 설계합니다.
- 결제 전 제품 언어로 조건을 설명합니다.
확인 목록
- 고객이 바로 판단할 수 있는 상태와 추가 설명이 필요한 상태가 구분되는가?
- 결제 전 다시 확인해야 하는 가격·조건·시간 값이 정해져 있는가?
- 원본 오류를 안전한 다음 행동으로 바꿀 수 있는가?
- 운영자가 고객에게 보인 내용을 확인할 수 있는가?
흔한 실수
- 조회 가능을 확정 예약처럼 표현하는 일
- 공급사 용어를 조건 설명 없이 그대로 옮기는 일
- 성공 화면만 설계하고 지원 흐름을 나중에 붙이는 일
