[칼럼] 소프트웨어는 구현될 하드웨어를 필요로 한다

글로벌오토뉴스 2024.01.25 조회수

265

현대가 이번 CES 2024에서 천명한 두 개의 주제는 수소, 그리고 소프트웨어였다. 지난 글에서 수소의 밸류체인 완성이 현대차그룹의 향우 사업 분야를 확장하는 커다란 그림이며 이미 견고한 기반이 준비되어 있는 반면 범 현대가와의 연합을 통한 에너지 시장 진출에서 가능성을 높일 수 있으리라는 전망을 말했었다.

오늘은 두번째 주제인 소프트웨어에 대한 의견, 혹은 조심스러운 조언이다. 미래차를 이야기할 때 SDV, 즉 소프트웨어 기반 자동차를 이야기하지 않는 자동치 브랜드는 없다. 그러나 이것이 얼마나 쉽지 않은 – 특히 대표적 종합 굴뚝 산업인 자동차 산업의 관점에서는 – 것인가는 대표적 레거시 OEM인 폭스바겐의 카리아드 프로젝트가 겪어 온 난맥상에서 확인할 수 있다. CAN BUS의 종주사로서 나름 자동차 전장 및 소프트웨어에 일가견이 있다고 자부했던 폭스바겐 그룹이었지만 차량용 운영체계까지 직접 개발하는 방식의 소프트웨어 기반 자동차로의 전환은 생각처럼 쉽지 않았다. 출시된 지 거의 1년이 다 되어서야 비로소 내비게이션을 사용할 수 있게 되었던 ID.3의 사례가 이를 증명하였고 그 이후에도 카리아드의 개발 지체가 그룹 전체의 모델 플랜에 지연을 가져왔다는 점에서도 섣부른 소프트웨어 기반 플랫폼으로의 전환은 오히려 걸림돌이 되기 일쑤였다.

이런 면에서 이번 현대차가 선언한 소프트웨어 중심의 모빌리티로의 전환은 전례들을 감안하여 탄탄한 추진 계획이 수립되기를 바란다. 그런데 이번 CES 2024에서 현대차그룹이 밝힌 소프트웨어 중심 전략의 범위는 상당히 포괄적이다. 각각의 분야에 따른 의견을 드리고자 한다.

그 첫번째는 SDV가 SDx, 즉 전체 모빌리티 생태계의 구성 요소를 소프트웨어 기반으로 구축하겠다는 ‘Software-defined everything’으로 확장된 것이다. 이를 위하여 소프트웨어와 하드웨어를 분리하여 개별적인 개발 및 업데이트가 가능한 소프트웨어 중심의 아키텍처를 구축한다는 것을 포함한다. 이 전략은 작년 송창현 사장이 천명한 ‘하드웨어와 소프트웨어의 디커플링’, 그리고 모듈 아키텍처, 아키텍처 표준화와 맥을 같이 한다.

송창현 사장은 ‘디커플링은 차량의 하드웨어 종속성을 낮추어 개발의 편의성을 높일 수 있으며, SDV 개발 속도도 획기적으로 높일 수 있다’고 말했다. 일견 맞는 말이다. 결국은 하드웨어를 활용하여 보다 다양한 고객 편의와 경험을 유연하게 개발, 제공할 수 있다는 것이 소프트트웨어만이 제공할 수 있는 부가가치이기 때문이다.

그러나 위의 송 사장의 말 가운데 ‘개발의 편의성’과 ‘개발 속도’는 조심스럽게 접근해야 할 부분이라고 생각한다. 글 뒷부분에서 말하겠지만 자동차가 소프트웨어 기반의 이동 디바이스로의 전환이라는 점에서는 자동차가 ‘바퀴 달린 스마트폰’이라고 불리워지는 점, 그리고 개발 과정에서 스마트폰의 개발 방식이 적용되는 것은 자연스러운 이종산업간의 노하우 전달 과정일 것이다. 그러나 모빌리티 디바이스로의 자동차는 소프트웨어의 개발 편의성과 속도에 유혹을 받아서는 안된다. 왜냐 하면 자동차는 결국은 하드웨어가 작동하면서 노면과의 물리적 상호작용을 통하여 이동과 조종성을 완성하는 아날로그적인 디바이스이기 때문이다.

따라서 소프트웨어의 하드웨어로부터의 디커플링은 완벽한 하드웨어의 이해를 바탕으로 해야 한다. 즉, 소프트웨어 개발을 위하여 디지털 트윈을 사용한다고 할 때, 이 디지털 트윈이 하드웨어를 완벽하게 모사하지 못한다면 그 소프트웨어는 하드웨어와 결합하여 작동할 때 원래 기획했던 대로 작동한다는 보장이 없기 때문이다. 단순히 독립적인 소프트웨어 개발은 성립되지 않는다.

그러므로 위에서 송 사장이 말했던 하드웨어와 소프트웨어의 디커플링, 모듈 아키텍처, 아키텍처 표준화는 하드웨어 개발과 소프트웨어 개발 양쪽에서 모두 이루어져야만 의미가 있다. 특히 모듈형 하드웨어 플랫폼이 완성된 뒤에 이것의 특성과 잠재 성능을 완벽히 이해하여 디지털 트윈이 완성되어야 하고, 이 디지털 트윈을 이용하여 소프트웨어의 표준화된 모듈 아키텍처가 개발되어야 한다. 이것은 종속 관계가 아니다. 소프트웨어의 연산과 위한 감지 변수를 획득하여 소프트웨어로 전달하고, 소프트웨어가 결정한 명령을 최종적으로 실천하는 것이 하드웨어이기 때문일 뿐이다. 즉, 하드웨어와 소프트웨어는 같은 목표를 위한 역할 분담이라는 뜻이다.

그리고 다시 ‘개발 편의성과 속도’ 부분으로 돌아가자. 궁극적으로는 하드웨어 개발의 많은 부분을 소프트웨어로 대체하여 개발비와 기간을 절약하는 것이 많은 회사들이 소프트웨어 기반 디바이스로의 전환에 매력을 느끼는 이유일 것이다. 심지어는 최근 제어기 OTA(Over the air) 업데이트를 두고도 소비자들은 항상 최신형인 제품에 매력을 느낀 반면 제작사들은 오류의 즉각적 – 비용 경제적인 수정에 더 큰 매력을 느끼는 것에서도 비슷한 이유를 발견할 수 있다. 즉, 개발 단계에서의 속도는 물론, 개발 당시 발견하지 못했던 오류에 OTA를 통하여 소프트웨어적으로 대응할 수 있다는 점이 전체 개발 프로세스의 속도 향상에 직간접적으로 기여한다는 것이다.

그런데 과도한 시뮬레이터 및 소프트웨어 기반 개발이 재앙적 결과를 가져 온 사례는 쉽게 찾아볼 수 있다. 데표적 예는 최근 미국 보잉이 겪고 있는 항공기 품질 사태일 것이다. 짧은 기간 내에 두 차례나 추락하여 수많은 인명 손실을 발생시켰던 보잉 737 Max는 하드웨어의 설계상 오류를 추후 소프트웨어적인 방법으로 해결하려다가 파국적인 결말을 가져온 사례다. 그리고 미 공군의 초대형 고등 훈련기 도입 사업에 순수하게 소프트웨어로만 개발하여 파격적인 가격을 제시하여 프로젝트를 수주했던 보잉이었지만 실제 시제기 개발 단계에서 예측하지 못했던 윙 락 현상이 발생하여 전체 프로젝트가 난항에 빠졌다. 무수한 개발 경험과 방대한 데이터베이스를 가진 보잉 조차도 결국은 하드웨어의 특성을 정확하게 소프트웨어로 구현할 수 없었다는 뜻이다.

우리 나라 최초의 전투기인 KF-21의 최종 개발 단계에서 사용된 아이언버드(iron bird)는 매우 훌륭한 하드웨어와 소프트웨어의 통합 검증 시스템이라고 할 수 있다. 비록 지상에 고정된 장치이지만 아이언버드는 비행 제어 소프트웨어를 물리적 액츄에이터를 통하여 실제로 구현하고 모사된 비행면 부하를 가함으로써 실제 비행 상황과 매우 유사한 환경을 구현하는 하드웨어 시뮬레이터이다. 이를 통하여 KF-21 개발진은 비행 제어 소프트웨어가 하드웨어인 기체의 특성을 정확하게 이해하고 제어하는가를 검증할 수 있었고, 그 결과 실제 시제기들의 시험 비행에서 보잉사의 사례와 같은 치명적인 오류를 발생시키지 않을 수 있었던 것이다.

다시 한 번 요약하자면 소프트웨어와 하드웨어는 디커플링될 수 없다. 소프트웨어가 하드웨어의 특성과 잠재 성능을 정확하게 이해하여 디지털 트윈을 구현한 뒤에 비로소 소프트웨어는 독자적 개발을 시작할 수 있는 것이다. 그리고 모듈 아키텍처는 하드웨어와 소프트웨어에 모두 적용되어야 한다.

CES 2024에서 현대차그룹이 소프트웨어 중심으로의 전환의 두번째 예로 든 부분은 인포테인먼트 시스템의 강화다. 이를 위하여 현대차그룹은 자체 개발한 대형언어모델(LLM)을 기반으로 하는 음성 어시스턴트와 인공지능 내비게이션, 즉 생성형 AI를 적용하겠다는 뜻을 밝혔다. 또한 외부 개발자들이 참여할 수 있는 차량용 앱 마켓을 구축하고 신속한 개발을 위하여 개발자 키트를 공유할 계획을 밝혔다.

이 두번째 방향성은 이미 스마트폰의 생태계에서 충분히 검증된 방식과 플랫폼 생태계다. 따라서 기술적으로는 커다란 난관이 없을 듯 하다. 하지만 전혀 다른 두 가지 측면에서 방향성을 결정할 필요가 있다. 첫번째는 경쟁력이다. 자동차 회사가 대형언어모델을 비롯한 인공지능 소프트웨어의 개발에서 이미 앞서나가고 있는 인공지능 전문 기업들과의 경쟁에서 이길 수 있을까? 물론 자동차 및 모빌리티 특화 사양이 있겠지만 사용자들에게 친숙한 자연어 인터페이스와 같은 소프트웨어 기업 특화 기술이 기반이라는 점은 부인할 수 없기 때문이다.

논리적으로는 우호적인 소프트웨어 전문 파트너에게 솔루션 공급을 위뢰하는 것이 옳다. 그것이 개발 속도는 물론 품질 안정성을 확보하는 가장 좋은 방법이다. 하지만 이 소프트웨어 기반 플랫폼이 미래의 주력 사업 영역이라는 점이 문제다. 카 쉐어링과 라이드 헤일링 등으로 신차 판매 대수가 감소할 것이라는 전망을 기반으로 할 때 차량의 전 연령주기를 통하여 지속적으로 수익을 창출해야 한다는 결론에 도달하고, 따라서 소프트웨어 마켓을 통한 차량 판매 후 수익이 매우 큰 역할을 담당할 것이기 때문이다. 따라서 자체 개발 혹은 수직계열화를 통하여 수익성의 극대화를 목표로 하는 것은 논리적이다.

그러나 그렇다고 해서 자동차 기업이 자체 소프트웨어 개발을 해낼 수 있다는 보장은, 그리고 경쟁력을 갖출 수 있다는 뜻은 아니다. 따라서 초기에는 외부 파트너를 통한 기반 구축과 기술 습득, 그 다음으로 계열사 내 소프트웨어 전문 기업을 통한 개념 및 선행 개발과 사내 연구소의 소프트웨어 개발 조직을 통한 실행 개발의 병행의 수순으로 순차적 – 병렬적으로 진행해야 할 것이다.

조금은 다른 분야지만 자율 주행 기술과 관련해서도 사내 연구소 주도의 레벨 3 – 모셔널을 통한 라이다 기반 레벨 4 – 비 라이다 방식의 42닷 등으로 순차적 – 병렬적으로 신기술을 개발해왔던 것은 옳은 접근이었다. 특히 모셔널 뒤에는 세계적 자율주행 전문 기업인 앱티브가 있다는 점에서 외부 파트너를 통한 초기 기반 구축이라는 목적에도 부합한다.

그러나 반년만의 연구 개발 조직 개편을 통하여 개발의 이원화를 통한 광범위한 기술 축적과 내부 경쟁보다는 일원화된, 그리고 소프트웨어 중심의 개발 쪽으로 현대차그룹의 향후 R&D의 방향성이 변경되었다. 그만큼 소프트웨어 기반 체계로의 전환에 가속할 필요가 있다는 의지의 표현일 것이다.

현대차가 코드42, 즉 현 42닷의 송창현 사장과 인연을 맺은 지, 그리고 앱티브와의 합작 기업인 모셔널을 설립한 지도 어느새 4년이 되었다. 그 사이에 42닷의 인수도 이루어졌다. 투자액에 더하여 그 동안의 누적 적자도 상당하다. 또한 2024년 정의선 회장 취임 4년차이기도 하다. 그동안 수익성에서는 상당한 실적을 보였던 정의선 휘하의 현대차그룹이었다.

그리고 이제는 미래차 기업으로서의 가시적인 전환을 보여주어야 할 때가 되었다. 하지만, 다시 한 번 당부하지만 지나친 극적 효과보다는 견실한 추진을 부탁한다. 왜냐 하면 큰 실수를 만회할 만한 시간적 여유가 없기 때문이다. 그것은 중국 전기차의 해외 약진이다. 세계적 블록화 경제 및 정치적 긴장감은 말할 필요도 없다.
소프트웨어 엔지니어와 하드웨어 엔지니어의 사고 체계는 다르다. 일하는 방법도 다르다. 따라서 섬세한 조율을 통한 ‘통역사’가 꼭 필요하다. 한 쪽만 존재할 수도 없다.

글 / 나윤석 (자동차 전문 칼럼니스트)