“비행기가 더 안전하다.”

이 말은 사실이다. 자동차 이동과 비교하면 통계적으로 비행이 훨씬 안전하다. 비행을 두려워하는 사람에게 우리는 늘 이렇게 설명한다. 수치상으로 보면 비교 자체가 되지 않을 정도라고 말이다.

그럼에도 불구하고 필자의 지인 중 가장 총명하다고 할 만한 두 명은 이 통계를 인정하면서도 끝내 비행기를 타지 않는다. 필자는 비행기에 오를 때마다 이들을 떠올린다. 멕시코 휴가를 마치고 제트블루 항공편을 타고 돌아오던 날도 다르지 않았다. 그 비행 경로는 몇 주 전 북쪽으로 향하던 또 다른 제트블루 항공편이 지나갔던 길과 일부 겹쳤다.

그 항공편 역시 휴가객으로 가득 차 있었을 것이다. 2025년 10월 30일, 멕시코 칸쿤 국제공항을 출발해 뉴어크 리버티 국제공항으로 향하던 에어버스 A320 기종의 제트블루 1230편 이야기다. 다음 날 뉴욕타임스 보도에 따르면, 멕시코 휴양지를 떠난 지 약 두 시간 반이 지난 시점, 항공기는 갑작스러운 고도 하강으로 잠들어 있던 승객을 깨웠다. 원치 않는 곡예 비행과 같은 상황이 끝난 뒤, 제트블루 조종사들은 탬파에 비상 착륙하는 데 성공했다. 15명 이상이 탬파의 병원에서 치료를 받게 되며 사실상 휴가를 연장해야 했다.

제트블루 측은 점검을 위해 해당 항공기를 운항에서 제외했다고 밝혔다.

민간 항공 분야에서는 사고나 사건이 간헐적으로 발생하고, 극히 예외적인 경우에는 대형 사고로 이어지기도 한다. 일반 승객 입장에서는 이런 사례에 대한 보도를 접하는 일이 아주 낯설지는 않기 때문에, 보다 광범위한 흐름이나 반복되는 패턴이 드러나기 전까지는 이번과 같은 뉴스 역시 일단 마음 한편에 접어두게 된다.

특히 보잉 737 맥스(Max) 결함 사태 이후 유사한 사건이 주로 보잉 항공기에서 발생해 왔다는 점을 고려하면, 그리고 만약 이야기가 여기서 끝났다면 이번 상황도 보잉 기종이었다면 그저 그런 사례로 넘겼을 것이다. 그러나 이번 제트블루 항공편에 투입된 항공기와, 필자가 앉았던 항공기는 모두 에어버스 기종이었다. 에어버스는 2024년 2월 미 연방항공청(FAA) 보고서가 지적한 ‘보잉의 안전 여정에서 드러난 공백’과는 상대적으로 거리가 있는 항공기로 인식됐다.

‘바로 이 항공기였구나.’ 필자는 속으로 그렇게 생각했다. 그렇다면 이후 진행된 조사는 무엇을 밝혀냈을까? 기계적 결함이었을까, 소프트웨어 문제였을까? 가능성은 낮지만, 혹시 악성코드 같은 요인이었을까?

원인은 우주 방사선, 해법은 소프트웨어 롤백?

뉴욕타임스는 필자가 JFK로 돌아온 날과 같은 날인 11월 28일, 해당 조사 결과를 충실히 전하는 기사를 게재했다. 이 기사는 에어버스의 보도자료를 일부 인용해 구성됐으며, 다음과 같은 내용으로 시작했다.

유럽 항공기 제조사 에어버스는 최근 발생한 한 사건을 통해 “강력한 태양 복사가 비행 조종 시스템의 작동에 핵심적인 데이터를 손상시킬 수 있음이 드러났다”라고 밝혔다.

이는 태양 활동과 연관된 고에너지 방사선이 전자 데이터에 오류를 일으킨다는 의미다. 뉴욕타임스에 따르면, 이 문제는 에어버스 A320 기단과 이를 운용하는 항공사 전반에 광범위한 영향을 미칠 수 있다. 전 세계 항공사가 A320을 얼마나 채택했는지를 분석한 결과, 최대 6,000대의 항공기가 영향을 받을 수 있으며, 일부 기체는 하드웨어 변경이 필요할 가능성도 있는 것으로 나타났다.

‘영향이 상당하겠는데’라고 생각하며 이어진 문장을 읽었다.

대부분 경우 이 문제는 이전 소프트웨어 버전으로 되돌리는 방식으로 비교적 신속하게 해결할 수 있다.

잠깐만.

오래된 위험, 새로운 의문

그렇다면 이런 방사선 영향은 얼마나 자주 발생하는 걸까? 물리적 원리는 무엇일까?

이 문제에는 과학사의 맥락이 있다. 노벨상 수상자인 빅터 헤스는 제1차 세계대전 이전, 기구를 타고 고고도로 올라가 방사선 수치를 측정하는 실험을 통해 우주 방사선(cosmic ray)의 존재를 처음 밝혀냈다. 1960년대에 이르러서는 우주 프로그램에서 승무원 건강에 영향을 미칠 수 있는 요인으로 주목받기 시작했다. 1975년에는 위성에서 발생한 이상 현상이 방사선으로 인한 ‘단일 이벤트 업셋(single-event upset, SEU)’으로 규정됐고, 1979년에는 해수면 고도에서도 전자 장치가 방사선의 영향을 받을 수 있다는 사실이 알려졌다.

1990년 FAA는 항공 승객에게도 이런 위험이 존재한다는 점을 공식적으로 인정했다. 컴퓨터 의존도가 높은 플라이 바이 와이어(fly-by-wire, FBW) 항공기인 에어버스 A320은 항공우주 공학 분야에서 이 현상이 이미 충분히 이해되던 시기에 설계됐다.

당시의 소프트웨어 엔지니어라면 SEU에 대응하기 위해 하드웨어와 소프트웨어 차원의 대비책이 모두 필요하다는 점을 알고 있었을 것이다. 오류 정정 코드(error correction code, ECC) 메모리 같은 기술이 대표적이다. 비트 하나가 뒤집히면서 비정상적으로 범위를 벗어난 명령이 생성되는 상황을 감지하기 위한 무결성 검사 역시 필요하다.

그렇다면 의문이 생긴다. 2025년 말, A320의 문제를 해결하는 방법이 왜 소프트웨어를 이전 버전으로 되돌리는 것일까? 방사선으로 인한 SEU에 대응하는 기능이 최신 버전에 있다면, 이전 버전에도 동일한 기능이 포함돼 있었을 가능성이 크지 않을까? 아니면, 기존 접근법을 대체할 새로운 방식이 최근 버전에 도입됐다가 오히려 문제를 키웠던 것은 아닐까?

에어아시아 창업자 “테스트 부족 명백”

이 지점에서 소프트웨어 품질 엔지니어로서의 자아가 반응하기 시작했다. 방사선 이야기는 사건의 핵심과는 어딘가 어긋나 보였기 때문이다. 전체 맥락에서 보면, 방사선이라는 요소는 오히려 이상할 정도로 부차적인 문제처럼 느껴졌다. 의문을 품은 사람은 필자뿐만이 아니었다.

토니 페르난데스는 에어아시아 항공 그룹 설립자다. 에어아시아는 현재 상당수의 에어버스 항공기를 운용하고 있으며, 추가로 약 400대에 달하는 에어버스 항공기를 주문한 상태다. 페르난데스는 최근 인터뷰에서 이번 사안에 대한 우려를 공개적으로 드러냈다.

페르난데스는 사우스차이나모닝포스트(South China Morning Post)와의 인터뷰에서 “조금 이상하게 느껴진다. 에어버스가 반드시 들여다봐야 할 문제이며, 충분한 테스트가 이뤄지지 않았던 것이 명백해 보인다”라고 지적했다. 페르난데스는 에어버스가 2025년 항공기 820대 생산이라는 목표를 맞추기 위한 부담 속에서 무리한 일정에 놓여 있을 가능성도 언급했다.

방사선 서사와는 별개로, 표면적인 원인은 엘리베이터·에일러론 컴퓨터(Elevator Aileron Computer, ELAC 2) 소프트웨어 문제로 설명됐다. 이 시스템은 조종석의 사이드스틱 입력을 항공기 후방의 승강타로 전달해 기체의 피치와 롤을 제어하는 역할을 한다. 문제 해결을 위해 적용된 소프트웨어 롤백은 ‘L104’ 버전을 ‘L103’으로 되돌리는 방식이었다. ELAC 하드웨어 개발사인 탈레스는 해당 소프트웨어는 자사의 책임 범위에 속하지 않는다고 로이터통신에 밝혔다.

뉴어크로 향하던 제트블루 항공편에서 승객들이 경험한 갑작스러운 기수 하강 현상은 A320에만 국한된 문제가 아닐 수 있다. A319와 A321 시리즈의 여러 변형 기종도 영향을 받는 것으로 알려졌다. 한 추산에 따르면, 에어버스의 발표가 있었던 시점 전 세계 하늘에는 3,000대가 넘는 A320 계열 항공기가 운항 중이었다. 기내 와이파이를 통해 이 소프트웨어 취약성 관련 소식을 접한 11월 28일의 승객들이 머릿속으로 자신만의 안전 계산을 다시 해보는 장면이 떠오른다.

SDLC가 남긴 4가지 교훈

자극적으로 소비되는 ‘태양 복사’나 ‘우주 방사선’ 이야기 너머에는, 에어버스가 진지하게 짚고 넘어가야 할 소프트웨어 개발 생명주기(SDLC)에 대한 문제가 있다. 여기서 도출할 수 있는 핵심 교훈은 모두에게 익숙한 4가지로 정리된다.

• 테스트 엔지니어링
• CI/CD와 파이프라인 품질
• 관찰 가능성
• 공급망

눈여겨볼 점은, 이 목록에 ‘코딩’이 포함되지 않다는 사실이다. 물론 L104 버전에서 빌드 패키징 실수가 있었을 수도 있고, 서비스 호출이 실수로 삭제되거나 API 파라미터가 잘못 구성 또는 이해됐거나, 소스 코드에 문법 오류가 있었을 가능성도 배제할 수는 없다. 그러나 이런 문제는 소프트웨어 개발에서 흔히 발생하는 것으로, 정상적인 SDLC라면 충분히 대응할 수 있다.

먼저 테스트 엔지니어링이다. 적절한 테스트 하네스가 있었다면 ELAC의 범위 검사(range check)를 호출해야 했던 비정상 텔레메트리를 충분히 시뮬레이션할 수 있었을 것이다. 테스트 하네스는 소프트웨어 개발 이후 별도의 단계로 붙이는 것이 아니라, 개발과 동시에 설계·구축돼야 한다.

CI/CD와 파이프라인 품질도 핵심이다. 여기에 변경 관리나 구성 관리까지 포함해 볼 수 있다. L104 개발 과정에서 에어버스가 CI/CD를 실제로 활용했는지와는 별개로, 향후 SDLC는 분명 그 방향으로 갈 수밖에 없다. 이번 사례는 SDLC 파이프라인 어딘가에서 문제가 발생해, 핵심 기능이 퇴행(regression)하는 상황을 허용했다. 이것이 일회성 실수일 가능성이 낮다.

관찰 가능성 역시 중요하다. 이 항목을 포함한 이유 중 하나는 필자가 IEEE에서 새로운 데브옵스 표준에 관측 가능성 원칙을 반영하는 소규모 작업 그룹에 참여하고 있기 때문이다. SEU는 관측 가능성이 왜 필요한지를 잘 보여주는 사례다. 테스트 엔지니어는 우주 방사선이 실제 발생하기를 기다릴 수는 없지만, 치명적인 SEU 이벤트에 시스템이 제대로 대응하지 못하는 상황은 반드시 감지할 수 있어야 한다. 이를 위해서는 요구사항 엔지니어링을 더 정교하게 수행하고, 핵심 기능에 필요한 텔레메트리를 정확히 이해해야 한다.

공급망 문제도 빼놓을 수 없다. 탈레스는 L104 문제를 일으킨 소프트웨어 릴리스에 직접 관여하지 않았을 수 있지만, 에어버스 플랫폼은 다수의 업체가 제공한 소프트웨어와 하드웨어로 구성된다. 컴퓨팅 공급망 전반에서의 통합은 안전 요구사항과 제품 수명 주기가 긴 항공 산업 특성상 더욱 복잡한 과제가 된다. 탈레스의 ‘우리 책임이 아니다’라는 반응은 공동 정보 공유와 문제 해결 체계에 균열이 있거나, 서드파티 리스크 관리 조직의 가시성이 제한돼 있음을 시사할 수 있다.

상황은 여기서 더 악화될 수도 있다. SDLC의 이 4가지 영역 중 어느 하나라도 허점이 생기면, 항공 전자 시스템에 있어 최악의 시나리오인 악성코드 침투 가능성이 열리게 된다. 이는 결코 가볍게 넘길 수 없는 위험이다.

AI 도입은 해법일까, 새로운 복잡성일까?

여전히 해소되지 않은 2가지 구조적 위험이 있다. 바로 복잡성과 전문화다. A320의 전체 기능 세트는 물론, 소프트웨어 자재 명세서(SBOM)나 API 자재 명세서(API-BOM)만 관리하는 것만 해도 결코 간단한 일이 아니다.

A320은 1987년 출시된 제품으로, 방대한 운용 기단 전반에 걸쳐 기존 하드웨어와 소프트웨어를 계속 지원해야 한다는 부담을 안고 있다. 복잡성과 전문화는 앞으로도 점점 더 불투명해질 가능성이 크다. 이는 추적 가능성, 투명성, 관리 용이성을 확보하려는 시도를 계속해서 어렵게 만들 것이다.

다른 기업과 마찬가지로 에어버스 역시 이런 문제를 해결하기 위해 AI를 도입할 가능성이 크다. 어쩌면 다음 소프트웨어 버전인 L105에서 그 모습을 볼 수도 있다. 하지만 AI의 도입은 필요한 전문 영역을 늘리는 동시에, 항공기 전체의 복잡성도 한층 더 키울 수밖에 없다.

전반적인 AI 기술에 대한 대중의 불안감이 여전히 존재하는 상황에서 “비행기가 더 안전하다”라는 전제가 언제 흔들릴지, 그런 날이 올지 두려워진다.
dl-itworldkorea@foundryco.com