ISO/SAE 21434는 왜 자동차 개발 프로세스를 바꿨을까?

자동차 사이버보안 규제 이야기 04

이전 편 | CSMS는 실제로 무엇을 관리할까 — 현업 관점에서 본 사이버보안 관리 체계

앞선 글들에서 R155와 CSMS를 이야기했습니다.
"무엇을 해야 하는가"는 이제 어느 정도 그림이 그려졌을 겁니다.

그런데 실제 개발 현장에서 더 자주 등장하는 질문은 이겁니다.
"그래서 개발 프로세스를 어떻게 바꿔야 하는데?"

ISO/SAE 21434가 바로 그 질문에 답하는 표준입니다.
규제가 목적지를 제시했다면, 21434는 거기까지 가는 지도입니다.

오늘은 이 표준이 자동차 개발 방식을 어떻게, 그리고 왜 바꿨는지를 이야기합니다.

21434가 등장하기 전 — 개발 현장은 어땠나

ISO/SAE 21434가 2021년에 발행되기 전, 자동차 사이버보안 개발에는 공통된 기준이 없었습니다. 회사마다, 프로젝트마다 접근 방식이 달랐습니다.

21434 이전

보안은 개발 완료 후 "추가"하는 것

위협 분석 방법이 회사마다 다름

보안 요구사항이 명확히 정의되지 않음

공급사에 보안 요건 전달 기준 없음

보안 검증 범위와 방법이 제각각

출시 후 취약점 대응 절차 없음

21434 이후

보안은 설계 시작 단계부터 반영

TARA 방법론으로 표준화

사이버보안 목표·요구사항 추적 관리

공급사 보안 요건 계약·관리 기준 제시

V&V 활동 범위와 증거 기준 정의

취약점 모니터링·대응 프로세스 포함

21434가 등장하기 전에도 보안을 잘 하는 회사는 있었습니다. 하지만 "잘 한다"의 기준이 달랐습니다. 21434는 그 기준을 업계 전체가 공유하는 공통 언어로 만든 것입니다.

ISO/SAE 21434 — 규정이 아니라 방법론이다

이미 앞선 글에서 짚었지만 다시 한번 명확히 합니다. ISO/SAE 21434는 법적 규정이 아닙니다. 지키지 않아도 당장 벌칙이 없습니다.

그런데도 사실상 필수가 된 이유는 하나입니다. R155(규정)를 충족하려면 체계적인 방법론이 필요하고, 그 방법론으로 업계가 21434를 선택했기 때문입니다. 인증기관도, OEM도, Tier-1도 모두 21434를 공통 언어로 씁니다.

ISO는 국제표준화기구, SAE는 미국 자동차공학회입니다. 두 기관이 공동으로 발행한 이유는 사이버보안이 자동차 도메인(SAE)과 정보보안 도메인(ISO) 양쪽 전문성을 모두 필요로 하기 때문입니다. 2021년 정식 발행됐습니다.

이 시리즈를 따라오셨다면 R155, CSMS, 21434가 자꾸 함께 등장해서 헷갈릴 수 있습니다. 세 개념의 역할을 한 번에 정리하면 이렇습니다.

개념	성격	핵심 질문
UN R155	법적 규정	"사이버보안을 관리하고 있는가?"
CSMS	운영 체계	"어떤 체계로 관리하는가?"
ISO/SAE 21434	개발 방법론	"개발 과정에서 어떻게 실행하는가?"

21434가 개발 방식을 바꾼 세 가지 핵심

1. 보안을 "나중"에서 "처음"으로 — Shift Left Security

과거 개발 방식에서 보안은 대부분 후처리였습니다. 기능 개발이 끝나고 나서 "보안 검토"를 하는 식이었습니다. 이미 설계가 굳어진 상태에서 보안 문제를 발견하면 수정 비용이 엄청납니다.

IT 업계에서는 이 문제를 오래전부터 인식하고 Shift Left Security라는 개념으로 대응해왔습니다. 보안 활동을 개발 타임라인의 왼쪽, 즉 초기 단계로 당긴다는 의미입니다. 21434는 이 개념을 자동차 개발 프로세스에 공식적으로 정착시킨 표준입니다.

개념 설계 단계에서부터 TARA를 수행하고, 그 결과를 기반으로 보안 목표를 세우고, 그 목표가 설계와 구현에 반영됩니다. Security by Design이 구호가 아닌 프로세스로 자리 잡습니다.

2. 위협 분석을 표준화 — TARA

21434에서 가장 핵심적인 활동은 TARA(Threat Analysis and Risk Assessment, 위협 분석 및 위험 평가)입니다.

TARA 수행 흐름

1

자산 식별 (Asset Identification) 보호해야 할 대상을 정의합니다. 엔진 제어 데이터, 브레이크 제어 신호, 개인정보, 펌웨어 등 가치 있는 자산을 목록화합니다.

↓

2

위협 시나리오 도출 (Threat Scenario) 각 자산에 대해 어떤 공격이 가능한지 시나리오를 작성합니다. "공격자가 OBD-II 포트를 통해 브레이크 ECU에 악성 메시지를 주입한다" 같은 형태입니다.

↓

3

영향 평가 (Impact Rating) 공격이 성공했을 때 안전(Safety), 재정(Financial), 운영(Operational), 개인정보(Privacy) 측면에서 얼마나 심각한지 평가합니다. 21434는 이 네 가지 범주를 기준으로 씁니다.

↓

4

공격 가능성 평가 (Attack Feasibility) 공격자가 실제로 이 공격을 수행하기 얼마나 어려운지를 평가합니다. 필요한 전문 지식, 장비, 시간, 접근 기회 등을 고려합니다.

↓

5

위험도 산정 (Risk Determination) 영향과 공격 가능성을 조합해 위험도(Risk Level)를 결정합니다. 위험도에 따라 "허용", "경감", "회피", "전가" 중 하나를 선택합니다.

↓

6

사이버보안 목표 및 요구사항 도출 위험 경감이 필요한 항목에 대해 "무엇을 보호해야 하는가(목표)"와 "어떻게 보호할 것인가(요구사항)"를 정의합니다. 이후 설계와 구현의 근거가 됩니다.

TARA의 핵심 가치는 보안 결정에 근거를 만드는 것입니다. "Secure Boot를 왜 적용했는가"라는 질문에 "다들 하니까"가 아니라 "TARA에서 이 위협의 위험도가 높게 평가됐기 때문에"라고 답할 수 있게 됩니다. 모든 보안 결정이 문서로 추적됩니다.

3. 개발 전 과정에 보안 활동을 통합

21434는 개념 설계부터 폐기까지 각 단계마다 수행해야 할 사이버보안 활동을 정의합니다. 기존의 V-모델 개발 프로세스에 보안 레이어가 씌워지는 구조입니다.

개발 단계별 21434 사이버보안 활동

개념 설계

→

TARA 수행
보안 목표 정의

시스템 설계

→

사이버보안
요구사항 도출

HW/SW 설계

→

보안 설계 리뷰
Secure Coding

구현

→

코드 보안 분석
취약점 스캐닝

통합 및 검증

→

Penetration Test
Fuzzing·V&V

양산·운영

→

취약점 모니터링
인시던트 대응

ISO 26262와 21434 — 안전과 보안은 다르다

자동차 업계에서 21434보다 훨씬 먼저 자리 잡은 표준이 있습니다. 바로 기능 안전을 다루는 ISO 26262입니다. 많은 개발자들이 처음에 21434를 26262의 보안 버전으로 이해합니다. 비슷해 보이지만 본질적으로 다릅니다.

구분	ISO 26262 (기능 안전)	ISO/SAE 21434 (사이버보안)
다루는 위협	무작위 하드웨어 결함, 소프트웨어 오류	의도적인 외부 공격
위협의 성격	예측 가능한 고장 패턴	끊임없이 진화하는 공격 방식
대응 시점	개발 완료 후 고정	차량 생애주기 내내 지속
핵심 활동	FMEA, FTA, ASIL 분류	TARA, Penetration Test
출시 후 관리	변경 없으면 재분석 불필요	새 취약점 발견 시 재검토 필요

가장 중요한 차이는 "위협이 변하는가"입니다. 하드웨어 결함은 차량 출시 이후 새로운 고장 패턴이 갑자기 생기지 않습니다. 하지만 사이버 공격은 차량이 출시된 이후에도 새로운 공격 기법이 계속 등장합니다. 그래서 21434는 "완료"가 없는 표준입니다.

두 표준은 충돌하지 않습니다. 오히려 보완적입니다. 안전(Safety)과 보안(Security) 모두 결과적으로 "차량이 의도대로 동작하는가"를 추구합니다. 실무에서는 두 표준의 활동을 통합해서 진행하는 경우가 많습니다.

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

TARA가 제일 어렵다 — 21434에서 현업 개발자들이 가장 어려워하는 부분이 TARA입니다. 자산을 어느 수준까지 정의할지, 위협 시나리오를 얼마나 세분화할지, 위험도를 어떻게 정량화할지에 대한 감을 잡는 데 시간이 걸립니다. OEM마다 요구하는 TARA의 깊이도 달라 경험이 쌓여야 노하우가 생깁니다.

26262를 먼저 경험한 개발자가 유리하다 — 21434의 프로세스 구조(요구사항 → 설계 → 구현 → 검증 → 추적성)는 26262와 유사합니다. 26262에 익숙한 개발자라면 21434의 흐름을 이해하는 데 시간이 덜 걸립니다. 다만 "위협이 진화한다"는 사이버보안의 본질적 차이를 인식하는 것이 중요합니다.

추적성(Traceability) 관리가 생각보다 큰 일이다 — 21434는 TARA의 위협 시나리오가 보안 요구사항으로, 보안 요구사항이 설계로, 설계가 구현으로, 구현이 검증으로 이어지는 추적성을 요구합니다. 이걸 문서로 관리하는 것이 실무에서 상당한 공수를 차지합니다. 전용 도구(예: DOORS, Polarion)를 쓰는 이유입니다.

표준이 "어떻게"를 모두 정해주지는 않는다 — 21434는 "무엇을 해야 하는가"의 범위까지는 잘 정의하지만, "어떻게 구체적으로 수행하는가"는 조직이 결정해야 합니다. 예를 들어 TARA 방법론도 STRIDE, EVITA, HEAVENS 등 여러 접근법이 있고 표준은 특정 방법을 강제하지 않습니다. 이 자유도가 처음에는 오히려 혼란을 주기도 합니다.

마무리

ISO/SAE 21434는 자동차 개발 방식에 새로운 질문을 추가했습니다.
"이 기능이 동작하는가?"에서 "이 기능이 안전하게 동작하는가?"로.

이 질문 하나가 개발 프로세스의 시작점을 바꿨습니다. 보안이 마지막 관문이 아니라 설계의 출발점이 됐고, 위협 분석이 개발자의 선택이 아닌 표준 프로세스가 됐습니다.

21434가 완벽한 표준은 아닙니다. 해석의 여지가 많고, 적용 방식이 회사마다 다릅니다. 하지만 자동차 업계가 처음으로 사이버보안을 개발 방법론의 수준에서 다루기 시작했다는 것 자체가 큰 변화입니다.

핵심 요약

• ISO/SAE 21434는 법적 규정이 아닌 기술 표준 — R155를 충족하는 방법론으로 사실상 필수화됐다
• 가장 큰 변화는 보안을 "나중"에서 "처음"으로 — Security by Design이 프로세스가 됐다
• TARA는 21434의 핵심 — 자산 식별부터 위험도 산정까지 6단계로 표준화됐다
• 모든 보안 결정은 TARA에서 시작해 설계·구현·검증까지 추적성이 유지돼야 한다
• ISO 26262(기능 안전)와 다른 점 — 위협이 출시 후에도 계속 진화하기 때문에 "완료"가 없다
• 표준이 "무엇을"은 정의하지만 "어떻게"는 조직이 결정해야 한다

이 시리즈

1

자동차는 언제부터 '보안'을 고민하게 됐을까?

2

UNECE R155 쉽게 이해하기 — 도대체 뭘 요구하는 규정인가

3

CSMS는 실제로 무엇을 관리할까 — 현업 관점에서 본 사이버보안 관리 체계

4

ISO/SAE 21434는 왜 자동차 개발 프로세스를 바꿨을까  ← 현재 글

ISO21434 SAEJ3061 TARA 차량사이버보안 UNECE_R155 SecuritybyDesign 자동차보안개발 ISO26262 펜테스트 보안요구사항 자동차규제