Robin: BILL 리스크팀이 에이전트 3개로 신용 한도 심사 대기를 3시간에서 12분으로

BILL 리스크팀은 신용 한도 심사에서 요청을 받아 담당자에게 넘기고 고객 데이터를 한 장으로 모으는 일을 에이전트 3개 묶음인 Robin에 맡겼고 건당 대기 시간이 약 3시간에서 12분으로 줄었습니다. 결정은 여전히 심사역이 링크 한 번으로 내립니다. 따라 하려면 심사 전에 사람이 손으로 하던 수집과 배정을 따로 떼어 시간을 재고 요약 속 숫자가 어느 시스템에서 왔는지 보이게 만드는 일부터 해야 합니다.

요약

BILL은 미국 중소기업에 지급(AP), 수금(AR), 지출 관리(Spend & Expense, 이하 S&E) 서비스를 파는 핀테크 회사입니다. 창업자이자 CEO인 René Lacerte는 2026년 11월 5일 2027 회계연도 1분기 실적 콜에서 리스크팀이 지난 1년 동안 만든 에이전트를 소개했습니다. PYMNTS는 같은 날 이 발언을 기사로 정리했습니다. 대표 사례는 Robin입니다. S&E 고객이 신용 한도 승인이나 변경을 요청하면 심사 건이 생깁니다. Robin은 에이전트 세 개가 함께 이 건을 맞는 심사역에게 보내고 흩어진 고객 결제·행동 데이터를 요약 한 장으로 묶고 클릭 한 번으로 결정하는 링크를 붙입니다. 예전에는 심사역이 채팅과 이메일로 들어온 요청을 쫓아다니고 대시보드 여러 개에서 데이터를 꺼내 건을 손으로 맞췄습니다.

Lacerte는 그 결과 건마다 고객이 기다리는 시간이 “about 12 minutes instead of 3 hours”가 됐다고 말했습니다. 약 15분의 1입니다. 리스크팀 전체로 보면 에이전트 100개 이상이 24시간 돌며 사건 파일 수집, 신용평가 초안, 모델 문서 작성을 맡고 있고 회사 추정으로 매달 1,400시간 이상(정규직 약 8명분)을 팀에 돌려줍니다. 줄어든 시간은 판단 자체가 아니라 판단 앞의 수집과 정리에서 나왔습니다. Lacerte는 이 성과를 2026 회계연도 구조조정에서 내건 ‘AI 네이티브 회사’ 전환이 작동한다는 근거로 들었습니다. CFO Rohini Jain은 사기 시도가 늘어나는 가운데 리스크팀이 더 적은 자원으로 AI 모델을 훨씬 많이 쓰며 일한다고 덧붙였습니다. 아래에서는 Robin이 하는 세 가지 일과 리스크팀의 에이전트 운영 방식을 나눠 설명하고 같은 구조를 직접 만들 때 필요한 설계와 일정을 붙입니다.

핵심 메커니즘

Case Routing: 요청을 맞는 심사역에게 바로 보낸다

Case Routing(심사 건 배정)은 들어온 요청을 누가 볼지 정하는 단계입니다. 입력은 채팅과 이메일로 흩어져 들어오는 한도 요청입니다. 처리 단계에서는 요청의 종류와 고객을 알아낸 뒤 담당 심사역을 고릅니다. 출력은 심사역 대기열에 놓인 건 하나입니다. Lacerte는 Robin이 요청마다 맞는 심사역에게 보낸다고 설명했고 예전에는 심사역이 채팅 메시지와 이메일 속 요청을 직접 쫓아다녔다고 했습니다. 요청 채널이 여럿이고 건마다 담당이 달라지는 조직일수록 효과가 큽니다. 심사역이 한 명이고 요청이 한 창구로만 들어온다면 이 단계에서 아낄 시간은 적습니다.

작은 예시(가상): 한 고객사의 재무 담당자가 다음 달 출장이 많으니 카드 한도를 올려 달라는 이메일을 영업 담당자에게 보냅니다. 배정 단계는 이 메일에서 고객 ID, 요청 종류(증액), 희망 금액을 뽑아 그 업종을 맡은 심사역의 대기열에 넣습니다. 영업 담당자가 메일을 전달하고 심사역이 받은 편지함을 뒤지던 과정이 사라집니다.

Case Summary: 흩어진 대시보드를 한 장으로

Case Summary(고객 데이터 요약)는 심사역이 판단에 쓰는 데이터를 한곳에 모으는 단계입니다. 고객 ID를 받아 결제 이력과 이용 행태 같은 데이터를 시스템마다 조회하고 판단에 필요한 항목만 추려 요약 한 장으로 내놓습니다. Lacerte에 따르면 예전에는 심사역이 결제와 행동 데이터를 서로 다른 대시보드에서 꺼내 맞춰 봤습니다. 판단에 쓰는 항목이 거의 정해져 있고 시스템에서 조회할 수 있는 심사에 잘 맞습니다. 근거 자료가 건마다 크게 달라지는 대형 여신처럼 요약 틀을 고정하기 어려운 심사에서는 효과가 작습니다.

작은 예시(가상): 요약 한 장에는 현재 한도, 최근 6개월 결제 금액과 연체 횟수, 카드 사용 패턴의 변화, 과거 한도 변경 이력이 들어가고 항목마다 원천 시스템과 조회 시각이 붙습니다.

One-click Decision Link: 결정은 사람이, 클릭 한 번으로

One-click Decision Link(원클릭 결정 링크)는 요약과 함께 오는 결정 버튼입니다. 심사역은 요약을 읽고 링크에서 승인이나 변경 같은 결정을 고르면 됩니다. Robin은 결정을 대신 내리지 않습니다. 판단은 심사역에게 남기고 판단까지 가는 동선만 줄입니다. 링크가 어느 시스템에 어떻게 결정을 반영하는지는 원문에서 밝히지 않았습니다. 승인 권한이 사람에게 있어야 하는 신용·여신 업무, 그리고 결정 근거를 남겨야 하는 업무에 맞습니다.

Always-on Risk Agents: 리스크팀이 직접 만든 24시간 에이전트 100여 개

Robin은 리스크팀이 만든 에이전트의 한 예입니다. Lacerte는 리스크팀이 지난 1년 동안 여러 기능에 걸쳐 에이전트를 100개 넘게 만들었고 이 에이전트들이 24시간 돌며 정해진 일을 스스로 끝낸다고 했습니다. 그가 든 일은 사건 파일 수집, 신용평가 초안 작성, 모델 문서 작성입니다. 모두 합쳐 매달 1,400시간 이상, 정규직 약 8명분을 돌려준다는 것이 회사 추정입니다. 단순히 나누면 에이전트 하나가 맡은 일은 월 14시간 안팎입니다. 큰 에이전트 하나보다 작은 일 하나씩을 맡은 에이전트를 많이 두는 방식으로 읽힙니다. Lacerte는 Q&A에서 이 일을 하는 AI를 훈련시킬 데이터가 매우 많다는 점도 BILL의 강점으로 꼽았습니다.

작은 예시(가상): 매일 밤 연체 징후가 생긴 고객 목록을 받아 사건 파일을 미리 만들어 두는 에이전트, 신규 심사 건마다 신용평가 초안을 써 두는 에이전트, 모델을 바꿀 때마다 변경 내역을 문서로 정리하는 에이전트를 각각 따로 둡니다.

통념과 다른 주장

저자가 든 사례

Robin: S&E 신용 한도 심사

구분	내용
상황	S&E 고객의 신용 한도 승인·변경 요청을 심사역이 손으로 맞췄습니다. 요청은 채팅과 이메일로 쫓고 결제·행동 데이터는 서로 다른 대시보드에서 꺼냈습니다.
한 일	에이전트 3개 묶음 Robin이 요청을 맞는 심사역에게 보내고 고객 데이터를 요약 한 장으로 묶고 원클릭 결정 링크를 붙입니다. 에이전트별 분담은 원문에서 밝히지 않았습니다.
결과	건당 처리와 고객 대기 시간이 약 3시간에서 약 12분으로 줄었습니다. Lacerte는 고객 경험이 빨라지고 직원이 더 중요한 일에 집중하게 됐다고 했습니다.
연결	Case Routing, Case Summary, One-click Decision Link

리스크팀 에이전트 100여 개

구분	내용
상황	CFO에 따르면 들어오는 사기 시도의 압력이 계속 커지고 있고 리스크팀은 더 적은 자원으로 일합니다.
한 일	리스크팀이 지난 1년간 에이전트를 100개 넘게 만들어 24시간 돌립니다. 사건 파일 수집, 신용평가 초안, 모델 문서 작성을 맡깁니다.
결과	매달 1,400시간 이상, 정규직 약 8명분을 돌려준다고 회사가 추정했습니다. 1분기 사기·신용 손실은 예상보다 약 200만 달러 적었고 CFO는 고객 유입 단계를 바꾼 결과가 아니라 손실 관리가 나아진 덕으로 설명했습니다.
연결	Always-on Risk Agents

Chat with BILL: 고객지원 대화의 45%

구분	내용
상황	고객지원 문의를 사람이 받았습니다.
한 일	약 1년 전 AI 지원 채팅 Chat with BILL을 열었습니다.
결과	AI가 처리하는 고객지원 대화가 출시 후 45%까지 늘었습니다.
연결	내부 리스크 업무 밖에서도 같은 방식(사람 앞단의 반복 응대를 AI가 맡음)을 쓰는 예

기술 디테일: 신용 한도 심사 에이전트를 직접 만든다면

아래는 원문에 없는 내용으로, Robin과 같은 구조를 실제로 돌릴 때 필요한 설계를 가상 예시로 정리했습니다.

Case Routing을 돌리려면 LLM은 추출만 하고 배정은 규칙으로 정합니다. 요청 문장에서 고객, 요청 종류, 금액을 뽑는 일은 LLM이 잘합니다. 누구에게 보낼지는 업종, 금액 구간, 심사역별 대기 건수 같은 규칙으로 정해야 결과가 매번 같고 설명할 수 있습니다. 추출 결과는 구조화 출력(JSON 스키마 강제)으로 받고 temperature는 0으로 둡니다. 추출은 빠르고 저렴한 소형 모델로 충분합니다. 정답을 아는 과거 요청 100건으로 고객 ID 추출 정확도를 먼저 재고 95%에 못 미치면 사람 대기열로 보내는 기준을 낮춥니다. 고객 ID를 확신하지 못하면 추측하지 말고 customer_id를 비우고 needs_review를 true로 둬 사람 대기열로 보냅니다.

{
  "request_id": "REQ-20261107-0142",
  "channel": "email",
  "customer_id": "C-58213",
  "request_type": "limit_increase",
  "requested_limit_usd": 25000,
  "reason_text": "다음 달 출장 증가",
  "extraction_confidence": 0.93,
  "needs_review": false,
  "assigned_underwriter": "uw_kim",
  "routing_rule": "업종=제조, 금액 구간=1만~5만 달러, 대기 건수 최소"
}

Case Summary를 돌리려면 숫자는 SQL로 뽑고 문장만 LLM이 씁니다. 현재 한도, 최근 6개월 결제 금액, 연체 횟수 같은 숫자는 조회 쿼리에서 바로 가져오고 LLM이 다시 쓰지 않게 합니다. LLM은 “최근 3개월 사용액이 한도의 90%를 넘었다” 같은 서술만 쓰고 문장마다 근거 필드 이름을 달게 합니다. 항목마다 원천 시스템과 조회 시각을 붙이고 조회 시각이 24시간을 넘긴 데이터는 요약 위쪽에 경고로 띄웁니다. 도입 전에 과거 건 20개로 요약을 3번씩 만들어 숫자 항목이 세 번 모두 같은지, 서술이 근거 필드와 맞는지 대조합니다.

One-click Decision Link를 안전하게 쓰려면 링크를 일회용으로 만듭니다. 링크에는 서명된 토큰을 넣고 배정된 심사역 계정에서만 열리게 합니다. 24시간이 지나거나 한 번 쓰면 닫히게 합니다. 승인 외의 결정(변경, 거절)은 사유 코드를 고르지 않으면 제출되지 않게 합니다. 결정마다 요약 버전, 클릭 시각, 사유 코드를 로그에 남겨 나중에 “무엇을 보고 결정했나”를 되짚을 수 있게 합니다.

12분 같은 숫자를 재려면 타임스탬프 네 개를 남깁니다. 대기 시간을 요청 접수(t0)에서 결정(t3)까지로 정의하고 중간에 배정 완료(t1)와 요약 준비(t2)를 기록합니다. 평균만 보지 말고 중앙값과 상위 10% 지연을 함께 봐야 오래 묵는 건이 보입니다. 이 기록이 없으면 도입 전후 비교도, 어느 단계에서 시간이 줄었는지도 말할 수 없습니다.

에이전트를 100개 규모로 늘리려면 등록부부터 만듭니다. 에이전트마다 이름, 담당자, 실행 조건(일정 또는 이벤트), 읽는 시스템, 내놓는 산출물, 사람이 확인하는 지점, 월 절감 시간 추정치를 한 줄로 적습니다. 절감 시간은 “건수 × (예전 처리 시간 − 지금 확인 시간)“으로 계산하고 계산식을 함께 남깁니다. 그래야 1,400시간 같은 합계를 나중에 다시 설명할 수 있습니다.

막히는 경우	증상	대응
고객 식별 실패	이메일에 회사명만 있고 ID가 없음	needs_review로 사람 대기열에 넣고 추측 배정 금지
오배정	업종이나 금액 구간을 잘못 읽음	심사역 화면에 재배정 버튼, 재배정 사유를 규칙 보완에 사용
오래된 데이터	조회 시각이 24시간 초과	요약 위에 경고 표시, 재조회 후 결정
요약 숫자 불일치	서술 속 숫자와 조회값이 다름	숫자는 서술에 쓰지 않고 필드 참조로만 표시
링크 오용	전달된 링크를 다른 사람이 클릭	배정 계정 인증, 일회용, 만료

현업 실행 디테일: 누가, 언제, 무엇을

아래 역할, 일정, 판정 기준은 원문에 없는 가상 예시입니다.

역할	담당	하는 일
오너	심사팀장	범위와 판정 기준 결정, 매주 금요일 30분 점검 주재
업무 전문가	심사역 2명	요약 항목 확정, 병행 운영 중 결과 검토
데이터 담당	리스크 데이터 엔지니어	조회 쿼리, 타임스탬프 기록, 요약 데이터 연결
에이전트 개발	AX 추진팀 개발자 1~2명	추출 프롬프트, 배정 규칙, 결정 링크 구현
통제	모델 리스크·컴플라이언스 담당	결정 로그, 권한, 링크 보안 검토

시작 전 준비물. 최근 3개월 심사 건 목록과 건별 접수·결정 시각, 채널별 실제 요청 원문 50건, 심사역이 한 건을 볼 때 여는 화면 목록, 결정 사유 코드표, 심사역 배정 규칙(문서가 없으면 팀장 인터뷰 메모)을 모읍니다.

기간	할 일	산출물
1주	현재 대기 시간 측정, 심사역 2명 작업 관찰	단계별 소요 시간표
2~3주	배정 규칙과 추출 구현, 사람 배정과 병행 비교	배정 일치율 리포트
3~4주	요약 항목 확정, 과거 20건으로 대조 검증	요약 템플릿, 불일치 목록
4~5주	결정 링크 구현과 보안 검토, 한 팀에 시범 적용	결정 로그, 시범 운영 기록
6주	전후 비교와 확대 여부 판정	판정 메모

인터뷰 질문. 심사역에게 묻습니다. 한 건을 열면 가장 먼저 어떤 화면을 보는가? 결정에 실제로 쓰는 숫자는 무엇이고 참고만 하는 숫자는 무엇인가? 건이 오래 묵는 이유는 대개 무엇인가(요청을 못 찾음, 데이터 대기, 다른 부서 확인)? 요약에 없으면 결정을 못 내리는 항목은 무엇인가? 팀장에게는 지금 배정을 누가 어떤 기준으로 하는지, 잘못 배정된 건은 어떻게 돌려보내는지를 묻습니다.

진행 판정 기준(가상 예시). 6주차에 대기 시간 중앙값이 도입 전의 절반 이하인지, 배정이 사람 판단과 90% 이상 일치하는지, 요약 숫자 불일치가 0건인지, 결정 로그가 모든 건에 남았는지를 봅니다. 넷을 모두 넘으면 다른 심사 유형으로 넓히고 하나라도 못 넘으면 그 단계만 2주 더 고칩니다.

어디에 먼저 쓸까. 국내 기업에서 같은 구조가 바로 들어갈 곳은 사람이 최종 결정을 내리되 결정 전에 자료를 모으는 시간이 긴 승인 업무입니다. 카드사·캐피털의 한도 조정, 제조·유통사의 거래처 여신 한도 심사, 구매팀의 신규 협력사 등록 심사가 해당합니다. 순서는 BILL의 사례를 따라 측정, 배정, 요약, 결정 링크로 가는 편이 안전합니다. 결정 권한을 건드리지 않으므로 규제와 내부 통제 부담이 작고 효과는 대기 시간이라는 한 숫자로 바로 보입니다. 첫 사례가 자리를 잡으면 사건 파일 준비나 문서 작성처럼 작은 반복 업무를 맡는 에이전트를 현업 팀이 직접 하나씩 늘리게 하고 등록부로 전체 절감 시간을 관리합니다. 현업 스폰서는 심사팀장, 데이터 준비도는 “결정에 쓰는 숫자를 쿼리로 뽑을 수 있는가”로 먼저 점검합니다.

원문 사례

항목	내용
발표	BILL 2027 회계연도 1분기(2026년 9월 30일 마감) 실적 콜, 2026년 11월 5일
발언자	René Lacerte(창업자·CEO), Rohini Jain(CFO)
Robin	S&E 신용 한도 심사용 에이전트 3개 묶음. 배정, 고객 데이터 요약, 원클릭 결정 링크
심사 대기	건당 약 3시간 → 약 12분
리스크팀 에이전트	지난 1년간 100개 이상, 24시간 가동. 사건 파일 수집, 신용평가 초안, 모델 문서 작성
돌려준 시간	월 1,400시간 이상, 정규직 약 8명분(회사 추정)
고객지원	AI 처리 대화 비중 45%(Chat with BILL 출시 약 1년 뒤)
1분기 신규 기능	Risk Intelligence, AI Control Hub, AI 지원 온보딩, Chat with BILL(베타), 외부 MCP 커넥터 등 5개
기타	Visa·Billtrust와의 결제 에이전트 시범을 약 4주 만에 구축. 코드 대부분을 AI가 작성
배경	2026 회계연도 구조조정으로 AI 네이티브 회사 전환 추진. PYMNTS 앞선 보도로는 5월에 인력 30% 감축 계획
1분기 실적	총매출 3억 5,380만 달러(전년 대비 13% 증가), 비GAAP 영업이익률 39%

핵심 개념

Underwriting

신용 한도나 보험 인수처럼 위험을 받아들일지, 어떤 조건으로 받을지 정하는 심사 업무입니다.

Spend & Expense

BILL의 법인카드·경비 관리 사업입니다. 고객에게 카드 한도를 주므로 한도 심사가 따라옵니다.

AI-native

BILL이 구조조정 목표로 내건 말로, 고객용 기능뿐 아니라 내부 업무를 만들고 돌리는 방식에도 AI를 기본으로 쓰는 회사를 뜻합니다.

Risk Intelligence

지급 승인 단계에서 거래처의 과거 청구 패턴과 다른 청구서를 짚고 이유를 보여 주는 BILL의 고객용 에이전트입니다. 첫 6주에 1억 달러 넘는 이상·착오 지급을 찾았다고 회사가 밝혔습니다.

AI Control Hub

고객이 BILL 에이전트가 한 행동을 한 화면에서 지켜보게 하는 관리 화면입니다.

FTE

Full-Time Equivalent. 정규직 한 명이 한 달에 일하는 시간을 기준으로 업무량을 사람 수로 바꾼 값입니다.

내 메모

TODO: 내 생각 추가

원문은 PYMNTS의 「BILL Slashes Underwriting Times From 3 Hours to 12 Minutes With AI」(2026.11.5)입니다. 기사 일부가 구독 양식으로 가려져 있어, 같은 실적 콜의 Motley Fool 녹취록(「BILL (BILL) Q1 2027 Earnings Call Transcript」, 2026.11.6 게시)으로 발언과 수치를 확인하고 보탰습니다(이전 업무 방식, S&E 한도 심사라는 범위, CFO 발언, 신규 기능, 실적 수치). 요약, 핵심 메커니즘의 원문 설명, 사례, 원문 사례 표는 두 자료의 내용을 AX Review가 다시 정리했습니다. 시간 절감 수치는 모두 회사 추정치이고 ‘약 15분의 1’과 ‘에이전트당 월 14시간 안팎’은 공개 수치를 단순 계산한 값입니다. Underwriting, FTE의 뜻풀이는 일반적인 정의로 보탰습니다. 메커니즘의 작은 예시, JSON 예시, 타임스탬프 설계, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 발언은 원문 기사와 녹취록에서 볼 수 있습니다.