PDF(문서 형식)

한 줄 정의

PDF는 글자, 이미지, 폰트, 표, 페이지 레이아웃을 한 파일 안에 담아 거의 같은 모양으로 교환하기 위한 문서 형식이야. Adobe가 만든 Portable Document Format이고, 현재는 ISO 32000 계열 표준으로 관리돼.

AI 문서 처리에서 PDF가 중요한 이유는 “파일 하나”처럼 보여도 실제 입력이 서로 다르기 때문이야. 어떤 PDF는 텍스트가 살아 있어서 바로 추출할 수 있고, 어떤 PDF는 스캔한 페이지 이미지라서 OCR부터 필요해. 또 표, 차트, 도면, 슬라이드처럼 레이아웃이 답의 일부라면 텍스트만 뽑아서는 정보가 빠질 수 있어.

RAG는 검색해서 답하게 만드는 방식이고, OCR은 이미지 속 글자를 뽑는 기술이고, 임베딩은 검색용 벡터를 만드는 표현 방식이야. PDF와 비교하면 셋 다 처리 방법에 가깝고, PDF는 그 처리 방법들이 읽어야 하는 문서 컨테이너에 가까워.

어떻게 작동하나

PDF는 문서를 페이지 단위로 표현해. 페이지 안에는 텍스트 객체, 이미지, 벡터 그래픽, 폼, 링크 같은 요소가 들어갈 수 있고, 보는 사람의 운영체제나 앱이 달라도 비슷하게 보이도록 만든다. PDF 2.0 표준은 ISO 페이지 기준 문서 분량이 986쪽이야. 그냥 단순한 이미지 파일은 아니라는 뜻이지.

AI 파이프라인에서는 보통 세 가지 경로로 나뉘어.

• 텍스트 레이어 추출: 글자가 살아 있으면 문단과 표를 추출해서 RAG용 청크로 쪼갠다.
• 스캔 PDF OCR: 페이지가 이미지에 가까우면 OCR로 글자와 좌표를 뽑는다.
• 페이지 이미지 검색: 레이아웃 자체가 중요하면 페이지를 이미지로 렌더링한 뒤 Vision-Language Model이나 멀티모달 임베딩으로 검색한다.

Hugging Face의 2026년 4월 16일 글이 보여 준 문서 페이지 이미지 검색 예시가 이 세 번째 길에 가까워. 글에서는 텍스트 질의로 차트, 표, 레이아웃이 남아 있는 페이지 이미지를 찾는 작업을 다뤘고, public internet PDF에서 모은 약 50만 개 query-image sample을 언급했어. 전처리한 영어 데이터 53,512개 중 train config는 10,000개, eval config는 300개로 나뉘었다고 설명해.

왜 중요한가

PDF를 잘못 읽으면 그 뒤의 AI 품질을 엉뚱한 곳에서 고치게 돼. 검색이 실패했는데 생성 모델만 바꾸거나, 스캔본인데 텍스트 추출기만 바꾸거나, 표 레이아웃이 필요한데 본문 문자열만 임베딩하는 식이야. 이런 경우 모델이 부족한 게 아니라 입력을 잘못 펼친 거라서, 원인을 다르게 봐야 해.

실무 예시는 이렇게 갈라서 보면 더 빨라.

• 계약서 PDF: 조항 번호와 문장 순서가 중요해서 텍스트 추출 뒤 청크 순서를 확인해야 해.
• 재무 보고서: 표와 차트가 같이 쓰이니 표 추출 결과와 페이지 이미지를 따로 비교해야 해.
• 연구 논문: 본문, 각주, 그림 캡션이 서로 다르게 쓰이니 검색 인덱스에 넣을 때 메타데이터를 나눠야 해.

v5.4.0 릴리스도 이 흐름을 보여 줘. 릴리스 노트는 SentenceTransformer와 CrossEncoder가 텍스트, 이미지, 오디오, 비디오를 다루는 멀티모달 임베딩과 재정렬을 지원한다고 설명해. Hugging Face의 예시에서는 빠른 1차 검색은 임베딩 모델로 하고, 상위 10개 후보는 reranker로 다시 점수화해. PDF 페이지 검색도 결국 “문서를 읽었다”보다 “어떤 표현으로 후보를 만들고 다시 골랐나”를 봐야 해.

주의해서 볼 점

먼저 텍스트 PDF와 스캔 PDF를 나눠 봐야 해. 텍스트가 살아 있는 PDF라도 읽기 순서, 표 셀, 머리말, 꼬리말, 주석이 추출기마다 다르게 나올 수 있어. 스캔 PDF는 더 직접적이야. 사람 눈에는 글자인데 시스템에는 이미지라서 OCR 품질, 해상도, 기울기, 작은 글씨가 바로 검색 품질을 흔들어.

두 번째는 레이아웃이 답의 일부인지 보는 거야. Hugging Face 학습 글에서는 Qwen3 계열의 Qwen3-VL-Embedding-2B를 문서 페이지 이미지 검색에 맞춰 학습했을 때 자체 Eval에서 NDCG@10이 0.888에서 0.947로 올랐다고 적어. 이 숫자는 PDF 페이지 이미지를 찾는 작업에서 레이아웃과 시각 정보가 중요할 수 있다는 신호야. 다만 특정 데이터셋과 학습 설정의 결과라서, 그대로 팀 문서 검색 성능으로 옮겨 적으면 안 돼.

마지막으로 PDF 검색과 PDF 이해를 섞지 않는 게 좋아. 페이지 이미지를 잘 찾는 모델이 표 숫자를 정확히 검증한다는 뜻은 아니고, OCR 텍스트가 있다고 원문 인용이 자동으로 믿을 만해지는 것도 아니야. 운영에서는 추출 텍스트, 페이지 번호, 좌표, 검색 점수, 최종 답변을 따로 기록해야 나중에 어디서 틀렸는지 확인할 수 있어. 문서 AI에서 PDF는 답이 아니라 입력 조건이야.