자율주행과 ADAS 기능이 고도화되면서, 차량 안전을 바라보는 시각도 근본적으로 달라지고 있습니다. 전통적으로 자동차 기능안전의 근간이었던 ISO 26262는 “시스템이 고장 나면 어떻게 할 것인가”라는 질문에 답하기 위해 만들어졌습니다. 수십 년간 이 접근은 매우 효과적이었습니다. 하드웨어가 고장 나거나 소프트웨어에 결함이 있을 때 차량이 안전한 상태로 전이하도록 설계하는 것, 이것이 기능안전의 핵심이었기 때문입니다.
그런데 한 가지 질문이 남습니다. 시스템이 설계대로 정상 동작하는데도 위험한 상황이 발생한다면, 그 책임은 어디에 있을까요? 카메라가 정상 작동하지만 강한 역광 때문에 전방 차량을 인식하지 못하는 경우, 레이더가 정상이지만 맨홀 뚜껑을 장애물로 오판하여 급제동하는 경우 – 이러한 상황은 엄밀히 말해 “고장”이 아닙니다. 시스템은 설계된 대로 동작하고 있지만, 그 설계 자체가 충분하지 않았던 것입니다.
바로 이 질문에서 출발한 것이 SOTIF(Safety of the Intended Functionality, ISO 21448)입니다. 본 글에서는 ISO 26262와 SOTIF가 각각 어떤 위험을 다루는지 깊이 있게 살펴보고, 두 표준의 경계가 실무에서 어떻게 교차하며, 통합적으로 적용하기 위해 무엇을 고려해야 하는지 논의하겠습니다.
1. ISO 26262 - 고장으로부터의 안전
ISO 26262가 다루는 위험의 원인은 크게 두 가지로 나뉩니다. 첫 번째는 하드웨어 랜덤 고장으로, 반도체 소자의 노화, 온도 스트레스, 전자기 간섭 등 물리적 원인에 의해 예측 불가능한 시점에 발생하는 고장입니다. 두 번째는 체계적 고장으로, 설계 오류, 사양 누락, 코딩 결함 등 개발 과정에서 유입되는 결정론적 오류를 말합니다. 하드웨어 랜덤 고장은 확률적 메트릭으로 정량 평가하고, 체계적 고장은 프로세스 준수와 검증 활동의 엄격도를 통해 관리합니다.
전동 조향 시스템의 모터 드라이버 IC가 단락 고장을 일으키면, 운전자가 조향 제어를 상실하여 차선 이탈이나 대향차와의 충돌로 이어질 수 있습니다. ISO 26262는 앞서 말씀 드린 위험의 관점에서, 이러한 고장 시나리오를 체계적으로 식별하고 이중화 설계, 안전 상태 전이, 고장 감지 및 진단 등의 안전 메커니즘을 통해 위험을 허용 가능한 수준으로 낮추도록 요구합니다.
정리하면, ISO 26262의 관점에서 “안전하다”는 것은 시스템에 고장이 발생하더라도 차량이 안전한 상태를 유지하거나, 합리적인 시간 내에 안전한 상태로 전이할 수 있다는 것을 의미합니다.
2. SOTIF(ISO 21448) - 의도된 기능의 한계로부터의 안전
SOTIF는 ISO 26262와는 근본적으로 다른 질문을 던집니다. 시스템에 고장이 없는데도 위험한 상황이 발생할 수 있는가? 이 질문에 대한 답은 명확히 “그렇다”입니다.
ADAS나 자율주행 시스템은 센서로 주변 환경을 인지하고, 알고리즘으로 상황을 판단하며, 액추에이터를 통해 차량을 제어합니다. 이 과정에서 센서의 물리적 성능 한계, 알고리즘의 불충분한 판단 능력, 개발자가 예상하지 못한 운용 조건 등이 고장 없이도 위험을 만들어낼 수 있습니다. ISO 21448은 2022년에 정식 발행되었으며, 시스템 고장이 아닌 차량 수준 기능 명세의 불충분(vehicle-level specification insufficiency), E/E 구현의 사양 및 성능 한계, 합리적으로 예측 가능한 오용(reasonably foreseeable misuse)에서 비롯되는 비합리적 위험을 다룹니다.
SOTIF가 식별하는 위험의 원인을 좀 더 구체적으로 살펴보겠습니다. 첫째, 기능 명세의 불충분입니다. 기능을 정의할 때 모든 운용 시나리오를 고려하지 못하면, 특정 조건에서 시스템이 의도하지 않은 방식으로 동작할 수 있습니다. 예를 들어, AEB 시스템의 요구사항이 “전방 차량과의 충돌 위험 시 자동 제동”이라고만 정의되어 있고, 정지 차량과 움직이는 차량의 구분, 곡선 도로에서의 거동 등이 명세되지 않았다면, 이는 기능 명세의 불충분에 해당합니다.
둘째, 센서와 알고리즘의 성능 한계입니다. 카메라는 역광, 야간, 폭우 등의 조건에서 인식 성능이 급격히 저하될 수 있고, 라이다는 검은색 차량이나 비반사 물체에 대해 탐지 거리가 줄어들 수 있습니다. 머신러닝 기반 인지 알고리즘은 학습 데이터에 포함되지 않은 물체나 상황에 대해 예측 불가능한 출력을 내놓을 수 있습니다. 셋째, 합리적으로 예측 가능한 오용(misuse) 입니다. 운전자가 시스템의 기능 범위를 오해하거나, 의도된 사용 조건을 벗어나 시스템을 사용하는 경우가 이에 해당합니다.
대표적인 SOTIF 관련 위험 시나리오를 살펴보면, 그 특성이 더욱 명확해집니다. AEB 시스템이 강한 역광 조건에서 전방 차량을 인식하지 못해 제동이 지연되는 경우를 생각해 보겠습니다. 카메라 센서는 정상 동작하고 있고, 이미지 처리 알고리즘도 설계대로 실행되고 있지만, 역광이라는 환경 조건이 객체 인식 성능을 저하시켜 위험이 발생합니다. 반대의 경우도 있습니다. 도로 위 맨홀 뚜껑이나 그림자를 장애물로 오인식하여 불필요하게 급제동하는 상황은, 뒤따르는 차량과의 추돌 위험을 초래합니다. 이 모든 것은 시스템 고장이 아니라 의도된 기능 자체의 한계에서 비롯됩니다.
SOTIF는 트리거 조건과 시나리오 분석을 중심으로 접근합니다. 트리거 조건이란 시스템의 기능적 불충분함을 활성화시키는 특정 조건을 의미하며, 환경적 조건(날씨, 조명, 도로 상태), 인프라 조건(차선 표시 상태, 교통 신호 배치), 다른 교통 참여자의 행동(예측 불가능한 보행자 움직임) 등이 포함됩니다. SOTIF의 궁극적 목표는 알려진 위험 시나리오를 해소하고, 미지의 위험 가능성을 체계적인 탐색과 검증을 통해 수용 가능한 수준까지 낮추는 것입니다.
또한 주목할 점은 SOTIF에는 ISO 26262의 ASIL과 같은 등급 체계가 존재하지 않는다는 것입니다. 대신 위험의 허용 가능성을 자체적인 기준으로 평가하며, 시뮬레이션, 실차 시험, 필드 데이터 분석 등 다양한 검증 수단을 통해 잔여 위험이 수용 가능한 수준임을 입증해야 합니다.
3. 두 표준의 경계: 어디서 나뉘고, 어디서 만나는가
두 표준의 관계를 이해하기 위해서는 위험의 원인을 기준으로 구분하는 것이 가장 명확합니다. 대표적인 사례를 비교하면 차이가 더욱 선명해집니다. 센서의 통신 라인이 단선되어 데이터 전송이 중단되는 것은 ISO 26262의 영역입니다. ECU 내부의 연산 유닛에서 비트 플립(bit flip)이 발생하여 잘못된 제어 값이 출력되는 것도 마찬가지입니다. 반면, 카메라가 역광 환경에서 전방 물체를 오인식하는 것, 머신러닝 알고리즘이 학습되지 않은 유형의 장애물에 대해 잘못된 판단을 내리는 것은 SOTIF의 영역입니다.
그러나 실무에서는 두 표준의 경계가 항상 깔끔하게 나뉘지 않습니다. 대표적으로 세 가지 영역에서 경계의 모호함이 나타납니다. 첫째, 센서 성능 저하(degradation) 문제입니다. 센서가 완전히 고장 나서 출력이 멈추거나 비정상 값을 내보내는 것은 명백히 ISO 26262의 영역입니다. 그러나 센서가 동작은 하되 성능이 점진적으로 저하되는 경우는 어떨까요? 카메라 렌즈에 먼지나 이물질이 쌓여 인식률이 서서히 떨어지는 경우, 레이더 안테나의 미세한 정렬 오차로 탐지 정확도가 감소하는 경우가 이에 해당합니다. 이러한 상황은 “고장”으로 볼 수도 있고, “성능 한계가 드러난 것”으로 볼 수도 있어, 두 표준의 경계에 걸치게 됩니다.
둘째, 소프트웨어 알고리즘 오류의 분류입니다. 명확한 코딩 결함으로 인한 오동작은 ISO 26262의 체계적 고장에 해당합니다. 예를 들어, 변수 오버플로우로 인해 제어 값이 비정상적으로 커지는 경우가 그렇습니다. 반면, 알고리즘 자체의 설계 한계는 SOTIF의 범위입니다. 머신러닝 모델의 일반화 성능이 부족하여 학습 데이터에 없던 상황에서 잘못된 출력을 내는 경우가 대표적입니다. 그런데 실제 개발 현장에서 “이것이 코딩 버그인가, 아니면 알고리즘 설계의 한계인가”를 명확히 구분하기 어려운 경우가 적지 않습니다.
셋째, 운전자 오용의 범위입니다. 합리적으로 예측 가능한 오용, 예를 들어 운전자가 레벨 2 ADAS 시스템을 사용하면서 전방 주시를 게을리하는 경우는 SOTIF에서 다룹니다. 그러나 비합리적 오용, 즉 운전자가 의도적으로 시스템을 오작동시키려는 행위 등은 두 표준 모두의 범위를 벗어납니다. 문제는 “합리적으로 예측 가능한” 오용의 경계를 어디에 설정하느냐에 따라 분석의 범위가 크게 달라진다는 것입니다.
4. 실무 적용: 통합적 안전 분석 접근법
두 표준을 별개의 활동으로 분리하여 수행하면 비효율적일 뿐만 아니라, 두 표준의 경계 영역에 놓인 위험 시나리오가 누락될 가능성이 높아집니다. 따라서 실무에서는 ISO 26262와 SOTIF를 통합적으로 접근하는 것이 바람직합니다.
4.1 위험원 분석 단계의 통합
가장 효과적인 통합 지점은 위험원 분석 단계입니다. ISO 26262의 HARA를 수행할 때, 고장 기반 위험원뿐 아니라 기능 한계 기반 위험원도 함께 식별하는 것입니다. 예를 들어, “전방 충돌”이라는 위험 시나리오를 분석한다면, ISO 26262 관점에서는 “AEB 시스템의 제어 모듈 고장으로 제동 명령이 전달되지 않는 경우”를 식별하고, 동시에 SOTIF 관점에서는 “역광, 안개, 터널 출구 등의 환경 조건에서 전방 차량 인식이 지연되는 경우”를 함께 식별합니다. 이렇게 하면 동일한 위험 시나리오에 대해 고장 원인과 기능 한계 원인을 모두 포괄하는 안전 컨셉을 수립할 수 있으며, 중복 분석을 줄이고 누락을 방지할 수 있습니다.
4.2 요구사항 정의 단계의 통합
동일 기능에 대해 Safety Requirement와 SOTIF Requirement를 분리하지 않고 시스템 및 소프트웨어 등의 요구사항 정의 단계에서 통합된 형태로 기술에 해당합니다.
예를 들어, 특정 AEB 기능에 대해:
- 센서 고장에 대한 대응 요구사항 (Functional Safety)
- 오검출/미검출에 대한 성능 요구사항 (SOTIF) 을
하나의 요구사항 구조 내에서 관리함으로써, 설계 및 검증 단계에서의 일관성을 확보할 수 있습니다.
4.3 Verification & Validation 단계의 통합
Verification 및 Validation 단계에서는 두 표준의 접근 방식이 명확히 구분되지만, 실제 프로젝트에서는 통합 전략이 요구됩니다.
- ISO 26262: Fault injection, safety mechanism 검증 중심
- ISO 21448: Scenario 기반 validation, edge case 분석 중심
특히, 시스템 Validation 단계에서는 Fault 기반 시험과 Scenario 기반 시험을 동일 Validation 전략 내에서 통합하여, 실제 운행 환경을 반영한 다양한 시나리오를 기반으로 안전성 검증 수행합니다. 이러한 통합 검증 접근은 실제 차량 환경에서 발생 가능한 복합적인 위험을 효과적으로 커버할 수 있습니다.
4.4 시나리오 기반 검증의 확대
ISO 26262의 검증은 전통적으로 고장 주입(fault injection) 테스트와 안전 메커니즘의 진단 커버리지 평가에 집중합니다. 특정 고장을 인위적으로 주입하고, 시스템이 이를 감지하여 안전 상태로 전이하는지를 확인하는 것입니다. SOTIF는 여기에 더해 다양한 환경 조건과 엣지 케이스(edge case)에 대한 시나리오 기반 검증을 요구합니다.
이를 위해서는 시뮬레이션 환경에서 수만에서 수백만 개의 시나리오를 자동으로 생성하고 실행하는 대규모 시나리오 테스트가 필요합니다. 또한 실제 도로에서 수집한 주행 데이터를 분석하여 시뮬레이션에서 다루지 못한 미확인 시나리오를 탐색하는 과정이 수반되어야 합니다. 특히 ODD(Operational Design Domain) 경계 조건, 즉 시스템이 정상 동작하도록 설계된 영역의 가장자리에서 시스템이 어떻게 거동하는지를 면밀히 확인하는 것이 중요합니다. ODD를 벗어나는 순간 시스템이 안전하게 기능을 축소하거나 운전자에게 제어권을 이양할 수 있어야 하기 때문입니다.
4.5 잔여 위험의 통합 평가
ISO 26262에서는 ASIL 등급에 따른 정량적/정성적 안전 목표 달성 여부를 평가합니다. 하드웨어 랜덤 고장에 대해서는 PMHF, SPFM, LFM 등의 정량 지표를 산출하고, 체계적 고장에 대해서는 프로세스 준수도와 검증 활동의 완전성을 평가합니다.
SOTIF에서는 접근이 다릅니다. 알려진 및 잠재적 트리거 조건을 체계적으로 탐색하고, 시뮬레이션 커버리지, 실차 주행 거리, 필드 데이터 분석 결과 등 검증과 운영 증거를 종합적으로 제시하여, 미지의 위험 가능성에 대한 충분한 탐색과 저감이 이루어졌음을 논증해야 합니다. 두 관점의 잔여 위험 평가를 통합적으로 수행함으로써, 고장에 의한 위험과 기능 한계에 의한 위험을 모두 아우르는 보다 완전한 안전 논증(safety case) 을 구축할 수 있습니다.
5. 마무리: 자율주행 시대의 안전 분석 프레임워크
자율주행 레벨이 높아질수록 SOTIF의 중요성은 더욱 커집니다. SAE J3016 기준 레벨 2 이하에서는 운전자가 상시 차량을 감시하고 최종 안전 책임을 지므로, 기능 한계에 의한 위험을 운전자의 즉각적인 개입으로 완화할 수 있습니다. 시스템이 전방 차량을 놓치더라도 운전자가 이를 발견하고 브레이크를 밟으면 됩니다.
그러나 레벨 3(조건부 자동화) 이상에서는 상황이 근본적으로 달라집니다. 시스템이 동적 운전 과업(DDT, Dynamic Driving Task)의 전부 또는 상당 부분을 책임지므로, 의도된 기능의 한계를 운전자가 아닌 시스템 차원에서 관리해야 합니다. 레벨 3에서는 시스템이 한계 상황을 인지하고 운전자에게 충분한 시간을 두고 제어권을 이양(take-over request)해야 하며, 레벨 4 이상에서는 운전자 개입 없이 시스템 스스로 안전한 상태에 도달할 수 있어야 합니다. 이는 SOTIF 관점에서 훨씬 광범위하고 엄격한 시나리오 분석과 검증을 요구합니다.
향후 자율주행 시대의 종합적 안전 분석 프레임워크는 네 가지 축을 유기적으로 연결해야 합니다. ISO 26262는 하드웨어와 소프트웨어 고장에 대한 기능안전 프레임워크를 제공하고, ISO 21448(SOTIF) 은 기능 명세와 성능 한계에서 비롯되는 위험을 다루는 프레임워크를 제공합니다. 여기에 ISO/SAE 21434가 사이버보안 위협에 대한 엔지니어링 프레임워크를 제공하고, UN R155/R156은 사이버보안 관리체계와 소프트웨어 업데이트 관리체계에 대한 규제 요구를 제공하며, 이는 차량 안전 논증을 보완하는 요소로 작동합니다. 이 네 가지 축이 서로 독립적으로 운영되는 것이 아니라 하나의 통합된 안전 논증 안에서 상호 참조되고 보완될 때, 비로소 자율주행 시대에 요구되는 수준의 안전성을 입증할 수 있습니다.