문서 자동화: Intelligent Document Processing 5개 후보 선택법

문서 자동화는 IDP와 클라우드 API 등 5개 후보를 문서 유형, 추출 정확도, 연동과 예외 검수 기준으로 비교합니다. 같은 샘플로 데모해 ERP 전달까지 확인하고 적합한 후보를 고르는 방법을 안내합니다.

문서 자동화: Intelligent Document Processing 5개 후보 선택법

협력사 문서를 업무 시스템으로 옮기는 팀은 필드 추출부터 예외 처리와 등록까지 같은 샘플로 확인해야 합니다. 아래 다섯 항목은 서로 배타적인 제품 순위가 아니라 검토 경로와 적용 상황을 정리한 것입니다. 클라우드 문서 처리 API는 구현 범주이고 Google Document AI는 그 범주의 구체적인 예시이므로 두 경로는 겹칠 수 있습니다. 문서 검색과 답변이 필요한 업무는 별도의 RAG 결과로 평가합니다.


핵심 요약

문서 자동화 후보를 검토하는 경로와 기준

  • 업무 흐름까지 잇기: 문서 추출 뒤 ERP 등 후속 단계까지 자동화하려면 RPA 연계형 IDP를 검토합니다.
  • 양식 편차 다루기: 협력사별 서식과 문서 종류가 섞이면 다양한 문서에서 필드를 추출하는 전문 IDP를 비교합니다.
  • API형으로 구축하기: 개발팀이 기존 클라우드 환경에서 처리 흐름을 구성한다면 API형 문서 처리를 살펴봅니다. Google Document AI는 이 경로의 구체적인 예시이며 별개의 배타적 후보가 아닙니다.
  • Google Document AI를 검증하기: Google Cloud 중심 팀은 Form Parser와 커스텀 추출 경로를 실제 문서로 평가합니다.
  • 거래 문서가 대부분일 때: 송장·발주서 처리 전문 후보를 두고 필드 검수와 업무 시스템 전달까지 확인합니다.
후보 유형우선 검토할 상황데모에서 확인할 지점
RPA 연계형 IDP기존 로봇과 ERP 업무 흐름을 함께 운영할 때사람의 예외 판단 뒤 자동화 재개, 기존 커넥터·업무 규칙, 중복 등록 처리
다양한 문서용 전문 IDP협력사별 서식과 문서 유형이 다양할 때분류·필드 추출·커스텀 모델·양식 변경 절차
클라우드 문서 처리 API개발팀이 API 기반으로 업무 규칙과 전송을 구성할 때온라인·배치 요청, 응답 스키마, 호출 권한과 운영 부담
Google Document AI (API형의 구체 예시)Google Cloud와 해당 프로세서 구성을 중심으로 API형 경로를 검토할 때Form Parser와 커스텀 추출 경로를 한국어 원본 문서로 검증
거래 문서 전문 처리송장·발주서와 품목 대조가 대부분일 때머리글·품목 필드, 발주 대조, 예외 검수와 ERP 전달

다섯 후보를 가르는 기준

후보를 고를 때는 제품 이름보다 처리할 문서, 자동화할 단계, 연동 방식 세 가지를 먼저 정합니다. 매달 수천 건이라는 양은 처리량 확인에 중요하지만, 문서가 균일한지와 한 건의 오류가 어떤 업무 영향을 주는지도 함께 봐야 합니다. 표준 PDF 송장만 있는 팀과 손글씨가 섞인 스캔 발주서, 이메일 첨부, 납품 증빙을 한꺼번에 받는 팀은 같은 추출 조건을 요구하지 않습니다.

첫째, 문서 유형과 필드 목록을 작성합니다. 송장 번호, 공급업체, 발행일, 공급가액, 부가세, 총액, 품목 행, 발주 번호 가운데 시스템에 실제로 입력하는 값만 포함합니다. 날짜 표기와 통화 단위, 품목 행의 식별 키처럼 서식 차이로 혼동하기 쉬운 값은 정의를 따로 적습니다. 필드의 의미가 조직 안에서 다르면 모델 점수보다 스키마 설명부터 맞춰야 합니다.

둘째, 사람의 검토와 업무 전달을 자동화 범위에 포함합니다. 문서 업로드, 유형 분류, 값 추출, 필수값·합계 확인, 예외 검수, ERP 전송, 실패 건 재처리는 서로 다른 단계입니다. 데모가 추출 화면만 보여주면 입력 업무 가운데 어느 부분이 줄어드는지 판단하기 어렵습니다. 사람이 수정한 값이 어디에 기록되고, 승인 뒤 자동화가 어느 단계부터 이어지는지도 확인합니다.

셋째, 기존 업무 시스템과 연결하는 경로를 구분합니다. RPA 도구의 워크플로를 이어 쓰는지, API 응답을 사내 서비스가 받아 처리하는지, 사람이 검수한 뒤 ERP로 전달하는지에 따라 제품이 맡는 범위가 달라집니다. 클라우드 이용 여부와 데이터가 처리되는 위치, 조직의 운영 책임은 별개 항목으로 묻습니다.

필드별 평가표에는 승인된 원문값, 정규화 규칙, 기대값과 처리 결과를 따로 둡니다. 송장 번호·통화·세금·총액은 업무 담당자가 자동 처리와 사람 검수 기준을 시험 전에 정합니다. 서식 차이를 정규화하는 규칙과 실제 금액 차이를 허용하는 규칙은 별도로 승인하며, 임의 반올림으로 금액 불일치를 통과시키지 않습니다.


1. 추출 뒤 ERP 업무까지 잇는 RPA 연계형 IDP

이미 RPA(로봇 프로세스 자동화)로 반복 업무를 처리한다면 문서 이해 기능과 기존 워크플로를 이어 쓰는 유형부터 검토합니다. 아래 UiPath의 공식 실습은 판단이 어려운 송장 대조를 사람의 확인 작업으로 보내는 구성 예시입니다. 실제 제품·라이선스·연결 방식에서 같은 흐름이 제공되는지 데모로 확인합니다.

한 공개된 RPA 기반 송장 대조 실습은 자동화가 송장과 발주서의 일치 여부를 판단하지 못할 때 사람에게 Action Center 작업을 만들고, 사람이 결정을 내리도록 구성합니다. 사람에게는 결정을 내리는 데 필요한 입력을 한 화면에 요약하고, Action Center에서 찾기 쉬운 작업 제목을 붙입니다. 구매팀은 데모에서 사람이 값을 고친 뒤 워크플로가 이어지는지, 승인·보류·반려가 각각 어떤 상태로 기록되는지 확인해야 합니다.

이 유형은 기존 RPA 운영 방식과 업무 시스템 연결을 함께 평가하려는 조직에 맞습니다. 실무자는 기존 로봇, 업무 규칙, 예외 작업함을 재사용할 수 있는지, ERP 화면이나 API에 어떤 별도 설정이 필요한지 확인합니다. 공급업체별 문서가 자주 바뀌는 상황에서는 추출 모델의 수정과 배포도 데모 범위에 넣습니다.

RPA 라이선스나 운영 도구가 없는 팀은 문서 처리만 필요한데도 더 넓은 자동화 구성을 도입하는 셈이 될 수 있으므로, 처리 흐름 전체에서 실제로 쓸 구성요소를 기준으로 비교합니다.

데모에는 정상 송장만 넣지 않습니다. 발주 번호가 없거나 합계가 맞지 않는 문서, 페이지가 뒤집힌 스캔, 필수 필드가 비어 있는 건을 넣고 자동 분류 결과와 사람의 판단 절차를 지켜봅니다. 담당자가 예외를 해결한 뒤 ERP 등록이 한 번만 실행되는지, 실패가 다시 큐에 들어오는지, 중복 처리 여부를 운영자가 알아볼 수 있는지도 질문합니다. 이런 결과가 있어야 RPA 연계가 추출을 넘어 실제 입력 노동을 줄이는지 알 수 있습니다.


2. 협력사별 서식이 다양한 전문 IDP

공급업체마다 송장 양식이 다르고 송장 외 문서도 섞인다면 여러 문서 유형을 분류하고 추출 모델을 적용하는 전문 IDP 유형을 비교합니다. 이 유형에서 중요한 질문은 사전 학습된 추출 기능이 우리 문서 종류에 맞는지, 필드 정의를 바꾸거나 자체 모델을 만들 수 있는지입니다. 표준 서식 한 종류만 처리하는 데모로는 양식 편차가 큰 환경을 평가하기 어렵습니다.

ABBYY Vantage의 공식 입력 앱 설명은 OCR과 사전 학습된 추출 모델인 Skills를 소개합니다. 이는 제품 범위를 확인하는 출발점이며, 대상 라이선스의 문서 분류·추출·검수 경로는 실제 협력사 문서로 확인합니다.

양식 편차를 평가하려면 협력사별 문서군을 나누고, 각 군에서 대표 샘플과 예외 샘플을 함께 준비합니다. 같은 필드가 페이지의 다른 위치에 있거나 항목 표가 여러 페이지로 이어지는 경우도 넣습니다. 필드 이름과 의미, 값의 표준화 규칙을 정의한 뒤 후보가 각 문서를 분류하고 필요한 값만 추출하는지 확인합니다.

품목 행은 순서로만 비교하면 행이 추가되거나 빠졌을 때 오류를 놓칠 수 있습니다. 송장 행 ID 같은 식별 키를 기준으로 행을 대조하는 방법이 평가에 도움이 됩니다.

2026년 7월 공개된 ExtractBench의 평가 데이터는 8개 업무 분야의 67개 문서 유형, 총 370개 기업 문서로 구성됩니다. 이 수치는 해당 벤치마크의 표본 구성을 설명할 뿐, 업계 전체의 문서 분포나 우리 문서에서의 성능을 나타내지는 않습니다. 데모 문서도 디지털 원본, 스캔, 표가 복잡한 파일, 손글씨나 저품질 이미지처럼 서로 다른 조건을 대표하도록 고릅니다.

이 후보 유형은 문서 구성이 넓고 양식 차이가 추출 결과에 영향을 주는 조직에 적합합니다. 반대로 처리할 서식이 고정되어 있고 기존 서비스의 사전 프로세서가 필요한 필드를 이미 제공한다면, 모델을 직접 구성하는 데 드는 작업이 불필요할 수 있습니다. 공급업체가 새 서식을 보낼 때 필드 정의·학습 데이터·검수 화면 중 무엇을 업데이트해야 하는지 확인하면, 초기 데모뿐 아니라 변경 대응 방식도 비교할 수 있습니다.


3. API형 문서 처리의 공통 구현·운영 기준

API형 문서 처리는 별개의 제품 순위가 아니라 문서 처리를 API로 연결하는 구현 경로입니다. Google Document AI는 이 범주의 구체적인 예시이며, 기능별 설명은 다음 절에서 다룹니다. 이 절에서는 공급자와 무관하게 확인할 구현·운영 기준에 집중합니다.

개발팀은 API 응답을 사내 서비스에서 검증하고 저장·접근 권한·중복 방지·예외 대기열·재처리를 설계해야 합니다. API가 값을 반환하는 것과 그 값이 ERP에 안전하게 등록되는 것은 별도 단계이므로, 오류와 부분 실패를 누가 모니터링하고 복구할지도 정합니다. 온라인·배치 처리 경로와 호출량 조건은 선택한 서비스의 현재 공식 안내에서 확인합니다.

API형 경로는 사내 개발자가 거래 규칙을 코드로 통제하고 여러 시스템에 전달할 때 적합합니다. 송장 금액과 발주 금액의 차이 판정, 공급업체 코드 연결처럼 조직별 규칙은 사내에서 구현할 범위를 정합니다.


4. Google Cloud 중심이라면 Google Document AI

Google Document AI는 API형 문서 처리의 구체적인 예시로, Google Cloud 중심 팀이 검토할 수 있는 경로입니다. Google Document AI의 Form Parser는 여러 문서 유형에서 텍스트, 키-값 쌍, 표와 일반 엔터티를 추출합니다. Form Parser 2.0은 200개가 넘는 언어를 지원한다고 명시되어 있습니다. 언어 수만으로 한국어 협력사 문서 성능을 판단할 수는 없으므로, 실제 한글 서식과 스캔 품질로 필드 결과를 점검합니다.

Google Cloud의 Custom-based extraction 절차에서는 추출 필드를 정의하고 모델을 평가할 수 있습니다. 데이터셋의 최소 요구량은 선택한 프로세서 버전과 학습 방식의 현재 공식 안내에서 확인합니다. 특정 절차의 최소 문서 수는 해당 설정의 요건이지, 충분한 성능 평가 표본을 뜻하지는 않습니다. 실제 문서 유형과 변동을 반영해 학습·테스트 표본을 별도로 설계합니다.

Form Parser와 커스텀 추출 경로를 같은 한국어 원본 문서로 비교하고, 문서·필드별 F1, 정밀도, 재현율은 추출 품질 지표로 기록합니다. 이는 검수와 업무 규칙을 거쳐 ERP 등록까지 성공했는지를 보여주는 end-to-end 결과와 구분해 평가합니다.


5. 송장·발주서 처리 비중이 큰 거래 문서 전문 후보

업무 문서 대부분이 송장과 발주서라면 거래 문서에 초점을 둔 처리 후보를 별도 비교군으로 둡니다. 이 유형은 여러 부서의 잡다한 문서 전체를 자동화하는 능력보다 송장 머리글과 품목 행, 발주서의 참조 번호, 두 문서의 대조와 보류 절차가 현재 업무에 맞는지가 기준입니다.

품목 행은 식별 키별 수량·단가·세금·총액을 대조하고 누락·중복을 따로 기록합니다. 자동 등록을 막는 필수 키와 금액 오차 처리 규칙은 업무 담당자가 승인합니다. 사람이 수정한 행도 같은 업무 규칙과 중복 검사를 다시 통과한 뒤 등록합니다.

송장과 발주서의 대조를 자동화하려면 필드 추출 후에 업무 규칙이 작동하는지 확인합니다. 발주 번호가 누락되거나 금액 차이가 허용 범위를 넘는 문서가 자동 승인되는지, 보류·담당자 검토로 이어지는지 시험합니다. 발주 번호 누락, 허용 금액 초과, 공급업체 식별 불일치에는 서로 다른 보류 사유를 연결합니다. 데모 후보가 추출, 대조, 예외 전달 가운데 어디까지 제공하는지 명확하게 나누면 별도로 구현할 범위가 보입니다.

이 유형은 입력 문서가 구매·지급 프로세스에 집중되고 거래 항목 검증이 핵심일 때 비교할 가치가 있습니다. 여러 문서 유형과 복잡한 예외 흐름을 처리한다면 전문 IDP나 RPA형 후보와 같은 문서 세트로 비교합니다.


후보 5개를 같은 데모로 좁히는 법

같은 문서를 디지털 원본과 현장에서 발생하는 스캔 상태로 나눠 데모합니다. 각 문서군의 오류와 사람이 확인한 시간을 별도로 기록하면 읽기 품질과 자동화 범위를 함께 비교할 수 있습니다.

같은 평가 문서와 승인된 업무 규칙을 적용하고, 추출 품질과 end-to-end 등록 결과를 구분해 기록합니다. 아래 항목은 독립 제품 순위가 아니라 검토 경로별 비교 기준이며, 클라우드 문서 처리 API와 Google Document AI는 범주와 구체 예시의 관계로 서로 겹칩니다.

  1. 추출 결과: 필수 필드별 정답 일치와 숫자·날짜 형식 처리, 품목 행의 누락·중복을 기록합니다. 원문값과 정규화값을 별도 열에 두고 변환 규칙도 적습니다.
  2. 근거와 예외: 값이 문서의 어디에서 추출됐는지 확인합니다. 값 누락·충돌은 재처리, 보류, 담당자 검토로 분기하고 수정 뒤 같은 검증을 다시 실행합니다.
  3. 업무 시스템 전달: 검수 승인 후 ERP에 필요한 필드가 전달되는지, 전송 실패가 다시 처리 가능한지, 같은 문서가 두 번 등록되지 않는지 확인합니다.
  4. 운영 작업량: 사람이 수정한 필드와 검토한 문서 수, 예외 처리 시간, 새 양식 등록에 필요한 작업을 후보별로 계산합니다.
  5. 총비용과 운영 조건: 최신 견적의 처리 단위·초과 사용 조건과 배포 위치, 운영 주체를 확인하고, API·RPA·사람 검수에 필요한 구현 비용을 함께 추산합니다.

ExtractBench의 정답 구축 절차는 불일치를 스키마 모호성, 모델 오류, 판정 불가로 나누고, 합의되거나 검증된 셀만 후보 정답에 포함합니다. 스캔 양식에서는 사람이 PDF의 값을 대조해 모델 간 불일치나 문서에서 판정되지 않는 셀을 수정합니다. 팀은 필드 정의가 애매한 사례를 먼저 정리한 뒤 같은 승인값으로 각 경로를 평가해야 공정하게 결과를 비교할 수 있습니다.

자동 처리 비율은 사람의 수정 없이 합의한 검증과 ERP 인계를 모두 통과한 고유 문서 수 ÷ 전체 평가 대상 고유 문서 수로 계산합니다. 실패·보류 문서도 분모에 포함하고, 재시도는 같은 문서의 중복 실적으로 세지 않습니다.

필드별 F1·정확도는 추출 품질 지표이며, 이 비율은 검증과 ERP 인계까지 포함한 end-to-end 업무 결과입니다. 두 결과를 구분해 기록합니다.

원문을 읽지 못한 건, 필드 오류, 스키마가 애매한 건을 구분해 기록하고, 지급액·세금·공급업체 식별처럼 실패 영향이 다른 필드는 업무 담당자가 검수 기준을 정합니다. 벤치마크나 다른 데이터셋의 수치를 우리 문서의 기대 성능으로 사용하지 않습니다.

이 기준으로 같은 샘플 세트를 평가해 필수 필드와 예외 처리, 수정 이력, ERP 인계 결과를 확인합니다. 이를 통과한 경로에 한해 처리량, 견적, 배포·운영 조건을 비교하고, 사람이 계속 확인해야 하는 문서 유형과 필드를 정합니다. 데모 기록에는 원문 버전과 파서가 제공하는 위치 식별자를 남깁니다.


필드 등록과 문서 검색은 별도 목표입니다

예를 들어 송장에서 공급업체 코드와 총액을 ERP에 기록하는 업무는 정해진 필드의 등록 결과를 만듭니다. 계약서와 납품 문서에서 납기 조건을 찾아 답하는 업무는 검색 결과와 근거 문장을 제공합니다.

검색, 필드 추출, 업무 검증, 저장과 예외 처리를 함께 구성할 때는 각 출력의 승인자와 다음 단계를 정합니다. 근거 문장을 찾은 결과와 ERP에 승인된 값을 한 번만 기록한 결과를 서로 다른 수락 항목으로 둡니다.

필드 등록 뒤 원문 질의가 필요한 업무에서는 ERP 등록 ID와 승인된 원문·문서 버전의 대응을 남깁니다. Seahorse Cloud의 제품 구성을 검색 경로 후보로 확인하되, ERP 등록과 문서 답변의 수락 결과 및 담당자는 각각 기록합니다.



자주 묻는 질문

RAG가 송장 필드를 ERP에 자동 등록할 수 있나요?

아니요, RAG만으로 필드 등록 작업의 성능을 판단할 수 없습니다. 송장 번호·금액을 구조화해 검증하고 시스템에 전달하는 흐름은 IDP와 업무 자동화 데모로 평가하며, RAG는 문서 검색과 답변 근거를 따로 확인합니다.

스캔된 송장도 데모에 넣어야 하나요?

네, 실제 협력사 문서에 스캔본이나 낮은 이미지 품질이 포함되면 그 샘플을 넣습니다. 기울기, 희미한 글자, 여러 페이지의 표, 손글씨가 있는 파일은 PDF 원본과 함께 준비해 추출 결과와 사람 검수 절차를 봅니다.

후보 제품의 정확도는 한 숫자로 비교해도 되나요?

아니요, 송장 번호·총액·날짜·품목 행 등 업무 필드별로 정답 일치와 오류 영향을 나눠 봅니다. 문서 유형과 스캔 상태를 같게 맞추고, 어떤 값은 자동 처리하고 어떤 값은 사람에게 보낼지 업무 담당자가 정합니다.

데모 뒤 최종 후보를 어떻게 고르나요?

필수 필드 추출, 예외 검수, ERP 전달을 통과한 후보를 먼저 추립니다. 그다음 실제 사용량 기준의 견적과 연동 구현, 운영 인력, 배포 조건을 비교해 조직이 맡을 수 있는 범위에 맞는 후보를 선택합니다.

결론

같은 문서로 후보별 추출 품질과 ERP 등록 결과를 따로 비교하고, 업무를 통과한 후보는 운영 작업량과 비용까지 확인해 최종 선택합니다.

관련 배경: 한글 문서에서 추출한 데이터를 업무 레코드로 검증하기


문서와 검색 흐름을 직접 확인하세요

우리 조직의 문서와 평가 기준으로 필요한 기능을 확인해보세요.

씨홀스 콘솔 열기