화이트라벨이냐, 자체 예약엔진 구축이냐

견적서가 도착했고 금액도 감당 못 할 수준은 아닙니다. 믿을 만한 개발자가 예약엔진 가격을 매겼습니다. 검색, 결과 목록, 결제, 관리자 화면 하나, 기간은 석 달. 숫자가 터무니없지는 않습니다. 자체 시스템을 갖고 싶다는 생각은 2년째 하고 있었습니다. 화이트라벨이냐 자체 예약엔진 구축이냐라는 질문이 실제로 결판나는 순간이 바로 여기인데, 대개 엉뚱한 근거로 결판납니다. 2년 차의 모양이 아니라 첫 달의 가격으로요.

그 견적은 정직합니다. 다만 눈에 보이는 부분의 작업만 담고 있습니다.

개발 견적이 실제로 값을 매기는 대상

여러분이 받게 될 거의 모든 견적은 표면에 값을 매깁니다. 검색 폼, 결과 목록, 탑승객 정보 페이지, 결제 단계, 관리자 화면의 예약 목록. 그 작업은 실재하고, 역량 있는 팀이라면 잘 해냅니다. 동시에 그것은 이미 범용재가 된 절반이기도 합니다. 같은 노선을 파는 두 여행사가 결코 경쟁하지 않는 절반이죠. 잔여석 화면의 줄 간격이 더 좋아서 그 여행사를 고른 고객은 지금까지 한 명도 없었습니다.

나머지 절반은 브라우저에서 보이지 않는 연동의 반대편에 있습니다. 시간이 사라지는 곳이 거기입니다.

비용은 화면이 아니라 연동 건수에서 나온다

supplier에 접속 권한을 요청하면 회신 메일에 API key가 담겨 오지 않습니다. 테스트 환경, certification 절차, 법인 단위로 발급되는 자격 증명, 규정 문서, 그리고 자기 일정대로 답하는 담당자 한 명을 받습니다. 그다음에는 그 supplier 특유의 방언을 만납니다. static rate는 이쪽, live availability는 저쪽. free-sale 옆에 release period가 붙은 allotment. 엔진이 반드시 지켜야 하는 cut-off. 변경에 요금이 붙는지 결정하는 fare rule. 그리고 누구의 것과도 맞아떨어지지 않는 ancillary 카탈로그. 이제 이것을 고객이 당연히 갖고 있으리라 기대하는 supplier 수만큼 곱하십시오.

연동 하나는 프로젝트입니다. 여섯 개는 부서이고, 그 일은 끝나지 않습니다. 여섯 곳 중 누구도 변경을 멈추겠다고 약속한 적이 없기 때문입니다.

견적서에 실제로 적힌 화면들 뒤에도 같은 함정이 있습니다. 검색은 하나의 기능처럼 보이지만, 두 항공사가 같은 여정을 다른 가격으로 돌려주는 순간 코드 안에서 고객이 어느 쪽을 볼지 결정해야 합니다. 환불은 버튼 하나처럼 보이지만, fare rule은 위약금이라 하고 supplier는 바우처라 하고 고객은 카드로 돌려달라고 합니다. markup은 설정 페이지의 숫자 하나처럼 보이지만, 같은 운임 위에서 법인 고객에게 한 규칙, 부산의 sub-agent에게 다른 규칙, 매장에 걸어 들어온 손님에게 또 다른 규칙을 적용하고 싶어지는 날이 옵니다.

그 산수가 바로 개발 견적이 빼놓는 부분이고, UI에 견주면 반올림 오차가 아니라 제품 그 자체입니다. 화이트라벨 플랫폼에서는 그 일이 이미 끝나 있고 이미 사람이 붙어 있습니다. supplier 콘텐츠는 한 건씩 서명하는 계약이 아니라 supplier group을 통해 매장에 도달하고, 사이트는 실제로 파는 것에 따라 항공, 호텔, 패키지, 입장권을 켭니다.

2년 차까지 살아남는 비교표

이 표를 구매자가 아니라 운영자의 눈으로 읽으십시오. 모든 행의 질문은 같습니다. 누가 책임을 집니까?

이 중 두 행은 직접 구축 쪽입니다. 위로용 상품이 아닙니다. 파는 것이 충분히 특이하다면 그 두 행이 위쪽 전부를 이깁니다.

잘못 고르면 치르는 값

자체 구축 엔진의 실패는 프로젝트가 무너지는 모습이 아닙니다. 무너지는 건 눈에 보이고, 아프지만 넘어갈 수 있습니다. 값비싼 쪽은 잘 돌아가던 시스템이 서서히 멈추는 경우입니다.

작성한 개발자는 이직하고, 다음 사람은 코드를 통째로 읽어본 사람이 아무도 없기 때문에 사소한 변경마다 위험 비용을 붙여 견적합니다. supplier는 자기 일정대로 endpoint를 폐기하고, 예약은 모니터링보다 고객이 먼저 알아차리는 방식으로 실패하기 시작합니다. 1년 차에 정확히 구현한 fare rule은 다시 검토되지 않고, 뒤따라오는 ADM은 계약 개발자가 아니라 여러분의 IATA 번호로 청구됩니다. 결제 자격 증명이 만료됩니다. 인증서가 만료됩니다. 두 버전 뒤처진 프레임워크는 일주일도 잡아두지 않았던 보안 논의로 바뀝니다.

이 중 어느 것도 청구서 형태로 오지 않습니다. 그래서 사람들이 실제로 하는 비교에는 절대 등장하지 않습니다. 그것은 주의력의 형태로 옵니다. 화요일을 망가진 PNR에 쓰는 대표는 그 화요일에 아무것도 팔지 못했고, 자체 구축 이후 조용해진 여행사가 조용해진 이유는 소프트웨어가 고장 나서인 경우가 드뭅니다. 일을 물어 오던 사람이 이제 시스템을 지키는 사람이 되었기 때문입니다.

직접 만드는 편이 정말 옳은 경우

그런 경우가 분명히 있고, 사례가 충분히 구체적이라 스스로 대조해 볼 수 있습니다.

• 소프트웨어가 곧 차별점일 때. 여행을 파는 대신 다른 여행 사업자에게 기술을 판다면, 돈을 받는 바로 그것을 외부에 맡길 수는 없습니다.
• 이미 엔지니어가 있고, 두 번째 사람 예산까지 잡아두었을 때. 만드는 사람이 아니라, 첫 사람이 떠난 뒤 넘겨받을 유지보수 담당자 말입니다. 승계 계획 없는 구축은 절차만 늘어난 임대입니다.
• 아무도 모델링하지 않은 업무를 운영할 때. 자체 객실을 쥐고 단체 PNR을 비자 단계에 묶는 성지순례 전문 업체는, 범용 엔진이 딱 들어맞을 일을 하고 있지 않습니다.

어느 쪽도 아닌 길도 있습니다. 매장은 사고, 진짜 자기 것인 부분만 직접 만드는 것입니다. 플랫폼이 항공과 호텔 API를 열어두는 이유가 정확히 그것인데, 다만 접근은 셀프 서비스 키가 아니라 상담으로 시작합니다. 전면 구축을 확정하기 전에 이 혼합안의 값을 매겨 보십시오. 정말 통제하고 싶었던 부분은 대개 엔진 전체가 아니라 업무 흐름 하나입니다.

그리고 사업 모델이 sub-agent 위에서 돌아간다면 그 부분도 제대로 계산하십시오. 여신 한도와 settlement 청구는 여기서 일요일마다 누가 대사하는 스프레드시트가 아니라 일급 개념입니다. 자체 구축에서는 첫 견적에 아무도 넣지 않은 두 번째 프로젝트입니다.

양쪽에 똑같이 던지는 질문 하나

무엇이든 서명하기 전에 개발자와 플랫폼 양쪽에 같은 질문을 하십시오. 내년 3월에 어느 supplier가 certification을 바꾸면, 그 작업은 누가 하고, 누구의 기한에 맞추며, 나는 어떻게 알게 됩니까? 두 답은 닮지 않을 것이고, 그 차이가 실제로 고르고 있는 대상입니다.

문서 두 장을 견주는 것보다 돌아가는 매장과 견적서를 견주는 편이 더 정직한 시험입니다. 그러니 확정 전에 무엇이 실제로 준비되는지 보고 싶다면 마법사에서 사이트를 하나 만들어 보십시오. 카드를 묻지 않고, 받은 서브도메인은 자체 도메인을 연결한 뒤에도 영구히 남습니다.