EmbeddingGemma 2 공개: 온디바이스 멀티모달 검색이 RAG 설계를 바꾸는 지점

Google이 2026년 10월 6일 EmbeddingGemma 2를 공개했다. 핵심 키워드는 세 가지다. 오픈 웨이트, 멀티모달 임베딩, 온디바이스 실행이다. 텍스트와 코드만 임베딩하는 모델이 아니라 이미지, 비디오 프레임, 오디오까지 하나의 768차원 벡터 공간에 매핑한다. 전체 구성은 740M 파라미터지만, 필요한 인코더만 골라 로드할 수 있다.

이 소식은 RAG를 만드는 개발자에게 꽤 실용적이다. 지금까지 멀티모달 검색을 만들려면 텍스트 임베딩 모델, 이미지 캡션 모델, 음성 인식, 비디오 키프레임 추출, 별도 랭킹 로직을 조합하는 경우가 많았다. 파이프라인이 길어질수록 지연 시간은 늘고, 개인정보는 서버로 올라가고, 장애 지점도 많아진다. EmbeddingGemma 2는 이 구조를 단순하게 만들 수 있는 선택지를 제공한다.

모델이 제공하는 실제 선택지

Google 개발자 블로그에 따르면 EmbeddingGemma 2는 Gemma 4 기반의 sub-1B 모델이다. 텍스트와 코드는 270M 파라미터 구성으로 시작할 수 있고, 비전 인코더를 더하면 440M, 오디오를 더하면 570M, 모든 모달리티를 포함하면 740M 구성이 된다. 모든 구성이 같은 768차원 공간으로 투영되기 때문에, 처음에는 텍스트 검색으로 시작했다가 나중에 이미지나 오디오 검색을 붙이는 방식이 가능하다.

Matryoshka Representation Learning도 실무에서 중요한 포인트다. 벡터를 768차원에서 128차원까지 동적으로 줄일 수 있다. Google은 256차원에서도 텍스트와 코드의 원래 품질 대부분을 유지하고, 이미지·비디오·음성 검색에서도 약 95% 품질을 유지한다고 설명한다. 벡터 DB 비용을 직접 내는 팀이라면 이 숫자가 중요하다. 차원을 768에서 256으로 줄이면 저장 공간, 인덱스 메모리, 검색 I/O가 모두 줄어든다.

라이선스도 확인할 만하다. Apache 2.0 기반 공개 모델이라는 점은 사내 검색, 로컬 앱, 고객 데이터가 섞이는 제품에서 검토하기 쉽다. 다만 “오픈 웨이트”가 곧 “아무 제약 없는 운영”을 뜻하지는 않는다. 배포 대상, 모델 카드, 데이터 처리 정책, 모바일 앱 스토어 심사 기준은 별도로 확인해야 한다.

어디에 바로 쓸 수 있나

첫 번째 사용처는 코드베이스 검색이다. 개발자가 “결제 실패 후 재시도 큐가 어디서 처리되나”처럼 자연어로 묻고, 모델이 함수명이나 파일명과 상관없이 관련 코드를 찾아주는 흐름이다. 기존 키워드 검색은 retry, payment, queue 같은 단어가 정확히 맞아야 한다. 임베딩 검색은 의미가 가까운 코드와 문서를 찾는다. EmbeddingGemma 2가 코드 이해 성능을 개선했다고 강조한 이유도 여기에 있다.

두 번째는 로컬 미디어 검색이다. Google AI Edge 예시는 휴대폰 안의 사진과 비디오를 자연어 또는 예시 이미지로 찾는 흐름을 보여준다. “고양이가 키보드 위에서 자는 사진”, “아이들이 웃는 장면”, “생일 케이크 촛불을 끄는 순간” 같은 질의를 서버 업로드 없이 처리한다. 개인 사진, 현장 점검 영상, 의료·교육 자료처럼 민감도가 높은 데이터에는 서버 전송을 줄이는 것만으로도 제품 설계가 달라진다.

세 번째는 제로샷 의도 라우팅이다. 사용자의 입력을 미리 정의한 라벨과 설명에 직접 매칭해서, 별도 학습 없이 라우팅할 수 있다. 예를 들어 고객지원 앱에서 “환불 요청”, “배송 조회”, “계정 잠금”, “기술 오류” 라벨을 설명과 함께 임베딩해두고, 들어오는 문의를 가장 가까운 라벨로 보낸다. LLM 호출 없이 밀리초 단위로 처리할 수 있다면 비용과 지연 시간이 모두 줄어든다.

RAG 설계에서 바뀌는 부분

기존 RAG 설계는 보통 텍스트 문서가 중심이다. PDF를 텍스트로 뽑고, 음성은 STT로 바꾸고, 이미지는 캡션을 만든 뒤, 최종적으로 텍스트 임베딩을 저장한다. 이 방식은 단순하지만 정보 손실이 있다. 차트의 시각적 구조, 영상의 특정 장면, 오디오의 비언어적 신호는 텍스트 변환 과정에서 사라질 수 있다.

멀티모달 임베딩을 쓰면 원본 모달리티를 더 오래 유지할 수 있다. 영상은 키프레임과 오디오 청크를 임베딩하고, 문서는 텍스트와 이미지 페이지를 함께 인덱싱하며, 코드는 주석과 실제 구현을 같이 검색할 수 있다. 물론 모든 것을 하나의 컬렉션에 넣는다고 좋은 것은 아니다. 검색 목적별로 컬렉션과 메타데이터를 나눠야 한다. 코드 검색, 이미지 검색, 고객 문의 라우팅은 스코어 해석 방식이 다르다.

온디바이스 RAG에서는 더 큰 변화가 생긴다. 서버에 벡터를 올리지 않고 SQLite나 로컬 벡터 인덱스에 저장할 수 있다. 네트워크가 없어도 검색이 되고, 민감한 데이터가 기기를 떠나지 않는다. 대신 기기별 메모리와 배터리, 인덱싱 시간, 업데이트 전략을 고려해야 한다. 모델이 작아졌다고 해도 모든 기기에서 같은 사용자 경험이 나오지는 않는다.

도입 전에 해야 할 벤치마크

첫째, 차원 축소 테스트를 해야 한다. 768, 512, 256, 128차원에서 recall@k와 지연 시간을 비교한다. 운영 비용만 보면 낮은 차원이 유리하지만, 검색 품질이 급격히 떨어지는 구간이 있다. 특히 이미지와 오디오 검색은 데이터셋 특성에 따라 차이가 크다.

둘째, 모달리티별 실패 케이스를 분리해야 한다. 텍스트 검색이 잘 된다고 비디오 검색이 잘 되는 것은 아니다. 영상 검색에서는 키프레임 간격, 오디오 청크 길이, 장면 전환 감지가 결과 품질을 좌우한다. 코드 검색에서는 파일 단위로 임베딩할지, 함수 단위로 임베딩할지, 주석을 포함할지가 중요하다.

셋째, 로컬 인덱스 업데이트 비용을 측정해야 한다. 사용자가 사진 3만 장을 가진 상태에서 첫 인덱싱이 40분 걸리면 제품으로 쓰기 어렵다. 백그라운드 인덱싱, 충전 중 처리, 변경분만 업데이트, 오래된 항목 우선순위 조정이 필요하다.

실행 체크리스트

• 현재 RAG 파이프라인에서 텍스트 변환 때문에 손실되는 데이터 유형을 적는다.
• 텍스트·코드만 필요하면 270M 구성부터 테스트한다.
• 이미지와 비디오 검색이 필요하면 440M 이상 구성을 검토한다.
• 오디오 검색이 핵심이면 570M 또는 전체 740M 구성을 따로 벤치마크한다.
• 벡터 차원은 768, 512, 256, 128로 나눠 recall@5, recall@10, 검색 지연 시간을 비교한다.
• 로컬 저장소는 SQLite 기반부터 시작하고, 데이터가 커지면 별도 벡터 인덱스를 검토한다.
• 온디바이스 검색은 첫 인덱싱 시간, 배터리 사용량, 메모리 피크를 측정한다.
• 민감 데이터는 서버 업로드 없이 처리한다는 제품 약속을 로그와 네트워크 정책으로 검증한다.
• 코드 검색은 파일 단위와 함수 단위 인덱싱을 모두 테스트한다.
• 검색 결과가 LLM 답변으로 이어질 경우, 원본 파일·프레임·타임스탬프를 반드시 함께 보여준다.

EmbeddingGemma 2의 가치는 “모든 것을 한 모델로 해결한다”가 아니다. 텍스트 중심 RAG에서 벗어나 로컬 데이터, 미디어 데이터, 코드 데이터를 더 적은 파이프라인으로 검색할 수 있게 만드는 데 있다. 새 프로젝트라면 처음부터 멀티모달 인덱싱을 고려하고, 기존 RAG 제품이라면 비용이 큰 변환 단계부터 하나씩 줄여보는 접근이 현실적이다.