Gemini Embedding 2를 활용한 멀티모달 RAG 설계는 이제 “텍스트 임베딩 하나 더 좋은가?” 수준으로 보면 안 됩니다. Google Developers Blog의 공식 글 https://developers.googleblog.com/en/building-with-gemini-embedding-2/ 가 던지는 메시지는 더 큽니다. 문서 검색, 이미지 기반 검색, 에이전트형 질의응답을 한 파이프라인 안에서 묶을 때 임베딩 품질뿐 아니라 인덱싱 단위와 검색 전략을 같이 바꿔야 한다는 뜻입니다. 특히 실무에서는 RAG가 실패하는 이유가 모델 부족보다 데이터 구조 설계 실패인 경우가 더 많습니다. 그래서 Gemini Embedding 2를 쓸 때도 API 호출법보다 먼저 인덱싱 설계를 봐야 합니다.
팀들이 RAG를 붙여놓고도 “검색은 되는데 답이 이상하다”고 말하는 경우가 많습니다. 원인은 대체로 세 가지입니다. 첫째, 너무 긴 청크를 만들어 핵심 신호가 희석됩니다. 둘째, 텍스트만 기준으로 저장해서 이미지, 표, UI 스크린샷 같은 중요한 맥락이 버려집니다. 셋째, 검색 단계와 생성 단계를 같은 기준으로 다뤄서, 회수된 문맥이 질문 의도와 미세하게 어긋납니다.
Gemini Embedding 2 관련 글이 주목할 부분은 바로 여기입니다. 멀티모달과 에이전트형 활용을 함께 이야기한다는 것은, 이제 검색 대상이 문서 본문만이 아니라 이미지·캡션·메타데이터·도구 결과까지 넓어졌다는 뜻입니다. 즉 “벡터 DB에 PDF 넣고 끝” 방식으로는 정확도 한계가 빨리 옵니다.
실무에서 바로 필요한 결정은 아래 다섯 가지입니다.
문단 단위가 항상 정답은 아닙니다. 제품 문서는 섹션 단위가 나을 수 있고, API 문서는 엔드포인트+예제 조합이 나을 수 있습니다. 스크린샷이 많은 운영 문서는 이미지 설명과 인접 텍스트를 함께 묶는 편이 더 유리합니다. 중요한 건 사람이 읽기 좋은 단위와 검색이 잘 되는 단위가 다를 수 있다는 점입니다.
이미지, 표, 코드 블록, 캡션, 파일 경로, 수정 시각, 문서 소유 팀 같은 메타데이터를 같이 넣어야 에이전트형 질의응답에서 정답률이 오릅니다. 예를 들어 “지난 분기 보안 가이드에서 관리자 권한 관련 UI 문구가 어떻게 바뀌었지?” 같은 질문은 본문 텍스트만으로는 약합니다.
FAQ, API 문서, 회의록, 고객사 매뉴얼을 한 인덱스에 다 넣으면 편해 보이지만 검색 의도가 뒤섞여 품질이 흔들립니다. 반대로 인덱스를 너무 쪼개면 운영이 복잡해집니다. 보통은 “정적 지식”, “변동이 잦은 운영 문서”, “멀티모달 자산” 정도로 나누는 게 현실적입니다.
벡터 검색만으로 끝내면 회수율은 높아도 정밀도가 떨어질 수 있습니다. 따라서 1차로 넓게 찾고, 2차로 질문 의도 기준 재정렬을 거치는 구조가 좋습니다. 이 단계에서 메타데이터 필터와 키워드 매칭을 같이 쓰면 성능이 더 안정적입니다.
“답변이 그럴듯하다”는 평가로는 개선이 안 됩니다. 질문셋을 만들고, 정답 문서가 상위 N개 안에 들어오는지, 생성 답변에 근거 문서가 실제 반영됐는지, 이미지/표 맥락이 살아 있는지 따로 봐야 합니다.
Gemini Embedding 2는 아래 같은 상황에서 가치가 큽니다.
예를 들어 고객지원 봇이 “결제 실패 후 재시도 버튼이 어디 있나요?”라는 질문을 받았을 때, 텍스트 FAQ만으로는 한계가 있습니다. 하지만 UI 스크린샷, 버튼 라벨, 화면 설명이 같은 검색 단위로 저장돼 있으면 답변 품질이 확 올라갑니다.
해결은 단순합니다. 질문 의도별로 청크 크기를 다르게 테스트해야 합니다. API 문서는 짧은 청크가, 정책 문서는 중간 청크가 잘 맞는 경우가 많습니다.
검색용 요약 필드를 따로 두면 회수 품질이 좋아집니다. 본문 전체는 생성 단계에서 쓰고, 검색 단계는 요약+메타데이터를 우선 활용하는 방식이 효과적입니다.
이미지를 그대로만 저장하면 벡터는 있어도 실용도가 떨어집니다. 화면명, 요소명, 동작, 오류 상태 같은 구조화 설명을 붙여야 합니다.
RAG는 데모에서 잘 되고 실제 운영에서 무너지는 경우가 많습니다. 자주 묻는 질문, 실패 사례, 애매한 질의, 멀티홉 질의를 섞은 평가셋이 꼭 필요합니다.
Gemini Embedding 2를 당장 붙여보고 싶다면 순서를 단순하게 가져가면 됩니다. 먼저 검색 실패가 잦은 문서 묶음 하나를 고릅니다. 다음으로 청크 전략 세 가지를 준비합니다. 예를 들어 문단 단위, 섹션 단위, 이미지+텍스트 결합 단위입니다. 그 뒤 30~50개의 실제 질문으로 각 전략을 비교합니다. 마지막으로 상위 검색 결과와 최종 답변을 함께 평가해 “찾기는 잘했는데 답을 잘못 썼는지”, 아니면 “애초에 못 찾았는지”를 분리합니다.
이 과정을 거치면 임베딩 모델 교체 효과와 데이터 설계 효과를 분리해 볼 수 있습니다. 보통 후자가 더 큽니다. 즉, Gemini Embedding 2는 좋은 출발점이지만 성능의 대부분은 인덱싱 구조에서 결정됩니다.
