Google Developers Blog는 2026년 4월 30일 Gemini Embedding 2의 정식 출시를 소개했습니다. 핵심은 텍스트, 이미지, 비디오, 오디오, 문서를 하나의 semantic space로 매핑하는 unified embedding 모델이라는 점입니다. 개발자 입장에서는 '멀티모달 RAG를 어떻게 설계할 것인가'라는 질문으로 바로 이어집니다.
기존 RAG는 대부분 텍스트 문서 검색이었습니다. PDF를 잘라 임베딩하고, 벡터 DB에서 top-k를 찾고, LLM에 넣어 답하게 하는 구조입니다. 하지만 실제 서비스 데이터는 텍스트만으로 존재하지 않습니다. 제품 이미지는 이미지 안에 정보가 있고, 강의 영상은 화면과 음성에 정보가 나뉘어 있고, 고객센터 자료는 PDF, 스크린샷, 녹취, 표가 섞여 있습니다. Gemini Embedding 2 같은 멀티모달 임베딩은 이 데이터를 한 파이프라인으로 다룰 가능성을 열어줍니다.
텍스트 RAG에서는 chunk size를 정하는 것이 중요합니다. 멀티모달 RAG에서는 검색 단위가 더 복잡합니다. 이미지 한 장, 영상 30초, 슬라이드 한 페이지, 음성 발화 5문장, 표 하나가 각각 검색 단위가 될 수 있습니다.
예를 들어 제품 매뉴얼 검색 서비스를 만든다고 합시다. 사용자는 '이 에러 화면이 뜨면 어떻게 해?'라고 묻고 스크린샷을 올릴 수 있습니다. 이때 검색 대상은 텍스트 매뉴얼의 에러 코드 설명뿐 아니라, 기존 티켓에 첨부된 스크린샷, 튜토리얼 영상의 특정 화면, 릴리즈 노트의 이미지 캡션일 수 있습니다.
따라서 인덱싱 전에 데이터 타입별 검색 단위를 정해야 합니다. 추천 기준은 다음과 같습니다.
검색 단위가 너무 크면 답변 근거가 흐려지고, 너무 작으면 맥락이 사라집니다. 멀티모달에서는 원본 조각과 주변 맥락을 함께 저장하는 방식이 안전합니다. 예를 들어 영상 20초 구간을 검색 결과로 뽑더라도 앞뒤 10초 transcript를 같이 넘기는 식입니다.
모든 데이터를 하나의 semantic space에 넣을 수 있다는 말은 모든 검색을 벡터 유사도만으로 해결하라는 뜻이 아닙니다. 실제 서비스에서는 메타데이터 필터가 품질을 좌우합니다.
사용자가 '지난주 결제 오류 화면'을 찾는다면 의미 유사도보다 날짜와 제품 영역이 먼저입니다. '모바일 앱 온보딩 화면'을 찾는다면 플랫폼, 버전, 화면 이름이 중요합니다. 벡터 검색은 후보를 찾는 데 강하지만, 권한·날짜·제품·언어·고객사 같은 조건은 구조화 필터가 더 안정적입니다.
권장 쿼리 순서는 다음과 같습니다.
이 순서를 지키면 '비슷하지만 접근 권한이 없는 문서'나 '의미는 맞지만 오래된 버전의 이미지'를 답변 근거로 쓰는 문제를 줄일 수 있습니다.
Google은 Gemini Embedding 2의 특징으로 task-specific prefixes를 언급합니다. 임베딩 모델을 사용할 때 쿼리와 문서에 목적을 알려주는 방식은 검색 품질에 영향을 줍니다. 같은 문장이라도 '질문에 답하기 위한 검색'인지, '비슷한 이미지를 찾기 위한 검색'인지, '분류를 위한 표현'인지에 따라 좋은 벡터 표현이 달라질 수 있습니다.
실무에서는 prefix 전략을 검색 기능별로 나눠야 합니다.
모든 데이터에 같은 prefix를 붙이면 멀티모달 모델의 장점을 덜 쓰게 됩니다. 검색 기능이 여러 개라면 인덱스를 하나로 유지하더라도 query prefix는 다르게 운용하는 편이 좋습니다.
임베딩 운영비는 모델 호출 비용만이 아닙니다. 벡터 차원이 커질수록 저장 비용, 메모리 사용량, 검색 지연시간이 늘어납니다. Google이 언급한 Matryoshka dimensionality reduction은 필요한 품질과 비용 사이의 조절 장치로 볼 수 있습니다.
서비스 초기에는 높은 차원으로 모두 저장하고 싶어집니다. 하지만 데이터가 수백만 건을 넘으면 벡터 DB 비용과 latency가 바로 문제로 올라옵니다. 따라서 처음부터 품질 실험을 해야 합니다. 예를 들어 3가지 차원 설정으로 같은 쿼리 세트를 돌리고, top-5 hit rate, 평균 latency, 저장 비용을 비교합니다.
실험 쿼리는 실제 사용자 질문에서 뽑아야 합니다. '환불 정책' 같은 깔끔한 키워드보다 '이 화면에서 다음 버튼이 안 눌려요', '영상 3분쯤 나온 설정 어디 있어요', '이 계약서 조항이 갱신 조건 맞나요' 같은 자연 질문이 더 중요합니다.
멀티모달 RAG에서 신뢰를 만드는 방법은 출처 표시입니다. 텍스트 문서라면 문서 제목과 문단 링크를 보여주면 됩니다. 이미지나 영상은 더 구체적이어야 합니다. 사용자가 답변을 검증할 수 있어야 하기 때문입니다.
좋은 출처 형식은 다음과 같습니다.
출처를 이렇게 남기면 hallucination을 줄이는 효과도 있습니다. 모델이 답변을 만들 때 근거 조각을 명확히 참조하고, 사용자가 틀린 답변을 신고하기 쉬워집니다.
Gemini Embedding 2의 실무 가치는 멀티모달 데이터를 한 번에 넣을 수 있다는 데서 끝나지 않습니다. 진짜 가치는 흩어진 업무 지식을 검색 가능한 단위로 재구성하는 데 있습니다. 텍스트 RAG를 그대로 확장하지 말고, 검색 단위·메타데이터·출처 표시를 처음부터 멀티모달 기준으로 설계해야 합니다.
