[뉴스스페이스=이승원 기자] 보잉 737맥스(MAX)에서 착륙을 포기하고 재상승하는 복행(go-around) 상황 뒤 자동 비행유도 기능 일부가 해제될 수 있는 소프트웨어 문제가 드러났다. 보잉은 “즉각적인 안전 위험은 아니다”라고 선을 그었지만, 미 연방항공청(FAA)이 시정조치 검토위원회(CARB)를 가동하기로 하면서 문제의 본질은 단순한 결함 자체보다 위험 판단·통지 시점·인증 관리의 적정성으로 확장되고 있다.

복행 뒤 ‘VNAV 이탈’…문제는 가장 바쁜 구간

reuters, aerotime, cbsnews, migflug, telanganatoday에 따르면, 이번 문제는 737맥스 비행관리컴퓨터(FMC)의 운영 소프트웨어 버전 14 및 14.1과 관련된 것으로 알려졌다. 정밀접근 중 자동조종장치가 켜진 상태에서 착륙을 중단하고 복행한 뒤, 승무원이 사전에 입력된 비행경로를 수정하는 특정 조건에서 수직항법(VNAV·Vertical Navigation)이 해제될 수 있다는 내용이다. VNAV는 항공기가 경로상의 각 지점에서 계획된 고도와 상승·하강 프로파일을 자동으로 관리하도록 돕는 기능이다.

핵심은 ‘자동조종장치 전체가 꺼지는가’와 ‘자동화 수준이 낮아지는가’를 구분하는 데 있다. 보잉은 VNAV가 해제돼도 자동조종장치는 계속 작동하며, 기체는 더 단순한 형태의 자동 피치 제어로 전환될 수 있다고 설명했다. 즉 “항공기가 즉시 조종 불능 상태에 빠진다”는 의미는 아니다. 다만 다음 접근 과정에서 조종사가 자동화 기능을 복구하거나 수동으로 추가 조작을 해야 할 수 있어, 저고도·기상악화·관제 지시 변경 등이 겹치는 복행 국면에서 승무원 업무부하를 높일 수 있다는 우려는 남는다.

복행은 비정상 상황만을 뜻하지 않는다. 활주로 점유, 돌풍, 시정 악화, 앞선 항공기의 난류, 불안정 접근 등 여러 사유로 정상적인 안전 절차에 따라 실시될 수 있다. 따라서 결함 발생 조건이 좁더라도, 항공안전 관점에서는 “발생 가능성이 낮다”는 설명만으로 충분하지 않다. 해당 조건에서 비행 승무원이 얼마나 신속하게 시스템 상태를 인지하고, 절차대로 재설정하며, 수동 비행으로 안전 여유를 유지할 수 있는지가 규제당국의 평가 대상이 될 전망이다.

보잉 “안전 위험 아니다” vs FAA “CARB 소집”

보잉은 지난 8월 모든 737 운항사에 해당 소프트웨어 문제를 알렸으며, 기존 조종사 절차만으로도 안전하게 대응할 수 있다는 취지의 정보를 공유했다고 밝혔다. 보잉은 영구적 해결을 위한 소프트웨어 업데이트와 함께, 문제가 발생했을 때 조종사가 VNAV를 다시 활성화할 수 있도록 하는 운항 절차도 항공사들과 마련 중이다.

그러나 FAA의 대응은 보잉의 자체 판단만으로 사안을 종결하지 않겠다는 신호다. FAA는 “일부 737맥스 항공기의 비행컴퓨터 소프트웨어 업데이트에서 잠재적 문제를 인지하고 있으며 보잉 및 항공사와 긴밀히 협력하고 있다”고 밝혔다. 이어 시정조치 검토위원회(CARB)를 소집하고, 안전 우려가 확인되면 즉각 조치하겠다고 공식화했다.

현재 영향을 받는 항공기 대수는 명확히 공개되지 않았다. 항공사가 소프트웨어 업데이트 사실을 제조사에 의무적으로 보고할 필요가 없는 구조여서, 보잉이 기체별 설치 현황을 역추적해야 하는 상황으로 전해진다. 이는 항공기 감항성 관리에서 하드웨어 부품 추적성만큼이나 소프트웨어 구성관리(configuration management)가 중요해졌다는 점을 보여준다. 소프트웨어 버전이 같아 보여도 항공사별 도입·업데이트 일정이 다를 수 있기 때문이다.

“2024년 인지, 2026년 통지”…더 큰 쟁점은 대응 속도

CBS 뉴스는 보잉이 한 항공사로부터 이 문제를 처음 통보받은 시점이 2024년 11월이라고 보도했다. 보잉은 이를 검토한 뒤 2025년 2월 당시에는 안전 문제가 아니라고 판단했지만, 올해 운항사들로부터 추가 정보를 받은 뒤 정식 안전검토위원회를 가동했고, 그 결과를 이달 FAA에 제출한 것으로 전해졌다.

이 보도가 사실이라면, 이번 사안의 가장 민감한 대목은 결함의 존재보다 안전성 판단이 어떻게 달라졌고, 왜 운항사 통지가 2026년 8월까지 이어졌는가다. 보잉이 최초 인지 단계에서 어떤 시험·시뮬레이션·운항 데이터 분석을 실시했는지, 추가 정보가 최초 평가를 뒤집을 만큼 무엇을 보여줬는지, FAA에는 각 단계에서 언제 어떤 내용이 공유됐는지가 확인돼야 한다.

항공안전에서 ‘즉각적 위험이 아니다’라는 표현은 ‘문제가 없다’는 뜻과 다르다. 위험은 통상 결함 발생 확률, 발생 시 운항 환경, 승무원의 회복 가능성, 방어장벽의 중첩 여부를 함께 따져 평가한다. 이번 사례는 낮은 빈도의 복합 조건에서 발생할 수 있으나, 발생 위치가 접근·착륙이라는 고위험 비행 단계라는 점에서 단순한 편의 기능 오류로만 보기 어렵다.

항공사도 인도 거부…맥스7·맥스10 인증 변수

사우스웨스트항공과 유나이티드항공은 영향을 받는 소프트웨어가 탑재된 신규 737맥스 인도를 받지 않겠다는 입장을 보잉에 전달하고, 이전 버전 소프트웨어를 요구한 것으로 알려졌다. 알래스카항공·아메리칸항공·사우스웨스트·유나이티드는 자사가 현재 운항하는 737맥스 기단에는 해당 버전이 설치돼 있지 않다고 CBS 뉴스에 밝혔다.

이번 문제는 737맥스7과 맥스10의 인증·인도 일정에도 변수로 작용할 수 있다. 보도에 따르면 맥스7은 소프트웨어 버전 14로 인증됐고, 맥스10은 버전 14.1로 인증 시험을 진행해 왔다. FAA가 문제의 범위와 시정 방식을 다시 들여다보면, 수년째 지연돼 온 맥스10 인증 일정과 맥스7 인도 계획이 추가로 영향을 받을 가능성을 배제하기 어렵다. 다만 FAA가 실제 인증 지연이나 운항 제한을 결정한 것은 아직 아니며, 현 단계에서 이를 단정하기는 어렵다.

보잉은 원래 2028년 중 새 소프트웨어 버전을 내놓는 방안을 운항사에 제시했지만, 현재 수정 일정과 절차 보완을 앞당기려 하고 있는 것으로 알려졌다. 소프트웨어 결함이 비교적 제한된 조건에서 발생한다고 해도, 해결 시점을 약 1년 이상 뒤로 둔 초기 계획은 운항사들이 받아들이기 어려운 대목이다.

346명 희생 뒤에도 반복되는 ‘신뢰 비용’

737맥스의 신뢰 위기는 기술적 결함 하나로만 설명되지 않는다. 2018년 10월 인도네시아 라이온에어 610편 추락으로 189명이 숨졌고, 2019년 3월 에티오피아항공 302편 추락으로 157명이 사망했다. 두 사고의 사망자는 총 346명이다. 당시 핵심 쟁점이었던 조종특성향상시스템(MCAS)은 단일 받음각 센서의 잘못된 데이터에 반응해 기수를 반복적으로 내릴 수 있었고, 그 결과 조종사의 기체 통제 능력이 심각하게 제약됐다.

2024년 1월에는 알래스카항공 1282편 737맥스9에서 비행 중 도어 플러그가 이탈하는 사고가 발생했다. 이 사고는 소프트웨어가 아닌 제조·품질관리 문제였지만, 보잉의 설계·생산·검사·문서화 체계 전반에 대한 규제 압박을 키웠다. 이번 VNAV 결함은 맥스의 과거 MCAS 문제와 같은 유형도, 즉각적 감항성 위기라고 단정할 사안도 아니다. 그럼에도 사고 이력이 누적된 기종에서 비행유도 소프트웨어의 새 결함이 뒤늦게 공개됐다는 사실 자체가 시장과 승객에게 더 큰 불안을 줄 수 있다.

결함보다 중요한 것은 ‘방어선의 신뢰성’

이번 사안은 “자동화가 해제돼도 조종사가 수동 비행을 할 수 있다”는 기술적 설명과 “왜 그 자동화가 중요한 비행 단계에서 예기치 않게 낮은 수준으로 전환되는가”라는 안전관리 질문이 충돌하는 사례다. 조종사는 원칙적으로 모든 자동화가 사라진 상황에서도 항공기를 안전하게 비행·착륙하도록 훈련받는다. 보잉의 설명도 이 전제 위에 서 있다.

하지만 현대 여객기 운항에서 자동화는 단순한 편의 장치가 아니라 고도·속도·경로·에너지 관리를 체계화해 승무원의 인지 부담을 줄이는 방어선이다. 복행 직후처럼 관제 지시, 재접근 준비, 기상 회피, 항공기 자세 및 추력 관리가 동시에 필요한 시점에 그 방어선 하나가 약화되면, 안전 평가는 “조종사가 결국 통제할 수 있는가”를 넘어 “불필요한 업무부하와 오류 유발 요인이 새로 생기는가”까지 따져야 한다.

보잉과 FAA가 향후 공개해야 할 것은 단순한 ‘안전 위험 없음’이라는 결론이 아니라 구체적 근거다. 영향을 받는 소프트웨어 버전과 기체 수, 실제 운항 중 발생 보고 여부, 시뮬레이터 검증 결과, 조종사 절차의 수행 시간과 오류 가능성, 소프트웨어 수정·배포 일정이 투명하게 제시돼야 한다. 737맥스의 진짜 시험대는 결함을 발견했다는 사실이 아니라, 이를 얼마나 빨리 식별하고 공개하며 독립적인 검증 아래 재발 방지 체계로 연결하느냐에 있다.