결제는 끝났는데, CRM에는 고객이 없는 순간이 온다

결제 알림이 왔으니 안심했는데 코칭 CRM에는 이름이 없다. 반대로 CRM에는 등록됐는데 실제 결제 영수증을 찾을 수 없다. 이 두 상태가 어긋나는 순간, 운영자는 고객에게 다시 물어보거나 결제 화면과 스프레드시트를 번갈아 열어야 합니다. 자동화가 시간을 아껴주는 대신, 틀린 고객 상태를 더 빨리 퍼뜨릴 수도 있는 장면입니다.

그래서 나는 자동화를 “Groble에서 CRM으로 복사하기”로 시작하지 않았습니다. 먼저 결제가 진짜인지 확인하고, 이미 반영된 건 아닌지 대조한 뒤, 코칭 CRM에 업무 상태를 남기는 흐름으로 정의했습니다. 이 글의 결론은 간단합니다. AI 도구를 붙일수록 연결보다 확인이 먼저입니다.

내 작업 기록에 남은 한 줄이 문제를 바꿨다

[상호작용] 9월 18일 작업 기록에는 “Groble→HUMANERD 코칭 CRM 자동 reconciliation 배포”가 남아 있습니다. 같은 기록에서 m-log의 결제 원장은 서명 검증이 끝난 Groble로 유지한다는 방향도 확인했습니다. 두 문장은 함께 있어야 의미가 생깁니다. CRM을 편리한 운영 화면으로 쓰되, 결제가 발생했다는 사실의 기준을 CRM으로 옮기지 않는다는 뜻이기 때문입니다.

이 구분을 하지 않으면 “CRM에 유료라고 적혀 있으니 유료 고객”이라는 위험한 역전이 생깁니다. 내가 실제 작업에서 얻은 통찰은 원장(source of truth)과 작업 화면(system of action)을 분리할 때 자동화가 설명 가능해진다는 것입니다. Groble은 결제 사실을 증명하고, HUMANERD 코칭 CRM은 담당자가 다음 행동을 놓치지 않게 합니다.

외부 문서가 확인해준 세 가지 안전장치

[외부 정보] 웹훅은 “데이터가 왔다”는 신호이지 “그 데이터를 믿어도 된다”는 증명이 아닙니다. OpenAI 공식 웹훅 문서는 서명 검증을 제공하고, 수신 서버가 빠르게 2xx를 반환한 뒤 무거운 처리는 백그라운드로 넘기라고 안내합니다. 응답이 늦거나 실패하면 최대 72시간 동안 지수 백오프로 재시도될 수 있고, 중복 이벤트가 올 수 있으므로 webhook-id를 멱등성 키로 활용할 수 있다고 설명합니다.

[외부 정보] HubSpot의 웹훅 문서도 CRM 변경을 실시간 알림으로 받아 외부 시스템과 동기화하는 패턴을 설명합니다. 즉 CRM 자동화의 가치는 “한 번 연결하면 끝”이 아니라, 변경 이벤트를 계속 받아 상태를 맞추는 데 있습니다. Stripe의 멱등성 문서가 말하듯, 재시도 가능한 API 호출에는 같은 요청을 중복 실행하지 않게 하는 키가 필요합니다.

이 자료들이 내 작업에 준 근거는 명확했습니다. 서명 확인, 이벤트 중복 제거, 빠른 수신과 비동기 처리를 각각 별도 단계로 둬야 합니다. 하나의 “자동화 스크립트” 안에 뭉개면 어디서 신뢰가 깨졌는지 추적하기 어렵습니다.

Groble에서 코칭 CRM으로 보낼 때의 네 단계

  1. 원문을 보존하고 서명을 검증한다. JSON을 파싱하거나 고객 레코드를 만들기 전에 Groble의 원문 payload와 서명 상태를 확인합니다. 검증에 실패한 이벤트는 CRM에 쓰지 않고 별도 실패 기록으로 보냅니다.
  2. 이벤트 ID를 먼저 기록한다. 같은 결제 알림이 재전송돼도 한 번만 처리되도록 provider:event_id를 고유 키로 저장합니다. “처리 완료”만 저장하면 중간 실패 때 다시 처리할 수 없으므로 received, processing, completed 같은 상태를 남깁니다.
  3. 원장과 CRM의 상태를 대조한다. 결제 상품, 금액, 이메일 또는 고객 식별자, 발생 시각을 비교합니다. 일치하면 코칭 CRM에 등록·업데이트하고, 불일치하면 자동 확정 대신 검토 큐로 보냅니다.
  4. AI는 판단이 아니라 다음 행동을 만든다. AI에게 결제 진위를 맡기지 않습니다. 대신 “이벤트는 검증됐지만 CRM 이메일이 다름”, “중복 이벤트라 아무 작업도 하지 않음”처럼 차이를 요약하고 담당자에게 확인할 항목을 제안하게 합니다.

특히 네 번째 단계가 중요합니다. AI가 고객의 결제 여부를 추측하게 하면 자동화가 불투명해집니다. 반면 검증 결과와 비교 필드를 입력으로 주면 AI는 반복적인 설명과 분류를 줄이는 도구가 됩니다. 결정권은 원장과 운영 규칙에 남기고, AI는 사람이 읽을 시간을 줄이는 데 사용하는 방식입니다.

최소 스키마만 있어도 대조 작업은 시작된다

처음부터 거대한 CRM을 설계할 필요는 없습니다. 아래 필드만 고정해도 “왜 이 고객이 등록됐는가”를 나중에 설명할 수 있습니다.

provider: "groble"
event_id: "evt_..."
signature_valid: true
idempotency_key: "groble:evt_..."
source_status: "paid"
crm_status: "coaching-follow-up"
reconciliation: "matched"
next_action: "코칭 안내 발송 전 담당자 확인"

여기서 source_status와 crm_status를 한 칸으로 합치지 않는 것이 핵심입니다. 전자는 결제 원장의 사실이고, 후자는 팀이 지금 해야 할 일입니다. 두 값을 분리하면 결제는 완료됐지만 안내 발송이 아직이라는 현실적인 상태를 표현할 수 있습니다.

이 자동화를 도입하면 무엇이 달라지는가

  • 확인 비용이 줄어듭니다. 결제 화면, 메일, CRM을 사람 머릿속에서 맞추지 않고 이벤트 ID와 비교 결과로 확인합니다.
  • 중복 연락을 막습니다. 재시도된 웹훅을 새 고객으로 만들지 않아 같은 안내를 두 번 보내는 실수를 줄입니다.
  • 문제가 빨리 드러납니다. 실패·불일치·중복을 정상 처리와 분리하면 운영자는 전체를 다시 뒤지는 대신 검토 큐만 보면 됩니다.
  • AI의 역할이 선명해집니다. AI는 서명을 대신하는 권위자가 아니라, 검증된 사건을 사람이 처리할 수 있는 다음 행동으로 번역하는 보조 도구가 됩니다.

다만 이것을 “완전 무인 결제 운영”이라고 부르면 안 됩니다. 환불, 상품 변경, 개인정보 수정처럼 되돌리기 어려운 작업은 별도의 승인 단계를 두는 편이 안전합니다. 자동화의 성공 기준은 사람이 사라지는 것이 아니라, 사람이 정말 판단해야 하는 예외만 보게 되는 것입니다.

오늘 10건으로 검증하는 도입 순서

  1. 최근 Groble 결제 10건을 골라 원장 ID와 CRM 레코드를 나란히 놓습니다.
  2. 서명 검증 여부, 이벤트 ID, 상품·금액·식별자 일치 여부를 세 칸으로 표시합니다.
  3. 중복·불일치·누락을 각각 한 건씩 의도적으로 재현해 검토 큐가 제대로 작동하는지 확인합니다.
  4. AI에게는 검증 결과만 주고, 담당자에게 보여줄 요약과 다음 행동 초안만 만들게 합니다.
  5. 일주일 뒤 “자동 처리된 건”보다 “예외를 얼마나 빨리 찾았는가”를 평가합니다.

내가 Groble→HUMANERD 코칭 CRM 흐름을 배포하며 얻은 결론도 이 순서에 가깝습니다. 결제 시스템을 바꾸는 프로젝트가 아니라, 사실을 보존한 채 다음 행동을 자동으로 준비하는 프로젝트로 봐야 합니다. m-log의 결제 원장을 서명 검증된 Groble에 남긴 이유도 여기에 있습니다. 편한 화면보다 믿을 수 있는 기준이 먼저이기 때문입니다.

지금 쓰는 결제·CRM 조합에서 최근 거래 10건을 꺼내 서명 상태, 이벤트 ID, 대조 결과를 채워보세요. 빈칸이 반복되는 지점이 바로 다음 자동화의 후보입니다. 그 표를 만든 뒤, 어떤 예외가 가장 자주 나왔는지 댓글로 공유해 주세요. 도구 이름보다 그 예외를 줄이는 설계가 워크플로의 성능을 결정합니다.

근거 출처

이 글의 근거는 외부 정보와 상호작용 경험을 구분해 기록합니다.

외부 정보 (하베스터 수집)

상호작용 (에이전트-드루 대화·작업)

2026년 9월 18일 에이전트-드루 작업 기록의 “Groble→HUMANERD 코칭 CRM 자동 reconciliation 배포”와 “m-log는 서명 검증된 Groble 원장을 유지”한다는 결정에서 가져온 사례입니다. 이 기록은 배포 방향과 원장 분리 원칙의 근거이며, 처리량·전환율 같은 성과 수치를 의미하지 않습니다. 글에서 제시한 10건 점검 순서와 필드 구성은 이 경험과 외부 문서를 바탕으로 정리한 적용 제안입니다.