세상의 모든 길을 연결합니다

안녕하세요. 

현대·기아·제네시스 차량을 쓰는 전 세계 고객에게 만족스러운 경로를 설계하고 있는 박준형입니다. 

GIS센터개발팀에서 경로 서비스 개발을 맡고 있고요, 

특히 비교 경로 기능 고도화에 집중하고 있어요. 

가장 최근엔 주차장 비교 경로를 만들었는데,

 “어느 주차장이 더 덜 붐비고, 더 빨리 들어갈 수 있나”를 보여주는 기능이에요

GIS센터개발팀은 현대자동차그룹의 글로벌 커맨드 센터라고 생각해요

저희는 교통정보를 수집·가공하고, 패턴 정보를 만들고, 그걸 바탕으로 경로탐색을 합니다. 

한 줄로 요약하면 데이터를 경로라는 경험으로 바꾸는 팀이죠.

최근에 집중한 비교경로 서비스들이 저희 팀의 역할을 가장 잘 보여준다고 생각해요.

사용자에게 최단시간 경로 하나만 제시하는게 아니라, 

학습을 기반으로 제시하는 자주 가는 길,

머신러닝을 활용한 AI 추천 경로, 

통제 의심 구간 회피 경로 등 10여 가지 대안을 제시했어요.

사용자의 불편함을 데이터로 확인하고 기술로 해결하여,

사용자에게 만족을 가져다주는 역할이 저희 팀의 가장 큰 임팩트입니다.

저는 최근에 주차장 비교경로 서비스를 담당했어요.

기존 내비게이션은 목적지 건물까지만 안내했다면,

저희 팀은 주차장 입구의 실시간 혼잡도까지 고려했어요.

사용자가 타사 내비게이션보다 빠른 경로로 목적지에 도착했는데, 

주차장 입구에서 10분씩 기다리는 불편함을 없앤거죠.

사용자는 화면에서 주차 N분 감소 말풍선이 붙은 경로를 직관적으로 선택할 수 있어요

크게 네 단계예요. 

① 실시간 교통을 모으고,  
② 과거 패턴 정보와 합칩니다. 

③ CCH 기반 경로탐색 엔진이 최적 경로를 계산하고, 

④ 그 결과를 단말에 표시합니다. 

조금 더 자세히 설명해볼게요

실제 도로 위 차량들로부터 '지금 여기 막혀요!' 등의 실시간 교통정보를 수집하고,

해당 정보의 과거 패턴정보를 합쳐서, 수백만 개의 링크에 대한 코스트를 계산하여 전처리를 합니다.

사용자가 목적지를 설정하면, CCH(Contraction Hierarchies) 경로 탐색 알고리즘을 기반으로 

평균 0.5초 안에 최적 경로와 비교 경로 여러 가지를 설정하여 단말에 표시하는 과정을 거쳐요

방금 말씀드린 CCH라는 알고리즘을 사용하는데요,

쉽게 말하자면 '서울에서 부산까지 갈 때는 무조건 경부고속도로 타야지'처럼, 

꼭 지나가야하는 주요 길목들을 미리 계산해두는거예요.

덕분에 사용자가 검색하는 순간에는 전체가 아닌, 

꼭 필요한 부분만 빠르게 계산해서 국내 기준 평균 0.5초의 응답속도를 유지하고 있습니다.

네, 꽤 달라요.

나라마다 교통법규·주행 습관이 다르고, 

운전자들이 편하다고 느끼는 동선도 달라서요. 

그래서 저희는 단순 번역이 아니라 현지 교통 문화에 맞춘 로직으로 서비스를 운영해요.

유럽과 인도에서 현지화 과정을 예로 들어볼게요

유럽은 비넷(Vignette)이라는 유료도로 정책이 있어요. 

우리나라는 톨게이트에서 구간별로 고속도로 요금을 정산하지만,

유럽에서는 기간제 통행권을 사야하거든요.

그래서 경로 상에 비넷 구간을 감지해, 

운전자에게 “이 길은 비넷이 필요해요”라고 안내하고 선택지를 드려요. 

또한 인도 서비스 현지화 과정도 기억에 남아요.

서비스 초기에 유턴이 왜 이렇게 많냐는 현지 피드백을 받은 적이 있어요.

알고 보니 인도는 중앙분리대가 길게 이어진 도로가 많아 바로 좌회전이 안 되고

한참 더 직진을 해서 유턴을 해야 하는 경우가 흔했다고 합니다.

저희는 최단 경로만 생각했는데 

현지 운전자는 조금 돌아도 유턴이 없는 길을 선호했어요

이후 로직을 수정해 유턴 최소화 옵션을 제공하여 고객들로부터 호평을 받은 기억이 나네요.

같은 ‘최적 경로’라도 나라별로 편한 동선이 달라요. 

저희는 그 차이를 데이터·로직으로 흡수해서 현지에서 진짜 편한 길을 안내하려고 합니다.

전기차를 이용하시는 고객분들은 EV 경로 플래너 기능을 꼭 사용해보세요

장거리 주행이라면 내비의 EV 경로 플래너를 꼭 켜고, 

목적지 최소 배터리량을 원하는 값으로 설정하세요. 

단순히 ‘가까운 충전소’가 아니라 잔여량으로 도달 가능한 충전 거점을 포함해 

진짜 도착 가능한 경로를 자동으로 설정해줘서, 

목적지 도착 시 설정한 잔량을 확보할 수 있습니다. 

주행 중 충전 불안감이 확 줄어요.

퇴근길처럼 익숙한 길엔 

자주 가는 길 비교경로나 AI 비교경로를 확인해 보세요. 

내 주행 패턴을 학습한 경로가 

순수 최단·최속보다 '내가 편하게 느끼는 길’을 더 빨리 제안해 줄 때가 많습니다.

저희가 작성한 코드가 50개국 10종의 플랫폼에 반영되기 때문에

오너십(Ownership)문화가 강합니다. 

개발 단계부터 꼼꼼하게 테스트하고, 배포 후에도 전 세계 사용자들의 반응을 모니터링하며

개선점을 찾는 것이 몸에 배어 있어요.

서비스 장애에 대해 굉장히 경각심을 가지고 업무를 진행합니다.

코드 한 줄을 짜더라도 코드 리뷰를 거쳐서 각 기능의 파트장들이 승인을 해야만 그 코드를 merge할 수 있어요.

코드 리뷰가 활발히 이루어지는 팀이에요

일단 저는 9시에 출근해요.

출근 후, 밤새 쌓인 글로벌 서비스 모니터링 로그부터 확인합니다.

그리고 이후엔 동료들의 코드 리뷰를 하고 

오전 중 스크럼 회의에서 오늘 할 일을 공유하고 점심 전까지는 집중 코딩 시간을 갖습니다.

또 오후에는 주로 새로운 기능 개발 비교 경로 등 그리고 성능 최적화 작업을 하고 

그리고 중간중간 단말 부서와 협업 미팅을 합니다.

퇴근 전에는 오늘 작업한 내용을 커밋하고 

테스트를 돌려봅니다.

저희는 크게 두 부서와 긴밀하게 협업해요

교통정보 파트와는 데이터를 주고받는 협업을 해요.

저희가 “이런 교통정보가 필요하다”고 요청하면, 

그 데이터를 가공해 전달해 주고저희는 이를 엔진에 적용해 경로 품질을 높입니다.

단말(헤드유닛) 부서와는 차량 내 최종 UX를 함께 만듭니다.

저희가 경로 API를 제공하면 

단말팀은 “이걸 사용자에게 어떻게 보여줄지”

HMI(Human-Machine Interface) 관점에서 기획하고 구현해요.

예를 들어 통제 의심 구간 기능의 경우, 

저희가 통제 의심 플래그를 API로 내려주면

단말팀은 이를 사용자가 직관적으로 알아볼 수 있는 아이콘으로 표시하는 식입니다.

기획부터 릴리즈까지 스프린트 단위로 지속적으로 싱크를 맞추며 아주 긴밀하게 협업합니다.

모두 중요한 가치지만, 

최종 결정의 기준은 항상 ‘사용자 체감’입니다.

예를 들어, 0.1초 더 빠른 경로가 있지만 

지나치게 많은 골목길을 통과해 운전자가 피곤해진다면

저희는 조금 느리더라도 사용자가 편하게 운전할 수 있는 경로를 선택합니다.

저희의 목표는 가장 빠른 길을 제공하는 게 아니라,

‘사용자가 가장 만족스럽게 주행을 마칠 수 있는 경험’을 제공하는 것이기 때문이에요.

그래서 경로 이탈률 같은 고객 행동 지표가 중요한 판단 기준이 되곤 합니다.

제가 오토에버를 선택한 이유는 국내 1위 나아가 글로벌 탑 티어 차량에 탑재되는 

내비게이션의 심장인 경로 탐색 엔진을 직접 만든다는 임팩트 때문이었어요.

제가 개발한 로직이 전 세계 수억 대의 차량에서 동작하고 

많은 사람들의 이동을 돕는다는 점이 가장 매력적인 도메인이라고 느껴졌어요.

앞으로 제가 커리어적으로 큰 성장을 이룰 수 있을 것 같다고 확신이 들어서

오토에버에 합류했습니다

그럼요, 일단 기대했던 것 이상의 스케일을 다룬다는 점이 가장 인상적이었어요.

50여 개국에 제 기능을 적용하고 대규모 트래픽을 안정적으로 운영하는 경험은

쉽게 접할 수 있는 기회가 아니거든요.

입사 전에는 '오토에버는 소프트웨어 회사겠지'라고 생각했는데,

막상 들어와 보니 단말 부서, 즉 하드웨어(헤드유닛) 담당 부서와의

협업이 예상보다 훨씬 많고 긴밀했어요.

단순 API 개발을 넘어 차량의 HMI(Human-Machine Interface) 환경까지

고려하여 '사용자가 운전 중에도 안전하고 편하게 쓸 수 있는지'를 

함께 고민하는 과정이 특히 인상적이었어요.

팀에서 가장 기억에 남는 에피소드를 하나 꼽자면, 

경로 이탈률과 관련된 경험을 빼놓을 수 없습니다. 

한동안 경로 이탈률이 좀처럼 줄지 않아 팀 전체가 큰 고민에 빠진 적이 있었거든요. 

저희는 분명 ‘가장 빠른 길’을 안내하고 있는데도 

사용자들은 계속 다른 길을 선택해 나가고 있었습니다.

처음에는 더 빠른 길을 찾는 데 집중했지만,

데이터를 면밀히 분석해 보니 사용자들이 원하는 것은 

빠르지만 복잡한 길이 아니라, 

조금 느리더라도 익숙하고 편안하게 달릴 수 있는 길이라는 

사실을 알게 되었습니다. 

결국 ‘최적’의 기준은 사람마다 다르다는 점을 깨닫게 된 것이죠. 

이 경험을 바탕으로 저희는 자주 가는 길, 

AI 추천 경로처럼 사용자의 운전 패턴을 학습해 

다양한 선택지를 제공하는 비교 경로 기능을 중점적으로 개발했습니다. 

그 결과 경로 이탈률은 상반기 대비 9.68%나 감소하며 확실한 개선 효과를 보였습니다.

이 과정에서 팀이 확실히 배운 점이 하나 있습니다.

 ‘엔지니어가 보기엔 최적의 답’과 ‘사용자에게 최적인 답’은 서로 다를 수 있다는 사실입니다. 

데이터를 통해 사용자가 왜 이탈하는지,

어떤 길을 더 선호하는지 깊이 들여다봐야만 진짜 문제를 해결할 수 있다는 점을 다시 한번 느꼈습니다.

가장 핵심이 되는 경로 탐색 엔진은 

성능과 메모리 제어가 중요한 만큼 C++로 개발합니다. 

평균 0.5초라는 빠른 응답 속도를 유지해야 하기 때문에, 

가장 빠르고 세밀한 최적화가 가능한 언어가 필수적이거든요. 

실제로 엔진의 핵심 로직은 C++로 만들고 있습니다.

반면, 서버 영역은 안정성과 유지보수성을 고려해 

Java와 Spring Boot를 사용합니다. 

엔진이 계산한 경로를 단말로 전달하는 API 서버가 Java 기반으로 동작하고, 

Nginx, Tomcat 조합으로 실제 서비스에 제공되고 있어요. 

차량 단말에서 경로 요청이 들어오면 서버가 이를 받아 엔진의 결과를 빠르게 전달하는 구조입니다.

또 방대한 교통 데이터를 분석하고 배치 작업을 자동화할 때는 Python을 활용합니다. 

라이브러리가 풍부하고 프로토타이핑이 빠르기 때문에, 

실험적인 아이디어를 테스트하거나 데이터 처리 파이프라인을 만들 때 가장 효율적이죠.

정리하면, C++(핵심 엔진) – Java/Spring Boot(API 서버) – Python(데이터 분석/배치) 

이렇게 세 축으로 기술 스택이 구성되어 있고, 

각 스택이 맡는 역할이 명확해서 협업 시에도 흐름이 아주 깔끔한 편입니다.

업무 특성상 공부는 꾸준히 하는 편이에요. 

보통 주 1~2회 정도는 해외 기술 블로그나 논문을 찾아보려고 합니다.

특히 Google Maps Engineering Blog나 Uber Engineering Blog 

같이 위치 기반 서비스나 경로 탐색 관련해서 인사이트를 줄 수 있는 곳들을 자주 보는 편이고요. 

아카이브에 올라오는 최신 논문들도 가끔씩 챙겨 봅니다.

실제로 예전에 저희 서비스 중에, 

유독 특정 도시에서만 경로 탐색 속도가 느린 현상이 있었어요. 

그때 관련 논문을 하나 보고 아이디어를 가져와, 

그 지역 도로망 특성을 반영해서 CCH 알고리즘의 가중치를 조정하는 테스트를 해봤어요.

그 결과, 그 지역의 롱테일 쿼리 응답 속도가 평균 15% 정도 개선됐고, 

이 경험을 팀에 공유해서 실제 서비스에도 적용할 수 있었어요.

이런 식으로 “읽고 → 적용해보고 → 효과를 확인하고 → 팀에 공유”하는 사이클을 꾸준히 돌리려고 노력하고 있어요.

시간이 나면 보통 노래방을 가거나 영화를 보고

게임을 하면서 스트레스를 풀어요

쉬는 날에 확실하게 스트레스를 푸는 것이 저만의 리듬이에요😎

그리고 조금 색다른 취미도 있어요. 

바로 체스입니다. 

예전에는 K리그 체스 선수로 활동했고, 

전국대회 준우승도 했고, 

국제대회 4위까지 했었어요. 

한 판 두는 데 보통 두세 시간씩 걸리다 보니, 

끝나고 나면 전체 수순을 처음부터 끝까지 복기하는 게 거의 습관처럼 몸에 배어 있어요

이게 지금 하는 개발 일이랑도 꽤 닮아 있어요. 

긴 코드를 따라가면서 “여기서 왜 이렇게 동작했지?”를 되짚어 보고, 

코드 리뷰할 때 전체 흐름을 머릿속에서 그려보는 과정이 체스 복기랑 비슷하거든요. 

그래서 새로운 기능을 설계할 때나 복잡한 로직을 분석할 때, 

체스를 통해 길러진 집중력이나 복기 능력이 자연스럽게 도움이 되고 있다고 느껴요.

문제정의 -> 해결 -> 효과 구조가 가장 설득력 있다고 생각해요.

단순히 '이런 기술을 써봤어요'가 아니라,

''이런 문제가 있어서(문제정의), 

그걸 해결하려고 이 기술을 선택했고(해결),

그 결과 이만큼 개선했다(효과)'의 스토리 구성이 중요합니다.

저희 팀의 업무도 정확히 이런 구조이기도 하고요.

문제를 다 풀고 나서 Edge Case를 놓치는 분들이 많아요.

다익스트라 문제를 예로 들면,

목적지가 길이 아예 없는 섬 같은 상황이나 성능 최적화를 고려하지 않아

시간초과가 나는 경우가 해당돼요

내비게이션은 어떤 상황에서도 멈추면 안 되기 때문에,

이런 꼼꼼함을 중요하게 보아요.

일단 코드가 실행되게 만든 후,

더 효율적으로 최적화할 방법이 없을까를 

한 번 더 고민하는 습관을 들이면 좋습니다.

책임감과 주인의식을 갖고 업무에 임하시는 분들이 잘 맞아요

내가 작성한 코드가 전 세계 수억 명에게 영향을 주기 때문에

주인의식을 갖고 코드에 책임을 질 줄 알아야 해요.

또한, 사용자를 중심에 두고 고민할 줄 아는 사람이 좋은 성과를 내요.

반대로, 나에게 주어진 업무만 하고, 

'왜' 라는 질문 없이 업무를 처리하는 것이 편하다면

팀에 잘 적응하지 못할 가능성이 커요