정보관리기술사 학습 노트
← 목록으로
컴퓨팅·임베디드
#SOTIF#ISO 21448#자율주행#기능안전#ODD
최종 업데이트 · 2026-10-24

SOTIF(ISO 21448, 의도된 기능의 안전)

1. 개요

가. 정의

SOTIF(Safety Of The Intended Functionality, 의도된 기능의 안전) 는 시스템에 어떤 고장(malfunction)도 없는데도, 의도한 기능 자체의 성능 한계·오인식·사양 부족 때문에 생기는 불합리한 위험(unreasonable risk)으로부터의 자유를 다루는 자동차 안전 개념이며, 이를 체계화한 국제표준이 ISO 21448:2022이다. "부품이 고장나지 않았어도, 기능이 설계된 한계 안에서 정상 동작했음에도 위험할 수 있다"는 문제의식 위에 서 있다.

SOTIF가 등장한 배경은 자동차 안전의 무게중심이 '고장 대비'에서 '인지·판단의 성능 한계 대비'로 이동했다는 데 있다. 전통적 기능안전 표준인 [[iso-26262]]는 센서 단선, 비트 플립, 소프트웨어 결함처럼 '원인을 특정할 수 있는 고장'이 위험으로 번지는 것을 막는다. 그러나 카메라·레이더·라이다와 딥러닝 인지 알고리즘에 의존하는 ADAS(첨단운전자보조)·자율주행에서는, 어떤 부품도 고장나지 않았는데 역광에서 보행자를 놓치거나, 도로 위 비닐봉지를 장애물로 오인해 급제동하는 식의 사고가 발생한다. 이는 '고장'이 아니라 '설계된 기능이 감당하지 못하는 상황(성능 부족)'이므로 ISO 26262의 틀로는 설명·통제되지 않는다. 이 공백을 메우기 위해 2019년 ISO/PAS 21448(기술시방서)로 출발해 2022년 6월 정식 국제표준(ISO 21448:2022)으로 발행되었다.

SOTIF를 이해하는 출발점은 '고장이 없어도 안전하지 않을 수 있다'는 역설이다. ISO 26262가 "시스템이 올바르게 동작하지 못할 때(malfunction)"를 다룬다면, SOTIF는 "시스템이 사양대로 올바르게 동작했음에도 결과가 위험할 때"를 다룬다. 예컨대 긴급제동(AEB) 시스템이 전방 정지차량을 인식하지 못한 것은 레이더가 '설계된 반사특성 범위' 안에서 금속 구조물과 정지차량을 구분하지 못한 성능 한계이지 고장이 아니다. 따라서 SOTIF의 핵심 질문은 "고장을 어떻게 검출·대응할 것인가"가 아니라 "의도한 기능의 한계를 어디까지 알아내고, 그 한계가 위험이 되지 않도록 어떻게 입증할 것인가"이다.

ISO 21448은 ADAS와 운전자동화 레벨 1~5(SAE J3016)에 걸쳐, 특히 복잡한 센서와 처리 알고리즘으로 상황을 인지하는 기능과 합리적으로 예견 가능한 오사용(reasonably foreseeable misuse) 까지 적용 범위로 삼는다. 즉 운전자가 운전보조기능을 과신해 손을 놓는 등의 오사용도 '시스템이 감당해야 할 조건'으로 보고 안전논증에 포함한다는 점이 특징이다.

표준의 발전 경로 자체가 이 문제의식의 성숙을 보여 준다. 초기에는 2019년 ISO/PAS 21448이라는 '공개시방서(Publicly Available Specification)' 형태로, 즉 아직 완전한 합의에 이르지 못한 잠정 지침으로 출발했다. 자율주행 사고 사례가 축적되고 업계의 경험이 쌓이면서 2022년 정식 국제표준으로 승격되었고, 이때 적용 범위가 레벨 12 운전보조에서 레벨 35 자율주행까지 명시적으로 확장되었다. '고장 없는 위험'이라는 개념이 변방의 문제의식에서 자동차 안전의 중심 의제로 올라선 과정을 압축적으로 드러내는 셈이다.

나. SOTIF가 다루는 위험의 두 원천

SOTIF가 겨냥하는 위험은 크게 두 가지 사양적 결핍에서 비롯된다. 첫째는 기능 사양 부족(functional insufficiency) 으로, 의도한 기능을 차량 수준에서 정의할 때 특정 상황을 미처 고려하지 못해 생기는 틈이다. 둘째는 성능 한계(performance limitation) 로, 센서·인지·판단 알고리즘이 물리적·통계적으로 가질 수밖에 없는 한계(센서 해상도, 악천후 감쇠, 학습 데이터 편향)다. 이 둘이 특정 트리거 조건(triggering condition) — 역광, 안개, 공사구간, 이례적 도로표지 같은 환경·시나리오 요소 — 과 만나면 위해 거동(hazardous behavior) 으로 현실화된다.

여기서 반드시 구분해야 할 개념이 '트리거 조건'과 '기능 부족'의 관계다. 기능 부족은 시스템이 내재적으로 가진 약점이고, 트리거 조건은 그 약점을 밖에서 자극해 발현시키는 상황이다. 예컨대 '야간 저조도에서 검은 옷 보행자 인식률 저하'라는 기능 부족이 있어도, 그런 보행자가 나타나는 트리거 조건이 없으면 사고는 일어나지 않는다. 따라서 SOTIF 활동의 본질은 ① 기능 부족을 찾아내 줄이고, ② 그것을 발현시키는 트리거 조건을 체계적으로 발굴하며, ③ 둘이 만나도 위해로 번지지 않도록 설계·검증하는 것으로 요약된다. 답안에서는 '성능 한계 × 트리거 조건 = 위해 시나리오'라는 인과 구조를 명확히 서술하는 것이 핵심이다.

다. 합리적으로 예견 가능한 오사용

SOTIF가 ISO 26262와 뚜렷이 구별되는 또 하나의 지점은 사람의 오사용까지 시스템이 감당할 조건으로 포함한다는 데 있다. 운전보조기능을 '자율주행'으로 오해해 운전대에서 손을 놓거나, 경고를 무시하고 재인계를 지연하거나, 설계되지 않은 도로에서 기능을 켜는 행위는 모두 '합리적으로 예견 가능한 오사용(reasonably foreseeable misuse)'에 해당한다. SOTIF는 이러한 인간 요인을 '사용자의 잘못'으로 치부하지 않고, 시스템이 예견하고 완화해야 할 설계 입력으로 본다. 이는 자율주행에서 사고의 상당수가 기술 한계와 인간의 과신·오인이 맞물린 '인간-기계 상호작용(HMI)' 문제에서 비롯된다는 통찰을 반영한다.

이 관점이 실무에 주는 함의는 크다. 단순히 인지 성능을 높이는 것만으로는 안전을 입증할 수 없고, 운전자의 주의 상태 감시(DMS, Driver Monitoring System), 명확한 작동 한계 고지, 단계적 재인계 경고, 모드 혼동(mode confusion) 방지 설계가 SOTIF 안전논증의 필수 요소가 된다. 예컨대 '시스템이 켜져 있다고 착각한 운전자가 개입하지 않는 상황'을 트리거 조건으로 명시하고, 그런 상황에서도 안전한 최소위험상태로 전이하도록 설계해야 한다. 따라서 SOTIF는 센서·알고리즘의 공학 문제이면서 동시에 인간공학·행동과학의 문제이기도 하다.

2. SOTIF 시나리오 4영역과 핵심 개념

SOTIF의 가장 널리 알려진 개념 틀은 시나리오를 '알려짐/알려지지 않음(known/unknown)' × '안전/위험(safe/unsafe)' 의 두 축으로 나눈 네 개 영역(Area 1~4) 이다. 아래 구조도는 이 2×2 틀과, SOTIF 활동이 각 영역을 어떻게 이동시키려 하는지를 보여 준다.

graph TD
  subgraph KNOWN["알려진 시나리오"]
    A1["Area 1: 알려진 안전<br/>정상 동작 영역"]
    A2["Area 2: 알려진 위험<br/>식별된 위해 시나리오"]
  end
  subgraph UNKNOWN["알려지지 않은 시나리오"]
    A4["Area 4: 알려지지 않은 안전"]
    A3["Area 3: 알려지지 않은 위험<br/>미발굴 위해 시나리오"]
  end
  A3 -->|"시나리오 발굴·주행누적"| A2
  A2 -->|"설계개선·기능수정"| A1
  A4 -.->|"분석으로 확인"| A1
  GOAL["목표: Area 2·3 최소화"]
  A2 --> GOAL
  A3 --> GOAL

이 네 영역의 의미를 풀면 다음과 같다. Area 1(알려진 안전) 은 시스템이 의도대로 안전하게 동작함이 확인된 영역으로, 개발이 지향하는 최종 상태다. Area 2(알려진 위험) 는 분석·시험으로 이미 식별한 위해 시나리오로, 설계 개선·기능 제한·운전자 경고 같은 조치로 Area 1로 옮겨야 한다. Area 3(알려지지 않은 위험) 은 아직 발견하지 못한 위해 시나리오로, SOTIF가 가장 경계하는 영역이다 — 존재조차 모르므로 직접 제거할 수 없고, 시나리오 발굴·대규모 주행 데이터 누적을 통해 '알려진' 영역(Area 2)으로 끌어낸 뒤에야 제거할 수 있다. Area 4(알려지지 않은 안전) 는 아직 모르지만 실제로는 안전한 시나리오다. 따라서 SOTIF의 전략 목표는 명확하다 — Area 2와 Area 3의 크기를 수용 가능한 수준까지 줄이는 것이다.

이 틀이 중요한 이유는 자율주행 안전의 본질적 난제를 드러내기 때문이다. Area 3는 '모른다는 것조차 모르는(unknown unknowns)' 영역이어서 완전히 비울 수 없다. 세상의 모든 주행 상황을 사전에 열거하는 것은 불가능하기 때문이다. 그래서 SOTIF는 "얼마나 검증했을 때 충분히 안전하다고 선언할 것인가"라는 검증 목표(validation target)를 설정하고, 통계적 논증으로 잔여 위험이 수용 가능함을 보이는 방식에 의존한다. 바로 이 점이 고장 경로를 결정론적으로 추적하는 ISO 26262와 근본적으로 다르다.

영역 알려짐 여부 안전/위험 핵심 활동
Area 1 알려짐 안전 정상 동작 — 유지·확대
Area 2 알려짐 위험 설계 개선으로 Area 1화
Area 3 모름 위험 시나리오 발굴로 Area 2화
Area 4 모름 안전 분석으로 Area 1 확인

표는 네 영역을 정리한 것이지만, 실제 개발에서 핵심 노력은 경계면에 집중된다. 즉 Area 2↔Area 3의 경계(아직 모르는 위험을 어떻게 드러낼 것인가)와 Area 1↔Area 2의 경계(식별된 위험을 어떤 조치로 안전화할 것인가)가 SOTIF 엔지니어링의 두 전선이다. 실무에서는 체계적 위험분석(HAZOP·기능분석)으로 Area 2를 넓히고, 시뮬레이션·필드 운영·엣지케이스 마이닝으로 Area 3를 Area 2로 끌어온다.

이 4영역 모델을 ODD와 겹쳐 보면 이해가 한층 깊어진다. ODD를 좁게 설정하면 시스템이 마주칠 시나리오 공간이 작아져 Area 3(미지의 위험)도 작아지지만, 그만큼 기능이 제공되는 범위가 제한된다. 반대로 ODD를 넓히면 효용은 커지나 미지의 트리거 조건이 급증해 Area 3가 팽창한다. 즉 ODD는 4영역의 전체 크기를 규정하는 '무대의 경계' 이며, SOTIF 활동은 그 무대 안에서 위험 영역을 조명해 줄여 나가는 작업이다. 이 때문에 "ODD를 어디까지 넓히고, 그 경계를 어떻게 감지·강제할 것인가"가 SOTIF 전략의 첫 단추가 된다.

또한 네 영역 사이의 이동은 일방향이 아니라 반복적이라는 점에 유의해야 한다. 설계를 바꿔 Area 2를 Area 1로 옮기면, 그 변경이 예상치 못한 새로운 위해를 만들어 또 다른 Area 3를 낳을 수 있다. 예컨대 false positive 제동을 줄이려 인지 민감도를 낮추면, 이번에는 실제 장애물을 놓치는 false negative 위험(새로운 Area 3)이 커진다. 이처럼 SOTIF의 위험은 '상충(trade-off) 구조'를 띠므로, 한 영역을 줄이는 조치가 다른 영역을 키우지 않는지 교차 검증하는 반복 루프가 필수다.

3. SOTIF 활동 프로세스와 검증·타당성확인

ISO 21448은 SOTIF 달성을 위한 활동을 생애주기에 걸친 반복(iterative) 프로세스로 제시한다. 아래 상세도는 기능 정의에서 출발해 위험 평가, 설계 조치, 검증·타당성확인, 운용 단계 피드백으로 순환하는 흐름을 나타낸다.

flowchart LR
  F["의도기능 정의<br/>(기능·ODD 명세)"] --> H["위해 식별·평가<br/>(HARA, 위해거동 분석)"]
  H --> T["트리거조건 분석<br/>(기능부족·성능한계 도출)"]
  T --> D["설계개선·기능수정<br/>(Area 2 저감)"]
  D --> V["검증(Verification)<br/>알려진 위험 제거 확인"]
  V --> VAL["타당성확인(Validation)<br/>미지 위험 통계적 논증"]
  VAL --> ACC{"수용 가능?"}
  ACC -->|"아니오"| T
  ACC -->|"예"| REL["출시·배포"]
  REL --> OP["운용단계 모니터링<br/>(필드데이터·OTA 개선)"]
  OP -.->|"신규 트리거 발견"| T

이 프로세스가 ISO 26262의 V모델과 닮은 듯 다른 점을 짚을 필요가 있다. 두 표준 모두 '요구→설계→검증'의 생애주기 골격과 추적성을 공유하지만, ISO 26262의 V모델이 각 단계 산출물의 정합성을 결정론적으로 검증하는 '닫힌 루프'라면, SOTIF 프로세스는 미지의 위험을 계속 발굴해 되먹이는 '열린 반복 루프'에 가깝다. 즉 SOTIF는 "개발이 끝나는 시점"이 명확하지 않고, 수용기준을 만족할 때까지 그리고 운용 중에도 계속 돌아간다. 이 구조적 차이가 두 표준의 검증 철학을 가른다.

프로세스의 각 단계를 산문으로 설명하면 이렇다. 먼저 의도기능 정의 단계에서 기능의 목적과 함께 ODD(Operational Design Domain, 운용설계영역) — 도로종류·속도·기상·조도 등 시스템이 안전하게 동작하도록 설계된 조건 범위 — 를 명세한다. ODD는 SOTIF의 출발점이자 경계로, "이 범위 안에서는 안전을 보장하고 범위를 벗어나면 안전하게 기능을 제한·이양한다"는 약속이다. ODD를 좁히면 안전 입증은 쉬워지지만 기능 효용이 줄고, 넓히면 효용은 커지나 검증 부담이 폭증하는 트레이드오프가 여기서 결정된다.

다음으로 위해 식별·평가에서는 기능이 의도대로 동작했을 때도 벌어질 수 있는 위해 거동을 도출하고, 트리거 조건 분석에서는 그 위해를 유발하는 환경·상황 요소와 그 배후의 기능 부족·성능 한계를 체계적으로 찾아낸다. 이어 설계 개선에서 센서 다중화(카메라+레이더+라이다 융합), 인지 알고리즘 보강, 기능 제한(저속에서만 작동), 운전자 재인계(takeover) 요청 같은 조치로 식별된 위험(Area 2)을 줄인다.

SOTIF 활동의 하이라이트는 검증(Verification)과 타당성확인(Validation) 의 구분이다. 검증은 "식별된 알려진 위험(Area 2)이 조치로 실제 제거되었는가"를 확인하는 활동으로, 목표 시나리오에 대한 시험·시뮬레이션으로 수행한다. 반면 타당성확인은 "아직 식별하지 못한 위험(Area 3)을 포함해, 잔여 위험이 수용 가능한 수준인가"를 통계·시나리오 커버리지로 논증하는 활동이다. 전자가 결정론적 점검이라면 후자는 확률적 설득이며, 자율주행이 수억 km의 실주행·시뮬레이션 데이터를 요구하는 이유가 바로 이 타당성확인의 부담에 있다. 예컨대 치명적 사고가 인간 운전자보다 드물다는 것을 통계적으로 보이려면, 사고 간 평균 주행거리가 매우 길기 때문에 천문학적 주행거리가 필요하다는 'approval trap(검증의 함정)'이 알려져 있고, 이를 완화하기 위해 시나리오 기반 검증·시뮬레이션·가속시험이 결합된다.

SOTIF 논증에서 간과하기 쉬운 단계가 수용기준(acceptance criteria) 설정이다. 미지 위험을 완전히 없앨 수 없으므로, "잔여 위험이 어느 수준이면 사회적으로 받아들일 만한가"를 사전에 정의해야 비로소 '충분히 검증했다'는 선언이 가능하다. 실무에서는 GAMAB(Globally At Least As Good, 기존 수단만큼은 안전), MEM(Minimum Endogenous Mortality, 자연 사망률 대비 추가 위험 제한), ALARP(As Low As Reasonably Practicable, 합리적으로 실행 가능한 한 낮게) 같은 위험수용 원리를 참조해 정량 목표를 세운다. 예컨대 '동급 인간 운전자의 사고율 이하'를 목표로 삼으면, 이를 통계적으로 입증하기 위한 주행거리·시나리오 커버리지가 역산된다. 이 수용기준이 모호하면 검증은 끝없이 늘어나거나 자의적으로 종료되므로, 기준의 투명성과 사회적 합의가 SOTIF의 신뢰성을 좌우한다.

또 하나 핵심 설계 요소가 최소위험상태(MRM/MRC, Minimal Risk Maneuver/Condition) 다. 시스템이 ODD 경계를 벗어나거나 자신의 성능 한계를 감지하면, 위험을 키우지 않는 상태 — 예컨대 안전하게 감속해 갓길 정차하거나 운전자에게 제어를 이양하는 동작 — 로 전이해야 한다. 여기서 중요한 것은 '한계를 스스로 아는 능력'이다. 인지 불확실성이 높아지는 상황(악천후·OOD 입력)을 런타임에 탐지해 기능을 우아하게 저하(graceful degradation) 시키는 설계가 없으면, 시스템은 자신이 틀렸다는 사실조차 모른 채 위험한 결정을 내린다. 따라서 불확실성 정량화와 ODD 모니터링은 SOTIF 아키텍처의 심장부에 놓인다.

마지막으로 운용단계 모니터링은 SOTIF를 1회성 인증이 아니라 지속적 안전보증으로 만드는 축이다. 출시 후에도 필드 데이터에서 새로운 트리거 조건이 발견되면 이를 Area 3→Area 2로 반영하고, OTA(무선 업데이트)로 인지 모델·제어 로직을 개선해 안전 수준을 유지·향상한다. 이 피드백 루프가 자율주행 안전의 핵심 운영 모델이다.

4. 비교 — ISO 26262와의 관계 및 적용 사례

SOTIF를 정확히 쓰려면 ISO 26262와의 분담 구도를 명확히 해야 한다. 두 표준은 경쟁이 아니라 상호 보완 관계다. ISO 26262가 다루는 것은 'E/E 고장(fault)'이 만드는 위험, 즉 '고장 공간(fault space)'이고, SOTIF가 다루는 것은 고장이 없어도 성능이 부족해 생기는 위험, 즉 '부족 공간(insufficiency space)'이다. 차이가 생기는 근본 이유는 위험의 원천과 증명 방식에 있다. 고장은 원인을 특정할 수 있고 확률로 정량화되므로 FTA·FMEA로 추적하고 하드웨어 지표로 잔여 위험을 수치화한다. 반면 성능 부족은 '언제 어떤 상황에서 오인식할지'를 완전히 열거할 수 없어 시나리오 커버리지와 통계적 논증에 의존한다. 흥미롭게도 ISO 21448은 애초 ISO 26262의 한 부(part)로 논의되었으나, '고장 없는 위험'이라는 성격이 근본적으로 달라 별도 표준으로 분리되었다.

구분 ISO 26262 ISO 21448(SOTIF)
대상 위험 E/E 고장(malfunction) 성능 한계·오인식(고장 없음)
공간 고장 공간(fault) 부족 공간(insufficiency)
등급 체계 ASIL A~D(+QM) 등급 없음(시나리오 논증)
핵심 기법 HARA·FTA·FMEA·HW지표 시나리오 발굴·V&V·통계논증
증명 철학 결정론적 증거 확률·시나리오적 논증

이 비교에서 실무적으로 중요한 함의는, 자율주행 시스템 하나를 안전하게 만들려면 두 표준을 동시에 적용해야 한다는 점이다. 예컨대 자동긴급제동(AEB)을 보자. 레이더 ECU가 비트 플립으로 오작동해 제동 명령을 누락하는 것은 ISO 26262의 영역이고, 레이더가 고장 없이도 금속 맨홀 뚜껑을 정지차량으로 오인해 불필요한 급제동(false positive)을 거는 것은 SOTIF의 영역이다. 실제 2016~2018년 일부 자율주행·운전보조 사고들은 부품 고장이 아니라 인지 알고리즘의 한계(정지 트레일러·공사 구조물 오인 등)에서 비롯된 것으로 분석되며, 이것이 SOTIF가 정식 표준으로 승격된 직접적 동인이 되었다.

같은 ECU 안에서 두 표준이 어떻게 공존하는지를 보면 분담 구도가 더 분명해진다. 자율주행 제어기는 ISO 26262 관점에서 락스텝 코어·ECC·워치독으로 '고장 없는 연산'을 보장하는 동시에, SOTIF 관점에서 인지 결과의 불확실성을 정량화해 신뢰할 수 없을 때 안전하게 기능을 저하시킨다. 전자는 "계산이 틀리지 않았는가"를, 후자는 "계산은 맞았지만 그 결과를 믿어도 되는가"를 묻는다. 따라서 하나의 안전 아키텍처 안에 결정론적 고장 안전 메커니즘과 확률적 성능 안전 메커니즘이 층을 이뤄 공존하며, 둘 중 어느 하나라도 빠지면 자율주행 안전논증은 성립하지 않는다. 답안에서 "26262=고장 대비, SOTIF=성능 한계 대비, 둘은 상호 보완"이라는 분담을 구체 사례로 풀어내면 비교의 깊이가 산다.

또 다른 적용 사례로 차선유지보조(LKAS)를 들 수 있다. 노면 표시가 지워졌거나 공사구간에서 임시 차선과 기존 차선이 겹치는 트리거 조건에서, LKAS가 잘못된 차선을 따라 조향하는 것은 전형적 SOTIF 위험이다. 이를 ODD 명세(차선 표시 품질이 일정 기준 이상인 도로로 작동 제한)와 운전자 재인계 요청, 다중 센서 융합으로 완화한다. 이처럼 SOTIF는 기능의 효용과 안전 사이에서 ODD를 어떻게 긋고, 한계 상황을 어떻게 감지해 안전하게 이양할지를 설계하는 활동이다.

센서 융합이 SOTIF에서 차지하는 비중도 이 사례들이 공통으로 드러낸다. 카메라는 색·형상 인식에 강하나 저조도·역광에 약하고, 레이더는 거리·속도에 강하나 정지물·형상 구분에 약하며, 라이다는 3차원 형상에 강하나 악천후·비용에 약하다. 서로의 성능 한계가 겹치지 않도록 이종 센서를 융합(redundancy·diversity) 하면, 한 센서가 특정 트리거 조건에서 실패해도 다른 센서가 보완해 Area 3를 구조적으로 줄일 수 있다. 다만 융합 자체가 새로운 기능 부족(센서 간 시공간 정합 오류, 상충 판정)을 낳을 수 있어, 융합 로직도 SOTIF 분석의 대상이 된다는 점을 잊어서는 안 된다.

5. 심화 — AI 안전표준으로의 확장과 최신 동향

최근 SOTIF 지형의 가장 큰 변화는 AI·머신러닝 기반 인지의 안전 입증이라는 난제다. 딥러닝 인지 모델은 학습 데이터에 없는 분포(out-of-distribution) 입력에서 예측 불가하게 실패하고, 내부 결정 과정을 설명하기 어려운 블랙박스 특성을 가진다. 이는 SOTIF가 말하는 '기능 부족'의 전형이지만, 전통적 시나리오 분석만으로는 모델의 한계를 충분히 드러내기 어렵다. 이 공백을 메우기 위해 2024년 ISO/PAS 8800(Road vehicles — Safety and artificial intelligence)이 발행되어, 자동차 AI의 안전 생애주기·데이터셋 품질·모델 성능 보증을 SOTIF·ISO 26262와 연계하는 체계를 제시한다. 함께 UL 4600(자율주행차 안전사례 표준)은 완성 시스템의 안전논증(safety case)을 요구하며, 이들 표준이 다층으로 결합해 '고장 안전(26262) + 성능 안전(21448) + AI 안전(8800) + 전체 안전사례(UL 4600)'의 입체적 체계를 형성하고 있다.

이 흐름을 떠받치는 기반 기술로 불확실성 정량화(uncertainty quantification)와 런타임 모니터링이 주목받는다. 딥러닝 모델이 자신의 예측이 얼마나 믿을 만한지를 함께 출력하게 하고(예: 베이지안 신경망, 앙상블, OOD 탐지), 신뢰도가 낮으면 다른 센서로 교차검증하거나 기능을 저하시키는 설계가 그것이다. 모델이 '확신에 차서 틀리는(confidently wrong)' 순간을 포착하는 것이야말로 SOTIF가 AI 인지에 요구하는 핵심 능력이며, 설명가능 AI(XAI)와 안전 아키텍처가 만나는 접점이다.

두 번째 동향은 시나리오 기반 검증(scenario-based validation)과 시뮬레이션의 부상이다. 앞서 말한 '검증의 함정'(천문학적 실주행 거리) 때문에, 업계는 OpenSCENARIO·OpenDRIVE 같은 표준 포맷으로 주행 시나리오를 기술하고, 고충실도 시뮬레이션과 디지털 트윈에서 수백만 개의 변형 시나리오를 자동 생성·실행하는 방식으로 Area 3를 탐색한다. 특히 엣지케이스 마이닝(실주행·사고 데이터에서 희귀·위험 상황을 추출)과 적대적 시나리오 생성(의도적으로 인지를 교란하는 상황 합성)이 결합되어, 제한된 비용으로 미지 위험의 커버리지를 높이는 것이 핵심 연구 주제가 되었다.

세 번째는 데이터셋 품질이 안전 속성이 된다는 인식이다. 딥러닝 인지의 성능 한계는 결국 학습·검증 데이터의 분포에서 비롯되므로, ISO/PAS 8800은 데이터셋의 완전성·대표성·균형성·정확성을 안전 요구로 끌어올린다. 특정 인종·체형·악천후·지역 도로가 데이터에서 과소표집되면 그대로 Area 3의 미지 위험으로 남기 때문이다. 이에 따라 '어떤 ODD를 커버하려면 어떤 분포의 데이터가 얼마나 필요한가'를 역설계하는 데이터 요구공학과, 데이터의 출처·라벨 품질·편향을 추적하는 데이터 거버넌스가 SOTIF 실무의 새로운 축으로 부상했다. 이는 AI·데이터 분야의 데이터 품질·MLOps 역량이 안전공학과 직접 맞물리는 지점이다.

네 번째는 보안과의 융합이다. 커넥티드·자율주행 환경에서 적대적 공격(adversarial attack) — 예컨대 교통표지판에 스티커를 붙여 인지 모델을 오분류시키는 공격 — 은 '악의적으로 유발된 트리거 조건'으로, SOTIF(성능 한계)와 사이버보안 표준 ISO/SAE 21434의 경계에 놓인다. 따라서 안전과 보안을 하나의 위협모델로 통합해 분석하는 접근이 요구된다. 예상 출제 방향으로는 "ISO 26262·SOTIF·ISO/PAS 8800의 통합 안전 프로세스를 자율주행 인지 사례로 논하라"는 융합형 논제, 또는 "SOTIF의 Area 3(미지의 위험)를 줄이기 위한 시나리오 기반 검증·시뮬레이션 전략을 설계하라"는 아키텍처형 논제가 유력하다.

6. 고려사항 및 시사점

  • 적용 전략 — ODD 중심 설계와 단계적 축소: SOTIF 활동의 성패는 ODD를 얼마나 명확히 긋고, 그 경계를 실시간으로 감지해 안전하게 기능을 제한·이양하느냐에 달려 있다. 초기에는 ODD를 보수적으로 좁게 설정해 안전을 확실히 입증한 뒤, 필드 데이터·시뮬레이션으로 미지 위험(Area 3)을 줄여 가며 점진적으로 ODD를 확장하는 단계적 전개 전략이 현실적이다. ODD를 벗어나는 상황의 감지(ODD monitoring)와 안전한 최소위험상태(MRM, Minimal Risk Maneuver) 설계가 핵심 역량이다.

  • 트레이드오프 — 효용 vs 검증 부담 vs 비용: ODD를 넓히고 자동화 수준을 높일수록 기능 효용은 커지지만, 입증해야 할 시나리오 공간이 폭발적으로 늘어 검증 비용·기간이 비선형적으로 증가한다. 반대로 과도하게 보수적인 설계(잦은 false positive 제동, 빈번한 재인계 요청)는 안전하되 상품성을 해친다. 기술사 관점에서는 '안전은 타협 불가'라는 전제 아래, ODD·센서 구성·검증 목표 사이의 위험 비례적 최적점을 찾는 균형 감각이 요구된다.

  • 전망 — 데이터 기반 연속 안전보증으로의 전환: SOTIF는 출고 시점의 1회성 인증이 아니라, 운용 중 필드 데이터·OTA·시뮬레이션을 통한 지속적 안전보증(continuous safety assurance) 으로 패러다임을 이동시킨다. 새로운 트리거 조건이 발견될 때마다 안전사례를 갱신하는 '살아 있는 안전논증(living safety case)'이 표준 실무의 중심이 될 것이며, 이는 디지털 트윈·시나리오 DB·엣지케이스 마이닝 역량과 직결된다.

  • 연계 기술 — 기능안전·AI안전·보안의 통합: SOTIF는 독립 활동이 아니라 [[iso-26262]](고장 안전), ISO/PAS 8800(AI 안전), ISO/SAE 21434(사이버보안), [[software-safety-analysis]]의 FMEA·FTA, [[rtos]]의 실시간성과 유기적으로 결합되어야 한다. 특히 딥러닝 인지의 불투명성·데이터 의존성은 전통적 안전분석 기법만으로 다룰 수 없으므로, 설명가능 AI·불확실성 정량화·런타임 모니터링 같은 신기술을 안전 아키텍처에 통합하는 설계 역량이 필수가 된다.

  • 국내·제도 관점 — 규제·인증과의 정합: 국내(한국)에서도 자율주행 임시운행 허가와 레벨 3 안전기준이 마련되면서, SOTIF는 완성차·부품 업계의 형식승인·안전평가 실무에 직접 영향을 미친다. UNECE WP.29의 자율주행 관련 규정과 ISO 21448·ISO/PAS 8800이 인증 근거로 자리 잡는 흐름에서, 기술사는 표준의 기술 내용뿐 아니라 그것이 규제·인증·책임(제조물책임) 체계와 어떻게 맞물리는지를 함께 조망해야 한다. 성능 한계로 인한 사고의 책임 소재가 제조사·운영자·운전자 중 누구에게 있는지의 법적 논의도 SOTIF 입증 수준과 직결된다.

  • 조직·거버넌스 — 시나리오 자산과 안전문화: SOTIF의 경쟁력은 결국 '얼마나 풍부하고 체계적인 시나리오·주행 데이터 자산을 축적했는가'로 귀결된다. 시나리오 DB의 형상·버전 관리, 데이터 품질 거버넌스, 미지 위험을 지속 발굴·반영하는 조직 프로세스가 뒷받침되지 않으면 아무리 뛰어난 알고리즘도 '입증되지 않은 안전'에 그친다. 기술사는 SOTIF를 단일 프로젝트의 검증 활동이 아니라, 데이터·프로세스·문화에 걸친 전사적 지속 투자로 설계·운영하는 거버넌스 관점을 갖추어야 한다.

참고자료

한 줄 요약: SOTIF(ISO 21448:2022)는 고장이 없어도 의도한 기능의 성능 한계·오인식 때문에 생기는 위험을 다루는 자동차 안전 표준으로, 시나리오를 알려짐×안전의 4영역으로 나눠 Area 2·3를 줄이고 트리거 조건 분석·검증·타당성확인·운용 모니터링으로 미지 위험을 통계적으로 논증하며, ISO 26262(고장 안전)·ISO/PAS 8800(AI 안전)과 결합해 자율주행 안전을 떠받친다.