Hacker News 의견

• 기사에서 가장 중요한 정보가 맨 아래에 묻혀 있었음
  항공기 제조사가 태양 복사선이 비행 제어에 중요한 데이터를 손상시킬 수 있음을 발견했다고 밝힘
  대부분은 간단한 소프트웨어 업데이트로 해결 가능하다고 함
  멕시코에서 미국으로 향하던 JetBlue 항공편이 갑작스러운 고도 하락을 겪은 뒤 긴급 착륙했고, 15~20명이 경상을 입었다고 함
  이 사건의 원인이 강한 태양 복사선으로 인한 컴퓨터 데이터 손상으로 추정됨

  • 2008년 Qantas 72편 사고에서도 비슷한 전력 스파이크가 있었음
    당시 ADIRU가 오작동했고, 비행 데이터 기록기에도 동일한 패턴의 손상이 남았음
    이런 현상은 고장난 솔리드 스테이트 릴레이의 전형적인 신호로 보임
    반면 복사선에 의한 비트 플립은 시간과 에너지 면에서 포아송 분포를 따르므로, 이를 통해 원인을 구분할 수 있음
  • 좀 더 기술적인 분석 기사가 필요하다고 생각함
    Airbus의 비행 제어 컴퓨터는 세 가지 CPU(AMD, Intel, Motorola)로 삼중 중복 구조를 갖추고 있음
    이런 시스템에서 비행이 방해받았다면 경보가 다수 발생했어야 함
    관련 논문은 여기에서 볼 수 있음
  • 실제로는 업데이트가 아니라 롤백이었다고 함
    관련 내용은 PPRuNe 포럼 글에서 확인 가능함
  • 복사선 문제를 소프트웨어로 해결할 수 있다는 점이 흥미로움
  • 이 원인이 얼마나 확실한지, 그리고 통제된 환경에서 재현이 가능했는지 궁금함
    강한 태양 복사선이 실제로 존재했다는 증거도 명확히 공개되면 좋겠음
    태양 복사선이 원인일 수는 있지만, 때로는 설명되지 않는 현상을 포괄하는 핑계로 쓰이기도 함

• 그래도 사고가 나기 전에 조치를 취한 건 다행임

  • 잠재적 문제가 있을 때 취해야 할 올바른 엔지니어링 대응임
  • 하지만 실제로는 비행 중 문제가 발생한 뒤에야 발견된 것임
    더 심각한 결과로 이어질 수도 있었음
  • 이런 일이 품질 보증(QA) 체계에 대해 무엇을 말해주는지 의문임
    Airbus를 비난하려는 건 아니지만, Boeing을 향한 얕은 조롱은 불편함
    JetBlue 사건은 결코 가벼운 일이 아니었음
    Airbus도 AF447 사고나 1988년 Habsheem 에어쇼 추락 같은 논란에서 자유롭지 않음
  • “I ain’t going” 같은 태도는 예전에도 사고 몇 번쯤은 개의치 않았던 것 같음

• 관련 논의는 이 스레드에서도 이어지고 있음

• SpaceX는 이 문제를 극단적인 중복 하드웨어 구성으로 해결했다고 들음
  즉, 더 많은 하드웨어를 병렬로 설치하는 방식이 해법일 수도 있음

• Boeing이라면 이런 문제를 예산 항목에 포함시켜 무시했을지도 모른다는 농담이 나옴

  • 근거가 무엇인지 묻는 반응도 있었음

• 태양 복사선 간섭으로 비행 제어 컴퓨터의 데이터가 손상되었다는 점이 무섭게 느껴짐
  조종사의 입력과 실제 제어면 사이에 컴퓨터 프로그램이 존재한다는 사실이 불안함
  이런 시스템이 실제로 작동한다는 게 놀라움

  • 하지만 기계적 고장도 언제든 발생할 수 있음

• 그래도 이런 문제를 책임감 있게 대응하는 기업이 남아 있다는 게 다행임

• 전 세계 언론이 같은 비논리적인 보도를 그대로 퍼뜨리는 게 이상함
  기사 작성자 중에 엔지니어와 결혼한 사람조차 없는 건가 싶음
  시간이 꽤 흘렀는데도 여전히 명확한 해석이 나오지 않음

• 혹시 이 그래프가 원인일까 싶음
  태양 주기 진행 그래프를 보면 흥미로움

  • 예측 가능한 태양 주기를 “근본 원인”이라 부르는 건, xkcd의 Bobby Tables 엄마를 SQL 인젝션의 원인이라 하는 것과 같음