Multi-modal RAG 구현 전략: 이미지, 테이블, 차트를 RAG에 통합하기

Multi-modal RAG는 텍스트뿐 아니라 이미지, 테이블, 차트 등 다양한 형태의 정보를 검색하고 LLM 응답에 활용하는 아키텍처 패턴입니다.

핵심 요약

• 기본 RAG는 텍스트만 처리하므로, PDF 내 차트, 테이블, 다이어그램의 정보가 유실됩니다.
• Multi-modal RAG는 이미지와 테이블을 별도로 추출하고, 각각에 적합한 임베딩 또는 요약 전략을 적용합니다.
• 구현 방식은 크게 세 가지입니다: 멀티모달 임베딩, 텍스트 요약 후 임베딩, 원본 보존 후 Vision LLM 활용.
• 문서 유형과 비용 제약에 따라 전략이 달라지며, 단일 방식으로 모든 문서를 처리하기 어렵습니다.
• 프로덕션 환경에서는 파싱 품질, 비용, 지연 시간의 trade-off를 고려한 하이브리드 접근이 필요합니다.

1. 왜 Multi-modal RAG가 필요한가

기본 RAG 시스템을 구축하고 사내 기술 문서를 인덱싱했다고 가정합니다. 사용자가 "지난 분기 매출 추이를 알려줘"라고 질문하면, 해당 정보가 PDF의 차트에만 존재하는 경우 RAG는 답을 찾지 못합니다.

실무에서 이런 상황은 빈번합니다.

• 기술 문서의 아키텍처 다이어그램에 핵심 정보가 담겨 있습니다.
• 재무 보고서의 테이블에 수치 데이터가 정리되어 있습니다.
• 제품 매뉴얼의 스크린샷에 설정 방법이 표시되어 있습니다.
• 연구 논문의 그래프에 실험 결과가 시각화되어 있습니다.

텍스트 기반 RAG는 이런 비텍스트 정보를 처리하지 못합니다. PDF에서 텍스트만 추출하면 테이블 구조가 깨지고, 이미지는 아예 무시됩니다. 문서의 30~50%에 해당하는 정보가 검색 대상에서 빠지는 셈입니다.

Multi-modal RAG는 이 문제를 해결하기 위해 텍스트, 이미지, 테이블을 각각 적절한 방식으로 처리하여 검색 가능하게 만드는 접근입니다.

2. 한 줄 정의

Multi-modal RAG는 텍스트, 이미지, 테이블 등 서로 다른 형태(modality)의 데이터를 통합적으로 인덱싱하고 검색하여 LLM 응답 생성에 활용하는 아키텍처 패턴입니다.

기본 RAG와의 차이를 정리하면 다음과 같습니다.

구분	기본 RAG	Multi-modal RAG
입력 데이터	텍스트만	텍스트 + 이미지 + 테이블
문서 파싱	텍스트 추출	구조 분석 (레이아웃, 요소 분류)
임베딩	텍스트 임베딩 모델	멀티모달 임베딩 또는 요약 후 텍스트 임베딩
검색 결과	텍스트 청크	텍스트 + 이미지 + 테이블 혼합
LLM 입력	텍스트 컨텍스트	텍스트 + 이미지 (Vision LLM)

3. 핵심 구성 요소

multimodal-rag-architecture

Multi-modal RAG는 기본 RAG의 파이프라인을 확장합니다. 추가되는 핵심 구성 요소는 다음과 같습니다.

3.1 문서 파싱 레이어 (Document Parsing)

기본 RAG에서는 단순 텍스트 추출로 충분하지만, Multi-modal RAG에서는 문서의 구조를 분석해야 합니다.

구성 요소	역할	도구 예시
Layout Analysis	페이지 내 텍스트/이미지/테이블 영역 식별	Unstructured, Azure Document Intelligence, Amazon Textract
Table Extraction	테이블 구조(행/열)를 보존하며 추출	Camelot, Tabula, Document Intelligence
Image Extraction	이미지를 개별 파일로 추출	PyMuPDF, pdf2image
OCR	이미지 내 텍스트 인식	Tesseract, Azure Computer Vision, Google Cloud Vision

3.2 멀티모달 임베딩 (Multi-modal Embedding)

서로 다른 형태의 데이터를 같은 벡터 공간에 매핑하는 모델입니다.

모델	제공사	특징
CLIP	OpenAI	이미지-텍스트 쌍을 같은 벡터 공간에 매핑
Titan Multimodal Embeddings	AWS	텍스트와 이미지를 기본 1,024차원 벡터로 변환 (축소 옵션 지원)
Vertex AI Multimodal Embeddings	Google Cloud	텍스트, 이미지, 비디오를 1,408차원 벡터로 통합 임베딩
Cohere Embed v3	Cohere	텍스트 + 이미지 멀티모달 지원, 기존 텍스트 임베딩과 호환

3.3 Vision LLM (멀티모달 생성 모델)

검색된 이미지를 직접 이해하고 응답을 생성할 수 있는 모델입니다.

• GPT-4o, GPT-4 Vision (OpenAI)
• Claude Sonnet/Opus (Anthropic) — 이미지 입력 지원
• Gemini Pro Vision (Google)
• Amazon Nova (AWS Bedrock)

이 모델들은 이미지를 입력으로 받아 내용을 분석하고, 텍스트 컨텍스트와 결합하여 응답을 생성합니다.

4. 구현 전략

multimodal-rag-flow

Multi-modal RAG를 구현하는 방식은 크게 세 가지로 나뉩니다. 각각의 trade-off가 다르므로 문서 유형과 요구사항에 따라 선택합니다.

4.1 전략 A: 멀티모달 임베딩 (Unified Embedding)

이미지와 텍스트를 같은 벡터 공간에 임베딩하여 통합 검색하는 방식입니다.

[텍스트 청크] ──→ [멀티모달 임베딩 모델] ──→ [벡터]
[이미지]      ──→ [멀티모달 임베딩 모델] ──→ [벡터]  ← 같은 공간
[테이블 이미지] ──→ [멀티모달 임베딩 모델] ──→ [벡터]

검색 시: 텍스트 쿼리 → 벡터 → 텍스트/이미지 모두에서 유사도 검색

장점: 텍스트와 이미지를 동일한 방식으로 검색할 수 있습니다. 파이프라인이 단순합니다.

단점: 멀티모달 임베딩 모델의 텍스트 검색 성능이 텍스트 전용 모델보다 낮을 수 있습니다. 이미지의 세부 정보(숫자, 텍스트)를 벡터만으로 정확히 표현하기 어렵습니다.

적합한 경우: 이미지 자체의 시각적 유사성이 중요한 경우 (제품 이미지 검색, 다이어그램 유형 분류 등).

4.2 전략 B: 텍스트 요약 후 임베딩 (Summarize & Embed)

이미지와 테이블을 Vision LLM으로 텍스트 요약한 뒤, 요약 텍스트를 임베딩하는 방식입니다.

[이미지] ──→ [Vision LLM: "이 이미지를 설명해줘"] ──→ [텍스트 요약]
[테이블] ──→ [Vision LLM: "이 테이블을 요약해줘"] ──→ [텍스트 요약]
                                                          │
                                                          ▼
                                              [텍스트 임베딩 모델] ──→ [벡터]

검색 시: 텍스트 쿼리 → 벡터 → 요약 텍스트에서 유사도 검색
응답 시: 검색된 요약 + 원본 이미지를 Vision LLM에 전달

장점: 기존 텍스트 임베딩 모델을 그대로 사용할 수 있습니다. 검색 품질이 텍스트 기반이므로 예측 가능합니다. 요약에 메타데이터(페이지 번호, 섹션 제목)를 포함할 수 있습니다.

단점: 요약 과정에서 정보 손실이 발생할 수 있습니다. 인덱싱 시 Vision LLM 호출 비용이 추가됩니다. 요약 품질이 전체 검색 품질에 영향을 미칩니다.

적합한 경우: 테이블의 수치 데이터, 차트의 트렌드 정보를 검색해야 하는 경우. 기존 텍스트 RAG 인프라를 확장하는 경우.

4.3 전략 C: 원본 보존 + Vision LLM (Raw + Vision)

이미지와 테이블을 원본 그대로 저장하고, 검색 시 메타데이터 기반으로 찾은 뒤 Vision LLM에 직접 전달하는 방식입니다.

[이미지] ──→ [메타데이터 추출: 페이지, 섹션, 캡션] ──→ [메타데이터 인덱싱]
[테이블] ──→ [메타데이터 추출: 제목, 컬럼명]       ──→ [메타데이터 인덱싱]

검색 시: 텍스트 검색으로 관련 섹션 식별 → 해당 섹션의 이미지/테이블 원본 첨부
응답 시: 텍스트 컨텍스트 + 원본 이미지를 Vision LLM에 전달

장점: 정보 손실이 없습니다. Vision LLM이 원본을 직접 분석하므로 정확도가 높습니다.

단점: 이미지 자체를 검색하기 어렵습니다 (메타데이터에 의존). 응답 생성 시 Vision LLM 호출이 필수이므로 비용과 지연 시간이 증가합니다. 이미지 크기에 따라 토큰 소비가 큽니다.

적합한 경우: 이미지의 세부 정보(숫자, 레이블, 관계)가 중요한 경우. 문서 수가 적고 정확도가 최우선인 경우.

4.4 전략 비교 요약

기준	A: 멀티모달 임베딩	B: 요약 후 임베딩	C: 원본 + Vision
인덱싱 비용	낮음	높음 (LLM 호출)	낮음
검색 정확도	중간	높음	메타데이터 의존
응답 정확도	중간	중간~높음	높음
구현 복잡도	낮음	중간	높음
지연 시간	낮음	낮음	높음 (Vision LLM)
기존 인프라 호환	별도 모델 필요	호환	호환

운영 환경에서는 전략 B와 C를 결합하는 하이브리드 방식이 많이 사용됩니다. 요약 텍스트로 검색하되, 응답 생성 시에는 원본 이미지를 Vision LLM에 함께 전달하는 구조입니다.

5. 실무 사용 사례

사례 1: 기술 문서 검색 시스템

클라우드 인프라 팀에서 AWS/Azure 공식 문서, 내부 아키텍처 문서를 RAG로 검색하는 시스템을 운영한다고 가정합니다.

기본 RAG로는 "VPC 피어링 구조를 보여줘"라는 질문에 텍스트 설명만 반환합니다. 하지만 실제로 엔지니어가 원하는 것은 아키텍처 다이어그램입니다.

Multi-modal RAG를 적용하면: 1. 문서 파싱 시 아키텍처 다이어그램을 별도 추출합니다. 2. Vision LLM으로 다이어그램을 요약합니다: "VPC A(10.0.0.0/16)와 VPC B(10.1.0.0/16)가 피어링으로 연결된 구조. Route Table에 상대 VPC CIDR이 등록됨." 3. 요약 텍스트를 임베딩하여 검색 가능하게 합니다. 4. 검색 시 요약으로 매칭하고, 응답에 원본 다이어그램을 포함합니다.

이 경우 전략 B + C 하이브리드가 적합합니다. 검색은 요약 텍스트로, 응답은 원본 이미지와 함께 제공합니다.

사례 2: 재무 보고서 분석

분기별 재무 보고서 PDF에서 매출 데이터를 검색하는 시스템입니다.

핵심 데이터가 테이블과 차트에 집중되어 있으므로: 1. 테이블을 구조화된 형태(Markdown 또는 CSV)로 추출합니다. 2. 차트를 Vision LLM으로 분석하여 수치와 트렌드를 텍스트로 변환합니다. 3. "2026년 1분기 매출은?" 같은 질문에 테이블 데이터를 기반으로 정확한 수치를 답합니다.

이 경우 테이블 추출 품질이 핵심입니다. Azure Document Intelligence나 Amazon Textract 같은 전문 서비스가 단순 OCR보다 정확한 테이블 구조를 제공합니다.

사례 3: 제품 매뉴얼 고객 지원

하드웨어 제품 매뉴얼에서 설치/설정 방법을 검색하는 고객 지원 챗봇입니다.

매뉴얼의 상당 부분이 스크린샷과 사진으로 구성되어 있으므로: 1. 각 이미지에 캡션과 섹션 정보를 메타데이터로 저장합니다. 2. "전원 버튼 위치"를 질문하면, 해당 섹션의 텍스트 + 제품 사진을 함께 반환합니다. 3. Vision LLM이 이미지를 분석하여 "전원 버튼은 기기 후면 좌측 상단에 위치합니다"라고 답합니다.

6. 보안 고려사항

Security Note
Multi-modal RAG는 이미지 데이터를 외부 LLM API로 전송하므로, 기본 RAG보다 데이터 유출 위험이 큽니다. 이미지에 포함된 민감 정보(개인정보, 기밀 수치, 내부 시스템 정보)를 사전에 식별하고 처리해야 합니다.

6.1 이미지 내 민감 정보

• 스크린샷에 포함된 IP 주소, 계정 정보, API 키가 Vision LLM으로 전송될 수 있습니다.
• 인덱싱 전에 이미지 내 민감 정보를 탐지하고 마스킹하는 전처리가 필요합니다.
• AWS Macie, Azure Purview 같은 데이터 분류 서비스를 활용하거나, 커스텀 PII 탐지 파이프라인을 구축합니다.

6.2 데이터 전송 범위 확대

• 기본 RAG는 텍스트 청크만 LLM에 전달하지만, Multi-modal RAG는 이미지 원본을 전달합니다.
• 이미지 한 장에 포함된 정보량이 텍스트 청크보다 훨씬 많을 수 있습니다.
• 외부 API 사용 시 이미지 데이터의 보존/학습 정책을 확인해야 합니다.
• 규제 환경에서는 VPC 내 배포 가능한 모델(AWS Bedrock, Azure OpenAI)을 우선 검토합니다.

6.3 접근 제어 복잡도 증가

• 이미지와 텍스트가 서로 다른 접근 권한을 가질 수 있습니다.
• 예: 텍스트 요약은 전체 공개이지만, 원본 이미지는 특정 부서만 접근 가능한 경우.
• 메타데이터에 접근 권한 정보를 포함하고, 검색 시 필터링을 적용해야 합니다.

7. 비용/운영 고려사항

주의
Multi-modal RAG는 기본 RAG 대비 인덱싱 비용이 2~5배, 응답 생성 비용이 3~10배 증가할 수 있습니다. 모든 이미지를 처리하기보다 비즈니스 가치가 높은 문서를 선별하는 것이 중요합니다.

7.1 비용 구조 비교

구성 요소	기본 RAG	Multi-modal RAG (추가분)
문서 파싱	텍스트 추출 (무료~저비용)	Layout Analysis + OCR (건당 과금)
인덱싱	텍스트 임베딩만	+ Vision LLM 요약 호출 (전략 B)
벡터 저장	텍스트 벡터	+ 이미지 벡터/메타데이터 (저장 용량 증가)
응답 생성	텍스트 LLM	Vision LLM (이미지 토큰 추가)

7.2 비용 최적화 전략

• 선별적 처리: 모든 이미지를 처리하지 않습니다. 캡션이 있는 이미지, 특정 크기 이상의 이미지만 대상으로 합니다.
• 요약 캐싱: 동일 이미지의 요약 결과를 캐싱하여 재인덱싱 시 LLM 호출을 줄입니다.
• 계층적 처리: 먼저 저비용 OCR로 텍스트를 추출하고, OCR 결과가 부족한 경우에만 Vision LLM을 호출합니다.
• 이미지 압축: Vision LLM에 전달하기 전에 이미지를 적절한 해상도로 리사이즈합니다. 대부분의 Vision LLM은 고해상도 이미지를 내부적으로 축소하므로, 미리 줄이면 전송 비용을 절약할 수 있습니다.
• 배치 처리: 인덱싱은 실시간이 아니므로, 배치로 처리하여 API 호출을 최적화합니다.

7.3 운영 고려사항

• 파싱 품질 모니터링: 문서 레이아웃이 다양하면 파싱 실패율이 높아집니다. 파싱 결과를 샘플링하여 품질을 확인하는 프로세스가 필요합니다.
• 이미지 저장소 관리: 추출된 이미지를 별도 Object Storage(S3, Blob Storage)에 저장하고, 벡터 저장소에는 참조 URL만 보관합니다.
• 모델 업데이트 대응: Vision LLM이나 멀티모달 임베딩 모델이 업데이트되면, 기존 요약/벡터와의 일관성이 깨질 수 있습니다. 모델 버전을 메타데이터로 관리합니다.
• 지연 시간 관리: Vision LLM 호출이 추가되므로 응답 시간이 길어집니다. 스트리밍 응답과 비동기 이미지 분석을 조합하여 체감 지연을 줄입니다.

8. 자주 하는 실수

1. 모든 이미지를 무조건 인덱싱하는 것: 로고, 아이콘, 장식용 이미지까지 처리하면 노이즈가 증가하고 비용만 늘어납니다. 정보 가치가 있는 이미지만 선별해야 합니다.
2. 테이블을 이미지로만 처리하는 것: 테이블은 구조화된 데이터이므로, 가능하면 Markdown이나 CSV 형태로 추출하는 것이 검색 정확도가 높습니다. 이미지 기반 처리는 구조 추출이 어려운 경우의 fallback입니다.
3. 요약 품질을 검증하지 않는 것: Vision LLM의 이미지 요약이 항상 정확하지는 않습니다. 특히 복잡한 차트나 손글씨가 포함된 이미지에서 오류가 발생할 수 있습니다. 요약 결과를 샘플링하여 품질을 확인해야 합니다.
4. 단일 전략으로 모든 문서를 처리하려는 것: 기술 문서의 다이어그램, 재무 보고서의 테이블, 매뉴얼의 사진은 각각 다른 처리 전략이 필요합니다. 문서 유형별로 파이프라인을 분리하는 것이 효과적입니다.
5. 이미지 해상도를 고려하지 않는 것: 너무 작은 이미지는 Vision LLM이 분석하기 어렵고, 너무 큰 이미지는 토큰 비용이 급증합니다. 적절한 해상도 기준(예: 최소 200x200, 최대 2000x2000)을 설정합니다.
6. 원본 이미지 참조를 유지하지 않는 것: 요약 텍스트만 저장하고 원본 이미지 경로를 잃어버리면, 나중에 응답에 이미지를 포함하거나 요약을 재생성할 수 없습니다. 항상 원본 참조를 메타데이터로 보관합니다.

9. 구현 시 기술 스택 선택 가이드

문서 파싱

도구	특징	적합한 경우
Unstructured.io	오픈소스, 다양한 문서 형식 지원, 레이아웃 분석	자체 호스팅, 커스터마이징 필요 시
Azure Document Intelligence	관리형 서비스, 높은 테이블 추출 정확도	Azure 환경, 정형 문서 중심
Amazon Textract	AWS 네이티브, 테이블/폼 추출	AWS 환경, S3 연동
LlamaParse	LlamaIndex 생태계, LLM 기반 파싱	RAG 특화 파싱이 필요한 경우

벡터 저장소

멀티모달 데이터를 저장할 때는 메타데이터 필터링과 다양한 데이터 타입 저장을 지원하는 벡터 DB가 유리합니다.

• Weaviate: 멀티모달 모듈 내장, 이미지 벡터 네이티브 지원
• Qdrant: 다양한 벡터 타입과 페이로드 필터링 지원
• Pinecone: 관리형 서비스, 메타데이터 필터링
• pgvector: PostgreSQL 확장, 기존 RDB 인프라 활용 가능

오케스트레이션 프레임워크

• LangChain: Multi-modal 문서 로더와 검색 체인 지원
• LlamaIndex: Multi-modal RAG 전용 인덱스(MultiModalVectorStoreIndex) 제공
• Haystack: 파이프라인 기반 구성, 커스텀 노드 확장 용이

10. 정리

• Multi-modal RAG는 텍스트 기반 RAG의 한계를 넘어 이미지, 테이블, 차트를 검색 대상에 포함하는 아키텍처입니다.
• 구현 전략은 멀티모달 임베딩, 요약 후 임베딩, 원본 보존 + Vision LLM 세 가지이며, 실무에서는 하이브리드 접근이 일반적입니다.
• 문서 파싱 품질이 전체 시스템 품질을 결정하므로, 파싱 레이어에 충분한 투자가 필요합니다.
• 기본 RAG 대비 비용이 크게 증가하므로, 처리 대상을 선별하고 계층적 처리 전략을 적용해야 합니다.
• 이미지 데이터의 보안 위험이 텍스트보다 크므로, 민감 정보 탐지와 접근 제어를 강화해야 합니다.

참고 문서

• LlamaIndex 공식 문서: Multi-Modal RAG
• LangChain 공식 문서: Multi-modal
• Unstructured.io 공식 문서
• Azure Document Intelligence 공식 문서
• Amazon Textract 공식 문서