AI가 핵심 내용을 요약했어요
AI 기술을 활용한 요약 서비스입니다. 보다 정확한 정보를 위해 본문 확인을 권장합니다.
현대차그룹의 스마트 모빌리티 솔루션 기업 42dot은 특정 도메인 지식보다 문제를 스스로 정의하고 끝까지 검증할 수 있는 기본 역량을 갖춘 개발자를 중요하게 평가한다. 42dot의 개발자들은 AI 에이전트 Gleo AI, VLA 기반 자율주행 AI, Vehicle OS 등 각기 다른 분야에서 기술을 실제 제품으로 완성하는 전 과정을 책임지며, 팀과 함께 명확한 기준을 세우고 실패에서 다음 행동의 근거를 찾는 방식으로 일하고 있다.
42dot은 어떤 개발자와 함께 최고의 결과를 만들어갈까요? 각자 다른 분야에서 일하는 세 명의 개발자에게서, 42dot에 어울리는 구성원의 모습을 찾아보았습니다.
자동차를 정의하는 중심이 하드웨어에서 소프트웨어로 옮겨가고 있습니다. 운영체제와 AI, 자율주행 기술처럼 서로 다른 소프트웨어가 하나의 차량 안에서 유기적으로 연결되면서, 자동차를 개발하는 방식도 빠르게 변화하고 있죠. 기업이 요구하는 개발자의 모습 역시 마찬가지입니다. 개발자들은 이제 개별적인 기능을 구현하는 데 그치지 않고, 실제 고객 경험까지 함께 고민해야 하는 시대가 되었습니다.
스마트 모빌리티 솔루션 기업 42dot에는 차량용 OS와 AI 에이전트, 자율주행 AI 등 다양한 분야의 개발자들이 하나의 제품을 만들어갑니다. 이곳에서는 여러 업무가 이뤄지고 있지만, 이들이 일하는 방식에는 공통점이 있었습니다. 서로 다른 영역에서 일하는 세 명의 개발자를 만나 이야기를 들어보았습니다.
류성한 팀 리드(Team Lead)는 Gleo Core팀의 총책임자 역할을 맡고 있습니다. LLM 기반 AI 에이전트 ‘Gleo AI’가 사용자의 의도를 이해하고 차량 기능을 안전하고 자연스럽게 수행할 수 있도록 핵심 지능을 개발 중입니다.
김하영 팀 리드는 VLA(Vision Language Action) 기반 자율주행 AI를 개발하는 Trion팀을 이끌고 있습니다. AI 기술을 실제 차량의 주행 제어로 연결하기 위해 연구하고 있습니다.
마지막으로 Vehicle OS팀의 이준희 팀 리드는 Vehicle API와 차량 통신 미들웨어, 서비스 레이어 등을 개발하며 차량 안의 다양한 소프트웨어가 하나의 시스템으로 동작하는 기반을 만들고 있습니다.
42dot이 바라는 구성원의 모습
세 명의 개발자에게 가장 먼저 42dot에 입사했을 당시의 경험을 물었습니다. 신규 구성원을 모집할 때, 42dot의 기준이 다른 회사와 다르다고 느낀 점은 무엇이었을까요?
첫 번째 질문에 류성한 팀 리드가 먼저 입을 열었습니다. “기술 자체보다 그 기술로 무엇을 만들고 싶어 하는지 보는 것 같아요.” 그는 뒤이어 “같은 기술을 다루더라도 어떤 제품을 만들고 싶은지, 무엇을 좋은 제품이라고 생각하는지는 사람마다 다르기 때문입니다”라고 부연 설명을 더했습니다.
이준희 팀 리드는 더 직접적인 답변을 내놓았습니다. “기본기를 가장 중요하게 봅니다. 차량이나 엔지니어링 도메인 경험이 많지 않더라도 실제 업무에서 어떤 기술을 사용했고, 그 기술을 얼마나 깊이 이해했으며, 문제를 얼마나 끈기 있게 해결해 왔는지를 중요하게 평가합니다.” 실제로 그의 팀에는 오디오 시스템, 클라우드 데이터베이스 개발자 출신의 구성원이 함께 일하고 있습니다.
김하영 팀 리드도 비슷한 지점을 짚었습니다. “특정 도메인 지식보다, 문제를 스스로 정의하고 끝까지 검증할 수 있는 역량을 중요하게 봅니다.” 그는 “단순히 정답을 맞히는 면접이라기보다, 판단의 근거와 문제에 접근하는 방식을 확인하는 과정에 가까웠어요”라고 하며 5년 전 면접에서의 기억을 끄집어냈습니다.
업무에 몰두하게 만드는 동기부여
42dot의 구성원 중에는 자동차 기술과는 무관한 기업에서 이직한 사람들도 적지 않습니다. 그래서 세 개발자에게 자동차를 특별히 좋아하지 않는 사람도 42dot에 합류해 업무에 몰두하게 만드는 힘이 무엇인지 물었습니다.
“우리가 개발한 알고리즘이 실제 상황에서 의도한 대로 작동하는 순간입니다.” 이번엔 김하영 팀 리드가 먼저 이야기를 꺼냈습니다. “같은 주행 영상을 입력하고 내비게이션 목적지만 다르게 설정했을 때, 저희가 개발한 자율주행 AI 모델은 좌회전, 우회전, 직진 등 요구되는 주행 행동에 맞춰 적절한 차로를 선택했습니다. 그 모습을 보며 우리가 만든 기술이 실제 차량의 움직임으로 이어진다는 것을 실감했습니다.”
동기부여 이야기에 류성한 팀 리드도 맞장구를 쳤습니다. “개발한 소프트웨어가 실제로 도로를 달린다는 자부심이 있죠.” 그는 “AI 개발자로 일하다 보면 PoC(Proof of Concept) 단계에서 끝나는 프로젝트도 많지만, 42dot에서는 우리의 노력이 실제 제품으로 사람들과 만난다는 것에 보람을 느낍니다”라고 하며 이야기를 정리했습니다.
한편, 이준희 팀 리드는 “기업이 나아가는 방향을 구성원들과 함께 이해하는 데서 큰 동기부여를 느낍니다”라고 답했습니다. 그는 곧이어 "창사 행사나 플레오스 행사, 테크데이 등을 통해 42dot이 걸어온 길과 앞으로 만들고자 하는 기술, 제품의 방향이 구성원들과 공유되는데요. 그때 개인의 성과가 팀과 조직의 성장으로 이어지는 걸 체감합니다"라고 설명을 더했습니다.
새로운 구성원이 42dot에 스며드는 과정
서로 다른 배경을 가진 사람들이 엮여 있는 사회에서 새로운 조직에 적응하는 건 여간 어려운 일이 아닌데요. 42dot에서는 신규 구성원이 기업 문화나 시스템에 적응할 수 있도록 어떤 온보딩 프로그램을 마련하고 있을까요?
류성한 팀 리드는 ‘Ask your Buddy!’ 프로그램을 꼽았습니다. 그는 “입사 초기에는 업무 자체보다 누구에게 무엇을 물어봐야 할지 모르는 순간이 더 어렵게 느껴질 수 있습니다”라고 운을 떼며 “해당 프로그램은 그런 시행착오를 줄여주고, 42dot에서 실제로 어떻게 일하는지 빠르게 이해할 수 있게 도와줍니다”라고 정리했습니다.
이준희 팀 리드는 기업 내 제도뿐만 아니라 편하게 질문하고 도움을 청할 수 있는 분위기를 42dot만의 문화로 꼽았습니다. “필요한 질문이나 도움을 편하게 요청할 수 있는 분위기가 잘 형성되어 있어요. 특히 업무에 필요하다면 함께 작업 현장으로 이동해 실제 개발과 검증이 어떻게 이루어지는지 직접 이해할 수 있도록 돕기도 합니다.”
온보딩이 그저 형식적인 제도에만 머무르지 않고, 구성원들의 일하는 방식 속에서도 자연스럽게 이어지고 있다는 이야기였습니다. 김하영 팀 리드는 한 가지를 더하며 이야기를 마무리 지었습니다. “코드만 보고 바로 업무를 시작하면 전체 맥락을 파악하기 어려워요. 그래서 주요 기술이나 실험 방식, 시스템 구조 등을 문서화하고, 팀의 방향성과 현재 집중하고 있는 문제를 공유하는 세션도 마련합니다. 이를 통해 새로 합류한 분들이 자신이 맡은 업무뿐 아니라 전체 문제의 흐름을 이해할 수 있도록 돕고 있습니다.”
AI를 제품으로 완성하는 방법
“기술이 상품화되어 고객 경험으로 구현되기까지의 모든 프로세스를 책임감 있게 개발하고 검증해야 합니다.” 42dot에 합류한 뒤 가장 크게 달라진 점을 묻는 말에 류성한 팀 리드가 가장 먼저 꺼낸 이야기입니다.
그가 이야기에 살을 붙였습니다. “예전에는 모델 성능이나 알고리즘 개선 자체를 중요한 목표로 삼아야 했습니다. 그런데 제품은 달라요. 새로운 기능을 만들 때도 실제 차량에서 안정적으로 동작하는지, 예상치 못한 상황에서는 어떻게 대응해야 하는지, 출시 이후에는 사용자 피드백을 반영하는 단계까지 함께 고민해야 했습니다.”
이러한 고민은 팀의 개발 방식에도 반영되고 있습니다. Gleo Core팀은 기능별 동작 방식과 예외 케이스, 판단 기준, 테스트 기준 등을 정리한 Gleo Spec Wiki를 개발의 공통 원칙으로 활용하고 있습니다.
“최근에는 AI 코딩 도구가 빠르게 확산되면서 개발 방식도 달라지고 있습니다. 하지만 AI 코딩 도구를 활용하는 목적은 단순히 더 빠르게 코드를 작성하는 것이 아닙니다. 제품 요구사항과 도메인 맥락, 테스트 기준까지 같은 기준 위에서 개발하고 검증해, 더 일관되고 신뢰할 수 있는 제품을 만드는 것이 중요합니다.” 류성한 팀 리드의 말입니다.
그런데, 그가 개발하는 Gleo AI를 제품으로 완성하는 과정에서 예상치 못한 문제를 발견하는 일도 적지 않습니다. 대표적인 사례가 ‘Gleo Guard’라는 가드레일 모듈을 고도화하는 단계에서 진행한 레드티밍(Red Teaming)이었습니다. 레드티밍은 일반적인 사용 흐름에서 벗어난 입력을 AI에 의도적으로 제시해 예상하지 못한 오류나 안전성 문제를 찾아내는 검증 과정인데요. 류성한 팀 리드는 당시를 회상하며 이야기했습니다.
“레드티밍 작업 중 ‘근처에 두쫀쿠 파는 곳 찾아 줘’라는 요청 문구가 문제가 된 적이 있어요. 당시 외부 LLM API 기반의 Gleo Guard는 ‘두쫀쿠’라는 신조어가 가진 최신 문화적 의미와 차량 내 목적지 검색 의도를 이해하지 못했던 거죠. 따라서 정상적인 내비게이션 검색 요청이 위험 발화로 분류될 가능성도 있었습니다.”
뒤이어 그는 팀이 문제를 해결했던 과정을 설명했습니다. “하지만 저희 팀은 이를 특정 단어 하나의 문제로 취급하지 않았습니다. 사용자 의도와 차량의 사용 맥락을 함께 이해해야 하는 구조적인 과제로 바라보고 Gleo Guard를 차량 도메인에 특화된 자체 모델로 고도화했습니다. 또한 레드티밍에서 발견된 사례를 바탕으로 신조어나 축약어도 사용자의 의도를 해석하는 판단 맥락으로 활용할 수 있도록 개선했습니다.”
인터뷰를 마무리하던 중, 류성한 팀 리드가 미소를 머금으며 가족 이야기를 꺼냈습니다. “Gleo AI를 개발하던 시기에 태어난 딸이 이제는 자동차를 보면 ‘빠방’이라고 말해요. 그럴 때면 저 차들 가운데는 아빠가 만든 기술이 들어간 차도 있다고 이야기해 주곤 합니다.”
AI 성능을 높이는 연구에 매진했던 개발자는 이제 실제 도로 위를 달리는 모빌리티를 개발합니다. 류성한 팀 리드에게 42dot은 AI 모델을 넘어, 고객이 경험하는 제품 전체를 책임지는 개발자로 성장할 수 있는 곳이었습니다.
복잡한 문제에서 답을 찾는 과정
“자동차 도메인 지식은 언제든 익힐 수 있지만, 문제를 끝까지 이해하고 동료들과 함께 해결하는 방식은 개발자에게 꼭 필요한 역량이라고 생각합니다.” 이준희 팀 리드는 자신의 업무 철학을 한마디로 압축했습니다.
그가 개발하는 Vehicle OS는 이 생각을 그대로 반영합니다. 차량 창문의 열림 정도를 제어할 때도 개발자는 제어기의 복잡한 구조를 몰라도, ‘Window.set_position(0.5)’ 같은 하나의 코드만으로 기능을 사용할 수 있습니다. “개발자는 제어기 구조를 일일이 이해하지 않아도, 실제로 구현하려는 로직에 더 집중할 수 있어요.” 차량이라는 복잡한 시스템을 다루면서도, 그 복잡함을 다른 개발자가 굳이 알 필요 없게 만드는 것이 그가 만드는 기술이 지향하는 방향입니다.
다른 부서나 외부 기업과의 협업이 잦은 만큼, 그가 추구하는 업무 태도 역시 뚜렷했습니다. “각자가 관심을 두는 부분과 이해 수준이 다를 수 있기 때문에, 우리가 미처 인지하지 못한 세부 사항이 있을 수 있다는 점을 항상 염두에 두는 것이 중요합니다.” 이어서 이준희 팀 리드가 설명을 보탰습니다. “따라서 특정 방향에만 고정되기보다는, 사고와 방향성을 열어두고 협업에 임하는 태도가 필요합니다. 복잡한 의사결정이 필요할 때는 생각하는 방향을 미리 정리해서 미팅에 들어가는 편이고요.”
새로운 도메인을 접할 때마다 그는 사양 문서부터 확인합니다. “내용이 방대하거나 전문 용어 해석이 필요하면 사양 작성자와 주기적으로 싱크업하면서 이해도를 높여요. 요즘은 회사에서 제공하는 AI 도구를 활용해서 관련 자료를 빠르게 파악하기도 하고요.” Vehicle API팀 안에서 의견이 갈릴 때도 그 원칙은 비슷하게 이어지고 있습니다. “의사결정 전에는 적극적으로 의견을 내고, 결정 후에는 공동의 목표에 맞춰 집중하는 방식으로 문제를 해결하고 있습니다.”
기술 개발과 협업, 그리고 낯선 도메인을 익히는 과정에서도 그의 방식은 결국 같았습니다. 문제를 끝까지 파고들고, 그 해답을 가장 단순한 형태로 다듬어내는 것. 이준희 팀 리드에게 42dot다운 개발자란, 복잡한 문제 앞에서도 가장 명료한 답을 찾아내는 사람이었습니다.
정답보다 기준을 찾는 과정
자율주행 AI를 개발하는 일에는 정답이 없습니다. 같은 상황에서도 어떤 판단이 더 적절한지, 어떤 학습 방식이 더 효과적인지는 끊임없이 검증하고 수정해야 하기 때문이죠. 그래서 김하영 팀 리드가 가장 먼저 고민하는 것은 새로운 모델을 만드는 일이 아니라, 팀이 같은 문제를 바라볼 수 있는 기준을 마련하는 일이었습니다.
“자율주행 AI는 고려해야 할 요소가 매우 많습니다. 그래서 먼저 ‘의도대로 일관되게 움직이는 자율주행을 만들자’는 공감대를 만들었어요. 이를 바탕으로 누구나 같은 기준에서 개선 수준을 확인할 수 있는 평가 지표를 만들었습니다.”
평가에 대한 공통된 원칙이 생기자, 팀의 개발 방식도 자연스럽게 달라졌습니다. 김하영 팀 리드가 기억을 떠올리며 이야기를 이어갔습니다. “팀원들이 마치 게임에서 점수를 올리듯 평가 지표를 높여가며 모델을 개선하기 시작했어요. 실패한 실험도 자연스럽게 다음 논의로 이어졌죠.”
이 기준은 조직 간 협업에서도 중요한 역할을 했습니다. 차선 변경 기능을 개발할 때는 주행 상황을 이해하는 VLM 스쿼드와 일관된 주행 궤적을 만드는 VLA 스쿼드가 함께 다양한 주행 사례를 검토했습니다.
협업 사례를 들며 김하영 팀 리드는 이렇게 말했습니다. “의견이 다를 때도 해결책부터 바로 비교하지는 않아요. 먼저 지금 해결하려는 문제가 무엇인지, 반드시 만족해야 하는 조건이 무엇인지부터 함께 정리했습니다. 기준이 세워지면 누구의 의견이 맞는지를 따지기보다, 현재 문제에는 어떤 선택이 더 적합한지를 논의할 수 있거든요.”
그는 이런 문화가 팀 안에서도 자연스럽게 이어진다고 설명했습니다. “한두 달마다 세션을 열어 실험 결과와 새롭게 확인한 문제를 함께 공유합니다. 평소에도 새로운 기술이 나오면 개발에 어떻게 적용할 수 있을지 자발적으로 논의하는 문화가 있습니다.”
김하영 팀 리드는 인터뷰 말미에 ‘좋은 리더’에 대한 생각도 들려주었습니다. “팀에서 가장 많은 답을 아는 사람이 리더가 돼야 한다고 생각하지 않습니다. 팀이 더 좋은 판단을 할 수 있도록 기준을 만들고, 서로 다른 전문성을 자연스럽게 연결하는 사람이 되고 싶습니다.”
42dot다운 개발자라는 것
인터뷰를 통해 만난 세 명의 개발자는 서로 다른 기술을 다루지만, 일하는 방식에서 공통점을 발견할 수 있었습니다. 자신이 맡은 범위에서 결과를 내는 것으로 끝내지 않고 더 나은 구조를 고민하며, 팀과 함께 명확한 기준을 만드는 것. 또 실패에서 다음 행동의 근거를 찾고, 리더와 구성원 모두가 깊이 이해한 뒤 결정하는 방식으로 일하고 있었습니다.
42dot이 함께하고 싶은 개발자도 마찬가지입니다. 화려한 기술 스택이나 자동차 도메인 지식보다 새로운 문제를 두려워하지 않는 단단한 ‘마음가짐’과 팀과 함께 더 나은 기준을 세워나가는 ‘자세’에 주목합니다. 자신이 만든 코드가 실제 도로 위에서 고객 경험으로 완성될 때까지 책임지는 일, 42dot은 그 가슴 뛰는 여정에 함께 할 개발자를 기다리고 있습니다.
사진. 민영
