여객기의 좌석 아래, 화물칸이 있다
“고객의 여행”에서 “화물 운송”으로 시선 옮기기
에어프레미아의 항공기는 약 300여명의 승객과 더불어, 각종 업체에서 보내는 해외배송 화물을 함께 실어 나른다. 이 화물칸에는 내가 주문한 직구템이 있을 수도 있고, 우리나라에서 수출하는 해산물, 전자제품도 실린다. (심지어 살아 있는 동물도 화물의 한 종류로 실린다.) 탑승객들이 모두 탑승하고 그들의 짐과 예약된 화물까지 다 실리면 항공기의 문이 닫히고 비행이 시작된다.
최근 여객 비중 못지않게 화물 사업의 매출 비중이 빠르게 커지면서 화물 역시 운영 효율화와 디지털 전환의 필요성이 커졌기에, “고객의 여행”에 집중해왔던 랩스 내에 화물 TF가 결성되었다. 랩스는 여객 판매 시스템을 중심으로 홈페이지/앱을 통한 항공권 예매, 온라인 체크인 등 B2C 서비스 중심의 조직이었기에, B2B 기반의 화물 사업이라는 완전히 낯선 도메인을 마주했다.
우리가 마주한 “화물”
에어프레미아 홈페이지에서는 개인 고객을 대상으로, 예약과 결제가 실시간으로 이루어지고, 탑승 전 온라인 체크인 서비스를 제공한다. 반면 화물은 에어프레미아와 계약 관계에 있는 대리점들의 직원이 화주의 요청에 따라 예약을 하고, 공항에서 조업사가 화물을 항공기에 적재하는 등 복잡한 B2B 네트워크로 구성된다. 사실 항공권 예매나 온라인 체크인은 내가가 여행을 준비하는 고객이 되어 생각해보거나 혹은 사용자 인터뷰를 할 수 있었는데, 내가 “화물 취급 대리점”의 직원이 될 수는 없었으니까, 처음에 마주한 기분은 ‘막막’ 그 자체였다.
“화물팀의 업무 프로세스와 환경, 이해관계자 구조를 파악하기 위해 화물사업실 인터뷰와 대리점 설문을 병행했어요.”
– 지은 (디자이너)
사람이 항공기를 타서 여행하는 것과 화물이 가장 다른 점이 있다. 하나의 운송장(AWB, Air Waybill) 안에서도 화물이 여러번 나뉘어 분리되어 이동하기도 하고(partial case), 공항과 항공사의 사정으로 이미 적재되었던 화물이 다시 오프로드되는 비정상 상황이 발생하기도 한다. 화물 예약 및 처리 프로세스를 학습하는 것도 큰 숙제였다.
“하나의 운송장 안에서 분리, 개별도착 및 비정상운항 상황을 모두 고려해야 했어요. 정말 다양한 데이터 조합의 비정상 상황(엣지케이스) 들을 상상해볼 수 있어야 했습니다.”
– 현수 (QA)
“화물이 실제 예약부터 인도까지 가지는 여러 상태값의 구조를 이해하는 게 가장 어려웠어요. IBS 원천데이터에는 필요·불필요 정보가 다 들어와서 어떤 기준으로 구분해야 할지부터 정의가 필요했죠.”
– 현중 (BE)
항공 도메인을 처음 접한 사람들이 많이 느끼는 어려움 중 하나가 바로 외계어처럼 느껴지는 “축약어”인데, 여객에서 사용하는 언어들이 막 익숙해질 무렵 우리는 또 다른 세계의 ‘외계어’를 접하게 된다. AWB부터 해서, FSU, SCC, RCF… 그냥 구글링해서는 나오지 않는 축약어들. 정말 말 그대로 ‘대환장 파티’ 였다.
“축약어도 포털에 검색이 안 돼서 파악이 어려웠어요.”
– 지수 (디자이너)
결국 TF가 처음 마주한 것은 ‘개발 어떻게 하지?‘가 아니라 ‘화물에 대한 이해’였다. 화물의 여정을 표현하기 위해 우리는 복잡한 데이터들을 어떻게 바라보고 분석해야 하는지, 그리고 어떻게 사용자가 쉽게 인식할 수 있게 만들지. 프로젝트는 이렇게 시작했다.
내 화물의 위치를 빠르고 정확하게 - AWB Tracking
이번 프로젝트의 첫 목표는 대리점, 화주 등 화물의 위치를 파악하고 싶은 사람 누구나 확인할 수 있는 AWB Tracking 페이지를 구축하는 것이었다. 에어프레미아 역시 고객이 자신의 화물의 위치를 파악하기 위해 전화, 이메일 또는 네이트온(!)을 통해 영업 담당자에게 문의해야 했다. 우리는 ibs에서 제공하는 Tracking API를 가지고, AWB 번호만 입력하면 실시간으로 상태를 조회할 수 있는 서비스를 만들고자 했다.
독자의 이해도를 높이기 위한 FYI
-
대한항공이나 아시아나 외에 우리나라 국적 항공사 중 화물 추적기능을 제공하는 항공사는 없다.
-
화물 Booking, Manifest, Export/Import 등을 위한 솔루션이 여러개 존재하는데 그 중 에어프레미아는 IBS의 iCargo를 사용한다. 보통의 화물 솔루션들이 지금까지는 API 방식이 아닌 전문 통신, ftp 등의 방식을 사용해왔으며, IBS 역시 API로 전환한지 얼마 되지 않았다. 에어프레미아가 IBS의 API를 사용하여 개발한 첫 사례다(!!).
고객의 목소리로부터
화물사업실의 경험과 이야기를 듣고나니 더욱 더 “고객”은 어떨지 궁금해졌다. “정말로, B2B의 고객들은 지금의 방식이 최고라고 생각하는 걸까? 새롭지만 더 편한 것을 원하진 않을까?”라는 의문이 우리 안에 자리잡았다. 그래서 화물사업실의 도움을 받아 대리점 고객의 실제 업무 환경과 니즈를 이해하기 위한 설문조사를 진행했고, 예상과 달리 많은 응답이 빠르게 모였다.
“의외로 대리점에서 응답을 적극적으로 주셨고, ‘이건 진짜 필요한 일’이라는 확신을 얻었어요.”
– 지은 (디자이너)
설문의 결과는 TF의 방향성을 좀 더 구체화시킬 수 있는 인사이트가 되었다.
- 응답자의 70% 이상이 5년 이상의 경력자로, 화물 솔루션을 사용하는 데 생기는 불편함에 어느 정도 익숙해져 있다.
- 가장 중요한 개선 포인트는 “예약 편의성”과 “화물 예약의 상태 시각화”
- 벤치마크 대상은 대한항공과 아시아나가 압도적이었으며, 외항사 중에서는 Lufthansa 가 꼽혔다.
복잡한 정보를 ‘화물의 여정’으로 시각화
IBS에서 제공하는 Tracking API에서 내려오는 데이터는 SEG(구간) 단위로 복잡하게 얽혀있덨다. 단순히 시간순으로 나열하면 매우 혼란스러웠다(고객이나 예약팀에서 예약을 수정한 정보도 모두 함께 내려왔기 때문). 우리는 이 데이터를 ‘화물의 현재 위치’ 기준으로 재구성해, “접수-출발-도착-인도” 4가지의 상태값으로 단순화하여 보여주기로 했다. 그리고 하단 Details 섹션에서 타임라인 순으로 세부 상태값과 설명을 나열했다.
“화물의 상태를 시간순이 아닌 위치 기준으로 재배열한 건, 여객 서비스에서 ‘승객이 어디쯤 와 있나’를 보는 감각과 비슷했어요.”
– 지은 (디자이너)
고객의 피드백을 받아 진화하는 Summary 영역
초기 버전에서는 출발지, 도착지, 중량, 수량 정도만 표시했다. 하지만 런칭 후 대리점과 화주들의 피드백을 받았고, Detail까지 내리지 않아도 Summary에서 “각 구간의 항공편명과 예상 스케줄까지 한눈에 보고싶다”는 요청이 많았다.
“사용자들이 디테일까지 내려보지 않고 Summary에서 모든 걸 파악하려는 경향이 강했어요. 우리가 제안한 구조가 실제로 더 큰 가치를 주고 있었던 셈이죠.”
– 지은, 지수 (디자이너)
결국 Summary는 단순한 요약이 아니라 화물 운송의 지도가 되었다. Tracking 화면을 여는 순간, 사용자는 내 화물의 여정을 한눈에 파악할 수 있게 되었다.
사용자와 함께 발전하는 제품
런칭 이후 Mixpanel 로그 분석을 통해 사용자의 행동과 개선 포인트를 지속적으로 모니터링 하고 있다. 초기에는 단순히 PV 정도만 기록할 계획이었지만, 데이터 정합성이 우려되어 어떤 빌 넘버를 조회했고, 그 빌넘버가 가지는 값들은 무엇이고, 고객이 어떤내용을 확인했는지 등의 세부적인 로그를 강화했다.
CS 응대를 위해 넣었던 세부 정보들은 아직은 사업 이해도가 낮은 우리에게 생각보다 많은 인사이트를 주었다. 런칭한 9월에 대비하여 10월의 MAU는 51.7%나 증가하였고, 한국 외에도 미국, 베트남, 중국, 홍콩 등 다양한 국가에서 트래픽이 유입되고 있다. 그리고 서두에 말했던 것처럼, 예약과의 Tracking 관련 문의가 0이 되면서 홈페이지 활용률이 늘어나 CS 문의량이 전반적으로 감소되는 놀라운 효과를 낳았다. 데이터는 이 서비스가 외부/내부 고객의 실제 문제들을 해결한 제품임을 확인해주었다.
새로운 시스템을 위한 새로운 구조
여객과는 다른 Cargo, 새로운 개발 아키텍처로
화물 시스템은 기존 에어프레미아 공식 홈페이지와 완전히 분리된 도메인으로 시작되었다. 이로 인해 기존에 만들어둔 유틸 함수나 디자인 시스템을 그대로 가져올 수 없었고, 코드를 중복 관리해야 하는 비효율이 발생했다. 이런 문제를 해결하기 위해 개발팀은 Turborepo 기반 모노레포 구조를 도입했다. @repo/ui, @repo/utils, @repo/i18n 등 공통 패키지를 모듈화해 여러 프로젝트에서 함께 사용할 수 있게 했다. 이 공통화 작업은 한 번에 진행하지 않고, Cargo 개발 일정과 우선순위에 맞춰 단계적으로 전환했다.
“공통화 작업은 한 번에 전체를 옮기는 방식이 아니라, 우선순위를 정해 단계적으로 진행했습니다.”
– 민주, 우정 (FE)
백엔드 역시, 기존 공홈의 브랜치 전략(Git-flow) 대신 트렁크 기반(Github-flow)로 전환해 CI/CD를 간소화했다. 장애 알림은 Sentry 대신 Datadog을 사용해 간단하지만 실시간에 가까운 모니터링 환경을 구축했다.
“트렁크 기반 개발로 전환하면서 훨씬 간결하게 CI를 할 수 있었어요.”
– 재녕 (BE)
기술적으로 새로운 구조를 도입함과 동시에 생성형 AI를 적극 활용하기도 했다. IBS에서 내려주는 원천데이터를 우리의 API 구조로 재조합할 때, 생성형 AI를 활용하여 반복적 로직을 자동화했고 이는 리소스 절약에도 큰 도움이 되었다.
“원천데이터를 BE API 구조로 재조합할 때 생성형 AI를 많이 활용했어요. 반복적 로직을 자동화하면서 리소스를 많이 절약했습니다.”
– 현중 (BE)
화물이 가져다 준 새로운 순간들
낯설었지만, 결국 성장의 여정
가장 큰 벽, 진입할 수 없는 세계
우리가 마주한 가장 큰 벽은 “사용자의 세계에 직접적으로 들어갈 수 없다”는 점이었다. 실제 협업 대상은 화물사업실이었고, 화주나 대리점의 목소리는 영업 담당자의 의해 간접적으로만 들을 수 있었다.
“화물사업실에서 ‘대리점 고객은 이런 걸 원해요’라고 설명해주셨지만, 정말로 그들이 그렇게 느끼는지 직접 확인할 수 없다는 점이 늘 고민이었어요.”
– 지은 (디자이너)
여객 서비스의 경우 팀원 스스로 항공권을 구매해보며 고객 경험을 체험할 수 있다. 하지만 화물은 우리가 직접 ‘대리점 계정’이 될 수 없는 영역이었다. 그래서 TF는 내부 인터뷰와 설문, iCargo 솔루션 테스트, 그리고 Mixpanel 로그 데이터 분석을 통해 고객의 행동을 간접적으로 이해해야 했다.
또 하나의 큰 허들은 IBS 솔루션(iCargo)의 제약이었다. racking API는 필요한 값보다 훨씬 더 많은 데이터를 필터링 없이 반환했다. 이로 인해 “어떤 데이터가 실제로 유효한가”를 식별하기가 어려웠다. 개선 요청을 해봤지만 다른 항공사도 쓰는 API기 때문에 수정이 어렵다는 답만 돌아왔다. (그리고 지금 생각해보면 이들이 생각하는 Tracking의 정의와 우리가 생각하는 Tracking의 정의가 다른 것은 아닐까 싶기도 하다.)
“Tracking API는 너무 많은 값이 한꺼번에 내려와서 어떤 데이터가 진짜로 신뢰할 수 있는지 구분하기 어려웠어요.”
– 영은 (PM)
결국 팀은 고객의 니즈를 충족시키기 위해 데이터 필터링 로직을 수차례 수정하며 검증을 반복했다. 이는 외부 솔루션의 제약 속에서도 “주어진 환경 안에서 최적의 해법을 찾는 훈련”이 되었다.
개인의 성장과 팀의 변화
무엇보다 우리 개개인과 팀의 성장에도 큰 영향을 미친 프로젝트였다. B2B도 결국엔 사람 중심의 서비스였고, 복잡하지만 문제 해결의 본질은 같았다. 도메인 자체를 이해하기 위해서 팀원들끼리 같이 맞대고 이해해가는 과정이 꽤 즐거웠다.
“B2B는 정적이고 재미없다는 선입견이 있었는데, 문제 정의와 솔루션 도출의 본질은 똑같았어요.”
– 지수 (디자이너)
“짧고 정확한 커뮤니케이션의 중요성을 배웠습니다.”
– 재녕 (BE)
“도메인 지식이 아무도 없는 상태에서 다 같이 머리를 맞대고 이해해가는 과정이 너무 즐거웠어요. 이해하지 못하는 상황을 함께 이해하는 공감대가 생겼습니다.”
– 현중 (BE)
개인의 성장과 팀의 변화
Mixpanel 대시보드에는 수천 건의 AWB 조회 데이터가 쌓였다. 이 데이터를 통해 어떤 노선이 자주 조회되는지, AWB당 평균 SEG 수, 트럭 운송 구간 비율 등을 파악할 수 있었다.
“B2B 고객은 데이터로부터 배울 게 별로 없을 거라 생각했어요. 그런데 Mixpanel에서 실제 트렌드를 보면서, 화물 운항 흐름과 사용자 니즈가 일치한다는 걸 깨달았죠.”
– 영은 (PM)
단순한 로그 수집에서 시작된 분석은 결국 화물 사업을 더 잘 이해하게 된 학습 과정이 되었다. B2B 환경에서도 데이터는 충분히 의미 있었다. 이 경험은 다음 단계—온라인 예약 시스템 구축으로 나아가는 방향성을 제시했다.
What is the Next?
Booking!
AWB Tracking으로 시작된 프로젝트는 이제 온라인 예약 시스템 구축으로 확장되어, 26년 2월에 대리점 고객용 예약 시스템 오픈을 목표로 열심히 달리고 있다. 단순 조회 시스템에서 예약이라는 Action을 취할 수 있는 서비스를 제공하기 위해, 여러 대리점의 목소리와 행동 데이터를 기반으로 효율적이고 신뢰할 수 있는 UX를 만들어 나가고 있다.
서두에 말했듯, 우리의 프로젝트가 성공적으로 릴리즈된다면 대한항공과 아시아나항공에 이어 세번째로 화물 예약 시스템을 제공하는 항공사가 된다. 엑셀파일과 이메일로 이루어지던 화물 사업이 Digitalization을 향해 화물사업실과 랩스가 함께 움직이고 있다. 오랫동안 항공업에 몸담았던 사람으로써 느끼기에, 이 업계는 새로운 것을 시도하기에는 굉장히 보수적이다. 이런 불모지와 같은 환경에서도 랩스가 피워 낼 Digital Innovation의 새싹이 시들지 않고 계속 성장하기 위해 우리는 끊임없이 노력할 것이다.