핵심 답변
OCR의 기본 질문은 “이 이미지에 어떤 글자가 있는가?”입니다. Document AI가 다루는 범위는 보통 그보다 넓습니다. “그 글자가 어디에 있고, 어떤 문단·표·필드에 속하며, 다른 정보와 어떻게 연결되는가?”를 구조화합니다. 다만 ‘Document AI’라는 이름의 범위는 업체와 제품마다 다르므로 실제 기능을 확인해야 합니다.
OCR은 문자 인식의 출발점입니다
스캔 이미지에는 사람 눈에 글자가 보여도 컴퓨터가 바로 검색할 수 있는 문자 데이터가 없을 수 있습니다. OCR은 글자 영역을 찾고 그 모양을 문자로 변환합니다. 최신 OCR 서비스는 단어와 줄뿐 아니라 위치, 방향, confidence 같은 부가정보도 제공할 수 있습니다.
그러나 OCR이 `100,000,000원`을 정확히 읽었다고 해서 그 숫자가 예정가격인지 계약금액인지 자동으로 알게 되는 것은 아닙니다. 그 의미는 주변 제목, 표의 헤더, 문단과의 관계에서 결정됩니다.
Layout은 ‘어디에 있는가’를 다룹니다
문서에서 같은 글자라도 페이지 상단의 제목인지, 표 셀 안의 값인지, 각주인지에 따라 역할이 달라집니다. Layout analysis는 텍스트와 시각 요소의 위치, 문단 경계, 페이지 헤더·푸터, 표 영역 같은 구조를 찾아 이런 차이를 표현합니다.
Microsoft Document Intelligence의 Layout 모델이 paragraph role, bounding polygon, table cell의 row/column과 span 정보를 별도로 반환하고, Google Document AI가 textAnchor와 boundingPoly를 함께 제공하는 것은 문자와 위치를 구분해 다루기 위해서입니다.
Structure는 ‘무엇과 연결되는가’를 다룹니다
레이아웃으로 위치를 알았다고 해도 관계를 만들어야 할 수 있습니다. 표에서는 헤더와 값, 양식에서는 라벨과 입력값, 문서에서는 제목과 하위 문단을 연결해야 합니다. Google의 Layout Parser는 제목·표·목록 같은 요소와 상위 제목의 문맥을 유지한 채 구조화된 chunk를 만드는 기능을 설명하고 있습니다.
즉 Document AI의 핵심은 글자 인식 자체보다 문서를 다시 사용할 수 있는 구조로 만드는 일에 가깝습니다.
단계를 나누면 OCR과 Document AI의 차이가 더 명확합니다
| 단계 | 주요 질문 | 예시 결과 |
|---|---|---|
| OCR | 무슨 글자인가? | 문자, 단어, 줄 |
| Layout | 어디에 있는가? | 좌표, 문단, 제목, 표 영역 |
| Structure | 무엇과 연결되는가? | 행·열·헤더, 제목-본문 관계 |
| Extraction | 어떤 값인가? | 계약금액, 날짜, 업체명 같은 필드 |
| Classification | 어떤 종류의 문서인가? | 계약서, 청구서, 증명서 등 |
| Validation | 결과를 믿어도 되는가? | confidence, 규칙 검증, 사람 검토 |
| Traceability | 원문 어디에서 나왔는가? | 페이지·좌표·원문 참조 |
어떤 제품은 이 단계를 거의 모두 제공하고, 어떤 제품은 OCR과 기본 레이아웃까지만 제공합니다. 따라서 제품명보다 어느 단계까지 결과를 제공하는가를 보는 편이 정확합니다.
OCR 정확도 99%가 문서 이해 99%를 뜻하지는 않습니다
문자 단위 정확도가 높아도 중요한 한 글자가 틀리면 업무 의미는 크게 달라질 수 있습니다. 원문 `100,000,000원`을 `10,000,000원`으로 읽었다면 대부분의 문자는 맞지만 금액은 열 배 차이가 납니다.
반대로 모든 문자를 정확히 읽어도 관계가 틀릴 수 있습니다. `계약기간 2026.01.01~2026.12.31`과 `보증기간 2027.01.01~2027.12.31`을 모두 정확히 OCR했지만 라벨과 날짜 연결이 뒤바뀌면 문서 데이터는 잘못됩니다.
문서 정확도는 한 숫자로 설명하기 어렵습니다. 문자 인식, 레이아웃, 표 구조, 필드 연결, 원문 추적성을 서로 다른 품질 층으로 보는 것이 좋습니다.
Confidence는 자동판정이 아니라 검토 우선순위에 가깝습니다
Document AI 제품은 문자나 추출 필드에 confidence score를 제공할 수 있습니다. Google의 Custom Extractor 문서도 confidence를 사람이 다시 검토할 항목을 결정하는 신호로 활용할 수 있다고 설명합니다. 그러나 높은 confidence가 정답을 보장하거나 낮은 confidence가 오답을 의미하지는 않습니다.
중요한 금액·날짜·자격조건처럼 오류 비용이 큰 값은 confidence가 높더라도 규칙 검증이나 원문 대조가 필요할 수 있습니다.
디지털 문서는 OCR 없이도 Document AI 대상이 될 수 있습니다
Document AI를 “스캔 문서에 OCR 하는 기술”로만 이해하면 범위가 너무 좁습니다. DOCX, HWPX, 디지털 PDF처럼 이미 기계 판독 가능한 문서는 원본 구조와 텍스트를 직접 읽을 수 있습니다. 이 경우 중요한 문제는 OCR이 아니라 문단·표·스타일·읽기 순서·원문 위치를 어떻게 구조화할지입니다.
즉 OCR은 Document AI 파이프라인의 한 입력 경로일 수 있지만, 모든 문서가 OCR을 거쳐야 하는 것은 아닙니다.
RAG에서는 파싱과 chunking도 Document AI 품질의 일부가 됩니다
긴 문서를 검색형 AI에 넣기 위해 작은 chunk로 나눌 때 고정된 글자 수만 기준으로 자르면 제목과 본문, 표 헤더와 값이 서로 다른 chunk로 갈라질 수 있습니다. Google의 Layout Parser가 상위 제목 같은 문맥을 chunk에 함께 넣는 기능을 제공하는 것도 이러한 문제를 줄이기 위해서입니다.
따라서 RAG에서 답이 틀렸다고 항상 생성 모델만 문제인 것은 아닙니다. 원문 파싱 → 구조 복원 → chunking → retrieval → generation 중 어느 단계에서 정보가 끊겼는지 확인해야 합니다.
도구를 고를 때는 ‘AI냐 OCR이냐’보다 필요한 결과를 먼저 정합니다
| 목적 | 주요 필요 기능 |
|---|---|
| 스캔 문서 검색 | OCR + 기본 읽기 순서 |
| 표 데이터 수집 | 표 탐지 + 셀·헤더·병합 구조 |
| 양식 필드 추출 | 키-값·entity extraction + validation |
| RAG 검색 | layout-aware parsing + 구조 기반 chunking |
| 검토 가능한 보고서 | 추출 결과 + 원문 페이지·위치 추적 |
필요한 결과가 단순 검색용 텍스트인지, 계약 조건처럼 사람이 다시 검토해야 하는 구조화 정보인지에 따라 필요한 기술 수준이 달라집니다.
DOGURANG은 인식보다 ‘연결과 검증’까지를 중요하게 봅니다
DOGURANG에서 문서 AI의 목표는 문자를 최대한 많이 읽는 것에 그치지 않습니다. 원본 형식에서 얻은 텍스트와 구조, 페이지 위치를 연결하고 중요한 정보가 어디에서 나왔는지 다시 확인할 수 있게 유지하는 것이 실제 업무 검토에 더 중요합니다.
스캔 문서의 입력 단계는 스캔 PDF와 OCR에서, 가장 대표적인 구조 문제인 표는 표가 많은 문서는 왜 텍스트 추출만으로 부족한가에서 자세히 다룹니다.
공식 참고자료
- Google Cloud — Document AI overview
- Google Cloud — Extraction overview
- Google Cloud — Layout Parser와 구조 기반 chunking
- Microsoft Learn — Read OCR 모델
- Microsoft Learn — Layout 모델
Document AI, Document Intelligence, IDP 같은 명칭은 제품마다 포함 기능이 다릅니다. 이름보다 현재 버전의 실제 입력 형식, 출력 구조, 검증 기능을 확인해야 합니다.