▲

항공 분야에 대해 프로그래머들이 믿는 잘못된 상식들

 (flightaware.engineering)
1P by GN⁺ 12시간전 | ★ favorite | 댓글 2개
  • 항공 데이터는 복잡하고 비표준적인 특성이 많음
  • 항공편, 공항, 네비게이션, 트랜스폰더 정보 등에 대해 개발자가 흔히 잘못된 가정을 함
  • 실제 비행 추적 시스템은 다양한 예외 상황과 데이터 이상현상에 유연하게 대응해야 함
  • 많은 오해는 소프트웨어나 고객 시스템에서 예상치 못한 오류를 야기함
  • 데이터 설계 시에는 현실의 복잡성을 면밀히 반영하는 관점이 필요함

개요

FlightAware는 전 세계 항공 데이터를 처리 및 배포하는 소프트웨어를 개발하는 기업임. 그러나 실제 항공 데이터는 직관과 달리 정형적이지 않고 예외와 변칙이 많음. 많은 개발자는 데이터 구조, 흐름, 식별 체계 등에서 여러 전제를 가정하지만, 이는 현실에서 잘못된 가정으로 작용하여 시스템의 오류와 불일치를 초래함. 이 글은 이름 잘못된 상식 시리즈의 연장선에서, 항공 산업 내 소프트웨어에서 빈번하게 저지르는 오해와 그로 인해 발생하는 사례들을 정리함.

Flights (항공편 정보)

  • 항공편은 항상 게이트에서 출발한다는 오해가 있지만, 실제로는 여러 번 게이트를 이동하거나, 예정보다 아주 늦거나 빠르게 출발하는 경우가 있음
  • 항공편 스케줄이나 출발·도착 공항이 명확하다고 생각하기 쉽지만, 헬리콥터·군용기 등은 공항이 아닌 곳에서 이착륙하는 사례가 존재함
  • 항공편의 비행시간이나 스케줄이 규칙적일 것 같지만, 며칠에 걸쳐 진행되는 장기 비행이나 변칙적 운항도 빈번함
  • 항공편 식별번호(예: UAL1234)가 유일하다고 가정하기 쉽지만, 실제로는 한 항공기에 여러 식별자나 번호가 부여되며, 동일 번호가 여러 상황에서 사용될 수 있음
  • 표기상 같은 번호라도 항공편 식별자, 등록번호, 기타 표식이 혼재되어 혼란을 초래하고, 티켓, 관제, 조종사마다 사용하는 식별 정보가 다를 수 있음

Airports (공항 정보)

  • 공항 위치와 식별 코드가 고정적이라고 생각될 수 있으나, 실제로는 공항이 폐쇄, 이전·통합되는 경우가 있어 위치나 코드가 변경됨
  • 터미널/게이트 번호, 활주로 등의 명칭 체계도 일관되지 않고 예외적인 규칙이 많음
  • ICAO/IATA 코드 체계에 대해서도 중복, 복수 코드 부여, 위치 코드 오해 등 현실과 맞지 않는 사례가 다수 존재함
  • 어떤 식별정보(예: IATA 코드)가 있다고 반드시 실제 공항임을 보장하지 않으며, 철도역·버스터미널 등에 IATA 코드가 부여된 사례도 존재함
  • 심지어 ICAO 코드 중에는 지구가 아닌 곳(예: 외계 크레이터)에 할당된 경우도 있음

Airlines (항공사 정보)

  • 별도의 라인에서 구체적인 잘못된 상식들이 언급되지 않았으므로 생략함

Navigation (항법 및 항로 정보)

  • 웨이포인트 명칭이 고유할 것이라는 오해가 있으나, 실제론 중복이 있음
  • 항공에서 사용하는 고도 정의는 하나로 통일되어 있지 않고, 여러 기준에 따라 다르게 해석됨
  • 항공관제 데이터가 완벽히 정확하다고 생각할 수 있으나, 실제로는 오류 또는 변경이 자주 발생함
  • 항공편 계획의 취소, 플랜 변경 등이 실제 비행에 반영되지 않거나, 동일 항공편이 여러 번 목적지를 변경할 수 있음
  • 레이더, 항공관제 기관 간 데이터 불일치나, 동시 관측의 위치 괴리 현상도 존재함

Transponders and ADS-B (트랜스폰더 및 ADS-B 관련 정보)

  • ADS-B 신호가 비행기에서만 송신된다고 가정하지만, 공항 차량·기타 장치에서도 송신될 수 있음
  • GPS 좌표의 정확성, 신호의 신뢰성에 대한 과신 역시 오해임
  • 트랜스폰더 등록정보(식별 번호, 모드 S 어드레스 등) 오류‧중복, 유지보수 누락, 포맷 오류 등으로 실시간 데이터와 실제 정보 간 불일치가 빈번함
  • ADS-B 정보가 그대로 수신/저장된다고 생각하기 쉽지만, 전송 오류, 신호 위조 등 다양한 이슈가 발생함
  • 기기 고장, 관리 부주의, 외부 요인(예: 쥐의 케이블 훼손) 역시 현실적 변수임

마무리

이 목록은 FlightAware 및 Hyperfeed 개발팀이 다년간 수많은 실제 사례에서 얻은 경험과 인사이트를 바탕으로 구성된 항공 데이터 신뢰성의 복잡성을 보여줌. 각종 오류와 오해를 줄이기 위해, 실존하는 예외 상황을 철저히 고려한 데이터 모델링 및 운용의 중요성을 강조함.

▲
aliveornot 8시간전  [-]

읽기만 해도 혈압 오르네요 ㅋㅋ

답변달기
▲
GN⁺ 12시간전  [-]
Hacker News 의견

  • 항공기에는 시간에 따라 변하지 않는 단일 유일 식별자가 없는 상황 설명. 각 비행체에는 일련번호가 부여되지만, 이것만으로는 유일성을 담보하지 못한다는 실제 경험 공유. "제조사, 기종, 일련번호"의 조합이 그나마 일생에 걸쳐 유일 식별자가 되지만, 기체가 구조 변경으로 타입이 달라지면 이마저 변하는 경우 존재. 항공처럼 거대하고 복잡한 시스템에 변하지 않는 식별자가 없는 게 신기하다고 느끼는 개인적 감상 추가. 항공기 등록 번호(꼬리번호)는 자동차 번호판처럼 바뀌고, ICAO 24비트 식별자는 ADS-B 장비에 연결돼있어 이동/변경이 자유로운 특성까지 설명

    • "제조사, 기종, 일련번호" 조합이 특허 대상이 된 점이 신기하다는 호기심 표현. 어떻게 이런 게 새롭다고 인정받아 특허가 될 수 있었는지 궁금증 제기

    • 이 이야기를 '테세우스의 배' 역설과 연결하여, 항공기의 정체성과 식별자 변화에 관한 철학적 연상 소개 Ship of Theseus 위키피디아 링크

    • 항공 산업이 국가별로 사일로처럼 각각 다르게 발전해 표준화가 늦었다는 역사적 배경 공유. 세계적 표준이 제대로 정착된 자체가 놀라운 일이라고 보는 시각. 현재 대형 제조사들이 소수로 통합되어서 그나마 가능한 상황이라는 분석

    • 실제 환경에서 "진정한" 유일 식별자가 중요한 문제로 자주 등장한다는 현장 경험 공유. 해결책은 거의 항상 “모델, 제조사, 일련번호” 조합이며, 필요하다면 생산연도까지 추가. 심지어 인간 데이터도 언어(모국어) 같은 기준으로 de-duplication 시도했던 사례 언급

    • 활주로번호도 시간이 지나며 바뀌는 예시로 위키 문서 Runway 위키피디아 링크 공유

  • 이런 리스트들은 항상 더 자세한 설명이 붙으면 훨씬 유익했을 거라는 의견. 하지만 링크된 출처 정보 중에는 유익한 게 많아, 예를 들어 '화성의 분화구에 ICAO 공항 코드가 부여된 사례(JZRO)' 소개 Jezero 분화구 위키피디아 링크, 출발은 정상인데 40시간 후착륙 지연 항공편 예시

    • 리스트에 적힌 사례들이 사실 지루한 사유 때문이 많다고 지적. 예컨대 2주짜리 비행은 Google Balloon이며, 40시간 지연은 단순히 나쁜 날씨, ADS-B 값은 조종사가 입력하는데 종종 실수한다는 배경 설명

  • 제조사-기종-일련번호 조합이 너무나 자명해 보이는데 그게 어떻게 특허가 됐으며, 지금 누군가 그 특허로 이익을 취하고 있는지 의문 제기

  • 비행 데이터 분석 소프트웨어 개발 경험에서, 헬리콥터/비행기 모두 다양한 곳(병원, 옥상, 주차장, 운동장, 공항, 골프장 등)에서 이착륙하므로 “항공에 관한 온갖 거짓말” 속에서 대부분의 시간을 보내는 실제 개발자 고충

  • "Falsehoods..." 시리즈 글을 볼 때마다 많은 개발자가 인간 중심의 시스템이 엄격한 규칙만 따르리란 착각에 빠지는 점이 흥미롭다고 보는 시각

    • 개발자는 모든 것을 엄격한 규칙 체계로 환원하는 걸 좋아하지만 실제 세상은 그렇지 않음을 인정

    • 프로그래밍이라는 직업 자체가 유연한 인간 시스템과 엄격한 규칙기반 기계 사이 인터페이스라는 본질을 가지고 있다는 분석

    • 프로그래머 입장에서 세상을 소프트웨어로 모델링할 때 이러이러한 전제를 당연하다고 생각하지만, 실제로는 전혀 그렇지 못해 겪는 딜레마와 혼돈 공유. 예를 들어, 비행편에는 출발/도착 공항이 당연히 있다고 가정하지만 현실은 다르다는 예시

    • 소프트웨어 본질상 도메인 모델링을 반드시 규칙 세트로 만들어야만 한다고 주장. 만약 규칙이 없다면 아무 기능도 제공할 수 없기 때문. 일반인에게 '윤초(leap second)' 같은 예외를 설명하면 헛소리라고 오해하기 쉬운 만큼, 오히려 개발자가 세상의 예외와 복잡함을 잘 인식하는 경우 많다는 주장

  • "Falsehoods Programmers Believe..." 시리즈에서 각 항목을 테스트 케이스로 취급하는 방법 제시. 프로그램에 잘못 내재된 가정들을 검증하는 단위/통합 테스트로 확장 가능

    • 실제로 각 항목별로 테스트가 만들어졌고, 근무 당시엔 일상적인 것부터 극단적인 것까지 천 개가 넘는 테스트가 있었던 경험. 품질과 엔지니어링에 큰 가치를 두던 팀이었다는 회상

  • "항공편은 공항에서 이/착륙한다"는 전제가 과거 브라질 항공 시스템에 무조건 있었으며, 이를 임시방편으로 해결한 사례 언급. "공항/활주로는 위치나 방향이 변하지 않는다" 역시 너무 자주 잘못 가정된다는 비판. "항공기는 활주로나 헬리포트에서만 착륙한다"는 전제까지 추가해야 한다는 제안

    • 브라질의 오래된 항공 시스템들이 이런 문제를 어떻게 임시처리했는지 더 자세히 알고 싶다는 질문

  • CGP Grey의 공항 코드의 엉망진창인 과정을 잘 요약한 영상 공유 YouTube 링크. 시스템의 독특한 사정까지 설명

  • 동일한 주제를 다루는 FlightAware 포럼 관련 토론도 소개 FlightAware 포럼 링크

  • 프로그래머 입장에서 이 리스트의 모든 전제를 합리적이라고 생각했다가, 뒤늦게 고통스럽게 현실을 깨닫는 과정에서 머리가 폭발하는 기분 공유. 훌륭한 요약이었다는 찬사

답변달기