1. 개요
지난 2020년 11월, 미국 도로교통안전국(NHTSA)이 자율주행차 안전에 관한 흥미로운 보고서를 발간했습니다. 제목을 직역해보면 “일반적인 레벨 3 고속도로 주행(Highway Chauffeur) 시스템의 차로 중앙 유지 및 차로 변경 maneuvers의 의도된 기능 안전성(SOTIF)” 정도인데요. 이 보고서는 자율주행 레벨 3 시스템의 안전을 새로운 관점(SOTIF)에서 분석한 내용을 담고 있습니다. 오늘 포스트에서는 이 보고서가 다루는 내용과, SOTIF란 무엇인지, 그리고 ADAS/자율주행 엔지니어들에게 주는 시사점을 풀어보겠습니다.
2. SOTIF란 무엇이고 왜 중요할까?
먼저 SOTIF라는 개념부터 알아보겠습니다. SOTIF는 Safety of the Intended Functionality의 약자로, 우리말로는 보통 “의도된 기능의 안전”이라고 부릅니다. 말 그대로 “시스템이 의도된 대로 정상 동작하는 상황에서의 안전”을 의미합니다. 즉, 고장이 없는데도 설계상의 한계나 주변 상황 때문에 위험이 발생하지 않도록 하는 안전 개념입니다. 기존의 자동차의 기능 안전 표준인 ISO 26262 (Functional Safety, 기능 안전)가 전자/전기 시스템의 고장으로 인한 위험에 초점을 맞춘 것과 대조적입니다.
예를 들어, 우리가 차량의 크루즈 컨트롤(정속주행 장치)을 사용한다고 해보겠습니다. 이 장치는 설정된 속도를 잘 유지해주지만, 만약 구불구불한 산길이나 눈길에서 그대로 사용한다면 어떻게 될까요? 차는 설정 속도를 열심히 지키겠지만 커브를 돌 때 속도를 줄이지 못해 위험해질 수 있습니다. 시스템은 멀쩡히 의도대로 동작했지만 그 상황에서는 안전하지 않았던 것입니다. 또 다른 예로, 자율주행 센서를 떠올려보겠습니다. 카메라와 레이더가 하드웨어적으로는 정상이지만, 강한 햇빛이나 빗물, 눈부심 등으로 인해 앞차나 물체를 제대로 인식하지 못하는 경우가 있습니다. 실제로 몇 년 전 테슬라 차량은 밝은 햇빛 아래 트레일러 트럭의 흰 옆면을 하늘로 착각해 제대로 인식하지 못했고, 제동하지 않아 사고가 난 사례도 있었습니다. 이처럼 고장이 아닌 상황에서 발생하는 위험을 체계적으로 줄이는 것이 SOTIF의 목표입니다.
SOTIF의 개념을 좀 더 공식적으로 살펴보면, ISO 21448 표준에서는 SOTIF를 “의도된 기능의 기능적 불충분 또는 합리적으로 예견 가능한 오용으로 인한 위험의 부재”로 정의합니다. 말이 약간 어렵지만, 쉽게 풀면 시스템 기능 자체의 한계나 운전자의 잘못된 사용으로 위험이 생기지 않게 한다는 뜻입니다. 여기서 오용(misuse)이란 운전자가 시스템을 지원하려고 의도한 방식과 다르게 사용하는 경우를 말합니다. (예컨대, 사용 범위가 아닌 곳에서 자율주행 기능을 켜는 것 등). SOTIF는 이런 경우까지 고려하여 “합리적으로 예견 가능한” 오용에 의한 위험도 줄이도록 합니다.
비유: SOTIF를 좀 더 쉬운 비유로 설명해보면, 기능 안전(ISO 26262)이 “기계가 아프거나 망가졌을 때 안전망”을 챙기는 거라면, SOTIF는 “기계가 멀쩡히 움직일 때 바보짓 하지 않도록” 챙기는 것이라고 할 수 있습니다. 로봇 청소기가 고장 없이 잘 돌아다녀도, 계단을 인식 못 해서 굴러떨어지는 일이 없도록 만드는 게 SOTIF인 셈이지요.
위 그림은 SOTIF에서 다루는 시나리오의 4분면 분류를 나타낸 것입니다. 가로축은 시스템이 그 상황을 알고 있느냐 (Known), 세로축은 안전하냐 위험하냐 (Safe/Unsafe)를 의미합니다. 1번 영역 (초록)은 "알려진 안전한 시나리오", 2번 영역(보라)은 "알려진 위험한 시나리오", 3번 영역(빨강)은 "모르는 (예측 못한) 위험 시나리오", 4번 영역(청록)은 "모르는 안전한 시나리오" 를 뜻합니다. 개발자는 처음에는 모르는 위험(3번 영역)이 존재한다는 사실을 받아들이고, 개발 과정을 통해 그것들을 하나하나 찾아내 알려진 위험 (2번) 으로 옮긴 뒤 적절한 조치를 취해 안전한 영역으로 바꿔나가야 합니다. SOTIF 활동의 핵심 목표는 바로 이 '모르는 위험'을 줄이는 것이며, 따라서 다양한 시나리오 발굴과 검증이 강조됩니다.
3. 기능 안전(ISO 26262)과 SOTIF는 뭐가 다를까?
앞서 설명에서 눈치채셨겠지만, ISO 26262 (기능 안전)과 SOTIF는 다루는 범위와 접근 방식에서 차이가 있습니다. 개발 실무에 중요한 몇 가지 차이를 정리해보겠습니다:
- 다루는 위험 원인: ISO 26262는 전자/전기(E/E) 시스템의 오류나 고장으로 인한 위험에 초점을 둡니다. 예를 들어 ECU 오작동, 센서 고장, 브레이크 회로 단선 같은 일이죠. 반면 SOTIF는 시스템이 제대로 작동하고 있음에도 성능 한계나 설계상 부족함으로 발생하는 위험을 다룹니다. 센서가 특정 조건에서 물체를 놓치는 경우나, 소프트웨어 알고리즘이 훈련되지 않은 패턴을 만나 잘못 판단하는 상황 등이 이에 해당합니다.
- 사고 시나리오 예시: ISO 26262 관점에서는 “만약 브레이크 제어 장치가 고장 난다면?”, “EPS 전자식 조향이 끊긴다면?” 같은 질문을 던집니다. 실제 사례로는 조향 보조 상실, 전자식 파킹 브레이크 동작불능, 에어백 오폭발 등이 전형적인 기능 안전 이슈입니다. 반면 SOTIF 관점에서는 “카메라가 눈부심으로 차선을 잘못 인식하면?”, “차로 유지 알고리즘이 도로 표시를 오인하면?”, “운전자가 시스템을 잘못 켜서 생기는 상황은?” 같은 것을 가정합니다. 즉 “비정상 상황” 대 “특이하지만 정상인 상황”의 차이라고 볼 수 있습니다.
- 안전 확보를 위한 조치: 기능 안전에서는 주로 이중화(redundancy)나 Fail-safe 메커니즘으로 고장에 대비합니다. 예를 들어 한 센서가 고장 나도 다른 센서가 대신하거나, 오류 발생 시 즉시 운전자 경고 후 시스템을 종료(안전 모드)하는 식이죠. 한편 SOTIF에서는 성능 한계에 대한 보완 설계가 중요합니다. 운영 도메인(ODD)을 명확히 정의해 범위 밖에서는 기능이 활성화되지 않게 하거나, 애매한 상황에서는 보수적으로 동작(예: 확신이 없을 땐 차로 변경 시도 안함)하게 만드는 것입니다. 또한 환경/센서 상태 모니터링을 통해 신뢰도가 떨어지면 운전자에게 경고하거나 속도를 줄이는 등의 조치를 취합니다. 경우에 따라서는 학습된 모델 개선이나 추가 센서 장착도 고려됩니다.
- 개발 프로세스와 표준: ISO 26262는 2011년 처음 제정되어 2018년 개정된, 비교적 성숙한 안전 표준입니다. 자동차 업계에서는 ASIL 등급, V-모델 개발 프로세스 등으로 익숙합니다. SOTIF는 2019년에 PAS(공개 사양)로 처음 발표되고 2021년에 정식 ISO 21448 표준으로 나온 신생 표준입니다. 원래 ISO 26262의 일부(Part 14)로 추가하려던 것을, 그 복잡성 때문에 별도 표준으로 분리한 역사도 있습니다. 현재 업계에서는 ISO 26262로 다 못 담는 부분을 SOTIF로 보완하는 식으로 두 표준을 모두 적용하는 추세입니다. 즉, 고장 대응 + 성능 한계 대응이라는 두 축이 모두 필요한 것입니다.
- 검증 및 테스트: ISO 26262에서는 하드웨어 신뢰성 시험, 소프트웨어 단위 테스트, 결함 주입 테스트 (H/W, S/W, 시스템, 차량 레벨) 등 비교적 정형화된 시험들로 안전성을 입증합니다. 반면 SOTIF에서는 “알려지지 않은 위험”을 찾아내야 하기 때문에 방대한 시나리오에 대한 시험이 필요합니다. 시뮬레이션이 특히 중요해졌는데, 시뮬레이션으로 다양한 조건을 재현하고, 실제 주행 데이터도 활용하여 이상 사례를 찾아냅니다. 어느 정도냐 하면, 방대한 시나리오를 도는 컴퓨터 시뮬레이션과 머신러닝 기반의 데이터 처리 없이는 SOTIF 달성이 어렵다고 할 정도입니다. 따라서 엔지니어링적으로도 빅데이터, AI를 활용한 검증 기법이 SOTIF에 필요합니다.
정리하자면, ISO 26262는 “고장이 나지 않게 또는 고장이 나도 안전하게” 만드는 것이고, SOTIF는 “고장이 안 난 상태에서도 어이없는 사고가 나지 않게” 만드는 것입니다. 둘 다 “비합리적인 위험의 부재(absence of unreasonable risk)”를 추구한다는 점에서는 철학이 비슷하고, 함께 적용해야 자동차를 종합적으로 안전하게 만들 수 있습니다.
4. 레벨 3 고속도로 운전(Highway Chauffeur) 시스템 이해하기
보고서의 대상 시스템은 “레벨 3 고속도로 Chauffeur”라고 불리는 자율주행 시스템입니다. 여기서 레벨 3는 SAE 자율주행 분류 기준으로 “조건부 자동화” 단계에 해당합니다. 특정 조건에서 차량이 스스로 조향, 가속, 제동 등 동적 운전을 모두 수행하며, 그 동안 운전자는 계속 주시하지 않아도 됩니다. 다만 시스템이 맡길 수 없는 상황이 오면 운전자가 개입할 준비는 하고 있어야 합니다. 시스템이 “이제 당신이 다시 운전하세요”라고 충분한 시간 전에 알려주면 (예: 10초 전에 경고), 운전자가 다시 운전대를 잡고 제어를 인계받는 식입니다. 요약하면 “일정 조건에서는 차가 운전을 알아서 하고, 필요하면 사람이 넘겨받는” 단계입니다.
그렇다면 “고속도로 Chauffeur”란 무엇일까요? 쉽게 말해 고속도로에서의 자율주행 운전 비서 정도로 볼 수 있습니다. 고속도로라는 비교적 단순한 도로 환경(차선이 뚜렷하고 보행자가 없음)에서 차량이 스스로 차로를 유지하며 주행하고, 앞차를 추월하기 위해 자동으로 차로 변경도 수행하는 시스템입니다. 이 시스템은 전방의 차량과 차선을 카메라, 라이다, 레이더 등 여러 센서로 인지하고, 차량 제어 알고리즘을 통해 조향 및 속도를 제어합니다. 운전자는 이 기능이 동작하는 동안 손을 놓고 있어도 되지만, 아예 잠을 잔다거나 운전석을 비워서는 안 됩니다 (최소한 시스템 요청 시 즉각 대응할 수는 있어야 합니다).
보고서에 기술된 레벨 3 Highway Chauffeur는 주로 고속도로 상에서의 장거리 주행을 상정하고 있습니다. 예를 들어 시속 약 130km/h 범위에서 작동하며, 필요 시 완전 정지까지 제동도 수행할 수 있습니다. 다만 on/off 램프 구간이나 도시 교차로 등은 지원하지 않고, 진입로 합류나 고속도로 분기점에서는 운전자에게 제어를 넘긴다는 가정이 있습니다 (운영범위를 고속도로 본선으로 제한한 것입니다). 그리고 차로 유지(lane centering)와 자동 차로 변경(lane switching)라는 두 가지 핵심 기능에 집중합니다.
- 차로 유지: 차량이 현재 주행하는 차선의 중앙에 위치하도록 지속적으로 조향을 보정합니다. 차선이 뚜렷하게 표시된 경우 이를 인식해 중앙을 잡고 주행하고, 만약 차선 표시가 일시적으로 없어지면 주변 차량의 움직임이나 도로 가장자리 등을 참고하여 차선을 유지하려고 시도합니다. (보고서 내용에 따르면, 차선이 안 보일 경우 앞서가는 차량을 추격(follow)하거나 도로 경계 랜드마크를 이용해 위치를 유지하는 전략을 가정했습니다.)
- 자동 차로 변경: 앞차가 너무 느릴 때 등 필요한 상황에서, 스스로 방향지시등(깜빡이)을 켜고 옆 차로로 차선을 바꿔 추월합니다. 이를 위해 후측방 레이더/카메라로 옆 차로의 빈 공간을 탐색하고, 안전한 거리가 확보되면 차선을 이동합니다. 차로 변경 완료 후에는 다시 차로 유지 기능으로 새로운 차선의 중앙을 따라갑니다. (이 시스템은 운전자의 확인 없이도 차가 알아서 차로 변경까지 하기 때문에, 엄밀히 말해 현행 레벨 2 차량들의 “차로 변경 보조”보다 발전된 기능입니다.)
이 밖에도 고속도로 주행 상황에서 필연적으로 요구되는 여러 상황 대응이 필요합니다. 끼어드는 차량 감지 및 대응, 다른 차의 차로 변경에 대한 반응, 합류 차로에서의 차량에 양보, 차량이 옆에 없어도 불필요한 차로 변경을 하지 않는 것 등등의 행동 컴피턴시(competency)가 요구됩니다. 보고서에서는 관련 연구를 인용하여, “lane centering”과 “lane switching/overtaking” 기능을 제대로 수행하려면 다음과 같은 세부 능력이 필요하다고 정리합니다:
- 앞차 추종 및 추월: 느린 앞차를 감지하고, 더 빠른 진행을 위해 차로 변경/추월을 시도하는 능력.
- 끼어들기 대응: 옆 차로 차량이 갑자기 내 차 앞으로 끼어드는 경우 이를 감지하고 속도 조절 또는 회피를 하는 능력.
- 차량 합류 대응: 고속도로 진입로에서 차량이 합류할 때 안전거리를 유지하거나 필요 시 차로 변경/속도 조절로 대응.
- 차로 관련 규칙 준수: 추월 금지 구역(예: 곧 도로가 합쳐지는 구간 등)에서는 차로 변경을 하지 않고 기다리는 능력, 차로 변경 시 방향지시등으로 주변에 알리는 것 등.
물론 이 모든 것은 고속도로라는 제한된 환경에서 벌어지는 일들입니다. 도시 환경처럼 복잡하지는 않지만, 그래도 고려해야 할 시나리오의 가지수가 많다는 걸 알 수 있습니다. 레벨 3 시스템이 이 모든 것을 완벽히 해내는 것이 목표지만, 현실적으로는 어떤 상황에서는 한계가 드러날 수 있습니다. 바로 그 “한계 상황에서의 안전”을 따져본 것이 이번 NHTSA 보고서입니다.
5. NHTSA 보고서: SOTIF 관점에서 본 Level 3 시스템 안전 분석
이제 본격적으로 NHTSA 보고서의 내용을 살펴보겠습니다. 이 연구에서는 위에서 설명한 “전형적인 레벨 3 고속도로 자율주행 시스템”을 가정하고, SOTIF 프로세스를 적용하여 잠재 위험 요소를 식별하고 대책을 제시했습니다. 또한 ISO 26262의 기존 기능 안전 프로세스와 SOTIF 프로세스를 어떻게 통합할 수 있는지도 함께 논의했습니다. (보고서에서는 실제 차량 테스트를 한 것은 아니고, 분석 중심의 연구입니다. 하지만 그만큼 체계적인 Hazard 분석과 시나리오 구상이 이루어졌습니다.)
어떤 위험(Hazard)들이 있는지 먼저 보도록 하겠습니다. 연구진은 SOTIF 절차에 따라 시스템 레벨에서 발생할 수 있는 위험 시나리오 4가지를 도출했고, 이에 대응하는 5개의 안전 목표(Safety Goals)를 정했습니다. 정의된 대표적인 위험 시나리오(Hazard)는 다음과 같습니다:
- 차로 이탈 또는 도로 이탈: 레벨 3 시스템이 활성화된 상태에서 차량이 의도치 않게 차선을 벗어나거나 아예 도로 밖으로 나가버리는 상황. 예를 들어 차선 유지 기능이 실패해서 가드레일 쪽으로 서서히 다가가는 경우 등을 포함합니다.
- 차로 변경 충돌: 자동 차로 변경을 했는데 옆 차로에 이미 차가 있거나 장애물이 있어 충돌할 뻔한 상황. 이는 차량 센서/알고리즘이 사각지대의 차량을 놓쳤거나, 판단 착오로 안전거리가 부족한데 차로를 바꾼 경우 등이 원인이 될 수 있습니다.
- 차로 변경 미완료: 차로 변경을 시도했으나 차량이 완전히 옮겨가지 못하고 두 개 차로 사이에 걸쳐버린 상황. 예컨대 변경 도중 장애를 감지해 멈춰버리거나, 차량 제어 이상으로 차로 중앙을 벗어나지 못한 케이스입니다. 이 경우 뒤따르는 차량들에게도 매우 위험한 상황이 됩니다.
- 시스템 간 간섭: 자율주행 시스템이 차량의 다른 더 높은 우선순위의 안전 시스템 동작을 방해하는 경우. 예를 들어 자율주행 시스템이 차로 변경을 위해 가속하거나 조향 중인데, 동시에 발생한 긴급 자동제동(AEB)이나 차량 안전제어(ESC) 등의 개입과 충돌하는 상황을 떠올릴 수 있습니다.
이처럼 4가지 Hazard를 정의한 뒤, 각각에 대한 세부 안전 목표를 수립했습니다. 그리고 그러한 Hazard들이 어떤 조건에서 촉발되는지 원인을 분석했는데, 여기서 트리거(triggering event)라는 개념이 등장합니다. 트리거란 Hazard로 이어질 수 있는 잠재적 사건이나 조건을 말하는데, 센서의 한계, 알고리즘 오동작, 시스템 설정 한계, 운전자 행동 등 여러 가지가 될 수 있습니다. NHTSA 보고서에서는 시스템 측면의 트리거 59가지와 운전자 오용 측면의 트리거 22가지를 식별했습니다. 총 81가지 시나리오 요인을 찾아낸 셈인데, 이는 상당히 포괄적으로 가능한 경우의 수를 따졌다는 의미입니다.
시스템 측면 트리거 59가지는 카메라, 레이더, GPS/지도, 차선모델 알고리즘, 객체 추적 알고리즘, 차량위치 추정, HMI 인터페이스 등 각 구성요소별로 잠재적인 한계 상황을 망라합니다 (보고서의 표에는 센서/모듈별로 어떤 한계 상황이 Hazard로 이어질 수 있는지 나열돼 있습니다). 예를 들면: 카메라의 경우 “강한 역광으로 표지판을 잘못 인식”, 레이더의 경우 “차선 merge 구간에서 가짜 물체로 인식(스플릿 단면)”, 지도의 경우 “맵 데이터가 오래되어 차선 변경 금지 구역 표시가 누락”, 차선 모델 알고리즘의 경우 “차량이 도로 분기시에 어느 차로 따라갈지 혼동” 등이 트리거 예시입니다 (가령 이런 일이 발생하면 앞서 정의한 Hazard로 이어질 수 있습니다).
운전자 오용에 해당하는 22가지 트리거는 시스템이 의도한 사용이 아닐 때 발생하는 위험입니다. “예견 가능한 오용(foreseeable misuse)”이라고도 부르는데, 예를 들어 운전자가 고속도로가 아닌 곳에서 이 기능을 활성화하려고 시도한다든지, 시스템이 인수 요구를 했는데도 무시하고 계속 딴짓을 한다든지 하는 상황들입니다. 이런 케이스도 충분히 예상 가능하기 때문에 안전 분석에 포함한 것입니다.
이렇게 다양한 트리거를 찾았다면, 이제 그 위험을 줄이기 위한 대책(SOTIF mitigation)을 정리합니다. 보고서에서는 무려 126가지의 SOTIF 완화 조치 예시를 제시합니다. 대책의 종류도 매우 다양합니다. 일부는 기능적 제한입니다. 예를 들어 “센서 신뢰도가 떨어지면 아예 차로 변경 기능을 비활성화”하거나 “일부 상황에서는 운전자 경고 후 자동해제” 같은 식입니다. 또 다른 대책은 추가 감지/검증 로직으로, “앞차 추종 시 앞차 움직임이 이상하면 주변 랜드마크와 교차 검증”, “차선 모델과 차량 실제 주행궤적의 오차를 실시간 감시” 등의 방법이 언급됩니다. 그리고 운전자에게 단계적으로 경고를 주는 HMI 전략도 포함되어 있습니다. (예: 처음엔 시각/청각 경고 → 반응 없으면 비상등 켜고 서서히 감속 등 경고 에스컬레이션 전략)
흥미로운 부분은, 이렇게 트리거 시나리오를 식별하기 위해 실제 데이터를 활용했다는 점입니다. 연구진은 미국의 FARS(치명적 사고 보고 시스템) 데이터베이스를 참고해서, 고속도로에서 발생했던 다양한 사고 상황을 분석했습니다. 그 결과 평소 우리가 놓치기 쉬운 비정형 시나리오들을 트리거로 포함시켰습니다. 예를 들어, 고속도로 차선이 지워졌을 때 차로 유지 기능이 앞차를 따라서 주행하도록 프로그래밍되어 있다면 어떤 위험이 있을까요? 앞차가 만약 음주운전 차량처럼 심하게 지그재그로 움직인다면 우리 차량도 잘못 따라가서 차로를 이탈할 수 있습니다. 실제 FARS 데이터에서 “앞차가 불규칙하게 주행(swerve)하는 상황”이 사고로 이어진 경우들이 있었고, 이걸 보고서에 트리거 시나리오로 반영한 것입니다. 그리고 대책으로 “앞차 추종 시, 주변 도로 경계나 랜드마크를 함께 참고하여 앞차가 이상주행하면 그대로 따라가지 않도록 제한”하는 방법을 제안했습니다. 또 다른 예로, “강한 횡풍(crosswind)이나 도로의 블랙아이스” 같은 환경 조건도 사고 데이터에서 추출했습니다. 이런 상황에선 카메라가 차선을 제대로 못 볼 수 있는데, 보고서는 “조향 알고리즘이 추정한 경로와 차량 위치 센서가 보고하는 실제 움직임의 차이를 모니터링해서, 미끄러짐 징후나 오차가 크면 운전자에게 경고하거나 시스템을 안전모드로 전환”하는 식의 대처를 언급했습니다.
이러한 접근은 SOTIF 분석에서 시나리오를 발굴하는 방법론으로서 큰 의의가 있습니다. 실제 도로에서 벌어졌던 이례적 사건들을 체계적으로 분류하여 우리 시스템에 잠재된 위험 요인을 찾는다는 것입니다. ISO 21448 Annex나 다른 연구에서도 시나리오 분류 체계를 제시하고 있지만, 현실 데이터(FARS)로 보강한 점이 인상적입니다. 요약하자면, 이 NHTSA 연구는 “레벨 3 자율주행 시스템에 SOTIF 프로세스를 적용하면 이런 결과물이 나온다”를 하나의 사례로 보여준 것입니다. 보고서 말미에는 현재 업계에서 논의되는 SOTIF 검증 기법 (예: 시뮬레이션, 테스트 주행, 형식적 방법 등)과, 향후 이런 검증을 뒷받침할 데이터 필요성 (예: 다양한 주행 데이터 공유 등)에 대한 논의도 포함되어 있습니다. 이는 곧 향후 자율주행 차량의 안전 평가가 어떤 방향으로 나아갈지 시사하는 부분이기도 합니다.
6. 자율주행 개발자를 위한 시사점
이 보고서를 통해 얻을 수 있는 실질적인 시사점은 무엇일까요? 레벨 3 이상의 자율주행 시스템을 개발하는 엔지니어 관점에서 몇 가지 핵심 포인트를 정리해보면 다음과 같습니다:
- 운영 도메인(ODD)의 명확한 정의: 자율주행 기능이 어디까지 안전하게 동작할 수 있는지 그 경계를 정확히 설정해야 합니다. 그리고 시스템이 그 범위를 벗어나지 않도록 설계하는 것이 중요합니다. 예를 들어 이 보고서의 L3 시스템은 “차선이 잘 표시된 고속도로”로 ODD를 한정했습니다. 만약 차선이 사라지거나 악천후 등 ODD 조건을 벗어나면 즉시 운전자에게 제어를 넘기거나 시스템을 안전 모드로 전환해야 합니다. ODD를 명확히 하면, 불필요한 위험 시나리오에 휘말리지 않게 되고 SOTIF 확보가 수월해집니다.
- “알려진” 위험 시나리오에 대한 대응: 개발 과정에서 이미 인지한 Hazard 시나리오(위험요소)들은 명확한 안전 요구사항(Safety Goal)으로 관리하고 반드시 대응책을 구현해야 합니다. 이는 기존의 기능 안전 활동과도 일맥상통합니다. 예를 들어 “차로 변경 시 옆차 감지 실패로 인한 충돌 위험”을 알고 있다면, 추가 센서 장착이나 소프트웨어 보정 알고리즘 등으로 그 위험을 낮추는 대책을 제품에 반영해야 합니다. 알려진 위험을 방치하지 않는 것, 이것이 안전 개발의 기본이죠.
- “모르는” 위험을 찾아내기 위한 노력: 우리가 미처 생각하지 못한 시나리오(Unknown Unsafe)가 남아 있을 수 있다는 겸허한 전제가 필요합니다. 이를 줄이기 위해 다양한 시나리오에 대한 적극적인 테스트와 시뮬레이션을 수행해야 합니다. 단순한 주행 테스트만으로는 한계가 있으므로, 시뮬레이션을 활용하여 극한 상황까지 가정해보고, 과거의 사고 데이터나 이상주행 데이터도 분석에 사용해야 합니다. 이러한 데이터 중심, 시나리오 중심의 검증 문화가 SOTIF에서는 매우 중요합니다. SOTIF의 핵심 목표가 바로 알려지지 않은 위험을 찾아내 알려진 것으로 만드는 것이니까요. (일반적인 소프트웨어 테스팅의 edge case 찾기를 훨씬 확장한 개념이라고 보시면 됩니다.)
- 고장이 아닌 성능 한계에도 대비: 센서나 인지 알고리즘은 항상 일정 확률로 오인식이나 오판단을 할 수 있음을 염두에 두고, 이를 완화할 수 있는 체계를 갖춰야 합니다. 예를 들어 카메라가 빛 반사로 물체 인식을 못하면 레이더로 cross-check를 한다든지, 확신이 들지 않을 때는 차량을 더 천천히 움직이며 안전율을 높인다든지 하는 것입니다. 또한 시스템 자체적으로 자기 진단을 통해 센서 데이터를 신뢰도 점수(Confidence)로 표현하고, 이 점수가 낮으면 운전자에게 경고하거나 일부 기능을 제한하는 것도 SOTIF적인 설계입니다. 이러한 모니터링과 완화 조치가 있으면 설령 오인식이 발생해도 큰 사고로 이어질 확률을 줄일 수 있습니다.
- 운전자 인수(Takeover / Handover) 및 HMI 설계: 레벨 3 시스템은 결국 사람과 기계의 바통 터치가 존재합니다. 안전하려면 이 제어권 전환 과정이 매끄럽고 확실해야 합니다. 그러려면 운전자에게 언제 어떻게 경고를 줄지 체계가 중요합니다. 예컨대 처음에는 계기판에 노란 경고로 “곧 제어를 넘겨주세요”를 띄우고, 반응이 없으면 경고음을 크게 울리며, 그래도 응답 없으면 비상등을 켜고 서서히 감속하는 식의 단계적 대응이 필요합니다 (보고서에서도 이러한 경고 에스컬레이션 전략의 예시를 보여주었습니다). 엔지니어는 HMI와 제어 로직을 함께 고려하여, 운전자가 충분히 인지하고 개입할 수 있는 시간과 방법을 제공해야 합니다. 이는 SOTIF에서 말하는 “합리적으로 예견 가능한 오용”, 즉 운전자가 제때 개입하지 못하는 상황까지 대비하는 것이기도 합니다.
- 표준 및 모범 사례 활용: 마지막으로, 업계 표준과 가이드를 적극 활용하는 것도 좋은 방법입니다. 이미 말했듯이 현재는 ISO 26262 (기능 안전)와 더불어 ISO 21448 (SOTIF) 표준이 나와 있으니 개발 프로세스에 통합하는 것이 좋습니다. 또 이번 NHTSA 보고서처럼 공개된 연구 사례들을 참고하면 어떤 Hazard를 고려해야 할지, 어떤 대책들이 있는지 아이디어를 얻을 수 있습니다. SOTIF는 아직 진화 중인 분야라 국제 컨퍼런스나 논문에서 새로운 시나리오와 솔루션이 계속 나오고 있으므로, 정보에 촉각을 세우는 엔지니어의 자세가 필요합니다. 최근에는 자율주행 전체 시스템 안전을 다루는 UL 4600 같은 새로운 표준까지 제정되고 있으니, 우리 개발 제품에 맞는 안전 프레임워크를 지속적으로 업데이트해야 합니다.
7. 맺음말
ADAS/자율주행 시스템의 안전은 이제 “고장이 안 나는 것”을 넘어 “정상적으로 작동해도 실수하지 않는 것”까지 포괄하는 개념으로 확장되고 있습니다. NHTSA 2020 보고서는 이러한 변화에 발맞춰 엔지니어들이 어떻게 사고하고 개발해야 하는지 잘 보여주는 사례라고 생각됩니다. 차량을 설계할 때 기능의 한계까지도 미리 염두에 두고 안전을 확보하는 접근법은, 레벨 3 뿐만 아니라 레벨 4, 5 완전자율주행을 향한 길에서 필수적일 것입니다.
'Mobility > Safety Engineering' 카테고리의 다른 글
NHTSA - Automated Lane Centering 관련 기능 안전 분석 정리 (1) | 2025.05.06 |
---|---|
NHTSA - Functional Safety Assessment of an Automated Lane Centering System 정리 (0) | 2025.05.06 |