안전을 설계하다: E2E 아키텍처와 자율주행의 미래

The Autonomous의 패널 토론 ‘End-to-End Architectures for Autonomous Systems: From Sensors to Actuators’는 자동차 업계가 실제로 움직이고 있는 핵심 지점을 정확히 짚어냈다. 
메르세데스-벤츠, 아우디, TTTech Auto, 인피니언, 이노비즈의 주요 책임자들이 한자리에 모여 레벨 3, 레벨 4 자율주행의 안전 아키텍처를 end-to-end 관점에서 해부했다. 논의의 핵심은 분명했다. 중복성(redundancy)과 내결함성(fail-operational) 없이 고도화된 자율주행을 안전하게 지속 운용할 수 없으며, 이를 떠받치는 결정론적(real-time, deterministic) 데이터 전송과 고가용성(high availability)이 안전 방정식의 양대 축이라는 점이다. 그 토론을 빠짐없이 옮겼다.

정리 | 한 상 민 기자_han@autoelectronics.co.kr


Moderator: Ricky Hudi, Chairman of The Autonomous
                   Jennifer Sarah Boone, The Autonomous Event Moderator    
Panel:         Martin Hart, Director Automated and Autonomous SW Dev of Mercedes-Benz
                   Bernhard Augustin, Head Dev & Intg, ADAS/AD Sensors & Compute of Audi
                   Peter Schaefer, Executive Vice President and CSO Automotive of Infineon
                   Omer Keilaf, CEO & Co-Founder - Innoviz Technologies    
                   Stefan Poledna, CTO of TTTech Auto





 

Ricky Hudi        여러분은 진짜 성공사례들을 만들어낸 주인공들입니다. 우리는 이 패널 토론에서 end-to-end 자율주행 시스템을 함께 설계할 것입니다. fail-operational과 함께 시스템 아키텍처, 센서부터 액추에이터에 이르는 end-to-end 연결을 보고, 그 안에서의  통신, 미들웨어 솔루션의 필요성과 중요성도 논의할 것입니다. OTA 업데이트도 다룰 겁니다. 마지막으로 협업, 오픈소스의 필요성을 짚어보겠습니다.
첫 질문입니다. 마틴, 메르세데스 벤츠는 세계 최초로 진정한 레벨 3 시스템을 출시한 OEM입니다. fail-operational 시스템을 설계할 때 핵심 고려사항은 무엇입니까?  
Martin Hart        할 게 많지만 핵심은 대부분 중복성(redundancy)입니다. 모든 중요 체인에서 중복이 필요합니다. 센서에서 시작해 인지 단계의 의사결정, 다음의 제어, 액추에이션, 심지어 배터리 전원 공급까지도 마찬가지입니다. 결국 시스템 안에 중복성과 내결함성(fault tolerance)이 핵심입니다. 여기서 말하는 중복성은 단순히 센서를 하나 더 추가하는 것이 아닙니다. 다른 모달리티(modality)를 추가하는 것도 포함됩니다. 우리는 인지 단계에서 다양한 모달리티를 병행하는 것을 굉장히 중요하게 생각합니다. 이노비즈의 오메르(Omer)도 같은 생각일 겁니다. 실제로 우리는 인지부터 조향, 제동까지 모두에 이런 방식을 적용했고, 그 결과 세계 최초 레벨 3 시스템을 내놓을 수 있었습니다.


Ricky Hudi        첫 번째 레벨 3 시스템 개발 여정에서 예상못한 배움은 무엇이었습니까? 
Martin Hart        도로 위에 정말 기묘한 상황들이 많다는 것입니다. 미국 시장에 진출했을 때 그 차이를 실감했죠. 미국에서는 정말 고성능 시스템이 필요하다는 것을 깨달았습니다. 예를 들어 고속도로를 달리다 보면 ‘더블 덤프 트레일러(double dump trailers)’라는 것을 마주할 수 있습니다. 쉽게 말해 트럭 뒤에 두 개의 트레일러가 연결된 형태인데, 시스템은 이 두 번째 트레일러가 앞 트럭에 연결돼 있다는 사실을 정확히 인식해야 합니다. 그리고 그에 맞춰 훨씬 더 이른 시점에 반응해야 하죠. 이처럼 세상에는 참으로 다양한 상황들이 펼쳐집니다. 흔히 말하듯 ‘열린 세계(open world)’의 문제입니다. 길 위에 세탁기가 떨어져 있을 수 있는 것처럼 상상할 수 없는 일이 일어나기도 합니다.
  Ricky Hudi        맞습니다, 수많은 코너 케이스가 존재합니다. 베른하르트! 우리가 함께 아우디에서 운전자 지원 시스템의 설계와 개발을 시작했던 것 기억해요? 지금도 당신은 그 분야에서 한계를 넓혀가고 있는데요, fail-operational 시스템을 설계할 때 가장 중요하게 고려하는 것은 무엇입니까? 지난 10여 년간 이 분야에 관여하면서 얻은 가장 큰 교훈은 무엇입니까?    
Bernhard Augustin        두 가지를 말씀드리고 싶습니다. 마틴의 말처럼 아주 다양한 모달리티가 필요합니다. 이는 인지나 센서 차원에 그치는 게 아니라, 하드웨어와 아키텍처에서의 전송 방식, 각 센서의 버스(bus) 기술까지 포함됩니다. 다른 한편으로는, 실제 세상에는 정말 다양한 시나리오들이 존재한다는 것입니다. 오늘 우리가 이야기하는 것도 이 부분인데, SDV는 이런 현실 상황에 대비할 준비가 돼 있어야 합니다. 
문제는, 실제 시나리오들이 아키텍처 설계에 영향을 미치게 되면 그것을 나중에 바꾸는 것이 결코 쉽지 않다는 점입니다. 그래서 처음부터 매우 명확하게 준비해야 합니다. 예를 들어 코너 케이스들이 아키텍처에 영향을 미칠지에 대한 질문을 던져야 합니다. 더 많은 AI가 필요한지, 규칙 기반(rule-based) 중복성을 추가해야 할지? 만약 처음 아키텍처 설계에 이런 부분을 고려하지 않았다면 그걸 나중에 어떻게 구현할 수 있을지와 같은 질문을 해야 합니다. 
지금 우리가 SDV 아키텍처를 준비하고 있다고 해도 향후 몇 년 동안 이런 문제로 큰 고민을 하게 될 것이고, 중요한 건 코너 케이스를 어떻게 아키텍처에 반영할 것인가입니다. 어떤 것들은 SCM(Safety Case Management) 등으로 대응할 수 있지만, 어떤 것들은 불가능하기도 합니다. 특히 규칙 기반에서 AI로의 전환과 관련된 부분은 향후 몇 년 동안 더 중요한 과제가 될 겁니다.


 
Ricky Hudi         OEM 여러분, 왜 중요한 경험을 한데 모아 통합된 안전 아키텍처, 전체적인 안전 구조를 만들지 않는지 궁금합니다. 
피터! 인피니언 뿐 아니라 산업 전반의 관점에서 fail-operational 시스템을 설계할 때 중요 고려사항은 무엇인가요? 
Peter Schefer        차량에 본격적으로 들어오기 시작한 가장 중요 화두 중 하나가 바로 end-to-end AI입니다. 이는 과거에 봐온 접근 방식과 매우 다릅니다. 이 end-to-end AI는 우리가 레벨 4와 레벨 5에 도달할 수 있게 해 줄 것입니다. 동시에 우리가 직면할 현실은, 그 결과물을 가볍게 신뢰해서는 안 된다는 것입니다. 
새로운 아키텍처의 모습은 이렇습니다. AI 프로세서가 end-to-end 모델을 실행하는 한편, 반드시 강력한 마이크로컨트롤러, 즉 ASIL-D 등급의 세이프티 컨트롤러가 함께 있어야 합니다. 이 컨트롤러는 일종의 중재자 역할을 하며, 여기서 다시 결정론적(deterministic) 접근이 필요해집니다. 우리는 이 컨트롤러에 규칙 기반 알고리즘을 적용해 AI가 내놓은 결과가 합리적인 범위에 있는지 검증해야 합니다. 만약 그렇지 않다면, 이 컨트롤러가 즉시 백업 플랜을 실행해야 합니다. 즉, 완전히 다른 셋업이 필요하다는 것입니다. 이 방식은 분명 우리가 배우고 발전하는 데 도움이 될 것입니다. 동시에 반드시 주의해야 합니다. 강력한 AI를 활용하는 한편, 그 결정을 안전하게 만드는 두 번째 결정론적 프로세서가 반드시 자리 잡고 있어야 합니다. 


Ricky Hudi        두 번째 마이크로프로세서는 정말 중요한 부분 같습니다. 오래된 친구인 헤르만 코페츠(Hermann Kopetz) 교수와 슈테판(TTTech Auto)에게서 이 점을 배웠었지요. fail-operational 시스템은 결코 모든 것을 하나의 박스에 집어넣는 방식으로 설계해서는 안 됩니다. 절대 금지입니다. 그런데, 저는 요즘 업계에서 더 많은 기능을 하나의 SoC에 몰아넣으려는 흐름을 보고 있습니다. 물론 통합은 장점이 있지만, 분명히 한계가 있다고 생각합니다. 확립된 안전 설계 원칙을 고려했을 때 시스템 통합을 단일 칩에서 어디까지 밀어붙일 수 있을까요? 
Stefan Poledna        매우 중요한 질문입니다. 중복성 문제는 정말 핵심입니다. 우리 기준으로 보면, 대략 100만 마일 주행당 한 건의 치명적인 사고가 발생합니다. 단일 시스템으로 이 수준의 안전을 달성하려면, 통계적으로 신뢰할 수 있는 수준의 검증을 위해 약 88억 마일의 주행 검증이 필요합니다. 이는 유한한 시간 안에 결코 달성할 수 없는 규모입니다. 유일한 길은 결국 중복성을 갖추는 것입니다. end-to-end AI 모델 역시 발전을 이끌 것이고 전진에 기여할 겁니다. 하지만 그것만으로는 안전 방정식의 절반밖에 풀지 못합니다. 반드시 중복 구조가 있어야 합니다. 물리적 차원에서도 중복이 필요합니다. 중복된 센서, 서로 다른 감지 방식, 컴퓨팅, 통신, 처리, 액추에이터 측면까지 체인 전체에서 중복성이 갖춰져야 합니다. 
칩 설계도 마찬가지입니다. 단일 칩 하나에 모든 것을 의존해서는 그 수준의 안전을 달성할 수 없습니다. 칩 차원에서 반드시 중복성이 필요합니다.
덧붙여, ‘인간은 눈으로 운전하잖아? 그걸로 충분히 안전해’라는 말을 종종 듣습니다. 물론 인간은 눈으로 운전하고 상당히 안전하게 운전해 약 1억 마일당 한 건의 치명적 사고라는 수치에 도달합니다. 그런데 반드시 이해해야 할 것은 AI가 인간의 두뇌가 아니라는 것입니다. 카메라는 인간의 눈이 아닙니다. 완전히 다른 메커니즘, 전혀 다른 시스템입니다. 따라서 이 둘을 단순 비교하거나 비유하는 것은 맞지 않습니다. 


Ricky Hudi         OEM이 반도체 업체에게 운전자 지원 시스템과 콕핏 솔루션을 하나의 SoC에 통합하라고 요구하고 있습니다. 특히 fail-operational 시스템, 즉 레벨 3 이상과 관련해서 말이죠. 여러분은 이런 단일 SoC 통합에 대해 어떻게 생각하십니까? 
Martin Hart        혼합 크리티컬리티(mixed criticality), 두 가지 기능을 하나의 칩에 함께 올리는 개념이지요. 저는 이 방식이 레벨 2, 혹은 레벨 2++까지는 가능하다고 봅니다. 왜냐하면 상업적으로도 비용 측면에서도 합리적인 선택이 될 수 있기 때문입니다. 하지만 레벨 3 단계로 넘어가 차량이 운전 과업의 책임을 직접 떠맡게 되면 이야기가 완전 달라집니다. 대안이 없습니다. 반드시 연산 측면에서의 중복성이 필요합니다.
단기적으로는 알고리즘 수준에서도 중복이 필요합니다. 전통적인 룰 기반 방식과 AI 양쪽 모두에서 말입니다. 레벨 3의 도심 주행을 생각해 보면 AI 없이는 불가능합니다. 장기적으로 AI 자체가 백업 역할까지 할 수 있는 체계로 발전할 수도 있습니다. 그렇기 때문에 우리가 함께 힘을 합쳐야 합니다. Safe AI를 어떻게 구현할 수 있을지, 의사결정이 어떻게 내려지는지를 투명하게 들여다보고 시스템을 완전히 이해할 수 있도록 만들어야 합니다. 

Bernhard Augustin        기술적으로 가능하냐의 문제뿐만 아니라, 비즈니스 모델 관점에서 타당하냐를 함께 고려해야 합니다. 또, 해당 기술을 어떤 차종에 적용할 것인지, 즉 확장성 측면에서 의미가 있는지도 검토해야 합니다. 어떤 차종에서는 이런 통합이 타당할 수 있습니다. 하지만 그렇지 않은 경우, ‘혼합 크리티컬리티’와 ‘간섭으로부터의 자유(freedom from interference)’ 같은 요구사항을 충족할 수 있는지 의문이 생깁니다. 만약 이를 충족할 수 있다 하더라도, 개발 프로세스나 각 도메인에서의 반복 주기 관점에서 과연 합리적인지 따져봐야 합니다. 그리고 확장 상황에 따라 실제로 비즈니스 케이스가 성립하는지도 확인해야 합니다. 
그래서 저는 하이엔드 차량 영역에서의 대규모 통합에 대해선 회의적입니다. 왜냐하면 이 분야에는 아직도 많은 미해결 과제가 존재하기 때문입니다. 결국 자율주행은 이를 가능케 하는 기반 기술의 진화와 함께 발전할 것이고, 각 상황에 따라 지금 단계에서 전체 통합을 추진하는 것이 타당한지를 신중히 따져봐야 한다고 생각합니다.

Peter Schefer        레벨 2에서는 일정 정도의 절충과 통합이 가능합니다. 하지만 레벨 3 이상으로 올라가면 반드시 시스템을 분리해야 합니다. 물론 약간의 통합은 가능할 수 있겠지요. 레벨 3 이상에서는 안전을 위해 최소한 두 개의 독립적인 축, 즉 안전 기반 위에 이중 시스템을 세워야만 합니다.
앞으로 2~3년 안에 AI가 우리를 놀라게 할 것이라고 생각합니다. 우리는 이에 민첩하게 대응할 수 있어야 하며, 그 시점에서 어떤 구성이 최적일지를 찾아내야 합니다. 기능안전성을 이야기할 때 흔히 메인 프로세서와 그 분리가 제대로 돼 있는지, 혹은 하위에 통합돼 있는지를 논의합니다. 하지만 실제로 fail-operational 시스템을 가능하게 하는 것은 훨씬 더 많은 반도체들입니다. 예를 들어 전력분배 같은 부분도 그렇고요. 이 영역에서는 여전히 통합을 향해 나아가고 있습니다. 즉, 한편으로는 통합이 진행되고, 다른 한편으로는 분리가 이뤄지는 상황입니다. 중요한 것은 결국 유연성을 유지하는 것입니다.






 
Ricky Hudi         ‘통합 자체에 반대한다’는 게 아닙니다. 하지만 레벨 3 이상이라면 여기엔 잘 알려진 설계 원칙이 있습니다. 바로 ‘모든 것을 한 바구니에 담아서는 안 된다’는 것입니다. 이것이 중요한 이유는 만약 그 원칙을 어기고 지름길을 택했다가 치명적인 사고가 발생한다면 그 책임은 정말로 심각한 문제가 되기 때문입니다.
이제 end-to-end에 대해 살펴보겠습니다. 오메르! 여러 센서에서 나오는 데이터를 통합하는 최선의 방법은 무엇일까요? 완벽한 end-to-end 솔루션 보장을 위한 베스트 프랙티스가 있다면요? 
Omer Keilaf        저희가 보고 있는 흐름은 현재 레벨 3 시스템이 배치되는 단계에서 내년이면 실제로 레벨 4 시스템이 상용화되는 시점으로 이동하고 있다는 것입니다. fail-safe 접근 관점에서 보면, 라이다 공급업체로서 이노비즈의 책임은 가장 신뢰할 수 있고 최고 품질의 데이터를 제공하는 것입니다. 불필요한 프로세싱을 줄이고, 시간이 지나며 빠르게 변할 수 있는 AI 대신 변하지 않는 데이터를 기반으로 시스템을 구축할 수 있습니다. 따라서 데이터를 가장 정확하고 탄탄하게 제공하는 것이 무엇보다 중요합니다.
많은 사람들이 레벨 2 라이다, 레벨 3 라이다, 레벨 4 라이다의 차이는 무엇이냐고 묻습니다. 대부분은 해상도, 거리, 비용을 떠올리는데, 그것이 전부가 아닙니다. 예를 들어, 레벨 2 시스템에서는 라이다가 5분마다 잠깐 멈추더라도 크게 문제 되지 않습니다. 하지만 레벨 3에서는 그뿐 아니라 비용과 탐지 거리 등이 중요해집니다. 왜냐하면 주로 고속도로 환경에서 사용되기 때문입니다. 그리고 레벨 3에서 레벨 4로 넘어가면, 핵심은 가용성(availability)입니다. 즉, 센서가 얼마나 신뢰할 수 있고 항상 작동 가능한가 하는 점이 중요해집니다. 레벨 4에서는 운전자가 개입하지 않기 때문에 라이다는 100% 가용성을 보장해야 합니다. 뒷좌석에 가족이 타고 있다고 생각해보세요. 시스템이 센서를 청소하는 동안, 창문에 벌레가 붙어 있다는 이유 등으로 위험에 빠지면 안 됩니다. 이런 부분들이야말로 높은 수준의 안전을 논할 때 반드시 지켜져야 할 요소입니다.
그래서 저희는 여러 OEM과 협력해 다양한 시나리오를 정의하고 있습니다. 물론 이는 라이다 뿐만 아니라 모든 센서 모듈에 해당되는 이야기입니다. 한 가지 분명히 말씀드리고 싶은 건, AI 개선이나 다른 기술 발전이 이뤄진다고 해도 데이터의 품질이 항상 핵심이라는 것입니다. 소프트웨어는 시간이 지나면서 업그레이드할 수 있지만, 센서를 바꿀 수는 없습니다. 바로 그 결정이 레벨 2, 레벨 3, 그리고 그 이후의 진보를 가능하게 하는 출발점입니다. 


Ricky Hudi         end-to-end 연결을 더 깊이 들여다보겠습니다. 저와 TTTech Auto가 함께 하는 동안, 우리는 파트너, 고객들로부터 ‘왜 꼭 결정론적 데이터 전송(deterministic data transmission)이 필요한가?’란 질문을 수도 없이 받아습니다. 그리고 이제는 많은 시스템이 실제 시장에 배치되고 거기서 나온 경험들이 쌓이고 있습니다. 마틴! 당신이 직접 시스템을 시장에 내놓은 경험을 토대로, 어떤 경우에 ‘반드시 결정론적 데이터 전송이 필요하다’라고 할 수 있을까요? 또 어떤 경우에는 운영체제 내부에서 충분한 연산 성능과 대역폭이 보장된다면 굳이 결정론적 전송이 필요 없다고 할 수 있을까요?  
Martin Hart         결정론적 동작을 보장하는 것은 모든 핵심 기능을 예측가능하게 제어하기 위해 필수적입니다. 특히 끼어들기 상황이나 긴급제동과 같은 순간에는 반드시 결정론적으로 반응해야 합니다. 그래서 우리는 센서 신호처리 지연, 마이크로컨트롤러와 프로세서 간 통신, 그리고 제어 과정 전반에서 지연을 줄이기 위해 노력하고 있습니다.
다른 부분도 있습니다. 예컨대 ‘추론(reasoning)’ 같은 기능은 반드시 결정론적 순서에 따라야 하는 것은 아닙니다. 이런 부분은 클라우드에서 계산해도 괜찮을 수 있습니다. 예를 들어 ‘여기가 주차 공간인가?’, ‘이 교차로 상황은 어떻게 해석해야 하는가?’, ‘여기서 어떤 행동을 해야 하는가?’와 같은 문제들은 더 많은 시간이 허용되기도 합니다. 따라서 안전과 직접 연결된 기능들은 반드시 결정론적이고 그렇지 않은 부분들은 어느 정도 분리해 다룰 수 있습니다. 
Stefan Poledna        안전은 본질적으로 실시간 성능과 맞물려 있습니다. 앞서 언급된 것처럼, 앞으로 end-to-end AI가 본격적으로 적용될 것이고 큰 진전을 보게 될 겁니다. 하지만 이 역시 반드시 모니터링이 필요하고 중복성이 확보돼야 합니다. 만약 시스템에 중복성 설계가 돼 있다면, 언제 백업 체계로 전환할지, 또는 최소 위험 상태(minimum risk maneuver)로 전환할지를 그 순간에 신속히 결정해야 합니다. 다시 말해, 이 또한 실시간으로 결정이 내려져야 한다는 뜻입니다.
오메르가 언급한 부분에 대해 덧붙인다면, 특히 레벨 4를 위한 fail-operational 시스템을 생각할 때 안전의 의미가 달라집니다. 지금까지는 시스템을 멈출 수 있었기 때문에 비교적 단순했습니다. 뭔가 안전하지 않다고 판단되면 차량을 멈추고 운전자가 개입해 상황을 수습할 수 있었죠. 만족스럽지는 않더라도 최소한 안전은 담보됐습니다. 하지만 fail-operational 시스템에서는 이야기가 달라집니다. 운전자가 눈을 떼고 상황을 보지 않는 상태라면 단순히 ‘위험하다’ 싶을 때 바로 멈추는 선택은 통하지 않습니다. 그렇게 되면 매번 fallback이나 긴급 회피 경로(emergency path)로 빠져들게 되고, 결과적으로 시스템은 본래 해야 할 일을 수행하지 못하게 됩니다. 이는 사용자 누구에게도 만족스러운 결과가 아닐 겁니다.
따라서 안전성과 동시에 고가용성(high availability)을 반드시 확보해야 합니다. 그렇지 않으면 시스템은 늘 백업으로만 전환돼 제 역할을 못 할 것입니다. 결국 결정론적 성능과 고가용성이라는 두 가지 측면이 핵심입니다. 


Ricky Hudi        베른하르트! 그렇다면 전체적인 end-to-end 시스템 아키텍처의 안전성을 확보하기 위해서는 결정론적 데이터 전송을 반드시 설계에 포함시켜야 한다는 의미일까요?       
Bernhard Augustin        특정 사용 사례에서의 의사결정은 반드시 시간 축에서 올바르게 정렬되어야 하며 결정론적으로 이뤄져야 합니다. 하지만 동시에 전체 아키텍처 차원에서 우리가 조율해야 할 또 다른 과제가 있습니다. 모든 센서가 동일한 주파수나 동일한 업데이트 속도로 작동하는 것은 아니기 때문에 비동기적(asynchronous) 요소가 존재합니다. 그렇다면, 예를 들어 end-to-end 네트워크 안에서 토폴로지가 바뀌거나 업데이트 주기가 변하는 상황에서는 어떻게 될까요? 그런 경우 어떤 일이 일어나겠습니까? 장애 허용 시간(fault tolerant time)이나 fail-operational 요구사항을 충족하는 백그라운드 시스템은 반드시 결정론적으로 작동해야 하는 것입니다. 왜냐하면 이것이 바로 ‘fallback scenario’이기 때문입니다. 다른 하나는 완전한 성능을 목표로 하지만, 만약 그것이 제대로 작동하지 않는다면 반드시 결정론적인 백그라운드 시스템이 이를 뒷받침해야 합니다.
또, 이를 검증하기 위해서는 반드시 실시간 데이터를 활용한 시뮬레이션이 필요합니다. 즉, 비결정론적 동작을 하는 주요 부분들이 있더라도 최종적으로 중요한 의사결정은 결정론적이어야 하고, 무엇보다 그것이 실제로 올바르게 작동한다는 것이 입증돼야 합니다. 저는 이 점을 강조하고 싶습니다. 결정론적으로 작동한다는 사실이 입증될 수 있어야 합니다. 


Ricky Hudi        센서 측면에서 결정론적 인터페이스를 구현하기 위해 특별히 요구되는 사항이 있을까요? 
Omer Keilaf            일반적으로 저희에게 요구되는 것은 항상 결정론적으로 작동하는 것입니다. 결국 OEM이 다양한 조건에서 시스템을 검증하려고 할 때 센서가 너무 많은 변수에 따라 성능을 최적화하려는 기회주의적 동작을 보여서는 안 됩니다. 그렇게 되면 테스트 과정에 반영할 수 없습니다. 그들이 원하는 것은 센서가 예측가능하게 동작하는 것이고, 이를 통해 시뮬레이션을 만들어 데이터를 더 빠르게 수집하고 안전과 관련된 시나리오들을 수행할 수 있게 되는 것입니다. 따라서 센서는 안전 운용 가능성을 앞당기기 위해 반드시 예측가능하게 작동해야 합니다. 즉, 센서 내부에서 기회주의적 AI 처리를 배제하고, 고객이 언제나 센서가 어떤 방식으로 작동하는지를 명확히 알 수 있도록 해야 한다는 요구를 받고 있습니다.


Ricky Hudi        피터! 센서나 SoC 측면에서 인피니언이 이를 지원하기 위해 어떤 기술을 제공하고 있나요?
Peter Schaefer        SoC 자체보다는 결정론적 특성과 관련해 제때 정보를 확보하는 것이 더 중요한 부분이라고 생각합니다. 핵심은 결국 차량을 어떻게 합리적인 비용으로 유지하느냐, 혹은 더 저렴하게 만들 수 있느냐는 점입니다. 차량 내 배선이 지나치게 많아지고 네트워크 구조가 복잡해지고, 포인트 투 포인트(point-to-point) 통신이 많아지면 복잡성이 높아지고 비용도 올라갑니다. 이 문제를 해결하는 중요 열쇠는 이더넷을 폭넓게 사용하는 것입니다. 이미 ADAS, IVI, 존 컨트롤러 간 통신 백본으로 이더넷이 자리 잡았고, 앞으로는 노드 단에서도 저대역폭 이더넷이 도입될 것입니다. 하지만 진짜 중요한 질문은 ‘카메라, 레이다, 라이다를 어떻게 연결할 것인가’입니다. 바로 이 지점에서 TSN(Time-Sensitive Networking)과 AVB(Audio Video Bridging)를 포함한 이더넷 기반 솔루션이 역할을 하게 됩니다. 물론 이는 상당한 변화이지만 그 변화는 충분히 가치가 있습니다. 더 단순하고 비용이 낮으면서 지연도 허용가능한 수준의 시스템을 만들 수 있기 때문입니다. 저는 이것이 앞으로 몇 년간 큰 전환점이 될 것이라 생각합니다.



좌측부터 리키 후디 The Autonomous 의장과 슈테판 폴레드나 TTTech Auto CEO.


 
Ricky Hudi        아무리 시스템 안에 막대한 연산 능력이 있다 해도 그것만으로 지연을 보장할 수 없습니다. 이 또한 실제 세계에서 시스템을 배치하며 얻은 중요 교훈입니다. 시스템을 어떻게 설계할 것인가, end-to-end 아키텍처를 어떻게 만들어야 하는가, 데이터 전송을 어떻게 구현해야 하는가와 같은 질문들에 직면한 것이죠. 
그런데 여기서 OEM에 의문이 있습니다. 왜 자동차 산업은 반도체 산업이나 통신 산업에 비해 표준화 수준이 뒤처져 있는 겁니까? 무려 40년입니다. ‘fireside chat’에서 손영권 사장이 언급했듯이, 40년 전 반도체 업계에선 각자 수십 가지 방식으로 설계하던 것이 시놉시스(Synopsys), 케이던스(Cadence)와 같은 기업이 등장하면서 지금은 어떤 결과물이 나올지 모두 알 수 있는 구조가 자리 잡았습니다. 통신도 마찬가지로 GSMA, 3GPP와 같은 표준이 등장하면서, 이제 전 세계 어디 공항에 내려도 휴대폰이 곧바로 작동합니다. 
Bernhard Augustin        표준화는 어디서부터 시작할 수 있을까요? 보통은 인터페이스, 프로토콜 수준에서 시작하는 경우가 많습니다. 솔직히, 올바른 하드웨어 아키텍처를 정하는 것은 그리 쉽지 않다고 생각합니다. 아까 ‘통합은 어떻게 되는가’라는 부분과도 연결되는데, 여기서는 여러 전략이 존재합니다. 예를 들어, 중국 기업 중 하이엔드 시장을 노리는 곳들은 전혀 다른 아키텍처의 기본선을 갖고 있습니다. 이런 상황은 엄청난 다양성을 보여주지만, 다른 한편으로는 여전히 기술 발전 속도가 빠르다는 점을 보여줍니다.
이제 앞으로 3년 동안 무슨 일이 벌어질까란 질문이 따라옵니다. 다시 말해, 아키텍처와 인터페이스 표준화 측면에서 그 결과가 무엇으로 나타날까하는 것이죠. 이를테면, 전체적으로 이더넷이 될 수도 있고, 다양한 버스 기술들이 공존할 필요가 생길 수도 있습니다. 결국 목표가 무엇인가 하는 문제가 남습니다. 사실 이런 논의를 하고 나면 어떤 때는 같은 결론에 도달하기도 하지만, 전혀 그렇지 못하기도 합니다. 아직도 굉장히 넓은 선택지와 다양한 해법이 존재한다는 것, 그리고 그것이 우리가 지금 직면한 어려움이라는 점을 말하고 싶습니다.


Ricky Hudi        우리는 이미 촉매 역할을 할 수 있는 퍼즐의 한 조각을 갖고 있을지도 모릅니다. The Autonomous의 ‘안전 아키텍처(Safety and Architecture)’ 워킹그룹이 바로 그 예입니다. 이들이 함께 만들어낸 것은 정말 특별한 성과입니다. 스테판! 지난 3년간 여정을 통해 나온 결과를 조금 설명해 주시겠습니까? 참고로 두 번째 에디션은 무료로 내려받을 수 있습니다. 
Stefan Poledna        약 200쪽 분량인데, 이 문서는 아키텍처란 핵심을 정면으로 다루고 있습니다. 특히 중복성을 어떻게 구현할 것인가를 중심으로, 다양한 선택지와 여러 아키텍처 유형을 상위 수준의 기준에 맞춰 분석했습니다. 그 결과 각 아키텍처가 특정 요구사항에 대해 얼마나 잘 부합하는지를 평가하고, 일종의 순위를 매기는 방식으로 정리했습니다. 이 문서는 실제로 다운로드와 활용도가 매우 높고, 인용과 참고 사례가 늘고 있습니다. 
그리고 저는 큰 흐름에서 분명한 수렴(convergence)이 나타나고 있다고 봅니다. 즉, 점진적으로 end-to-end AI로 나아가는 주된 경로가 잘 이해되고 있습니다. 동시에 여기에는 이 경로의 결과가 특정 안전 기준에 부합하는지를 지속적으로 모니터링하는 부분이 있고, 만약 안전 문제로 이어질 경우 차량을 안전한 상태로 유지하기 위한 최소 위험 조치(minimum risk maneuver)를 수행하는 부분도 포함돼 있습니다.
지난 2년 동안의 end-to-end AI의 발전 속도가 너무나 빠르고 큰 폭의 전환이 일어나고 있기에 표준화 추진이 결코 쉽지 않다는 점도 강조하고 싶습니다. 다만 이런 높은 수준에서 보면, 모두가 공감할 부분이 있습니다. 레벨 2++를 넘어서려면 반드시 중복성 확보가 필요하다는 것입니다. 5년 전만 해도 이는 논란의 여지가 있는 주제였지만, 지금은 더 이상 그렇지 않습니다.


 
Ricky Hudi        10년 뒤, 자율주행 시스템의 전체적인 안전 아키텍처와 표준화 수준 측면에서 산업은 어디에 가 있을 것이라고 보십니까?
Peter Schaefer        fail-operational 시스템을 어떻게 구현할 것인가에 대한 공통된 합의가 이뤄질 것 같습니다. 이에 대한 명확한 기준과 표준이 마련될 것입니다. 지금은 무엇이 옳은 방법인지에 대해 불확실성이 존재하지만, 업계 전체가 좀 더 명확한 기반을 공유하게 될 것입니다. 그리고 그 위에서 AI가 기능적 진화를 이끌어 갈 것이라 봅니다.

Bernhard Augustin        스테판의 말처럼, 앞으로 3년이 지나면 이 기반 위에서 무엇을 구체적으로 바꾸고 구현해야 하는지에 대해 더 잘 이해하게 될 것입니다. 다만 과연 공통 표준 수준에 도달할까는 의문입니다. 

Martin Hart        저 역시 공통 표준이 마련될 것이라고 굳게 믿습니다. 우리는 그 목표를 향한 노력을 결코 포기해서는 안 됩니다. 당장은, AI가 자율주행을 주도하고 있기 때문에 상황이 끊임없이 요동치고 있습니다. 저는 이를 일종의 ‘폭풍기(storming phase)’라고 부르고 싶습니다. 지금은 모든 것이 급격히 변하고 있지만, 몇 년이 지나면 희망컨대 ‘성과기(performing phase)’로 접어들어 다시금 표준화와 안전에 집중할 수 있을 것이라 생각합니다.

Omer Keilaf        저는 안전(safety)을 마슬로우 피라미드의 첫 번째 층위로 봅니다. 일정 시점이 되면 이 부분은 수렴하게 되고 이후에는 차량에서 사용자가 경험하는 상위 층위로 초점이 옮겨갈 것이라고 봅니다. 레벨 3와 레벨 4가 본격적으로 등장하면 레벨 2++는 자연스럽게 뒤로 밀려날 것입니다. 사실 레벨 2는 매우 불안전한 위치입니다. 운전자의 감독이 제때 개입하기에 충분하지 못한 사례가 너무 많기 때문입니다. 레벨 3와 레벨 4가 가능해지는 순간, 레벨 2는 과거의 일이 될 것이라고 확신합니다. 

Stefan Poledna        제 관점에서, 아키텍처의 중복성은 이미 전제된 요소입니다. 이것은 반드시 확립될 것이고 수렴하게 될 것입니다. 진정한 과제는 AI를 어떻게 안전하게 만들 것인가에 있습니다. 앞으로 10년 동안 우리가 직면할 가장 큰 도전은 AI를 중복적인 방식으로 안전하게 구현하는 것입니다. 


Jennifer Sarah Boone        10년 이상 소프트웨어 업데이트를 받아야 하는 차량을 고려할 때, OEM은 하드웨어 라이프사이클 관리 계획을 어떻게 세워야 할까요? 
Bernhard Augustin          10년이란 기간을 놓고 보면 공통 표준이 마련되기는 어렵습니다. 왜냐하면 반도체 업체의 기술은 3년마다 극적으로 진화하기 때문에 그 범위를 그대로 유지하기가 불가능합니다. 그러면 질문은 ‘7~8년 지난 고객 차량에 하드웨어를 업데이트할 비즈니스 모델이 존재할 수 있는가?’로 바뀝니다. 현재로서는 고객이 그 비용을 기꺼이 지불할 의향이 있다고 보기 어렵습니다. 저희도 여러 차례 이 문제를 고민해 봤지만 솔직히 현실적으로 실현될 수 있는 뚜렷한 해법을 찾지 못했습니다. 이것이 바로 SDV의 한계라고 할 수 있습니다. 결국 차량은 3년 정도 주기로 페이스리프트가 이뤄질 때만 하드웨어 업데이트가 가능하고, 이를 일반적인 업데이트 메커니즘으로는 적용하기 어렵습니다.


Jennifer Sarah Boone         지금까지 논의된 고려사항이 사실상 매우 전통적인 자동차 업계의 사고방식을 반영하고 있습니다. 그렇다면 이와 같지 않은 새로운 진입자들과는 어떻게 경쟁할 수 있을까요? 
Peter Schaefer        새로운 진입자들도 결국 목표는 같다고 봅니다. 가능한 한 자동화된 강력한 시스템을 갖추거나 궁극적으로 자율주행을 실현하는 것을 지향한다는 점에서요. 그래서 그들 역시 fail-operational 시스템을 어떻게 구축할 것인가를 고민합니다. 10년 안에 일부 기업들은 실패할 것입니다. 모두가 아는 사실이지만, 지나치게 큰 위험을 떠안으면 결국 실패로 이어질 수 있기 때문입니다. 다만 새로운 진입자들은 기존의 역사적 짐이 없다는 장점이 있습니다. 이 때문에 완전히 새롭게 시작할 수 있고, 경우에 따라 end-to-end AI 접근법도 처음부터 적용할 수 있어 더 빠르게 움직일 수 있습니다. 그렇다고 해서 그들이 fail-operational의 중요성을 간과한다고는 보지 않습니다.

Martin Hart        경쟁은 결코 나쁜 것이 아닙니다. 새로운 플레이어들이 등장하는 것은 자동차 산업 전체에 피트니스 프로그램이 주어지는 것과 같다고 볼 수 있습니다. 동시에 우리는 우리 강점을 결코 놓아서는 안 됩니다. 안전하고, 신뢰할 수 있으며, 결함에도 대응할 수 있는 시스템을 구축하겠다는 분명한 태도를 유지해야 합니다.

Ricky Hudi         하지만 여기서 중요한 것이 있습니다. 모두가 배우고 받아들여야 할 점은, fail-operational 시스템의 설계·개발·구현·검증·검증 과정에는 이미 정립된 안전 설계 원칙들이 존재한다는 것입니다. 항공산업, 원자력 발전소, 철도에서 잘 알려진 이런 원칙은 결코 간과하거나 생략할 수 없는 것들입니다. 만약 이를 무시하거나 심지어 인식조차 하지 못한 채 건너뛰려 한다면 책임 문제에 직면했을 때 심각한 어려움을 겪게 될 것입니다.

Stefan Poledna        안전(safety)은 단순한 사고방식의 문제가 아니라 반드시 지켜야 할 절대적인 원칙입니다. 새로운 아이디어와 신선한 접근 방식은 안전을 구현하는 방법에 얼마든지 적용될 수 있습니다. 하지만 안전 그 자체에 어떠한 타협도 있어서는 안 됩니다. 그것이 중요하지 않다고 말하는 순간, 이미 잘못된 길로 들어서는 것입니다.
 

---

비전 센서만으로 자율주행 절대! 결코! 실현되지 않는다!
보쉬의 AI 선언, 레벨 2++에서 시작된 미래
The Autonomous, 안전 아키텍처 로드맵 2판 공개

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

---