스캔 PDF 판별 안 하면 RAG 검색이 틀어지는 이유 3가지 (2026년 firecrawl 사례)

스캔 PDF 판별 안 하면 RAG 검색이 틀어지는 이유 3가지 (2026년 firecrawl 사례)

스캔 PDF를 텍스트 도구로 읽으면 에러가 아니라 빈 문자열이 나오고, 그대로 벡터DB에 들어가 검색 결과를 틀어지게 만듭니다. firecrawl/pdf-inspector는 이 판별을 10~50ms 안에 자동화합니다.

결론부터 말하면, RAG 파이프라인에서 검색 품질이 이상해지는 원인 중 하나는 스캔 PDF를 판별 없이 그냥 텍스트 도구에 넣었기 때문일 가능성이 큽니다. "우리 팀 문서엔 스캔본이 꽤 많은데, 이거 텍스트로 뽑을 수는 있나요?" 문서 처리 파이프라인을 붙이다 보면 한 번쯤 마주치는 질문이죠. 이 글에서는 2026-08-04 기준 GitHub 트렌딩에 오른 firecrawl/pdf-inspector를 통해 스캔 PDF 판별이 왜 필요한지, OCR 비용 절감은 어떻게 계산하는지, 한국어 PDF 텍스트 추출에서 특히 주의할 지점은 무엇인지 순서대로 짚어보겠습니다.

목차

• 스캔 PDF 판별 없이 넘어가면 벡터DB에서 생기는 조용한 실패
• firecrawl/pdf-inspector란: 스캔 PDF 판별부터 마크다운 변환까지
• OCR 비용 절감은 어떻게 계산하나: Google·AWS 가격 실측
• 한국어 PDF 텍스트 추출에서 특히 봐야 할 지점
• 아직 열려 있는 결함들
• 도입 전 확인할 3단계
• 자주 묻는 질문 (FAQ)

스캔 PDF 판별 없이 넘어가면 벡터DB에서 생기는 조용한 실패

PDF 포맷은 화면에 뭐가 보이는지만 정의해요. 그 픽셀 뒤에 실제로 읽을 수 있는 문자가 있는지는 보장하지 않습니다. 그래서 스캔본을 텍스트 추출 함수에 넣으면 에러가 뜨는 대신 조용히 빈 문자열이 돌아와요. 실패가 실패처럼 보이지 않는 거죠.

문제는 그다음입니다. 이 빈 문자열이 그대로 임베딩되고 벡터DB에 저장됩니다. 검색이 안 되는 게 아니라, 엉뚱한 문서가 검색 결과 상단에 뜨기 시작해요. AI 에이전트 문서 인제스천 파이프라인을 운영하는 입장에서는 원인을 찾기 특히 까다로운 유형의 결함입니다. 로그에 에러가 남지 않으니까요.

해법은 단순합니다. 판별을 인제스천 앞단에 두는 것. 텍스트가 있는 페이지는 로컬에서 빠르게 뽑고, 없는 페이지만 OCR로 보내는 라우팅입니다.

firecrawl/pdf-inspector란: 스캔 PDF 판별부터 마크다운 변환까지

스캔 PDF 판별(PDF classification): PDF 파일을 열기 전에 텍스트 레이어가 있는지 없는지 미리 판정해, OCR이 필요한 페이지만 골라내는 과정입니다. firecrawl/pdf-inspector는 이 판정을 10~50ms 안에 처리하고 TextBased·Scanned·ImageBased·Mixed 네 가지로 분류합니다.

GitHub API로 확인한 저장소 실측값(2026-08-04 기준)이에요.

기능은 세 층으로 나뉩니다. 분류(detector)는 xref 테이블과 콘텐츠 스트림의 텍스트·이미지 연산자만 훑어서 신뢰도 점수와 함께 판정을 내려요. 추출(extractor)은 좌표·폰트 정보를 유지하며 다단 조판 감지, 읽기 순서 재구성, CID 폰트 CMap 디코딩까지 처리하고요. 변환(markdown)은 폰트 크기로 제목 수준을 잡고 표·코드블록·리스트를 감지해 마크다운으로 뽑아냅니다.

명시적으로 하지 않는 것도 분명해요. OCR 자체는 하지 않습니다. ML 모델도, 외부 API 호출도 없고 PDF 파싱 의존성은 lopdf 하나뿐이에요. 스캔본을 만나면 "이건 내 담당이 아니다"라고 알려주는 것까지가 역할입니다.

참고로 급상승 자체는 신규 공개가 아니라 뒤늦은 발화였어요. 저장소는 2026-02-06부터 존재했고, 방아쇠는 2026-08-02 Firecrawl 공식 X 계정 게시물(좋아요 5,216 · 조회 525,202)이었습니다. 흥미로운 건 Hacker News 반응은 게시물 2건 모두 5 points에 그쳤다는 점이에요. 대신 실질적인 논의는 GitHub 이슈 트래커로 몰렸는데, 이 내용은 아래에서 다룹니다.

OCR 비용 절감은 어떻게 계산하나: Google·AWS 가격 실측

OCR API 공식 가격을 직접 확인했어요.

OCR 비용 절감은 어떻게 계산하나: Google·AWS 가격 실측

이미지 출처: cloud.google.com

판별 없이 다 OCR로 보내면 텍스트 기반 PDF에도 이 비용이 그대로 붙습니다. 여기에 지연 시간도 겹쳐요. README에 소개된 라우팅 예시는 텍스트 기반이면 로컬 추출 약 150ms, 아니면 OCR 서비스 2~10초로 잡습니다.

규모를 가늠해볼까요. README는 "OCR이 필요 없는 약 54%의 PDF"를 로컬에서 처리한다고 주장하는데, 이 수치는 저장소 자체 주장일 뿐 근거 링크나 데이터셋 출처가 공개돼 있지 않습니다(검증 불가). 그 전제를 그대로 산술에만 적용해보면, 월 100만 페이지 파이프라인에서 54만 페이지가 텍스트 기반이라 가정할 때 Google Document AI 기준으로는 약 $810, AWS Textract 표 분석 요금 기준으로는 약 $8,100의 호출 비용이 절약 대상이 됩니다. 자릿수가 크게 갈리는 이유는 단순 텍스트 검출과 표 구조 분석의 단가 차이(10배)예요. 이 숫자는 어디까지나 미검증 전제를 얹은 시뮬레이션이라는 점을 감안해서 참고해야 합니다.

한국어 PDF 텍스트 추출에서 특히 봐야 할 지점

가장 구체적인 근거는 소스 트리 안에 있어요. src/adobe_korea1.rs(348,818 bytes)는 Adobe-Korea1-2 cid2code.txt의 UniKS-UCS2 컬럼에서 생성한 CID→유니코드 매핑 테이블 17,056개 항목을 담고 있습니다.

이게 왜 중요하냐면, 한글 PDF에서 "화면에는 글자가 보이는데 복사하면 깨지거나 빈칸이 나오는" 현상의 흔한 원인이 CID 폰트예요. 글자가 유니코드 코드가 아니라 폰트 내부 번호(CID)로만 기록돼 있고, 그 번호를 유니코드로 되돌릴 표(ToUnicode CMap)가 문서에 빠져 있으면 추출기는 의미 없는 숫자만 받습니다. firecrawl/pdf-inspector는 이 경우를 위해 Adobe-Korea1 표준 매핑을 내장해뒀고요. 실제로 2026-08-04 기준 열려 있는 PR 중 하나가 "ToUnicode 없는 Adobe CID 폰트 디코딩(bcmaps 번들)"입니다.

아직 열려 있는 결함들: 완성된 해법으로 소개하긴 이릅니다

한국어 실무자라면 여기가 가장 중요한 대목이에요. 2026-08-04 기준 다음 CJK 결함이 열려 있습니다.

• 2026-08-04 등록: dompdf가 만든 CIDFontType2 서브셋에서 ToUnicode가 전 범위 identity bfrange일 때 CJK 부분 깨짐
• 2026-08-02 등록: 서브셋 GID 재매핑이 CIDFontType0(CFF)을 오염시켜 일본어 Adobe-Japan1 PDF가 엉뚱한 글리프로 추출됨
• 2026-08-03 등록: extract_pages_markdown()의 needs_ocr 값이 같은 페이지에 대한 classify_pdf() 결과와 모순됨

같은 기간 아랍어 RTL 텍스트가 논리 순서가 아닌 시각 순서로 반환되는 문제, 2단 조판에서 컬럼은 감지되나 마크다운이 래스터 순서로 섞이는 문제, 표가 한 줄로 뭉개지는 문제도 함께 접수돼 있어요. PR도 37건 열려 있어서 대응 속도 자체는 빠른 편이지만, 상위 기여자는 abimaelmartell 한 명이 410 커밋이고 나머지는 1~2 커밋 수준입니다. 회사(Firecrawl) 제품의 핵심 부품이라는 게 그나마 지속성의 근거고요.

정리하면 판별 자체를 1급 기능으로 내세운 경량 도구는 드물었지만, 다국어·복잡 조판 정확도는 검증이 더 필요한 단계예요.

회사 RAG 파이프라인 PDF 처리에 도입하기 전 확인할 3단계

1. 표본으로 먼저 돌려보기: 실제 다루는 문서(관공서 고시문, 스캔된 계약서, 한글 워드프로세서로 만든 PDF)로 detect-pdf CLI(cargo install pdf-inspector)를 먼저 실행해 분류 정확도를 확인합니다.
2. 분류와 추출 품질을 따로 확인하기: 분류가 맞더라도 추출 품질은 별도 검증이 필요해요. 위에서 다룬 CJK 이슈가 정확히 이 구간에서 터집니다.
3. 판별-추출 불일치 가능성 감안하기: needs_ocr와 classify_pdf() 결과가 어긋날 수 있다는 걸 전제로 파이프라인을 설계합니다. 레지스트리별 버전도 제각각이라(Rust 0.1.x·Python 0.2.x·Node 1.x) 여러 언어를 동시에 쓰는 팀은 버전 동기화 자동화를 그대로 물리지 않는 게 안전합니다.

자주 묻는 질문 (FAQ)

Q: 한국어 PDF 깨짐 문제는 이제 완전히 해결됐나요?

아직 진행형입니다. 17,056개 CID 매핑 테이블은 있지만 2026-08-04 기준 dompdf CIDFontType2 CJK 부분 깨짐, Adobe-Japan1 글리프 오염 이슈가 열려 있어요. 도입 전 실제 문서로 먼저 검증하는 게 안전합니다.

Q: 회사 문서를 이 도구에 넣어도 안전한가요?

판별 단계는 로컬 Rust 라이브러리로 동작하고 외부 API 호출이나 ML 모델이 없습니다. cargo install pdf-inspector로 로컬에 설치해 판별만 먼저 테스트해볼 수 있고, OCR로 보낼지 말지는 그다음 판단이라 데이터가 외부로 나가는 시점을 직접 통제할 수 있어요.

Q: OCR 비용을 얼마나 아낄 수 있나요?

README의 "약 54%" 전제를 그대로 대입하면 월 100만 페이지 기준 Google Document AI로 약 $810, AWS Textract 표 분석 기준으로 약 $8,100이 절약 대상 규모입니다. 다만 54%라는 수치 자체가 저장소 자체 주장이라 근거가 공개돼 있지 않으니, 자기 문서 표본으로 실제 텍스트 기반 비율을 먼저 재보는 게 정확합니다.

마무리

스캔 PDF를 판별 없이 넘기면 실패가 아니라 빈 문자열로 조용히 새어 들어가고, 그게 검색 품질 저하로 나타납니다. firecrawl/pdf-inspector는 이 판별을 로컬에서 빠르게 처리하고 한국어 CID 매핑까지 챙긴 흔치 않은 도구지만, CJK·아랍어·2단 조판 정확도는 여전히 다듬는 중이에요. 우리 팀 상황에 맞는지부터 따져보셔도 충분합니다. 판단에 필요한 기준은 위에 정리해 뒀어요. 스캔 PDF 판별을 인제스천 앞단에 두는 것만으로도 조용한 검색 품질 저하를 상당 부분 예방할 수 있습니다.

관련 글

• AI 에이전트 스킬 reverse-skill 논란, 도입 전 확인할 3가지 신호
• Claude 무단 접근 사고로 다시 짚는 AI 에이전트 보안 점검 기준 6가지

참고 자료

• firecrawl/pdf-inspector (GitHub)
• src/adobe_korea1.rs: Adobe-Korea1 CID 매핑 테이블
• Fire-PDF Launch: Firecrawl 공식 블로그
• Google Document AI 공식 가격
• AWS Textract 공식 가격
• Firecrawl 공식 X 게시물