필드별 OCR 정확도:
전체 95%, 핵심 필드는 60%

'95% 정확도'의 함정

전통적인 OCR 엔진은 문서 이미지에서 개별 문자를 올바르게 인식한 비율인 문자 단위 정확도로 성능을 측정합니다. Google이 유지 관리하는 오픈소스 벤치마크인 Tesseract 5는 깨끗한 인쇄 문서에서 95%의 문자 정확도를 달성합니다. ABBYY FineReader와 같은 엔터프라이즈 엔진은 실험실 조건에서 97~99%에 도달합니다. 이는 실제 테스트 세트에서 측정된 실제 수치입니다.

하지만 문자 정확도는 기업이 실제로 필요로 하는 것, 즉 완전하고 정확한 데이터 필드를 측정하기에는 부적합한 지표입니다. 10자리 송장 번호에서 한 자리 숫자만 잘못 읽혀도 전체 필드가 틀리게 됩니다. 1,000자 페이지에서 99%의 문자 정확도는 10개의 문자가 틀렸다는 뜻이며, 그 10개의 오류가 15개 대상 필드 중 3개에 포함된다면 필드 수준 정확도는 80%로 떨어집니다. TDWI는 실제 생산 OCR 파이프라인에서 이러한 정확한 시나리오를 문서화했습니다. 대시보드에는 99%라고 표시되지만, 추출된 비즈니스 필드 5개 중 1개에는 오류가 포함되어 있습니다.

더 심각한 점은 오류가 균등하게 분포하지 않는다는 것입니다. 기존 OCR은 일부 필드 유형은 거의 항상 정확하게 인식합니다. 반면 다른 필드 유형은 너무 심하게 실패하여 추출 자체가 무의미해집니다. 문제는 실패할 가능성이 가장 높은 필드(라인 항목의 금액, 필기된 날짜, 표 형식 데이터)가 수정 비용이 가장 많이 드는 필드라는 점입니다.

인쇄된 날짜와 숫자 — OCR이 잘하는 영역

깨끗하게 인쇄된 고대비 문서에서 전통적인 OCR은 표준 위치에 있는 날짜와 금액을 잘 처리합니다. 흰색 배경에 11pt Arial로 인쇄된 "06/09/2026" 형식의 송장 날짜는 300 DPI에서 거의 완벽한 문자 인식 정확도로 OCR 처리됩니다. 오른쪽 하단에 "$1,234.56"으로 인쇄된 총 금액은 공급업체 송장 전체에서 일관된 위치에 있을 때 잘 관리된 템플릿과 결합하여 안정적으로 추출됩니다.

이러한 필드가 OCR 공급업체가 인용하는 95~99% 수치를 만들어냅니다. 이는 표준화된 글꼴, 예측 가능한 위치, 높은 대비라는 최상의 시나리오를 나타냅니다. 이것이 전통적인 OCR이 실제로 작동하는 영역입니다.

형식이 달라지자마자 균열이 나타납니다. "09/06/2026"으로 작성된 날짜는 미국식으로 6월 9일인가요, 영국식으로 9월 6일인가요? 전통적인 OCR은 차이를 감지할 메커니즘이 없습니다. 숫자를 충실히 읽고, 다운스트림 시스템은 추측하거나 기본적으로 미국 형식을 사용합니다. Python 기반 유럽 송장 파이프라인을 구축하는 Reddit 사용자는 정확히 이 문제를 문서화했습니다. 이탈리아 송장은 31/12/2024를 사용하고, 독일 송장은 31.12.2024를 사용하며, 영국 송장은 31/12/2024를 사용합니다(동일한 구문, 다른 일/월 순서). 로케일 인식 정규화 없이 여러 국가의 송장 배치에서 추출된 날짜는 몇 달씩 조용히 뒤섞입니다.

금액에는 더 미묘한 실패 모드가 있습니다. 깨끗하게 인쇄된 "$1,234.56"은 잘 읽힙니다. 하지만 "$1,234.56"인 라인 항목 소계가 "$1,234.56"인 송장 총액 바로 위 행에 있을 때(같은 숫자, 다른 의미) 템플릿 기반 추출은 잘못된 값을 가져올 위험이 있습니다. 통화 기호 변형이 문제를 복잡하게 만듭니다. "€1.234,56"(유럽식 소수점 쉼표), "¥1,235"(일본 엔, 소수점 없음) 또는 통화 기호 없이 인쇄된 금액은 각각 다른 구문 분석 규칙을 위반할 수 있습니다.

이름과 주소 — 문자는 맞지만 맥락이 틀린 경우

겉으로 보기에는 OCR이 이름과 주소를 쉽게 처리할 수 있을 것 같습니다. 텍스트이며, 보통 읽기 쉬운 글꼴로 인쇄되어 있고, 특수 문자도 없습니다. 기존 OCR 엔진은 "John Smith"라는 문자열을 높은 신뢰도로 정확히 인식하고, "123 Main Street, Springfield, IL 62701"이라는 주소도 거의 비슷한 수준으로 인식합니다.

문제는 문자 인식이 아닌 필드 식별에 있습니다. OCR은 "John Smith"를 페이지의 문자로 읽습니다. 이 텍스트가 고객 이름인지, 공급업체 이름인지, 배송처 연락처인지, 승인 관리자인지 알지 못합니다. 이러한 관계는 문서의 레이아웃에 의해 정의됩니다. John Smith가 "청구처:", "배송처:", 또는 "발신처:" 옆에 인쇄될 수 있으며, 기존 OCR의 하향식 문자 파이프라인은 공급업체마다 레이아웃이 다를 때 레이블을 관련 값에 연결할 수 없습니다.

이것이 템플릿 기반 시스템이 공급업체 레이아웃별로 별도의 좌표 맵을 필요로 하는 이유입니다. 템플릿은 "고객 이름은 픽셀 좌표 (450, 320)에 있습니다."라고 말합니다. 새 공급업체가 고객 이름을 (520, 280)에 배치하면 템플릿은 빈 공간이나 잘못된 필드를 캡처합니다. 문제는 공급업체 수에 따라 확장됩니다. 공급업체가 20개이면 20개의 템플릿을 구축하고 유지 관리해야 합니다. 200개이면 템플릿 유지 관리가 전업 업무가 됩니다.

이 실패의 비용은 종종 감지되지 않기 때문에 교활합니다. 잘못 매핑된 이름 필드는 형식 오류를 발생시키지 않습니다. "Sarah Chen"은 고객 필드에 있든 공급업체 필드에 있든 유효한 이름입니다. 실수는 나중에 지불이 잘못된 업체로 가거나 보고서가 거래를 잘못된 상대방으로 그룹화할 때 표면화됩니다.

품목 및 표 — OCR이 구조를 잃는 곳

표는 전통적인 OCR이 가장 크게 실패하는 영역이며, 거의 모든 업무 문서(송장 라인 항목, 구매 주문 세부 정보, 경비 보고서 내역, 은행 거래 명세서 행)에 등장합니다. 문제는 구조적인 데 있습니다. OCR 엔진은 읽기 순서(왼쪽에서 오른쪽, 위에서 아래)에 따라 문자를 선형 스트림으로 출력합니다. 5개의 행이 있는 3열 표는 단일 텍스트 조각 시퀀스로 평탄화되고, 어떤 값이 어떤 헤더에 속하는지를 정의하는 열 경계는 사라집니다.

실제 벤치마크는 그 피해를 수치로 입증합니다. 복잡한 표 레이아웃(셀 병합, 중첩 헤더, 일관되지 않은 열 너비)에서 전통적인 OCR의 행 수준 정확도는 60~80%로 떨어집니다. "수량" 열에 속해야 할 값이 "단가" 열에 들어갑니다. 두 줄로 설명된 행이 두 개의 개별 항목으로 분할됩니다. OCR이 열 구분선을 숫자 "1"로 혼동하여 소수점이 한 자리씩 이동합니다.

이는 문자 인식 실패가 아닙니다. OCR 엔진은 개별 문자("5", "pcs", "$12.50")를 올바르게 읽지만, 다운스트림 시스템은 어떤 문자가 어떤 행과 열에 속하는지 재구성할 방법이 없습니다. 출력은 뒤섞인 텍스트 덩어리로, 행별로 수동 재구성이 필요합니다.

템플릿 기반 접근 방식은 "라인 아이템 테이블은 Y=600에서 시작하여 Y=900에서 끝난다"와 같이 테이블 영역을 정의하여 이 문제를 해결하려고 합니다. 하지만 테이블 높이는 라인 아이템 수에 따라 달라집니다. 동일한 공급업체의 1줄 주문과 20줄 주문은 완전히 다른 길이의 테이블을 생성합니다. 템플릿의 고정 영역은 테이블의 일부만 캡처하거나, 더 나쁜 경우 테이블 아래의 관련 없는 텍스트를 마지막 행으로 끌어옵니다. 테이블 데이터를 구조화된 스프레드시트로 추출하는 실용적인 가이드에서 중요한 변수는 추출 엔진이 테이블 구조를 의미론적으로 이해하는지 여부입니다. 단순히 경계 상자 내의 문자를 읽는 것이 아닙니다.

체크박스, 스탬프, 혼합 콘텐츠 — 기존 OCR이 볼 수 없는 것

기존 OCR이 실패하지 않는 문서 요소 범주가 있습니다. 단순히 전혀 감지할 수 없습니다. 이러한 요소는 출력을 생성하지 않거나, 쓰레기 문자를 생성하거나, 최악의 경우 인접한 텍스트 필드의 추출을 오염시킵니다.

체크박스. 체크된 상자(✓)와 체크되지 않은 상자(☐)는 사람의 눈에는 시각적으로 구별되지만, 기존 OCR 엔진에게는 둘 다 감지 임계값 근처의 대비가 낮은 덩어리입니다. OCR은 하나를 얼룩으로, 다른 하나를 "아무것도 아님"으로 등록하거나, 체크 표시를 잘못된 문자("V", "7" 또는 임의의 글리프)로 읽을 수 있습니다. "이 상자가 체크되었습니다"라는 의도는 절대 캡처되지 않습니다. 체크박스 필드에 의존하는 양식(보험 신청서, 검사 보고서, 규정 준수 체크리스트)은 OCR이 문서를 처리한 후 모든 체크박스를 100% 수동 검토해야 합니다.

도장과 워터마크. 송장 본문 위에 겹쳐진 "PAID" 도장, 계약서 페이지 전체에 표시된 "CONFIDENTIAL" 워터마크, 구매 주문서 위에 중첩된 빨간 회사 직인 — 이 모든 것은 동일한 공간 영역에 두 개의 시각 정보 레이어가 존재하게 만듭니다. 기존 OCR은 전경과 배경을 분리할 수 없습니다. 단일한 노이즈가 있는 이미지 영역으로 인식하여 왜곡된 텍스트를 출력하거나 아무것도 출력하지 못합니다. 도장 텍스트와 문서 본문 텍스트 모두 읽을 수 없게 됩니다.

혼합 콘텐츠. 컬러 배경에 인쇄된 텍스트, 어두운 헤더의 흰색 텍스트, 음영 처리된 표 셀 안의 데이터 값은 모두 OCR 엔진이 필요한 대비 임계값을 낮춥니다. "Invoice"라고 적힌 흰색 텍스트가 있는 진한 파란색 헤더 막대는 빈칸으로 나올 수 있습니다. 엔진의 이진화 단계가 전체 영역을 검은색으로 변환하여 흰색 텍스트를 잃어버리기 때문입니다. 밝은 회색 교차 행 띠에 인쇄된 금액은 회색 배경과 검은색 텍스트 사이의 대비가 엔진의 감도 곡선 아래로 떨어지면 문자가 누락될 수 있습니다.

이러한 실패는 표나 필기체 문제와 근본적으로 다릅니다. 표는 OCR이 구조를 잃어버리기 때문에 실패합니다. 체크박스와 도장은 OCR이 처음부터 감지하지 못하기 때문에 실패합니다. 이 차이는 수정 방법에 중요합니다. 망가진 표는 후처리할 수 있지만, 추출되지 않은 것은 후처리할 수 없습니다.

필기체 — 30~60% 급락

손글씨 인식은 OCR에서 가장 어려운 문제이며, 정확도 수치가 이를 반영합니다. 기존 OCR 엔진의 경우, 제한된 문자 상자 안에 인쇄체로 쓴 손글씨는 약 75%의 문자 정확도를 보입니다. 필기체의 경우 정확도가 50% 이하로 떨어집니다. 이는 깔끔하게 작성된 학습 샘플이 아닌, 실제 서류 처리 파이프라인에서 OCRSolutions의 생산 벤치마킹을 통해 얻은 데이터입니다.

그 이유는 기계적입니다. 기존 OCR은 개별 글리프를 알려진 문자 모양 데이터베이스와 패턴 매칭하여 작동합니다. 인쇄체 "A"는 항상 인쇄체 "A"처럼 보입니다. 약간의 글꼴 변형은 있지만, 문자 골격은 일관됩니다. 그러나 손글씨 "A"는 일관된 골격이 없습니다. 기울기, 획 굵기, 합자 연결, 글자 간격, 기준선 흔들림은 필기자마다 다르며, 같은 필기자가 한 페이지 내에서 쓴 글씨에서도 자주 다릅니다. 안정적인 패턴이 없으면 고정된 글리프 데이터베이스에 대한 패턴 매칭은 실패합니다.

필기체는 모든 문제를 더 악화시킵니다. 글자가 연결되면 엔진은 한 문자가 끝나고 다음 문자가 시작되는 지점을 판단할 수 없습니다. 연결된 "tion" 시퀀스는 문자 데이터베이스에 일치하는 것이 없는 하나의 분화되지 않은 글리프가 됩니다. 필기체에 대한 일반적인 OCR 출력은 무작위 문자 문자열입니다. 예를 들어 "total"이 "totl"로, "January"가 "Jnury"로 인식되는데, 이는 엔진이 인쇄체 OCR을 신뢰할 수 있게 만드는 시각적 분할 단서 없이 개별 문자 모양을 추측하기 때문입니다.

실질적인 결과는 서명된 배송 명세서, 수기로 작성된 검사 양식, 연필로 적힌 시간 기록부처럼 필기 요소가 포함된 문서 워크플로우는 OCR이 완료된 후에도 수동 데이터 입력 단계가 필요하다는 것입니다. 수동 입력을 없애기 위해 만들어진 도구는 인쇄된 부분만 처리할 수 있고, 사람이 손으로 쓴 모든 내용은 여전히 원본을 읽는 사람이 직접 입력해야 합니다. 수기 양식을 디지털 텍스트로 변환하는 것처럼 필기 문서를 다루는 워크플로우에서는 추출 엔진의 선택에 따라 전체 문서가 자동으로 처리되거나 인쇄된 헤더만 살아남는지가 결정됩니다.

AI 추출이 필드 유형별로 다르게 처리하는 이유

AI 기반 추출은 단일한 차별화되지 않은 메커니즘으로 이러한 모든 문제를 해결하지 않습니다. 각 필드 유형은 서로 다른 이유로 실패하며, AI 추출은 각 이유에 대해 서로 다른 기능으로 대응합니다. 마치 정비사가 개스킷 누수와 전기 결함을 엔진 성능 저하라는 동일한 증상에도 다르게 수리하는 것과 같습니다.

이름과 주소 (맥락 문제): AI 비전 모델은 문서 구조와 각 텍스트 조각의 의미를 이해하며 문서를 위에서 아래로 읽습니다. ImageToTable.ai 같은 도구에서 사용자 정의 열 추출을 구성할 때 — "고객 이름", "공급업체 주소", "청구서 번호" 같은 필드 이름을 입력하면 — AI는 픽셀 좌표를 찾지 않습니다. 대신 의미적 설명과 일치하는 값을 문서에서 스캔합니다. "청구 대상:" 옆에 있는 "John Smith"는 페이지 상의 위치와 관계없이 고객 이름으로 매핑됩니다. 템플릿, 좌표 맵, 공급업체가 청구서를 재설계할 때의 재구축이 필요 없습니다. 이 메커니즘이 다중 공급업체 문서 배치에서 템플릿 기반 정확도 60%와 AI 추출 95%+ 사이의 격차를 해소합니다.

라인 항목과 표 (구조 문제): AI 비전 모델은 페이지를 텍스트 스트림으로 평탄화하지 않고 공간 레이아웃(열, 행, 병합 셀, 중첩 헤더)의 내부 표현을 유지합니다. 청구서에서 라인 항목을 추출할 때 모델은 표 영역을 식별하고, 행과 열로 분할하며, 각 셀 값을 해당 열 헤더와 연결합니다. 출력은 기존 OCR이 버리는 표 구조를 보존합니다. 이로 인해 복잡한 레이아웃에서 행 수준 정확도가 60–80%에서 90%+ 범위로 향상됩니다.

체크박스와 혼합 콘텐츠 (감지 문제): AI 비전 모델은 텍스트로 변환하기 전에 문서를 이미지로 처리합니다. 즉, 사람이 읽는 것처럼 체크박스, 도장, 워터마크를 주변 텍스트와 구분되는 별도의 시각적 요소로 "볼" 수 있습니다. 체크된 박스는 무작위 글리프가 아닌 체크 표시로 인식됩니다. 텍스트 위에 겹쳐진 도장은 별도 레이어로 식별되며, 모델은 그 아래에 있어야 할 텍스트를 추론하여 추출할 수 있습니다.

필기체 인식(패턴 실패)의 경우: 수백만 개의 필기 샘플로 학습된 AI 모델은 글자 골격을 단순히 매칭하는 것이 아니라, 획 패턴 뒤에 숨은 의도를 이해하여 문자를 인식합니다. 개별 문자 인식이 놓친 부분은 문맥이 채워줍니다. 송장 하단의 "Amount Due" 필드에 "Totl"이라고 적혀 있으면, 모델은 갑자기 "a"를 인식해서가 아니라, 해당 레이블과 위치로 보아 "Totl"이 반드시 "Total"이어야 한다고 판단합니다. 이러한 문맥 기반 보정 덕분에 필기체 인식 정확도가 50%에서 블록체의 경우 85~93%, 필기체의 경우 75~85%로 향상됩니다.

이러한 메커니즘은 어느 것도 마법이 아닙니다. 각각은 극한 조건(심하게 훼손된 스캔, 사람조차 읽기 어려운 필기체, 눈에 띄는 열 경계가 없는 표)에서는 실패합니다. 하지만 각 메커니즘은 기존 OCR이 해결하지 못하는 특정 실패 모드를 정확히 겨냥합니다. 모든 필드 유형에 걸친 누적 효과는 문서 배치를 "40% 수동 검토 필요"에서 "5% 수동 검토 필요"로 바꿔놓습니다.

직접 시도해보면 그 차이를 즉시 확인할 수 있습니다. 아래 데모는 위에서 논의한 동일한 필드 유형(날짜, 금액, 공급업체명, 라인 항목, 세금)이 포함된 송장을 AI 추출 파이프라인을 통해 처리합니다. 템플릿, 좌표 매핑, 또는 원하는 열 이름을 입력하는 것 외의 사전 구성이 전혀 필요 없습니다.

OCR 감사 방법: 어떤 필드 수정 비용이 가장 많이 드는가

현재 문서 처리 파이프라인을 운영 중이라면, 전체 정확도 비율이 아닌 필드 유형별 수정 비용을 측정하는 것이 가장 유용합니다. 95%의 전체 정확도는 대시보드에서 괜찮아 보이지만, 필드별 분석은 오류의 5%가 어디에 집중되어 있는지와 그 오류를 수정하는 데 실제로 드는 비용을 알려줍니다.

현재 추출 파이프라인에서 필드 수준 정확도 감사를 실행하는 방법은 다음과 같습니다:

팀이 다중 공급업체 송장을 처리하는 기존 OCR 파이프라인에서 이 감사를 실행하면 일관된 패턴이 나타납니다. 라인 항목과 테이블이 가장 많은 수정 시간을 소모합니다. 오류 수가 가장 많아서가 아니라(필기체가 그 범주에서 1위), 각 테이블 오류가 원본 문서에서 행과 열의 관계를 재구성해야 하기 때문입니다. 500개의 송장에서 각각 5개의 라인 항목이 있을 때 20%의 테이블 오류율은 수동으로 재구성해야 할 500개의 행을 의미합니다. 행당 2분이면 16시간의 수정 시간이 소요됩니다. 이는 OCR이 자동으로 처리해야 할 배치에 대해 이틀 이상의 전체 작업 시간에 해당합니다.

달러 금액과 날짜는 원시 오류율이 낮음에도 불구하고 두 번째로 비용이 많이 드는 범주입니다. 놓친 오류의 결과가 크기 때문입니다. 잘못된 송장 합계가 ERP로 넘어가면 조정 불일치가 발생하여, 이를 해결하는 데 드는 비용이 필드 수준 수정으로 잡았을 때보다 훨씬 더 큽니다. 이러한 필드 수준 실패가 전체 파이프라인 비효율성으로 어떻게 집계되는지에 대한 광범위한 관점은 AI OCR 대 기존 OCR 정확도 벤치마크 분석과 AI 데이터 입력 정확도 기대치 설정에 대한 실용 가이드를 참조하세요.

어떤 필드 유형이 팀의 시간을 잡아먹는지 파악했다면, 다음 질문은 추출 엔진이 해당 특정 필드 유형을 더 잘 처리할 수 있는지 여부입니다. 병목 현상이 테이블 구조라면, 의미론적 테이블 이해가 없는 엔진으로 전환하는 것은 같은 문제를 다른 문제로 대체하는 것에 불과합니다. 병목 현상이 필기체나 체크박스라면, 이를 감지할 수 없는 엔진은 절대 개선되지 않습니다. 감사는 추출이 실패하고 있다는 사실뿐만 아니라 어디서 실패하는지 알려줍니다. 그리고 그 위치가 업그레이드가 실제로 병목 현상을 해결하는지, 아니면 같은 오류 로그의 로고만 바꾸는지를 결정합니다.

자주 묻는 질문

전통적인 OCR은 문서 유형에 따라 성능 차이가 있나요?

네, 그렇습니다. 전통적인 OCR은 깨끗하고 인쇄된 단일 컬럼 텍스트 문서(계약서, 편지, 단일 출처의 표준화된 양식)에서 우수한 성능을 보입니다. 표, 필기체, 혼합 글꼴, 낮은 대비 또는 출처별 레이아웃 차이가 있는 문서에서는 정확도가 떨어집니다. 그 차이는 미미하지 않습니다. 타자기로 작성된 편지는 필드 정확도 98%로 추출될 수 있지만, 품목별 표가 포함된 다중 공급업체 송장 배치는 60~85%로 추출됩니다.

더 높은 해상도로 스캔하면 전통적인 OCR 정확도를 높일 수 있나요?

어느 정도까지는 가능합니다. 300 DPI(표준 권장 사항)로 스캔하면 150 DPI나 멀리서 찍은 스마트폰 사진보다 문자 인식이 향상됩니다. 하지만 해상도 향상은 문자 수준 오류에만 영향을 미칠 뿐, 생산 파이프라인에서 수정 시간의 대부분을 차지하는 구조적 오류(표, 필드 매핑, 체크박스)에는 아무런 영향을 미치지 않습니다. 깨진 표의 선명한 이미지는 여전히 깨진 표일 뿐입니다.

어떤 필드 유형이 추출 시스템에 가장 어려운가요?

필기체, 특히 필기체는 AI 기반 추출을 포함한 모든 시스템에서 가장 어려운 필드 유형으로 남아 있습니다. 다양한 필기체 데이터 세트로 훈련된 AI 모델은 인쇄체에서 85~93%, 필기체에서 75~85%의 정확도를 달성하는데, 이는 전통적인 OCR의 30~60%에 비해 상당히 개선된 수치이지만 99%는 아닙니다. 필기체 필드에 중요한 데이터(결제 금액, 환자 이름, 규정 준수 확인 값)가 포함된 워크플로우의 경우, 신뢰도가 낮은 추출에 대한 사람의 검토(Human-in-the-loop)가 여전히 가장 안전한 접근 방식입니다.

ImageToTable.ai는 필기체 문서를 처리할 수 있나요?

ImageToTable.ai는 동일 문서 내에서 필기, 인쇄 텍스트, 체크박스, 도장, 표 구조를 모두 인식할 수 있는 비전-언어 모델을 사용합니다. 필기 인식 정확도는 가독성과 필체에 따라 달라집니다 — 깔끔한 인쇄체는 안정적으로 추출되나, 심하게 흘린 필기체는 수동 확인이 필요할 수 있습니다. 모델은 문서의 어느 영역을 읽었는지 시각적 단서를 제공하므로, 문서 전체를 다시 읽지 않고도 필기 입력란을 빠르게 확인할 수 있습니다. 문서가 주로 필기로 작성된 경우, 확장 전에 소규모 배치 테스트를 통해 특정 필기 샘플에 대한 정확도를 먼저 측정해 보시기 바랍니다.

ImageToTable.ai는 기존 OCR과 표 추출 방식이 어떻게 다른가요?

기존 OCR은 선형 텍스트 스트림을 출력합니다. 표는 평면화됩니다. ImageToTable.ai는 문서를 시각적 레이아웃으로 처리하여 표 영역을 감지하고, 행과 열을 분할하며, 각 셀 값을 해당 열 헤더와 연결합니다. 출력은 표 구조를 유지합니다 — 각 행은 출력 스프레드시트의 행이 되고, 각 열은 사용자가 지정한 열 이름에 매핑됩니다. 이는 템플릿 없이 작동하므로, 동일 공급업체의 5행 인보이스와 20행 인보이스 모두 표 높이와 관계없이 정확하게 추출됩니다. 기존 방식과의 차이점에 대한 자세한 설명은 AI 데이터 입력 개요를 참조하세요.