차량 데이터에 파운데이션 모델이 필요해진 이유

안녕하세요, 디라이브에서 차량 AI 모델을 만들고 있는 김민재입니다.

차량 관제는 오래도록 GPS였습니다. 차가 어디 있는지는 알려주지만 어떤 상태인지는 알려주지 않습니다. 디라이브는 차량 ECU에서 나오는 신호(속도, 엔진 회전수, 스로틀, 브레이크, 조향각 같은 것들)를 초 단위로 받아, 그걸로 차의 상태를 판단하는 회사입니다.

"상태를 판단한다"는 건 결국 이런 질문에 답하는 일입니다. 이 차, 고장 나기 전에 조짐이 보이는가. 방금 사고가 난 건가. 그리고 고객사가 다른 차종을 들여와도 이게 그대로 되는가. 저희는 이 세 질문을 각각 따로 풀려다 세 번 같은 벽에 부딪혔고, 그래서 방향을 바꿔 주행 신호의 "평소"를 먼저 배우는 공통 모델을 만들었습니다. 이 글은 그 모델이 왜 필요해졌는지와 그것이 무엇인지를 소개합니다.

세 번 부딪힌 벽

첫째, 라벨이 없습니다. 모델에게 "이게 고장이다, 이게 사고다"라고 알려줄 정답 표시가 라벨인데, 고장은 드물고 사고는 더 드뭅니다. 저희가 구할 수 있던 사고 데이터는 수천 건 단위였고 그마저 외부 공개 데이터였습니다. 고장은 "어느 차가 언제 무슨 고장이었다"는 기록 자체가 거의 없습니다. 정답을 보여주며 가르치는 방식으로는, 정답이 없는 문제는 아예 시작을 못 합니다.

둘째, 차종마다 신호가 다릅니다. 이름도, 단위도, 주기도 다릅니다. 여러 차종 데이터를 그냥 섞어서 학습시켜 봤더니 오히려 성능이 떨어졌습니다. 채널을 차종 간에 같은 의미로 맞춰 정렬한 뒤에야 섞는 게 손해가 아니게 됐습니다. 그리고 이 정렬 작업이 생각보다 큰 일이었습니다. 한번은 학습 데이터의 절반 넘게 차지하던 차종의 스로틀 채널이, 신호 이름 하나를 잘못 참조해 통째로 비어 있던 걸 몇 달 뒤에야 발견했습니다. 모델이 배우기 전에 사람이 정렬을 제대로 해야 했습니다.

셋째, 차종이 바뀌면 처음부터입니다. 질문별로 만든 모델은 특정 차종의 라벨 데이터로 학습돼 있으니, 고객사가 다른 차종을 들여오면 데이터 수집부터 다시 해야 합니다. 차종이 하나 늘 때마다 이 과정을 반복하는 구조는 감당이 안 됩니다.

세 벽의 공통점은 하나였습니다. 판단을 배우기 전에 "평소 주행이 어떻게 움직이는지"를 먼저 아는 모델이 없었다는 것입니다.

그래서 만든 것

라벨 없는 주행 데이터는 많습니다. 차는 매일 달리고, 신호는 매초 나옵니다. 이걸로 먼저 배우게 하자는 게 출발점이었습니다.

방법은 단순합니다. 6.4초짜리 주행 구간에서 신호 일부를 가리고, 가려진 부분을 맞히게 합니다. 정답이 데이터 안에 있으니 라벨이 필요 없습니다. 이걸 공개 데이터 94개 차종, 약 200만 구간으로 반복하면 모델은 가속하면 회전수가 따라 오르고, 핸들을 꺾으면 좌우 바퀴 속도가 벌어지고, 브레이크를 밟으면 속도가 이렇게 줄어든다는 "평소"의 감각을 얻습니다.

이 모델 하나가 바닥이 되고, 그 위에 판단을 얹습니다. 고장 조짐도 사고도 결국 "평소와 다른 움직임"이라, 평소를 아는 모델 위에서는 적은 라벨로도 판단을 배울 수 있습니다. 새 기능을 붙일 때 처음부터 다시 학습하지 않습니다. 이런 구조를 파운데이션 모델이라고 부릅니다. GPT 같은 범용 AI가 문장으로 이걸 했다면, 저희는 주행 신호로 합니다. 범용 AI는 엔진 회전수가 초 단위로 어떻게 움직이는지 본 적이 없으니까요.

실제로 되는가

세 벽에 하나씩 대응하는 결과가 있습니다.

• 라벨 희소: 사고 감지 헤드를 이 모델 위에 얹었더니, 신호 통계만 쓰던 기존 방식보다 모든 지표에서 앞섰습니다. 실시간 스트림에서도 학습 때와 같은 값을 냅니다.
• 차종 확장: 학습 때 없던 차종을 그대로 던져도, 그 차종 데이터 전부로 새로 학습한 모델보다 주행 신호를 잘 맞힙니다. 저희가 직접 하네스를 물려 수집한 아반떼에서도 같았습니다.
• 운영: 추론은 병목이 아니었습니다. 6시간 연속 실시간 구동에서 수신부터 판정까지 20ms대였습니다.

만들면서 배운 것

"데이터를 많이 넣으면 된다"가 아니었습니다. 초기에는 학습 데이터를 키워도 성능이 금방 포화됐습니다. 결정적이었던 건 양보다 어떤 채널을 넣느냐였습니다. 채널을 5개에서 17개로 늘린 데이터는, 채널 5개짜리 데이터의 4배 분량과 맞먹었습니다. 지금 저희 수집 우선순위가 "더 오래"가 아니라 "더 많은 채널"인 이유입니다.

정렬 작업이 모델링보다 오래 걸렸다는 것도 배운 점입니다. 위에서 말한 스로틀 채널 사고 같은 것들은 모델이 아니라 파이프라인에서 터졌습니다. 앞선 글(차량에서 데이터를 꺼내는 방법)이 "해독은 차종마다 다시"라고 했는데, 그 해독 다음의 정렬도 같은 성격의 일이었습니다.

마치며

앞으로 이 블로그에 하나씩 풀 예정입니다. 새 차종을 재학습 없이 붙이는 이야기, 시뮬레이션 주행으로 학습 데이터를 만드는 이야기, 신호가 빠졌을 때 모델이 어떻게 버티는지 같은 것들입니다.

차량 데이터로 무엇을 판단하고 싶으신지 있으시면 편하게 문의해 주세요.