제8부 자율주행

8.10 기능안전 III — SOTIF(ISO 21448)

8.10.1 이 장에서 배우는 것 / 선수 지식

8.8~8.9에서 기능안전(ISO 26262)이 오작동(고장) 으로 인한 위험을 다룬다고 했다. 그런데 자율주행 사고의 상당수는 고장이 아니다 — 인지 시스템이 완벽히 정상 동작해도 안개 속 보행자를 못 보거나, 처음 보는 물체를 오인하거나, 엣지케이스에서 오판한다. 이것은 오작동이 아니라 의도된 기능의 한계다. SOTIF(Safety Of The Intended Functionality, ISO 21448) 가 이 빈틈을 다룬다. 기능안전 4부작의 III.

핵심 통찰: 자율주행 안전의 실질적 어려움은 고장이 아니라 "롱테일 엣지케이스" 다. 모든 부품이 정상 동작해도 인지가 충분하지 못하면 사고다 — 그리고 그 시나리오는 무한히 많고 다 열거할 수 없다. SOTIF는 이를 "알려진/모르는 × 안전/위험"의 4영역으로 틀을 세워, 모르는 위험(unknown-unsafe)을 체계적으로 줄이는 접근이다. 핵심은 "위험을 0으로 증명"이 아니라 "모르는 위험을 알려진 것으로, 위험을 안전으로 옮겨 허용 가능한 잔여 위험까지".

배우는 것:

SOTIF가 무엇인가 — 의도 기능의 한계로 인한 위험(고장 아님), 기능안전(8.8)이 못 메우는 빈틈.
4영역 프레임 — known/unknown × safe/unsafe, 목표(unknown-unsafe 최소화).
트리거 조건 — 기능 불충분을 유발하는 특정 조건의 식별·완화.
시나리오 기반 검증 — 시뮬레이션(8.15)·필드 데이터로 unknown을 발견·축소.
잔여 위험 — 무한 시나리오를 다 못 함, "얼마나 안전해야 충분한가"의 어려움.

선수 지식: 8.8(기능안전=오작동, 이 구분)·8.9(안전 메커니즘)·8.1(인지·엣지케이스·레벨·발표≠양산). 시뮬레이션은 8.15, 데이터 엔진은 8.14, 데이터 플라이휠은 7.7, AI 인지 안전은 8.11. 환경은 자율주행 안전 공학.

정직: SOTIF는 무한 시나리오를 다 검증할 수 없음을 인정하는 표준이다 — 위험을 0으로 증명하는 것이 아니라 체계적으로 줄여 허용 가능한 잔여 위험에 이르는 것. "얼마나 안전해야 충분한가"는 일부 사회적·규제적 판단이고 어렵다. 이 장은 개념·틀을 가르치되 실제 SOTIF 분석·검증·잔여 위험 논증은 자격 있는 엔지니어·표준·규제의 영역이다.

8.10.2 SOTIF가 메우는 빈틈 — 고장 없는 위험

8.8의 구분을 다시:

왜 자율주행에 결정적인가:

AV 인지가 지배적 안전 과제: 자율주행 사고의 상당수는 부품 고장이 아니라 인지가 상황을 충분히 다루지 못함 — 즉 대부분 SOTIF 영역. 기능안전(고장)만 잘해도 부족.
롱테일: 도로엔 무한히 다양한 상황(날씨·조명·객체·행동)이 있고, 학습·설계가 못 다룬 엣지케이스의 긴 꼬리가 위험. 이것이 자율주행 양산이 어렵고 느린 본질(8.1).
AI의 내재적 한계: 학습 기반 인지는 본질적으로 불확실·불완전하다 — 학습 분포 밖에서 틀릴 수 있음(8.11).

핵심: 기능안전(고장) + SOTIF(한계) 둘 다 필요하고, 자율주행에선 SOTIF가 더 어려운 과제다. 모든 부품이 완벽히 동작해도 인지가 보행자를 못 보면 사고 — 그것은 고장이 아니라 기능의 한계이고, SOTIF가 이를 체계적으로 다룬다.

8.10.3 4영역 프레임 — 알려진/모르는 × 안전/위험

SOTIF의 핵심 틀: 시나리오를 두 축(알려짐 vs 모름, 안전 vs 위험) 으로 4영역에 나눈다.

	안전(safe)	위험(unsafe)
알려짐(known)	① 알려진-안전 (검증된 안전)	② 알려진-위험 (위험 인지·완화)
모름(unknown)	④ 모르는-안전	③ 모르는-위험 ⚠️ (미지의 엣지케이스)

목표: ① 알려진-안전을 키우고, ③ 모르는-위험을 줄인다 — ②를 식별해 완화(트리거 조건 처리)하면 ①로, ③(가장 무서움)을 발견해 ②로 옮기고 완화하면 ①로.

각 영역:

① 알려진-안전(known safe): 우리가 알고 안전이 검증된 시나리오. 키우는 것이 목표.
② 알려진-위험(known unsafe): 위험함을 안 시나리오(트리거 조건 식별됨). 완화해 ①로.
③ 모르는-위험(unknown unsafe): 위험한데 우리가 모르는 시나리오 — 가장 무서운 영역(미지의 엣지케이스). 발견해 줄이는 것이 SOTIF의 핵심.
④ 모르는-안전(unknown safe): 모르지만 안전한 것.

핵심: SOTIF는 "모르는 위험(③)을 알려진 것으로 끌어내 완화" 하는 게임이다 — 무한 시나리오를 다 못 하니, 모르는 위험을 체계적으로 발견·축소한다(시뮬레이션·필드 데이터). ③을 0으로는 못 만들지만(미지는 늘 있음), 허용 가능한 잔여 위험까지 줄이는 것이 목표. 이것이 자율주행 검증의 본질.

8.10.4 트리거 조건 — 불충분을 유발하는 것

트리거 조건(triggering condition): 의도된 기능의 불충분을 유발하는 특정 조건.

식별: 분석·테스트·필드 데이터로 트리거 조건(어떤 조건이 인지를 무너뜨리나)을 찾는다.
완화: ① 기능 개선(더 나은 인지·센서·융합), ② 운영 설계 영역(ODD) 제한(그 조건을 회피, 예: 특정 날씨엔 자율 비활성), ③ 안전 메커니즘(8.9, 불확실 시 안전 상태), ④ 중복·다양한 센서(다른 모달리티가 보완).
ODD(Operational Design Domain): 시스템이 안전하게 동작하는 정의된 조건 범위 — 트리거 조건을 ODD 밖으로 두어 회피(8.1의 "L4가 어떤 ODD인가").

핵심: SOTIF는 트리거 조건을 식별·완화해 모르는 위험을 줄인다. 흰색 트레일러·짙은 안개·비정형 객체 같은 조건이 인지를 무너뜨릴 수 있고, 이를 찾아 기능 개선·ODD 제한·센서 다양성·안전 메커니즘으로 완화. ODD 정의가 핵심 — "어디서 안전한가"를 명확히(8.1 발표≠양산).

8.10.5 시나리오 기반 검증 — unknown을 발견

SOTIF의 검증은 무한 시나리오를 다 못 하니 모르는 위험을 발견·축소하는 데 집중한다:

왜 시뮬레이션·데이터인가:

시뮬레이션(8.15 DRIVE Sim): 위험·희귀 시나리오(엣지케이스·악천후·사고 직전)를 실차로 다 만들 수 없다 — 시뮬레이션으로 대규모·안전하게 탐색·재현. 시나리오 공간을 체계적으로 커버.
필드 데이터·데이터 플라이휠(7.7·8.14): 실주행이 미지의 상황을 노출 — 실패·이탈·불확실 사례를 모아 unknown을 발견하고 학습·검증에 환류. 쓸수록 안전해지는 루프.
통계적 논증: 무한 시나리오라 "0 위험 증명" 불가 — 충분한 주행·시뮬레이션·시나리오 커버리지로 허용 가능한 잔여 위험을 논증(통계·시나리오 기반).

핵심: 시뮬레이션 + 필드 데이터가 SOTIF의 엔진이다 — 모르는 위험은 책상에서 다 못 찾으니, 시뮬레이션으로 시나리오 공간을 탐색하고 실주행 데이터로 미지를 노출해 ③을 줄인다. 이것이 8.15(시뮬레이션)·8.14(데이터 엔진)·7.7(플라이휠)이 안전과 묶이는 이유.

8.10.6 잔여 위험 — "얼마나 안전해야 충분한가"

SOTIF의 정직한 한계:

0 위험 불가: 미지의 엣지케이스는 늘 있어 절대 안전은 증명 불가 — SOTIF는 이를 인정하고 잔여 위험을 허용 수준까지 줄인다.
"충분히 안전"의 기준: 인간 운전자 대비? 절대 사고율? — 부분적으로 사회적·규제적 판단이고 논쟁적. 자율주행 양산이 느린 이유 중 하나.
검증의 끝없음: 시뮬레이션·필드 데이터로 계속 줄이되, 양산은 그 시점의 잔여 위험 논증이 규제·안전 케이스를 통과해야.

정직: SOTIF는 "안전을 완성"이 아니라 "위험을 충분히 줄였음을 논증" 이다 — 0 위험은 불가능하고, "얼마나 안전해야 충분한가"는 일부 사회적·규제 판단이다. 자율주행 양산이 어렵고 느린 본질이 여기 있다(8.1 발표≠양산). 데모는 known-safe 영역만 보여주지만, 양산은 unknown-unsafe를 충분히 줄였음을 입증해야 한다.

8.10.7 중간 점검 (체크포인트)

[ ] SOTIF(ISO 21448)가 고장 없는 의도 기능의 한계로 인한 위험을 다루며, 기능안전(8.8)의 빈틈을 메움을 안다.
[ ] 자율주행에서 SOTIF가 더 어려운 과제(롱테일 엣지케이스·인지 한계)임을 안다.
[ ] 4영역(known/unknown × safe/unsafe)과 목표(모르는-위험 최소화)를 설명한다.
[ ] 트리거 조건 식별·완화(기능 개선·ODD 제한·센서 다양성·안전 메커니즘)를 안다.
[ ] 시뮬레이션·필드 데이터가 모르는 위험을 발견·축소하는 엔진임을 안다.
[ ] 0 위험 불가·허용 가능한 잔여 위험·"얼마나 안전해야 충분한가"의 어려움을 안다.

증상→의심: 고장은 다 막았는데 사고 → SOTIF(인지 한계) → 트리거 조건·시나리오 검증. 특정 날씨·객체에서 인지 실패 → 트리거 조건 → 완화·ODD 제한·센서 다양성. 테스트 통과인데 실주행 엣지케이스 실패 → 모르는-위험(③) → 시뮬레이션·필드 데이터로 발견. "0 위험" 주장 → 불가능(미지) → 잔여 위험 논증. 데모만 보고 양산 가정 → known-safe만 본 것(8.1). 모르는 위험을 책상에서만 → 시뮬레이션·실주행 데이터 필요.

8.10.8 트레이드오프·대안

결정	트레이드오프
ODD 좁게 vs 넓게	트리거 조건 회피·안전 vs 활용성·기능
기능 개선 vs ODD 제한(트리거)	능력·비용·시간 vs 운영 한정
시뮬레이션 vs 실주행(시나리오)	대규모·안전·sim2real 갭 vs 현실·느림·위험
잔여 위험 허용 수준	출시 가능 vs 안전·규제(사회적)
기능안전만 vs +SOTIF/AI	고장만 vs 한계·인지까지(필요·둘 다)

견해: ODD를 명확·보수적으로 정의해 트리거 조건을 회피하고, 시뮬레이션(대규모 탐색)·필드 데이터(미지 노출)로 모르는 위험을 줄인다. 좁은 ODD(특정 지역·날씨)는 안전하나 활용 제한, 넓힐수록 트리거 조건↑. 잔여 위험은 0이 안 되니 허용 수준을 규제·안전 케이스로 논증. 기능안전(8.8~8.9) + SOTIF + AI 안전(8.11)을 함께 — 자율주행 안전은 셋의 합. 모든 것이 자격 있는 엔지니어·표준·규제.

비엔비디아 정직: SOTIF(ISO 21448)는 업계 표준이고 모든 자율주행 개발자가 직면한다 — NVIDIA만의 것이 아니다. NVIDIA의 기여는 시뮬레이션(DRIVE Sim, 8.15)·데이터 엔진(8.14)·AI 인지 도구로 시나리오 탐색·데이터 플라이휠을 지원하는 것. SOTIF 자체·잔여 위험 논증·양산 결정은 OEM·자격 있는 엔지니어·규제의 영역. 자율주행 양산이 느린 것은 SOTIF(롱테일)가 어렵기 때문 — 컴퓨팅(8.1~8.5)이나 기능안전(8.8~8.9)만으로 안 됨.

8.10.9 흔한 함정

기능안전 = 안전 전부 오해. ISO 26262(고장)만으론 부족 — SOTIF(한계) 가 자율주행의 더 큰 과제. 인지 한계는 고장이 아님.
인지 한계를 고장으로 처리. 정상 동작 중 못 보는 것은 오작동이 아니라 기능 불충분 → SOTIF·트리거 조건.
테스트 통과 = 안전. known-safe만 검증한 것 — 모르는-위험(③) 은 시뮬레이션·필드 데이터로 발견해야.
"0 위험" 주장. 무한 시나리오라 불가 — 허용 가능한 잔여 위험으로 논증.
ODD 모호. 트리거 조건을 회피하려면 ODD를 명확히 — "어디서 안전한가" 불명이면 위험.
시뮬레이션만 또는 실주행만. 시뮬레이션(대규모·안전·sim2real 갭)과 실주행(현실·미지 노출)을 함께.
데모를 양산으로. 데모는 known-safe 영역 — 양산은 unknown-unsafe 축소 입증(8.1).
이 책으로 SOTIF 논증. 개념·틀만 — 실제 분석·검증·잔여 위험·양산은 자격 있는 엔지니어·규제.

8.10.10 연습문제

연습 1 (빈틈). 기능안전(8.8)을 완벽히 했는데도 자율주행 사고가 날 수 있는 이유를, SOTIF로 설명하라.

정답

기능안전(ISO 26262)은 오작동(고장) 으로 인한 위험만 다룬다 — 센서 고장·비트 오류·SW 버그를 안전 메커니즘(락스텝·중복화, 8.9)으로 막는다. 그러나 고장이 전혀 없어도 사고가 날 수 있다: 인지 시스템이 완벽히 정상 동작해도 ① 안개·역광·악천후에서 객체를 못 보거나, ② 처음 보는 비정형 물체(특이 차량·도로 위 장애물)를 오인하거나, ③ 엣지케이스(반사·그림자·비정상적인 각도)를 오인한다 — 이것은 부품이 고장난 것이 아니라 의도된 기능의 한계(functional insufficiency) 다. 학습·설계가 그 상황을 충분히 다루지 못한 것. 기능안전은 이를 다루지 않으므로(고장이 아니라서), 기능안전만 완벽해도 인지 한계로 사고 가능. SOTIF(ISO 21448) 가 이 빈틈 — 의도 기능의 한계로 인한 위험 — 을 다룬다. 자율주행에선 사고의 상당수가 부품 고장이 아니라 인지 불충분이라, SOTIF가 더 큰 안전 과제. 기능안전(고장) + SOTIF(한계) + AI 안전(8.11) 셋이 다 필요 — 어느 하나로는 부족.

연습 2 (4영역). SOTIF의 4영역(known/unknown × safe/unsafe)을 설명하고, 어느 영역이 가장 위험하며 SOTIF의 목표가 무엇인지 답하라.

정답

4영역: ① 알려진-안전(known safe) — 알고 안전이 검증된 시나리오. ② 알려진-위험(known unsafe) — 위험함을 안 시나리오(트리거 조건 식별됨), 완화 대상. ③ 모르는-위험(unknown unsafe) — 위험한데 우리가 모르는 시나리오(미지의 엣지케이스). ④ 모르는-안전(unknown safe) — 모르지만 안전. 가장 위험한 영역 = ③ 모르는-위험 — 위험한데 존재조차 모르니 대비할 수 없다(예고 없는 사고의 원천, 롱테일 엣지케이스). SOTIF의 목표: ③(모르는-위험)을 체계적으로 발견해 줄이고, ①(알려진-안전)을 키운다. 방법: ③을 분석·시뮬레이션(8.15)·필드 데이터(8.14)로 발견해 ②(알려진-위험)로 끌어내고, ②를 트리거 조건 완화·기능 개선·ODD 제한으로 ①(알려진-안전)로 옮긴다. 무한 시나리오라 ③을 0으로는 못 만들지만(미지는 늘 있음), 허용 가능한 잔여 위험까지 줄이는 것이 목표. 핵심: 모르는 위험을 알려진 것으로 끌어내 완화 — SOTIF는 "모름을 줄이는" 게임이고, 그래서 시뮬레이션·필드 데이터가 엔진.

연습 3 (트리거 조건). "흰색 트레일러를 밝은 하늘 배경에서 못 본다"는 인지 한계를 트리거 조건·완화로 분석하라.

정답

기능 불충분: 카메라 인지가 흰색 트레일러(낮은 대비)를 밝은 하늘 배경에서 충분히 검출 못 함(특정 조명·색·대비 조건의 한계). 트리거 조건: "밝은 하늘 배경 + 흰색/밝은 대형 차량 + (역광·특정 각도)"가 그 불충분을 위험하게 만드는 조건. 식별: 분석·테스트·필드 데이터(실패·이탈 사례)로 이런 조건을 찾음 → ③(모르는-위험)에서 ②(알려진-위험)로. 완화(여러 층): ① 센서 다양성 — 카메라만이 아니라 레이더/라이다가 흰색 트레일러를 보완(다른 모달리티는 색·대비에 안 속음) → 융합으로 검출. 이것이 다센서가 SOTIF에 중요한 이유. ② 기능 개선 — 인지 모델을 그 조건 데이터로 학습·개선(데이터 플라이휠, 7.7·8.14), 후처리·플로지빌리티(다른 센서와 교차 검증). ③ ODD 제한 — 그 조건을 회피(예: 특정 조명·날씨에 자율 비활성) — 단 활용성 손실. ④ 안전 메커니즘(8.9) — 인지 불확실(낮은 신뢰)이면 안전 상태(감속·운전자 인수 요청). ⑤ 시뮬레이션(8.15)으로 그 조건을 재현·테스트해 검증. 정리: 트리거 조건을 식별해 센서 다양성·기능 개선·ODD·안전 메커니즘으로 완화 — 단일 해법이 아니라 다층. 흰 트레일러는 SOTIF의 유명한 예 — 정상 동작하는 카메라의 한계라 고장 메커니즘으로는 검출되지 않음.

연습 4 (검증). SOTIF에서 "모르는 위험"을 발견·축소하려면 왜 시뮬레이션과 필드 데이터가 둘 다 필요한지 설명하라.

정답

모르는 위험(③)은 책상 분석만으론 다 못 찾는다(미지라서) — 시뮬레이션과 필드 데이터가 상호 보완: 시뮬레이션(8.15 DRIVE Sim): ① 위험·희귀 시나리오(엣지케이스·악천후·사고 직전·드문 객체)를 실차로 안전하게 다 만들 수 없다 — 시뮬레이션으로 대규모·안전하게 합성·재현. ② 시나리오 공간을 체계적으로 탐색(파라미터 변주: 조명·날씨·객체·각도). ③ 발견한 트리거 조건을 재현·회귀 테스트. 한계: sim2real 갭(10.7) — 시뮬레이션이 현실을 완벽히 못 반영, 모르는 것은 시뮬레이션에도 없을 수 있음. 필드 데이터(8.14·7.7): ① 실주행이 미지의 실제 상황을 노출 — 시뮬레이션이 상상 못 한 엣지케이스를 현실에서 만남(실패·이탈·불확실 사례). ② 그 사례를 모아 unknown을 발견하고 학습·시뮬레이션에 환류(데이터 플라이휠). 한계: 위험 상황을 실주행으로 만들면 위험, 느림, 드문 케이스는 막대한 주행 필요. 둘 다 필요한 이유: 시뮬레이션은 대규모·안전·반복으로 알려진 공간을 커버하고, 필드 데이터는 현실의 미지를 노출 — 필드에서 발견한 새 엣지케이스를 시뮬레이션으로 변주·재현해 더 탐색, 시뮬레이션 가설을 필드로 검증. 순환(데이터 플라이휠, 7.7): 필드 발견 → 시뮬레이션 변주 → 학습·검증 → 배포 → 필드. 어느 하나로는 부족 — 시뮬레이션만이면 sim2real 갭·상상 한계, 필드만이면 느리고 위험. 둘의 보완으로 ③을 축소.

연습 5 (잔여 위험). "우리 자율주행은 안전을 완벽히 검증했다"는 주장을 SOTIF 관점에서 비판하고, 올바른 안전 논증을 설명하라.

정답

비판: "완벽히 검증"은 SOTIF 관점에서 불가능하다 — 도로 상황(날씨·조명·객체·행동)은 무한히 다양하고, 모르는-위험(③)은 본질적으로 존재조차 모르는 것이라 다 열거·검증할 수 없다. "위험 0 증명"은 미지의 엣지케이스가 늘 있으므로 불가능. "완벽 검증" 주장은 known-safe 영역만 보거나, 무한 시나리오의 본질을 무시한 것. 올바른 안전 논증: ① 잔여 위험 인정 — 0 위험이 아니라 허용 가능한 잔여 위험(acceptable residual risk) 을 목표로, 모르는-위험을 충분히 작게 줄였음을 논증. ② 체계적 축소 — 분석·시뮬레이션(8.15)·필드 데이터(8.14·7.7)로 ③을 발견·완화, 트리거 조건·ODD 관리. ③ 통계적·시나리오 기반 논증 — 충분한 주행·시뮬레이션·시나리오 커버리지로 "충분히 안전함"을 통계·시나리오로 입증(절대 증명이 아니라). ④ 명확한 ODD — "어디서·어떤 조건에서 안전한가"를 정의(8.1). ⑤ 지속 모니터링·갱신 — 양산 후에도 필드 데이터로 새 위험 발견·개선(데이터 플라이휠), 안전은 "완성"이 아니라 지속. ⑥ "얼마나 안전해야 충분한가" 는 일부 사회적·규제 판단 — 규제·안전 케이스 통과. 정리: 자율주행 안전은 "완벽 검증"이 아니라 "모르는 위험을 체계적으로 허용 수준까지 줄이고 그것을 논증·지속 관리". 0 위험을 약속하는 것은 SOTIF를 모르는 것 — 양산이 느린 이유가 이 잔여 위험·롱테일의 어려움(8.1 발표≠양산). 자격 있는 엔지니어·표준·규제의 영역.

8.10.11 요약 · 다음 장

SOTIF(ISO 21448) 는 고장이 없어도 의도된 기능의 한계(인지 불충분·엣지케이스)로 인한 위험을 다룬다 — 기능안전(ISO 26262, 8.8=오작동)이 못 메우는 빈틈. 자율주행에선 SOTIF가 더 어려운 과제(롱테일).
4영역(known/unknown × safe/unsafe) — 가장 위험한 모르는-위험(③) 을 발견·축소해 알려진-안전(①)으로 옮기는 것이 목표.
트리거 조건(불충분을 유발하는 조건)을 식별·완화 — 센서 다양성·기능 개선·ODD 제한·안전 메커니즘(8.9).
시뮬레이션(8.15) + 필드 데이터(8.14·7.7) 가 모르는 위험을 발견·축소하는 엔진 — 둘이 보완(sim2real 갭·현실 미지).
0 위험은 불가 — 허용 가능한 잔여 위험까지 줄였음을 통계·시나리오로 논증, "얼마나 안전해야 충분한가"는 일부 사회적·규제. 자율주행 양산이 느린 본질(8.1 발표≠양산).
정직: SOTIF는 위험을 0으로 증명하는 것이 아니라 체계적으로 줄이는 것, 실제 분석·잔여 위험·양산은 자격 있는 엔지니어·표준·규제의 영역.
SOTIF는 의도된 기능의 한계(고장도 공격도 아님)를 다룬다 — 공격자가 트리거 조건을 의도적으로 유발하는 경우(적대적 패턴·센서 스푸핑)는 사이버보안(8.12)과 경계가 맞닿는다.

다음 장: 8.11 기능안전 IV — AI 인지의 안전·검증. SOTIF의 핵심인 인지가 학습 기반(AI) 일 때의 특수한 안전 도전을 본다 — 신경망의 불확실성·설명 가능성·분포 밖 입력·검증의 어려움, 그리고 AI 인지를 안전 케이스에 넣는 접근(불확실성 추정·중복·모니터링). 이로써 기능안전 4부작(8.8~8.11)을 마무리한다.