AEGLOSLAB 엔비디아 기술 스택

제8부 자율주행

8.11 기능안전 IV — AI 인지의 안전·검증

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

8.10(SOTIF)에서 자율주행 안전의 핵심 과제가 인지의 한계라 했다. 그런데 그 인지가 학습 기반(AI/신경망) 일 때, 전통적 안전(코드 기반)이 못 다루는 특수한 도전이 생긴다 — 신경망은 명세가 아니라 데이터로 학습되고, 왜 그렇게 판단하는지 설명하기 어렵고, 학습 분포 밖에서 예측 불가하다. 이 장은 그 AI 인지의 안전·검증을 본다. 기능안전 4부작(8.8~8.11)의 마무리.

핵심 통찰: AI 인지 안전은 활발한 미해결 연구 영역이다 — "이 신경망이 안전함을 증명"하는 합의된 방법이 없다. 전통 안전은 연역적(요구→설계→검증, 추적 가능)인데 AI는 귀납적(데이터→모델)이라 간결한 추적성이 없다. 그래서 접근은 형식적 증명이 아니라 통계적·아키텍처적 — 데이터 품질·불확실성 추정·중복/다양성·모니터링으로 위험을 줄이되, 보증은 통계·시나리오 기반이다. 이것이 자율주행이 어려운 핵심 이유다.

배우는 것:

  • AI 인지가 검증하기 어려운 이유 — 명세 없음·OOD 예측 불가·설명 불가·귀납 vs 연역·검증 갭.
  • AI 안전 접근(미해결, 떠오르는) — 데이터 품질·불확실성 추정·중복/다양성·모니터링·OOD 탐지·안전 아키텍처.
  • 안전 아키텍처 — AI를 doer로, 안전 감시(checker)로 감싸기(8.9).
  • 검증·메트릭 — 안전 관련 지표(평균 아닌 안전 critical), 시나리오·통계·시뮬레이션·필드.
  • 떠오르는 표준 — AI 안전(ISO/PAS 8800류)·기능안전·SOTIF와의 결합.

선수 지식: 8.10(SOTIF·인지 한계·시나리오/필드)·8.8(기능안전·추적성)·8.9(안전 메커니즘·중복·다양성·doer/checker)·6.6(데이터 큐레이션)·7.7(드리프트·플라이휠). 인지·데이터 엔진은 8.14, 시뮬레이션은 8.15. 환경은 자율주행 AI 안전.

정직(매우 중요): AI 인지 안전은 미해결·진행 중인 영역이다 — "신경망이 안전함을 형식적으로 증명"하는 방법은 없고, 표준(ISO/PAS 8800 등)도 진화 중이다. 이 장은 도전과 접근의 개념을 가르치되, 어떤 접근도 위험을 0으로 만들지 못하며 보증은 통계적·아키텍처적이다. 실제 AI 안전 케이스·검증·양산은 자격 있는 엔지니어·표준·규제의 영역이고, 이 책으로 안전을 보증할 수 없다.

8.11.2 왜 AI 인지는 검증하기 어려운가

전통 소프트웨어 안전(8.8)은 연역적이다 — 요구를 명세하고, 설계로 분해하고, 코드를 리뷰하고, 각 요구를 검증으로 닫는다(추적성). AI 인지는 이 틀에 안 맞는다:

전통 SW (연역) AI 인지 (귀납) 요구 설계 코드(리뷰 가능) 검증 (요구별) '이 코드가 보행자를 어떻게 검출하는가' 를 줄 단위로 리뷰·추적 가능 데이터 학습 신경망 (수백만 파라미터) '이 신경망이 왜 이렇게 판단하나'를 줄 단위로 설명·추적 불가

AI 인지의 안전 난점:

  • 명세 없음: 신경망의 행동은 데이터로 학습된 것이지 명세된 것이 아니다. "보행자 검출" 요구를 코드로 추적할 수 없다 — 학습된 가중치가 그 행동을 암묵적으로 담는다.
  • OOD(분포 밖) 예측 불가: 학습 분포 안에선 잘 하지만, 처음 보는 입력(out-of-distribution) 에서의 행동은 예측 불가 — 자신 있게 틀릴 수 있다(8.10 모르는-위험).
  • 설명 불가(opacity): 왜 그렇게 판단했는지 설명하기 어려워, "모든 경우를 커버함"을 입증하기 어렵다.
  • 취약성(brittleness): 미세한 변화·적대적 입력·엣지케이스에 갑자기 틀릴 수 있다. 드리프트(7.7)로 시간이 지나며 나빠지기도.
  • 검증 갭: 입력 공간이 무한이라 다 테스트 못 한다. 그리고 평가셋 정확도 95%가 안전이 아니다 — 평균이 아니라 드문 안전 critical 케이스(보행자·야간·악천후)가 중요하고, 평균 지표는 그것을 은폐한다.

핵심: AI 인지는 "명세·추적·설명"의 전통 안전 도구가 안 통한다 — 데이터로 학습된 불투명한 함수라, 형식적으로 "안전함"을 증명할 수 없다. 그래서 안전을 다른 방식(데이터·불확실성·중복·모니터링)으로 접근하되, 보증은 형식 증명이 아니라 통계적·아키텍처적이다. 이것이 자율주행 안전의 가장 어려운 매듭.

8.11.3 AI 안전 접근 — 데이터·불확실성

AI 인지 안전의 떠오르는 접근(미해결이나 실무 방향):

① 데이터 품질·커버리지(안전의 토대). AI 모델의 안전은 데이터에 묶인다 — 학습 데이터가 운영 영역(ODD)·엣지케이스·안전 critical 상황을 커버해야:

데이터 품질·커버리지 (안전의 토대) 큐레이션 (6.6): 정제· dedup· decontamin ation (정직한 평가) 커버리지: ODD의 조건 (날씨· 조명·객체· 지역)을 데이터가 대표하나 엣지케이스· 안전 critical: 드문 위험 상황 (보행자· 야간· 악천후)을 충분히 데이터 플라이휠 (7.7· 100): 필드 실패를 데이터로 환류 '데이터 갭 = 안전 갭' 모델이 못 본 상황은 위험

② 불확실성 추정(모를 때 알기). 모델이 자신의 불확실성을 알아야 — 확신이 낮거나 OOD면 그것을 알려 안전 동작(8.9)을 트리거:

불확실성 추정 모델이 출력과 함께 '얼마나 확신하나'를 냄 낮은 신뢰·높은 불확실 → '믿지 말고' 안전 상태로(감속·운전자 인수·중복 채널) OOD 탐지: 입력이 학습 데이터와 다르면 → 신뢰하지 않음 '모를 때 모른다고 하는' 게 안전의 핵심 (자신 있게 틀리는 것이 위험)

핵심: AI 안전의 두 토대는 데이터(못 본 것은 못 한다)와 불확실성(모를 때 알기) 이다. 데이터가 운영 영역을 커버해야 하고(6.6·7.7), 모델이 OOD·저신뢰를 인식해 안전 동작을 트리거해야(8.9). "자신 있게 틀리는 것"이 가장 위험하니 불확실성 추정이 결정적.

8.11.4 AI 안전 접근 — 중복·다양성·모니터링

전통 안전 메커니즘(8.9)을 AI 인지에 적용:

③ 중복·다양성(8.9). 단일 AI 인지는 신뢰할 수 없으니, 다양한 중복 경로로 — 한 경로의 맹점을 다른 경로가 보완:

다센서·다모달 융합(8.7· 97) 카메라(AI) + 레이더 + 라이다 → 서로 다른 원리, 다른 맹점 예: 카메라가 흰 트레일러를 못 봐도(8.10) 레이더/라이다가 봄 다양한 모델: 같은 입력을 다른 모델·알고리즘으로 (공통원인 회피, 8.9) AI 인지를 다양성 있는 중복으로 → 단일 모델 실패에 강건

④ 모니터링·안전 아키텍처(doer/checker, 8.9). AI를 감시 envelope 로 감싼다:

AI 인지(doer) + 독립 안전 감시(checker, 8.9) 플로지빌리티: AI 출력이 물리· 논리적으로 타당한가(독립 체크) 안전 envelope: AI가 무엇을 하든 안전 제약(속도·거리) 안에 가두기 런타임 모니터링: OOD·이상· 드리프트(7.7) 탐지 → 안전 상태 AI는 성능을, 안전 감시(보통 더 단순·검증 가능)는 안전을 보장

이 패턴이 핵심이다 — AI를 "성능 엔진"으로 쓰되, 검증 가능한 안전 감시가 안전을 책임진다. AI가 불투명해도, 그 출력을 독립 체커·안전 envelope가 제약하면 위험한 행동을 막을 수 있다(완전하진 않지만).

핵심: AI 인지 안전은 "AI를 믿지 않고 감싸기" 다 — 다양성 있는 중복(센서·모델)으로 맹점을 보완하고, 독립 안전 감시(doer/checker, 8.9)·OOD 탐지·런타임 모니터링으로 AI 출력을 제약·검증한다. AI 자체를 증명할 수 없으니, 아키텍처로 안전을 확보. 단 이것도 완전하지 않다.

8.11.5 검증·메트릭·표준

검증(SOTIF·통계와 결합, 8.10). AI 인지는 다 테스트 못 하니:

검증 (SOTIF·통계와 결합, 8.10) 안전 관련 메트릭: 평균 (mAP)이 아니라 '안전 critical 지표' 보행자 recall(놓침이 치명적), 엣지케이스 성능, 드문 클래스 → 평균 95%가 안전이 아님 (드문 위험 케이스가 중요) 시나리오 기반(8.10): 트리거 조건·엣지케이스 시나리오로 테스트 시뮬레이션(8.15) + 필드 데이터(8.14·7.7): 모르는 위험 발견·축소 통계적 논증: 충분한 주행· 시나리오로 잔여 위험 (8.10)을 논증 회귀·모니터링(7.7): 모델 갱신 시 회귀, 운영 중 드리프트

떠오르는 표준. 기능안전(ISO 26262)·SOTIF(ISO 21448)는 AI를 직접 다루기엔 부족해, AI 안전 표준이 떠오른다:

  • ISO/PAS 8800류(자동차 AI 안전, 진화 중): AI 시스템의 안전을 다루는 표준화 노력 — 데이터·모델·검증·운영을 안전 관점에서. (명칭·내용은 진화·확인 필요.)
  • 결합: 기능안전(8.8~8.9, 고장) + SOTIF(8.10, 한계) + AI 안전(8.11, 학습 인지)이 함께 자율주행 안전을 구성.

정직: AI 인지 검증은 "평균 정확도"로 안전을 주장하면 안 된다 — 안전 critical 케이스(보행자·엣지케이스)가 평균에 묻힌다. 안전 관련 메트릭·시나리오·통계·시뮬레이션·필드로 잔여 위험을 논증하되, 형식적 증명은 불가하고 표준도 진화 중이다. 이것이 AI 자율주행의 미해결 매듭.

8.11.6 워크스루 — AI 인지 안전 설계

AI 인지를 안전 케이스에 넣는 접근(개념, 자격 있는 엔지니어가 실제 수행).

1) 데이터(토대) ODD·엣지케이스·안전 critical을 커버하는 데이터 (6.6), decontamination, 필드 플라이휠(7.7·8.14)로 갭 메우기 2) 불확실성 모델이 신뢰·불확실을 출력 → 저신뢰·OOD면 안전 동작 트리거(8.9) 3) 중복·다양성(8.9) 다센서·다모달 융합(카메라+레이더+라이다), 다양한 모델 → 맹점 보완 4) 안전 아키텍처(doer/checker, 8.9) AI(doer) + 독립 안전 감시(checker)·안전 envelope· 플로지빌리티·런타임 모니터 5) 검증 안전 관련 메트릭(보행자 recall 등)·시나리오(8.10)· 시뮬레이션(8.15)·필드 → 잔여 위험 논증(통계·시나리오, 8.10) 6) 운영 드리프트 모니터링(7.7)·필드 데이터·재학습· 재검증(데이터 플라이휠)

안전 아키텍처(개념):

센서 다양성 AI 인지(doer) 출력 + 불확실성 독립 안전 감시(checker) 플로지빌리티·OOD·envelope 안전 상태(불확실/이상 시) 융합·계획 안전 메커니즘(8.9) 제어

AI는 성능을, 감시·중복·불확실성·데이터가 안전을 (불완전하게) 확보한다.

견해: "AI를 믿지 말고, 데이터로 커버하고, 불확실성으로 모르는 것을 알고, 중복으로 맹점을 메우고, 감시로 제약하고, 시나리오·필드로 검증하고, 운영에서 계속 개선" — 이것이 현재 AI 인지 안전의 다층 접근이다. 어느 하나로는 부족하고, 전체가 통계적·아키텍처적 보증을 준다(형식 증명 아님). 자율주행 양산이 어려운 핵심이 이 AI 안전·SOTIF의 미해결성.

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

  • [ ] AI 인지가 검증하기 어려운 이유(명세 없음·OOD·설명 불가·귀납 vs 연역·검증 갭)를 안다.
  • [ ] 평균 정확도가 안전이 아님(안전 critical 케이스)을 안다.
  • [ ] AI 안전 접근(데이터 커버리지·불확실성 추정·중복/다양성·모니터링·OOD 탐지·안전 아키텍처)을 제시한다.
  • [ ] AI를 doer로, 독립 안전 감시(checker)로 감싸는 아키텍처(8.9)를 안다.
  • [ ] 검증이 시나리오·통계·시뮬레이션·필드(8.10)로 잔여 위험을 논증함과, 형식 증명 불가를 안다.
  • [ ] AI 인지 안전이 미해결·진행 중이고, 기능안전·SOTIF와 함께 필요함을 안다.

증상→의심: 평가셋 정확도 높은데 실주행 위험 → 안전 critical·OOD·엣지케이스 → 안전 메트릭·시나리오. AI가 자신 있게 틀림 → 불확실성 추정·OOD 탐지 없음. 단일 카메라 AI 맹점 → 중복·다양성(다센서) 없음. AI 출력을 그대로 신뢰 → 안전 감시(doer/checker)·envelope 없음. 시간 지나며 인지 저하 → 드리프트(7.7) 미모니터. "신경망을 증명했다" → 형식 증명 불가, 통계·아키텍처 논증. 데이터가 ODD 미커버 → 데이터 갭=안전 갭.

8.11.8 트레이드오프·대안

결정트레이드오프
AI 성능 vs 검증 가능성강력·불투명 vs 단순·검증 가능
단일 AI vs 중복/다양성비용↓·맹점 vs 비용↑·강건
불확실성 보수적 vs 공격적안전(거부↑·기능↓) vs 활용(위험↑)
안전 envelope 좁게 vs 넓게안전·기능 제약 vs 성능·위험
AI 안전만 vs +기능안전/SOTIF인지만 vs 고장·한계까지(셋 다)

견해: AI를 성능 엔진으로 쓰되 안전은 아키텍처로 — 검증 가능한 안전 감시(doer/checker)·중복/다양성·불확실성·데이터·시나리오 검증의 다층으로 위험을 줄인다. 불확실 시 보수적으로(안전 쪽), envelope로 제약. 단일 AI를 "무검증으로 신뢰하는" 건 위험. 기능안전(8.8~8.9, 고장) + SOTIF(8.10, 한계) + AI 안전(8.11, 학습)이 함께 — 자율주행 안전은 셋의 합이고, AI 안전이 가장 미해결. 모든 것이 자격 있는 엔지니어·표준·규제·검증.

비엔비디아 정직: AI 인지 안전은 업계·학계 전체의 미해결 과제이고 NVIDIA만의 답이 없다 — 떠오르는 표준(ISO/PAS 8800류)도 진화 중. NVIDIA의 기여는 데이터 엔진(8.14)·시뮬레이션(8.15)·다센서 융합·안전 SoC(락스텝·안전섬, 8.2)·불확실성/모니터링 도구로 접근을 지원하는 것. AI 안전 보증은 형식 증명이 아니라 통계·아키텍처적이고, 양산은 잔여 위험·규제에 달렸다. 자율주행이 어렵고 느린 본질이 여기(8.1 발표≠양산) — 컴퓨팅·기능안전이 충분해도 AI 인지 안전·SOTIF가 매듭.

8.11.9 흔한 함정

  • 평균 정확도 = 안전 오해. mAP 95%가 안전이 아님 — 안전 critical 케이스(보행자·엣지케이스)·드문 클래스가 중요. 안전 관련 메트릭.
  • AI를 무검증으로 신뢰하기. 단일 AI 출력을 무비판 신뢰 → 안전 감시(doer/checker)·중복·불확실성·envelope로 감싸야.
  • 불확실성 무시. 모델이 OOD·저신뢰를 모르면 자신 있게 틀림(가장 위험) → 불확실성 추정·OOD 탐지.
  • 데이터 갭 무시. 모델이 못 본 상황은 위험 — ODD 커버리지·엣지케이스·플라이휠(6.6·7.7).
  • 중복/다양성 없이. 단일 모달·단일 모델은 맹점 공유 → 다센서·다양한 모델(공통원인 회피, 8.9).
  • "신경망 증명". 형식적 안전 증명은 불가 — 통계·시나리오·아키텍처 논증, 형식 증명으로 오인 금지.
  • 드리프트 미모니터. AI는 시간이 지나며 나빠질 수 있음(7.7) → 운영 모니터·재학습·재검증.
  • AI 안전만으로 충분 가정. 기능안전(고장)·SOTIF(한계)도 필요 — 셋 다. 이 책으로 안전 보증 불가.

8.11.10 연습문제

연습 1 (왜 어려운가). 전통 소프트웨어 안전(8.8)의 방법(명세·리뷰·추적)이 AI 인지에 왜 안 통하는지, 귀납 vs 연역으로 설명하라.

정답

전통 SW 안전은 연역적: 요구를 명세 → 설계로 분해 → 코드를 줄 단위로 리뷰 → 각 요구를 검증으로 닫음(추적성). "이 코드가 보행자를 어떻게 검출하나"를 명시적으로 작성·리뷰·추적할 수 있다. AI 인지는 귀납적: 데이터로 학습 → 수백만 파라미터의 신경망. 안 통하는 이유: ① 명세 없음 — 행동이 데이터로 학습된 것이지 줄 단위로 명세된 것이 아님. "보행자 검출" 요구를 코드로 추적 불가(가중치가 암묵적으로 담음). ② 리뷰 불가 — 학습된 가중치를 사람이 읽어 "올바른가" 검토 못 함(불투명). ③ 추적성 깨짐 — 요구→설계→구현→검증의 간결한 추적 사슬(8.8)이 귀납적 학습엔 없음. ④ OOD 예측 불가 — 명세가 없으니 학습 분포 밖 입력의 행동을 보증·예측 못 함. 즉 전통 안전은 "무엇을 어떻게 하는지 명시하고 검증"인데, AI는 "데이터에서 배운 불투명한 함수"라 명시·검증의 대상이 다름. 그래서 AI 안전은 명세·리뷰·추적 대신 데이터·불확실성·중복·모니터링·통계 검증으로 접근하되, 형식 증명은 불가. 이것이 AI 자율주행 안전의 가장 어려운 매듭이고, 미해결 영역.

연습 2 (평균 ≠ 안전). "우리 검출 모델 mAP 95%니 안전하다"는 주장을 비판하고, 안전 관련 메트릭이 무엇이어야 하나?

정답

비판: 평균 지표(mAP 95%)는 안전을 보장하지 않는다 — 평균은 다수의 흔하고 쉬운 케이스에 지배되어, 드물지만 안전 critical한 케이스(보행자·야간·악천후·가려진 객체)의 실패를 은폐한다. mAP 95%여도 그 5%가 보행자 놓침에 집중되면 치명적. 안전은 평균이 아니라 최악·드문 위험 케이스의 문제(SOTIF 8.10의 롱테일). 또 평가셋이 운영 분포·엣지케이스를 대표 못 하거나 누출(decontamination 안 됨, 6.6)되면 95%도 거짓. 안전 관련 메트릭: ① 안전 critical 클래스의 recall(보행자·차량·VRU의 놓침률 — 놓침이 치명적, false negative 중심). ② 엣지케이스·드문 시나리오 성능(악천후·야간·비정형 객체별). ③ OOD/불확실 케이스 처리(모를 때 안전 동작하나). ④ 거리·조건별 검출 성능(먼 거리 보행자 등). ⑤ 시나리오 기반(트리거 조건별, 8.10). ⑥ 잔여 위험의 통계적 논증(충분한 주행·시뮬레이션). 핵심: 평균이 아니라 안전 critical 케이스의 실패율·롱테일을 봐야 하고, 그것도 시나리오·시뮬레이션(8.15)·필드(8.14)로 검증해 잔여 위험을 논증. "mAP 95% = 안전"은 안전 공학을 모르는 주장. 자격 있는 엔지니어가 안전 케이스로(8.8).

연습 3 (불확실성·OOD). AI 인지가 "자신 있게 틀리는" 것이 왜 가장 위험하고, 불확실성 추정·OOD 탐지가 어떻게 돕는지 설명하라.

정답

"자신 있게 틀림"이 가장 위험한 이유: AI가 높은 신뢰로 잘못된 판단(예: 보행자를 배경으로 확신)을 내면, 시스템이 그 출력을 신뢰해 위험한 행동(제동 안 함)을 한다 — 모델이 "모르겠다"고 했으면 안전 동작했을 텐데, 확신하니 검증 없이 진행. OOD(학습 분포 밖) 입력에서 신경망은 종종 근거 없이 확신하는 경향이 있어 특히 위험. 도움: ① 불확실성 추정 — 모델이 출력과 함께 얼마나 확신하나(불확실성) 를 냄. 저신뢰·고불확실이면 그 출력을 믿지 않고 안전 동작(감속·운전자 인수 요청·중복 채널 의존, 8.9)을 트리거 → "모를 때 모른다"가 안전. ② OOD 탐지 — 입력이 학습 데이터와 다른지(분포 밖) 탐지해, OOD면 신뢰하지 않고 안전 동작 → 처음 보는 상황(8.10 모르는-위험)에서 자신 있게 틀리는 것을 막음. 효과: 자신 있게 틀리는 대신 "불확실하니 보수적으로" 행동 → 위험한 오판을 안전 상태로 전환. 한계: 불확실성 추정·OOD 탐지 자체도 완벽하지 않음(틀린 확신을 다 못 잡음) — 그래서 중복·다양성·안전 감시(8.9)와 함께. 핵심: 안전의 큰 부분은 "모를 때 아는 것" — 불확실성·OOD가 AI를 "겸손하게" 만들어 모르는 상황에서 안전 동작을 끌어냄. 단 이것도 미해결 연구로 완전하지 않음.

연습 4 (안전 아키텍처). AI 인지를 안전하게 쓰는 doer/checker 아키텍처를 설계하라. AI가 불투명한데도 어떻게 안전을 확보하나?

정답

설계(doer/checker, 8.9 적용): AI 인지(doer) 가 객체 검출·분류·깊이 등 성능을 담당(강력하나 불투명·불확실). 그 출력을 독립 안전 감시(checker) 가 제약: ① 플로지빌리티 체크 — AI 출력이 물리·논리적으로 타당한가(예: 검출된 객체 위치·속도가 가능한가, 직전 프레임·다른 센서와 일관한가). ② 안전 envelope — AI가 무엇을 판단하든, 차량 행동을 안전 제약(속도·거리·감속 한계) 안에 가둠 — 예: AI가 "전방 비었다"고 해도 envelope가 안전 거리·속도를 강제. ③ OOD·이상·드리프트 런타임 모니터링(7.7) — 입력/출력이 비정상이면 안전 상태. ④ 중복·다양성(8.9) — 카메라 AI + 레이더/라이다(다른 원리·맹점) 융합으로 한 경로 실패 보완. ⑤ 불확실성 — AI가 저신뢰면 checker가 보수적으로. AI가 불투명해도 안전을 확보하는 원리: AI 자체를 증명할 순 없지만, 검증 가능한(더 단순한) 안전 감시·envelope·중복이 AI 출력을 제약하면, AI가 틀려도 위험한 행동(안전 envelope 밖)을 막을 수 있다. checker는 "성능"이 아니라 "타당성·안전 제약"만 보면 되어 더 단순·검증 가능. 비유: AI는 빠른 운전자, checker는 "물리·안전 규칙을 어기면 막는" 감독. 한계: envelope·checker도 완전하지 않고(특히 인지 자체가 틀리면 — 보행자를 못 보면 checker도 모름), 그래서 데이터·중복·다양성·시나리오 검증과 다층으로. AI 안전은 단일 해법이 아니라 아키텍처적 다층 — 그래도 형식 증명이 아니라 통계·아키텍처 보증. 자격 있는 엔지니어가 안전 케이스로.

연습 5 (종합·정직). 자율주행 안전이 기능안전(8.8~8.9)·SOTIF(8.10)·AI 안전(8.11) 셋을 모두 요구하는 이유와, "AI 자율주행은 곧 완성"이라는 낙관에 대한 정직한 평가를 하라.

정답

셋이 모두 필요한 이유(다른 위험): ① 기능안전(ISO 26262, 8.8~8.9) — E/E 오작동(고장) 으로 인한 위험(센서 고장·비트 오류·SW 버그). 안전 메커니즘·중복화로. ② SOTIF(ISO 21448, 8.10) — 고장 없어도 의도 기능의 한계(인지가 정상 동작해도 못 보는 엣지케이스·롱테일). 시나리오·트리거 조건·ODD로. ③ AI 안전(8.11) — 인지가 학습 기반일 때의 특수 도전(명세 없음·OOD·불투명·검증 갭). 데이터·불확실성·중복·아키텍처로. 셋은 다른 종류의 위험을 다루며 어느 하나로는 부족 — 고장을 다 막아도 인지 한계로 사고(SOTIF), 인지를 잘해도 학습 인지의 불확실성(AI 안전), AI를 잘해도 부품 고장(기능안전). 자율주행 안전 = 셋의 합(+ 사이버보안 8.12). "곧 완성" 낙관의 정직한 평가: ① AI 인지 안전·SOTIF는 미해결 — 신경망을 형식 증명할 방법이 없고, 롱테일 엣지케이스는 무한, 잔여 위험은 0이 안 됨. ② 데모 ≠ 양산(8.1) — known-safe 데모는 인상적이나 양산은 unknown-unsafe를 충분히 줄였음을 입증해야(어렵고 느림). ③ 컴퓨팅은 병목이 아님 — 칩(8.1~8.5)·기능안전(8.8~8.9)이 충분해도 SOTIF·AI 안전이 매듭. ④ "얼마나 안전해야 충분한가" 는 일부 사회적·규제 판단으로 미정. ⑤ ODD가 좁은 L4는 가능해지지만 "어디서나 L5"는 먼 목표. 정직한 결론: 자율주행은 꾸준히 진보하나 "곧 완성"은 과장 — AI 안전·SOTIF·잔여 위험·규제가 본질적 어려움이고, 한정된 ODD에서 점진적으로 확대되는 것이 현실적 경로. 안전은 마케팅이 아니라 자격 있는 엔지니어·표준·규제·검증의 영역이고, 이 책으로 안전을 보증할 수 없다.

8.11.11 요약 · 다음 장(기능안전 4부작 마무리)

  • AI 인지는 전통 안전(명세·리뷰·추적)으로 검증하기 어렵다 — 데이터로 학습된 불투명한 함수라 명세 없음·OOD 예측 불가·설명 불가·귀납 vs 연역·검증 갭. 평균 정확도 ≠ 안전(안전 critical 케이스가 중요).
  • AI 안전 접근(미해결, 다층): 데이터 커버리지(못 본 것은 못 함)·불확실성 추정(모를 때 알기)·중복/다양성(맹점 보완)·모니터링·OOD 탐지·안전 아키텍처(doer/checker).
  • AI를 doer로, 검증 가능한 안전 감시(checker)·envelope·중복으로 감싼다(8.9) — AI를 증명 못 해도 출력을 제약해 위험한 행동을 막음(불완전하나).
  • 검증은 안전 관련 메트릭·시나리오·통계·시뮬레이션(8.15)·필드(8.14·7.7) 로 잔여 위험을 논증 — 형식 증명 불가, 표준(AI 안전)도 진화 중.
  • 자율주행 안전 = 기능안전(고장) + SOTIF(한계) + AI 안전(학습) — 셋 다 필요, AI 안전이 가장 미해결. 정직: 이 영역은 진행 중이고, 실제 보증·양산은 자격 있는 엔지니어·표준·규제, "곧 완성"은 과장(8.1).
  • 기능안전(8.8~8.11) 완료: ISO 26262·ASIL(8.8) → 안전 메커니즘·중복화(8.9) → SOTIF(8.10) → AI 인지 안전(8.11). 자율주행 안전의 전 영역을 개념으로 익혔다(실제 안전은 전문가·표준의 영역).

기능안전·SOTIF·AI 안전 세 기둥을 봤다 — 남은 네 번째 기둥 사이버보안(ISO/SAE 21434·TARA, 8.12) 은 "공격자 없음"을 가정하지 않는 관점으로 이 셋을 보완한다(안전=기능안전+SOTIF+AI안전+사이버보안).

다음 장: 8.13 DriveWorks·Hyperion 센서 스택. 안전을 봤으니 개발 도구로 — DriveWorks(센서 추상화·캘리브레이션·인지/계획 모듈)와 Hyperion(센서 세트·레퍼런스 아키텍처)로 자율주행 센서 파이프라인을 구축하는 워크스루를 본다.