이 논문은 기업의 온갖 문서 형식(PDF, 워드, 프레젠테이션, 스캔본)을 RAG(검색 증강 생성) 시스템에 넣기 위한 새로운 전처리 방법 D-RAC를 제안한다. 핵심은 모든 문서를 일단 PDF로 표준화하고, 멀티모달 LLM 한 번의 처리로 '검색에 최적화된 마크다운'으로 바꾼 뒤, 텍스트를 다시 생성하지 않고 식별자(ID) 기반으로 청킹하는 것이다. 그 결과 초록 기준으로 청킹 단계 출력 토큰을 95.7% 줄이고, 비용을 77.8~85.6% 절감했다.
기업이 사내 지식을 챗봇이나 검색 시스템에 태우려면, 먼저 문서를 잘게 쪼개(청킹) 검색 가능한 조각으로 만들어야 한다. 그런데 현실의 기업 문서는 형식이 제각각이다. PDF, 워드, 파워포인트, 그리고 종이를 찍은 스캔본까지 섞여 있다. 게다가 그 안의 정보는 복잡한 시각적 레이아웃, 여러 단(칼럼)으로 나뉜 페이지, 빽빽한 표 안에 갇혀 있다.
문제는 이 문서를 기계가 '읽는 순서대로' 풀어내기가 매우 어렵다는 점이다. 논문은 기존 방식의 두 갈래 모두 한계가 있다고 지적한다.
첫째, 규칙 기반 추출이나 OCR(광학 문자 인식). 이 방식은 마치 신문 지면을 위에서 아래로 무작정 훑는 것과 같아서, 읽는 순서(reading order)를 망가뜨리고, 표를 납작하게 뭉개며(flatten), 제목의 계층 구조(heading hierarchy)를 잃어버린다. 2단 편집된 페이지를 왼쪽 위부터 오른쪽 아래로 죽 읽어버리면 문맥이 뒤엉키는 것을 떠올리면 된다.
둘째, 추출한 텍스트 위에서 LLM이 알아서 다 처리하는 '완전 에이전트형 청킹(agentic chunking)'. 품질은 나을 수 있지만, LLM이 텍스트를 다시 써 내려가야 하므로 토큰 비용이 많이 들고, 없는 내용을 지어내는 환각(hallucination) 위험도 생긴다.
정리하면, 정확도를 지키려 하면 비용과 환각이 커지고, 저렴한 규칙 기반으로 가면 문서 구조가 무너진다. D-RAC는 이 딜레마를 겨냥한다.
D-RAC는 저자들이 앞서 발표한 웹 문서용 프레임워크 W-RAC(Web Retrieval-Aware Chunking)를 임의의 문서 형식으로 확장한 것이다. 이름 그대로 '검색을 염두에 둔(Retrieval-Aware) 청킹'이다. 동작을 일상적인 비유로 풀면 이렇다.
1단계, 모든 문서를 PDF로 표준화한다. 워드든 PPT든 스캔이든, 사실상 모든 형식은 '충실하고 결정론적인(deterministic, 즉 매번 같은 결과가 나오는) PDF 인쇄본'을 가진다는 점을 활용한다. 프린터로 뽑으면 어떤 파일이든 똑같은 종이 모양이 되는 것과 같다. 입력의 다양성을 PDF라는 하나의 관문으로 모으는 것이다.
2단계, 멀티모달 LLM(글자뿐 아니라 이미지·레이아웃을 함께 보는 모델)이 렌더링된 페이지를 한 번 훑어 '검색 최적화 마크다운'으로 바꾼다. 이때 두 가지가 핵심이다. 표는 앞뒤 맥락 없이도 그 자체로 이해되는 '자족적 문장(self-contained prose)'으로 다시 쓴다. 예를 들어 '분기 / 매출' 표의 한 칸을 "2026년 3분기 매출은 …이다"처럼 완결된 문장으로 풀어, 나중에 조각으로 잘려 나가도 뜻이 살아남게 한다. 동시에 제목의 계층 구조는 그대로 보존한다.
3단계, 이렇게 만든 마크다운을 W-RAC 방식 그대로 청킹한다. 먼저 결정론적으로 파싱해 'ID로 지정 가능한 단위(ID-addressable units)'로 나눈다. 문서 조각마다 번호표를 붙이는 셈이다. 그다음 가벼운 LLM이 각 조각의 짧은 텍스트 미리보기(대략 200~400자)와 제목 계층 정보를 함께 보고, 어떤 조각을 어떻게 묶을지 계획(chunk planning)한다. 이때 원본 텍스트를 다시 써 내려가는 것이 아니라, 계획의 '출력'을 조각의 식별자(번호)만으로 표현하는 것이 핵심이다. 도서관 사서가 책 내용을 통째로 베껴 쓰는 대신, 표지 요약과 분류 정보를 훑어보되 최종 분류표에는 청구기호만 적어 넣는 것과 같다.
이 설계의 결정적 장점은 '청킹 중에는 원본 텍스트를 절대 다시 생성하지 않는다'는 점이다. LLM이 미리보기와 계층 정보를 참고하되 출력으로는 번호만 내놓으므로 내용을 지어낼 여지가 없고(관측 가능성·observability 유지), 출력 토큰이 극히 적다(저비용). 다만 여기서 결정론적인 부분은 마크다운을 조각으로 나누는 파싱과, 주어진 ID 계획에 따라 텍스트를 다시 이어 붙이는 재구성 단계다. 어떤 조각을 어떻게 묶을지 정하는 계획 자체는 여전히 LLM이 생성하고(논문 실험도 temperature 0.1을 사용한다), ID만 출력한다고 해서 매 실행의 청크 구성이 반드시 똑같다고 보장되는 것은 아니다. 그럼에도 W-RAC가 웹에서 누리던 관측 가능성과 저비용이라는 이점을 그대로 유지하면서, '렌더링 가능한 모든 형식'을 일급 입력으로 받아들이게 된 것이다.
논문은 RAG-Multi-Corpus 벤치마크의 PDF 하위 집합에서 D-RAC를 평가했다. 이 하위 집합은 다섯 개 기업 도메인에 걸친 236개 문서, 795페이지 규모다. 초록이 밝힌 수치는 다음과 같다.
| 항목 | 결과(초록 기준) |
|---|---|
| 전체 코퍼스 변환·청킹 시간 | 72분, 오류 0건 |
| 생성된 검색용 청크 | 1,748개 |
| 청킹 단계 출력 토큰 | 95.7% 감소 |
| 청킹 비용 절감 | 77.8%(GPT-4.1 가격) ~ 85.6%(Gemini 2.5 Pro 가격) |
| 청킹 시간 | 75% 단축 |
| 확장성 | 500페이지 이상 문서에도 선형(linear) 확장 |
여기서 비교 대상은 '프런티어 LLM을 쓴 에이전트형 청킹'이다. 즉 최신 대형 모델로 알아서 청킹하는 방식과 견줬을 때, D-RAC는 출력 토큰을 20분의 1 수준으로 줄이면서도 795페이지 코퍼스를 오류 없이 처리했다는 것이 핵심 성과다. 비용이 GPT-4.1 기준 약 5분의 1, Gemini 2.5 Pro 기준 약 7분의 1로 떨어졌다는 점은, 대규모 문서를 다루는 기업 입장에서 곧바로 체감되는 절감이다.
'선형 확장'이라는 표현도 중요하다. 문서가 500페이지를 넘어가도 처리 시간이 페이지 수에 비례해 늘 뿐, 급격히 폭증하지 않는다는 뜻이다. 수천 페이지짜리 매뉴얼·계약서·규정집이 흔한 기업 환경에서 예측 가능한 비용 구조를 제공한다.
초록만으로 판단할 때 몇 가지는 솔직히 짚어야 한다.
온틀은 'AI 프로젝트 매니저 파견형 SaaS'로, 소기업과 1인 창업가의 반복 업무를 덜어주는 것을 지향한다. 그런 제품에서 사내 문서를 다루는 RAG는 곧 'AI가 회사 자료를 정확히 읽고 답하게 하는' 토대다. D-RAC의 접근은 이 지점에서 실용적인 시사점을 준다.
첫째, 입력 형식의 다양성을 'PDF 표준화'라는 하나의 관문으로 흡수하는 발상은, 고객사마다 워드·엑셀·PPT·스캔본이 뒤섞인 현실에 잘 맞는다. 형식마다 별도 파서를 만들어 유지보수하는 부담을 줄일 수 있다.
둘째, '청킹 중에는 텍스트를 다시 생성하지 않는다'는 원칙은 비용과 신뢰성 모두에 의미가 있다. AI PM처럼 반복적으로 대량 문서를 처리해야 하는 제품에서, 출력 토큰을 줄이면 운영비가 내려가고, 묶음의 결과가 새로 쓴 문장이 아니라 조각 번호로 남으면 '왜 이 조각이 이렇게 묶였는가'를 추적하기 쉬워진다(관측 가능성). 고객에게 근거를 설명해야 하는 업무 도구일수록 이 관측 가능성은 품질만큼 중요하다.
셋째, 표를 자족적 문장으로 풀어 두는 전략은 검색 품질에 직접적이다. 실제 업무 문서의 핵심 정보는 표에 몰려 있는 경우가 많은데, 조각으로 잘려도 뜻이 살아남는 형태로 저장해 두면 답변의 근거 인용이 안정된다.
다만 온틀 관점에서도 앞의 한계는 그대로 유효하다. 최종 검색·답변 품질 지표는 본문에서 별도로 확인해야 하고, 마크다운 변환 단계의 정확도는 도입 전에 자사 문서로 소규모 검증(파일럿)해 보는 것이 안전하다. 비용 절감 수치는 인상적이지만, 우리 데이터에서의 재현은 별개 문제라는 태도가 맞다.
워드·PPT·스캔 등 형식이 제각각이라도 거의 모든 형식은 '충실하고 매번 같은 결과가 나오는 PDF 인쇄본'을 만들 수 있기 때문입니다. 입력의 다양성을 PDF라는 하나의 관문으로 모으면, 형식마다 별도 처리 로직을 만들 필요 없이 이후 단계를 통일할 수 있습니다.
초록 기준으로, 프런티어 LLM을 쓴 에이전트형 청킹과 비교해 청킹 단계 출력 토큰을 95.7% 줄였고, 청킹 비용을 GPT-4.1 가격 기준 77.8%, Gemini 2.5 Pro 가격 기준 85.6% 절감했으며 청킹 시간은 75% 단축했습니다.
D-RAC는 청킹 단계에서 원본 텍스트를 다시 생성하지 않습니다. LLM은 각 조각의 짧은 텍스트 미리보기(대략 200~400자)와 제목 계층 정보를 참고하지만, 계획의 출력은 조각에 붙은 식별자(번호)만으로 표현하므로, 내용을 새로 써 내려가며 환각을 일으킬 여지가 줄어듭니다. 다만 어떤 조각을 어떻게 묶을지 정하는 계획 자체는 LLM이 생성하므로(실험도 temperature 0.1 사용), 매 실행의 청크 구성이 완전히 동일하다고 보장되지는 않습니다. 또한 그 앞의 마크다운 변환 단계는 여전히 멀티모달 모델의 이해에 의존합니다.
초록이 제시한 수치는 주로 청킹 단계의 비용·속도·처리 안정성입니다. 표를 자족적 문장으로 풀고 제목 계층을 보존하는 설계는 검색에 유리하도록 의도됐지만, 최종 검색·답변 품질에 대한 구체 수치는 초록에 명시돼 있지 않으므로 본문의 상세 평가를 확인해야 합니다.