업무용 차량 정비 예정일과 주행거리 알림 시스템 구축 방법

업무용 차량의 정비 알림은 주행거리와 예정일 중 먼저 도달한 기준으로 계산해야 합니다. 계기판 입력이 빠졌다고 이미 지난 정비일 알림까지 사라져서는 안 됩니다. 차량별 정비 항목에 두 기준을 등록하고, 입력 확인 상태와 정비 알림을 나란히 보여 주는 시스템으로 설계합니다.

아래는 실제 납품 사례가 아닌 가상의 구축 예시입니다. 사전 알림 범위는 500km 또는 7일 이내, 집계일은 한국시간 날짜로 정했습니다. 이 수치는 계산 설명용이며 권장 정비 주기가 아닙니다. 실제 주기는 차량·정비 항목별 제조사 지침과 사용 조건을 담당자가 확인해 등록해야 합니다. 알림 목록은 차량의 운행 안전을 판정하는 화면이 아닙니다.

계기판 숫자와 확인 날짜를 함께 받습니다

• 운전자는 모바일 화면에서 차량번호, 계기판 누적거리, 확인 날짜와 사진을 제출합니다. 이동한 구간 거리가 아니라 누적거리이며, 이 예시의 단위는 정수 km입니다. 제출 즉시 정비 완료나 관리자의 승인으로 처리하지 않습니다.
• 차량 담당자는 이전 확정값보다 감소한 입력과 누락값을 확인합니다. 계기판 교체라면 새 숫자만 덮어쓰지 않고 교체 시점과 기존 누적거리를 연결하는 별도 보정 절차로 넘깁니다.
• 정비 기준 화면에는 차량·항목별 다음 예정일과 누적거리 기준을 저장합니다. 기준 변경 권한은 담당자에게만 주고 변경 사유와 적용 버전을 남깁니다. 운전자는 본인 배정 차량의 입력만 제출하도록 제한합니다.

이 예시는 당일 확인값만 최신으로 인정합니다. 어제의 낮은 누적거리를 오늘 값처럼 사용하지 않는 정책입니다. 차량을 운행하지 않은 날의 확인 방식이나 자동 수집 지연 허용시간은 도입 시 따로 정합니다.

입력 오류가 있어도 날짜 알림은 남기는 SQL

다음은 SQLite 3.54.0에서 실행한 읽기 전용 조회입니다. 가상 차량 7대의 동일 정비 항목에 대해 이전 확정값은 10,000km, 다음 기준은 15,000km로 고정했습니다. read_on은 확인 날짜, km는 집계할 제출값, due_on은 검토해 등록한 예정일입니다. 운영 데이터는 수정하지 않습니다.

WITH
p(today, soon, prev_km, due_km) AS (
  VALUES ('2026-10-22', '2026-10-29', 10000, 15000)
),
v(id, read_on, km, due_on) AS (VALUES
  ('A','2026-10-22',15000,'2026-11-10'),
  ('B','2026-10-22',12000,'2026-10-22'),
  ('C','2026-10-22',14600,'2026-11-10'),
  ('D','2026-10-22', NULL,'2026-10-22'),
  ('E','2026-10-22', 9000,'2026-11-10'),
  ('F','2026-10-21',11000,'2026-11-10'),
  ('G','2026-10-22',11000,'2026-11-10')
),
x AS (
  SELECT v.*, p.*, CASE
    WHEN km IS NULL THEN 'MISSING'
    WHEN km < prev_km THEN 'REVERSED'
    WHEN read_on IS NULL OR read_on <> today THEN 'STALE'
    ELSE 'OK' END AS quality
  FROM v CROSS JOIN p
)
SELECT id, quality, CASE
  WHEN due_on <= today THEN 'DUE'
  WHEN quality <> 'OK' THEN 'CHECK'
  WHEN km >= due_km THEN 'DUE'
  WHEN km >= due_km - 500 OR due_on <= soon THEN 'SOON'
  ELSE 'WATCH' END AS reminder
FROM x ORDER BY id;

반환된 quality는 입력 상태, reminder는 알림 분류입니다.

id  quality   reminder
A   OK        DUE
B   OK        DUE
C   OK        SOON
D   MISSING   DUE
E   REVERSED  CHECK
F   STALE     CHECK
G   OK        WATCH

A는 거리 기준과 같아 DUE(기한 도달), B는 예정일 당일이라 DUE입니다. C는 남은 거리가 400km라 SOON(정비 예정)입니다. D는 누적거리가 없어도 날짜가 도달했으므로 MISSING과 DUE를 함께 보여 줍니다. E의 감소값과 F의 전날 값은 CHECK(확인 필요), G는 이 입력에서 아직 알림 범위가 아닌 WATCH입니다. OK와 WATCH는 운행 허가를 뜻하지 않습니다.

D의 누락값을 11,000km로 보완해도 날짜 기준이 남아 DUE입니다. E를 사진 확인 후 14,600km로 정정하면 SOON으로 바뀝니다. 과거 제출값은 삭제하지 않고 정정 사유를 연결합니다. 같은 숫자 수정이라도 어떤 알림을 해제할 수 있는지 구분해야 합니다.

날짜는 실제 존재하는 YYYY-MM-DD, 거리는 음수가 아닌 정수로 먼저 검증한다는 전제입니다. 이 SQL은 날짜 형식 검증기가 아닙니다. CASE는 먼저 맞는 조건을 반환하므로 입력 오류가 여러 개면 하나만 표시합니다.[2] 운영 화면은 전체 오류 사유를 별도로 보존합니다. WITH로 만든 임시 입력은 이 조회 안에서만 사용합니다.[1]

예약한 날이 아니라 실제 정비한 날에 다음 기준을 만듭니다

담당자는 알림 목록에서 차량과 정비 항목을 골라 작업 요청을 만들고, 관리자에게 일정·비용 승인을 요청합니다. 승인 뒤 예약을 잡아도 기존 DUE를 지우지 않습니다. 정비소 방문이 취소되거나 부품이 준비되지 않았으면 미완료 항목으로 남겨 재예약합니다.

작업 후 담당자는 실제 완료일, 당시 누적거리, 처리한 정비 항목과 증빙을 등록합니다. 검토자가 완료를 확정할 때만 해당 항목의 다음 기준을 생성합니다. 오일만 교체했는데 타이어 점검 알림까지 초기화하면 안 됩니다. 실제 완료 기준으로 다음 일정을 계산할지 고정 일정에 맞출지도 항목별로 정하고, 이력이 없는 차량은 첫 기준을 확인 대기로 둡니다.

조회 화면에는 예정일·남은 거리, 입력 확인 상태, 작업 요청·승인·예약·완료 상태를 따로 표시합니다. 일별 알림은 차량·항목·기준 버전·집계일을 묶어 같은 건을 중복 생성하지 않도록 설계합니다. 발송 실패는 재시도 대상으로 남기고, 발송 성공을 담당자의 확인이나 정비 완료로 바꾸지 않습니다. 이 예제의 실행은 분류 계산만 확인한 것이며 실제 알림 전송·동시 완료 저장·차량 상태 진단을 검증한 결과는 아닙니다.

문법 확인: [1] SQLite WITH · [2] SQLite CASE와 비교 연산. 구축 서비스는 softmoa.com에서 확인할 수 있습니다.

소프트모아는 해당 시스템을 구축합니다. 문의하기