AI OCR 도입 가이드 2026 — 정확도를 어떤 단위로 재고 검수 기준에 적는 법
OCR 견적의 「정확도 99%」는 판정 기준이 아닙니다. 문자 단위 99%가 10자 필드에서 90%, 필드 15개 문서에서는 20%대가 되는 산술을 보여주고, 키 필드와 보조 필드를 나눠 적는 방법, 표 밀림·손글씨·도장겹침 같은 실패 모드, 세금계산서 OCR 검수 기준 한 건 전개, 체크섬·합계 검증이 모델 개선보다 싼 이유, 사람 검증 흐름 설계, 클라우드와 온프레미스 판단, 견적 비교 6개 축까지 발주자 관점으로 정리했습니다.
OCR 견적을 받으면 「정확도 99%」라는 숫자가 적혀 있다. 그 숫자로는 아무것도 판정할 수 없다. 무엇을 하나로 세어 99%인지가 비어 있기 때문이다.
문자 단위로 99%면 좋은 수치다. 그런데 사업자등록번호 10자리를 읽을 때 문자 하나만 틀려도 그 필드는 실패다. 문자 정확도 99%가 10자 필드에서는 약 90%가 되고, 필드 15개를 다 맞혀야 하는 문서 한 장으로 보면 20%대로 내려간다(오류가 서로 독립이라는 가정 아래의 산술이지만, 단위를 바꾸면 숫자가 자릿수로 달라진다는 점은 그대로다).
그래서 OCR 발주에서 가장 먼저 정해야 하는 것은 모델이나 벤더가 아니라 정확도를 어떤 단위로 재고, 못 읽은 것을 누가 처리하는가다. 이 글은 그 두 가지를 숫자로 적는 방법을 정리한 것이다.
OCR·AI OCR·문서 AI는 어디가 다른가
세 단어가 섞여 쓰이는데 하는 일의 범위가 다르다. 견적서에 어느 쪽이 적혀 있는지로 공수가 갈린다.
| 구분 | 하는 일 | 결과물 | 한계 |
|---|---|---|---|
| 전통 OCR | 이미지의 글자를 텍스트로 | 글자 덩어리 | 「어느 값이 사업자번호인지」는 모른다 |
| AI OCR | 위 + 레이아웃·표 구조 인식 | 위치가 붙은 텍스트 | 서식이 바뀌면 흔들린다 |
| 문서 AI(IDP) | 위 + 필드 추출·검증·분류 | {사업자번호: "..."} 형태 | 필드 정의와 검증 규칙을 사람이 만들어야 한다 |
업무에 쓰려면 거의 항상 세 번째가 필요하다. 「텍스트를 뽑았다」로는 ERP에 넣을 수 없다. 어느 글자가 공급자 상호이고 어느 숫자가 공급가액인지 구조화돼야 다음 단계가 돌아간다.
그래서 견적서에 「OCR 적용」만 적혀 있으면 범위가 비어 있다. 필드 추출까지인지, 검증 규칙까지인지, ERP 연동까지인지를 나눠 적어야 비교가 된다.
정형과 비정형 — 비용이 자릿수로 갈린다
같은 「OCR」인데 대상 문서의 성격이 공수를 결정한다.
| 구분 | 예 | 왜 쉽거나 어려운가 | 공수 |
|---|---|---|---|
| 고정 양식 | 세금계산서, 급여명세서, 정부 서식 | 필드 위치가 거의 고정 | 낮다 |
| 준정형 | 영수증, 거래명세서, 명함 | 항목은 같은데 배치가 제각각 | 중간 |
| 비정형 | 계약서, 보고서, 메일 | 어디에 무엇이 있을지 모른다 | 높다 |
| 손글씨 혼재 | 수기 전표, 서명·메모가 섞인 양식 | 인쇄체와 다른 모델이 필요 | 가장 높다 |
발주 전에 실제 문서 샘플을 유형별로 세어 보는 것이 견적을 비교 가능하게 만드는 첫 작업이다. 「영수증 OCR」이라고만 적으면 업체는 카드 전표 한 종류를 가정하고, 실제로는 수기 간이영수증이 3할 섞여 있는 경우가 많다.
그리고 양식 종류 수가 공수를 직접 늘린다. 고정 양식 1종은 쉽지만 30종이면 각각의 필드 맵을 만들어야 한다. 과업에 「대상 양식 종류 수와 종별 월 건수」를 적어 두면 그 축으로 견적을 맞출 수 있다.
정확도를 어떤 단위로 재나
여기가 1페이지 어디에도 없는 자리다. 단위를 정하지 않으면 검수가 협상이 된다.
| 단위 | 세는 법 | 쓰는 곳 |
|---|---|---|
| 문자(CER) | 틀린 글자 ÷ 전체 글자 | 모델 성능 비교 |
| 필드 | 완전히 맞은 필드 ÷ 전체 필드 | 업무 판정의 기본 단위 |
| 문서 | 모든 필드가 맞은 문서 ÷ 전체 문서 | 「사람 확인 없이 통과」 비율 |
세 숫자가 어떻게 벌어지는지 보면 왜 단위를 못 섞는지 분명해진다. 문자 정확도 99%를 가정하고 오류가 독립이라 보면:
| 단위 | 계산 | 값 |
|---|---|---|
| 문자 10자 필드 | 0.99^10 | 약 90% |
| 문자 20자 필드 | 0.99^20 | 약 82% |
| 필드 15개 문서 (필드 90% 기준) | 0.90^15 | 약 22% |
「문자 99%」와 「문서 22%」가 같은 모델의 숫자다. 업체는 앞을 말하고 발주처는 뒤를 기대한다. 이 어긋남이 검수 자리에서 처음 드러난다.
그래서 과업에 이렇게 적는다
| 모호한 기준 | 판정 가능한 기준 |
|---|---|
| 정확도 99% 이상 | 필드 단위 정확도 95% 이상(발주처 지정 샘플 300건) |
| 중요 항목은 정확해야 | 키 필드(사업자번호·공급가액·일자) 필드 정확도 99% 이상 |
| 사람 확인 최소화 | 문서 단위 무수정 통과율 70% 이상 |
| 잘 못 읽으면 표시 | 신뢰도 임계 미만 필드를 검토 대기로 분리, 분리율 보고 |
키 필드와 나머지를 나누는 것이 가장 실용적이다. 숫자·식별자 필드는 한 글자 오류가 업무를 깨뜨리므로 기준을 높게, 비고·주소 같은 자유 텍스트는 낮게 둔다. 전 필드에 같은 기준을 걸면 쉬운 쪽은 과잉이고 어려운 쪽은 미달이 된다.
정확도 기준을 숫자로 만드는 일반적인 요령은 부하테스트 가이드의 판정 문장 절과 같고, 검수 문서화는 테스트 케이스 작성과 검수 기준에 정리했다.
실패 모드 — 벤치마크가 안 알려주는 것
벤더가 제시하는 정확도는 깨끗한 샘플 기준이다. 현장 문서에서 깎이는 요인은 따로 있다.
| 요인 | 무엇이 깨지나 | 대응 |
|---|---|---|
| 표 | 셀 경계·병합 셀에서 값이 옆 칸으로 밀린다 | 표 구조 인식을 별 항목으로 검수 |
| 손글씨 | 인쇄체 모델로는 급락 | 수기 비율을 세고 별도 처리 경로 |
| 회전·기울어짐 | 스캔·사진 촬영본에서 흔하다 | 전처리(deskew) 범위에 포함 |
| 저해상도 | 팩스·재스캔본 | 최소 해상도 기준을 과업에 적는다 |
| 도장·서명 겹침 | 글자 위에 겹치면 못 읽는다 | 해당 필드는 사람 확인 고정 |
| 배경 무늬·보안 용지 | 노이즈로 인식률 저하 | 샘플에 반드시 포함 |
표가 가장 자주 과소평가된다. 거래명세서처럼 품목이 여러 줄인 문서는 「값을 읽었는가」보다 「어느 줄의 어느 열인가」가 중요한데, 셀이 하나 밀리면 수량과 단가가 뒤바뀐다. 문자 정확도는 100%인데 데이터는 전부 틀린 상태가 된다. 그래서 표가 있는 문서는 행·열 정합성을 별도 기준으로 둬야 한다.
그리고 샘플은 발주처가 고른다. 업체가 고른 샘플로 측정하면 좋은 숫자가 나온다. 깨끗한 것·기울어진 것·수기 섞인 것·도장 겹친 것을 비율대로 섞어 지정하고 그 목록을 과업지시서 별첨으로 붙인다.
검수 기준 한 건을 끝까지 — 세금계산서 OCR
항목을 나열해도 막상 적으려면 막힌다. 한 건을 끝까지 전개한다.
전제 — 매입 세금계산서를 월 4,000건 받는다. 전자세금계산서가 7할이고 나머지 3할이 종이·스캔본이다. 지금은 경리 담당 2명이 ERP에 손으로 입력한다.
1단계 — 전자분을 먼저 빼낸다
전자세금계산서는 원본 데이터가 있어서 OCR이 필요 없다. 국세청 전송분을 받아 쓰면 정확도 100%다. OCR 대상은 종이·스캔본 1,200건이다.
이 구분을 안 하면 4,000건 전체를 OCR로 처리하는 견적을 받고, 70%를 불필요하게 처리한다. 「OCR이 필요 없는 분량을 먼저 걷어내는 것」이 가장 값싼 비용 절감이다.
2단계 — 필드를 나눈다
| 구분 | 필드 | 기준 |
|---|---|---|
| 키 필드 | 공급자 사업자번호, 작성일자, 공급가액, 세액 | 필드 정확도 99% |
| 보조 필드 | 공급자 상호, 품목명, 수량, 단가 | 필드 정확도 95% |
| 자유 텍스트 | 비고 | 기준 없음. 참고로만 저장 |
키 필드 4개에 99%를 거는 이유는 그것이 틀리면 회계가 틀어지기 때문이다. 사업자번호가 한 자 틀리면 매입세액 공제가 막힌다. 반면 품목명이 한 글자 틀려도 업무는 돌아간다.
3단계 — 검증 규칙을 붙인다
OCR 정확도를 올리는 것보다 읽은 값을 검증하는 규칙이 싸고 효과적이다.
| 필드 | 검증 규칙 | 걸러내는 것 |
|---|---|---|
| 사업자번호 | 체크섬 검증 + 거래처 마스터 대조 | 숫자 오인식 대부분 |
| 작성일자 | 유효 날짜 + 신고 기간 내 | 연도 오인식 |
| 공급가액·세액 | 세액 = 공급가액 × 10% ± 1원 | 자릿수 오인식 |
| 합계 | 품목 합 = 공급가액 | 표 행 밀림 |
마지막 줄이 표 밀림을 잡는다. 품목별 금액의 합이 공급가액과 안 맞으면 셀이 밀린 것이고, OCR 신뢰도가 높아도 검토 대기로 보낸다. 이런 규칙 네 개가 모델을 한 단계 올리는 것보다 효과가 크다.
4단계 — 판정 문장
발주처가 지정한 세금계산서 300건(전자 제외, 기울어짐·수기·도장겹침 각 20% 포함) 샘플 기준으로 키 필드 4종 필드 정확도 99% 이상, 보조 필드 95% 이상, 문서 단위 무수정 통과율 70% 이상을 만족한다. 검증 규칙 4종을 통과하지 못한 건은 검토 대기로 분리하며, 분리율 15% 이하로 한다. 측정에 쓴 샘플·필드별 오류 목록·원시 인식 결과를 제출물에 포함한다.
5단계 — 이 건에서 계산해야 하는 것
| 항목 | 계산 |
|---|---|
| 처리 대상 | 1,200건/월 (전자 제외) |
| 무수정 통과 | 70% = 840건 → 사람 손 안 감 |
| 검토 대기 | 15% = 180건 → 사람이 확인 |
| 나머지 | 180건 → 통과했지만 오류 가능 |
마지막 줄을 빠뜨리면 안 된다. 「무수정 통과 70%」는 30%를 사람이 본다는 뜻이 아니다. 검토 대기로 분리된 15%만 보고, 나머지 15%는 틀린 채로 통과한다. 그 비율이 회계에서 허용 가능한지가 도입 판단이다. 허용 안 되면 전건 확인이 되고, 그러면 OCR의 가치는 「입력 시간 단축」뿐이다.
사람 검증 비율을 설계에 넣는다
정확도 95%짜리 시스템은 5%를 사람이 처리하는 흐름이 있어야 서비스가 된다. 그 흐름이 범위에 없으면 모델은 도는데 업무는 안 돌아간다.
| 설계 요소 | 없으면 |
|---|---|
| 신뢰도 임계와 분리 규칙 | 전건을 사람이 다시 본다 |
| 검토 대기 목록 화면 | 어느 건을 봐야 하는지 모른다 |
| 원본 이미지와 추출값 나란히 보기 | 확인에 원본을 따로 열어야 한다 |
| 수정 이력 저장 | 다음 학습 데이터가 안 쌓인다 |
| 재처리 경로 | 양식이 바뀌면 전부 다시 손으로 |
세 번째가 체감 생산성을 가장 많이 바꾼다. 원본 이미지와 추출 필드를 한 화면에 두고 틀린 칸만 고치는 구조면 건당 수 초로 끝나고, 원본을 따로 열어야 하면 손 입력과 비슷해진다. 이 화면이 과업 범위에 있는지 확인한다.
그리고 수정 이력을 쌓는 것이 다음 단계의 재료다. 사람이 고친 값은 곧 정답 레이블이고, 그것이 모이면 모델을 우리 문서에 맞춰 개선할 수 있다. 저장 안 하면 매달 같은 오류를 같은 손으로 고친다.
클라우드냐 온프레미스냐 — 문서 성격이 정한다
이 결정이 가능한 업체 목록 자체를 바꾸므로 발주 전에 정해야 한다.
| 조건 | 선택 |
|---|---|
| 개인정보·의료·금융 문서 | 온프레미스 또는 전용 환경 검토 |
| 망분리 요구가 있다 | 온프레미스. 클라우드 API 업체는 후보에서 빠진다 |
| 월 건수가 적고 민감도 낮음 | 클라우드 API가 압도적으로 싸다 |
| 건수가 많고 꾸준하다 | 온프레미스의 고정비가 회수된다 |
클라우드 API는 건당 과금이라 적은 건수에서 압도적으로 싸다. 반대로 월 수만 건이면 고정비 구조가 유리해진다. 손익분기는 건당 단가와 서버·라이선스 비용으로 계산하면 나오는데, 그 계산을 하기 위해 월 건수를 먼저 세야 한다.
주의할 점 하나 — 개인정보가 포함된 문서를 외부로 보낼 때는 처리위탁 관계가 생긴다. 어디에 저장되고 얼마나 보관되는지를 확인해야 한다.
견적을 비교 가능하게 만드는 축
| 축 | 공수를 늘리는 쪽 | 확인할 질문 |
|---|---|---|
| 양식 종류 수 | 1종 → 30종은 필드 맵 30개 | 종별 건수가 적혀 있나 |
| 문서 성격 | 고정 양식 → 비정형 → 손글씨 혼재 | 수기 비율을 샘플로 확인했나 |
| 범위 깊이 | 텍스트 추출 → 필드 추출 → 검증 → 연동 | 어디까지인지 나눠 적혀 있나 |
| 검증 규칙 수 | 규칙 하나하나가 구현 대상 | 체크섬·대조·합계 검증이 포함인가 |
| 검토 화면 | 나란히 보기·수정·재처리 | 화면이 범위에 있나 |
| 배포 방식 | 클라우드 API vs 온프레미스 | 월 건수로 손익분기를 냈나 |
세 번째 축이 가장 자주 비어 있다. 「OCR 도입」이라는 한 줄에 텍스트 추출만 들어 있는 견적과 연동까지 들어 있는 견적이 나란히 오면 금액 차이가 의미를 갖지 못한다.
문서 자동화를 업체 선정 관점에서 비교한 내용은 AI 문서 자동화 솔루션 업체 추천에 따로 정리했다. 한글·HWP 문서를 다루는 경로는 HWP-MCP 한글문서 AI 가이드를 참고하면 된다.
흔한 실수 일곱 가지
| 실수 | 결과 | 대응 |
|---|---|---|
| 정확도 단위를 안 정함 | 검수 자리에서 처음 논의 | 문자·필드·문서 중 필드를 기본으로 |
| 전 필드에 같은 기준 | 쉬운 쪽 과잉, 어려운 쪽 미달 | 키 필드와 보조 필드 분리 |
| 샘플을 업체가 고름 | 좋은 숫자로 통과, 운영에서 무너짐 | 발주처가 비율대로 지정 |
| 원본 데이터가 있는 분량을 OCR | 70%를 불필요하게 처리 | 전자분을 먼저 걷어낸다 |
| 검증 규칙을 안 넣음 | 모델 개선에만 의존 | 체크섬·합계 검증이 더 싸다 |
| 사람 검증 흐름 미설계 | 모델은 도는데 업무가 안 돌아감 | 검토 대기·나란히 보기를 범위에 |
| 표 정합성 미검수 | 문자 100%인데 데이터가 전부 틀림 | 행·열 정합성 별도 기준 |
자주 묻는 질문
정확도 몇 %면 쓸 만한가요? 단위를 정하지 않으면 답할 수 없다. 실무 기준으로는 키 필드 필드 정확도 99%, 보조 필드 95%, 문서 무수정 통과율 70% 근처가 흔한 출발점이다. 다만 회계·의료처럼 오류 비용이 큰 영역은 전건 확인을 전제로 설계하고, OCR의 가치를 「입력 시간 단축」으로 잡는 편이 현실적이다.
손글씨도 읽히나요? 인쇄체보다 많이 떨어지고 모델도 다르다. 수기 비율을 먼저 세고, 많으면 수기 필드만 사람 확인 고정으로 설계하는 쪽이 전체를 수기 대응 모델로 바꾸는 것보다 싸다.
우리 문서로 학습시켜야 하나요? 고정 양식이면 대개 필요 없다 — 필드 맵과 검증 규칙으로 충분하다. 비정형이거나 도메인 용어가 많으면 미세조정이 효과를 내는데, 그때 필요한 것이 사람이 고친 이력이다. 그래서 수정 이력 저장이 범위에 있어야 한다.
월 건수가 적으면 도입할 가치가 없나요? 건수가 적으면 클라우드 API로 가볍게 시작하는 쪽이 맞다. 고정비가 큰 구성은 건수가 받쳐 줘야 회수된다. 그리고 건수가 적어도 오류 비용이 크면 검증 규칙만 붙여도 효과가 있다.
ERP 연동까지 한 번에 해야 하나요? PoC 단계에서는 빼는 쪽이 낫다. 연동은 상대 시스템 사정에 묶여 일정이 밀리고, 검증해야 하는 것(우리 문서가 읽히는가)과 무관하다. 읽히는 것이 확인된 뒤 연동을 붙인다. PoC와 본 구축을 나누는 요령은 AI MVP 개발 가이드에 정리했다.
정리
OCR 발주에서 순서는 이렇다.
OCR이 필요 없는 분량을 먼저 걷어낸다. 원본 데이터가 있는 전자문서를 OCR로 돌리는 것이 가장 흔한 낭비다.
정확도 단위를 필드로 정하고 키 필드를 분리한다. 「문자 99%」와 「문서 22%」는 같은 모델의 숫자다. 단위를 안 정하면 그 간극이 검수 자리에서 터진다.
샘플은 발주처가 비율대로 지정한다. 기울어짐·수기·도장겹침을 실제 비율로 섞고 목록을 과업 별첨으로 붙인다.
검증 규칙을 모델보다 먼저 박는다. 체크섬·거래처 대조·합계 일치 네 개가 모델을 한 단계 올리는 것보다 효과가 크고 싸다.
사람 검증 흐름을 범위에 넣는다. 검토 대기 목록과 원본·추출값 나란히 보기가 없으면 정확도가 높아도 업무가 안 줄어든다.
문서 유형을 세어 범위를 끊고 검수 기준을 숫자로 적는 작업이 필요하시면 문의로 알려 주세요. 트리숲은 대표번호 070-8064-3349 · official@treesoop.com 으로도 연락하실 수 있습니다.