자동화가 멈추는 곳에 AI를 넣는다: Asurion의 송장 예외 처리 사례

Asurion 사례는 기존 송장 시스템의 예외 처리 구간에 AI를 배치한 접근을 보여줍니다. 우리 기업에 적용하려면 자동 처리율과 함께 수정의 정확성, 보류 기준, 재처리 안전성을 검증해야 합니다.

회계팀이 송장을 읽는 도구를 도입했는데도 직원의 일은 크게 줄지 않는 상황을 떠올려봅시다. 화면에는 정보가 채워져 있지만 담당자는 품목을 다시 찾고, 발주번호를 확인하고, 어느 자료를 기준으로 수정할지 판단합니다. 자료를 읽은 다음에 남는 일이 여전히 많다면 어디부터 바꿔야 할까요.

저는 AI 전환을 논의할 때 이 질문부터 확인하고 싶습니다. 우리 업무는 어느 상태에서 멈추고, 그 뒤에 사람이 무엇을 반복해서 고치는가. 새 도구를 고르는 일과 함께 이 멈춤의 이유를 기록해야 실제로 줄일 수 있는 일을 찾을 수 있습니다.

이 글은 2026년 10월 24일 확인한 공개 자료에 기반합니다. Asurion은 LeanX의 고객사가 아니며, 해당 시스템을 직접 재현한 결과도 아닙니다. 먼저 공개 사례의 사실과 수치 범위를 짧게 정리하고, 이후에는 한국 기업이 시험할 수 있는 LeanX의 독자적인 업무 설계와 가상 실험을 제안합니다.

1. Asurion은 어디에 에이전트를 넣었나

Microsoft가 10월 8일 공개한 고객 사례에 따르면, Asurion은 기존 송장 수집 환경을 유지하며 Copilot Studio 에이전트를 Power Automate 흐름에 넣었습니다. 품목·발주번호 불일치가 주요 문제였습니다. 오류 정보가 에이전트로 전달되면 정해진 지침으로 번호를 대조·보정하고, 후속 흐름이 재처리해 Dynamics 365 Finance로 넘기는 구조입니다.

여기서 제가 가져오는 질문은 모델의 이름보다 자동화가 멈춘 뒤의 판단을 어떻게 정리할 것인가입니다. 우리 업무에서도 오류 메시지만 보면 원인이 비슷해 보일 수 있습니다. 그러나 단순한 표기 차이와 실제로 다른 주문을 가리키는 경우는 처리 방식이 달라야 합니다. 그 차이를 설명할 자료와 담당자가 있어야 실험을 시작할 수 있습니다.

2. 70%라는 숫자에는 대상 범위가 붙어야 한다

같은 공식 사례의 성과 보고를 범위별로 정리하면 다음과 같습니다.

보고 단계	무인 처리율	범위·상태
기준선	20% 미만	공급사 2곳
첫 주	55% 초과	북미·남미 공급사
추가 개선 후	70% 초과	북미·남미
향후 지향	85% 이상	목표이며 MCP 작업은 QA 단계

동일 모집단의 전후 비교는 확인되지 않습니다. 무인 처리율의 상세 산식·측정 기간·오보정률·비용도 제시되지 않았습니다. 독립 감사가 아닌 공급사 발행 고객 사례라는 점을 함께 읽어야 합니다.

따라서 이 수치를 우리 파일럿의 예상 효과로 옮겨 쓰기보다, 우리 팀이 어떤 분모와 품질 기준을 기록할지 정하는 참고점으로 삼는 편이 적절합니다. 숫자를 보고 도구를 고르기 전에 어떤 요청을 처리 대상으로 세었는지, 보류된 건은 어디에 포함했는지, 잘못 통과한 건은 어떻게 발견했는지 질문해야 합니다.

3. 정보 추출, 업무 검증, 원장 반영을 나누어 본다

Dynamics 365의 일반 제품 문서는 추출 이후 매핑·검증·검토·ERP 전달을 별도 상태로 설명합니다. 오류나 경고가 있는 송장은 사람의 검토·수정이 필요합니다. 이 설명은 제품의 일반 동작이며 Asurion의 세부 설정을 확인한 근거는 아닙니다.

우리 팀의 프로세스를 그릴 때도 이 단계를 구분할 수 있습니다. 문서에서 값을 읽었다는 것은 해당 값이 회사의 기준 정보와 맞는다는 뜻이 아닙니다. 번호가 맞아도 금액과 거래처가 맞는지 추가 확인이 필요할 수 있습니다. ERP에 전달된 상태를 지급 완료와 같은 상태로 기록하지 않도록 업무별 완료 정의도 정해야 합니다.

Power Automate의 공식 연결 문서는 표준 하네스 에이전트를 흐름에서 호출하고 응답을 기다린 뒤 다음 단계에 사용할 수 있다고 설명합니다. 실제 구현에서는 사용하는 에이전트 유형과 연결 방식을 확인해야 합니다. 아래 설계는 이 연결 가능성을 참고한 제안이며 Asurion의 실제 코드나 구성을 추정한 것이 아닙니다.

4. 가상 사례: 번호를 고치는 일에도 조건이 필요하다

다음은 LeanX가 만든 가상 입력입니다. 실제 Asurion의 번호, 데이터, 규칙이 아닙니다. 설명을 위해 회사가 승인한 발주서와 품목 대응표가 있다고 가정합니다.

가상 입력	대조 자료	시험할 판단
발주번호 PO-1045 / 서울지점	해당 거래처의 발주서 목록	번호와 부가 설명을 구분할 수 있는가
외부 품목 ABC-01	거래처별 승인 품목 대응표	맥락에 맞는 내부 품목 후보를 찾는가
같은 품목 후보 2개	발주서의 수량·규격	하나를 고를 근거가 부족하면 보류하는가
이미 처리한 송장 재입력	기존 처리 식별자와 상태	중복 실행을 막고 기존 결과를 설명하는가

첫 번째 입력에서 문자열 뒤쪽을 무조건 지우는 규칙부터 만들면 위험합니다. 어떤 거래처는 그 부분이 실제 식별자일 수 있기 때문입니다. 원문을 보존하고 수정 후보와 이유를 분리해 기록해야, 담당자가 바뀐 값을 검토하고 잘못된 규칙을 찾아낼 수 있습니다.

저라면 실험의 결과 형식을 먼저 정하겠습니다. 원래 값, 수정 후보, 참고한 자료와 버전, 선택 이유, 미확인 항목, 처리 상태를 한 묶음으로 받습니다. 후보가 그럴듯하다는 이유만으로 원장을 덮어쓰는 권한은 주지 않습니다. 첫 단계에서는 검토용 결과를 저장하는 데까지만 허용합니다.

근거가 충돌하거나 원장에 없는 번호가 나오면 무엇을 할지도 정해야 합니다. 이때의 좋은 결과는 빈칸을 채우는 대신 어느 정보가 부족하고 누구의 확인이 필요한지 알려주는 것일 수 있습니다. 보류를 실패로만 집계하면 시스템이 불확실한 상황까지 통과시키는 쪽으로 평가가 기울 수 있습니다.

5. 처리율과 함께 잘못된 통과를 측정한다

다음은 실제 실험 결과가 아닌 LeanX의 평가 제안입니다. 합성 송장 30건을 준비해 정상 10건, 명확한 표기 차이 10건, 판단이 모호한 건 5건, 중복 입력 5건으로 나눕니다. 이 수량과 분류가 보편적인 기준이라는 뜻은 아닙니다. 조직이 반복해서 겪는 문제에 맞게 조정해야 합니다.

각 입력에는 담당자가 검토한 기대 결과와 이유를 적습니다. 명확한 표기 차이에서는 어떤 변경까지 허용할지, 모호한 입력에서는 무엇을 물어야 할지, 중복 입력에서는 어느 상태를 반환해야 할지 정합니다. AI의 출력을 보기 전에 기준을 적어야 결과에 맞춰 정답을 바꾸는 일을 줄일 수 있습니다.

평가 항목	확인할 질문
처리 대상	같은 유형·기간·조건의 입력을 비교했는가
통과 결과	기대 결과와 근거가 모두 맞는가
잘못된 통과	보류해야 할 입력을 자동 통과시키지 않았는가
보류 품질	부족한 자료와 확인 담당자를 설명하는가
사람 작업	검토·수정·재작업에 실제로 몇 분을 쓰는가
실행 비용	재시도와 검수까지 포함한 결과당 비용은 얼마인가

처리율이 올라도 중요한 오보정이 생겼다면 확대를 멈추고 원인을 살펴야 합니다. 반대로 시스템이 모호한 건을 정확히 보류해 담당자의 불필요한 탐색을 줄였다면 그 변화도 기록할 가치가 있습니다. 하나의 비율보다 결과의 품질과 사람의 작업을 함께 보려는 이유입니다.

규칙을 수정한 뒤에는 처음 사용하지 않은 별도 입력으로 확인합니다. 이전 사례의 정답만 잘 맞히는지, 새로운 거래처 표기나 충돌에서도 기준이 유지되는지 봅니다. 작은 합성 표본의 통과를 실제 운영의 정확도나 비용 절감으로 확대 해석해서는 안 됩니다.

6. 실패 뒤의 재실행까지 업무로 설계한다

에이전트의 답변이 맞더라도 연결이 끊기거나 다음 시스템의 응답이 늦어질 수 있습니다. 이 경우 처리 여부를 확인하지 않은 채 다시 실행하면 중복 등록을 만들 수 있습니다. 저는 입력 식별자와 수정 버전, 전달 상태, 확인된 결과를 나누어 기록하는 방식부터 제안합니다.

예를 들어 상태를 준비, 검토 대기, 전달 요청, 결과 확인으로 구분합니다. 전달 뒤 결과를 받지 못하면 성공이나 실패로 단정하지 않고 실제 대상 시스템을 조회하는 확인 단계로 보냅니다. 이 상태와 복구 절차는 팀의 시스템에 맞게 설계하고 실제 시험으로 검증해야 합니다.

사람이 검토할 화면에는 원본과 수정 후보, 근거를 함께 둡니다. 담당자가 후보 번호만 보는 상태와 어느 자료의 어느 항목을 대조했는지 보는 상태는 다릅니다. 어떤 결과를 승인했는지 남겨야 오류가 발견됐을 때 영향 범위와 수정 대상을 찾을 수 있습니다.

이 단계에서 필요한 사람의 역할도 구체화합니다. 현업은 예외 유형과 업무상 정답을 설명하고, 구축 담당자는 데이터 연결과 권한·상태 처리를 구현하며, 검토자는 처음 보지 않은 입력과 실패 상황으로 결과를 확인합니다. 서로 같은 용어로 통과·보류·완료를 설명할 수 있는지 먼저 점검합니다.

7. 우리 회사의 첫 AX 과제를 찾는 질문

최근 한 달 동안 직원이 반복해서 고친 업무를 떠올려보세요. 입력 누락, 코드 불일치, 중복 등록, 기준 자료 충돌처럼 원인을 분류합니다. 그중 발생 빈도가 높고 정답을 대조할 자료와 책임자가 있는 한 유형을 골라볼 수 있습니다. 모든 예외를 한 번에 해결하려 하지 않아도 됩니다.

교육에서는 이 예외를 설명하고 시험 기준을 적는 연습을 할 수 있습니다. 파일럿에서는 정해진 입력과 결과 기록으로 실제 검토 부담을 확인합니다. 구축에서는 통과한 범위의 권한과 변경 이력, 모니터링·복구 절차까지 연결합니다. 각 단계의 결과를 다음 단계의 판단 근거로 남기는 접근입니다.

관련해서 AI의 승인 결과당 원가를 보는 방법과 업무 데이터를 판단 자산으로 만드는 방법을 함께 읽을 수 있습니다. LeanX는 기업·기관의 AI 교육, 업무 파일럿과 구축을 연결합니다. 우리 팀이 반복해서 고치는 업무 하나의 자료와 검토 기준을 정리하고 싶다면 업무 체험이나 상담에서 시작할 수 있습니다.

공식 출처와 적용 범위

• Microsoft Customer Stories, Asurion 고객 사례, 2026-10-08 공개. 공급사 발행 고객 사례이며 독립 성과 감사가 아닙니다.
• Microsoft Learn, Invoice capture solution workspace, 2026-10-24 확인. 제품의 일반 처리 상태 설명입니다.
• Microsoft Learn, Call Microsoft Copilot Studio agents from Power Automate, 2026-10-24 확인. 일반적인 연결 방법입니다.

가상 번호·평가 표본·결과 형식·권한·복구 설계는 LeanX의 제안입니다. 실제 Asurion 설정이나 LeanX 고객 성과로 읽지 않도록 구분했습니다.