FAX로 도착하는 주문서를 AI Builder로 읽기 ── 수기 입력을 줄이는 현실적인 설계와 한계

「수주의 40%는 아직 FAX입니다. 복합기에서 나온 주문서를 보면서 판매 관리 시스템에 한 건씩 치고 있습니다」. 제조업이나 도매업 상담에서 정말 자주 듣는 이야기입니다. 이어서 나오는 것이 「거래처에 웹 발주를 부탁할 수 있는 관계가 아니다」, 「큰 거래처일수록 상대 발주 시스템이 FAX 송신을 전제로 되어 있어 손댈 수 없다」는 사정입니다.

FAX 수주를 개선하는 길은 크게 두 갈래입니다. 하나는 웹 수주나 CSV 가져오기로 옮겨 「FAX를 그만두는」 길입니다. 다른 하나는 FAX를 받은 채로 읽기와 입력을 자동화해 「그만둘 수 없는 FAX와 함께하는」 길입니다. 전자는 별도 글 「FAX 수주를 웹으로 옮기려면 ── 이중 운영 기간의 설계와 단계 이전의 실무」에서 다루었습니다. 이 글은 후자, 즉 FAX를 PDF 데이터로 받아 AI Builder 문서 처리로 읽고, 사람 확인을 거친 뒤 수주 대장과 기간계로 넘기는 설계 이야기입니다.

미리 말하면, 이 구조는 「전자동」이 되지 않으며, 되어서도 안 됩니다. 그래도 매일 1~2시간짜리 입력 작업을 「읽기 결과만 확인하면 되는」 수십 분으로 줄일 수 있다면, 투자 대비가 맞는 회사는 많을 것입니다. 어디까지 자동화되고 어디부터가 한계인지를, Microsoft Learn에서 확인할 수 있는 사양에 근거해 정리합니다.

1. 먼저 결론

• FAX 읽기 자동화의 전제는 FAX를 종이가 아니라 데이터(PDF)로 받는 것입니다. 복합기의 FAX 전달 기능이나 클라우드 FAX 서비스로 수신 FAX를 파일로 만들고, SharePoint에 모으는 일부터 시작합니다.
• AI Builder의 문서 처리 커스텀 모델은 주문서처럼 독자 레이아웃인 서식에서 항목·표를 추출할 수 있습니다. 학습은 「같은 레이아웃의 서식 = 컬렉션」 단위이며, 컬렉션당 최소 5건(최대 20건)의 샘플이 필요합니다.¹²
• 학습 유형(고정 템플릿 문서·일반 문서) 모두 일본어를 지원하고, FAQ에는 손글씨 추출에도 대응한다고 명시되어 있습니다. 다만 FAX 품질의 실제 서식에서 어디까지 읽히는지는 반드시 자사 샘플로 검증해야 합니다.³²
• 흐름의 핵심은 신뢰도 점수로 가르는 것입니다. 추출 결과에는 필드마다 0~1 점수가 붙으므로, 고신뢰는 대장에 자동 기록하고 저신뢰는 사람 확인으로 보내는 분기를 넣습니다. 전 건을 사람이 본다는 전제는 버리지 않고, 「확인이 편해지는」 설계로 만듭니다.⁴
• 모든 거래처 서식을 읽으려 하지 마십시오. 레이아웃마다 컬렉션을 나누는 구조상, 건수 상위 거래처의 정형 주문서만으로도 효과가 납니다. 저품질 서식은 샘플을 15~20건으로 늘리라는 대처가 공식 안내되어 있습니다.²⁵
• AI Builder는 소비형 크레딧이 따로 필요합니다. 문서 처리는 페이지 단위로 소비하고, 커스텀 모델은 미리 빌드된 모델보다 레이트가 높은 편입니다. 2025년 10월 발표된 AI Builder 크레딧의 단계적 종료로, 체계는 Copilot 크레딧으로 이전 중입니다.⁶⁷
• 읽기는 만능이 아닙니다. 건수·거래처 수·서식의 정형 정도에 따라서는 웹 수주 이전이나 EDI가 본류입니다(8장의 판단표).

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 28건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 「그만두기」와 「읽기」 ── 두 길을 섞지 않기

FAX 수주 상담을 받을 때 맨 먼저 확인하는 것은 「FAX를 그만둘 수 있는 상대인가」입니다.

웹 수주로의 이전은 거래처가 행동을 바꾸게 하는 일입니다. 단계 이전 글에서 썼듯이, 건수가 많고 시스템에 맞출 수 있는 거래처부터 차례로 옮기고, 효과가 큰 곳에서 수기 입력을 줄여 갑니다. 한편 도저히 움직일 수 없는 거래처는 남습니다. 상대 발주 업무가 FAX 전제로 돌아가고, 담당자 고령화로 웹 입력을 부탁할 수 없고, 애초에 자사가 「부탁하는 쪽」의 힘 관계에 있지 않다 ── 이런 상대의 FAX는 수년 단위로 남는다고 보는 편이 현실적입니다.

그래서 나오는 것이 「읽기」 길입니다. 요점은 이 두 길이 배타적이지 않다는 점입니다.

「읽기」 길의 가장 큰 이점은 거래처에 어떤 변화도 요구하지 않는다는 점입니다. 단계 이전의 이중 운영 기간에 FAX 채널 처리 비용을 낮추는 수단으로도 씁니다. 한계도 분명합니다. 읽기 정확도는 100%가 되지 않으므로 확인 공정은 남습니다. 거래처마다 레이아웃이 다른 서식을 전부 읽으려 하면 모델 유지에 지칩니다. 그래서 옮길 수 있는 상대는 옮기고, 남는 상대의 FAX를 읽는 조합으로 생각합니다.

참고로, 메일 첨부 PDF로 오는 주문서 처리는 「메일로 도착하는 주문서·청구서 PDF를 Power Automate로 자동 처리하기 ── 저장·분류·알림·읽기 설계」에서 다루었습니다. FAX를 메일 전달로 받는 경우, 수신 이후 설계는 이 글과 메일 글이 만나는 지점이 됩니다.

3. 전제: FAX를 「데이터」로 받기 ── 종이인 채로는 시작되지 않는다

AI Builder에 넘길 수 있는 것은 파일입니다. 복합기가 인쇄한 종이를 다시 스캔하는 운영은 수고가 입력에서 스캔으로 바뀔 뿐 자동화가 아닙니다. 맨 먼저 해야 할 일은 수신 FAX가 사람 손을 거치지 않고 파일로 저장되는 경로를 만드는 것입니다. 현실적인 선택지는 두 가지입니다.

• 복합기의 FAX 전달 기능. 업무용 복합기 상당수는 수신 FAX를 인쇄하지 않고 지정 폴더에 저장(스캔 to 폴더)하거나, 메일에 첨부해 전달할 수 있습니다. 설정은 기종 매뉴얼과 유지보수 업체에 확인합니다.
• 클라우드 FAX 서비스. FAX 번호 자체를 클라우드 서비스로 옮기고, 수신 FAX를 PDF로 메일이나 API로 받는 형태입니다. 복합기를 교체하지 않고 데이터화할 수 있으며, 번호 이동 가능 여부와 요금 체계는 서비스마다 확인이 필요합니다.

어느 경로든, 도착지는 SharePoint 문서 라이브러리로 맞추기를 권합니다. SharePoint 커넥터에는 「파일이 만들어질 때(속성만)」 트리거와 「파일 콘텐츠 가져오기」 작업이 있어, 저장 그 자체를 이후 읽기 흐름의 시작점으로 삼을 수 있기 때문입니다.⁸ 메일 전달로 받는 경우에는 공유 사서함으로 받아 첨부 PDF를 SharePoint에 저장하는 흐름을 앞단에 둡니다(이 설계는 메일 첨부 글의 3~4장 그대로입니다).

파일 형식에서 한 가지 주의가 있습니다. 복합기 전달 설정에 따라 FAX가 TIFF로 저장되는 경우가 있습니다. AI Builder 문서 처리는 모델 학습에는 PDF·JPG·PNG만 쓸 수 있지만, 학습이 끝난 모델을 클라우드 흐름에서 실행할 때는 TIFF도 처리할 수 있습니다.³ 그래도 학습 샘플 준비를 생각하면, 전달 설정에서 PDF 출력을 골라 두는 편이 솔직합니다. 더불어 처리할 수 있는 파일은 최대 20 MB, 이미지라면 50×50~10,000×10,000픽셀이라는 제한도 알아 둡니다.³

4. AI Builder 문서 처리로 무엇을 할 수 있는가

커스텀 모델 학습의 구조

AI Builder 문서 처리는 샘플 서식으로 「이 서식의 어디에 무엇이 적혀 있는지」를 학습시키는 커스텀 AI 모델입니다. 모델을 만들 때는 먼저 문서 유형을 고릅니다.¹

거래처의 정형 주문서라면 기본적으로 고정 템플릿 문서입니다. 이어서 추출할 정보를 정의합니다. 필드(주문 번호, 주문일, 거래처명, 납품처 등), 표(품목·수량·단가의 명세 행), 확인란을 지정할 수 있습니다.¹

학습 단위가 되는 것이 컬렉션입니다. 컬렉션은 「같은 레이아웃 서식의 그룹」이며, 거래처 A의 주문서와 B사의 주문서처럼 레이아웃이 다른 서식은 다른 컬렉션으로 나눕니다. 각 컬렉션에는 최소 5건의 샘플 문서를 올리고, 필드나 표 위치에 태그를 붙여 학습시킵니다. 컬렉션당 샘플은 최대 20건, 모델당 최대 200개 컬렉션까지 만들 수 있습니다.¹³ 고품질 문서라면 5건으로 충분한 경우가 많은 반면, 저품질 스캔에서는 15~20건을 쓰라고 공식 FAQ에서 권장합니다.²

모델 작성 절차

학습과 테스트에는 크레딧이 소비되지 않으므로⁹, 일단 만들어 보는 편이 빠릅니다. 화면 경로는 다음과 같습니다(메뉴 이름은 Microsoft Learn 표기에 맞춥니다).¹

1. Power Apps(make.powerapps.com) 또는 Power Automate(make.powerautomate.com)에 로그인합니다.
2. 왼쪽 창의 … More(기타) > AI hub를 엽니다. 자주 쓰면 고정해 두면 편합니다.
3. Discover an AI capability 안에서 AI models를 고릅니다.
4. Extract custom information from documents(문서에서 사용자 지정 정보 추출)를 고릅니다.
5. Create custom model을 고르면 마법사가 시작됩니다.
6. Choose document type에서 문서 유형을 고릅니다. 거래처의 정형 주문서라면 Fixed template documents(고정 템플릿 문서)입니다.
7. Choose information to extract에서 +Add로 추출할 항목을 정의합니다. 텍스트·숫자·날짜·확인란·표를 추가할 수 있고, 숫자는 소수점 기호(. 또는 ,), 날짜는 연월일 순서, 표는 열 구성을 여기서 지정합니다.
8. 레이아웃마다 컬렉션을 만들고, 각각에 5건 이상의 샘플(JPG·PNG·PDF)을 올립니다. 거래처 두 곳의 양식이 다르면 컬렉션도 두 개 만듭니다.
9. 올린 각 샘플 위에서, 7단계에서 정의한 항목에 해당하는 위치를 태그합니다.
10. Train으로 학습시키고 Quick test로 시험합니다. 기대한 대로 읽히면 게시(공개)해 흐름에서 호출할 수 있는 상태로 만듭니다.

자사 샘플이 아직 없을 때 조작만 시험하고 싶다면, Microsoft가 준비한 샘플 데이터로 모델을 만들 수도 있습니다.¹

참고로 6단계에서 고른 문서 유형과는 별개로, 모델은 내부 Document Intelligence 버전(v4.0 / v3.1)을 갖습니다. 마지막으로 편집한 시점에 정해지며, Settings > Published model version에서 확인할 수 있습니다. 표와 셀의 신뢰도 점수를 얻는 것은 v4.0이며, 오래된 모델은 편집·재학습·재게시하면 v4.0으로 올라갑니다.¹

일본어와 손글씨 지원

일본어 서식을 다룰 때 확인할 점은 Microsoft Learn에서 다음과 같이 확인할 수 있습니다.

• 고정 템플릿 문서·일반 문서 어느 학습 유형이든 일본어가 지원 언어에 포함됩니다.³
• 공식 FAQ에 「문서 처리는 인쇄 텍스트와 손글씨 텍스트를 추출할 수 있다」고 명시되어 있습니다.²

다만 여기는 솔직히 적습니다. 「지원한다」와 「자사 FAX가 실무 정확도로 읽힌다」 사이에는 거리가 있습니다. FAX는 해상도가 낮고, 흐려짐·뭉개짐·기울어짐이 일상적으로 일어납니다. 손글씨 수량 정정이나 휘갈긴 비고가 읽힐지는 서식이 어떻게 적혀 있는지에 달렸습니다. 문서 처리 모델의 학습과 테스트는 무료이므로⁹, 도입을 판단하기 전에 실제로 수신한 FAX PDF 그 자체를 샘플로 학습·테스트하고 자사 서식에서의 정확도를 보는 단계를 반드시 넣으십시오. 깨끗한 원본 PDF로 학습하고 FAX로 운영하면, 테스트와 운영의 화질 차이가 너무 커서 정확도가 나오지 않는 실패로 흐르기 쉽습니다.

미리 빌드된 모델과의 차이

AI Builder에는 학습이 필요 없는 미리 빌드된 모델도 있습니다. 대표적인 것이 청구서 처리 모델로, 청구서 번호·청구일·지급액 같은 공통 필드를 학습 없이 추출할 수 있고, 지원 언어에 일본어가 포함됩니다.¹⁰ 청구서 처리라면 먼저 이것을 시험하는 편이 빠릅니다.

반면 주문서용 미리 빌드된 모델은 없습니다. 주문서·발주서·납품서처럼 레이아웃이 회사마다 다른 서식은 공식 FAQ에서도 고정 템플릿 문서 커스텀 모델의 전형 예로 들어 있으며², 이 글의 주제인 FAX 주문서는 커스텀 모델 영역입니다.

5. 흐름 전체 설계 ── 사람 확인을 넣기

전체 모습은 다음과 같습니다. 핵심은 한가운데의 「사람 확인」이며, 여기를 뺀 전자동 구성은 뒤에서 말할 이유로 권하지 않습니다.

flowchart TD
    Fax[거래처에서 FAX 수신] --> Digitize[복합기의 FAX 전달 / 클라우드 FAX 서비스<br/>PDF로 폴더·메일로]
    Digitize --> Save[SharePoint 문서 라이브러리에 저장<br/>수신 일시를 포함한 고유 파일 이름]
    Save --> Trigger[클라우드 흐름 시작<br/>파일이 만들어질 때]
    Trigger --> AIB[AI Builder: 문서 처리<br/>주문 번호·거래처·납기·명세 추출]
    AIB --> Score{신뢰도 점수 판정<br/>예: 주요 필드가 모두 0.9 이상?}
    Score -- 고신뢰 --> Ledger[수주 대장 목록에 기록<br/>상태: 자동 읽기 완료·미확정]
    Score -- 저신뢰 --> Review[담당자에게 확인 요청<br/>Teams 알림 + 원본 PDF 링크]
    Review --> Fix[원본과 대조해 수정한 뒤 확정<br/>상태: 확인 완료]
    Ledger --> Batch[목록을 모아 확인하고 확정<br/>상태: 확인 완료]
    Fix --> Entry
    Batch --> Entry[기간계로 입력 ── 상태 「확인 완료」 행만<br/>CSV 가져오기 / Power Automate for desktop]

읽기 단계

흐름에서는 「문서 처리(Process documents)」 작업에 학습·게시가 끝난 모델과 SharePoint에서 가져온 파일 콘텐츠를 넘깁니다(이 작업은 2025년 5월에 「문서에서 정보 추출」에서 이름이 바뀌었습니다). 출력에는 정의한 각 필드의 값({필드} value)과 신뢰도 점수({필드} confidence score), 표 셀마다의 값과 점수가 포함됩니다. 여러 페이지 문서에서는 처리할 페이지 범위를 지정해 소비를 줄일 수도 있습니다.⁴

구현 시 주의로, 추출 값은 모두 문자열로 돌아옵니다. 수량이나 금액을 대장의 숫자 열에 넣으려면 int/float 식으로 변환하고, 통화 기호나 공백은 replace 식으로 제거합니다. 날짜도 formatDateTime 식으로 맞춥니다.⁴ FAX 번호나 주문 번호의 전각·반각 흔들림도 여기서 정규화해 두면 이후 대조가 수월해집니다.

확인 단계 ── 여기가 핵심

읽기 결과 확인은 다음 두 형태가 짜기 쉽습니다.

1. 대장 목록의 상태 열로 확인을 돌리기. 수주 대장을 SharePoint 목록으로 두고, 읽기 결과를 「확인 필요」 상태로 등록한 뒤, 담당자가 목록에서 원본 PDF(첨부 또는 링크)와 비교해 수정하고 상태를 「확인 완료」로 바꿉니다. 확인 완료로의 변경을 트리거로 후속 처리를 돌립니다. 대장을 Excel에서 SharePoint 목록으로 옮기는 설계는 「Excel 대장을 SharePoint 목록으로 바꾸기」에서 다루고 있습니다.
2. Teams 승인으로 확인을 돌리기. 승인(Approvals) 커넥터의 「시작 후 승인 대기」 작업을 사용자 지정 응답과 함께 써서, 「이대로 등록」「수정 필요」 같은 선택지로 담당자가 판단하게 하는 형태입니다. 승인 만드는 법과 응답 처리는 「Power Automate로 승인 흐름 만들기 ── 종이와 메일의 결재·신청을 전자화하기」에서 자세히 썼습니다.¹¹

어느 쪽이든 알림은 Teams 채널에 모으고, 원본 FAX PDF 링크를 반드시 붙이십시오.¹² 확인 작업의 실체는 「읽기 결과와 원본의 대조」이므로, 원본을 여는 데 품이 드는 설계면 확인이 형식만 남습니다.

대장에서 기간계로

확인이 끝난 데이터를 기간계에 넣는 방법은 기간계 쪽 입구에 달렸습니다. CSV 가져오기 기능이 있으면 확인 완료 데이터를 CSV로 만들어 가져오는 편이 견실합니다. 가져오기 없이 화면 입력만 있는 경우에는 Power Automate for desktop으로 화면 조작을 자동 입력하는 선택지가 됩니다. 이 설계는 「Power Automate for desktop으로 기간계 입력을 자동화하기」에서 다루고 있습니다. 흐름 전체의 오류 처리(읽기 실패 시 알림, 다시 실행)는 「Power Automate의 오류 처리와 재시도 설계」의 생각이 그대로 쓰입니다.

6. 정확도와 함께하기 ── 전부 읽히지 않아도 효과는 난다

신뢰도 점수로 가르기

「읽기는 틀릴 수 있다」를 전제로 두면, 설계의 중심은 신뢰도 점수 쓰임새가 됩니다. 점수는 0~1이며, 1에 가까울수록 추출 값이 맞을 확실성이 높음을 나타냅니다.⁴ 실무에서는 예를 들어 이렇게 가릅니다.

• 주문 번호·거래처·납기·명세의 주요 필드가 모두 임계값(예: 0.9) 이상 → 「자동 읽기 완료」로 대장에 넣습니다. 담당자는 목록을 모아 확인하고 확정 조작만으로 끝냅니다
• 하나라도 임계값 미만 → 「확인 필요」로 담당자에게 보냅니다. 점수가 낮은 필드를 알림에 밝히고, 원본과 대조해 수정하게 합니다

구현은 「조건」 작업 하나로 충분합니다. 「문서 처리」 뒤에 조건을 두고, 동적 콘텐츠 목록에서 {필드 이름} confidence score를 골라 임계값과 비교합니다. 주요 필드를 묶어 판정하려면 조건을 고급 모드(식)로 바꿔 and로 잇습니다. 아래 <...>는 Microsoft Learn 예시를 따라 「동적 콘텐츠에서 삽입하는 자리」를 나타냅니다.⁴

and(
  greaterOrEquals(<주문 번호 confidence score>, 0.9),
  greaterOrEquals(<거래처명 confidence score>, 0.9),
  greaterOrEquals(<납기 confidence score>, 0.9)
)

식을 쓸 때 포인트는 두 가지입니다.

• 값과 점수는 형이 다릅니다. {필드} value는 문자열이지만 {필드} confidence score는 0~1의 float로 돌아오므로, 점수는 그대로 숫자 비교할 수 있습니다. 금액이나 수량 자체를 조건에 쓸 때만 float()나 int()로 변환합니다.⁴
• 명세 표의 셀에도 점수가 붙습니다({표 이름}{열 이름} confidence score). 다만 표 열을 참조한 시점에 그 작업은 자동으로 「Apply to each」 안으로 들어갑니다. 명세 전체를 묶어 판정하려면 변수(예: minScore를 1.0으로 초기화)를 준비하고, 루프 안에서 각 행 점수와 비교해 최솟값을 남긴 뒤, 루프 밖에서 한 번만 임계값과 비교하는 형태가 다루기 쉽습니다.⁴ 참고로 표와 셀의 신뢰도 점수를 얻는 것은 Document Intelligence v4.0 모델입니다.¹

조건의 「예」 쪽에서 수주 대장에 「자동 읽기 완료」로 등록하고, 「아니요」 쪽에서 Teams 알림과 확인 필요 등록으로 가르면, 이 장의 분류가 그대로 흐름이 됩니다.

고신뢰 쪽도 확인 자체를 빼는 것은 아니라는 점에 주의하십시오. 점수는 「맞을 확실성이 높다」는 표시일 뿐, 옳음의 보증이 아닙니다. 고신뢰여도 오독은 일어나므로, 기간계로 넘기는 것은 사람이 확정 조작을 한 「확인 완료」 행만이라는 관문은 점수와 관계없이 유지합니다. 점수로 바꿔도 되는 것은 확인의 무게(모아 확정할지, 한 건씩 수정할지)이지, 확인의 유무가 아닙니다.

임계값은 처음부터 고정하지 말고, 운영 시작 후 「자동으로 넘겼는데 실은 틀린 건수」를 보면서 조정합니다. 중요한 것은 실수의 비용이 비대칭이라는 점입니다. 확인 필요로 너무 많이 기울여도 확인 품이 조금 늘 뿐이지만, 오독을 자동으로 통과시키면 오출하로 이어집니다. 망설이면 임계값은 높게 둡니다.

FAX 화질이라는 숙명

문서 처리 요건에는 「종이 스캔은 고품질 이미지일 것」, 「문자가 임베드된 PDF(텍스트 PDF)가 깨짐이나 위치 어긋남이 없어 바람직하다」고 적혀 있습니다.³⁵ FAX는 이 이상의 반대편에 있습니다. 그래도 취할 수 있는 수단은 있습니다.

• 학습 샘플을 실제 FAX로 쓰기. 앞에서 말했듯, 운영 때와 같은 화질로 학습시키는 것이 첫째입니다. 저품질 이미지에서는 샘플을 10~15건 이상으로 늘리라고 공식 안내되어 있습니다.⁵
• 송신 측 품질을 개선하도록 요청하기. 상위 거래처에는 「고화질(파인) 모드로 보내 달라」고 부탁할 수 있는 경우가 있습니다. 거래처에 변화를 요구하지 않는 길이기는 해도, 송신 버튼 옆 설정 하나라면 부탁하기 쉬운 편입니다.
• 안 읽히는 서식을 억지로 읽지 않기. 흐려짐이 심하거나 손글씨가 대부분인 서식은 확인 필요가 상시화됩니다. 그 거래처는 읽기 대상에서 빼고 지금까지처럼 수기 입력하는 판단도 필요합니다.

레이아웃이 거래처마다 다른 문제

주문서 레이아웃은 거래처 수만큼 있습니다. 문서 처리는 이것을 컬렉션으로 흡수하는 설계이며, 레이아웃마다 컬렉션을 나눠 하나의 모델에 모을 수 있습니다(최대 200).³ 다만 컬렉션을 늘릴수록 샘플 수집과 태그 작업, 정확도 검증, 레이아웃 변경 추종이라는 유지가 늘어납니다. 거래처가 주문서 양식을 바꾸면 그 컬렉션은 다시 학습해야 합니다.

그래서 시작은 「전부 읽기」가 아니라 「건수 상위 거래처의 정형 주문서만 읽기」입니다. FAX 수주가 월 600건이고 상위 3사가 350건을 차지한다면, 컬렉션 3개(샘플 각 5~20건) 모델로 입력 작업의 약 60%가 대상이 됩니다. 나머지는 지금까지처럼 수기 입력이면 됩니다. 이는 단계 이전 글에서 쓴 「효과가 큰 곳부터 차례로 움직인다」 원칙의 읽기 판이며, 웹 이전의 거래처 분류(A/B/C)를 그대로 쓸 수 있습니다. 파일럿으로 형을 만들고 효과를 잰 뒤 컬렉션을 더하는 진행이 모델 유지 소모를 막습니다.

세부 제약도 확인해 둡니다. 페이지를 넘기는 필드나, 페이지를 넘어 이어지는 명세 행은 현재 지원되지 않습니다.³ 여러 페이지 주문서가 많은 거래처에서는 명세 설계에 주의가 필요합니다.

7. 라이선스와 비용 규모 ── 크레딧이라는 소비 모델

AI Builder 작업은 Power Automate 라이선스와 별도로, 실행할 때마다 소비형 용량을 씁니다. 여기를 모르고 만들기 시작하면 운영에서 NoCapacity 계열 오류에 부딪힙니다.⁹

구조는 이렇습니다. 문서 처리는 처리한 페이지 수에 따라 크레딧을 소비합니다(추출 대상 데이터가 없는 페이지에서도 소비합니다).² 소비 레이트는 기능마다 다르며, 공식 레이트표에서는 커스텀 모델 문서 처리가 페이지당 100 AI Builder 크레딧, 미리 빌드된 청구서 처리 등은 페이지당 32크레딧, Copilot 크레딧 체계에서는 콘텐츠 처리로 페이지당 8 Copilot 크레딧으로 정의되어 있습니다.⁶

크레딧을 얻는 경로는 이전에는 다음 두 가지였습니다.⁹

• AI Builder 용량 애드온: 애드온 1개당 100만 크레딧
• Premium 라이선스에 포함된 시드 크레딧: Power Automate Premium 라이선스 1개당 5,000크레딧

크레딧은 테넌트 단위로 모이고, 관리자가 환경에 할당해 씁니다. 어림하면 Premium에 포함된 5,000크레딧은 커스텀 모델 문서 처리 50페이지분입니다. 한 장짜리 주문서가 월 50건까지면 포함분으로 들어가고, 월 600건이면 애드온이나 Copilot 크레딧 구매가 필요하다는 규모감입니다.

소비량 어림

금액은 시점과 계약에 따라 달라지므로 이 글에서는 다루지 않습니다. 다만 소비하는 크레딧 양은 공개 레이트에서 스스로 계산할 수 있습니다. 커스텀 모델 문서 처리는 페이지당 100 AI Builder 크레딧, Copilot 크레딧 체계에서는 콘텐츠 처리로 페이지당 8 Copilot 크레딧입니다.⁶ 월간 읽기 페이지 수를 곱하기만 하면 됩니다.

계산 생각은 Microsoft FAQ 예(영수증 처리 32,000건 × 32크레딧 = 1,024,000크레딧 → 애드온 1개 + Premium 5개로 충당)와 같습니다.⁹ 실제 지불액은 이 소비량에 자사 계약 단가(애드온이나 Copilot 크레딧 가격, 환율이나 할인 적용)를 곱해 냅니다. Power Platform 라이선스 가이드(PDF)에 레이트 카드가 있으므로, 견적은 그곳과 최신 가격 정보로 확인하십시오.⁹

주의점으로, 소비량은 월 단위로 재설정되며, 남은 양은 다음 달로 이월되지 않습니다.⁹ 성수기 봉우리에 맞춰 여유 있게 확보하면 비수기 분은 낭비입니다. 페이지 범위 지정으로 불필요한 읽기를 줄이고, 읽기 대상을 건수 상위 거래처로 좁히는 설계상의 절약이 곧 비용에 닿습니다.

크레딧이 떨어졌을 때의 대처

NoCapacity, EntitlementNotAvailable, QuotaExceeded, No capacity was found, Credit usage exceeds allocation 같은 오류로 흐름이 실패하면 환경에 대한 크레딧 할당을 확인합니다. 흐름 디자이너에는 「All AI Builder credits in this environment have been consumed(이 환경의 AI Builder 크레딧을 모두 소비했습니다)」라는 복구 패널이 나옵니다.⁹

확인과 대처 경로는 다음과 같습니다.⁹

1. Power Platform 관리 센터에서 Licensing(라이선스) > Capacity add-ons(용량 애드온) > Summary 탭을 열고, 구매·할당·소비된 크레딧 수를 확인합니다.
2. 환경별 소비량은 AI Builder 소비 보고서로 확인합니다. 당월 분을 합하면 그 환경의 월간 소비량이 됩니다.
3. 부족하면 같은 화면의 Add-ons 탭에서 Assign to an environment로 환경에 다시 할당합니다(테넌트 전체 또는 다른 환경의 잉여를 돌립니다).
4. 그래도 부족하면 용량 애드온 추가 구매(기존 고객만, 2026년 11월 1일까지) 또는 Copilot 크레딧 구매·종량 과금 허용을 검토합니다.

여기서 알아 둘 사양이 하나 있습니다. 환경에 크레딧을 할당하면, 그 환경은 테넌트의 미할당 크레딧을 자동으로는 쓰지 않습니다.⁹ 「테넌트 전체에는 아직 남았는데 이 환경만 멈췄다」는 사고는, 이 사양을 모르면 원인에 닿지 않습니다. 반대로 할당을 하지 않은 환경은 테넌트의 미할당 분을 씁니다. 운영을 시작하기 전에, 읽기 흐름을 둘 환경이 어느 상태인지 관리자와 확인해 두십시오.

다만 이 체계는 지금 한창 이행기입니다. 2025년 10월 Microsoft는 AI Builder 크레딧의 단계적 종료를 발표했습니다. 2025년 11월 1일 이후 신규 고객은 AI Builder 용량 애드온을 살 수 없고, 2026년 11월 1일에는 애드온 갱신 종료와 Premium 라이선스 포함 시드 크레딧 폐지가 예정되어 있습니다. AI Builder 기능 자체는 없어지지 않으며, Copilot 크레딧으로 계속 쓸 수 있습니다. 이전 기간 중에는 AI Builder 크레딧을 먼저 소비하고, 떨어지면 Copilot 크레딧을 소비하며, 둘 다 없으면 실행이 차단되는 우선순위입니다.⁷

요컨대 「읽기에는 실행량에 따른 추가 비용이 든다. 그 통화가 바뀌는 중」입니다. 이 글에서는 구체 금액을 들지 않지만, 월간 FAX 건수 × 페이지 수에서 레이트표로 소비량을 어림하고 최신 가격 정보와 맞춰 확인하십시오. Power Automate 쪽 라이선스(표준/프리미엄 커넥터의 경계)는 「Power Automate의 라이선스와 표준/프리미엄 커넥터의 경계」에서 정리하고 있습니다.

8. 어느 길을 고를까 ── 판단표

FAX 주문서 대처는 AI Builder 읽기만이 답이 아닙니다. 건수·거래처 수·서식의 정형 정도로 선을 그으면 대체로 다음과 같습니다.

판단의 감각으로는 「같은 레이아웃의 서식이 한 달에 몇 장 오는가」를 세는 편이 빠릅니다. 이 수가 큰 거래처가 몇 곳 있으면 읽기가 먹힙니다. 레이아웃당 장수가 적은 채 거래처만 많으면 읽기 모델 유지가 수지에 맞지 않고, 웹 이전이나 EDI, 또는 수기 입력 유지가 더 합리적입니다.

또 하나 잊지 말아야 할 것이 확인 공정의 위치입니다. 읽기 자동화의 효과는 「입력이 0이 되는 것」이 아니라 「입력이 확인으로 바뀌는 것」입니다. 효과 측정에서는 도입 전 입력 시간과 도입 후 확인·수정 시간을 같은 자로 재십시오. 확인 필요율(임계값 미만으로 사람에게 돌아간 비율)과 자동 처리의 오독 건수를 함께 쫓으면, 임계값 조정과 컬렉션 추가의 판단 재료가 됩니다.

9. 정리

FAX로 도착하는 주문서 자동화는 「FAX를 그만두기」와는 다른 길로 설계할 수 있습니다. 정리하면 다음과 같습니다.

먼저 수신 FAX를 복합기 전달 기능이나 클라우드 FAX 서비스로 PDF화해 SharePoint에 모읍니다. 종이인 채로는 아무것도 시작되지 않습니다. 이어서 AI Builder 문서 처리 커스텀 모델을 건수 상위 거래처의 정형 주문서로 좁혀 학습시킵니다. 컬렉션당 최소 5건, FAX 품질이면 샘플을 넉넉히, 학습에는 실제로 수신한 FAX를 씁니다. 그리고 신뢰도 점수로 자동과 확인 필요를 가르고, 사람 확인을 거친 뒤에 대장과 기간계로 흘립니다. 전자동을 노리지 않는 것이 오히려 도입을 빠르게, 운영을 안정시킵니다.

비용 면에서는 소비형 크레딧 어림과, AI Builder 크레딧에서 Copilot 크레딧으로의 이전 일정 확인이 필수입니다. 그리고 읽기는 어디까지나 「그만둘 수 없는 FAX와 함께하기」 위한 수단입니다. 협력을 얻을 수 있는 거래처는 웹 수주나 CSV 가져오기로 옮기고, 남는 FAX를 읽기로 가볍게 합니다. 두 길을 조합할 때 수기 입력의 총량이 가장 작아집니다.

FAX 수주의 PDF화부터 읽기 흐름 설계, 확인 단계와 기간계 연동의 다듬기, 웹 이전과의 조합까지, 자사 서식에서 어디까지 갈 수 있는지 검증하면서 진행하고 싶다면 아래 상담 영역으로 연락해 주십시오.

관련 글

• FAX 수주를 웹으로 옮기려면 ── 이중 운영 기간의 설계와 단계 이전의 실무
• 메일로 도착하는 주문서·청구서 PDF를 Power Automate로 자동 처리하기 ── 저장·분류·알림·읽기 설계
• EDI란? 기업 간 수발주를 어떻게 편하게 하는가 ── FAX·메일·수기 입력에서 데이터 연동으로
• Power Automate for desktop으로 기간계 입력을 자동화하기
• 생력화 투자 보조금으로 FAX 수주의 웹화는 가능한가 ── 일반형으로 하는 수발주 시스템 투자의 생각법

관련 상담 영역

합동회사 고무라소프트에서는 FAX·메일로 도착하는 서식의 읽기 자동화 설계부터, 확인 흐름 다듬기, 기존 판매 관리 시스템·기간계와의 연동까지 상담받습니다.

• 기술 상담·설계 리뷰
• Windows 앱 개발
• 문의

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

AI Builder는 일본어 FAX 주문서를 읽을 수 있나요?

읽을 가능성은 충분합니다. AI Builder의 문서 처리 커스텀 모델은 고정 템플릿 문서·일반 문서 어느 학습 유형에서도 일본어를 지원하며, 손글씨 추출에도 대응한다고 FAQ에 명시되어 있습니다. 다만 FAX는 해상도가 낮고 흐려짐이나 기울어짐도 생기기 쉬우므로, 실제로 어디까지 읽히는지는 서식과 회선 품질에 달려 있습니다. 도입을 판단하기 전에, 실제로 수신한 FAX의 PDF를 샘플로 모델을 학습시키고 자사 서식에서의 정확도를 확인하시길 강하게 권합니다.

모델 학습에는 샘플 서식이 몇 장 필요한가요?

같은 레이아웃의 서식을 모은 「컬렉션」마다 최소 5건의 샘플 문서가 필요합니다. 컬렉션 하나에 등록할 수 있는 상한은 20건입니다. 고품질 문서라면 5건으로 충분한 경우가 많은 반면, FAX처럼 저품질 스캔에서는 15~20건을 쓰라고 권장됩니다. 거래처마다 주문서 레이아웃이 다르면 레이아웃별로 컬렉션을 나누고(모델당 최대 200개 컬렉션), 우선 건수가 많은 거래처의 정형 주문서만으로 시작하는 편이 현실적입니다.

읽은 결과를 그대로 기간계 시스템에 등록해도 되나요?

무인으로 그대로 흘리는 구성은 권하지 않습니다. AI Builder 추출 결과에는 필드마다 0~1의 신뢰도 점수가 붙습니다. 점수가 높은 건은 수주 대장에 자동 기록하고, 낮은 건은 담당자에게 알려 원본 FAX 이미지와 대조해 확인·수정하게 하는 분기를 반드시 넣습니다. 확인이 끝난 데이터만 기간계 입력(CSV 가져오기나 Power Automate for desktop으로 옮겨 입력)으로 넘기면, 오인식이 곧 오출하로 이어지는 사고를 막을 수 있습니다.

AI Builder를 쓰려면 어떤 비용이 드나요?

AI Builder 작업은 실행할 때마다 소비형 크레딧을 씁니다. 문서 처리는 읽은 페이지 수에 따라 소비하고, 커스텀 모델은 미리 빌드된 모델보다 소비 레이트가 높게 잡혀 있습니다. 이전에는 AI Builder 크레딧(용량 애드온이나 Power Automate Premium에 포함된 5,000크레딧)으로 충당하는 체계였지만, 2025년 10월에 AI Builder 크레딧의 단계적 종료가 발표되어 Copilot 크레딧으로의 이전이 진행 중입니다. Premium에 포함된 시드 크레딧은 2026년 11월 1일에 끝나므로, 새로 도입할 때는 반드시 최신 라이선스 체계를 확인하십시오.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.