왜 자동차 사이버보안은 항상 개발 막바지에 터질까?

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

차량 개발이 거의 끝나갈 무렵, 갑자기 연락이 옵니다.

"보안 산출물 좀 만들어주실 수 있나요?"

이 업계에서 일하다 보면 한 번쯤은 겪는 장면입니다. 설계가 확정되고, 코드가 올라가고, 검증까지 마친 시점에 갑자기 사이버보안 얘기가 나옵니다. 대부분 규제 대응 때문입니다.

왜 자동차 사이버보안은 항상 개발 막바지에 터질까요?

그리고 막바지에 터진 보안은
왜 실제로 차량을 더 안전하게 만들지 못할까요?

---

실제로 이런 일이 벌어진다

개발이 사실상 완료된 상태에서 자기인증(VTA) 요건을 맞추기 위해 보안 산출물을 뒤늦게 만들어야 하는 상황이 있습니다. TARA도, 사이버보안 계획도 전부 사후 작성입니다.

이때 가장 큰 문제가 드러납니다.

⚠️ 이미 개발이 끝난 시스템에서 구조적으로 보안 요구사항을 충족할 수 없는 항목이 나옵니다.

설계 단계에서 보안이 반영되지 않았기 때문에, 아무리 문서를 잘 만들어도 실제 보안 수준을 높이는 건 불가능합니다.

결국 그 항목들은 "Risk Acceptance" 처리되거나, 다음 모델에서 개선하겠다는 계획서로 마무리됩니다. 문서는 만들어졌지만, 차량이 더 안전해진 건 아닙니다.

---

왜 이런 일이 반복될까

자동차 개발은 오랫동안 V-모델을 기반으로 해왔습니다. 기능 안전(ISO 26262)은 이 프로세스 안에 오래전부터 녹아들어 있습니다. 하지만 사이버보안은 달랐습니다.

ISO/SAE 21434가 본격적으로 주목받기 시작한 건 최근 몇 년이고, UN ECE WP.29 규제가 실질적인 강제력을 갖게 된 것도 2022년 이후입니다. 그러다 보니 많은 조직에서 사이버보안을 "개발 끝나고 확인하는 것"으로 인식해왔습니다.

차량 개발에서 보안이 터지는 전형적인 패턴

CONCEPT

요구사항
정의

→

DESIGN

시스템
설계

→

IMPLEMENTATION

개발·
구현

→

VALIDATION

검증·
테스트

→

SOP 직전

보안
산출물?

💥 설계가 굳어버린 뒤에 보안을 넣으려고 하면 — 아무것도 바꿀 수 없습니다

보안이 프로세스 밖에 있다는 게 문제의 핵심입니다.
요구사항 단계에서 보안 요건이 정의되지 않으면, 설계에 반영될 수 없고, 구현에서 고려될 수 없습니다. 나중에 아무리 문서를 써도 이미 굳어버린 아키텍처는 바꾸기 어렵습니다.

---

막바지 보안 대응이 만드는 전형적인 문제들

📄 TARA 사후 작성

개발 완료 후 위협 분석을 합니다. 이미 설계가 확정된 상태라 Risk가 발견돼도 아키텍처를 바꿀 수 없습니다.

→ 문서는 있지만 실제 Risk는 그대로

⚠️ Risk Acceptance 남발

구조적으로 대응 불가능한 항목들이 전부 "Risk 수용"으로 처리됩니다. 다음 모델 개선 계획으로 마무리됩니다.

→ Risk 관리가 아닌 Risk 미루기

🔍 Pentest 타이밍 문제

SOP 직전에 Pentest를 합니다. 취약점이 발견돼도 일정 때문에 수정이 불가능합니다. 발견해도 반영을 못 합니다.

→ 취약점 확인 후 출하

📋 Traceability 부재

Threat → Requirement → Implementation 연결이 없습니다. 보안 기능이 왜 있는지 설명이 안 됩니다.

→ Audit에서 반드시 지적 받음

---

ISO 21434가 말하는 것 — Cybersecurity by Design

ISO/SAE 21434는 명확하게 말합니다. 보안은 개발이 끝난 뒤 덧붙이는 게 아니라, 개념 단계부터 설계에 내재되어야 합니다.

개발 단계	ISO 21434가 요구하는 보안 활동	타이밍
Concept Phase	TARA 수행, Cybersecurity Goal 정의, CAL 결정	초기 필수
System Design	보안 아키텍처 설계, Cybersecurity Requirement 도출	초기 필수
SW Development	Secure Coding, 보안 요구사항 구현	개발 중 반영
Integration & Test	보안 기능 검증, Vulnerability Test	계획된 검증
SOP 직전	산출물 정리, Pentest, Cybersecurity Case 완성	막바지만으론 불가

❌ 현실에서 자주 일어나는 것

• 보안은 나중에 하면 된다
• SOP 앞에 산출물 만들면 된다
• Pentest 한 번 하면 끝이다
• 보안팀이 따로 처리한다

✅ ISO 21434가 요구하는 것

• Concept 단계부터 TARA 수행
• 보안 요구사항이 설계 제약으로 작동
• Requirement → Test Traceability 유지
• 개발팀과 보안팀이 함께 진행

막바지 대응은 Risk를 해결하는 게 아닙니다.
문서로 Risk를 가리는 것에 가깝습니다. 그리고 그건 규제 대응은 될 수 있어도, 실제 차량 보안은 아닙니다.

---

왜 바뀌기 어려운가

이걸 알면서도 왜 반복될까요. 이유는 구조적입니다.

막바지 보안이 반복되는 구조적 이유

일정이 보안보다 먼저다 — 차량 개발 일정은 수년 전부터 확정됩니다. 그 일정 안에 보안 활동이 처음부터 들어가 있지 않으면, 나중에 끼워 넣는 게 불가능합니다.

개발팀과 보안팀이 따로 논다 — 보안 요구사항이 시스템 설계에 반영되려면 개발 초기부터 함께 움직여야 합니다. 조직이 분리되어 있으면 연결이 안 됩니다.

규제 대응이 목적이 된다 — VTA 통과, Audit 통과가 목표가 되면 실제 보안 수준보다 문서 완성도가 더 중요해집니다. 수단이 목적을 대체하는 문제가 생깁니다.

보안 비용을 나중으로 미룬다 — 초기에 보안을 설계에 반영하면 비용이 들어 보입니다. 하지만 막바지에 문제가 터지면 그 비용이 몇 배가 됩니다. 단기 판단이 장기 비용을 만듭니다.

---

마무리

차량 사이버보안이 막바지에 터지는 건
담당자의 문제가 아닙니다.

보안이 개발 프로세스 밖에 있는 구조의 문제입니다.

ISO 21434는 그 구조를 바꾸라고 요구합니다. Concept 단계부터 TARA를 하고, 보안 목표가 설계 제약이 되고, Requirement가 구현을 만들고, 검증이 그것을 확인하는 흐름.

보안을 막바지에 몰아서 처리해본 경험이 있다면 압니다. 그건 보안을 한 게 아닙니다. 보안을 한 것처럼 보이게 한 것입니다.

핵심 요약

1

막바지 보안은 문서만 만들 뿐 차량을 안전하게 만들지 못한다 — 굳어버린 아키텍처는 바꿀 수 없습니다

2

ISO 21434는 Concept 단계부터 보안을 요구한다 — TARA·Goal·Requirement가 초기 설계 제약으로 작동해야 합니다

3

Risk Acceptance 남발은 Risk 관리가 아니라 Risk 미루기다 — 다음 모델 계획서는 현재 차량을 안전하게 만들지 않습니다

4

규제 통과가 목표가 되면 실제 보안이 사라진다 — 수단이 목적을 대체하는 순간 보안은 형식이 됩니다

5

이건 담당자 문제가 아닌 구조 문제다 — 보안이 개발 일정과 프로세스 안에 처음부터 있어야 합니다

차량사이버보안 ISO21434 SecureByDesign 자동차개발 TARA CSMS VTA 보안프로세스