몇 달 전만 해도 멀티모달 RAG라는 말을 들으면 그냥 이미지 업로드 버튼 하나 붙이면 되는 줄 알았다. 실제로 손대보니 완전히 다른 이야기였다. 문서 안의 표와 다이어그램을 검색 가능하게 만드는 것부터, 어떤 VLM을 골라서 어떻게 서빙할지, 그리고 사용자가 실제로 사진을 찍어 들고 와서 묻는 순간까지, 각 단계마다 텍스트 RAG에서는 겪어보지 못한 문제들이 쌓여 있었다. 세 편에 걸쳐 각 단계를 따로 정리하면서 느낀 건, 이 셋을 따로 떼어놓고 보면 절대 완성된 그림이 안 그려진다는 점이었다. 이 글에서는 그동안 다뤘던 세 편의 내용을 하나로 엮어서, 멀티모달 RAG를 처음부터 설계하려는 사람이 전체 지도를 볼 수 있도록 정리해보려 한다.
멀티모달 RAG를 하나의 문제로 보면 안 되는 이유
멀티모달 RAG를 처음 기획할 때 가장 흔히 하는 실수가, 이걸 하나의 기능 단위로 생각하는 것이다. 실제로는 세 개의 완전히 다른 층위가 겹쳐서 만들어지는 시스템이다. 첫 번째 층위는 인덱싱, 그러니까 문서 안에 있는 이미지를 어떤 방식으로 처리해서 검색 가능한 형태로 저장할지에 대한 문제다. 두 번째 층위는 모델과 인프라, 즉 이미지를 이해하는 데 어떤 VLM을 쓰고 그걸 어떻게 안정적으로 서빙할지에 대한 문제다. 세 번째 층위는 사용자 경험, 사용자가 실시간으로 이미지를 들고 와서 질문했을 때 그걸 어떻게 받아서 답변으로 만들어낼지에 대한 문제다. 이 세 층위는 각각 요구하는 기술 스택도 다르고, 실패했을 때 드러나는 증상도 다르다. 인덱싱 단계에서 실패하면 애초에 검색될 자료가 없어지고, 모델과 인프라 단계에서 실패하면 서버가 죽거나 캡션 품질이 형편없어지고, 사용자 경험 단계에서 실패하면 기능은 다 만들어졌는데 아무도 안 쓰는 결과가 나온다. 세 편을 준비하면서 이 구분을 계속 강조했던 이유도 여기에 있다.
1단계, 문서 안 이미지를 검색 가능하게 만들기
가장 먼저 부딪히는 문제는 문서 파싱이다. 텍스트만 청킹하던 파이프라인은 문서 안에 있는 이미지를 완전히 건너뛴다. 이 문제를 풀기 위해 이미지를 이미지 그대로 벡터화하는 임베딩 방식과, VLM으로 캡션을 뽑아서 텍스트 파이프라인에 흡수시키는 캡셔닝 방식을 비교했다. 이미지 캡셔닝과 벡터 임베딩이 실무에서 어떻게 다른지를 다룬 글에서 자세히 풀었지만, 핵심만 다시 짚으면 이렇다. 이미지 임베딩은 CLIP 계열 모델로 이미지와 텍스트를 같은 벡터 공간에 넣는 방식이라 시각적 특징은 살릴 수 있지만, 표나 도면처럼 구조화된 정보를 담아내는 데는 약하고 기존 텍스트 임베딩 인프라와 별도로 관리해야 하는 부담이 있다. 반대로 캡셔닝 방식은 이미지를 VLM으로 설명 텍스트로 바꾼 다음 기존 파이프라인에 그대로 흡수시키는 방식이라, 구현 난이도가 낮고 기존 인프라를 재사용할 수 있다는 게 가장 큰 장점이다. 대부분의 기업용 RAG는 캡셔닝 기반으로 먼저 커버리지를 확보하는 게 현실적인 시작점이라는 결론을 이 글에서 냈다.
여기서 또 하나 명확히 해야 했던 게, 인덱싱 단계의 멀티모달과 질의 단계의 멀티모달을 구분하는 일이었다. 문서 안 이미지를 미리 캡셔닝해두는 것과, 사용자가 질의 시점에 직접 이미지를 들고 오는 것은 완전히 다른 문제다. 이 구분을 명확히 하지 않고 시작하면 프로젝트 중간에 아키텍처를 다시 짜게 된다는 걸 직접 경험했다.
실제 구현 과정에서는 PDF 파서로 이미지를 개별 추출하고, 그 이미지가 문서의 어느 위치에 있었는지 함께 기록하는 것부터 시작해야 했다. 이 위치 정보가 빠지면 나중에 캡션과 원본 문맥을 연결할 방법이 없어진다. 추출된 이미지는 VLM으로 캡셔닝해서 원본 청크 옆에 메타데이터로 붙이고, 그 결과를 기존 임베딩 모델로 벡터화하는 흐름으로 마무리된다. 이 단계에서 캡셔닝 작업을 배치로 처리할지, 문서 업로드 시점에 실시간으로 처리할지도 중요한 설계 결정이었는데, 대부분의 경우 배치 처리로 백그라운드에서 미리 인덱싱해두는 쪽이 사용자 질의 시점의 지연을 줄이는 데 유리했다.
2단계, 어떤 모델로 어떻게 서빙할 것인가
인덱싱 방향을 정하고 나면 바로 다음 질문이 온다. 그래서 어떤 VLM을 쓸 건데. VLM 모델 선정과 vLLM 멀티모달 서빙에서 겪은 시행착오를 정리한 글에서는 Qwen 계열의 세대별 변화, InternVL과 LLaVA의 구조적 차이, 그리고 오픈소스와 상용 API 사이의 트레이드오프를 다뤘다. 결론적으로는 인덱싱처럼 대량으로 처리해야 하는 작업은 오픈소스 VLM을 자체 서빙하는 게 비용 면에서 유리하고, 사용자가 실시간으로 복잡한 이미지를 들고 오는 경로는 상용 모델의 안정적인 품질을 섞는 하이브리드 구성이 현실적이라는 방향을 잡았다.
서빙 인프라 쪽에서는 텍스트 전용 LLM을 서빙하던 경험을 그대로 옮기면 안 된다는 걸 뼈저리게 배웠다. 멀티모달 모델은 이미지를 비전 인코더에 통과시키는 단계가 앞에 하나 더 붙기 때문에, 텍스트 프리필과는 완전히 다른 성격의 연산이 섞인다. 텐서 병렬 설정을 텍스트 모델 기준으로 그대로 가져다 썼다가 GPU 메모리가 터진 경험을 그 글에서 자세히 풀었는데, 이미지 토큰까지 감안한 배치 크기 설계가 왜 필요한지는 직접 겪어봐야 체감되는 부분이었다.
모델 선정에서 또 하나 강조했던 게 라이선스와 vLLM 통합 성숙도였다. 벤치마크 점수가 아무리 좋아도 상업적 이용에 제약이 있거나 vLLM에서 아직 안정적으로 지원되지 않는 모델이라면, 프로덕션에 바로 올리는 건 위험하다. 신규 모델이 나올 때마다 곧바로 전환하기보다 한두 세대 앞선 안정 버전으로 먼저 검증하고, 커뮤니티에서 실전 검증이 충분히 쌓인 뒤 전환하는 방식이 결과적으로 더 안전했다.
3단계, 사용자가 이미지를 들고 와서 묻는 순간
앞의 두 단계가 준비되면 마지막으로 사용자 경험을 완성해야 한다. 실시간 이미지 질의 아키텍처를 설계하고 프로덕션에 배포한 과정에서는 FastAPI로 이미지와 텍스트를 동시에 받는 엔드포인트를 어떻게 설계했는지, 이미지 이해 결과와 벡터 검색 결과를 어떻게 하나의 답변으로 합성했는지, 그리고 멀티턴 대화에서 이미지 참조를 어떻게 처리했는지를 다뤘다. 이 단계에서 가장 크게 배운 건, 텍스트 RAG에서는 신경 쓸 필요 없던 비용 통제와 보안 문제가 이미지가 섞이는 순간 완전히 새로운 무게로 다가온다는 점이었다. 이미지 업로드에는 레이트 리밋이 필수였고, 업로드된 이미지의 보관 정책과 로그 관리도 처음 설계 단계에서는 놓쳤다가 뒤늦게 추가한 부분이었다.
기술적으로도 배울 게 많았지만, 이 단계에서 가장 인상 깊었던 건 답변의 신뢰도를 어떻게 높이느냐는 문제였다. 이미지에서 얻은 이해 결과와 문서 검색으로 찾은 정보를 뒤섞어서 하나의 답변으로 뭉뚱그리면, 사용자 입장에서는 그 답이 어디서 나온 건지 알 수가 없다. 이미지 기반 설명과 문서 기반 설명을 구조적으로 분리해서 보여주는 것만으로도 현장 사용자들의 신뢰도가 눈에 띄게 올라갔다는 걸 확인한 뒤로는, 답변 합성 단계에서 출처 구분을 빠뜨리지 않는 게 원칙이 됐다.
세 단계를 관통하는 설계 원칙
세 편을 마무리하고 나서 다시 보니, 각 단계에서 반복적으로 등장했던 원칙이 하나 있다. 텍스트 RAG를 다뤄본 경험에서 나온 습관과 가정을 그대로 옮겨오면 안 된다는 것이다. 인덱싱 단계에서는 청킹 로직에 이미지 처리를 욱여넣으려다 실행 시간 차이 때문에 결국 별도 노드로 분리해야 했고, 모델 서빙 단계에서는 텍스트 모델의 메모리 설정을 그대로 가져다 쓰다가 크래시를 겪었고, 실시간 질의 단계에서는 텍스트 검색 로직을 그대로 이어붙이려다 검색 정확도가 오히려 떨어지는 경험을 했다. 세 가지 실패 사례 모두 같은 근본 원인에서 나왔다. 이미지라는 모달리티가 파이프라인의 어느 지점에 어떤 방식으로 영향을 주는지를 충분히 검증하지 않고, 기존 구조에 끼워 맞추려 했다는 점이다.
또 하나의 공통 원칙은 층위를 분리해서 설계하라는 것이다. 인덱싱 파이프라인, 모델 서빙 인프라, 실시간 질의 엔드포인트를 각각 독립적으로 확장하고 교체할 수 있도록 설계해두면, 나중에 VLM을 새 버전으로 바꾸거나 검색 로직을 개선할 때 다른 층위에 영향을 주지 않고 작업할 수 있다. 실제로 Qwen2.5-VL에서 Qwen3-VL로 캡셔닝 모델을 교체할 때, 인덱싱 파이프라인만 건드리고 실시간 질의 로직은 전혀 손대지 않아도 됐던 건 이 분리 설계 덕분이었다.
멀티모달 RAG를 시작하는 팀에게 남기고 싶은 말
처음 멀티모달 RAG를 붙이려는 팀이 있다면, 세 층위를 한꺼번에 다 완성하려 하지 말고 순서를 정해서 단계적으로 접근하라고 권하고 싶다. 대부분의 경우 가장 먼저 손대야 할 건 인덱싱 단계다. 문서 안의 표와 다이어그램을 놓치지 않고 검색 대상에 포함시키는 것만으로도 사용자가 체감하는 개선 폭이 크다. 그다음에 모델과 서빙 인프라를 안정화하고, 마지막으로 실시간 이미지 질의처럼 사용자 경험을 확장하는 기능을 얹는 순서가 리스크를 가장 적게 안고 갈 수 있는 길이다. 반대로 실시간 이미지 질의부터 화려하게 시작하면, 정작 그 답변의 근거가 되어야 할 문서 인덱스가 부실해서 결과물의 신뢰도가 떨어지는 경우를 여러 번 봤다.
결론, 멀티모달 RAG는 세 층위의 합이다
멀티모달 RAG는 이미지 업로드 버튼 하나로 완성되는 기능이 아니라, 인덱싱과 모델 서빙과 사용자 경험이라는 세 층위가 각자의 문제를 풀고 서로 맞물려야 완성되는 시스템이다. 어느 하나만 잘 만들어도 나머지가 부실하면 전체 경험이 무너진다는 걸 직접 세 단계를 거치며 확인했다. 이 시리즈를 준비하면서 가장 크게 얻은 건 특정 기술 스택에 대한 지식보다, 텍스트 RAG의 익숙한 가정을 매 단계마다 의심하고 다시 검증하는 태도였다. 앞으로 멀티모달 RAG를 확장하면서 새로운 케이스가 나올 때마다 이 원칙을 계속 되새기려 한다.
세 편을 쓰는 동안 참고할 만한 국문 자료가 거의 없어서 매번 직접 부딪혀가며 정리해야 했다. 그만큼 시행착오도 많았지만, 그 과정 자체가 이 시리즈의 가장 큰 자산이라고 생각한다. 앞으로 Azure 위에서 vLLM 멀티모달 서빙을 더 큰 스케일로 확장하거나, 에이전틱 기능이 강화된 최신 VLM을 실무에 적용하는 과정도 계속 기록해나갈 계획이다. 멀티모달 RAG는 아직 표준화된 정답이 없는 영역이라, 이런 실전 기록들이 쌓일수록 뒤따라오는 사람들의 시행착오를 조금이라도 줄여줄 수 있을 거라 믿는다.