추측하지 말아야 할 때를 아는 AI 에이전트 구축하기 (Qwen + MCP)
요약
본 글은 Qwen 모델과 자체 구축한 Recona 에이전트를 활용하여 미결제 청구서와 결제를 대조하고 연체 금액을 추적하는 방법을 설명합니다. 이 시스템은 Cloudflare Workers, Alibaba Cloud SAS 등 다양한 기술 스택으로 구성되어 자동화된 수금 작업을 수행하며, AI의 추론 결과에 의존하기보다 결정론적 코드를 통해 안전성을 확보하는 것이 핵심입니다.
핵심 포인트
- Qwen과 Recona를 활용하여 미결제 청구서 대조 및 연체 금액 추적이 가능합니다.
- Cloudflare Workers와 D1을 사용하여 웹훅 처리 및 데이터 수집 오케스트레이션을 구현했습니다.
- AI의 추론 결과(신뢰도)만 믿지 않고, 결정론적 코드가 최종 자동화를 제어하는 것이 중요합니다.
- 이 시스템은 사람이 개입할 필요가 없는 워크플로우를 목표로 합니다.
청구서 금액의 정확히 절반에 해당하는 결제가 들어왔습니다. 지불자의 이메일은 파일에 등록된 고객과 일치했습니다. 하지만 아프리카 전역의 Stripe 대체 결제 처리기인 Paystack이 생성한 참조 번호는 아무것도 일치하지 않았습니다.
Qwen은 이것을 보고 30%의 신뢰도와 이름 없는 청구서로 응답했습니다.
저는 Qwen Cloud를 활용하여 Global AI Hackathon Series에 참가하기 위해 Recona을 구축했습니다. 이 에이전트는 Paystack 결제를 미결제 청구서와 대조하고, 사람이 개입할 필요가 없는 쉬운 케이스의 연체된 금액을 추적합니다. 위에서 언급한 거래는 데모의 흥미로운 부분이 될 예정이 아니었습니다. 오히려 그것 자체가 핵심 포인트가 되었습니다.
Recona가 하는 일
나이지리아에서 프리랜서로 활동하거나 소규모 사업체를 운영하며 결제를 받는 경우, PMT final tunde와 같은 참조 번호로 돈이 들어오고, 당신은 저녁 시간을 보내며 어떤 청구서에 대한 것인지 알아내고 어떤 고객에게 독촉하는 것을 잊었는지 파악합니다. Recona는 이 두 가지 절차를 자동화합니다. Qwen을 사용하여 입금된 결제를 미결제 청구서와 대조하고, 청구서가 오래될수록 점점 더 단호한 알림 초안을 작성하여 보내는 일일 수금 작업을 수행합니다.
Cloudflare Workers와 D1이 데이터 수집 및 오케스트레이션을 처리합니다. 여기에는 중복 전송에 대해 이상적인(idempotent) Paystack 웹훅과 서명 검증이 포함됩니다. Alibaba Cloud SAS는 모든 Qwen 추론을 담고 있는 Dockerized Node 서비스를 실행하며, 이는 데이터 수집 계층과는 별도로 배포됩니다. 이 재무 조정기(reconciler)는 REST와 MCP 도구(match_transaction_to_invoice, draft_payment_reminder) 형태로 매칭 엔진을 스트리밍 가능한 HTTP를 통해 노출합니다. Telegram은 사람이 개입하는 인터페이스입니다. 왜냐하면 여기서 실제 작업은 다른 대시보드에 로그인하는 것이 아니라 스스로 닫히는 워크플로우이기 때문입니다.
제가 설계한 규칙은 다음과 같습니다: 모델이 제안하고, 결정론적 코드가 처리합니다. 청구서를 자동 폐쇄하려면 정확한 금액, 일치하는 통화, 그리고 임계값 이상의 신뢰도가 필요하며 — 이는 Qwen이 응답한 후 코드에서 확인되며, 프롬프트로부터 절대 신뢰하지 않습니다.
데모에서 보여주고 싶었던 것
데모에서 보여주고 싶었던 것
원래는 깔끔한 시나리오를 준비했었습니다. 고객이 청구서 금액의 절반을 결제하는 경우입니다. Qwen은 어떤 청구서인지 정확하게 식별합니다. 하지만 제 결정론적 가드(deterministic guard)가 금액이 틀렸기 때문에 자동 마감(auto-close)을 막습니다. 모델은 맞지만, 안전을 위해 코드가 이를 무효화시키는 것입니다. 좋은 데모의 흐름이었죠.
실제로는 그렇지 않았습니다.
저는 실제 거래를 실제 시스템 — 즉 recon-ingest.fpl-test.workers.dev에 배포된 실제 Cloudflare Worker, 실제로 배포된 조정기(reconciler), 그리고 실제 Qwen API를 통해 실행했습니다. 저는 이를 두 번 실행했습니다. 한 번은 원래 청구서로, 다른 한 번은 결제 금액을 정확히 두 배로 재설정하여 새로운 청구서를 생성한 후 테스트하여 우연의 일치인지 확인하기 위해서였습니다.
두 경우 모두, 청구서 고객 이메일과 일치하지만 금액이 정확히 절반인 결제를 받았고, 어떤 청구서 번호와도 관련 없는 참조 번호를 가지고 있을 때, Qwen은 30%의 신뢰도를 반환했으며 확정된 청구서 ID는 없었습니다. 비록 그 자체의 추론 텍스트에서 올바른 청구서를 ID로 명시했음에도 말입니다. 틀린 것이 아니었습니다. 단지 충분한 신호가 있다고 확신할 수 없는 답변은 커밋하지 않았을 뿐입니다.
저는 선택에 놓였습니다. 이미 작성해 둔 스크립트에 데모 비디오를 맞출 것인지, 아니면 모델이 실제로 수행한 것을 보여줄 것인지 말입니다. 저는 현실에 맞게 내레이션을 다시 작성했습니다.
정직한 버전이 더 나은 데모인 이유
저는 제가 우려했던 실패 모드 — 즉 자신감 있는 오답이 제 가드를 통과하는 경우 — 에 대비하여 설계했습니다. 하지만 그 반대 케이스, 즉 모델 자체의 확신이 사용 가능한 신호가 되지 못하도록 지나치게 주의에 갇혀서 인간이 모델이 실제로 정답을 알았는지 여부와 관계없이 모든 것을 검토하게 되는 시스템에는 그렇게 세심하게 대비하지 않았습니다.
제가 본 것은 그 중간 지점에 있습니다. Qwen은 올바른 청구서에 대해 소리 내어 추론했고, 이를 단정하기를 거부했으며, 조정 계층(orchestration layer)에 읽을 수 있는 번호 — 즉 '30%, 이유가 이렇습니다' — 를 전달했습니다. 이것이야말로 정책을 구축할 수 있는 정확한 종류의 것입니다. 제 자동 마감 게이트는 모델의 추측이 맞는지 여부를 평가할 필요가 없습니다. 단지 Qwen이 스스로 계산한 신뢰도 점수만 믿고, 그 점수가 낮으면 기본적으로 인간에게 이관하면 됩니다.
모델이 틀렸을 때 이를 잡아내기 위해 안전 계층(safety layer)을 구축하지 마세요. 대신 모델 자체의 불확실성(uncertainty)을 첫 번째 출력으로 취급하고, 그 위에 가드레일(guardrails)을 설정하는 방식으로 만드세요. 다른 방법은 모델이 스스로 내놓은 답변을 판단하는 데 있어 당신이 모델보다 더 똑똑해야 함을 요구합니다. 하지만 이 방식은 단지 모델에게 자신이 무엇을 모르는지에 대해 정직할 것을 요구할 뿐이며, 제가 테스트한 Qwen은 그러했습니다.
Repo: github.com/dannwaneri/recona — MIT 라이선스. Global AI Hackathon Series with Qwen Cloud의 Track 4: Autopilot Agent를 위해 구축되었습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기