당신의 AI 에이전트는 PDF를 grep 할 수 없으며, 이는 토큰을 낭비하게 만듭니다 🔥

당신의 코딩 에이전트는 전체 리포지토리(repo)를 밀리초 단위로 grep 할 수 있습니다. 하지만 PDF를 동일한 방식으로 처리할 수는 없습니다.

PDF는 기본적으로 AI 친화적이지 않습니다. 선택 가능한 텍스트를 포함하고 있더라도, 에이전트에게 중요한 구조(읽기 순서, 표, 공식, 캡션, 그림 등)가 종종 유실되거나 다시 추측해야 하는 상황이 발생합니다. 이러한 추출 과정은 정보 손실(lossy)이 발생하며, 비용이 들지 않는 것도 아닙니다.

내부적으로 어떤 일이 일어나고 있는지, 그리고 왜 한 번 깨끗한 마크다운 (Markdown)으로 변환하는 것이 해결책인지 설명하겠습니다.

공개 사항 (Disclosure): 저는 브라우저 기반 PDF→마크다운 (Markdown) 변환기인 pdfmarkdown.app을 제작하고 있으므로, 이 점을 고려하여 판단해 주시기 바랍니다. 주장은 검증 가능하도록 작성했으니 직접 테스트해 보셔도 좋습니다.

PDF는 텍스트가 아니라 그림입니다

대부분의 PDF는 문장을 저장하지 않습니다. 대신 각 글리프 (glyph)가 페이지의 어디에 위치하는지를 저장합니다. "Married"라는 단어는 위치가 지정된 글리프들의 연속으로 저장될 수 있지만, 이들이 하나의 단어를 형성한다는 기록, 그 단어가 해당 단락에 속한다는 기록, 또는 왼쪽 열을 오른쪽 열보다 먼저 읽어야 한다는 기록은 없을 수 있습니다. (태그가 지정된 PDF (Tagged PDFs)는 논리적 구조와 읽기 순서를 포함할 수 있지만, 실제 환경에서는 드물거나 신뢰할 수 없기 때문에 도구들이 이를 전적으로 의존할 수는 없습니다.)

인간의 눈은 이 모든 것을 즉시 재구성합니다. 소프트웨어는 이를 다시 _추측_해야 하며, 바로 이 추측 과정에서 문제가 발생합니다.

PDF는 각 글리프 (glyph)가 어디에 있는지는 알지만, 읽어야 할 순서는 알지 못합니다. 마크다운 (Markdown)은 순서와 구조를 저장하며, 이것이 바로 모델이 필요로 하는 것입니다.

문제가 발생하는 다섯 가지 지점

변환기(또는 모델)가 추측을 수행할 때, 실제 의미를 담고 있는 다음 다섯 가지 요소가 무너지는 경향이 있습니다:

다섯 가지 중단점: 스캔된 페이지, 다중 열 순서, 표, 수식, 그리고 이미지.

• 스캔된 페이지는 그저 이미지일 뿐입니다. 텍스트 레이어가 전혀 없습니다. OCR (광학 문자 인식) 없이는 모델이 사진을 "보고" 조용히 내용을 지어내게 됩니다.
• 다중 열(Multi-column) 페이지는 잘못된 순서로 읽힙니다. 2단 구성의 논문은 왼쪽 절반 줄을 읽은 뒤 오른쪽 절반 줄을 읽는 식으로 이어져, 문장들이 뒤섞여 의미 없는 결과가 됩니다.
• 표(Tables)가 무너집니다. 행과 열이 하나의 길게 늘어진 줄로 평탄화됩니다. "2024" 아래에 있던 숫자가 다른 행의 레이블 옆에 둥둥 떠다니게 됩니다.
• 수식(Formulas)이 횡설수설로 변합니다. E = mc²가 E mc2가 되고, 아래첨자와 위첨자가 밀려나며, 논문의 핵심인 방정식이 읽을 수 없는 상태가 됩니다.
• 도표(Figures)는 의미를 잃습니다. 차트가 누락되거나, 기껏해야 단순한 이미지로 추출됩니다. 텍스트 또는 마크다운(Markdown) 파이프라인 (RAG, 검색, 텍스트를 grep 하는 에이전트) 내에서 해당 이미지는 아무런 의미를 전달하지 못합니다. 비전 모델(Vision model)은 이를 볼 수 있을지 몰라도, 여러분의 검색 인덱스(Retrieval index)와 grep은 할 수 없습니다.

해결책: 깨끗한 마크다운(Markdown)이 AI가 실제로 잘 읽는 형식입니다

마크다운은 제목을 위한 #, 표를 위한 실제 행과 열, 코드 블록을 위한 fenced blocks 등 가볍고 명시적인 구조를 가진 일반 텍스트입니다. 이 단순함이 핵심입니다:

• 구조가 추측되는 것이 아니라 명시됩니다. 읽기 순서, 표의 형태, 계층 구조가 모두 기록되어 있습니다.
• grep이 가능하며 토큰 효율적입니다. 일반 텍스트이므로 에이전트가 한 줄씩 검색할 수 있으며, 모델이 헤쳐 나가야 할 이진 데이터(Binary cruft)가 없습니다.
• 모델들은 방대한 양의 마크다운으로 학습되었습니다 (모든 README, 모든 위키, 모든 문서 사이트). 따라서 모델은 이를 기본적으로 파싱(Parse)할 수 있습니다.

PDF를 깨끗한 마크다운으로 단 한 번 변환하십시오. 그러면 모든 도구가 매 쿼리마다 (엉망으로) 재작업하게 만드는 대신, 손실이 발생할 수 있는 추출 과정을 단 한 번, 의도적으로 완료할 수 있습니다.

llms.txt가 적합한 위치

이는 **llms.txt**의 핵심 아이디어와 동일합니다. 이는 웹사이트가 중요한 콘텐츠를 일반 Markdown 형식의 지도로 게시하여, AI 도구가 렌더링된 HTML이나 PDF와 씨름하는 대신 직접 읽을 수 있도록 하는 신흥 컨벤션 (convention)입니다. AI가 무언가를 읽기를 원한다면, 깨끗한 Markdown을 건네주세요. 당신의 디스크에 있는 PDF나 AI가 크롤링하는 웹페이지나 정확히 동일한 문제를 가지고 있으며, 해결책 또한 정확히 동일합니다.

PDF를 AI용 Markdown으로 변환할 때: 주의 깊게 살펴볼 점

PDF를 변환한다면, 첫 번째 단락이 괜찮아 보이는지에 의존하지 말고 실제로 깨지는 부분들을 기준으로 결과를 판단하십시오. 다음 네 가지를 확인하세요:

1. 표 (tables)가 실제 행과 열로 살아남았는가?
2. 수식 (formulas)이 읽을 수 있는 수학 형식으로 살아남았는가?
3. 스캔된 페이지 (scanned pages)가 인식되었는가, 아니면 소리 없이 쓰레기 데이터로 반환되었는가?
4. 도표 (figures)가 출력물에 포함되기는 했는가?

이것이 제가 pdfmarkdown.app에 요구하는 기준입니다. 이 도구는 브라우저에서 실행되며, 출력물을 신뢰하기 전에 위 네 가지 사항을 확인할 수 있도록 원본 PDF와 Markdown을 나란히 보여줍니다. 또한 페이지가 진정으로 처리하기 어려운 경우(텍스트 레이어가 없는 스캔본 등)에는 억지로 꾸며내지 않고 미리 알려줍니다. 이는 제가 보여드릴 수 있는 최소한의 기준(floor)이지,

1. 토큰 (Tokens). 모델이 PDF를 처리하기 위해서는 먼저 텍스트로 파싱 (Parsing)되어야 합니다. 단순한 패턴(매 채팅마다 PDF를 첨부하는 방식)에서는 매 턴마다 해당 파싱 비용을 다시 지불하게 됩니다. 프롬프트 캐싱 (Prompt caching)과 RAG (검색 증강 생성)가 이 문제를 완화해주기는 하지만, 이들 역시 근본적인 원인, 즉 PDF가 애초에 텍스트가 아니었다는 점을 우회하여 해결하려는 방식입니다. 한 번 Markdown으로 변환해 두면 파싱은 영구적으로 완료됩니다. 임베딩 (Embedding) 비용도 저렴하고, 검색 비용도 저렴하며, 질문하는 비용도 저렴해집니다.

2. 에이전트는 필요할 때 읽습니다. Claude Code와 Codex는 파일 전체를 컨텍스트 (Context)에 들이붓지 않습니다. 대신 필요한 시점에 필요한 몇 줄만을 grep 하고 검색합니다. PDF는 먼저 텍스트로 추출하지 않으면 그런 방식으로 검색할 수 없으며, 이것이 바로 "Markdown으로 변환하는 것"의 핵심입니다. 한 번만 수행하면 당신의 에이전트는 이를 저장소 (Repo) 내의 다른 파일들과 동일하게 취급합니다.

에이전트가 실제로 읽는 방식: Markdown을 사용하면 필요한 세 줄만 가져올 수 있습니다. 반면 PDF는 검색을 시작하기 전에 전체를 디코딩 (Decoding)해야 합니다.

따라서 트렌드는 직관과는 반대로 흘러갑니다. AI가 하나의 문서와 채팅하는 것에서 에이전트가 코드와 문서 전체 라이브러리를 탐색하는 것으로 변화함에 따라, PDF는 병목 현상 (Bottleneck)을 줄이는 것이 아니라 오히려 더 크게 만듭니다. 모델이 좋아질수록 에이전트 패턴은 더 흔해질 것이며, 이는 깔끔한 Markdown의 필요성을 줄이는 것이 아니라 오히려 더 높입니다.

"저는 그냥 Obsidian에 PDF를 보관하는데, 그래도 이게 필요한가요?"

특히 그렇습니다. 보관함 (Vault)의 생명은 당신이 무엇을 검색하고, 연결하고, 다른 노트로 접어 넣을 수 있느냐에 달려 있습니다. 보관함에 놓인 가공되지 않은 PDF는 막다른 길과 같습니다. 내부의 헤딩 (Heading)으로 [[link]]를 걸 수도 없고, 한 단락을 데일리 노트로 가져올 수도 없으며, grep 할 수도 없습니다. Markdown으로 변환하면 PDF는 다른 모든 것과 마찬가지로 당신과 당신의 보관함을 사용하는 모든 AI가 읽을 수 있는 일급 시민 (First-class) 노트가 됩니다.

요약

• 대부분의 PDF는 글자가 _어디에 위치하는지(where glyphs sit)_를 저장할 뿐, _무엇을 어떤 순서로 말하는지(what they say in what order)_를 저장하지 않습니다. 따라서 이를 읽는 모든 것은 추측을 해야 하며, 표(tables), 수식(formulas), 다단 페이지(multi-column pages), 스캔본(scans) 및 그림(figures)에서 그 추측이 가장 최악의 결과를 낳습니다.
• PDF를 텍스트로 추출하기 전까지는 grep을 하거나 임베딩(embed)할 수 없습니다. 깔끔한 마크다운(Markdown) 이야말로 구조가 유지된 텍스트입니다. 즉, grep이 가능하고, 토큰 비용이 저렴하며, 모델이 네이티브하게 읽을 수 있는 형태입니다. llms.txt도 웹을 위한 동일한 개념입니다.
• 더 똑똑한 모델들이 나온다고 해서 이 문제가 사라지는 것은 아닙니다. 토큰 비용과 에이전트(agent) 방식의 온디맨드(on-demand) 읽기 방식 때문에, 한 번 마크다운으로 변환해 두는 것은 시간이 지날수록 더욱 가치 있어집니다.

PDF를 깔끔한 마크다운으로 한 번 변환하고, 표와 수식이 제대로 들어왔는지 훑어보며 확인하세요. 그 이후부터는 당신이 전달하는 모든 도구, 모델, 에이전트가 원본을 추측하는 대신 진짜 내용을 읽게 됩니다.