ISO 21434는 왜 개발보다 조직 관리부터 시작할까?(1편_자동차 사이버보안이 결국 “조직 싸움”이 되는 이유)

현업에서 보는 ISO/SAE 21434 01

이전 편 | ISO/SAE 21434는 도대체 무엇을 바꿨을까? — 0편 오버뷰

ISO/SAE 21434를 처음 열어본 개발자들이 공통적으로 하는 말이 있습니다.

"왜 Clause 1~4는 그렇다 치고, Clause 5가 갑자기 조직 정책 얘기야?"

Secure Boot 구현법을 기대했는데
Policy, Role & Responsibility, Competence, PSIRT 이야기가 나옵니다.

그리고 제품 개발(Clause 10)은 한참 뒤에 나옵니다.

이것이 우연이 아닙니다.
21434는 의도적으로 조직과 프로세스를 먼저 요구합니다.
왜냐하면 자동차 사이버보안에서 가장 어려운 건 암호화 기술이 아니라,
조직과 공급망을 움직이는 것이기 때문입니다.

자동차 보안은 개발자 한 명이 해결할 수 없다

웹 서비스라면 한 회사가 대부분의 시스템을 직접 개발합니다. 하지만 자동차는 다릅니다. 차량 한 대에는 수십 개 회사의 코드가 섞이고, 수백 명의 개발자가 관여하며, 수년에 걸쳐 프로젝트가 진행됩니다.

자동차 개발 구조 — 수많은 조직이 연결된다

OEM

차량 전체
아키텍처

→

TIER-1

ECU
개발

→

TIER-2

SW 모듈
공급

→

MCU Vendor

HSM
Secure Boot

→

OSS

OpenSSL
Linux

이 구조에서는 뛰어난 보안 엔지니어 한 명이 Secure Boot를 완벽하게 구현해도 충분하지 않습니다. 그 엔지니어가 퇴사하면 어떻게 될까요? 공급사가 납품한 ECU에도 같은 수준의 보안이 적용됐는지 누가 확인할까요?

개인의 역량으로 만든 보안은 그 개인이 없어지면 사라집니다.
역할, 책임, 공급망, 프로세스, 증거 관리가 함께 움직여야 조직 보안이 됩니다.

21434 Clause 5의 핵심 철학은 이것입니다. "보안을 우연히 잘하는 회사"가 아니라 "보안을 지속적으로 관리할 수 있는 회사"를 만들어라.

Clause 5 — 조직 차원의 보안 체계를 세워라

Clause 5는 프로젝트마다 즉흥적으로 대응하지 말고, 회사 차원에서 사이버보안을 관리하는 체계를 갖추라는 요구입니다.

Clause 5 Organizational Cybersecurity Management 조직 수준 보안 관리

Cybersecurity Policy

조직이 사이버보안을 어떻게 다룰 것인지 선언하는 최상위 정책. 경영진이 서명하고 전사에 공표해야 합니다. 프로젝트마다 기준이 달라지는 문제를 방지하는 기반 문서입니다.

역할·책임·권한 정의

누가 TARA를 수행하고, 누가 승인하는지 명확히 정의합니다. "보안은 보안팀이 알아서"가 아니라 개발·QA·구매·경영진 모두의 역할이 정의됩니다.

역량 관리 (Competence)

보안 활동을 수행하는 인력이 필요한 역량을 갖추고 있는지 확인하고 관리합니다. 교육 이력, 자격 기록이 Work Product로 남습니다.

도구 관리 (Tool)

보안 활동에 사용하는 도구(TARA 도구, Fuzzing 도구 등)가 신뢰할 수 있는지 확인하는 절차가 필요합니다. 도구 오류가 보안 분석 결과를 왜곡할 수 있기 때문입니다.

공급망 보안 관리

공급사가 보안 요구사항을 충족하는지 관리하는 프로세스. 공급사 선정 기준, 보안 요건 전달, 이행 확인, 감사 절차가 포함됩니다.

PSIRT 운영

보안 취약점이 보고됐을 때 대응하는 전담 조직(Product Security Incident Response Team). CVE 접수, 심각도 평가, 패치 배포, 외부 공개 절차가 정의되어야 합니다.

Clause 5에서 가장 많이 지적되는 부분이 PSIRT입니다. "우리 회사에 PSIRT가 없습니다"가 문제가 아닙니다. 취약점이 보고됐을 때 어떻게 처리하는지 절차가 정의되어 있어야 합니다. 소규모 조직이라도 절차는 반드시 있어야 합니다.

Clause 6 — 프로젝트마다 보안을 계획하고 계약하라

Clause 5가 "회사 체계"라면, Clause 6은 "이번 프로젝트에서 실제로 어떻게 운영할 것인가"에 해당합니다.

Clause 6 Project Dependent Cybersecurity Management 프로젝트 수준 보안 관리

Cybersecurity Plan

이 프로젝트에서 어떤 보안 활동을, 언제, 누가, 어떤 방법으로 수행할지 계획하는 문서. TARA 일정, V&V 계획, Pentest 계획이 포함됩니다. 프로젝트 보안 활동의 중심 문서 역할을 합니다.

Tailoring

21434의 모든 활동을 모든 프로젝트에 동일하게 적용할 필요는 없습니다. Tailoring은 이 프로젝트의 특성에 맞게 활동 범위를 조정하는 것입니다. 단, 조정 근거가 반드시 문서화되어야 합니다.

Cybersecurity Interface Agreement (CIA)

OEM과 Tier-1, Tier-1과 Tier-2 간의 보안 역할·책임·인터페이스를 정의하는 문서. "누가 어떤 TARA를 수행하고, 어떤 증거를 제출하는가"를 계약 수준에서 합의합니다.

Cybersecurity Case

최종적으로 "우리는 충분한 보안 활동을 수행했다"는 근거를 정리한 문서. VTA 심사의 핵심 산출물입니다.

Cybersecurity Monitoring

프로젝트 진행 중 보안 활동이 계획대로 이루어지고 있는지 모니터링합니다. 이슈 발생 시 에스컬레이션 경로도 정의되어야 합니다.

CIA — 공급망 보안 역할 계약의 핵심

Clause 6에서 현업 실무자들이 가장 많이 마주치는 개념이 CIA(Distributed cybersecurity Activities, 또는 Cybersecurity Interface Agreement)입니다.

차량 보안 활동은 OEM 혼자 할 수 없습니다. TARA의 일부는 Tier-1이, Tier-1의 일부는 Tier-2가 수행합니다. 이 역할 분배가 계약으로 명확히 정의되지 않으면 책임 공백이 생깁니다.

CIA — 역할 분배 예시

OEM

차량 수준 TARA 수행, 사이버보안 목표 정의, Tier-1 보안 요구사항 전달, VTA 최종 책임, 공급사 CIA 수령·검토

Tier-1

OEM 요구사항 수령, ECU 단위 TARA 수행, 보안 기능 구현·V&V, OEM에 증거 제출, Tier-2 CIA 체결·관리

Tier-2

Tier-1 요구사항 수령, SW 보안성 입증, SBOM 제공, CVE 발생 시 Tier-1 통보

CIA가 없으면 어떤 일이 생길까요? Tier-2 소프트웨어에서 취약점이 발견됐을 때 Tier-1이 몰랐다고 하고, Tier-1의 ECU 취약점이 발견됐을 때 OEM이 몰랐다고 합니다. 책임 소재가 불분명해지고 대응이 늦어집니다. CIA는 이 상황을 방지하는 계약 문서입니다.

자동차 보안은 결국 공급망 관리다

Clause 5와 6에서 가장 중요한 부분 중 하나가 공급망 관리입니다. 실제 차량 소프트웨어는 OEM 혼자도, Tier-1 혼자도 만들 수 없기 때문입니다. 21434 이전과 이후 공급망 관리 방식은 크게 달라집니다.

21434 이전 공급망

기능 동작 중심 납품

보안 요구사항 불명확

취약점 대응 책임 모호

오픈소스 관리 부족

출시 후 대응 체계 없음

21434 이후

보안 요구사항 계약 반영

SBOM 관리 요구

취약점 통보 체계 요구

공급사 Audit 수행

PSIRT 운영 연결

실제 프로젝트에서는 기술 구현보다 공급망 조율이 더 어려운 경우가 많습니다. 특히 여러 OEM에 동시에 ECU를 납품하는 Tier-1은 OEM마다 다른 보안 요구사항 형식을 맞춰야 하는 현실적인 어려움이 있습니다.

PSIRT — 출시 후 보안의 핵심

PSIRT(Product Security Incident Response Team)는 차량 출시 후 보안 취약점이 발견됐을 때 대응하는 전담 조직 또는 프로세스입니다.

과거 자동차 산업에서는 "차량 출시 = 프로젝트 종료"에 가까웠습니다. 하지만 SDV 시대에는 새 CVE 발생, 오픈소스 취약점 공개, 원격 공격 가능성 발견, OTA 보안 업데이트 필요 같은 일들이 지속적으로 발생합니다.

PSIRT 취약점 대응 흐름

취약점 접수
CVE/제보/자체발견

→

심각도 평가
영향 차종·위험도

→

대응 방향 결정
패치/완화/허용

→

패치 개발·검증
OTA 또는 리콜

→

배포 및 추적
영향 차량 확인

→

종료·기록
Work Product

차량은 이제 "출시 후에도 계속 관리되는 소프트웨어 시스템"이 되었습니다. PSIRT는 그 변화를 상징하는 대표적인 조직입니다. PSIRT는 IT 기업에서 오래전부터 운영해온 개념이지만, 자동차 업계에서는 R155와 21434 이후에야 본격적으로 논의되기 시작했습니다.

왜 자동차 사이버보안이 "조직 싸움"이 되는가

실제 현장에서 자동차 사이버보안이 실패하는 이유를 보면 기술 문제보다 조직 문제가 훨씬 많습니다.

흔한 실패 패턴

"보안은 보안팀이 알아서 한다" — 개발팀은 기능만, 보안팀은 뒤에서 검토만 하는 구조

21434가 요구하는 것

역할·책임 정의로 개발팀도 보안 활동의 주체가 됨. 보안팀은 관리·지원 역할.

흔한 실패 패턴

"이 ECU 보안은 Tier-1이 알아서 한다" — 공급망 보안 가시성 없음, 책임 불명확

21434가 요구하는 것

CIA로 OEM-Tier-1-Tier-2 역할 명확히 계약. 누락되는 활동 없음.

흔한 실패 패턴

"출시했으니 끝이다" — 출시 후 취약점 대응 체계 없음, CVE 발견 시 혼란

21434가 요구하는 것

PSIRT로 출시 후 대응 프로세스 사전 정의. Cybersecurity Policy에 포함.

흔한 실패 패턴

"담당자가 퇴사하면 아무도 모른다" — 개인 역량 의존, 지식 이전 없음

21434가 요구하는 것

역량 관리·교육 체계로 조직 역량 축적. Competence Record로 증거 관리.

21434가 조직을 먼저 다루는 이유를 한 문장으로 정리하면 이렇습니다. 기술은 조직이 뒷받침되지 않으면 지속되지 않기 때문입니다. Secure Boot를 구현했지만 관리하는 조직이 없으면, 키가 만료되도 아무도 모르고, 취약점이 생겨도 대응하지 못합니다.

Clause 5·6의 주요 Work Product

Clause	Work Product	핵심 내용
5	Cybersecurity Policy	조직 전체 보안 정책 선언. 경영진 서명. 주기적 검토 필요.
5	Organizational Cybersecurity Rules	보안 활동 수행 기준·절차 정의. Policy를 실무로 구체화.
5	Competence Record	인력별 보안 역량·교육 이력. 누가 어떤 활동을 수행할 자격이 있는지.
5	Tool Qualification Evidence	보안 도구 신뢰성 근거. 도구 오류가 결과를 왜곡하지 않음을 증명.
6	Cybersecurity Plan	프로젝트별 보안 활동 계획. 일정·담당자·방법론 포함. 프로젝트 보안의 중심 문서.
6	CIA (Cybersecurity Interface Agreement)	OEM-공급사 간 보안 역할 계약 문서. 책임 공백 방지.
6	Tailoring Decision	활동 범위 조정 근거. 왜 특정 활동을 생략하거나 축소했는지 문서화.
6	Cybersecurity Case	"충분한 보안 활동을 수행했다"는 최종 근거 정리. VTA 심사의 핵심 산출물.

Work Product를 "문서 폭탄"으로 보기보다 다르게 생각해보면 좋습니다. 이 문서들은 결국 "우리가 보안 활동을 제대로 했다"는 증거입니다. VTA 심사에서 이 증거가 없으면 아무리 기술적으로 잘 만들어도 인정받기 어렵습니다.

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

보안 담당자는 있는데 책임자는 없는 경우 — TARA 수행은 했지만 최종 승인 책임이 명확하지 않은 프로젝트들이 존재합니다. Clause 5는 이런 상황을 막기 위해 역할·책임 정의를 매우 중요하게 봅니다. 서류상 Policy와 실제 운영이 다르면 심사에서 반드시 지적됩니다.

CIA 협상이 프로젝트 초기 가장 중요한 활동 중 하나다 — Tier-1 입장에서 범위를 너무 많이 맡으면 비용과 공수가 폭발하고, 너무 적게 맡으면 OEM이 승인을 거부합니다. OEM마다 요구하는 형식과 범위도 달라서, 프로젝트마다 대응 방식이 달라지는 문제가 생깁니다.

Tailoring은 축소가 아니라 설명이다 — "이 프로젝트는 규모가 작으니 TARA를 간단히 하겠다"고 Tailoring을 쓰면 심사에서 통과하기 어렵습니다. 왜 이 활동이 이 프로젝트에서 불필요한지를 논리적으로 설명해야 합니다.

공급망 아래로 갈수록 보안 역량 차이가 커진다 — Tier-2·Tier-3 중에는 보안 전담 조직 자체가 없는 경우도 있습니다. 공급망 전체를 같은 수준으로 끌어올리는 것이 현실적으로 가장 어려운 과제 중 하나입니다.

결국 Traceability 관리 싸움이 된다 — 요구사항 하나가 어디서 나왔고 어떤 테스트로 검증됐는지 끝까지 연결돼야 합니다. 실제 프로젝트에서는 이 추적성 관리 공수가 상당하며, PSIRT 운영도 절차 정의보다 실제로 움직이는 훈련이 더 어렵습니다.

마무리

21434가 조직 관리부터 시작하는 이유는 간단합니다.
보안 기술은 조직 구조 위에서만 제대로 동작하기 때문입니다.
자동차 사이버보안은 결국 조직이 얼마나 체계적으로 운영되는가의 싸움입니다.

그리고 SDV 시대로 갈수록 이 흐름은 더 강해질 것입니다. 차량은 출시 후에도 계속 업데이트되고, 취약점이 발견되며, 새로운 공격이 등장하기 때문입니다.

다음 편에서는 Clause 7·8, 즉 분산 개발과 지속 활동을 다룹니다. 공급망 전체에 걸친 보안 관리와 차량 출시 이후에도 계속되는 보안 활동이 주제입니다.

핵심 요약

• 자동차 보안은 단일 개발자가 해결할 수 없는 공급망 구조 문제다
• 21434가 조직을 먼저 다루는 이유 — 개인 역량이 아닌 조직 체계로 보안을 관리해야 지속되기 때문
• Clause 5는 조직 전체의 보안 정책·역할·역량·공급망·PSIRT를 다룬다
• Clause 6는 프로젝트별 보안 계획, 역할 계약(CIA), 활동 조정(Tailoring), Cybersecurity Case를 다룬다
• CIA는 OEM-Tier-1-Tier-2 간 보안 역할과 책임의 공백을 방지하는 계약 문서다
• PSIRT는 출시 후 취약점 대응을 위한 조직·프로세스 — 절차 정의가 핵심
• Tailoring은 활동 축소가 아니라 조정 근거의 문서화다
• 현업에서는 기술보다 공급망 조율과 Traceability 관리가 더 어려운 경우가 많다

📚 현업에서 보는 ISO/SAE 21434 — 시리즈

0

ISO/SAE 21434는 도대체 무엇을 바꿨을까? — 오버뷰

1

ISO 21434는 왜 개발보다 조직 관리부터 시작할까?  ← 현재 글

2

차량 보안은 왜 공급망 전체를 관리해야 할까? — Clause 7·8

3

Concept Phase에서는 무엇을 정의할까? — Clause 9

4

보안 요구사항은 어떻게 ECU 설계가 될까? — Clause 10

5

차량 보안 검증은 무엇을 증명해야 할까? — Clause 11

6

양산 이후 차량 보안은 어떻게 유지될까? — Clause 12~14

ISO21434 Clause5 Clause6 CSMS PSIRT CIA 차량사이버보안 조직보안관리 WorkProduct 공급망보안 Traceability 자동차규제