Freight Exception Agents: Worldwide Express가 운임 청구 예외를 에이전트 3개로 나눠 미해결 잔액을 75% 줄인 방식
미국 물류 중개사 Worldwide Express는 3자 대조에서 걸린 LTL 운임 송장을 에이전트 3개로 나눠 처리합니다. 6개월 만에 주 1만 건을 오류율 1% 미만으로 닫고 미해결 잔액을 1,500만 달러에서 400만 달러로 줄였습니다. 구조화 출력, 정확도 측정법, 12주 시범안을 붙였습니다.
Worldwide Express는 운임 청구 예외를 유형별 에이전트 3개에 맡겼습니다. 운송사별 규정은 코드가 아니라 지식베이스로 바꿔 끼웠습니다. 처음엔 사람이 건마다 승인하다 정확도가 99%를 넘자 일괄 승인으로 바꿨습니다. 따라 하려면 예외 유형과 운송사별로 정확도를 따로 재는 기준과 반려 이력을 고치는 고리부터 갖춰야 합니다.
요약
Worldwide Express는 ShipStation Global에 속한 미국 물류 중개사입니다. 시스템 전체 매출이 약 50억 달러이고 LTL(less-than-truckload, 여러 화주의 소량 화물을 한 트럭에 섞어 나르는 운송) 운송사 75곳 이상, 고객 13만 곳 이상을 연결합니다. 운송사가 보낸 송장은 발주(PO), 입고 기록, 송장 금액을 맞춰 보는 3자 대조(three-way match)를 거치는데 약 14%가 여기서 걸렸습니다. 걸린 건은 사람이 하나씩 풀었습니다. 유형 확인, 원인 조사, 운송사 메일, 답신 대기, TMS(운송 관리 시스템) 반영의 다섯 단계였습니다. 운송사마다 요율 구조와 이의 제기 절차가 달라 시간이 많이 들었습니다. 그동안 매달 1,500만 달러 규모의 현금이 예외에 묶였습니다. 2025년 6월 AWS 자문팀과 주문에서 현금 회수까지(Order-to-Cash) 전 과정을 진단해 자동화 후보 19개를 뽑았고 가치가 가장 큰 운임 예외를 먼저 골랐습니다.
진단에서 실운영까지는 6개월이 걸리지 않았습니다. 지금은 운송사 40곳 이상에 적용해 매주 예외 1만 건, 전체 예외의 약 50%를 에이전트가 닫습니다. 오류율은 1% 미만입니다. 미해결 예외 잔액은 1,500만 달러에서 6개월 뒤 400만 달러로 75% 줄었고 이렇게 풀린 현금이 1,000만 달러입니다. 연간 비용 절감은 100만 달러를 넘고 첫해 ROI는 60배, 현금 회수 기간은 4주 짧아졌습니다. 원문은 규칙 기반 자동화가 정해진 흐름에는 맞지만 이 예외들은 맥락을 보고 판단해야 해서 에이전트를 택했다고 설명합니다. 아래에서는 에이전트 구성, 운송사 지식베이스, 사람 승인 단계, 지표를 개념별로 풀고 같은 방식을 매입 정산에 옮길 때 필요한 출력 형식, 정확도 측정법, 일정을 덧붙였습니다.
핵심 메커니즘
Three Exception Agents: 예외 유형마다 에이전트 하나
예외는 세 종류입니다. 수량이나 서비스 코드가 선적 기록과 다른 품목 불일치, 청구 운임이 계약 요율과 다른 요율 차이, 리프트게이트·주거지 배송·재계량 같은 예상 밖 부대비용(accessorial)입니다. Worldwide Express는 유형마다 에이전트를 하나씩 두었습니다. Invoice Matching Agent는 송장에 맞는 선적 기록을 찾아 어긋난 항목을 표시합니다. Pricing Variance Agent는 청구 금액을 계약 요율과 비교해 차이가 정당한지 판단합니다. Accessorial Validation Agent는 부대비용이 실제 배송 이벤트로 뒷받침되는지 봅니다. 감지된 예외는 셋 중 하나로 넘어갑니다. 무엇으로 배정하는지는 원문에서 밝히지 않았습니다. 유형을 쪼개면 에이전트마다 볼 증빙과 판단 기준이 좁아져 검토와 개선이 쉬워집니다. 예외 유형이 한두 개뿐이거나 판단이 단순한 산식이면 이렇게 나눌 필요가 적습니다.
Agent Anatomy: 지시문, action, 운송사 지식베이스
에이전트 하나는 세 부분으로 됩니다. 첫째는 역할, 판단 경계, 출력 형식을 정한 instruction prompt(지시문)입니다. 둘째는 action(에이전트가 호출하는 기능)으로, Worldwide Express의 TMS인 SpeedShip에 붙어 있습니다. 에이전트는 분석가가 쓰는 API를 그대로 불러 계약 요율, 선적 정보, 배송 증빙을 보고 결론도 같은 SpeedShip 업무 흐름에 기록합니다. 셋째가 운송사별 지식베이스입니다. 이 구성 덕분에 운송사별 코드 없이 같은 에이전트 3개가 모든 운송사를 처리합니다. 모델 추론은 Amazon Bedrock이 맡습니다. 오케스트레이션은 Amazon EC2(Auto Scaling) 위에 직접 짜서 오픈소스 에이전트 라이브러리를 쓸 수 있게 했습니다. 구체적인 모델명과 라이브러리 이름은 원문에 나오지 않습니다. 구축은 Worldwide Express, AWS, 파트너사 LTM이 함께 했습니다.
Carrier Knowledge Base: 판단 전에 매번 운송사 규정을 조회
운송사 지식베이스에는 요율 규칙(tariff), 할증 정의, 이의 제기 절차, 허용 편차 기준, 운송사별 SOP 문서가 들어 있습니다. 에이전트는 추천을 내기 전에 해당 운송사의 규정을 먼저 꺼내 봅니다. 그래서 같은 리프트게이트 요금이라도 운송사 A와 B에서 다른 결론이 나올 수 있습니다. 처리가 끝나면 무엇을 확인했고 무엇을 했는지 평문 메모를 남깁니다. 검토자는 이 메모로 판단 근거를 바로 확인합니다. 운송사가 늘 때 코드를 고치지 않고 문서만 더하면 되므로, 거래처마다 계약 조건이 다른 정산 업무에 맞는 방식입니다. 지식베이스를 어떤 저장소와 검색 방식으로 만들었는지는 원문에 없습니다.
Human-in-the-Loop: 건별 승인에서 일괄 승인으로
처음에는 모든 추천을 사람이 SpeedShip 분석가 화면에서 건마다 승인한 뒤 확정했습니다. 원문은 재무운영(FinOps) 조직이 받아들이게 하려면 이 단계가 필요했다고 설명합니다. 정확도가 99%를 넘은 뒤에는 일괄 승인을 기본값으로 바꿨습니다. 검토자가 추천을 반려하면 시스템이 기록하고 팀은 반려 이력을 보고 지시문과 지식베이스를 고칩니다. 이 고리를 돌수록 자동화 범위가 넓어집니다. 분석가의 시간은 반복 처리에서 복잡하고 금액이 큰 분쟁으로 옮겨 갔습니다. 정확도를 어떻게 쟀는지는 원문에서 밝히지 않았습니다.
Observability: 운송사·유형별로 쪼개 보는 대시보드
대시보드는 네 가지를 봅니다. 운송사별 자동화율, 예외 유형별 오류율, 해결 시간, 사람이 추천을 뒤집은 빈도입니다. 운송사와 유형으로 나눠 보면 어느 운송사의 지식베이스가 부족한지, 어느 에이전트의 지시문을 고쳐야 하는지가 드러납니다. 사람 수정 빈도는 일괄 승인으로 넘어갈 시점을 정하는 근거도 됩니다.
통념과 다른 주장
흔히 이렇게 봅니다운임 정산 같은 반복 업무는 규칙 기반 자동화로 충분하다.
원문은 이렇게 봅니다규칙 기반 자동화는 정해진 흐름에 맞는다. 운임 예외는 맥락을 보고 판단해야 하므로 에이전트가 맞다.
근거운송사마다 요율 구조와 이의 제기 절차가 달라 사람이 건마다 따로 확인해야 했습니다. 에이전트 도입 뒤 주 1만 건을 오류율 1% 미만으로 처리합니다.
흔히 이렇게 봅니다거래처마다 조건이 다르면 거래처별로 자동화를 따로 만들어야 한다.
원문은 이렇게 봅니다에이전트는 유형별 3개로 고정하고 운송사 차이는 지식베이스 문서로 흡수한다.
근거운송사별 코드 없이 같은 에이전트 3개를 운송사 40곳 이상에 적용했습니다.
저자가 든 사례
| 항목 | 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|---|
| 예외 처리 | 송장 약 14%가 3자 대조에서 걸려 다섯 단계 수작업 | 유형별 에이전트 3개에 배정 | 주 1만 건, 예외의 약 50%를 에이전트가 처리 | Three Exception Agents |
| 운송사 확대 | 75곳 이상 운송사의 요율·절차가 제각각 | 운송사별 지식베이스, 운송사별 코드 없음 | 운송사 40곳 이상 적용 | Carrier Knowledge Base |
| 승인 방식 | FinOps가 AI 판단을 믿어야 함 | 건별 승인 뒤 99% 초과 시 일괄 승인 | 오류율 1% 미만 | Human-in-the-Loop |
| 현금 | 매달 1,500만 달러 규모 현금이 묶임 | 예외를 빨리 닫음 | 잔액 75% 감소, 1,000만 달러 회수, 현금화 4주 단축 | 전체 |
기술 디테일: 같은 구조를 직접 만든다면
아래는 원문에 없는 실행 제안입니다. 필드명과 숫자는 가상 예시입니다.
세 에이전트로 배정하려면 LLM 분류보다 3자 대조가 실패한 사유를 먼저 씁니다. 수량·서비스 코드가 틀렸으면 Invoice Matching, 기본 운임 금액이 틀렸으면 Pricing Variance, 계약에 없는 부대비용 항목이 있으면 Accessorial로 보내는 식입니다. 사유가 둘 이상이면 금액이 큰 쪽으로 보내고 나머지는 같은 건에 메모로 붙입니다. 규칙으로 못 가르는 건만 작은 모델에 분류를 맡기고 오배정률을 주마다 봅니다.
판단 결과를 검토하려면 에이전트 출력을 정해진 JSON으로 받습니다. 검토 화면과 대시보드가 같은 필드를 읽게 합니다. 근거 조항(evidence)이 비어 있으면 자동 승인 대상에서 뺍니다.
{
"exception_id": "EX-2026-118204",
"carrier_id": "CARRIER-A",
"exception_type": "accessorial",
"agent": "accessorial_validation",
"billed_amount": 145.00,
"expected_amount": 0.00,
"decision": "dispute",
"evidence": [
{"source": "carrier_kb", "doc": "CARRIER-A tariff", "clause": "liftgate 정의", "effective_date": "2026-01-01"},
{"source": "speedship", "doc": "delivery_events", "detail": "도크 하차 기록, 리프트게이트 미사용"}
],
"runs_agreed": "3/3",
"note": "배송지가 도크 보유 사업장이라 리프트게이트 요금 근거 없음. 이의 제기 권고.",
"review_status": "pending"
}판단이 흔들리지 않게 하려면 temperature를 0으로 두고 같은 건을 세 번 돌려 decision이 모두 같을 때만 일괄 승인 후보로 올립니다. 하나라도 다르면 건별 검토로 보냅니다. 일정 금액(예: 500달러)을 넘는 건과 지식베이스 문서가 없는 신규 운송사 건은 정확도와 상관없이 사람이 봅니다.
운송사 규정을 정확히 찾으려면 지식베이스 문서마다 carrier_id, 문서 종류(tariff, 할증, SOP, 이의 절차), 적용 시작일을 메타데이터로 붙입니다. 검색은 운송사와 선적일 기준으로 먼저 거른 뒤 그 안에서만 합니다. 요율표가 바뀌었는데 옛 문서가 걸리는 실수를 막기 위해서입니다.
99% 기준을 재려면 정확도를 “검토자가 고치지 않고 승인한 비율”로 정하고 예외 유형 × 운송사 칸마다 따로 셉니다. 칸마다 최근 200건 이상이 쌓이고 4주 연속 99%를 넘긴 칸만 일괄 승인으로 바꿉니다. 전체 평균이 99%여도 특정 운송사 칸이 낮을 수 있기 때문입니다.
SpeedShip 같은 TMS에 붙이려면 조회용 action과 기록용 action을 나눕니다. 에이전트는 조회만 바로 하고 기록은 사람 승인이나 일괄 승인 규칙을 통과한 뒤에만 실행합니다. 모든 기록에 exception_id와 승인 주체를 남겨 감사에 대비합니다.
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 요율표 개정 미반영 | 옛 요율로 판단 | 적용 시작일 필터, 운송사 공지 받으면 KB 갱신 |
| 배송 증빙 없음 | 부대비용 판단 불가 | 자동 판단 중지, 운송사에 증빙 요청으로 분기 |
| 신규 운송사 | KB 문서 없음 | 문서 등록 전까지 건별 검토 |
| 반려 사유가 자유 서술 | 개선 대상이 안 보임 | 반려 사유 코드(요율 오적용, 증빙 오독 등)를 고르게 함 |
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 맡는 일 |
|---|---|
| 재무운영(FinOps) 책임자 | 첫 예외 유형 선정, 일괄 승인 전환 승인 |
| FinOps 분석가 | 건별 검토, 반려 사유 코드 기록 |
| 운송사 관리 담당 | 요율표·SOP 문서 수집과 갱신 |
| AI·데이터 엔지니어 | 라우팅, 지시문, 지식베이스, 대시보드 |
| TMS 담당 IT | 조회·기록 API 권한 분리 |
| 내부통제 담당 | 금액 상한, 승인 기록 기준 확인 |
준비물. 최근 6개월 예외 목록과 해결 결과(인정, 이의, 조정 금액), 운송사별 요율표·할증표·SOP, TMS 조회 API 권한, 반려 사유 코드 목록이 필요합니다. 기준선으로 예외 유형별 건수, 평균 해결 일수, 미해결 잔액을 시작 전 4주치로 잡습니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 예외 유형 분류, 반복이 가장 많은 유형과 상위 운송사 5곳 선정 | 기준선 표, 대상 범위 |
| 3~6주 | 에이전트가 판단만 하고 사람은 기존대로 처리, 둘을 비교 | 유형 × 운송사별 일치율 |
| 7~10주 | 건별 승인으로 실운영, 반려 이력으로 지시문·KB 수정 | 주간 반려 리포트 |
| 11~12주 | 기준 넘은 칸만 일괄 승인 전환 여부 판정 | 확대 결정 문서 |
현업에 물을 것.
- 3자 대조에서 걸리는 건 중 가장 많은 유형과 운송사는 어디인가요?
- 분석가가 이의 제기를 결정할 때 실제로 열어 보는 화면과 문서는 무엇인가요?
- 운송사 요율표가 바뀌면 누가, 며칠 안에 알게 되나요?
- 지금 이의 제기 결과(인정, 기각)를 시스템에 남기고 있나요?
진행 판정 기준(예시). 첫 유형에서 건별 승인 4주 동안 일치율 99% 초과, 오판 금액이 처리 금액의 0.5% 미만, 평균 해결 일수가 기준선보다 짧으면 일괄 승인으로 넘깁니다. 하나라도 못 채우면 반려 이력을 고친 뒤 4주를 더 봅니다.
AX 적용 제언. 원문은 가장 반복적인 예외 유형 하나로 작게 시작해 정확도를 증명한 뒤 넓히라고 권합니다. 국내 3PL, 포워더, 자체 물류비를 정산하는 제조·유통사라면 운송비 정산의 부대비용 검증이 첫 후보로 좋습니다. 같은 구조는 일반 매입 송장의 3자 대조에도 그대로 옮겨집니다. CFO에게 보고할 지표는 처리 건수보다 미해결 잔액과 현금 회수 기간이 낫습니다. Worldwide Express도 잔액 감소와 현금화 단축을 앞에 내세웠습니다. Order-to-Cash 진단에서 후보 19개를 뽑고 하나를 골랐듯, 처음부터 전 과정을 바꾸기보다 후보 목록과 우선순위를 먼저 만드는 편이 빠릅니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 발표 | AWS Machine Learning Blog, 2026.10.30 |
| 저자 | Saumya Shah, Nikhil Bhagat, Lynette Woolfolk(AWS), Arjun Srinivasan(ShipStation Global AI·데이터 과학 SVP) |
| 회사 | Worldwide Express(ShipStation Global 소속), 시스템 매출 약 50억 달러, LTL 운송사 75곳 이상, 고객 13만 곳 이상 |
| 문제 | LTL 송장 약 14%가 3자 대조 실패, 다섯 단계 수작업, 매달 1,500만 달러 규모 현금이 묶임 |
| 진단 | 2025년 6월 AWS Business Transformation & Value Advisory와 Order-to-Cash 진단, 자동화 후보 19개 |
| 구성 | 에이전트 3개(Invoice Matching, Pricing Variance, Accessorial Validation), SpeedShip action, 운송사별 지식베이스, Amazon Bedrock, Amazon EC2 |
| 승인 | 건별 사람 승인 → 정확도 99% 초과 뒤 일괄 승인 기본 |
| 결과 | 6개월 안에 실운영, 운송사 40곳 이상, 주 1만 건(예외 약 50%), 오류율 1% 미만, 잔액 1,500만→400만 달러, 현금 1,000만 달러 회수, 연 100만 달러 이상 절감, 첫해 ROI 60배, 현금화 4주 단축 |
| 다음 | Order-to-Cash의 다른 과정으로 확대 |
핵심 개념
- three-way match
- 발주, 입고 기록, 송장 금액이 서로 맞는지 보는 매입 검증. 하나라도 어긋나면 예외로 빠집니다.
- accessorial
- 기본 운임 외에 붙는 부대비용. 리프트게이트, 주거지 배송, 재계량 같은 항목입니다.
- tariff
- 운송사가 정한 요율과 청구 규칙 문서. 운송사마다 구조가 다릅니다.
- Order-to-Cash
- 주문을 받아 청구하고 현금을 회수하기까지의 전 과정.
- FinOps
- 이 원문에서는 청구와 정산을 맡는 재무운영 조직을 가리킵니다.
- SpeedShip
- Worldwide Express의 TMS. 분석가와 에이전트가 같은 API와 화면을 씁니다.
내 메모
TODO: 내 생각 추가
원문은 AWS Machine Learning Blog의 「How Worldwide Express automated freight exceptions with Amazon Bedrock」(Saumya Shah 외, 2026.10.30)입니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 사례, 원문 사례 표는 저자가 밝힌 내용을 AX Review가 다시 정리했으며 수치와 효과는 회사 측 설명입니다. 기술·현업 실행 디테일, JSON 예시, 실패 대응 표, 일정과 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용은 원문 페이지에서 볼 수 있습니다.