급발진은 신기루와 같습니다. 급발진을 주장하는 사람들은 많지만, 막상 검사하고 재현하려 하면 나타나지 않는다고들 하죠.

프로그래밍에도 비슷한 버그가 있습니다. 하이젠버그(Heisenbug)라고 합니다. 평소에는 오류가 나타나는데 디버깅하려고 하면 실행환경이나 타이밍이 달라져 사라져버리는 버그입니다. 말 그대로 신기루 같은 존재입니다.

물론 그렇다고 급발진이 하이젠버그라는 뜻은 아닙니다. 다만 “재현되지 않았다”와 “존재할 수 없다”는 전혀 다른 주장이라는 점을 생각해볼 필요가 있습니다.

ECU 역시 수많은 센서와 프로그램이 동시에 작동하는 실시간 컴퓨터입니다. Toyota 급발진 논란에서도 NASA가 ECU까지 조사했지만 급발진을 설명할 전자적 원인을 찾지 못했습니다. 그런데 2013년 Bookout v. Toyota에서는 임베디드 소프트웨어 전문가 Michael Barr 측이 소스코드를 다시 분석해 stack overflow, task death, memory corruption 등의 위험요소를 지적했습니다. 이것이 Toyota 급발진 전체를 소프트웨어 문제로 입증한 것은 아니지만 NASA가 못 찾았다고 해서 오류가 없었던 것은 아니라는 점은 중요합니다.

항공기는 자동차보다 훨씬 엄격하게 소프트웨어를 검증합니다. 그런데도 Qantas 72에서는 특정 센서 오류를 알고리즘이 제대로 거르지 못해 비행기가 갑자기 기수를 숙였습니다. 737 MAX에서도 센서 입력과 MCAS 설계 문제가 대형 사고로 이어졌습니다.

항공기가 안전한 이유는 오류 확률을 0이라고 믿어서가 아닙니다. 사고가 나면 아무리 희귀한 failure mode라도 찾아내고 시스템 전체에 반영하기 때문입니다. 급발진 논쟁에서도 같은 태도가 필요합니다. 

특히 페달 오조작이 확실히 확인된 사고를 버릴 게 아니라 control condition으로 사용해야 합니다. 페달 영상으로 실제 액셀 조작이 확인됐다면 그 사고는 아주 가치 있는 데이터입니다. 그때의 APP, RPM, 속도, 기어, 브레이크, wheel speed 등을 모두 수집합니다. 도로 요철이나 충돌, 차체가 튀는 순간까지 시간축에 맞추면 더 좋습니다. 그러면 실제 사람이 페달을 잘못 밟았을 때 각 센서가 어떤 패턴을 보이는지 알 수 있습니다. 요철을 지날 때 APP 100%가 그대로 유지되는지도 실제 사고자료에서 확인할 수 있습니다. 100% APP일 때 RPM과 속도가 어떻게 변하는지도 수십·수백 건에서 비교할 수 있습니다.

여기에 블랙박스와 차량 내부의 녹음자료도 매우 중요한 독립 증거가 됩니다. 변속레버를 움직였다면 조작음이 남을 수 있고, 엔진 회전수 변화는 엔진음의 높낮이로도 확인할 수 있습니다. 경고음, 방향지시등음, 충돌음, 타이어 마찰음도 사고의 시간순서를 맞추는 단서가 됩니다.

급발진 주장 사고에서 항상 제기되는 논란은 EDR을 믿을 수 있느냐입니다. “이 사고는 실제 페달 오조작 사고의 분포 안에 들어가는가?” 이 질문이 “EDR을 믿느냐, 운전자를 믿느냐”보다 훨씬 과학적입니다.

강릉 티볼리 사고도 좋은 예입니다. EDR은 마지막 5초간 APP 100%를 기록했습니다. 하지만 동일 연식 차량의 풀액셀 재연시험에서는 사고차보다 훨씬 빠르게 가속했습니다. 이 차이만으로 ECU 오류를 증명할 수는 없습니다. 충돌이나 도로조건 때문에 달라졌다면 그것 역시 control data와 재연시험으로 검증하면 됩니다.

문제는 이런 실증을 현재 피해자가 직접 해야 한다는 것입니다. 같은 차를 구하고 CAN 로거와 EDR 장비를 준비해 사고도로에서 여러 번 시험해야 합니다. 충돌 전후 조건까지 재현하려면 비용은 더 커집니다.

반면 제조사는 시험차, 시험장비, firmware, calibration, 내부시험과 field data를 이미 가지고 있습니다. 즉 가장 싸게 검증할 수 있는 쪽은 제조사인데 가장 비싸게 입증해야 하는 쪽은 소비자입니다.

EDR 자체에도 한계가 있습니다. 강릉 사고는 약 30초 가까이 진행됐지만 APP 기록은 마지막 5초만 남았습니다. 그런데 왜 5초일까요? 5초를 저장하는데 필요한 메모리는 수백 KB 밖에 되지 않습니다. 최근 미국은 최소 20초, 10Hz를 저장하는 규격으로 바꿨다고 합니다. 

급발진이라고 주장하면 제조사가 무조건 책임지라는 얘기가 아닙니다. 일정한 개연성이 생긴 사고라면 제조사가 가진 자료를 독립 전문가가 검증할 수 있게 하자는 것입니다. 원인이 확인된 페달 오조작 사고도 익명화해 국가 차원의 control database로 만들면 좋습니다.

앞으로는 AI도 중요한 역할을 할 수 있습니다. 과거에는 수십만 줄 ECU 코드를 전문가가 직접 뒤져야 했습니다. 이제 AI는 위험한 코드 경로, 메모리 오류, race condition 후보를 빠르게 선별할 수 있습니다. 자동차 회사 역시 AI를 사용하면 출고 전에 더 많은 오류를 제거할 수 있을 것입니다. 최근에 오래된 오프 소스 프로젝트, 보안 프로그램에서 AI가 수십 건의 오류를 찾아냈다는 기사를 보셨을 것입니다.

그렇다면 한 발 더 나가 단종된 자동차의 ECU 프로그램을 일정 기간 후 공개하는 것도 생각해볼 만합니다. 10년이나 15년 뒤 대학·연구기관·독립 개발자들이 AI와 정적분석 도구로 다시 검사하게 하는 것입니다. 과거에는 비용 때문에 발견하지 못했던 오류를 몇 년 뒤 AI가 찾아낼 수도 있습니다. 그 오류가 아직 운행 중인 같은 차종의 리콜이나 안전점검으로 이어질 수도 있습니다. 과거 사고를 다시 분석할 중요한 단서가 될 수도 있습니다. 물론 ECU는 하드웨어, 센서, calibration과 함께 작동하기 때문에 코드만 공개한다고 모든 오류를 찾을 수 있는 것은 아니지만 독립적인 검증을 할 수 있다는 점이 중요합니다.

그리고 이 논의의 결론은 “급발진이 있다”와 “항상 페달 오조작이다” 중 하나를 선택하자는 것이 아닙니다. 오히려 그런 양자택일에서 벗어나자는 이야기입니다. 현재까지 페달 블랙박스처럼 직접적인 증거가 확보된 사례에서는 페달 오조작이 강하게 확인됐습니다. 따라서 새로운 사고에서도 페달 오조작의 기저확률을 높게 두는 것이 합리적입니다. 운전자가 “나는 분명 브레이크를 밟았다”고 주장하지만 실제로는 그렇지 않았던 적이 많았기 때문에 그 말을 모두 믿을 수 없습니다. 그러나 기저확률은 결론이 아닙니다.

개별 사건에서 강한 반대 증거가 나오면 그에 맞게 판단을 갱신해야 합니다. 실제로 단순한 순간적 페달 착각으로만 보기에는 특이해 보이는 영상들도 있습니다. 한 영상에서는 차량이 장시간 멈추지 않는 상황에서 탑승자가 삼촌에게 전화해 대처방법을 묻고 여러 조작 끝에 차를 세웁니다.

고속도로 ‘삼촌, 차가 안 멈춰요’ 영상

또 다른 사례에서는 택시기사가 차량이 멈추지 않자 좌우 구조물에 일부러 충돌시키며 가까스로 속도를 줄입니다.

택시기사가 고의 충돌로 차량을 세우는 영상

이런 영상들이 급발진을 입증하는 것은 아니지만 “어차피 페달 오조작일 것”이라며 연구 대상에서 제외할 이유도 없습니다.

결론적으로 자동차 회사도 자신의 소프트웨어가 완벽하다고 생각하지 않을 것입니다. CEO나 고위 관리자가 그렇게 생각할 수 있어도 직접 설계하고 프로그래밍하는 개발자들은 그렇게 생각하지 않을 것입니다. (아마도 개발자들은 오류를 발견 못 했다고 결함이 없다고 확신 할 수 없지만, 해당 사고가 결함 때문이라는 증거도 없으니 침묵하고 있을 수도 있습니다.) 그럼에도 우리는 모든 비용을 사고자에게 전가하고 있습니다. 특별히 의심해볼 만한 증거가 있어도 마찬가지입니다.

물론 프로그램의 무결성을 요구한다면 세상에 자동차가 없을 것입니다. 그렇다고 해도 사고의 책임과 비용을 모두 사고 당사자에게 전가하는 것은 무책임합니다. 특별히 의심해볼 이유가 있을 때에는 법원은 적극적으로 제조사에게 입증의 책임을 요구해야 합니다. 더 나아가 독립적인 조사 기관을 설립하여 특별히 의심할 수 있는 경우에 대해서는 국가가 주도적으로 조사를 진행하여 진실을 밝혀야 합니다.

PS) 만약 제가 급발진과 비슷한 상황이라면 두 발을 모두 떼어낼 것입니다. 그럼에도 사고가 난다면 자동차를 법원이 인정하는 방식으로 보존한 후 AI가 더욱더 발전한 미래에 분석을 할 것입니다. 마치 후대에 새로운 치료법을 기대하며 냉동인간이 되는 것처럼.