Concept부터 V&V까지 — 협력사는 자동차 사이버보안 추적성을 어떻게 관리해야 할까?

현업에서 보는 차량 보안 V&V

V&V 막바지에 자주 나오는 말들

"이 Requirement는 어디서 나온 거죠? TARA 어디에 있어요?"

"이 테스트가 어떤 Threat 대응인지 연결이 안 됩니다."

"OEM Requirement와 내부 Requirement 매핑 다시 주세요."

"Goal → Requirement → Testcase Traceability가 안 보입니다."

이 말들이 나오는 시점은 대부분 양산 직전, V&V 막바지, OEM Review 직전입니다. 그리고 이 시점에서 추적성이 없다는 걸 깨달으면 — 남은 일정 안에 소급하는 게 거의 불가능합니다.

자동차 사이버보안은 단순히 "보안 기능 개발"만 하는 일이 아닙니다.
왜 만들었고, 어떤 위험을 대응했고,
무엇으로 검증했는지를 끝까지 연결해서 설명할 수 있어야 합니다.
그걸 가능하게 하는 게 Traceability입니다.

---

왜 갑자기 추적성이 중요해졌나

예전 차량 개발에서는 기능 구현, 성능, 품질 중심이었습니다. 그런데 R155와 ISO/SAE 21434 이후 OEM이 협력사에 요구하는 게 바뀌었습니다.

❌ 예전 : "보안 기능 넣어주세요" — 기능이 있으면 됐다

✅ 지금 : "어떤 Threat를 분석했고, 왜 이 Requirement가 나왔고, 어떻게 검증했는지 연결해서 보여주세요"

OEM Audit에서 보는 건 테스트 결과 하나가 아닙니다. 위협 → 요구사항 → 구현 → 검증이 하나의 체인으로 연결돼 있는지를 봅니다. 어느 하나라도 끊기면 Evidence로 인정받지 못합니다.

---

Concept에서 V&V까지 — 실제 추적 구조

보안 추적성 체인 전체 흐름

STEP 1

Item
Definition

아이템 정의

→

STEP 2

TARA

위협·위험 분석

→

STEP 3

CS Goal

보안 목표

→

STEP 4

CS
Requirement

보안 요구사항

→

STEP 5

Architecture
& Impl.

설계·구현

→

STEP 6

V&V

검증·확인

각 단계는 앞 단계를 ID로 참조해야 합니다. TARA 위협 ID → CS Goal ID → Requirement ID → 구현 모듈 → Testcase ID. 이 ID 체계가 끊기지 않고 연결되는 것이 Traceability입니다.

그리고 협력사 현실에서는 여기에 OEM Requirement가 추가됩니다.

협력사가 실제로 받는 흐름

1

OEM CS Requirement 수령 — OEM이 협력사에 내려주는 보안 요구사항. 형식과 수준은 OEM마다 다릅니다.

2

OEM Req → 내부 System Req 매핑 — OEM 요구사항을 자사 시스템 요구사항으로 분해·매핑합니다. 이 단계에서 ID 연결이 시작됩니다.

3

System Req → SW Req 분해 — 시스템 요구사항을 SW 수준으로 세분화합니다. 각 SW Req에 구현 담당과 ID가 붙어야 합니다.

4

구현 + Testcase 작성 — 구현과 동시에 Testcase를 작성해야 합니다. 나중에 만들면 연결이 끊깁니다.

5

V&V 수행 및 증적 제출 — OEM에 제출하는 증적은 단순 테스트 결과가 아니라 요구사항 ID와 연결된 형태여야 합니다.

ID 연결 구조 예시

OEM-CS-001

→

SYS-CS-010

→

SW-CS-032

→

TC-CS-104

OEM 요구사항 → 시스템 요구사항 → SW 요구사항 → 테스트케이스가 ID로 연결됩니다. 이 체계가 처음부터 정리되어 있어야 Audit에서 한 번에 추적이 됩니다.

---

실무에서 가장 많이 터지는 문제 4가지

01

Requirement는 있는데 구현 연결이 없다

OEM Requirement "CAN Message Authentication 적용"까지는 존재합니다. 그런데 실제 ECU 코드 어디서 MAC 생성, Freshness 처리, Verification이 구현됐는지 연결이 없습니다.

"SecOC는 구현했는데 어떤 CAN ID에 적용됐는지, 코드 어디에 있는지 연결이 안 됩니다."

Audit 지적 : "이 Requirement의 구현 근거를 보여주세요." — 문서는 있고 코드도 있는데 연결이 없으면 Evidence로 인정받지 못합니다.

02

구현은 했는데 Testcase 연결이 없다

SecOC 구현 완료, Secure Boot 구현 완료. 테스트도 다 했습니다. 그런데 어떤 테스트가 어떤 Requirement를 검증하는지 Testcase ID와 Requirement ID 간 매핑이 없습니다.

"이 테스트가 어떤 Requirement 검증인지 보여주세요." — 그 순간 Testcase Coverage 연결이 안 되기 시작합니다.

Audit 지적 : "테스트를 했다는 건 알겠는데, 어떤 보안 요구사항을 검증한 겁니까?" — 테스트 결과가 있어도 매핑 없이는 요구사항 충족 증명이 안 됩니다.

03

TARA와 Requirement 연결이 끊긴다

TARA에서 "CAN Spoofing → Steering 오동작 → 메시지 무결성 보장 필요"까지 잘 만들었습니다. Requirement에 SecOC 적용도 있습니다. 그런데 실제 어떤 CAN ID에 SecOC가 적용됐는지, 테스트가 수행됐는지 연결이 없습니다.

"TARA는 했고 Requirement도 있는데, 실제 구현·검증이랑 연결이 안 됩니다."

Audit 지적 : "이 위협에 대한 대응이 실제로 구현·검증됐음을 보여주세요." — TARA가 구현과 단절되면 TARA 자체가 의미를 잃습니다.

04

V&V 막바지에 "증적 지옥"이 시작된다

개발 단계에서는 기능 개발, 일정 대응, 이슈 수정 중심으로 움직입니다. 그러다 V&V 막바지에 갑자기 Requirement Coverage, Test Coverage, Traceability Matrix를 요구받습니다.

"지금 추적성 매트릭스 만들려면 얼마나 걸려요?" — "...한 달은 걸릴 것 같습니다."

이미 늦었습니다. 소급 작업은 시간이 두 배 걸리고, 빠뜨린 항목이 생기고, Audit에서 일관성 없음이 더 잘 보입니다.

---

OEM이 실제로 보는 것

OEM이 확인하는 것	의미	끊겼을 때 지적
Threat 근거	왜 이 Requirement가 필요한가	"이 요구사항은 어떤 위협에서 나왔습니까?"
Requirement Trace	OEM Req와 내부 Req 연결	"OEM-CS-001이 내부 어떤 Req와 매핑됩니까?"
Implementation Trace	실제 어디에 구현됐는가	"이 Requirement의 구현 위치를 보여주세요."
Verification Trace	무엇으로 검증했는가	"이 Testcase가 어떤 Requirement를 검증합니까?"
미충족 항목 처리	빠진 것에 대한 근거	"이 항목은 왜 검증이 안 됐습니까?"

---

협력사를 위한 실무 팁

01

ID 체계를 프로젝트 초반에 확정해라

추적성의 핵심은 ID 연결입니다. OEM Requirement ID, 내부 System Req ID, SW Req ID, Testcase ID — 이 체계가 처음부터 통일되어 있어야 합니다. 나중에 맞추려면 모든 문서를 다시 손봐야 합니다.

✅ OEM이 ID 형식을 지정하는 경우가 있습니다. 프로젝트 초반에 OEM 요구사항 문서에서 ID 체계를 확인하고 그대로 따르는 게 가장 안전합니다.

02

Testcase를 구현과 동시에 만들어라

"구현 먼저, 테스트는 나중"으로 가면 연결이 끊깁니다. Requirement가 확정되는 시점에 Testcase 골격도 함께 만드는 습관이 필요합니다. 테스트케이스 첫 줄에 "이 테스트는 SW-CS-032를 검증한다"를 명시하면 추적성이 자연스럽게 생깁니다.

✅ Penetration Test, Fuzz Test 같은 외부 수행 테스트도 마찬가지입니다. 테스트 업체에 "결과서에 Requirement ID 매핑을 포함해달라"고 사전에 요청해야 합니다.

03

미충족 항목을 숨기지 마라 — 빈칸이 가장 위험하다

모든 요구사항을 다 구현·검증하지 못하는 경우가 있습니다. 일정, 자원, 기술적 한계 때문입니다. 이때 빈칸으로 두거나 슬쩍 넘어가는 게 가장 위험합니다. OEM Audit에서 빈칸은 즉각 지적 대상입니다.

✅ 미충족 항목은 이유(기술적 한계, 일정 제약), 대안(Compensating Control), Risk Acceptance 여부를 명시하세요. "알고 있고 이렇게 판단했다"는 근거가 있는 것과 없는 것은 Audit에서 완전히 다르게 처리됩니다.

04

설계 변경이 생기면 추적성부터 업데이트해라

코드는 바뀌었는데 Requirement 문서, 설계 문서, Testcase가 이전 구조 그대로인 경우가 자주 생깁니다. 변경이 생기면 영향받는 추적성 체인 전체를 함께 업데이트하고, 재검증이 필요한 Testcase를 식별해야 합니다.

✅ 변경 관리 프로세스에 "추적성 문서 업데이트"를 체크리스트 항목으로 넣으세요. 코드 변경 시 연결된 Requirement ID와 영향받는 Testcase를 함께 기재하는 방식이 효과적입니다.

05

엑셀도 되지만 — 관리 방법이 핵심이다

OEM Audit에서 엑셀 매핑 테이블을 제출해도 됩니다. 그런데 엑셀은 변경 관리가 어렵습니다. ECU 수가 늘어나고 Requirement가 수백 개가 되면 엑셀만으로는 한계가 옵니다. DOORS, Polarion, Jama, Jira 같은 요구사항 관리 툴을 일찍 도입할수록 나중이 편합니다.

✅ 툴이 없다면 엑셀에서 시트 간 ID 링크를 명확히 하고, 변경 시 반드시 버전과 변경 이력을 남기세요. "이 매핑이 언제 마지막으로 검토됐는가"가 Audit에서 확인됩니다.

---

현업에서는 이렇게 느껴진다

추적성 구축 현장에서 배운 것들

보안 기능 구현보다 Traceability 관리가 더 오래 걸리는 경우가 많다 — 특히 프로젝트 후반으로 갈수록 심해진다. 추적성은 Audit 직전에 만드는 게 아니라 처음부터 쌓아가는 것이다.

OEM마다 요구하는 추적성 수준과 형식이 다르다 — 같은 기능이어도 어떤 OEM은 엑셀로 받고, 어떤 OEM은 특정 툴 형식을 고집한다. 계약 초반에 형식을 확인하는 게 나중에 재작업을 막는다.

개발 막바지에 Traceability를 만들려고 하면 거의 항상 터진다 — Requirement와 Testcase 연결이 가장 많이 깨진다. 소급 작업은 시간이 두 배 걸리고 품질도 떨어진다.

결국 중요한 건 "설명 가능성"이다 — "보안을 했다"와 "보안을 증명할 수 있다"는 다르다. 왜 만들었고 어떻게 검증했는지 끝까지 연결 가능해야 한다.

---

마무리

자동차 사이버보안은 결국
"보안 기능 하나 잘 만드는 싸움"이 아닙니다.

어떤 위험에서 시작됐고, 왜 이 Requirement가 나왔고,
무엇으로 구현했고, 어떻게 검증했는지를
끝까지 연결해서 설명할 수 있어야 합니다.

그 순간부터 사이버보안은 단순 개발이 아니라
"추적성 관리"의 영역으로 들어가기 시작합니다.

핵심 요약

1

Traceability는 TARA → Goal → Req → 구현 → V&V가 ID로 연결되는 체계다 — OEM Req와 내부 Req 매핑도 이 체계 안에 포함된다

2

실무에서 가장 많이 끊기는 곳은 4곳이다 — Req↔구현, Testcase↔Req, TARA↔구현, V&V 막바지 소급

3

OEM은 기능 존재보다 연결 구조를 본다 — Threat 근거, Req Trace, 구현 위치, 검증 연결, 미충족 처리까지 확인한다

4

ID 체계와 Testcase는 초반부터 만들어야 한다 — 소급 작업은 시간이 두 배 걸리고 Audit에서 일관성 없음이 더 잘 보인다

5

미충족 항목은 숨기지 말고 근거와 함께 명시해야 한다 — 빈칸이 가장 위험하고, 근거 있는 미충족은 Audit에서 인정받을 수 있다

Traceability 추적성 ISO21434 TARA V&V 자동차사이버보안 보안요구사항 OEM협력사 CSMS R155 SecureCoding Audit대응