예약에서 끝나지 않는 여행: 한 명이 10여 개 레포를 가로질러 만든 항공 여정 케어

마이리얼트립이 예약한 항공편의 운항 상태를 고객이 앱을 열지 않아도 실시간으로 받아보는 서비스를 선보였습니다. 출발 3시간 전 알림부터 게이트 변경과 지연, 결항, 회항, 출발, 도착, 수하물 상태까지, 비행의 흐름 전체를 고객이 찾기 전에 먼저 안내합니다.

여행은 항공권을 예약하는 순간 끝나지 않습니다. 짐을 싸고 공항으로 향하고 비행기에 올라 목적지에 내려 짐을 찾을 때까지 이어집니다. 마이리얼트립은 그 여정 전체를 빈틈없이 잇는 '여행 경험의 완전한 연결'을 그려 왔습니다. 예약을 마친 다음의 시간, 비행이 실제로 움직이는 구간까지 그 연결을 넓히는 일이 자연스러운 다음 걸음이었습니다.

이번에 선보인 항공 여정 케어는 바로 그 구간을 잇는 서비스입니다. 그리고 여기에는 또 하나의 이야기가 있습니다. 서버와 iOS, Android, 웹, 인프라, 데이터까지 10여 개 레포에 걸친 이 서비스를 한 명의 프로덕트 엔지니어(PE)가 주도해 구현했습니다.

그 PE는 CTO 직속 PS팀(Product Strategy) 소속입니다. PS팀은 전사에서 가장 중요한 문제에 가장 잘 맞는 PE를 배치하고, 그 PE가 문제 정의부터 구현과 배포까지 끝까지 책임지는 조직입니다.

이 서비스도 그렇게 한 PE가 끝까지 맡은 일이었습니다. 어떻게 한 사람이 이 넓은 범위를 처음부터 끝까지 연결해 만들 수 있었을까요. 그 과정을 담당 PE인 조정훈님에게 직접 들었습니다.

그동안 비어 있던 자리, 내 비행기의 지금

첫 질문은 단순했습니다. 왜 이 서비스를 만들기 시작했는가.

정훈님은 '비어 있던 자리'를 먼저 꺼냈습니다. 그동안 고객은 자신이 탈 비행기가 지금 어떤 상태인지 직접 찾아야 했습니다. 지연됐는지 게이트가 바뀌었는지 결항됐는지 알려면 항공사 앱을 열거나 검색을 하거나 공항 웹사이트를 따로 뒤져야 했습니다. 정보가 가장 필요한 순간에 정작 정보는 여기저기 흩어져 있었습니다.

여행을 좋아하는 정훈님이 마이리얼트립을 직접 쓰며 늘 느낀 결핍이기도 했습니다. 항공권을 파는 일은 잘하면서도, 고객이 그 티켓을 들고 공항으로 떠나는 순간부터는 케어의 공백이 있었습니다. 결제 완료 화면이 뜨면 플랫폼의 역할이 끝난 듯하지만, 고객의 진짜 여행은 그 순간부터 시작입니다. 공항철도 안에서, 탑승 게이트 앞에서, 예기치 못한 지연에 발을 구르는 순간이야말로 플랫폼이 고객을 가장 단단하게 챙겨야 할 때입니다.

"결제 완료 화면 다음부터가 고객의 진짜 여행입니다. 그 마지막 순간까지 화면 너머로 동행하고 싶어, 고민 없이 직접 손을 들었어요."

관점을 바꾸자 답이 보였습니다. 고객이 정보를 찾으러 오게 하는 대신 마이리얼트립이 먼저 다가가면 됩니다. 예약 정보는 이미 마이리얼트립에 있으니, 그 예약에 상용 항공 데이터를 실시간으로 결합하면 고객이 묻기 전에 운항 상태를 전합니다.

어느 항공사를 타든, 예약한 그 자리에서

비슷한 기능이 세상에 없는 건 아닙니다. 이 점을 알면서 시작했고, 그렇기에 두 가지를 다르게 가져갔습니다.

하나는 마이리얼트립에서 예약한 고객이라면 누구나 똑같이 케어받는다는 점입니다. 항공사를 가리지 않습니다. 어떤 항공편을 예약했든 같은 방식으로 운항 상태를 받아봅니다. 특정 항공사 앱에 들어가야만 알 수 있던 정보를, 예약한 채널 하나로 모았습니다.

다른 하나는 별도의 앱을 새로 만드는 대신 고객이 이미 쓰는 자리에 통합했다는 점입니다. 운항 정보를 보려고 또 다른 앱을 깔거나 열 필요가 없습니다. 마이리얼트립 앱의 '내여행' 예약상세에 '실시간 운항정보 ›'가 들어가 예약을 확인하던 흐름 그대로 운항 상태로 이어집니다. 항공편명으로 통합 검색도 되니 예약과 별개로 특정 편의 상태를 바로 찾아봅니다.

여기에 잠금화면 위젯을 더했습니다. 고객이 앱을 켜는 과정조차 덜어내려면 iOS와 Android라는 서로 다른 두 생태계의 잠금화면을 각각의 방식으로 공략해야 했습니다.

iOS (Live Activity): 추적 화면에 진입하는 순간 위젯 세션을 생성합니다. 이후 운항 정보에 변화가 생기면 서버에서 전달되는 실시간 상태 변경 이벤트를 통해 잠금화면 카드와 Dynamic Island를 갱신하도록 구성했습니다.
Android (Ongoing Notification): 캔버스 역할을 하는 RemoteViews로 커스텀 카드 레이아웃을 직접 만들었습니다. 상단 알림 영역에 이 카드를 상주시킨 뒤, 데이터 변경 푸시가 들어올 때마다 카드 자체를 통째로 실시간 교체하는 방식으로 대응했습니다.

백엔드에서 가공한 하나의 운항 상태 스냅샷을 두 OS의 위젯 엔진에 오차 없이 안착시키는 것이 이번 구현의 핵심이었습니다.

"앱을 열지 않아도 폰만 슬쩍 보면 1초 만에 내 비행기 상태가 파악되도록, OS별 네이티브 디테일을 끝까지 팠어요."

고객이 이미 머무는 곳에 정보를 가져다 두는 쪽은 손이 더 많이 갑니다. 내여행 화면도 손봐야 하고, 잠금화면 위젯은 iOS와 Android를 따로 다뤄야 합니다. 이렇게 여러 곳을 동시에 건드려야 한다는 점이 다음 이야기로 이어집니다.

한 사람이 10여 개 레포를 가로지른다는 것

이 서비스가 흥미로운 진짜 이유는 여기에 있습니다. 이 서비스는 서버, iOS, Android, 웹, 인프라, 데이터까지 여섯 영역을 한 명의 PE가 주도해 구현했습니다.

고객이 보는 건 하나의 매끄러운 화면입니다. 비행기가 지금 어디에 있고 언제 출발하는지가 깔끔하게 떠오릅니다. 하지만 그 한 화면 뒤에서는 여러 층이 맞물려 돌아갑니다. 데이터를 받아 적재하는 층, 그 데이터를 가공해 알림으로 만드는 층, 그 알림을 iOS와 Android 각각에 맞게 띄우는 층, 내여행과 웹에 같은 정보를 보여주는 층. 보통은 층마다 다른 사람이 붙습니다.

이번에는 한 사람이 그 흐름을 처음부터 끝까지 이었습니다.

"한 군데를 바꾸면 다른 여러 곳이 함께 움직이니까, 연결을 전부 머릿속에 그려두지 않으면 진도가 안 나갔어요."

이런 방식이 가능한 건 마이리얼트립이 엔지니어를 보는 관점 덕분입니다. 마이리얼트립에는 서버 담당, iOS 담당처럼 영역으로 나뉜 직군 구분이 없습니다. 모든 엔지니어가 PE로서, 익숙한 영역이 어디든 필요하면 그 경계를 넘어 직접 만듭니다.

정훈님이 가장 어렵게 꼽은 것은 10여 개 저장소를 혼자 넘나드는 컨텍스트 스위칭이었습니다. 백엔드에서 실시간 데이터를 받는 로직을 짜다가 알림 엔진으로 넘어가 파싱 규칙을 고치고, 모바일 네이티브 두 곳에서 위젯 레이아웃을 잡은 뒤 다시 웹 내여행 화면을 손보는 흐름이 쉴 새 없이 이어졌습니다. 이 범위를 빠르게 돌파한 힘은 두 가지였습니다. AI Native 관점을 극대화해 생소한 영역의 레거시 코드를 빠르게 분석하고 읽어낸 것, 그리고 경계를 넘을 때마다 각 영역 전문가인 동료들이 코드 리뷰로 안전판이 되어준 것입니다.

"AI를 가이드 삼아 생소한 코드를 빠르게 익히고, 각 영역 전문가인 동료들이 리뷰로 방어선을 쳐준 덕에 완주할 수 있었어요."

물론 한 사람이 모든 걸 했다는 뜻은 아닙니다. 정훈님이 전체 흐름을 주도했지만, 데이터와 인프라처럼 운영이 함께 걸린 곳은 관련 팀과 협의하며 진행했습니다. 한 사람이 흐름을 연결하되 여러 사람이 그 흐름이 안전한지 함께 봤습니다.

여러 레이어를 한 사람이 관통하면 층과 층 사이에서 정보가 새거나 어긋나는 일이 줄어듭니다. 데이터가 들어오는 방식과 그 데이터가 알림으로 나가는 방식을 같은 사람이 알고 있으니 중간에서 생기는 오해가 적습니다. 소수의 인원이 넓은 범위를 책임지는 마이리얼트립의 일하는 방식이 이 서비스에 그대로 담겼습니다.

정확하게, 한 번만 보내기

실시간 데이터를 다루는 일에서 가장 무거운 건 신뢰입니다. 운항 알림은 틀린 정보가 한 번 나가거나 같은 알림이 두 번 나가는 것만으로도 신뢰가 무너집니다. 게이트가 바뀌지 않았는데 바뀌었다고 알리거나 출발 알림이 두 번 울리면, 고객은 그다음부터 알림 자체를 믿지 않습니다.

그래서 가장 공을 들인 지점이 '정확하게, 한 번만 보내기'였습니다. 상용 항공 데이터인 Cirium을 실시간으로 결합하고, 그 데이터를 받아 가공해 발송하는 파이프라인을 구성했습니다. 끝없이 밀려드는 원천 데이터에서 게이트 변경, 수하물 수취대 배정, 터미널 변경처럼 고객에게 진짜 의미 있는 변화만 골라 감지하도록 필터링을 짜고, 항공기 속도나 고도 같은 미세한 잡음은 걸러냈습니다. 출발지와 목적지의 시차로 날짜가 꼬이지 않게 모든 시각을 공항 현지 시각으로 맞췄고, 운항 편별 고유 키로 발송 이력을 원자적으로 검증해 같은 고객에게 중복 알림이 가는 일을 원천 차단했습니다.

"틀린 알림을 보낼 바에는 차라리 안 보냅니다. 진짜 의미 있는 변화만 골라, 정확히 한 번 보내는 데 집중했어요."

그 결과는 오픈 첫 주에 드러났습니다. 첫 주 동안 시각 오류나 중복 발송은 없었습니다.

"화려한 기능을 더하는 것보다, 보내야 할 때 정확히 한 번 보내는 게 어렵습니다. 첫 주 동안 오류 없이 돌아간 게 가장 다행스러운 부분이에요."

화면에 새 기능이 하나 추가되는 일과 그 기능이 매번 정확하게 동작하는 일은 무게가 다릅니다. 공을 들인 곳은 후자였습니다.

예약 이후의 여행까지 책임진다

비행 상태를 알려주는 알림 하나처럼 보이지만, 그 안에는 분명한 방향이 담겨 있습니다. 고객이 예약을 마친 뒤의 시간까지, 그 여정을 끝까지 함께하겠다는 방향입니다.

그 방향을 한 명의 PE가 여러 레이어를 넘나들며 직접 구현하고, 여러 팀이 함께 받쳐 완성했습니다. 정훈님이 그리고 싶었던 건 공항으로 향하는 길의 풍경입니다. 전광판 앞, 캐리어를 끄는 길, 탑승동의 소음. 여행에서 가장 두근거리는 그 순간이 불안 대신 온전한 설렘으로 채워지기를 바랐습니다.