RAG PDF와 피디에프 인스펙터 선택법 2026

공식 저장소 설명 기준으로 피디에프 인스펙터는 문서 유형을 약 10~50밀리초 범위에서 분류하고, 텍스트 기반 문서는 약 200밀리초 이내의 로컬 처리를 목표로 합니다. 다만 이 수치는 저장소가 제시한 설명이지 독립 실험 결과가 아닙니다. 따라서 RAG PDF 전처리에서는 피디에프 인스펙터와 광학 문자 인식 중 하나만 고르는 대신, 먼저 분류한 뒤 필요한 페이지만 광학 문자 인식으로 보내는 혼합 라우팅을 기본값으로 잡는 편이 안전합니다. 공식 저장소의 기능 설명

이 글은 처음부터 문서 수집 파이프라인을 설계하는 개발자와 아키텍트에게 적합합니다. 이미 광학 문자 인식을 모든 파일에 적용해 처리 시간이 길어진 팀, 그리고 원격 맥 환경에서 반복 회귀 테스트를 준비하는 운영 책임자도 대상입니다.

마지막 업데이트: 2026년 8월 10일. 피디에프 인스펙터 저장소의 최신 설명과 관련 공식 문서를 확인했습니다. 성능과 정확도는 실제 샘플, 라이브러리 버전, 실행 환경에 따라 달라지므로 고정된 수치로 해석하면 안 됩니다.

품질 지표와 원문 보존

RAG에 넣을 텍스트는 문자가 존재하는지만으로 평가할 수 없습니다. 원문 추출 결과가 문장 순서와 단락 경계를 잃으면 임베딩 단계에서 의미가 분리됩니다. 제목과 본문이 뒤섞이면 검색 결과의 출처 설명도 불안정해집니다.

피디에프 인스펙터의 공식 저장소는 텍스트 기반, 스캔 기반, 이미지 기반, 혼합형 문서를 구분하고 페이지별 광학 문자 인식 경로를 반환하는 기능을 설명합니다. 또한 위치 정보를 활용한 텍스트 추출과 마크다운 변환을 제공한다고 안내합니다. 그러나 이것이 모든 표와 수식을 완전하게 구조화한다는 뜻은 아닙니다. 실제 RAG 구조에 맞는 품질은 별도 샘플로 검증해야 합니다.

일반적인 PDF 파싱 도구도 한계가 있습니다. 파이뮤피디에프 공식 문서는 기본 텍스트 추출이 원문에 기록된 순서를 그대로 반환할 수 있으며, 자연스러운 읽기 순서나 표 추출이 자동으로 보장되지 않는다고 설명합니다. 텍스트 추출의 한계에 대한 공식 문서

RAG PDF 전처리에서는 다음 항목을 별도 점수로 기록해야 합니다.

• 글자 존재율: 빈 페이지나 인식 불능 페이지가 남지 않았는지 확인합니다.
• 단락 보존율: 줄바꿈 때문에 한 문장이 여러 조각으로 쪼개지지 않았는지 봅니다.
• 제목 인식률: 제목과 본문이 같은 단위로 합쳐지지 않았는지 확인합니다.
• 표 보존율: 셀의 행과 열 관계가 유지되는지 검사합니다.
• 출처 추적성: 문서 이름, 페이지 번호, 영역 좌표를 다시 찾을 수 있어야 합니다.
• 검색 회수 품질: 같은 질문에 원문과 관련된 조각이 반복해서 반환되는지 비교합니다.

RAG PDF를 가져오기 전에 반드시 광학 문자 인식을 해야 하는가요?

아닙니다. 페이지에 신뢰할 수 있는 텍스트가 있으면 먼저 원문 추출을 시도해야 합니다. 광학 문자 인식은 스캔 페이지, 빈 텍스트 층, 글자가 깨진 페이지처럼 원문 추출만으로 검색 가능한 텍스트를 만들기 어려운 경우에 적용합니다.

문제는 텍스트 층이 있다고 해서 항상 쓸 만한 것은 아니라는 점입니다. 스캐너가 만든 낮은 품질의 숨은 텍스트가 들어 있으면 글자는 추출되지만 단어 순서와 문장이 무너질 수 있습니다. 따라서 “텍스트가 있는가”와 “RAG에 사용할 수 있는가”를 분리해 검사해야 합니다.

처리 효율과 라우팅 구조

모든 PDF를 처음부터 이미지로 렌더링하고 광학 문자 인식하는 방식은 구현이 단순합니다. 대신 텍스트형 파일에도 렌더링과 인식 단계를 추가하게 됩니다. 파일 수가 늘어나면 CPU 사용량, 임시 이미지 저장 공간, 처리 대기열, 실패 재시도 로직이 함께 커집니다.

피디에프 인스펙터를 앞단에 두면 페이지 또는 파일 단위로 다음 경로를 나눌 수 있습니다.

1. 텍스트 품질이 충분한 페이지는 원문 추출기로 보냅니다.
2. 텍스트가 없거나 품질이 낮은 페이지는 렌더링 후 광학 문자 인식으로 보냅니다.
3. 혼합형 문서는 페이지별 결과를 합칩니다.
4. 표와 수식이 많은 페이지는 별도 파서나 수동 검증 대기열로 보냅니다.
5. 실패한 페이지는 원본과 중간 산출물을 보존한 뒤 재처리합니다.

이 방식의 장점은 단순한 평균 처리 시간보다 불필요한 광학 문자 인식 호출을 줄일 수 있다는 점입니다. 다만 실제 처리량은 페이지 크기, 이미지 해상도, 언어 모델, 병렬 작업 수, 저장 장치에 좌우됩니다. 공식 문서도 광학 문자 인식 언어를 잘못 선택하면 품질이 낮아질 수 있다고 설명합니다. 광학 문자 인식 언어 설정 안내

선택 점수표

피디에프 인스펙터가 광학 문자 인식을 대신할 수 있나요?

전체를 대신할 수는 없습니다. 피디에프 인스펙터는 분류와 원문 추출의 입구 역할에 가깝습니다. 이미지 안의 글자를 새로 읽어 텍스트 층으로 만드는 작업은 광학 문자 인식 엔진이 담당합니다.

오픈 소스 광학 문자 인식 도구인 오크리마이피디에프는 스캔 PDF에 검색 가능한 텍스트 층을 추가하는 용도로 설계되어 있습니다. 기존 텍스트가 있는 페이지를 어떻게 처리할지, 결과 텍스트를 별도 파일로 저장할지 같은 옵션도 제공합니다. 오크리마이피디에프 공식 문서

복잡한 레이아웃의 경계

두 단으로 구성된 기술 문서는 원문 추출만으로도 읽기 순서가 뒤섞일 수 있습니다. 표는 셀의 위치만 남고 행과 열의 의미가 사라질 수 있습니다. 수식은 이미지처럼 포함되어 있거나 글꼴 정보만으로 표현되어 일반 텍스트와 다른 처리 경로가 필요합니다.

각 도구의 책임 범위를 나누면 설계가 명확해집니다.

• 피디에프 인스펙터: 문서와 페이지 유형 분류, 텍스트 존재 여부 검사, 위치 기반 원문 추출을 담당합니다.
• 일반 PDF 파서: 글자, 블록, 표, 좌표와 같은 구조 정보를 추출합니다.
• 광학 문자 인식: 이미지에 포함된 글자를 문자 데이터로 변환합니다.
• 후처리 계층: 제목, 단락, 표, 페이지 번호, 문서 식별자를 RAG용 스키마로 정리합니다.
• 검증 계층: 실패 페이지, 낮은 신뢰도 결과, 표와 수식을 별도로 표시합니다.

파이뮤피디에프 공식 문서는 이미지 기반 텍스트라면 OCR 텍스트 페이지를 만든 뒤 다시 텍스트를 추출하는 방식을 안내합니다. 이미지 기반 PDF의 OCR 처리 예시 이 구조는 “파서 대 OCR”의 대결보다 실제 시스템에 가깝습니다.

주의할 점은 분류 결과를 문서 이해 결과로 오해하지 않는 것입니다. 혼합형으로 분류됐다는 사실은 페이지별 처리 경로가 다를 수 있다는 뜻이지, 표의 의미나 수식의 논리를 자동으로 이해했다는 뜻이 아닙니다.

비용 모델과 실행 환경

비용은 도구 이름보다 처리 단계와 실행 방식으로 계산해야 합니다. 기본 모델은 다음과 같이 잡을 수 있습니다.

총비용 = 감지 시간 비용 + 렌더링 시간 비용 + 광학 문자 인식 시간 비용 + 임베딩 비용 + 저장 비용 + 실패 재처리 비용

여기서 전체 OCR은 원문이 이미 있는 페이지까지 렌더링할 가능성이 있습니다. 혼합 라우팅은 감지 단계가 추가되지만, 광학 문자 인식을 필요한 페이지에만 적용하도록 설계할 수 있습니다. 어느 쪽이 더 저렴한지는 문서 중 스캔 페이지의 비율, 재처리율, 피크 물량, 보관 기간을 넣어 계산해야 합니다.

규모별 구성 비교

작은 원형에서는 전체 OCR이 빠르게 결과를 확인하는 방법이 될 수 있습니다. 하지만 지속적인 증분 수집에서는 피디에프 인스펙터를 앞단에 두고, 처리되지 않은 페이지와 실패 페이지만 별도 대기열에 넣는 편이 운영상 유리합니다.

대량 작업은 항상 가장 큰 장비를 빌리는 방식으로 해결되지 않습니다. 피크 기간에는 병렬 작업을 늘리고, 평상시에는 낮은 사용량 환경으로 줄이는 구성이 합리적입니다. 원격 맥 환경을 비교할 때는 클라우드 맥 대여 방식과 맥 가상 서버 가격 구성을 함께 확인하되, 실제 비용은 문서 수와 처리 시간으로 산출해야 합니다.

구현 순서와 실패 회귀

첫 버전은 아래 순서로 구성하면 됩니다.

1. 샘플 묶음을 고정합니다. 텍스트형, 스캔형, 혼합형, 다단 편집, 표 중심, 수식 중심 문서를 포함합니다.
2. 페이지 단위 원본 정보를 저장합니다. 문서 식별자, 페이지 번호, 파일 해시, 추출 경로를 함께 기록합니다.
3. 피디에프 인스펙터로 1차 분류합니다. 파일 전체 결과만 보지 말고 페이지별 분류와 신뢰도도 저장합니다.
4. 원문 추출 결과를 먼저 검사합니다. 글자 수보다 단락, 제목, 표, 읽기 순서를 검사합니다.
5. 조건부 OCR을 실행합니다. 텍스트가 없거나 품질 점수가 기준보다 낮은 페이지만 대상으로 삼습니다.
6. 두 결과를 하나의 스키마로 합칩니다. 문서 제목, 페이지 번호, 단락 순서, 표 여부, 추출 경로를 보존합니다.
7. 임베딩 전에 검증합니다. 빈 결과, 지나치게 짧은 결과, 반복 문자, 깨진 인코딩을 차단합니다.
8. 질문 세트로 회귀합니다. 질문별 정답 페이지, 검색된 페이지, 인용 가능한 문장을 비교합니다.
9. 버전을 고정하고 로그를 남깁니다. 파서, OCR 엔진, 언어 데이터, 렌더링 도구의 버전을 기록합니다.

실패 처리는 처음부터 설계해야 합니다. OCR 시간 초과, 페이지 렌더링 실패, 암호화된 PDF, 글꼴 인코딩 오류를 모두 성공과 실패로만 나누면 원인 분석이 어렵습니다. 분류 실패, 추출 실패, OCR 실패, 구조화 실패, 임베딩 실패처럼 단계별 상태를 남겨야 재처리 대상을 좁힐 수 있습니다.

RAG PDF 전처리에서 평가해야 할 지표는 무엇인가요?

최소한 텍스트 완성도, 단락 보존, 제목 분리, 표 구조, 페이지 추적성, 질문 회수율, 실패율, 재처리율, 페이지당 처리 시간, OCR 적용 비율을 기록해야 합니다. 정확도 하나만 보면 원문은 잘 읽었지만 인용 위치를 잃은 문제를 놓칠 수 있습니다.

• [ ] 텍스트형·스캔형·혼합형 샘플을 모두 포함했는지 확인합니다.
• [ ] 모든 결과에 문서 식별자와 페이지 번호가 붙었는지 검사합니다.
• [ ] 원문 추출과 OCR 결과의 단락 순서를 비교합니다.
• [ ] 표와 수식이 포함된 페이지를 별도 집계합니다.
• [ ] OCR 적용 전후의 처리 시간과 실패율을 기록합니다.
• [ ] 같은 파이프라인을 다시 실행해 결과가 재현되는지 확인합니다.
• [ ] 파서와 OCR 버전 변경 뒤 기준 질문 세트를 다시 실행합니다.
• [ ] 실패 결과를 원본과 함께 재처리할 수 있는지 확인합니다.

오크리마이피디에프 문서는 OCR 결과를 별도 텍스트 파일로 저장할 수 있지만, 기존 텍스트가 있는 페이지나 OCR을 건너뛴 페이지의 결과가 기대와 다를 수 있다고 설명합니다. 따라서 보조 텍스트 파일만 믿지 말고 페이지별 처리 상태를 별도로 관리해야 합니다. OCR 결과 파일과 페이지 처리 조건

규모별 최종 선택

소형 원형은 피디에프 인스펙터로 분류한 뒤 원문 추출과 OCR을 각각 한 번씩 비교하는 구성이 적합합니다. 목표는 최저 비용이 아니라 어떤 문서 유형이 실패하는지 빠르게 찾는 것입니다.

주기적인 일괄 처리는 혼합 라우팅이 유리합니다. 감지 결과에 따라 작업 대기열을 나누고, OCR이 필요한 페이지에만 렌더링을 적용해야 합니다. 처리 주기가 명확하면 작업 완료 후 실패 목록을 별도 검토할 수 있습니다.

지속 생산 수집은 세 계층으로 나누는 편이 안전합니다.

1. 감지 계층에서 PDF 유형과 페이지별 신뢰도를 기록합니다.
2. 추출 계층에서 원문 파싱과 조건부 OCR을 실행합니다.
3. 검증 계층에서 품질 점수, 출처, 실패 원인, 회귀 결과를 관리합니다.

결론은 단순합니다. 피디에프 인스펙터는 OCR의 경쟁자가 아니라 OCR 호출 여부를 결정하는 앞단에 가깝습니다. 텍스트형 문서까지 전체 OCR로 보내면 처리 단계와 운영 비용이 불필요하게 늘어날 수 있습니다. 반대로 스캔과 혼합형 문서를 원문 파서에만 맡기면 검색 가능한 텍스트와 페이지 인용을 잃을 수 있습니다.

현재 파이프라인이 모든 PDF를 OCR로 처리한다면 렌더링 대기, 임시 파일 증가, 언어별 인식 편차, 실패 페이지 재처리라는 문제가 생길 수 있습니다. 반대로 로컬 파서만 사용하는 구조는 스캔 문서와 낮은 품질의 숨은 텍스트에 취약합니다. 이런 조건에서는 먼저 작은 샘플로 혼합 라우팅을 검증하고, 필요한 기간에만 Zilmac의 맥 대여 환경을 사용해 반복 회귀를 수행하는 방식이 현실적입니다. 장기 고정 부하나 물리 장치 의존성이 높다면 자체 장비가 더 적합할 수 있지만, 일괄 테스트와 임시 OCR 작업처럼 처리 기간이 분명한 경우에는 원격 맥 환경이 준비 시간을 줄이는 선택지가 될 수 있습니다.