텍스트만 읽던 RAG, 이제 이미지·다이어그램까지 이해시키기

문서 속 그림은 왜 챗봇이 못 읽을까요?

요즘 사내 문서나 기술 문서를 챗봇에 물어보는 시스템 많이들 만드시죠. 이걸 보통 RAG(검색 증강 생성, Retrieval-Augmented Generation) 라고 불러요. 이게 뭐냐면요, 그냥 LLM한테 물어보면 모델이 학습한 범위 안에서만 답하잖아요. 그래서 우리 회사 문서나 제품 매뉴얼을 따로 잘게 쪼개서 저장해두고, 질문이 들어오면 관련 있는 조각을 먼저 찾아온 다음(검색), 그걸 근거로 LLM이 답을 생성(생성) 하게 만드는 방식이에요. 환각(없는 사실을 지어내는 것)을 줄이고 최신 정보를 반영할 수 있어서 거의 표준이 됐죠.

그런데 여기에 한 가지 큰 구멍이 있어요. 대부분의 RAG는 텍스트만 인덱싱한다는 거예요. 문제는, 실제 기술 문서에는 글자만 있는 게 아니라는 거죠. 아키텍처 다이어그램, 설정 화면 스크린샷, 그래프, 표, UI 캡처 같은 게 핵심 정보를 담고 있는 경우가 정말 많거든요. "이 버튼 어디 있어요?"의 답이 글이 아니라 스크린샷 안에 있는 식이에요. 텍스트만 색인하면, 챗봇 입장에선 그 그림들이 통째로 투명 인간이 돼버리는 거예요.

이미지를 검색 가능하게 만드는 방법들

그래서 이미지를 RAG에 넣으려는 시도가 많은데, 크게 두 갈래예요.

1) 이미지를 글로 풀어쓰기 (VLM 캡셔닝)

비전 모델(이미지를 이해하는 AI)한테 그림을 보여주고 "이게 뭔지 자세히 설명해줘"라고 시킨 뒤, 그 설명 텍스트를 기존 텍스트 파이프라인에 같이 색인하는 방식이에요. 장점은 명확해요. 이미 잘 돌아가는 텍스트 검색 구조를 그대로 쓸 수 있거든요. 단점은, 그림이 가진 미묘한 디테일이 글로 옮기는 과정에서 날아갈 수 있고, 이미지마다 모델을 한 번씩 돌려야 하니 비용과 시간이 든다는 거예요.

2) 이미지와 텍스트를 같은 공간에 임베딩하기 (멀티모달 임베딩)

그림과 글을 같은 벡터 공간에 숫자로 변환해서, "로그인 화면"이라는 텍스트 질문으로 실제 로그인 스크린샷을 바로 찾아오게 하는 방식이에요. CLIP 계열 모델이 대표적이죠. 글과 그림을 직접 매칭할 수 있다는 게 강력한데, 표 안의 정확한 숫자나 코드 스크린샷처럼 세밀한 내용은 놓치기 쉬워요.

여기서 정말 중요한 포인트가 하나 있어요. 그림은 주변 맥락과 떼어놓으면 의미가 반쪽이 된다는 거예요. 똑같은 화살표 박스 다이어그램이라도 앞 문단이 "결제 흐름"을 설명하는지 "배포 파이프라인"을 설명하는지에 따라 뜻이 완전히 달라지잖아요. 그래서 잘 만든 시스템은 이미지를 설명할 때 그 그림 주변의 본문 텍스트까지 같이 모델에 넣어서, 맥락을 반영한 풍부한 설명을 만들어내요. "이건 그래프다" 수준이 아니라 "X축은 시간, Y축은 응답 지연이고, 캐시 도입 후 절반으로 줄어든 걸 보여주는 그래프" 같은 식으로요.

업계 맥락

예전엔 이미지 검색이라고 하면 단순히 비슷한 사진을 찾는 정도였는데, LLM·멀티모달 모델이 좋아지면서 "문서 속 그림의 의미까지 검색에 녹인다"는 방향으로 진화하고 있어요. 순수 멀티모달 임베딩만으로 가는 진영과, 검증이 쉽고 디버깅이 편한 캡셔닝 방식을 선호하는 진영이 공존하는데, 실무에선 둘을 섞은 하이브리드가 현실적인 답인 경우가 많아요.

한국 개발자에게 주는 시사점

사내 위키나 제품 매뉴얼로 RAG 챗봇 만드시는 분들 많을 텐데요, 본인 문서에 그림 비중이 얼마나 되는지 한번 점검해보세요. 의외로 핵심 답이 죄다 스크린샷 안에 있는 경우가 흔하거든요. 처음부터 거창한 멀티모달 임베딩 도입하기 부담되면, 우선 비전 모델로 이미지에 설명 캡션을 달아 텍스트로 색인하는 방식부터 시작하는 걸 추천해요. 기존 파이프라인 거의 안 건드리고도 챗봇이 "보는 눈"을 갖게 되니까요.