ISO/PAS 8800은 AI 요소를 위해 새로 세운 독립 표준이 아닙니다. ISO 26262, ISO 21448 같은 기존 기능안전 표준은 데이터로 만들어진 동작, 즉 학습된 AI 모델에 대해 안전 논거를 충분히 제시하지 못합니다. ISO/PAS 8800은 바로 그 영역을 메우려고 나온 표준입니다. 그렇다면 기존 절차의 어디가 비어 있고, 이 표준은 그 자리를 어떻게 채우고 있을까요?
1. 개요
이 글은 ISO/PAS 8800이 왜 나왔고 어떻게 구성되어 있는지 다룹니다.
ISO/PAS 8800은 2024년 12월에 발간되었습니다 [1]. 담당 분과는 ISO/TC 22(도로차량) 기술위원회의 SC 32입니다. 적용 대상은 양산 도로차량에 탑재되며 AI 기술을 쓰는 안전 관련 전기 및 전자(Electrical and Electronic, E/E) 시스템입니다. 차량 밖에 있는 AI 요소의 개발은 대상이 아니지만, 그 요소가 차량 안전에 직접 또는 간접으로 영향을 준다면 차량과의 상호작용은 대상에 들어갑니다.
2. 왜 새 기준이 필요했는가?
기존 절차로 AI 요소를 그대로 다루기 어려운 까닭은 개발 방식이 다르기 때문입니다. 코드로 동작을 정하는 개발과 데이터로 동작을 정하는 개발을 나란히 놓으면 차이가 드러납니다.
| 구분 | 코드 기반 개발 | 데이터 기반 개발 |
|---|---|---|
| 동작을 정하는 것 | 사양서 | 사양서와 데이터셋 |
| 구현 | 사람이 코드를 작성 | 학습이 모델을 생성 |
| 사양 충족의 확인 | 리뷰와 테스트로 사양 충족 여부 확인 | 성능 측정으로 잔존 오류 규모를 논증 |
| 결함이 있는 곳 | 코드에서 찾아 수정 | 데이터와 모델 구조 |
코드 기반 개발이 지금까지의 방식입니다. AI로 코딩을 하는 시대이지만, 이 방식에서는 AI 모델 자체가 제품 코드에 들어가지 않습니다. 사양서가 동작을 정하고, 사람이 코드를 짜고(AI가 일부 코드를 생성하기도 합니다), 리뷰와 테스트로 사양 충족을 확인합니다. 잘못된 곳이 있으면 코드에서 찾습니다.
데이터 기반 개발은 학습으로 만든 AI 모델이 제품 안에서 동작하는 방식입니다. 이때는 사양서만으로 동작이 정해지지 않습니다. 이 표준은 AI 시스템에 안전요구의 정밀한 서술이 없다는 점을 검증의 첫 어려움으로 꼽고, 지도학습으로 구현된 모델은 더 분해할 수 없다고 적습니다 [1]. 그래서 데이터셋이 사양의 일부가 됩니다.
이 차이에서 기존 기능안전(Functional Safety) 절차로는 커버할 수 없는 항목이 세 가지 생깁니다.
- 데이터셋에 붙는 안전요구
- 남은 오류가 얼마나 되는지에 대한 정량 논증
- 출고한 뒤에 다시 학습하고 다시 승인하는 경로
ISO 26262 시리즈는 E/E 시스템의 고장으로 생기는 위험을 다루도록 만들어졌으므로, 이 세 가지를 직접 다루는 요구사항이나 절차를 두고 있지 않습니다 [2].
ISO 21448은 고장이 없는데도 성능의 한계 때문에 생기는 위험을 다룹니다 [3]. 방향은 맞지만, 원인이 학습 데이터와 모델 구조에 있는 경우까지 상세한 지침을 주지는 않습니다. 적용 범위도 다릅니다. ISO 21448은 주변 상황을 제대로 인지하는 것이 안전에 필수적인 기능을 대상으로 합니다. 보행자를 알아보는 카메라처럼 인지가 어긋나면 바로 위험으로 이어지는 기능이 여기에 해당합니다. 반대로 연비나 응답성 같은 성능을 끌어올리려고 AI를 넣은 요소는 ISO 21448의 대상이 아니더라도, 안전요구가 배분되면 ISO/PAS 8800의 대상이 됩니다.
여기서 분명히 짚어 둘 점이 있습니다. ISO/PAS 8800은 위험원 분석 및 리스크 평가(Hazard Analysis and Risk Assessment, HARA)를 표준의 범위에서 스스로 뺐습니다. 이 활동은 차량 수준의 시스템 안전공학 활동으로 넘겼습니다. 그래서 AI 팀이 위험도를 직접 매기는 구조가 아닙니다. AI 시스템이 받는 안전요구는 위에서 배분되어 내려옵니다.
문서 형식이 국제표준(International Standard, IS)이 아니라 공개 규격(Publicly Available Specification, PAS)인 데에도 이유가 있습니다. AI 기술의 최신 수준이 빠르게 바뀌기 때문에, 잔여 리스크를 낮추는 데 필요한 절차와 제품 특성을 상세 요구로 못 박기 어렵다고 표준 스스로 밝히고 있습니다 [1]. 그래서 이 문서는 상세 요구 대신 프로젝트별 보증 논증(assurance argument)을 세우는 원칙을 제시합니다. 산업 분야를 가리지 않는 일반 지침은 ISO/IEC TR 5469에 있고, ISO/PAS 8800은 그 틀을 도로차량에 맞춘 문서입니다 [4].
3. 표준은 어떻게 구성되어 있는가
크게 두 갈래로 나누어 읽으면 쉽습니다. 하나는 AI 안전 생명주기의 순서를 이루는 조항이고, 다른 하나는 모든 단계에 걸쳐 적용되는 조항입니다.
AI 안전 생명주기의 순서를 이루는 조항
| 조항 | 주제 | 핵심 내용 |
|---|---|---|
| Clause 9 | AI 안전요구 도출 | 배분된 안전요구를 정량 목표와 입력 공간으로 상세화 |
| Clause 10 | AI 기술과 아키텍처 조치의 선택 | 안전요구에 맞춘 모델 구조와 개발 조치의 선정 |
| Clause 11 | 데이터 관련 고려사항 | 데이터셋 생명주기와 데이터셋 안전 분석의 수행 |
| Clause 12 | AI 시스템의 검증과 확인 | AI 컴포넌트 시험과 시스템 수준 안전 확인의 구분 |
| Clause 13 | AI 시스템의 안전 분석 | 불충분성의 원인과 대책을 도출한 뒤 요구로 환류 |
| Clause 14 | 운영 중의 조치 | 필드 데이터 수집에서 재학습, 재승인, 재배포로 연결 |
모든 단계에 걸쳐 적용되는 조항
| 조항 | 주제 | 핵심 내용 |
|---|---|---|
| Clause 5 | 적합성 요구 | 테일러링 또는 부적합의 근거 |
| Clause 6 | 기본 개념 | 적용 경계와 원인결과 사슬 |
| Clause 7 | AI 안전관리 | 참조 생명주기와 확인 조치 |
| Clause 8 | 보증 논증 | 주장과 증거의 결합 구조 |
| Clause 15 | 도구 신뢰 | 학습 프레임워크와 지원 도구 |
Clause 9에서 Clause 14까지는 AI의 안전 관련 적용 순서를 이룹니다. 안전요구를 도출하고, AI 기술과 아키텍처 조치를 고르고, 데이터를 다루고, 검증하고, 분석하고, 운영합니다. Clause 5, Clause 6, Clause 7, Clause 8, Clause 15는 순서가 아니라 모든 단계에 걸립니다. 적합성 선언 방식과 기본 개념, 안전관리, 보증 논증, 도구 신뢰가 여기에 들어갑니다.
이 가운데 엔지니어들이 알고는 있지만 실무에서 잘 적용하지 않는 것이 Clause 8의 보증 논증입니다. 등급 하나로 조치의 엄격도가 정해지는 방식이 아닙니다. 조직이 안전하다는 주장을 세우고, 그 주장을 받치는 증거를 범주별로 모아 하나의 논리로 엮습니다. 표기법으로는 목표 구조 표기법(Goal Structuring Notation, GSN)이 쓰입니다. 참고로 Palin 등은 ISO 26262 안전 사례(safety case)에 GSN의 패턴(pattern)과 모듈 확장(modular extension)을 적용해 재사용할 수 있는 안전 논증을 만드는 방법을 제안했습니다 [9].
Annex A의 Table A-1에는 조항별 목적과 선행 조건, 작업산출물이 한 표로 정리되어 있습니다. 실무에서 자주 찾는 조항만 골라 요약하면 다음과 같습니다.
| 조항 | 무엇을 정하는가 | 대표 작업산출물 |
|---|---|---|
| Clause 7 | AI 안전관리와 참조 생명주기 | AI 안전 생명주기, 안전계획 |
| Clause 8 | 보증 논증의 구조와 평가 | 안전 보증 논증, 확인 조치 보고서 |
| Clause 9 | 배분받은 안전요구의 상세화 | AI 안전요구, 입력 공간 정의, 알려진 불충분성 |
| Clause 11 | 데이터셋 생명주기와 데이터셋 안전 분석 | 데이터셋 생명주기, 데이터셋 요구 사양, 안전 분석 증거 |
| Clause 12 | 검증과 확인의 범위 분할 | AI 시스템 검증 보고서, 확인 보고서 |
| Clause 14 | 운영 중 조치와 재승인 | 운영 중 안전 보증 절차 사양, 필드 데이터와 발견된 기능 부족 |
이 가운데 실무에서 가장 자주 되묻는 세 조항을 차례로 살펴보겠습니다.
Clause 11: 데이터셋에 붙는 안전요구
데이터셋에 안전요구가 붙는다는 말이 무엇을 뜻하는지는 Clause 11을 보면 알 수 있습니다. 이 조항은 데이터와 관련된 안전 속성을 예로 들어 놓았습니다.
- 데이터가 담으려는 현상에 실제로 대응하는가
- 입력 공간과 안전 관련 사례를 정해진 범위까지 커버하는가
- 분포가 실제 환경을 반영하며 편향이 없는가
- 데이터셋 사이에 정보가 새지 않는가
같은 촬영 구간에서 뽑은 영상을 학습과 시험에 나누어 쓰면 마지막 속성이 깨집니다. 시험 성적이 좋아도 그 숫자를 증거로 쓸 수 없다는 뜻입니다. 소스 코드만 형상 관리하고 데이터셋 버전은 담당자 폴더에 두는 관행으로는 이 속성들을 논증할 수 없습니다.
Clause 12: 검증과 확인
Clause 12는 검증과 확인의 영역을 나눕니다. 검증은 시험 단계에만 있는 활동이 아닙니다. 안전요구를 정의할 때는 그 요구가 정확하고 완전하며 서로 모순이 없는지 보고, 설계 단계에서는 아키텍처와 조치가 요구를 충족하는지 보며, 데이터 생명주기에서는 각 단계의 데이터를 봅니다.
AI 컴포넌트 시험은 순서가 정해져 있습니다. 배분받은 안전요구를 먼저 분석해 시험 방법의 조합을 고르고, 합격과 불합격을 가르는 판정 기준을 정한 다음에 실행합니다. 정확도 숫자를 먼저 뽑고 목표를 나중에 맞추는 순서가 아닙니다. 안전 확인은 성격이 다릅니다. AI 시스템이 상위 시스템에 통합된 뒤에 배분받은 안전요구가 충족되었는지 보는 활동이며, 보통 시스템을 통합하는 주체가 수행하고 AI 개발자는 이를 지원합니다.
시험을 어디서 수행하는지도 이 조항이 다룹니다. 복잡한 환경에서 동작하는 AI 시스템은 날씨나 다른 도로 사용자의 거동 같은 조건을 실차 시험으로 다 검증하기 어렵습니다. 강한 역광이나 지워진 차선 표시처럼 드물게 나타나는 상황을 충분히 커버하기는 특히 어렵습니다. 그래서 가상 시험 플랫폼을 씁니다. 가상 환경은 센서가 보는 영상만 만드는 것이 아니라 깊이와 객체 분할, 바운딩 박스 같은 정답 정보를 함께 만들어 줍니다.
다만 가상에서 만든 데이터를 그대로 증거로 쓸 수는 없습니다. 표준은 하드웨어 인 더 루프(Hardware in the Loop, HiL) 시험으로 같은 장면을 실제 센서에 넣어 가상 데이터셋과 실측 데이터셋을 대조하는 방법을 제시합니다. 가상 시험 플랫폼 자체를 어떻게 평가하는지는 ISO/IEC TR 5469에 자세히 나와 있습니다 [4].
Clause 7: 증거를 검토하는 사람
누가 증거를 검토하는지는 Clause 7에서 정의합니다. 안전계획과 보증 논증에 대한 확인 리뷰, AI 안전 감사, AI 안전 심사가 확인 조치로 요구됩니다. 요구되는 독립성 수준은 안전요구 가운데 가장 높은 자동차 안전 무결성 수준(Automotive Safety Integrity Level, ASIL)에 따라 달라집니다. 작성자와 다른 사람이면 되는 수준부터, 부서가 다르고 출하 권한이 분리된 사람이어야 하는 수준까지 네 단계로 나뉩니다. 기존 기능안전의 확인 조치(confirmation measure) 체계를 AI 산출물로 넓힌 것이라고 보면 됩니다.
혼동하기 쉬운 용어: 확인(validation)
확인(validation)이라는 말은 이 표준에서 세 가지 뜻으로 나옵니다.
- 학습 과정에서 검증 데이터로 AI 모델을 확인하는 것
- 일반 시스템 개발에서 말하는 확인
- ISO 26262에서 온 안전 확인
표준이 세 용어를 구분한다고 명시하고 있으므로, 사내 개발 문서에서 이 용어를 쓸 때도 어느 뜻인지 함께 적어 두는 편이 정확합니다.
4. 표준이 든 적용 예시
ISO/PAS 8800의 적용 여부를 가르는 기준은 AI를 쓰는지가 아닙니다. 그 AI에 안전요구가 배분되는지입니다. 표준 서론에 실린 예가 이 기준을 잘 보여 줍니다. 성능을 최적화할 목적으로 AI를 쓰는 엔진 제어기는 ISO 21448의 대상이 아니지만 ISO/PAS 8800의 대상입니다 [1]. 상황 인지가 본질적인 기능이 아니어도 안전요구가 걸리면 이 표준을 적용해야 합니다. 반대 방향도 분명합니다. AI 모델이 들어 있지 않은 컴포넌트는 ISO 26262 시리즈만으로 개발할 수 있습니다.
AI를 안전 메커니즘으로 쓰는 경우도 대상에 들어갑니다. 다른 요소를 감시하는 기능 자체가 학습으로 만들어졌다면, 그 감시의 성능을 증거로 논증해야 합니다.
부속서에도 실무에 바로 참고할 만한 내용이 모여 있습니다.
- Annex B: GSN으로 쓴 보증 논증 예시
- Annex E: 시스템 이론적 프로세스 분석(System-Theoretic Process Analysis, STPA) 적용 예시
- Annex G: 아키텍처와 개발 조치 목록
- Annex H: 머신러닝(Machine Learning, ML)에 쓰이는 성능 지표
처음 적용한다면 이 부속서들을 먼저 참조하는 것이 실무에 도움이 될 것입니다.
요구를 다 충족하지 못하는 경우에는 적절한 테일러링으로 그 요구가 적용되지 않음을 보이거나, 부적합이 수용 가능하다는 근거를 만들어 평가받습니다. 판단 방식은 ISO 26262-2를 따릅니다 [5]. 적용하지 않기로 한 결정에도 근거를 남겨야 하며, 그 근거가 논리적으로 합당해야 합니다.
5. 결론
ISO/PAS 8800을 새 표준이 하나 더 늘었다고 읽으면 대응이 어긋납니다. 이 문서는 기존 절차가 데이터로 만들어진 동작을 다루지 못하는 영역을 보완하기 위해 나왔습니다. 위험원 분석과 차량 수준의 리스크 판단은 원래 위치에 그대로 남아 있습니다.
그래서 첫 작업은 새로운 표준 절차나 방법론을 구축하는 것이 아닙니다. 지금 쓰는 개발 프로세스에서 AI 요소가 적용되는 지점을 찾는 일입니다. 그 지점에서 다음 세 가지를 확인해 보시기 바랍니다.
- 데이터셋에 안전요구가 붙어 있는가?
- 남은 오류의 크기를 숫자로 말할 수 있는가?
- 출고 뒤 재학습에서 재승인까지 이어지는 경로가 그려져 있는가?
비어 있는 지점이 보이면, 그 자리에 ISO/PAS 8800의 요구를 고려해 더해 가면 됩니다.
참고 문헌
- ISO/PAS 8800:2024, Road vehicles, Safety and artificial intelligence, Dec. 2024.
- ISO 26262-1:2018, Road vehicles, Functional safety, Part 1: Vocabulary, Dec. 2018.
- ISO 21448:2022, Road vehicles, Safety of the intended functionality, Jun. 2022.
- ISO/IEC TR 5469:2024, Artificial intelligence, Functional safety and AI systems, Jan. 2024.
- ISO 26262-2:2018, Road vehicles, Functional safety, Part 2: Management of functional safety, Dec. 2018.
- ISO/TS 5083:2025, Road vehicles, Safety for automated driving systems, Design, verification and validation, Apr. 2025.
- ISO/SAE 21434:2021, Road vehicles, Cybersecurity engineering, Aug. 2021.
- ISO 24089:2023, Road vehicles, Software update engineering, Feb. 2023.
- R. Palin, D. Ward, I. Habli, and R. Rivett, “ISO 26262 safety cases: Compliance and assurance,” in 6th IET International Conference on System Safety 2011, 2011, pp. 1-6, doi: 10.1049/cp.2011.0251.
표준의 판본과 발간 시기는 2026년 10월 3일에 확인한 기준입니다.
관련 서비스
AI 요소가 들어간 시스템의 안전요구 배분부터 보증 논증 정리까지 기능안전 대응을 고민 중이시라면, 세온이앤에스의 접근 방식을 확인해 보세요.
관련 영상
이 글의 핵심을 영상으로도 정리했습니다.