ASIL은 익숙한데 CAL은 낯설다 — ISO 26262 vs ISO 21434

현업에서 보는 차량 보안 기술

자동차 개발 현장에서 두 팀이 자주 부딪힙니다.

기능 안전팀: "SecOC 넣으면 실시간 응답이 늦어져요. 브레이크 제어에 영향 줍니다."
사이버보안팀: "인증 없이는 CAN Injection을 막을 수 없어요. 외부 공격에 무방비입니다."

둘 다 맞는 말입니다.
그런데 둘이 동시에 맞으면, 어떻게 해야 할까요?

ISO 26262와 ISO/SAE 21434. 자동차 산업의 두 핵심 규격이
왜 현장에서 충돌하고, 어떻게 함께 가야 하는지를 살펴봅니다.

두 규격은 무엇을 다루는가

두 규격은 출발점부터 다릅니다. ISO 26262는 기능 안전(Functional Safety), ISO/SAE 21434는 사이버보안(Cybersecurity)을 다룹니다. 같은 차량을 대상으로 하지만 바라보는 방향이 다릅니다.

ISO 26262 기능 안전 (Functional Safety)

자동차 E/E 시스템의 기능 안전 요구사항

무작위 HW 고장과 시스템 결함으로부터 보호

ASIL(A~D) 기반 위험도 분류

HARA로 위험 분석, Safety Goal 도출

결정론적 위협 — 고장 확률 기반 설계

개발 단계 중심 (양산 후 변경 최소화)

ISO/SAE 21434 사이버보안 (Cybersecurity)

차량 사이버보안 요구사항과 프로세스

의도적 공격으로부터 보호

CAL(1~4) 기반 위험도 분류

TARA로 위협 분석, Security Goal 도출

비결정론적 위협 — 공격자 의도 기반 설계

개발 + 운영 전 생애주기 (출시 후에도 지속)

두 규격의 가장 큰 차이는 위협의 성격입니다. ISO 26262는 "고장이 발생할 확률"을 기반으로 설계합니다. ISO/SAE 21434는 "공격자가 의도적으로 무엇을 할 수 있는가"를 기반으로 설계합니다. 같은 ECU를 보지만 전혀 다른 질문을 합니다.

HARA vs TARA — 비슷해 보이지만 다른 분석 방법

두 규격 모두 개발 초기에 위험을 분석하는 활동을 요구합니다. ISO 26262는 HARA(Hazard Analysis and Risk Assessment), ISO/SAE 21434는 TARA(Threat Analysis and Risk Assessment)입니다. 이름은 비슷하지만 접근 방식이 다릅니다.

HARA vs TARA — 분석 접근 방식 비교

HARA (ISO 26262)

위험 상황(Hazardous Situation) 식별

↓

심각도(S)·노출도(E)·제어가능성(C) 평가

↓

ASIL 등급 결정 (A/B/C/D/QM)

↓

Safety Goal 도출

↓

Functional Safety Requirement

TARA (ISO 21434)

자산(Asset) 식별

↓

위협 시나리오·공격 경로 분석

↓

Attack Feasibility·피해 평가

↓

Security Goal 도출

↓

Cybersecurity Requirement

관점	HARA (ISO 26262)	TARA (ISO 21434)
위협 원인	무작위 고장, 설계 결함	공격자의 의도적 행위
분석 시점	개발 초기 1회 (변경 시 재수행)	개발 + 운영 중 지속 업데이트
위험 등급	ASIL A~D + QM	CAL 1~4
핵심 질문	"이 기능이 실패하면 얼마나 위험한가?"	"이 자산이 공격받으면 얼마나 위험한가?"
결과물	Safety Goal → FSR → TSR	Security Goal → CSR → Architecture

두 분석은 같은 ECU를 대상으로 수행됩니다. 그런데 협력이 없으면 같은 기능에 대해 Safety Goal과 Security Goal이 서로 모순되는 결과가 나올 수 있습니다. 이것이 두 규격 통합의 핵심 과제입니다.

ASIL과 CAL — 위험 등급 체계가 어떻게 다른가

두 규격 모두 위험도를 등급으로 분류하지만 기준이 다릅니다. ISO 26262는 ASIL, ISO/SAE 21434는 CAL을 사용합니다.

관점	ASIL (ISO 26262)	CAL (ISO 21434)
의미	Automotive Safety Integrity Level — 안전 무결성 수준	Cybersecurity Assurance Level — 보안 보증 수준
등급	QM / A / B / C / D (낮음→높음)	CAL 1 / 2 / 3 / 4 (낮음→높음)
결정 기준	Severity(S) × Exposure(E) × Controllability(C)	Impact(피해) × Attack Feasibility(공격 가능성)
위협 성격	Random Failure 기반 — 고장 발생 확률	Intentional Attack 기반 — 공격자 의도와 능력
높은 등급 의미	ASIL-D: 가장 엄격한 안전 요구사항 적용	CAL 4: 가장 강력한 보안 대응 요구
등급별 요구사항	설계·구현·검증 요구사항이 ASIL별로 다름	보안 활동 수준과 Work Product가 CAL별로 다름

ASIL-D ECU라고 해서 CAL 4가 자동으로 적용되지 않습니다. 반대도 마찬가지입니다. 같은 ECU에 ASIL과 CAL이 독립적으로 결정되며, 둘의 요구사항이 충돌하지 않도록 설계에서 조율해야 합니다. 실무에서는 CAL보다 TARA 결과 자체를 직접 활용하는 경우도 많습니다.

FMEA vs TARA — 현장 엔지니어에게 더 익숙한 비교

HARA는 시스템 수준 분석이라 다소 추상적으로 느껴질 수 있습니다. 많은 개발자들에게 더 익숙한 것은 실제 ECU 개발에서 매일 쓰는 FMEA입니다. FMEA와 TARA를 비교하면 두 규격의 차이가 더 직관적으로 이해됩니다.

ISO 26262 FMEA 관점

어떤 고장 모드(Failure Mode)가 존재하는가?

그 고장이 시스템에 어떤 영향을 주는가?

고장을 어떻게 감지할 것인가?

Fail-safe 또는 Degraded Mode 동작이 가능한가?

고장 발생 확률을 어떻게 줄일 것인가?

ISO 21434 TARA 관점

공격자는 어떤 자산(Asset)을 노리는가?

어떤 공격 경로(Attack Path)가 존재하는가?

공격 성공 가능성(Feasibility)은 얼마나 되는가?

공격 성공 시 어떤 피해(Damage)가 생기는가?

어떤 보안 대응(Security Control)이 필요한가?

FMEA와 TARA의 결정적 차이는 "위협의 출처"입니다. FMEA는 시스템 내부에서 우연히 발생하는 고장을 다룹니다. TARA는 시스템 외부에서 의도를 가진 공격자를 다룹니다. 같은 브레이크 오동작이라도 FMEA는 "MCU가 오류를 일으켰을 때"를, TARA는 "공격자가 CAN 메시지를 주입했을 때"를 분석합니다.

현장에서 실제로 충돌하는 상황들

두 규격이 현장에서 어떻게 충돌하는지 구체적인 시나리오로 살펴봅니다.

충돌 1 SecOC와 Brake ECU 실시간 응답

ISO 26262 관점

Brake Control은 ASIL-D. 응답 지연은 Safety 위반. MAC 검증 연산이 수 ms를 추가하면 제동 성능에 영향. "보안보다 Safety가 우선이다."

ISO 21434 관점

인증 없는 CAN 메시지는 CAN Injection 공격에 무방비. 공격자가 Brake 명령을 위조할 수 있다면 Safety 자체가 무너진다. "보안 없이는 Safety도 없다."

충돌 2 Secure Boot와 부팅 시간

ISO 26262 관점

Safety Critical ECU는 빠른 부팅이 요구됩니다. 차량 시동 후 수 초 내에 Brake, Steering이 준비되어야 합니다. Secure Boot 서명 검증이 부팅 시간을 늘리면 Safety 요구사항 위반.

ISO 21434 관점

펌웨어 무결성 검증 없이 부팅하면 변조된 코드가 Safety Critical 기능을 제어할 수 있습니다. 빠른 부팅보다 신뢰할 수 있는 부팅이 먼저입니다.

충돌 3 OTA 업데이트와 Safety 검증

ISO 26262 관점

Safety Critical 소프트웨어 변경은 엄격한 V&V 프로세스를 거쳐야 합니다. OTA로 수시로 업데이트하면 Safety 검증 없이 배포될 위험이 있습니다. "업데이트 = 재검증"이 원칙.

ISO 21434 관점

취약점 패치를 빠르게 배포하지 못하면 공격에 노출된 상태가 지속됩니다. 긴 Safety 검증 주기가 보안 패치를 막는 병목이 됩니다.

충돌 4 Fail-Safe vs Security Response

ISO 26262 관점

시스템 오류 시 안전 상태(Safe State)로 전환해야 합니다. ECU가 이상 감지 시 기능을 유지하거나 Degraded Mode로 동작하는 것이 Safety 설계 원칙.

ISO 21434 관점

공격 탐지 시 즉시 기능을 차단하거나 격리하는 것이 보안 대응 원칙. 그런데 주행 중 브레이크 ECU를 차단하면 그 자체가 Safety 사고가 됩니다.

충돌의 본질은 이것입니다. Safety는 "기능이 항상 동작해야 한다(Availability)"를 요구하고, Security는 "공격 시 기능을 멈춰야 한다(Isolation)"를 요구합니다. 같은 ECU에서 두 요구가 정면으로 부딪힙니다.

왜 두 팀은 아직도 따로 움직이는가

기술적 충돌 외에 조직적 이유도 있습니다.

관점	기능 안전팀	사이버보안팀
배경	전통적 자동차 개발 조직. 10~20년 경력	상대적으로 새로 만들어진 조직. IT 보안 배경
도구	FMEA, FTA, DOORS, Medini	TARA 도구, PenTest 장비, SAST/DAST
검증 방식	결정론적 테스트, Coverage 기반	공격 시나리오 기반, 취약점 탐색
일정 감각	양산 일정 고정 — 변경 최소화	취약점 발견 시 즉각 대응 필요
성공 기준	ASIL 충족, Safety Case 완성	공격 방어, Cybersecurity Case 완성

두 팀은 같은 차량의 같은 ECU를 보지만, 서로 다른 언어로 이야기합니다. ASIL과 CAL, Fault와 Threat, Hazard와 Vulnerability. 개념 자체가 다르니 협업이 어렵습니다.

그럼에도 함께 가야 하는 이유

두 규격이 충돌하는 것처럼 보이지만, 사실 목표는 같습니다. 차량에 탑승한 사람을 안전하게 보호하는 것입니다. 다만 위협의 종류가 다를 뿐입니다.

"Safety 없는 Security"는 아무리 강한 암호화도 의미가 없습니다. 보안 기능이 Safety Critical 기능을 망가뜨리면 공격자가 원하는 결과를 보안 기능 스스로 만들어주는 것입니다.

"Security 없는 Safety"도 마찬가지입니다. ASIL-D로 설계된 Brake ECU라도 CAN Injection으로 제어권을 빼앗기면 Safety 설계 전체가 무너집니다.

실제로 ISO/SAE 21434 자체도 이 점을 인식하고 있습니다. 21434는 Safety와 Security의 상호 영향을 고려하도록 요구하며, 두 분석 결과가 서로 모순되지 않도록 검토할 것을 명시합니다.

어떻게 함께 가야 하는가 — 통합 접근 방법

1

HARA와 TARA를 같은 시점에 시작하라

두 분석을 순차적으로 하면 결과가 어긋납니다. 같은 ECU·기능을 대상으로 HARA와 TARA를 병렬로 수행하고, 서로 참조하며 모순이 없는지 확인해야 합니다. Safety Goal과 Security Goal이 같은 기능을 다르게 정의하는 상황을 초기에 발견할 수 있습니다.

2

Security가 Safety에 미치는 영향을 명시적으로 분석하라

사이버 공격이 Safety Hazard를 유발할 수 있는지 분석합니다. "CAN Injection이 Brake 오동작을 일으킬 수 있는가?" 같은 질문이 HARA에 반영되어야 합니다. 이것이 21434에서 요구하는 Safety와 Security의 상호 영향 분석입니다.

3

충돌 지점을 설계에서 해결하라 — 늦게 발견할수록 비용이 커진다

SecOC CPU 부하 문제는 HSM으로, Secure Boot 부팅 시간 문제는 병렬 검증 구조로, OTA와 Safety 검증 충돌은 Safety Critical과 Non-Critical 소프트웨어 분리로 설계 단계에서 해결합니다. 운영 단계에서 발견하면 수정 비용이 폭발합니다.

4

Security Response가 Safety에 영향을 주지 않도록 설계하라

공격 탐지 시 차단·격리 반응이 Safety Critical 기능을 멈추지 않도록 설계해야 합니다. Degraded Mode 동작, 기능 분리 구조, IDS Alert의 Safety Impact 분류가 사전에 정의되어야 합니다. "공격받아도 차는 멈추지 않아야 한다"는 원칙이 설계에 반영되어야 합니다.

5

두 팀이 같은 테이블에서 협업하라

기술적 해결만큼 조직적 협업이 중요합니다. Safety 담당자와 Security 담당자가 HARA·TARA 수행 시 함께 참여하고, 서로의 결과를 검토하는 프로세스가 있어야 합니다. 한 팀이 완성한 후 다른 팀이 검토하는 방식은 이미 늦습니다.

현장에서 자주 마주치는 오해들

흔한 오해

"Safety가 우선이니까 Security는 Safety 검토 후에 시작하면 된다" — 순차적 접근이 당연하다는 생각

실제로는

사이버 공격이 Safety Hazard를 만들 수 있음. 두 분석은 처음부터 함께 진행해야 결과가 서로 모순되지 않음

흔한 오해

"ASIL-D면 Security도 자동으로 강하다" — 높은 ASIL 등급이 보안도 보장한다는 생각

실제로는

ASIL은 무작위 고장에 대한 등급. 의도적 공격에 대한 저항성은 별개. ASIL-D ECU라도 CAN Injection에는 무방비일 수 있음

흔한 오해

"보안 기능은 Safety 기능 위에 얹으면 된다" — 기존 Safety 설계에 보안을 추가로 올리면 된다는 생각

실제로는

보안 기능이 Safety 성능에 영향을 줄 수 있음. 처음부터 Safety + Security를 함께 고려한 아키텍처 설계가 필요

흔한 오해

"두 규격은 별개라 따로 대응하면 된다" — 각각 인증 받으면 끝이라는 생각

실제로는

같은 ECU에서 두 규격이 동시에 적용됨. 충돌 지점을 해결하지 않으면 한쪽 인증을 받아도 다른 쪽에서 문제가 생김

현업에서는 실제로 이렇게 경험한다

두 팀이 같은 단어를 다르게 쓴다 — "위험(Risk)"이라는 단어 하나도 Safety팀과 Security팀이 다르게 정의합니다. Safety는 고장 확률 기반, Security는 공격 시나리오 기반. 회의에서 같은 단어로 다른 이야기를 하다가 나중에야 서로 다른 의미였다는 것을 발견하는 경우가 많습니다.

SecOC CPU 부하 협상이 가장 자주 일어나는 충돌이다 — "SecOC 넣으면 제어 주기가 늦어진다"는 Safety팀의 반대와, "인증 없으면 CAN 공격에 무방비"라는 Security팀의 주장이 충돌합니다. 결국 HSM 도입 또는 Safety Critical 메시지 우선 선별로 타협하는 경우가 많습니다.

OTA Safety 검증이 보안 패치 속도를 막는다 — 취약점이 발견돼서 빠르게 패치를 배포하고 싶은데, Safety Critical 소프트웨어 변경은 전체 Safety 재검증을 요구합니다. 이 때문에 패치 배포가 수 개월씩 지연되는 경우가 실제로 발생합니다.

공격 탐지 시 대응 방법을 설계 초기에 정하지 않으면 나중에 답이 없다 — IDS가 공격을 탐지했을 때 해당 ECU를 차단할 것인가, 알림만 보낼 것인가, Degraded Mode로 전환할 것인가. 이 결정을 양산 직전에 하려면 아키텍처 전체를 바꿔야 합니다. 초기 설계 단계에서 Safety팀과 Security팀이 함께 정해야 합니다.

두 규격을 모두 아는 사람이 드물다 — ISO 26262 전문가와 ISO 21434 전문가는 많지만, 두 규격의 상호 영향을 이해하고 통합 설계를 할 수 있는 사람은 업계에서 아직 드뭅니다. 그래서 두 팀 사이에서 조율 역할을 하는 시스템 아키텍트의 중요성이 점점 커지고 있습니다.

마무리

Safety 없는 Security는 의미가 없고,
Security 없는 Safety도 이제는 완전하지 않습니다.

두 규격은 충돌하는 것이 아니라,
서로 다른 방향에서 같은 목표를 향하고 있습니다.

SDV 시대로 갈수록 이 두 규격의 통합은 선택이 아닌 필수가 됩니다. 외부와 연결된 차량에서는 사이버 공격이 Safety Hazard를 만들 수 있고, Safety 설계 없이는 보안 대응도 제대로 할 수 없습니다.

가장 중요한 것은 초기 설계 단계에서 두 팀이 같은 테이블에 앉는 것입니다. 나중에 충돌을 발견할수록 수정 비용은 기하급수적으로 커집니다.

핵심 요약

• ISO 26262는 무작위 고장 기반 기능 안전, ISO 21434는 의도적 공격 기반 사이버보안을 다룬다
• HARA는 고장 확률 기반, TARA는 공격 시나리오 기반 — 같은 ECU를 다른 관점으로 분석한다
• 대표 충돌: SecOC CPU 부하 vs 실시간 제어, Secure Boot 부팅 시간, OTA와 Safety 검증 주기, Fail-Safe vs Security Response
• 충돌의 본질: Safety는 "항상 동작(Availability)", Security는 "공격 시 차단(Isolation)"을 요구한다
• Security 없는 Safety는 CAN Injection 한 번에 무너질 수 있다
• Safety 없는 Security는 보안 대응 자체가 Safety 사고를 만들 수 있다
• 통합 접근: HARA·TARA 병렬 수행, 상호 영향 분석, 설계 단계 충돌 해결, Security Response Safety 영향 사전 정의
• 두 규격을 모두 이해하는 시스템 아키텍트의 역할이 점점 중요해지고 있다
• 충돌은 초기 설계 단계에서 해결해야 한다 — 늦을수록 비용이 폭발한다
• SDV 시대에 Safety와 Security의 통합은 선택이 아닌 필수다

ISO26262 ISO21434 FunctionalSafety Cybersecurity HARA TARA ASIL SafetyVsSecurity 차량사이버보안 자동차규제 SDV 시스템설계