실무 가이드 · 중상급

PDF·표·이미지를 놓치지 않는 멀티모달 RAG 설계

PDF를 단순 텍스트로 평탄화하지 말고 페이지·섹션·표·그림 단위로 분석해 원문 텍스트, 구조화 데이터, 설명 텍스트, 페이지 좌표를 연결 저장한다. 검색 시 질문 유형에 맞는 표현을 함께 찾고, 답변에는 페이지와 원문 영역을 인용해 사용자가 즉시 검증할 수 있게 한다.

발행 LLM / RAG10분 읽기

30초 답변

PDF RAG의 핵심은 OCR 정확도 하나가 아니라 원문의 구조와 위치를 끝까지 보존하는 것이다. 본문 텍스트만 이어 붙이면 표의 행·열 관계, 차트의 범례, 그림과 설명의 연결, 각 내용이 있던 페이지 위치가 사라진다. 페이지를 분석해 문단, 제목, 표, 그림을 구분하고 각 요소마다 원문 텍스트, 구조화 표현, 검색용 설명, 페이지 번호와 좌표를 함께 저장해야 한다.

권장 흐름은 다음과 같다.

파일 검사 → 페이지 렌더링·OCR → 레이아웃 분석 → 표·그림 추출 → 구조 보존 청킹 → 텍스트·시각 표현 색인 → 질문 유형별 검색 → 원문 좌표 기반 인용

이 글의 핵심

  • PDF는 파일 형식일 뿐 내용이 텍스트인지 스캔 이미지인지 보장하지 않는다. 페이지별로 처리 경로를 판별해야 한다.
  • 표는 셀 텍스트만 모으면 의미가 깨진다. 행·열, 병합 셀, 헤더, 단위, 각주, 다음 페이지 연결을 보존한다.
  • 그림과 차트는 OCR 텍스트, 캡션, 주변 문단, 이미지 설명을 연결하되 생성된 설명과 원문을 구분한다.
  • 모든 검색 단위에 문서 ID, 페이지, 원문 polygon·span, 파서 버전을 저장해야 인용과 재처리가 가능하다.
  • 멀티모달 모델에 PDF 전체를 매번 넣는 방식과, 대규모 문서 검색용 RAG 색인은 목적과 비용 구조가 다르다.

PDF를 먼저 분류해야 하는 이유

같은 PDF 안에도 서로 다른 페이지가 섞일 수 있다.

  • 텍스트 레이어가 있는 전자 문서
  • 스캔 이미지로만 구성된 문서
  • 텍스트 위에 도장·서명·메모가 얹힌 혼합 문서
  • 표와 차트가 대부분인 보고서
  • 두 단 편집, 세로쓰기, 회전된 페이지가 있는 문서

파일 단위로 “텍스트 PDF” 또는 “스캔 PDF”라고 한 번만 판정하면 혼합 문서에서 누락이 생긴다. 페이지별로 텍스트 레이어 존재 여부, 추출 문자량, 이미지 비율, 회전, 비정상 문자 비율을 검사하고 필요한 페이지만 OCR로 보완한다. 단, 추출 문자량이 적다는 이유만으로 표지나 도면 페이지를 오류로 단정하지 않는다.

Microsoft의 Document Intelligence Layout 모델은 텍스트뿐 아니라 페이지, 문단, 표, 그림, 섹션 같은 구조 요소와 위치 정보를 반환한다. Google Cloud의 Gemini layout parser는 제목, 머리말, 꼬리말, 표, 그림을 식별하고 문서 계층을 보존해 RAG용 청크를 만드는 흐름을 설명한다. 제품 선택과 별개로 “텍스트 추출”과 “레이아웃 이해”를 다른 품질 항목으로 봐야 한다.

권장 데이터 모델: 원본, 파생물, 좌표를 분리해 연결한다

하나의 문서 요소를 하나의 문자열로만 저장하지 말고 다음 계층을 둔다.

계층보존할 정보용도
문서원본 URI, 파일 해시, 버전, MIME, ACL변경·삭제·권한 추적
페이지실제 페이지 순번, 표시 페이지 라벨, 폭·높이·회전좌표 변환·뷰어 연결
요소유형, 읽기 순서, 원문 span, polygon, 신뢰도구조 복원·강조 표시
표현원문 텍스트, 정규화 텍스트, HTML/JSON, 이미지 설명검색·생성
관계부모 섹션, 표-캡션, 그림-주변 문단, 연속 표문맥 복원

예시는 다음과 같다.

{
  "element_id": "manual-2026:v3:p12:table-2",
  "source_document_id": "manual-2026",
  "source_version": "v3",
  "page_index": 12,
  "printed_page_label": "10",
  "element_type": "table",
  "section_path": ["4. 유지보수", "4.2 점검 주기"],
  "polygon": [0.08, 0.22, 0.92, 0.22, 0.92, 0.76, 0.08, 0.76],
  "raw_text": "...",
  "structured_ref": "object://parsed/manual-2026/v3/table-2.json",
  "search_text": "점검 대상별 주기와 담당 부서를 정리한 표...",
  "parser_version": "layout-pipeline-2026-07"
}

좌표는 어떤 단위와 원점을 사용하는지 함께 기록한다. 페이지 폭·높이와 회전 정보가 없으면 OCR polygon을 웹 뷰어에 정확히 그릴 수 없다. Azure의 분석 응답 구조 문서는 span이 전체 콘텐츠에서의 논리 위치를, bounding region이 페이지 번호와 polygon을 표현한다고 설명한다.

본문과 레이아웃: 읽기 순서를 검증한다

두 단 보고서를 단순히 좌상단에서 우하단으로 읽으면 왼쪽 열과 오른쪽 열 문장이 섞일 수 있다. 머리말·꼬리말이 모든 청크에 반복되면 검색 결과를 오염시키고, 각주가 본문에서 떨어지면 조건이 사라진다.

다음 기준으로 구조를 정리한다.

  1. 제목과 섹션 계층을 청크 메타데이터에 상속한다.
  2. 반복 머리말·꼬리말·페이지 번호는 원본에는 보존하되 기본 검색 텍스트에서는 제외한다.
  3. 목록 번호, 주의·경고 박스, 각주를 해당 문단과 관계로 연결한다.
  4. 읽기 순서가 비정상인 페이지를 샘플링해 사람이 렌더링 결과와 비교한다.
  5. OCR 정규화본과 원문을 모두 저장해 검색 편의와 인용 정확성을 분리한다.

OCR에서 띄어쓰기와 기호를 정규화할 수 있지만 제품 코드, 수식, 단위, 조항 번호까지 임의로 바꾸면 안 된다. 검색용 정규화 필드와 인용용 원문 필드를 따로 둔다.

표: 텍스트 변환보다 구조 보존이 먼저다

표 질문은 “어떤 값이 있는가”뿐 아니라 “어느 행과 어느 열이 만나는가”를 묻는다. 셀을 줄바꿈으로 이어 붙이면 A 제품 / 3년과 B 제품 / 5년의 대응이 바뀔 수 있다.

표 처리 시 최소한 다음을 저장한다.

  • 행·열 인덱스와 행/열 span
  • 다단 헤더와 반복 헤더
  • 셀 원문, 숫자, 단위
  • 표 제목·캡션·각주
  • 표가 속한 섹션과 주변 설명
  • 페이지와 셀 또는 표 전체 polygon
  • 여러 페이지에 걸친 표의 연결 ID

복잡한 표는 HTML 또는 셀 JSON을 정본으로 두고, 검색을 위해 별도 문장 표현을 만든다. 예를 들어 “모델 AX-7의 정기점검 주기는 6개월이며 담당은 설비팀” 같은 행 단위 문장을 생성할 수 있다. 이 문장은 검색 보조용 파생물이며 원문 값과 대조할 수 있어야 한다. 생성 모델이 표를 요약한 설명은 generated_description으로 표시하고 원문과 섞지 않는다.

Azure Layout 문서는 표의 행·열 수, 셀 인덱스, 병합 정보, bounding region을 제공하고, 최신 Markdown 출력에서 복잡한 표를 HTML 표로 표현한다고 설명한다. 이는 특정 형식을 그대로 채택하라는 뜻보다 병합 셀과 헤더 구조를 잃지 말라는 설계 기준으로 해석할 수 있다.

여러 페이지에 걸친 표는 특히 주의한다. 다음 페이지에 열 헤더만 반복되고 표 제목이 없을 수 있다. 페이지별 추출 결과를 무조건 별도 표로 저장하지 말고 열 수, 헤더, 인접 위치, 캡션, 문서 구조를 기준으로 연결 후보를 만들고 확신이 낮으면 검수 대상으로 보낸다.

그림과 차트: 네 가지 신호를 연결한다

그림 하나에는 서로 다른 정보가 있다.

  1. 이미지 안의 OCR 텍스트
  2. 문서에 적힌 캡션
  3. 그림을 설명하는 앞뒤 문단
  4. 시각 모델이 만든 설명 또는 이미지 임베딩

차트 질문에서 OCR만 사용하면 축·범례·색상 관계를 놓칠 수 있고, 캡션만 사용하면 실제 값의 변화가 사라진다. 반대로 시각 모델 설명만 색인하면 모델이 읽지 못한 값이 사실처럼 굳어질 수 있다. 네 신호를 별도 필드로 유지하고 동일한 figure_id로 연결한다.

검색은 질문에 따라 경로를 달리할 수 있다. “그림 3의 설치 방향”은 캡션·주변 문단과 이미지 표현을 함께 찾고, “2분기 이후 매출 추세”는 차트 설명 후보를 찾은 뒤 원본 이미지를 시각 모델에 다시 제공해 검증한다. 답변에는 “PDF 12쪽, 그림 3”처럼 사용자가 확인할 수 있는 위치를 표시한다.

OpenAI의 file inputs 문서는 비전 기능이 있는 모델에 PDF를 입력하면 추출 텍스트와 각 페이지 이미지를 함께 전달한다고 설명한다. 이는 개별 문서 분석에는 유용하지만, 대규모 문서 모음에서 매 질의마다 PDF 전체를 전달하는 것과는 다르다. 같은 공식 문서도 큰 파일 검색에는 File Search 같은 retrieval 도구를 사용하라고 안내하며, PDF의 텍스트와 페이지 이미지는 토큰 사용량을 늘릴 수 있음을 명시한다.

검색과 답변: 여러 표현을 찾되 하나의 원문으로 귀결한다

멀티모달 색인에는 같은 표나 그림에서 만든 여러 검색 레코드가 존재한다. 검색 결과에서 이들을 독립 근거처럼 세지 말고 source_element_id로 묶는다. 텍스트 검색, 벡터 검색, 이미지 검색이 동일 요소를 찾았다면 점수를 융합하고 답변에는 원본 요소 한 건으로 인용한다.

질문 라우팅 예시는 다음과 같다.

질문검색 대상생성 시 다시 확인할 원본
“해지 절차는?”본문·제목·목록원문 문단과 각주
“표에서 AX-7 보증기간은?”표 행 문장·셀 JSON해당 셀과 헤더
“차트가 보여주는 추세는?”캡션·주변 문단·이미지 설명원본 차트 이미지
“서명란이 비어 있나요?”페이지·영역 후보고해상도 원본 영역

답변 모델에는 필요한 영역만 제공한다. 그러나 잘라낸 이미지에는 섹션명, 표 헤더, 단위처럼 해석에 필요한 주변 영역을 포함한다. 크롭 범위와 원문 좌표를 기록해 사용자가 전체 페이지로 돌아갈 수 있게 한다.

사용자 경험과 실패 시나리오

“답변 숫자는 맞는데 어느 열의 값인지 확인할 수 없습니다”

표를 평문으로 바꾸면서 헤더 관계가 사라진 경우다. 답변 인용을 표 전체가 아니라 셀, 행 헤더, 열 헤더의 조합으로 구성하고 PDF 뷰어에서 해당 영역을 강조한다. 원문 좌표가 없으면 품질 검수도 느려진다.

“PDF 10쪽이라고 했는데 뷰어에서는 12쪽입니다”

표지와 목차 때문에 파일의 실제 page index와 인쇄된 페이지 라벨이 다를 수 있다. 둘을 별도 필드로 저장하고 사용자에게는 “PDF 12쪽(문서 표기 10쪽)”처럼 보여준다.

“스캔 문서의 0과 O, 1과 I가 자꾸 바뀝니다”

OCR 신뢰도가 낮은 식별자를 자동 수정하면 더 위험하다. 원문 이미지, OCR 결과, 정규화 후보를 함께 보관하고 코드·금액·날짜처럼 중요한 필드는 규칙 검증 또는 사람 검수를 거친다. OCR confidence 하나만으로 정답 여부를 판정하지 않는다.

“차트 설명은 그럴듯하지만 실제 범례와 반대입니다”

시각 모델이 만든 설명을 원문처럼 사용한 경우다. 생성 설명임을 표시하고, 범례·축·단위를 포함한 원본 이미지를 답변 시 다시 확인한다. 정밀 수치 질문은 가능하면 표 형태의 원자료나 구조화 데이터로 연결한다.

“문서를 업데이트했는데 예전 페이지가 인용됩니다”

원본 파일 버전과 파생 이미지·OCR·청크 버전이 분리되지 않은 상황이다. 인용에는 문서 버전과 파일 해시를 포함하고, 새 버전 활성화 후 구버전 검색 레코드와 크롭 이미지를 함께 비활성화한다.

실무 체크리스트

  • 페이지별로 텍스트·스캔·혼합 유형과 회전을 판별하는가?
  • 원본 파일 해시, 문서 버전, 파서 버전을 보존하는가?
  • 문단·표·그림마다 페이지 번호, polygon, span, 읽기 순서가 있는가?
  • 페이지 실제 순번과 문서에 인쇄된 페이지 라벨을 구분하는가?
  • 검색용 정규화 텍스트와 인용용 원문을 분리하는가?
  • 표의 행·열, 병합 셀, 헤더, 단위, 캡션, 각주를 보존하는가?
  • 여러 페이지 표의 연결 여부를 검증하는가?
  • 그림의 OCR, 캡션, 주변 문단, 생성 설명을 별도 필드로 관리하는가?
  • 생성된 표·그림 설명을 원문 사실과 구분하는가?
  • 여러 검색 표현을 source_element_id로 중복 제거하는가?
  • 답변 인용에서 원문 페이지와 영역을 바로 열 수 있는가?
  • 낮은 OCR 품질, 회전 표, 두 단 문서, 작은 글자 차트를 평가셋에 포함했는가?
  • 문서 삭제·권한 변경 시 크롭 이미지와 파생 색인도 함께 제거되는가?
  • PDF 전체 전달과 RAG 검색의 비용·지연·보안 차이를 검토했는가?

자주 묻는 질문

Q1. PDF를 Markdown으로 변환하면 멀티모달 RAG가 완성되나요?

아니다. Markdown은 제목과 본문 구조를 표현하는 데 유용하지만 원문 좌표, 이미지 픽셀, 복잡한 병합 표, OCR 신뢰도, 요소 간 관계를 모두 담는 정본으로는 부족할 수 있다. Markdown은 검색·생성용 표현 중 하나로 두고 구조화 JSON과 원문 좌표를 함께 보존하는 편이 안전하다.

Q2. 표도 일반 문단처럼 임베딩하면 되나요?

간단한 2열 표는 가능하지만 복잡한 표에서는 행·열 관계가 손실될 수 있다. 셀 구조를 정본으로 저장하고 행 단위 설명이나 헤더가 포함된 검색 문장을 추가한다. 정확한 값 질문의 답변 단계에서는 검색용 설명이 아니라 원본 셀과 헤더를 다시 확인해야 한다.

Q3. 모든 그림에 이미지 임베딩과 비전 모델 설명이 필요한가요?

아니다. 로고, 장식, 반복 아이콘은 제외할 수 있고 캡션과 주변 문단만으로 충분한 그림도 있다. 차트, 도면, 설치 사진처럼 시각 정보가 답변에 직접 필요한 문서 유형부터 적용하고, 실제 질문 평가셋에서 검색 기여와 비용을 비교한다.

근거 자료

KMWorks AI Tech Lab은 기업 환경에서 검증·운영할 수 있는 AI 시스템 설계 기준을 공유합니다.