04 AsianaSabre, 2년 6개월의 기록(2)
회사생활을 관통한 두 단어, BFM & Expedia
AsianaSabre에서의 2년 6개월을 관통하는 두 단어가 있다. 바로 'BFM'과 'Expedia'이다.
이 단어들은 내 멱살을 잡고 맹렬하게 질주하며 짧은 시간 안에 내가 Skill-up 할 수 있도록 도와주었고, 더불어 회사생활에는 지옥문을 활-짝 열어주었다. 이번 챕터에서는 그 이야기를 자세히 풀어본다.
3. BFM(Bargain Finder Max) 프로젝트
올여름, LA로 휴가 계획을 준비하는 직장인 A가 있다. 가장 먼저 해야 할 일은? 여행사 웹사이트에 접속해 LA로 향하는 비행기 티켓을 구매하는 것이다. 휴가 일정과 맞고, 비행시간이 짧으며, 이왕이면 기내식이 맛있는 항공사의, 가장 저렴한 티켓을 사고 싶을 것이다.
눈은 손보다 빠르다 직장인 A 씨에게 딱 맞는 비행기 티켓을 찾아주는 시스템, 그것이 바로 'BFM'이다.
Sabre에서는 Shopping Product(고객이 쇼핑하는 과정에 관여하는 서비스)라는 카테고리 안에 수많은 서비스를 제공하는데, BFM은 이른바 요즘 잘 나가며 밀고 있는(?) 가장 스마트한 운임제공솔루션이라고 보면된다.
항공권을 구성하는 Database는 크게 3 가지 -스케줄, 운임, 좌석-이며, 각각의 데이터는 서로 다른 시스템을 기반으로 발전해왔다. 항공 스케줄은 OAG-1929년 미국에서 여행자를 위한 총 300개의 항공편 정보를 담은 책자를 발행하다가, 컴퓨터 기술의 진보와 항공산업의 발전에 따라 온라인 시스템까지 제공하게 된 회사- 에서, 항공운임은 ATPCO -전 세계 모든 항공사는 운임 데이터를 정해진 포맷에 맞추어 ATPCO 서버에 입력해야 한다-, 좌석 상황은 항공사 개별 서버에서 관리·제공한다.
*항공운임 ATPCO https://www.atpco.net/
*Schedule OAG https://www.oag.com/airline-schedules
BFM이 등장하기 전에는 이랬다. 소비자가 여행사 웹사이트에 접속해 2019년 3월 15일, 인천 출발 오사카 도착 항공권 '검색' 버튼을 누른 순간, 시스템은 1) 스케줄 DB에 접속해 2019년 3월 15일 인천에서 출발하며 오사카로 도착하는 비행 스케줄 전체를 쭉- 끌어오고, 2) 그 날짜에 사용할 수 있는 운임을(항공권 운임은 시즌 별로 달라진다) 가져와 스케줄 data에 1:1로 매칭 한 뒤, 3) 그중에서도 좌석이 아직 남아있는 옵션들을 추려서 프런트 화면에 뿌려주는 3단계 과정을 거친다. 물론 인천에서 오사카를 가는데 2번 넘게 경유하고 지구 반 바퀴를 돌아, 비행시간만 14시간씩 걸리는 요상한 항공권들은 걸러내는 작업도 포함이다. BFM은 그 3단계 과정을 1단계로 획기적으로 줄인, 스마트한 Shopping product인 셈이다. 무수한 데이터를 알아서 끌어오고 정렬한 뒤, 소비자 또는 여행사 취향에 맞게 세팅된 AI알고리즘에 따라 최고의 선택지만을 보여준다는 것이다.
여기서 질문,
BFM이란 시스템을 최근에 도입했다면, 그동안 우리는 어떻게 온라인으로 비행기 티켓을 구매했는가?
그렇다. 한국은 그동안 로컬에서 개발한 자체 운임 검색시스템(FMS)을 사용하고 있었고, 내가 involve 했던 BFM프로젝트란, 정확히 말하면 BFM Migration 프로젝트, 즉 기존에 사용하던 중앙시스템을 BFM기반으로 옮기는 대대적인 규모의 사업이었다. (비유하자면, Window 기반 서비스를 MAC으로 옮긴다고 볼 수 있다)
- 3.1 하나라도 놓칠 수 없는 Spec 분석
Migration의 시작은, 이전 시스템의 Spec을 발라내어(?) 신규 시스템에 해당 기능들이 존재하는지를 꼼꼼히 확인하는 작업이다. 앞에서 말했듯이, 이전 시스템은 10년 넘는 세월에 걸쳐 지금 모양으로 완성되었다. 그 스펙을 분석하는 일이란, 과거 10년 동안 업계에 무슨 일이 있었는지를 되도록 빠짐없이 복기하는 지난한 과정이었고, 나로서는 내가 중학교를 다니던 시절 이 회사에 무슨 일이 있었는지를 들으며 강제 추억여행을 하는 괴로운 시간이었다.
A 부장: 자, 이제 경유 횟수 관련해서 이야기해볼까? 지금 시스템에는 경유를 5회까지 선택하도록 프런트에서 제공하고 상세 스케줄 조회하는 페이지에도 들어가 있는데, 이렇게까지 이게 필요하나? 요즘 누가 경유를 세네 번씩 하면서 해외여행을 가?!
B과장 : 그러네요, 아무리 많이 해야 경유 세 번 정도일 텐데, 시스템에도 3회로만 제한할까요?
C차장: 아니야 아니야, 이거 이렇게 횟수 늘려놓은 이유가 있어요. 2010년도인가? 00항공사에서 유럽 가는 티켓을 출시했다고. 실제 경유 횟수는 한 번인데, 그 안에 Hidden stop이라는 게 있었다니까? 비행기는 착륙하는데 승객은 내리지 않고 기름만 넣는 케이스. 이거 때문에 컴플레인 엄청 받았잖아! 어떤 승객이 자기는 경유 한 번하는 여정인 줄 알고 티켓 끊었는데, 왜 여러 번 서냐고. Hidden stop도 경유에 포함시켜서 시스템을 만든 거야 그때.
A, B: 아... 그러면 유지하거나, hidden stop으로 발라내서 구현할지를 따로 논의해야겠네...
위와 같은 대화가 프로젝트 회의 때마다 백 번쯤 반복되었다. 나에게는 항공산업의 역사를 단기간 속성 코스로 학습할 수 있는 좋은 기회이기도 했지만, 내가 숙지하는 것보다 빠른 속도로 밀고 들어오는 학습 분량에 머리가 어질어질했다.
- 3.2 영원히 반복되는 test, test,,, test
Spec 분석작업이 끝나면 BFM 기능 테스트에 돌입한다. 한국시장에 필요한 기능이 제대로 구동되는지, 우리가 예상한 방향으로 돌아가는지 확인하는 과정이다. 기본적으로는 항공권 검색 필터인 경유지, 다구간조회, Codeshare 옵션, 소아/유아 운임 등을 선택했을 때 결과가 제대로 노출되는가를 확인한다. 보다 복잡한 케이스 중에는 정말 기상천외한 것들도 있었는데, 한 두 가지 사례를 옮겨보면 이렇다.
항공권 검색 필터에는 생각보다 많은 것들이 존재한다.
BFM에는 운임을 내 입맛대로 가져오기 위한 설정값이 5~60개쯤 존재한다. 인천-상하이를 여행 가는데 한 번쯤 경유하는 대신 저렴한 운임을 가져올 수도 있고, 기내 와이파이가 제공되는 항공사를 찾아줄 수도 있다. 각각의 필터 값을 어떤 조합으로 설정하느냐에 따라서 조회되는 운임이 천차만별로 달라진다.
인천-상하이 항공요금. 경유해서 가느라 편도 비행시간만 21시간이고, 게다가 이코노미 좌석인데, 왜 120만 원인 거죠?!
그러나 옵션이 많다는 게 무조건 좋은 것은 아니었다. 그만큼 테스트 시나리오도 복잡해졌다. 때론 위 상황처럼 인천-상하이 항공권을 검색하는데 왜 갑자기 100만 원짜리 요금이 보이는 것인지, 30만 원짜리 운임은 도대체 어디로 갔는지, 50개 옵션을 어떻게 조정해야 하는지를 끊임없이 확인하는 작업의 연속이었다. 이것을 대륙별로 나누고, 노선별로 나누고, 또 항공사별로 나누어서 테스트하고 원인을 추적하다 보면 말 그대로 24시간이 모자란다.
L차장: BFM에서는 외국인 노동자 운임이 검색 안 되네요.
J과장: 어? 중국·베트남 지역 전문 여행사들은 외국인 노동자만 장사하는 곳들이 있어서 꼭 나와야 되는데? BFM은 지원이 안 되는 거예요?
Sabre: Hold on, 확인해볼게요.
(며칠 뒤)
Sabre: 이거, 운임을 등록할 때 승객 유형을 제대로 입력 안 해서 검색도 안 되는 거예요. 보이죠? 전부 다 일반 성인으로 등록되어있죠?
L차장: 그러면 BFM 설정값을 바꿔야 되는 거예요?
Sabre: No, No BFM problem. 항공사가 운임을 등록할 때 '외국인 노동자'라는 코드를 기입해야죠.
L차장: ????????? 아니, 중국노선만 항공사 30개가 넘는데, 그 담당자들을 다 설득해서 고치라고요?
이렇게 기능은 존재하지만, 한국시장 업무 관행 상 실제 사용이 불가능한 경우도 있다. 그러면 추가 개발에 들어간다. 혹은 BFM이 아닌 또 다른 API를 붙여야 하는 경우 -BFM프로젝트가 한창 진행되던 중, BFM Advanced API의 존재를 알게 되고 싶은 한숨을 내쉬었다. 또 공부해야 돼...- 그럴수록 새로운 project가 하나 둘 늘어나면서, 그 일들이 또 하나의 삼라만상을 펼쳐냈다. 일의 전체 그림이 그려지지 않고, 지금 위치가 어느 단계인지 알 수 없으니, 밑 빠진 독에 물 붓기, 무작정 사막 위를 걷는 기분이었다. 이슈가 터질 때마다 쉽게 지치고, 또 불만족만 쌓이는 원인이 되었다.
- 3.3 뜻밖의 복병, 한글 운임규정
꽤 많은 시간이 흐른 뒤, BFM으로 Migration 하느냐 마느냐의 관건은 바로 운임규정에 달려있다는 것을 알게 되었다. 항공권 운임규정이란, 해당 운임을 어떤 승객이 사용할 수 있는지 -예를 들면 소아 운임의 기준은 항공사마다 13세, 15세, 16세로 천차만별이며 그 조건은 규정에 명시한다- 항공권 변경과 환불조건은 무엇인지, 해당 운임을 사용할 수 있는 항공편은 무엇인지 등을 정해놓은 규정이다.
이것이 항공운임규정이고, 소비자들은 이 내용의 한글 번역본을 본다.운임규정은 각 항공사가 정하여 ATPCO DB에 등록한다. 주로 영문으로 작성되는데, 항공사별/ 노선별/ 운임 담당자 별 입력하는 스타일이 다 다르다는 사실이 엄청난 복병이었다. 왜냐하면, 이 내용을 전부 한글로 번역해서 제공해야 하기 때문이다.
국내 여행사가 항공권 운임규정을 영문으로 제공하는 것은 있을 수 없는 일이다. 소비자가 그 내용을 알아볼 수 없으니 커뮤니케이션이 불가할 뿐 아니라, 이후 소비자보호법상 문제가 될 수 있기 때문이다. 운임규정 API는 응답을 영문으로만 제공할 수 있으니 -입력 데이터가 영문이기 때문- 규정을 한글로 번역할 다른 방법이 필요했다. 최초에는 규정에 사용되는 단어가 고만고만하니까 다 추려내서 단어 단위로 한글 번역 DB를 만들어 본사에 등록하기로 했다. 그러나, 운임규정을 몇 개 뜯어보니 아래와 같은 문제가 있었다.
Case 1 ▶ '환불 가능'이라는 말을 아래와 같이 창의적으로 표현함
'refundable' , 'can be refund', 'authorize to reissue'...
Case2 ▶ 영어인데 영어인 듯 영어 아닌 느낌
CHD, INF are allowed to RFND at least 14 days before departure
(해석: Child and Infant are allowed to refund at least 14 days before departure)
사람이 데이터를 입력하다 보니 언어 습관에 따라 쓰는 단어가 묘하게 달라졌다. 또한, 운임규정은 완벽한 영어문장으로 표현되지 않는다. DB 상에서는 영문 character 하나하나가 다 돈으로 연결되어 되도록 축약된 말을 사용한다고 한다. 그러한 이유들로 인해, 하나의 정형화된 규정 포맷을 뽑아낼 수가 없었다. BFM Migration의 운명은 결국 운임규정에 따라 좌우되었고, 프로젝트 일정을 전면 수정하여 운임규정이 한글로 완성된 항공사를 우선으로 하나 씩 옮겨가기로 했다.
이 프로젝트 안에서 나는 Sabre HQ와의 커뮤니케이션을 전담했고, 영문으로 이루어지는 대부분의 업무를 맡았다. 덕분에 Sabre HQ가 있는 싱가포르로 출장을 여러 번 다녀왔고, 싱가포르에 있는 직원들을 한국으로 여러 번 데려오기도 했다. 또한, 시스템을 자체 도입하는 여행사에게도 BFM 서비스를 소개하기 위해서 위 모든 내용이 버무려져 있는 영문 매뉴얼을 한국어로 제작하는 일도 했다. 그 밖에도 더 있지만, 할많하않
4. Expedia Korea 항공권 오픈
여전히 이 곰만 보면 가슴 한 구석이 콕콕 아려온다대망의 마지막 과업, Expedia. 앞서 언급한 1번부터 3번까지의 실무들을 몽땅 버무려놓은 집합체가 바로 Expedia 항공서비스 오픈 프로젝트이다. 나는 2016년 7월 Expedia 항공사업 오픈 팀 멤버로 합류하였고, 입사 반년 차 이제 막 구내식당 메뉴에 입맛이 익숙해질 즈음받게 된, 뜻밖의 새로운 과업이었다.
혼란의 소용돌이 속으로 Expedia 업무에서 가장 혼란스러웠던 것은 프로젝트에 involve 된 이해관계자들이 너무나 많다는 점이었다. 크게 나눠보면 5가지 입장 -Sabre HQ/아시아나세이버/익스피디아 코리아/Expedia HQ/아시아나항공- 여기에 Sabre HQ 만 보아도, Global account 담당/development 담당/ 기능별 담당자들을 (shopping·payment·ticketing 등) 다 합하면 최소 20명이 넘는 직원들과 이메일을 핑퐁 해야 했다. 일일이 세어보진 않았지만, Expedia 프로젝트 전체를 둘러싼 이해관계자는 훨-씬 더 많았을 것이다.
그러나, 애석하게도 이러한 관계도를 명확하게 인지한 다음 업무를 시작한 건 아니었다. 그저 낯선 이메일 타래에 내가 갑자기 불쑥 소환되거나, 당장 내일 있을 컨퍼런스콜에 초대되거나, 나도 처음 듣는 한국 여행사 실무에 대해 질문받거나, 갑자기 본사에서 담당자가 한국 출장을 온다고 하거나... 그렇게 한 명 한 명 나의 동료들을 주워모은(?) 것이다. 눈 떠보니 나는 어느새 한국 로컬 시장을 대표하는 직원이 되었다. 한국 직원이라는 이유만으로 커뮤니케이션의 중심에 위치하는 상황이 된 것이다. Hey, Marina. You're the key man.
Expedia 항공사업 오픈 프로젝트는, 풀어말하면 Expedia Korea 웹사이트에 항공권 예약· 발권 서비스를 연동하는 것이다. 국내선과 국제선 두 파트로 나뉘며, 국내선은 아시아나항공 자체 시스템을 연동하는 것이고, 국제선은 Sabre 예약시스템을 연동하는 일이기 때문에 서로 다른 두 개의 과업으로 볼 수 있다.
- 4.1 국내선
Time-out을 잡아라
Expedia에는 엄격한 기준이 있었다. 소비자가 검색 버튼을 딱 클릭했을 때 항공권 요금 리스트가 2초 안에 보여야 한다, 그 이후에 들어오는 데이터는 받지 않는다는 2초 time-out. 그러나 당시 아시아나항공 국내선 시스템은 서버 상황에 따라 2초를 넘는 경우가 훨씬 많았다. 아무리 우리 쪽에서 운임 데이터를 넘겨주어도 Expedia는 그 내용을 볼 수 없다는 뜻이다. 그로 인해 국내선 서비스는 대대적인 시스템 수선작업부터 출발했다. 개발언어를 바꾸고, 프로세스 일부를 병합하거나 뜯어내고, 최후의 방법으로는 프리미엄 API를 사용하는 등.. 이 작업에만 몇 달의 시간을 쏟았다. 그 과정에서 나는 삽질도 많이 했지만... IT시스템의 하드웨어 관련 내용을 심도 있게 공부할 수 있었다.
No-show 환불은 누가 할래?
혹시 휴가 일정이 바뀌거나, 피치 못 할 사정으로 비행기 티켓을 환불(refund)해 본 경험이 있는가? 아마 여행사 콜센터 혹은 카카오톡 고객 서비스를 통해 연락을 취했을 것이다. 국내 여행사들은 refund를 시스템으로 처리하지 않고, 직원이 직접 매뉴얼로 작업하기 때문이다 -국내선 항공권은 당일 취소에 수수료가 붙지 않아 시스템으로 처리하는 경우도 있지만, No-show 환불의 경우에는, 티켓이 이미 소멸된 상태이므로 직원이 매뉴얼로 작업해야 한다-. 그러나 Expedia 측은 회사 미션이 One-stop 서비스라며 반드시 웹사이트 내부에 refund 버튼이 존재해야 함을 강조했다. 지금까지 국내에는 refund 기능을 온라인으로 사용하지 않았기 때문에 이 기능 역시 바닥부터 새로 시작하는 개발 프로젝트로 이어졌다. 특정 서비스를 API 형태로 개발하고, 환불 페널티가 제대로 계산되는지 확인하고, 티켓에는 환불 이력이 기록되는지 등등.. 끝없는 test의 반복.
홍길동은 안 되고, Hong Gil Dong은 된다?
R: Marina, 한국인이 김포공항에서 출입국 심사할 때, 티켓에 이름이 영어로 쓰여 있으면 문제가 될까?
나: 엥? 한국인은 당연히 한국 이름으로 수속하지. 제주도 갈 때 여권을 들고 가진 않아, 주민등록증 그러니까 Korean ID가 따로 있어.
R: I know. 그런데 익스피디아 웹사이트에는 한글을 타이핑할 수 없어. 그러니까 한국인이 영문 이름으로 출입국 할 수 있는지 알아봐 줘.
나: ????????
우리에겐 'Expedia 웹사이트를 변경해서는 안 된다'라는 불문율이 있었다. 문제는 항공권을 예약할 때 이름을 한글로 입력할 수 없다는 것이었는데, 국제선은 기본이 영문이니 그렇다 쳐도 국내선에 영문 이름을 사용하는 것은 어색한 일이었다. 그래서 한국인이 제주도 가는 비행기를 영문 이름으로 탑승하는 케이스가 가능한지를 알아보라는 특명이 내려졌다. 김포공항 고객센터에 전화했는데, 자기네 소관이 아니니 출입국사무소로 연락해 보라고 하고, 출입국사무소에서는 도대체 무슨 일이냐며 의심 가득한 추궁(?)을 받는 긴긴 통화가 이어졌다.
낯설고도 낯선 Blue screen
아무리 Expedia라 하더라도, 모든 걸 온라인 시스템만으로 소화할 수는 없다. 반드시 사람 손을 타야만 하는 문제가 꼭 발생하기 때문이다. 물론, Expedia에도 직원이 근무하는 고객센터가 존재하고 그 채널을 통해서 한국 국내선 항공권 관련 이슈를 해결할 수 있다. 다만, 직원들의 작업도구인 blue screen을 Sabre HQ 직원들에게 이해시키는 일이 관건이었다.
앞에서 국내선 시스템은 Sabre가 아닌, 아시아나항공 시스템을 직접 사용한다고 언급했다. 아시아나세이버는 여행사 직원들의 편의를 위해서 Sabre Workspace 제품 안에 '국내선 tab'을 추가하였는데, 이 모양이 Sabre시스템과 너무나도 유사해 보인다는 것이 핵심이었다. 정확하게 말하면 '국내선 tab'은 한국 로컬에만 존재하는 기능인 것이다. 기술적으로 Expedia에 내려줄 수 없는 기능이었다.
저 작은 tab을 이해하기란 하늘의 별따기Sabre HQ 직원들은 도무지 이해할 수 없었다. 우리 product 안에 저렇게 버젓이 있는데 뭐가 다르다는 거지? 그냥 설치 파일을 Expedia 직원들한테 전달해주면 되는 거 아니야? 아니, 그러면 한국은 저걸 어떻게 붙인 거야? 대체 저 tab은 정체가 뭐야?? 이 상황을 이해시키는데만 한 달의 시간이 걸렸다.
- 4.2 국제선
국내카드와 해외카드, 달라도 너무 달라
Expedia 국제선 파트 업무는 처음부터 끝까지 '결제'라는 단어로 수렴한다. 특히, Expedia 웹사이트에는 해외교포나 외국인 고객도 큰 비중을 차지하기 때문에 국내 결제뿐 아니라 해외 결제까지 핸들링 가능한 시스템이 필요했다. 그래서 결제시스템 관련 요건도 보다 복잡하게 얽혀있었다.
먼저, 본인인증에 대해 이야기해본다. 국내카드와 해외카드는 본인인증 시 필요한 정보가 다르다. 국내카드는 카드번호+유효기간+생년월일+비밀번호 앞 2자리가 필요한 반면, 해외카드는 훨씬 심플하다. 카드번호+유효기간+CVC코드로 인증을 한다. 앞에서 이야기했던 불문율을 떠올려보자.
'Expedia 웹사이트를 변경해서는 안 된다'
Expedia 웹사이트는 이미 해외카드를 기준으로 UI가 만들어져 있다. 이때, 국내카드로 결제를 하려면 어딘가에 생년월일과 비밀번호 앞 2자리를 입력할 수 있는 빈칸이 필요한데 UI를 바꿀 순 없단다. 처음에는 해외카드만 받자는 이야기도 있었지만, 고객들의 컴플레인이 뻔하게 예상되었다. 결국 VAN사와 별도 미팅을 통해서 이 문제를 해결할 수 있는 힌트를 얻었고, 역시나 수 십 번의 이메일 핑퐁 끝에 이슈를 해결했다.
(좌) 국내카드 인증 화면 (우) 해외카드 인증 화면해외결제수수료? 그게 뭔데?
결제시스템 개발 완료 후에 테스트를 하던 때이다. VISA, Master 카드로 해외 결제 테스트를 하는데, 본사에서는 금액이 다르게 청구되었다며 엄청난 시스템 오류라고 방방 뛰었다. 확인해보니 항공권 요금에 해외결제수수료 1.4%가 추가된 금액으로 테스트 결과는 정상이었다. 해외에는 '해외결제수수료'라는 개념이 없어서 오류라고 인지한 것이었다.
나: Samsung card가 해외 결제를 하려면 VISA라는 브랜드와 제휴를 해야 하는데 이때 수수료가 발생해. 그걸 해외결제수수료라고 하는 거야.
R: I can't understand. 이 회사에서 10년 넘게 일 하면서 그런 개념 처음 들어봐, 진짜 오류 아니야?
나: 아니야 아니야. 봐봐, 이거 카드회사에서 결제할 때 내 휴대폰으로 SMS 문자 준 건데,
(화면 캡처해서 보여줌) 지난달에 면세점에서 VISA로 결제한 거야. 밑에 해외결제수수료 1.4% 보여?
R: Um... 이거 정말 중요한 문제야. 그럼 VISA, Master, 다이너스, Amex 종류 별로 다 테스트해줘.
나: What???????
본사 직원에게 이 개념을 이해시키는 데에만 또 한 두 달이 걸렸다. 결제 관련 사고가 발생하면 큰 문제로 이어지니 민감한 이슈이기도 했고, 본사 쪽에서도 100% 납득한 이후에 컨펌하고자 더 까다롭게 질문했던 것이다.
승인번호 8자리
국내카드와 해외카드는 승인번호 자리 수마저 다르다. 국내카드는 8자리, 해외카드는 6자리이다. (알고 보니 Union Pay는 5자리던가...?) 이 승인번호가 중요한 이유는 항공권 정산 프로세스와 관련이 있다.
예를 들어, 한 여행사가 인천-두바이행 에미리트 항공권을 10장 팔았다고 가정해보자. 여행사는 손님에게 항공권 금액을 원화 KRW로 받았다. 그런데 항공사는 사우디 통화 리얄 Riyal로 받기를 원한다. 이럴 때 정산을 어떻게 할까? 게다가 여행사가 거래하는 항공사만 100곳이 넘는다면? 그 여행사는 전 세계 통화를 다루어야 할까?
이렇게 난감한 상황을 미연에 방지할 수 있도록, 항공사와 여행사 간 정산은 BSP를 통해서 이루어진다.
BSP란, 국제항공운송협회 (IATA)에서 시행하는 항공여객판매대금 정산제도. 항공사와 대리점 (여행사) 간의 거래에서 발생하는 국제선 항공 여객운임을 다자간 개별적으로 직접 결제하는 방식 대신, 정산 은행을 통하여 일괄 정산토록 한다.
승인번호는 BSP와 맺은 일종의 약속과 같다. 따라서 승인번호 자릿수, 기입된 위치는 전 세계적으로 통일되어있다. 일반 승객은 볼 수 없지만, 항공사 직원이나 여행사 직원들은 손님의 티켓 어딘가에 기입되어있는 승인번호를 확인할 수 있다. BSP도 역시 이 번호를 보고 정산을 진행하거나, 항공사에 환불을 요청하거나, 페널티를 부과하는 것이다. 승인번호가 다르거나, 금액이 다르면 정산도 환불도 그 어떤 작업도 진행되지 않는다.
문제의 요지는 국내카드 승인번호가 8자리인 반면, 티켓 상 기입할 수 있는 숫자는 6자리뿐이라는 것이다. 이 8자리 숫자를 6자리 숫자로 변경해주는 알고리즘이 중간에 존재해야 했다. 변경된 6자리는 proxy code라는 별도의 명칭으로 부르며, 6자리를 8자리 승인번호로 되돌리는 작업도 필요했다. 그 모든 시스템이 문제없이 돌아가야 프로젝트를 비로소 Expedia 웹사이트를 오픈할 수 있었다.
일을 하긴 하는데, 내가 무슨 일을 하는지 모르겠어-
입사하고 내가 가장 많이 했던 말이다. 아마 이 긴 글을 다 읽긴 읽었는데.. 뭘 읽었는지 1도 모르겠다고 느낀 독자가 있다면, 그게 3년 전의 내 모습이다. 지금은 Job Description을 나름 체계적으로 구분해서 설명할 수 있지만, 당시에는 그 전말을 찾아내기까지 너무나 오랜 시간이 걸렸고, 아주 지난한 프로세스를 돌았다.
그래서 이번 <아시아나세이버에서의 2년 6개월> 기록을 마친 뒤 아주 아주 뿌듯한 마음이 일었다. 회사에서 하는 일들이 도통 손에 잡히지 않아 전전긍긍하던 신입시절을 지나, 이제는 그 모든 일들에 번호를 매겨가며 설명할 수 있다니. 이 얼마나 감개무량한 성장인가?
이 기록을 통해서 새삼 느낀 것은, 첫 사회인으로 내가 맡았던 업무는 상상 그 이상으로 복잡한 일이었다는 것, 모든 업무 내용과 프로세스를 이해하는 데에 무려 1년 이상의 시간이 걸렸는데, 사실은 그 속도가 빠른 것이었으며, 앞으로 어떤 일을 하게 되더라도 웬만한 일에 대해서는 어렵다거나, 복잡하다거나, 도무지 내가 해낼 수 없을 것 같다는 생각이 들지 않겠다는 것이었다. 2년 6개월 사이에 멧집이 그만큼 단단해진 것이리라.
'나는 도대체 왜 이렇게까지 괴롭게 일을 배웠는가?'
일머리가 없다며 스스로를 자책하게 만든 어떤 과업은, 사실 그 과업이 만들어진 맥락과 놓여있는 환경, 그리고 계열사 간 역학관계에 의해 어느 누가 맡아서 하더라도 괴로워질 수밖에 없었던 일이다. 이때, 그 상황을 빠져나오는 방법은 둘 중 하나이다. -포기하거나 극복하거나- 다만, 과업을 기어코 정복해내고 잘하게 된 사람만이 가질 수 있는 발언권이 있고, 그런 사람이 꺼낸 말만이 비로소 괴로운 상황을 바꿀 수 있는 힘을 갖는다.
그래서 나는 괴롭게 배우고, 시끄럽게 항의하기로 했다. 그게 신입시절을 이겨낸 내 나름의 버팀목이었다.
또 한 가지, 그렇게 괴로운 시간을 지날 수 있었던 이유는, 내가 자라는 모습을 옆에서 묵묵히 바라봐준 동료들 덕분이었다. 도무지 이해되지 않는 과업을 받아 입이 삐죽 나와있을 때, 납득할 수 없는 지시사항에 얼굴이 벌겋게 익었을 때, 나를 조용히 불러내서 다독여주던 선배들, 말없이 달달한 것들을 손에 쥐어주던 동기들. 무엇보다 막내의 치기 어린 의견에 시간을 기꺼이 내어주며 어떤 식으로든 응답해주는 상사를 만난 것은 지금 생각해도 정말 큰 행운이다.
tip. 어디선가 많이 본 회의 풍경인 것 같아 참고 삼아 덧붙인다. 긴 글이 싫다면, 영상만 보아도 ok :)
https://youtu.be/BKorP55Aqvg
