[이것도 AI로 될까? — 차 관리 편] 4부 — 기록만 쌓이면 아무도 보지 않는다

Kai U

2026년 8월 22일 • 19분 읽기

이번 편의 요청의 요지
정비 기록과 주기를 계산해서, 교체할 때가 되면 내가 먼저 확인하지 않아도 알려 줘.

기록만 쌓이면 아무도 보지 않는다

사진 한 장으로 정비 기록이 들어가게 됐다. 날짜와 주행거리와 항목이 숫자로 남는다.

실제 화면의 구조는 유지하고, 주행거리와 날짜·정비 수치는 예시값으로 바꾼 게시용 편집본이다.

그런데 며칠 지나고 보니 달라진 것이 별로 없었다. 기록은 잘 쌓이는데 내가 그걸 열어 보지 않는다. 열어 보려면 먼저 지금 뭔가 갈 때가 됐나 하고 궁금해해야 한다. 궁금해하지 않으면 데이터베이스든 메모장이든 그냥 조용히 있는다.

처음 문제로 돌아온 것이다. 나는 판정을 넘기고 싶었지 기록만 옮기고 싶었던 게 아니었다.

그래서 AI에게 기록을 쌓는 데서 멈추지 말고, 언제 무엇을 해야 하는지 계산해서 먼저 알려 주는 흐름을 만들어 달라고 했다. 이번 편의 목표는 입력 자동화가 아니라, 기억과 계산을 내 머리에서 꺼내는 것이었다.

취급설명서의 주기표를 그대로 옮겼다

차를 살 때 받은 책에 정비 주기표가 있다. 항목마다 몇 km 또는 몇 개월이라고 적혀 있다. 그걸 그대로 옮겼다.

옮기면서 알게 된 것이 있다. 항목마다 기준이 다르다. 어떤 것은 거리만 있고, 어떤 것은 기간만 있고, 어떤 것은 둘 다 있다. 둘 다 있으면 먼저 오는 쪽이 기준이다. 엔진오일은 거리로도 기간으로도 걸린다. 차를 안 타도 오일은 늙는다.

메모장에 적을 때는 이 구분을 하지 않았다. 거리만 적어 두고 기간은 머릿속에 있었다. 그래서 오래 안 탄 해에는 거리가 안 찼다는 이유로 넘어가곤 했다.

또 하나. 표에는 "가혹 조건"이라는 항목이 따로 있었다. 짧은 거리를 자주 타거나, 정체가 많거나, 먼지가 많은 곳을 다니면 주기를 줄이라고 적혀 있다. 그러니까 설명서의 숫자는 하나가 아니라 조건에 따라 두 벌이었다. 나는 그동안 앞쪽 숫자만 보고 있었다.

내 차는 설명서와 다르게 탄다

엔진오일을 나는 6,000km쯤에서 간다. 설명서의 기본 숫자와 다르다. 짧은 거리를 자주 타고 시내 주행이 많다. 설명서의 기준으로는 가혹 조건에 가깝다.

그래서 이 항목만 내 기준으로 덮어썼다. 미션오일도 마찬가지다. 첫 교체 시점과 그다음 주기를 내가 아는 값으로 넣었다.

주기표를 통째로 옮기는 것보다 이렇게 하나씩 덮어쓸 수 있는 것이 중요했다. 앞서 메모장에서 힘들었던 것이 바로 이 부분이다. 기준을 바꾸면 그 뒤 계산을 전부 다시 해야 했다. 지금은 숫자 하나만 고치면 나머지는 알아서 다시 계산된다.

그래서 화면에 주기를 고치는 탭을 따로 만들었다. 항목별로 거리와 기간, 며칠 전부터 알릴지를 바꿀 수 있다. 만들 때는 "이걸 자주 쓸까" 싶었는데, 실제로는 주기표를 옮기는 과정에서 내가 가장 많이 쓴 화면이 됐다.

알릴 수 없는 항목이 있었다

옮기다 보니 주기를 못 적는 항목이 나왔다. 브레이크 패드, 타이어, 배터리, 와이퍼.

이것들은 몇 km라고 정해 놓기 어렵다. 어떻게 타느냐에 따라 다르고, 결국 상태를 봐야 아는 것들이다. 설명서에도 "점검"이라고만 적혀 있지 교체 주기는 없다.

처음에는 적당한 숫자를 넣을까 생각했다. 브레이크 패드는 보통 얼마쯤이라고들 하니까. 그런데 그건 내가 아는 것이 아니라 어디선가 들은 것이다. 그 숫자로 알림이 오면 나는 그게 근거 있는 값인 줄 알고 정비소에 갈 것이다.

그래서 둘을 나눴다. 기록은 남길 수 있지만 알림은 하지 않는 항목을 따로 뒀다. 패드를 갈았다는 사실은 남는다. 비용도 집계된다. 다만 "이제 갈 때가 됐다"고 시스템이 먼저 말하지는 않는다.

이 구분을 넣고 나서 화면이 조금 복잡해졌다. 항목 목록에 알림 대상과 기록 전용이 섞여 있으니 헷갈린다. 그래서 알림을 켜고 끄는 스위치를 항목마다 뒀다. 모르는 것을 아는 척하지 않게 하는 대신, 그걸 눈에 보이게 만드는 값은 치러야 했다.

화면을 만들었더니 데이터가 안 나왔다

판정 규칙은 PostgreSQL 뷰로 만들어 뒀다. 항목별로 마지막 정비가 언제였는지, 그 뒤로 얼마나 탔는지, 남은 거리와 남은 날짜가 얼마인지를 계산해서 한 번에 보여 준다. 알림이든 화면이든 이 뷰 하나만 읽으면 되게 해 두는 것이 목적이었다. 판정 규칙을 바꿀 때 고칠 곳이 한 군데면 좋으니까.

폰에서 볼 화면은 웹앱으로 만들었다. 데이터는 Directus를 앞에 세워 읽는다. 표마다 권한을 걸 수 있어서, 화면 전용 계정을 따로 만들고 필요한 다섯 표에만 읽기 권한을 줬다. 주기를 고치는 표에만 쓰기를 열었다.

그런데 화면을 만들고 열었더니 빈 목록이었다.

사용자 화면 뒤에서 Directus가 정비 항목과 표시 이름을 관리하는 모습이다. 내부 레코드 식별자와 사용하지 않는 설정 패널은 게시용 이미지에서 덜어 냈다.

원인은 Directus 쪽이었다. 원본 표는 권한을 걸어 열어 줄 수 있는데, SQL 뷰는 그 목록에 나타나지 않았다. 데이터베이스에 만들어 둔 그 계산 결과를 바깥으로 내보내 주지 않는 구조였다.

한동안 설정을 뒤졌다. 되게 만드는 방법을 찾다가 결국 방향을 바꿨다. 계산을 화면 쪽에서 한 번 더 하기로 했다. 원본 표 다섯 개를 읽어다가, 뷰가 하던 것과 같은 계산을 자바스크립트로 다시 한다.

같은 계산이 두 곳에 생겼다. 좋은 구조는 아니다. 한쪽만 고치면 화면과 알림이 서로 다른 말을 하게 된다. 그래서 화면 쪽 계산을 별도 파일로 떼어 두고 시험을 붙였다. 브라우저와 시험이 같은 파일을 쓰게 해 두고, 실제 값으로 판정 결과를 검사한다. 미션오일이 몇 km 남았는지 같은 것을 숫자로 박아 두었으니, 규칙을 고쳐서 그 값이 달라지면 바로 드러난다.

우회하기로 정했으면 그 우회가 만든 위험도 같이 처리해야 한다. 그러지 않으면 몇 달 뒤에 "화면에는 아직 여유 있다고 나오는데 알림은 왜 왔지" 하고 헤매게 된다.

같은 날 기록이 서로를 덮었다

정비 기록을 넣으면 거기 적힌 주행거리가 자동으로 주행거리 이력에도 들어가게 해 뒀다. 명세서에 이미 찍혀 있는 값이니 따로 넣을 이유가 없다. 데이터베이스 트리거로 처리했다. 정비 기록이 들어오면 그 행의 날짜와 주행거리를 주행거리 표에 함께 넣는다.

그런데 정비 기록을 저장했는데 화면의 현재 주행거리가 안 바뀌는 일이 있었다. 65,500km짜리 기록을 넣었는데 화면은 62,300km 그대로였다.

원인은 내가 넣어 둔 규칙이었다. 하루에 여러 번 들어와도 한 줄만 남기려고 날짜에 유일 제약을 걸고, 충돌하면 아무것도 하지 않게 해 뒀다. 그러니까 같은 날짜에 이미 기록이 있으면 새로 들어온 것을 그냥 버렸다. "한 줄만 남긴다"는 의도가 "먼저 들어온 것이 이긴다"로 동작하고 있었다.

고치는 방향은 두 가지였다. 나중에 들어온 것이 이기게 하거나, 더 큰 값이 이기게 하거나. 더 큰 값을 골랐다. 주행거리는 줄어들지 않는다. 그리고 지난 명세서를 뒤늦게 넣는 경우가 있는데, 그때 과거의 작은 값이 현재 값을 끌어내리면 안 된다.

규칙을 고치면서 이미 저장된 기록들도 같은 규칙으로 다시 훑게 했다. 규칙만 고치고 지나가면 고친 시점 이후의 기록만 맞고 그전 것은 틀린 채로 남는다.

API를 붙이면 무엇이 좋아지는지 따져 보았다

여기까지 오니 남은 것은 현재 주행거리였다. 정비를 받을 때마다 갱신되지만 그 사이에는 멈춰 있다.

차에는 통신 기능이 있고 제조사가 개발자용 접속 방법을 공개해 두었다. 등록하면 차의 상태를 프로그램으로 읽어 올 수 있다. 매일 한 번 주행거리를 받아 오면 내가 아무것도 안 해도 판정이 최신으로 유지된다. 그림으로는 깔끔했다.

붙이려고 보니 딸린 것이 많았다.

인증 절차를 따로 만들어야 한다
받은 인증은 만료되므로 갱신하는 장치가 필요하다
갱신이 실패하면 알아차릴 방법도 있어야 한다
규격이 바뀌면 따라가야 한다
가입하고 차량 연동 승인을 받아야 시작할 수 있다

목록을 적어 놓고 보니 이 중 어느 것도 한 번 만들고 끝나는 것이 아니었다. 인증 갱신은 계속 돌아야 하고, 규격 변경은 언제 올지 모른다. 만드는 비용보다 데리고 사는 비용이 크다.

고장 나는 방식도 마음에 걸렸다. 이런 연결은 소리 없이 멈춘다. 인증이 만료된 날부터 데이터가 안 들어오는데 화면은 멀쩡하다. 마지막으로 받은 값이 그대로 남아 있으니까. 숫자가 이상해 보이지도 않는다. 그냥 어제와 같을 뿐이다.

이걸 만들면서 실제로 비슷한 일을 한 번 겪었다. 코드를 서버로 옮기는 데 쓰던 접속 열쇠에 만료일이 있었다. 그날이 오면 자동으로 돌던 것이 조용히 멈춘다. 화면에는 아무 표시도 없다. 그래서 만료일 없는 방식으로 바꿨다. 같은 종류의 함정을 또 놓고 싶지 않았다.

필요한 값은 주행거리 하나뿐이었다

따지다가 판정식을 다시 열어 봤다.

교체 시기를 계산하는 데 들어가는 값은 셋이다. 마지막으로 그 항목을 갈았을 때의 주행거리와 날짜, 그리고 지금 주행거리. 앞의 둘은 내 기록에 이미 있다. API에서 가져올 것은 지금 주행거리 하나뿐이었다.

숫자 하나를 자동으로 받자고 인증과 갱신과 규격 추적을 떠안는 셈이다. 그래서 안 붙이기로 했다.

대신 이렇게 한다. 정비를 받으면 명세서에 주행거리가 찍혀 있으니 그때 갱신된다. 그 사이에는 가끔 내가 직접 넣는다. 계기판을 보고 숫자만 보내면 된다. 이 경로는 이미 만들어 둔 것이 있었다. 사진 없이 숫자만 넣는 입력이 필요해서 진작 붙여 뒀는데, 그게 여기서 쓰였다.

그것만으로는 부족한 구석이 있다. 정비소에 안 가는 동안에는 주행거리가 멈춰 있다. 6개월 동안 정비를 안 받고 10,000km를 타면 시스템은 그 사실을 모른다.

그래서 추정식을 하나 만들려고 했다. 기록이 두 개만 쌓이면 하루 평균이 나온다. 마지막 기록에 하루 평균과 지난 날짜를 곱하면 지금을 어림할 수 있다. 실측이 들어올 때마다 평균도 정확해지니 시간이 지나면 나아질 것이다.

만들지 않았다. 제조사 앱을 다시 열어 보니 주행거리가 그냥 적혀 있었다. 월 주행거리와 월 평균 연비도 있고, 최근 주행 기록을 열두 달까지 볼 수 있고, 내려받을 수도 있었다.

추정은 실측이 없을 때 쓰는 것이다. 실측이 있는데 추정식을 만들면, 나는 그 식을 검증하려고 다시 실측을 찾게 된다. 없는 값을 지어내는 코드를 한 줄이라도 두면 그 값이 맞는지 계속 신경 써야 한다. 그럴 바에는 숫자를 보고 보내는 편이 정확하고, 하는 일도 적다.

안 만든 것이 다행이었다는 것은 나중에 알았다. 앱에서 주행 기록을 내려받아 열두 달을 세어 봤다. 한 달에 1,182km를 탄 달이 있고 4,296km를 탄 달이 있었다. 3.6배 차이다. 하루 평균을 곱하는 방식은 이 편차 앞에서 의미가 없다.

더 정확히 말하면, 내가 처음 하루 평균을 재 봤을 때 나온 값은 169km였다. 기록 두 개 사이가 사흘이었기 때문이다. 열한 달로 다시 재니 89km였다. 사흘치로 잰 값이 두 배 가까이 부풀어 있었다. 그 숫자로 "지금 몇 km쯤"을 계산해서 알림에 실었다면, 나는 그게 틀린 줄도 모르고 정비소에 갔을 것이다.

붙일 자리는 열어 뒀다. 주행거리가 어디서 왔는지 표시하는 칸을 처음부터 만들어 뒀다. 나중에 내려받은 기록을 한꺼번에 넣게 되면 그 칸에 출처만 하나 더하면 된다. 다른 곳은 건드릴 필요가 없다.

한 달에 한 번 먼저 말을 건다

이제 마지막 조각이다. 판정한 결과를 내가 찾아가서 보는 게 아니라 먼저 알려 주게 했다.

n8n에 워크플로를 하나 더 만들었다. 스케줄로 깨어나서, 알림 대상만 걸러 주는 뷰를 읽고, 보낼 것이 있으면 텔레그램으로 보낸다. 노드 다섯 개짜리다. 기록을 넣는 봇과 같은 채널을 쓴다.

매월 1일 아침에 한 번 확인한다. 교체 시기가 지났거나 다가온 항목이 있으면 이렇게 온다.

🚗 정비 알림

⚠️ 지금 교체
  엔진오일 · 1,200km 초과

🔜 곧 교체
  에어클리너 · 800km 남음

📍 주행거리를 34일째 못 받았습니다.
   /odometer 로 계기판 숫자를 알려주세요.

기준 61,200km · 2026-05-31

주기를 매일로 하지 않은 데는 이유가 있다. 교체 시기가 지난 항목은 갈기 전까지 계속 걸려 있다. 매일 보내면 같은 문장이 매일 온다. 그러면 읽지 않게 되고, 읽지 않게 되면 정작 필요한 날에도 안 읽는다. 정비 주기가 수천 km 단위이니 한 달에 한 번이면 놓칠 일도 없다.

보낼 것이 없으면 아무것도 보내지 않는다. 매달 "이상 없음"을 보내는 것도 같은 이유로 하지 않았다. 조용한 것이 정상이라는 뜻이 되게 했다.

주행거리를 한 달 넘게 못 받았으면 그 이야기도 함께 붙인다. 거리 판정은 그 숫자에 매달려 있는데, 그게 오래됐으면 판정도 그만큼 낡은 것이다. 알림이 스스로 재료를 요구하는 셈이다.

메시지에 판정 기준이 된 주행거리와 날짜도 함께 적는다. 처음에는 넣지 않았는데, 알림을 받고 "이게 언제 기준이지" 하고 화면을 열어 보게 되더라. 그럴 거면 알림에 적어 두는 게 맞다.

자동화의 마지막 한 칸은 비워 둔다

세 편을 통틀어 사람이 하는 일이 둘 남았다. 정비소를 나오면서 명세서를 한 장 찍는 것, 그리고 가끔 계기판 숫자를 알려 주는 것.

둘 다 없앨 수 있었다. 사진은 찍자마자 저장까지 자동으로 이을 수 있었고, 주행거리는 API로 매일 받아 올 수 있었다. 두 번 다 그렇게 하지 않았다.

앞의 것은 읽기가 틀릴 수 있어서다. 한 줄이 통째로 사라지는 것을 봤다. 뒤의 것은 유지 비용 때문이다. 숫자 하나를 위해 계속 돌봐야 하는 장치를 늘리고 싶지 않았다.

만들면서 자꾸 자동화를 늘리려는 쪽으로 손이 갔다. 한 칸이라도 사람이 하는 곳이 남아 있으면 덜 만든 것 같았다. 이번에도 그래서 API 문서를 한참 읽었다.

그런데 다 만들고 보니 덜어낸 자리가 이 도구를 계속 쓰게 만들고 있다. 틀린 기록이 조용히 쌓이지 않고, 어느 날 조용히 멈춰 있지도 않다. 고장 나면 내가 알아차릴 수 있는 방식으로 고장 난다.

메모장에 계산을 적던 일은 없어졌다. 그 자리에 사진 한 장과 가끔 보내는 숫자 하나가 들어왔다. 그 정도면 충분히 넘긴 것 같다.

이제 정비 시기를 확인하려고 매번 앱과 메모장을 열지 않는다. 알림이 오면 기준 날짜와 주행거리를 보고 판단하면 된다. AI가 대신 정비 결정을 내리는 것이 아니라, 내가 결정해야 할 순간을 놓치지 않게 앞에서 알려 주는 것이다.

이 시리즈에서 가장 크게 달라진 부분도 여기 있다. 사진 한 장으로 기록을 남긴 것이 시작이었다면, 주기를 계산해 알려 주는 순간부터 그 기록이 생활 속 도구가 됐다.

다음 5부에서는 이 도구를 집 밖에서도 써야 한다는 문제가 남는다. 정비소는 집에 없으니, 집 안에서만 되는 시스템은 아직 절반짜리였다.

제작 기록

이 글의 초고 작성과 자료 정리, 그리고 정비 주기 판정과 알림의 설계·구현·시험에는 Claude Code가 사용됐다. 시리즈의 제목·본문 윤문과 재구성, 게시용 이미지 편집과 Ghost 드래프트 반영에는 ChatGPT(Codex)가 함께했다. 공개 발행 전 전체 내용과 화면은 사람이 직접 검토하고 수정했다. 본문의 주행거리와 항목 숫자는 예시로 바꾼 값이다.