Blog

Filter by Tags
Filter by Teams
Gleo Guard l 차량 AI Agent를 위한 안전 가드레일
Tech2026.09.11

Gleo Guard l 차량 AI Agent를 위한 안전 가드레일

Gleo Guard l 차량 AI Agent를 위한 안전 가드레일 * 본 이미지는 생성형 AI 기술을 활용하여 제작되었습니다. LLM 기반 AI Agent는 이제 단순히 질문에 답하는 수준을 넘어, 사용자의 요청을 이해하고 실제 기능 실행까지 연결하는 방향으로 발전하고 있습니다. 특히 차량 안에서 동작하는 AI Agent는 내비게이션, 통화, 메시지, 차량 기능 제어처럼 실제 행동으로 이어질 수 있는 기능과 연결됩니다. 그래서 차량 AI Safety는 일반적인 챗봇 안전성보다 더 넓은 범위를 다뤄야 합니다. 42dot의 Gleo Guard는 이러한 문제의식에서 출발했습니다. Gleo Guard는 Gleo AI가 사용자의 발화를 안전하게 이해하고, 차량 환경에서 실행 가능한 요청인지, 위험하거나 부적절한 요청인지, 응답 시 어떤 범위를 지켜야 하는지를 판단하는 가드레일 모듈입니다. 단순히 특정 단어를 차단하는 필터가 아니라, 사용자의 의도, 차량 내 사용 맥락, 국가·언어별 정책, 기능 실행 가능성을 함께 고려합니다. 이번 글에서는 Gleo AI LLM 으로 Gleo Guard 를 개발하며 얻은 경험을 소개합니다. 핵심은 더 작은 모델로 더 빠르고 효율적인 추론을 만들면서도, 차량 AI Agent에 필요한 안전성과 정확도를 함께 끌어올리는 것이었습니다. 1. Gleo Guard 소개: 차량 안의 AI를 위한 안전 판단 레이어 Gleo Guard는 Gleo AI 앞단에서 사용자의 발화를 먼저 확인합니다. 사용자의 요청이 안전한지, 제한이 필요한지, 혹은 차량 기능으로 이어져도 되는지 판단합니다. 차량용 AI Agent에서 가드레일이 중요한 이유는 명확합니다. 일반 챗봇은 부적절한 답변을 생성하지 않는 것이 주된 목표일 수 있지만, 차량 AI는 실제 행동과 연결됩니다. 예를 들어, 사용자의 말 한마디가 목적지 검색, 전화 걸기, 메시지 전송, 차량 기능 실행으로 이어질 수 있습니다. 따라서 Gleo Guard는 “이 질문에 답해도 되는가?”뿐만 아니라 “이 요청을 차량 환경에서 실행해도 되는가?”를 함께 판단해야 합니다. 이때 가장 어려운 문제는 과도한 차단과 과소 차단 사이의 균형입니다. 위험한 요청은 반드시 제어해야 하지만, 정상적인 차량 기능 요청까지 막으면 사용자 경험이 크게 나빠집니다. 예를 들어, 사용자가 음식점 이름에 민감한 단어가 포함된 장소를 검색할 수도 있고, 연락처 이름에 비속어가 들어 있을 수도 있습니다. 반대로 표현은 평범해 보여도 실제 의도는 불법 행위, 개인정보 침해, 프롬프트 탈취일 수 있습니다. Gleo Guard는 이러한 경계 사례를 단어가 아니라 맥락과 의도 중심으로 판단하도록 설계되었습니다. Gleo Guard는 침착하고 믿음직한 조수석 동승자입니다. 운전자의 요청을 자연스럽게 돕되, 차량 환경에 맞지 않거나 안전을 해칠 수 있는 요청은 실행 전에 판단하고 제어합니다. Gleo Guard의 목표는 더 많이 차단하는 것이 아니라, 차량 안에서 Gleo가 더 안전하고 신뢰할 수 있는 방식으로 작동하게 하는 것입니다. 2. Gleo Guardrail Policy: 무엇을 허용하고, 무엇을 제한할 것인가 그림 1. Gleo Guard 의 차단 정책 Gleo Guard의 정책은 크게 두 가지 관점으로 구성됩니다. 첫 번째는 명확히 위험한 요청을 제한하는 Critical 정책 입니다. 불법 행위, 자해, 혐오, 프롬프트 인젝션 등과 관련된 내용이 여기에 포함됩니다. 예를 들어, 범죄 실행 방법이나 무기 제작법처럼 실제 피해로 이어질 수 있는 요청은 제공하지 않고, 대신 예방·신고·안전 확보처럼 허용 가능한 범위의 정보를 안내합니다. 두 번째는 맥락에 따라 조심스럽게 다뤄야 하는 Caution 정책 입니다. 투자나 의료 조언과 같은 내용은 차단만으로 해결하기 어렵습니다. 이러한 요청은 사실 기반 설명, 중립적 비교, 안전한 표현, 전문가 상담 권고처럼 허용 가능한 범위를 명확히 분리해야 합니다. 응답 원칙도 단순합니다. 위험한 요청에는 짧고 명확하게 거절하고, 가능한 경우 안전한 대안을 제시합니다. 합법성이나 사실관계가 불확실한 경우에는 단정하지 않고 공식 채널이나 전문가 확인을 권합니다. 또한 국가별 정책이 필요한 항목은 사용 지역과 언어 맥락을 함께 고려합니다. 차량 AI Safety 관점에서 중요한 예외도 있습니다. 병원이나 약국을 찾는 요청은 의료 진단이 아니라 내비게이션 기능일 수 있습니다. 연락처 조회 요청은 개인정보 침해처럼 보일 수 있지만, 사용자의 연결된 모바일 기기에 저장된 연락처를 확인하는 정상 기능일 수 있습니다. Gleo가 지원하는 공개 기능이나 음성 명령을 묻는 것은 허용되지만, 내부 프롬프트나 비공개 도구 정의를 요구하면 제한해야 합니다. 이런 예외를 처리하는 것은 차량 AI Agent에서 과도한 차단을 줄이는 핵심 요소입니다. 3. Policy-to-Data: 합성데이터 생성 방법 그림 2. Policy-to-Data Generation Workflow Gleo Guard의 핵심 작업 중 하나는 문서로 정의된 안전 정책을 모델이 학습할 수 있는 데이터로 변환하는 일이었습니다. 이를 위해 정책을 기준으로 가드레일의 판단 경계를 체계적으로 탐색하는 Policy 기반 LLM-as-an-attacker 워크플로우 를 구성했습니다. LLM-as-an-Attacker 란 LLM이 정책에 기반한 적대적 사용자 역할을 수행하며, 부적절한 콘텐츠를 요청하거나 제한된 행동을 유도하는 프롬프트를 생성하여 가드레일의 취약한 판단 경계를 체계적으로 탐색하는 방법입니다. Gleo Guard에서는 여기에 정상 요청이 과도하게 차단되는 경우까지 함께 점검할 수 있도록, 허용·제한 조건과 예외 사항을 반영한 대조적 경계 사례 생성으로 범위를 확장했습니다. 이 접근에서는 합성데이터 구축의 전체 과정이 하나의 정책 기반 공격 시나리오 탐색 워크플로우로 동작합니다. 첫번째 단계 로는 각 정책을 라벨 단위로 정리하고, 허용 규칙, 제한 규칙, 기대 행동, 차량 AI Agent에서 필요한 예외 조건을 정책 카드로 구조화했습니다. 정책 카드는 Attacker가 어떤 부적절한 콘텐츠 요청이나 제한된 행동 유도 요청을 생성해야 하는지, 그리고 어떤 정상 요청이 과도하게 차단될 수 있는지를 탐색하는 기준이 됩니다. 두번째 단계 에서는 각 정책 카드에서 생성 조건을 구성했습니다. 생성 조건에는 적용할 정책, 허용 또는 제한 여부, 사용자의 의도, 기대하는 응답 방식, 단일·다중 대화 여부, 차량 기능 실행과의 연관성 등이 포함됩니다. 명확한 Safe 또는 Unsafe 사례뿐 아니라, 표면적인 표현만으로는 정책 판단이 어려운 경계 사례를 중점적으로 구성했습니다. 세번째 단계 에서는 구성한 생성 조건을 바탕으로 다양한 사용자 요청과 대화 사례를 생성했습니다. 예를 들어 직접적인 위험 표현을 피하면서 부적절한 콘텐츠를 생성하도록 유도하는 요청, 일상적인 표현으로 제한된 기능 실행을 요청하는 사례, 여러 대화 턴에 걸쳐 위험한 의도를 점진적으로 드러내는 사례를 생성했습니다. 반대로 민감한 표현이 포함되어 있더라도 저장된 연락처에 전화를 걸거나 특정 장소를 검색하는 정상적인 차량 기능 요청처럼, 단순한 키워드 기준으로는 과도하게 차단될 수 있는 허용 사례도 함께 생성했습니다. 차량 기능 실행과 관련된 사례는 Action-Aware 데이터 로 구성했습니다. 전화 걸기, 메시지 전송, 목적지 검색, 연락처 조회, 일정 등록, 차량 기능 제어 등 실행 가능한 후보 행동을 추상적으로 표현하고, 해당 행동을 허용할지, 차단할지, 추가 확인이 필요한지를 함께 정의했습니다. 실제 전화번호, 주소, 메시지 원문이나 내부 도구 인자를 사용하는 대신, 정책 판단에 필요한 행동 유형과 대상 유형만 포함했습니다. 생성된 데이터의 예시는 다음과 같습니다. 네번째 단계 에서는 별도의 검증기를 통해 적용된 정책이 올바른지, 생성된 요청이 의도한 허용·제한 조건과 일치하는지, 기대 행동과 Action gate가 적절한지를 확인했습니다. 또한 부적절한 콘텐츠를 답변 형태로 직접 포함하거나, 위험한 실행 정보가 지나치게 구체적이거나, 개인정보가 포함된 사례는 제거했습니다. 또한, Gleo Guard는 공개 안전성 데이터도 보완적으로 활용했습니다. 자체 워크플로우가 놓칠 수 있는 혐오, 공격성, 자해, 프롬프트 인젝션 등의 패턴을 보완하기 위해 공개 데이터를 Gleo Guard의 Canonical Label 로 매핑하고, 언어별 정리와 중복 제거를 거쳐 학습 데이터에 포함했습니다. 이 과정을 통해 Gleo Guard의 학습 데이터는 단순한 Safe/Unsafe 분류 데이터가 아니라, 정책의 판단 경계를 체계적으로 공격하고 검증하여 구축한 데이터가 되었을 뿐만 아니라, 차량 AI Agent가 실제 상황에서 요청을 거절할지, 안전한 대안을 안내할지, 정상적인 차량 기능으로 수행할지까지 학습할 수 있는 action-aware 데이터로 구성했습니다. 4. Aligning to Policy: 모델이 정책을 따르도록 학습하기 Gleo Guard 학습 방법 정책을 반영한 데이터를 구축한 이후에는, 모델이 실제 서비스 환경에서도 일관되게 정책을 따르도록 학습해야 합니다. 이를 위해 Gleo Guard는 SFT와 RL을 단계적으로 활용했습니다. 먼저 SFT(Supervised Fine-Tuning, 지도 미세조정) 는 사전 학습된 언어 모델에 입력과 기대 출력이 짝을 이룬 데이터를 제공하고, 모델이 주어진 입력에 대해 목표 출력을 생성하도록 추가 학습하는 방법입니다. 일반적으로 LLM의 SFT에서는 사용자 지시와 이에 부합하는 응답으로 구성된 데이터를 사용해, 다음 토큰을 예측하는 기본 언어 모델을 실제 사용자의 지시를 따르는 모델로 조정합니다. 이를 통해 모델은 학습 데이터에 명시된 출력 형식과 기본적인 판단 기준을 직접 익힐 수 있습니다. Gleo Guard의 SFT 단계에서는 사용자 발화와 대화 맥락을 입력으로 사용하고, 해당 요청이 어떤 정책 라벨에 해당하는지와 어떤 방식으로 응답해야 하는지를 학습합니다. 예를 들어, 요청을 허용할지 또는 제한할지를 정답 데이터로 제시합니다. 이 단계에서는 모델이 Gleo 정책의 기본적인 경계를 이해하고, 차량 AI Agent에서 기대하는 판단과 응답 방식을 안정적으로 익히도록 합니다. 이후 RL(Reinforcement Learning, 강화학습) 단계에서는 모델이 생성한 결과에 대한 평가를 보상 신호로 활용해, 더 높은 보상을 받는 판단과 응답을 선택하도록 모델을 조정합니다. SFT가 정답 예시의 출력을 직접 학습하는 방식이라면, RL은 여러 가능한 출력 중 어떤 결과가 정책과 기대에 더 잘 부합하는지를 평가하고, 그러한 결과가 생성될 가능성을 높이는 방식입니다. 이번 RL 학습에서는 GRPO(Group Relative Policy Optimization) 를 활용했습니다. GRPO는 하나의 입력에 대해 여러 응답을 생성한 뒤, 각 응답의 보상을 그룹 내에서 상대적으로 비교하여 정책을 업데이트하는 방식입니다. 이를 통해 별도의 value model 없이도 상대적인 보상 정보를 활용하여, 모델이 더 높은 품질의 응답을 생성하도록 최적화할 수 있었습니다. Gleo Guard의 RL 단계에서는 사람이 검수한 신호를 활용하여 모델의 정책 판단을 더욱 정교하게 조정합니다. SFT를 통해 정책의 기본적인 허용·제한 기준을 학습한 뒤, 실제 서비스에서 발생할 수 있는 미묘한 경계 사례에 대해서도 더 적절한 판단을 내리도록 보완하는 과정입니다. 예를 들어 SFT만으로는 비속어가 포함된 요청을 모두 위험한 요청으로 판단할 수 있지만, RL을 통해 “비속어가 포함되어 있더라도 저장된 연락처에 전화를 거는 정상적인 요청” 과 같이 표현상의 위험 신호와 실제 사용자의 의도를 구분하고, 서비스 정책에 맞는 판단을 학습할 수 있습니다. 또한 Gleo Guard는 다양한 서비스 정책 변화에 대응할 수 있도록 예시 기반 학습 능력도 함께 학습합니다. 학습 과정에서는 동일한 정책을 다양한 시스템 프롬프트와 예시(Few-shot Example) 형태로 구성하여, 예시가 추가되거나 변경되어도 정책을 일관되게 적용할 수 있도록 학습했습니다. 또한 학습시 특정 예시만 암기하는 것을 방지하기 위해 혼동 할 수 있는 예시를 함께 사용하여 모델의 강건성을 높였습니다. 이를 통해 SFT에서는 정책의 기본적인 판단 기준과 응답 형식을 학습하고, RL에서는 사람의 검수 신호를 바탕으로 경계 사례에 대한 판단을 더욱 정교하게 조정했습니다. 그 결과, Gleo AI LLM 이 Gleo 정책에 따라 일관되고 안정적으로 판단할 수 있도록 학습하였습니다. 5. 실험 결과: Safe / Unsafe 이진 판정 성능 평가는 두 가지 관점에서 진행했습니다. 첫 번째는 Gleo Guard 자체가 입력 발화를 Safe/Unsafe로 잘 분류하는지 보는 평가입니다. 두 번째는 실제 Gleo 응답까지 생성한 뒤, 최종 응답이 안전한지 다시 평가하는 E2E Safety Test입니다. 아래 표는 42dot 내부에서 구축한 평가셋에서 측정한 Safe/Unsafe 분류의 Macro Accuracy 입니다. Macro Accuracy는 Safe와 Unsafe 각각을 올바르게 분류한 비율을 구한 뒤 동일한 비중으로 평균한 지표로, 클래스별 데이터 수의 차이에 영향을 덜 받으면서 두 클래스에 대한 균형 잡힌 분류 성능을 나타냅니다. 구분 모델 Macro Accuracy 42dot model Gleo Guard 98.26% API model (OpenAI) GPT-5.5 88.78% API model (OpenAI) GPT-5.6-luna 88.00% API model (OpenAI) GPT-5-mini 86.96% API model (Claude) Sonnet-5 80.40% API model (Claude) Haiku-4.5 79.17% Open model Qwen3.5-35B-A3B 79.55% Open model Qwen3.5-4B 81.88% * 본 결과는 당사 내부에서 자체적으로 구축한 평가셋을 바탕으로 동일한 시험 조건에 따라 측정한 결과입니다. 실제 서비스 환경에서의 성능은 사용 환경, 데이터 특성 및 시스템 운영 조건 등에 따라 달라질 수 있습니다 . Gleo Guard는 API model 과 open model을 포함한 비교 대상 중 본 내부 평가에서 가장 높은 성능을 기록했습니다. 특히, OpenAI에서 공개한 최신 모델인 GPT-5.6-luna 대비 Unsafe 요청을 Safe로 잘못 판단하는 오류는 7.50%에서 1.66%로 감소했으며, Safe 요청을 Unsafe로 과도하게 차단하는 오류는 16.50%에서 1.82%로 감소했습니다. 그 결과, Macro Accuracy는 88.00%에서 98.26%로 10.26%p 향상되었습니다. E2E Safety Test에서는 입력 분류 성능뿐 아니라 Gleo가 실제로 생성한 최종 답변이 안전한지도 평가했습니다. 이를 위해 LLM-as-a-Judge 방식을 활용했습니다. LLM-as-a-Judge 란 별도의 LLM이 평가자 역할을 맡아, 주어진 평가 기준에 따라 다른 모델의 응답 품질이나 정책 준수 여부를 판정하는 방법입니다. 이번 평가에서는 전체 대화 문맥과 마지막 Gleo 응답을 함께 입력하고, 응답이 안전한지, 정책에서 요구한 방향에 맞게 답변했는지, 위험한 요청을 올바르게 거절했는지, 허용 가능한 요청을 과도하게 거절하지 않았는지를 평가했습니다. 구체적으로 15,010건의 테스트케이스에 대해 Gleo AI의 답변을 생성한 뒤, Kanana Safeguard 8B 모델의 LLM-as-a-Judge 를 활용해 [user question, assistant answer] 쌍을 다시 판정했습니다. 평가는 최종 응답의 Safe/Unsafe 여부뿐 아니라, 필요한 경우 올바른 거절과 안전한 대안이 포함되었는지, 일부라도 위험한 요청을 따르지는 않았는지, 정책에 맞는 답변이었는지를 종합적으로 확인했습니다. 그 결과 위험 답변은 668건에서 246건으로 줄었고, 위험 비율은 4.5%에서 1.6%로 낮아졌습니다. E2E 평가 기준 API model Gleo Guard 변화 Safe 응답 수 14,342 14,764 +422 Unsafe 응답 수 668 246 -422 Unsafe 비율 4.5% 1.6% -2.9%p 이 결과는 학습한 모델이 단순히 분류 점수만 개선한 것이 아니라, 실제 Gleo의 최종 응답 안전성에도 영향을 준다는 점을 보여줍니다. 또한 기존 SAFE 답변이 새 실행에서 UNSAFE로 전환되는 비율, 즉 누출률도 약 3% 수준에서 0.91%로 낮아졌습니다. 이와 같은 내부 검증 환경에서는 개선 케이스가 악화 케이스보다 4.2배 많아, 단순 재생성 노이즈가 아니라 Gleo Guard 의 실질적인 효과로 해석했습니다. 6. 향후 계획: 글로벌 AI 윤리와 레드티밍 자동화 Gleo Guard 는 앞으로 더 빠르고 정확한 판단, 과잉 탐지 감소, 글로벌 확장을 목표로 고도화할 계획입니다. 첫 번째 방향은 차량 위치에 따른 AI 윤리 적용 입니다. 같은 요청이라도 차량이 위치한 국가, 언어, 문화, 종교, 법·제도, 사회적 정서에 따라 다르게 해석될 수 있습니다. 예를 들어 위기 상황 안내 번호, 의료·법률 안내 방식, 정치적 민감도, 상업적 성 서비스 관련 정책, 영토·역사 표현, 브랜드·제품 비교에 대한 허용 범위는 지역별로 달라질 수 있습니다. 앞으로는 차량의 locale, jurisdiction, 언어 설정, 사용자 맥락을 더 정교하게 반영해 지역별 안전 정책을 적용할 예정입니다. 두 번째 방향은 레드티밍 자동화 입니다. 현재의 레드티밍은 전문가가 Gleo의 반응을 보며 실시간으로 취약 패턴을 찾고 인사이트를 제공하는 방식으로 운영되었습니다. 앞으로는 이 과정을 자동화하려고 합니다. 정책 카드와 실제 서비스 로그에서 레드티밍 시나리오를 생성하고, Gleo 실행 결과를 외부 평가 모델과 정책 verifier로 검증한 뒤, 실패 케이스를 다시 합성데이터 생성 파이프라인으로 재투입하는 구조입니다. 차량은 이동하는 공간입니다. 사용자는 운전 중이고, 동승자가 있을 수 있으며, 어린이나 청소년이 함께 있을 수도 있습니다. 그래서 차량 AI Safety는 단순한 응답 안전성 검증을 넘어, 실제 행동과 사용 맥락, 지역 정책, 사용자 경험까지 함께 고려해야 합니다. Gleo Guard는 Gleo AI가 더 똑똑한 Agent가 되는 것뿐 아니라, 실제 차량 환경에서 신뢰할 수 있는 Agent가 되기 위한 기반 기술입니다. • 조성국 Seongkuk Cho (Senior AI Engineer) ㅣ Gleo Core Team Gleo AI가 사용자에게 더욱 안전하고 신뢰도 높은 응답을 제공할 수 있도록 가드레일 기술과 안전성 평가 체계를 개발하고, 지속적으로 서비스 품질을 개선하고 있습니다. • 장준원, Joonwon Jang (AI Model Engineer) ㅣ Gleo Foundation Team Gleo AI의 다양한 기능을 지원할 수 있도록 42dot LLM Model의 post-training을 담당하고 있으며, 지속적으로 모델 성능을 개선하고 있습니다. 7. 참고문헌 [1] Perez, E., et al. “Red Teaming Language Models with Language Models.” Proceedings of EMNLP , 2022. [2] Choi, D., et al. “COMPASS: A Framework for Evaluating Organization-Specific Policy Alignment in LLMs.” arXiv preprint arXiv:2601.01836 , 2026. [3] Ouyang, L., et al. “Training Language Models to Follow Instructions with Human Feedback.” Advances in Neural Information Processing Systems , 2022. [4] Bai, Y., et al. “Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback.” arXiv preprint arXiv:2204.05862 , 2022. [5] Bai, Y., et al. “Constitutional AI: Harmlessness from AI Feedback.” arXiv preprint arXiv:2212.08073 , 2022. [6] OpenAI. “GPT-4 System Card.” Technical Report , 2023. [7] Zheng, L., et al. “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.” Advances in Neural Information Processing Systems , 2023. [8] Zhao, H., et al. “Qwen3Guard Technical Report.” arXiv preprint arXiv:2510.14276 , 2025. [9] Kanana Safeguard Team. “Kanana Safeguard.” Hugging Face Model Card, 2025.
42dot Work&Way l Ep5. 42dot Silicon Valley
Culture2026.09.07

42dot Work&Way l Ep5. 42dot Silicon Valley

How do the minds shaping the future of mobility think, make decisions, and push boundaries? The Work & Way series offers an inside look at 42dot’s way of working and its team members. In Episode 5, we’re stepping inside 42dot Silicon Valley! From UX and design to autonomous driving, machine learning and AI, Product Intelligence, TaaS, and the Real-time Platform, Jeff orchestrates across technical disciplines within the organization to ensure teams with different expertise work toward a shared goal. Explore the Work & Way of the 42dot Silicon Valley—where our teams tackle tough engineering problems, collaborate seamlessly, envision new possibilities for mobility, and turn that vision into real-world change. Watch the full episode now.
42dot Work&Way | How Developers Work at 42dot | Ep4. Autonomous Driving
Culture2026.09.07

42dot Work&Way | How Developers Work at 42dot | Ep4. Autonomous Driving

How do developers at 42dot work, grow, and shape their culture? Discover the stories from within. Our new series, Work&Way, spotlights the teams and technologies behind 42dot. Through interviews, we explore what it means to make progress at 42dot — from development workflows and collaboration practices to the engagement programs that enable focus and growth. In Episode 4 of Work&Way — a series where 42dot developers share firsthand accounts of how they work and thrive – we hear from 이성진 about his work on AD Division. Meet a 42dot developer from the Atria AI Group – the very heart of our autonomous driving platform – as he builds toward a safer and more reliable future for autonomous driving through iterative testing across real-world roads and simulation environments. Watch the full story now.
42dot Work&Way | How Developers Work at 42dot | Ep3. Vehicle OS
Culture2026.09.07

42dot Work&Way | How Developers Work at 42dot | Ep3. Vehicle OS

How do developers at 42dot work, grow, and shape their culture? Discover the stories from within. Our new series, Work&Way, spotlights the teams and technologies behind 42dot. Through interviews, we explore what it means to make progress at 42dot — from development workflows and collaboration practices to the engagement programs that enable focus and growth. In Episode 3 of Work&Way — a series where 42dot developers share firsthand accounts of how they work and thrive – we hear from 이준희 about his work on Vehicle OS Group. Watch the full story now.
42dot Work&Way | How Developers Work at 42dot | Ep2. Connectivity Framework
Culture2026.09.07

42dot Work&Way | How Developers Work at 42dot | Ep2. Connectivity Framework

How do developers at 42dot work, grow, and shape their culture? Discover the stories from within. Our new series, Work&Way, spotlights the teams and technologies behind 42dot. Through interviews, we explore what it means to make progress at 42dot — from development workflows and collaboration practices to the engagement programs that enable focus and growth. In Episode 2 of Work&Way — a series where 42dot developers share firsthand accounts of how they work and thrive – we hear from Sechan Choi about his work on Connectivity Framework Team. Watch the full story now.
How do developers at 42dot work, grow, and shape their culture? Discover the stories from within.
Culture2026.09.07

42dot Work&Way | How Developers Work at 42dot | Ep1. Gleo AI

How do developers at 42dot work, grow, and shape their culture? Discover the stories from within. Our new series, Work&Way, spotlights the teams and technologies behind 42dot. Through interviews, we explore what it means to make progress at 42dot — from development workflows and collaboration practices to the engagement programs that enable focus and growth. In Episode 1 of Work&Way — a series where 42dot developers share firsthand accounts of how they work and thrive – we hear from Jisang Yoo about his work on Gleo AI, an LLM-powered agentic AI for in-vehicle experiences. Watch the full story now.
Continual learning from data stream to insight
Tech2024.09.02

Continuous Model Performance Improvement through Active Learning

To implement reliable autonomous driving technology, it's essential to accurately reconstruct the 3D environment around the vehicle in real-time. At 42dot, we are advancing autonomous driving technology by continuously collecting data and tracking model performance to develop high-performance 3D perception models that operate in real-time. 1. The Problem of Duplicate Predictions in Object Detection Models and Its Impact Autonomous vehicles reconstruct their surrounding environment to identify the location of obstacles, predict the movement of other vehicles and pedestrians, and plan a safe driving route. Therefore, the accuracy of the 3D object detection model, which is the first step in the autonomous driving system, significantly affects the vehicle's operation. At 42dot, we continuously collect data to evaluate and improve our models. When evaluating the model with recently added data, we found that in cases where 4-5 pedestrians were gathered in a small area, more duplicate predictions occurred than the actual number of pedestrians. These duplicate predictions can ca1use the autonomous vehicle to recognize non-existent objects, potentially leading to abnormal movements. While we can reduce false detections by increasing the prediction score threshold in the post-processing stage, this may increase the number of undetected pedestrians, posing a safety risk. When the score of predicted pedestrians is low, the probability of the detected object being a duplicate prediction increases. 2. Active Learning Pipeline To improve the model's weaknesses, 42dot operates an Active Learning Pipeline that continuously collects data from similar cases and includes it in network training. To efficiently incorporate newly collected data into model training with minimal human intervention, we use a high-performance model that operates offline. The knowledge learned from this high-performance model is then distilled into the real-time model operating in the vehicle, improving its performance. 3. Introduction of Transformer Model Structure Recent object detection models [1, 2] have significantly improved performance by introducing transformer structures. Transformers allow object queries to exchange information between objects through self-attention and utilize the entire information of the feature map, providing richer information than CNN structures. In particular, transformer-based object detection models use one-to-one matching between ground truth and predictions during training, which is highly effective in suppressing duplicate predictions. These characteristics of transformer models are expected to effectively solve the pedestrian duplicate prediction problem and greatly improve pedestrian detection performance. 4. Utilizing Denoising Techniques However, contrary to expectations, simply introducing a transformer-based object detection model did not result in significant performance improvements. To identify the cause of the problem, we analyzed the number of object queries per class in the model. In densely populated urban areas, we found that the number of object queries generated around pedestrians was very high, causing instability in the learning process when matching the generated object queries with ground truth. To solve this, we applied the Dense Distinct Query [3] technique introduced at CVPR 2023, which helped resolve the issue and secure learning stability. 5. Performance Improvement Results By introducing these various technologies, we have significantly reduced the number of pedestrian duplicate predictions while greatly improving the model's precision. Additionally, the prediction quality of pedestrian location, size, and direction of movement has been further improved. This enhanced high-performance model is applied to vehicles to improve driving performance. 42dot is committed to continuously developing and researching technology to make autonomous driving safer. Youngseok Kim, Juhan Cha (Intern) ⎢ AD Algorithm We are developing technology to help autonomous vehicles understand their surroundings faster and more accurately. Reference [1] Nicolas Carion et al., “ End-to-End Object Detection with Transformers ,” ECCV, 2020. [2] Xuyang Bai et al., “ TransFusion: Robust LiDAR-Camera Fusion for 3D Object Detection with Transformers ,” CVPR, 2022. [3] Shilong Zhang et al., “ Dense Distinct Query for End-to-End Object Detection ,” CVPR, 2023.
Multilingual chat bubbles surrounding LLM text
Tech2024.03.29

42dot LLM 1.3B

We have previously released our large language model (LLM), 42dot LLM. The released 1.3 billion parameter models were trained using our own carefully collected internal data and training infrastructure. 42dot LLM stands out as a Korean-English bilingual model, being the first of its kind to be accessible to the public in Korea. Our model demonstrates superior performance on various quantitative and qualitative benchmarks compared to other competitive models of similar size. The release comprised two types of LLMs: 42dot LLM-PLM, a Pre-trained Language Model, and 42dot LLM-SFT, a Supervised Fine-Tuned language model, which was fine-tuned from the PLM to better align with human usability. [Demo of 42dot LLM] https://huggingface.co/42dot/42dot_LLM-PLM-1.3B https://huggingface.co/42dot/42dot_LLM-SFT-1.3B 1. SFT Model Supervised Fine-Tuning is a technique that uses a small, carefully labeled dataset to adjust the weights and biases of a pre-trained model to make it more aligned for a specific task. Incorporating a diverse range of instruction-following data in the fine-tuning dataset can enhance the usability of a language model (LLM), making it more human-friendly for communication and interaction. Large language models that are aligned through this technique are termed SFTs, in order to differentiate from the models aligned using a different alignment technique called reinforcement learning with human feedback (RLHF). One of our released models, 42dot LLM-SFT was aligned in this way. And you can interact and communicate easily with this model similar to the well-known ChatGPT. 2. LLaMA Architecture 42dot LLM consists of transformer decoders like the other LLMs, and is constructed with an architecture compatible with LLaMA, one of the most popular LLMs open-sourced by Facebook (Meta). We opted to align our architecture with LLaMA primarily to ensure compatibility with well-established open-source frameworks. Consequently, our models seamlessly run on popular frameworks, enabling their application in Korean contexts. This stands in contrast to LLaMA models, which lack support for the language. It's essential to note that our models were developed from scratch and are qualitatively different and independent of the available LLaMA models. 3. Model Size The 42dot LLM consists of 24 layers, resulting in around 1.3 billion parameters in total. It was trained with over 1.4 trillion tokens, which is of similar scale to the other open-source LLMs such as the above-mentioned LLaMA. We emphasize again, unlike the other LLMs, our data includes a large amount of high-quality Korean texts as well as English texts, resulting in a Korean-English bilingual model that can understand both languages fluently. 4. Tokenizer The process of parsing a sentence into smaller units, such as words or syllables, is called tokenization. These units form a vocabulary utilized by a tokenizer to represent texts in a machine-readable format, presented as a sequence of tokens for processing by Language Models (LLMs). The Byte-Pair Encoding (BPE) algorithm, among various methods, is employed to build such a vocabulary. BPE dissects text into bytes or characters, retaining the most frequently occurring pairs. This method proves particularly advantageous for the Korean language, a highly agglutinative language rich in morphology with a unique writing system. Representing the Korean language poses challenges due to varied ways words and phrases can be tokenized depending on context. BPE adeptly captures these nuances by representing the language as a sequence of sub-word tokens, which can be combined to form larger linguistic units such as words or phrases. Given these advantages, 42dot LLM utilizes BPE tokenization, a choice also embraced by other prominent models like OpenAI's GPT. A custom dictionary, comprising approximately 50,000 BPE sub-word tokens in both Korean and English, was crafted by sampling from a vast pool of over 10 million documents. 5. GPU Training Cluster 42dot has garnered a large amount of compute in order to train powerful LLMs by establishing its own high-performance GPU training cluster, with a capacity to run 320 GPUs simultaneously. Utilizing this infrastructure, we trained 42dot LLM-PLM on A100 80G GPUs with a total of 49,152 GPU hours, which is equivalent to about one week of simultaneous utilization of 320 GPUs. An additional 112 GPU hours of compute was used for fine-tuning the PLM for 42dot LLM-SFT. 6. Evaluation Result The resulting 42dot LLMs outperform other similarly sized large language models in various zero-shot evaluation metrics, in both Korean and English. In a comprehensive dialogue performance evaluation benchmark featuring 121 prompts across ten different categories, our model outperforms similarly sized LLMs by a significant margin. Notably, it is noteworthy that our model's performance is closely competitive with GPT-3.5, a model over 100 times larger, boasting an estimated 175 billion parameters. 7. Public LLM We’ve made the models freely available, along with a generation script so that anyone can easily test and run our LLMs. The models are governed by the CC BY-NC 4.0 license, allowing individuals to utilize them for non-commercial purposes, provided appropriate credit is given. https://huggingface.co/42dot/42dot_LLM-PLM-1.3B https://huggingface.co/42dot/42dot_LLM-SFT-1.3B We believe in the power of the open source ecosystem. Like any LLM, 42dot LLM is not free of limitations and can show signs of hallucinations by generating inaccurate, misleading or inconsistent responses. However, empowered by the potential of open sourcing, we believe that these challenges can be addressed in the foreseeable future. With the introduction of 42dot's Korean-English bilingual language models, we aim to take a positive stride towards enhancing the Korean LLM ecosystem. LLM Group We are developing a large language model to provide new mobility experiences.
CES 2024 42dot booth with exhibition visitors
Tech2024.03.28

42dot at CES 2024: Software-Defined Vehicle Technology

At CES 2024, 42dot announced its 'software-defined everything' strategy. As Hyundai Motor Company’s Global Software Center, we unveiled the new E/E architecture for SDV and core SDV (software-defined vehicle) technologies. 1. New E/E Architecture for SDV With the ever-expanding features, cars today harbor intricate E/E (electrical and electronics) architectures. Our SDV framework hinges on a hardware and software decoupled structure, a solution that simplifies the vehicle’s architecture and empowers engineers to focus on software development. This strategic decoupling grants engineers the flexibility and agility to enhance vehicle system development while ensuring unparalleled user-centric experiences. The streamlined architecture consists of a centralized HPVC (high-performance vehicle computer), zone controllers responsible for controlling the vehicle's sensors and actuators along with a fault-tolerant SDV OS system. 1.1 HPVC (High-Performance Vehicle Computer) At the crux of the new E/E architecture for SDV, there is the HPVC (high-performance vehicle computer), also known as the brain. These HPVC units are the powerhouse of computation within the SDVs, integrating various functions while assuming the position of primary control. With the HPVC, SDVs can consolidate multiple roles and features into a single unit, reducing the reliance on numerous hardware controllers or multiple domain controllers. There are four main functions: • Autonomous driving stacks covering from Level 2 ADAS to Level 4 automated driving systems, to enhance the user’s safe mobility experience. • In-vehicle infotainment (IVI) for communication betw een the vehicle and the driver/passenger. • Data gateway interconnects HPVC and controllers via a high-speed Ethernet backbone network and handles (collecting, exchanging and storing) a large amount of data internally through high bandwidth and throughput communication . • Connectivity via RF communication to send and receive data outside the vehicle via LTE (5G), BT/WIFI, etc. 1.2 Zone Controller The zone controller is an electronic control unit that manages the vehicle's sensors and actuators. To accelerate the transition to SDV (software-defined vehicle), we physically integrate dozens to hundreds of existing control systems via zone controllers to simplify the E/E architecture. The functions of the control units are reorganized as they integrate into their respective zones. Consequently, the complexity and costs of wire harnesses and communication power nets are significantly reduced. The new E&E architecture for SDV showcases one of its advantages of immediately responding to a malfunction with a fault-tolerant system. When a failure occurs in a zone controller, any other zone controller can take over the role of the failed controller due to the decoupled architecture and fault tolerance of the SDV OS. 1.3 SDV OS The SDV OS efficiently manages applications across the vehicle built with the new E/E architecture, and effectively runs applications on physically distributed hardware, ensuring reliability and efficiency. Additionally, through the unified vehicle API, it enables vehicles composed of physically distributed hardware to be virtually managed as a single product, maximizing software flexibility and optimizing resource utilization across the vehicle. 42dot’s SDV OS is powered by Rust, to operate a mission-critical system that ensures safety. 2. Core SDV Technologies 42dot defines vehicles as ‘AI machines’ (machines that continually learn and improve to better serve). SDVs (software-defined vehicles) are not merely recipients of human-provided data but sophisticated devices that analyze and learn to perceive, plan, and control by utilizing data collected from their own sensors. We would like to introduce the SDV technologies that address the ever-evolving needs of users. 2. 1 Data-Driven Learning Systems To build a smart AI system, 42dot is transforming vehicles into learning machines with the goal of not only advancing AI engineering but also bringing AI & autonomous driving technology to the public. 42dot is continuously collecting, curating, and training data to validate AI models and improve camera-based autonomous driving technology. To optimize the process, they have integrated an agile development of two-week sprints of engineering, performing simulation, deploying into R&D fleets, and eventually deploying software into service fleets. 42dot automates the training, optimization, deployment, and integration process to enhance efficiency (CI/CD). The MLOps and DataOps methodology enables 42dot to create a framework for rapid improvements of AI in mobility. 2.2 Safety-Designed Vehicle Safety is our utmost priority, hence 42dot is implementing safety in all aspects of SDV hardware and software such as strengthening the cybersecurity of SDVs, redundant vehicle network and enhancing safe driving practices. 42dot is committed to developing a comprehensive, integrated SDV security solution that addresses cybersecurity concerns across multiple facets, encompassing the protection of personal information and the prevention of unauthorized data access. Moreover, safe driving can be enhanced through the use of AI. The SDV's AI algorithms employ 3D camera vision to perceive its surroundings, anticipate the vehicle's trajectory based on driver input, and alert against potential collisions with obstacles. This data is sent to the cloud and shared with other vehicles. 2.3 LLM for Advanced Mobility Large language models (LLM) harness the power to learn intricate language structures and when implemented correctly, they have the potential to change the way we move. Now, most existing vehicle AI assistants provide responses in a single-turn method. However, LLM-based assistants offer seamless multi-turn conversations that mirror human interactions. Empowered with the language structures trained from vast amounts of data, 42dot’s AI assistant, based on its own LLM, can generate proper human-like responses. 42dot’s own AI assistant will be integrated into various in-vehicle infotainment apps and connected services such as AI assistant, AI navigation, autonomous driving, intelligent fleet safety & management - the possibilities are endless. The AI assistant can provide tailored recommendations based on one’s habits and lifestyle. It can also generate necessary human readable/listenable alerts which improves the efficiency of fleet management. 2.4 Self-Managed Smart City SDV technologies can extend to fleets and into cities to optimize businesses and cities’ transportation infrastructure. 42dot provides safe, user-centric autonomous technology and mobility algorithms to provide optimized routing based on real-time data. Road data managed via the cloud is shared with all SDV equipped vehicles to provide optimal mobility services. All mobility information such as vehicle, driver, trip data, and real-time traffic information is digitized and managed via a centralized FMS (fleet management system). Vehicle collisions and accidents are handled with AI-driven accident alerts and reporting systems. The 42dot system automatically notifies relevant parties and creates documentation for operation needs. All driver, vehicle and traffic data including video clips are tamper-resistant, managed and protected with blockchain technology. These technologies not only enable us to manage fleets but also efficiently manage the movement of cities through “software-defined everything”. 2.5 Autonomous Mobility Platform TAP! 42dot advances SDV and mobility technologies to provide customer-oriented mobility experiences. 42dot’s ‘TAP!’, the official autonomous mobility platform of Seoul, is leading the commercialization of autonomous mobility. The platform accommodates multiple autonomous vehicles from different providers, including 42dot, in seven different service locations. Users can dispatch different routes and autonomous vehicles such as autonomous taxis and shuttles. At CES 2024, 42dot introduced SDV technology that is continuously updated for optimized performance, just like smart phones. We are applying smartphone development practices to automotive development. 42dot is actively recruiting talents who want to join our journey to making software-defined everything. *Link: https://www.42dot.ai/en/careers/open-roles BMX (Brand Marketing eXperience) Team We are in charge of branding and marketing of 42dot

News

Gleo AI icon
2026.07.15

포티투닷, “사람처럼 자연스러운 대화” 가능한 차량용 음성 AI 에이전트 ‘글레오 AI’ 기술 공개

포티투닷, “사람처럼 자연스러운 대화” 가능한 차량용 음성 AI 에이전트 ‘글레오 AI’ 기술 공개 - 대화 맥락, 주행 상황 등 고려해 사용자 의도 종합적 이해…정보 제공 및 차량 직접 제어 - 목적에 따라 LLM 선택적 활용되는 구조로 유연성 및 성능 확보…’인지-판단-실행’ 전 과정 수행 - 자체 개발 ‘가드레일 에이전트’ 적용 및 무선 업데이트로 품질 지속 개선…”개인화 AI로 발전시킬 것” [2026년 5월 21일] 포티투닷(42dot)이 사람처럼 자연스러운 대화가 가능한 대규모 언어 모델(LLM) 기반의 차량용 음성 AI 에이전트 ‘글레오 AI(Gleo AI)’ 개발을 완료하고 관련 기술을 21일 공개했다. 글레오 AI는 현대자동차그룹의 글로벌 소프트웨어 센터인 포티투닷이 지난 2024년 개발에 착수해 이달 현대자동차 ‘더 뉴 그랜저’를 통해 처음 선보인 차량용 음성 AI 에이전트다. 대규모 언어 모델을 기반으로 차량에 동승한 사람과 대화하듯 자연스러운 의사소통이 가능하며, 사용자 요청에 따라 정보를 제공하거나 여러 가지 기능을 직접 제어한다. 모빌리티 AI의 새 지평을 열겠다는 의지를 담아 개발된 글레오 AI는 단순히 명령을 수행하는 것을 넘어, 차량 환경에 최적화된 음성 기술을 바탕으로 발화자의 위치를 인식하고, 대화 맥락과 주행 상황 등을 고려해 사용자의 의도를 종합적으로 이해한다. 이후 의도를 처리하기 위해 가장 적합한 에이전트를 선택 및 조합해 기능을 실행하고, 사람처럼 자연스러운 응답까지 생성한다. 글레오 AI는 차량용 기술로 개발된 음성 AI 에이전트로, 말로 하는 명령만으로 내비게이션 목적지 설정부터 공조 제어, 차량 기능 조작 등 다양한 기능을 차량 내 안전한 환경에서 제어 가능하다. 이를 통해 운전자 및 탑승객은 별도의 버튼 및 터치 조작 없이도 차량과 끊임없는 상호작용을 하며 즐겁고 편리한 이동 경험이 가능하게 된다. 글레오 AI의 구조는 이해, 판단, 답변 생성 등 단계별 목적에 따라 다양한 LLM이 선택적으로 활용될 수 있도록 설계돼 성능과 유연성을 동시에 확보했다. 또한 글레오 AI는 ▲LLM 인텔리전스(LLM Intelligence) ▲하이브리드 AI 아키텍처(Hybrid AI Architecture) ▲스피치 인텔리전스(Speech Intelligence) ▲글레오 인터페이스(Gleo Interface) 등 기술적 특징을 바탕으로, 차량 환경에 특화된 ‘인지-판단-실행’ 전 과정을 유기적으로 수행한다. 더불어 고객 경험 신뢰도 강화를 위해 포티투닷이 자체 개발한 ‘가드레일 에이전트’가 적용됐으며, 향후 무선 업데이트(OTA)를 통해 글레오 AI의 기능과 품질을 지속적으로 개선해 나갈 방침이다. 포티투닷 박민우 대표는 “글레오 AI는 ‘나의 수고를 덜어주는 이동 동반자’로서, 앞으로 더 많은 기능을 자연스럽게 수행하고 맥락을 이해하도록 고도화될 것”이라며, “중장기적으로는 사용자 행동과 선호를 이해해 말하지 않아도 필요한 것을 돕는 개인화 AI로 발전시킬 것”이라고 밝혔다. ■ ‘인지-판단-실행’에 최적화된 기술 적용 글레오 AI의 LLM은 대화 맥락과 발화 의도를 이해해 에이전트의 과업을 추론 및 배분하며, 사용자 의도에 기반해 최종적인 실행 정보와 사용자 응답 문장을 생성하는 핵심 역할을 수행한다. 또한 하이브리드 아키텍처를 채택해 저지연성과 안정성이 필수적인 차량 및 시스템 작업은 온디바이스에서 처리하고, 고성능 연산이 필요한 작업은 클라우드에서 수행하도록 설계됐다. 또한 최신 LLM 기반의 TTS(Text-To-Speech) 기술을 통해 고도로 자연스러운 음성을 생성하며, 초저지연 응답 속도를 구현해 끊김 없는 대화를 지원한다. 이러한 음성 기능은 글레오 인터페이스 생태계 내에서 기본 시스템 앱뿐 만 아니라 외부 서드파티(3rd Party) 앱도 쉽게 연동하고 확장할 수 있게 한다. ■ ‘진짜 사람처럼’ 소통하는 AI 시스템 적용 및 엄격한 신뢰성 구축 글레오 AI만의 차별점은 차량 환경에 특화된 인지-판단-실행 구조의 에이전트 프레임워크가 진짜 사람 같은 AI 시스템으로 구현됐다는 것이다. 기존의 일반적인 AI 음성 비서가 정해진 단순 명령어 기반으로만 작동해 사람의 부가적인 개입이 필요한 불편함이 존재했다면, 글레오 AI는 사용자의 발화를 맥락 기반으로 이해하고 의도를 판단하기 때문에 정확한 명령어를 알지 못해도 자연스럽게 수행할 수 있으며, 이전 대화와 상황까지 연속적으로 이해해 사용자의 편의성을 극대화한다. 단순히 정보를 제공하는 데 그치지 않고 차량 기능과 앱을 직접 제어해 내비게이션, 공조, 미디어, 차량 설정 등 다양한 기능을 하나의 대화 흐름 안에서 수행할 수 있다. 발화자의 좌석 위치나 차량 상태에 따라 다른 작업을 수행하는 것도 가능하다. 또한 포티투닷은 글레오 AI를 통해 정확하고 최신의 외부 정보까지도 제공하기 위해 지식 에이전트(Knowledge Agent)를 구축했다. 웹 검색, 자체 데이터 컬렉션 등을 기반으로 관련 정보를 실시간으로 탐색하고, 이를 요약 및 재구성하는 등 사전에 학습하지 않은 최신 정보까지도 활용해 사용자에게 보다 풍부한 답변을 제공한다. 뿐만 아니라 포티투닷은 차량 환경에 최적화된 음성 및 인터랙션 기술을 글레오 AI에 내재화했다. 글레오 AI에 적용된 음성 전처리 기술, 언어별 음성 인식, 자연스러운 음성 합성은 포티투닷이 자체 개발한 것으로, 복합적인 변수가 존재하는 차량 환경에서도 안정적인 음성 품질을 제공한다. 차량 내 인터랙션 데이터는 개인정보와 주행 맥락이 결합돼 있어 엄격한 통제가 필수적이다. 글레오 AI는 독자 기술로 개발돼 데이터의 수집부터 저장, 활용까지 전 과정의 거버넌스를 보장한다. 가드레일 에이전트를 통해 위험 발화를 사전에 감지하며, 법규 위반이나 부적절한 요청은 응답을 제한해 시스템의 신뢰성과 윤리성을 확보했다. 특히 차량 제어 요청은 안전 상황을 확인한 뒤 동작하도록 구조화해 안정성을 높였다. ■ 사용자 피드백을 반영한 지속적 기술 고도화 글레오 AI의 기능과 품질은 OTA를 통해 지속적으로 개선될 예정이다. 포티투닷은 실제 주행 데이터와 고객 피드백(VOC)을 서비스에 즉각 반영하는 체계를 구축하는 것을 포함해, ▲자체 LLM 비중 확대 ▲온디바이스 AI 적용 확대 ▲개인화 및 추천 기능 고도화 ▲다양한 서비스 및 앱과의 연동 확대 추진 등을 통해 향후 개인화 AI로 발전시킬 계획이다.