Blog & News

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 시리즈에서는 팀과 기술을 소개하며 개발 과정부터 협업 방식, 그리고 몰입과 성장을 돕는 Engagement Program까지 42dot에서의 성장을 인터뷰로 담았습니다. 개발자들이 직접 들려주는 42dot의 일하는 방식과 성장 이야기인 Work&Way 시리즈 5편에서는, Silicon Vally의 스토리를 전달합니다. UX와 디자인부터 자율주행, 머신러닝과 AI, Product Intelligence, TaaS, Real-time Platform까지. 서로 다른 전문성을 지닌 엔지니어링 팀을 연결하며 차세대 SDV 플랫폼의 품질과 성능을 만들어가는 42dot Silicon Valley의 Work&Way를 지금 바로 영상으로 확인해 보세요!

42dot의 개발자들은 어떤 환경에서 성장하고, 어떻게 일하며, 어떤 문화를 만들어가고 있을까요? Work&Way 시리즈에서는 팀과 기술을 소개하며 개발 과정부터 협업 방식, 그리고 몰입과 성장을 돕는 Engagement Program까지 42dot에서의 성장을 인터뷰로 담았습니다. 자율주행 플랫폼의 핵심을 담당하는 Atria AI Group에서, 실제 도로와 시뮬레이션 환경에서 반복적인 테스트를 통해 더 안전하고 신뢰할 수 있는 자율주행의 미래를 축적해 나가는 42dot 개발자의 이야기를 지금 바로 만나보세요.

42dot의 개발자들은 어떤 환경에서 성장하고, 어떻게 일하며, 어떤 문화를 만들어가고 있을까요? Work&Way 시리즈에서는 팀과 기술을 소개하며 개발 과정부터 협업 방식, 그리고 몰입과 성장을 돕는 Engagement Program까지 42dot에서의 성장을 인터뷰로 담았습니다. 개발자들이 직접 들려주는 42dot의 일하는 방식과 성장 이야기인 Work&Way 시리즈 3편에서는, Vehicle OS Group의 스토리를 전달합니다. Vehicle OS를 통해 차량 개발의 방식을 새롭게 정의하고, 더 빠르고 유연하게 기능을 확장해 나가는 42dot 개발자의 일상! 사용자에게 더 안전하고 편안한 경험을 제공하기 위해 HMI(Human-Machine Interface)를 고민하고 구현해 나가는 이야기를, 지금 바로 만나보세요!

42dot의 개발자들은 어떤 환경에서 성장하고, 어떻게 일하며, 어떤 문화를 만들어가고 있을까요? Work&Way 시리즈에서는 팀과 기술을 소개하며 개발 과정부터 협업 방식, 그리고 몰입과 성장을 돕는 Engagement Program까지 42dot에서의 성장을 인터뷰로 담았습니다. 개발자들이 직접 들려주는 42dot의 일하는 방식과 성장 이야기인 Work&Way 시리즈 2편에서는, Connectivity Framework팀의 스토리를 전달합니다. 지금 바로, 영상으로 확인해 보세요!

42dot의 개발자들은 어떤 환경에서 성장하고, 어떻게 일하며, 어떤 문화를 만들어가고 있을까요? Work&Way 시리즈에서는 팀과 기술을 소개하며 개발 과정부터 협업 방식, 그리고 몰입과 성장을 돕는 Engagement Program까지 42dot에서의 성장을 인터뷰로 담았습니다. 개발자들이 직접 들려주는 42dot의 일하는 방식과 성장 이야기인 Work&Way 시리즈 1편에서는, LLM 기반의 차량용 Agentic AI - Gleo AI를 개발하는 스토리를 전달합니다. 지금 바로, 영상으로 확인해 보세요!

신뢰도 높은 자율주행 기술을 구현하기 위해서는 차량 주변의 3차원 환경을 실시간으로 정확하게 재구성하는 것이 필수적입니다. 42dot에서는 실시간으로 작동하는 고성능 3차원 인지 모델을 개발하기 위해 지속적으로 데이터를 수집하고, 모델의 성능을 추적하여 자율주행 기술을 발전시키고 있습니다. 1. 객체 탐지 모델의 중복 예측 문제와 그 영향 자율주행 자동차는 차량 주변의 환경을 재구성하여 장애물의 위치를 파악하고, 다른 차량과 보행자의 움직임을 예측하여, 차량이 안전하게 주행할 수 있는 경로를 계획합니다. 따라서, 자율주행 시스템에서 가장 먼저 수행되는 3차원 객체 탐지 모델의 정확도는 차량의 안정적인 운행에 큰 영향을 미칩니다. 42dot에서는 지속적으로 데이터를 수집하여 모델을 평가, 개선하고 있습니다. 최근 추가된 데이터로 모델을 평가한 결과, 작은 구역에 보행자가 4-5명 모여있는 경우, 실제 보행자 수보다 많은 중복 예측이 발생하는 것을 확인했습니다. 이러한 중복 예측은 자율주행 차량이 존재하지 않는 물체를 인식하게 만들어 비정상적인 움직임을 유발할 수 있습니다. 예측된 결과의 후처리 과정에서 예측 점수의 임계값을 높여 오탐지를 줄일 수 있지만, 이 경우 탐지하지 못하는 보행자의 수가 증가하여 안전에 위협이 될 수 있습니다. 예측된 보행자의 점수가 낮은 경우, 검출된 물체가 중복된 예측일 확률이 높아집니다. 2. Active Learning Pipeline 42dot에서는 모델의 약점을 개선하기 위해 유사한 케이스의 데이터를 지속적으로 수집하고 네트워크 학습에 포함시키는 Active Learning Pipeline을 운영하고 있습니다. 이때 새롭게 수집된 데이터를 사람의 개입을 최소화하며 효율적으로 모델 학습에 포함시키기 위해, 비실시간으로 동작하는 고성능 모델을 사용하고 있습니다. 이렇게 고성능 모델에서 학습된 지식은, 차량에서 실시간으로 동작하는 모델에 증류(distillation)되어 성능을 향상시키는데 이용됩니다. 3. Transformer 모델 구조 도입 최신의 객체 탐지 모델[1, 2]들은 트랜스포머 구조 도입하여 성능을 크게 향상시키고 있습니다. 트랜스포머는 object query들이 self-attention을 통해 객체 간 정보를 교환하고, feature map의 전체 정보를 활용하여 CNN 구조보다 더 풍부한 정보를 활용할 수 있습니다. 특히 트랜스포머 기반의 객체 탐지 모델은 학습 과정에서 GT와 예측 사이의 one-to-one 매칭을 사용하기 때문에 중복 예측을 억제하는 데 큰 효과가 있습니다. 이러한 트랜스포머 모델의 특성은 보행자 중복 예측 문제를 효과적으로 해결하여 보행자 탐지 성능을 크게 향상시킬 수 것이라고 기대할 수 있습니다. 4. Denoising 기법 활용 하지만 기대와는 다르게 단순히 트랜스포머 기반의 객체 탐지 모델을 도입하는 것만으로는 높은 성능 향상을 확인할 수 없었습니다. 문제의 원인을 파악하기 위해 모델의 클래스 별 object query의 개수를 분석한 결과, 사람이 매우 밀집된 도심 구간에서는 아래와 같이 보행자 주변에서 생성된 object query의 숫자가 매우 많기 때문에 생성된 object query와 GT를 매칭하는 과정에서 학습이 불안정해지는 것을 알 수 있었습니다. 이를 해결하기 위해 2023년 CVPR에서 소개된 Dense Distinct Query[3] 기법을 적용하여 문제를 해결하고 학습의 안정성을 확보할 수 있었습니다. 5. 성능 향상 결과 이와 같이 다양한 기술을 도입하여 보행자 중복 예측의 수를 대폭 감소시키면서 모델의 정밀도(precision)를 크게 향상시켰습니다. 또한, 보행자의 위치, 크기, 진행 방향 등의 예측 품질도 한층 더 개선되었습니다. 이렇게 향상된 고성능 모델은 차량에 적용되어 주행 성능을 높이는 데 사용됩니다. 42dot은 끊임없는 기술 개발과 연구를 통해 자율주행 기술을 더 안전하고 친숙하게 발전시키기 위해 최선을 다하고 있습니다. 김영석, 차주한(Intern) ⎢ AD Algorithm 자율주행 차량이 주변 환경을 더욱 빠르고 정확하게 이해할 수 있도록 돕는 기술을 개발하고 있습니다. 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.

42dot에서는 지난 가을, 자체 개발한 초거대 언어 모델인 42dot LLM을 공개한 바 있습니다. 42dot LLM은 국내 최초의 한영 통합 언어 모델로서 직접 구축한 데이터와 자체 학습 인프라를 활용해, 비슷한 규모의 다른 언어 모델 대비 월등한 성능을 달성하며 좋은 품질을 보여줬습니다. LLM은 크게 사전 학습 모델인 PLM과 사용자 지침을 따르도록 튜닝한 파인 튜닝 모델로 구분할 수 있습니다. 저희는 두 모델을 모두 공개하였으며, 전자는 42dot LLM-PLM이라는 이름으로, 후자는 42dot LLM-SFT라는 이름으로 공개한 바 있습니다. [42dot LLM 실행 데모] https://huggingface.co/42dot/42dot_LLM-PLM-1.3B https://huggingface.co/42dot/42dot_LLM-SFT-1.3B 1. SFT 모델 미세 조정 모델 중에서도 정교하게 레이블을 지정한 소규모 데이터셋을 이용해 사전 학습 모델의 가중치와 편향을 조정하는 기법을 Supervised Fine-Tuning이라 하는데, 이 기법을 활용한 언어 모델을 해당 기법의 영어 약어를 덧붙여 SFT 모델이라 부릅니다. 저희가 공개한 생성 언어 모델 또한 SFT 기법을 활용했기 때문에 특별히 42dot LLM-SFT라 명명하였으며, 우리가 흔히 챗GPT처럼 대화를 주고받을 수 있는 LLM을 이야기할 때는 바로 이 SFT 기법을 활용한 모델을 일컫습니다. 2. 라마(LLaMA) 구조 42dot LLM은 여타 LLM과 동일하게 트랜스포머의 디코더 구조를 사용하며, 특히 페이스북에서 오픈소스로 공개하여 큰 호응을 얻은 바 있는 라마(LLaMA)와 거의 동일한 구조를 채택하였습니다. 굳이 라마를 택한 이유는 다양한 프레임워크와의 호환성을 유지하기 위해 오랜 기간 심사숙고하여 내린 결정이며, 그 덕분에 한글을 전혀 이해하지 못하는 라마와 달리 저희 모델은 한글을 자연스럽게 이해하면서 해외 유명 프레임워크에서도 아무런 문제 없이 자연스럽게 구동됩니다. 물론 구조만 동일할 뿐 라마 모델의 원래 매개변수는 전혀 사용하지 않았기 때문에 모든 매개변수는 바닥부터 저희가 직접 학습을 진행하였습니다. 3. 모델 크기 42dot LLM은 13억 개가 넘는 매개변수를 지닌 1.3B 모델이며, 총 24개의 레이어를 갖고 있는 초거대 언어 모델입니다. 여기에 라마와 거의 동일한 분량인 1.4조(1.4T) 개의 토큰을 이용해 학습을 진행하였으며, 해외의 여타 LLM과 달리 대량의 고품질 한글 데이터를 포함하여, 한글과 영어를 동시에 이해하는 한영 통합 언어 모델을 구축하였습니다. 4. 토크나이저 문장을 단어 또는 음절 같이 최소 단위로 나누는 작업을 토큰화(Tokenization) 작업이라고 하며 이 작업을 하는 도구를 토크나이저(Tokenizer)로 부릅니다. 이 중 글자를 바이트 단위로 쪼개어, 자주 등장하는 바이트의 쌍을 쌓아나가는 방식을 Byte-Pair Encoding, 줄여서 BPE 알고리즘이라 하는데 이 방식은 한글에도 매우 유리합니다. 왜냐면 우리말은 교착어이기 때문에 다양한 표현이 가능하여 분석하기 어렵지만 BPE는 이런 다양한 변형을 잘 파악할 수 있기 때문이죠. 이 때문에 오픈 AI의 GPT도 같은 방식을 사용한 바 있으며, 저희 42dot LLM 또한 BPE 방식을 사용해 문장을 토큰화하고 있습니다. 이렇게 토큰화 과정을 거쳐 한글과 영어 토큰 약 5만여 개로 구성된 단어 사전을 구축하였으며 이 과정은 총 1천만 건의 문서를 샘플링하여 구축하였습니다. 5. GPU 학습 클러스터 42dot은 320장의 GPU를 동시에 투입할 수 있는 고성능의 GPU 학습 클러스터를 자체 구축하여 보유하고 있습니다. 42dot LLM-PLM의 학습 또한 이 인프라를 활용하였으며 A100 80G GPU로 총 49,152 시간(GPU hours) 동안 학습을 진행하였습니다. 320장을 동시에 투입할 경우 약 1주일 남짓 소요되는 시간이며, 여기에 더해 42dot LLM-SFT에 112 시간(GPU hours)을 추가로 학습하였습니다. 6. 성능 평가 결과 이렇게 완성된 42dot LLM은 제로샷 성능 평가에서 비슷한 규모의 다른 언어 모델 대비 월등한 성능을 달성하였습니다. 한국어뿐만 아니라 영어에서도 높은 성능을 보였으며 10가지 카테고리에 대해 총 121개의 프롬프트로 구성한 대화 성능 평가에서도 비슷한 규모의 다른 언어 모델에 대비해서 압도적인 성능 차이를 보입니다. 심지어 GPT-3.5와도 크게 차이 나지 않는 놀라운 품질을 보여줍니다. 7. 모델 무료 공개 각 모델 파일은 모두 무료로 공개하였습니다. 또한 간단한 생성 코드를 함께 제공하여 누구나 손쉽게 LLM을 구동할 수 있도록 하였습니다. 라이선스는 CC BY-NC 4.0를 따르며 출처를 밝히면 비상업적 용도에 한 해 누구나 자유롭게 활용하실 수 있습니다. https://huggingface.co/42dot/42dot_LLM-PLM-1.3B https://huggingface.co/42dot/42dot_LLM-SFT-1.3B 저희는 오픈소스 생태계의 힘을 믿습니다. 여타 LLM과 마찬가지로 42dot LLM도 환각(Hallucination) 현상 같은 근본적인 문제를 지니고 있으며, 미처 포함하지 못한 질문-응답 케이스가 존재할 수 있기 때문에 기대하는 형태의 응답을 생성하지 못할 수도 있습니다. 하지만 혁신을 촉발하는 오픈소스의 힘은 이 같은 문제 또한 근시일 내에 해결해 내리라 믿습니다. 42dot의 국내 최초 한영통합 언어 모델 공개로 우리나라의 LLM 생태계가 한 단계 더 도약하길 기대해 봅니다. LLM Group 새로운 유형의 모빌리티 경험을 제공하기 위한 large language model을 개발하고 있습니다.

CES 2024에서 현대자동차그룹이 발표한 ‘software-defined everything’ 전략에 맞춰 그룹의 글로벌 소프트웨어 센터인 42dot이 공개한 새로운 SDV 전기・전자 아키텍처와 핵심 기술들을 소개합니다. 1. New E/E Architecture for SDV 최근 차량에 많은 기능이 탑재되면서 차량의 전기・전자 아키텍처 또한 복잡해지고 있습니다. 이런 복잡성은 차량 개발을 위한 시간과 비용을 증가시켜 새로운 기능을 쉽게 추가하기 어렵게 만듭니다. 42dot은 이 문제를 해결하기 위해 SDV (software-defined vehicle)로 하드웨어와 소프트웨어를 디커플링하여 차량의 아키텍처를 단순화하였습니다. 새로운 전기・전자 아키텍처는 고성능 차량용 컴퓨터인 HPVC와 차량의 센서와 액추에이터를 제어하는 zone controller 그리고 SDV OS로 구성되어 있으며, 이를 통해 엔지니어는 소프트웨어 개발에 집중하여 사용자 경험에 최적화된 시스템을 빠르게 만들 수 있습니다. 1.1 HPVC (High-Performance Vehicle Computer) SDV 전기・전자 아키텍처의 핵심은 고성능 차량용 컴퓨터인 HPVC (high-performance vehicle computer)입니다. HPVC는 여러 기능을 동시에 실행하는 고성능 제어기로 하드웨어와 도메인 컨트롤러의 기능을 하나의 유닛으로 통합하여 하드웨어를 단순화할 수 있습니다. HPVC는 다음과 같은 주요 기능이 있습니다. • 차량 내부 제어기들 사이의 커뮤니케이션에 필요한 gateway 역할을 합니다. • 차량 내/외부의 data를 저장하는 storage 역할을 제공하여 필요한 애플리케이션에서 사용할 수 있도록 합니다. • Connected service를 위한 RF 통신 장치로, LTE (5G), BT/WiFi 등을 통해 차량의 정보를 외부로 연결하고 차량 제어, OTA를 위한 데이터를 외부로부터 수신할 수 있습니다. • 레벨 2(ADAS)부터 레벨 4의 자율주행 시스템까지 포함하는 자율주행 스택은 사용자에게 안전한 이동을 제공합니다. • 운전 정보와 멀티미디어 콘텐츠와 같은 엔터테인먼트와 AI 어시스턴트 음성 제어를 통해 차량 편의 장치 및 앱 서비스를 제공할 수 있는 IVI (In-vehicle infotainment) 스택도 제공합니다. 1.2 Zone Controller Zone controller는 차량의 센서와 액추에이터를 제어하는 전자 제어 장치입니다. 기존 수십에서 백여 개에 달하는 제어 시스템을 zone controller를 통해 물리적으로 통합함으로써 전기・전자 아키텍처의 복잡성을 낮춰 SDV (software-defined vehicle)로의 전환에 빠르게 대응할 수 있습니다. 또한 차량 구역 단위로 제어기들을 통합하여 기능적으로도 재구성할 수 있으며, 차량의 신경/혈관과도 같은 배선을 통해 전력 공급과 제어/통신의 복잡도를 낮춤으로써 비용 또한 절감할 수 있습니다. 또한, SDV 전기・전자 아키텍처는 fault-tolerant 시스템으로 기능 장애에 즉시 대응할 수 있는 장점이 있습니다. 특정 zone controller에 장애가 발생해도 디커플링된 아키텍처와 SDV OS의 fault tolerance로 다른 zone controller가 그 역할을 대신 수행할 수 있습니다. 1.3 SDV OS SDV OS는 HPVC, zone controller, high speed network backbone으로 재편된 전기・전자 아키텍처에서 애플리케이션이 안정적이고 효율적으로 동작하도록 관리합니다. 또한 통합된 차량 API는 분산된 하드웨어로 구성된 차량이 하나의 제품처럼 가상으로 관리되어 소프트웨어의 유연성을 극대화하며, 차량 전반의 리소스 사용을 최적화합니다. SDV OS상에서 구현되는 모든 application들은 안전한 시스템을 제공하기 위해 미션 크리티컬 시스템을 위한 프로그래밍 언어인 Rust를 기본 언어로 사용합니다. 2. Core SDV Technologies 42dot은 자동차를 ‘AI 머신’ 즉, 스스로 배우고 개선하는 기계로 정의하고 있습니다. 엔지니어가 주는 데이터만으로 학습하는 것이 아니라, 차량이 각종 센서 등으로부터 수집한 데이터 기반으로 학습, 분석, 인지, 판단 및 제어까지 하는 기술들을 개발하고 있습니다. SDV로 고객이 누리게 될, 안전하고 지속적으로 개선되는 사용자 경험과 편의를 제공하는 기술들을 소개합니다. 2. 1 Data-Driven Learning Systems 42dot은 스마트한 AI 시스템을 만들기 위해 차량을 끊임없이 학습하고 개선되는 AI 머신으로 규정하고 AI와 자율주행 기술을 대중에게 제공하는 목표를 가지고 있습니다. 42dot은 지속적으로 데이터를 수집, 가공 및 학습시켜 AI 모델을 검증하고 카메라 기반의 자율주행 기술을 개선하고 있습니다. 2주 단위 스프린트로 개발, 시뮬레이션, R&D 검증을 거쳐 최종적으로 서비스 차량에 소프트웨어를 배포하는 빠르고 유연한 애자일 개발 프로세스를 진행하고 있습니다. 이렇게 학습, 최적화, 배포 및 통합 프로세스를 자동화하여 효율성을 향상시키고 있으며(CI/CD), MLOps 및 DataOps를 통한 신속한 개선이 가능한 개발 환경을 갖추고 있습니다. 2.2 Safety-Designed Vehicle 최근 차량 외부와의 연결로 안전성, 해킹 및 개인정보 노출 위협 요소가 커지고 있습니다. SDV의 사이버 보안은 운전자와 교통안전을 보장하는데 결정적인 역할을 하고 있습니다. 42dot은 하드웨어와 소프트웨어의 모든 부분에서 안전을 최우선 가치로 두고 통합된 SDV 보안 솔루션을 개발하고 있습니다. 카메라 비전과 운행 정보를 기반으로 한 AI 알고리즘은 차량의 경로를 예측하고 장애물과의 잠재적 충돌에 대비하여 경고합니다. 이 데이터들은 클라우드로 전송되어 다른 차량들과 공유되어 안전 운전을 지원합니다. 2.3 LLM for Advanced Mobility LLM (large language models)은 복잡한 언어 구조를 학습하여, 우리가 이동하는 방식을 획기적으로 변화시킬 수 있습니다. 대부분의 차량 AI assistant는 싱글 턴(single-turn) 방법으로 응답을 제공하지만, 방대한 데이터에서 훈련된 42dot의 LLM 기반 AI assistant는 사람의 상호 작용을 모방하는 연속적인 대화가 가능합니다. 42dot의 AI assistant는 다양한 인포테인먼트 앱은 물론, AI 내비게이션, 자율주행, IFS (intelligent fleet safety) 등 connected service까지 무한한 적용 범위를 가지고 있습니다. 또한 운전자의 습관과 라이프스타일을 기반으로 맞춤형 서비스를 제공할 수도 있으며, 텍스트나 소리를 통해 중요한 정보를 제공하여 효율적인 차량 관리가 가능합니다. 2.4 Self-Managed Smart City SDV 기술은 fleet과 도시에도 적용되어 관련 비즈니스와 교통 인프라를 최적화할 수 있습니다. 42dot은 사용자 중심의 자율주행 기술과 알고리즘을 통해 실시간 데이터를 기반으로 최적의 라우팅을 제공합니다. 또한 클라우드를 통해 관리되는 도로 데이터는 모든 SDV 차량과 공유되어 최적의 이동이 가능합니다. 차량, 운전자, 도로 데이터와 실시간 교통 정보는 중앙화된 FMS (fleet management system)를 통해 디지털화되어 관리되고, 차량 사고 발생 시, AI 기반 사고 알림 및 보고 시스템으로 처리됩니다. 42dot의 시스템은 자동으로 관계자들에게 사고 사실을 알리고 운영에 필요한 리포트를 작성합니다. 동영상을 포함한 모든 운전자, 차량 및 교통 데이터는 블록체인 기술로 관리되고 보호됩니다. 이러한 기술로 "software-defined everything"을 통해 차량을 넘어 도시의 모든 이동이 스스로 관리될 수 있습니다. 2.5 Autonomous Mobility Platform TAP! 42dot의 ‘TAP!’은 서울시의 자율주행 플랫폼으로서 자율주행 상용화를 이끌고 있습니다. 42dot의 자율주행차 외에도, 다양한 업체가 서비스를 쉽게 운영할 수 있도록 자율주행 플랫폼을 제공하고 있으며, 서울시 상암동을 시작으로 7개 지역에서 자율주행 서비스를 운영하고 있습니다. 승객들은 TAP! 앱을 통해 다양한 차량을 호출하여 안전하고 편안한 자율주행 경험을 할 수 있습니다. 지금까지 CES 2024에서 공개한 소프트웨어 중심의 SDV (software-defined vehicle) 기술을 소개했습니다. 42dot은 지속적으로 업데이트되는 스마트폰 같은 차량을 만들기 위해 소프트웨어 회사의 개발 방식을 차량에 적용하며 ‘개발 방식의 대전환’도 이끌고 있습니다. 42dot과 함께 software-defined everything 전략을 실현할 engineering, product, business 전문가라면, 지금 바로 채용 공고를 확인해 보세요. *링크: https://www.42dot.ai/ko/careers/open-roles BMX (Brand Marketing eXperience)팀 42dot의 브랜드 마케팅을 담당하고 있습니다.