EmbeddingGemma 2 출시: 온디바이스 멀티모달 검색의 실무 포인트

요약: Google이 EmbeddingGemma 2를 공개했다. 텍스트, 코드, 이미지, 비디오, 오디오를 하나의 768차원 벡터 공간으로 매핑하는 sub-1B 오픈 모델이다. 개발자에게 중요한 지점은 “멀티모달 RAG”보다 더 구체적이다. 로컬 검색, 개인정보 보호, 벡터 저장 비용, 모바일 지연시간을 동시에 다룰 수 있는 선택지가 늘었다.

핵심 키워드: EmbeddingGemma 2, 온디바이스 AI, 멀티모달 임베딩, 로컬 RAG, 벡터 검색

무엇이 새로워졌나

EmbeddingGemma 2는 Google이 2026년 10월 6일 공개한 오픈 가중치 멀티모달 임베딩 모델이다. 텍스트와 코드뿐 아니라 이미지, 비디오 프레임, 오디오까지 같은 벡터 공간에 올린다. 전체 모델은 740M 파라미터이며, 필요한 encoder만 골라 로드할 수 있다.

Google 설명 기준 구성은 다음과 같다.

• 텍스트/코드: 270M 파라미터.
• 텍스트 + 비전: 440M 파라미터.
• 텍스트 + 오디오: 570M 파라미터.
• 전체 멀티모달: 740M 파라미터.
• 출력 벡터: 기본 768차원.
• Matryoshka Representation Learning으로 512, 256, 128차원 truncation 지원.

여기서 실무적으로 중요한 숫자는 740M보다 270M과 256차원이다. 대부분의 앱은 처음부터 이미지, 오디오, 비디오 검색을 모두 넣지 않는다. 문서 검색과 코드 검색만 필요하다면 text-only 구성으로 시작할 수 있고, 나중에 이미지나 오디오 encoder를 추가해도 같은 벡터 공간을 유지할 수 있다.

기존에는 이미지 검색을 만들려면 이미지 captioning 모델로 텍스트를 만들고, 다시 텍스트 임베딩을 생성하는 식의 파이프라인을 쓰는 경우가 많았다. 이 방식은 구현은 쉽지만 지연시간과 오류 전파가 생긴다. EmbeddingGemma 2는 텍스트와 이미지가 직접 같은 공간에서 비교되기 때문에 중간 caption 품질에 덜 의존한다.

온디바이스 검색에서 왜 의미가 큰가

많은 개발자가 RAG를 서버 기능으로만 생각한다. 하지만 실제 제품에서는 로컬 검색이 더 나은 경우가 많다. 사진첩, 회의 녹취, 개인 문서, IDE 코드 조각, 오프라인 매뉴얼처럼 민감하거나 대용량인 데이터는 매번 서버로 올리기 어렵다.

EmbeddingGemma 2는 이 문제에 맞춰 설계된 쪽에 가깝다. Google은 AI Edge Gallery와 Foresight 예시를 통해 로컬 미디어 검색, 비디오 순간 탐색, 회의 기록 검색을 보여줬다. 특히 모바일에서는 사용자가 검색어를 입력하는 동안 결과가 바로 바뀌는 search-as-you-type 경험이 중요하다. 서버 왕복이 끼면 이 경험은 쉽게 망가진다.

예를 들어 “고양이가 키보드 위에서 자는 사진”을 찾는 기능을 만든다고 하자. 서버 방식이면 사진 업로드, 임베딩 생성, 저장, 검색, 개인정보 동의가 모두 얽힌다. 온디바이스 방식이면 사진을 로컬 SQLite에 벡터로 저장하고, 쿼리 벡터와 cosine similarity만 계산하면 된다. 민감한 사진이 기기를 떠나지 않는다는 점도 제품 설명에 명확히 쓸 수 있다.

이 구조는 한국 서비스에도 바로 응용 가능하다.

• 병원 앱: 환자 문서와 이미지 검색을 기기 안에서 처리.
• 건설 현장 앱: 오프라인 도면, 사진, 체크리스트 검색.
• 교육 앱: 강의 영상에서 특정 장면 찾기.
• 개발자 도구: 로컬 코드베이스와 스크린샷 기반 검색.
• 개인 생산성 앱: 회의 오디오와 메모를 같이 검색.

벡터 차원과 저장 비용 계산

임베딩 모델을 도입할 때 많이 놓치는 부분이 저장 비용이다. 768차원 벡터는 생각보다 크다. Google 예시에 따르면 bfloat16 기준 100만 개의 768차원 벡터는 약 1.5GB가 필요하고, 128차원으로 줄이면 약 250MB까지 내려간다. 대략 6배 차이다.

제품 설계에서는 이 숫자가 바로 의사결정으로 이어진다. 사용자의 로컬 사진 3만 장을 색인한다면 768차원도 큰 문제는 아닐 수 있다. 하지만 기업 문서 1,000만 chunk를 색인하거나 모바일에서 앱 저장공간을 500MB 이하로 유지해야 한다면 차원 축소가 중요해진다.

권장 접근은 다음과 같다.

• 정확도가 가장 중요하고 데이터가 적으면 768차원 또는 512차원.
• 저장공간과 속도 균형이 필요하면 256차원.
• 1차 후보군만 빠르게 줄이는 용도라면 128차원.
• 128차원은 multimodal 검색에서 품질 하락이 커질 수 있으므로 실제 데이터로 검증.

특히 2단계 검색 구조를 쓰면 비용을 줄일 수 있다. 128차원 또는 256차원으로 후보 100개를 빠르게 찾고, 그다음 더 강한 reranker나 원본 768차원 similarity로 재정렬하는 방식이다. 검색 품질과 비용을 같이 잡을 때 흔히 쓰는 패턴이다.

개발자가 바로 테스트할 수 있는 구조

EmbeddingGemma 2는 sentence-transformers로 사용할 수 있다. Google 예시는 다음 흐름을 제시한다. 모델을 로드하고, query에는 SearchQuery prompt를, document에는 Document prompt를 붙여 encode한다. 이미지나 오디오는 modality dictionary로 넘긴다.

실제 서비스 PoC는 복잡하게 시작할 필요가 없다. 다음 구조면 충분하다.

1. 데이터 1,000개를 고른다. 문서, 코드, 이미지 등 실제 제품 데이터를 섞는다.
2. 768차원과 256차원 인덱스를 각각 만든다.
3. 사용자가 실제로 입력할 법한 query 50개를 만든다.
4. 각 query마다 top 10 결과를 눈으로 평가한다.
5. latency, 저장공간, top 3 적중률을 비교한다.

이때 synthetic query만 쓰면 안 된다. “회의록 검색” 제품이라면 사용자가 실제로 “지난주 민수님이 말한 결제 이슈”처럼 애매하게 검색한다. “payment bug meeting note” 같은 깔끔한 query만 테스트하면 실제 품질을 과대평가한다.

도입 전 조심해야 할 부분

첫째, 멀티모달 임베딩이 모든 검색 문제를 해결하지는 않는다. 날짜, 권한, 상태값, 금액 같은 정형 필터는 여전히 metadata filtering으로 처리해야 한다. 벡터 검색만으로 “지난 3개월 안에 작성된 문서 중 승인 완료된 건”을 안정적으로 찾기는 어렵다.

둘째, 로컬 색인은 업데이트 전략이 필요하다. 사진이나 문서가 추가될 때마다 전체를 다시 임베딩하면 배터리와 CPU를 많이 쓴다. 변경분만 queue에 넣고, 충전 중이거나 Wi-Fi 상태일 때 처리하는 식의 백그라운드 정책이 필요하다.

셋째, 개인정보 보호를 제품 문구로만 쓰면 안 된다. 정말 기기 밖으로 나가지 않는 데이터, 진단 로그에 포함되는 데이터, crash report에 들어갈 수 있는 데이터를 구분해야 한다. 온디바이스 AI도 telemetry 설계가 부실하면 개인정보 이슈가 생긴다.

실행 체크리스트

• 검색 대상이 텍스트만인지, 이미지/오디오/비디오까지 필요한지 먼저 나눈다.
• text-only 270M 구성으로 작은 PoC를 만들고, 필요할 때 encoder를 추가한다.
• 768차원과 256차원 인덱스를 모두 만들어 실제 query 50개로 비교한다.
• 벡터 검색과 metadata filtering을 분리해 설계한다.
• 로컬 색인은 변경분 처리, 배터리 상태, 네트워크 상태를 고려해 큐로 운영한다.
• 개인정보 설명에는 “기기 밖으로 나가는 데이터”와 “로컬에 남는 데이터”를 명확히 구분한다.