매출 누수 탐지 도구를 만들며 배운 점: 대조 작업은 AI에 맡기지 않기

AI 요약

Vadym이 만드는 Leakwise는 Harvest, Xero 또는 CSV에 기록된 작업 시간, 프로젝트, 비용을 실제 청구 내역과 대조해 차이를 찾습니다. 작성자는 재무 담당자가 원하는 것은 똑똑해 보이는 결과보다 확인 가능한 근거라고 말합니다. 그래서 대조와 계산에는 결정론적 규칙을 쓰고, 각 발견 항목에 원본 기록과 계산 과정을 연결합니다.

AI와 재무 데이터의 역할 분리

Leakwise는 AI를 발견 항목의 설명과 우선순위 지정에만 씁니다. 금액을 계산하거나 기록을 대조하는 작업에는 넣지 않습니다. 발견 항목이 실제로 회수 가능한 누락인지 판단하고 처리하는 일도 자동화하지 않습니다. 사용자가 각 항목을 검토해 해결하거나 제외하며, 실제 회수한 금액을 기록합니다.

요금은 사용자 계정 수가 아니라 감시하는 월간 청구액을 기준으로 나눕니다. 현재 제품은 매출이 없고 고객도 없습니다. 공개 데모와 대기 목록을 운영하며, 다음 단계로 실제 에이전시 데이터를 시험하려고 합니다.

기록에 잡히지 않는 누락과 오탐

댓글에서는 시간당 요금이 갱신되지 않은 채 예전 요금으로 청구되는 경우, 청구서 발행 뒤 도착한 비용, 기록하지 않은 짧은 추가 작업 등이 누락 지점으로 거론됩니다. 반면 로그에 남지 않은 25분짜리 부탁은 Leakwise가 볼 수 없다고 작성자는 밝혔습니다. 작업 기록과 청구서의 차이를 찾는 도구가 입력 기록 자체에 없는 일을 탐지하지는 못하기 때문입니다.

고정 요금제나 리테이너 프로젝트에서는 실제 작업 시간이 청구 대상이 아닐 수도 있습니다. 계약에 추가 작업이 포함된 경우도 단순한 시간과 청구서의 차이만으로는 매출 누수라고 단정하기 어렵습니다. 댓글에서는 제외 사유를 남기고, 계약상 청구할 수 없는 작업은 회수 가능한 누락과 분리해 집계하자는 제안이 나왔습니다. 작성자는 청구 모델과 제외 사유를 대조 로직에 반영하는 방안을 검토하고, 계약서 자동 분석 대신 고객별 수동 표시부터 고려하겠다고 답했습니다.

AI 설명이 확인된 원인처럼 보이는 문제도 제기됐습니다. 예를 들어 미대조 금액을 보고 컨설턴트가 청구서를 잊었다고 단정하면 잘못된 후속 조치를 부를 수 있습니다. 작성자는 설명이 발동한 규칙과 원본 기록만 가리키고, 원인을 추측하지 않도록 하겠다고 답했습니다.

Indie Hackers 반응

• @chenhao5721865 — 확인 가능한 결과가 똑똑해 보이는 결과보다 중요하다는 원칙에 공감합니다. EU 전자송장 규정 EN 16931 검증을 만들 때도 같은 문제를 겪었습니다. 약 200개의 업무 규칙은 LLM에 맡길 수 없습니다. 예를 들어 세율 0%인 항목에 세금 범주 "S"를 쓰면 XML 구조는 맞아도 규정에는 어긋납니다. 재무 담당자는 신뢰도 점수가 아니라 규칙 ID와 위반 위치를 원합니다. 돈을 다루는 도구라면 결정론적 처리와 설명용 AI를 나누는 편이 맞습니다.
• @hugokm — 선금을 받은 뒤 잔금을 청구하지 않는 경우도 있습니다. 개발자가 250달러를 먼저 받고 나머지 250달러는 승인 뒤 받기로 했는데, 고객이 전화로 승인한 뒤 사이트를 공개하고도 잔금을 못 받은 사례를 봤습니다. Leakwise는 선금을 한 청구서의 일부로 보나요, 별도 청구서로 보나요?
  • @Vadym — 제가 주로 찾는 것은 청구서에 아예 들어가지 않은 작업입니다. 이미 발행한 청구서의 미수금은 매출 누수라기보다 수금 문제라 현재는 다루지 않습니다. 선금은 청구서가 발행됐다면 한 장에 단계별 지급을 넣든 두 장으로 나누든 대조합니다. 승인 뒤 잔금 청구서를 아예 만들지 않는 경우가 더 까다롭습니다.
• @lirik — 금액은 맞더라도 AI가 이유를 지어내는 사례를 테스트해야 합니다. "대조되지 않은 300유로"를 "컨설턴트가 청구서를 보내지 않았습니다"라고 바꾸면 엉뚱한 대상을 쫓게 됩니다. 설명에는 발동한 규칙과 원본 행만 들어가나요, 원인을 추론할 수도 있나요?
  • @Vadym — 피하고 싶은 실패 방식입니다. 설명은 발동한 규칙을 다시 말하고 원본 행을 가리켜야 합니다. "컨설턴트가 청구를 잊었습니다" 같은 문구는 추측이므로 나타나면 버그로 보겠습니다.
• @shipplays — 고정 요금제나 리테이너에서는 기록된 시간이 전부 청구 대상은 아닙니다. 시간과 청구서의 차이를 누수로 표시하면 거짓 경보가 되고 사용자가 무시할 수 있습니다. 청구, 리테이너 포함, 손실 처리 같은 제외 사유를 남기면 다음 달에도 같은 경보가 반복되는 일을 줄일 수 있습니다.
  • @Vadym — 리테이너와 고정 요금제에서는 차이가 항상 매출 손실을 뜻하지 않는다는 점이 맞습니다. 청구 모델과 제외 사유를 대조 로직에 반영하려고 합니다.
• @AmandaBrown — 재무 도구에서는 감사 가능성이 곧 판매 조건입니다. 돈이나 규정처럼 실제 수치에 영향을 주는 제품은 구매자가 논리를 직접 추적해야 합니다. "AI가 판단했습니다"와 "원본 행, 규칙, 차액은 이렇습니다"는 조달 과정에서 다르게 받아들여집니다.
• @theboris7 — 매출이 없는 단계라면 구독보다 일회성 수동 감사를 먼저 제안하는 방법이 있습니다. 고객에게 지난 분기 Harvest 내역과 청구서를 받아 누락을 찾아주고, 일정 금액 이상 발견할 때만 비용을 받는 방식입니다. 실제 사례와 금액을 확보하면 대기 목록보다 제품 가치를 설명하기 쉽습니다.
  • @Vadym — 실제 데이터를 통한 수동 감사가 빠르게 배울 방법일 수 있습니다. 아직 실제 에이전시 데이터로 시험하지 않아 확인하기 전에는 회수 금액을 말하지 않겠습니다.
• @vadimvlasov — 계약에 "고객이 합리적으로 요청하는 추가 작업을 추가 비용 없이 수행한다"는 조항이 있으면 기록된 시간이 청구서에 없어도 누수라고 할 수 없습니다. 계약상 청구 불가 항목을 별도 상태로 두면 에이전시가 어떤 계약 조항 때문에 작업을 무료로 제공하는지 알 수 있습니다.
  • @Vadym — 현재 Leakwise는 계약서를 읽지 않으므로 그런 작업도 청구되지 않은 시간으로 표시됩니다. 별도 상태는 아직 검토할 아이디어입니다. 고객별 수동 표시부터 시작하는 편이 계약서 분석보다 나을 수 있습니다.
• @REFFoundry — 가장 큰 누수는 범위가 늘어나는 작은 부탁일 수 있습니다. 메시지로 요청한 사소한 수정에 25분을 쓰고 변경 요청을 기록하지 않으면 월말에 청구하지 못합니다. 다만 아무도 기록하지 않은 작업은 Leakwise가 볼 수 없고, 리테이너 한도를 넘긴 작업은 대조 대상에 더 가깝습니다.

원문: Indie Hackers / 번역·요약: Trawling