렌터카 업계 지인에게 우연히 들은 이야기 하나가 아이디어의 출발점이 됐다. 개인들의 경우 미납된 고속도로 통행료나 과태료가 있을 경우 개인 차량에 이 비용이 귀속되니 문제가 없지만 렌터카 회사는 이야기가 다르다. 미납 통행료나 과태료 발생 사실을 일찍 확인한다면 각 통행료 징수 주체와 과태료 부과 관공서에 실제 차량을 빌려간 손님으로 납부 대상자 변경을 하면 된다. 문제는 이 변경 신청 기간이 짧다는 것이다. 통상 고지서는 미납 통행료, 과태료가 발생한 시점보다 2~3개월 뒤 통지된다. 당시 차량을 렌트했던 고객이 연락이 잘되고 통행료/과태료 부과 사실을 수긍하여 정상적으로 납부를 해준다면 아무런 문제가 없겠으나, 고객 입장에서도 몇달 전 벌어진 기억도 안나는 통지서를 쉽게 수긍하기는 어렵다. 때문에 렌터카 회사에서 이 비용을 추후에 받아내는 것은 여간 성가신 일이 아니다. 전국 50개가 넘는 유료도로 운영사에 흩어져 있는 미납 내역과 미납 과태료를 납부자 변경 신청 마감 전에 일일이 확인하는 건 사람이 손으로 하기엔 너무 번거로운 일이다.

여기서 아이디어가 나왔다. 렌터카 회사가 보유 차량 목록만 올리면, 납부자 변경 마감일 전에 미납 통행료 여부를 자동으로 확인하고 알려주는 B2B SaaS.

왜 지금까지 아무도 안 만들었을까 — API 진입 장벽

가장 먼저 확인한 건 이 데이터를 프로그램으로 조회할 방법이 있는가였다. 한국에는 CODEF, Hectodata 같은 공공/민간 데이터 중계 API 서비스가 있어서, 이런 흩어진 정부·공공기관 데이터를 API 형태로 가져올 수 있다. 문제는 이 API들이 전부 API 내용을 확인하기도 전에 비용을 지불해야하고 별도의 사업자 등록이 필요하다는 점이다.

가족 명의로 사업자를 내는 방법도 검토했지만, 실질적인 운영 주체와 명의자가 다른 구조는 법적·세무적으로 문제 소지가 있다고 판단해 보류했다.

우회로를 찾다가 멈춰선 지점 — hipass.co.kr

API 진입이 막히자 자연스럽게 대안을 찾게 됐다. 하이패스 홈페이지(hipass.co.kr)에는 비회원도 차량 미납 통행료를 조회할 수 있는 기능이 있다. 이 페이지를 직접 크롤링하면 사업자 등록 없이도 데이터를 모을 수 있지 않을까 생각했다.

그런데 확인해보니 이 엔드포인트는 robots.txt로 명시적으로 크롤링이 금지되어 있었다. 이 지점에서 확실하게 결정한 게 하나 있다 — 아무리 속도를 늦추고 우회 기법을 쓰더라도, 이렇게 명시적으로 금지된 경로는 스크래핑하지 않기로 했다. 기술적으로 가능하다는 것과 해도 되는 것은 다른 문제라고 판단했다.

그래서 지금은 여기까지 멈춰 있다

정리하면, 이 프로젝트는 지금 두 가지 정당한 경로가 모두 막힌 상태다.

  1. CODEF/Hectodata 공식 API — API 접근 비용과 세부 내용 확인 불가
  2. hipass.co.kr 비회원 조회 스크래핑 — 명시적으로 금지된 경로라 배제

그럼에도 지금 할 수 있는 것 — 목업 데이터로 골격 먼저 짜기

API 접근 문제가 풀리기를 기다리기만 하는 건 비효율적이라, 실제 데이터 없이 시스템 골격부터 먼저 만들어두는 쪽으로 방향을 잡았다. 나중에 API 접근이 열리면 데이터 소스만 갈아끼우면 되도록 설계하는 게 목표다.

계획한 골격은 이렇다.

1. 차량 등록 대시보드 렌터카 회사가 보유 차량 목록(차량번호, 소유권 이전 예정일)을 업로드하고 한눈에 볼 수 있는 화면. 목업 단계에서는 엑셀 업로드 → 파싱 → DB 저장 흐름만 구현한다.

2. 배치 스케줄러 매일 정해진 시각에 등록된 차량 목록을 순회하며 미납 통행료 여부를 확인하는 배치 작업. 지금은 실제 API 대신 더미 응답(랜덤하게 미납/완납 상태를 생성하는 목 서버)을 붙여서 전체 파이프라인이 정상적으로 도는지만 검증한다.

3. D-day 알림 소유권 이전 예정일이 임박한 차량 중 미납 통행료가 있는 건에 대해 담당자에게 알림(이메일 또는 카카오톡 알림톡)을 보내는 기능.

4. 엑셀 업로드-매칭 워크플로우 렌터카 회사마다 차량 관리 시스템이 제각각이라, 엑셀 파일 형식도 회사마다 다를 가능성이 높다. 컬럼명이 다르더라도 차량번호 같은 핵심 필드를 유연하게 매칭하는 파서를 미리 설계해두는 게 실사용 단계에서 중요할 것으로 보인다.

5. DB 스키마 대략적인 뼈대는 이렇게 잡고 있다.

vehicles (차량)
  - id
  - plate_number (차량번호)
  - rental_company_id

toll_check_results (통행료 조회 결과)
  - id
  - vehicle_id (FK)
  - checked_at
  - unpaid_amount
  - transfer_date (납부자 변경 마감일)
  - source (조회 출처: 목업 단계에서는 "mock")

alerts (알림 발송 이력)
  - id
  - vehicle_id (FK)
  - alert_type (D-7, D-3, D-1 등)
  - sent_at

아직 풀리지 않은 질문

목업으로 골격을 짜더라도, 나중에 API 접근이 열렸을 때 실제로 쓸모가 있으려면 확인해야 할 게 하나 더 있다. CODEF의 비회원 미납 통행료 조회 API가 35건 상한 없이 소액 미납까지 다 잡아주는지는 아직 확인하지 못했다. 이 상한이 실제로 존재한다면, 대량의 차량을 다루는 렌터카 회사 입장에서는 이 API만으로는 충분하지 않을 수도 있다.

이 프로젝트는 지금 “기술적으로는 골격을 짤 수 있지만, 실제 데이터 접근권이라는 조직적·제도적 문제가 먼저 풀려야 한다"는 지점에 멈춰 있다. API 접근 문제가 정리되면 다시 진전시킬 계획이다.