많은 사람들이 이렇게 생각합니다.
"또 규격서 하나 나왔구나. 조항 외우면 되겠지."
하지만 21434를 실제로 마주한 개발자와 관리자들의 반응은 다릅니다.
"이거… 기술 얘기가 아니잖아요?"
"왜 갑자기 조직 정책이랑 공급망 얘기가 나와요?"
"우리 개발 프로세스를 전부 바꿔야 한다는 건가요?"
맞습니다. 21434는 기술 표준이 아닙니다.
자동차 개발 방식 전체를 바꾸는 프로세스 표준입니다.
그리고 그 변화는 생각보다 훨씬 깊은 곳에서 시작됩니다.
21434는 왜 등장했는가
2015년 지프 체로키 원격 해킹 사건 이후 자동차 업계는 충격을 받았습니다. 주행 중인 차량의 브레이크가 원격으로 차단됐습니다. 문제는 기술이 없어서가 아니었습니다. 보안을 어떻게 개발 프로세스에 통합해야 하는지에 대한 공통 기준이 없었기 때문이었습니다.
OEM마다, 프로젝트마다 제각각인 보안 접근법으로는 글로벌 공급망에서 일관된 보안 수준을 만들 수 없었습니다. 그래서 ISO와 SAE가 손잡고 2021년 발행한 것이 ISO/SAE 21434입니다.
Connected Car 시대 — 무엇이 달라졌는가
21434가 왜 지금 등장했는지 이해하려면 차량이 어떻게 변해왔는지를 먼저 봐야 합니다.
21434가 바꾼 개발 흐름
21434가 개발 방식을 어떻게 바꿨는지 가장 직관적으로 보여주는 것이 개발 흐름의 변화입니다.
HSM / SecOC
PenTest
21434가 실제로 바꾼 것
이 변화를 한 문장으로 정리하면 이렇습니다. 21434는 보안을 "개발자의 선택"에서 "조직의 의무"로 바꿨습니다.
21434의 전체 구조 — Clause 맵
21434는 총 15개의 Clause로 구성됩니다. 크게 다섯 가지 영역으로 나눌 수 있습니다.
조직 보안 관리 Clause 6
프로젝트 관리
분산 개발 Clause 8
지속 활동
개념 단계 Clause 15
TARA
제품 개발 Clause 11
검증·확인
양산 Clause 13
운영·유지보수 Clause 14
폐기
ISO 26262(기능 안전)과 무엇이 다른가
자동차 업계에서 21434보다 훨씬 먼저 자리 잡은 표준이 있습니다. 기능 안전을 다루는 ISO 26262입니다. 많은 개발자들이 처음에 21434를 26262의 보안 버전으로 이해합니다. 비슷해 보이지만 본질적으로 다릅니다.
| 구분 | ISO 26262 (기능 안전) | ISO/SAE 21434 (사이버보안) |
|---|---|---|
| 다루는 위협 | 무작위 하드웨어 결함, 소프트웨어 오류 | 의도적인 외부 공격자 |
| 위협의 성격 | 예측 가능한 고장 패턴 | 끊임없이 진화하는 공격 방식 |
| 분석 방법 | FMEA, FTA, ASIL 분류 | TARA, Penetration Test |
| 완료 시점 | 개발 완료 후 대체로 고정 | "완료"가 없음 — 생애주기 내내 지속 |
| 공급망 관리 | 부품 품질 관리 중심 | 보안 요구사항 흐름·증거 수령까지 |
두 표준은 충돌하지 않습니다. 오히려 보완적입니다. 현업에서는 안전(Safety)과 보안(Security) 활동을 통합해서 진행하는 경우가 많습니다.
Work Product — 21434가 요구하는 산출물들
21434를 처음 접하면 낯선 개념이 하나 있습니다. Work Product입니다. 각 Clause가 수행해야 할 활동(Activity)과 함께 그 활동의 결과물로 남겨야 할 문서·데이터를 정의합니다. 이것이 Work Product입니다.
Work Product는 단순한 보고서가 아닙니다. 심사 기관이 "이 조직이 21434를 실제로 따르고 있는가"를 판단하는 증거입니다. 그래서 21434를 "문서 폭탄"이라고 부르는 현업자도 있습니다.
조직이 사이버보안을 어떻게 다룰 것인지 선언하는 최상위 정책 문서. 경영진 서명 필요.
프로젝트별로 어떤 보안 활동을, 언제, 누가 수행할지를 정의하는 계획서.
OEM과 공급사 간 보안 역할·책임·인터페이스를 정의하는 계약 수준의 문서.
무엇을 분석할지 정의하고, TARA 결과에서 도출된 최상위 보안 목표 문서.
시스템·ECU·SW 수준으로 내려간 구체적 보안 요구사항. Secure Boot, SecOC 같은 기술의 근거가 됩니다.
보안 목표가 실제로 달성됐음을 증명하는 최종 증거 패키지. VTA 심사의 핵심 제출물.
21434가 OEM·Tier-1·Tier-2의 역할을 어떻게 바꿨나
21434 이전에는 보안이 주로 OEM의 문제였습니다. 하지만 21434는 공급망 전체의 역할을 재정의했습니다.
"이제 자동차 공급망에서 사이버보안 역량은 중요한 경쟁력이 됐습니다." 기능만 납품하던 시대에서, 보안이 검증된 기능을 납품하고 그것을 증명하는 시대로 바뀐 것입니다.
이 시리즈는 기존 글들을 어떻게 연결하는가
이 블로그에는 이미 자동차 사이버보안의 핵심 기술과 규제를 다룬 글들이 있습니다. ISO/SAE 21434 시리즈는 새로운 내용을 쌓는 것이 아니라, 기존 글들이 21434의 어느 Clause와 연결되는지를 보여줍니다.
| R155, CSMS — 자동차는 왜 보안을 고민하게 됐을까 | Clause 5·6 조직·프로젝트 관리 |
| 공급망 보안, SBOM, PSIRT | Clause 7·8 분산 개발·지속 활동 |
| TARA 수행, TARA → Security Requirement | Clause 9·15 Concept + TARA |
| Secure Boot, HSM, SecOC, SGW, Security Access | Clause 10 제품 개발 |
| 차량 Pentest, V&V | Clause 11 검증·확인 |
| OTA 보안, 취약점 관리, PSIRT | Clause 12~14 양산·운영·폐기 |
현업에서 21434를 처음 마주했을 때 느끼는 것들
마무리 — 이 시리즈는 무엇을 다루는가
ISO/SAE 21434는 자동차 개발에 새로운 질문을 추가했습니다.
"이 기능이 동작하는가?"에서
"이 기능이 안전하게 동작하는가?"로,
그리고 "그것을 어떻게 증명할 것인가?"까지.
이 시리즈는 21434의 조항을 번역하지 않습니다. 대신 각 Clause가 현업에서 어떤 의미를 가지는지, 왜 그런 활동이 필요한지, 실제로 무엇을 만들어야 하는지를 다룹니다. 그리고 이 블로그에 이미 있는 기술 글·규제 글들이 21434의 어느 지점과 연결되는지를 보여줍니다.
핵심 요약
- 21434는 기술 표준이 아닌 프로세스 표준 — 자동차 개발 방식 전체를 바꾼다
- 보안을 개발자 선택에서 조직 의무로 바꾼 것이 21434의 핵심 철학
- 15개 Clause — 조직·프로젝트·공급망·개념·개발·검증·양산·운영·폐기까지 생애주기 전체
- 26262(기능 안전)와 다른 점 — 위협이 출시 후에도 진화하기 때문에 "완료"가 없다
- Work Product — 활동의 결과물로 남겨야 할 증거. 현업에서 가장 큰 부담
- OEM·Tier-1·Tier-2 모두 역할이 재정의됐다 — 공급망 전체의 문제
- 이 시리즈는 기존 기술·규제 글들을 21434 관점으로 연결하는 허브 역할을 한다
'차량 사이버보안 > ISO21434 실무' 카테고리의 다른 글
| 차량 보안은 왜 공급망 전체를 관리해야 할까? — Clause 7·8 (1) | 2026.05.15 |
|---|---|
| ISO 21434는 왜 개발보다 조직 관리부터 시작할까?(1편_자동차 사이버보안이 결국 “조직 싸움”이 되는 이유) (0) | 2026.05.15 |
| 자동차 사이버보안은 왜 공급망 전체를 봐야 할까? (0) | 2026.05.14 |
| TARA 결과는 실제로 어떻게 Security Requirement로 연결될까? (0) | 2026.05.12 |
| TARA는 실제로 어떻게 수행할까? (0) | 2026.05.12 |