> ## Content Index
> Fetch the complete content index at: https://withkai.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# [이것도 AI로 될까? — 차 관리 편] 4부 — 기록만 쌓이면 아무도 보지 않는다
- URL: https://withkai.io/igeosdo-airo-doelgga-ca-gwanri-pyeon-4bu-girogman-ssahimyeon-amudo-boji-anhneunda/
- Published: 2026-08-22T14:15:35.000Z
- Updated: 2026-08-22T14:15:35.000Z
- Author: Kai U
- Tags: AI, IT·개발, 도커, 생산성

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

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

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

![정비 항목별 남은 거리와 상태를 보여 주는 화면 편집본](https://withkai.io/content/images/2026/08/carlog-4-homepage-sanitized-v2.png)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 알릴 수 없는 항목이 있었다

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

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

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

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

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

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

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

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

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

![Directus에서 정비 항목을 데이터로 관리하는 화면](https://withkai.io/content/images/2026/08/carlog-4-directus-service-items-sanitized.png)

*사용자 화면 뒤에서 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)가 함께했다. 공개 발행 전 전체 내용과 화면은 사람이 직접 검토하고 수정했다. 본문의 주행거리와 항목 숫자는 예시로 바꾼 값이다.