03 AsianaSabre, 2년 6개월의 기록(1)
회사 밖에서 다시 쓰는 Job Description
Job Description, 직무내용 설명서는 직무분석에 따라 과업을 수행하는데 필요한 설비˙기능˙자격˙조건에 대해 분류하고 기재한 문서이다. JD는 대개 채용을 위해 지원자들에게 해당 업무내용을 소개할 때나, 업무인계를 목적으로 인수인계서를 제작할 때 작성한다.
나는 무려 2개월 넘게 업무 인수인계서를 작성하고, 후임자를 위한 일대일 교육을 진행했다. 내 시간을 기꺼이 떼어주기로 했다. 그 이유는, 신입시절 내가 아무것도 모른 채로 통과해야만 했던 버티기의 시간, 그 외로운 일을 후임자가 되풀이하지 않았으면 하고 바랐기 때문이다. 후임자를 교육하면서 불쑥 억울하기도, 섭섭하기도, 또 서럽기도 한 감정이 떠올랐는데, 그때 이런 생각을 했다.
'아, 왜 나는 단 한 번도 나를 위한 Job Description를 쓰지 않았을까?'
쉴 틈 없이 밀려오는 업무를 쳐내느라 그런 걸 정리할 여유가 없었고,
시간이 지나니 이미 업무가 손에 익어서 그런 작업이 필요 없었고,
참고할만한 좋은 사례를 주변에서 포착하지 못했다는, 여러 가지 이유가 있었을 것이다.
그래서 이번에는 오로지 나의, 나에 의한, 나만을 위한 Job Description을 완성하기로 마음먹었다. 촘촘히 건져 올린 옛 업무들을 다 펼쳐놓고 바라보는 일은 뜻밖에도 재미있었다. 회사라는 바구니 속에서라면 절대 거들떠보기도 싫었던 업무를 향해 여유로운 마음이 일었다. 한 걸음 떨어지자, 내 업무를 둘러싼 다양한 맥락들을 이해할 수 있었다. 또 내가 업무를 진행하면서 일으킨 공과 과를 똑바로 보고, 직무내용을 객관적으로 서술할 수 있었다. 이것은 Next step을 위해 내 역량을 정리하는 차원에서 아주 중요한 작업이 되었다. (또 모르지 뭐, 이 글을 읽고, 같이 일해보자는 제안이 들어올지?)
GDS 산업을 둘러싼 배경
AsianaSabre는 항공권 예약˙발권 시스템을 개발하고 여행사를 위한 IT solution을 제공하는 회사이다. 항공산업 초창기 시절, 비행 스케줄도 해외여행이 가능한 인구도 매우 적었다. 따라서 모든 항공권 예약˙발권˙정산 프로세스를 사람이 직접, 손으로 거뜬히 소화할 수 있었다. 하지만 지금은 어떤가? 2016년 기준 전 세계에 등록된 항공사만 400개가 넘고, 운항노선을 다 따지면 몇십 만개에 달한다. 항공산업의 판이 커지면서 더 이상 사람 손으로 일을 해결한다는 것이 불가능해지자, Computer system인 GDS(Global Distribution System)가 도입되었다. GDS는 현재 전 세계 항공사 Database와 연결되어 비행노선, 스케줄, 항공운임과 좌석 상황을 실시간으로 전달한다. 언제 어디서 누가 항공권을 구매한다고 해도 이 GDS를 거쳐야만 가능해진 것이다.
과거 여행사 풍경. 뒷 벽면에 부착된 칠판 위로 항공 스케줄이 적혀있다. 직원이 직접 먹지에 출·도착지와 항공요금을 작성하여 티켓을 만들어주던 시절.GDS를 취급하는 회사는 전 세계에 단 4곳뿐이다-Sabre, Amadeus, Galileo, Worldspan-. 그리고 우리나라에는 크게 대한항공 계열의 토파스(Topas)와 아시아나항공 계열의 세이버(AsianaSabre)가 항공시스템 시장을 과점하고 있다. 국적항공사가 GDS를 품은 이유는 간단하다. 항공사에서 항공권을 판매하려면 무조건 GDS를 거쳐야 하는데, 예약·발권·변경·취소 그 모든 과정에서 수수료가 발생한다. 항공사는 조금이라도 원가를 줄여야 하는 입장이기 때문에, 합작투자 형태로라도 GDS와 한 식구가 된다면 수익을 셰어 하는 과정에서 원가절감이 가능한 것이다.
IT+영어+항공업무, 원펀치 쓰리강냉이 샷
AsianaSabre는 크게 두 종류의 시스템을 다룬다. 하나는 여행사 카운터 직원이 바라보는 시스템(BlueScreen), 또 하나는 고객이 PC나 모바일을 통해서 바라보는 시스템(IBE, Internet Booking Engine).
나는 IBE 솔루션 기획 및 운영을 담당했고, Sabre HQ와 직접 소통하면서 한국시장에 필요한 Resource를 끌어오는 코디네이터 역할을 수행했다. 항공업무(잘 모르는 것)를 IT(더 모르는 것)로 풀어내야 하는데, 그걸 또 영어(잘 못하는 것)로 소통해야 하는 원펀치 쓰리강냉이 샷의 업무 삼중고가 시작된 것이다.
이하에는 업무를 조금 더 세분화하여 적절한 예시와 함께 적어본다.
1. 아시아나 국내선 서비스 운영
아시아나항공 국내선 시스템을 여행사에 연동하고, 항공권 예약과 발권이 원활하게 이루어질 수 있도록 관리하며, 유관부서와의 협의를 이끌어내는 역할. 국내선 서비스를 이야기하기에 앞서 짚어야 할 특이점이 있다. 국내선 항공권은 앞에서 말한 GDS를 거치지 않는다. (대한민국 국내선 노선은 전체 항공권 시장과 비교하면 큰 portion을 차지하는 것도 아니고, 항공사 자체 시스템으로도 충분히 핸들링할 수 있으며, 원체 국내선 요금이 저렴하여 GDS에 수수료로 떼 줄 돈도 없기 때문이다.) 대신 항공사가 자체적으로 사용하는 시스템 일부 기능(API)을 여행사에 열어주고, API에 접속할 수 있는 루트를 깔아주는 개념으로 운영된다. 다만, 여행사 직원들의 편의를 돕기 위해 AsianaSabre bluescreen에는 국내선 탭을 별도로 개발하여 마치 하나의 GDS에서 운영되는 것처럼 시스템을 연동해놓았다. 알고 보니, 이러한 개념은 한국시장에만 존재하는 것으로 이후 Sabre 본사 직원들을 크나 큰 혼란의 도가니로 몰아넣는 주범이 된다.
여행사 직원은 위 화면만 보고도 국제선-국내선을 다 핸들링할 수 있다.- 1.1 국내선 항공료˙유류할증료 DB 운영 ★★
: 아시아나항공에서 국내선 신규 노선을 개발하거나(ex. 무안-제주노선), 유류할증료가 변경되거나, 시즌 별 특가가 출시되거나(ex. 6월 보훈의 달 국가유공자 특가), 모든 항공권 운임과 관련된 변경사항이 발생할 때마다 이를 유관부서에 알리고 DB서버에 반영하는 작업을 진행한다.
위에서 언급한 대로, 국내선 서비스는 항공사 시스템을 직접 끌어오는 것이다. 그래서 중앙시스템 요금 DB는 아시아나항공이, 여행사 웹사이트 화면에 뿌려지는 요금 DB는 아시아나세이버가 관리한다. 문제는 두 개의 DB를 각각 다른 부서에서 다루다 보니, 웹사이트에서 보이는 요금이 일치하지 않는 경우가 발생한다는 것이었다.
인터파크에서 김포-제주 아시아나항공 운임을 38,000원으로 조회했는데, 카드결제를 하려고 보니 45,000원으로 바뀌어 보인다. 메인 페이지 요금은 세이버 DB에서, 운임 계산은 항공사 DB에서 진행되기 때문이다. 운임이 저렴해지면 (손님에게는) 문제가 없지만, 운임이 비싸지면 여행사로 컴플레인이 어마무시하게 접수된다. 낚시요금 아니냐, 사기 치는 거 아니냐- 사기 치는 거 아니고, 그저 시스템 오류이니 여행사에 접수하면 된다...
처음에는 우리 쪽 협력업체 잘못인 줄 알고 개발 담당자를 엄청 쪼았다. 제대로 작업한 거 맞아요? 숫자 잘못 보신 거 아니죠? 원인을 추적해보니, 아시아나 항공 내부 커뮤니케이션 문제였다. 나에게 요금변경을 요청한 담당자는 영업팀 소속이고, 항공시스템 DB 담당자는 운임팀 소속이었는데, 영업팀 담당자가 당사 운임팀을 누락한 채 내 쪽에만 DB 업데이트를 요청한 것이다. 이러한 사고가 발생한 이유는, 아시아나항공 쪽 인사이동이 잦아 인수인계가 제대로 되지 않았기 때문이었고, 이 후로 인수인계가 있을 때마다 같은 오류가 반복되어 나중에는 내가 거꾸로 담당자에게 '운임팀에도 공지하셔야 돼요'라며 상대편의 업무까지 챙기게 되었다.
대기업은 규모가 큰 조직이다. 따라서 이런저런 부서가 존재하고, 그에 따라 직무내용이 세분화되어 잘게 쪼개져있다. 이러한 조직에는 역할분담이 분명해서 내 업무가 무엇인지 잘 알 수 있다는 장점도 있지만, 작은 일을 처리할 때조차 어느 부서의 누구 담당자를 찾아야 하는지 검색 비용이 상당하다는 단점도 있었다. 회사 다니면서 들었던 명언 오브 명언, '그 일을 어느 부서 누가 담당하는지만 알아도 업무 90%는 정복한 거야' 여전히 가슴속에 새겨져 있다.
- 1.2 오류 발생 Log데이터 분석 ★★
: 항공권을 시스템으로 발권하다 보면 오류가 왕왕 발생한다. 항공권을 구성하는 요소가 매우 복잡하게 얽혀있어 시스템이 커버할 수 없는 영역도 있고, 아무래도 사람이 관여하는 것보다 시스템은 디테일이 떨어질 수밖에 없다. (소비자가 21세기를 살게 하려면, 직원들은 보이지 않는 곳에서 20세기처럼 일해야 한다) 오류가 발생하면 시스템 운영자인 내가 출동한다. 오류를 해결하는 프로세스이다. 먼저, 여행사 개발자가 오류 Log데이터를 이메일로 접수하고, 나는 그 내용을 협력사에 의뢰해 오류 상황을 분석한다. 오류 원인에 따라 항공 쪽 유관부서와 협의하여 그때그때 필요한 조치를 취하는(여행사 시스템을 수정하도록 알려주거나, 운임 보상을 해주거나, 비행기 좌석을 열어주는 등) 코디네이터인 셈이다.
소아 승객인데 성인요금으로 항공권이 발권되었어요
제주도민이 제주도 노선을 탑승하는데, 도민 할인이 적용되지 않았어요
운임을 선택해서 예약을 진행하려고 보니 '존재하지 않는 운임'이라고 경고창이 뜨네요?
여행사 홈페이지에서 환불을 진행했는데 '완료되었습니다'라는 팝업창만 뜨고 실제로 환불이 되지 않았어요!
반년쯤 지나자, 위 케이스처럼 자주 발생하는 오류들에 대해서는 개발사에 문의하지 않아도 스스로 코드를 읽어내는 경지에 도달했다. 개발자는 아니어도, 코드들을 자주 접하다 보니 슥-훑어보면 원인을 대충 짚어낼 수 있을 정도로 능력치가 계발된 것이다. 대개는 1.1의 상황과 관련이 있었고, 모든 회사 일에서 가장 중요한 것은 바로 커뮤니케이션이며, 이것만 잘해도 업무의 절반은 줄어들겠구나-라는 교훈을 얻었다.
내가 태운 비행기를 타고 제주도에 간 사람이 과연 몇 명쯤 될까- 1.3 신규 여행사 API resource 제공 ★
: 새로 여행사를 창업하거나, 웹사이트 제작을 직접 하는 고객사에는 국내선 API resource를 문서로 전달하여 시스템이 잘 구동될 수 있도록 안내하는 일을 했다. 개발자에게 API 문서를 제공하고, ID/PW를 발급해주면 그 뒤는 척척해내는 여행사는 완전 땡큐! 하지만 일은 언제나 거기서 끝나지 않는다. 여행사에 소속된 개발자가 항공업무를 잘 모르는 경우도 많다. 그때는 어린아이에게 한글을 ㄱ,ㄴ,ㄷ,ㄹ 부터 가르치는 심정으로 한 땀 한 땀 설명을 이어갔는데- API는 이런 순서로 연동하고, 항공 용어는 이런 뜻이에요, 블라블라~- 나중에는 해당 여행사 국내선 실무자와 직접 논의하시라고 토스했다.
2. 국제선 서비스 기획 및 운영
혹시 항공권을 인터넷으로 구매할 때, 이런 인상을 받은 적 있는가? 여행사 웹사이트가 참 묘하게 다 비슷하군.
국내 여행사 웹사이트 대다수는 2-3군데 IT 개발사가 전담으로 맡아 제작했다고 볼 수 있다. 따라서 하나투어를 보든, 롯데관광을 보든, KRT를 보든, UI나 메뉴 구성이 거기서 거기다라는 인상을 받게 된다.
과거에는 여행사 규모가 영세하여 내부에 IT개발팀을 갖출 여력이 없었다고 한다. 게다가, 여행사 웹사이트는 일반적인 홈페이지 제작과 매우 다르다. 항공권 구성이나 운임, Tax 개념 등 항공산업을 구조적으로 이해할 수 있는 지식이 밑바탕되어야 이를 시스템으로 구현해낼 수 있다. 그러려면 여행사 업무를 잘 아는 IT 개발자에게 일감을 의뢰해야 하는데, 그런 사람이 업계에 몇 명 없거니와, 개발업체를 발굴하는 일 자체가 쉽지 않아 소수의 개발사로 작업이 몰리게 되었다는 사연이다.(특히, 항공권 정산·통계·회계시스템은 진입장벽이 훨씬 높아서, 업계에서는 우스갯소리로 며느리만 아는 기술이라고도 부른다)
머지않아 여행산업 규모가 크게 성장했고, 대자본을 축적하여 사내 IT팀을 갖춘 여행사들이 속속 등장한다. 더불어, 여행사들이 글로벌 시장에 진출함에 따라 국가별 로컬 비즈니스 관행에 맞는 시스템을 이것저것 더 필요로 하게 되었고, 그러다 보니 여행사 입맛에 맞게 주도적으로 시스템을 구현하고자 하는 니즈가 생겨난다. 이에 따라, 내가 담당한 국제선 서비스 업무 역시 '위탁개발'과 '자체개발' 두 가지 대상을 구분하여 성격이 달라지게 되었다. 아래에는 그 내용을 설명하고자 한다.
-2.1 IBE 솔루션 기획 및 운영 (위탁개발) ★★
: IBE(Internet Booking Engine)는 아시아나세이버가 여행사의 온라인 항공권 판매를 편리하게 진행할 수 있도록 개발한 시스템이다. 90년대 초반, 인터넷 기업들이 등장하면서 이 IBE 시스템도 생겨났고 10년이 넘게 히스토리가 차곡차곡 쌓인다. 시스템 하나를 10년 세월에 걸쳐 수정하고, 다듬고, 때론 뒤집어엎기도 했던 역사가 촘촘해지면서 복잡도도 딱 10배만큼 커졌다. 입사 첫 해 3월 한 달간 OJT교육을 받을 때, 이 IBE 시스템 기본 내용을 공부하면서 난생처음 마주하는 유형의 복잡함에 매우 당황했다. '내가 그래도 인 서울 4년제 대학을 졸업한 사람인데, 이걸 이해 못 한단 말이야?' 스스로를 자책했다. 하지만 지나고 보니, 아시아나세이버 내부에도 IBE시스템 전체를 마스터한 사람이 오직 한 두 명뿐이라는 것을 알게 되었다. 누가 담당해도 어려웠을 업무라는 것을 알고 조금 안심했다. 그러한 이유로, IBE에 대해서는 내가 기여할 수 있는 영역이 극히 적었음을 고백한다.
<담당업무>
여행사가 특가운임을 open 했는데, 웹사이트에 노출되지 않는 경우 → 보통 유선으로 문의를 접수한다
→ 담당자에게 토스한다
항공권 발권 오류 보상처리, 이를테면 인천-LA 운임이 원래 130만 원인데, 시스템 오류로 110만 원으로 발권되었다. 이때, 시스템 log데이터를 분석해 잘잘못을 판단한 뒤 차액인 20만 원을 보상한다. 보상처리에 필요한 품의를 상신하고 전표를 작성하고 여행사에 입금 처리하는 일을 담당한다.
자사 계열 웹사이트와 타사 계열(대한항공 토파스) 웹사이트를 비교하고, 보완할만한 기능이 있다면 Sabre HQ에 요청해 연관되는 API resource를 받아 스터디한다.
(주기적으로 시스템 기능 개선이 이루어져야 타사 기능과 비교해 뒤떨어지지 않는다)
- 2.2 SWS (Sabre Web Service)의 처음과 끝 (자체개발) ★★★★
: 항공권을 예약˙발권˙변경˙환불하는 모든 프로세스를 온라인 상에 구현하려면 Sabre API가 필수적이다. SWS업무는 API 사용계약을 맺고 온라인 시스템을 자체 개발하려는 여행사에게 1) Test key를 발급하고
2) API resource 사용법을 알려주며 3) 기본적인 개발 가이드를 제공하는 것으로 요약된다. 주로 여행사 IT 개발자들과 커뮤니케이션하며 시스템 A to Z를 코디하는 역할이었다. (2.1은 SWS를 이용해서 아시아나 세이버가 여행사 대신 IBE라는 패키지 서비스를 만들어낸 것이고, 2.2는 조각조각 나뉜 모듈단위 기능을 말한다.)
SWS는 나에게 특히 아픈 손가락과 같다. 처음부터 끝까지 오롯이 나 혼자 담당한 업무로서(정/부 모두 김가현, back-up 해주는 사람 x), 내 잘못=회사 잘못으로 비쳐 압박감이 상당한 업무였고, 나에게 1차 퇴사 욕구를 던져준 막막한 과제였기 때문이다. SWS는 심지어 회사 내에서도 3년 넘게 공석인 업무였는데, 내가 입사함과 동시에 존재감을 드러내며, 처음부터 끝까지 나의 피땀 눈물로 일어선 서비스라고 할 수 있다.(그만큼 웹사이트를 자체개발한 여행사가 적었다는 말이다)
- Sabre API에 대한 이해
- 항공권에 대한 구조화된 지식
- 웹 프로그래밍 스킬
SWS를 제대로 이해하고 다루기 위해서는 위 세 가지 선행 스킬이 있어야 한다 -뭘 잘 몰랐을 때에는 문과생이 IT업무를 맡아 고통받는다고 생각했는데, 사실 셋 다 몰라서 발생한 총체적 난국이었다-. 무엇 하나 손에 들고 있는 스킬이 없는 상태에서 정말 맨 땅에 헤딩하듯 SWS를 공부하기 시작했다. 고통스럽게 꾸역꾸역 develop 한 만큼, 어느새 눈 감고도 시스템을 다룰 정도로 손에 익었을 때에는 그 뿌듯함이 지구를 뿌술 정도였다.
- 2.2.1 기본 매뉴얼 제작
의외로 여행업계에 꽤 많은 개발자들은 항공권에 대한 실무지식이 없었다. 처음에는 내 역할을 IT스러운(?) 어떤 것이라고 스스로 정의하고, API Test key를 발급해주거나, Sabre Dev Studio라는 API Resource 모음 웹사이트를 알려주는 기계적인 응대한 반복 했다- 어쩌면 개발자에게는, 'I need an apple'이라는 문장을 쓰고 싶다고 문의했는데, 한영사전을 던져주고 원하는 걸 알아서 찾아보라고 응답한 불친절한 담당 자였을지 모른다-.
사실 그들이 원했던 대답은 API로 원하는 기능을 구현하려면, 각 API를 어떤 순서로 연동해야 하는지, Request 전문은 어떻게 작성해야 하는지, 몇몇 오류 응답을 해결하려면 Request를 어떻게 수정해야 하는지였다는 것을 몇 개월 후에 알게 되었다. 그걸 깨닫고 SWS를 이해하고 주요 내용을 정리하는 작업에만 1년 반이란 시간이 걸렸다.
이를테면, 성인 한 명의 항공권을 발권하려면 아래와 같은 API를 정해진 순서대로 연동해야 한다.
SessionCreateRQ
AirSchedulesAndAvailabilityRQ
EnhancedAirBookRQ
PassengerDetailsRQ
.
.
DesignatePrinterLLSRQ
TravelItineraryReadRQ
AirTicketLLSRQ
여기에다가 좌석을 지정하거나, 특별식을 주문하거나, 이름을 변경하거나, 마일리지를 적립하는 등 작업내용이 추가되면 필요한 API도 훨씬 더 많아지고 구성도 복잡해진다. 그걸 이해하고 응대하려면 어떤 API가 무슨 기능을 하는지 알고 있고, 실무는 어떤 순서대로 진행되며, 그에 맞는 Request-Response를 분석하는 방법까지 이해해야 나도 상대방에게도 설명해줄 수 있다.
처음 SWS업무를 시작할 때에는 담당 여행사가 1-2곳뿐이었는데, 그 수가 늘어나자 한 건 한건 문의 응대를 하는 일이 버거워졌다. 문의 내용도 천차만별이었다. 그래서 한 번은 마음을 크게 먹고 지난 1년 치 이메일을 샅샅이 훑어서 정리하는 작업을 시작했다. 기본 매뉴얼과 자주 묻는 케이스를 모아두니 응대가 한결 쉬워졌다.
- 2.2.2 API 접속 계정관리
잘 만든 API하나, 부동산 열 채 안 부럽다? API 하나하나가 다 돈과 연결되어있다. 마치 부동산 보증금과 월세처럼, API를 사용하려면 최초 License fee를 목돈으로 지불하고 매 달 사용료도 내야 한다.
나는 여행사 계약조건에 따라 API 접속 권한을 부여하거나 할당된 Transaction 이상으로 호출하는 여행사는 없는지 관리하는 역할도 했다. 관리는 계정(여행사 ID/PW) 단위로 이루어진다. 계정 별로 접속 가능한 API도 다르고, 조회할 수 있는 데이터도 다르며, Transaction(사용량)도 다르다. 이를 관리하고, Sabre HQ 요금정책이 변경되면 그에 맞춰 사용료도 변경하고 여행사와 계약조건도 수정하는 일을 했다.
- 2.2.3 API 기능분석
앞에서 나열한 SessionCreateRQ, AirSchedulesAndAvailabilityRQ, EnhancedAirBookRQ들은 SWS API의 이름들이다. 이름이 다르다는 건 곧 처리하는 기능이 다르다는 뜻이다. Sabre에는 약 300 여개에 달하는 API가 존재하며, 지금도 한 달에도 몇 건씩 새로운 API가 추가된다.
이를 빠른 속도로 정확하게 따라잡는 일이 중요하다. Sabre HQ에서는 주기적으로 newletter를 발송하는데, 그 안에 API 업데이트가 포함되며, 해당 API가 처리하는 내용과 보완이 필요한 부분, 어느 국가에서 사용할 수 있고, 정식 오픈 날짜는 언제인지, 서비스가 종료되는 API는 무엇인지 등 각종 내용이 적혀있다. 이 정보들을 놓치지 않고 숙지한 뒤, 한국시장에 적용할 수 있는 것들을 잘 골라내서 키워야(?)한다.
비인간적으로 보이던 API test 화면에도 1년쯤 지나니 적응되더라항공권 실무도 모르고, 웹 프로그래밍도 모르고, 게다가 영어도 낯설어 뭐 하나 쉬운 일이 없을 때에는 '내가 여기 왜 앉아있나' 자괴감만 들었다. 백과사전 급으로 방대한 자료 속에서 API 하나 찾는 데에만 4-5일이 걸렸다. 다 찾아놓고도 테스트를 하지 못해 여행사 개발자에게 아직 찾는 중이라고 둘러댈 때도 있었다. 1년쯤 지나자, 이제는 뭘 물어보기도 전에 '혹시 이거 찾으시던 거 아니에요?'라며 선수를 칠(?) 정도로 스킬업이 되었다.
내 월급 값을 해낸다는 뿌듯함과 함께 등줄기가 짜릿한 순간이었다.
뜻밖에 반전은 여기까지 내가 맡은 업무 중 가장 쉬운 세 가지를 나열했다는 것이다.
진짜 지옥문은 다음 글에 이어진다, To be continued...
