자동차 개발에서 AI와 GPU는 더 이상 연구용 기술이 아닙니다. 카메라 객체 인식, 센서퓨전, 주행 경로 판단, 운전자 모니터링처럼 계산량이 큰 기능에서 GPU는 핵심 실행 플랫폼이 되었습니다. 문제는 GPU가 빠르다는 사실이 곧 안전하다는 의미는 아니라는 점입니다.
현장에서는 “AI 모델을 충분히 학습했으니 GPU 쪽은 성능만 보면 된다”, “GPU 코드는 검증 도구가 부족하니 일반 시험으로 대체하면 된다”, “AI는 확률적이므로 기존 기능 안전 방식으로 설명하기 어렵다”는 이야기가 자주 나옵니다. 이런 말에는 현실적인 어려움도 있지만, 그대로 받아들이면 안전 케이스가 비어 있는 상태로 양산 판단을 하게 됩니다.
ISO 26262는 특정 기술을 금지하는 표준이 아니라, 위험을 식별하고 그 위험을 통제했다는 증거를 요구하는 표준입니다. 따라서 GPU 기반 AI 기능도 무엇이 위험한지, 어떻게 분리하고 감시했는지, 어떤 검증으로 충분성을 보였는지를 설명해야 합니다. 이 글은 AI 시대의 차량 시스템을 기능안전 관점에서 바라보고, 현장에서 자주 발생하는 이슈와 대응 방향을 정리한 내용입니다.
1. GPU 기반 AI 시스템의 오해와 기능 안전 이슈
GPU 기반 AI 시스템을 기능 안전 관점에서 다룰 때 가장 먼저 정리해야 할 것은 “GPU는 단순히 빠른 연산 장치일 뿐”이라는 인식입니다. 카메라 객체 인식, 센서퓨전, 경로 판단, 운전자 경고처럼 안전 관련 판단에 영향을 준다면 GPU는 단순 성능 부품이 아니라 차량 위험과 연결되는 구성 요소가 됩니다.
현장에서는 AI 모델 정확도가 높으면 안전 문제도 대부분 해결된다거나, GPU 코드는 검증 도구가 부족하므로 일반 시험으로 대체하면 된다는 인식이 생기기 쉽습니다. 그러나 모델이 올바른 판단을 하더라도 GPU 커널, 메모리 처리, 동기화, 스케줄링, 오류 보고 체계가 불안정하면 안전 기능은 실패할 수 있습니다.
GPU의 핵심 안전 이슈는 다음과 같습니다.
- 수많은 스레드가 동시에 실행되면서 실행 순서에 따라 결과가 달라지는 병렬 실행 오류가 발생할 수 있습니다.
- 평균 실행 시간이 빠르더라도 메모리 접근 지연이나 자원 경쟁으로 최악 응답 시간이 달라질 수 있습니다.
- 메모리, 캐시, 연산 유닛을 여러 기능이 공유하면 비안전 기능이 안전 기능의 실행 시간이나 데이터를 방해할 수 있습니다.
- 따라서 GPU가 QM으로 분류되더라도 ASIL 기능과 자원을 공유한다면 간섭 방지(Freedom From Interference)에 대한 근거가 필요합니다.
- GPU 내부 상태는 CPU처럼 쉽게 확인하기 어려워 오류가 발생해도 시스템이 제때 알지 못할 수 있습니다. 따라서 GPU 오류를 독립적으로 감지할 수 있는 모니터링 구조와 오류 보고 체계가 필요합니다.
결국 중요한 질문은 GPU를 사용했는가가 아니라, GPU가 틀리거나 늦거나 멈췄을 때 차량이 어떻게 안전하게 대응하는가입니다. GPU 기반 AI 기능은 AI 모델, GPU 소프트웨어, GPU 하드웨어, CPU 모니터링, 안전 상태 전이가 하나의 안전 흐름으로 연결되어야 합니다.
2. ISO 26262 관점의 질문과 안전 케이스
GPU 기반 AI 기능을 ISO 26262 관점에서 다룰 때 중요한 것은 GPU를 ASIL로 볼 것인지, QM으로 볼 것인지의 속성만 정하는 것이 아닙니다. 더 중요한 질문은 GPU 실패가 차량 위험으로 어떻게 이어지고, 그 위험을 설계와 검증 증거로 어떻게 통제했는가입니다.
확인해야 할 핵심 질문은 다음과 같습니다. GPU 결과가 틀리거나 늦거나 멈췄을 때 어떤 차량 위험이 발생하는가, GPU 관련 안전 요구사항이 시스템, 소프트웨어, 하드웨어 요구사항으로 분해되어 있는가, GPU와 ASIL 기능 사이의 간섭 방지를 설명할 수 있는가, GPU 오류를 독립적으로 감지하고 안전 상태로 전이할 수 있는가, 요구사항과 설계, 코드, 시험, 결함 조치가 서로 추적되는가입니다.
그러므로 안전케이스는
- “GPU를 사용했다”는 기술 설명이 아니라, GPU 오류가 발생해도 안전 목표가 유지된다는 논리적 증거입니다. 따라서 GPU가 담당하는 기능과 차량 위험 사이의 연결 관계, ASIL 또는 QM 판단 근거, GPU 실패 모드, 안전 메커니즘, 검증 증거, 잔여 위험과 운영 제한이 연결되어야 합니다.
- 결국 ISO 26262 관점의 핵심은 GPU가 항상 정상 동작한다는 주장이 아니라, GPU가 실패하더라도 시스템이 이를 감지하고 허용 가능한 안전 상태로 전이할 수 있음을 증거로 보여주는
것입니다.
3. 설계 전략: 신뢰보다 감시와 격리
안전 기능과 비안전 기능을 분리
가능하면 안전 관련 GPU 작업과 일반 작업은 전용 파티션, 전용 메모리 영역, 시간 분리, 우선순위 제어, 접근 권한 관리로 분리해야 합니다. 같은 GPU를 쓰는 것이 문제가 아니라, 서로 간섭하지 않음을 어떻게 입증했는지가 핵심입니다. 안전 기능이 필요한 시간에 실행되지 못하거나, 비안전 기능의 오류가 안전 기능의 데이터 영역을 훼손한다면 분리는 실패한 것입니다.
CPU 기반 독립 모니터링 체계
GPU 출력은 독립적인 CPU 모니터링을 통해 확인해야 합니다. 객체 위치와 크기가 물리적으로 가능한지, 프레임 간 변화가 비정상적으로 튀지 않는지, 지정 시간 안에 결과가 도착했는지, 신뢰도 점수가 안전 기준을 만족하는지 점검해야 합니다. 이 모니터는 GPU와 다른 원리로 판단해야 공통 원인 고장을 줄일 수 있습니다.
고장 대응과 안전상태 전이의 요구사항
GPU 기반 AI 기능은 고장 발생 시 누가 감지하고, 어떤 조치를 할지를 요구사항으로 미리 정해야 합니다. GPU 지연, 잘못된 출력, 헬스비트 중단, 메모리 오류가 발생하면 시스템은 운전자 경고, 기능 제한, 감속, 안전 정지 등 적절한 안전 상태로 전이해야 합니다. 고장 시 기능을 중지하는 것이 안전하면 Fail-Safe, 기능을 계속 유지해야 하면 Fail-Operational 전략을 적용합니다. 핵심은 GPU 고장을 완전히 없애는 것이 아니라, 고장을 감지하고 안전하게 대응할 수 있게 설계하는 것입니다.
업데이트와 재사용 조건 관리
AI 모델이나 GPU 커널은 양산 후에도 변경될 수 있습니다. 모델 파라미터, CUDA 커널, 드라이버, 하드웨어 설정이 바뀌면 기존 검증 결과를 그대로 재사용할 수 있는지 판단해야 하며, 변경 영향 분석과 회귀 시험 범위를 안전 케이스 갱신 기준에 반영해야 합니다.
4. 검증 전략: 설명 가능한 증거
GPU 기반 AI 시스템 검증은 주행 데이터만 많이 돌리는 방식으로는 부족합니다. ISO 26262 관점에서는 요구사항 기반 검증, 코드 수준 분석, 통합 시험, 타이밍 검증, 오류 주입, 안전 케이스 증거가 서로 연결되어야 합니다.
- 정적 분석: CUDA/C++ 코딩 규칙, 동기화 누락, 메모리 경계, 원자 연산 사용, 레이스 가능성을 실행 전에 확인합니다. 검출된 위반은 조치 결과와 예외 승인 근거까지 남겨야 합니다.
- 동적 시험: 반복 실행, 스트레스 시험, 메모리 검사, 타이밍 측정으로 실행 중에만 드러나는 오류를 찾습니다. 동일 입력을 여러 번 실행해 결과와 실행 시간이 흔들리는지도 확인해야 합니다.
- 통합 시험: 센서 입력, GPU 출력, CPU 모니터, 플래너, 제어 출력까지 데이터 흐름과 오류 처리를 확인합니다. GPU만 정상이어도 인터페이스나 모니터 조건이 틀리면 안전 기능은 실패할 수 있습니다.
- 시나리오 시험: 야간, 악천후, 부분 가림, 드문 객체, 센서 노이즈처럼 AI 기능이 흔들릴 수 있는 조건을 포함합니다. 운영 설계 영역(ODD) 밖에서는 어떤 제한 또는 경고가 필요한지도 함께 확인합니다. (SOTIF-ISO21448 영역의 참조)
- 오류 주입: GPU 응답 지연, 잘못된 결과, 헬스비트 중단, 메모리 오류를 넣고 감지 시간과 안전 상태 전이를 확인합니다. 안전 메커니즘은 문서에 적혀 있는 것보다 실제로 작동하는지가 중요합니다.
검증의 목적은 결함이 없다고 주장하는 것이 아니라, 결함이 위험으로 전이되기 전에 감지, 격리, 완화된다는 것을 보이는 것입니다. 특히 GPU의 간헐적 오류는 반복 시험과 경계 조건 시험을 함께 수행해야 확인할 수 있습니다.
AI 기능은 정확도 지표뿐 아니라 오탐과 미탐, 데이터 분포, 운영 설계 영역(ODD), 실패 시 반응, 모니터링 기준, 잔여 위험 수용 근거를 함께 제시해야 합니다. 필요한 경우 SOTIF 관점의 의도된 기능 성능 한계도 검토합니다.
5. 현장 체크포인트와 실무 적용
GPU 기반 AI 기능은 위험 식별, 설계 대응, 검증 증거 확보, 변경 관리 순서로 정리하는 것이 효과적입니다. 먼저 GPU가 담당하는 차량 기능을 정의하고, GPU 결과가 틀리거나 늦거나 멈췄을 때 어떤 위험으로 이어지는지 HARA와 연결해야 합니다. 이후 지연, 무응답, 잘못된 출력, 메모리 오류, 자원 간섭, 진단 누락 등 오류 유형별 대응 방안을 요구사항으로 정리합니다.
검증 단계에서는 정적 분석, 동적 시험, 오류 주입, 시나리오 시험이 어떤 안전 요구사항을 확인하는지 연결하고, 변경 단계에서는 AI 모델, GPU 커널, 드라이버, 하드웨어 설정 변경 시 필요한 재검증 기준을 정해야 합니다. 중요한 것은 활동의 개수가 아니라 위험, 설계, 검증, 증거가 끊기지 않고 이어지는 것입니다.
6. CPU-GPU 모니터링 구조와 역할별 실행
예를 들어 카메라 기반 객체 인식 기능에서 GPU가 차량, 보행자, 차선 후보를 빠르게 산출하더라도, 그 결과가 바로 제동이나 조향 판단으로 연결되면 위험할 수 있습니다. 따라서 CPU 기반 안전 모니터가 GPU 출력의 시간, 값, 연속성, 신뢰도를 독립적으로 확인하고, 통과한 결과만 플래너와 제어 기능이 사용하도록 해야 합니다. 이때 시스템 엔지니어는 GPU 실패가 안전 목표에 미치는 영향을 HARA와 시스템 안전 요구사항에 반영하고, 소프트웨어 엔지니어는 CUDA 커널의 동기화, 메모리 경계, 오류 반환, 타임아웃 처리를 구현 기준에 포함해야 합니다.
검증 엔지니어는 지연, 잘못된 결과, 메모리 오류, 모니터링 실패를 포함한 오류 주입 시험을 설계하고, 품질과 안전 담당자는 요구사항, 설계, 코드, 시험, 결함 조치가 추적되는지 확인해야 합니다. 이 예시의 핵심은 GPU가 항상 맞다는 전제가 아니라, GPU가 틀리거나 늦어도 CPU 모니터가 감지하고 차량을 허용 가능한 안전 상태로 전이시킬 수 있음을 증거로 입증하는 것입니다.
결론
AI 시대의 자동차 시스템에서 GPU는 선택이 아니라 필수에 가까워지고 있습니다. 그러나 기능안전 관점에서 중요한 질문은 “GPU를 썼는가”가 아니라 “GPU 실패를 차량 수준에서 통제할 수 있는가”입니다. 성능이 좋고 모델 정확도가 높아도, 오류 감지와 격리, 안전 상태 전이, 검증 증거가 부족하면 ISO 26262 관점의 설명은 완성되지 않습니다.
따라서 GPU 기반 AI 시스템의 안전 전략은 세 가지로 정리할 수 있습니다. 첫째, 안전 관련 기능과 비안전 기능을 가능한 한 분리하고 간섭을 통제해야 합니다. 둘째, GPU 결과를 독립적으로 감시하고 실패 시 안전 상태로 전이하는 아키텍처를 가져야 합니다. 셋째, 정적 분석과 동적 시험, 오류 주입, 시나리오 시험을 연결하여 안전 케이스 안에서 설명 가능한 증거를 만들어야 합니다.
A-SPICE가 단순 산출물 작성이 아니라 개발 역량을 설명하는 모델인 것처럼, ISO 26262도 문서 작성을 위한 표준이 아니라 위험을 다루는 방식의 표준입니다. GPU와 AI를 안전하게 쓰기 위한 핵심은 새로운 기술을 피하는 것이 아니라, 그 기술의 실패 방식을 이해하고 현장에 맞는 설계, 검증 체계를 만드는 것입니다.