차량 안팎의 변수, 42dot이 Agentic AI로 풀어야 할 문제

42dot의 협찬을 받아 요즘IT 브랜디드 콘텐츠로 제작했습니다.

“수정구! 에이동! 창업로! 사십번길 이십!”

달리는 차 안에서 목적지로 가려면, 이렇게 내비게이션에 한 글자 한 글자 또박또박 외쳐야 합니다. 아마 많은 분들이 공감하실 텐데요. 그마저도 못 알아듣는 경우가 많아, 결국 손으로 목적지를 입력하곤 합니다. 게다가 내비게이션 외에는 음성으로 차량을 제어할 수 있는 기능은 사실상 거의 없고요.

최근 일상에서 자주 사용하는 생성형 AI를 떠올리면, 더 아이러니하게 느껴집니다. 텍스트는 물론 음성 요청도 잘 알아듣고, 복잡한 작업까지 뚝딱 해주는 게 더 이상 낯설지 않기 때문입니다. 그런데 유독 ‘자동차 안’에서는 AI가 힘을 제대로 쓰지 못한다는 느낌을 지울 수 없습니다. 이는 ‘이동하는 차량’이라는 환경이 가진 독특한 제약과 기술적 난이도 때문인데요.

현대자동차그룹의 글로벌 소프트웨어 센터 42dot이 개최한 ‘Gleo AI 기술 설명회’ 역시 바로 이 고민에서 출발했다고 합니다. 이번 세션은 차량 환경에서 Agentic AI를 구축할 때 직면하는 한계를 정의하고, 이를 극복하기 위해 어떤 기술적 의사결정을 내렸는지, 현업 개발자에게 직접 들을 수 있는 자리였는데요. 요즘IT도 그 현장에서 생생한 경험담을 듣고 왔습니다.

이번 글에서는 ‘Gleo AI 기술 설명회’에서 공유된 기술적 인사이트와 직접 경험한 시승 체험을 바탕으로, 과연 ‘Gleo AI’가 차량용 AI의 난제들을 어떻게 풀어가고 있는지 그 과정을 하나씩 따라가 보겠습니다.

*Gleo AI: 현대자동차그룹의 글로벌 소프트웨어 센터인 42dot이 개발한 Vehicle-Native Agentic AI(차량 내재형 AI 에이전트). 단순히 질문에 답하는 챗봇이 아니라, 운전자의 목적을 이해하고 차량의 현재 상황을 고려해 실제 행동까지 수행하고자 하는 목적을 가짐.

왜 차량이 가장 어려운 무대일까

먼저 자동차와 AI의 관계성을 살펴보려면, 생성형 AI(Generative AI)와 Agentic AI의 차이부터 짚어볼 필요가 있습니다.

둘의 차이는 명확합니다. 생성형 AI가 질문을 이해해 답변을 만드는 데서 끝난다면, Agentic AI는 사용자의 목표를 출발점으로 상황을 관찰하고, 추론하고 계획하며, 도구를 활용해 실행하죠. 그리고 그 결과를 검증하는 단계까지 스스로 수행하며, 실제 과업을 끝까지 완수합니다.

문제는 ‘달리는 차량’이 이런 Agentic AI에게 유독 혹독한 무대라는 점입니다.

화면 속 잘못된 답변은 단순한 오류로 끝나지만, 차량 기능의 오작동은 운전자의 안전과 직결됩니다. 모든 동작이 신뢰를 바탕으로 이루어져야 하는 이유입니다. 디지털 기술이 고도화된 지금까지도 아날로그 방식의 페달과 핸들 조작에 의존하는 것 역시 명확한 제어와 안전을 확보하기 위해서입니다.

42dot은 이번 ‘Gleo AI’ 세션에서 차량 환경의 Agentic AI가 반드시 갖춰야 할 4가지 필수 조건을 명확히 정의했습니다.

• 끊임없이 변하는 상황을 따라가야 합니다(Dynamic Context): 위치, 주행 경로, 목적지, 차량 상태, 현재 화면, 직전 대화가 끝없이 움직입니다. “조금 덥네”라는 한마디도 마찬가지입니다. 에어컨을 켜달라는 뜻일 수도, 이미 켜져 있다면 온도를 낮춰달라는 뜻일 수도, 창문을 열어달라는 뜻일 수도 있습니다.
• 맥락을 통해 의도를 파악해야 합니다(Context-Dependent Intent): “가는 길”, “거기”, “첫 번째” 같은 말은 그 자체로는 무엇도 가리키지 않습니다. 차량 상태와 대화 맥락을 함께 봐야만 해석됩니다.
• 여러 기능을 하나로 엮어야 합니다(Multiple Tools & Services): 하나의 요청이 장소 검색, 내비게이션, 도착 시간 확인, 연락처, 메시지, 차량 제어를 동시에 건드립니다.
• 실행 전에 확인하고 검증해야 합니다(Safe & Verifiable Action): 차량에서 AI의 동작은 화면 속 답이 아니라 실제 물리적인 행동으로 이어집니다. 그만큼 사용자 확인, 실행 조건 재검사, 성공·실패 확인과 결과 피드백이 따릅니다.

결국 차량의 Agentic AI는 단순한 비서가 아니라, ‘변화하는 상황을 이해하고 안전한 실행까지 책임지는 운전 동반자’로 진화해야 한다는 뜻입니다. 범용 AI를 그대로 가져다 쓰는 대신, 차량 환경에 맞게 설계된 Vehicle-Native AI Agent, 즉 차량 내 AI Companion(운전자의 상황을 이해하고 실질적인 도움을 주는 동반자형 AI)을 새롭게 그려낸 이유가 여기에 있습니다.

한 문장과 여러 단계 사이의 간극

“집에 가는 길에 주차 편한 카페 찾아줘.”

운전자에겐 말 한마디로 끝나는 직관적인 요청입니다. 하지만 차량 시스템 내부에서는 이 단 한 문장을 처리하기 위해 복잡한 연쇄 판단이 시작됩니다.

• ‘집에 가는 길’: 현재 활성화된 내비게이션 경로 데이터 추출
• ‘주차 편한’: 장소 검색 필터 조건 변환
• ‘카페 찾아줘’: 경로상 유효 반경 내 검색 및 거리·소요 시간 기준 후보 정렬

진짜 난관은 그 다음에 찾아옵니다. 운전자가 “첫 번째 곳으로 안내해 줘”라고 말하는 순간, AI는 방금 자신이 제시했던 목록 데이터를 기억하고 있어야 합니다. 목적지가 새로 설정되면 즉시 도착 예정 시간(ETA)을 재계산해야 하고, 이어서 “OO에게 도착 시간 문자 보내줘”라는 요청이 들어오면 방금 계산된 ETA 데이터를 메시지 본문에 실시간으로 동기화해야 합니다.

사용자는 이 복잡한 물밑 과정을 알지 못합니다. 로직으로 풀어 쓰면 수십 줄에 달하는 작업이지만, 운전자 귀에 들리는 건 “첫 번째 카페로 안내를 시작합니다”라는 짧은 안내 음성뿐이기 때문입니다. 42dot이 이를 두고 “사용자에게는 단 한 문장이지만, 시스템에게는 수많은 모듈의 정교한 협업”이라고 정의한 이유가 여기에 있습니다. 그리고 이 간극이 바로, 이어서 설명할 세 가지 기술이 저마다 복잡해질 수밖에 없는 이유입니다.

세 가지 기술은 왜 이렇게 만들어지는가

1) 듣기의 문제: Speech Technologies

말을 이해하기에 앞서, 차량 내 AI에게 가장 먼저 주어지는 과제는 소리를 제대로 듣는 것부터입니다.

명절에 온 가족이 차로 이동하는 상황을 떠올려 봅시다. 첫째는 좋아하는 음악을 크게 틀어놓았고, 카시트에 앉은 아기는 울고 있으며, 옆에서는 어머니가 아기를 달래는 목소리가 섞입니다. 여기에 고속도로를 달리며 생기는 엔진음과 노면 소음은 덤이고요. 이런 상황에선 사실 가족끼리도 대화가 잘 안 됩니다.

차량의 음성 인식 기술이 일반 스마트폰이나, AI 스피커와 다르게 접근해야 하는 이유가 바로 여기에 있습니다. 사람조차 알아듣기 힘든 소음 속에서 오직 운전자의 목소리만 정교하게 골라내야 하기 때문이죠.

입력이 정리되면 그다음은 타이밍의 문제입니다. AI는 사용자가 자신을 부를 때만 깨어나야 하는데, 여기에도 긴장이 있습니다. 너무 예민하면 엉뚱한 말에도 깨어나고, 둔하면 정작 부를 때 못 알아듣습니다. 그래서 42dot은 호출어를 한 번에 판단하지 않고, 먼저 가볍고 빠른 모델로 후보를 걸러낸 뒤 정밀한 모델로 다시 확인하는 방식을 연구합니다. 하나의 모델로 속도와 정확도를 모두 갖기 어렵기 때문입니다.

말이 언제 끝났는지를 판단하는 것도 의외로 까다로운 문제입니다. 너무 빨리 끝났다고 판단하면 사용자의 말이 중간에 잘리고, 너무 늦게 판단하면 응답이 답답해집니다. 그 뒤에는 음성을 텍스트로 옮기는 과정이 오며, 이때는 차량에서 자주 쓰이는 지명이나, 연락처 이름 같은 고유명사를 정확히 적어내는 게 관건입니다. 마지막으로 AI가 답할 차례가 되면, 반대로 텍스트를 자연스러운 말로 바꿉니다. “220V”를 “이백이십 볼트”로 읽는 식으로요.

2) 판단의 문제: Gleo AI LLM

오늘날 우리는 흔히 ‘소 잡는 칼로 닭을 잡는’ 과소비를 하곤 합니다. 간단한 분류나 단답형 작업은 작고 가벼운 모델로도 충분한데, 습관적으로 가장 뛰어난 최고 성능의 모델만 고집하는 거죠.

개인 사용자가 구독형 서비스 내에서 쓰는 정도라면 큰 문제가 아니지만, API를 호출해 서비스하는 기업 입장에선 이야기가 완전히 달라집니다. 요청 한 번당 발생하는 비용이 소형 모델과 대형 모델 사이에 수십 배 이상 차이 나기 때문입니다. 특히 최근에는 랩탑이나 단말기(On-device)에서 무료에 가까운 리소스로도 훌륭히 작동하는 소형 언어 모델(SLM)이 다수 등장했습니다.

42dot의 LLM 파트 역시 이 지점에서 질문을 뒤집었습니다. “어떤 모델이 가장 강력한가?”가 아니라, “이 작업에 가장 적합하면서도, 빠르게 응답하고, 비용 효율적인 모델은 무엇인가?”로 묻기 시작한 겁니다.

간단한 제어나 상태 확인은 차량 내부에서 작고 빠른 모델이 처리하고, 깊은 추론이 필요한 복잡한 맥락 파악은 클라우드의 고성능 모델이 맡는 방식입니다. 단일 모델의 최고 스펙을 자랑하는 대신, ‘각 태스크에 꼭 맞는 모델을 얼마나 정교하게 골라 쓸 것인가’를 문제 해결의 중심에 둔 셈입니다.

문제 해결 방향은 찾았지만 또 다른 난관이 기다리고 있었는데요. 바로 ‘데이터’ 문제입니다.

공개된 웹 데이터에서 한국어가 차지하는 비중은 매우 작은 데다, 차량 특화 데이터는 그보다 훨씬 귀합니다. 운전 중의 자연스러운 발화, 음성 인식 오류가 섞인 입력, 그리고 에이전트의 행동 후 차량 상태 변화가 정밀하게 연결된 데이터는 웹 어디에서도 찾을 수 없기 때문입니다.

이 문제를 풀기 위해 42dot은 합성 데이터(Synthetic Data)를 연구하고 있습니다. 합성 데이터란 단순히 양을 늘리는 게 아니라, 모델 개선이 필요한 지점을 집중 생성하고 형식 검증과 품질 평가를 거쳐 다시 학습에 쓰는 순환 구조입니다.

다만, 여전히 남아 있는 문제가 있습니다. 모델이 생성한 데이터로 다시 학습을 시키면, 이미 잘하는 영역만 강화되고 정작 부족한 예외 상황(Edge Case)은 계속 방치되는 것 아니냐는 질문입니다. 모델이 자신의 오류까지 학습해 성능이 왜곡되는 이른바 ‘환각의 재생산’이나 ‘모델 붕괴(Model Collapse)’ 현상에 대한 우려입니다.

실제 현장 Q&A에서도 이와 관련된 날카로운 질문들이 이어졌는데요. 42dot 연구진 역시 이 지점이 결코 만만치 않은 과제임을 솔직하게 인정했습니다. 현재는 데이터 생성 후 엄격한 필터링 과정을 거치고, 시뮬레이션을 통해 발굴한 실패 사례를 다시 학습 데이터로 피드백하는 ‘순환 루프’를 구축하며 예외를 줄여나가는 중입니다.

주목할 점은 이 모든 단계가 따로 놀지 않는다는 겁니다. 데이터 생성부터 학습·통합·경량화·서빙·평가까지가 하나의 연결된 사이클로 돌아갑니다.

3) 실행의 문제: AI Agent

세 파트 중 AI Agent는 가장 무거운 제약을 안고 있습니다. 차 안에서의 실행은 화면 속 답변이 아니라 사이드 미러를 접고 편다거나, 메시지 발송 같은 실제 행동으로 이어지기 때문입니다. 답이 틀리면 다시 물으면 그만이지만, 주행 중에 사이드 미러가 접히면 사고로 이어질 수 있습니다. 그래서 42dot은 즉시성이 필요한 일은 온디바이스가, 복잡한 추론과 외부 서비스 연결은 서버가 맡는 하이브리드 구조를 개발하고 있습니다.

복합적인 요청은 Supervisor가 목적을 해석하고 작업으로 나눈 뒤, 내비게이션·도착 시간·연락처·메시지 등 필요한 전문 에이전트를 선택해 하나의 실행 계획으로 묶어냅니다. 그 결과는 선택한 목적지, 새 도착 예정 시간, 수신자 정보, 작성된 메시지, 확인이 필요한 실행 항목을 포함한 하나의 구조화된 결과로 정리됩니다.

안전과 관련해서는 세 가지 질문을 던집니다. 무엇이 사실인가, 무엇을 실행해도 되는가, 누가 최종 결정하는가입니다.

첫 번째는 모델의 기억에만 의존하지 않고 위치 정보·차량 매뉴얼·최신 정보를 조회해 근거를 확보하는 것이고, 두 번째는 Gleo Guard가 요청과 응답, 행동이 기준에 맞는지 판단하는 것입니다. 세 번째는 전화·문자·목적지 변경 같은 중요한 행동은 사용자 확인을 거치도록 하는 것입니다. 새 기술이니까 더 안전하다는 식이 아니라, 위험한 실행은 사용자의 확인을 거치도록 설계하고 부적절한 출력은 걸러내는 방식으로 접근한다는 점이 핵심입니다.

다만 서비스를 만들어본 사람이라면, 여기서 진짜 어려운 부분이 무엇인지 짐작할 겁니다. 확인을 받느냐 마느냐가 아니라, 언제 받느냐입니다. 매번 되묻으면 대화 한 번으로 끝난다는 에이전트의 존재 이유가 희박해지고, 반대로 지나치게 줄이면 사용자가 의도하지 않은 일이 벌어집니다. 위험도를 나누고 그 기준을 정하는 일은 안전 장치인 동시에 사용자 경험 설계의 가장 까다로운 지점이기도 합니다.

시승에서 직접 확인한 것들

기술 세션이 끝난 뒤에는 실제 차량에서 Gleo AI를 직접 써볼 수 있는 시간이 이어졌습니다. 앞서 들었던 구조가 실제 경험으로 어떻게 나타나는지 확인하고 싶었는데요. 그래서 실제로 되는지 안 되는지보다는 어떤 상황에서, 어떻게 반응하는지를 중심으로 보려고 했습니다.

우선 장소 검색, 에어컨, 사이드미러처럼 차량 기능을 조작하는 요청은 대체로 매끄럽게 이어졌습니다. 이런 작업은 차량 내부에서 바로 처리되는 영역이고, 앞서 설명된 온디바이스 실행 구조가 체감되는 지점이기도 했습니다. 문자 보내기도 흐름 자체는 의도대로 이어졌습니다. 수신자를 찾고, 내용을 구성하고, 보내기 전에 확인을 거치는 과정이 세션에서 들은 설명과 거의 그대로 연결됐습니다.

다만 “이제 끝났다”라고 말한 음성이 “이재 끝나고”라는 텍스트로 전환되는 등, 문맥을 반영한 보정이 약간 아쉬운 부분도 있었습니다. 앞서 기술 세션에서 품질과 속도 사이의 균형을 계속 조정하고 있다고 설명했던 만큼, 앞으로 이런 부분이 얼마나 더 자연스럽게 보완될지도 지켜볼 만합니다.

대화의 지속성에서도 특징이 있었습니다. Gleo AI는 ‘글레오’라는 호출어로 부를 수 있는데요. 특히 정보 검색이나 일상 대화처럼 대화가 이어질 가능성이 높은 영역에서는 응답 후에도 마이크가 열려 있어, 다시 호출하지 않고 대화를 이어갈 수 있습니다. 또한 대화 내용은 화면에 채팅 형태로 쌓여, 앞선 요청과 응답을 사용자가 직접 확인할 수 있죠. 다만 제가 주로 시도한 차량 제어나 메시지 발송처럼, 실행으로 끝나는 요청에서는 다음 요청을 위해 다시 호출어를 불러야 했습니다.

끝으로 대화 중 끼어들기(barge-in)에 대해서도 개선이 필요함을 느꼈습니다. 듣기와 말하기를 동시에 처리하는 방향을 개발하고 있다는 설명을 들었고, 실제로 시도해보기도 했지만, AI가 말하는 중간에 새 요청을 겹치면 의도가 정확히 전달되지 못하는 느낌이었습니다. 결국 호출어로 새롭게 부른 뒤에 말하거나, 응답이 끝난 뒤에 다음 요청을 하는 편이 더 편했습니다.

실제 차 안에서 직접 확인해 보니, 42dot 기술 세션에서 들었던 내용과 비슷했습니다. 구조는 대부분 그대로 연결되어 있었지만, ‘어렵다’라고 고백했던 기술적 제약들은 여전히 풀어가야 할 과제로 남아 있었습니다. 어느 한 단계의 오차, 맥락을 어디까지 이어갈 것인가, 사람과 AI가 서로의 말을 어떻게 주고받을 것인가는 실제로도 쉽지 않은 문제임을 다시 확인할 수 있었죠.

문제 정의는 끝났다

이번 Gleo AI 세션에서 가장 인상 깊었던 점은 완성된 기능이 아니라, ‘개발 과정 그 자체’였습니다. 특히 Q&A 시간에 “이어질 시승 체험에서 Gleo AI를 최대한 다양하게 써보고, 마음껏 혼내듯 피드백을 달라”는 말이 기억에 남았는데요. 직접 시승해보며 마주친 점들을 떠올리면, 이 부탁은 그냥 겸손이 아니라 현재 단계에 대한 정확한 인식에 가까웠습니다.

42dot이 그리는 앞으로의 방향은 여러 갈래로 뻗어 있습니다. 명령을 처리하는 AI를 넘어 말하지 않아도 상황을 먼저 이해하는 AI 컴패니언으로의 진화, 사용자의 맥락과 선호를 반영하는 개인화, 그리고 자율주행 시대의 차량이라는 공간을 연구 방향으로 제시했습니다.

결국 하나의 흐름으로 읽힙니다. 차량의 Human-Machine Interface(사람과 기계가 상호작용하는 방식)가 정확한 명령어를 입력하던 방식에서, 자연스러운 대화로 이동의 맥락을 이어가는 방식으로 이동하는 중이라는 거죠.

지금 42dot의 Gleo AI가 “AI Agent, Gleo AI LLM, Speech Technologies”를 하나의 End-to-End Experience(음성 인식부터 판단, 실행까지 끊김 없이 이어지는 전체 경험)로 연결하려는 이유도 결국 여기에 있습니다.

그리고 그 전환은 단순히 ‘말을 잘 알아듣는’ 기술보다, ‘주어진 상황을 어떻게 이해하고 풀 것인가’라는 문제를 먼저 정의하는 것에서 시작됩니다. 아직 답은 완성되지 않았지만, 앞으로 우리는 차량과 어떤 모습으로 소통하게 될까요? 곧 다가올 변화의 모습을 기대해 봐도 좋겠습니다.

*기술 세션에서 소개되는 일부 기술과 기능은 현재 개발 중인 내용이며, 실제 적용 범위와 제공 시점은 개발 및 서비스 환경에 따라 달라질 수 있습니다. 본 자료에는 현재 제공 중인 기능과 연구·개발 중인 기술이 함께 포함되어 있으며, 시승 중 경험한 내용은 해당 차량과 환경에서 확인한 것입니다.

글쓴이: 이재훈 작가

#42dot #GleoAI

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.