[태그:] 모빌리티

차는 이미 소프트웨어다: SDV와 AI 비서의 진짜 역할

부제: 요즘 뜨거운 SDV와 AI 비서를 제품 구조 관점에서 다시 보기

서론

요즘 SDV, 피지컬 AI, AI 비서 같은 단어가 끊임없이 등장합니다.
읽다 보면 “뭔가 대단한 일이 벌어지는 것 같긴 한데, 도대체 구조가 어떻게 된다는 거지?” 하는 생각이 들 때가 많습니다. 저도 그래서, 도대체 이게 뭔 소린지 PM 관점에서 한 번 끝까지 파헤쳐 보기로 했습니다.

결국 제조사들이 말하는 SDV(Software Defined Vehicle)는 “소프트웨어로 가득찬 차”가 아니라,
‘판매 후에도 계속 업데이트·과금·데이터 수집이 가능한 플랫폼으로 차를 다시 정의’하겠다는 선언에 가깝습니다. 그리고 그 위에서 사람의 자연어를 받아 차량 전체를 움직이는 인터페이스가 AI 비서(Assistant)입니다.

한국만 놓고 봐도 현대차·기아가 SDV·피지컬 AI 관련 조직과 발표를 전면에 내세우고 있고,
완성차·빅테크 모두 “차 안의 AI”를 새로운 전장으로 삼으려는 분위기입니다. 게임/콘텐츠 도메인에서 AI 챗봇 PM를 하고 있는 입장에서, 이 흐름이 우리가 만드는 챗봇·어시스턴트와 얼마나 닮아 있고 뭐가 다른지가 궁금했습니다.

이 글에서는 ① SDV 구조, ② 그 위에서의 AI 비서 역할, ③ PM 관점에서 체크해야 할 포인트를 제품 아키텍처·데이터·가드레일 관점에서 한 번 차분히 풀어보려고 합니다.

요약하면, 이 글의 질문은 하나입니다.
“차가 이미 소프트웨어라면,
그 위에서 AI 비서는 정확히 무엇을 결정하고 어디까지 책임져야 할까?”

※ 클릭하시면 크게 보입니다.

 

1. 왜 SDV인가 — “한 번 팔고 끝” 모델의 한계

하드웨어 경쟁은 이미 상향 평준화되었습니다. 완성차 입장에서는 이제:

  • OTA(Over-the-Air Update)로 기능을 계속 추가·개선하고
  • FoD(Feature on Demand)·구독으로 반복 매출을 만들며
  • 실제 주행 데이터를 기반으로 제품 개선 루프를 돌려야 합니다.

즉 SDV는 “소프트웨어가 많은 차”가 아니라,
“팔린 이후에도 계속 업데이트되고, 돈을 버는 플랫폼”으로의 전환입니다.
한국에서도 현대차·기아가 SDV·OTA 조직을 전면에 내세우는 이유가 여기에 있습니다.

개인적으로는 완성차들이 SDV를 이야기하는 이유가
“소프트웨어 회사처럼 보이고 싶어서”라기보다,
판매 이후에도 매출과 데이터를 계속 가져가는 구조를 선점하려는 경쟁에 더 가깝다고 보고 있습니다.

2. SDV의 핵심 구조 — OS·OTA·규제까지 포함한 플랫폼

제품 구조 관점에서 SDV는 대략 이렇게 보입니다.

  • 중앙 집중형 컴퓨팅(HPC)
    고성능 SoC 기반 차량 컴퓨터가 인포테인먼트·ADAS·AI 연산을 통합 처리합니다.
  • 서비스 지향 아키텍처(SOA)
    조명, 시트, 공조, ADAS가 각각 서비스 단위로 노출되고, API로 호출됩니다.
  • 통합 Vehicle OS(MB.OS 등)
    차량 기능 전체를 하나의 OS에서 관리하는 구조가 UX·AI 통합의 기반이 됩니다.
  • OTA 파이프라인
    기능·맵·모델을 원격 업데이트하고, 롤백·버전 관리까지 포함한 운영 체계입니다.
  • 규제·보안(UNECE WP.29 등)
    소프트웨어 변경 이력·사이버 보안 요구사항을 강하게 제약합니다.

요약하면, SDV는 “API로 쪼개진 차량 기능 + 이를 관리하는 OS/OTA/규제 레이어”입니다.

3. SDV 위 AI Assistant의 역할 — UX이자 총괄 매니저

이 상위 레이어 위에서 AI Assistant는 세 가지 역할을 맡습니다.

  1. 오케스트레이터
    자연어로 들어온 의도(“나 추워”, “졸리다”)를 여러 서비스 호출로 분해·조합합니다.
  2. Deep Integration UX
    창문·공조·시트 열선·앰비언트 라이트까지 한 번에 제어하는 “행동 단위 UX”를 만듭니다.
  3. 에코시스템 인터페이스
    스마트폰·가전·차를 잇는 HyperOS류 생태계에서 기기 간 경계를 허무는 역할을 합니다.

비유하자면, SDV는 스마트 공장, AI Assistant는 그 안에서
사람의 주문을 이해해 로봇팔·컨베이어를 돌리는 지능형 운영 책임자입니다.
공장 설비가 아무리 좋아도 책임자가 오판하면… 뭔가 터진다는 건 다들 아실 겁니다.

실제 제가 챗봇 PM 일을 하면서 느낀 것도 비슷했습니다.
챗봇이 얼마나 “똑똑해 보이느냐”보다,
내부 시스템·API들을 어떻게 엮어서 실제 행동으로 만들 것인가가 결국 승부였습니다. 차량 내부에서도 AI Assistant는 같은 역할을 맡게 될 가능성이 매우 크다고 보고 있습니다.

4. AI Assistant의 동작 방식 — Intent → Plan → API

LLM 기반 AI Assistant의 기본 플로우는 다음 네 단계로 정리할 수 있습니다.

  1. Intent 파악
    음성/텍스트 → “온도 조절”, “경로 안내”, “상태 설명” 같은 상위 Intent로 변환
  2. 플랜 생성(Planning)
    필요한 차량 서비스와 순서를 정해 워크플로우 생성
    – 예: 히터 온도 +2도 → 시트 열선 1단 → 송풍 모드 변경
  3. 서비스 실행(Orchestration)
    SOA로 노출된 API를 중앙 컴퓨터(HPC)에서 호출, Latency·리소스 점유율은 별도 KPI로 관리합니다. (출처: input data)
  4. 피드백 & 로그
    3D 그래픽·음성으로 “지금 무엇을 하는지”를 설명하고,
    사고·클레임에 대비해 설명 가능한 로그로 남깁니다.

즉, “자연어 → 의도 → 플랜 → 차량 API 호출”이 AI Assistant의 기본 루프입니다.

🔹챗봇과의 차이 — 같은 Intent, 다른 결과물

일반적인 CS/서비스 챗봇은 보통 이렇게 동작합니다.

  • 챗봇
    • Intent → 라우팅 → FAQ/검색 결과/툴 호출
    • 결과물: 텍스트·링크·정보 “답변”

반면 차량 AI 비서는 한 단계가 더 붙습니다.

  • 차량 AI 비서
    • Intent → Plan 생성 → 차량 API 호출 → 실제 차량 동작
    • 결과물: 히터·창문·시트·조명 등 “물리적인 행동”

의도까지는 똑같이 해석하지만,
챗봇은 “무슨 말을 할지”를 고르고,
차량 AI 비서는 “무엇을 어떻게 움직일지”를 계획하고 실행한다는 점이 핵심 차이입니다.

그래서 “이게 피지컬 AI냐?”라고 물으면,
넓은 의미에서는 그렇다고 볼 수 있을 것 같습니다.
자연어를 받아서 실제 물리 세계(차량 하드웨어)를 움직이는 AI 오케스트레이터니까요.
다만 완전히 자율로 막 움직이게 두지는 않고,
가드레일과 규제 안에서만 행동하는 형태라는 점이 현실적인 한계이자 특징입니다.

5. 리스크·가드레일 — 어디까지 맡길 것인가

장점만큼 리스크도 분명합니다.

  • 안전(Safety)
    잘못된 Intent 해석으로 위험한 설정을 바꿀 수 있습니다.
    → 조향·제동 등은 AI의 직접 단독 제어 금지가 기본 가드레일입니다.
  • 환각(Hallucination)
    실제 차량 상태와 다른 정보를 그럴듯하게 말해 운전자가 오판할 수 있습니다.
  • 주의 분산(Distraction)
    과도한 대화·그래픽이 시야를 빼앗을 수 있어, HMI 설계에서 “운전 중 모드”가 필수입니다.
  • 규제·OTA 제약
    모델·프롬프트 변경도 WP.29 등 규제 안에서 검증·승인·롤백을 거쳐야 합니다.
  • 보안·데이터
    차량·모바일·홈 데이터 통합은 편리하지만, 해킹 시 공격 범위가 커집니다.

실제 여러 조직에서 “AI가 알아서 잘 해주겠지”라는 기대가 앞서는 모습을 자주 봅니다.
하지만 제품을 만들어보면, AI의 능력을 키우는 것 못지않게
“무엇을 절대 못 하게 할지”를 정의하는 일이 훨씬 어렵다는 걸 체감하게 됩니다.

6. PM 체크리스트 — 지금 당장 확인해야 할 10가지

AI Assistant/SDV 프로젝트를 맡은 Product Manager라면,
장기적으로는 이 10문항에 숫자로 답할 수 있는 구조를 갖추는 게 목표가 될 것입니다.

  1. 자연어 명령의 테스크 완수율(Task Completion Rate)은 어떻게 정의·측정하고 있는가?
  2. Assistant 기능의 FoD/구독 매출 기여도는 얼마나 되는가?
  3. 사고·오작동 시 AI 판단 근거를 복기할 설명 가능한 로그 구조가 있는가?
  4. 자동차 도메인 전용 데이터셋으로 LLM 환각률을 주기적으로 평가하는가?
  5. 모델/로직 업데이트 실패 시 즉시 되돌릴 OTA 롤백 프로세스가 있는가?
  6. WP.29 등 기준에 맞는 소프트웨어 변경 이력·보안 패치 체계가 운영되는가?
  7. HPC에서 AI 연산의 리소스 점유율·응답 지연 시간(p95 등) 목표는 무엇인가?
  8. AI 결정이 3D 그래픽·음성으로 운전자가 직관적으로 이해할 수 있게 표현되는가?
  9. 사용자의 루틴·상태를 활용하되, 과한 간섭 없이 선제 제안하도록 설계했는가?
  10. 스마트홈·모바일 등 외부 기기와의 연동을 위한 API 표준·버전 전략이 정리되어 있는가?

멋진 데모를 넘어서 실제 양산·운영 단계로 가는지는, 거의 이 10문항에서 갈릴 것입니다.

결론 — 한 줄로 정리하면

SDV는 차량을 소프트웨어 플랫폼으로 재정의하는 상위 레이어이고,
AI Assistant는 그 위에서 사람의 말을 받아 여러 기능을 대신 조합해주는 총괄 매니저에 가깝습니다.

결국 게임은 “얼마나 똑똑하냐”가 아니라,
얼마나 안전하고 일관되게, 그리고 수익이 나게 오케스트레이션하느냐에서 결정될 것입니다.

용어 정리 (Glossary)

  • SDV (Software Defined Vehicle)
    소프트웨어로 기능을 정의·업데이트하는 차량 구조.
    기계·하드웨어 중심이 아니라 소프트웨어·데이터·OTA가 가치의 중심이 되는 차를 의미합니다.
  • OTA (Over-the-Air Update)
    정비소 방문 없이, 무선 네트워크를 통해 차량 소프트웨어를 업데이트하는 방식입니다.
    지도, 인포테인먼트, ADAS 로직, AI 모델까지 OTA로 바뀔 수 있습니다.
  • FoD (Feature on Demand)
    차량에 이미 들어 있는 기능을 필요할 때만 유료로 열어 쓰는 방식입니다.
    예: 일정 기간 동안만 고급 ADAS, 고급 오디오 모드, 구독형 기능 등을 쓰고 과금.
  • MB.OS (Mercedes-Benz Operating System)
    메르세데스-벤츠가 개발하는 통합 차량 운영체제로, 인포테인먼트·ADAS·차량 제어를 하나의 OS에서 관리하는 SDV 전략의 핵심 사례입니다.
  • SOA (Service Oriented Architecture)
    차량 기능(조명, 시트, 공조, ADAS 등)을 “서비스” 단위로 쪼개 API처럼 호출할 수 있게 만든 아키텍처입니다.
    AI Assistant가 이 서비스들을 조합해 워크플로우를 만들 수 있게 해줍니다.
  • HPC (High Performance Computer)
    과거 여러 ECU로 나뉘던 연산을 통합하는 고성능 차량용 중앙 컴퓨터입니다.
    AI Assistant·3D 그래픽·ADAS 연산을 한 번에 처리하는 하드웨어 기반이 됩니다.
  • HMI (Human-Machine Interface)
    운전자와 차량이 상호작용하는 화면·버튼·음성 인터페이스 전반을 의미합니다.
  • UNECE WP.29 / R155 / R156
    UN 유럽경제위원회 산하 자동차 규제 포럼(WP.29)에서 만든 규정들로,
    – R155: 차량 사이버 보안 규정
    – R156: 소프트웨어 업데이트(OTA) 규정
    SDV·AI Assistant를 설계할 때 반드시 고려해야 하는 글로벌 규제 축입니다.