대금을 받는 과정에서 가장 어려운 단 한 가지는 송장을 작성하는 것이 아닙니다. 그것은 바로 후속 조치(follow-up)입니다. 조용한 고객에게 언제 재촉해야 할지, 그리고 관계를 망치지 않는 어조로 어떻게 전달할지를 아는 것입니다. 대부분의 도구는 "지불 기한 7일 후 리마인더 전송"과 같은 단순한 크론 잡(cron job)으로 이 문제를 해결합니다. 이는 거의 모든 경우에 잘못된 방식이며, 그 이유는 다음과 같습니다.

고정된 리마인더 일정의 문제점

결제 행동은 균일하지 않습니다. 어떤 고객은 "net 30" 송장의 32일째에 시계처럼 정확하게 결제합니다. 늦는 것이 아니라 단지 그들만의 리듬인 것입니다. 또 다른 고객은 5일째에 결제하지만, 3일째에 리마인더를 보냈을 때만 결제합니다. 일괄적인 "기한 경과 7일" 리마인더는 첫 번째 고객(항상 결제할 예정이었던 고객)을 짜증 나게 만들고, 두 번째 고객(더 일찍 독려가 필요했던 고객)은 놓치게 됩니다.

따라서 진짜 문제는 스케줄링이 아니라 **고객별 타이밍 예측(per-client timing prediction)**입니다. 각 고객의 결제 분포(payment distribution)를 모델링하고, 리마인더가 가장 높은 한계 효과(marginal effect)를 갖는 지점, 즉 고객이 결제 의도를 실제 송금으로 전환할 가능성이 가장 높은 순간에 행동해야 합니다.

고객별 분포로서의 결제 리듬 모델링

모든 송장은 다음과 같은 레이블이 지정된 데이터 포인트(labeled data point)를 제공합니다: (sent_date, due_date, paid_date, amount, was_reminded). 시간이 흐름에 따라 고객별로 이는 "송장 발송부터 결제까지의 일수"에 대한 분포가 됩니다. 단순한 방법은 이를 평균 내는 것이지만, 그렇게 하지 마십시오. 평균은 분포의 형태를 숨기며, 그 형태가 바로 핵심 신호(signal)이기 때문입니다.

우리는 각 고객의 결제일을 하나의 분포로 모델링하며, 평균보다 더 중요한 두 가지를 추적합니다:

• 분산 (Dispersion) — 좁은 분포(항상 30~32일 사이)는 30일 이전의 리마인더가 소음(noise)임을 의미합니다. 넓은 분포는 고객이 리마인더에 민감함을 의미합니다.
• 리마인더 리프트 (Reminder lift) — 재촉이 있었을 때와 없었을 때의 결제일 분포를 비교하면, 리마인더가 실제로 이 고객의 행동을 변화시키는지, 그리고 얼마나 변화시키는지 알 수 있습니다.

for client in clients:
    hist = paid_events(client)              # list of days-to-pay
    p50, p90 = quantiles(hist, [.5, .9])
...

else 분기는 사람들이 흔히 건너뛰는 부분이지만, 사실 가장 중요합니다. 45일째에 안정적으로 결제하는 고객에게는 세 번의 리마인더(reminder)가 필요하지 않습니다. 44일째까지는 단 한 번의 알림도 필요 없습니다. 불필요한 독촉을 억제하는 것은 적절한 시기에 알림을 보내는 것만큼이나 가치 있는 일입니다. 왜냐하면 불필요한 리마인더를 보낼 때마다 고객은 당신의 메시지를 무시하도록 학습되기 때문입니다.

콜드 스타트 (Cold start): 첫 번째 송장에는 이력이 없다

고객별 데이터가 없는 경우, **계층적 사전 확률 (hierarchical prior)**에 의존해야 합니다. 즉, 전체 모집단 분포(또는 세그먼트 — 대행사는 스타트업과 결제 패턴이 다름)에서 시작한 다음, 새로운 결제가 발생할 때마다 해당 고객의 추정치를 그 고객 고유의 행동 패턴 쪽으로 끌어당기는 방식입니다. 베이지안 업데이트 (Bayesian updating)는 이를 깔끔하게 수행합니다. 두세 번의 송장이 발행되고 나면, 고객 특유의 신호 (client-specific signal)가 사전 확률 (prior)을 압도하게 됩니다. 그전까지는 적어도 맹목적인 추측은 하지 않는 셈입니다.

사용자의 말투로 초안 작성하기 — 보정 (calibration) 문제

타이밍이 돈을 움직인다면, 말투는 고객을 유지합니다. 리마인더는 채권 추심 대행사가 아닌, _당신_처럼 들려야 합니다. 우리는 LLM에 사용자의 실제 과거 메시지 몇 개를 스타일 예시 (style exemplars)로 제공하고, 구조화된 컨텍스트 (연체 일수, 이전 리마인더 발송 여부, 관계 기간)를 함께 입력하여 모델이 단계적 대응 (escalation)을 보정할 수 있도록 합니다.

• 신뢰할 수 있는 고객에게 보내는 첫 번째 독촉 → 가볍게, 선의를 가정함.
• 30일 연체된 상태에서의 세 번째 독촉 → 더 단호하게, 하지만 여전히 전문적으로.

핵심은 단계적 대응이 전역 템플릿 (global template)이 아니라, _고객 자신의 이력에 따른 함수_여야 한다는 점입니다. 연체 횟수가 같더라도, 해당 고객이 이전에 연락을 끊은 적이 있는지에 따라 말투는 달라져야 합니다. 이 이력을 프롬프트 (prompt)에 전달하면, 모델은 당신이 직접 작성한 그 어떤 if/else 조건문보다 훨씬 더 잘 보정해 줍니다.

스크립트가 아닌 에이전트(agent)로 만드는 요소

에이전트는 루프를 닫습니다 (closes the loop). 결제된 모든 송장은 분포를 업데이트하고, 리프트 (lift)를 재추정하며, 다음 고객의 리마인더 일정을 재조정합니다. 에이전트는 무엇을 보낼지뿐만 아니라, 보낼지 말지 자체를 결정하며, "아무것도 보내지 않음"이라는 결정 또한 일급 시민 (first-class) 액션으로 취급합니다. 이러한 피드백 루프가 단순한 자동화와, 시간이 지남에 따라 당신의 특정 고객군에 맞춰 점점 더 똑똑해지는 에이전트 사이의 차이점입니다.

우리는 이를 Tally로 구축했습니다. Tally는 모든 송장 (invoice)을 모니터링하고, 각 고객의 리듬을 학습하며, 고객이 실제로 결제하는 시점에 당신의 말투로 리마인더 (reminder) 초안을 작성합니다. 무료로 체험해 보세요 → https://kynth.studio/l/tally