SDV란 코끼리를 한 입씩 먹는 법

발표 | 디르크 슬래마(Dirk Slama) 교수, digital.auto 의장 겸 보쉬 부사장
정리 | 한 상 민 기자_han@autoelectronics.co.kr









지난 1년 동안 한국에서는 어떤 일들이 있었을까요? 제가 들은 바로는, 우선 BTS가 군 복무를 마치고 돌아왔다는 소식입니다. 많은 분이 그들의 재결합을 손꼽아 기다리고 있다고 들었습니다. 그리고 ‘오징어 게임’ 시즌 3을 몰아서 보신 분 계신가요? 손 한번 들어보시겠어요? 네. 꽤 많으시군요. 
마지막으로, 아마도 지난 4개월 동안 모든 것이 인공지능 (AI)에 관한 이야기였던 것 같습니다. 여기 한국에서도 AI를 국가적인 과제로 삼고 계신 것으로 알고 있습니다. 새로 임명된 경제부총리가 이 AI 이니셔티브를 총괄하고 있다고 들었고요. 
이 컨퍼런스의 주제가 ‘소프트웨어 정의 자동차(SDV)라는 점에서, 저는 앞으로는 SDV를 넘어서 AI로 정의되는 차량, 즉 AI-Defined Vehicle에 대해 이야기할 것입니다.  



바이빙


AI의 ‘하이프 사이클 (Hype Cycle) ’을 한번 들여다보죠. 지난 2년 동안 가장 중요한 기술 트렌드가 무엇이었는지 모두 동의하실 겁니다. 바로 생성형 AI (Generative AI)였죠. 하지만 가트너(Gartner)의 하이프 사이클을 보면, 지금은 약간 기대감이 줄어드는 하강 구간에 들어섰다는 걸 알 수 있습니다. 
사실 우리 모두 느끼고 있는 부분이지만, 생성형 AI에는 아직 해결해야 할 몇 가지 문제가 있습니다. 대표적인 것이 환각 (hallucination) 현상이고요. 그리고 앤드리 카파시 (Andrej Karpathy) 가 이야기하는 ‘울퉁불퉁한 지능 (Jagged Intelligence) ’이라는 개념도 그렇습니다. 가끔은 AI가 너무 똑똑해서 감탄할 정도지만, 또 어떤 순간에는 완전히 엉뚱한 말을 하기도 합니다. 또 하나 중요 주제는 AI의 장기 기억 (long-term memory) 부족입니다. 오늘날 우리가 AI를 훈련시키고 나면, 그 안에 축적된 지식이 전부입니다. 실제 대화나 응용에서 새로운 정보를 넣어야 할 때는, 별도의 도구를 이용해 문맥창 (context window) 에 추가 정보를 슬쩍 끼워 넣는 방식이 필요하죠.

그럼에도 불구하고, 저는 이 AI라는 흐름이 우리 세계를 말 그대로 ‘고속’으로 바꾸고 있다고 생각합니다. 그리고 지금 이 순간 그 변화를 가장 뚜렷하게 보여주는 분야가 바로 코딩이라고 봅니다. SDV에 대해 이야기할 때, 결국 핵심은 ‘코딩’입니다.  제가 항상 느꼈던 점이 하나 있습니다. 코딩이라는 건 늘 같은 방식이었습니다. 코드를 줄줄이 직접 입력하면서 하나씩 시스템을 만들어가고, 마지막엔 어떤 기능을 마무리하듯 ‘마감 손질’을 하죠. 그런데 문제는, 그 이후 뭔가를 바꾸고 싶을 때였습니다. 예를 들어, 새로운 기능을 추가하거나, 데이터베이스를 바꾸거나, 아니면 기존 시스템을 클라우드 환경으로 옮기고 싶을 때…. 항상 쉽지 않았습니다. 결코 ‘매끄럽게 전환되는 경험’이 아닙니다. 상당히 어렵고, 시간이 많이 드는 일이었습니다.

하지만 요즘은 AI의 도움 덕분에 ‘바이빙 (vibing)’이란 개념이 등장하고 있습니다. 이건 기존의 코딩 방식과는 전혀 다른 느낌이에요. ‘바이빙’은 마치 도예가가 진흙 덩어리를 손으로 빚는 것과 같은 느낌입니다. 코드라는 진흙 덩어리를 두고 단지 몇 개의 프롬프트만으로 형태를 만들어 나갈 수 있는 겁니다. “이렇게 바꿔줘”, “이 기능 넣어줘” 하고 말이죠. 새로운 기능을 추가하거나 더 근본적인 아키텍처 변경까지도 그렇게 할 수 있습니다. 정말 마법 같죠.
저는 지난주에 이걸 다시 한번 실험해 봤습니다. 사실 지난 2년 동안 주기적으로 이런 AI 코딩 툴들을 써보곤 했습니다. 몇 달 간격으로 계속 시도했습니다. 솔직히 말씀드리면, 2년 전에는 꽤 실망스러운 경험이었습니다. 기술이 아직 덜 성숙했거든요.
그런데 지난주엔 정말 놀라운 경험을 했습니다. ‘유레카(Eureka)’의 순간이었죠! 그날도 AI 코딩 툴 중 하나를 가지고 장난치듯 이것저것 시험해보고 있었는데, 문득 제가 30년 동안 늘 써왔던 예제를 떠올렸습니다. 직접 공부할 때도, 코딩을 가르칠 때도 항상 써왔던 아주 단순한 시뮬레이션 예제였습니다.
그 익숙한 코드를 가지고 AI와 함께 작업을 해보니, 전혀 다른 방식으로 문제를 해결해 주는 걸 보고 정말 감탄했습니다. 그 경험은, 제가 지난 수십 년 동안 겪었던 ‘코드는 일일이 써야 하고, 구조는 손으로 다 짜야 한다’는 고정관념을 완전히 흔들어 놓았습니다.

아주 단순한 시뮬레이션이 있습니다. 물고기 (fish) 와 상어 (shark) 가 등장하죠. 상어는 물고기를 잡아먹습니다. 그런데 물고기가 충분하지 않으면 상어가 굶어 죽고, 다시 물고기가 늘어나죠. 굉장히 단순해 보이지만, 사실 제법 현실적인 생태 시뮬레이션입니다. 저는 이걸 웹 브라우저 상에서 단지 프롬프트 몇 개만으로 구현했습니다. 바로 Replit 과 같은 최신 AI 도구를 사용해서요. 그렇게 해서 살아 움직이는 시뮬레이션 시스템을 만들었습니다. 시뮬레이션된 바다에서 물고기와 상어의 개체 수가 어떻게 변하는지 시각적으로 보여줍니다. 놀라운 건, 이 시스템이 저를 위해 몇 가지 조정 컨트롤러도 자동으로 생성했다는 겁니다. 예를 들어, 상어가 얼마나 오래 굶을 수 있는지, 생존 조건 등을 제가 조절할 수 있도록 말이죠. 이 모든 과정을 제가 직접 코딩한 것이 아닙니다. 단 20분 만에, 그리고 코드 한 줄 없이, 이 정도의 복잡성을 가진 시뮬레이션을 완성해 낼 수 있었습니다. 이게 바로 생성형 AI의 힘입니다.
그리고 다음으로 다룰 주제는 요즘 엄청난 주목을 받고 있는 Agentic AI 입니다. ‘ Agentic AI ’란 말을 못 들어봤다면 귀를 막고 있었냐고 말하고 싶을 정도입니다.






  그렇다면 Agentic AI는 과연 무엇일까요? 제 생각은 단순합니다. 그건 바로, 신용카드 한 장과 노트북 한 대를 쥐여주면 스스로 무언가를 할 수 있는 AI, 즉 자율적으로 행동할 수 있는 AI입니다. 
앤드류 응(Andrew Ng)처럼 정말 스마트한 사람들은 Agentic AI의 여러 패턴을 정의해놓았습니다. 예를 들어, 문제를 더 쉽게 다룰 수 있도록 세분화해서 계획을 세우는 ‘계획 에이전트(planning agent)’, 문제 해결에 필요한 정보를 찾아주는 ‘리트리벌 기반 에이전트 (Retrieval-Augmented Agent, RAG)’, 그리고 특정 도구를 활용해 실제 문제를 해결해 주는 ‘도구 활용 에이전트 (tool-using agent)’ 등이 있습니다. 그리고 이 모든 에이전트가 협업해 일을 완수하도록 ‘오케스트레이션’된다는 개념입니다.

그럼, 조금 전의 예제에 Agentic AI 개념을 적용한다면요? Replit AI를 사용해 상어-물고기 시뮬레이션을 만들던 중이었는데, 그래프를 보다 보니 문제가 하나 눈에 띄더군요. 물고기와 상어의 개체 수를 보여주는 그래프에서 툴팁에 상어(shark)가 두 번 표시되는 UI 결함이 있었던 겁니다. 그래서 저는 그냥 프롬프트를 입력했습니다. “이 UI의 작은 오류를 수정할 수 있을까?”라고요. 여기서 중요한 건, 모두 공감하듯 AI가 전체 작업의 마지막 10%를 제대로 끝내는 것이 얼마나 어려운지 잘 알고 있다는 점입니다. 디테일을 잘 마무리하는 건 여전히 AI에게 도전입니다. 하지만 이 경우엔 놀랍게도 매우 잘 작동했습니다. AI는 문제를 인식했고, 그 문제를 고쳤습니다. 그리고 정말 신기한 것은, 수정된 애플리케이션의 스크린샷을 직접 찍고, 그 스크린샷을 분석해 정말 문제가 해결됐는지를 스스로 확인했다는 점입니다.
실제로 AI 에이전트들이 어떻게 계획을 세우고, 또 그것을 특화된 에이전트들이 실행해 나가는지를 직접 볼 수 있었습니다. 이런 일련의 흐름을 보면서, 정말 놀랍다고 느꼈습니다.

이제 이 흐름 속에서 세 번째 중요한 주제가 등장합니다. 바로 컨텍스트 엔지니어링 (Context Engineering)입니다. 좀전에도 언급했듯이, 우리는 AI를 활용하면서 기억력 문제 등 여러 과제들을 경험해 왔습니다. 그래서 지금 이 시점에 중요한 것은 생성형 AI와 Agentic AI의 맥락에서 이 컨텍스트 엔지니어링이라는 새로운 분야가 본격적으로 주목받고 있다는 것입니다.
이 컨텍스트 엔지니어링이라는 개념은, 단순히 우리가 지난 2년 동안 배워온 프롬프트 엔지니어링 (prompt engineering)을 넘어서는 것입니다. 보다 깊이 있는 개념으로, 현재 해결하고자 하는 과업에 필요한 기억 (memory), 과거 히스토리(history), 그리고 관련된 추가 문맥 정보 (context information)까지 모두 함께 다루는 것입니다. 저는 그래서 이렇게 말하고 싶습니다. 컨텍스트 엔지니어링은 우리가 주목해야 할 세 번째 핵심 개념이라고요.
그리고 이제, 이 모든 것들을 SDV에 어떻게 적용할 수 있을지를 생각해보고 싶습니다. 



 



그러니까, SDV와 AI가 만났을 때 어떤 일이 벌어질 수 있을까를 말입니다. 
분명한 건, 우리가 SDV를 이야기할 때 아마 대부분이 이렇게 말할 겁니다. “방금 말한 상어-물고기 시뮬레이션? 그건 귀엽긴 하지만, 실제로 자동차 산업에서 마주하는 복잡성과는 비교도 안돼!”라고요. 맞습니다. 현실의 자동차 개발 프로세스는 훨씬 더 복잡합니다.
예를 들어보죠. 새로운 차량 플랫폼을 개발하려면 요구사항만 해도 수십만 개, 심지어 백만 개를 넘기도 합니다. 이 모든 요구사항을 V 모델 전반에 걸쳐 정확하게 추적하는 건 사실상 불가능에 가깝다고 할 것입니다. 게다가 우리는 여전히 레거시 아키텍처를 안고 있습니다. 오늘 아침에도 AUTOSAR가 앞으로 어디로 가야 하는가에 대한 아주 흥미로운 논의를 했습니다. 이런 부분들은 여전히 핵심 과제로 남아있습니다.
그런데 진짜로 치명적인 도전은 따로 있습니다. 바로, 파생 모델 (variant)에 따라 조합 수가 기하급수적으로 증가한다는 점입니다. 이 복잡성은 우리가 반드시 해결해야 할 과제입니다. 여기다 더해, 우리는 레거시 DevOps 툴체인을 여전히 사용하고 있고 데이터는 부서별로 분리돼 있고 일관성도 부족합니다. 그리고 인증 (homologation) 프로세스도 여전히 과거의 방식에 머물러 있습니다.
자, 그렇다면 이런 모든 문제에 대한 해답은 무엇일까요?







 
어떤 엔지니어들과 이야기를 나눠보면 이렇게 말할 겁니다. “아, 문제 없습니다. 지식 그래프 (knowledge graph)를 쓰면 되죠”라고요. 그런데, 여기서 던져야 할 질문이 있습니다. 우리가 또 다른 ‘기업용 괴물’을 만들고 있는 건 아닌지, 다시 말해, 뭐든지 하나의 모델로 해결하겠다는 장기적인 관점의 5년짜리 초대형 프로젝트를 또 시작하고 있는 건 아닌지요. 과연 그게 진짜 해답일까요?
글쎄요, 일부는 도움이 될 수 있습니다만 진짜 핵심 질문은 여전히 남아 있습니다. 바로, 이 어마어마한 복잡성을 어떻게 다뤄야 할까, 이 SDV란 코끼리를 어떻게 먹을 것인가?란 것입니다. 그리고 그 해답은, 아마 여러분 모두가 알고 있는 것일 겁니다.
‘한 번에 한 입씩 (Bite by bite)!’

이 이야기는 결국 작년 이맘때로 되돌아오게 만듭니다. 작년에 우리가 무슨 얘기를 했었죠?
SDV에 대해 하드웨어 추상화 계층 (Hardware Abstraction Layers)에 대해 이야기했고, SDV의 하위 안전 계층들에서 상위 계층으로 가능한 한 많은 코드를 끌어올리자 (shift north)고 했습니다. 상위 계층은 속도도 빠르고 품질 관리만 받으면 되지만 하위 계층은 실시간성과 안전성 때문에 훨씬 보수적이어야 합니다. 
이것이 바로, ‘진흙을 빚듯’ 코드를 다듬는 바이빙 (Vibing) 방식과 정교한 작업이 요구되는 실시간 안전성 영역 사이의 차이입니다. 그리고 중요한 건, 이 두 가지 중 어느 것도 사라지지 않는다는 점입니다. AI가 분명 도움을 줄 수는 있지만, 자동차 소프트웨어 전체를 하룻밤 사이에 모두 바이빙 스타일로 바꿔버릴 수는 없습니다. 이것이 바로 SDV의 두 축 중 하나입니다. 그리고 나머지 절반은 바로, 자동차 산업 특유의 복잡성을 다루는 방식입니다. 이 복잡성을 제대로 다룬다는 것은, 우리가 애자일 (Agile)하고 점진적이며 (Incremental) 지속적인 혁신 루프 (Continuous Innovation Loop)를 가져가는 동시에 ‘처음부터 제대로 만들자 (First time right)’란 원칙과 조화를 이뤄야 한다는 뜻입니다.

그리고 받아들여야 할 사실이 하나 있습니다. 자동차 산업 내에서도 속도감이 전혀 다른 가치 흐름 (Value Stream)이 존재한다는 점입니다. 예를 들어, AI와 소프트웨어 관련된 부분은 정말 빠르게 진화하고 있지만, 메카트로닉스 같은 물리적 영역은 훨씬 더 느리게 움직입니다. 이 점을 받아들이는 것이 정말 중요합니다. 그렇기 때문에, 우리는 반드시 아키텍처적인 관점을 함께 가져가야 합니다. 계층적 아키텍처 (Architectural layering), 결합도가 낮은 구조 (loose coupling), 그리고 다중 속도 모델 (Multi-speed delivery model)이 필요합니다.







이제 이걸 다시 한번 우리가 앞서 이야기했던 AI와의 접점에서 바라봐야 합니다. 기억나시죠? 우리가 이야기했던 컨텍스트 엔지니어링(Context Engineering), 그리고 AI의 기억(Memory)에 대한 이야기들요. 이 모든 걸 종합적으로 바라보면, 우리는 결국 이 모든 요소를 하나로 엮어주는(Glue together) 능력이 필요하다는 결론에 이르게 됩니다.
그리고 이를 위해 필요한 건, 기업 전반에 걸친 거대한 지식 그래프를 수년에 걸쳐 구축하는 방식이 아니라, 지금 이 순간 직면한 문제를 중심으로, 시스템 엔지니어링이나 제품군 (product line) 엔지니어링 영역에서 직접적으로 적용이 가능한 방식이어야 합니다.
우리는 지금 당면한 문제를 해결하기 위해, 컨텍스트 캡슐 (Context Capsule), 혹은 ‘엔지니어링 라이프사이클 캡슐 (ELC)’와 같은 것을 구축할 수 있어야 합니다. 즉, 현재의 문제에 가장 적합한 지식과 상황이 포함된 작은 패키지를 만들 수 있어야 한다는 이야기입니다. 

이런 사고방식을 가지고 다시 Agentic AI의 도구들로 돌아와 봅시다. 예를 들어, 우리가 지금 어떤 문제를 다루고 있다고 해봅시다. 새로운 기능을 만들거나, 혹은 차량의 하드웨어 추상화 계층 (HAL)에 특정 API를 추가하는 비교적 작고 구체적인 작업이 될 수도 있습니다. 이런 작업을 할 때, 우리는 계획 에이전트 (Planning Agent)를 활용해 문제를 더 작은 단위로 쪼개는 것부터 시작할 수 있습니다. 예를 들어 차량용 API를 구현한다고 하면, 자동차 분야에서는 이게 그렇게 간단한 일이 아닙니다. 가장 먼저 생각해야 할 것은 물리적으로 이 기능을 구현할 수 있는 기반이 존재하는가란 점입니다. 소프트웨어로 구현하기 전에, 실제 하드웨어의 물리적 가능성을 먼저 파악해야 합니다. 이런 점들은 바로, 해당 문제를 해결하기 위한 컨텍스트 캡슐에 반드시 포함돼야 하는 내용입니다. 
이후에는, RAG (Retrieval-Augmented Generation)와 같은 에이전트를 사용해 다양한 엔터프라이즈 데이터 소스와 연결할 수 있습니다. 예를 들어, 요구사항 관리 시스템, 버전 충돌 관리 시스템, DevOps 데이터베이스, 기타 내부 시스템들과 연동해 관련 데이터를 확보합니다. 그다음엔 툴 에이전트 (tool-using agents)를 통해 수집한 데이터를 기반으로 실제 작업을 수행할 수 있습니다.






그럼 이제 좀 더 구체적인 예시를 하나 들어보겠습니다. 저희가 예전부터 자주 써왔던 예시인데요, 바로 ‘승객 환영 시퀀스(Passenger Welcome Sequence)’입니다. 이 예시를 계속 사용하는 이유는 두 가지입니다. 첫째, 많은 OEM이 실제로 이 기능을 개발하고 있다는 점이고요, 둘째, 이해하기가 쉽다는 점입니다.
이 기능은 차량이 운전자의 근접 여부를 인식하고, 자동으로 승객 환영 시퀀스를 실행하는 것을 의미합니다. 예를 들면 이렇습니다. 운전자가 다가오면 자동으로 도어를 열고, 클라우드에서 운전자의 선호 설정을 불러와, 차량의 언어 설정, 시트 위치, 공조 시스템 (HVAC) 설정 등도 자동으로 조정하는 것입니다. 이 시나리오는 결국 우리가 이 전체 시퀀스를 세부 단계로 나누고 (Break down), 하나하나 차근차근 구현해야 한다는 것을 보여주는 예시입니다.

자, 실제로 어떻게 할 수 있을까요? 이건 아주 빠르게 움직이는 밸류 스트림 상에서 처리돼야 할 문제입니다. 만약 이게 만 번 중 한 번이라도 제대로 작동하지 않는다면, 물론 그건 이상적인 상황은 아닙니다만 그렇다고 해서 큰 피해를 주는 것도 아니죠. 반면, 그 시퀀스에 포함된 요소 중 하나가 ‘문 열림 (open door)’이라면 이야기는 다릅니다. 이건 훨씬 민감하고 중요한 기능입니다. 하지만 전체적인 관점에서 볼 때, 승객 환영 시퀀스의 고수준 오케스트레이션 (high-level orchestration)은 점진적으로 개선할 수 있는 부분이고, 애자일 원칙을 적용해 개발할 수 있는 좋은 영역입니다.
자, 이제 이 ELC 캡슐을 구축하기 위해서는 무엇이 필요할까요? 가장 먼저 해야 할 일은 요구사항을 이해하는 것입니다. 아시다시피, 요구사항이 수백만 개나 됩니다. 그런데 이렇게 수많은 요구사항 중에서, 정말로 우리에게 중요한 건 무엇인지 어떻게 골라낼 수 있을까요? 그래서 digital.auto 프로젝트 안에서 실험을 해봤습니다. 우리가 시도한 건, 일종의 요구사항 레이다 (requirements radar)를 만드는 것이었습니다. 레이다의 개념은, 중심에 우리가 작업하고 있는 기능에 가장 중요한 요구사항을 배치하고, 그 외곽으로 점점 중요도가 떨어지는 요구사항을 배치하는 방식입니다. AI는 이 구조 안에서 여러 시스템, 예를 들어 DOORS, Rhapsody, Polarion 등 어디에 숨어 있든 간에 요구사항을 자동으로 찾아내고, 해당 기능에 적합한 요구사항을 선별합니다. 이렇게 추출된 요구사항은 규제 요건일 수도 있고, 기능적 요구사항이나 비기능적 요구사항일 수도 있습니다. 이게 바로 ELC 캡슐 구축의 출발점입니다. 
다음 단계는 본격적인 구현 단계입니다. 이제 승객 환영 시퀀스와 관련된 고객 여정, 글로벌 규제, 그리고 우리만의 아이디어를 바탕으로 요구사항을 충분히 이해했고 실제로 구현하기 시작합니다. 

이 구현 과정 역시 AI의 도움을 받아야 합니다. 물론, 여기서 AI가 코드를 생성한다든가 하는 것도 포함됩니다. 하지만 요구사항과 실제 코드 사이의 간극을 완전히 메우기 위해선 여전히 몇 가지 단계가 더 필요합니다. SDV에서 간극을 메우기 위해 차량 API (vehicle API)가 아주 중요한 역할을 합니다. 이와 관련해 digital.auto는 현재 Eclipse 재단 내에서 오픈소스 프로젝트를 운영 중입니다. 최근에는 이 프로젝트를 확장하면서 AI 에이전트 기능을 네이티브하게 내장하기 시작했습니다. Vehicle API Explorer란 도구는 COVESA의 API 카탈로그를 기반으로 하고 있으며, 현재 그 안에는 1,200개 이상의 차량 신호(vehicle signals)가 최하위 수준에서 정의돼 있습니다.

이제 해야 할 일은, 지금까지 수집한 승객 환영 시퀀스에 대한 요구사항 중 어떤 요구사항이 실제로 인터페이스와 연결돼 있는지 파악하는 것입니다. 그래서 AI에게 “지금 내가 필요한 인터페이스를 보여줘”라고 하면, 당연히 AI가 제시하는 인터페이스는 좌석을 움직이는 기능, 문을 여는 기능 등입니다. 그런데 흥미롭게도, 이 AI는 계획 상태 (planning status) 같은 추가 정보도 제공합니다. 예를 들어, 화면에서 ‘시트 이동 (moving the seat)’ API가 존재하고, 커밋됨 (committed) 상태라고 돼 있는데, 이 API는 차량이 양산에 들어갈 때 실제로 해당 기능이 구현될 것이라는 의미입니다. 즉, 양산 시점에서 이 API가 제대로 작동할 준비가 돼 있다는 것입니다. 반면에, 같은 예시에서 ‘문 열기’ 기능은 차량 API 카탈로그에는 등록돼 있지만, 아직 커밋되지 않은 상태라고 나옵니다. 양산 시점에 이 기능이 지원된다는 확실한 보장이 아직 없다는 뜻입니다.








그렇다면 이제 AI가 해야 할 일은, 이 문제를 더 세부적으로 나눠서 분석하는 것입니다. 즉, 이 API가 커밋되려면 정확히 무엇이 필요한가란 질문에 답할 수 있도록 도와줘야 합니다. 예를 들어, ‘문 열기 API’가 커밋되려면 어떤 기능이 필수로 갖춰져야 할까를 고려하면 먼저 차량에 도어 모터를 실제로 장착할 계획이 있는지를 알아야 합니다. 이런 결정은 메카트로닉스 설계와 밀접하게 관련돼 있습니다. 도어 모터를 장착하지 않기로 했다면 문을 여는 API를 ECU에 구현하는 것은 무의미할 수 있습니다. 이처럼, 하드웨어와의 의존성이 강한 부분일수록 API가 실제 구현 가능할지 여부를 판단하는 데 더 많은 분석이 필요합니다.

여기서 AI는 또 하나의 역할을 합니다. AI는 이 문제와 관련된 사람 간의 연결 관계, 작업 간 의존성, 업무 흐름 등을 이해하고, 시스템 안에서 이들 요소를 기반으로 의존 관계 (dependency)를 생성할 수 있습니다.
그리고 기분 좋게 승객 환영 시퀀스를 구현하고 있을 때에도 AI는 이렇게 말해줍니다. 
“잠깐만요, 아직 ‘문 열기’ 기능과 관련된 중요한 의존성이 해결되지 않았어요”라고요. AI는 우리에게 중요한 미해결 요소가 남아있다는 걸 상기시켜주고, 그 문제를 해결하지 않는 이상 전체 시스템 구현에 문제가 생길 수 있다는 점을 알려줍니다. 이제 우리는 다시 요구사항 분석 단계로 돌아가야 합니다. 다음으로 이 기능을 어떻게 하면 안전하게 구현할 수 있을지를 고민해야 합니다. 
예를 들어, ‘문 열기’는 단순한 기능이 아니고 승객 환영 시퀀스의 일부이기도 하지만 하드웨어 의존성이 크고 구현 속도도 느릴 수밖에 없습니다. 그래서 우리는 다시 새로운 문제에 직면하게 됩니다. 이 문제는 이른바 ‘조금 더 느리게 움직이는 트랙’에 속한 작업입니다.

이제 해야 할 일은 명확합니다. 요구사항을 구현 방식에 맞춰 어떻게 매핑할 것인가, 그리고 그 기능을 실제로 어떻게 구현할 것인가를 구체적으로 설계해야 합니다. 구현 단계에서 우리는 좀 더 진보된 코드 중심 도구 (code-centric tools)를 활용합니다. 예를 들면, ETAS의 임베디드 AI 코더 (Embedded AI Coder)와 같은 것입니다. 우리가 이야기하는 건, 이런 종류의 안전 관련 기능 (safety-relevant features)을 구현하는 과정을 실제로 가속화하는 데 도움이 되는 도구입니다. 이런 도구를 활용할 수 있다고 가정했을 때, 다음으로 중요한 질문은 당연히 이것이 테스트 관점에서는 어떤 의미를 가지는가입니다.
현재 우리는 두 개의 ELC 캡슐을 갖고 있습니다. 이는 당면히 두 가지 작업에 필요한 모든 데이터를 담고 있습니다. 그다음 해야 할 일은 이 ELC 캡슐을 더욱 풍부하게 만드는 것입니다. 예를 들면, 테스트 전용 데이터, 테스트 케이스, 테스트 구현, 테스트 실행 결과 등을 이 안에 추가해 나가는 것입니다. 궁극적으로는, 이 모든 것들이 글로벌 마스터 테스트 플랜 (global master test plan)과 연결돼야 합니다. 결국 시스템 전반에서의 테스트 전략, 계획과 일관성을 유지해야 하기 때문입니다. 




마지막으로, 이 모든 것을 마무리하면서 언급하고 싶은 주제가 하나 더 있습니다.
바로 형식 승인 (homologation)입니다. 이건 사실상 우리가 생각하는 것보다 훨씬 앞 단계, 그러니까 V 모델의 오른쪽 끝이 아니라 왼쪽 시작점에서부터 시작돼야 할 항목입니다. 즉, 개발 초기 단계부터 고려돼야 한다는 뜻입니다. 그래서 다시 ELC 캡슐로 돌아와야 합니다. 이번에는 여기에 형식 승인과 관련된 데이터, 예를 들어 적용 대상이 되는 글로벌 규제 정보를 추가해야 합니다. digital.auto는 이를 위해 Certivity 같은 파트너 회사들과 협력하고 있습니다. 이들은 AI를 활용해 전 세계에 흩어져 있는 수많은 규제, 수천 개의 PDF 문서에 흩어진 규제 정보를 스캔하고 분석합니다. 이 과정에서, AI는 각 규제가 어떤 시스템이나 기능에 적용되는지를 판단하고 그 내용을 정리합니다. 그렇게 해서 ‘사전 형식 승인 평가 (homologation pre-assessment)’라는 프로세스를 시작할 수 있게 됩니다. 이 평가가 어떤 걸 알려주느냐 하면, 예를 들어 전체 승객 환영 오케스트레이션의 경우에는 상대적으로 가벼운 형식 승인 절차로 처리할 수 있습니다. 왜냐하면 이 기능은 안전 관련 핵심 기능이 아니기 때문입니다. 반면, 이 시퀀스에서 사용하는 여러 개별 모듈, 예컨대 ‘문 열기’ 같은 기능은 매우 중요한 안전 관련 기능이기 때문에 보다 복잡하고 엄격한 형식 승인 절차를 반드시 거쳐야 합니다. 그래서 이런 차이를 고려해 계획을 세우고 AI 기반 플래닝 에이전트가 제안한 형식 승인 계획 데이터를 사람 전문가와의 협업을 통해 점검하고 보완합니다.
이런 방식으로 우리는 데이터를 준비하게 됩니다. 그리고 준비된 정보를 바탕으로 서로 다른 속도로 움직이는 여러 개의 밸류 스트림을 따라 시스템을 실행하고 검증할 수 있게 됩니다. 이 밸류 스트림은 다중 속도 개발 프로세스 (multi-speed delivery)의 일부입니다.


 

이 모든 이야기를 종합해보면, 제가 여러분께 오늘 보여드리고 싶었던 건 바로 우리가 현재 어떤 방향으로 가고 있는지에 대한 단면입니다. 우리는 지금 SDV에서 AI 정의 자동차(AI-Defined Vehicle)로 전환하는 과도기에 있습니다.
오늘 이 발표의 핵심 메시지는 이겁니다. 
“이 복잡한 문제를 한 번에 다 해결하려고 하지 말고, 한 번에 한입씩(bite at a time) 문제를 나누고, 다중 속도 개발 시스템의 맥락 안에서, 그리고 현존하는 AI 인프라 수준에 맞춰 각 단계를 분해하고 해결한다”는 것입니다. 
이를 위해 우리는 ELC 캡슐이란 개념을 사용합니다. 이 캡슐은 요구사항, 상황, 메모리 등 모든 정보를 포함하며 각 단계를 ‘씹을 수 있는 크기(digestible bites)’로 잘게 나눌 수 있도록 도와줍니다. 그렇게 우리는, 조금씩, 그러나 끊임없이, AI와 함께 앞으로 나아갈 수 있습니다.

---