SW 업데이트 활동에서 기능안전과 사이버보안의 연계 활동

ISO 24089(SUMS, Software Update Management Systems)는 차량 소프트웨어 업데이트의 전 주기를 다루지만, 그 본질은 기능안전(ISO 26262)의 안전성 보장과 사이버보안(ISO/SAE 21434)의 취약점 차단을 업데이트 시점까지 연장하는 것이며, 그러므로 공급사도 두 표준의 활동을 단일 산출물 흐름 위에서 SW업데이트 활동의 정합성 및 일관성을 점검해야 합니다.

1. 개요

자동차 산업에서 차량은 더 이상 출고 시점에 완성되는 제품이 아닙니다. SDV 패러다임 아래에서 차량 기능은 OTA를 통해 출고 후에도 지속적으로 변경되며, 이에 따라 출고 이후 발생하는 안전 결함과 보안 취약점을 어떻게 관리할 것인가가 핵심 과제로 부상하고 있습니다. ISO 24089는 이러한 문제 인식 아래 제정된 표준으로, 자동차 소프트웨어 업데이트의 거버넌스와 엔지니어링 활동을 조직 레벨부터 캠페인 실행 레벨까지 정의합니다.

다만 ISO 24089가 단독으로 작동하는 표준이 아니라는 점이 중요합니다. 표준 본문은 여러 곳에서 ISO 26262과 ISO/SAE 21434의 활동 산출물을 입력 또는 출력으로 명시적으로 요구합니다. 즉 업데이트 패키지 하나를 만들고 배포하는 과정에서 ASIL평가 결과와 TARA 결과가 동시에 인용되어야 합니다.

본 레터는 ISO 24089의 각 Clause 활동이 ISO 26262와 ISO/SAE 21434의 어떤 활동과 연계되는지 정리하고, 안전성 위반의 제거 및 점검과 사이버보안 취약점 차단을 동시에 달성하기 위한 실무적 점검 포인트와 사례를 제시하고자 합니다.

2. ISO 24089의 구조와 두 표준의 접점

ISO 24089는 활동 단위를 여섯 개의 레이어로 구분합니다.

Clause 4는 조직 레벨로 SUMS의 거버넌스, 정책, 역할과 책임을 정의.
Clause 5는 프로젝트 레벨로 특정 ECU 또는 차량모델 단위의 SW 업데이트 프로젝트의 요구사항 기술
Clause 6은 업데이트를 관장하는 백엔드와 키 관리 인프라 요구사항 정의
Clause 7은 차량 자체의 업데이트 수신, 검증, 적용 능력에 대한 요구사항 명시
Clause 8은 SW 업데이트 패키지의 구성과 검증 요구사항 기술
Clause 9는 다수 차량을 대상으로 한 캠페인의 준비, 실행, 평가에 대한 요구사항 기술

특히 공급사 관점에서 Clause 5.3.4(무결성)에서 요구하는 패키지 데이터의 변조 방지와 검증을 위해 ISO/SAE 21434의 암호 메커니즘을 참조하지만, 동시에 ISO 26262 Part 6에서 요구하는 안전 관련 데이터 무결성(체크섬, CRC 등) 요구사항도 함께 충족해야 합니다. Clause 7.3.1(차량 위험 관리)에서는 업데이트 실패 시 잔여 차량 거동의 안전성을 다루는데, 이는 ISO 26262 Part 3의 HARA와 ISO/SAE 21434 Clause 15의 TARA가 동일한 시나리오를 두 시각으로 평가하는 형태가 됩니다. 결국 ISO 24089는 두 표준의 결과물을 패키지와 캠페인 단위로 통합, 재해석하는 통합 레이어 성격을 가지고 있습니다.

A. ISO 26262와의 연계 활동

기능안전 측면에서 가장 중요한 연계 지점은 Clause 7과 Clause 8입니다. Clause 7.3.1은 업데이트 자체가 발생할 수 있는 신규 위험원을 식별하도록 요구하며, 이는 기존 기능안전에서 도출된 안전 목표(Safety Goal)와 안전 요구사항(Safety Requirement)이 업데이트 후에도 유지되는지를 다시 평가하는 활동으로 이어집니다. 단순히 “기존 안전 분석을 재사용한다”가 아니라, 업데이트 시점의 임시 비안전 상태(예: 부트로더 전환 중 일시적 제동 보조 비활성화)와 롤백 시 잔여 위험을 별도로 식별해야 합니다.

Clause 8.3.3(패키지 검증)은 ISO 26262 Part 4의 시스템 통합/검증, Part 6의 소프트웨어 단위/통합 검증과 직접 결합됩니다. 공급사는 패키지가 변경한 소프트웨어 모듈의 영향 범위(Impact Analysis)를 분석하고, 그 범위에 해당하는 안전 관련 테스트 항목을 회귀 검증해야 합니다. 특히 ASIL X ECU의 경우 회귀 테스트 커버리지와 결함 주입(Fault Injection) 결과까지 패키지의 검증 산출물에 첨부해야 합니다. Clause 9.3.3(캠페인 평가)에서는 배포 후 차량으로부터 수집되는 진단 정보를 이용해 안전 기능의 정상 동작을 모니터링해야 하며, 이는 ISO 26262 Part 7의 생산, 운용, 서비스 활동과 연결됩니다. 여기서 “기능안전 활동은 출시 전에 끝나며, ISO 24089는 그 결과를 단순 참조할 수 있다”는 인식은 이슈가 될 수 있는 가정입니다. ISO 24089는 패키지마다 안전 영향도를 재평가할 것을 요구하므로, 공급사의 안전 분석 산출물(HARA, FSC, TSC, 안전 케이스)은 살아 있는 문서로서 업데이트 주기에 맞춰 갱신되어야 합니다.

B. ISO/SAE 21434와의 연계 활동

사이버보안 측면에서 ISO 24089는 ISO/SAE 21434의 운용 단계 활동을 구체적인 업데이트 메커니즘으로 구현하는 역할을 합니다. Clause 4.3.2(지속적 개선)는 ISO/SAE 21434 Clause 13(운용 및 유지보수)에서 다루는 취약점 공개(Vulnerability Disclosure)와 사이버보안 사건 대응(Incident Response)의 직접 후속 절차이며, 공급사는 OEM의 제품 보안 사고 운영 절차에 관련 대응 능력을 갖추어야 합니다.

Clause 5.3.4(무결성)는 ISO/SAE 21434 Clause 11의 사이버보안 검증과 결합되며, 패키지 서명에 RSA 2048비트 이상 또는 ECDSA P-256 이상의 알고리즘을 사용하고 해시는 SHA-256 이상을 사용하는 등 구체적 암호 기준을 적용해야 합니다.

Clause 9.3.2(캠페인 실행)와 Clause 9.3.3(캠페인 평가)에서는 배포 중 사이버 공격 탐지와 사후 인시던트 모니터링이 요구됩니다. 공급사는 자신이 제공한 ECU에서 발생한 비정상 로그를 OEM에 어떤 포맷과 주기로 회신할지, 그리고 어떤 임계값에서 캠페인을 긴급 중단할지를 사전에 합의해야 합니다.

3. 연계 활동 방안

추상적인 매핑 설명만으로는 실무에 적용하기 어렵기 때문에, 공급사가 다루는 두 가지 대표 ECU 유형을 들어 안전과 보안의 연계 점검 방식을 기술하고자 합니다.

첫 번째는 ASIL C 또는 D 등급 제동 제어 ECU 펌웨어에 사이버보안 패치를 OTA로 배포하는 경우입니다. 제동 제어 ECU는 차량 자세 제어와 미끄럼 방지 동작을 담당하므로, 단순한 보안 패치 한 건이라도 그 안에 포함된 작은 타이밍 변경이 제동 거리 증가나 응답 지연으로 이어질 수 있다는 특성을 갖습니다. 따라서 공급사는 패치의 성격이 보안에 한정된 것이라고 해서 안전 검증을 약화시켜서는 안 되며, 안전 회귀 검증을 동일 수준으로 수행해야 합니다.

연계 점검의 흐름은 다음과 같습니다. 패키지를 만들 때 메타데이터에 ASIL 등급과 해당 패치가 대응하는 취약점 식별 정보를 함께 기록하여, 두 표준이 같은 패키지를 동일한 식별자로 가리키도록 해야 합니다. 패키지 검증 단계에서는 보안 패치가 제동력 응답성과 같은 안전 관련 타이밍 요구사항을 위반하지 않는지 회귀 테스트로 확인해야 하며, 이때의 회귀 시나리오 목록은 기존 ISO 26262 검증 계획을 참조할 수 있습니다. 캠페인 실행 단계에서는 일부 차량에서 비정상적인 감속 패턴이나 ABS 경고등 점등 같은 신호가 감지될 경우, 사이버보안 측의 SLA(서비스 레벨 협약)와 무관하게 캠페인을 즉시 중단하는 것이 두 표준의 공통 요구를 만족시키는 방향입니다. 즉, “보안 일정을 맞추는 것보다 이미 도로 위에 있는 차량의 안전을 우선한다”는 원칙이 캠페인 중단 조건에 명시되어야 합니다.

두 번째는 ADAS 전방 카메라 ECU의 인지 알고리즘을 새 버전으로 교체하는 경우입니다. ADAS 제어기는 단순 펌웨어 업데이트가 아니라 신경망 모델 파일이나 학습 가중치 데이터의 교체를 동반하는 경우가 많고, 그 결과 차량의 인지 성능 자체가 달라진다는 특성을 갖습니다. 따라서 일반 제어기와 달리, 기존에 정의해 둔 안전 요구사항을 만족하는지뿐 아니라 ISO 21448(SOTIF) 관점의 평가를 함께 수행해야 합니다.

연계 점검의 흐름은 다음과 같습니다. 차량 위험 관리 단계(Clause 7.3.1)에서는 개선된 새 알고리즘이 인지 성능 영역과, 동시에 새로 발생할 수 있는 인지 한계 영역(예: 야간 보행자 인식 결과의 변화나 새로운 도로 환경에 대한 오인식)을 모두 식별해야 하며, 이는 기존 SOTIF 분석을 갱신하는 활동으로 이어집니다. 동시에 사이버보안 관점에서는 알고리즘 모델 파일이 다운로드 과정에서 변조되지 않도록 무결성 검증을 적용해야 하는데, 이는 모델 파일의 해시 값을 패키지에 함께 포함시키고 차량 측에서 그 해시를 비교하는 방식으로 구현됩니다. 공급사는 패키지에 모델 해시뿐 아니라 그 모델이 검증된 시뮬레이션 시나리오 식별자를 함께 첨부함으로써, 사후에 어떤 모델이 어떤 도로 시나리오에서 검증되었는지가 두 표준 모두에서 동일하게 추적되도록 만들어야 합니다.

하지만 SW 업데이트 캠페인을 운영하다 보면, 기능안전과 사이버보안의 요구사항이 항상 같은 방향으로 일치시킬 수 없는 지점들이 존재합니다. 실무에서 부딪히는 갈등은 다음과 같이 정리할 수 있습니다.

첫째, 긴급 보안 패치와 안전 검증 기간 사이의 충돌입니다. ISO/SAE 21434 Clause 13의 운용 단계에서 신규 취약점이 공개되면 OEM이 정한 SLA에 따라 며칠 이내에 패치를 배포해야 하지만, ASIL 등급 ECU의 정상 회귀 검증 일정으로는 해당 SLA를 맞추기 어려운 경우가 많습니다. 이때 권장되는 접근은 패키지의 영향 범위 분석 결과에 따라 회귀 테스트의 최소 항목 집합을 사전에 정의해 두는 것입니다. 예를 들어 안전 관련 코드를 변경하지 않는 보안 패치라면 핵심 안전 시나리오만 회귀하여 신속히 배포하고, 안전 관련 코드를 변경하는 경우에는 SLA를 일부 양보하더라도 전체 회귀 검증을 강제하는 의사결정 방안을 사이버보안 케이스와 안전 케이스에 함께 명시해 두는 방식입니다.

둘째, 보안 강화와 차량 기능의 가용성 사이의 충돌입니다. 보안 부트로더 강화나 인증서 체계 전환은 보안 측면에서 명확한 개선이지만, 업데이트가 실패할 경우 차량이 정상 부팅되지 않거나 제동이나 인지 기능이나 성능 관련 안전 기능이 마비되는 부작용을 동반할 수 있습니다. 이에 대한 접근은 이중 뱅크 구조(A/B 파티션)를 설계 단계에서 적용하는 것입니다. 현재 운영 중인 소프트웨어(A 파티션)는 그대로 유지한 채 새로운 보안 업데이트를 별도 파티션(B)에 설치하고, 부팅 검증이 정상적으로 완료된 이후에만 B로 전환하도록 구성합니다. 만약 B 파티션의 부팅 검증이 실패하면 자동으로 A 파티션으로 복구되므로, 업데이트 실패 여부와 관계없이 차량은 항상 정상 동작 가능한 상태를 유지할 수 있습니다.

셋째, 통신 보안 강화와 배포 효율 사이의 충돌입니다. 강한 암호화와 모든 데이터의 무결성 검증은 보안에 유리하지만, OTA 패키지의 전송 시간과 차량의 전력 소비를 증가시킵니다. 공급사는 차량이 정차 중이거나 충전 중인 상태와 같이 안전한 컨텍스트에서만 배포가 허용되도록 실행 조건을 정의하고, 동시에 무결성 검증과 전송 채널 보호 수준을 OEM 보안 요구사항에 맞춰 균형 있게 유지해야 합니다.

4. 결론

ISO 24089는 SW 업데이트와 관련된 새로운 활동을 요구하도록 정의한 표준이지만, 기능안전과 사이버보안에서 이미 수행되어 온 활동들을 업데이트 단위로 묶고 그 일관성을 유지하도록 하는 것이 필요합니다. 따라서 공급사가 가장 먼저 해야 할 일은 새로운 산출물을 만드는 것이 아니라, 기존 ISO 26262 산출물(HARA, FSC, TSC, 안전 케이스)과 ISO/SAE 21434 산출물(자산 식별, TARA, 사이버보안 케이스)이 패키지 식별자와 캠페인 식별자에 의해 양방향으로 추적 가능하도록 만드는 작업입니다.

실무 적용 시 주의사항은 다음과 같이 정리할 수 있습니다.

패키지 메타데이터에 ASIL과 Attack Feasibility rating 점수를 함께 기록하여 우선순위 충돌이 발생할 때 의사결정 근거를 남겨야 합니다.
회귀 테스트 범위를 안전과 보안에서 따로 정의하지 말고 영향 범위 분석을 단일 기준으로 통합해야 합니다.
캠페인 중단 임계값을 안전 신호(예: 비정상 감속, DTC 폭증)와 보안 신호(예: 인증 실패율 증가)를 모두 포함하여 사전에 합의해야 합니다.
Tier-2 공급사가 제공하는 부품의 ISO 24089 준수 증빙을 Tier-1이 통합 관리해야 하며, 이는 ASPICE(Automotive SPICE) 공급사 평가와 연계 운영하는 것이 효율적입니다.
안전 케이스(Safety Case)와 사이버보안 케이스(Cybersecurity Case)를 별개의 산출물로 통합 연계하여, 동일한 패키지 식별자와 캠페인 식별자를 키로 삼아 양방향 추적이 가능한 산출물 체계로 관리해야 합니다 단, 별도의 산출물로 존재한한다면, 두개의 산출물 간의 일관성 확보와 통합 검토 단계가 필요합니다.
운용 단계의 학습을 다음 프로젝트의 입력으로 피드백하기 위해 OEM과 공급사 사이의 인시던트 회신 포맷과 보고 주기를 계약 단계에서 합의해 두어야 후속 캠페인의 의사결정 속도를 확보할 수 있습니다.

UNECE WP.29 R155(사이버보안)와 R156(소프트웨어 업데이트) 인증이 OEM에 의무화되면서 공급사의 역할과 책임이 커지고 있습니다. ISO 24089를 단독 표준이 아닌 두 안전, 보안 표준의 통합 운영 매개체로 인식하고, 단일 거버넌스와 단일 산출물 추적 체계를 갖추는 것이 향후 인증 대응의 핵심이 될 것입니다.