EmbeddingGemma 2: 기기 안에서 사진·소리를 함께 검색합니다

기기 안의 문서·코드·사진·녹음을 함께 찾으려는 개발자는 서로 다른 입력을 같은 검색 공간에 넣는 공개 모델을 선택할 수 있습니다. Google이 2026년 10월 6일 발표한 EmbeddingGemma 2입니다. 사진을 설명문으로 바꾸고, 녹음을 받아쓴 뒤, 그 텍스트를 다시 검색 벡터로 만드는 여러 단계를 줄이는 방향입니다. 초기 Reddit 반응에는 오디오 임베딩에 대한 관심과 바로 적용해 보려는 기대가 보입니다. (Google AI Edge 발표 · 개발자 가이드 · Reddit 토론)

한눈에 보기

구조·제공 경로는 공식 발표와 개발자 문서에 따른 설명입니다. 성능·메모리·속도는 Google의 평가이며, 아래 저장량 계산은 명시한 벡터 형식만 적용한 산술 예시입니다. 독립적인 한국어 검색 시험 결과는 찾지 못했습니다. (공식 가이드)

임베딩이 무엇이고, 여러 종류의 파일을 어떻게 함께 찾습니까?

임베딩은 입력의 의미를 숫자 배열로 옮기는 표현입니다. 예를 들어 “해 질 무렵 바다”라는 검색어와 해변 사진, 파도 소리 녹음이 가까운 벡터로 표현되면 같은 질의로 세 자료를 찾아낼 수 있습니다. 정확히 같은 단어가 들어 있는 파일을 찾는 키워드 검색과 달리 의미의 가까움을 이용합니다. 검색 결과를 답변 생성 모델에 넘기는 RAG는 이런 검색을 생성 과정의 앞단에 붙인 구성입니다. (개발자 가이드)

EmbeddingGemma 2는 입력별 전용 인코더와 공유 백본을 거쳐 결과를 같은 768차원 공간에 놓습니다. 인코더는 이미지나 소리처럼 서로 다른 데이터를 모델이 처리할 표현으로 바꾸는 부분입니다. 공통 공간을 쓰므로 텍스트로 사진을 찾거나, 사진으로 비슷한 사진을 찾거나, 텍스트로 녹음을 찾는 검색을 같은 방식으로 구성할 수 있습니다. Google의 예제는 사진과 파도 소리를 각각 임베딩한 뒤 한 텍스트 질의와의 유사도를 비교합니다. (입력과 교차 모달 검색 예제)

이 변화는 중간 설명문을 만드는 모델에 검색 의미를 맡기던 구조를 줄이는 데 도움이 됩니다. 사진의 설명문에 빠진 요소나 받아쓰기에서 빠진 비언어 소리를 직접 입력으로 검색할 여지가 생깁니다. 다만 실제 결과는 인덱싱할 자료와 질의에 따라 달라집니다. “소리를 받는다”는 모델 특성과 “한국어 회의에서 필요한 순간을 잘 찾는다”는 제품 품질은 각각 시험할 항목입니다. (모델 설계 설명)

기존 EmbeddingGemma와 무엇이 달라졌습니까?

기존 EmbeddingGemma 모델 카드는 Gemma 3 기반 약 300M 파라미터의 텍스트 임베딩 모델로 설명합니다. 새 모델은 Gemma 4 기반이며 코드 검색을 강화하고 이미지·영상·음성을 같은 공간으로 확장합니다. 한 번에 넣는 문맥도 이전 모델 카드의 2K 토큰에서 8,192토큰으로 늘었습니다. 768차원을 512·256·128차원으로 줄이는 MRL은 이전 모델도 지원하던 기능이라, 새로 생긴 것은 그 선택을 미디어 벡터에도 쓸 수 있다는 점입니다. 이전 모델을 문서 검색에 사용하던 팀에는 텍스트 품질 외에 미디어 인덱스를 추가할 수 있다는 변화가 큽니다. (이전 EmbeddingGemma 모델 카드 · 새 모델 개발자 가이드)

여기서 새 모델 내부의 모듈 호환성과 이전 버전에서의 이전 작업을 나눠 생각하면 편합니다. 가이드는 EmbeddingGemma 2의 같은 체크포인트에서 텍스트 전용으로 만든 질의 벡터를 전체 모듈로 만든 문서 벡터와 직접 비교할 수 있다고 설명합니다. 텍스트 인덱스를 만들다가 비전이나 오디오 모듈을 추가해도 이미 만든 벡터를 재계산할 필요가 없다는 안내입니다. 이전 EmbeddingGemma 1 벡터까지 같은 공간에 놓인다는 안내는 이 설명에 포함되지 않습니다. (구성 선택과 기존 벡터 설명)

코드 검색에서는 파일이나 함수에 질의와 관련된 코드가 있는지 찾는 앞단에 쓸 수 있습니다. 공식 데모는 Hugging Face transformers 코드베이스를 텍스트 전용 270M 구성으로 임베딩하고, Gemma 4 26B A4B와 Pi 에이전트 하네스로 관련 코드를 검색합니다. 임베딩 모델은 후보를 찾고 생성 모델은 그 결과로 작업을 이어가는 역할 분담입니다. 에이전트가 코드를 고치는 능력을 임베딩 점수 하나로 판단하기보다는 검색이 필요한 함수를 얼마나 잘 골라 주는지 확인하는 데 맞습니다. (공식 코드 검색 데모)

필요한 모듈만 켜면 메모리가 얼마나 줄어듭니까?

전체 모델의 740M은 약 7억 4천만 파라미터를 뜻합니다. 텍스트·코드 백본 270M에 비전 170M과 오디오 300M을 더한 구성입니다. 사진 검색만 만드는 앱이라면 오디오 인코더를 빼고, 문서와 녹음 검색이라면 비전 인코더를 빼는 선택이 가능합니다. 가이드는 비활성 인코더를 처음부터 메모리에 올리지 않아 가중치와 최대 할당량을 모두 줄인다고 설명합니다. (모듈 구성)

기기 실행에서는 파라미터 수와 실제 RAM을 따로 봅니다. 가중치를 낮은 정밀도로 저장하는 양자화, 입력 길이, 런타임과 검색 인덱스가 함께 메모리에 영향을 줍니다. Google AI Edge 발표는 양자화 인지 학습(QAT)을 이용한 INT4·INT8 압축을 설명하며, Pixel 11 Pro에서 텍스트 전용 가중치 약 191MB, 전체 멀티모달 모델 약 567MB의 활성 RAM을 제시합니다. 이 숫자는 그 기기의 최적화된 실행 예시이고, Python에서 다른 정밀도로 불러온 모델의 전체 메모리와는 조건이 다릅니다. (양자화와 기기 메모리 설명)

앱 설계에서는 모델을 올린 뒤 파일을 처리할 때 늘어나는 메모리도 관찰하면 좋습니다. 특히 사진·영상 디코딩, 벡터 인덱스, 함께 실행하는 생성 모델의 작업량을 구분해 재면 모듈을 빼서 줄인 부분을 파악하기 쉽습니다. Google은 Gemma 4와 조합할 때 텍스트 토크나이저와 오디오 인코더 아키텍처를 공유해 전체 메모리 부담을 줄이는 방향도 설명합니다. (공유 구성 설명)

벡터 차원을 줄이면 저장량과 검색 품질은 어떻게 달라집니까?

모델을 작게 올리는 것과 이미 만든 벡터를 작게 저장하는 것은 별도 선택입니다. EmbeddingGemma 2는 Matryoshka Representation Learning(MRL)을 지원합니다. 벡터 앞부분만 남겨 768차원을 512·256·128차원으로 줄여도 의미를 비교할 수 있도록 학습한 방식입니다. 질의와 문서는 같은 차원으로 맞추고, 잘라 낸 벡터를 정규화하는 설정을 사용합니다. (MRL 안내 · SentenceTransformer API)

위 품질 비율은 Google의 설명입니다. 128차원으로 줄이는 선택이 모든 입력에서 같은 손실을 만드는 것은 아니므로, 사진과 소리 검색을 주로 하는 앱이라면 256·512·768차원의 결과도 함께 비교할 수 있습니다. 재현율은 찾고 싶은 관련 자료 중 검색이 얼마나 많이 골라냈는지를 보는 지표입니다. 작은 벡터로 후보를 고른 다음 더 정밀한 모델로 순서를 다시 정하는 구성도 가능합니다. (차원 선택 지침)

가이드의 bfloat16 예시는 벡터 100만 개를 768차원으로 저장하면 약 1.5GB, 128차원으로 저장하면 약 250MB라고 설명합니다. 2바이트 값으로 직접 계산하면 각각 1,536,000,000바이트와 256,000,000바이트입니다. 같은 조건에서 256차원은 512,000,000바이트입니다. 이 계산에는 파일 이름·타임스탬프 같은 메타데이터와 검색 인덱스의 추가 공간을 제외했습니다. 모델을 작게 올려도 수백만 개 벡터를 큰 차원으로 저장하면 인덱스가 더 큰 메모리를 차지할 수 있다는 점을 보여 줍니다. (저장량 예시)

AI Edge 발표에는 인덱스 공간을 최대 8배 줄인다는 설명도 있지만, 차원만 768에서 128로 자르는 산술은 6배입니다. 개발자 가이드의 같은 자료형 예시를 기준으로 위 표를 작성했습니다. (AI Edge 최적화 설명 · 차원별 가이드)

공식 성능 주장과 속도는 어떤 조건에서 나왔습니까?

Google은 EmbeddingGemma 1 대비 MTEB Code 점수의 14% 향상을 주장합니다. MTEB는 여러 임베딩 작업을 평가하는 벤치마크이며, 이 항목은 코드 관련 평가입니다. 발표는 이미지·영상·음성 검색을 추가하면서 다국어 텍스트 정확도를 유지했다고 설명합니다. 14%는 코드 평가의 비교 수치로 읽고, 모든 검색 작업의 정확도가 14%포인트 오른 값으로 환산하지 않습니다. (벤치마크 설명)

속도 예시는 MacBook M5 Pro GPU에서 이미지 임베딩 37.3ms, 초당 26.9장입니다. 이미지당 최대 비전 토큰 70개 조건의 비전 인코딩 측정입니다. 전체 사진 보관함을 읽고 인덱싱하는 시간, 오디오 검색 시간, 휴대폰에서의 입력 지연과는 각각 다른 측정 항목입니다. 사진 한 장의 벡터 계산과 이미 저장한 벡터에서 결과를 찾는 시간도 나누면 앱의 병목을 찾기 편합니다. (기기별 비전 지연 설명)

한국어 도입에서는 다국어라는 설명보다 자신의 검색어와 자료 조합이 중요합니다. 예를 들어 한국어 질의로 영어 코드 주석을 찾는 작업, 한국어 질의로 여행 사진을 찾는 작업, 녹음 속 발화를 찾는 작업은 정답 자료가 다릅니다. 각 용도에서 기대하는 파일을 정하고 상위 결과에 들어오는지 비교하는 방식으로 모델·차원·모듈 구성을 선택할 수 있습니다. 여기에는 직접 실행한 한국어 품질 수치를 제시하지 않습니다.

앱과 개발 도구는 어디서 이용할 수 있습니까?

받는 곳부터 정리하면 이렇습니다. 모델 가중치는 Hugging Face에 공개됐고 Transformers·sentence-transformers·vLLM·SGLang·MLX·Ollama·LM Studio·LiteRT에서 쓸 수 있다고 안내됩니다. 휴대폰용으로 미리 양자화한 번들은 Hugging Face의 LiteRT Community에 있습니다. 설치 없이 브라우저에서 먼저 보려면 웹 데모가 있고, Gallery 앱은 Google Play와 App Store에서, Foresight는 Mac 다운로드 페이지에서 받습니다. (개발자 가이드의 지원 도구 · AI Edge 발표의 다운로드 안내)

일반 체험 경로는 Google AI Edge Gallery의 Instant Media Search와 Video Moments Finder입니다. 첫 데모는 사진·영상의 로컬 벡터를 SQLite 데이터베이스에 저장하고 질의와의 코사인 유사도로 결과를 찾습니다. 코사인 유사도는 벡터 방향의 가까움을 비교하는 값입니다. 둘째 데모는 영상의 순간을 인덱싱해 자연어 질의와 맞는 타임스탬프를 보여 줍니다. Gallery 저장소의 일반 OS 요건은 Android 12 이상·iOS 17 이상입니다. 개별 기기에서 새 데모가 실행되는 상태는 별도로 확인할 항목입니다. (데모 발표 · Gallery 공식 저장소)

Mac용 Foresight는 회의 대화·개인 파일·노트를 로컬에서 색인하고 찾는 실험 앱으로 소개됐습니다. EmbeddingGemma 2와 Gemma 4를 함께 사용하며, 시스템 오디오와 마이크 입력을 연결해 메모를 보완하고 관련 자료를 찾는 방향입니다. 검색용 임베딩 모델만 내려받는 경로와 생성 모델까지 함께 쓰는 회의 앱의 요구 자원을 구분하면 도입 조건을 파악하기 쉽습니다. (Foresight 소개)

개발 경로는 MediaPipe Universal Embedder와 Semantic Retriever입니다. 전자는 이미지 크기 조절·정규화·토큰화를 처리하고 벡터를 반환하며, 후자는 기기에 벡터를 색인하고 가까운 후보를 찾습니다. 전처리와 검색을 직접 구현할지, 이런 Task 인터페이스를 이용할지 선택할 수 있습니다. 더 세밀하게 가속과 처리를 제어하려는 앱은 LiteRT 직접 실행 경로도 안내됐습니다. (MediaPipe·LiteRT 안내)

Android ML Kit 통합은 “앞으로 몇 주 안에” 제공할 계획입니다. 발표는 가능한 기기에서 NPU 가속과 자동 모델 업데이트를 활용하는 경로로 설명합니다. NPU는 신경망 계산을 가속하는 전용 처리 장치입니다. 현재 안내된 Gallery·Python 경로와 앞으로 제공할 Android 서비스 통합을 나눠 일정에 넣는 편이 좋습니다. 한국 앱 스토어의 노출 여부와 Foresight의 세부 하드웨어 요건은 미확인입니다. (ML Kit 제공 계획)

Python으로 붙일 때 어떤 설정을 사용합니까?

개발자 가이드는 sentence-transformers 6.1.0 이상을 안내합니다. 모델 ID는 google/embeddinggemma-2입니다. 텍스트 검색어에는 SearchQuery, 검색 대상 문서에는 Document 프롬프트를 적용합니다. 검색어와 문서의 역할을 짧은 작업 지시로 구분하는 방식입니다. 아래는 공식 예제의 텍스트 전용 모듈 선택과 256차원 출력을 합친 구성 예시입니다. (공식 Python 가이드 · API 매개변수)

from sentence_transformers import SentenceTransformer

model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"vision_config": None, "audio_config": None},
    truncate_dim=256,
)
query = model.encode(
    "What causes the northern lights?",
    prompt_name="SearchQuery",
    normalize_embeddings=True,
)
document = model.encode(
    "The northern lights are caused by charged particles from the sun.",
    prompt_name="Document",
    normalize_embeddings=True,
)
print(model.similarity(query, document))

이미지·영상·음성은 모달리티 이름을 키로 쓰는 사전 입력으로 전달하고, 텍스트와 미디어를 섞을 때는 <|image|>·<|video|>·<|audio|> 표시로 위치를 지정합니다. 가이드는 영상의 기본 샘플링을 초당 1프레임, 오디오를 16kHz 모노로 설명합니다. 긴 영상 전체를 하나의 무제한 입력으로 넘기기보다는, 공유 8,192토큰 창 안에서 구간별 벡터와 시간 정보를 저장하는 제품 설계를 검토할 수 있습니다. (미디어 입력·문맥 안내)

또 다른 용도는 제로샷 의도 분류입니다. 학습 예제를 추가하지 않고 사용자 입력을 미리 작성한 분류 이름·설명과 비교하는 방식입니다. MediaPipe Decision Task 예시는 체스에서 매 턴 500개 선택지를 100ms 미만 응답으로 평가한다고 소개합니다. 이는 해당 예제의 지연 주장입니다. 업무 라우팅에 적용한다면 겹치는 분류 설명과 애매한 입력의 처리 기준을 준비하고 실제 질의로 비교할 수 있습니다. (Decision Task 예제)

비용과 라이선스는 어떻게 봅니까?

Google은 모델을 Apache 2.0으로 공개했다고 안내합니다. 기기에서 실행하는 검색은 호출마다 클라우드 토큰 요금을 내는 API와 다른 비용 구조입니다. 가중치 실행에 별도 클라우드 구독을 요구하지 않는다는 설명도 있습니다. 실제 예산은 기기 성능, 초기 인덱싱 시간, 모델과 미디어·벡터 저장 공간, 앱 개발·유지 작업으로 옮겨 갑니다. (라이선스 안내 · 로컬 실행 소개)

사진 100만 장을 검색하는 앱에서는 모델 메모리뿐 아니라 앞의 벡터 저장량을 함께 계산하면 좋습니다. 영상 검색은 저장하는 프레임 수와 오디오 구간 수가 인덱스 크기를 바꿉니다. 필요한 모달리티와 차원을 정하는 것이 곧 비용·자원 선택이 됩니다. 클라우드로 전송하는 단계를 줄이는 로컬 구조의 이점은 앱이 실제로 데이터를 처리하고 보관하는 방식과 함께 확인할 수 있습니다. (모듈과 저장량 선택)

초기 반응은 어떻습니까? (2026년 10월 7일 기준)

r/LocalLLaMA 출시 토론에는 일부 이용자가 오디오 입력을 임베딩할 수 있다는 점이 새롭다고 반응했습니다. 기기 메모리 제약을 거론하는 댓글과 모델을 바로 바꿔 써 보려는 반응도 있습니다. 데이터셋에 어떤 모델을 써서 색인할지 고민하던 시점에 나왔다는 댓글은 실제 검색 도구에 넣으려는 기대를 보여 줍니다.

메모리를 거론한 댓글은 적은 RAM으로 실행을 걱정할 이용자들을 예상하는 농담에 가깝습니다. 실패한 기기의 측정 보고로 해석하지 않았습니다. 전반적으로 초기 관심과 사용 의향이며 한국어 검색 품질·배터리 소모·대규모 인덱스 품질을 검증한 후기와는 구분합니다. 한국어 실사용 후기는 찾지 못했습니다. (반응 원문)

도입 전에 무엇을 비교하면 좋습니까?

텍스트 검색만 필요한 팀은 우선 270M 구성으로 기존 검색 결과를 비교할 수 있습니다. 사진·녹음이 이미 중요한 앱은 같은 질의를 여러 모달리티에 적용해 원하는 자료가 함께 나오는지 살펴볼 수 있습니다. 벡터 차원은 768에서 시작해 256·128로 줄이며 놓치는 파일을 기록하면 저장 공간을 위해 치르는 품질 손실을 파악하기 쉽습니다. 이 비교 절차는 공식 가이드의 모듈·차원 선택을 실제 자료에 적용하는 방법입니다. (구성 선택 가이드)

제품에서는 질의 하나의 속도와 처음 모든 자료를 색인하는 시간을 따로 기록할 수 있습니다. 검색 결과에 파일 경로·타임스탬프를 붙이고, 사진·녹음·문서별 정답 자료를 마련하면 “함께 검색된다”는 특성이 사용자의 작업에 도움이 되는지 판단할 수 있습니다. 지금의 도입 근거는 다양한 입력을 공통 공간으로 묶는 구조와 공개 구현 경로입니다. 한국어 정확도와 실제 기기의 자원 사용량은 자신의 자료로 채울 비교 항목입니다.

참고한 자료

• Google AI Edge 발표 — 2026-10-06 발표, 앱·메모리·속도·ML Kit 계획.
• EmbeddingGemma 2 개발자 가이드 — 모듈·입력·차원·코드 평가·Apache 2.0 안내.
• 기존 EmbeddingGemma 모델 카드 — 이전 텍스트 모델과의 차이.
• Google AI Edge Gallery 저장소 — 앱의 일반 OS 요건·설치 경로.
• SentenceTransformer API — 프롬프트·차원 축소·정규화 설정.
• Reddit 출시 토론 — 초기 관심과 기대.

자료 확인일은 2026년 10월 7일입니다. 모델·앱을 직접 실행한 결과는 포함하지 않았습니다.