한 고객이 PDF 발주서를 보냈다고 가정해 보겠습니다. 품목, 수량, 단가와 요청 납기일이 적혀 있고, AI는 모든 값을 화면에 채웠습니다. 그런데 주문 담당자는 원본 PDF를 열어 첫 줄부터 다시 대조합니다.

이 글에서 고객이 보내는 문서는 구매 주문서인 발주서, 공급자인 회사가 ERP에 만드는 기록은 판매 주문이라고 부르겠습니다. 두 문서 사이의 타이핑만 사라지고 사람이 매번 처음부터 확인한다면 입력은 자동화됐어도 주문 업무는 거의 그대로입니다.

그렇다고 추출값을 곧바로 판매 주문으로 만들 수도 없습니다. 필요한 것은 전부 자동 등록과 전부 사람 검토 사이의 세 번째 방식입니다. 조건이 명확한 반복 주문은 실제로 자동 처리하고, 경계를 벗어난 필드와 그 이유만 사람에게 보여 줘야 합니다.

120 BOX를 정확히 읽어도 주문은 틀릴 수 있습니다

발주서에 120 BOX가 적혀 있고 AI도 그대로 읽었다고 하겠습니다. ERP는 같은 품목을 EA 단위로 관리하지만 이 고객과 승인한 환산 관계가 없습니다. AI의 읽기는 정확해도 회사가 몇 개를 납품해야 하는지는 아직 확정되지 않았습니다.

시스템이 120을 임의로 고칠 수도 없습니다. 이번에만 들어온 대량 주문일 수 있고, 고객이 단위를 잘못 적었을 수도 있습니다. 이때 필요한 것은 더 높은 OCR 점수가 아니라 고객에게 단위를 확인하거나 승인된 환산 규칙을 선택하는 일입니다.

문서 AI의 confidence는 추출한 단어와 필드 연결이 맞을 가능성에 대한 값입니다. Microsoft는 실제 문서와 사용 시나리오로 임계값을 보정한 뒤 자동 처리와 사람 검토의 경계를 정하라고 안내합니다.[1] 높은 confidence는 120 BOX를 잘 읽었다는 근거가 될 수 있지만, 그 수량과 단가로 판매해도 된다는 허가증은 아닙니다.

이 차이는 AI 때문에 새로 생긴 문제가 아닙니다. OpenPeppol의 구조화 전자 주문 표준은 주문에 대한 응답을 수신, 수락, 거절, 변경 수락으로 나눕니다. 판매자는 수량·납기·대체 품목·가격을 바꿔 응답할 수도 있습니다.[2] 문서를 받은 것과 거래를 받아들인 것은 원래부터 다른 사건입니다.

사람 검토보다 자동 통과 범위를 먼저 정합니다

모든 추출 주문을 승인 대기열로 보내면 안전해 보입니다. 실제로는 담당자가 매번 같은 칸을 대조하고 승인 버튼을 누르는 새 병목이 생깁니다. 저라면 한 거래처의 반복 주문부터 다음 조건을 시스템이 확인하게 하겠습니다.

  • 등록된 고객과 납품처가 하나로 확정됩니다.
  • 고객 품목이 ERP 품목과 승인된 관계로 연결됩니다.
  • 수량 단위와 계약 가격·통화가 유효합니다.
  • 요청 납기를 약속할 수 있습니다.
  • 고객 발주번호가 확인되고 변경·취소 주문이 아닙니다.

과거 주문으로 먼저 시험해 자동 처리 후보 가운데 사후에 정정된 건수와 재출고·반품·청구 수정 비용을 구합니다. 같은 기간의 수동 입력 오류와 비교하고, 파일럿 전에 합의한 최대 오류율과 건당 손실을 모두 밑돈 범위만 엽니다. 고위험 오류는 비율과 별개로 한 건만 발생해도 해당 조건을 다시 닫습니다. 판매 주문을 만들었다고 출고·예약·청구까지 자동으로 이어지는지는 ERP 설정에 따라 다르므로, 자동화가 도달할 정확한 상태도 함께 정해야 합니다.

하나라도 확인되지 않으면 주문 전체가 아니라 해당 조건만 멈춥니다. 고객 미확정, 단위 환산 없음, 계약 가격 불일치처럼 사람이 답할 수 있는 이유가 남아야 합니다. 높은 confidence인데 회사 규칙과 충돌한 필드도 예외이고, 낮은 confidence여도 업무에 영향을 주지 않는 메모의 줄바꿈은 같은 무게로 다룰 필요가 없습니다.

Business Central의 Sales Order Agent는 기본적으로 계획·예약·가용성 계산 등에 영향을 주지 않는 판매 견적을 먼저 만들지만, 설정에 따라 고객에게 견적을 보내지 않고 판매 주문으로 바로 전환할 수도 있습니다.[3] 제품마다 구현은 다르지만, 중간 상태를 반드시 수동 승인소로 두어야 하는 것은 아닙니다. 중간 상태는 AI를 영원히 못 믿어서 만드는 곳이 아니라, 자동 처리 가능한 범위를 증거로 넓히는 경계입니다.

예외 화면이 PDF를 다시 읽게 하면 실패입니다

120 BOX 주문이 멈췄다면 담당자에게 문서 전체를 다시 읽게 할 이유가 없습니다. 화면에는 문제가 된 원문 한 줄, AI가 뽑은 값, ERP의 기준 단위, 환산 규칙이 없다는 이유와 가능한 다음 행동이 함께 보여야 합니다. 담당자는 승인된 환산 규칙을 선택할지, 이번 건만 수량을 확정할지, 고객에게 확인을 요청할지 결정합니다.

원본의 어느 위치에서 값이 나왔는지와 담당자가 무엇을 바꿨는지는 판매 주문에 연결돼야 합니다. 그래야 잘못된 주문이 생겨도 모델 탓이나 담당자 탓으로 끝내지 않고, 어떤 문서와 규칙에서 문제가 시작됐는지 찾을 수 있습니다.

파일럿의 첫 질문도 평균 인식률이 아닙니다. 수동으로 한 건을 입력하는 시간과 예외 한 건을 해결하는 시간을 먼저 비교해야 합니다. 예를 들어 수동 입력에 3분이 걸렸는데 예외 화면에서도 PDF를 다시 읽느라 3분이 든다면, 복사 작업이 화면 이동으로 바뀌었을 뿐입니다. 이 경우에는 거래처나 품목 범위를 더 좁히거나, 멈추는 이유를 더 정확하게 보여 주거나, 프로젝트 자체를 보류하겠습니다.

성공 기준은 자동 승인률을 가장 높이는 것도 아닙니다. 조건 안의 주문은 사람 없이 정확한 상태까지 끝나고, 조건 밖의 주문은 사람이 한 가지 판단만 하면 되는지가 더 중요합니다.

반복 거래처의 종착지는 더 좋은 OCR이 아닙니다

같은 거래처가 같은 양식으로 많은 주문을 보낸다면 PDF를 계속 읽는 구조부터 다시 봐야 합니다. 상대 시스템에 이미 고객 ID·품목 ID·수량·단위가 있는데 이를 PDF로 인쇄한 뒤 AI로 다시 구조화하는 왕복에는 매번 해석 오류와 검토 비용이 붙습니다.

OpenPeppol의 전자 주문 사양은 첨부 파일을 추가 정보에 쓰고 주문서 사본으로 사용하지 말라고 안내합니다.[2] 모든 회사가 Peppol을 써야 한다는 뜻은 아닙니다. EDI, API, 합의한 CSV처럼 양쪽이 같은 식별자와 단위를 주고받는 구조라면 됩니다.

저라면 물량이 많고 거래 조건이 안정적인 고객부터 구조화 주문 채널로 옮기겠습니다. AI는 이런 핵심 거래를 영원히 OCR로 우회하는 주인공보다, 구조화 채널을 쓰기 어려운 거래처와 새로운 양식을 받아 주는 입구에 더 잘 맞습니다.

주문서 자동화의 완료 장면은 AI가 PDF의 모든 칸을 채운 화면이 아닙니다. 명확한 주문은 사람 없이 약속한 ERP 상태까지 들어가고, 애매한 주문은 PDF 전체가 아니라 멈춘 이유 하나만 들고 담당자에게 도착하는 장면입니다. 구조화 채널로 옮기기 어려운 거래에서 사람이 계속 처음부터 다시 읽고 있다면, 다음에 개선할 것은 모델보다 자동 통과 범위와 예외 화면입니다.

출처

  • AI
  • ERP
  • 주문서자동화
  • 문서AI
  • 제조업자동화