로보택시 release를 승인하려면 ‘시험을 많이 했다’는 목록이 아니라 이번 ODD와 software·vehicle·operation 조합에서 남은 충돌·상해·사망 위험이 목표 아래라는 논증이 필요하다. Zoox Safety Case Framework의 실무 가치는 claim 문장을 늘리는 데 있지 않다. 세 영역의 서로 다른 증거를 한 safety clearance에서 합치고, 어느 하나가 바뀌면 다시 계산하도록 만드는 데 있다.
파일럿의 대상은 문서가 아니라 한 release다
Zoox Safety Case Framework는 autonomy behavior safety, robot platform safety, operational safety를 target ODD 안에서 평가한다고 설명한다. 주요 risk metric은 potential Collision, Injury, Fatality event의 추정 간격인 CIF이며, simulation과 real-world data를 사용한다. CIF는 실제 미래 사고를 정확히 예언하는 숫자가 아니라 가정과 evidence에 묶인 위험 추정치다.
파일럿 범위는 software release, vehicle revision, city·geofence, weather·road 조건, fleet operation과 support procedure를 정확히 고정한다. ‘Zoox 전체가 안전한가’를 한 번에 답하지 않는다. 이번 조합이 target을 통과하면 그 범위에만 clearance를 준다.
claim도 분해한다. autonomy는 perception·prediction·planning·control과 collision check, platform은 sensor·compute·actuator·firmware와 crash protection, operation은 mission control·maintenance·rider support와 incident response를 맡는다. 공통 hazard가 여러 영역을 건너면 evidence owner와 interface requirement를 함께 둔다.
현장 준비가 덜 됐으면 계산부터 멈춘다
ODD 정의가 모호하거나 fleet exposure가 편향돼 있으면 CIF를 정교하게 계산해도 의미가 약하다. 지도, 속도·도로유형, 날씨, 승객 범위, emergency service와 maintenance staffing을 baseline으로 고정한다. 새로운 market은 기존 도시 data를 prior로 쓸 수 있어도 현지 exposure와 edge case를 따로 모아야 한다.
| 영역 | 받는 입력 | 내는 증거 | 다음 승인자 |
|---|---|---|---|
| 자율주행 행동 | ODD·hazard·fleet log·scenario | simulation·closed-course·road risk estimate | system safety |
| 차량 플랫폼 | HARA·hardware rate·diagnostic coverage | FMEA/FTA/FMEDA·fault·crash 시험 | functional safety·vehicle |
| 운영 | fleet·정비·지원·incident 절차 | 훈련·감사·response와 human reliability | operations safety |
| 통합 clearance | 세 영역의 잔여 risk와 불확실성 | CIF target 비교·조건·제외범위 | release authority |
handoff의 약점은 평균값 사이에 숨어 있다. autonomy가 sensor fault를 처리한다고 가정했는데 platform diagnostic 시간이 다르거나, operation이 vehicle 상태를 보지 못하면 세 영역이 각각 통과해도 system claim은 깨진다. interface assumption을 시험 항목과 telemetry field로 바꾼다.
파일럿은 위험 기여도를 흔들어 보는 방식으로 설계한다
Zoox는 synthetic simulation과 실제 log replay, optimization으로 고위험 조건을 찾고, 드물게 나타나는 perception-sensitive scenario는 closed course에서 반복한다고 설명한다. 도로 주행은 준비된 software를 human-monitored test vehicle에서 확인한 뒤 driverless clearance로 이어진다. 각 방법은 서로 보완하지만 같은 오류를 공유할 수 있다.
파일럿은 대표 정상경로보다 risk model을 크게 흔드는 가정을 고른다. 취약도로이용자, 센서 가림, brake·steering fault, 통신단절, support delay와 maintenance error를 넣고 CIF contribution이 어떻게 변하는지 본다. simulation scenario의 likelihood weighting은 실제 fleet exposure와 맞춰야 한다.
- ODD와 software·vehicle·operation version을 동결한다.
- CIF target과 human benchmark의 기간·지역·중증도 정의를 기록한다.
- 각 hazard를 autonomy·platform·operation evidence와 requirement로 연결한다.
- 고위험·저빈도 scenario는 simulation과 controlled physical test를 조합한다.
- interface assumption과 common-cause failure를 별도 fault campaign으로 검증한다.
- 불확실성·excluded condition과 human review decision을 clearance에 남긴다.
성공률 대신 clearance 문턱을 측정한다
시험 합격률이 높아도 위험한 scenario가 빠졌다면 안전 case는 약하다. primary metric인 CIF 추정이 target을 충족하는지, 각 severity와 party에 대한 interval이 충분한지, scenario·requirement·fault coverage와 real-world correlation이 닫혔는지를 함께 본다.
| 예외 | 첫 책임자 | 필요한 증거 | release 처리 |
|---|---|---|---|
| simulation과 실물 불일치 | validation owner | seed·model·vehicle trace | 원인 닫힐 때까지 보류 |
| 새 platform fault mode | vehicle safety | HARA·FMEDA·fault test | CIF와 requirement 갱신 |
| support·정비 지연 | operational safety | incident drill·staffing·handoff log | ODD·fleet cap 또는 절차 수정 |
| 새 ODD edge case | autonomy·system safety | 현지 exposure·scenario result | 지역 clearance 별도 심사 |
| risk target 근처 uncertainty | release authority | sensitivity·confidence·독립 review | 보수적 제한 또는 추가 자료 |
CIF가 miles per event라면 값이 클수록 사건이 드물다는 방향도 명확히 표기해야 한다. 서로 다른 severity를 한 숫자로 평균내지 않고 collision, MAIS1+ injury와 fatality target을 분리한다. human benchmark의 불확실성도 denominator에 포함한다.
release 뒤 발견은 실패가 아니라 갱신 입력이다
공공도로에서 새 사건이 나오면 운영을 무조건 계속하거나 safety case를 전부 폐기하는 두 극단을 피한다. affected ODD·vehicle·release를 격리하고, event reconstruction과 counterfactual simulation, fault tree와 operational response를 갱신한다. 위험이 target을 넘거나 unknown이면 fleet 제한·중지와 수정 후 clearance를 거친다.
Zoox의 공식 safety 페이지는 Mission Control, TeleGuidance와 rider support의 역할을 설명한다. 이 기능이 존재한다는 사실은 response time과 모든 사건의 해결을 보증하지 않는다. drill, staffing, communication loss와 first responder handoff를 실제 운영 evidence로 넣어야 한다.
변경 이력은 이전 evidence를 무효화하거나 재사용하는 근거가 된다. model parameter update, sensor supplier, brake firmware, maintenance interval과 fleet 규모 확대가 hazard마다 어떤 test를 다시 요구하는지 impact matrix를 유지한다. 수정이 작은지 큰지는 code line 수가 아니라 risk contribution으로 판정한다.
확대 여부는 남은 위험을 숨기지 않는 데서 갈린다
scale 조건은 이번 release가 target을 통과했다는 것만이 아니다. 더 많은 vehicle·ride·city에서 operational support와 maintenance가 같은 수준을 유지하고, rare event detection과 reporting이 scale에 맞게 작동해야 한다. fleet를 늘리면 exposure가 늘어 새 사건을 빨리 발견하는 동시에 response workload도 커진다.
NHTSA의 Zoox 상업 면제 발표는 임시 면제와 강화된 감독을 함께 둔다. 규제 milestone은 scale 가능성을 높이지만 safety case의 release별 갱신을 대신하지 않는다. 제조 대수, active fleet와 승인 ODD를 각각 추적한다.
go는 claim–argument–evidence link가 현재 artifact hash와 맞고, 세 영역의 CIF contribution과 불확실성이 target 안에 있으며, interface·common-cause 시험과 운영 복구가 닫힌 경우다. no-go는 단순히 사고가 한 건 있었기 때문이 아니라 그 사건을 risk model로 설명하고 통제할 증거가 없을 때다. 제한 ODD로 되돌리는 것도 정당한 scale decision이다. 기체 기능, 낙하산·FTS와 운항 승인을 분리하는 DJI 낙하산·FTS 안전 사례도 단일 장치를 전체 safety case로 바꾸지 않는 비교 기준이 된다.
현장에서 다시 확인할 질문
Safety Case 파일럿은 몇 개월이면 충분한가요?
고정된 개월 수보다 필요한 exposure와 scenario·fault coverage, simulation–실물 correlation, 운영훈련이 닫혔는지가 기준이다. 희귀 중상·사망 위험은 road miles만으로 직접 입증하기 어렵기 때문에 simulation, controlled test와 human benchmark를 함께 쓰고 uncertainty가 target 안에 들어올 때까지 범위를 넓히지 않는다.
Zoox가 도시나 fleet를 늘릴 때 Safety Case를 새로 써야 하나요?
전체를 처음부터 버릴 필요는 없지만 변경 영향은 반드시 평가해야 한다. 새 ODD, vehicle·sensor·software, support staffing과 maintenance 변화가 건드리는 claim과 CIF contribution을 갱신하고 해당 evidence를 다시 통과시킨다. 영향이 없는 근거도 문서화돼야 이전 증거를 안전하게 재사용할 수 있다.
자료 마지막 확인: 2026년 8월 26일