SOTIF (ISO21448:2022) 개요

Junique 2025. 5. 8. 23:36

1. Introduction

운전자 지원 시스템(ADAS)부터 완전 자율주행까지 차량의 자동화 수준이 높아질수록 새로운 종류의 안전 문제가 대두되고 있습니다. 기존에는 ISO 26262 기능 안전 표준으로 전기/전자 시스템의 결함에 따른 위험을 관리해왔지만, 자율주행 차량에서는 결함이 없어도 발생하는 위험까지 고려해야 한다는 점이 명확해졌습니다. 예를 들어, 차량 센서와 소프트웨어가 정상적으로 동작하고 있음에도 불구하고 특정 도로 환경이나 사용 방법에 따라 사고로 이어질 수 있는 상황들이 존재합니다. 이러한 배경에서 2022년 국제 표준으로 제정된 ISO 21448:2022 “도로 차량 – 의도된 기능성의 안전(SOTIF: Safety of the Intended Functionality)”이 등장하게 되었습니다. 본 포스트에서는 SOTIF 표준의 개념과 제정 목적, 자율주행 시스템에 적용하는 방법과 실제 사례, 그리고 다른 관련 표준들과의 관계 및 향후 도전 과제에 대해 살펴보겠습니다.

2. ISO 21448 (SOTIF)의 제정 배경과 목적

전통적인 차량 안전 접근법은 결함(Fault)을 중심으로 이루어졌습니다. ISO 26262 (기능 안전)은 차량 전자장치의 하드웨어 고장이나 소프트웨어 버그 등 오작동으로 인해 발생하는 위험을 줄이는 데 초점을 맞추고 있습니다. 그러나 시간이 지남에 따라 이러한 접근만으로는 첨단 운전자 지원 시스템(ADAS)이나 자율주행에서 나타나는 모든 위험 요소를 다 포괄하기 어렵다는 인식이 생겼습니다. 자율주행차에는 사람 대신 복잡한 센서와 알고리즘이 주변을 인식하고 판단하게 되는데, 이들은 작동에는 이상이 없어도 현실 세계의 무수히 다양한 상황에서 예기치 못한 행동을 보일 수 있기 때문입니다.

이러한 공백을 메우기 위해 자동차 업계는 새로운 안전 표준인 SOTIF을 도입하였습니다. SOTIF는 “의도된 기능의 안전성(Safety Of The Intended Functionality)”의 약자로, 시스템이 의도된 대로 동작하고 있음에도 발생할 수 있는 위험을 다룹니다. ISO 21448:2022는 SOTIF에 대한 일련의 프로세스와 가이드라인을 제공하여, 자율주행 시대에 적합한 안전 확보 방법론을 제시하는 것을 목적으로 합니다. 쉽게 말해, SOTIF는 기존 기능 안전이 다루지 못하는 부분 – 시스템이 고장나지 않았는데도 발생하는 위험 – 을 식별하고 감소시키는 데 초점을 둔 표준입니다.

3. SOTIF의 개념: 의도된 대로 동작하지만 안전하지 않은 경우

ISO 21448에서는 SOTIF(의도된 기능의 안전성)을 다음과 같이 정의합니다:

"의도된 기능의 기능 효과 부실이나 합리적으로 예상 가능한 인적 오용으로 발생하는 위험에 따른 불합리한 위험이 없는 상태"

즉, 시스템의 기능적 한계(불충분)나 예상 가능한 오용으로 인해 발생할 수 있는 모든 불합리한 위험(absence of unreasonable risk)을 배제한 상태가 SOTIF의 목표입니다. 여기서 “의도된 기능의 기능 효과 부실”이란 센서나 알고리즘 등이 정상 작동은 하지만 성능상 한계로 인해 상황을 제대로 인지·대응하지 못하는 경우를 의미합니다. 또한 “예상 가능한 오용”이란 사용자가 시스템을 잘못 사용하거나 시스템의 한계를 몰라 발생하는 위험을 가리킵니다.

예를 들어, 카메라 기반의 차선 유지 보조 시스템을 생각해보겠습니다. 이 시스템이 하드웨어나 소프트웨어 결함 없이 정상 작동 중이지만 강한 역광이나 폭우와 같은 상황에서는 카메라 센서가 차선을 제대로 인식하지 못할 수 있습니다. 또 다른 예로, 운전자가 첨단 운전자 보조 기능을 과신하여 차선 변경 기능을 켠 채 전방 주시를 소홀히 하는 것도 합리적으로 예상 가능한 오용에 해당합니다. 이렇듯 SOTIF는 시스템이 의도대로 동작함에도 안전하지 못하게 되는 시나리오들을 찾아내고 방지하는 개념입니다. 이는 기존의 기능 안전(결함 방지)과는 다른 새로운 패러다임으로, 자율주행차의 안전을 한층 강화하기 위해 도입되었습니다.

4. 기능 안전(ISO 26262)과 SOTIF의 차이점

두 표준의 큰 차이는 어떤 위험을 다루는가입니다. ISO 26262가 E/E 시스템의 고장으로 인한 위험을 다루는 반면, SOTIF는 고장이 없는 상태에서도 발생할 수 있는 위험을 대상으로 합니다. 아래 표는 ISO 26262 기능 안전과 ISO 21448 SOTIF의 주요 차이점을 비교한 것입니다.

구분	ISO 26262 (기능 안전)	ISO 21448 (SOTIF)
대상 위험	전기/전자 시스템의 고장(결함)으로 인한 위험 – 하드웨어 오작동, SW 버그 등	고장 없는 상태에서 기능 성능 한계나 오용으로 인한 위험 – 센서/알고리즘 인지 한계, 사용자 오용 등
접근 방식	HARA 등을 통해 위험도 분석 및 ASIL 등급 결정 결함 예방 및 안전 메커니즘 설계 (이중화, 고장 감지 등)	시나리오 분석으로 유해한 상황(해저드) 식별 및 트리거 조건 도출 설계 개선, ODD 제한 등으로 위험 최소화
검증 방법	결함 주입 테스트, 부품 신뢰성 시험 등 결함 대응 검증 중심	시나리오 기반 테스트 및 시뮬레이션으로 알려진 위험 시나리오 검증, 미지의 위험 시나리오 탐색을 위한 검증/평가
표준 성격	2011년 제정, 2018년 개정 – 성숙한 기능 안전 국제표준 자동차 E/E 결함으로 인한 위험 관리가 목적	2019년 PAS 발행, 2022년 국제표준 확정 – 기능 안전 보완 표준, ADAS/자율주행 기술로 인한 새로운 위험 관리가 목적

두 표준은 이렇듯 다루는 범위와 기법이 상호 보완적입니다. 기능 안전이 “고장나지 않도록 혹은 고장 시 안전하게(fail-safe)” 만드는 것이라면, SOTIF는 “고장 없어도 위험하지 않도록” 만드는 것이라고 요약할 수 있습니다. 따라서 자율주행 시스템 개발에서는 ISO 26262와 ISO 21448 두 가지를 모두 충족함으로써 결함발생 및 비결함 상황 모두에 대비한 종합적인 안전 확보가 필요합니다.

5. SOTIF가 다루는 시스템 수준 안전 이슈

그렇다면 SOTIF에서 말하는 "의도된 기능의 기능적 불충분"에는 어떤 구체적인 사례들이 있을까요? SOTIF가 다루는 대표적인 시스템 수준 이슈들은 다음과 같습니다:

인지 한계와 오인식: 카메라, 레이더, 라이더와 같은 센서의 한계로 인해 객체를 놓치거나 잘못 인식하는 경우입니다. 예를 들어 밝은 하늘 배경에 흰색 트럭이 있다면 비전 시스템이 트럭의 윤곽을 분간하지 못하거나, 센서 퓨전이 예상치 못한 물체를 잘못 분류하는 상황입니다. 이러한 인지 성능 부족은 시스템 고장이 아니지만 위험을 초래할 수 있습니다.
경계 조건(edge case) 시나리오: 시스템이 설계된 운용 설계 범위(ODD)의 극한 경계에 있는 시나리오들입니다. 극한 날씨(폭우, 폭설, 안개), 매우 희귀한 도로 상황(예: 도로에 떨어진 이례적인 장애물), 복잡한 교통 상황 등에서 시스템이 의도와 다르게 대응할 수 있습니다. 예를 들어 자동 비상제동(AEB) 기능이 빙판길이나 공사 구간 같은 특별한 노면 상태에서는 성능이 저하되는 경우가 이에 해당합니다.
합리적으로 예측 가능한 오용: 운전자나 사용자에 의한 잘못된 사용으로 인한 위험입니다. 대표적으로 레벨 2 자율주행(부분 자동화) 시스템을 운전자가 지나치게 신뢰하여 운전 부주의를 하는 것이 있습니다. 2016년 테슬라 차량의 사망 사고에서 운전자가 자동조향 장치를 켠 채 동영상을 시청하며 전방 주시 의무를 소홀히 한 것이 하나의 사례입니다. 이처럼 사용자가 시스템 능력을 과신하거나, 경고를 무시하거나, 의도된 사용 조건을 벗어나 활용하는 행위는 모두 오용으로 인한 위험 요소입니다.
시스템 요구사항 누락: 개발 단계에서 특정 상황에 대한 대비가 요구사항에 반영되지 않아 발생하는 안전 공백도 SOTIF 범주에 들어갑니다. 예를 들어, 어떤 ADAS 소프트웨어가 드문 교통신호 조합에 대한 로직이 구현되지 않았다면, 해당 상황에서 오동작은 결함이 아닌 사양 불충분으로 볼 수 있습니다. 이러한 경우도 SOTIF 관점에서 식별하여 대처해야 합니다.

요컨대 SOTIF가 다루는 것은 시스템이 정상적으로 동작 중임에도 외부 요인이나 설계 미비로 인해 유발되는 위험 시나리오 전반입니다. 이러한 시나리오들은 자율주행 시스템의 센서 인지, 판단 알고리즘, 제어 로직, 사용자와의 상호작용 등 시스템 종합적인 수준에서 나타나며, 각각에 대해 안전 대책이 필요합니다.

6. 자율주행 및 ADAS에서의 SOTIF 사례 연구

SOTIF 개념은 이미 여러 자율주행 및 ADAS 사례에서 그 중요성이 드러났습니다. 아래 사례들은 기능 결함이 아닌 기능 한계나 사용 문제로 인해 발생한 실제 사고/오동작 사례들입니다.

사례 1: 밝은 하늘에 가려진 트레일러 인지 실패 – 2016년 미국 플로리다에서 발생한 테슬라 모델 S 사고는 SOTIF의 대표적 사례로 자주 언급됩니다. 차량의 자동조향(오토파일럿) 시스템이 밝은 대낮에 하얀색 트레일러 트럭의 옆면을 하늘로 오인하여 앞차로 인식하지 못했고, 제동이 걸리지 않아 차량이 트레일러 아래로 돌진했습니다. 이 사고에서 차량 시스템에는 하드웨어 결함이 없었지만, 비전 알고리즘의 한계로 특정 배경/물체 조합을 탐지하지 못한 것이 원인이었습니다. 또한 운전자가 당시 전방을 주시하지 않고 주의 의무를 다하지 않은 misuse(오용) 요인도 함께 지적되었습니다. 이 사례는 SOTIF에서 말하는 센서 인지 한계와 사용자 오용이 복합적으로 드러난 비극적인 예입니다.
사례 2: 자율주행 시험차의 보행자 인식 오류 – 2018년 미국 애리조나주 템피에서 Uber의 자율주행 시험 차량이 밤에 도로를 건너던 보행자를 치어 사망에 이르게 한 사고가 있었습니다. 미 교통안전위원회(NTSB) 조사에 따르면, 해당 차량의 자율주행 소프트웨어는 횡단하는 보행자를 끝까지 “알 수 없는 객체” 등으로 분류하여 즉각적인 제동을 하지 못했습니다. 이는 알고리즘이 학습한 범위를 벗어난 비정형 상황(밤에 자전거를 끌고 무단횡단하는 보행자)을 제대로 인식하지 못한 기능적 한계 사례입니다. 또한 당시 차량에 탑승한 안전 요원이 운전에 충분히 집중하지 않아 제때 개입하지 못했던 점도 문제였습니다. 이 사고 역시 SOTIF 관점에서 인지 성능 부족과 인적 감독 부재라는 복합 요인이 작용한 사례입니다.
사례 3: AEB의 오경보 및 고스트 급제동 – 일부 차량의 자동 긴급제동 시스템이 실제로 위험이 없는 상황에서 잘못된 충돌 판단으로 급제동하는 현상이 보고된 바 있습니다. 예를 들어 고속도로 주행 중 고가도로의 그림자를 차량 또는 장애물로 인식하여 갑자기 브레이크를 거는 이른바 “고스트로 인한 제동” 현상도 SOTIF 이슈(잘못된 객체 인식)**로 분류됩니다. 이러한 오작동은 센서 데이터 해석상의 한계나 알고리즘 과민 반응(false positive) 때문에 발생하며, 뒤따르는 차량에 2차 위험을 초래할 수 있습니다.

위 사례들은 공통적으로 시스템 자체는 고장나지 않았음에도 특정 조건에서 안전에 문제가 발생했음을 보여줍니다. SOTIF 표준은 이러한 사례들에서 교훈을 얻어, 사전에 이러한 위험 시나리오를 예측·관리할 수 있도록 체계적인 분석과 시험 방법을 제시하고 있습니다.

7. SOTIF와 관련 표준/프레임워크의 연계

자율주행차 개발에는 SOTIF 외에도 다양한 표준과 프레임워크들이 적용되며, 상호 보완적으로 통합되는 추세입니다. ISO 21448 SOTIF과 함께 고려해야 할 주요 표준들로 ISO/PAS 8800 (AI 안전), ISO/SAE 21434 (사이버보안), Automotive SPICE (ASPICE), IATF 16949 (자동차 품질) 등이 있습니다. 각각 SOTIF와 어떤 관계가 있는지 살펴보겠습니다.

ISO/PAS 8800:2024 – 도로 차량 AI 안전: 이 표준(PAS)은 인공지능/머신러닝이 적용된 자동차 시스템의 안전을 다루며, 기존 ISO 26262와 SOTIF를 AI 분야로 확장한 것입니다. 자율주행에 딥러닝 기반 인식 등이 활용되면서, 데이터 편향이나 학습모델의 불확실성이 새로운 위험을 낳고 있습니다. ISO/PAS 8800은 이러한 AI 모델의 성능 불충분이나 오류로 인한 위험을 관리하기 위한 개발 프로세스를 제시하여 SOTIF 개념을 보강합니다. 예를 들어, AI 모델의 훈련 데이터 한계로 인해 발생하는 인지 오류도 SOTIF의 범주이지만, 8800에서는 AI 개발 단계(데이터셋 관리, 모델 검증 등)에 특화된 가이던스를 제공합니다. 향후 ISO/PAS 8800은 정식 국제표준으로 발전하면서 SOTIF와 더욱 긴밀히 통합될 전망입니다.
ISO/SAE 21434 – 자동차 사이버보안: 사이버보안 표준 ISO 21434는 커넥티드카와 자율주행차의 보안 위협을 다룹니다. 보안과 안전은 밀접한 관계가 있기 때문에, 해커에 의한 공격이나 소프트웨어 무결성 훼손이 안전 문제로 직결될 수 있습니다. 예를 들어 공격자가 센서 신호를 조작하면 SOTIF 관점의 오인식 위험을 의도적으로 야기할 수 있습니다. 따라서 ISO 21434의 구현은 SOTIF 및 기능 안전과 조화를 이루도록(harmonized) 진행되어야 한다는 것이 업계의 인식입니다. 실제로 UNECE WP.29 사이버보안 규정 등에서는 제조사가 사이버보안과 안전을 모두 충족할 것을 요구하고 있습니다. 요약하면, 안전(Safety)과 보안(Security)은 자율주행차 개발 프로세스에서 서로 영향을 주므로, SOTIF 분석 시에도 보안 취약점으로 인한 오동작 가능성을 고려해야 합니다.
Automotive SPICE (ASPICE): ASPICE는 자동차 소프트웨어 프로세스에 대한 성숙도 모델로, 개발 조직이 표준화된 프로세스를 갖추도록 요구합니다. SOTIF 프로세스는 ASPICE의 시스템/소프트웨어 개발 단계와 연계되어 수행될 수 있습니다. 예를 들어 요구사항 분석 단계에서 SOTIF 위험 시나리오에 대한 요구사항을 식별하고, 설계 단계에서 이를 반영하며, 테스트 단계에서 시나리오 기반 검증을 수행하는 식입니다. 많은 OEM들은 공급사에 ASPICE 준수를 요구하기 때문에, SOTIF 활동 또한 ASPICE 프로세스에 녹여서 진행하게 됩니다. 또한 ASPICE는 추적성 관리, 검증·확인 등 프로세스상의 모범 사례를 제공하므로, SOTIF에서 도출된 위험 분석 결과와 테스트 케이스들을 체계적으로 관리하는 데 도움을 줍니다. 한편 ISO 26262 기능 안전도 ASPICE와 통합적으로 구현되는 경우가 많아, 기능 안전 + SOTIF + ASPICE를 함께 충족하는 개발환경 구축이 중요해지고 있습니다.
IATF 16949 – 자동차 품질경영 시스템(QMS): IATF 16949는 자동차 산업의 품질 경영에 관한 국제 규격으로, 제품 개발 전 과정에 걸쳐 리스크 기반의 품질 관리를 강조합니다. 안전은 품질의 핵심 요소 중 하나이므로, 기능 안전과 SOTIF 같은 안전 프로세스는 IATF 16949의 제품 실현 프로세스 내에 통합되어 운영됩니다. 예를 들어 조직의 품질 매뉴얼에 기능 안전 및 SOTIF 준수를 위한 절차를 포함하고, 변경 관리 시 안전 영향 평가를 거치도록 규정하는 식입니다. 또 IATF 16949는 고객 요구사항 준수를 중요시하므로, 완성차 업체가 SOTIF 준수를 요구할 경우 이를 품질 시스템에서 관리해야 합니다. 요약하면 IATF 16949는 조직 차원에서 SOTIF를 포함한 안전 활동이 체계적으로 이루어지도록 뒷받침하는 상위 프레임워크 역할을 합니다.

이처럼 SOTIF는 다른 여러 표준들과 함께 자율주행차의 안전을 다각도로 보장하는 퍼즐의 한 조각이라 할 수 있습니다. 한 가지 표준만으로는 복잡한 안전 요구사항을 모두 충족하기 어렵기 때문에, 통합적 시각에서 기능 안전, SOTIF, 사이버보안, 프로세스 품질, AI 안전 등을 종합적으로 적용하는 것이 업계의 흐름입니다.

8. 개발 수명주기에서의 SOTIF 프로세스 적용

그렇다면 실제 개발 프로젝트에서 SOTIF는 언제, 어떻게 적용될까요? ISO 21448은 위험 식별에서 검증까지 전 과정을 아우르는 체계적인 SOTIF 프로세스를 권고하고 있으며, 이는 일반적으로 V-모델 등 시스템 개발 수명주기에 통합됩니다. 주요 단계를 순서대로 살펴보겠습니다.

출처: https://www.autoelectronics.co.kr/article/articleView.asp?idx=3151

개념 단계: 아이템 정의 및 위험 식별 – 개발 초기에 시스템의 기능(아이템)과 사용될 시나리오를 명확히 정의하고, 잠재적 위험 시나리오를 식별합니다. 여기에는 기능 안전을 위한 HARA(Hazard Analysis and Risk Assessment)와 별도로 SOTIF 관점에서의 해저드 식별이 이루어집니다. 예를 들어, 시스템이 대응하기 어려운 환경 조건이나 센서의 약점, 사용자 오용 시나리오를 브레인스토밍하고 과거 사고 사례도 조사합니다. 이렇게 찾아낸 해저드 각각에 대해 해당 위험을 유발하는 트리거 조건(triggering condition)이나 이벤트가 무엇인지 분석합니다. (예: “밝은 햇빛 + 흰색 물체”가 트리거 조건이 되어 인지 실패 해저드를 유발).
안전 목표 및 요구사항 수립 – 식별된 SOTIF 해저드들을 없애거나 줄이기 위한 안전 목표(Safety Goals)를 설정합니다. 그리고 이를 만족하기 위한 시스템의 개선 요구사항이나 제약사항을 도출합니다. 개선 요구사항의 예로는 센서 사양 향상, 알고리즘 보정, 또는 특정 조건에서는 시스템이 작동을 제한하도록(Odd 제한) 하는 것이 있을 수 있습니다. 또한 사용자 오용을 줄이기 위해 UI/경고 메시지 개선이나 사용자 교육 방안도 요구사항에 포함될 수 있습니다. 이러한 요구사항들은 ISO 26262상의 기능 안전 요구사항과 함께 시스템 설계에 반영됩니다.
설계 단계: 기능 개선 및 구현 – 수립된 요구사항에 따라 시스템을 구체적으로 설계합니다. SOTIF 해저드를 낮추기 위한 설계 조치를 취하는 단계로, 예를 들어 다중 센서 융합으로 단일 센서의 한계를 보완하거나, 알고리즘 튜닝을 통해 오탐지율/미탐지율을 낮추는 작업이 해당됩니다. 혹은 완전히 기술적인 해결이 어려운 해저드의 경우 운용 설계 범위(ODD) 제한을 명시하여, 시스템이 안전하게 작동할 수 있는 조건을 제한하는 것도 설계상의 조치입니다. 설계 변경으로 위험이 얼마나 줄었는지 SOTIF 위험 평가를 수행하며, 필요시 추가 해저드가 나타나지는 않았는지 반복적으로 검토(iteration)합니다.
검증 단계: 알려진 시나리오 검증 (Verification) – 설계 단계에서 대응한 알려진 위험 시나리오들에 대해 시험을 수행합니다. 각 해저드에 대응하는 시험 시나리오를 만들어, 실제 시스템이 그 상황에서 안전하게 동작하는지 검증하는 것입니다. 예를 들어 “밝은 햇빛+흰 물체” 시나리오에 대해 시뮬레이션이나 테스트 트랙에서 유사 상황을 재현하여 차량이 올바르게 정지하는지 확인합니다. 이 단계에서는 요구사항 충족 여부를 확인하는 테스트 케이스들이 주로 실행되며, Hardware-in-the-loop(HIL) 시뮬레이션이나 프로토타입 차량 시험 등이 활용됩니다. 검증 결과 미흡한 부분이 발견되면 설계로 피드백하여 수정하고 다시 검증하는 과정 반복이 이루어집니다.
확인 단계: 미지의 시나리오 평가 (Validation) – SOTIF 프로세스에서 중요한 특징은 아직 식별되지 않은 Unknown 해저드에 대한 탐색입니다. 설계 시 예상하지 못한 위험이 남아있을 수 있으므로, 다양한 시나리오를 폭넓게 시험하여 잔여 위험(residual risk)이 허용 가능한 수준인지 확인해야 합니다. 이를 위해 수많은 시나리오를 발생시키는 시나리오 기반 테스트와 시뮬레이션이 동원됩니다. 실제 도로 주행 테스트(시제품 차량을 일반 도로에서 운행하며 데이터 수집), 가상 시뮬레이션, 폐쇄된 시험장 테스트 등을 조합하여 가능한 한 다양한 상황을 실험합니다. 이 단계에서는 특정 요구사항보다는 시스템의 한계 탐색에 초점을 맞춰 테스트를 설계합니다. 테스트 결과 만약 새로운 위험 시나리오가 발견되면 이를 다시 분석하여 원인(trigger)을 규명하고 필요한 경우 설계 개선 및 추가 검증을 수행합니다. 최종적으로 알려진 해저드는 충분히 대비되었고, 추가로 발견된 위험이 미미하여 잔여 위험이 사회적으로 용인 가능한 수준임을 입증하면 SOTIF 달성이 선언됩니다.

출처: Development of ISO 26262 and ISO 21448 Concept Design Process Integration: ISO 26262 and ISO/PAS 21448 Design Process Integration

위 그림은 이러한 SOTIF 프로세스가 ISO 26262 기반 V-모델 개발 프로세스에 통합된 예시입니다. 좌측 V에서는 개념 단계의 항목 정의(Item Definition)와 위험 분석(HARA)를 수행하고, 기능 및 시스템 사양 수립과 함께 SOTIF 해저드 식별 및 위험 평가를 진행합니다 (그림 중 5~7번 활동). 이후 설계 단계에서 SOTIF 위험 감소를 위한 기능 수정을 반영하고(8번), 우측 V에서는 검증 전략 수립(Verification & Validation Strategy 정의) 후 알려진 시나리오 검증(10번)과 알려지지 않은 시나리오 평가(11번)를 통해 최종적으로 SOTIF를 입증하게 됩니다. 이처럼 SOTIF 활동은 개발 라이프사이클 전반에 걸쳐 반복적이고 단계적으로 이루어지며, ISO 26262 기능 안전 활동과 병행하여 진행됩니다.

9. 시나리오 기반 테스트와 시뮬레이션 접근법

SOTIF의 핵심 과제 중 하나는 도로상의 무한에 가까운 다양성의 시나리오에 대해 시스템의 안전성을 확인하는 것입니다. 현실적으로 모든 시나리오를 도로 시험으로 경험해볼 수 없기 때문에, 가상 시나리오 기반 테스트와 시뮬레이션이 필수적인 도구로 부상했습니다. ISO 21448 표준 역시 폭넓은 가상 테스트의 활용을 강조하고 있으며, 최근에는 시나리오 기반 검증을 지원하는 다양한 표준과 툴이 발전하고 있습니다 (예: ISO 34502/34503 자율주행 시나리오 기반 평가 프레임워크 표준 등).

시나리오 기반 테스트 접근법에서는 우선 시스템의 운용 범위(ODD)를 고려하여 시나리오 카탈로그를 작성합니다. 도로 유형, 교통밀도, 기상 상황, 조도, 주변 행위자(다른 차량, 보행자 등) 행동 등 변수들을 조합하여 시나리오를 생성합니다. 이때 과거 사고 데이터베이스, 규제 기관 테스트 시나리오(예: Euro NCAP 평가 시나리오) 등을 참고하여 위험도가 높은 시나리오들을 우선 선정합니다. 선정된 시나리오들은 매개변수(Parameter) 가 조금씩 달라지도록 변형시켜 여러 유사 상황을 커버하도록 합니다 (예: 보행자 횡단 시나리오에서 보행자 속도, 차속, 조명 등을 바꿔가며 다수 실험).

시나리오 세트가 준비되면, 이를 검증하기 위한 시뮬레이션 환경을 구축합니다. 시뮬레이터는 차량 동역학, 센서 모델, 주변 객체의 물리 등을 현실감 있게 모사해야 하며, 도로 시나리오를 재현 가능하고 반복 가능하게 실행할 수 있어야 합니다. 현대 자율주행 개발에서는 물리 기반 시뮬레이터뿐 아니라 실제 주행 로그 데이터를 재생하는 방식, 그리고 AI를 활용해 가상 장면을 합성하는 기법 등 다양한 시뮬레이션 기술이 활용됩니다.

특히 대규모 시뮬레이션의 중요성이 큰데, SOTIF 해석에서는 수백만 가지 시나리오를 신속히 생성·테스트할 수 있는 시뮬레이션 플랫폼이 필요하다고까지 언급됩니다. 그만큼 다양한 코너 케이스를 찾아내려면 자동화된 시나리오 생성 및 병렬 시뮬레이션 실행이 필수적입니다. 예를 들어, 클라우드 컴퓨팅을 활용하여 수만 대의 가상 차량을 동시에 주행시켜 보는 식으로 테스트 범위를 넓힐 수 있습니다. 최근에는 이러한 시나리오 폭발 문제를 해결하기 위해 몬테카를로 방법, 강화학습을 통한 위험 시나리오 탐색 등 지능적인 테스트 자동화 기법도 연구되고 있습니다.

시뮬레이션 시험에서 발견된 문제는 설계로 피드백되고, 설계 개선 후에는 다시 해당 시나리오를 테스트하여 문제가 해결됐는지 확인합니다. 또한 시뮬레이션의 유효성도 중요 이슈인데, 가상환경 결과가 현실에서도 유효함을 보여주기 위해 실차 테스트와의 상관성을 수시로 교차 검증합니다. 예컨대, 중요한 시나리오는 실제 테스트 트랙이나 도로주행으로 재현해 보고 시뮬레이터 결과와 비교함으로써 신뢰성을 확보합니다.

시나리오 기반 접근을 지원하기 위해 업계 표준들도 속속 등장하고 있습니다. 앞서 언급한 ISO 34502 시리즈는 시나리오 정의 및 분류, ODD 명세화, 시나리오 기반 검증 절차 등을 정립하여 업계 공통의 체계를 만드는 노력입니다. 또한 ASAM OpenODD, OpenScenario 같은 데이터 포맷 표준도 개발되어 서로 다른 시뮬레이션 툴 간 시나리오 정보 교환을 가능케 합니다. 이러한 표준화는 궁극적으로 안전 인증 단계에서 시나리오 테스트 결과를 당국에 제출하고 신뢰를 얻는 데에도 도움이 될 것으로 기대됩니다.

정리하면, 시나리오 기반 테스트와 시뮬레이션은 SOTIF 목표를 달성하기 위한 필수 수단이며, 효과적인 적용을 위해 방대한 시나리오 풀 구성, 고신뢰도 시뮬레이터 확보, 테스트 커버리지 관리, 시나리오 표준화 등이 중요합니다. SOTIF 표준은 “무엇을 해야 한다”까지는 지침을 제공하지만, 어떻게 구현할지는 구체적으로 규정하지 않기 때문에각 기업과 연구기관들이 이 분야의 베스트프랙티스를 계속 개발해나가고 있는 상황입니다.

10. 향후 도전 과제 및 발전 방향

자율주행 기술과 환경은 빠르게 변화하고 있으며, SOTIF 분야에도 앞으로 극복해야 할 여러 도전 과제가 존재합니다.

첫째, AI 및 머신러닝 시스템의 안전성 확보입니다. 자율주행차는 딥러닝 기반 비전 인식, 강화학습 기반 주행 제어 등 학습된 모델에 크게 의존하게 되었는데, 이러한 모델들은 동작이 블랙박스(black-box)이고 훈련 데이터 밖의 상황에서는 예측 불가능한 거동을 보일 수 있습니다. ISO 21448에서도 학습된 기능의 불확실성을 다루지만 체계적인 방법론이 추가로 필요하며, ISO/PAS 8800이 그 시작이라 할 수 있습니다. 향후에는 AI 시스템의 안전을 정량적으로 평가하고 신뢰성을 향상시키는 기법들(예: 신뢰도 측정, 온라인 모니터링 등)이 SOTIF 프레임워크에 통합될 것으로 전망됩니다.

둘째, 시나리오 커버리지 증명의 어려움입니다. 이론적으로 완전한 안전을 증명하려면 모든 가능 시나리오에서 시스템이 안전함을 보여야 하지만, 이는 불가능에 가깝습니다. 따라서 현실적인 대안은 위험도를 정량화하고 잔여 위험이 충분히 낮음을 입증하는 것입니다. 하지만 잔여 위험 평가나 통계적 증거 제시는 여전히 난제입니다. 예를 들어 “이 정도 테스트를 했으니 충분히 안전하다”를 얼마나 확신시킬 수 있는지, 안전 입증(Assurance)을 위한 공통된 방법론이 더 발전해야 합니다. 시뮬레이션으로 발견하지 못한 극단적 코너 케이스가 숨어있을 가능성을 완전히 배제할 수 없기에, 업계와 학계에서는 형식적 방법(Formal Methods)이나 사고율 기반 확률적 평가 등의 접근을 연구하고 있습니다.

셋째, 표준과 규정의 정교화입니다. SOTIF는 이제 막 본격 표준으로 자리잡았고, 여러 관련 표준(ISO 26262, 21434 등)과의 정합성 이슈가 있습니다. 예컨대 기능 안전상의 ASIL과 SOTIF상의 위험 평가를 하나의 체계로 종합하는 방법, SOTIF 분석 결과를 인증 기관에 제출할 때의 형식 등이 향후 논의될 수 있습니다. UNECE 등 국제 규제에서도 고도 자율주행 승인을 위해 SOTIF 개념을 고려하기 시작했으며, 국제 조율을 통한 안전 기준의 발전이 예상됩니다. 또한 현재 PAS로 발행된 ISO 8800의 정식 표준화, SOTIF와 사이버보안의 통합 가이드(ISO TS 5083 예정) 등도 진행 중이어서, 안전 프레임워크의 확장이 이루어질 것입니다.

넷째, 운영 단계에서의 SOTIF 관리입니다. 차량이 양산되어 도로에 나온 후에도 소프트웨어 업데이트(OTA)나 AI 모델 업그레이드로 기능이 변경될 수 있는데, 이때 새로운 SOTIF 위험이 발생할 수 있습니다. 따라서 개발단계뿐 아니라 운영 단계의 SOTIF 개념, 예컨대 실주행 데이터로부터 미처 알지 못했던 위험 시나리오를 모니터링하고 피드백하는 피드포워드/피드백 루프가 중요해질 것입니다. 이를 위해 클라우드에서 차량 데이터를 수집·분석하여 위험도를 재평가하는 SAF(Software Aktualisierungspflicht) 개념이나, 제조사가 지속적으로 안전성을 모니터링하는 체계가 논의되고 있습니다.

다섯째, 완전 자율주행(Level 4/5)으로 갈수록 SOTIF의 중요성이 극대화된다는 점입니다. 사람의 개입이 더 이상 없을 때 차량 스스로 모든 상황을 안전하게 처리해야 하므로, SOTIF에서 다루는 unknown unsafe를 얼마나 효율적으로 줄이느냐가 상용화의 열쇠입니다. 이를 지원하기 위해 UL 4600 같은 자율주행 안전 평가 표준이 등장했고, 다양한 안전 케이스 (Safety Case) 프레임워크가 제안되고 있습니다. 이들 역시 SOTIF와 철학을 같이하며, 미래에는 SOTIF 표준이 이러한 새로운 안전 접근들과도 양방향으로 영향을 주고받으며 발전할 것입니다.

11. 결론

ISO 21448:2022 SOTIF는 자율주행 시대의 필연적 산물로, “의도된 대로 동작하지만 안전하지 않을 수 있는” 시스템의 한계를 체계적으로 관리하기 위한 표준입니다. SOTIF 개념과 프로세스를 통해 개발자는 기능 구현 단계부터 잠재 위험 시나리오를 발굴하고, 설계 개선과 검증을 반복하여 잔여 위험을 최소화할 수 있습니다. 이는 기존 기능 안전(ISO 26262) 체계의 빈틈을 메워주며, 사이버보안(ISO 21434), AI 안전(ISO/PAS 8800) 등의 분야와도 맥락을 같이합니다.