software

머신러닝을 위한 역사적 항공편 데이터 정규화 개발자 가이드

발행: (2025년 12월 4일 오후 10:07 GMT+9)
9 min read
원문: Dev.to

Source: Dev.to

데이터 과학 세계에는 항공 분야에서 다른 어떤 산업보다도 더 진실된 오래된 격언이 있습니다: Garbage In, Garbage Out.
예측 모델을 구축하고 있다면—항공 지연을 예측하든, 공급망 물류를 최적화하든, 동적 가격 책정 엔진을 구동하든—머신러닝(ML) 모델의 아키텍처는 훈련 데이터의 품질에 비해 부차적입니다. 항공 데이터는 **“더럽다”**는 평판이 있습니다: 콜 사인 변경, 시차 이동, 복잡한 코드쉐어 계약, 운영상의 불규칙성 등이 모두 잡음을 유발할 수 있습니다. 가공되지 않은 JSON을 그대로 신경망이나 회귀 모델에 투입하면 신뢰할 수 없는 예측이 나오게 됩니다.

이 가이드는 역사적 항공편 데이터를 정규화하기 위해 필요한 구체적인 데이터 엔지니어링 파이프라인을 살펴보고, 모델이 하늘의 현실을 반영하도록 합니다.

첫 번째 장애물: “코드쉐어 함정”

항공 데이터를 ingest할 때 개발자들이 가장 흔히 저지르는 실수는 모든 항공편 번호를 고유한 물리적 이벤트로 취급하는 것입니다. 뉴욕(JFK)에서 런던(LHR)으로 운항하는 단일 항공기가 동시에 여러 마케팅 항공편 번호(AA100, BA1500, IB4000)를 가질 수 있습니다. 이것을 코드쉐어라고 합니다.

왜 머신러닝을 깨뜨리는가

  • 각 마케팅 번호는 동일한 물리적 비행을 나타내므로 중복 행이 데이터셋을 부풀리고 모델을 편향시킵니다.

정규화 해결책

  1. Ingest the raw data.
  2. Filter for is_codeshare: false.
  3. Master the dataset to the operating flight number (the carrier actually operating the aircraft).

티켓이 아닌 “금속(항공기)”을 분리함으로써 훈련 데이터가 물리적 현실을 반영하게 됩니다.

공항 데이터 API를 활용한 특성 강화

역사적 비행 로그는 일반적으로 이륙, 착륙, 지연 시간과 같은 이벤트를 포함합니다. 왜 지연이 발생했는지를 예측하려면 공항 환경에 대한 맥락 정보가 필요합니다.

즉시 적용 가능한 아이디어: 활주로·터미널 가중치

  • number_of_runways
  • airport_elevation
  • terminal_complexity_score

논리: 2개 활주로 공항에서 하나의 활주로가 폐쇄되면 용량이 50 % 감소해 재앙적인 상황이 되지만, 5개 활주로 허브에서는 사소한 불편에 불과합니다. 이러한 인프라 특성을 데이터에 추가하면 ML 모델이 공항 회복력을 평가하게 되어 지연 예측 정확도가 크게 향상됩니다.

시간 정규화: UTC vs. 현지 시간 역설

항공은 협정 세계시(UTC/Zulu)를 사용하지만, 승객 행동, 공항 직원 배치, 러시 아워 교통 등은 현지 시간을 따릅니다.

전략

  • Sequential Time (UTC): 비행 시간, 턴어라운드 시간, 연속 이벤트 연결 등에 사용합니다.
  • Cyclical Time (Local): 도착/출발 시간을 현지 IANA 타임존(예: America/New_York)으로 변환하고 hour_of_day(0‑23)와 day_of_week 같은 인간 중심 특성을 추출합니다.

이를 통해 모델은 “JFK에서 금요일 현지 시간 16:00‑19:00 사이에 출발하는 항공편은 택시‑아웃 지연 확률이 높다”는 패턴을 학습할 수 있습니다.

엣지 케이스 처리: 전복 및 “유령 비행”

표준 데이터셋에서는 전복된 비행이 데이터 오류로 나타날 수 있습니다(예: ORD로 예정됐지만 IND에 도착 기록).

해결책

전처리 과정에서 route_integrity 불리언 플래그를 생성합니다:

Conditionroute_integrity
arrival_airport_scheduled == arrival_airport_actualTrue
otherwise (diverted)False

사용법:

  • 일반 스케줄 신뢰성 모델을 훈련할 때 전복 항공편을 제외합니다.
  • 비정상 이벤트를 모델링하고 싶다면 이를 별도의 “Anomaly Detection” 데이터셋으로 분리합니다. 전복 항공편을 일반 모델에 포함하면 잡음이 증가해 정확도가 떨어집니다.

“턴어라운드” 특성: 테일 넘버 연결

대부분의 기본 비행 추적기는 개별 비행을 독립적으로 다루지만, 실제로 비행은 종종 체인의 한 링크입니다. **항공기 등록 번호(Tail Number)**를 사용해 데이터를 연결하면 연쇄 효과를 포착할 수 있습니다.

“체인 반응” 특성

  • Incoming delay buffer:
    • Scenario: Flight B is scheduled to depart at 14:00.
    • Data: The aircraft for Flight B is currently on Flight A, which is delayed and lands at 13:50.
    • Calculation: Only 10 minutes remain for deplaning, cleaning, and boarding—insufficient time, leading to a delay for Flight B.

특정 항공기를 추적함으로써 경로만 보는 것이 아니라 연쇄 지연을 모델이 학습하게 됩니다.

원시 로그에서 예측 인텔리전스로

멋진 대시보드와 비즈니스 결정을 이끄는 대시보드의 차이는 데이터 엔지니어링에 있습니다. 원시 항공 데이터는 무엇이 일어났는가를 기록하고, 정규화된 데이터(코드쉐어 제거, 공항 맥락 강화, 항공기 이력 연결)는 무엇이 일어날 것인가를 매핑합니다. 이 정규화 단계를 따르면 ML 모델이 잡음이 아닌 명확한 신호로 학습하게 됩니다.

자주 묻는 질문

Q1: 훈련을 위해 과거 데이터를 얼마나 오래까지 사용해야 하나요?
A: 모델 목적에 따라 다르지만, 최소 12개월은 계절 패턴을 포착하고, 3‑5년은 이상치에 대한 강인성을 제공합니다.

Q2: 역사 로그에서 누락된 데이터 포인트는 어떻게 처리하나요?
A: 일반적인 전략으로는 중앙값/평균값으로 대체(imputation)하거나, 동일 테일 넘버에 대한 이전 기록을 기반으로 앞쪽 채우기(forward‑filling)하거나, 누락 항목에 플래그를 달아 모델이 결측 자체를 학습하도록 하는 방법이 있습니다.

Q3: 이 데이터를 지속 가능성 보고에 활용할 수 있나요?
A: 가능합니다—정규화된 데이터에 연료 소비 및 배출 계수를 결합하면 정확한 탄소 발자국 지표를 산출할 수 있습니다.

추천 리소스

  • Aviationstack – JSON 형태의 실시간 및 역사적 비행 데이터.
  • FlightAware (AeroAPI) – 광범위한 커버리지를 제공하는 종합 비행 추적.
  • OAG – 전 세계 항공사 일정 및 성과 데이터.

이들 제공자는 위에서 설명한 정규화 파이프라인을 구축하는 데 필요한 원시 로그를 제공하는 강력한 API를 제공합니다.

Back to Blog

관련 글

더 보기 »