ISO26262, ISO21434, ASPICE의 Audit과 Assessment의 차이

1. 들어가가며: 혼란스러운 배경

자동차 업계에서는 Audit(감사)과 Assessment(심사)라는 용어가 자주 혼용되어 사용되어 왔습니다. 아래의 예와 같이, 어느 소프트웨어 엔지니어가 메일을 확인하다 아래 제목을 보고, 한숨을 쉽니다.

ISO 26262 기능안전 심사 준비 자료 요청
ASPICE 프로세스 심사 사전 미팅 안내
ISO/SAE 21434 사이버보안 감사 관련 회의 요청

그리고 품질팀에서 갑자기 “다음 달 내부 Audit이 있으니, 프로세스 증빙을 정리해 달라”고 요청하고, 기능안전 담당자는 “기능안전 Assessment도 준비해야 하니 Safety Case와 관련 증빙이 필요하다”고 말합니다. 그러다 보니 담당 소프트웨어 엔지니어의 머릿속에는 물음표만 늘어납니다.

겉으로 보기에는 Audit은 규정 준수 확인, Assessment는 수준 평가 정도의 차이는 있는 것 같지만, 실제 현장에서는 이 모든 활동을 통칭해 그냥 ‘심사’라 부르고, OEM에서 오는 메일에는 또 Security ‘감사’라는 표현까지 뒤섞여 사용됩니다.

결국 담당 엔지니어는 지금 내가 준비하고 있는 것은 감사(Audit)인가, 심사(Assessment)인가, 아니면 인증을 위한 심사 전체를 말하는 것인가? 어디 까지를 Audit이라고 하고, 어디서부터를 Assessment라고 해야 하는지, 그 경계는 점점 더 모호해져만 가는 것처럼 느껴집니다.

이러한 현장에서 자주 발생하는 혼란을 해소하기 위해서 이번에는 각 표준(ISO 26262, ISO/SAE 21434, ASPICE)에서 요구하는 Audit과 Assessment의 개념 차이를 이해 가능하도록 정리하고, 또한 기능안전 Assessment와 사이버보안 Assessment의 통합의 효율성도 살펴보도록 합니다.

2. 표준별 Audit 및 Assessment 개념 정의와 목적

2.1 ISO 26262의 Functional Safety Audit vs. Assessment

ISO 26262(도로 차량 기능안전)에서는 confirmation measures(확인 조치)라는 틀 안에서 Functional Safety Audit(기능 안전 감사)과 Functional Safety Assessment(기능 안전 심사)를 구분합니다. 표준에 따르면,

Functional Safety Audit: ISO 26262 프로세스 관련 목표가 달성되었는지를 판단하는 활동입니다. 다시 말해, 개발 프로젝트에서 기능안전 프로세스가 표준이 요구하는 방식으로 수행되었는지를 독립적으로 확인하는 절차이며, Audit의 초점은 프로세스 준수 여부에 있으며, 절차와 문서가 표준 요구사항을 충족하는지를 점검합니다. 즉 프로세스 중심의 점검이라고 볼 수 있습니다.
Functional Safety Assessment (FSA): 제품(Item) 또는 엘리먼트(Element)에 대해 기능 안전 목표(안전 목표)가 실제로 달성되었는지를 판단하는 독립적인 평가 활동입니다. FSA는 Audit보다 포괄적인 시각으로, 해당 항목의 안전 목표(Functional Safety Objectives) 실현 여부를 판단하는 것이 목적입니다. Assessment의 범위에는 안전 계획서와 그에 따라 산출된 모든 산출물, 기능안전 확보를 위한 프로세스, 구현된 안전 메커니즘의 적절성과 효과성, 안전 케이스에 제시된 논거 등을 모두 포함합니다. 즉, 제품과 개발 프로세스 전반에 걸친 안전 확보 여부를 종합적으로 검증합니다. 결과적으로 FSA를 수행한 후에는 해당 아이템의 기능안전 확보 상태에 대해 승인(acceptance), 조건부 승인(conditional acceptance), 거부(rejection)의 권고 판단이 담긴 평가 보고서가 작성됩니다. 이는 단순 준수 여부를 넘어서 제품 출시의 안전 승인 여부를 독립적으로 평가하는 것입니다.

요약하면, ISO 26262의 Audit은 프로세스 중심, Assessment는 안전 목표(제품) 중심입니다. Audit 결과는 보통 추후 Assessment의 입력으로 활용되며, Audit에서 식별된 프로세스 상의 문제점은 Assessment 시에 고려됩니다. 두 활동 모두 독립적으로 수행되어야 하나(개발팀과 독립성 유지), Audit은 절차 준수 확인, Assessment는 안전 확보 판단이라는 차이가 있습니다.

2.2 ISO/SAE 21434의 Organizational Cybersecurity Audit과 Cybersecurity Assessment

ISO/SAE 21434는 Organizational Cybersecurity Audit(조직 사이버보안 감사 – 5.4.7절)과 Cybersecurity Assessment(사이버보안 심사- 6.4.8)을 요구하고 있습니다. 즉 Organizational Cybersecurity Audit은 표현과 같이 조직 레벨의 CSMS(Cybersecurity Management System)의 정기적인 프로세스 감사이며, Cybersecurity Assessment는 특정 차량/부품이 실제로 충분히 안전한지 독립적으로 판정하는 제품/아이템 평가입니다.

Organizational Cybersecurity Audit: 조직의 사이버보안 관리체계(CSMS)가 ISO/SAE 21434의 조직 레벨 요구사항을 충족하고 있는지 실제 프로젝트/제품에 일관되게 적용되고 있는지를 독립적으로 정기 점검하는 활동입니다. 즉 조직 차원의 CSMS가 제대로 설계운영·개선되고 있는지 보는 시스템/프로세스 감사로서, IATF 내부 감사 프로세스와 연계가 가능합니다.
Cybersecurity Assessment(CSA): ISO/SAE 21434에 따르면 사이버보안 심사란 “아이템(Item)의 자산(asset)들이 잠재적 위협 시나리오로부터 충분히 보호되고 있는 상태를 판단하는 활동”으로 정의됩니다. 쉽게 말해, 개발된 차량 아이템(또는 부품)이 알려진 위협에 대해 적절한 보안 대책이 적용되어 안전한지를 독립적인 시각에서 판단하는 것입니다. 그 심사 범위는 해당 프로젝트의 사이버보안 계획과 그에 명시된 모든 산출물, 식별된 사이버보안 위험에 대한 대처 조치, 구현된 보안 통제(control)의 적절성과 효과, 그리고 표준의 목표 달성 여부를 입증하는 근거들을 모두 포함합니다. 기능안전과 마찬가지로 CSA 를 수행한 후에는 해당 아이템의 사이버보안 확보 상태에 대해 승인(acceptance), 조건부 승인(conditional acceptance), 거부(rejection)의 권고 판단이 담긴 평가 보고서가 작성됩니다.

즉 Organizational Cybersecurity Audit은 조직 전체 CSMS의 건강상태를 정기적으로 체크하는 조직·프로세스 감사이며, Cybersecurity Assessment는 제품 보안성에 대한 독립 평가이며, 이는 기능안전의 Assessment에 대응되는 개념입니다.

2.3 Automotive SPICE®에서의 Process Assessment

Automotive SPICE®(ASPICE)는 자동차 소프트웨어 개발 프로세스의 성숙도와 품질을 심사하기 위한 모델로, ISO/IEC 330xx 시리즈 (구 ISO/IEC 15504 SPICE)를 기반으로 합니다. ASPICE에서는 Audit보다는 Assessment라는 용어를 사용하며, 구체적으로 Process Assessment(프로세스 심사)를 수행합니다. ISO/IEC 33002:2015에서는 프로세스 심사의 목적을 “특정 조직 단위의 프로세스 구현 상태를 이해하고 심사하는 것(The purpose of process assessment is to understand and assess the processes implemented by an organizational unit)”으로 명시하고 있습니다. 즉, 프로세스 심사란 조직에서 실행 중인 개발 프로젝트가 정해진 모델이나 기준에 얼마나 적합하고 성숙하게 수행되는지 측정하는 활동입니다. ASPICE의 Assessment는 프로세스의 성숙도를 측정하는 데 초점이 있으며, 일반적으로 프로세스 개선(Process Improvement)을 위한 진단이나 OEM의 공급사 선정 평가 등에 활용됩니다. Audit처럼 단순히 규정 준수 여부를 체크하는 것이 아니라, 현재 프로세스의 수행 역량을 등급으로 평가하고 부족한 부분을 도출하는 것이 특징입니다. 또한 평가 결과는 여러 조직 간 벤치마킹이 가능하도록 신뢰도와 일관성이 중요합니다. 물론 여기서 CLASS라는 용어가 등장하는 데 이부분은 심사원들이 이해하는 전문영역이라 설명은 제외하도록 합니다.

한편, Automotive SPICE에는 ‘Audit’이라는 용어가 표준 용어로는 등장하지 않지만, 품질 시스템 맥락에서는 종종 ‘프로세스 감사’라는 용어를 혼용하기도 합니다. 예를 들어 IATF 16949에서는 제품 실현 프로세스에 대한 제조 공정 감사 등을 요구하는데, 이것은 ASPICE의 프로세스 평가와 목적과 방법이 다릅니다. 품질 Audit은 특정 절차 준수 여부를 확인하고 불합리 또는 비준수 항목을 발견하는 데 초점을 두는 반면, ASPICE Assessment는 프로세스 능력 향상과 수준 측정에 중점을 둡니다. 따라서 ASPICE 심사 결과는 프로세스 능력 등급과 개선 권고를 제공하여 지속적 개선에 활용되고, Audit 결과는 주로 시정 조치를 통해 규정 준수를 확보하는 데 활용됩니다. 두 접근 모두 중요하지만, 용어와 목표가 다르므로 혼용해서는 안 됩니다.

3. 기능안전과 사이버보안의 효율적인 Assessment

기능안전(ISO 26262)과 사이버보안(ISO/SAE 21434)은 둘 다 리스크 기반 접근인 HARA ↔ TARA (위험 식별→평가→대응)의 방법론을 적용하고, V모델 기반으로 라이프사이클이 컨셉→요구사항→아키텍처 →구현→검증/검증→생산→운영/서비스→폐기로 동일하며, 계획, 요구사항 관리, 형상/변경관리, 검증/검증, 공급망 관리 등 공통 프레임워크를 사용합니다. 또한 독립적인 평가 요구인 FSA(Functional Safety Assessment)와 CSA(Cybersecurity Assessment)도 같은 판정결과(승인, 조건부 승인, 거부 등)을 요구합니다. 더 나아가 실제 설계에서는

안전을 위해 진단/로그를 많이 남기면 → 보안 관점에서는 정보 노출 리스크
보안을 위해 강한 인증/암호화를 걸면 → 안전 긴급상황에서 응답 지연/복잡성 증가

처럼 Safety와 Security 요구가 충돌하는 부분이 생깁니다.

이러한 이유로 통합하여 심사를 하면 이 트레이드오프가 논리적으로 정당한지, 해야 할 운영 절차나 추가적인 기술적 조치가 필요한지 한 번에 검토할 수 있어, 각각 따로 최적화하다가 전체 시스템은 이상해지는 상황을 줄일 수 있습니다. 다시 말해 통합된 Assessment는 기술적·조직적·비용 측면에서 모두 합리적인 선택이라고 할 수 있습니다.

4. 정리하며

자동차 산업에서는 기능안전, 사이버보안, 프로세스 품질 등 다양한 표준 요구사항을 동시에 충족해야 하며, Audit과 Assessment는 이러한 표준들의 신뢰성을 확보하기 위한 필수 활동입니다. 그러나 용어와 개념이 혼용되면 실무에서 불필요한 혼란을 초래하고, 경우에 따라 안전과 품질 프로세스의 위험으로 이어질 수 있습니다.

이에 본 고에서는 ISO 26262, ISO/SAE 21434, ASPICE 세 표준을 중심으로 Audit(감사)과 Assessment(심사)의 정의와 차이를 정리하고, 표준 간에 통합이 가능한 심사 요건을 설명하였습니다. 비록 각 표준이 접근하는 대상과 세부 목적은 다르지만, 공통적으로 독립적인 검증을 통해 부족함을 식별하고 이를 개선하거나, 그 결과를 바탕으로 승인 여부를 판단한다는 목적을 공유합니다.

이러한 관점에서 Audit과 Assessment는 서로 다른 표준을 관통하는 하나의 통합된 독립 검증 메커니즘으로 이해할 수 있으며, 이는 향후 기능안전·사이버보안·프로세스 품질 심사를 보다 효율적이고 일관된 방식으로 설계하는 데 중요한 고려점이 되기를 기대합니다.