OCR vs 문서 추출 — 글자는 데이터가 아닌 이유

송장 한 더미를 스캔하고, OCR 도구에 돌린 다음, 그러고도 여전히 숫자를 손으로 스프레드시트에 옮겨 적고 있는 자신을 발견한 적이 있다면, 이미 이 글이 다루는 간극을 몸소 느껴 본 셈입니다. OCR은 제 일을 했습니다 — 페이지의 그림을 텍스트로 바꿔 주었으니까요. 하지만 텍스트는 데이터가 아닙니다. 1,250.00이라는 글자가 페이지 어딘가에 있다는 사실만으로는, 그것이 소계도 세금도 지난달 잔액도 아닌 지급해야 할 총액이라는 점을 알 수 없습니다.

바로 그 마지막 한 구간 — “여기 페이지에 적힌 단어들이 있습니다”에서 “여기 총액, 거래처, 그리고 모든 품목 내역이 라벨이 붙은 채 바로 쓸 수 있게 준비되어 있습니다”로 가는 구간 — 이 문서 추출입니다. 이 글에서는 그 차이를 쉬운 말로 설명하고, 각각이 어디에 들어맞는지 보여 주며, 여러분의 워크플로에 실제로 어느 쪽이 필요한지 가려내도록 돕습니다.

OCR이 실제로 하는 일

OCR — 광학 문자 인식 — 은 단 하나의 일을 합니다. 텍스트의 이미지를 보고 그 텍스트를 출력하는 것입니다. 스캔한 영수증을 넣으면 그것을 다시 텍스트로 돌려줍니다 — 가맹점 이름, 품목 내역, 총액, 날짜 — 대략 읽는 순서대로, 한 줄로 이어진 글자 더미로 말입니다.

이건 몇 가지 일에는 분명히 유용합니다.

• 스캔한 PDF를 검색 가능하게 만들기. 사진으로 찍은 문서에서 Ctrl-F를 쓸 수 있게 해 주는 것이 바로 OCR입니다.
• 접근성. 스크린 리더는 OCR이 만들어 내는 텍스트 레이어가 필요합니다.
• 전문 검색용 아카이브. 나중에 내용으로 문서를 찾기만 하면 된다면, OCR로 충분합니다.

OCR이 하지 못하는 일은 문서를 이해하는 것입니다. 어느 숫자가 총액이고 어느 것이 세금인지 모릅니다. 가운데 세 줄이 품목 내역이고 맨 아래 줄이 합계라는 것을 모릅니다. “Acme Corp”가 거래처이고 “Jane Smith”가 담당자라는 것을 모릅니다. 그저 글자만 넘겨주고, 의미는 여러분 몫으로 남겨 둡니다.

문서 추출이 더해 주는 것

문서 추출은 OCR이 끝나는 지점에서 시작합니다. 페이지의 내용을 받아 이름과 자료형이 있는 항목 — 스프레드시트, 데이터베이스, 또는 다른 시스템에 그대로 넣을 수 있는 구조화된 객체 — 로 돌려줍니다.

{
  "invoice_number": "INV-2026-0412",
  "issue_date": "2026-05-30",
  "vendor": "Acme Corp",
  "total_due": 1250.00,
  "currency": "USD",
  "line_items": [
    { "description": "Design work", "quantity": 10, "unit_price": 100.00 },
    { "description": "Hosting", "quantity": 1, "unit_price": 250.00 }
  ]
}

OCR이 만든 텍스트와 이것 사이에서 세 가지가 달라졌습니다.

1. 값에 라벨이 붙습니다. total_due는 그저 페이지에 우연히 있는 숫자가 아니라 총액입니다. 어느 것이 무엇인지 여러분이 가려낼 필요가 없습니다 — 추출이 이미 했으니까요.
2. 구조가 보존됩니다. 품목 내역은 납작하게 뭉개진 덩어리가 아니라 행의 목록으로 돌아옵니다. 하나만 있는 것(송장 번호)과 여러 개 있는 것(품목 내역)이 분리되어 있습니다.
3. 자료형이 정규화됩니다. 1250.00은 문자열 "$1,250.00"이 아니라 숫자입니다. 2026-05-30은 문서에 어떤 형식으로 인쇄되었든 정렬 가능한 날짜입니다. 먼저 무언가를 정리할 필요 없이 계산과 필터링을 할 수 있습니다.

이 모든 차이를 한 단어로 줄이면 이렇습니다. OCR은 글자를 주고, 추출은 데이터를 줍니다.

나란히 놓고 본 비교

	OCR	문서 추출
출력	이어진 텍스트	이름과 자료형이 있는 항목 (JSON / CSV / Excel)
문서를 이해하는가?	아니요 — 그냥 받아쓸 뿐	예 — 총액 vs 소계 vs 세금을 구분
구조	납작한 텍스트, 읽는 순서	목록, 표, 중첩을 보존
자료형	모든 것이 문자열	숫자, 날짜, 불리언이 정규화됨
새 레이아웃	작동함 (그냥 읽으니까)	거래처별 템플릿 없이도 작동
적합한 용도	검색, 아카이브, 접근성	데이터를 도구와 워크플로에 투입
여전히 다시 입력해야 하나?	보통 예	아니요

대부분의 팀에 가장 중요한 행은 마지막 행입니다. 숫자로 무언가를 하는 것 — 대사하고, 합산하고, 회계 시스템에 밀어 넣는 것 — 이 목표라면, OCR은 다시 입력하는 단계를 여전히 여러분 앞에 남겨 둡니다. 추출은 그것을 없앱니다.

”하지만 이미 OCR이 있는데 — 그걸로 충분하지 않나요?”

이것이 가장 흔한 질문이고, 솔직한 답은 이렇습니다. 그다음에 무엇을 하느냐에 전적으로 달려 있습니다.

문서를 찾아서 읽기만 하면 된다면, OCR로 충분합니다 — 쓰지도 않을 복잡함을 더하지 마세요. 하지만 사람이 OCR 출력을 읽고 그 값을 다른 어딘가에 입력하고 있다면, 바로 그 입력 단계가 추출이 존재하는 이유입니다. 신호는 간단합니다. 화면에서 숫자를 베껴 다른 화면에 옮겨 적고 있나요? 그렇다면, 추출이 자동으로 하는 일을 손으로 하고 있는 것입니다.

이와 관련된 함정 하나는 정규식으로 OCR 위에 추출을 직접 만드는 것입니다 — “TOTAL로 시작하는 줄을 찾아서, 그 뒤의 숫자를 가져와라.” 첫 번째 거래처에서는 작동하지만 두 번째에서는 깨집니다. 다음 송장은 대신 “Amount Due”라고 적혀 있거나, 총액을 다른 자리에 놓거나, 표가 두 페이지에 걸쳐 이어지기 때문입니다. 새 레이아웃마다 새 규칙이 필요합니다. 바로 그 쳇바퀴가, 템플릿 기반 및 정규식 기반 방식이 몇 가지 문서 형식을 넘어서면 확장되지 못하는 이유입니다.

요즘의 문서 추출은 무엇이 다른가

이전 세대의 추출 도구는 레이아웃마다 템플릿이 필요했습니다 — 샘플 문서에 상자를 그려 가며 “송장 번호는 항상 여기, 총액은 항상 저기”라고 지정해 줘야 했습니다. 이는 모든 문서가 똑같이 생겼을 때만 작동하는데, 거래처나 은행, 거래 상대방이 둘 이상 되는 순간 거의 사실이 아니게 됩니다.

레이아웃을 이해하는 추출은 사람이 읽는 방식으로 문서를 읽습니다 — 항목이 페이지 어디에 자리하는지가 아니라, 항목이 무엇을 의미하는지 이해함으로써 말입니다. 새로운 송장 레이아웃은 설정할 템플릿 없이 첫 시도부터 작동합니다. 표가 12페이지에 걸쳐 넘쳐흐르는 은행 명세서도 깔끔한 하나의 목록으로 돌아옵니다. 두 언어가 섞인 세관 문서는 각 값을 원래의 문자 체계 그대로 유지합니다. 같은 방식이 영수증, 계약서, 신분증, 이력서, 검사 결과지에도 똑같이 적용됩니다 — 서로 다른 문서, 같은 발상입니다. 여러분이 원하는 것을 설명하면, 엔진이 그것을 찾아냅니다.

“원하는 것을 설명한다”의 실전판이 궁금하다면, 그것만 다룬 글을 따로 썼습니다. 좋은 추출 스키마를 작성하는 법입니다.

결과를 검증하는 건 어떻게 하나요?

원본 OCR에서 구조화된 항목으로 넘어가는 데에는 한 가지 타당한 걱정이 있습니다. 도구가 문서를 그저 받아쓰는 대신 해석할 때, 그 해석이 제대로 되었는지 어떻게 확인하느냐는 것입니다.

답은 출처 추적입니다. Ztract가 추출하는 모든 값은 원본 페이지에서의 정확한 위치에 닻을 내리고 있습니다. 출력에서 total_due를 클릭하면 원본 문서의 해당 지점에 불이 들어옵니다 — 그래서 숫자를 검증하는 일이 뒤지는 게 아니라 한 번 흘긋 보는 일이 됩니다. 이상해 보이는 항목을 훑어보고, 그중 무엇이든 한 번의 클릭으로 고치고(수정은 무료이며 — 페이지로 차감되는 것은 추출뿐입니다), 그러면 끝입니다. 원본을 직접 읽는 감사 가능성을 잃지 않으면서도 자동화의 속도를 얻습니다.

그래서 어느 쪽이 필요한가요?

빠른 결정 가이드입니다.

• 스캔한 문서를 검색하거나 보관해야 한다 → OCR로 충분합니다.
• 문서가 스크린 리더로 접근 가능해야 한다 → OCR로 충분합니다.
• 사람이 문서를 읽고 그 값을 스프레드시트, ERP, 또는 데이터베이스에 입력하고 있다 → 문서 추출이 필요합니다.
• OCR과 정규식을 함께 써 봤는데 레이아웃이 바뀔 때마다 깨진다 → 더 많은 규칙이 아니라 레이아웃을 이해하는 추출이 필요합니다.
• 추출된 모든 값이 원본까지 거슬러 감사 가능해야 한다 → 나란히 보여 주는 뷰어처럼, 출처 추적이 있는 추출이 필요합니다.

Ztract에 도달하는 대부분의 팀은 OCR로 시작했다가, 다시 입력하는 벽에 부딪혔고, 빠진 조각이 더 나은 문자 인식이 아니라 — 그 글자를 라벨이 붙은 데이터로 바꾸는 일이었음을 깨달았습니다.

여러분의 문서로 그 차이를 직접 시험해 보세요

이 간극을 가장 빠르게 체감하는 방법은, 여러분이 실제로 다루는 문서를 추출에 돌려 보고 구조화된 출력 — 라벨이 붙은 항목, 진짜 숫자, 행으로 정리된 품목 내역 — 을 텍스트 더미 대신 들여다보는 것입니다. 새 계정에는 30페이지 무료가 제공되며, 신용카드도 필요 없고, 가장 까다로운 레이아웃 몇 개를 시험해 보기에 충분합니다.

그리고 OCR과 추출 중 어느 것이 맞는 도구인지 확신이 서지 않는 워크플로가 있다면, 저희에게 알려 주세요 — 엉뚱한 것을 파느니, 맞는 접근법을 고르도록 돕는 편이 낫습니다.