핵심 답변
표에서 중요한 것은 셀 안의 글자를 얼마나 많이 읽었는지만이 아닙니다. 어떤 값이 어느 행·열·헤더와 연결되는지가 함께 보존되어야 합니다. 텍스트 추출이 100%여도 병합셀, 다단 헤더, 빈 셀, 여러 페이지에 이어진 표의 관계를 잃으면 실제 정보는 잘못 해석될 수 있습니다.
표의 의미는 값보다 ‘관계’에서 만들어집니다
일반 문장은 단어의 순서만 어느 정도 유지되어도 읽을 수 있습니다. 하지만 표는 위치가 의미의 일부입니다. 같은 “12.5”라는 숫자도 어느 행과 열에 놓였는지에 따라 매출액, 비율, 수량, 점수처럼 전혀 다른 뜻이 됩니다.
그래서 표를 처리할 때는 값(value)과 관계(relation)를 분리해서 봐야 합니다. 값은 셀 안의 문자열이고, 관계는 행·열 인덱스, 헤더, 병합 범위, 주변 제목, 페이지 같은 구조 정보입니다.
단순한 표에서는 텍스트만으로도 그럴듯해 보입니다
| 품목 | 수량 | 단가 | 금액 |
|---|---|---|---|
| A | 10 | 5,000 | 50,000 |
| B | 20 | 7,000 | 140,000 |
이 표를 `품목 수량 단가 금액 A 10 5,000 50,000 B 20 7,000 140,000`처럼 평문으로 바꿔도 사람은 어느 정도 원래 구조를 추측할 수 있습니다. 그래서 작은 샘플에서는 단순 텍스트 추출이 충분해 보이기도 합니다.
문제는 실제 업무 문서에 병합 헤더, 빈 셀, 여러 줄 문단, 소계·합계, 주석, 다중 페이지가 들어가기 시작할 때입니다.
병합셀과 다단 헤더가 들어가면 텍스트 순서만으로는 부족합니다
| 품목 | 2025 | 2026 | ||
|---|---|---|---|---|
| 수량 | 금액 | 수량 | 금액 | |
| A | 10 | 500 | 15 | 750 |
여기서 `2025 수량 금액 2026 수량 금액 A 10 500 15 750`이라는 문자열만 남으면, 헤더의 계층 관계를 알고 있는 사람은 복원할 수 있어도 프로그램은 별도 규칙 없이는 어느 금액이 어느 연도에 속하는지 확실히 알기 어렵습니다.
Microsoft Document Intelligence가 표 결과에 row/column index, row span, column span, cell bounding region과 header 정보를 별도로 제공하고, Google Document AI가 header rows와 body rows, cell 구조를 분리해 표현하는 이유가 바로 이런 관계 때문입니다.
빈 셀도 정보입니다
표에서 빈 칸은 “아무 의미가 없음”과 같지 않을 수 있습니다. 해당 항목이 없음, 미입력, 앞 셀의 값이 계속 적용됨, 병합된 영역의 일부임 등 문맥에 따라 다른 의미를 가질 수 있습니다. 단순 텍스트 추출에서는 빈 셀이 문자열을 만들지 않기 때문에 열 위치가 한 칸씩 당겨지는 문제가 생길 수 있습니다.
예를 들어 `A | 10 | [빈칸] | 50`이 `A 10 50`으로 평탄화되면 50이 세 번째 열 값인지 네 번째 열 값인지 알기 어려워집니다. 그래서 셀 좌표와 빈 셀의 존재 자체를 보존하는 것이 중요합니다.
표가 여러 페이지로 이어지면 ‘같은 표’인지 판단해야 합니다
긴 입찰내역서, 재무자료, 시험결과표는 한 표가 여러 페이지로 나뉘어 출력될 수 있습니다. 다음 페이지에서 헤더가 반복되기도 하고, 헤더 없이 데이터 행만 이어지기도 합니다. 페이지별로 표를 독립 추출하면 하나의 논리적 표가 여러 개로 쪼개질 수 있습니다.
반대로 서로 다른 두 표가 비슷한 열 구조를 가진다고 무조건 합치면 안 됩니다. 표의 제목, 열 구조, 페이지 연속성, 주변 문단, 헤더 반복 여부 같은 신호를 함께 봐야 합니다. Google의 Layout Parser도 복잡한 문서를 구조화하고 제목·표·목록의 문맥을 유지하는 것을 RAG 품질의 핵심으로 설명합니다.
표 품질은 네 단계로 나누어 보면 이해하기 쉽습니다
| 단계 | 확인 질문 | 실패 예 |
|---|---|---|
| Text completeness | 셀 안의 글자와 숫자가 존재하는가? | 금액 한 자리 누락 |
| Cell completeness | 필요한 셀이 빠지거나 합쳐지지 않았는가? | 빈 셀 삭제, 두 셀 결합 |
| Structure correctness | 행·열·병합·헤더 관계가 맞는가? | 2025/2026 헤더 연결 오류 |
| Meaning correctness | 값이 실제 의미와 올바르게 연결되는가? | 수량을 단가로 해석 |
문자 인식률 하나로는 아래 단계의 오류를 충분히 설명할 수 없습니다. 표를 후속 AI나 데이터베이스에 넣으려면 최소한 셀과 구조 수준까지 별도로 검증해야 합니다.
RAG와 LLM에서도 표 파싱은 모델 이전의 문제입니다
PDF를 RAG에 넣었는데 본문 질문은 잘 맞고 표 질문만 틀리는 경우, 먼저 LLM이나 임베딩 모델만 바꾸기 쉽습니다. 하지만 파싱 단계에서 헤더와 값의 관계가 이미 사라졌다면 검색 시스템에는 올바른 정답 구조 자체가 들어가 있지 않습니다.
예를 들어 `2026 금액 750`이 아니라 `금액 500 750`처럼 저장되었다면, 검색은 두 숫자를 모두 찾을 수 있어도 어느 숫자가 2026년 값인지 판단하기 어렵습니다. AI는 입력 단계에서 잃어버린 구조를 항상 안전하게 복원해 주는 장치가 아닙니다.
Markdown으로 변환하면 해결될까? — Markdown 표는 후속 LLM 처리에 편리하지만, 원본 셀 구조를 먼저 잘못 읽었다면 잘못된 관계를 보기 좋게 표현할 뿐입니다. 출력 형식보다 원본 구조 복원이 먼저입니다.
좌표와 원문 위치는 검토 가능성을 높입니다
표 데이터를 사용하다가 이상한 값이 발견됐을 때 원문 어느 페이지의 어느 셀에서 나온 값인지 다시 확인할 수 있으면 검증이 훨씬 쉬워집니다. 그래서 많은 Document AI 시스템은 텍스트와 함께 bounding polygon이나 page anchor 같은 위치 정보를 제공합니다.
좌표가 곧 의미를 보장하는 것은 아니지만, 구조 결과 → 원문 위치 → 사람이 보는 페이지를 연결하는 데 중요한 단서가 됩니다. 특히 계약금액, 규격 수치, 평가점수처럼 오류 비용이 큰 값은 원문으로 돌아갈 수 있는 경로가 유용합니다.
실제 표 문서를 처리할 때 무엇을 확인할까?
| 항목 | 확인 내용 |
|---|---|
| 표 탐지 | 원문 표 개수와 추출 표 개수가 크게 다르지 않은가 |
| 헤더 | 상위·하위 헤더와 반복 헤더가 올바르게 연결되는가 |
| 병합 | row span·column span이 의미대로 복원되는가 |
| 빈 셀 | 빈 칸이 삭제되어 열이 이동하지 않았는가 |
| 다페이지 | 이어지는 표와 별개 표를 올바르게 구분했는가 |
| 좌표 | 중요 셀을 원문 페이지에서 다시 찾을 수 있는가 |
| 검증 | 대표 표와 중요 수치를 원본과 표본 대조했는가 |
DOGURANG은 표를 ‘텍스트가 들어 있는 네모’로 보지 않습니다
DOGURANG에서 표는 행·열·셀·헤더·병합과 원문 위치가 연결된 구조입니다. 따라서 표 안의 문자열을 얻는 것뿐 아니라 그 문자열이 어떤 셀과 헤더 관계에서 나왔는지, 중요한 값이 원문에서 다시 확인 가능한지를 함께 다루는 것이 중요합니다.
스캔된 표에서는 여기에 OCR 단계까지 추가됩니다. 스캔 PDF와 OCR과 OCR과 Document AI의 차이를 함께 보면 처리 단계가 왜 나뉘는지 이해하기 쉽습니다.
공식 참고자료
- Google Cloud — Document AI Layout Parser
- Google Cloud — Document AI 처리 결과의 텍스트·레이아웃 정보
- Google Cloud — Document 구조와 Table/TableCell 스키마
- Microsoft Learn — Document Intelligence Layout 모델
Document AI 제품별 표 지원 범위와 다중 페이지 처리 방식은 버전과 입력 형식에 따라 다릅니다. 실제 적용 전에는 사용 중인 모델의 현재 문서를 확인해야 합니다.