“검증을 산업화하지 않으면 SDV는 멈춥니다”

많은 기업이 SDV 전환을 말하며 막대한 자금을 투입하고 있다. 그러나 현장 엔지니어들은 여전히 며칠씩 걸리는 테스트 결과, 불명확한 버그 리포트, 반복되는 재시험과 수작업 조율 속에서 혼란을 겪는다. 트레이스트로닉의 크리스천 코저 부사장은 그 원인을 개별 툴의 성능이 아니라, 도구와 팀 사이에서 끊어진 검증 흐름에서 찾는다. 이 인터뷰는 검증을 단순한 사후 확인이 아니라 SDV 개발 체계를 지탱하는 운영 구조로 다시 보게 만든다. SDV의 경쟁력은 엔지니어 개인의 헌신만으로 만들어지지 않으며, 리더십이 검증 구조를 어떻게 재설계하느냐에 달려 있다.


 
트레이스트로닉을 기존 테스트 툴 벤더와 구분 짓는 가장 결정적인 차이는 무엇입니까? 또 one:cx를 왜 자동차 데브옵스 플랫폼이라고 부르십니까?
Kohser        가장 큰 차이는 분명합니다. 기존 벤더들이 테스트 실행을 돕는다면, 트레이스트로닉은 검증 자체를 산업화합니다. 대부분의 테스트 툴 벤더나 인하우스 솔루션은 특정 작업, 특정 도구, 특정 실험실 활동을 최적화하는 데 초점을 맞춥니다. 하지만 SDV 시대의 OEM이 실제 마주한 문제는 그보다 훨씬 구조적입니다.
저는 현장에서 시간이 테스트 실행 단계 안에서 사라진다고 보지 않습니다. 시간은 그 사이에서 사라집니다. 결과를 다른 팀에 넘기고, 데이터를 모으고, 다시 개발자에게 피드백하거나 의사결정용으로 정리하는 과정에서 훨씬 더 많은 시간이 낭비됩니다. one:cx는 바로 그 파편화된 흐름을 하나로 연결하기 위해 만들어졌습니다.
우리는 2004년 BMW와의 프로젝트를 계기로 창업했습니다. 당시 BMW7 시리즈의 ECU 네트워크 아키텍처가 바뀌던 시기였고, 그 현장에서 반복적으로 확인한 것이 있습니다. 테스트 자체보다 커밋에서 요구사항, 실행, 결과, 후속 조치까지 이어지는 전체 루프가 끊기는 지점에서 시간과 품질이 가장 많이 손실된다는 사실입니다. SiL (Software-in-the-loop), HiL (Hardware-in-the-loop), 및 실차 테스트는 그 흐름 속에 있는 서로 다른 레벨일 뿐입니다. 중요한 것은 그것들을 하나의 검증 흐름으로 묶는 것입니다.
이것이 지금의 one:cx를 자동차 데브옵스 플랫폼이라고 부르는 이유이기도 합니다. 검증 속도가 따라오지 않는 상태에서 소프트웨어 개발 속도만 빨라지면 결국 ‘불안정성(downstream instability)’만 커집니다. 핵심은 단순한 실행(execution)이 아니라 검증 분산 처리(orchestration)입니다. 즉, 테스트를 더 많이 수행하는 것이 아니라, 검증이 조직 안에서 실제로 작동하게 만드는 것입니다.






왜 지금 SDV 시대에는 데브옵스와 오케스트레이션이 선택이 아니라 필수가 되었습니까? 
Kohser        개발 환경이 단순히 통제 불능이 됐다고 보지는 않습니다. 더 중요한 변화는, 이제 고객 가치가 만들어지는 전체 루프를 처음부터 끝까지 끊기지 않게 유지해야 한다는 점입니다. 과거에는 요구사항 정의, 기능 개발, 통합, 검증, 출시, 고객 피드백이 비교적 분리된 단계로 운영될 수 있었습니다. 하지만 지금은 이 모든 것이 하나의 루프로 연결돼 있습니다. 이 흐름이 계속 관리되지 않으면, 시장이 가장 빠르게 움직이는 지점에서 조직만 느려집니다.
이런 보틀넥은 늘 개별 팀 안이 아니라, 팀과 팀 사이, 도메인과 도메인 사이, 통합 단계와 테스트 환경 사이에서 발생합니다. 그 사이에 사일로와 수작업 조정이 끼어들고, 그 결과 ‘통합 단계에서 생긴 문제(integration debt)’가 쌓입니다.
저는 데브옵스를 단순히 CI/CD나 더 빠른 배포로 이해하지 않습니다. 핵심은 처음부터 끝까지 책임지는 구조(end-to-end ownership)입니다. 요구사항에서 시작한 일이 개발, 통합, 검증, 출시, 그리고 다시 고객 가치로 이어지는 흐름 안에서 끊기지 않아야 합니다. 이 루프가 끊기면 소프트웨어 개발 속도는 시장 지연으로 바뀌고, 이 루프가 유지되면 소프트웨어는 곧 경쟁력이 됩니다.


 
클라우드 네이티브 접근만으로는 자동차 산업에 충분하지 않다고 하셨습니다. 실리콘밸리식 소프트웨어 관점이 가장 크게 놓치는 부분은 무엇입니까? 
Kohser        클라우드 네이티브 접근은 속도, 유연성, 확장성을 줍니다. 분명히 가치 있습니다. 하지만 자동차는 순수 소프트웨어 환경이 아닙니다. 센서, 액추에이터, ECU, 차량 동역학, 실제 도로 환경, 기능 안전, 규제 준수가 모두 함께 작동하는 사이버-물리 시스템입니다. 실리콘밸리의 회사들은 소프트웨어 개발은 매우 잘합니다. 하지만 자동차에서는 도메인 간 복잡성, 물리적 거동, 다양한 공급망과 지역별 변형을 함께 다뤄야 합니다. 실제로 자동차를 개발하던 시기에 실리콘밸리 기업들조차 우리의 라이선스를 도입했습니다. 결국 모두가 소프트웨어와 하드웨어 전체 프레임워크를 다룰 수밖에 없습니다.
자동차 산업에서 진정한 차별화는 단순히 코드 배포 속도를 높이는 것에 있지 않습니다. 그보다는 실제 주행 조건과 유사한 환경에서 도메인을 넘나드는 결정론적(deterministic) 검증을 수행하고, 즉시 출시가 가능할 만큼 견고한 신뢰 수준을 확보하는 것이 핵심입니다. 이것이 바로 클라우드 네이티브 방식의 사고만으로는 충분하지 않은 이유입니다.



많은 OEM이 자동화와 CI/CD에 투자하고도 여전히 많은 지연을 겪습니다. 근본 원인은 무엇이며, 현장에서 가장 먼저 나타나는 적신호는 무엇입니까?
Kohser        근본 원인은 루프가 닫히지 않는다는 데 있습니다. 많은 CI/CD 파이프라인이 테스트 실행까지는 잘합니다. 하지만 그 이후, 결과를 해석하고 개발자에게 무엇이 일어났는지를 다시 돌려주는 부분에서 흐름이 끊깁니다.
현장에서 제가 직접적으로 말하는 표현이 있습니다. 8주 뒤 피드백이면 이미 늦는다는 것입니다. 개발자는 8주 전에 무엇을 바꿨는지 기억하지 못합니다. 그 코드가 왜 그렇게 작성됐는지, 어떤 맥락이었는지조차 사라집니다. 커밋 이후 몇 분, 몇 시간 안에 결과가 돌아와야 의미가 있습니다.
초기 적신호도 분명합니다. 문제는 보통 KPI에서 먼저 드러나지 않습니다. 현장에서는 그보다 앞서, 무엇이 문제인지 점점 분간하기 어려워지는 순간이 나옵니다. 자동화된 결과는 계속 나오지만, 개발자에게는 정리된 피드백 대신 이슈만 쌓입니다. 더 실무적으로 말하면, 엔지니어들은 더 긴 ‘문제 파악 과정(triage loop)’을 겪고, 같은 테스트를 반복해서 다시 해야 하고, 수동 리뷰 작업이 늘어납니다. 어느 시점이 되면 해당 이슈가 기존에 이미 알려진 문제에서 비롯된 것인지, 아니면 새롭게 확인된 문제인지조차 구분하기 어려워집니다. 저는 그 상태를 “판단이 흐려진 상태(loss of clarity)”라고 부릅니다. 자동화가 늘어나는데도 의사결정 속도가 따라오지 못하는 순간, 구조적 문제가 이미 시작된 것입니다.




SiL 기반 검증과 Continuous Testing은 무엇을 먼저 바꾸며, 개발팀과 테스트팀의 협업 방식은 어떻게 달라집니까? 
Kohser        달라지는 것은 개발자에게 전달되는 피드백 속도입니다. 그다음에 검증 리드타임이 줄어들고, 그 이후에야 의사결정의 질이 눈에 띄게 좋아집니다. 순서가 중요합니다.
현장 사례로는 AMG와 Mercedes-Benz 프로젝트가 있습니다. 이 프로젝트에서는 비즈니스 로직에서 시작해 빌드, 테스트 실행, 결과 회수까지 전체 사이클이 730초, 즉 13분도 안 되는 시간 안에 이뤄졌습니다. 이것은 단순히 테스트가 빨라졌다는 뜻이 아닙니다. 개발자가 거의 즉시 결과를 보고 바로 행동할 수 있다는 뜻입니다.
저는 이것을 소프트웨어의 현장 중심 관리라고 설명합니다. 지금 무엇이 일어나고 있는지, 어디에 갭이 있는지, 무엇을 개선할 수 있는지를 개발자가 직접 볼 수 있게 되는 것입니다. 이 변화는 협업 구조도 바꿉니다. 검증은 더 이상 개발 이후에 넘겨받는 단계가 아닙니다. 개발자는 더 이른 단계부터 품질에 대한 책임을 지게 되고, 테스트 조직은 자동화 환경 구축, 테스트 전략, 커버리지 설계, 거버넌스, 출시 근거 관리 같은 더 상위 역할로 이동합니다.



연속적인 검증(Continuous Validation)을 구현하는 데 있어 가장 큰 벽은 기술입니까, 조직입니까? 또 거대한 자동화 시스템의 신뢰성은 어떻게 확보합니까?
Kohser        저는 이 둘을 분리해서 보지 않습니다. 각 조직은 서로 다른 기술 역량, 서로 다른 워크플로우, 서로 다른 도메인 성숙도를 가지고 있습니다. 실제로는 수작업 테스트에서 자동화, 테스트 자산 표준화, 프로세스 자동화, 배포 증빙자료 (release evidence) 관리로 단계적으로 올라가야 합니다.
신뢰성 문제도 같은 맥락입니다. 실제로 더 위험한 것은 자동화 그 자체가 아니라, 분리된 툴과 수작업 인수인계, 파편화된 검증 근거로 SDV 규모의 복잡성을 관리하려는 방식입니다.
수작업은 눈에 보이기 때문에 더 안전해 보일 수 있습니다. 하지만 실제로는 불일치, 문서화되지 않은 전환, 낮은 재현성이 숨어 있는 경우가 많습니다. 반대로 관리 체계가 갖춰진 자동화는 실행을 더 가시화하고, 비교 가능하게 하고, 배포 진행 상태(release progression)를 정의된 기준 위에서 판단하게 합니다. 그것이 통제된 자동화(governed automation)의 의미입니다.

결국 핵심은 '루프의 속도'인데요. 실제로 최근 글로벌 시장에서 가장 공격적인 속도를 보여주는 중국 OEM들의 행보를 이 관점에서 어떻게 분석하십니까? 그들은 이미 새로운 운영 모델을 형성한 것입니까?
Kohser        저는 이것을 국가 간 비교라기보다 운영속도와 피드백 루프 설계(feedback-loop design)의 차이로 보고 싶습니다. 가장 큰 차이는 국가가 아니라 루프 속도입니다.
중국의 새로운 OEM들은 레거시에 덜 묶여 있습니다. 그리고 공급업체와의 협업 방식이 근본적으로 다릅니다. 독일에서는 어떤 프로젝트를 시작하기 전에 수천 페이지의 계약서를 검토해야 하는 경우가 있습니다. 그런데 중국에서는 한 장짜리 종이로 시작하기도 합니다. “좋은 제품을 함께 시장에 내자”는 합의가 먼저 있고, 그 뒤에 움직이는 식입니다. 독일에서는 모든 것을 세세히 명시하다 보니, 다 적고 나면 이미 개발 상황이 바뀌어 있는 경우도 있습니다. 2주 스프린트로 업데이트를 넣고, 바로 확인하고, 다시 개선하는 구조가 가능하다는 점이 큽니다. 
유럽이나 한국 OEM이 바꿔야 할 것을 살펴본다면, 개발·통합·검증 간 인수인계 구조입니다. 필요한 것은 테스트를 더 많이 하는 것이 아니라, 더 자주 통합하고, 사일로를 줄이고, 정리된 피드백을 기능 팀으로 직접 돌려보내는 구조입니다.






 
ADAS와 자율주행으로 갈수록 검증 구조는 어떻게 달라집니까? 시뮬레이션과 실제 테스트는 각각 어떤 역할을 맡아야 합니까?
Kohser        ADAS와 자율주행으로 갈수록 검증은 개별 기능의 합격·불합격을 확인하는 수준에 머물 수 없습니다. 이제는 다양한 상황에서 시스템이 얼마나 안정적이고 일관되게 동작하는지를 평가해야 합니다. 문제는 여기서부터입니다. 검증해야 할 시나리오와 예외 상황의 수가 폭발적으로 늘어나기 때문에 물리적 테스트만으로는 더 이상 감당할 수 없습니다. 그래서 시뮬레이션은 선택이 아니라 필수가 됩니다. 
시뮬레이션은 속도와 규모, 그리고 재현성을 제공합니다. 동일한 조건을 반복하고, 수천·수만 개의 시나리오를 병렬로 검증할 수 있기 때문에, 개발 초기 단계에서 문제를 훨씬 더 빠르게 발견할 수 있습니다. 특히 소프트웨어 통합이나 회귀 테스트에서는 시뮬레이션이 압도적인 효율을 보여줍니다. 하지만 그렇다고 해서 실제 테스트가 줄어드는 것은 아닙니다. 오히려 역할이 더 명확해집니다. 실제 테스트는 최종 확신을 위한 단계입니다. 센서 동작, 차량 거동, 실제 환경과의 상호작용처럼 현실 세계와의 일치 여부는 결국 물리적 검증을 통해 확인할 수밖에 없습니다.
결국 중요한 것은 둘 중 하나를 선택하는 것이 아니라 역할을 나누는 것입니다. 시뮬레이션은 더 넓은 학습과 빠른 피드백을 담당하고, 실제 테스트는 최종 검증과 신뢰 확보를 담당해야 합니다. 이 구조가 제대로 잡히지 않으면, 개발 속도는 빨라져도 검증이 지연되는 상황은 계속 반복됩니다.



AI와 Agentic Testing이 확대되는 가운데, 결국 SDV 시대의 성공과 실패를 가르는 결정적 차이는 무엇입니까? 그리고 한국의 엔지니어와 의사결정자들이 가장 먼저 바꿔야 할 것은 무엇입니까? 
Kohser        AI는 이미 테스트 영역에서 상당한 역할을 하기 시작했습니다. 테스트 생성, 결함 분류, 이상 탐지, 결과 요약, 원인 분석 지원 같은 영역에서는 분명한 효과가 있습니다. 실제로 우리는 자연어 요구사항에서 테스트 스펙을 만들고, 테스트 스텝을 구성하고, 결과를 클러스터링해 엔지니어가 무엇을 먼저 봐야 하는지를 바로 알 수 있게 하는 구조를 만들고 있습니다. 현장에서는 이런 변화가 굉장히 직접적으로 체감됩니다. 테스트 통과율이 10주 만에 50% 이하에서 74%까지 올라간 사례도 있었고, 어떤 엔지니어는 불명확한 데이터에 더 이상 발목 잡히지 않게 되면서 “내 삶을 되찾은 것 같다”고 표현하기도 했습니다. 데이터가 많아진 것이 아니라, 드디어 실행 가능해졌기 때문입니다. 결국 AI는 검증을 대신하는 기술이라기보다, 결과를 정리하고 무엇을 먼저 봐야 하는지를 보여주는 도구에 가깝습니다. 하지만 그렇다고 해서 AI가 모든 판단을 대신하는 단계까지 온 것은 아닙니다. 특히 출시 판단이나 기능 안전과 관련된 부분은 여전히 사람이 직접 책임을 져야 하는 영역입니다. 저희의 핵심 전략은 표준과 규범, 그리고 사람의 전문성을 AI와 결합하는 것입니다.
그래서 결국 SDV 시대의 경쟁력은 다른 곳에서 갈립니다. 더 많은 코드를 쓰는 능력이 아니라, 요구사항에서 개발, 검증, OTA, 고객 피드백까지 이어지는 전체 루프를 얼마나 빠르고 끊김 없이 운영할 수 있는가입니다. 이 루프가 빠르면 소프트웨어는 경쟁력이 되고, 이 루프가 느리면 그 투자는 결국 시장 성과로 이어지지 못합니다.
한국의 엔지니어와 의사결정자들에게 가장 중요한 변화도 여기에 있습니다. 검증을 개발 이후의 처리 단계로 보는 관점을 버려야 합니다. 검증은 개발과 함께 계속 이어지는 기능이어야 합니다. 지금의 구조는 너무 비쌉니다. 플랫폼 하나당 수백만 유로가 들어가는 방식은 장기적으로 지속 가능하지 않습니다. 이것은 엔지니어 몇 명이 더 열심히 일해서 해결할 문제가 아닙니다. 
검증 루프와 운영 모델 자체를 다시 설계해야 합니다.

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

---