“자료를 한곳에 모으면 GPT가 알아서 찾아줄까?”
1편에서 내 차에 대해 물어보면 실제 기록을 근거로 답해주는 GPT가 필요했던 이유를 이야기했습니다. 그다음 해야 할 일은 흩어져 있던 자료를 모으는 것이었습니다.
자동차등록증, 정비명세서, 보험수리 견적서, 자동차검사 기록, 타이어 교체 내역처럼 가지고 있던 자료부터 정리했습니다.
처음에는 이것들을 한곳에 모아두면 될 것 같았습니다. 그런데 자료가 많아질수록 다른 문제가 생겼습니다.
PDF와 사진을 한 폴더에 모아두는 것과, AI가 필요한 순간에 정확한 답을 찾을 수 있도록 데이터를 관리하는 것은 다른 일이었습니다.
예를 들어 “앞 타이어 언제 교체했지?”라고 물었다고 해보겠습니다.
AI가 정확하게 답하려면 타이어 교체 기록만 필요한 것이 아닙니다. 언제 교체했는지, 당시 주행거리는 얼마였는지, 앞뒤 어느 타이어였는지, 어디에서 작업했는지까지 서로 연결되어 있어야 합니다.
그래서 차량 자료를 모으는 것보다 먼저 AI가 찾아 쓸 수 있는 구조로 바꾸는 작업이 필요했습니다.
✓ 차량 자료를 한곳에 모으는 것만으로는 부족했다
제 차량 자료에는 성격이 다른 정보가 섞여 있었습니다.
자동차등록증에는 차량의 기본정보가 있고, 정비명세서에는 정비일과 주행거리, 작업 항목과 비용이 있습니다.
보험에는 보험료와 만기일이 있고, 자동차검사는 검사받은 날짜와 다음 검사 시점이 중요합니다.
타이어는 조금 다릅니다.
교체 날짜만 기록해서는 부족하고 어느 위치의 타이어를 교체했는지와 당시 주행거리도 함께 봐야 합니다.
이 모든 정보를 하나의 표에 계속 추가하면 처음에는 편해 보이지만 시간이 지나면서 오히려 찾기 어려워집니다.
그래서 Notion에 차량 관리 공간을 만들고 정보의 성격에 따라 나누기 시작했습니다.
실제로 만든 구조는 다음과 같습니다.
| 구분 | 무엇을 기록하는가 |
|---|---|
| 차량 정보 | 기본 제원, VIN, 가격, 취득비용 등 |
| 정비 이력 | 정비·수리·타이어·소모품 작업 |
| 소모품 기준 | 엔진오일·필터·타이어 등의 점검 기준 |
| 주행거리 기록 | 날짜별 주행거리 |
| 차량 일정 | 보험 만기·검사·세금·점검 예정 |
| 주유 기록 | 주유일·주유량·금액·주행거리 |
| 타이어 상태 | 앞뒤·좌우 타이어별 교체와 점검 상태 |
| 받은자료함 | 새 PDF·사진을 분석하기 전 모아두는 곳 |
| 월간 리포트 | 비용·주행·정비·예정일 요약 |
중요했던 것은 DB를 많이 만드는 것 자체가 아니었습니다. 나중에 어떤 질문에 답해야 하는지를 기준으로 데이터를 나누는 것이었습니다.

✓ 정비 기록은 문서가 아니라 ‘사건’으로 저장했다
정비 한 번을 받아도 관련 자료가 하나만 생기는 것은 아닙니다.
견적서가 있을 수 있고, 정비명세서와 결제 영수증이 따로 있을 수도 있습니다.
이것을 파일 개수대로 기록하면 실제로는 한 번의 정비인데 여러 건의 정비를 받은 것처럼 데이터가 쌓일 수 있습니다.
그래서 기준을 문서가 아니라 실제 발생한 사건으로 잡았습니다.
같은 날 같은 정비소에서 여러 자료가 만들어졌더라도 각각의 파일을 별개의 정비로 기록하지 않습니다.
반대로 같은 날 이루어진 작업이라도 앞으로 관리해야 할 의미가 다르면 구분할 필요가 있습니다.
예를 들어 보험수리와 타이어 교체가 같은 날 이루어졌다고 해도 보험수리는 수리 이력으로, 타이어 교체는 향후 타이어 상태와 점검 기준으로 활용됩니다.
결국 중요한 것은 파일 이름이 아니었습니다. 이 자료가 내 차에서 발생한 어떤 일을 설명하는가를 정하는 것이 먼저였습니다.
✓ 날짜와 금액도 그냥 숫자로 저장하지 않았다
차량 데이터를 정리하면서 의외로 조심해야 했던 것이 날짜와 금액이었습니다.
예를 들어 문서를 오늘 업로드했다고 해서 오늘이 정비일은 아닙니다.
과거 정비명세서를 뒤늦게 발견해 오늘 등록하더라도 차량 이력에는 실제 정비받은 날짜가 들어가야 합니다.
그래서 업로드한 날짜보다 문서에서 확인되는 실제 발생일을 우선하도록 기준을 잡았습니다.
금액도 마찬가지입니다.
정비명세서에 적힌 총액과 실제 카드 결제금액이 다를 수도 있습니다.
AI가 문서에서 발견한 숫자를 무조건 더하거나 아무 숫자 하나를 비용으로 선택하면 기록이 틀어질 수 있습니다.
그래서 차량관리에서는 단순히 ‘금액 = 숫자’로 보지 않고, 명세금액인지, 실제 결제금액인지, 보험수리 비용인지, 차량 취득비용인지 그 의미까지 구분하도록 했습니다.
이 기준이 있어야 나중에 “올해 실제 정비비로 얼마를 썼지?” 같은 질문에도 제대로 답할 수 있습니다.
✓ 원본 자료와 AI가 사용하는 데이터도 분리했다
PDF와 사진을 버리고 숫자만 남기는 방식도 피했습니다.
AI가 추출한 데이터가 언제나 맞다고 볼 수 없기 때문입니다.
그래서 원본 자료는 그대로 보존하고, AI가 읽어서 정리한 값은 별도의 구조화된 데이터로 관리하는 방향을 잡았습니다.
구조는 간단합니다.
원본 PDF·사진 → 내용 확인 → 필요한 값 추출 → 기존 기록과 비교 → 구조화된 데이터로 저장
이렇게 하면 나중에 값이 이상할 때 원본 문서를 다시 확인할 수 있습니다.
또 하나의 원칙도 정했습니다.
AI는 기록을 확정하는 사람이 아니라 제안하는 역할을 합니다.
문서에서 읽은 내용을 바로 차량관리 기록으로 확정해버리는 것이 아니라, 확인할 수 있는 값인지 판단하고 필요한 경우 사람이 검토한 뒤 확정하는 구조입니다.
정확한 차량관리에서는 자동화 속도보다 이 과정이 더 중요하다고 생각했습니다.
✓ 자료를 넣을 때마다 DB를 찾는 것도 불편했다
데이터 구조를 만들어놓고 보니 또 하나의 현실적인 문제가 생겼습니다.
새 정비명세서가 생길 때마다 ‘이건 정비 이력에 넣어야 하나?’ ‘타이어 상태도 같이 수정해야 하나?’ ‘주행거리 기록에도 넣어야 하나?’를 사용자가 판단해야 한다면 오래 사용하기 어렵습니다.
그래서 별도의 받은자료함(Inbox)을 만들었습니다.
사용자는 문서가 어느 DB에 들어가야 하는지 알 필요가 없습니다.
제목이나 간단한 메모와 함께 PDF나 사진을 넣으면 우선 받은자료함으로 들어갑니다.
그다음 AI가 문서를 읽고 어떤 자료인지 판단하고, 필요한 값을 추출해 기존 기록과 비교한 뒤 저장할 값을 제안하는 구조입니다.
사용자 입장에서는 결국 이렇게 단순해집니다.
사진이나 PDF를 넣는다 → AI가 읽는다 → 필요한 기록을 제안한다 → 확인한다.

차량관리 시스템을 오래 사용하려면 데이터 구조뿐 아니라 자료를 넣는 과정도 쉬워야 한다는 것을 이 단계에서 알게 됐습니다.
✓ 결국 GPT의 정확도는 질문보다 데이터에서 시작됐다
처음에는 좋은 질문을 하면 GPT가 내 차를 더 잘 관리해줄 것이라고 생각하기 쉽습니다.
하지만 실제로 만들어보니 순서가 반대에 가까웠습니다.
“엔진오일 언제 갈았지?” “앞 타이어 언제 교체했지?” “보험 만기는 언제야?” 이런 질문 자체는 어렵지 않습니다.
어려운 것은 그 질문에 답할 신뢰할 수 있는 내 차량 기록을 만들어두는 일이었습니다.
차량 정보와 정비 이력, 주행거리, 타이어, 보험과 검사 일정을 구분하고 실제 발생일과 비용의 의미까지 정리해두면 그때부터 GPT가 활용할 수 있는 데이터가 됩니다.
PDF를 많이 가지고 있는 것이 중요한 것이 아니었습니다. 필요한 순간에 정확한 기록을 찾아 연결할 수 있는 구조가 있어야 했습니다.
여기까지 만들고 나니 다음 문제가 남았습니다.
데이터가 잘 정리되어 있어도 제가 GPT에게 물어보지 않으면 아무 일도 일어나지 않습니다.
보험 만기가 다가오거나 자동차검사 시점이 와도 제가 기억하지 못하면 그대로 지나칠 수 있습니다.
그래서 다음 단계에서는 차량관리 시스템이 정해진 조건과 일정을 스스로 확인하도록 만들기 시작했습니다.
다음 편 예고 — 3편: 질문하지 않아도 관리 시점을 먼저 알려주는 AI 내차 매니저 자동화
Notion에 저장된 차량 데이터를 GitHub Actions가 정기적으로 확인하고, Claude와 ChatGPT는 어떤 역할을 맡는지, Telegram으로 필요한 알림을 보내는 구조를 어떻게 연결하는지 정리합니다.
