다통화 여행 예약 사이트, 마진은 어디서 새는가

리야드의 서브에이전트가 묻는다. 검색 화면에는 SAR로 떠 있었는데 인보이스는 왜 AED냐고. 확인해 보면 두 숫자 다 맞다. 운임은 공급사가 한 통화로 매겼고, 여행자에게는 다른 통화로 보여 줬고, 카드가 승인되는 순간 세 번째 통화로 정산됐다. 아무도 실수하지 않았는데 손에 남는 돈만 모자란다. 다통화 여행 예약 사이트가 조용히 돈을 잃는 자리가 여기고, 범인이 환율 자체인 경우는 거의 없다. 일하는 건 그 밑의 반올림 규칙이고, 견적과 정산 사이의 위험을 누가 지고 있느냐는, 아직 아무도 답하지 않은 질문이다.

통화는 두 갈래, 돈이 움직이는 건 하나뿐

국경을 넘어 파는 가게는 언제나 두 개의 통화 체계를 동시에 굴린다. 이 둘을 하나로 여기는 데서 대부분의 혼란이 시작된다.

표시 통화는 여행자가 읽는 숫자다. 표현 계층일 뿐이다. 이 플랫폼에서는 화이트라벨 사이트마다 기본 통화와 제시할 통화 목록을 고르고, 가격은 테넌트별 환율표로 클라이언트에서 환산된다. 이 한 줄이 들리는 것보다 무겁다. 화면의 숫자는 파생된 값이다. 페이지가 그려지는 순간의 공급가에 우리 환율을 곱한 결과이지, 누군가 붙잡아 두기로 합의한 가격이 아니다.

정산 통화는 실제로 돈이 움직이는 통화다. 공급사가 청구하는 통화, 게이트웨이가 승인하는 통화, 은행 명세서에 찍히는 통화, 환불이 나가는 통화. 보통 공급사마다 하나, 게이트웨이마다 하나 있고, 둘이 같으리라는 보장은 없다.

여행사가 "우리는 AED, SAR, USD로 판다"고 말할 때 실제 뜻은 거의 언제나 "세 개로 표시하고 하나로 정산한다"이다. 장사로는 아주 멀쩡한 방식이고, 대부분의 가게가 그렇게 돈다. 문제가 되는 건 하류의 무언가가 표시 가격을 약속으로 취급하는 순간이다. 환불, 서브에이전트 정산서, 분쟁. 표시 가격은 약속이 아니었다. 렌더링이었다.

다통화 예약 사이트에서 환리스크는 누가 지는가

여행자가 가격을 본 시점부터 돈이 정산되는 시점까지, 누군가는 반드시 움직이는 환율에 노출돼 있다. 물어야 할 것은 그 노출이 있느냐가 아니다. 누구 것이냐, 그리고 본인이 알고 있느냐다.

정직한 답은 셋이다. 자국 통화로 넷요금을 계약해 환산을 상대가 흡수하게 했다면 공급사가 진다. 공급사 통화로 청구해 카드사가 환전하게 하면 여행자가 진다. 우리에게는 가장 깨끗하고, 여행자가 가장 많이 항의하는 방식이기도 하다. 명세서 금액이 확인서 금액과 다르니까. 아니면 우리가 진다. 환율표를 둔다는 건 바로 그 뜻이고, 우리 환율과 정산일 실제 환율의 차이는 어느 방향이든 우리 것이 된다.

셋 다 변호할 수 있다. 피해야 할 건 아무도 정하지 않은 네 번째 상태다. 환율표는 생각난 사람이 고치고, 포지션은 한 분기 뒤 대사에서 발견된다. 주인과 갱신 주기를 한 문장으로 말할 수 없다면 지금 그 네 번째에 있다.

여기서 실제로 움직이는 변수는 환율 자체가 아니라 갱신 주기다. 일주일에 한 번 고치는 환율표와 분기에 한 번 고치는 환율표는 같은 기능이지만 전혀 다른 크기의 포지션을 만든다. 주기가 길수록 우리가 들고 있는 미실현 손익이 커지고, 그 손익은 판매량에 비례해 늘어난다. 주기를 정할 때 물어야 할 건 얼마나 자주 고칠 수 있느냐가 아니라, 이 시장에서 두 번의 갱신 사이에 팔리는 금액이 얼마이고 그 금액의 몇 퍼센트까지 흔들려도 견딜 수 있느냐다.

반올림은 서식이 아니라 가격 결정이다

대부분의 엔진은 반올림 단위 기본값이 0.01이다. 십진 통화가 그렇게 생겼으니까. 여행에는 네 가지 이유로 맞지 않는다.

첫째, 모든 통화에 보조 단위가 있는 건 아니다. 원화와 엔화에는 없다. 그런 시장에서 소수점 두 자리로 찍힌 가격은 소프트웨어가 새어 나온 흔적으로 읽히고, 존재하지 않는 단위에 0.01 단위로 반올림하는 건 헛도는 산수다.

둘째, 환산된 가격은 환산된 티가 난다. 1,236.47은 자기가 곱셈의 결과라고 스스로 밝히는 숫자다. 그걸 읽은 여행자는 뒤에 다른 숫자가 있다는 걸 알고, 다음 행동은 그 숫자를 다른 데서 찾는 것이다. 떨어지는 자리가 반듯한 가격만이 우리 가격으로 읽힌다.

셋째, 방향이 있다. 가까운 쪽으로 반올림하면 대칭이라 오차가 물량 안에서 상쇄되고 마진은 움직이지 않는다. 늘 올리면 매번 조금 얹고, 늘 내리면 매번 조금 내준다. 셋 다 정책이고, 골랐다면 아무 문제 없다. 사고는 고르지 않았는데 한쪽으로 기울어 있고, 나중에 유독 한 시장의 매출총이익만 왜 조금 낮은지 갸웃거리는 경우다.

넷째는 연산 순서인데, 실제로 무는 건 이것이다. 환산하고, 마크업을 얹고, 마지막에 한 번만 반올림한다. 환산할 때 넷운임을 반올림하고 마크업 뒤에 또 반올림하는 엔진은 두 번 반올림했고, 두 번째는 이미 나머지를 잃은 숫자에 적용된 것이다. 운임과 세금과 부가서비스를 별개 항목으로 매기면 이게 쌓여서 합계가 항목의 합과 달라진다. 이건 가격 문제이기 전에 정산 문제다.

실무에서 단위를 고르는 방법은 통화의 소수점 자릿수를 보는 게 아니라 그 시장의 가격대를 보는 것이다. 항공권 한 장과 좌석 지정 수수료에 같은 반올림 단위를 쓰면 한쪽에서는 아무 의미가 없고 다른 쪽에서는 가격 자체가 뒤틀린다. 판단 기준은 단순하다. 반올림이 만들어 내는 차이가 그 품목의 가격에 비해 눈에 띌 정도라면, 그건 표시를 다듬는 일이 아니라 사실상 할인이나 인상을 매기는 일이다. 그때부터는 마크업 정책으로 다룰 사안이지 설정 화면에서 기본값으로 둘 사안이 아니다.

항목별로 반올림하든 합계를 반올림하든 하나만 하고, 둘 다는 하지 말 것. 그리고 인보이스에 찍히는 숫자는 서브에이전트가 스프레드시트에 넣었을 때 반드시 맞아떨어지게 해 둘 것. 그들은 반드시 넣는다.

실제로 굴리는 세 가지 방식

아래 셋은 기능 등급이 아니다. "여행자에게 무엇을 약속하는가"에 대한 서로 다른 세 답이고, 짊어지는 일의 양이 다르다.

거의 모두가 왼쪽 칸에서 시작해, 신경 쓸 값어치가 생긴 시장 하나만 가운데로 옮기면 된다. 오른쪽 칸은 기술 옷을 입은 운영 결정이다. 지금 사내에서 원장 둘을 맞춰 보는 사람이 없다면, 통화를 하나 더 늘린다고 그 습관이 생기지는 않는다.

틀렸을 때 치르는 값

고전은 환불이다. 어떤 환율로 팔린 예약이 여섯 주 뒤 취소되고, 엔진이 손에 쥐고 있던 오늘 환율로 환불된다. 환율이 여행자에게 유리하게 움직였다면 차액은 우리가 냈고, 반대로 움직였다면 여행자는 덜 받았다고 믿는데, 그 믿음이 아주 틀린 것도 아니다. 판매 시점 환율을 예약에 저장하고, 그것에 대고 환불하라.

덜 알려진 쪽은 부분 환불이다. 항공권 한 장만 취소하고 나머지 일정을 유지하거나 호텔에서 하루치만 돌려줄 때는, 이미 반올림된 총액에서 한 조각을 떼어내야 한다. 판매 시점에 구성요소별 가격과 환율을 함께 저장해 두지 않았다면 그 조각은 계산해 낼 방법이 없고, 현장에서는 결국 사람이 눈대중으로 정한 숫자가 나간다. 같은 예약에 부분 환불이 두 번 일어나면 그 눈대중끼리도 맞지 않는다.

조용한 쪽은 여신이다. 서브에이전트 여신 한도와 정산 청구는 여기서 스프레드시트가 아니라 일급 기능으로 존재한다. 다만 그게 이득이 되는 건 한도가 그 에이전트가 실제로 파는 통화로 매겨져 있을 때뿐이다. SAR로 파는 상대에게 USD로 한도를 걸면 환율이 움직일 때마다 한도도 표류하고, 그 표류는 대개 최악의 순간에 발견된다. 공항에서 발권이 막히는 순간에.

그리고 느린 손실. 낡은 환율표는 에러를 내지 않는다. 팔린다. 몇 주 동안은 한 시장의 물량이 유난히 좋아 보이고, 달이 닫히는 순간 그 물량이 우리가 주는 줄 몰랐던 할인이었다는 게 드러난다. 환율표에 날짜와 담당자를 붙이라는 주장의 근거가 이것이다. 아무도 안 읽는 cron 말고.

시장 하나를 켜기 전에

위의 어떤 것도 프로젝트가 필요하지 않다. 필요한 건 통화가 선택기에 나타나기 전에, 이 순서대로 적어 둔 결정이다.

• 그 시장의 정산 통화와, 그것이 적용되는 공급사와 게이트웨이를 지목한다. 한 문장으로.
• 환율표를 누가 얼마나 자주 갱신하는지 정하고, 마지막 갱신일을 사람 눈에 띄는 곳에 둔다.
• 반올림 단위는 통화별로 고른다. 전역 하나로 두지 않는다. 보조 단위 없는 통화는 따로 확인한다.
• 순서가 "환산, 마크업, 마지막에 한 번 반올림"인지, 항목 가격의 합이 인보이스 합계와 맞는지 확인한다.
• 환불이 오늘 환율이 아니라 저장된 판매일 환율을 쓰는지 확인한다.
• 서브에이전트 여신 한도와 정산 인보이스가, 그 에이전트가 읽는 명세서와 같은 통화인지 확인한다.

그런 다음 켜고, 이 주 동안 팔고, 그 이 주를 한 번 손으로 대사해 본다. 첫 시장은 위 여섯 중 무엇을 잘못 짚었는지 알려 주는 장치다.

통화 동작은 가게에서 가장 데모하기 쉽고 가장 감사하기 어려운 부분이다. 그러니 설계를 굳히기 전에 실제 설정 화면을 보는 값어치가 있다. 기본으로 무엇이 따라오는지, 통화 목록과 환율표와 마크업이 사는 관리 화면을 보고 싶다면 마법사로 하나 띄워 보라. 플랫폼 서브도메인 위에 준비되고 카드는 묻지 않는다. 남의 엔진에 올라탈지 자체가 아직 고민이라면, 화이트라벨과 자체 구축 비교가 이 글 밑에 깔린 논쟁이고, 나머지 면은 화이트라벨로 실제 무엇을 얻는가에서 다룬다.

환율은 공개 정보다. 반올림 규칙과 환불에 쓰는 환율과 갱신 주기는 공개돼 있지 않고, 국경을 넘는 예약의 마진이 실제로 정해지는 곳은 그 셋이다.