safety case

이 문서는 자라는 중인 질문입니다. 아직 증거를 모으고 있으며, 내용이 바뀔 수 있습니다.

한 줄로 말하면

safety case는 “이 자율주행 시스템은 이 조건에서 충분히 안전하다”는 말을 그냥 선언으로 끝내지 않고, 무엇을 주장하는지·어떤 근거로 뒷받침하는지·어디까지가 적용 범위인지를 묶어 설명하는 안전성 입증 구조야.

비유로 이해하기

새 다리를 열기 전의 검사 서류를 떠올리면 쉬워. “튼튼하게 만들었다”는 말만으로는 차를 올릴 수 없어. 어떤 하중을 버텨야 하는지, 설계와 재료가 그 조건을 어떻게 만족하는지, 실제 시험에서 무엇을 확인했는지, 아직 통과시키지 않은 조건은 무엇인지를 함께 보여 줘야 해.

자율주행도 비슷해. 다만 다리는 같은 자리에 서 있지만 차는 날씨·도로·다른 운전자에 따라 계속 다른 상황을 만나. 그래서 안전성 입증도 한 번의 시험 성적표가 아니라, 위험을 찾아내고 줄이고 확인하는 근거의 묶음이 돼야 해.

정확한 정의

safety case의 중심에는 세 가지가 있어.

flowchart TB
    A["안전 주장<br/>어떤 조건에서 무엇이 안전한가"]
    B["위험과 경계<br/>어떤 실패와 운행 한계를 다루는가"]
    C["근거<br/>설계·시험·시뮬레이션·운행 기록"]
    D["검토와 갱신<br/>변경·사고 뒤에도 주장이 유지되는가"]

    A --> B
    B --> C
    C --> D
    D --> A

• 안전 주장은 막연한 “안전하다”가 아니야. 예를 들어 어떤 도로, 속도, 날씨, 차량 구성에서 어떤 위험을 허용 가능한 수준으로 낮춘다는 말이어야 해.
• 위험과 경계는 이 주장이 다루는 실패와 다루지 않는 조건을 함께 적는 자리야. 센서 고장, 잘못된 조향 명령, 통신 단절, 공사 구간처럼 무엇을 상정했는지 드러나야 해.
• 근거는 그 주장을 시험해 본 기록이야. 설계 검토, 격리 구조, 시뮬레이션, 시험 주행, 사고 대응 절차가 같은 무게를 갖는 것은 아니지만, 각 근거가 어느 위험을 줄이는지 연결돼야 해.
• 검토와 갱신은 소프트웨어나 운행 환경이 바뀌면 이전 근거도 다시 살펴야 한다는 뜻이야. 안전은 출시 전 한 번 통과하고 끝나는 성질이 아니지.

왜 중요한가

자율주행의 성능은 주행 영상이나 벤치마크 점수로 눈에 잘 보이지만, 공도 배포에서는 “어려운 상황을 만났을 때 왜 이 시스템이 통제된 범위 안에 남는가”를 설명할 수 있어야 해. 그래서 safety case는 모델 성능, 차량 제어, 운영 대응, 검증 절차 사이를 잇는 언어가 돼.

NVIDIA도 로보택시용 Halos Safety Evaluation Framework를 소개하며 레벨 2 보조운전부터 레벨 4 로보택시까지 신뢰할 만한 safety case를 만드는 도구와 지침을 제공한다고 설명했어.¹ 다만 회사가 프레임워크를 갖췄다는 사실과 특정 차량이 실제 공도에서 안전하다는 결론은 같지 않아. 그 사이에는 적용 범위에 맞는 독립적인 시험·운행 기록과 규제 검토가 남아 있어.

실제 예시

로보택시 안전 OS는 safety case에 들어갈 재료를 보여 줘. 안전 핵심 기능을 다른 기능과 격리하는 운영체제, 센서와 차량을 잇는 표준 인터페이스, 규칙 기반 가드레일, 대규모 시뮬레이션과 검증 인프라는 각각 다른 실패를 줄이려는 근거가 될 수 있어.

하지만 차량 안의 설계만으로는 충분하지 않아. 캘리포니아 자율주행차 규정 변화처럼 사고·위반 뒤의 데이터 기록, 원격 대응, 지오펜스 명령 이행도 공도에서 안전을 설명하는 일부가 돼. 차량이 평소에 잘 달리는 것과 문제가 생겼을 때 회사가 차량을 통제하고 설명하는 것은 다른 시험이기 때문이야.

또한 closed-loop simulation은 정책이 실제로 만든 다음 상황까지 시험하는 근거를 보태지만, 가상 환경이 현실을 모두 대신하지는 못해. 시험 하나가 safety case 전체를 완성하지 않는 이유야.

헷갈리지 말아야 할 점

• safety case는 인증서 한 장이 아니야. 인증은 특정 표준이나 요구사항을 만족했다는 중요한 증거일 수 있지만, 전체 주장·범위·운행 근거를 모두 대신하지는 않아.
• 주행거리가 안전을 자동으로 증명하지는 않아. 얼마나 달렸는지뿐 아니라 어떤 조건에서 달렸고, 어떤 위험을 만났으며, 실패를 어떻게 기록했는지도 봐야 해.
• 시뮬레이션이 실도로 시험을 없애 주지는 않아. 드문 위험 상황을 넓게 시험하는 데 유용하지만, 센서·도로·사람 행동이 현실과 다른 한계가 남아 있어.
• 안전은 기능 하나의 점수가 아니야. physical AI가 현실에서 움직일수록 모델, 차량 제어, 사람의 대응, 운영 기록이 함께 맞물려야 해.

관련 문서

• 로보택시 안전 OS — 차량 안쪽 안전 구조와 검증 인프라의 사례
• 캘리포니아 자율주행차 규정 변화 — 공도 운행 뒤 운영 책임과 기록의 문제
• closed-loop simulation — 행동의 누적 결과를 시험하는 방식
• physical AI — 현실 환경에서 작동하는 AI를 바라보는 더 큰 맥락

남은 질문들

• 자율주행차의 safety case에서 안전 주장과 운행 가능 범위는 어느 수준까지 공개돼야 할까?
• 설계·시뮬레이션·실도로 시험·사고 대응 기록은 서로 다른 위험을 어떻게 나눠 입증해야 할까?
• 소프트웨어 업데이트나 운행 지역 확대 뒤에는 어떤 근거를 다시 확인해야 할까?

각주

1. NVIDIA/Riccardo Mariani, 「For Robotaxis, Safety Must Be Built In, Not Bolted On」(2026-06-10) NVIDIA Blog. ↩︎