“HW는 같은데 SW만 조금 달라요” — TARA랑 보안 시험 다시 해야 하나?

현업에서 보는 차량 보안 기술

자동차 ECU 개발에서 하나의 ECU를 여러 차종에 재사용하는 건 이제 일반적인 전략입니다.

HW는 동일하고, MCU도 동일하고, Bootloader도 동일합니다. 그런데 차종마다 CAN Matrix가 조금 다르고, 진단 DID가 다르고, Gateway Routing이 다릅니다. OEM이 달라지면 OTA 정책도, 보안 요구사항도 달라집니다.

그리고 이때 반드시 나오는 질문이 있습니다.

"HW는 똑같은데 TARA 다시 해야 하나요?"
"기존 보안 시험 성적서 재사용 안 되나요?"
"SW 조금 바뀐 건데 Pentest 또 해야 하나요?"

Tier-1과 OEM 사이에서 가장 많이 논쟁되는 영역 중 하나입니다.

오늘은 ECU 재사용·Variant 개발에서 TARA 재검토 기준, 보안 시험 재사용 범위, 그리고 실제 현업이 어떻게 움직이는지 정리해봅니다.

---

자동차 ECU는 원래 재사용을 전제로 만든다

요즘 차량 개발은 차종별 ECU 완전 신규 개발보다 플랫폼 기반 재사용이 훨씬 많습니다. 같은 Gateway ECU, 같은 BCM, 같은 Telematics ECU를 세단·SUV·EV·해외 차종에 Variant 형태로 전개합니다.

개발 비용 절감, 일정 단축, 유지보수 단순화, OTA 운영 효율. 재사용 자체는 업계의 기본 전략입니다.

문제는 보안입니다.

⚠️ 보안은 "HW 동일 여부"보다 "Risk가 동일한가"를 봅니다.

HW가 같아도 연결되는 ECU, 외부 인터페이스, Gateway 정책, OTA 구조가 달라지면 Attack Surface 자체가 달라질 수 있습니다.

---

가장 흔한 오해 — "HW 같으면 TARA도 같은 거 아닌가?"

많은 엔지니어들이 이렇게 생각합니다. 하지만 TARA는 Asset, Threat Scenario, Attack Path, Damage Scenario를 기반으로 합니다.

같은 ECU라도 "어떤 차량 환경에 들어가는가"에 따라 Threat가 달라집니다.

동일한 MCU, 동일한 Bootloader라도 차량 토폴로지와 연결 구조가 바뀌면 공격자가 접근할 수 있는 경로가 달라집니다.

---

변경 유형별로 상황이 다르다

모든 변경이 똑같이 위험한 건 아닙니다. 변경의 성격에 따라 보안 재검토 범위가 크게 달라집니다.

CASE 1 — 단순 Variant

• 차량 로고·문구 변경
• Calibration 수정
• 내부 파라미터 조정
• DID 일부 변경

→ 기존 TARA 유지, 영향 분석만 수행
성적서 재사용 가능한 경우 많음

CASE 2 — 통신 구조 변경

• 신규 CAN Signal 추가
• 외부 ECU 연결 증가
• Gateway Routing 변경
• Diagnostic 정책 변경

→ Trust Boundary 변화 가능
부분 TARA 업데이트 + Regression Test

CASE 3 — OEM 전개 / 구조 변경

• 다른 OEM 납품
• OTA 기능 추가
• 신규 외부 인터페이스
• HSM / Crypto 변경

→ Security Context 자체가 달라짐
TARA 재검토 + 보안 시험 재수행 가능

---

OEM이 달라지면 — 가장 어려운 케이스

같은 ECU를 다른 OEM에 납품할 때가 진짜 복잡합니다. OEM마다 Security Requirement, Gateway 정책, 진단 정책, OTA 구조, Secure Debug 수준이 다 다릅니다.

항목	OEM A	OEM B
SecOC	선택	필수
Secure Debug	선택	강제
OTA 보안	없음	필수
Gateway Filtering	약함	Strict
보안 CAL 등급	CAL2	CAL4
Pentest 요구	선택	필수

HW는 완전히 동일해도 보안 요구사항이 이 정도로 달라질 수 있습니다. 이건 TARA와 보안 시험을 OEM 기준으로 재검토해야 하는 명확한 이유가 됩니다.

---

핵심은 Change Impact Analysis

현실에서는 Variant가 바뀔 때마다 Full TARA 재수행, Full Pentest, 전체 재인증을 하지 않습니다. 그렇게 하면 플랫폼 전략 자체가 무너집니다.

대신 핵심 질문은 하나입니다.

"이번 변경이 Cybersecurity Risk를 바꾸는가?"

이 질문에 답할 수 있는 구조가 Change Impact Analysis입니다.

CHANGE IMPACT ANALYSIS FLOW

STEP 1

변경 내용
식별

→

STEP 2

Attack Surface
변화 분석

→

STEP 3

TARA
재검토 범위

→

STEP 4

시험
Regression 범위

→

STEP 5

재사용 근거
문서화

변경 항목별 영향 가능성

변경 항목	Attack Surface 영향	TARA 재검토	시험 재수행
UI / 문구 변경	낮음	불필요	불필요
Calibration 변경	낮음	불필요	불필요
Diagnostic DID 변경	중간	부분 검토	Regression
CAN Signal 변경	중간~높음	부분 업데이트	Regression
Gateway Routing 변경	높음	재검토 필요	재수행 필요
신규 외부 인터페이스	매우 높음	신규 Threat 분석	재수행 필요
OTA 기능 추가	매우 높음	재검토 필요	Pentest 포함
HSM / Crypto 변경	매우 높음	재검토 필요	Full 재검증

---

TARA는 문서가 아니다

많은 사람들이 "TARA 문서 한 번 만들었으니까 끝"이라고 생각합니다. 하지만 ISO 21434 관점에서 TARA는 다릅니다.

✅ TARA는 한 번 작성하고 끝나는 결과물이 아니라,
변경 시 반복 검토 가능한 "Risk Assessment 방법론"입니다.

재사용 개발에서 핵심은 기존 TARA를 통째로 다시 쓰는 게 아니라,
어떤 부분이 유효하고 어떤 부분을 업데이트해야 하는지 판단하는 것입니다.

---

보안 시험 성적서는 언제 재사용 가능한가

현업에서 가장 많이 물어보는 질문입니다. 답은 하나입니다. 변경 영향 범위에 따라 달라집니다.

변경 수준	일반적인 대응 방향
경미한 Variant (로고, 파라미터)	기존 시험 성적서 재사용, 영향 분석 문서 첨부
통신 Signal 변경	변경 부분 Regression Test 수행, 기존 성적서 일부 갱신
신규 외부 인터페이스 추가	추가 항목 보안 시험 수행, 기존 항목 재사용
OTA 구조 변경	OTA 관련 Pentest 재수행 필요
다른 OEM 전개	OEM Security Requirement 기준 재검토, 필요 항목 재수행
보안 메커니즘 변경 (HSM, Crypto)	영향 범위 Full 재검증 필요

OEM들이 실제로 보는 것: "재시험 했는가"보다 "왜 기존 검증 결과를 계속 신뢰할 수 있는가"를 설명하는 문서입니다. 변경 이력, 영향 분석 결과, 재사용 근거가 핵심입니다.

---

Traceability가 재사용 전략의 기반이다

결국 영향 분석이 가능하려면 기존 보안 자산이 연결되어 있어야 합니다.

어떤 Threat가 → 어떤 Requirement로 연결되고 → 어떤 ECU 기능에 영향 주고 → 어떤 Test Case로 검증됐는지

이 추적 구조가 있어야 "이번 변경이 어디까지 영향 주는가"를 설명할 수 있습니다.

Traceability가 없으면 변경할 때마다 처음부터 전부 다시 해야 하는 상황이 됩니다. 플랫폼 재사용 전략이 가능한 이유는 결국 이 연결 구조가 유지되기 때문입니다.

---

SDV 시대에 이 문제가 더 커지는 이유

과거에는 차량 출시 후 SW 변경이 거의 없었습니다. 지금은 다릅니다. OTA, Feature Update, 지속 Patch가 계속 발생합니다. 차량은 이제 계속 변경되는 소프트웨어 플랫폼이 되어가고 있습니다.

변경이 반복될수록 Change Impact Analysis와 Incremental TARA 중요성은 계속 커집니다. ISO 21434가 Clause 8에서 지속 활동(Continuous Cybersecurity Activities)을 강조하는 이유도 여기에 있습니다.

---

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

현업 경험 4가지

같은 ECU라도 OEM마다 대응 방식이 달라진다 — 어떤 OEM은 기존 TARA 재사용을 허용하고, 어떤 OEM은 Variant별 TARA 업데이트를 요구합니다. 프로젝트 초반에 OEM의 변경 관리 정책을 확인하지 않으면 후반에 큰 공수가 생깁니다.

Tier-1은 "공통 플랫폼 유지"를 원하고, 보안팀은 "변화 가능성"을 먼저 본다 — ECU Variant가 늘어날수록 검증 비용이 폭발적으로 증가합니다. 개발팀은 "기능 조금 바뀐 수준"이라고 보지만 보안팀은 Attack Surface 변화 가능성을 먼저 따집니다. 이 둘의 시각 차이가 매 프로젝트마다 충돌 포인트가 됩니다.

영향 분석 문서가 없으면 재사용 주장이 안 된다 — "기존 성적서 있습니다"만으로는 OEM이나 VTA를 설득하기 어렵습니다. 왜 이번 변경이 기존 검증 결과에 영향을 주지 않는지를 설명하는 문서가 있어야 재사용이 인정됩니다.

결국 가장 중요한 건 Traceability다 — 변경사항이 어떤 Threat, Requirement, Test와 연결되는지 추적 가능해야 재사용 전략도 가능합니다. 이 구조 없이 Variant를 늘리다 보면 어느 순간 검증 자산이 뒤엉켜서 관리 자체가 불가능해집니다.

---

마무리

같은 ECU라도,
차량 환경과 연결 구조가 달라지면 Risk도 달라질 수 있습니다.

자동차 보안은 HW 동일 여부보다
Cybersecurity Context의 변화 여부를 더 중요하게 봅니다.

"다시 해야 하는가?" 보다 중요한 질문은 이겁니다.

"왜 기존 검증 결과를 계속 신뢰할 수 있는가?" — 이걸 설명할 수 있는 구조가 있다면 재사용은 가능합니다. 그리고 그 구조의 기반은 결국 Traceability입니다.

핵심 요약

1

HW가 같아도 차량 환경이 달라지면 Risk가 달라진다 — Attack Surface는 HW가 아닌 연결 구조로 결정됩니다

2

OEM이 달라지면 Security Context 자체가 달라진다 — 보안 요구사항, 정책, 메커니즘이 OEM마다 다릅니다

3

모든 Variant마다 Full 재시험을 하지는 않는다 — 핵심은 Change Impact Analysis 기반 판단입니다

4

TARA는 결과 문서가 아닌 반복 가능한 방법론 — 변경 시 업데이트하는 구조로 운영해야 합니다

5

재사용의 핵심 근거는 Traceability — 연결 구조가 없으면 재사용 주장 자체가 불가능합니다

ISO21434 TARA 차량사이버보안 ECU재사용 Variant개발 자동차보안 보안시험 RegressionTest 플랫폼ECU ChangeImpactAnalysis