문서 용량 줄이기만으로 RAG가 빨라질까?

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

사내 AI 시스템에 수십 페이지짜리 실무용 PDF 문서를 올리고 질문을 던졌을 때, 답변 대신 로딩 아이콘만 하염없이 도는 답답한 경험, 다들 한 번쯤 있으실 겁니다. 겉으로는 모델이 느려 보이지만, 실제 병목은 문서 처리 단계에 있을 수 있습니다.

기다림이 10초, 20초 길어질수록 우리는 자연스럽게 AI 모델 자체를 의심하게 됩니다. '도입한 LLM 성능이 떨어지나?', '프롬프트를 너무 복잡하게 짰나?', '서버 GPU를 더 늘려야 하나?'와 같은 질문들이 즉각적으로 꼬리를 물죠.

하지만 문서 기반 질의응답(RAG) 환경에서는 모델 자체보다 PDF 로딩, OCR, 파싱, 임베딩 전처리 같은 문서 처리 단계가 지연 원인이 되는 경우가 많습니다.

특히 도표, 스캔 이미지, 표, 도면이 섞인 기업용 PDF 문서는 단순 텍스트 파일처럼 가볍게 다뤄지지 않습니다. IBM은 문서 처리 자동화와 생성형 AI 활용 사례를, Snowflake는 데이터·AI 플랫폼 관점에서 멀티모달 데이터 활용을 강조합니다. 이런 복합 시각 요소가 많은 엔터프라이즈 PDF는 전통적인 검색 구조에 적지 않은 부담을 줄 수 있습니다.

이 말은 진단의 순서가 바뀌어야 함을 의미합니다. 따라서 응답 지연은 모델 성능보다 문서 입수·전처리 단계부터 점검해야 합니다. 이미지가 많은 묵직한 PDF를 스토리지에서 불러오고, 페이지 단위로 렌더링하며, 임베딩 가능한 조각으로 바꾸는 전처리 구간이 길다면, AI는 그 단계에서 지연을 겪게 됩니다.

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

PDF 용량이 크다는 것은 단순히 저장 공간을 많이 차지한다는 뜻으로 끝나지 않습니다. 문서를 읽어 메모리에 올리고, 해석하고, 임베딩 파이프라인에 넘기는 연쇄적인 시간 지연이 발생합니다. 문서가 클수록 한 번의 질의에 건드려야 할 데이터 바이트 수가 늘어나며 I/O 및 전처리 비용이 급증합니다.

여기서 중요한 것은 '문서 내용의 복잡성'과 '물리적 용량(크기)'을 분리해서 접근하는 것입니다. 내용의 복잡성은 모델이 풀어야 할 숙제이지만, 압도적인 물리량은 저장장치·네트워크·메모리·파서가 감당해야 할 문제입니다. 화면에 '답변 생성 중'이라는 메시지가 뜨더라도, 실제로는 데이터를 불러오는 준비 단계에서 허덕이고 있을 확률이 높습니다.

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

경량 문서 테스트: 텍스트만 남긴 가벼운 문서로 같은 질문을 던졌을 때 응답 시간이 확연히 줄어드는가?

캐시 여부: 캐시가 없는 최초 질의(Cold Start) 시에만 유독 지연이 심한가?

리소스 모니터링: GPU 사용률보다 스토리지 읽기나 문서 파싱 시간이 더 길게 기록되는가?

위 항목 중 둘 이상에 해당한다면, 병목은 생성 모델이 아닌 '문서 입수' 단계에 있을 가능성이 큽니다.

ZIP 압축과 문서 용량 최적화는 어떻게 다른가?

ZIP은 저장 효율은 높여주지만 데이터를 사용할 때 해제라는 후속 작업을 강제합니다. 반면, 문서 최적화는 파일 형식과 구조를 유지한 채 데이터의 군더더기를 덜어내므로, 저장과 읽기 단계 모두에서 속도 이점을 가져다줍니다.

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

콘텐츠 용량 최적화 솔루션을 검토할 때는 다음의 세 가지 기준을 충족해야 합니다.1. 원본 확장자 유지: 후속 파이프라인 추가 없이 기존 시스템에서 즉시 열람 및 처리가 가능해야 합니다.2. 시각 정보 품질 보존: 텍스트 주변 노이즈나 표 경계 훼손이 없어야 사람뿐만 아니라 OCR, 비전 인코더 등의 AI 모델이 정확히 인식할 수 있습니다. 3. 구조 변경 없는 연동: 새로운 뷰어나 시스템 도입을 강요하지 않고 기존 파서와 인덱서를 그대로 활용할 수 있어야 합니다. '파일프레소(Filepresso)'는 이러한 기준에 부합합니다. PDF, DOCX, XLSX 등 5가지 주요 업무 문서의 원본 포맷을 그대로 지원합니다. 해상도나 품질 저하를 최소화하는 '시각적 최적화 압축'을 통해 파일 용량을 원본 대비 최대 90%까지 줄여줍니다. 이미지가 포함되지 않은 일반 텍스트 문서라도 메타데이터 최적화를 거쳐 용량을 대폭 절감할 수 있습니다. 이미지나 도표가 많아 사내 문서를 반복적으로 참조해야 하는 환경에서는 이러한 '압축을 풀지 않고 바로 읽을 수 있는 운영형 문서'의 확보가 필수적입니다.

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

AI의 응답 속도를 개선하기 위해 새로운 솔루션 도입을 검토 중이라면, 거창한 인프라 점검보다 다음 세 가지를 먼저 실행해 보시길 권장합니다.

구간별 병목 측정: 전체 처리 시간을 '문서 로딩 시간', '파싱 및 OCR 시간', '임베딩 및 검색 시간' 3구간으로 나누어 특정 구간의 지연이 압도적인지 확인합니다.

샘플 문서 대조 테스트: 100페이지 분량의 텍스트 중심 PDF와 도표·스캔본이 다수 포함된 고용량 PDF를 각각 RAG에 투입하여, 첫 질의 응답 속도와 OCR 회수 품질을 비교 분석합니다.

운영본 분리 적용 검토: 컴플라이언스 문제로 원본 수정이 불가능한 경우, 보존용 원본은 놔두고 RAG가 참조할 '검색용 운영본'에만 최적화를 적용하는 아키텍처가 유효한지 판단합니다.

결국 AI의 성능을 온전히 끌어내기 위해 가장 먼저 해결해야 할 과제는, 문서를 작게 뭉쳐놓는 것이 아니라 'AI가 즉시 읽어 들일 수 있도록 가볍고 선명하게 다듬어주는 것'입니다. 다음 시연을 준비하기 전, 가장 무거운 문서 20개를 뽑아 로딩 시간을 먼저 재보십시오. 진짜 문제는 그 숫자 안에 숨어 있습니다.