Small Agent Team: DHL 재무가 에이전트 개발을 2~3명에 묶고 전건 사람 확인을 두는 이유

DHL Supply Chain 재무 조직은 에이전트를 빨리 많이 만드는 길 대신, 2~3명이 좁은 에이전트를 만들고 모든 변경을 사람이 확정하는 길을 골랐습니다. 따라 하려면 에이전트 권한을 ERP 역할에 묶고 에이전트 결과를 그 에이전트가 아닌 쪽이 채점하는 구조부터 만들어야 합니다.

요약

AIM Media House의 Deployed는 2026년 11월 3일, 라스베이거스 Oracle AI World에서 DHL Supply Chain 재무 리더 세 명을 만나 쓴 글을 실었습니다. 글로벌 회계 담당 SVP Graham Walker, 구현 책임자 Sam Game, 재무 혁신 조직을 이끄는 VP Mark Jungmann입니다. 이 조직은 공급사 송장을 한 해 약 170만 건 처리합니다. 재무 에이전트는 Oracle AI Agent Studio(Oracle ERP 안에서 AI 에이전트를 만드는 도구)로 3~4개를 만들었고 개발에 붙는 인원은 언제나 2~3명입니다. 공급사 데이터를 일괄로 바꾸는 에이전트가 2026년 1분기부터 돌고 있고 원장 업무를 맡는 Ledger Agent는 성탄절 직전 첫 운영 배포를 목표로 합니다.

가장 눈에 띄는 숫자는 송장 인식률입니다. 2026년 5~6월께 송장 인식 엔진을 Oracle Document IO로 바꾸자 공급사 송장 데이터 인식률이 약 60%에서 95~96%로 올랐습니다. 기사는 이 수치가 데이터를 읽어 낸 비율일 뿐, 사람 손 없이 끝난 송장의 비율은 아니라고 선을 긋습니다. 팀을 작게 둔 이유는 일관성입니다. Walker는 몇 년 동안 재무 프로세스를 표준화했는데도 직원이 각자 만든 보고서가 비슷하면서 조금씩 달랐던 경험을 들었습니다. 에이전트가 그 편차를 되풀이하지 않게 하려는 선택입니다. 통제도 같은 방향입니다. 거래 데이터를 바꾸는 에이전트는 Oracle 역할 권한에 묶이고 정보보안 인력이 개발 논의에 들어오며 효과가 입증될 때까지 모든 처리는 사람 확인에서 멈춥니다. 아래에서는 작은 팀, 좁은 에이전트, 인식률 지표, 사람 확인과 권한, 독립 채점을 차례로 풉니다.

핵심 메커니즘

Small Agent Team: 에이전트를 만드는 사람을 2~3명으로 묶는 운영 방식

재무 에이전트를 만들고 고치는 사람을 소수 전담 그룹으로 제한하는 방식입니다. 현업 요청은 누구나 낼 수 있지만 에이전트 설계와 배포는 그룹 안에서만 이뤄집니다. 같은 사람들이 모든 에이전트의 입력 형식, 권한, 출력 규칙을 정하므로 에이전트마다 기준이 갈라지지 않습니다. Walker가 경계한 것은 표준화를 끝낸 재무 프로세스가 사람마다 만든 도구 때문에 다시 갈라지는 일이었습니다. 이 방식은 에이전트가 장부나 마스터 데이터처럼 회사 전체가 같은 값을 봐야 하는 영역을 건드릴 때 맞습니다. 개인 메일 정리처럼 결과가 한 사람에게만 미치는 도구라면 전담 그룹을 거칠 필요가 적습니다. Walker는 재무팀이 개발자가 되려는 것이 아니라 배포와 변화 관리에 힘을 쓰려는 것이라고 말했습니다.

Narrow Agent: 한 업무 한 데이터만 맡는 좁은 에이전트

DHL 재무 에이전트는 재무 전체를 맡지 않고 정해진 데이터 객체 하나와 정해진 행동 하나를 맡습니다. 공급사 데이터 에이전트는 스프레드시트로 받은 변경 목록을 읽어 지급 조건 같은 공급사 정보를 한꺼번에 바꿉니다. 구매 요청 에이전트는 Agent Studio를 처음 써 본 기능 컨설턴트가 오후 한나절에 만들었습니다. 다음 후보도 좁게 잘려 있습니다. 매입채무(AP) 쪽 계정 매핑과 세금 코드 에이전트, 채권 회수 흐름이 검토 대상입니다. Game은 에이전트를 들이면서 기반 ERP 데이터 모델을 바꿀 필요가 없었다고 말했습니다. 범위가 좁을수록 권한을 작게 줄 수 있고 틀렸을 때 피해 범위도 작습니다.

Document IO: 인식률과 무인 처리율을 나눠 보는 송장 인식 엔진

Oracle Document IO는 LLM으로 송장 문서에서 데이터를 뽑아 공급사 송장 필드에 매핑하는 엔진입니다(Oracle 문서 기준, 기사가 링크로 인용). 입력은 공급사가 보낸 송장이고 처리는 공급사명, 송장 번호, 금액, 날짜 같은 항목 추출과 필드 매핑이며 출력은 ERP 송장 레코드의 초안입니다. DHL은 이 엔진으로 바꾼 뒤 인식률이 약 60%에서 95~96%로 올랐고 Game은 그 사이 팀이 따로 한 일이 없었다고 말했습니다. 기사가 짚듯 인식률은 송장 처리가 사람 없이 끝났다는 뜻이 아닙니다. 항목을 맞게 읽어도 계정 코딩, 승인, 예외 처리가 남기 때문입니다. 가상 예시로, 100건 중 96건의 필드를 맞게 읽어도 승인 단계에서 사람이 모두 확인한다면 무인 처리율은 0%입니다.

Human Stop: 역할 권한 안에서 제안하고 사람이 확정하는 통제

거래 데이터를 바꾸는 에이전트에 두 겹의 문을 다는 방식입니다. 첫째 문은 권한입니다. 에이전트가 바꿀 수 있는 범위를 Oracle의 역할 권한에 묶고 에이전트를 쓸 수 있는 직원도 따로 제한합니다. 둘째 문은 사람 확인입니다. Game은 효과가 입증될 때까지 모든 처리가 사람에서 멈춰야 한다고 말했습니다. 정보보안 담당자는 개발 논의에 함께 들어오고 사전 승인된 송장 처리 같은 주제도 함께 다룹니다. 신뢰도(confidence) 점수가 높은 건만 자동 처리하는 방식은 성과가 꾸준히 입증된 뒤의 다음 단계로 논의됐을 뿐 정책으로 정해지지 않았습니다. 기사는 이 통제가 감사인이 평가할 수 있는 증거를 남겨야 한다고 덧붙입니다. 에이전트 행동이 어떻게 기록되고 검토되는지 보여 줄 수 있어야 한다는 뜻입니다.

Independent Grading: 에이전트 결과를 그 에이전트가 채점하지 않는 원칙

에이전트가 한 일을 같은 에이전트가 잘했다고 판정하게 두지 않는 원칙입니다. Game은 이를 두고 “marking our own homework”를 경계해야 한다고 표현했습니다. 에이전트가 스스로 성공을 보고하면, 틀린 결과도 성공으로 기록되고 품질 지표가 실제보다 좋아 보입니다. 채점은 에이전트 밖에서 해야 합니다. 합계와 코드처럼 규칙으로 맞고 틀림을 가를 수 있는 항목은 결정적 코드가 확인하고 나머지는 사람이 표본을 다시 봅니다. 이 원칙은 앞의 Human Stop과 짝을 이룹니다. 지금은 사람이 모든 건을 확인하지만 나중에 확인을 줄이려면 독립 채점 기록이 쌓여 있어야 근거가 생깁니다.

통념과 다른 주장

저자가 든 사례

공급사 데이터 일괄 변경 에이전트

• 상황: 지급 조건 같은 공급사 정보를 여러 건 한꺼번에 바꿔야 하는 일이 반복됐습니다.
• 한 일: 스프레드시트로 변경 목록을 받아 일괄로 반영하는 에이전트를 Agent Studio로 만들었습니다. 사용 직원과 변경 권한은 Oracle 역할로 제한했습니다.
• 결과: 2026년 1분기부터 운영 중입니다. 처리 건수와 절감 시간은 원문에서 밝히지 않음.
• 연결: Narrow Agent, Human Stop.

Document IO로 송장 인식 엔진 교체

• 상황: 이전 엔진의 공급사 송장 데이터 인식률은 약 60%였고 처리 물량은 연 약 170만 건입니다.
• 한 일: 2026년 5~6월께 Oracle Document IO로 엔진을 바꿨습니다.
• 결과: 인식률이 95~96%로 올랐고 팀이 따로 손댄 것은 없었다고 Game은 말했습니다. 무인 처리율은 원문에서 밝히지 않음.
• 연결: Document IO 지표 구분.

한나절에 만든 구매 요청 에이전트

• 상황: Agent Studio를 써 본 적이 없는 기능 컨설턴트가 있었습니다.
• 한 일: 구매 요청(requisition) 에이전트를 직접 만들었습니다.
• 결과: 오후 한나절 만에 완성됐습니다. 에이전트의 세부 기능은 원문에서 밝히지 않음.
• 연결: Small Agent Team. 만들기가 쉬워질수록 누가 만들지 정하는 일이 더 중요해집니다.

Ledger Agent 일정

• 상황: 원장 업무로 에이전트를 넓히는 단계입니다.
• 한 일: 2026년 11월 5일 얼리어답터 환경에 올릴 예정이었습니다.
• 결과: 성탄절 직전 첫 운영 배포가 목표입니다. 기능 세부는 원문에서 밝히지 않음.
• 연결: Narrow Agent, Human Stop.

기술 디테일: 재무 에이전트를 직접 만든다면

아래 필드, 설정값, 검증 단계는 실제로 돌릴 때 필요한 것을 새로 쓴 실행 제안이며 DHL이나 Oracle이 밝힌 구현이 아닙니다.

Small Agent Team을 돌리려면 에이전트마다 레지스트리 레코드 하나를 두고 2~3명 그룹만 고칠 수 있게 잠급니다. writes_transactional이 true인 에이전트는 human_stop을 끌 수 없게 하고 erp_role에는 ERP 역할 이름을 그대로 적어 감사 때 권한 범위를 바로 보여 줍니다. 상태는 build, early_adopter, production 세 단계로 둡니다. 모델 사용량과 테스트·감독에 쓴 시간도 에이전트별로 적어 둡니다. 기사가 짚었듯 개발이 빨라져도 이 운영 비용은 남기 때문입니다(가상 예시).

{
  "agent_id": "supplier-bulk-update-v1",
  "owner_group": ["finance-agent-team"],
  "erp_role": "AP_SUPPLIER_MASTER_EDITOR",
  "allowed_users": ["ap.master.lead", "ap.master.analyst"],
  "data_object": "supplier_site",
  "allowed_fields": ["payment_terms", "pay_group"],
  "writes_transactional": true,
  "human_stop": true,
  "status": "production",
  "monthly_cost": {"model_usd": 0, "review_hours": 0}
}

공급사 일괄 변경 에이전트를 돌리려면 스프레드시트 열을 supplier_number, site, field, old_value, new_value, reason, requested_by로 고정합니다. LLM은 열 이름이 조금 다른 파일을 이 형식으로 맞추는 데만 쓰고 temperature는 0으로 둡니다. 검증은 코드로 합니다. 공급사가 있는지, 필드가 allowed_fields에 있는지, old_value가 ERP 현재값과 같은지를 확인합니다. 현재값이 다르면 누군가 먼저 바꾼 것이므로 그 행은 멈춥니다. 통과한 행은 전후 비교표로 묶어 승인자에게 보내고 승인 뒤 반영한 다음 다시 조회해 new_value와 같은지 대조합니다.

Document IO 성과를 재려면 지표를 셋으로 나눠 따로 셉니다. 필드 인식률은 공급사명, 송장 번호, 금액, 날짜, 세금 같은 항목 가운데 맞게 읽은 비율입니다. 무수정 통과율은 담당자가 한 필드도 고치지 않은 송장 비율입니다. 무인 처리율은 사람 손 없이 전기까지 끝난 송장 비율입니다. 셋을 공급사별, 송장 양식별로 나눠 보면 어느 공급사에서 인식이 떨어지는지 보입니다. 엔진을 바꾸기 전에 같은 표본 송장 500건으로 두 엔진을 함께 돌려 비교하면 교체 효과를 숫자로 남길 수 있습니다.

지표	분자	분모	쓰는 곳
필드 인식률	맞게 읽은 필드 수	전체 필드 수	엔진 교체·튜닝 판단
무수정 통과율	수정 없이 넘어간 송장	전체 송장	담당자 업무량 추정
무인 처리율	사람 손 없이 전기된 송장	전체 송장	자동 처리 확대 판단

자기 채점을 피하려면 채점을 네 겹으로 나눕니다. 에이전트는 결과만 내고 성공 여부를 쓰지 않습니다. 규칙 검증기가 합계, 코드 유효성, 권한 범위를 대조합니다. 문장 판단처럼 규칙으로 가를 수 없는 항목은 다른 모델과 다른 프롬프트로 판정하고 판정 기준은 사람이 만든 정답 표본 100건으로 매달 맞춰 봅니다. 마지막으로 사람이 매주 무작위 20건을 다시 봅니다. 판정 결과는 에이전트 로그와 분리된 테이블에 저장해 에이전트가 고칠 수 없게 합니다.

신뢰도 기반 처리를 검토하려면 바로 켜지 말고 그림자 모드(shadow mode, 자동 처리하지 않고 기록만 남기는 운영)로 시작합니다. 에이전트가 낸 신뢰도와 사람의 최종 판정을 건마다 함께 저장하고 신뢰도 구간별로 사람과 일치한 비율을 셉니다. 일치율이 기준을 넘는 구간만 자동 처리 후보로 올리고 정보보안과 내부통제가 승인한 뒤 적용합니다. DHL은 이 단계를 정책으로 정하지 않았으므로 기준값은 각 회사가 정할 몫입니다.

감사 증거를 남기려면 에이전트가 거래 데이터를 건드릴 때마다 아래 레코드를 씁니다. 감사인이 묻는 것은 누가 요청했고 에이전트가 무엇을 제안했고 누가 승인했고 실제로 무엇이 바뀌었는지입니다(가상 예시).

{
  "run_id": "sbu-2026-11-05-0012",
  "agent_id": "supplier-bulk-update-v1",
  "requested_by": "ap.master.analyst",
  "erp_role": "AP_SUPPLIER_MASTER_EDITOR",
  "proposed": [{"supplier_number": "100482", "field": "payment_terms", "old_value": "NET45", "new_value": "NET60"}],
  "checks": {"supplier_exists": true, "field_allowed": true, "old_value_match": true},
  "approved_by": "ap.master.lead",
  "approved_at": "2026-11-05T10:14:00",
  "applied": true,
  "post_check": "match"
}

막히는 경우	증상	대응
현재값 불일치	old_value가 ERP 값과 다름	그 행만 멈추고 요청자에게 현재값 회신
허용 밖 필드 요청	은행 계좌 같은 민감 필드 변경 요청	에이전트가 거부, 기존 수작업 통제 절차로 이관
인식률 하락	특정 공급사 양식에서 필드 누락	공급사·양식별 인식률 주간 확인, 해당 양식만 사람 입력
승인 대기 적체	사람 확인이 병목	승인자 2명 지정, 대기 24시간 넘으면 알림
같은 행 중복 반영	같은 변경이 두 번 들어감	run_id와 행 번호로 잠금, 반영 전 현재값 재확인

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

역할	맡는 일
재무 리더(CFO·회계 SVP)	성과 기준을 통제와 정보 품질로 정함, 이사회 보고, 확대 승인
구현 책임자	2~3명 에이전트 그룹 운영, 레지스트리 관리, 독립 채점 설계
기능 컨설턴트(2~3명 그룹)	Agent Studio로 에이전트 구축, 입력 형식과 검증 규칙 작성
공급사 마스터·AP 담당	변경 요청, 변경안 승인, 표본 재검토
정보보안	역할 권한 설계 참여, 사전 승인 처리 같은 예외 정책 검토
내부통제·감사	실행 기록이 감사 증거로 쓸 만한지 점검

준비물. ERP 역할 목록과 역할별 권한, 최근 3개월 공급사 마스터 변경 요청 내역(건수, 필드, 요청 경로), 송장 표본 500건과 담당자의 최종 입력값, 현재 송장 인식 엔진의 필드별 오류 기록, 감사인이 지난해 요구한 통제 증거 목록이 필요합니다.

기간	할 일	산출물
1~2주	2~3명 그룹 지정, 에이전트 레지스트리 작성, 정보보안과 역할 권한 설계	레지스트리, 권한 표
3~4주	공급사 일괄 변경 에이전트 구축과 사람 승인 운영, 송장 지표 기준선 측정	변경 기록, 지표 세 개 기준선
5~6주	독립 채점 가동, 송장 인식률을 공급사·양식별로 분리	채점 기록, 인식률 표
7~8주	감사 증거 점검, 그림자 모드 신뢰도 기록 검토, 확대 판정	판정 보고서, 다음 에이전트 후보

현업에 물을 것.

1. 공급사 정보 변경은 한 달에 몇 건이고 어떤 필드가 가장 자주 바뀌나요?
2. 변경을 지금은 누가 승인하고 승인 근거는 어디에 남나요?
3. 송장 입력에서 담당자가 가장 자주 고치는 항목은 무엇인가요?
4. 직원이 각자 만든 보고서나 매크로 가운데 같은 숫자를 다르게 내는 것이 있나요?
5. 감사인이 지난해 자동화 통제와 관련해 요구한 증거는 무엇이었나요?

진행 판정 기준(예시). 8주 동안 승인된 변경 가운데 재조회 대조에서 어긋난 건이 0건이어야 공급사 에이전트를 다른 필드로 넓힙니다. 독립 채점에서 에이전트 결과와 사람 판정의 일치율이 4주 연속 98% 이상(예시 값)이어야 그림자 모드 결과를 확대 논의에 올립니다. 감사 증거 점검에서 요청자, 승인자, 변경 전후 값 가운데 하나라도 빠진 기록이 나오면 확대를 멈춥니다.

AX 적용 제언. 송장 물량이 많고 ERP 표준화를 이미 한 번 거친 대기업 재무 조직이 첫 후보입니다. 순서는 성과 기준을 통제와 정보 품질로 정하는 일이 먼저입니다. 그다음 2~3명 그룹과 레지스트리를 만들고 공급사 마스터처럼 좁고 반복되는 변경부터 에이전트에 맡깁니다. 송장 인식 엔진을 바꿀 때는 인식률 하나로 보고하지 말고 무수정 통과율과 무인 처리율을 함께 내야 경영진이 자동화 수준을 잘못 읽지 않습니다. 노코드 도구로 현업 개발을 넓히려는 고객사라면, 장부와 마스터 데이터를 건드리는 에이전트만큼은 전담 그룹으로 묶고 개인 생산성 도구는 따로 풀어 주는 이원 운영을 제안할 만합니다.

원문 사례

항목	내용
기사	Deployed(AIM Media House), Amit Raja Naik, 2026.11.3 게재, 오피니언
취재	Oracle AI World(라스베이거스)에서 Graham Walker(SVP, Global Accounting), Sam Game(Implementation Director), Mark Jungmann(VP, Global Head of Finance Transformation Office) 인터뷰
규모	공급사 송장 연 약 170만 건, 재무 에이전트 개발 인원 늘 2~3명
도구	Oracle AI Agent Studio, Oracle Document IO, 기존 Oracle ERP 환경
에이전트	3~4개 구축. 공급사 데이터 일괄 변경(2026년 1분기 운영), 구매 요청(기능 컨설턴트가 한나절에 구축), Ledger Agent(11월 5일 얼리어답터 환경 예정, 성탄절 직전 첫 운영 목표)
검토 중	AP 계정 매핑·세금 코드 에이전트, 채권 회수 흐름
송장 인식	2026년 5~6월께 Document IO로 교체, 인식률 약 60% → 95~96%. 무인 처리율이 아닌 데이터 인식률
통제	Oracle 역할 권한, 에이전트 사용자 제한, 정보보안 참여(사전 승인 송장 처리 논의 포함), 전건 사람 확인, 자기 채점 경계, ERP 데이터 모델 변경 없음
다음 단계	신뢰도 기반 처리는 성과 입증 뒤 검토할 가능성으로만 논의
경영 메시지	통제와 정보 품질을 먼저, 효율은 뒤따르게. 효율을 앞세우면 이사회 기대가 인원 감축으로 좁아질 수 있음
재무 밖	HappyRobot 협력(2025년 11월 발표): 예약 일정 조율, 운전기사 후속 연락, 긴급 창고 조율. 연 수십만 건 이메일, 수백만 분 음성
업계 비교	FedEx는 5월 ServiceNow 협력을 넓혀 구매·지급 흐름에 물류 데이터를 넣음. UPS는 6월 고객 현장에 에이전틱 컨트롤 타워를 배치했다고 밝힘

핵심 개념

Oracle AI Agent Studio

Oracle ERP 안에서 에이전트를 만들고 배포하는 도구입니다. DHL은 이 도구로 재무 에이전트 3~4개를 만들었습니다.

supplier master data

공급사 이름, 사업장, 지급 조건, 은행 정보처럼 송장과 지급에 공통으로 쓰는 기준 정보입니다.

payment terms

송장을 받은 뒤 며칠 안에 대금을 치를지 정한 조건입니다.

requisition

구매 부서에 물품이나 서비스 구매를 요청하는 내부 문서입니다.

early-adopter environment

정식 운영 전에 일부 사용자가 먼저 써 보는 환경입니다.

role-based access

사람이나 에이전트가 할 수 있는 일을 개인이 아니라 역할 단위로 정하는 권한 방식입니다.

내 메모

TODO: 내 생각 추가

원문은 Deployed(AIM Media House)의 「DHL Supply Chain Is Keeping Its AI Agent Team Small on Purpose」(Amit Raja Naik, 2026.11.3 게재)이며 후보 주소의 기사를 그대로 읽었습니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. Document IO가 LLM으로 송장 필드를 추출한다는 설명은 기사가 링크한 Oracle 문서를 기사가 요약한 내용입니다. 핵심 메커니즘의 가상 예시, 기술 디테일, 현업 실행 디테일, 인포그래픽과 표는 실제로 돌릴 때 필요한 것을 새로 작성한 것이며 DHL이나 Oracle이 밝힌 구현이 아닙니다. 전체 내용은 원문에서 볼 수 있습니다.