SDV 피망 슬롯 환전의 본질은 ‘추적성’이다

SDV에 대한 담론은 흔히 빠른 업데이트, 즉 OTA에서 출발한다. 그러나 현장에서 더 자주 되돌아오는 질문은 결이 조금 다르다. “업데이트 이후에도 우리는 이 차를 계속 신뢰할 수 있는가?” 그렇다면 무엇이 보안을 증명하는가? Trustonic의 박우종 비즈니스 개발 이사와의 인터뷰를 통해, 이 글은 보안을 하나의 ‘기능(feature)’이 아니라 지속적인 업데이트가 반복되는 시대를 위한 운영 및 추적 구조로 다시 읽는다. 여기서 말하는 추적성(traceability)이란, 사고가 발생했을 때 원인 - 영향 - 책임의 경로를 가능한 한 신속하게 좁혀갈 수 있는 능력을 의미한다. 그리고 그 능력은 사고 이후 OEM이 부담해야 할 운영 비용과 대응 타임라인을 직접적으로 결정한다. 이 글은 현장의 언어로, SoC의 가장 아래 계층에 위치한 ‘신뢰의 바닥(trust floor)’, 즉 TEE가 왜 10년에 걸친 신뢰를 유지하기 위해 필수적인지를 말한다.

글 | 한상민 기자_ han@autoelectronics.co.kr
IN ENGLISH





“무슨 일이 발생했을 때, 우리는 그것을 추적할 수 있어야 합니다. 그것도 빠르게요.”
Trustonic의 박우종 이사가 말했다.
SDV 담론은 거의 습관처럼 OTA(Over-the-Air)에서 시작한다. 기능을 추가하고, 버그를 수정하고, 사용자 경험을 재구성하는 일. 이 모든 순간은 ‘미래’로 소비된다. 그러나 현장에서 제기되는 더 민감한 질문은 다르다. 업데이트 이후에도 이 차는 여전히 신뢰할 수 있는가? 그리고 그 질문은 결국 보안으로 이어진다. 여기서 보안은 곧바로 엔지니어링의 언어가 된다. 추적성, 책임성, 디버깅, 유지보수, 규제 대응, 비용. 
업데이트 이후 취약점이 드러나거나 문제가 폭발하든, OEM이 결국 떠안아야 할 것은 원인을 신속하게 좁혀갈 수 있는 구조다. 보안은 하나의 ‘기능’이라기보다, 사후에 근본 원인과 책임까지 도달하는 경로를 단축하는 설계에 가깝다.
그리고 여기서 드라마가 시작된다. 자동차 SoC 생태계가 점점 복잡해질수록, 피망 슬롯 환전은 하나의 단일한 해답으로 좁혀지지 않는다. 어떤 칩 벤더는 자사의 TEE(Trusted Execution Environment)를 전면에 내세우고, 또 다른 진영은 OP-TEE와 같은 오픈소스 TEE에서 출발한다. 그러나 진짜 문제는 그 이후다. 모델 라인, 판매 지역, 연식, 공급망이 변화할 때마다 피망 슬롯 환전은 운영적으로 지속가능한 형태로, 반복해서 다시 증명돼야 한다.
그래서 결국 ‘도착점(destination)’이 필요해진다. OP-TEE로 시작할 수는 있다. 그러나 규제가 본격적으로 집행되고 업데이트가 누적될수록, 조직은 머지않아 검증되고 인증된 TEE로 이동하게 된다. 즉, 추적과 책임이 가능한 ‘신뢰의 바닥(trust floor)’으로 향하게 된다.
Trustonic의 논리는 여기서 출발한다. TEE가 시스템의 가장 아래 계층에서 신뢰의 바닥을 구축할 때에만 그 위에서 이뤄지는 업데이트가 비로소 의미를 갖게 된다는 것이다.


 
“ECU나 도메인 안이 아닙니다. SoC 안입니다. SoC 내부에는 물리적인 TrustZone 영역이 있고, TEE는 그 안에 자리합니다.”  
자동차 안에서 Trustonic이 어디에 존재하느냐는 질문에 대한 박 이사의 답이다. 많은 보안 논의가 도메인, 네트워크, 애플리케이션과 같은 ‘상위 계층’에서 시작되는 반면, Trustonic은 출발선을 더 아래로 내린다. 이 접근은 어떤 ECU를 선택하느냐에서 시작하지 않는다. 대신, 어떤 SoC 내부의 어떤 격리된 실행 영역을 신뢰의 기반으로 삼을 것인가에서 출발한다.
Trustonic은 TEE를 커스텀 코드와 데이터(Trusted Applications, TA 등)를 격리하고 보호하는 보안 엔클레이브(secure enclave)로 설명한다. TrustZone과 같은 하드웨어 기반 격리 실행 환경을 활용해 시스템 내부에 보호된 실행 영역을 만들고, 그 위에 ‘신뢰의 바닥’을 깐다. 그리고 이 개념을 현실로 만드는 단 하나의 조건은 바로 ‘격리(isolation)’다.
자동차는 더 이상 닫힌 임베디드 박스가 아니다. Android, Linux, QNX와 같은 풍부한 OS 스택이 차 안으로 들어온다. 앱은 빠르게 늘어나고, 계정·컨텐츠·결제·키 관리 기능이 차량에 결합된다. 외부 연결성과 OTA가 일상화된 세계에서 보안은 한 번 구축하고 잊어버릴 수 있는 대상이 아니다. 보호해야 할 영역과 열어두어야 할 영역을 물리적으로 분리하는 아키텍처가 필요하다. TEE는 차량과 OEM 서버 간의 연결을 검증(attestation)하고, OTA가 유효한 출처에서 시작됐음을 보장하는 데 핵심적인 역할을 수행한다.





 
IVI, 게이트웨이, 존(Zone) 컨트롤러. 차량 내부에서 TEE의 실질적인 출발점은 어디일까? Trustonic은 보안을 SoC 내부의 격리된 영역에서 출발한다. 그렇다면 그 SoC가 가장 먼저 ‘풍부해지는(rich)’ 곳은 어디인가?
“가장 흔한 경우는 IVI 쪽입니다. SoC가 있는 곳이라면 어디든 사용할 수 있습니다. 하지만 마이크로컨트롤러에는 TrustZone 영역이 없기 때문에 그곳에서는 사용하지 않습니다.”
IVI/디지털 콕핏은 ‘PC화(PC-ification)’가 가장 빠르게 진행되는 영역이다. 풍부한 OS 스택, 앱 생태계, 외부 연결성, 사용자 데이터, 컨텐츠/DRM, 결제·인증, 키와 자격증명까지 모든 것이 한꺼번에 유입된다. 공격 표면은 넓고, 보호해야 할 자산은 방대하며, 업데이트는 빈번하다. IVI는 차량 내부에서 계정·컨텐츠·결제·개인 데이터가 처음으로 집중된 영역이었고, 그렇기 때문에 보안이 처음으로 ‘현실’이 된 곳이기도 하다. 많은 경우 IVI는 TEE 도입의 첫 단계가 된다.
Trustonic은 “왜 자동차에 TEE가 필요한가”를 4가지 범주로 정리한다. 이는 보안(민감 데이터 보호, 안전한 통신), 기능안전성(safety: 중요 기능의 격리, 안전한 소프트웨어 업데이트), 규제 준수/신뢰(compliance/trust: 규제 적합성의 기반), 그리고 IP 보호(알고리즘 및 자산 보호)다. 이런 요구들은 IVI 안에서 서로 겹치며 축적된다. 그래서 IVI는 기능의 최전선일 뿐 아니라 보안의 최전선이 되기도 한다.


 
IVI를 중심으로 TEE 도입이 가속화되고 있지만, 현장은 기술보다 더 거친 장벽에 직면해 있다. 바로 파편화된 공급망이다.
글로벌 자동차 전장 시장에서 일부 SoC 벤더는 막강한 영향력을 갖고 있다. 문제는 많은 대형 칩 제조사가 자사 하드웨어에 최적화된 폐쇄형 보안 솔루션(인하우스 TEE)을 번들로 제공한다는 점이다. 이는 자연스럽게 락인(lock-in) 효과를 만든다. 칩 벤더는 이를 ‘보증(assurance)’의 이름으로 권장하지만, 역설적으로 이는 OEM을 제약하는 아킬레스건이 될 수 있다.
박 이사는 이를 ‘디커플링(decoupling) 문제’라고 부른다.
“특정 칩셋에 묶인 보안은 처음에는 도입하기 편리할 수 있습니다. 그러나 OEM이 공급망을 다변화하려 할 때, 그것은 막대한 기술 부채로 돌아옵니다. 칩셋이 바뀔 때마다 보안 구조를 처음부터 다시 설계하고 재검증해야 하기 때문입니다.”
모든 OEM이 디커플링을 최우선 과제로 두는 것은 아니다. 그러나 멀티-SoC 전략이 시작되는 순간, 피망 슬롯 환전의 일관성은 곧 비용과 일정의 문제가 된다. 실제로 글로벌 OEM은 리스크 관리를 위해 서로 다른 칩셋을 혼용하는 경우가 많다. 그런 맥락에서 Trustonic과 같은 서드파티 TEE는 추상화 계층(abstraction layer)으로 기능할 수 있다. 즉, 서로 다른 하드웨어 위에서도 일관되게 동작하는 구조를 제공한다.
그 매력은, 칩셋과 무관하게 일관된 보안 수준을 유지하고, 사고 발생 시 근본 원인 분석을 위한 추적 도구를 통합할 수 있다는 점이다. 이는 일종의 ‘보안 독립 선언’과도 같다. OEM이 단일 칩 벤더의 생태계에 완전히 종속되는 것을 피하고, 소프트웨어 주도권을 유지하도록 돕는다. 그리고 이런 독립성이 확보되면, SDV의 핵심인 OTA 역시 칩셋 제약 없이 차량 전반에 걸쳐 신뢰를 유지할 수 있는 자유를 얻게 된다.


 
SDV에서 진짜 싸움은 업데이트가 반복되는 동안 신뢰가 무너지지 않도록 어떻게 막느냐가 될 수 있다.
OTA는 기능을 추가하는 이벤트다. 그러나 동시에 차량 내부의 자산(데이터, 키, 권한, 코드)이 이동하는 하나의 사건이기도 하다. 그 순간부터 보안은 ‘공격을 막는다’는 문제가 아니라, 무엇을 보호 범위로 정의할 것인가, 그리고 그 경계를 어떻게 유지할 것인가의 문제로 바뀐다.
“개인 데이터나 차량의 주요 자원을 변경하는 것은 보안 타깃입니다. 그것이 SoC 안에서 구현되었거나, 제조사가 정의한 보안 영역 내에서 보완 조치가 마련돼 있다면, 그 범위는 보호되고 있다고 볼 수 있습니다.”
이것이 OTA를 바라보는 박 이사의 기준이다. 핵심은 “Trustonic이 모든 것을 보장한다”는 것이 아니다. 오히려 OEM이 무엇을 보안 타깃으로 정의할지 결정하고, 그 타깃을 SoC 내부의 보호된 경계 안에 격리하는 것이다.
TEE는 그 경계를 기술적으로 유지하는 실행 환경이다. 업데이트가 많아질수록, 그 경계가 도전받을 가능성도 커진다. 그래서 업데이트된 코드는 적절히 검증되었는가, 키나 자격증명이 노출될 수 있는가, 중요한 루틴이 일반 OS의 취약점 영역으로 끌려 들어갈 수 있는가, 업데이트 이후에도 보호 경계는 온전히 유지되는가와 같은 질문들이 모여 ‘신뢰’를 형성한다. 그리고 TEE는 그 신뢰를 가장 아래 계층에서 지탱한다.






 
기업들이 UNECE R155/R156과 같은 사이버 규제를 이야기할 때, 많은 경우 프로세스와 문서 작업에서 출발한다. 그러나 이런 규제가 진정으로 요구하는 것은 ‘문서화(documentation)’가 아니다. 그것은 운영적으로 지속가능한 기술 구조다. SDV가 지속적인 업데이트를 전제로 작동하는 순간, 기업이 증명해야 할 것은 “보안이 존재한다”는 것이 아니라, 시간이 지나도 보안이 무너지지 않는 방식이다.
Trustonic은 글로벌 규제를 최종 목표가 아니라, 안전한 차량을 만들기 위한 출발점으로 본다. 그리고 자동차 및 IoT 피망 슬롯 환전 규제 전반에 공통되는 주제를 4가지로 압축한다. 이는 설계 단계부터의 피망 슬롯 환전(secure by design), 업데이트 이후의 업데이트 가능성과 안전성(updateability and safety after updates), 이슈에 대한 대응성(reactivity to issues), 그리고 SBOM, 즉 지금 어떤 코드가 실행되고 있는지를 아는 능력이다.
Trustonic은 이 모든 주제를 하나의 결론으로 연결한다.
왜 TEE가 ‘바닥’이어야 하는가다. 신뢰의 바닥이 흔들리면, 업데이트는 더 이상 가치를 더하는 수단이 아니라 리스크를 확산시키는 경로가 된다.
논리는 일관된다. ‘설계 단계부터의 보안’에 대해서는 공격 표면을 줄이는 구조와 정책을 강조한다. 예를 들어, 필요할 때만 코드를 실행하고, 보안 영역에서는 필요한 것만 실행하며, 필요하지 않을 때는 접근 지점을 열어두지 않는 것이다. 업데이트 시대에 대해서는 TEE 자체도 펌웨어처럼 관리되고 업데이트돼야 한다고 주장한다. 이슈 대응 측면에서는 취약점/이슈 대응 서비스를 언급한다. 그리고 추적성(SBOM) 측면에서는 “오픈소스 의존성이 없는 보안 OS(오픈소스 미사용)”를 하나의 운영 원칙으로 제시한다.
결론은 다시 추적성으로 돌아온다. 문서는 의도를 기록하지만, 설계·업데이트·대응·SBOM을 시간에 걸쳐 견딜 수 있는 하위 계층 구조가 없다면 그 의도는 증명이 될 수 없다. 문서는 의도를 기록한다. 운영은 책임을 증명한다. 그리고 바로 여기서 ‘출발점’과 ‘도착점’ 사이의 선택이 시작된다.


 
자동차 보안은 대체로 두 가지 방식으로 출발한다. 하나는 칩 벤더가 번들로 제공하는 TEE를 그대로 사용하는 것이다. 또 하나는 OP-TEE와 같은 오픈 구현을 ‘출발점’으로 삼는 방식이다. 출발은 다를 수 있다. 그러나 시간이 누적되면 질문은 ‘이걸 넣을 수 있는가?’에서 ‘10년 이상 OS와 보호 수준을 유지할 수 있는가?’로 바뀐다.
차량이 늘어나고 업데이트가 반복될수록, 피망 슬롯 환전은 기능이 아니라 운영이 된다. 그리고 비교의 기준도 성능이 아니라, 누가 10년에 걸쳐 업데이트 운영, 규제 요구, 취약점 대응에 대해 책임질 수 있는가로 이동한다.
박 이사는 이를 비용을 통해 설명한다.
“오픈 TEE를 사용하면, 자체 유지보수 자원을 투입해야 합니다. 그 비용 부담은 계속 증가합니다. 업데이트가 있을 때마다 보안 때문에 내부 리소스 비용이 더 늘어나게 됩니다.”
이 현실은 SoC의 경제 구조를 보면 더 분명해진다.
“SoC 제조사가 판매하는 것은 실리콘입니다. 소프트웨어가 주된 사업이 되기는 어렵습니다. 그러나 업데이트, 규제, 취약점 대응이 누적되면서 TEE가 핵심 포인트가 되는 상황이 발생합니다.”
Trustonic은 이 누적된 압박을 한 문장으로 압축한다.
‘OP-TEE는 출발점. Kinibi는 도착점.’
“레고(Lego)처럼 생각하면 됩니다. SoC 위에 우리의 블록을 얹는 것이죠.”
여기서 성능을 길게 논할 필요는 없다. 다만 TEE는 키 관리, 암호화, 서명, 피망 슬롯 환전 저장소, OTA 신뢰 루틴이 집중되는 지점이기 때문에 병목이 발생할 수 있다. 상용 TEE는 이런 경로를 최적화해 운영 부담을 줄일 수 있다. 핵심은 운영적 지속 가능성이며, 결론은 다시 추적성으로 돌아간다.
“우리 프로그램은 모듈화되고 구조화돼 있기 때문에 빠른 추적이 가능합니다. 오픈 구현의 경우에는 누가 무엇을 변경했는지 줄 단위로 확인해야 해서 속도가 느려집니다.”


 
“모든 프로젝트는 다릅니다. 차량 모델마다 프로그램 정의와 코드가 다르고, 연식이 바뀔 때마다 코드도 다시 바뀝니다. 그때마다 코드 네임도 구분됩니다.”
소프트웨어는 더 이상 OEM만이 생산하는 것이 아니다. 수십 개의 공급사 코드가 차량 안으로 흘러 들어오고, 모델 라인·연식·판매 지역이 바뀔 때마다 그 조합은 다시 구성된다. 그리고 방화벽이나 침입 탐지가 시작되기도 전에, 보안은 불편한 질문을 던진다. 이 차량에서 지금 실행되고 있는 코드는 누구의 것인가? 그것은 변경되지 않았는가(무결성)? 그리고 문제가 발생했을 때, 우리는 책임의 경로를 얼마나 좁게 추적할 수 있는가?
그래서 SDV 피망 슬롯 환전은 단순히 침입 탐지에만 초점을 두지 않는다. 시간이 지날수록 더 강조되는 것은 소유권(ownership), 무결성(integrity), 그리고 책임 경로를 관리할 수 있는 능력이다.
TEE의 역할을 과장할 필요는 없다. TEE는 공급망 전체를 한 번에 ‘증명’해주는 만능열쇠가 아니다. 그러나 TEE가 없다면, 반드시 보호되어야 할 최소 자산, 즉, 키, 자격증명, 민감 데이터, 핵심 루틴은 종종 하드웨어(HSM 또는 Secure Element)에 의존하게 된다. 그리고 이들 중 어느 것도 현장에서 고비용 리콜 없이 쉽게 업데이트할 수 있는 구조는 아니다. 그리고 여기서 위험은 커진다. 자산이 읽히거나 조작될 수 있고, ‘누가 무엇을 바꿨는지’를 추적하기도 전에 책임 경로는 흐려질 수 있다.
결국, Trustonic이 말하는 ‘바닥’은 하나의 실질적인 최소 조건이 된다. 그것은 모든 것을 완전히 통제하겠다는 약속이 아니라, 핵심을 격리해 이후에 책임 경로를 신속히 좁힐 수 있도록 만드는 선택이다.
“오픈 구현의 경우에는 누가 무엇을 변경했는지 줄 단위로 확인해야 해 속도가 느려집니다. 저희는 추적과 디버깅을 통해 빠르게 확인할 수 있습니다.”


 
AI가 차량 안으로 들어오면서 보안이 보호해야 할 대상의 성격도 바뀐다. 과거에는 코드, 키, 자격증명이 중심이었다. 이제는 모델 가중치와 학습 데이터가 하나의 패키지로 함께 들어온다. 박 이사는 이 변화를 거대한 담론이 아니라 가장 단순한 정의로 되돌린다.
“보안의 본질은, 보호하고자 하는 데이터가 타인에 의해 읽히거나 탈취되지 않도록 막는 것입니다.”
그는 Trustonic의 TEE 기술이 삼성 갤럭시 플랫폼에서 고가치 보안을 구축하는 데 기여했으며, 전 세계 수억 대의 디바이스에서 그 안정성을 입증했다고 설명한다. 한때 모바일 기기에서 개인 데이터와 결제를 보호하던 ‘신뢰의 바닥(trust floor)’은 이제 AI 자산을 보호하는 기반으로 자동차 영역으로 이동하고 있다.
이 논리는 프리미엄 가전제품 안의 개인 건강 정보나, 공장의 산업 자산 데이터에도 동일하게 적용된다. 데이터가 그러한 성격을 띠는 순간, 그것은 ‘보안 데이터’가 된다. 다시 말해, 보안이 확장되는 이유는 산업이 바뀌어서가 아니라, 자산의 성격이 바뀌기 때문이다.
자동차 산업은 이제 그 궤도 위에 올라섰다. 자산이 ‘정보’에서 ‘물리적 제어’로 확장되는 Physical AI 시대에, TEE가 구축한 신뢰의 바닥은 더욱 단단해져야 한다. 그것은 단순히 데이터를 보호하는 문제가 아니다. 공격자의 의도에 의해 차량이 움직이지 않도록, 끝까지 무결성을 증명하는 문제다.
박 이사는 이 전쟁의 최종 목적지로 포스트 양자 컴퓨팅(PQC)을 지목한다. 핀란드의 IQM과 같은 기업들을 통해 양자 컴퓨팅이 이론에서 현실로 이동함에 따라, 10년 후의 양자 공격에도 견딜 수 있는 ‘미래 신뢰(future trust)’는 SDV의 필수 조건이 된다. 이것이 Trustonic이 최신 솔루션 Kinibi 700에 양자 내성 보안을 선제적으로 통합한 이유이기도 하다.
TEE는 다시 한 번 의미를 갖는다. 그것은 일반 OS의 취약점으로부터 AI 모델, 제어 권한, 그리고 다가올 양자 컴퓨팅 위협까지 모든 것을 격리하고 보호하는 마지막 요새로 기능한다.





 
피망 슬롯 환전 논의가 길어질수록, 서로 다른 축이 하나의 문장으로 쉽게 압축되곤 한다.
침입 탐지, SOC 운영, 컨설팅, 규제 대응은 대체로 ‘상위 계층’에서 움직인다. 네트워크와 로그를 들여다보고, 이상 징후를 탐지하며, 사고 이후의 대응을 설계한다. 그러나 Trustonic이 말하는 TEE는 더 아래에서 출발한다. 보호해야 할 자산을 어디에 둘 것인가, 그리고 그 경계를 어떻게 유지할 것인가라는 질문이다.
박 이사는 그 차이를 과장하지 않는다.
“보안 사고가 중요하지 않다는 뜻은 아닙니다. 다만, 무엇을 반드시 보호해야 하는지 정의해야만, 확신을 가지고 보호할 수 있다는 것입니다.”
이 말은 그들의 포지셔닝을 정확히 보여준다. 탐지/모니터링이 ‘이상 징후를 감시하는 것’이라면, TEE는 처음부터 무엇이 읽혀서는 안 되고 무엇이 변경되어서는 안 되는지를 분리하는 전제조건에 가깝다. 이는 역할의 분담이다. SDV 보안은 상위 계층만 키운다고 해결되지 않으며, 하위 계층만 깐다고 끝나는 문제도 아니다. 무엇을 자산으로 정의할 것인가, 그 자산을 어떤 경계 안에 둘 것인가, 그리고 업데이트 이후에도 그 경계가 온전히 유지되는가의 문제다. 그래서 Trustonic은 IVI 뿐 아니라 게이트웨이, 텔레매틱스, V2X, 도메인 컨트롤러까지 반복적으로 언급한다. 즉, ‘차량 전반에 걸친 적용 가능성’이다.
중요한 것은 도메인 목록이 아니다. 중요한 것은 여러 SoC와 여러 도메인에 걸쳐 동일한 신뢰 기반(TEE + SDK + TA)을 운영적으로 지속가능한 형태로 유지하겠다는 약속이다. 피망 슬롯 환전은 독립된 기능이 되어서는 안 된다. 그것은 운영하고, 추적하고, 대응하는 방식이어야 한다.

SDV 시대의 자동차 보안은 더 이상 “업데이트할 수 있는가?”의 문제가 아니다. 업데이트가 반복되는 동안 핵심 자산을 둘러싼 경계가 유지되는가, 그리고 무언가가 깨졌을 때 원인과 책임의 경로를 얼마나 빨리 좁힐 수 있는가의 문제다. 앱은 바뀌고, OS는 바뀌며, 공급망은 변하고, 규제도 변한다. SDV 보안의 본질은 업데이트 그 자체가 아니다. 업데이트 이후에도 경계가 유지되는가에 있다. 그 경계를 10년간 운영하려면, 무슨 일이 발생했을 때 즉시 원인과 책임의 경로를 좁힐 수 있어야 한다.

“무슨 일이 발생했을 때, 우리는 그것을 추적할 수 있어야 합니다. 그것도 빠르게요.”
박 이사의 이 한 문장이 SDV 피망 슬롯 환전을 요약한다.


 

---

Trustonic 한눈에 보기

무엇을 하는 회사인가: Arm TrustZone 기반의 Secure-OS형 TEE(Trusted Execution Environment)인 Kinibi를 제공하는 보안 소프트웨어 기업이다. 자동차 분야에서는 SoC 내부의 TrustZone 영역에서 동작하며, 키 관리, 암호화, 서명, 보안 저장소, OTA 신뢰 루틴을 격리해 실행한다.
어디에 사용되는가: 주로 풍부한 OS 스택, 외부 연결성, 사용자 데이터가 집중되는 IVI/디지털 콕핏 영역에서 먼저 적용된다. SoC가 존재하는 곳이라면 어디든 배포가 가능하지만, TrustZone이 없는 MCU 영역에서는 사용할 수 없다.
포지셔닝: 칩 벤더 번들 TEE나 OP-TEE와 같은 오픈 구현이 ‘도입의 출발점’이라면, Trustonic은 규제 대응, 업데이트, 취약점 관리, 책임 추적을 포함하는 10년 단위의 운영 관점을 강조한다.
왜 Secure OS를 강조하는가: Secure OS에 서드파티 오픈소스 라이선스를 포함하지 않는 아키텍처를 채택해, SBOM 단순화, 취약점 대응, 인증·감사 준비 상태를 운영적으로 지속 가능한 형태로 유지하는 데 초점을 둔다.
배포 및 인증: 상용 디바이스에서의 대규모 배포 이력, 양산 자동차 적용 사례, 그리고 Common Criteria EAL5+ 인증을 통해 PoC를 넘어 실제 양산 운영 경험을 강조한다.

AEM(오토모티브일렉트로닉스매거진)

---