자율주행이라는 개념을 대중에게 가장 선명히 각인시킨 순간을 떠올리면, 많은 이들이 2002년 개봉한 마이너리티 리포트를 떠올릴 것이다. 운전 조작이 사라진 자동차가 개인의 이동 공간으로 변모해 자연스럽게 흐르듯 달리는 모습은 당시만 해도 먼 미래였다. 그러나 지난 20여 년 동안 전통적인 자동차 제조사부터 구글 같은 IT 기업까지 다양한 주체가 연구를 이어오며, 그 미래는 어느새 현실의 도로 위로 내려왔다. 오늘날에는 테슬라를 비롯한 여러 기술이 경쟁적으로 등장했고, 일부 도심에서는 무인택시가 시범적으로 운영되는 단계까지 이르렀다.
현실은 그러나 영화보다 훨씬 복잡하다. 도시마다 도로 구조와 교통 문화가 다르고, 이는 자율주행 시스템의 한계와 요구 조건을 분명하게 만든다. 특히 2025년 호주 멜버른에서 진행된 감독 하 자율주행 실험은 중요한 메시지를 남겼다. 트램이 일반 도로를 함께 사용하는 도시 구조 특성상 ‘훅턴’처럼 독특한 주행 방식이 요구되는데, 실험 차량들은 이 복합적인 상황에서 낮은 성공률을 보였다. 시스템을 신뢰하던 운전자는 차량이 상황을 제대로 해석하지 못하는 순간 위험에 한층 더 가까워졌고, 자율주행 기술의 확산과 함께 사고 보도가 늘어나는 이유도 이 지점에서 비롯된다. 더 많은 차량이 도로에 투입될수록 더 많은 소프트웨어가 더 다양한 상황을 완벽히 해석해야 하며, 초기 단계에서는 설계·운영상의 결함이 사고의 결정적 원인이 되기도 한다.
그렇다면 자율주행 시스템은 어떤 방식으로 사고를 예방하고, 더 안전한 방향으로 성장할 수 있을까? 그 답을 찾기 위한 출발점이 바로 Software Fault Tree Analysis(SFTA)다. 복잡한 도시 환경 속에서 자율주행 소프트웨어가 어떤 경로를 통해 위험을 만들어내는지, 그리고 어떤 지점에서 실패가 발생하는지 구조적으로 추적할 수 있는 분석 방식이다. 이제 이 관점에서 자율주행 사고를 살펴보자.
SFTA는 전통적 Fault Tree Analysis(FTA)를 소프트웨어 관점으로 확장하여, 소프트웨어 설계·구현·통합·런타임 행위가 어떻게 상위 수준의 사고(Top Event)를 유발하는지를 체계적으로 모델링하는 기법이다. 하드웨어 고장뿐 아니라 알고리즘 오판단(예: 객체 분류 실패), 데이터 결함(센서 노이즈·레이튼시), 상태관리 결함(예: 안전 모드 진입 실패), 소프트웨어 인터페이스 오류(타 서브시스템과의 메시지 불일치) 등을 논리 게이트(AND/OR 등)로 연결해 사고 원인 경로를 도식화한다.
SFTA의 핵심은 다음과 같다.
소프트웨어 결함을 논리적·구조적으로 표현: 모듈·프로세스·데이터 흐름을 토대로 사고 트리를 구성
인간-소프트웨어-하드웨어 상호작용 포함: 운전자(감독자), 원격 모니터링, 안전제어 등 사람 요소를 소프트웨어 관련 고장원으로 포함
설계·운영 완화책 설계에 직접 연결: 트리의 최소 절단집합(minimal cut sets)을 통해 우선순위 높은 결함·완화책 도출
자율주행 시스템은 복잡한 소프트웨어 스택(인식 → 추적 → 상황 판단(퍼플랜) → 경로계획 → 제어)과 다수 센서(라이다·카메라·레이더), 인간 감독, 통신 인프라가 결합된 시스템이다. 전형적 이유:
소프트웨어가 직접적으로 물리적 행위를 결정하므로 소프트웨어 결함은 즉시 물리적 사고로 이어질 수 있다.
비결정적 환경(밤, 외부객체·비표준 보행자 행동)에서 동작하는 자율주행은 경계 조건에서의 소프트웨어 실패 모드를 반드시 분석해야 함.
인간-자동화 상호작용 문제 — 자동화에 대한 과신(overreliance)이나 감시 태만으로 안전망이 붕괴할 수 있음.
규제·책임 문제 대응 — 사고 발생 시, 소프트웨어적 원인과 그 완화 조치(예: 드라이버 모니터링, 긴급제동 활성화)를 명확히 제시해야 함.
2018년 3월 18일, 미국 애리조나주 템피의 한 어두운 도로에서 우버의 자율주행 시험차가 보행자를 치어 사망하게 한 사건은 자율주행 역사상 첫 보행자 치명사고로 기록됐다. 이후 이 한 사건은 전 세계의 규제 논의와 안전 검토 체계를 뒤흔드는 기준점이 되었고, 동시에 SFTA를 활용해 소프트웨어적 원인과 결함 경로를 분석하기에 가장 대표적인 예로 자리 잡았다. 당시 차량의 인식·판단 로직은 보행자를 ‘자전거’, ‘기타 객체’, ‘알 수 없음’ 등으로 계속 재분류하며 위험 판단을 명확히 하지 못했고, 그 결과 회피 행동도 제대로 생성하지 못했다. 여기에 시험 설정 단계에서 긴급 제동 기능이 비활성화돼 있었으며, 차량 상태를 감시해야 했던 안전요원은 도로를 제대로 주시하지 않아 위험을 알아차리지 못했다. 기술적 결함과 운영적 취약성이 차례로 누적되며 결국 ‘충돌 회피 실패’라는 단일 사건으로 귀결된 것이다. NTSB 조사와 다양한 기술 분석은 이러한 일련의 오류가 단순한 센서 문제가 아니라 소프트웨어 처리 로직, 기능 비활성화 정책, 감독 체계의 허점이 복합적으로 작동한 결과임을 지적했다. 같은 맥락에서 Tesla Autopilot 관련 치명사고들 역시 자동화의 한계와 사용자의 기대·오용 사이에서 어떤 위험이 발생하는지를 보여주는 비교 사례로 자주 언급된다.
아래는 실제 분석 절차를 단계별로 진행한 것(Tempe 사고를 사례로 한 적용 포함)이다.
Step 1: 시스템 경계와 Top Event(최상위 사고) 정의
SFTA는 최상단에 분석하려는 사고를 놓는 것으로 시작한다. Tempe (템피) 사례에서는
“자율주행 모드 중 보행자 치명적 충돌”
이 사건이 Top Event가 된다.
시스템 경계: 자율주행 소프트웨어(인식·추적·분류·행동결정·행동 관리자), 센서 입력(라이다·카메라·레이더), 차량 제어/제동 인터페이스, 운전자(감독자) 모듈, 원격관리/로깅 시스템.
Top Event(예시): “자율주행 모드 중 보행자 치명적 충돌(사망)” — Tempe 사고의 실제 최상위 사건.
Tempe 사례 핵심 사실(요약): 차량은 밤에 보행자를 감지·분류하지 못했고, 긴급제동기능은 시험 설정상 비활성화되어 있었으며 차량의 안전감독자는 충돌을 막지 못했다.
Step 2: 기능적 분해(Functional Decomposition) — 소프트웨어·서브시스템 식별
SFTA는 Top Event에 기여할 수 있는 소프트웨어 관련 기능(또는 모듈)을 식별하며 나눠야 한다.
Tempe 예시:
인식(Perception): 센서 데이터 수집 · 객체 검출 · 분류(보행자/자전거/차량/기타).
추적(Tracking): 감지 객체의 위치·속도 추정.
상황판단(Behavior Prediction & Planning): 보행자 행동 예측, 충돌위험 판단, 긴급회피 계획.
결정/관리(System Manager): 긴급제동 활성화, 수동전환(운전자 경고) 정책.
제어(Actuation): 제동·조향 명령 실행.
운영·거버넌스(Human-in-loop/Monitoring): 운전자 주의 모니터링, 원격 모니터링, 로그·알람 시스템.
Step 3: 고장 모드 식별 (Software-focused failure modes)
각 서브시스템에서 가능한 소프트웨어 결함을 식별한다(예: 요구사항 미비, 알고리즘 오분류, 데이터 손실, 인터페이스 미스매치, 안전 모드 미작동 등). 사고에서 일어날 수 있는 고장들을 찾아는 것이 핵심이다.
Tempe에서 드러난 주요 소프트웨어 고장모드(조사 결과 기반):
인식 모델이 객체를 보행자로 올바르게 분류하지 못함(검출 실패 또는 ‘무시’ 필터링).
결함 발생 시 긴급제동을 차단하거나 운전자 개입을 전제로 긴급제동을 비활성화한 운영 설계.
데이터 레이턴시·동기화 문제로 상황 판단 지연.
운전자 주시상태를 실시간으로 감지·경고하지 못한 운영·소프트웨어 시스템.
Step 4: Fault Tree 구성 — 논리 게이트 적용
Top Event(보행자 치명적 충돌)를 초래할 수 있는 상위 분기(OR/AND)를 설정하고, 각 분기에 대응하는 원인(리프 노드)을 배치한다.
Top Event: 보행자 치명적 충돌
├─ OR ── Perception 실패 (보행자 미검출/오분류)
│ ├─ 카메라/라이다 입력의 소프트웨어 전처리 필터가 보행자 신호를 제거함
│ ├─ 객체 분류 모델의 학습 데이터 부족 → 오분류
│ └─ 센서 데이터 동기화 결함 → 객체 추적 실패
├─ OR ── 결정(Planner) 실패 (충돌 회피 명령 미생성)
│ ├─ 충돌예측 모듈 오류(거리·속도 계산 오류)
│ └─ 안전 정책으로 긴급제동 명령 억제(운영 설정)
├─ OR ── 제어/액추에이터 실행 실패
│ ├─ 제동 명령 메시지 손실(네트워크)
│ └─ 제동 소프트웨어 인터페이스 예외 처리 누락
├─ OR ── 인간 감독 실패(운전자 개입 없음)
│ ├─ 운전자 주의 모니터링 부재 또는 경고 무시
│ └─ 운전자 교육·절차 미비
└─ OR ── 환경/외부 요인(야간, 보행자 횡단 등)과 결합된 위의 항목들
이 트리에서 핵심적인 소프트웨어 기여 노드는 Perception 모듈의 오분류·필터링, Planner의 안전 정책, System Manager의 긴급제동 억제, 그리고 운전자 모니터링 소프트웨어의 부재·오작동이다. Tempe 사고에서 NTSB는 “차량이 보행자를 보지 못함(did not identify the woman as a pedestrian)”과 “긴급제동 기능이 시험설정으로 비활성화되어 있었음”을 지적했다.
Step 5: 최소절단집합(Minimal Cut Sets) 산출 — 우선순위화
트리에서 Top Event를 유발하는 최소 조합(더 이상 줄일 수 없는 실패 조합)을 식별한다.
예시:
{Perception: 보행자 미검출} — 단일 결함으로 Top Event에 직결될 수 있음. (높은 우선순위)
{Perception: 오분류, Planner: 긴급제동 억제} — 복합 결함.
{Perception: 미검출, Human Supervisor: 주의 없음} — 복합 결함.
{제어: 제동명령 손실, Perception: 지연} — 복합 경로.
우선순위는 각 노드의 발생 가능성(이력, 테스트 실패 사례)과 영향도(사망 가능성)를 고려해 정한다. Tempe의 역사(유사한 사고·사건 빈도)와 조사에서 드러난 설계·운영상 결함을 고려하면 Perception 미검출 단일 모드와 Human Supervisor 부재 조합이 핵심 컷셋으로 평가된다.
Step 6: 권고(완화책) 및 검증 액션 도출
각 컷셋에 대응해 기술적·운영적 완화책을 제시하고, 검증(테스트) 계획을 세운다. 여기는 전에 구축한 트리를 보며 분석하면 사고로 이어지는 최소 조합을 추출할 수 있다.
기술적 권고
감지·분류 보완: 다중센서(라이다+레이더+카메라) 데이터 레벨 융합 강화 및 분류기 학습셋에 비표준 보행자 행동(야간·비표준 횡단) 포함. (데이터 증강, 이상치 처리 강화)
정책 변경: 시험 모드에서라도 긴급제동(Autonomous Emergency Braking)을 비활성화하지 않도록 안전설계 변경 — 안전 모드는 항상 하드웨어 루트로 제동을 명령할 수 있어야 함.
실시간 운전자 모니터링: 운전자 얼굴·시선 추적, 경고·원격 상호작용 로그를 의무화.
안전 사례 거버넌스 강화: 운영 중지 기준·알람 임계값 설정, 사고 전 인시던트 누적 시 즉시 운영 중단·원인 분석.
검증(시험)
엣지 케이스(야간, 복잡한 조명, 보행자 비표준 자세) 시나리오 기반 통합 테스트.
지속적 필드 모니터링·시행착오 데이터의 안전증거(assurance case) 수집.
레드팀(공격/교란) 테스트: 센서오염·데이터 지연 시 소프트웨어 반응 검증.
소프트웨어 오분류(Perception)와 운영설계(긴급제동 비활성화)의 결합이 치명적이었다. 이는 단순한 센서 고장이 아니라 소프트웨어 설계·운영 정책의 문제였다.
인간 감독을 과신하는 운영 모델은 “감시자가 항상 개입할 것이다”라는 가정에 취약하다(심리학적 vigilance decrement). 따라서 인간을 최종 안전망으로만 의존하는 설계는 위험하다.
SFTA는 이러한 결합경로(소프트웨어 결함 + 운영·인간 요소)를 명확히 도식화하고, 우선순위 기반의 기술·절차적 완화책을 도출하는 데 유용하다.
초기 단계에서 SFTA 포함: 시스템 요구사항·안전 요구사항 정의 시점에 SFTA를 병행.
크리티컬 소프트웨어 모듈 식별: 인식·판단·제어와 같이 물리적 위험과 직접 연결되는 모듈 우선 적용.
운영 정책을 트리 내 요소로 포함: 소프트웨어뿐 아니라 ‘운영 모드 설정(예: 긴급제동 비활성화)’도 리프 노드로 취급.
정성·정량 결합: 가능하면 사고 데이터·테스트 실패율로 확률값을 대입해 우선순위를 수치화.
검증 루프: SFTA에서 도출한 완화책은 실험·필드데이터로 검증 → 결과를 SFTA에 피드백(반복적 개선).
자율주행은 소프트웨어가 물리적 세계를 직접 해석하고 제어하는 기술이며, 그 판단의 결과가 곧 사람의 생명과 연결된다. 그렇기 때문에 사고를 이해하려는 시도는 특정 코드 오류나 센서 한계를 짚는 수준에서 머무를 수 없다. 인식 알고리즘의 모호함, 데이터 처리 지연, 기능 비활성화 정책, 인간 감독의 부재 같은 요소들은 서로 얽히며 하나의 사고 경로를 만든다. 실제로 템피의 우버 사고는 기술적 결함과 운영적 실패, 인간 요소가 순차적으로 결합된 전형적 사례였고, 이런 구조적 실패는 어느 한 부분만 바라봐서는 재발을 막기 어렵다.
SFTA가 중요한 이유는 바로 이 복잡한 결합을 투명하게 드러내고, 위험이 어떤 경로로 형성되는지 구조적으로 모델링해 준다는 데 있다. 이는 한 사건을 분석하는 데 그치지 않고, 앞으로 확산될 자율주행 기술이 어떤 안전 기준을 갖추어야 하는지, 기업과 도시, 운전자, 엔지니어가 각각 어떤 책임을 져야 하는지 설계하는 기반이 된다. 다시 말해, SFTA는 기술·절차적 개선의 우선순위를 명확히 하고, 실제로 시스템 안전을 끌어올리는 데 필요한 방향성을 제공하는 도구다.
자율주행의 미래는 의심할 여지없이 더 정교해지고 더 넓게 퍼질 것이다. 그러나 그 미래가 ‘안전한 미래’가 되기 위해서는, 지금 발생한 사고들을 정확히 이해하려는 노력이 선행되어야 한다. SFTA는 그 여정에서 처음 마주하게 되는 지도와 같은 역할을 한다. 이러한 분석을 바탕으로 할 때에만, 우리는 기술의 속도를 안전의 속도와 함께 맞출 수 있다.