AI OCR 문서 자동화, 어디까지 맡길까

거래명세서와 청구서가 메일, 팩스, 사진으로 매일 들어오는데 담당자가 공급가액과 품목을 ERP에 다시 입력하고 있다면 AI OCR 문서 자동화를 검토할 시점입니다. 문제는 글자를 읽는 데서 끝나지 않습니다. 이 글을 읽으면 생성형 AI가 비정형 문서에서 어디까지 추출할 수 있는지, 어떤 값은 반드시 사람이 확인해야 하는지, 실제 도입 전에 무엇을 측정해야 하는지 판단할 수 있습니다.

기존 OCR과 생성형 AI 문서 추출은 무엇이 다른가

기존 OCR의 주된 역할은 이미지에 있는 글자를 텍스트로 바꾸는 것입니다. 정해진 위치에 거래일자와 합계가 찍히는 서식이라면 좌표를 지정해 값을 가져올 수 있습니다. 거래처마다 열 이름과 표 위치가 달라지거나, 한 셀이 두 줄로 접히면 규칙을 다시 만들어야 했습니다.

생성형 AI를 결합한 문서 추출은 한 단계 더 나아갑니다. 문서의 글자와 배치를 함께 보고, ‘공급받는 자’, ‘구매자’, ‘수신처’처럼 표현이 달라도 같은 필드로 연결합니다. 품목 표에서 수량, 단가, 금액의 관계를 파악하고 문서 종류를 분류하는 것도 가능합니다.

Google Cloud는 생성형 AI 기반 맞춤 추출기의 적용 문서로 인보이스, 은행 명세서, 선하증권, 급여 명세서를 제시합니다. 2025년 8월에는 문서에 직접 적히지 않은 값도 문맥으로 도출하는 ‘Derived entity’ 기능을 발표했습니다. 주소를 보고 국가를 판단하거나 표의 항목 수를 세는 방식입니다. 다만 이는 특정 제품의 공식 기능 설명이며, 모든 문서와 모델에서 같은 성능이 나온다는 뜻은 아닙니다. Google Cloud Document AI 공식 문서도 추출 결과의 신뢰도에 따라 사람이 검토하는 구성을 안내합니다.

현장에서 구분해야 할 것은 세 가지입니다.

1. 인식: 이미지에서 ‘12,800’이라는 글자를 읽습니다.
2. 추출: 그 값이 수량이 아니라 단가라는 사실을 찾아 지정된 필드에 넣습니다.
3. 검증: 수량과 단가를 곱한 금액, 공급가액과 세액의 합계가 맞는지 확인합니다.

AI OCR이 첫 번째와 두 번째를 처리해도 세 번째까지 자동으로 믿어서는 안 됩니다. 자동 입력의 품질은 모델 이름보다 검증 규칙과 예외 처리에서 갈립니다.

거래명세서와 청구서에서 어디까지 읽을 수 있나

문서 자동화 AI가 다루는 값은 성격에 따라 나눠야 합니다. 원본에 명시된 거래일자와 사업자번호를 읽는 일, 여러 행을 합산하는 일, 주소에서 국가를 추론하는 일은 오류의 원인과 책임이 서로 다릅니다.

특히 다페이지 문서는 한 장짜리 청구서와 다르게 취급해야 합니다. Google Cloud의 Derived entity 기능 문서는 추론 결과가 페이지 단위로 생성된다고 명시합니다. 첫 페이지의 공급자 정보와 마지막 페이지의 총액을 합쳐 판단하거나, 여러 페이지의 품목을 모두 더하는 작업은 별도 로직으로 검증해야 한다는 뜻입니다.

스캔 품질도 모델이 대신 해결해 주지 못합니다. 접힌 종이, 잘린 사진, 번진 팩스, 세로로 돌아간 페이지에서는 원문 자체가 불분명합니다. AI가 빈칸을 문맥으로 메우면 그럴듯한 값이 들어갈 수 있으므로, 읽지 못한 값과 추론한 값을 구분해 저장해야 합니다. 화면에서도 ‘원문 추출’, ‘계산’, ‘추론’을 다른 상태로 보여 주는 편이 좋습니다.

사람이 반드시 확인해야 하는 값은 무엇인가

사람 검수는 모든 문서를 처음부터 다시 읽는 일이 아닙니다. 오류가 비용, 지급, 재고, 개인정보에 영향을 주는 필드만 집중해서 보는 구조여야 합니다.

우선 검수할 항목은 다음과 같습니다.

• 신뢰도 점수가 내부 기준보다 낮은 필드
• 사업자번호, 계좌번호, 거래처 코드처럼 다른 대상과 연결되는 식별값
• 공급가액, 세액, 합계처럼 지급 금액을 바꾸는 숫자
• 수량 곱하기 단가, 공급가액 더하기 세액과 맞지 않는 값
• 원본에 직접 적혀 있지 않고 AI가 추론한 값
• 여러 페이지를 합산하거나 다른 문서와 대조해야 하는 값
• 신규 거래처 서식, 저화질 사진처럼 평가 자료에 없던 입력

신뢰도 점수만으로 승인 여부를 정해서도 안 됩니다. 일부 문서 추출 제품은 항목별로 0부터 1까지 점수를 제공하지만, 0.95가 실제 정확도 95%를 보장한다는 뜻은 아닙니다. 자사 문서 평가 세트에서 점수 구간별 오류율을 측정한 뒤 임계값을 정해야 합니다. 계좌번호는 점수가 높아도 거래처 원장과 대조하고, 참고 메모는 낮은 점수여도 업무 영향이 작다면 그대로 둘 수 있습니다.

NIST의 생성형 AI 위험관리 프로필도 생성형 AI에는 추가적인 사람 검토, 추적, 문서화가 필요할 수 있다고 설명합니다. 배포 전 한 번 시험하는 데 그치지 않고 성능과 한계, 위험을 반복해서 평가하고 그 결과를 기록하라는 취지입니다. 검수 화면과 변경 이력은 부가 기능이 아니라 운영의 핵심입니다.

거래명세서 자동 입력 흐름은 어떻게 설계하나

좋은 흐름은 문서가 도착하자마자 ERP에 값을 쓰지 않습니다. 원본 보관, 추출, 규칙 검증, 사람 승인 사이에 임시 저장 영역을 둡니다. 잘못된 값이 들어갔을 때 어느 단계에서 바뀌었는지 추적할 수 있어야 하기 때문입니다.

이 구조에서는 AI가 틀려도 바로 지급이나 재고 반영으로 이어지지 않습니다. 같은 문서가 메일과 스캔으로 중복 접수될 수 있으므로 문서번호, 거래처, 날짜, 금액을 조합한 중복 검사도 필요합니다. ERP 전송에 실패했을 때 처음부터 다시 처리하지 않도록 전송 상태와 재시도 기록도 남겨야 합니다.

담당자의 화면에는 문서 전체보다 문제가 있는 필드가 먼저 보여야 합니다. 예를 들어 합계가 맞지 않으면 원본의 합계 영역, 추출값, 계산값을 한 화면에 놓습니다. 품목 40개를 다시 읽게 하는 대신 차이가 난 2개 행만 보여 주는 식입니다. 이것이 지능형 문서 처리에서 실제 시간을 줄이는 지점입니다.

PoC에서는 정확도보다 무엇을 재야 하나

처음부터 모든 거래처 문서를 넣으면 실패 원인을 찾기 어렵습니다. 문서 종류 하나와 후속 업무 하나를 정해 시작하는 편이 낫습니다. 예를 들어 ‘국내 거래명세서에서 12개 필드를 추출해 ERP 임시 전표까지 생성한다’처럼 범위를 적습니다.

Google Cloud는 생성형 AI 맞춤 추출기에서 제로샷은 학습 문서 0개, 퓨샷은 5∼10개, 미세조정은 10∼50개 이상을 권장 범위로 제시합니다. 문서 변동이 크면 수백 건 이상이 필요할 수 있다고도 설명합니다. 이 숫자는 그 제품의 권장량이지 보편적인 성공 기준은 아닙니다. 실제 수신 문서를 거래처, 화질, 페이지 수, 표 형태별로 나누고 학습에 쓰지 않은 평가 세트를 따로 두어야 합니다.

PoC 보고서에는 최소한 다음 네 지표가 들어가야 합니다.

• 필드 정확도: 정답과 정확히 일치한 필드의 비율입니다. 금액과 사업자번호는 완전 일치로 평가합니다.
• 중요 필드 오류율: 계좌번호, 합계, 지급일처럼 틀리면 업무 사고로 이어지는 값만 따로 봅니다.
• 무수정 처리율: 사람이 값을 고치지 않고 승인한 문서 비율입니다.
• 문서당 검수 시간: 업로드부터 승인까지가 아니라 담당자가 실제 화면에서 쓴 시간을 잽니다.

가정해 보겠습니다. 평가 문서 1,000건 중 850건이 무수정 승인됐더라도 합계 오류 3건이 자동 승인됐다면 바로 운영하기 어렵습니다. 반대로 무수정 처리율이 60%여도 합계와 계좌번호 오류를 모두 검수 큐로 보냈고, 담당자의 문서당 작업이 4분에서 1분으로 줄었다면 적용 가치가 있을 수 있습니다. 수치는 예시이며, 핵심은 평균 정확도 하나로 승인하지 않는다는 점입니다.

신규 거래처 추가와 서식 변경 뒤에도 같은 평가를 반복해야 합니다. NIA의 2026년 「공공부문 AI 도입·활용 가이드」도 운영 단계에서 성능 모니터링과 지속적인 데이터 업데이트 방안을 두도록 제시합니다. 평가 방법을 설계할 때는 생성형 AI 답변 품질 평가의 원칙도 함께 적용할 수 있습니다.

개인정보와 보안은 어느 단계에서 확인하나

거래명세서와 신청서에는 담당자 이름, 전화번호, 주소, 계좌정보, 서명이 포함될 수 있습니다. 외부 OCR이나 생성형 AI API에 올리기 전에 입력 문서가 어디로 전송되는지, 얼마나 보관되는지, 모델 학습에 사용되는지, 삭제 요청이 가능한지부터 확인해야 합니다. 관리자 접근권한, 전송 구간 암호화, 처리 지역, 로그에 남는 값도 계약서와 기술 문서에서 확인합니다.

개인정보보호위원회는 2025년 8월 「생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서」를 공개했습니다. 생성형 AI의 수명주기별 개인정보 처리 기준과 안전조치를 다루므로 외부 API, 문서 보관, 재학습 조건을 검토할 때 기준으로 삼을 수 있습니다. KISA의 「인공지능(AI) 보안 안내서」도 문서 전송 경로와 외부 서비스 연동을 점검할 때 참고할 공식 자료입니다.

또한 2026년 9월 11일 시행된 「개인정보 보호법」 제37조의2를 구분해서 봐야 합니다. 개인정보를 완전히 자동화된 시스템으로 처리해 정보주체의 권리나 의무에 중대한 영향을 주는 결정을 내리는 경우, 거부나 설명 요구 및 인적 개입에 의한 재처리 문제가 생길 수 있습니다. 단순히 거래명세서 값을 임시 입력하는 일과, 추출 결과만으로 지급 거절이나 신청 자격 배제를 결정하는 일은 영향이 다릅니다. 후자라면 법무 담당자, 개인정보 담당자와 자동 결정의 범위, 설명 절차, 사람의 재검토 절차를 먼저 정해야 합니다.

외부 서비스 사용 기준은 사내 생성형 AI 사용 가이드라인에서 더 구체적으로 확인할 수 있습니다. PoC 범위와 예산, 운영 책임자를 정하는 순서는 기업 AI 도입 방법에 정리했습니다.

AI OCR 문서 자동화의 목표는 사람을 검수 과정에서 없애는 것이 아닙니다. 사람이 원본을 전부 옮겨 적는 대신, 금액 불일치와 추론값처럼 판단이 필요한 부분만 보게 만드는 것이 현실적인 기준입니다. KITDI의 문서 처리 구조와 업무 연계 방식은 기업 AI 솔루션에서 확인할 수 있습니다.