PDF를 AI에 전달할 때 항상 먼저 Markdown으로 바꿔야 하는 것은 아닙니다. 사용하는 서비스가 PDF를 어떻게 처리하는지, 문서에 선택 가능한 텍스트가 있는지, 표와 이미지가 중요한지에 따라 적합한 방법이 달라집니다.
변환의 핵심은 파일 형식을 바꾸는 것보다 AI가 읽을 내용이 원문과 맞는지 확인하는 데 있습니다. 텍스트 추출과 OCR은 유용하지만, 열 순서나 표·수식·스캔 품질에 따라 중요한 정보가 빠지거나 잘못 읽힐 수 있습니다.
같은 PDF라도 내용이 다릅니다
PDF는 화면에 문서를 보여 주는 형식입니다. 어떤 PDF에는 선택하거나 복사할 수 있는 텍스트가 들어 있고, 어떤 PDF는 종이 문서를 스캔한 이미지로 구성됩니다. 두 형태가 섞여 있는 파일도 있습니다.
| 문서 형태 | 먼저 볼 것 | 가능한 처리 |
|---|---|---|
| 텍스트가 포함된 PDF | 글자를 선택·복사할 수 있는가 | 텍스트를 추출해 순서를 확인합니다. |
| 스캔 이미지 PDF | 글자가 이미지로만 들어 있는가 | OCR로 문자 인식을 시도하고 결과를 대조합니다. |
| 표·그림이 많은 PDF | 위치와 시각적 관계가 중요한가 | 변환본과 함께 원본의 해당 부분을 확인합니다. |
OCR은 이미지 속 글자를 읽어 텍스트로 변환하는 기술입니다. 흐린 스캔, 작은 글자, 수식이나 복잡한 표에서는 오류가 생길 수 있으므로 결과를 그대로 정답으로 취급하면 안 됩니다.
Markdown 변환은 무엇을 돕나요?
Markdown은 제목, 목록, 링크 등을 비교적 단순한 텍스트로 표시하는 형식입니다. PDF의 읽기 순서와 문단 구조를 정리해 두면 나중에 내용을 검색하거나 문서의 일부를 AI에 전달하기 쉬울 수 있습니다.
다만 원본의 서식을 완전히 보존하는 형식은 아닙니다. 두 단으로 배치된 문서의 줄이 뒤섞이거나, 표의 셀 관계가 사라지고, 그림 속 정보가 텍스트에 포함되지 않을 수 있습니다. 결과가 보기 좋게 정리됐다는 이유만으로 의미까지 정확하다고 판단하면 안 됩니다.
예를 들어 PDF 표에서 매출과 비용 열이 바뀐 채 텍스트로 추출됐다면, AI가 그 내용을 유창하게 요약해도 분석은 잘못될 수 있습니다. 이는 가능한 오류를 설명하기 위한 가상 예시입니다.
LiteDoc은 어떤 접근을 사용하나요?
LiteDoc 공개 저장소는 브라우저에서 PDF를 Markdown으로 변환하는 도구라고 설명합니다. 저장소에 따르면 PDF.js를 사용해 텍스트 위치를 읽고, 스캔 문서나 깨진 글꼴에는 OCR을 사용하며, Markdown과 이미지를 묶어 내보낼 수 있습니다.
같은 저장소는 복잡한 레이아웃, 스캔된 수식·표, 디자인 요소가 많은 PDF에서 결과가 좋지 않을 수 있다고 밝힙니다. 이 글에서는 도구를 직접 설치하거나 여러 문서로 정확도를 시험하지 않았으므로, 모든 PDF가 정확히 변환된다고 말할 수 없습니다.
프로젝트는 오프라인에서 사용할 수 있는 배포 방식도 안내합니다. 그렇더라도 사용 중인 버전과 실제 네트워크 동작을 직접 확인하기 전에는 어떤 환경에서도 데이터가 외부로 나가지 않는다고 보장할 수 없습니다. 민감한 문서는 조직의 도구 사용 기준과 보안 정책을 먼저 확인하세요.
변환하면 AI 비용이 항상 줄어드나요?
변환된 텍스트의 길이와 서비스의 처리 방식에 따라 입력 사용량이 달라질 수 있습니다. 그러나 모든 PDF 페이지가 동일한 비용을 쓰거나, 텍스트로 바꾸면 언제나 전체 비용이 줄어든다고 단정할 수는 없습니다. 모델과 제품마다 PDF·이미지·텍스트를 처리하고 청구하는 방식이 다르며, OCR과 검토에도 자원이 들 수 있습니다.
원문에 제시된 ‘페이지당 일정한 토큰’이나 ‘모든 PDF를 이미지로 강제 처리한다’는 수치는 일반 규칙으로 확인하지 못해 사용하지 않았습니다. 실제 비교가 필요하다면 같은 문서와 작업으로 원본 PDF 방식과 텍스트 변환 방식을 시험하고, 사용량·결과 정확도·누락을 함께 기록해야 합니다.
AI에 전달하기 전에 무엇을 확인할까요?
1. 읽기 순서와 누락
제목과 문단이 원문 순서대로 나왔는지, 머리말이나 쪽번호가 반복되어 문맥을 방해하지 않는지 살펴봅니다. 두 단 문서는 특히 단을 가로질러 문장이 섞이지 않았는지 확인합니다.
2. 표와 수치
표의 행과 열, 단위와 음수 기호가 유지됐는지 원본과 비교합니다. 계약 조건이나 재무 수치처럼 오류의 영향이 큰 항목은 해당 페이지로 돌아가 확인합니다.
3. 이미지와 수식
그래프의 축, 그림 설명, 수식은 단순 텍스트 추출에서 빠질 수 있습니다. 시각 정보가 결론에 중요하다면 원본을 함께 확인하거나 해당 내용을 별도로 검토합니다.
4. 개인정보와 외부 전송
문서 전체를 외부 서비스에 보내도 되는지, 실제 필요한 부분만 사용할 수 있는지 확인합니다. 로컬 변환을 한 뒤에도 변환된 텍스트를 외부 AI에 넣으면 그 내용은 해당 서비스로 전달됩니다.
PDF를 그대로 쓸지 변환할지 고르는 기준
원본의 시각 정보가 중요한 경우
표·도표·레이아웃 자체가 중요하면 PDF를 지원하는 서비스의 처리 범위를 확인하고, AI의 설명을 원본과 대조합니다. PDF 지원 여부만으로 모든 도표를 정확히 이해한다고 보장되지는 않습니다.
긴 문서에서 텍스트 검색이 중요한 경우
추출한 텍스트나 Markdown으로 필요한 구간을 찾는 방법이 도움이 될 수 있습니다. 제목 구조와 페이지 출처를 함께 남겨야 나중에 원본을 다시 확인하기 쉽습니다.
스캔이나 복잡한 표가 많은 경우
OCR이나 다른 문서 처리 도구를 시험할 수 있지만, 인식 오류를 확인하는 시간이 필요합니다. 어떤 도구가 맞는지는 문서 유형과 요구 정확도에 따라 달라집니다.
처음 PDF를 AI에 올리고 요약하는 과정은 PDF 요약과 파일 업로드 안내에서 볼 수 있습니다. 검색 시스템에서 추출·분할·검색이 왜 흔들리는지는 RAG 운영 신뢰성 글에서 다룹니다.
자주 묻는 질문
텍스트로 바꾸면 AI가 PDF를 완벽히 이해하나요?
아닙니다. 읽기 순서가 잘못되거나 표·그림이 누락될 수 있습니다. 중요한 내용은 원문과 대조해야 합니다.
OCR이 필요한 PDF는 어떻게 구분하나요?
글자를 선택하거나 복사할 수 없는 스캔 문서라면 OCR이 필요할 수 있습니다. 다만 텍스트와 이미지가 섞인 PDF도 있으므로 페이지별로 확인해야 합니다.
브라우저에서 변환하면 파일이 절대 외부로 전송되지 않나요?
도구와 설정에 따라 다릅니다. 프로젝트의 설명, 사용하는 버전과 실제 네트워크 동작을 확인하고 민감한 자료는 조직의 정책에 맞춰 처리해야 합니다.
참고 자료
- LiteDoc 공개 저장소 — 프로젝트가 설명하는 PDF 변환 방식과 한계.
- Mozilla PDF.js — 웹에서 PDF를 다루는 오픈소스 프로젝트.
- Tesseract.js — 브라우저와 JavaScript 환경의 OCR 프로젝트.
다음 한 걸음
내 환경에서 막힌 부분은 실행 단계와 함께 질문해 주세요. 바꿔 만든 결과도 함께 나눌 수 있습니다.