OCR과 문서 파싱 비교: Tesseract만으로는 부족할 때

제가 접하는 'OCR이 필요하다'는 티켓 중 상당수는 사실 OCR 관련 문제가 아닙니다. 누군가는 ERP에서 인보이스 총액을 원하거나, 스프레드시트에서 은행 명세서의 거래 내역을 원하거나, CRM에서 계약서의 갱신 날짜를 원하는 경우입니다. 이것은 데이터 문제입니다. OCR은 기껏해야 그 과정 중 한 단계일 뿐입니다.

저는 OCR 및 문서 파싱 도구 비교 사이트인 OCRRank를 운영하고 있으며, 이 구분을 정확히 하는 것이 어떤 도구 질문에 앞서 가장 먼저 묻는 것입니다. 여기 제가 사용하는 프레임워크가 있습니다. 이는 데모에서 작동했던 Tesseract 스크립트를 가지고 있다가 프로덕션 환경에서 계속 문제가 생기는 개발자들을 위해 작성되었습니다.

두 가지 다른 작업

**OCR(광학 문자 인식)**은 픽셀을 문자로 변환합니다. 스캔본이나 휴대폰 사진을 입력하면 텍스트를 출력해 줍니다.

**문서 파싱(Document parsing)**은 레이아웃과 내용을 분석하여 구조화된 데이터를 반환합니다: 이름이 지정된 필드, 테이블, 라인 항목 등을 JSON, CSV 또는 Excel 형태로 제공합니다. 스캔본의 경우 일반적으로 내부적으로 OCR을 실행합니다. 디지털 PDF의 경우에는 아예 OCR이 필요하지 않은 경우가 많습니다.

	OCR	문서 파싱
입력	이미지, 스캔본, 사진, 이미지 전용 PDF	디지털 또는 스캔된 문서
...

유용한 테스트가 있습니다: 만약 성공 측정 기준이 'PDF에서 Ctrl+F 검색이 가능한지'라면, OCR(또는 이미 텍스트 레이어가 있는 PDF)만으로 충분할 가능성이 높습니다. 하지만 그 기준이 '사람이 다시 타이핑하지 않고 데이터를 게시하거나 매칭할 수 있는지'라면, 당신은 OCR 단독 영역을 벗어난 것입니다.

제로 단계: PDF에 애초에 OCR이 필요한가?

많은 팀들이 이미 선택 가능한 텍스트를 포함하고 있는 PDF에 OCR을 실행합니다. 이는 비용 낭비일 뿐만 아니라, 좋은 문자를 재인식하는 과정에서 오히려 데이터를 엉망으로 만들 수 있습니다.

먼저 확인해야 합니다. 이것은 예시적인 개요이며 프로덕션 코드는 아닙니다:

# Illustrative sketch: route pages by whether they have a text layer.
import pdfplumber
import pytesseract
...

이것이 무엇을 제공하는지 주목하세요: 문자열(strings)입니다. 완벽하게 작동하더라도, 어떤 문자열이 공급업체 이름인지, 어떤 숫자들이 어느 항목에 속하는지, 그리고 표의 2페이지가 어디서부터 시작되는지를 알아내는 부분은 여전히 직접 작성해야 합니다. 이 두 번째 파서는 실제 엔지니어링 시간이 대부분 투입되는 곳입니다.

또한 분기(branch)도 주목하세요. 혼합 패킷이 흔합니다 (1페이지는 디지털 원본, 2페이지는 서명된 전시품의 휴대폰 사진). 그리고 코드베이스에 if 스캔됨: tesseract else: pdfplumber가 있다면, 두 개의 파이프라인을 유지보수해야 합니다.

원하는 JSON 구조를 먼저 작성하세요. 도구를 고르기 전에

제가 가장 좋아하는 요령은, 누군가 공급업체 이름을 말하기 전에 필요한 JSON 키들을 화이트보드에 적어두는 것입니다.

키들이 단순히 text와 pages인 경우, 여러분은 OCR 단계에 있는 것입니다:

{
  "pages": [
    { "page": 1, "text": "ACME Supplies Ltd\nInvoice #10482\nDate 03/09/2026\n..." }
...

키들이 다음과 같은 형태인 경우, 여러분은 파싱(parsing) 솔루션을 찾고 있는 것입니다:

{
  "vendor": "ACME Supplies Ltd",
  "invoice_number": "10482",
...

(두 페이로드는 설명용으로 만들어진 것이며, 특정 도구의 출력물은 아닙니다.)

두 번째 형태는 사람이 개입하지 않고도 코드가 문서를 게시(post)하거나, 일치시키거나, 거부할 수 있게 해줍니다. 총액만 나오는 출력으로는 회계 지급(accounts payable) 처리가 불가능합니다. 왜냐하면 PO 라인과 전체 합계에서 잘못된 단가를 일치시킬 수 없기 때문입니다. 송장 데이터 추출 가이드에서는 AP 팀이 실제로 필요로 하는 헤더 및 라인 필드에 대해 더 깊이 다룹니다.

Tesseract만으로 충분할 때가 정말 있는 경우

오픈 소스 OCR이

더 이상 충분하지 않을 때

제 경험상 전환점은 거의 벤치마크 숫자가 아닙니다. 이번 달 세 번째 레이아웃 변경이거나, 페이지를 조용히 누락시키는 첫 스캔된 패킷일 수 있습니다. 이는 단순 OCR에 접착제(glue)만 붙인 수준을 넘어섰다는 신호입니다:

스캔본과 휴대폰 사진이 실제 운영 트래픽으로 나타남
많은 공급업체, 은행 또는 거래 상대방 때문에 템플릿별 스크립트가 계속 실패함
라인 항목(line items), 필드별 신뢰도(per-field confidence), 웹훅(webhooks) 또는 검토 대기열(review queue)이 필요함
누군가가 '추출된 데이터가 틀렸다'고 호출되고, 그 사람이 바로 당신임

Azure Document Intelligence, Amazon Textract, Google Document AI와 같은 클라우드 서비스들이 중간에 자리 잡고 있습니다. 이들은 역량 있는 빌딩 블록이지만, 여전히 IAM(Identity and Access Management), 비동기 작업(async jobs), 재시도(retries) 및 그 출력을 자체 스키마에 매핑하는 것은 사용자의 몫입니다. 저는 Tesseract 대 문서 파싱 API에서 전체 빌드 대 구매 트레이드오프를 작성했습니다.

결정 체크리스트

PDF에서 텍스트 선택이 가능한가요? 그렇다면 파싱 또는 테이블 추출부터 시작하고 OCR은 건너뜁니다.
이미지 전용 페이지인가요? OCR과 파싱 둘 다 필요하거나, 어느 쪽을 사용하든 동일한 스키마를 반환하는 단일 API가 필요합니다.
검색 가능한 텍스트만 필요한가요? OCR만으로 충분할 수 있습니다. 여기서 멈춥니다.
필드, 라인 항목 또는 거래 행(transaction rows)이 필요한가요? 이것은 문서 파싱입니다. 문서 유형에 따라 경로를 선택하세요.
다음 분기에 얼마나 많은 레이아웃 변화가 예상되나요? 안정적인 단일 레이아웃은 DIY 방식에 가깝고, 많거나 불확실한 레이아웃은 관리형(managed) 방식에 가깝습니다.

자체 문서로 테스트할 것들

벤더의 데모 PDF는 설계상 깨끗합니다. 직접 문서를 가져와서 현재 사용 중인 스크립트를 포함하여 모든 옵션으로 동일한 세트를 실행해 보세요:

최소 세 가지 파일: 깨끗한 디지털 PDF 하나, 여러 페이지로 된 표(table) 하나, 그리고 평범하거나 휴대폰으로 찍은 스캔 사진 하나.
페이지 수 비교 (in vs out). 조용한 페이지 누락(Silent page drops)은 가장 흔한 실패 사례 중 하나입니다.
수학 검증. 세 줄의 행을 골라 수량 곱하기 단가와 해당 행 금액이 일치하는지 확인합니다. 그리고 모든 행에 세금(tax)을 더한 값이 총액과 대략적으로 일치하는지도 확인해야 합니다.
이미지와 비교하여 3~5개의 핵심 필드(critical fields)를 직접 점검하세요: ID, 날짜, 합계 금액 등.
데모 뷰어 대신 페이로드(payload)를 요청하세요. 예쁜 PDF 미리 보기의 하이라이트된 텍스트는 UI 기능일 뿐입니다. 백엔드는 객체(objects)와 배열(arrays)가 필요합니다. 만약 스캔 이미지를 JSON으로 변환하는 경우라면, PDF to JSON / OCR API 가이드에서 좋은 응답이 포함해야 할 내용을 나열하고 있습니다.

세 가지 파일 모두를 가장 적은 수작업(babysitting)으로 통과시키는 경로가 여러분의 운영 기본값(production default)입니다.

제가 파악한 내용

저는 OCRRank에서 10가지 관리형 파싱 도구들을 정확도, 개발자 경험(developer experience), 가치, 신뢰도를 기준으로 점수화했습니다. 이때 정확도에 가장 높은 가중치를 두었습니다. 현재 개발자를 위한 제가 꼽는 1위는 DocuPipe (9.7/10)이며, 그 뒤를 Base64.ai (9.1)와 Affinda (9.0)가 따르고 있습니다. Nanonets와 Docsumo는 엔터프라이즈 IDP(Intelligent Document Processing) 및 금융 문서 분야에서 강점을 보입니다. 하지만