문서 추출 (Document Extraction)

나는 문서 추출 문제를 해결했다고 생각했다.

나의 Node.js 프로젝트는 PDF에서 텍스트를 뽑아낼 수 있었다. 사용한 라이브러리는 무료였다. API 비용도, 설정도, 번거로움도 없었다. 몇 개의 샘플 문서로 실행해 보니 텍스트가 깔끔하게 추출되었고, 나는 파이프라인(pipeline)의 "진짜" 부분들인 청킹 (chunking), 임베딩 (embeddings), 검색 (retrieval) 단계로 넘어갔다.

모든 것이 해결된 것처럼 보였다.

실제 기업 문서를 업로드하기 전까지는 말이다.

PDF는 문제없이 열렸다. 오류도 없었다. 텍스트가 추출되어 터미널에 긴 문자열로 그대로 나타났다. 추출은 "작동"했다.

그리고 나서 나의 RAG 시스템은 아주 간단한 질문에 완전히 틀린 답변을 내놓았다.

나는 누구나 그렇듯 평소 의심되는 요소들을 점검했다. LLM 프롬프트 (prompt)를 확인했다. 임베딩 (embeddings)을 확인했다. 검색 (retrieval)을 확인하고, 벡터 DB (vector DB)를 확인했으며, 올바른 청크 (chunks)가 제대로 불러와지고 있는지까지 확인했다.

모두 정상이었다.

버그는 나의 LLM에 있지 않았다. 임베딩 (embeddings)에도 없었다. 검색 (retrieval) 단계에도 없었다.

그것은 이 모든 단계보다 훨씬 앞선 곳에서 시작되었다.

파서 (parser)가 파이프라인의 나머지 단계들이 문서를 보기도 전에 조용히 문서를 망가뜨려 놓았던 것이다.

그 순간 깨달음이 왔다. 문서 추출은 단순히 "PDF를 읽는 것"이 아니었다. 그것은 다운스트림 (downstream)의 어떤 단계가 사용하기 전에 지식을 보존하는 것에 관한 문제였다. 그리고 지식을 보존하는 데에는 비용이 든다는 사실을 알게 되었다.

이 글 전체가 다루고자 하는 아이디어

아래의 모든 내용은 하나의 문장으로 귀결된다:

문서 추출은 당신이 인지하든 못하든, RAG 파이프라인에서 품질 대 비용 (quality-vs-cost) 결정을 내리는 첫 번째 지점이다.

"어떤 라이브러리를 사용해야 하는가"가 아니다. "OCR은 어렵다"는 것도 아니다. 단지 이것이다: 문서가 시스템에 들어오는 순간, 당신은 이미 저렴하지만 손실이 많은 방식과 비싸지만 충실한 방식 사이에서 선택을 하고 있으며, 그 선택이 이후의 모든 단계에 대한 한계치를 조용히 설정한다는 것이다.

"무료" 파서 비용이 실제로 지불되는 방식

나를 속였던 과정을 명확하게 나열하면 다음과 같다:

무료 파서 (Free parser)
     │
     ▼
...

그 체인에서 무엇이 빠져 있는지 주목하십시오: 바로 에러 메시지입니다. 추출(extraction) 과정이 실패하더라도 시스템이 충돌하는 경우는 거의 없습니다. 그저 조용히, 자신감 있고 형식이 잘 갖춰진, 하지만 '틀린' 답을 내놓을 뿐입니다. 그리고 그 실수에 대한 비용은 추출 단계에서 나타나지 않습니다. 대신 나중에, "사용자의 재시도" 또는 "환각률 (hallucination rate)"로 위장하여 LLM 단계에서 나타납니다.

그것이 함정입니다. 무료 파서 (Free parser)를 선택했다고 해서 비용이 사라진 것이 아닙니다. 단지 전체 파이프라인에서 가장 비용이 많이 드는 단계로 이동하여 그곳에 숨어버린 것입니다.

돈은 실제로 어디로 가는가?

추상적인 논의 대신 구체적인 사례를 들어보겠습니다.

당신이 한 달에 100만 페이지를 처리한다고 가정해 봅시다.

옵션 A — 무료 오픈 소스 파서 (Free, open-source parser)

API 비용: 월 $0

하지만:

• 표 (Tables)의 구조가 깨집니다.
• 스캔된 페이지의 OCR (Optical Character Recognition)이 상당 부분에서 조용히 실패합니다.
• 다이어그램과 스크린샷이 텍스트 없이 <Image>로 사라집니다.
• 다단(Multi-column) 페이지의 내용이 뒤섞입니다.

결과:

잘못된 추출 (Bad extraction)
     ↓
사용자가 원하는 답을 얻지 못함
...

추출 비용은 $0입니다. 하지만 성공적으로 답변된 질문당 실질적인 (effective) 비용은 2~3배 증가했습니다. 하나의 정답을 얻기 위해 LLM 호출 비용을 세 번 지불하고 있기 때문입니다.

옵션 B — 엔터프라이즈 문서 지능 (Enterprise document intelligence)

추출 비용: 월 몇 백 달러가 더 든다고 가정

하지만:

• 대다수의 표, 양식, 레이아웃이 온전하게 유지됩니다.
• 다이어그램이 사용 가능한 텍스트로 설명됩니다.
• 다단 페이지의 읽기 순서가 보존됩니다.

결과:

정확한 추출 (Good extraction)
     ↓
첫 번째 시도에 올바른 청크 (chunk) 검색
...

이제 이 논리를 규모(volume)에 적용해 보십시오. 옵션 A에서 아주 적은 비율의 쿼리라도 재시도가 필요하다면 — 그리고 각 재시도는 전체 LLM 라운드 트립 (round-trip)을 발생시킨다면 — "무료" 파서는 유료 추출 서비스를 직접 사용하는 것보다 추가적인 LLM 호출 비용으로 인해 결과적으로 더 많은 비용을 치르게 될 가능성이 큽니다. 게다가 그냥 포기하고 봇을 더 이상 신뢰하지 않게 되는 사용자들까지 고려한다면 더욱 그렇습니다.

그러한 시나리오에서, "비싼" 파서(parser)는 더 이상 비싼 선택지가 아닙니다. 그것은 더 저렴한 시스템이 됩니다.

이 시리즈의 핵심이 바로 이것입니다. 여러분이 걱정하는 비용 항목은 실제로 예산을 갉아먹는 항목인 경우가 거의 없습니다.

아무도 청구서를 보내지 않는 또 다른 비용이 있습니다. 바로 엔지니어링 시간(engineering time)입니다. 깨져버리는 모든 문서 유형 — 이상한 표 레이아웃, 흐릿한 잉크로 스캔된 페이지, 2단 구성 보고서 등 — 은 팀원 중 누군가가 인지하고, 디버깅(debug)하고, 테스트하고, 유지보수해야 하는 또 다른 예외 사례(edge case)가 됩니다. 무료 파서가 제품을 만드는 대신 추출 버그를 패치하는 데 팀의 시간을 몇 주씩 소모하게 만든다면, 그것은 진정으로 무료가 아닙니다.

아무도 기록하지 않는 비용: 반복되는 상용구(Boilerplate)

이 부분은 제가 추출(extraction)에 대해 생각하는 방식을 가장 크게 변화시킨 지점이며, 너무 사소해 보여서 쓰기를 거의 포기할 뻔했습니다. 하지만 사소하지 않습니다.

400페이지 분량의 은행 문서의 모든 페이지에 다음과 같은 푸터(footer)가 있다고 가정해 봅시다.

Confidential
Acme Bank
2025

사소해 보이죠? 하지만 여러분의 파서(parser)는 이것이 푸터라는 것을 모릅니다. 파서는 그저 모든 페이지에서 텍스트를 볼 뿐입니다.

Page 1  →  "Confidential Acme Bank 2025" + 실제 내용
Page 2  →  "Confidential Acme Bank 2025" + 실제 내용
Page 3  →  "Confidential Acme Bank 2025" + 실제 내용
...

그 문장 하나가 무려 400번 임베딩(embedded)되었습니다. 이제 이 문장은 데이터베이스에 거의 동일한 400개의 벡터(vector)로 존재하며, 임베딩 공간(embedding space)에서 서로 밀집되어 클러스터링(clustered)되어 있습니다.

여기서 실제로 타격을 입게 됩니다. 누군가 실제 질문을 던졌을 때, "Confidential Acme Bank 2025" 청크(chunk)들은 밀도가 높고 반복적이며 의미론적으로 일반적(semantically generic)이기 때문에, 실제 콘텐츠가 차지해야 할 top-k 슬롯을 밀어낼 수 있습니다. 검색(Retrieval)이 지식이 아닌 노이즈를 계속 반환하게 됩니다. 이는 검색 기능이 고장 나서가 아니라, 아무 의미 없는 데이터 400개를 입력했기 때문입니다.

정제되지 않은 상용구(Uncleaned boilerplate)
       ↓
400개의 거의 중복된 청크(near-duplicate chunks)
...

청킹 (Chunking)을 수행하기 전에 헤더 (Header), 푸터 (Footer), 페이지 번호, 워터마크 (Watermark)를 제거하는 것은 단순히 미관상의 정리 단계가 아닙니다. 이는 비용 최적화 (Cost optimization) 단계입니다. 그리고 이는 거의 아무도 이야기하지 않는 부분인데, 그 이유는 어떤 가격 책정 페이지 (Pricing page)에도 나타나지 않기 때문입니다.

다른 반복적인 문제 요소들 (Other Repeat Offenders)

이러한 패턴을 찾기 시작하면, 기업 문서의 모든 곳에서 나타납니다:

• 반복되는 로고 (Logos)
• 반복되는 페이지 번호 ("Page 47 of 212")
• 반복되는 워터마크 (Watermarks)
• 반복되는 면책 조항 (Disclaimers) ("This document is confidential and intended only for...")
• 반복되는 서명 블록 (Signature blocks)
• 모든 페이지 상단 또는 하단에 반복되는 법적 문구 (Legal boilerplate)

각 요소는 정확히 동일한 연쇄 과정을 따릅니다:

더 많은 불필요한 문구 (Boilerplate)  →  더 많은 청크 (Chunks)  →  더 많은 임베딩 (Embeddings)
        →  더 큰 벡터 DB (Vector DB)  →  더 많은 검색 노이즈 (Retrieval noise)
        →  더 많은 LLM 토큰 (Tokens)  →  더 많은 비용 (More money)

이 중 어느 것도 개별적으로는 비싸게 느껴지지 않습니다. 로고 하나는 비싸지 않습니다. 페이지 번호 하나도 비싸지 않습니다. 하지만 이러한 요소들을 수백 페이지, 수천 개의 문서에 곱하면, 지식의 추가 없이 벡터 데이터베이스 (Vector database)와 검색 노이즈 (Retrieval noise)를 조용히 부풀리게 됩니다. 이는 샘플 PDF 3개로 진행하는 데모에서는 보이지 않지만, 실제 운영 환경 (Production)에서 50,000개의 문서를 실행할 때는 매우 명확하게 드러나는 결정입니다.

또 다른 품질 대 비용의 갈림길: 이미지와 다이어그램 (Images and Diagrams)

오늘날의 기업 문서는 단순히 텍스트 단락으로만 이루어져 있지 않습니다. 다음과 같은 것들로 가득 차 있습니다:

• 아키텍처 다이어그램 (Architecture diagrams)
• 스크린샷 (Screenshots)
• 인보이스 (Invoices)
• 그래프 및 차트 (Graphs and charts)

그리고 여기서 여러분은 이 파이프라인(Pipeline)의 다른 모든 곳에서와 마찬가지로 정확히 동일한 갈림길에 맞닥뜨리게 됩니다:

                문서에 이미지가 포함됨
                         │
            ┌────────────┴────────────┐
...

이미지를 무시하는 것은 누군가가 오직 다이어그램(diagram) 내에만 존재하는 답을 요구하기 전까지는 비용이 들지 않습니다. 하지만 그 순간 "무료" 추출은 단지 "봇이 그 질문에 답할 수 없음"을 의미하게 되며, 여러분은 앞서 살펴본 표(table) 예시와 동일한 재시도 루프(retry loop)로 돌아가게 됩니다. 다만 이번에는 아무리 재시도해도 해결되지 않는데, 왜냐하면 지식 자체가 애초에 캡처되지 않았기 때문입니다.

동일한 갈림길, 동일한 트레이드오프 (trade-off), 매번 반복되는 동일한 근본적인 질문이 있습니다: 추출 품질을 위해 사전에 비용을 지불할 것인가, 아니면 추출 과정에서 발생한 공백을 메우기 위해 나중에 비용을 지불할 것인가?

한 문장으로 요약하기

표, OCR, 헤더 및 푸터 (headers and footers), 로고, 다이어그램 등 이 글에서 다룬 모든 섹션은 사실 서로 다른 모습을 하고 있을 뿐 동일한 결정 사항입니다:

지식을 보존하기 위해 추출 단계에서 비용을 조금 더 지불할 것인가, 아니면 추출 과정에서 조용히 버려진 것들을 보완하기 위해 나중에 재시도, 노이즈가 섞인 검색 (noisy retrieval), 그리고 LLM 토큰 (LLM tokens) 비용으로 훨씬 더 많은 비용을 지불할 것인가?

저렴한 추출은 실제로 저렴하지 않습니다. 그것은 단지 비용 청구서를 파이프라인에서 가장 비싼 부분으로 미루고, "환각률 (hallucination rate)"이나 "쿼리당 평균 토큰 (average tokens per query)"과 같이 관련 없어 보이는 지표 속에 비용을 숨길 뿐입니다.

이것이 바로 문서 추출 (document extraction)이 RAG 비용이 어디로 흘러가는지에 대한 시리즈에서 별도의 에피소드로 다뤄질 가치가 있는 진짜 이유입니다. 추출 비용 자체가 가장 큰 항목은 아닐지 모릅니다. 하지만 추출은 다른 모든 항목의 비용이 얼마나 커질지를 결정하는 단계입니다.

저는 임베딩 (embeddings)이 RAG를 비싸게 만드는 주범이라고 믿으며 이 시리즈를 시작했습니다. 하지만 두 에피소드를 지나오며 저는 매우 다른 사실을 깨닫고 있습니다. LLM 이전의 모든 단계가 결국 LLM이 여러분에게 최종적으로 얼마의 비용을 발생시킬지를 조용히 결정한다는 사실입니다.

가장 저렴한 파서 (parser)는 API 가격이 가장 낮은 것이 아닙니다. 불필요한 LLM 호출을 가장 적게 만들어내는 파서가 가장 저렴한 파서입니다.

에피소드 3 예고

이제 저는 제 추출 파이프라인을 훨씬 더 신뢰합니다. 하지만 즉시 새로운 질문이 떠올랐습니다:

깨끗한 텍스트를 얻었다면 — 이제 그것을 어떻게 나누어야(split) 하는가?

잘못된 파서가 지식을 망가뜨리는 것만큼이나, 잘못된 청킹 (chunking) 또한 완벽하게 추출된 지식을 쉽게 파괴할 수 있기 때문입니다.

노이즈는 줄이고, 실행은 더 많이. 이제 자세히 파헤쳐 봅시다.