Zonal OCR란 무엇이며
이를 깨뜨리는 네 가지 형태

영역은 픽셀 사각형이고, 템플릿은 프로그램입니다

영역은 페이지 위의 좌표 사각형으로, 필드 이름에 연결됩니다. 템플릿은 그러한 사각형들의 집합으로, 똑같이 생겨야 하는 모든 문서에 적용됩니다.

이 기법은 여러 이름으로 불립니다. Zone OCR, Zonal OCR, 템플릿 OCR, 필드 수준 OCR은 모두 같은 기법을 가리키므로 공급업체들은 이 용어들을 혼용합니다. 어떤 도구의 설정이 "샘플을 업로드하고 상자를 그리세요"로 시작한다면, 브로슈어에서 무엇이라 부르든 그것은 Zonal OCR입니다.

Zonal OCR과 전체 페이지 OCR의 차이는 결과물에 있습니다. 전체 페이지 OCR은 페이지 전체를 텍스트로 변환하고 읽기 순서를 유지하는데, 이는 검색, 보관, 검색 가능한 PDF에 필요한 것입니다. Zonal OCR은 이름이 붙은 값을 반환하는데, 이는 스프레드시트 열에 필요한 것입니다. 어느 쪽도 읽은 내용을 해석하지는 않습니다. 하나는 문서를 만들고, 다른 하나는 레코드를 만듭니다.

작업은 네 단계로 진행되며, 세 번째 단계에서 아키텍처의 특성이 드러납니다.

세 번째 단계는 구성 실수처럼 보이지만 그렇지 않은 실패를 설명해 줍니다. Tesseract의 문서에 따르면, 이 엔진은 기본적으로 텍스트 한 페이지를 기대하며, 작은 영역을 OCR하려면 입력을 단일 행으로 취급하는 것과 같은 다른 분할 모드가 필요합니다. 영역은 페이지를 가리키는 포인터가 아닙니다. 그것은 새로운 이미지이며, 엔진은 자신이 어떤 종류의 이미지를 보고 있는지 알려줘야 합니다.

이 모든 제약의 보상은 비용입니다. 좁은 다섯 개의 스트립을 읽는 비용은 전체 페이지를 읽는 비용의 일부에 불과하며, 로컬 엔진에서는 페이지당 한계 비용이 거의 없습니다. 정확성보다 이러한 경제성이 Zonal OCR이 여전히 스캔 소프트웨어, 캡처 제품군, 그리고 수많은 내부 스크립트에서 실행되는 이유입니다.

영역이 여전히 다른 모든 것을 능가하는 곳

Zonal OCR은 레이아웃을 직접 제어할 수 있을 때 여전히 올바른 선택입니다. 이는 향수가 아닙니다. 변하지 않는 페이지에 사용할 수 있는 가장 저렴한 결정론적 옵션입니다.

적합한 범위는 좁고 명확합니다. 직접 설계하고 인쇄하는 내부 양식(경비 청구서, 검사 체크리스트, 온보딩 패킷), 하나의 공식 버전만 유통되는 표준화된 정부 양식, 단일 발신자가 대량으로 보내는 출력물(한 은행의 명세서, 한 실험실의 보고서), 신분증 문서, 시험지 등입니다. 영역 내에서 동일한 엔진이 손으로 인쇄한 글자에 대해 ICR을, 체크박스에 대해 OMR을 실행할 수도 있으므로, 손으로 작성한 내부 양식은 합법적인 사용 사례입니다.

비용 모델은 대부분의 비교에서 생략되는 부분입니다. 로컬 영역 엔진은 페이지를 약 1초 이내에 처리하며 페이지당 비용이 청구되지 않습니다. 비전 모델은 페이지당 몇 초가 걸리고 추론 비용이 청구됩니다. 변하지 않는 하나의 양식으로 5만 페이지를 처리할 때, 그 차이는 정확성이 논의되기도 전에 프로젝트를 결정합니다.

이 기술은 평판보다 덜 경직되어 있습니다. 프로덕션 도구는 앵커("Invoice No."라는 단어를 찾아 그 오른쪽을 읽음), 패턴(더 넓은 영역에서 청구서 번호처럼 생긴 것을 검색), 그리고 정지어까지 페이지 아래로 확장되는 동적 영역을 추가합니다. 각 추가 기능은 허용 범위를 넓힙니다. 그러나 어느 것도 레이아웃별 구성을 제거하지 못하며, 바로 그 부분이 비용을 발생시킵니다.

하나의 시스템이 하나의 버전으로 인쇄한 하나의 양식이 이미 올바르게 읽힌다면, 비전 모델을 추가해도 이미 가지고 있지 않은 것을 얻을 수 없습니다.

영역이 깨지는 네 가지 문서 형태

영역은 네 가지 문서 형태에서 깨지며, 각각은 서로 다른 기계적 이유로 실패합니다. 레이아웃이 바뀐다는 일반적인 경고보다 어떤 형태를 보고 있는지 아는 것이 더 유용합니다.

1. 복합 필드

복합 필드는 고정된 사각형 안의 한 줄이 아닌 값을 담습니다. 청구지 주소는 고객에 따라 2~5줄입니다. 금액은 숫자로 한 번, 단어로 한 번 나타납니다. 공급업체 이름은 줄바꿈됩니다. "Invoice No."와 "Date"는 숫자 길이에 따라 움직이는 간격을 두고 하나의 가로 띠를 공유합니다.

영역은 가장 긴 주소를 담을 만큼 충분히 높아야 하고, 아래에 인쇄된 전화번호를 잡지 않을 만큼 충분히 좁아야 합니다. 이 두 요구사항은 서로 모순되며, 템플릿은 하나만 충족할 수 있습니다. 그 결과는 잘린 주소이거나 도시로 분류된 전화번호입니다.

2. 반복 행

추가하는 모든 항목 행은 그 아래의 모든 것을 페이지 아래로 밀어냅니다. 6행 청구서를 기준으로 만든 템플릿은 합계를 고정된 높이에 배치합니다. 같은 공급업체에 9행 청구서를 보내면 합계 영역이 대신 항목 행 위에 놓입니다.

고정 그리드는 발신자가 결코 동의한 적 없는 행 수를 인코딩합니다. 긴 주문은 그 위에 두 번째 실패를 더합니다. 합계가 2페이지로 이동하고, 1페이지용으로 정의된 템플릿은 대신 마지막 항목 행을 반환합니다.

3. 표

열마다 하나의 영역을 두는 것은 열이 가로 위치를 유지하고 행이 높이를 유지한다고 가정합니다. 실제 항목 행 표에서는 둘 다 성립하지 않습니다. 설명은 둘째 줄로 줄바꿈되고, 수량은 가변 너비 셀에서 오른쪽 정렬되며, 합계 행은 열을 가로지르고, 병합된 셀은 오른쪽의 모든 것을 밀어냅니다.

Tesseract 자체 문서에 따르면 이 엔진은 맞춤 분할과 레이아웃 분석 없이는 표를 다루는 데 어려움을 겪습니다. Zonal OCR 템플릿은 바로 그 분석을 손으로 만든 대체물이며, 표의 형태가 바뀔 때마다 다시 만들어야 합니다.

4. 가변 위치

같은 필드가 발신자가 다른 문서에서는 다른 좌표에 위치합니다. 할인 행, 세금 내역, 구매 주문 참조는 일부 청구서에는 나타나고 다른 청구서에는 나타나지 않으며, 선택적 블록이 있을 때마다 아래 필드가 밀려납니다. 스캐너 배율이 다르면 모든 것이 한꺼번에 이동합니다.

이것이 하나의 템플릿을 200개로 만드는 형상입니다. Zonal OCR을 판매하는 ABBYY는 자사의 용어집 항목에서 이 접근 방식이 공급업체 청구서나 발신자별로 레이아웃이 달라지는 문서 유형에는 적합하지 않다고 명시합니다. 기술 제공업체가 그런 경계를 긋는다면 진지하게 받아들일 가치가 있습니다.

2도 기울기가 영역에 미치는 영향

2도 회전만으로도 값을 좁은 영역 밖으로 이동시키기에 충분합니다. 어느 방향으로 이동하느냐에 따라 그 사실을 발견할 수 있는지가 결정됩니다.

Letter 페이지를 2도 회전하면 페이지 중심에서 4인치 떨어진 점이 약 0.14인치 이동합니다. 300 DPI에서 이는 약 42픽셀로, 10포인트 텍스트 한 줄에 가깝습니다. 값의 가장자리에 맞춰 그린 영역이 이제 이웃 값을 읽습니다.

이동으로 인해 날짜 영역이 합계 위로 옮겨가면 해당 필드는 1,245.00과 같은 값을 받습니다. ISO 8601을 기반으로 한 날짜 규칙이 이를 거부하고, 문서는 예외 큐로 이동하며, 누군가 스캔을 수정합니다. 번거롭지만 눈에 띄고 안전합니다.

이동으로 인해 합계 영역이 한 줄 위로 옮겨가면 합계 필드는 소계인 1,065.00을 받습니다. 그 값 자체는 형식상 문제가 없습니다. 금액 검증기를 통과하고, 게시되며, $180 차이는 몇 주 후 대사 시점에 나타납니다. 추출 단계는 성공을 보고했습니다.

수정되는 실패는 오류를 발생시키는 실패입니다. 비용을 초래하는 실패는 완벽하게 형식이 맞는 잘못된 숫자를 반환하는 실패입니다.

테스트는 깨끗하고 잘 정렬된 샘플을 사용합니다. 프로덕션에는 스캐너를 통해 약간 비스듬히 들어온 페이지가 포함되며, 검증기는 방금 승인한 숫자가 할당된 필드에 속하는지에 대해 아무런 의견이 없습니다.

템플릿은 누가 유지하고, 잘못된 행은 누가 찾는가

템플릿에는 소유자가 있고, 잘못된 행을 찾는 사람은 보통 다른 사람입니다. 바로 이 분리 지점에 실제 운영 비용이 자리합니다.

템플릿은 보통 도구를 설정한 사람이 만듭니다. 운영 분석가, IT 담당자, 때로는 계약서에 서명한 사람이 맡습니다. 영역을 텍스트보다 몇 픽셀 더 넓게 그린 이유, 또는 선 아래가 아니라 위에서 시작한 이유는 도구가 아니라 그 사람의 기억 속에 있습니다. 그 사람이 직무를 바꾸면 템플릿 라이브러리는 고고학 유물이 됩니다.

잘못된 행은 나중에, 다른 곳에서 발견됩니다. AP 담당자가 공급업체 명세서를 대사하다가 금액을 맞추지 못합니다. 컨트롤러가 월말에 차이를 발견합니다. 공급업체가 청구서가 왜 아직 미결제인지 문의하는 이메일을 보냅니다. 각 경우 모두 오류는 추출 시점에 생겼고, 하류에서 발견되었으며, 아무도 기록하지 않은 레이아웃 변경을 거슬러 추적됩니다.

온보딩은 비용의 나머지 절반입니다. r/dataengineering의 한 실무자는 그 차이를 명확히 표현했습니다. "새 공급업체 레이아웃용 템플릿을 만드는 데 약 4시간이 걸리던 것이 0초가 되었습니다." 같은 댓글은 그 시간이 대신 어디로 갔는지도 언급합니다. 템플릿을 작성하는 대신 출력을 검증하는 데로 갔습니다. 시간이 사라지는 것은 아닙니다. 이동할 뿐입니다.

커버리지는 이분법적입니다. 레이아웃은 라이브러리에 있거나 없거나 둘 중 하나이며, 발신자가 양식을 재설계하거나, 로고를 바꾸거나, 필드를 추가할 때마다 라이브러리의 경계가 움직입니다. 도구가 새 레이아웃의 80%를 처리하고 놓친 20%를 알려주는 중간 상태는 없습니다.

추출이 좌표에 의존하지 않게 되면 무엇이 바뀌는가

시맨틱 추출은 질문을 값이 어디에 있는가에서 값이 무엇인가로 바꿉니다. 페이지는 여전히 중요합니다. 다만 그 좌표가 주소 역할을 그만둡니다.

ImageToTable.ai는 Custom Column Extraction 방식으로 작동합니다. "Invoice Number", "Due Date", "Total"처럼 원하는 열 이름을 입력하면 비전 모델이 전체 페이지를 읽고 각 값이 무엇을 의미하는지로 위치를 찾습니다. 입력한 열 이름이 출력 테이블의 헤더가 됩니다. 이는 위치가 아니라 이름으로 문서에서 특정 필드를 추출하는 것과 같은 개념이며, 그릴 박스도 저장할 좌표도 없습니다. 여기서 형식 독립적이라는 말의 의미가 바로 이것입니다. 레이아웃이 바뀌어도 추출은 바뀌지 않습니다.

레이아웃은 여전히 단서입니다. 선 아래, "Total"이라는 단어 옆, 오른쪽 아래 모서리에 있는 숫자는 헤더에 있는 같은 숫자보다 합계일 가능성이 높습니다. 차이는 이 단서가 몇 달 전에 템플릿으로 고정되는 대신 추출 시점에 해석된다는 점입니다. 아무것도 외워두지 않았으므로 아무것도 낡지 않습니다.

실질적인 결과는 곧바로 따라옵니다. 새 공급업체의 첫 청구서에는 설정이 필요 없습니다. 60개 행이 있는 테이블은 템플릿이 예상한 6개 행으로 잘리는 대신 전체가 읽힙니다. 2도 회전된 스캔은 정렬 단계가 실패할 일이 없습니다. 정렬할 좌표 프레임 자체가 없기 때문입니다.

이 방식이 해결하지 못하는 점도 분명히 짚을 필요가 있습니다. 문서에 소계와 미지급액처럼 그럴듯한 후보가 두 개 있으면 모델은 여전히 하나를 골라야 하고, 열 이름이 결정을 내릴 만큼 구체적이어야 합니다. 원본에 인쇄된 산술 오류는 그대로 복사됩니다. 흐릿한 손글씨는 어떤 모델이든 읽을 수 있는 범위를 제한합니다. 또한 비전 모델은 확신을 가지고 틀릴 수 있기 때문에, 검토 화면에서 각 셀이 어느 영역에서 왔는지 강조 표시하여 의심스러운 값을 1~2초 만에 페이지에서 추적할 수 있습니다.

인쇄된 표 데이터는 페이지당 약 5~10초로 최대 99% 정확도로 인식됩니다. 이는 배치 작업에 충분히 빠르지만, 원장에 전기되는 필드의 검토를 건너뛸 이유는 되지 않습니다. 실패 양상은 중요한 차이가 있습니다. 영역이 어긋나면 같은 레이아웃을 공유하는 모든 문서에서 동일한 잘못된 값이 반환되지만, 모델의 간헐적 실수는 특정 문서에 국한되어 다음 문서에서 반복되지 않습니다.

문서에 어떤 방식이 필요한지 판단하는 방법

문서 수가 아니라 레이아웃 수를 세고, 그 레이아웃을 누가 통제하는지 물으십시오. 세 공급업체에서 온 청구서 1만 장은 영역이 잘 해결하는 문제입니다. 공급업체 200곳에서 온 청구서 200장은 그렇지 않습니다.

실용적인 기준: 레이아웃이 내 것이고, 안정적이며, 수가 적다면 영역이 더 저렴하고 빠르고 정확합니다. 레이아웃이 남의 것이거나, 예고 없이 새 버전으로 도착하거나, 서로 다른 형식이 십여 개 이상이라면 영역의 유지보수 비용이 모델의 페이지당 비용을 앞지릅니다. 애매한 중간 지대, 즉 여덟에서 열 곳의 발신자로부터 월 수백 장이 오는 경우는 보통 템플릿 수리에 쓸 수 있는 인력 시간에 따라 갈립니다.

세 가지 점검으로 벤더 데모보다 빠르게 결론이 납니다.

1. 값이 움직이는 필드를 돌려보십시오. 한 번도 템플릿을 만들지 않은 문서 스무 장에서 합계, 세액, 납기일을 뽑아보십시오. 실패 횟수를 세십시오. 필드별 정확도를 평균 내지 마십시오.
2. 한 페이지를 2도 회전시켜 다시 돌려보십시오. 도구가 오류를 내는지, 그럴듯하지만 틀린 숫자를 반환하는지 보십시오. 두 번째 동작이 바로 장부까지 도달하는 동작입니다.
3. 잘못된 합계를 누가, 언제 알아차릴지 물으십시오. 답이 "다음 달 대사할 때"라면 어떤 엔진을 고르든 검토 단계를 추가하십시오.

기법이 아니라 도구를 비교한다면, 차이는 한 번도 본 적 없는 공급업체를 각 도구가 어떻게 처리하는지에서 드러납니다. Docparser 같은 템플릿 기반 제품은 무언가를 읽기 전에 레이아웃에 대한 파싱 규칙이 필요하지만, 시맨틱 도구는 열 이름을 요청하고 첫 문서부터 시작합니다. OCR 소프트웨어와 가격에 대한 더 넓은 비교는 OCR 소프트웨어 총정리에 있으며, 스캔한 페이지를 텍스트가 아니라 표 행으로 바꾸는 소프트웨어가 실제로 필요하다면 데이터 입력용 OCR 소프트웨어 페이지에서 그 방법을 다룹니다.

FAQ

Zonal OCR를 쉽게 설명하면 무엇인가요?

샘플 페이지에 그린 상자 안으로만 범위를 제한한 OCR입니다. 각 상자는 필드 이름과 연결되므로, 출력은 텍스트 덩어리가 아니라 레이블이 붙은 값의 집합입니다. 소프트웨어는 상자 안에 들어오는 내용만 읽습니다.

Zonal OCR는 템플릿 OCR과 같은 건가요?

네. Zone OCR, zonal OCR, 템플릿 OCR, 필드 수준 OCR은 모두 같은 기법을 가리킵니다. 구분법은 설정 방식입니다. 샘플을 업로드하고 사각형을 그리는 것으로 시작한다면 zonal OCR입니다.

Zonal OCR와 전체 텍스트 OCR의 차이는 무엇인가요?

전체 텍스트 OCR은 페이지의 모든 문자를 읽어 읽기 순서대로, 보통은 검색 가능한 텍스트 레이어로 반환합니다. Zonal OCR는 정의한 영역만 읽어 이름이 붙은 필드를 반환합니다. 전체 텍스트 OCR은 검색과 보관을 위해 만들어졌고, zonal OCR는 데이터 캡처를 위해 만들어졌습니다. 둘 다 텍스트의 의미를 이해하지는 못하며, 바로 여기에서 전통적 OCR의 정확도 한계가 시작됩니다.

Zonal OCR의 주요 한계는 무엇인가요?

고정된 위치, 고정된 필드 크기, 가변적인 행 수, 스캔 기울기, 레이아웃당 하나의 템플릿입니다. 가장 비용이 큰 한계는 실패가 오류가 아니라 잘못된 위치에서 그럴듯한 값을 반환하는 경우가 많아, 문제가 하위 단계에서야 발견된다는 점입니다.

Zonal OCR는 손글씨에도 작동하나요?

영역 안에서는 ICR이 날짜 상자나 숫자 격자처럼 제약된 필드에 있는 손으로 인쇄한 글자를 읽을 수 있습니다. 필기체와 제약 없는 손글씨는 여전히 신뢰할 수 없으며, 양식마다 길이나 위치가 바뀌는 값에는 영역이 도움이 되지 않습니다.

Zonal OCR를 완전히 대체해야 하나요?

아닙니다. 레이아웃이 직접 관리하는 것이고, 처리량이 많고, 양식이 변하지 않는 곳에서는 그대로 유지하세요. 레이아웃이 통제할 수 없는 발신자에게 속한 곳에서는 대체하세요. 판단 기준은 페이지의 소유권이지 기법의 연식이 아닙니다.

영역은 다음에도 페이지가 똑같이 보일 것이라는 약속입니다. 그 약속이 지켜지는지는 소프트웨어가 아니라 문서의 속성입니다.

양식을 직접 인쇄한다면 그 약속은 지킬 수 있는 것이고, 영역은 그것을 지키는 좋은 방법입니다. 다른 사람이 인쇄한다면 그 약속은 애초에 할 수 있는 것이 아니었습니다. 원하는 열 이름을 입력하고 모델이 그것이 어디에 있든 찾아내게 하는 방식이 유지보수 대기열을 스프레드시트로 바꾸는 경우가 바로 그런 경우입니다.

계속 깨지는 레이아웃을 가져오세요. 무엇이 나오는지 확인해 보세요.