영국 항공 교통 관제 시스템의 붕괴

 (jameshaydon.github.io)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 2023년 8월 28일 영국 항공 교통 관제 운영사 NATS의 FPRSA-R 장애로 2,000편 이상이 취소되고, 비용은 1억 파운드 이상으로 추산됨
  • 혼란을 촉발한 비행 계획은 Eurocontrol IFPS가 수락한 유효한 계획이었고, NATS 시스템은 ADEXP 데이터와 ICAO4444 경로를 맞춰 영국 공역 구간을 추출하려 했음
  • 직접 원인은 지리적으로 다른 두 웨이포인트가 같은 식별자를 가진 경우였으며, FPRSA-R이 잘못된 중복 식별자를 이탈 지점으로 매칭해 유효한 영국 구간을 만들지 못함
  • 주 시스템과 백업 시스템은 같은 로직으로 같은 비행 계획을 처리하다 각각 critical exception을 내고 20초 안에 maintenance mode로 들어가 자동 처리가 중단됨
  • 항공기는 계속 안전하게 관제됐지만, 단일 비행 계획이 전체 자동 처리 시스템을 멈추게 한 실패 모드와 테스트 부족, 낮은 수준 로그에 의존한 복구 절차가 문제로 남음

2023년 8월 28일 NATS 장애의 규모

  • 영국 항공 교통 관제 운영사 NATS는 2023년 8월 28일 중대한 기술 장애를 겪음
  • BBC 기준 2,000편 이상이 취소됐고, 비용은 1억 파운드 이상으로 추산됨
  • 장애는 수십만 명에게 영향을 줬을 가능성이 있음
  • 초기 언론 보도는 “잘못된 비행 계획”이나 “프랑스 항공사의 실수” 가능성을 다뤘지만, 문제를 일으킨 비행 계획은 Eurocontrol IFPS가 수락한 ICAO4444 준수 비행 계획이었음
  • 이후 장애를 촉발한 실제 항공편은 French Bee FBU731로 식별됐고, LAX/KLAX에서 ORY/LFPO로 향하던 비행이었음

비행 계획이 NATS까지 도달하는 흐름

  • 항공사는 비행 계획을 Eurocontrol의 IFPS에 제출함
    • IFPS가 비행 계획을 수락하면, 출발 공항 관제 승인 후 항공기는 이륙할 수 있음
    • 이 단계에서 NATS 입력은 필요하지 않음
  • IFPS는 관련 항공 항행 서비스 제공자에게 비행 계획을 전달함
    • NATS는 항공기가 영국 공역에 진입하기 최소 4시간 전에 비행 계획을 받아야 함
    • 이 4시간은 처리 문제를 해결할 수 있는 완충 시간으로 기능함
  • Swanwick Centre의 NATS En-route 운영에서는 데이터를 FPRSA-R로 전달함
    • FPRSA-R는 IFPS에서 받은 ADEXP 형식 데이터를 UK National Airspace System, 즉 NAS와 호환되는 형식으로 변환함
    • NAS는 관련 공역과 경로 정보를 포함하는 비행 데이터 처리 시스템임

ICAO4444와 ADEXP의 차이

  • ICAO4444 비행 계획은 기계가 읽을 수 있고, 필요하면 사람이 읽을 수도 있는 형식임
    • 경로 부분에는 속도, 고도, 웨이포인트, 경로명, DCT 같은 직접 비행 표시가 포함됨
    • 예를 들어 N0440은 440노트, F310은 Flight Level 310을 뜻함
  • IFPS는 ICAO4444 비행 계획을 ADEXP 형식으로 변환해 전달함
    • ADEXP에는 원래 ICAO4444 비행 계획과 함께 유럽 지역 경로에 대한 추가 지리적 웨이포인트가 포함됨
    • 영국에 착륙하지 않고 영국 공역을 통과하는 항공편은 영국 밖 이후 여정에 필요한 웨이포인트도 포함될 수 있음
  • ADEXP의 RTEPTS에는 각 웨이포인트의 고도와 예상 통과 시간이 더 자세히 들어감
    • ICAO 경로에는 9개 웨이포인트가 있을 수 있지만, ADEXP 확장 목록에는 21개 웨이포인트가 포함될 수 있음
    • ICAO 경로의 출발지와 도착지는 별도 필드에 있으므로 경로 목록에 다시 포함되지 않음

장애를 만든 중복 웨이포인트

  • 문제의 ADEXP 웨이포인트 목록에는 지리적으로 다른 두 웨이포인트가 같은 designator를 갖고 있었음
    • ICAO와 다른 기관들이 비고유 웨이포인트 이름을 제거하려는 작업을 해왔지만, 전 세계에는 여전히 중복 이름이 있음
    • 최신 표준은 같은 식별자를 가진 웨이포인트가 지리적으로 넓게 떨어져 있어야 한다고 정함
    • 이 사건의 두 웨이포인트는 모두 영국 밖에 있었고, 하나는 경로 초반, 하나는 경로 후반에 있었으며 약 4,000해리 떨어져 있었음
  • 실제로 식별된 항공편 FBU731의 확장 비행 계획에는 DVL이라는 웨이포인트가 두 번 등장함
    • 하나는 미국 위스콘신 Devil’s Lake
    • 다른 하나는 프랑스 Normandy의 Deauville
    • 후자는 UN859 항로 확장 과정에서 비행 후반부에 나타난 것으로 정리됨

FPRSA-R의 처리 절차와 실패 지점

  • FPRSA-R는 ADEXP 웨이포인트 데이터에서 영국 공역 진입 지점을 처음부터 검색해 찾음
  • 이어 영국 공역 이탈 지점을 찾고, 그다음 ICAO4444 섹션에서 대응되는 구간을 찾으려 함
  • ICAO 경로에는 공역 이탈 지점이 반드시 포함될 필요가 없음
    • 소프트웨어는 이탈 지점이 ICAO 경로에 없으면 ADEXP 파일의 다음 가까운 지점을 사용해 다시 찾도록 설계돼 있었음
  • 이 사건에서는 소프트웨어가 ADEXP의 다음 웨이포인트들을 따라가다가 ICAO 경로에 존재하는 중복 식별자를 찾음
    • 하지만 그 식별자는 실제 영국 공역 이탈 이후의 웨이포인트가 아니라 경로 초반에 있는 다른 지리적 웨이포인트였음
    • 결과적으로 진입 지점과 이탈 지점의 순서나 구간이 유효하지 않아 영국 공역에 해당하는 ICAO 구간을 추출할 수 없었음
  • NATS 보고서는 이 지점을 사건의 root cause로 지목했고, 사이버 관련 기여는 배제할 수 있다고 정리함

주 시스템과 백업 시스템이 동시에 멈춘 이유

  • 안전 중요 소프트웨어는 안전하게 계속 진행할 수 없을 때 수동 개입이 필요한 상태로 이동하도록 설계됨
  • FPRSA-R 주 시스템은 비행 계획의 올바른 데이터를 보장할 수 없다고 판단해 critical exception을 발생시킴
    • 로그 파일을 시스템 로그에 기록함
    • maintenance mode로 들어감
    • C&M 시스템은 주 시스템이 더 이상 사용 가능하지 않음을 감지함
  • 백업 시스템은 주 시스템 장애 시 처리를 이어받도록 설계돼 있었음
    • 별도 하드웨어, 별도 전원, 별도 데이터 피드에 위치함
    • 하지만 같은 비행 계획에 같은 로직을 적용했고 같은 결과로 critical exception을 발생시킴
  • ADEXP 메시지 수신부터 주 시스템과 백업 시스템이 모두 maintenance mode로 들어가기까지 20초 미만이 걸림
  • 08:32에 자동 비행 계획 처리가 중단됐고, 이후 4시간 완충 시간 안에서 수동 비행 계획 입력이 필요해짐

복구 절차와 운영 영향

  • 1st Line 지원팀은 전용 C&M 시스템과 중앙 C&M 시스템, 운영팀 피드백을 통해 장애를 인지함
  • 초기 대응은 중앙 C&M 시스템으로 하위 시스템을 재시작하는 표준 복구 절차였음
    • 여러 번의 복구 시도가 실패함
    • 2nd Line 엔지니어링 팀이 투입돼 현장 엔지니어를 원격 영상 링크로 지원함
  • 1st Line과 2nd Line이 서비스 복구나 정확한 원인 식별에 실패하자 Technical Design 팀과 하위 시스템 제조사 지원이 요청됨
  • 제조사는 낮은 수준의 소프트웨어 로그 분석을 통해 장애를 일으킨 것으로 보이는 비행 계획을 식별함
    • 해당 비행 계획을 이해한 뒤 통제되고 안전한 방식으로 시스템을 복구하는 정확한 절차를 제공함
  • 장애 시 수동 입력과 부문 간 수동 조정 절차가 포함돼 있었지만, 수동 절차로 전환하면 영국 교통 흐름을 줄이기 위해 항공 교통 관제 제한을 적용해야 했음

Frequentis AG와 FPRSA-R

  • FPRSA 하위 시스템은 NATS에 여러 해 존재했으며, 2018년에 기존 시스템이 Frequentis AG의 새 하드웨어와 소프트웨어로 교체됨
  • Frequentis AG는 오스트리아 회사이자 항공 교통 관제 시스템 공급자 중 하나임
  • 해당 제조사의 ATC 제품은 약 150개국에서 운영되고, 항공 정보 관리와 메시지 처리 시스템 분야에서 세계적 위치를 가진 것으로 알려짐
  • Frequentis AG의 채용 페이지에는 항공 교통 관제 시스템과 관련해 Ada, C++, Java, Python이 등장하며, Java가 가장 흔하게 보임

소프트웨어 버그와 테스트 문제

  • FPRSA-R는 IFPS가 수락한 유효한 비행 계획에서 영국 공역에 해당하는 ICAO 구간을 추출하지 못함
  • 웨이포인트 식별자는 전역적으로 유일하지 않으며, 이는 알려진 문제임
    • 중복 웨이포인트가 매우 멀리 떨어져 있으면 일반 비행 계획은 여전히 모호하지 않을 수 있음
    • 하지만 소프트웨어는 이 조건을 견고하게 처리해야 했음
  • NATS는 ICAO가 관리하는 전역 데이터셋에서 이 사건과 관련된 소수의 중복 웨이포인트 이름을 제거하는 방안을 영국 정부를 통해 검토할 수 있다고 밝힘
  • NATS CEO Martin Rolfe는 BBC에 이 사건이 “1,500만분의 1” 가능성이라고 말함
    • 해당 시스템은 2018년에 도입됐고, 그동안 1,500만 개 비행 계획을 처리했다고 말함
  • 안전 중요 시스템이라면 비행 계획 처리 단계, 특히 영국 구간 추출 같은 중요한 단계가 테스트돼야 함
    • 중복 웨이포인트 이름을 고려하지 않은 테스트는 이 버그를 드러내지 못했을 수 있음
    • 무작위 비행 계획을 대량으로 투입하는 퍼징(fuzzing) 은 시스템이 나쁜 실패 모드로 들어가는 입력을 찾는 데 도움이 됐을 수 있음

실패 모드의 문제

  • 단일 비행 계획이 전체 FPRSA-R 자동 처리 시스템을 멈췄고, 그 결과 어떤 비행 계획도 자동 처리되지 않았음
  • 더 나은 실패 모드는 문제가 있는 단일 비행 계획을 별도의 느린 큐로 보내 사람이 수동 처리하게 하는 방식임
  • NATS는 이미 진행 중이거나 완료한 조치로 IFPS와 FPRSA-R 사이 데이터 흐름에 특정 메시지 필터를 추가해, 사건을 일으킨 조건에 맞는 비행 계획을 걸러내겠다고 밝힘
  • FPRSA-R가 멈췄을 때 관련 비행 계획은 낮은 수준의 소프트웨어 로그에서야 식별됐음
    • 비행 계획 처리 시스템에서 특정 비행 계획 처리 오류가 전체 시스템을 멈추면, 해당 비행 계획을 포함한 알림이 모니터링 팀에 즉시 전달되는 편이 더 적절함
  • NATS는 같은 상황이 재발할 경우 FPRSA-R를 빠르게 복구할 수 있는 운영 지침을 마련했고, 기술 운영자들이 새 절차를 수행하도록 교육받았다고 밝힘
    • 강화된 모니터링과 추가 엔지니어링 전문 인력도 활동을 감독할 예정임

형식 검증 가능성

  • 이 사건의 해당 단계와 시스템에서 형식 검증이 사용된 흔적은 뚜렷하지 않으며, 보고서에도 언급이 없음
  • 형식 검증이나 모델 체킹은 이런 종류의 버그를 줄이는 데 도움이 됐을 수 있음
  • 다만 대규모 시스템의 종단 간 형식 검증은 아직 초기 단계이며, 형식 검증을 일부 사용했더라도 결함 코드가 운영 환경에 들어갈 가능성은 남아 있음
  • 최종 조사 결과가 나와야 실제로 어떤 검증 방식이 사용됐는지 더 알 수 있음

안전과 공개 보고

  • 영국 상공의 항공기는 사건 내내 안전하게 유지됐음
    • 경험 있는 항공 교통 관제사들이 알려진 비행 계획, 무전, 레이더, 시야를 통해 항공기를 모니터링함
    • 결과는 인명 위험이 아니라 훨씬 적은 항공편만 이륙할 수 있거나 영국 공역을 피해 우회해야 하는 상황이었음
  • NATS는 항공편 수를 줄이는 조치를 취해 안전을 유지함
  • 공개된 보고서는 상당히 투명하고 상세하며, 중요 인프라에는 이런 보고가 중요함
  • Ryanair의 Michael O’Leary는 해당 보고서를 “rubbish”라고 비판하고 항공 산업에 미친 영향을 축소한다고 말했지만, 초기 보고서의 범위가 NATS의 실패 정도를 분석하는 데 있지는 않았다는 평가도 있음

더 견고한 구현 방향

  • 문제는 두 시퀀스의 웨이포인트를 다루는 것임
    • ADEXP: 전체 웨이포인트 목록
    • ICAO: ADEXP 웨이포인트의 부분열
  • ICAO 계획에는 공역 진입·이탈 지점이 반드시 포함되지 않기 때문에, 영국 공역에 해당하는 ICAO의 가장 작은 연속 구간을 찾는 작업은 단순하지 않음
  • 잘못된 알고리듬의 문제는 ICAO 데이터와 ADEXP 데이터를 동시에 가리키는 포인터들을 조작하면서, 명확하지 않은 불변식을 코드 밖에 둔 점임
  • 제안된 접근은 먼저 ICAO와 ADEXP 데이터를 하나의 Combined 비행 계획 구조로 맞춰 보고, 그 뒤 영국 구간을 추출하는 방식임
    • 가능한 모든 reconciliation을 계산해 모호한 경우를 탐지함
    • reconciliation이 0개면 ICAO와 ADEXP를 맞출 수 없음
    • 여러 개면 모호하므로 수동 처리 대상으로 삼을 수 있음
  • Haskell 예제 구현은 NonUkPlan, CannotReconcileIcaoAdexp, AmbiguousReconciliationsOfIcaoAdexp 오류를 명시적으로 다룸
  • 예제에서는 ADEXP 목록에 중복 식별자 Q가 있어도 ICAO와 ADEXP 데이터가 모호하지 않게 맞춰지면 올바른 영국 구간을 반환함
  • 전체 코드는 uk-portion-of-ICAO에 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 비행계획 질의에 지리적으로 분리된 범위 제한을 빼먹은 셈임. 예전에 비행 항법 시스템을 만들면서 이 버그를 알고 있었고, 실제로 본 적도 있으며, 이 버그를 피하려고 지오펜스를 넣으라는 명세를 따른 적이 있음

    • 항법 지점 이름이 전역적으로 유일하지 않고 지역 간 항로가 흔하다면, 왜 이런 항법 지점에 GUID를 붙이지 않았는지 이해가 안 감
    • 궁금한데 개발에는 어떤 언어를 썼는지 알고 싶음
    • ICAO 표준은 1978년부터 식별자를 중복하려면 서로 600해리(690마일, 1,100km) 이상 떨어져 있어야 한다고 정해둠

  • “백업 시스템이 같은 논리를 비행계획에 적용했고 같은 결과가 나왔다”는 대목이 문제임. 소프트웨어에서는 백업 시스템이 다른 논리를 써야 함
    예전에 Boeing에서 757 안정판 트림 시스템을 다룰 때, 트림을 작동시키는 배선에 항공전자 컴퓨터 두 대가 붙어 있었고 비교기를 통해 연결됐음. 두 박스가 동의하지 않으면 둘 다 권한을 잃게 하는 구조였음
    두 박스는 서로 다른 알고리즘, 다른 프로그래밍 언어, 다른 CPU, 방화벽으로 분리된 다른 팀의 코드로 설계됐고, 한쪽의 버그가 다른 쪽을 같은 방식으로 망가뜨리지 않게 하려는 의도였음

    • 이건 조종사가 백업이 되는 2oo2 시스템이었을 텐데, 2oo2는 가용성이 높지 않음
      항공관제 시스템은 최소한 2oo3[1], 즉 독립 개발된 3개 시스템 중 항상 2개가 동의해야 하는 구조여야 함. 그래야 한 시스템이 실패해도 나머지 둘이 계속 운영되어 항공 산업의 가용성에 영향을 주지 않음
      사람을 백업으로 두는 건 인력과 복잡도 때문에 불가능함. 항공관제 시스템은 IFR[2]와 CVFR[3] 조건에서 분리 관제를 제공할 수 있어야 함
      [1] https://en.wikipedia.org/wiki/Triple_modular_redundancy
      [2] https://en.wikipedia.org/wiki/Instrument_flight_rules#Separa...
      [3] https://en.wikipedia.org/wiki/Visual_flight_rules#Controlled...
    • 읽으면서 같은 생각이 먼저 들었음. 이 장애 전환 시스템은 소프트웨어 버그보다는 하드웨어 장애 완화를 위해 설계된 것처럼 보임
    • “안전장치 시스템이 실패하면, 안전하게 실패하지 못하는 방식으로 실패한다”
      J. Gall
    • 서로 다른 팀도 같은 실수를 자주 함. 완벽한 구조는 아니지만, 설명한 방식은 타당해 보임
    • 곁가지지만, MAX에서 그런 접근을 알고도 재사용하지 않은 건 아쉬움

  • NATS에서 같은 효과를 낸 다른 문제도 있었던 걸로 기억함. 1차 시스템이 넘어져서 2차로 전환했는데, 2차도 정확히 같은 이유로 넘어졌음
    장애 전환은 문제가 1차 시스템 자체에 있고 소프트웨어 자체가 아니라는 걸 알 때만 해야 할 듯함. 그냥 전환하는 방식은, 실제로 무엇을 해야 하는지 판단할 만큼 충분한 정보가 노출되지 않았다는 느낌만 강화함
    더 속이 안 좋은 부분은 “ValidateFlightPlan” 같은 메서드가 없어서 어떤 이유로든 파싱할 수 없으면 오류를 던지고, 그 오류를 아주 단순하게 처리하는 경로가 없었다는 점임. 외부 입력 처리기를 보면서 “망가지는 나쁜 입력이 오면 뭘 하지?”를 생각하지 않는 프로그래머가 있을까 싶음

    • 1차 시스템이 정상 상태가 아니라고 알려져 있다면, 디스크가 탔거나 우주선에 의한 비트 뒤집힘 같은 문제였길 바라며 전환해볼 수는 있음
      진짜 안전 기능은 수동 처리가 필요해지기 전 4시간의 여유 시간임
      항공에서 핵심 안전 통제는 “애초에 어떻게 안 망가지게 할까”보다는 “어떤 이유로든 이게 망가지면 무엇을 할까”에 가까움
    • 검증이 없었다는 점과 함께, 글에서 이 대목이 눈에 띄었음
      프로그래밍 스타일이 매우 명령형이고, 설명만 보면 절차가 텍스트 파일에서 파싱한 자료구조가 아니라 비행계획의 텍스트 표현을 직접 다루는 것처럼 들림. 실제로 그렇다면 꽤 걱정스럽지만, 설명 방식 때문일 수도 있음
      이 설명대로라면 그냥 텍스트에 정규식이나 부분 문자열 매칭을 돌리고, 클래스나 객체나 자료구조가 없는 구조여도 놀랍지 않음. 영국 항공 전체가 의존하는, 다시 쓰거나 교체할 수 없는 수십 년 된 C 코드일 가능성도 감안해야 함
    • 하드웨어가 원인이 아니라고 판별할 방법이 없으니 장애 전환 자체는 맞음. 다만 두 번째 실패가 발생했을 때의 대응을 더 잘 설계해서 연쇄 효과를 피했어야 함
    • 전기적으로 보면 퓨즈를 갈아 끼운 뒤 다시 터지는 걸 지켜본 셈임. 가게에는 더 이상 퓨즈가 없음. 이게 진전인가?
    • Ariane 5 발사 실패[1]도 비슷한 문제였고, 결과는 훨씬 더 장관이었음
      1차 시스템이 정수 오버플로로 실패했고, 동일한 2차 시스템도 같이 오버플로됨. 받음각이 증가하고 부스터가 분리되고, 로켓이 폭발함
      [1] https://en.wikipedia.org/wiki/Ariane_flight_V88

  • 왜 실패한 비행계획만 사람 검토 대기열에 넣고 나머지 비행은 계속 처리하지 못했는지 모르겠음. 그 “기능”이 없었다는 점이 가장 이해하기 어려움

    • 코드가 그 오류를 “이건 절대 일어나면 안 됨!”으로 분류했고, 실제로 그 일이 일어난 것임. “비행계획 데이터가 나쁨”이나 “데이터는 맞지만 아직 지원하지 않음”으로 분류하지 않았음
      “절대 일어나면 안 됨” 오류가 발생하면 시스템에 무엇이 잘못됐는지, 영향이 얼마나 크고 넓은지 알 수 없음. 이번처럼 계속 진행해도 됐을 수도 있지만, 소프트웨어에 치명적인 새 버그가 생겨 다른 모든 비행계획을 조용히 오염시키고 사람을 죽일 수도 있음. 계속해도 안전한지 모르면 멈춰야 함
    • 공정하게 보면 글 초반에 이 비행계획들이 이미 비행 중인 항공기에 대해 처리되는 경우도 있다고 나옴. 적어도 영국까지 4시간 이상 떨어져 있긴 하지만
      문제가 있는 특정 비행기가 이륙하지 못하게 막을 수 있다면 시스템을 계속 돌려도 괜찮지만, 이미 공중에 떠 있다면 얘기가 달라짐
      “영국 공역에 들어올 항공기가 항로 중인데 언제 어디로 들어올지 모른다. 그 항공기 위치를 알 때까지 추가 비행계획을 멈춘다”는 판단이 완전히 불합리하진 않음
      비행계획을 정말 처리할 수 없다면, 영국에 도달하기 전에 해당 항공기를 우회시켜 착륙시키는 식의 해법이 합리적일 수 있지만, 그런 건 결국 수동 개입을 기다려야 하는 일임
    • 글과 사후 분석 모두 FPRSA-R 시스템의 나쁜 실패 모드를 주요 문제로 봤고, 이게 가장 중요한 부분이라고 봄
      모든 시스템은 오작동할 수 있으니, 중요한 건 좋은 방식으로 오작동하고 담당자들이 그 상황에 대비하는 것임
      단일 비행계획 하나가 문제를 일으켰고 전체 FPRSA-R 시스템이 죽어 비행계획이 전혀 처리되지 않았음. 비행계획 하나에 문제가 있으면 사람이 수동 처리할 별도 느린 대기열로 옮겨야 함. NATS도 “이미 수행했거나 진행 중인 조치”에서 IFPS와 FPRSA-R 사이 데이터 흐름에 해당 조건의 비행계획을 걸러내는 메시지 필터를 추가한다고 인정함
    • 안전 필수 시스템에서 “알 수 없는 오류”를 맞으면 모든 불변 조건이 깨졌고 정의되지 않은 동작에 들어갔다고 가정해야 해서 멈출 수밖에 없음
      이게 알려진 오류로 처리됐어야 한다는 말은 타당하지만, 넓게 보면 “버그 없는 코드를 썼어야 한다”는 말과 비슷함. 구조체로 파싱했더라도 선택 키가 있다고 가정한 코드에서 갑자기 KeyError가 튀어나온 것과 같을 수 있음
      이런 일의 사후 분석과 개선은 예측할 수 없는 미처리 알 수 없는 오류가 언젠가는 발생한다는 전제를 두고, 그때 어떻게 더 잘 처리할지를 다뤄야 함. 버그의 해법은 버그를 고치는 것이지만, 대형 장애의 원인은 합리적 시간 안에 실행할 수 없는 재해 복구 계획이었음. 어떤 프로그래밍 관행, 스타일, 언어, 도구를 쓰든 비슷한 급의 사건은 최고의 개발자들이라도 언젠가 확률 1로 다시 생김
    • 글에 설명된 알고리즘은 입력 비행계획의 경유지를 순서대로 따라가는 단순 절차 코드가 아닐 가능성이 큼. 어떤 추상화 때문에 이게 입력 오류라는 사실이 가려졌을 수 있음
      코드 입장에서는 기반 항법 경유지 데이터베이스의 무결성 실패처럼 보였다면, 비행계획 처리를 중단하는 판단이 훨씬 이해됨
      예를 들어 코드가 경유지와 항로 저장소에 “이 항로가 영국 공역을 벗어나는 경유지를 찾아줘”라고 묻고, 그 경유지를 포함하는 항로 구간을 찾은 다음, 그 구간이 영국 공역을 지난다고 단언했는데 그 단언이 실패했다면, 이는 비행계획 문제가 아니라 항로 데이터에 내장된 가정이 깨진 것처럼 보일 수 있음
      어떤 의미에서는 실제로 치명적 버그일 가능성도 있음. 이 사건은 알고리즘이 데이터에 대해 세운 가정이 틀렸고, 잠재적으로 잘못된 답을 반환할 수 있음을 보여줌

  • 관련 글들
    우연히 같은 경유지 이름 때문에 영국 항공관제 시스템이 속음 - https://news.ycombinator.com/item?id=37430384 - 2023년 9월, 댓글 64개
    나쁜 비행계획 데이터가 영국 항공관제 장애를 일으킴 - https://news.ycombinator.com/item?id=37402766 - 2023년 9월, 댓글 20개
    NATS 항공관제 사고 보고서가 근본 원인과 해법을 상세히 밝힘 - https://news.ycombinator.com/item?id=37401864 - 2023년 9월, 댓글 19개
    영국 항공관제 네트워크 장애 - https://news.ycombinator.com/item?id=37292406 - 2023년 8월, 댓글 23개

    • The Daily의 최근 미국 항공 산업 에피소드를 듣고 나니, 머지않아 참사성 헤드라인을 보게 될 거라는 확신이 들었음. 이런 식으로는 계속 갈 수 없음
    • 이 글 제목을 보고 지금 새로 발생한 장애인 줄 알았음

  • Eurocontrol이 이미 받아들인 프랑스 비행계획을 탓했다는 사실은, 이들이 소프트웨어가 어떻게 동작하는지 제대로 몰랐다는 증거임. 그리고 오스트리아 회사도 집중적인 테스트 부족에 대한 책임을 일부 져야 함

    • 영국이라서 프랑스를 탓한 것뿐임. 나쁜 습관은 떨쳐내기 어려움

  • 훌륭한 글임. 읽어보면 요지는 이렇다고 봄
    전 세계에서 쓰는 경유지 이름은 유일하지 않고, 혼동을 피하려는 일종의 땜질로 최신 표준은 같은 식별자를 지리적으로 충분히 멀리 떨어뜨리라고 함. 그래도 하나의 항로에서 같은 경유지 이름이 서로 다른 위치를 뜻할 수 있음
    소프트웨어는 그 가능성을 고려하지 않았고, 항로 계산이 실패했으며, “치명적 예외”를 던지고 “유지보수 모드”에 들어감. 즉 죽었음
    백업 시스템이 이어받았지만 같은 데이터로 같은 버그를 맞아 역시 죽었고, 지원 인력은 고생했음. 결국 소프트웨어 공급사에 연락한 뒤에야 원인을 드러내는 저수준 로그를 찾았음

    • 이런 수준의 임무 필수 시스템에 왜 코드에 익숙한 사람이 24시간 7일 호출 대기 중이 아닌지 이해할 수 없음
    • 핵심은 적절한 이름공간이 없었다는 점임. 항공우주 엔지니어가 운영체제를 공부해야 한다니 누가 알았겠나 싶음
      은퇴한 공군 조종사 친구가 Cranfield University를 졸업했는데, 이곳은 영국의 대표적인 항공우주공학 대학원 기관이고 교육·연구용 자체 공항도 있음[1]. 그 친구가 Cranfield에서 운영체제를 배웠다고 했는데, 이제야 이유를 알겠음
      다른 댓글들을 보면 이름공간 표준은 이미 있지만 NATS/ATC가 쓰지 않는 듯함. 이번 일을 계기로 제발 쓰기 시작했으면 함. 최상위 댓글은 지오펜싱 버그를 말했지만, NATS/ATC가 올바른 이름공간을 쓰고 있었다면 지오펜싱은 애초에 필요 없었을 가능성이 큼
      [1] Cranfield University:
      https://en.wikipedia.org/wiki/Cranfield_University

  • “설명만 보면 절차가 텍스트 파일에서 파싱한 자료구조가 아니라 비행계획의 텍스트 표현을 직접 다루는 것처럼 들린다. 실제로 그렇다면 꽤 걱정스럽지만, 설명 방식 때문일 수도 있다”
    항공 산업 작업에서는 이런 방식이 흔함. 프로그래머에게 도메인 모델이나 파싱을 물어보면 멍한 표정을 짓곤 함. 검증 코드를 좋아하고, 검증이 안 되면 그냥 포기하는 걸 좋아함. 전부 멍청한 데이터 파이프라인이고, 현실 세계에서 일어나는 활동을 모델링하는 코드가 전혀 없음
    어떤 시스템에도 동작을 가진 “비행계획” 타입이나 경유지 타입 집합 같은 건 없음. 타입이 있어도 C 관점의 문자열 구조체이고, 그 구조체 멤버가 접근될 때마다 한 번도 아니고 매번 파싱됨. 글에서 말하듯 “프로그래밍 스타일은 매우 명령형으로 보인다”가 맞음

    • 검증 실패 시 포기하는 건 잘못 해석된 데이터를 퍼뜨려 훨씬 복잡한 버그를 낳지 않기 위한 표준적인 방식이긴 함. 빨리 검증하고, 강하게 검증하고, 오류를 보고하고, 입력의 어디가 이상한지 억지로 해석하려 들지 말아야 함. “똑똑하게” 굴려는 순간 안전 구멍이 생김
      나쁜 입력에서 죽는 건 잘못이지만, 명세도 없이 검증되지 않은 데이터를 해석하려 드는 건 이후의 이해 불일치와 호환성 문제, 예상치 못한 경계 조건을 부르기 쉽다. 완전 테스트된 모든 경우 대응 시스템, 잘못된 입력 시뮬레이션 도구, 파서와 파서 결과를 쓰는 모든 코드의 형식 검증에는 아무도 비용을 내고 싶어 하지 않음
      이미 비준수·레거시·버그 있는 데이터 송신기와 인터페이스 의미론·타이밍 복잡도 때문에 문제가 많음. 형식이나 인코딩이 잘못된 데이터에 똑똑하게 대응하려 하면 더 위험해짐
      명세대로 작동하는 시스템을 만드는 것만으로도 어렵고 비쌈. 명세되지 않은 동작을 더 관대하게 받아들이는 미묘한 변형은 버그를 요청하는 일이거나, 구매 가격 기준을 넘지 못하는 더 비싼 시스템을 만드는 일임
    • 아주 흥미롭고 조금 무섭기도 함. 서로 다른 산업이 딱히 명확하지 않은 이유로 각자 다른 개발 문화를 만들어왔다는 점이 재미있음

  • “영국 항공관제: 프랑스 오류가 장애를 일으켰는지 조사”
    당연히 아니지. 영국 시스템인데 어떻게 프랑스 항공사의 잘못이 되나? 이런 시스템은 중복성을 갖춘 오류 방지 구조여야 함
    항목 하나가 나쁘면 거부하고 계속 진행하는 것만으로도 충분했을 수 있음

    • 굳이 민족주의적으로 따지자면, 그 소프트웨어는 오스트리아산이었음

  • 기억하고 싶지 않은 하루였음. 원래 2시간이면 갈 목적지에 15시간이 걸렸음
    기차, 버스, 다시 기차를 탔고, 표를 예매한 지 30분 뒤에는 이틀 치가 모두 매진됐음

    • 공항에서 6시간 기다린 뒤에야 비행기가 취소됐다는 걸 알았고, 다시 예약해야 했음. 가족을 보러 New York에 가는 길이라 대체 교통수단도 딱히 없었음
답변달기