치명적 자동화의 결말: MCAS와 737 맥스 사태

자동화된 안전 기능이 어떻게 대참사의 원인이 되었나

2018년과 2019년, 불과 몇 개월 간격으로 두 대의 Boeing 737 MAX 여객기가 추락했을 때, 조사관들은 기체의 비행 제어 소프트웨어에서 공통된 실마리를 찾아냈습니다. 엔진 형상의 변화에 따른 기체 특성을 다루기 위해 설계된 시스템인 조종 특성 향상 시스템(MCAS)은 개발 후반부에서 그 동작이 더 공격적으로 변하고, 결정적으로 단일 받음각(angle‑of‑attack) 센서에 의존하도록 수정되었습니다. 이러한 변경 사항은 보호 계층을 제거했으며, 승무원들이 인지하거나 대응하도록 훈련받지 못한 빠르고 혼란스러운 고장 모드에 무방비로 노출되게 만들었습니다.

MCAS: 원래 의도된 역할

MCAS는 더 크고 전방에 배치된 엔진으로 인해 변화된 공학적 특성에 맞춰, MAX의 조종감을 이전 737 모델들과 유사하게 유지하기 위해 도입되었습니다. 이 시스템의 본래 역할은 제한적이었습니다. 특정 조건에서 기수가 너무 높게 들릴 가능성이 있을 때, MCAS는 수평 안정판(horizontal stabiliser)을 기수 하강 방향으로 약간 조절하여 조종사가 일관된 조종감을 느끼도록 돕는 것이었습니다. 초기 구상에서 이 시스템은 미세하게 작동하며 드물게 가동될 예정이었습니다.

시스템은 어떻게 변했는가 — 그리고 왜 그것이 중요했는가

개발 과정에서 Boeing은 MCAS의 역할을 확대했습니다. 실제로 구현된 버전은 초기 설계보다 더 자주 활성화되고 더 큰 안정판 보정값을 입력할 수 있었으며, 여러 소스를 교차 확인하는 대신 단일 받음각 센서의 데이터에 반응하도록 연결되었습니다. Lion Air와 Ethiopian Airlines 사고 모두에서, 잘못된 받음각 데이터로 인해 반복적인 기수 하강 입력이 발생했으며 조종사들은 이에 맞서 싸웠으나 제시간에 극복하지 못했습니다. 보수적이고 중복성을 갖춘 설계에서 공격적인 단일 센서 구현으로의 전환은 이러한 실패의 결정적인 요인이었습니다.

MCAS를 “A.I.”라고 부르는 것이 오해의 소지가 있는 이유 — 그리고 왜 그 명칭이 여전히 중요한가

미디어와 공공의 담론에서 이 추락 사고들은 때때로 “AI”의 실패로 프레임화되기도 합니다. 이러한 약칭은 매력적이지만 부정확합니다. MCAS는 데이터를 통해 스스로 학습하는 머신러닝 모델이 아니었습니다. 그것은 특정 센서 입력에 따라 작동하도록 코딩된 규칙인 결정론적 비행 제어 로직이었습니다. 하지만 그 위험성은 사람들이 불투명한 AI 시스템에 대해 우려하는 것과 동일합니다. 즉, 최종 사용자와 규제 당국으로부터 숨겨진 자동화된 동작이, 설계자가 충분히 예상하지 못한 방식으로 복잡한 현실 세계의 신호와 상호작용했다는 점입니다.

MCAS를 단순히 “자동화”라고만 부르는 것은 투명성, 중복성, 인간-기계 상호작용과 관련된 설계 선택이 어떻게 보호 기능을 위험 요소로 변질시켰는지를 과소평가하게 만들 수 있습니다. 이 사고들은 학습 기능이 없는 알고리즘이라 할지라도 엄격한 안전 공학, 즉 현재 우리가 다른 분야의 AI 시스템에 요구하는 것과 동일한 종류의 추적 가능한 요구 사항과 독립적인 테스트가 필요함을 드러냅니다.

기술적 결함을 증폭시킨 조직적 및 규제적 실패

기술적 선택은 진공 상태에서 이루어지지 않았습니다. 수많은 검토와 청문회 결과, 감독, 소통, 그리고 기업 문화의 문제들이 위험을 증폭시켰음이 밝혀졌습니다. 규제 당국은 진화하는 MCAS의 전체 세부 사항을 항상 전달받은 것은 아니었습니다. 초기 조종사 매뉴얼에서는 이 기능이 누락되었으며, MCAS가 드물게 활성화될 것이라는 가정이 실제 상황 발생 시 조종사의 대응 훈련을 축소시켰습니다. 이러한 제도적 붕괴는 공학적 실수를 공공 안전 위기로 전환시켰습니다.

Boeing과 규제 당국이 시행한 수정 조치

MAX 기단의 운항 중단 이후, Boeing과 항공 당국은 소프트웨어 및 운영상의 변경을 요구했습니다. 수정된 설계는 두 받음각 센서의 값이 일치할 때만 MCAS가 작동하도록 제한하며, 이벤트당 한 번만 활성화되도록 제한하고, 트림 입력의 강도를 완화했습니다. 규제 당국 또한 해당 기종의 복귀가 승인되기 전 문서화, 조종사 훈련 및 독립적 검증에 대한 요구 사항을 강화했습니다. 이러한 변경 사항들은 즉각적인 고장 모드들을 해결했지만, 이번 위기로 드러난 광범위한 거버넌스 문제를 완전히 지우지는 못했습니다.

더 넓은 AI 및 자동화 논의를 위한 교훈

MAX의 이야기는 자동화를 대규모로 도입하려는 모든 이들에게 경종을 울리는 입문서와 같습니다. 네 가지 교훈이 두드러집니다:

이것들은 AI 윤리와 안전 분야에서 익숙한 격언들이지만, 737 MAX는 그것들이 결코 추상적이지 않다는 것을 보여줍니다. 안전이 핵심인 시스템에서 이를 잘못 다루었을 때 치러야 할 대가는 즉각적이고 치명적입니다.

향후 논의가 나아가야 할 방향

기술적 수정으로 MAX는 더 엄격한 조건 하에 운항에 복귀했지만, 이 사건은 규제 산업에서 자동화를 관리할 때 범하지 말아야 할 표준적인 사례로 남아 있습니다. 정책 입안자와 엔지니어들에게 주어진 과제는 이러한 교훈을 강제 가능한 표준으로 바꾸는 것입니다. 즉, 자동화된 의사결정 시스템에 대한 더 명확한 인증 경로, 실질적인 설계 변경에 대한 의무적 보고, 그리고 제조업체와 인증 기관 간의 이해 상충을 줄이는 제도적 구조를 마련하는 것입니다.

언론과 대중에게는 용어의 정확성에 대한 경각심을 일깨워 줍니다. “AI”라는 단어는 헤드라인을 장식하기 좋지만, MAX 사례의 근본적인 문제는 머신러닝의 의미에서의 인공지능이 아니었습니다. 그것은 공격적인 자동화, 열악한 투명성, 그리고 약화된 안전 관행의 조합이었습니다. 이러한 조합을 공학적 및 거버넌스적 과제로 다루는 것이 재발 방지를 위한 더 생산적인 길입니다.

결론

737 MAX 참사는 불가피한 것이 아니었습니다. 그것은 특정한 설계 결정, 검증되지 않은 가정, 그리고 제도적 실패의 결과물이었습니다. 자동화와 AI가 더 많은 영역으로 확장됨에 따라, MAX 사례는 극명한 본보기가 되어야 합니다. 더 안전한 시스템은 한 줄의 코드에 대한 확신이 아니라, 보수적인 설계, 사용자와의 명확한 소통, 독립적인 검토, 그리고 강력한 규제 감독을 통해 만들어집니다. 이는 기술적인 세부 사항이 아니라 공공 안전의 전제 조건입니다.