NOVA: Unilever가 에이전트 5개로 손입력 주문 접수를 15~20분에서 90초로 줄인 방식

주문 자동화의 남은 10%는 고객에게 EDI를 강요해서가 아니라, 고객이 보내는 형식을 그대로 읽고 검증하는 에이전트로 풀 수 있습니다. Unilever는 만드는 에이전트와 검사하는 에이전트를 나누고 예외만 사람에게 넘겨 시범 시장 주문의 95%를 무접촉으로 처리했습니다. 따라 하려면 먼저 손입력 주문의 양과 처리 시간을 재고 검증 규칙을 고객·제품 마스터에 묶어야 합니다.

요약

Unilever는 한 해 약 2,000만 건의 주문을 받습니다. 대부분은 거래처 시스템과 Unilever 시스템 사이를 전자 문서로 오갑니다. 그런데 약 200만 건은 여전히 이메일 본문, PDF, 스프레드시트, 종이 주문서를 찍은 사진으로 들어옵니다. 세계 곳곳의 서비스 허브 직원이 이를 읽어 손으로 입력해 왔습니다. Unilever는 Microsoft와 함께 이 몫을 겨눈 다중 에이전트 시스템 NOVA를 Microsoft Foundry(Microsoft의 AI 앱·에이전트 구축 플랫폼) 위에 만들었습니다. 에이전트 4개가 주문을 읽고 맥락을 해석해 주문 내용을 뽑습니다. 다섯 번째 에이전트는 그 결과를 검증합니다. 통과한 주문은 SAP에 들어갑니다. 정보가 빠졌거나 예외인 건만 사람에게 갑니다. 같은 기술은 환불 클레임 검증에도 씁니다.

11개 시범 시장에서 order-to-cash(주문부터 대금 회수까지의 흐름) 첫 단계가 주문 1건에 15~20분에서 약 90초로 줄었습니다. 주문의 95%가 사람 손을 거치지 않았습니다. 주문 처리는 8배, 환불 클레임 처리는 2배 빨라졌습니다. 신규 고객 온보딩 시간은 90% 줄었습니다. 효과가 난 이유는 두 가지입니다. 하나는 대상을 좁힌 것입니다. 이미 자동화된 주문은 건드리지 않고 사람이 손으로 하던 혼합 형식 주문만 골랐습니다. 다른 하나는 검증을 별도 에이전트로 떼어 내고 예외를 사람에게 넘기는 길을 처음부터 설계한 것입니다. Unilever는 이를 11개 시장에서 50개 이상 시장으로 넓힐 계획이며 가장 큰 시장인 북미 가동을 앞두고 있습니다. 아래에서는 이 구조를 네 가지 작동 원리로 풀고 같은 시스템을 시험할 때 필요한 추출 필드, 검증 규칙, 운영 지표, 8주 일정을 덧붙입니다.

핵심 메커니즘

Long-tail 주문 겨누기: 자동화가 안 된 10%만 대상으로

무엇인가. 전체 주문 가운데 형식이 제각각이라 사람이 입력하던 몫만 떼어 에이전트에게 맡기는 범위 설정입니다.

어떻게 작동하나. 이미 시스템끼리 오가는 주문은 기존 경로를 그대로 둡니다. 이메일, PDF, 스프레드시트, 사진처럼 형식이 정해지지 않은 주문만 NOVA로 보냅니다. 그러면 에이전트가 틀려도 영향 범위가 제한되고 줄어든 수작업 시간이 곧바로 성과 지표가 됩니다.

언제 쓰나. 거래처가 수천~수십만 곳이고 그중 일부가 EDI(전자 문서 교환)를 갖출 형편이 안 될 때 맞습니다. 거래처가 몇 곳뿐이고 모두 EDI를 쓴다면 이 문제가 생기지 않습니다.

원문의 예. Microsoft 기사에 따르면 Unilever의 직거래 고객은 약 30만 곳으로, 슈퍼마켓 체인, 도매상, 유통사, 이커머스 파트너가 섞여 있습니다. 이들이 다시 수백만 개의 작은 가게에 물건을 댑니다.

읽기 에이전트와 검증 에이전트 분리: 만드는 쪽과 검사하는 쪽을 나눈다

무엇인가. 주문 내용을 뽑는 에이전트와 그 결과를 점검하는 에이전트를 따로 두는 구조입니다. NOVA는 읽기·추출에 4개, 검증에 1개를 둡니다.

어떻게 작동하나. 읽기 에이전트는 메일 본문과 첨부를 읽고 맥락을 해석한 뒤 주문 세부 내용을 뽑습니다. 맥락 해석이란 예를 들어 이 메일이 새 주문인지, 지난 주문을 고치는 메일인지 가리는 일입니다. 검증 에이전트는 뽑힌 결과를 다시 보고 빠진 값이나 규칙에 어긋난 값을 찾아냅니다. 한 에이전트가 읽고 스스로 확인하면 같은 착오를 되풀이하기 쉽습니다. 검사 역할을 떼어 내면 오류가 SAP에 들어가기 전에 걸러집니다.

언제 쓰나. 틀린 값이 그대로 다음 시스템에 들어가 배송·청구로 이어지는 업무에 맞습니다. 사람이 결과를 어차피 다 읽는 초안 작성 업무라면 검증 에이전트까지 둘 필요는 적습니다.

원문의 예. Microsoft 기사는 에이전트 4개가 읽고 해석하고 추출하며 1개가 그 일을 점검한다고 설명합니다. 4개가 각각 어떤 형식이나 단계를 맡는지는 밝히지 않았습니다.

예외는 사람에게: 무접촉 95%와 나머지 5%의 설계

무엇인가. 에이전트가 확신할 수 없는 주문을 억지로 처리하지 않고 사람에게 넘기는 경로입니다. 무접촉 비율(no-touch, 사람이 손대지 않고 끝난 비율)을 핵심 지표로 씁니다.

어떻게 작동하나. 검증을 통과한 주문은 바로 SAP에 들어갑니다. 정보가 빠졌거나 예외로 판정된 주문은 담당자 화면에 올라갑니다. 사람이 판단해 처리합니다. Microsoft 기사는 AI가 guardrail(허용 범위를 정한 안전장치) 안에서 여러 단계를 처리하고 사람은 판단이 필요한 지점을 정하고 감독한다고 설명합니다. 직원은 입력 대신 특이한 주문과 고객 응대에 시간을 씁니다.

언제 쓰나. 처리량이 많고 대부분이 정형적이지만 일부는 계약 조건이나 고객 사정을 알아야 판단할 수 있는 업무에 맞습니다.

원문의 예. 11개 시범 시장에서 주문의 95%가 무접촉으로 처리됐습니다. Order-to-Cash 글로벌 디렉터 Deepalok Roy Chowdhury는 직원이 데이터 입력 대신 고객과 이야기하는 데 시간을 써야 한다고 말했습니다.

확대 전 검증 관문: 프로세스 지도와 no-touch 측정

무엇인가. NOVA 같은 도구를 다른 시장으로 넓히기 전에 확대, 수정, 중단 가운데 하나를 고르는 관문입니다.

어떻게 작동하나. 고객 운영 책임자 Graham Sommer가 Consumer Goods Technology(CGT) 인터뷰에서 밝힌 순서는 셋입니다. 먼저 글로벌 프로세스 설계를 택소노미(업무 분류 체계) 수준까지 디지털 문서로 만듭니다. 그러면 어느 시장이 표준에서 벗어났는지, 왜 벗어났는지가 보입니다. 다음으로 시장별 역할과 페르소나를 정하고 파트너와 함께 프로세스를 표준화합니다. 마지막으로 각 도구의 no-touch 비율을 잽니다. 거버넌스는 두 층입니다. NOVA 같은 전사 프로젝트는 엄격한 거버넌스를 따릅니다. 개인 생산성용 작은 에이전트는 보안이 갖춰진 샌드박스에서 비교적 자유롭게 실험합니다.

언제 쓰나. 시장이나 법인마다 같은 업무를 조금씩 다르게 하는 다국적 조직에서, 시범 하나를 수십 개 시장에 복제하려 할 때 맞습니다.

통념과 다른 주장

저자가 든 사례

NOVA 주문 접수: 11개 시범 시장

구분	내용
상황	연 약 2,000만 건 가운데 약 200만 건이 이메일·PDF·스프레드시트·종이 사진으로 들어와 서비스 허브 직원이 손으로 입력
한 일	Microsoft Foundry 위에 읽기·추출 에이전트 4개와 검증 에이전트 1개를 두고 통과 건은 SAP에 입력, 누락·예외는 사람에게 넘김
결과	첫 단계 15~20분 → 약 90초, 95% 무접촉, 주문 처리 8배 빨라짐, 신규 고객 온보딩 90% 단축. 운영 환경에서 수천 건 처리
연결	Long-tail 주문 겨누기, 읽기·검증 분리, 예외는 사람에게

환불 클레임 검증: 같은 기술의 두 번째 쓰임

구분	내용
상황	환불 클레임마다 원 주문을 확인해 고객 귀책인지 가려야 했음
한 일	Microsoft 엔지니어가 Unilever 팀에 합류해 클레임 검증 프로세스를 8주가 안 걸려 만들고 시험함. 주문을 검증해 고객 귀책 여부를 판정
결과	환불 클레임 처리 2배 빨라짐. 판정 규칙의 세부는 원문에서 밝히지 않음
연결	읽기·검증 분리 구조를 다른 order-to-cash 업무에 재사용

확대 경로: 시범에서 50개 이상 시장으로

구분	내용
상황	NOVA는 Unilever가 이 규모로 처음 만든 공급망 다중 에이전트 시스템. 초기 몇 달은 맞는 아키텍처를 찾는 데 씀
한 일	11개 시장에서 시범 운영, 북미 가동 준비, 2026년 10월 21일 Microsoft Frontier Tour London에서 시연
결과	50개 이상 시장으로 확대 계획. 장기 목표는 수요예측, 계획, 물류, order-to-cash를 잇는 연결 운영
연결	확대 전 검증 관문

기술 디테일: 혼합 형식 주문을 에이전트로 받으려면

읽기·추출 에이전트를 만들려면 먼저 출력 형식을 고정합니다. 형식이 무엇이든 결과는 같은 JSON 하나로 나오게 하고 값마다 원문 위치와 확신도를 붙입니다. 이메일 본문은 텍스트로, PDF는 텍스트 층이 있으면 그대로 읽고 스프레드시트는 표 구조를 살려 읽습니다. 종이 사진은 OCR이나 비전 모델로 읽습니다. 원문은 4개 에이전트의 분담을 밝히지 않았으므로, 형식별로 나누거나 “분류, 추출, 매핑, 정리”처럼 단계별로 나누는 두 방식을 모두 시험해 볼 만합니다. 아래 스키마는 가상 예시입니다.

{
  "message_id": "mail-2026-10-30-000123",
  "intent": "new_order",
  "customer": {"sold_to_raw": "○○마트 물류센터", "sold_to_id": "100045", "match_confidence": 0.97},
  "ship_to": {"raw": "경기 ○○시 물류센터 2동", "ship_to_id": "200311"},
  "po_number": "PO-88213",
  "requested_delivery_date": "2026-11-04",
  "lines": [
    {"customer_item": "도브 바디워시 900ml", "sku": "SKU-PLACEHOLDER-01", "qty": 40, "uom": "CS", "unit_price": null, "source_span": "page1:row3", "confidence": 0.93}
  ],
  "missing_fields": ["unit_price"],
  "extraction_model": "모델명·버전 기록"
}

추출 호출은 temperature 0으로 두고 확신도가 낮은 값(예: 0.85 미만)만 두 번째 모델이나 다른 프롬프트로 한 번 더 읽어 일치 여부를 봅니다. 두 결과가 다르면 사람 검토로 보냅니다. 추출 모델이 주문 원문에 없는 값을 채우지 않도록, 원문에 없으면 null로 두라는 규칙을 스키마 설명에 넣습니다.

검증 에이전트를 만들려면 LLM 판단보다 결정적 규칙을 먼저 겁니다. 고객 마스터, 납품처 목록, 고객 품번과 자사 SKU 매핑표, 계약 단가, 최소 주문 수량을 조회 도구로 주고 규칙 위반을 사유 코드로 남기게 합니다. LLM은 규칙으로 판정할 수 없는 경우, 예를 들어 “지난주 주문과 같게”처럼 참조가 들어간 주문을 해석할 때만 씁니다. 원문의 클레임 사례처럼 귀책 판정이 필요하면 원 주문과 배송 기록을 근거로 붙여 사람이 확인하기 쉽게 만듭니다.

SAP에 넣을 때는 사람이 화면에서 입력하던 경로가 아니라 판매 주문 생성 API를 씁니다. S/4HANA라면 판매 주문 OData API, ECC라면 BAPI가 일반적입니다. 같은 메일이 두 번 처리되지 않도록 message_id와 PO 번호로 멱등 키를 만듭니다. 입력 결과로 받은 SAP 주문 번호를 원 메시지에 다시 기록합니다. 시범 초기 몇 주는 바로 확정하지 말고 보류 상태로 넣어 담당자가 승인하게 합니다.

자주 막히는 경우에 대비하려면 아래 다섯 가지를 처음부터 시험 세트에 넣습니다(실행 제안).

막히는 경우	증상	대응
메일 하나에 주문 여러 건	납품처가 다른 주문이 한 건으로 합쳐짐	납품처·PO 번호 기준으로 주문을 쪼개는 단계를 추출 앞에 둠
수정·취소 메일	기존 주문이 새 주문으로 중복 입력	intent 분류에 수정·취소를 넣고 원 PO를 찾으면 사람 확인
손글씨·흐린 사진	수량 숫자 오독	확신도 낮은 줄만 사람에게, 원본 이미지 조각을 함께 표시
처음 보는 고객 품번	SKU 매핑 실패	사람이 고른 매핑을 매핑표에 바로 반영해 다음부터 자동 처리
여러 언어 혼용	품명 해석 오류	시장별 정답 세트를 따로 두고 시장 단위로 정확도 확인

운영하며 보려면 지표 네 개를 매주 봅니다. 무접촉률은 원문이 쓴 지표입니다. 나머지 셋은 그 숫자를 믿을 수 있게 받쳐 주는 지표입니다. 무접촉률이 올라도 SAP 입력 후 수정되는 주문이 늘면 오류가 뒤로 밀린 것이므로, 첫 통과 정확도를 함께 봅니다. 예외 사유는 상위 세 개를 골라 매핑표나 마스터 데이터를 고치는 데 씁니다.

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

역할	담당	하는 일
스폰서	고객 운영 또는 영업관리 본부장	시범 시장·고객군 선정, 8주차 확대 결정
프로세스 오너	Order-to-Cash 리드	예외 기준과 승인 권한 정의, 무접촉 목표 설정
현업 분석가	주문 입력 담당 3~5명	시간을 잡아먹는 반복 작업 제보, 예외 건 처리와 피드백
마스터 데이터	고객·제품 마스터 담당	고객 품번 매핑표, 납품처, 계약 단가 정비
AI 엔지니어	IT 또는 파트너	추출·검증 에이전트, SAP 연동, 로그와 지표
통제	내부통제·감사	자동 입력 권한, 승인 흐름, 감사 추적 기준 확인

시작 전 준비물. 최근 3개월치 손입력 주문 원본(메일·첨부)과 그 주문이 실제로 SAP에 들어간 결과, 형식별 건수, 주문 1건 처리 시간 기준선, 고객 품번 매핑표, 예외로 되돌아간 주문의 사유 목록입니다. 원본과 입력 결과를 짝지은 표본 200~500건은 정답 세트로 씁니다.

기간	할 일	산출물
1~2주	손입력 주문 형식별 건수·처리 시간 계측, 분석가 인터뷰, 정답 세트 구축	기준선, 정답 세트, 반복 작업 목록
3~4주	추출 스키마와 검증 규칙 구현, 정답 세트로 정확도 측정	추출·검증 에이전트 v1, 정확도 리포트
5~6주	사람 입력과 나란히 돌리는 그림자 운영, 예외 사유 수집	불일치 목록, 매핑표 보완
7~8주	검증 통과 건만 보류 상태로 SAP 자동 입력, 지표 측정	무접촉률·처리 시간, 확대 여부 판정

예외 큐는 담당 분석가가 매일 오전·오후 두 번 비웁니다. 처리하면서 고른 사유 코드는 다음 주 규칙 보완 회의에 그대로 올립니다.

현업에 물을 것.

1. 주문 하나를 입력하면서 가장 오래 걸리는 확인 작업은 무엇인가요?
2. 고객이 쓰는 품번이나 품명이 우리 SKU와 다른 경우는 얼마나 자주 있나요?
3. 입력 후에 다시 고치는 주문은 어떤 사유가 가장 많나요?
4. 사람이 꼭 봐야 하는 주문은 어떤 조건인가요(금액, 신규 고객, 프로모션)?

진행 판정 기준(예시). 세 조건을 채우면 다음 시장이나 고객군으로 넓힙니다. 첫째, 정답 세트에서 주문 줄 단위 추출 정확도가 98% 이상입니다. 둘째, 그림자 운영에서 자동 입력 대상의 무접촉률이 70% 이상이고 그중 입력 후 수정 비율이 사람 입력 때보다 높지 않습니다. 셋째, 주문 1건 처리 시간 중앙값이 기준선의 절반 이하입니다.

AX 적용 제언. 국내 소비재·식품·유통 기업이라면 “주문 자동화율”보다 “손입력 주문 건수”를 먼저 세는 데서 시작하는 편이 낫습니다. Unilever도 전체 2,000만 건이 아니라 사람이 만지던 200만 건을 겨눴습니다. 첫 대상은 대리점·중소 유통처럼 EDI가 없는 거래처의 메일 주문이 적당합니다. 예외 기준은 Order-to-Cash 리드가, 매핑표는 마스터 데이터 담당이, 자동 입력 권한은 내부통제가 정하게 나눠 줍니다. 주문에서 구조가 잡히면 Unilever처럼 클레임, 반품, 신규 거래처 등록 같은 이웃 업무에 같은 읽기·검증 구조를 옮겨 씁니다.

원문 사례

항목	내용
1차 출처	Microsoft UK Stories, 2026.10.26 / Consumer Goods Technology(Liz Dominguez), 2026.09.28
등장 인물	Francis Castro(고객 운영 기술 책임자), Deepalok Roy Chowdhury(Order-to-Cash 글로벌 디렉터), Graham Sommer(고객 운영 책임자), Sam Kini(CDTO)
시스템	NOVA, Microsoft Foundry 기반 다중 에이전트, 읽기·추출 4개 + 검증 1개, SAP 입력
규모	연 주문 약 2,000만 건(Microsoft) 또는 약 2,300만 건(CGT), 혼합 형식 약 200만 건, 직거래 고객 약 30만 곳
시범 결과	11개 시장, 첫 단계 15~20분 → 약 90초, 95% 무접촉, 주문 처리 8배, 환불 클레임 2배, 신규 고객 온보딩 90% 단축
구축	클레임 검증 프로세스를 Microsoft 엔지니어와 8주 안에 구축·시험
확대	북미 가동 예정, 50개 이상 시장 계획
조직 맥락(CGT)	고객 운영 인력 6,000명(직원·파트너 절반씩), 에이전트 8개 전 세계 배포, 수요예측 약 60%·Kinaxis 계획 약 90% 무접촉, DigiOps 교육 9개월·약 150시간, 에이전트 제작 교육 약 2,000명
시연	2026.10.21 Microsoft Frontier Tour London

핵심 개념

order-to-cash

주문 접수, 배송, 청구, 수금, 판촉 클레임까지 이어지는 매출 쪽 업무 흐름입니다.

no-touch

사람이 한 번도 손대지 않고 끝까지 처리된 건의 비율. NOVA와 Unilever 계획 업무의 핵심 지표입니다.

EDI

Electronic Data Interchange. 거래처 시스템끼리 주문서·송장을 정해진 전자 형식으로 주고받는 방식입니다.

Microsoft Foundry

Microsoft의 AI 앱·에이전트 구축과 운영 플랫폼. NOVA가 이 위에서 돌아갑니다.

DigiOps

Unilever 고객 운영 조직의 사내 디지털 교육. 9개월 동안 약 150시간이며 직무와 관계없이 참여할 수 있습니다.

멱등 키

같은 요청이 두 번 들어와도 한 번만 처리되게 하는 식별값. 메일 재전송으로 주문이 중복 입력되는 일을 막습니다.

내 메모

TODO: 내 생각 추가

원문은 PYMNTS의 「Unilever Cuts Order Processing to 90 Seconds With AI Agents」입니다. 이번 정리에서는 PYMNTS 본문을 직접 열지 못해, 같은 사건의 1차 출처인 Microsoft UK Stories 「Unilever’s multi-agent creating customer value at global scale」(2026.10.26)과 Consumer Goods Technology 「How Unilever Scales AI, From Predictive Models to Agentic Workflows」(Liz Dominguez, 2026.09.28)를 기준으로 사실을 확인했습니다. 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 사례, 원문 사례 표는 두 기사 내용을 AX Review가 다시 정리했습니다. 수치와 효과는 Unilever와 Microsoft의 설명입니다. 기술·현업 실행 디테일, JSON 스키마, 검증 규칙, 지표, 일정과 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 그 안의 필드명과 숫자는 가상 예시입니다. 원문 전체는 각 매체에서 볼 수 있습니다.