# 멀티모달 RAG가 느려지는 이유: 무거운 PDF와 문서 전처리

> 원문: https://filepresso.writerun.blog/multimodal-rag-slow-pdf-document-preprocessing · 발행 2026-08-03 · 파일프레소

![](https://writerun.blog/assets/05292f77-b329-4557-9ce5-d913d7e6df4c/image.png)

## 응답이 느린 이유, 모델보다 먼저 봐야 할 지점

**​**

**사내 AI 시스템에 수십 페이지짜리**

**실무용 PDF 문서를 올리고 질문을 던졌을 때,**

**답변 대신 로딩 아이콘만 하염없이 도는 답답한 경험,**

**다들 한 번쯤 있으실 겁니다.**

​

겉으로는 모델이 느려 보이지만,

실제 병목은 문서 처리 단계에 있을 수 있습니다.

​

기다림이 10초, 20초 길어질수록

우리는 자연스럽게 AI 모델 자체를 의심하게 됩니다.

​

***'도입한 LLM 성능이 떨어지나?'***

***'프롬프트를 너무 복잡하게 짰나?'***

***'서버 GPU를 더 늘려야 하나?'*** 와 같은 질문들이

즉각적으로 꼬리를 물죠.

​

하지만 문서 기반 질의응답(RAG) 환경에서는

모델 자체보다 PDF 로딩, OCR, 파싱,

임베딩 전처리 같은 문서 처리 단계가

지연 원인이 되는 경우가 많습니다.

​

특히 도표, 스캔 이미지, 표, 도면이 섞인

기업용 PDF 문서는 단순 텍스트 파일처럼

가볍게 다뤄지지 않습니다.

​

IBM은 문서 처리 자동화와 생성형 AI 활용 사례를,

Snowflake는 데이터·AI 플랫폼 관점에서

멀티모달 데이터 활용을 강조합니다.

​

이런 복합 시각 요소가 많은 엔터프라이즈 PDF는

전통적인 검색 구조에 적지 않은 부담을 줄 수 있습니다.

​

이 말은 진단의 순서가 바뀌어야 함을 의미합니다.

**따라서 응답 지연은 모델 성능보다**

**문서 입수·전처리 단계부터 점검해야 합니다.**

​

이미지가 많은 묵직한 PDF를 스토리지에서 불러오고,

페이지 단위로 렌더링하며,

임베딩 가능한 조각으로 바꾸는 전처리 구간이 길다면,

AI는 그 단계에서 지연을 겪게 됩니다.

​

![](https://writerun.blog/assets/f1822790-f93e-4278-98c0-1c53bb16efd6/image.jpg)

**​**

## 무거운 PDF가 RAG를 느리게 만드는 실제 메커니즘

​

PDF 용량이 크다는 것은 단순히 저장 공간을 많이

차지한다는 뜻으로 끝나지 않습니다.

​

**문서를 읽어 메모리에 올리고, 해석하고,**

**임베딩 파이프라인에 넘기는**

**연쇄적인 시간 지연이 발생합니다.**

​

**문서가 클수록 한 번의 질의에 건드려야 할**

**데이터 바이트 수가 늘어나며 I/O 및 전처리 비용이 급증합니다.**

​

여기서 중요한 것은 '문서 내용의 복잡성'과

'물리적 용량(크기)'을 분리해서 접근하는 것입니다.

​

내용의 복잡성은 모델이 풀어야 할 숙제이지만,

압도적인 물리량은 저장장치·네트워크·메모리·파서가

감당해야 할 문제입니다.

​

화면에 '답변 생성 중'이라는 메시지가 뜨더라도,

실제로는 데이터를 불러오는 준비 단계에서

허덕이고 있을 확률이 높습니다.

​

**📝 문서 용량 병목을 확인하는 자가 진단 3요소**

**​**

**✅ 경량 문서 테스트** **:** 텍스트만 남긴 가벼운 문서로

같은 질문을 던졌을 때 응답 시간이 확연히 줄어드는가?

​

**✅ 캐시 여부** **:** 캐시가 없는 최초 질의 시에만

유독 지연이 심한가?

**​**

**✅ 리소스 모니터링** **:** GPU 사용률보다 스토리지

읽기나 문서 파싱 시간이 더 길게 기록되는가?

​

위 항목 중 둘 이상에 해당한다면, 병목은 생성 모델이

아닌 '문서 입수' 단계에 있을 가능성이 큽니다.

​

​

​

## ZIP 압축과 콘텐츠 용량 최적화(파일프레소)는 어떻게 다른가?

**구분**
**일반 파일 압축 (ZIP 등)**
**파일프레소**

**방식**
파일의 확장자를 .zip 등으로 변경하여 압축합니다.
원본 파일의 확장자(PDF, DOCX 등)를 그대로 유지합니다.

**활용**
파일을 읽고 사용하기 위해서는 반드시 압축 해제 과정이 선행되어야 합니다.
별도의 압축 해제 과정 없이 즉시 파일을 읽고 활용할 수 있습니다.

**적합성**
단발성 전송이나 장기 보관(아카이빙) 목적에 적합합니다.
파일을 반복적으로 열고 인덱싱해야 하는 RAG 파이프라인에 최적화되어 있습니다.

ZIP은 저장 효율은 높여주지만 데이터를 사용할 때

해제라는 후속 작업을 강제합니다.

​

반면, **파일프레소**는 **파일 형식과 구조를 유지한 채**

**데이터의 군더더기를 덜어내므로,**

**저장과 읽기 단계 모두에서 속도 이점을 가져다줍니다.**

​

​

![](https://writerun.blog/assets/8127e263-af68-4f47-b6d9-c46764cd09b3/image.jpg)

## RAG 파이프라인을 위한 문서 다이어트 3대 기준

**​**

콘텐츠 용량 최적화 솔루션을 검토할 때는

다음의 세 가지 기준을 충족해야 합니다.

​

**1. 원본 확장자 유지****:** 후속 파이프라인 추가 없이

기존 시스템에서 즉시 열람 및 처리가 가능해야 합니다.

​

**2. 시각 정보 품질 보존****:** 텍스트 주변 노이즈나

표 경계 훼손이 없어야 사람뿐만 아니라 OCR,

비전 인코더 등의 AI 모델이 정확히 인식할 수 있습니다.

**​**

**3. 구조 변경 없는 연동****:** 새로운 뷰어나 시스템 도입을

강요하지 않고 기존 파서와 인덱서를

그대로 활용할 수 있어야 합니다.

​

**파일프레소**는 이러한 기준에 부합합니다.

**이미지, 동영상, PDF, DOCX, XLSX 등**

**주요 업무 문서의 원본 포맷을 그대로 지원**합니다.

​

해상도나 품질 저하를 최소화하는 '시각적 최적화'로

**파일 용량을 원본 대비 최대 90%까지 줄여줍니다.**

​

이미지가 포함되지 않은 일반 텍스트 문서라도

메타데이터 최적화를 거쳐 용량을 대폭 절감할 수 있습니다.

​

이미지나 도표가 많아 사내 문서를 반복적으로

참조해야 하는 환경에서는 이러한 '압축을 풀지 않고

바로 읽을 수 있는 운영형 문서'의 확보가 필수적입니다.

​

​

​

## 도입 전 점검해야 할 3단계 시나리오

**​**

AI의 응답 속도를 개선하기 위해 새로운 솔루션 도입을

검토 중이라면, 거창한 인프라 점검보다

다음 세 가지를 먼저 실행해 보시길 권장합니다.

​

**✅ 구간별 병목 측정**

전체 처리 시간을 '문서 로딩 시간',

'파싱 및 OCR 시간', '임베딩 및 검색 시간' 3구간으로

나누어 특정 구간의 지연이 압도적인지 확인합니다.

​

**✅ 샘플 문서 대조 테스트**

100페이지 분량의 텍스트 중심 PDF와 도표·스캔본이

다수 포함된 고용량 PDF를 각각 RAG에 투입하여,

첫 질의 응답 속도와 OCR 회수 품질을 비교 분석합니다.

​

**✅ 운영본 분리 적용 검토**

컴플라이언스 문제로 원본 수정이 불가능한 경우,

보존용은 놔두고 RAG가 참조할 '검색용 운영본'에만

최적화를 적용하는 아키텍처가 유효한지 판단합니다.

​

결국 AI의 성능을 온전히 끌어내기 위해 가장 먼저

해결해야 할 과제는, 문서를 작게 뭉쳐놓는 것이 아니라

**'AI가 즉시 읽어 들일 수 있도록**

**가볍고 선명하게 다듬어주는 것'입니다.**

​

무거운 문서 20개를 뽑아 로딩 시간을 먼저 재보세요.

진짜 문제는 그 숫자 안에 숨어 있습니다.

​

콘텐츠 용량 최적화 솔루션, 파일프레소에 대해

궁금한 점이 있으시면

consulting@bellins.net 로 언제든 문의주세요💙