AI가 읽은 표에서 원문의 자리를 지키는 법

PDF를 AI용 문서로 바꿀 때 표의 병합 구조와 원문 위치를 어떻게 보존할까. Docling의 문서 모델을 바탕으로 읽기용 텍스트, 구조화 자료, 페이지 근거를 연결하는 업무 설계를 살펴본다.

GPT Image 2로 만든 개념 일러스트레이션. 실제 문서나 제품 화면을 재현한 이미지는 아니다.

교육 운영팀이 여러 PDF에서 강좌 정보를 모아 안내문을 만든다고 가정해 보자. AI가 야간 과정의 정원을 잘못 적었다. 추출된 문서를 확인하면 숫자는 모두 들어 있다. 빠진 것은 글자가 아니라 숫자 위에 있던 묶음 제목이다. 주간 과정의 정원과 야간 과정의 정원이 같은 줄로 풀리면서, 어떤 값이 어느 과정에 속하는지 흐려졌다.

이런 오류는 답변 모델을 바꾸기 전에 문서를 변환한 자리에서 살펴봐야 한다. 사람이 표를 읽을 때는 위치, 병합된 제목, 각주를 함께 본다. AI에게 전달하는 자료도 그 관계를 설명하거나 되짚을 수 있어야 한다. 변환이 끝났다는 판단에는 텍스트 파일이 생성됐는지뿐 아니라, 그 텍스트를 원문의 어느 부분과 대조할 수 있는지가 들어가야 한다.

숫자가 남아도 표의 관계는 사라질 수 있다

가상의 운영표에 ‘주간’과 ‘야간’이라는 큰 열 제목이 있고, 각 제목 아래 ‘정원’과 ‘추가 신청’이 있다고 하자. 한 강좌의 값은 순서대로 20, 3, 12, 2다. ‘야간 정원’이라는 질문의 답은 12다. 네 숫자를 정확하게 인식했더라도 상위 제목과 하위 열의 연결을 놓치면 20이나 2를 답할 수 있다. 문자 인식의 정확성과 표 해석의 정확성은 별도로 확인할 필요가 있다.

표 안의 빈칸도 한 가지 의미로 정리하기 어렵다. 원래 비어 있는 값일 수도 있고, 위쪽 셀이 여러 행에 걸쳐 병합된 결과일 수도 있다. 병합 영역을 평범한 빈칸으로만 저장하면 둘을 구별할 단서가 줄어든다. 후속 모델에게 ‘빈칸을 적절히 채워라’고 맡기는 방식은 문서에 없던 값을 보충하는 판단까지 변환 작업에 섞을 수 있다.

Docling의 공식 직렬화 문서는 이 차이를 구체적으로 설명한다. 내부 표 모델의 셀 병합 정보는 JSON과 HTML로 표현할 수 있지만, 기본 Markdown 표에서는 병합된 셀의 시작 위치에만 글자를 쓰고 나머지 자리를 빈칸으로 나타낸다. 병합 구조가 중요한 작업에서는 출력 형식을 선택할 때 이 차이를 고려해야 한다. 이는 Markdown을 쓰지 말라는 뜻이 아니라, 읽기 편한 출력 하나에 모든 구조가 남는다고 가정하지 말라는 뜻이다. Docling 직렬화 문서

여기서 확인한 것은 형식의 표현 능력이다. JSON으로 저장했다고 잘못 인식한 표가 자동으로 교정되지는 않는다. 올바르게 보존할 구조를 처음부터 잘못 추출했다면, 더 풍부한 형식은 그 오류도 충실히 보존할 수 있다.

읽기용 문서와 근거용 문서를 함께 남긴다

Docling의 DoclingDocument는 본문, 표, 그림과 문서 계층을 담는 공통 모델이다. 문서 항목 사이의 연결과 순서로 구조를 표현하며, 얻을 수 있는 경우 항목의 위치와 출처 정보도 담는다. 이 중간 표현을 유지하면 검색에 쓸 텍스트와 원문을 대조할 자료를 같은 변환 결과에서 만들 수 있다. Docling 문서 모델

2026년 10월 25일 확인한 docling-core 기본 브랜치의 TableCell 정의에는 행·열 병합 범위, 셀의 시작·끝 위치, 열 머리글과 행 머리글 여부를 나타내는 필드가 있다. 셀의 위치 상자는 없을 수도 있도록 정의돼 있다. 따라서 ‘필드가 존재한다’와 ‘이번 문서의 모든 셀에 믿을 만한 값이 채워졌다’를 구분해야 한다. 확인한 코드 리비전의 표 모델

업무에 적용한다면 원본 PDF, 구조화된 변환 결과, 검색용 문서를 연결해 보관하는 방식을 제안할 수 있다. 검색용 문서는 간결한 Markdown으로 만들되, 각 청크에서 원본 문서의 버전과 대응 항목을 찾을 수 있게 한다. 표를 설명하는 문장을 따로 만들었다면 그 문장이 추출 원문인지, 모델이 해석해서 쓴 문장인지도 구분한다. 이 보관 방식은 필자의 제안이며 Docling이 모든 연결을 자동으로 완성한다는 설명은 아니다.

예를 들어 ‘야간 과정 정원은 12명’이라는 문장은 검색하기 편하다. 여기에 같은 표의 위치와 해당 셀의 머리글 관계가 연결돼 있으면 검토자가 문장의 타당성을 확인할 수 있다. 반대로 문장만 남기면 잘못된 해석이 다음 요약과 검색을 거치며 원문처럼 굳을 수 있다. 검색용 청크의 문맥 보존은 이 연결 위에서 이어지는 작업이다.

페이지를 찾는 것과 답을 입증하는 것

출처에 ‘7쪽’이라고 적는 것만으로는 검토가 끝나지 않는다. 한 페이지에 표가 여러 개 있을 수 있고, 페이지 번호가 같아도 개정판에서 내용은 달라질 수 있다. 답변의 숫자와 그 숫자를 한정하는 머리글·단위·각주를 함께 확인할 수 있어야 한다.

현재 코드의 ProvenanceItem은 페이지 번호, 위치 상자, 문자 범위를 담는다. 위치 상자를 정의하는 BoundingBox에는 좌표의 원점도 들어 있다. 이 값들은 원문으로 돌아가는 데 필요한 재료다. 좌표를 화면에 표시할 때는 페이지 크기와 표시 이미지의 크기, 좌표 원점을 맞춰야 한다. 출처 위치 모델, 좌표 모델

공식 시각적 근거 표시 예제는 변환 문서를 JSON으로 보관하고, 검색된 청크의 문서 항목을 따라가 페이지 이미지에 위치 상자를 그린다. 예제 코드는 각 항목의 첫 번째 출처 위치만 사용하는 단순화도 명시한다. 실제 업무에서 표가 여러 페이지에 걸치거나 각주가 다른 위치에 있다면 필요한 근거를 모두 표시하는 처리는 별도로 설계해야 한다. Docling 시각적 근거 표시 예제

강조 상자가 그려졌다는 사실도 답변이 맞다는 보증은 아니다. 검색된 영역을 표시한 것인지, 답변의 특정 주장을 지지하는 영역까지 확인한 것인지 구별해야 한다. 가상의 교육 안내에서는 ‘12’가 있는 칸만 강조하면 충분하지 않다. 그것이 야간 과정의 정원이라는 머리글 관계, 인원의 단위, 적용 조건을 바꾸는 각주까지 검토 범위에 들어간다.

원본 파일의 식별자와 해시, 변환 도구의 버전·설정, 구조화 결과의 식별자를 함께 남기는 것도 이 때문에 유용하다. 같은 이름의 새 PDF로 원본을 바꿔 놓고 이전 좌표를 계속 쓰면 근거 연결은 조용히 어긋난다. 원본이 바뀌었을 때 관련 변환 결과와 검색 청크를 다시 검증하도록 묶는 것이 운영 설계의 과제다.

변환의 종료 조건을 업무 질문으로 정한다

변환 품질을 확인할 때는 쉬운 문단뿐 아니라 업무에서 자주 틀리면 곤란한 구조를 골라야 한다. 다음은 교육 운영표를 도입하는 팀이 사용할 수 있는 검토 예다. 실제 제품의 성능 측정 결과나 보편적인 합격 기준은 아니다.

검토 결과는 오류가 생긴 단계로 돌려보내야 한다. 글자를 틀리게 읽었다면 인식 결과를, 머리글 관계가 깨졌다면 표 구조와 출력 방식을, 원문 표시가 어긋났다면 좌표 변환과 버전 연결을 확인한다. 이 구분이 없으면 모든 문제를 답변 프롬프트의 부족으로 돌리게 된다. 모델을 더 오래 생각하게 해도 입력에서 사라진 관계가 안정적으로 복원된다는 보장은 없다.

전체 문서를 같은 강도로 검토할 필요는 없다. 팀이 실제로 안내·승인·배정에 사용하는 값과 조건부터 원문 대조를 수행하고, 어떤 구조에서 실패가 잦은지 모아 다음 검토 범위를 정할 수 있다. 사람이 수정한 결과는 처음의 변환 결과와 구별해 남겨야 같은 오류가 다시 생겼을 때 원인을 비교할 수 있다.

AI 문서 변환의 성과는 몇 페이지를 텍스트로 만들었는지에만 있지 않다. 사용자가 답변을 검토할 때, 숫자의 의미를 설명하는 원문의 자리까지 얼마나 정확하게 돌아갈 수 있는지도 성과에 포함된다. 문서가 읽기 쉬워지는 과정에서 그 되돌아가는 길을 함께 남겨야 한다.