Multimodal RAG

텍스트만 다루는 RAG는 어느 순간 아주 이상한 벽에 부딪힌다. 사용자는 분명 문서 안에 답이 있다고 말하는데, 시스템은 자꾸 엉뚱한 문단만 가져온다. 왜 그럴까. 답이 문단 안이 아니라 표의 셀, 차트의 축, 매뉴얼의 그림, 스캔 PDF의 작은 주석, 회의 녹음의 특정 시점에 있기 때문이다. 현실의 지식은 원래 텍스트만으로 존재하지 않는다.¹

이 지점에서 멀티모달 RAG는 선택이 아니라 확장이다. 더 화려한 데모를 만들기 위한 기능이 아니라, 실제 문서를 제대로 읽기 위해 필요한 구조다. 특히 논문, 특허, 제품 매뉴얼, 프레젠테이션 슬라이드, 스캔 계약서, 고객 통화 녹음처럼 여러 형식이 섞인 자료에서는 텍스트 중심 RAG가 구조적으로 놓치는 정보가 생긴다.²

텍스트 중심 RAG가 놓치는 것

텍스트 RAG는 문서를 문장과 문단의 연속으로 본다. 하지만 PDF는 본질적으로 의미 파일이 아니라 레이아웃 컨테이너에 가깝다. 사람은 페이지를 보면서 제목, 본문, 표, 캡션, 그림의 관계를 한눈에 이해하지만, 파이프라인은 그 관계를 추론해야 한다. 이 추론이 틀어지면 의미도 같이 틀어진다.¹

예를 들어 제품 매뉴얼에서 "빨간 표시가 뜨면 3단계를 다시 수행하라"라는 문장이 있다고 하자. 텍스트만 보면 그럴듯하다. 하지만 핵심은 바로 옆 그림의 빨간 아이콘 모양일 수 있다. 논문에서는 "Figure 3에서 보인 것처럼"이 자주 등장한다. 특허 문서에서는 청구항 설명보다 도면 부호가 더 중요할 때도 많다. 재무 보고서에서는 설명 문단보다 표의 헤더와 숫자 관계가 정답을 결정한다. 텍스트만 뽑아 임베딩하면, 중요한 증거를 스스로 버린 채 검색을 시작하는 셈이다.²

멀티모달 RAG의 기본 생각

멀티모달 RAG의 목적은 간단하다. 문서를 구성하는 서로 다른 정보 단위를, 잃어버리지 말고 검색 가능한 표현으로 바꾸는 것이다. 여기서 핵심은 "모든 것을 무조건 이미지로 넣자"도 아니고, "전부 텍스트로 바꾸자"도 아니다. 무엇을 어떤 표현으로 저장해야 의미 손실이 가장 적은지를 문서 유형별로 결정하는 일이다.¹

실무에서는 대체로 세 가지 접근이 반복된다.¹⁴

• 모든 것을 텍스트로 변환하는 방식이다. OCR로 글자를 읽고, 이미지는 설명문으로 바꾸고, 표는 Markdown이나 HTML로 직렬화해 텍스트 임베딩으로 처리한다.

• 이미지와 텍스트를 공통 벡터 공간에 넣는 방식이다. 텍스트 질문으로 이미지 페이지를 직접 검색하거나, 이미지와 텍스트를 같은 검색 파이프라인에서 다룬다.

• 모달리티별로 별도 인코더를 쓰고 나중에 합치는 방식이다. 텍스트는 텍스트대로, 이미지는 이미지대로, 표는 구조화 표현대로 검색한 뒤 점수를 합성한다.

정답은 하나가 아니다. 중요한 것은 문서 특성에 따라 이 셋을 섞는 것이다. 깨끗한 텍스트 보고서에는 텍스트 검색이 강하고, 레이아웃이 복잡한 매뉴얼과 슬라이드에는 멀티모달 검색이 강하다. 실제 실험에서도 기술 매뉴얼과 슬라이드에서는 페이지 이미지를 직접 임베딩하는 접근이 강점을 보였지만, 구조가 잘 잡힌 재무 문서에서는 OCR 기반 텍스트 검색이 더 정확한 경우가 있었다.²

OCR과 레이아웃 파싱이 첫 단추인 이유

멀티모달 RAG를 처음 만들면 많은 팀이 임베딩 모델부터 고른다. 하지만 품질을 가장 먼저 흔드는 것은 대개 OCR과 레이아웃 파싱이다. 여기서 한 번 어긋나면 뒤 단계가 줄줄이 흔들린다.¹²

스캔 PDF를 생각해 보자. OCR이 숫자 8을 3으로 읽으면 검색은 틀린 숫자를 기억한다. 두 단 문서를 한 줄로 이어 붙이면 문맥이 섞인다. 표 경계를 잘못 잡으면 열과 행의 관계가 무너진다. 그림 캡션을 본문과 연결하지 못하면 "이 그림이 무엇을 설명하는지"가 사라진다. 그러면 청킹은 잘못된 단위를 만들고, 임베딩은 손상된 의미를 벡터로 바꾸고, 검색은 틀린 후보를 올리고, 생성 모델은 비어 있는 틈을 자연스럽게 상상해 버린다. 환각은 마지막 단계에서 보이지만, 시작은 전처리에서 이미 일어난다.¹²

그래서 멀티모달 RAG의 품질은 흔히 다음 순서로 무너진다.

• OCR 오류

• 레이아웃 해석 오류

• 청크 경계 오류

• 검색 실패

• 근거 약한 생성

특히 한국어 스캔 문서, 오래된 팩스 문서, 도장과 필기가 섞인 문서, 표와 각주가 많은 계약서는 이 연쇄 붕괴가 빠르게 일어난다. 멀티모달 RAG를 도입한다는 것은 단순히 이미지를 넣는 것이 아니라, 이 첫 단추를 더 정교하게 맞추겠다는 선언에 가깝다.

이미지를 검색 가능하게 만드는 네 가지 전략

이미지는 텍스트처럼 바로 임베딩하기 어렵다. 그래서 보통 네 가지 전략이 쓰인다.

가장 널리 쓰이는 첫 번째 전략은 이미지를 설명문으로 바꾸는 방식이다. 구현이 쉽고 텍스트 인프라를 그대로 쓸 수 있다는 장점이 있다. 하지만 이미지 자체만 보고 만든 설명은 자주 문서 문맥을 놓친다. 비슷하게 생긴 두 표가 실제로는 서로 다른 대상을 설명하는데, 설명문만 보면 둘 다 "운영 자금 옵션 표"처럼 비슷하게 요약되어 버리는 식이다. 이를 보완하려면 이미지 주변의 텍스트, 캡션, 앞뒤 문단을 함께 붙여 문맥 인식형 설명을 만들어야 한다.⁵

두 번째 전략은 이미지 자체를 공통 벡터 공간에 넣는 방식이다. 이 접근은 "텍스트 질문으로 이미지 페이지를 찾는" 일을 가능하게 만든다. 실제로 PDF 각 페이지를 독립적인 이미지로 보고 임베딩하면, 차트나 도표가 중요한 문서에서 강한 검색 성능을 보일 수 있다.² ColPali 같은 문서 검색 모델은 OCR을 먼저 복원하지 않고도 문서 이미지를 직접 검색하는 흐름을 보여 준다.³

세 번째 전략은 페이지 전체 스크린샷 기반 검색이다. 이 방식의 매력은 레이아웃을 통째로 보존한다는 데 있다. 표, 그림, 머리말, 캡션의 상대적 위치가 모두 남는다. 스캔 PDF나 레이아웃이 복잡한 슬라이드에서는 이 단순함이 오히려 강력하다.²³

네 번째 전략은 멀티벡터 방식이다. 검색용으로는 요약이나 설명을 임베딩하고, 생성 단계에서는 원본 이미지나 원본 표를 다시 가져온다. 쉽게 말해 "찾기는 가볍게, 읽기는 원본으로" 하는 설계다. LangChain이 소개한 multi-vector retriever의 핵심도 여기에 있다.⁴

표는 텍스트가 아니라 구조다

표를 평평한 문장으로 펴면 많이 잃는다. 표의 의미는 단어 목록이 아니라, 헤더와 셀의 관계에 있다. "2024년 Q3 매출"이라는 값은 숫자 하나가 아니라, 행 헤더와 열 헤더를 동시에 알아야만 의미가 생긴다.¹⁶

그래서 표를 다룰 때는 최소한 세 표현을 구분해서 생각하는 것이 좋다.⁶⁸

• 검색용 표현: 표 요약, 핵심 키워드, 캡션

• 구조 보존 표현: HTML, JSON, LaTeX, Markdown 테이블

• 생성용 원본: 잘린 표 이미지 또는 페이지 내 바운딩 박스 정보

검색 단계에서는 요약과 캡션이 recall을 높여 준다. 하지만 실제 답변 단계에서는 구조 보존 표현이나 원본 이미지를 함께 봐야 한다. 그렇지 않으면 모델이 헤더-값 관계를 추측하게 된다. 표가 큰 문서에서는 "표 전체 요약으로 검색 → 원본 표 전달" 패턴이 특히 안정적이다.⁴⁶

차트는 표보다 더 어렵다. 막대의 길이, 축 단위, 색상 범례, 증가 추세, 이상치처럼 시각적 단서가 중요하기 때문이다. 차트는 대개 텍스트, 표, 이미지의 중간 지대에 있다. 그래서 차트는 설명문 하나만 저장하기보다, 차트 이미지와 주변 설명 문단, 필요하면 OCR로 읽은 축 라벨을 함께 보존하는 편이 안전하다.²

논문, 특허, 매뉴얼에서 멀티모달이 필요한 순간

복합 문서는 텍스트만으로 읽으면 결정적인 장면을 놓친다.

논문은 대표적인 예다. 본문은 아이디어를 설명하지만, 핵심 성능 비교는 표에 있고, 모델 구조는 그림에 있고, 세부 정의는 수식에 있다. "성능이 가장 좋은 변형이 무엇인가"는 표를 읽어야 하고, "모델 흐름이 어떻게 바뀌었는가"는 도식을 봐야 한다. 텍스트 청크만으로는 대답이 절반만 맞을 가능성이 높다.

특허는 더 까다롭다. 설명 본문과 도면 부호가 분리되어 있고, 같은 용어도 도면 번호가 붙는 순간 훨씬 정확해진다. 사용자가 "도 4의 밸브 구조가 도 2와 어떻게 다른가"라고 물으면, 텍스트 설명과 도면 이미지를 함께 다뤄야 한다. 텍스트만 검색하면 도면 참조 문장만 가져오고 정작 도면은 못 본다.

제품 매뉴얼은 멀티모달 RAG의 교과서 같은 사례다. 조립 안내, 경고 아이콘, 배선도, 상태 표시등, 순서도, 부품 표가 한 문서에 다 들어 있다. 실제 실험에서도 가구 조립 설명서처럼 그림 중심 문서는 페이지 이미지를 직접 검색하고, 그 이미지를 VLM에 넘겨 답을 생성하는 방식이 유효했다.³

오디오와 비디오까지 확장하면 무엇이 달라지나

멀티모달 RAG는 PDF를 넘어서 음성과 영상으로도 확장된다. 여기서 가장 먼저 해야 할 일은 매체를 검색 가능한 단위로 쪼개는 것이다. 오디오는 보통 정확한 전사와 타임스탬프가 핵심이고, 비디오는 전사 텍스트와 시각 설명을 함께 가져가야 한다.⁷

실무적으로는 오디오를 일정 길이 청크로 나누고, 비디오는 더 짧은 구간으로 잘라 각 구간마다 음성 전사와 화면 설명을 묶는 방식이 많이 쓰인다. 한 사례에서는 오디오는 1분 단위, 비디오는 15초 단위 비중첩 청크가 검색 성능과 비용의 균형이 좋았다.⁷

이때 중요한 것은 단순 전사가 아니다. 누가 말했는지, 언제 말했는지, 어떤 화면이 같이 나왔는지가 함께 있어야 한다. 고객 상담 녹음이라면 답은 특정 상담원의 발화 구간에 있고, 제품 데모 영상이라면 설명 음성보다 화면에 보이는 버튼 위치가 더 중요할 수 있다. 그래서 미디어 RAG에서는 텍스트, 타임스탬프, 원본 구간 링크가 모두 검색 결과의 일부가 된다.⁷

생성 단계에서는 원본을 보여 줘야 한다

멀티모달 RAG에서 자주 생기는 오해가 하나 있다. 검색만 멀티모달이면 충분하다는 생각이다. 하지만 검색 단계에서 이미지를 잘 찾았더라도, 생성 단계에서 다시 텍스트 요약만 넣어 버리면 원본의 세부 정보가 사라진다.

좋은 설계는 검색용 표현과 생성용 원본을 분리한다. 예를 들어 그림은 캡션이나 요약으로 찾되, 답변을 만들 때는 원본 이미지와 바운딩 박스, 관련 본문을 함께 넘긴다. 그래야 모델이 축 라벨, 작은 주석, 도형 관계를 직접 볼 수 있다.⁴⁸

실제로 "진짜 멀티모달 RAG"를 표방하는 시스템은 각 청크에 페이지 번호, 바운딩 박스, 모달리티, 원본 바이트를 함께 저장하고, 생성 단계에서 텍스트와 원본 이미지를 같이 전달한다. 이 구조가 있어야 답변에 인용을 붙일 수 있고, 사용자는 근거 영역을 눈으로 검증할 수 있다.⁸

평가가 어려운 이유

멀티모달 RAG의 평가는 텍스트 RAG보다 훨씬 어렵다. 이유는 간단하다. "정답 문장을 찾았는가"만으로 끝나지 않기 때문이다. 올바른 페이지를 찾았는지, 표의 맞는 셀을 참조했는지, 그림의 맞는 영역을 봤는지, 오디오의 맞는 시점을 집었는지까지 봐야 한다.²⁹

게다가 기존 벤치마크는 종종 이미 정답 문서가 주어진 상태에서 읽기 능력만 평가한다. 하지만 실서비스의 어려움은 그 문서를 먼저 찾는 데 있다. 실제 기업 문서 환경처럼 수만, 수백만 페이지 규모에서 페이지 검색을 평가해야 비로소 현실에 가까워진다.²

그래서 멀티모달 RAG 평가는 최소한 두 층으로 나누는 편이 좋다.²⁹

• 검색 평가: 페이지 hit rate, Recall@k, MRR, 모달리티별 검색 성공률

• 생성 평가: 사실성, 근거 일치성, 인용 커버리지, 셀·영역·시점 수준의 정확성

여기에 하나를 더 붙이면 좋다. 바로 손실 지점 추적이다. 실패 원인이 OCR인지, 표 직렬화인지, 이미지 검색인지, 생성기의 시각 추론 한계인지 따로 기록해야 한다. 멀티모달 시스템은 틀렸을 때도 꽤 그럴듯하게 말하기 때문에, 로그가 없으면 개선이 거의 감으로 흐른다.⁹

운영에서 반드시 만나는 한계

멀티모달 RAG는 텍스트 RAG보다 대체로 더 비싸고 더 느리다. 이유는 단순하다. 이미지와 비디오는 무겁고, 파싱도 비싸고, 생성 모델의 입력 제한도 더 빡빡하기 때문이다.³⁷

실무에서 자주 부딪히는 운영 제약은 대체로 이렇다.

• 모델마다 한 번에 처리 가능한 이미지 수, 해상도, 전체 시각 토큰 예산이 다르다.

• 같은 이미지를 넣어도 해상도 설정에 따라 비용과 성능이 크게 달라진다.

• OCR 없는 페이지 이미지 검색은 파이프라인을 단순화할 수 있지만, GPU 자원 요구가 커질 수 있다.

• 멀티모달 생성은 원본 이미지를 많이 붙일수록 정확해질 수 있지만, 지연시간과 비용이 빠르게 증가한다.

예를 들어 ColPali와 Qwen2-VL을 이용한 문서 검색 예시는 아예 "리소스 집약적"이라고 경고하고, 이미지 처리에서 최소·최대 픽셀 크기를 조절해 GPU 메모리에 더 많은 이미지를 넣도록 설계한다.³ 이 말은 곧 운영 관점에서 "검색 정확도"만 볼 수 없다는 뜻이다. 이미지 수 제한, 해상도 정책, top-k, rerank 이후 전달할 원본 수를 함께 예산화해야 한다.

여기서 중요한 원칙은 하나다. 모든 검색 결과를 모델에게 보여 주지 말고, 보여 줄 가치가 있는 원본만 압축해서 넘겨라. 텍스트 RAG에서 컨텍스트 예산을 관리하듯, 멀티모달 RAG에서는 이미지 예산과 비디오 예산을 따로 관리해야 한다.

실무 권장 설계

현실적인 기본값은 "하이브리드 멀티모달"이다. 처음부터 모든 것을 한 모델로 통일하려고 하지 말고, 텍스트가 강한 곳과 시각 정보가 강한 곳을 나눠 생각하는 편이 낫다.

문서 유형별로 보면 감이 빨라진다.

• 깨끗한 보고서, 정책 문서, 계약서 본문처럼 텍스트가 중심이면 OCR + 텍스트/표 구조화 + 하이브리드 검색이 기본이다.

• 슬라이드, 스캔 PDF, 매뉴얼, 차트 중심 문서라면 페이지 이미지 검색이나 이미지 임베딩을 적극 검토한다.

• 표가 중요한 문서라면 표 요약으로 찾고 원본 표로 읽는 멀티벡터 구조가 안정적이다.

• 오디오·비디오는 전사만 믿지 말고 타임스탬프와 시각 설명을 함께 저장한다.

결국 좋은 멀티모달 RAG는 "모든 것을 멀티모달로 처리하는 시스템"이 아니다. 오히려 어떤 정보는 텍스트로, 어떤 정보는 구조화 표로, 어떤 정보는 이미지 원본으로 다뤄야 하는지 구분하는 시스템이다.

멀티모달 RAG의 진짜 의미

멀티모달 RAG를 도입한다고 해서 갑자기 모든 문서를 완벽하게 이해하게 되는 것은 아니다. 오히려 파이프라인은 더 복잡해지고, 평가도 어려워지고, 운영비도 오른다. 그런데도 결국 이 방향으로 가게 되는 이유는 분명하다. 현실의 지식이 원래 그렇게 생겼기 때문이다.

문서는 문장만으로 이루어져 있지 않다. 사람은 표를 읽고, 그림을 보고, 배치를 이해하고, 음성을 듣고, 장면을 기억한다. 실무 RAG도 결국 그 방향으로 자라난다. 텍스트 RAG가 문서를 "읽는" 단계였다면, 멀티모달 RAG는 문서를 "보는" 단계다.

그리고 그 차이는 생각보다 크다. 챗봇이 더 똑똑해지는 정도가 아니라, 이제야 비로소 문서의 원래 모습을 존중하기 시작한다는 뜻이기 때문이다.

참고

¹Beyond Text RAG: Extracting Value from Every Data Type

²Evaluating Multimodal vs. Text-Based Retrieval for RAG with Snowflake Cortex

³Multimodal Retrieval-Augmented Generation with Document Retrieval (ColPali) and Vision Language Models

⁴Multi-Vector Retriever for RAG on tables, text, and images

⁵Building a Multimodal RAG That Responds with Text, Images, and Tables from Sources

⁶Exploring RAG for Tables

⁷How We Built Multimodal RAG for Audio and Video

⁸GitHub - Ismail-2001/multimodal-RAG-system

⁹Ask in Any Modality: A Comprehensive Survey on Multimodal Retrieval-Augmented Generation