AI가 PDF를 제대로 읽게 만드는 문서 전처리가 중요한 이유

PDF를 생성형 AI에 첨부하면 내용을 요약하고 질문에도 답해줍니다. 그렇다면 기업이 보유한 계약서, 보고서, 업무 매뉴얼, 기술문서 같은 PDF도 그대로 AI에 연결하면 될까요?

한두 개의 PDF를 사람이 직접 첨부해 내용을 확인하는 용도라면 별도의 복잡한 전처리 없이도 충분할 수 있습니다. 하지만 수백·수천 개의 문서를 지식베이스로 만들고, RAG나 AI Agent가 필요한 근거를 찾아 답하도록 하려면 이야기가 달라집니다. PDF에는 문장뿐 아니라 제목과 본문, 표의 행과 열, 이미지와 캡션, 각주, 페이지 번호처럼 서로 관계를 맺고 있는 정보가 들어 있기 때문입니다.

문서 전처리는 이런 PDF의 텍스트와 구조를 AI가 검색하고 활용하기 좋은 데이터로 바꾸는 과정입니다. PDF에서 글자만 추출하는 것이 아니라 필요에 따라 문자를 인식하고, 제목·문단·표 등의 구조를 구분하고, 검색하기 적절한 단위로 나누고, 문서의 출처와 버전 같은 정보까지 함께 정리합니다. AI 기반 문서 검색이나 RAG에서는 이렇게 준비된 데이터의 상태가 이후 검색과 답변 품질에 영향을 줄 수 있습니다.

AI가 PDF를 읽을 수 있는데도 전처리가 필요한 이유

사람이 PDF를 읽을 때는 글자만 보는 것이 아닙니다. 제목 아래에 어떤 내용이 이어지는지, 표의 어느 열과 행이 연결되는지, 특정 그림이 어느 설명에 해당하는지를 문서의 배치와 구조를 통해 함께 이해합니다. 반면 PDF에서 텍스트만 순서대로 가져오면 이런 관계가 사라질 수 있습니다.

예를 들어 제품 A / 2025년 매출 12억 원 / 2026년 매출 15억 원이라는 표를 사람이 보면 각 숫자가 어느 제품과 연도에 해당하는지 바로 이해할 수 있습니다. 하지만 추출 결과가 제품 A B 2025년 매출 12억 8억 2026년 매출 15억 7억처럼 평평한 문자열로 바뀐다면 글자는 모두 남아 있어도 데이터 사이의 관계는 알아보기 어려워집니다.

실제로 문서 기반 검색·RAG를 위한 기술 자료에서도 일반적인 텍스트 추출 과정에서 제목, 표, 목록과 같은 문서 구조가 사라지면 원래 문맥을 보존하기 어렵다고 설명합니다. 그래서 최근의 문서 처리 방식은 단순한 텍스트 추출보다 제목, 문단, 표, 이미지 등 문서 요소와 이들 사이의 관계를 함께 보존하는 방향으로 발전하고 있습니다.

따라서 AI가 PDF 파일을 열 수 있다는 것과, PDF 안의 정보를 AI가 안정적으로 검색하고 활용할 수 있다는 것은 다른 문제입니다.

PDF를 AI에 활용하려면 어떤 전처리가 필요할까요?

모든 PDF에 똑같은 전처리가 필요한 것은 아닙니다. 가장 먼저 봐야 할 것은 문서의 상태와 AI를 사용하는 목적입니다. 텍스트 위주의 짧은 보고서를 일회성으로 요약하는 것과 수만 건의 계약서·규정·기술문서를 검색하는 AI 지식베이스를 만드는 것은 필요한 처리 수준이 다릅니다.

첫 번째는 문서 안의 내용을 정확하게 읽는 과정입니다. PDF가 텍스트 기반으로 만들어졌다면 기존 텍스트를 가져올 수 있지만, 종이 문서를 스캔한 PDF는 페이지 자체가 이미지일 수 있어 OCR이나 문서 인식 기술이 필요합니다. 다만 글자를 읽어낸 것만으로 전처리가 끝나는 것은 아닙니다. 계약금액 100,000,000원이라는 문자를 정확하게 추출했더라도 이것이 어느 계약서의 어떤 항목에 해당하는지까지 연결되어야 실제 검색과 업무에서 활용하기 쉽습니다. OCR과 문서 정보 구조화의 차이가 궁금하다면 「지능형 문서 처리(IDP)란? OCR과의 차이부터 문서 업무 자동화까지」에서 더 자세히 확인할 수 있습니다.

두 번째는 문서의 구조를 유지하는 과정입니다. 기업 문서에서는 위치와 구조 자체가 의미를 가지는 경우가 많습니다. 재무제표의 숫자는 계정과목과 연도, 열 제목을 함께 봐야 하고, 검사성적서의 측정값은 품목·LOT·검사항목·기준값과 연결되어야 의미가 생깁니다. 보고서 역시 제목과 소제목의 계층이 유지되어야 특정 문장이 어떤 주제를 설명하는지 파악하기 쉽습니다. 따라서 문서 전처리에서는 제목, 문단, 목록, 표의 행과 열, 이미지와 캡션 등 필요한 구조를 구분하고 그 관계를 가능한 한 유지하는 것이 중요합니다. 특히 양식과 데이터 위치가 계속 달라지는 문서를 처리하는 방법이 궁금하다면 「금융권 비정형 문서 자동화: 양식도 형식도 제각각인 서류, 어떻게 일관되게 처리할까?」를 함께 읽어볼 수 있습니다.

세 번째는 필요한 데이터를 일관된 형태로 정리하는 과정입니다. 같은 의미의 정보도 문서마다 사업자등록번호, 사업자 번호, 사업자 No.처럼 다른 방식으로 표현될 수 있고 날짜나 금액의 형식도 제각각일 수 있습니다. 문서를 AI 검색뿐 아니라 분석이나 후속 업무에도 활용하려면 이러한 정보를 일정한 기준으로 구조화하거나 정규화할 필요가 있습니다. 이 단계는 모든 RAG에 반드시 필요한 것은 아니지만, 문서 종류가 다양하거나 특정 필드를 기준으로 검색·비교해야 하는 업무에서는 중요해집니다.

네 번째는 문서의 맥락을 설명하는 메타데이터를 함께 관리하는 과정입니다. 문서명, 문서 유형, 작성일, 시행일, 담당 부서, 버전, 원문 위치, 접근 권한과 같은 정보가 대표적입니다. 예를 들어 사용자가 현재 적용되는 출장비 기준을 질문한다면 내용이 비슷한 여러 규정 가운데 최신 시행 문서를 구분할 수 있어야 합니다. 특히 공문서처럼 시행 시점, 원문 추적, 버전 관리가 중요한 환경의 문서 처리 방식은 「공문서 지식베이스 구축, HWP·PDF 행정문서를 AI가 활용하게 만드는 방법」에서 별도로 다루고 있습니다.

긴 PDF는 왜 적절한 단위로 나눠야 할까요?

문서를 정확하게 읽고 구조화했다면 다음으로 중요한 것은 필요한 정보를 어떻게 찾게 만들 것인가입니다. RAG에서는 일반적으로 긴 문서를 검색하기 적절한 작은 단위로 나누어 저장하는데, 이를 청킹(Chunking)이라고 합니다.

청킹은 단순히 긴 문서를 일정한 글자 수로 잘라내는 작업만을 의미하지 않습니다. 너무 크게 나누면 하나의 Chunk 안에 서로 다른 내용이 많이 포함되어 필요한 정보를 정확하게 찾기 어려울 수 있고, 반대로 지나치게 작게 나누면 문장의 의미를 이해하는 데 필요한 앞뒤 맥락이 사라질 수 있습니다. 실제 RAG 설계 가이드에서도 문서의 구조와 의미를 고려해 관련 내용이 함께 유지되도록 Chunk를 구성하는 것이 중요하다고 설명합니다.

예를 들어 제4조 지원 대상은 다음과 같다라는 문장과 실제 지원 대상 목록을 서로 다른 Chunk로 완전히 분리하면, 검색 과정에서 조항 제목만 나오거나 대상 목록만 검색될 수 있습니다. 표 제목과 실제 표 데이터가 떨어져도 비슷한 문제가 생깁니다. 그래서 제목과 본문, 조항과 세부 항목, 표의 헤더와 데이터처럼 서로 연결된 정보는 그 관계를 가능한 한 유지하면서 나누는 것이 좋습니다.

즉, 좋은 청킹의 기준은 얼마나 일정하게 자르는지가 아니라, 검색된 일부 내용만 보더라도 원래 의미를 이해할 수 있는가에 가깝습니다.

전처리를 많이 할수록 좋은 것은 아닙니다

문서 전처리가 중요하다고 해서 모든 PDF를 복잡하게 처리할 필요는 없습니다. 목적에 비해 지나치게 많은 처리 단계를 추가하면 구축과 운영만 복잡해질 수 있습니다.

따라서 먼저 AI에게 이 문서로 무엇을 시키려는지를 정하는 것이 좋습니다. PDF 한두 개를 요약하는 것이 목적이라면 원본만으로 충분할 수 있지만, 여러 문서에서 특정 근거를 찾아야 하거나 서로 다른 문서를 비교해야 한다면 구조와 메타데이터가 중요해집니다. 추출한 값을 실제 시스템에 입력하거나 업무 판단에 사용하려면 데이터 구조화와 검증까지 범위가 넓어질 수 있습니다.

AI 답변이 이상하다면 모델보다 문서를 먼저 확인해볼 수 있습니다

문서 기반 AI의 답변 품질이 기대보다 낮으면 LLM이나 프롬프트부터 바꾸기 쉽습니다. 하지만 정답이 원문에 있는데도 AI가 계속 엉뚱한 내용을 찾는다면, 원천 문서가 어떤 형태로 검색되고 있는지도 함께 확인해야 합니다.

예를 들어 필요한 표가 텍스트로 제대로 변환되지 않았거나, 최신 문서와 이전 문서를 구분할 메타데이터가 없거나, 질문의 정답이 여러 Chunk에 잘려 흩어져 있다면 검색 단계에서부터 필요한 근거를 가져오지 못할 수 있습니다. 결국 문서 기반 AI에서는 원본 문서 → 문서 인식 → 구조화 → 청킹과 메타데이터 → 검색 → LLM 답변이 하나의 흐름으로 연결됩니다. RAG 설계에서도 문서의 구조와 표·이미지 같은 요소를 분석한 뒤 적절한 청킹 전략을 선택하는 전처리 단계가 중요하게 다뤄집니다.

실제로 수만 건의 기업·기관 문서를 AI 지식베이스로 활용하려면 파일을 한곳에 모으는 것만으로 끝나지 않습니다. Worktro의 「5만 2천건의 인증 심사 문서, 어떻게 AI 지식베이스로 구축했을까?」에서는 분산된 대규모 문서를 자연어로 탐색하고 활용할 수 있는 지식베이스로 만든 실제 사례를 확인할 수 있습니다.

결국 문서 전처리의 목적은 PDF를 다른 파일 형식으로 바꾸는 데 있지 않습니다. 사람이 읽도록 만들어진 문서의 내용과 구조를 AI가 검색하고 활용할 수 있는 데이터로 준비하는 과정에 있습니다. PDF를 AI에 연결했는데 원하는 답을 제대로 찾지 못하고 있다면 어떤 모델을 사용할지에 앞서, AI가 참고하고 있는 문서 데이터가 어떤 상태인지부터 살펴볼 필요가 있습니다.

자주 묻는 질문

PDF는 반드시 전처리한 뒤 AI에 넣어야 하나요?

아닙니다. 텍스트 위주의 PDF 몇 개를 요약하거나 일회성으로 질문하는 경우에는 원본 PDF만으로도 충분할 수 있습니다. 많은 문서를 반복적으로 검색하거나 RAG·AI Agent의 지식으로 사용해야 할 때 문서 구조, 청킹, 메타데이터 등의 전처리가 더 중요해집니다.

PDF 전처리와 OCR은 같은 것인가요?

같지 않습니다. OCR은 이미지나 스캔 문서에서 문자를 인식하는 기술입니다. 문서 전처리는 목적에 따라 OCR뿐 아니라 문서 구조 분석, 데이터 구조화, 메타데이터 구성, 청킹 등 AI가 문서를 활용하기 좋은 상태로 만드는 여러 과정을 포함할 수 있습니다.

RAG에서 청킹은 왜 필요한가요?

긴 문서에서 질문과 관련된 정보를 효율적으로 검색하기 위해 문서를 적절한 단위로 나눕니다. 이때 일정한 길이로 자르는 것뿐 아니라 제목, 문단, 조항, 표와 같이 의미가 연결된 구조를 고려하는 것이 중요합니다.

표가 많은 PDF도 AI가 활용할 수 있나요?

활용할 수 있지만 표의 텍스트만 추출하는 것으로 충분하지 않을 수 있습니다. 행·열, 헤더, 병합 셀 등 데이터 간 관계가 중요한 문서라면 표 구조를 보존하는 방식의 전처리가 필요할 수 있습니다.

문서 전처리를 하면 AI 답변이 정확해지나요?

문서 전처리는 AI가 검색할 수 있는 원천 데이터의 품질을 높이는 데 도움이 됩니다. 다만 최종 답변 품질은 문서 데이터뿐 아니라 검색 방식, 임베딩, 모델, 프롬프트 등 전체 구성에 영향을 받기 때문에 전처리만으로 정확도가 결정되지는 않습니다.

References

Process documents with Gemini layout parser | Google Cloud Documentation

Develop a RAG Solution on Azure - Preparation Phase | Microsoft Learn 

Develop a RAG Solution on Azure - Chunking Phase | Microsoft Learn