왜 차량 사이버보안은 결국 “문서 싸움”이 될까?— Secure Boot보다 더 중요한 건 “설명할 수 있는가”다

현업에서 보는 차량 보안 트렌드

자동차 사이버보안 프로젝트를 처음 경험한 개발자들이 가장 당황하는 순간이 있습니다.

Secure Boot도 넣었고, HSM도 적용했고, TARA도 했고, Pentest도 끝났습니다. 그런데 갑자기 이런 요청이 쏟아집니다.

OEM / AUDIT에서 실제로 오는 질문들

"근거 문서 있나요?"

"Traceability 보여주세요."

"Work Product 업데이트됐나요?"

"이 Requirement가 어떤 Test로 검증됐죠?"

"변경 영향 분석 결과 제출해주세요."

"Residual Risk 허용 근거는요?"

"공급망 Evidence는 어디 있나요?"

"이 Risk는 누가 Accept했나요?"

그리고 어느 순간 깨닫게 됩니다.

차량 사이버보안은 단순히 "보안 기능을 넣는 것"으로 끝나지 않습니다.

그 기능이 왜 필요한지, 어떻게 검증했는지,
변경 이후에도 왜 안전한지까지 설명할 수 있어야 합니다.

그래서 현업에서 이런 말이 나옵니다. "결국 자동차 보안은 문서 싸움이다."

왜 이런 말이 나오는지, 그리고 OEM들이 점점 더 기술보다 설명 가능성을 중요하게 보기 시작한 이유를 이야기해봅니다.

---

OEM이 묻는 질문이 바뀌었다

과거 자동차 개발에서는 기능 동작, 성능, 내구성이 전부였습니다. "잘 동작하면 된다"에 가까웠습니다.

하지만 차량이 네트워크에 연결되고, OTA가 들어가고, 클라우드·앱과 통신하고, 원격 진단이 가능해지면서 OEM이 던지는 질문이 완전히 달라졌습니다.

BEFORE — 예전 질문

"기능 동작하나요?"

기능 구현 여부
성능 수치
내구성 테스트 결과

NOW — 지금 질문

"왜 안전하다고 판단했나요?"

판단 근거
분석 과정
Traceability
검증 기록
변경 이력

이 질문의 변화가 자동차 보안이 문서 중심이 된 이유의 출발점입니다.

---

Secure Boot 넣었다고 끝이 아니다

개발팀이 "Secure Boot 적용했습니다"라고 말합니다. OEM 보안팀은 여기서 끝내지 않습니다.

Secure Boot 하나에 이어지는 실제 질문들

어떤 Threat 시나리오에 대응하는 건가요?

어떤 Asset을 보호하는 건가요?

공개키는 어디에 저장되나요?

HSM을 사용하나요?

Key Provisioning은 어떻게 하나요?

Anti-Rollback은 고려했나요?

어떤 Test Case로 검증했나요?

Bootloader 변경 시 영향 분석은요?

⚠️ 기능 자체보다 "왜 그 구현이 충분하다고 판단했는가"를 설명할 수 있어야 합니다.

차량 사이버보안은 기술 구현만으로는 부족합니다. 설명 가능성(Explainability)까지 요구됩니다.

---

그래서 ISO 21434는 Work Product를 강조한다

ISO 21434를 읽다 보면 계속 등장하는 단어가 있습니다. Work Product입니다.

단순한 문서가 아닙니다. "왜 그렇게 판단했는가"를 추적 가능하게 만드는 근거 자산입니다.

🎯

TARA 결과어떤 위협을 어떻게 분석했는지

📌

Cybersecurity Goal무엇을 보호하기로 결정했는지

📋

Cybersecurity Requirement어떤 기술 요구사항으로 분해했는지

🧪

Verification / Validation Result어떻게 검증했고 결과는 무엇인지

🔄

Impact Analysis변경 시 어디까지 영향이 가는지

⚖️

Residual Risk Assessment남은 Risk를 왜 허용하기로 했는지

ISO 21434가 Work Product를 강조하는 이유:
OEM은 "보안을 했다"는 말보다, "왜 그렇게 판단했는가"를 증명할 수 있어야 하기 때문입니다. Work Product는 그 증명의 재료입니다.

---

Traceability — 연결이 끊어지면 설명이 안 된다

자동차 보안에서 가장 중요해지는 개념이 Traceability입니다. 보안 활동의 각 단계가 서로 연결되어 있어야 합니다.

CYBERSECURITY TRACEABILITY CHAIN

TARA

Threat
식별

↔

GOAL

보안
목표

↔

REQUIREMENT

기술
요구사항

↔

ARCHITECTURE

설계
반영

↔

TEST CASE

검증
케이스

↔

EVIDENCE

결과
근거

이 연결이 끊어지면 어떤 변경이 어떤 Risk에 영향을 주는지 설명할 수 없습니다. OTA 업데이트 하나, CAN Signal 변경 하나가 어떤 Threat와 연결되는지 추적이 안 되는 겁니다.

Traceability가 없으면 변경할 때마다 처음부터 전부 다시 해야 합니다.
반대로 Traceability가 살아있으면 "이번 변경이 어디까지 영향 주는가"를 빠르게 설명할 수 있습니다.

---

OEM Audit에서 실제로 중요하게 보는 것

OEM Audit이나 Review에서 단순히 "SecOC 적용 완료", "Secure Boot 구현"만 확인하는 경우는 드뭅니다.

OEM이 실제로 보는 항목	왜 중요한가
Threat ↔ Requirement 연결	왜 이 기능이 필요한지 설명 가능해야 함
Requirement ↔ Test Traceability	검증 누락 여부 확인, 재시험 범위 판단
변경 영향 분석 이력	양산 이후 변경 대응 능력 확인
Residual Risk 허용 근거	남은 Risk를 왜 감수하기로 했는지 설명
공급망 Evidence	Tier-1·Tier-2 보안 관리 추적 가능 여부
Work Product 최신성	현재 ECU 상태와 문서가 일치하는지 확인

즉 OEM들은 "보안 기능이 있는가"에서 "보안을 체계적으로 관리하고 있는가"로 시선을 옮기기 시작했습니다.

---

왜 이렇게까지 해야 할까 — 결국 책임의 문제

UNECE R155 이후 OEM은 "보안 고려했습니다"가 아니라 "보안을 체계적으로 관리했습니다"를 증명해야 합니다.

사고 발생 시 어떤 판단을 했는지, 어떤 Risk를 허용했는지, 어떤 검증을 했는지 추적 가능해야 합니다. 이건 기술 문제가 아니라 책임(Responsibility)의 문제입니다.

✅ 문서와 Traceability는 결국 "책임의 흔적"입니다.

보안 사고가 발생했을 때 "우리는 이런 위협을 분석했고, 이렇게 판단했고, 이렇게 검증했다"를 보여줄 수 있어야 합니다.

---

IT 보안과 다른 이유

IT 업계는 빠른 패치가 핵심입니다. 문제 발생하면 패치 배포하면 됩니다.

자동차는 다릅니다.

🖥️ IT 보안

• 빠른 패치 배포가 핵심
• 사후 대응 중심
• 릴리즈 주기 짧음
• 형식승인 없음
• 단일 제품 중심

🚗 자동차 보안

• Safety 영향 고려 필수
• 형식승인 (Type Approval)
• 수년 ~ 수십 년 운영
• 공급망 전체 책임
• 사전 설명 가능성 요구

자동차는 "왜 안전한지 설명 가능해야 하는 산업"입니다. 그래서 기술만으로 끝나지 않고, 문서와 프로세스 비중이 훨씬 커집니다.

---

양산 이후가 더 어렵다

과거에는 차량 출시 후 변경이 거의 없었습니다. 지금은 OTA, Feature Update, CVE 대응, Variant 변경이 계속 발생합니다.

변경이 생길 때마다 문서와 Traceability가 살아있어야 합니다. 어떤 변경이 어떤 Threat와 연결되는지 추적이 안 되면, 변경할 때마다 보안 전체를 처음부터 다시 검토해야 하는 상황이 됩니다.

SDV 시대일수록 이 문제는 더 커집니다. 차량이 "계속 변경되는 소프트웨어 플랫폼"이 될수록, Change Impact Analysis와 Continuous Validation의 기반인 Traceability 중요성은 계속 커집니다.

---

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

현업 경험 4가지

프로젝트 후반엔 문서 작업 비중이 폭증한다 — 초기에는 구현 중심이지만, SOP 근처로 갈수록 Traceability 정리, Evidence 취합, Review 대응, Audit 준비 공수가 급격히 증가합니다. "보안 기능 만드는 것보다 설명하는 게 더 힘들다"는 말이 나오는 이유입니다.

OEM마다 요구하는 Work Product 형식이 다르다 — 같은 TARA라도 OEM별 Template, Evidence 수준, Review 기준이 달라 Tier-1 부담이 커집니다. 여러 OEM에 동시 납품하는 경우 이 비용이 배로 늘어납니다.

결국 Requirement 관리 툴이 중요해진다 — Excel 기반 관리만으로는 변경 추적과 Traceability 유지가 어려워집니다. ALM(Application Lifecycle Management) 툴 도입이 늘어나는 이유입니다.

Residual Risk 허용 근거와 변경 영향 분석이 가장 어렵다 — 구현 자체보다 "왜 이 Risk를 허용하기로 했는가", "이 변경이 어디까지 영향 주는가"를 설명하는 게 경험 많은 엔지니어도 어려워하는 영역입니다.

---

마무리

자동차 사이버보안은
"보안 기능을 넣는 산업"이 아니라,
"왜 안전하다고 판단했는지 설명해야 하는 산업"으로 가고 있습니다.

그래서 앞으로 더 중요해지는 건 Traceability, Work Product, Change Management, Continuous Validation, Evidence 기반 설명 가능성입니다.

현업에서 "차량 보안은 문서 싸움이다"라는 말이 나오는 이유는 불평이 아닙니다. 그게 이 산업의 본질이기 때문입니다.

핵심 요약

1

OEM의 질문이 바뀌었다 — "기능 동작하나요?"에서 "왜 안전하다고 판단했나요?"로

2

Secure Boot 하나도 설명 없이는 불충분하다 — 어떤 Threat 대응인지, 어떻게 검증했는지까지 필요합니다

3

ISO 21434 Work Product는 증명의 재료다 — TARA, Goal, Requirement, Validation Result, Residual Risk 전부 연결되어야 합니다

4

Traceability가 끊어지면 변경 때마다 처음부터다 — 연결 구조가 있어야 영향 범위를 설명할 수 있습니다

5

문서 싸움은 결국 책임의 문제다 — R155 이후 OEM은 보안을 "관리했음"을 증명해야 합니다

ISO21434 차량사이버보안 WorkProduct Traceability TARA CSMS R155 자동차보안 보안문서 ResidualRisk