BLOG인사이트

성공 기록, 정말 좋은 기록일까?

디라이브7분 읽기

성공 기록, 정말 좋은 기록일까?

차량 데이터를 다루다 보면 "이 값, 이 차에서 나오나?"를 하루에도 몇 번씩 확인합니다. 어떤 신호가 어느 경로로 나오는지, 단말이 어떤 값은 보내고 어떤 값은 안 보내는지 같은 것들입니다.

처음에는 나오는 것만 적었습니다. 나오는 건 바로 제품에 들어가니까 자연스럽게 기록이 남았고요. 나오지 않는 건 머릿속에만 두었는데, 프로젝트가 몇 개 겹치자 그 기억이 제일 먼저 흐려졌습니다. 그래서 언제부턴가 "불가"도 똑같이 적기 시작했습니다. 지금은 제가 가장 자주 여는 문서가 바로 그 기록입니다.

기억은 생각보다 빨리 흐려집니다

작은 회사라 한 사람이 여러 일을 같이 봅니다. 같은 주에 차량 신호를 분석하다가, 관제 단말을 붙이다가, 정부 과제 문서를 씁니다. 그러다 한참 뒤 예전 결론을 다시 꺼내 보면, 결론은 기억나는데 왜 그렇게 판단했는지가 잘 떠오르지 않습니다. 결국 같은 확인을 한 번 더 하게 됩니다.

AI 에이전트를 쓰기 시작하면서 이 문제가 더 잘 보였습니다. 에이전트는 매번 백지에서 시작합니다. 제가 적어 두지 않은 결론은 에이전트 입장에서는 없는 결론이라, 이미 끝난 확인을 처음부터 성실하게 다시 합니다.

진단 포트가 그랬습니다. 한때 테스트 차량의 진단 포트로 어떤 주행 정보를 얻을 수 있는지, 표준 항목부터 제조사 전용 영역까지 하나씩 다 확인한 적이 있습니다. 차속 같은 기본 항목도 미지원 응답이 오는 경우가 있었고, 제조사 전용 영역은 거부 응답으로 막혀 있었습니다. 이 결과를 근거로 수집 방식을 바꿨고, 지금은 차량 내부 통신을 직접 받아서 차속, 기어, 배터리 잔량 같은 데이터를 검증된 신호로 모으고 있습니다. 경로별 차이는 차량에서 데이터를 꺼내는 세 가지 방법에 따로 정리해 두었습니다.

"없다"고 쓰기 전에

기록을 쓰면서 제일 조심하게 된 단어가 "없다"입니다. 차량 데이터에서 "없다"는 대부분 "이 경로로, 이 조건에서는 안 보였다"는 뜻이거든요. 그 범위를 빼고 적으면 결론이 실제보다 훨씬 넓어집니다.

차종이 바뀔 때도 마찬가지입니다. 같은 제조사의 다른 차종에서는 전방 레이더가 잡은 물체 목록이 별도 통신선으로 나옵니다. 새로운 테스트 차량에서도 비슷할 거라 기대했는데, 지금 수집하는 위치에서는 그 통신선이 보이지 않았습니다. 그래서 "물체 목록 없음" 대신 "현재 수집 위치에서는 관측 안 됨"이라고 적어 두었고, 그 뒤로는 차종마다 구조를 따로 확인하고 나서 신호를 씁니다.

칸적은 내용
항목차선 편차
결론진단 포트 경로에서는 미지원. 차량 내부 통신에서는 확인
차량테스트 차량 A
수집 기기진단 스캐너 S, 차량 통신 수신 장비 P
수집 방식진단 포트 표준 요청 / 차량 내부 통신에 분기 연결, 수신 전용
일시 · 조건20XX년 X월 X일, 실차 세션 #01
사용 프로그램진단 요청 도구 D, 신호 분석 도구 C, 자체 검증 스크립트 V
검증서로 다른 세 신호를 계기판 표시값과 교차 확인
확신도확정
현재 상태차량 내부 통신 경로로 수집 중

칸이 많아 보이지만 지키는 원칙은 단순합니다. 경로, 조건, 검증 방법 중 하나라도 비어 있으면 "확정"이라고 쓰지 않습니다. "추정"이나 "판단 보류"로 두고, 뭘 확인하면 결론이 바뀔지를 같이 적어 둡니다. 문서 이름에도 날짜를 붙여서, 나중에 결론이 바뀌면 어느 날 어떤 확인부터 다시 보면 되는지 바로 찾을 수 있게 합니다.

값이 나와도 믿으면 안 되는 것

이 기록에 "불가"만 있는 건 아닙니다. 값은 멀쩡히 나오는데 그대로 믿으면 틀리는 것들도 같이 적습니다. 개인적으로는 이쪽이 더 무섭습니다. 안 나오는 건 바로 티가 나지만, 틀린 값은 그럴듯한 그래프가 되어 조용히 결론에 섞이니까요.

공개된 신호 정의 파일이 그랬습니다. 처음엔 이걸 출발점으로 삼았는데, 앞차와의 상대속도나 충돌까지 남은 시간 같은 항목이 33분을 달리는 내내 한 값에 멈춰 있었습니다. 조향각도 정의서에 적힌 필드 하나는 계속 0이었습니다. 이런 항목에는 "정의서 매핑 무효, 사용 금지"를 붙여 두었고, 실차에서 확인한 신호만 남긴 자체 정의서를 따로 만들었습니다. 조향각은 실제 값이 나오는 메시지를 찾아 옮겼고, 지금은 그 정의서를 기준으로 데이터를 읽습니다.

관제 단말도 비슷했습니다. 처음 연동했을 때 한국 시각에 UTC 표시가 붙어 들어와서 기록이 9시간씩 밀렸고, 차가 서 있는데도 속도가 마지막 값에 멈춰 있는 경우가 있었습니다. 이런 건 수신 단계의 보정 규칙으로 정리해 두고, 데이터가 들어오는 시점에 바로 적용하고 있습니다.

요즘 이 기록을 가장 많이 읽는 건 AI입니다

처음엔 저 혼자 보려고 쓴 기록이었습니다. 지금은 다른 프로젝트를 마치고 돌아온 제가 읽고, 새로 합류한 동료가 읽고, 무엇보다 AI 에이전트가 읽습니다. 에이전트에게는 작업을 시작하기 전에 이 기록부터 읽게 해 두었습니다.

에이전트가 독자가 되면서 쓰는 방식이 꽤 바뀌었습니다. 사람은 "아마 안 될 듯"을 보면 "확인은 안 했구나" 하고 알아서 걸러 읽습니다. 에이전트는 그걸 "안 된다"로 받아들이기도 하고, 그냥 무시하기도 합니다. 그래서 확인한 것과 추정한 것을 꼭 나눠 적고, 결론 옆에 다음에 뭘 하라는지도 한 줄 붙입니다. "진단 포트로 차속 요청 재시도 금지" 같은 식입니다. 사람이 보기엔 좀 딱딱한데, 이 한 줄이 있으면 에이전트가 끝난 조사를 다시 시작하지 않습니다.

💡 에이전트가 읽는다고 생각하고 쓰면, 사람이 읽기에도 더 정확한 기록이 됩니다.

"불가"도 언젠가는 바뀝니다

기록이 쌓이면서 생긴 고민도 있었습니다. 한 번 "불가"로 적힌 항목은 아무도 다시 열어 보지 않게 되고, 에이전트가 기록을 충실히 따를수록 더 그렇습니다. 그런데 차종이 바뀌거나, 수집 장비나 펌웨어가 바뀌면 어제의 "불가"가 오늘은 틀릴 수 있습니다.

그래서 지금은 "불가" 항목마다 언제 다시 볼지를 같이 적습니다. 수집 위치가 바뀌면 다시 확인한다든지, 새 펌웨어가 나오면 이 항목부터 본다든지 하는 식입니다. 그런 변화가 생기면 해당 항목부터 다시 확인합니다.

마치며

새 차와 새 장비를 다룰 때마다 확인할 게 쌓입니다. 결과를 보면 "가능"보다 "불가"가 더 많습니다. 초기에 그걸 하나씩 적어 둔 덕분에, 지금은 새 일을 시작할 때 이미 확인된 길 위에서 출발합니다.

성공 기록은 어디로 가야 하는지 알려 주고, 불가 기록은 어디로 가지 않아도 되는지 알려 줍니다. 둘이 함께 있을 때 비로소 좋은 기록이 됩니다.

목록으로

우리 현장에 맞는 서비스를 찾아보세요

운영 방식에 맞는 플랫폼을 제안해드립니다