EmbeddingGemma 2로 사내문서와 음성 영상까지 찾는 로컬 검색 만들기

EmbeddingGemma 2의 270M–740M 구성과 768차원 축소를 구분하고, 사내문서·음성·영상 검색을 원문 위치·권한·한국어 평가까지 설계하는 실무 가이드입니다.

개정 1판 · 최근 고침: 공식 모델카드·개발 가이드·제작자 앱 소개를 대조하고 로컬 검색 설계·산술 용량표·한국어 평가 절차를 작성했습니다. · 고침 기록 보기

제작자 공개 사양·앱 소개와 편집부의 미실행 설계를 구분합니다. 모델 설치·코드 실행·앱 사용·영상 재생 및 한국어 성능 측정은 하지 않았습니다. 메모리 산술은 벡터 배열만 계산한 예시입니다.

어느 파일과 어느 장면에 있는지 찾기

문서와 사진, 녹음, 영상을 같은 검색 공간에 담는 740M 모델이 나왔다. 텍스트만 쓸 때는 270M 구성으로 줄일 수 있다. 작은 모델을 실제 업무 검색에 붙일 때 필요한 설계와 평가 기준을 살펴본다.

회의에서 들은 설명은 기억나는데 어느 파일에 있는지 모를 때가 있다. 문서 제목을 검색해도 안 나오고 녹음 파일을 열자니 한 시간이 넘는다. 동료가 화면에 띄운 슬라이드에는 찾는 내용이 있었지만 회의록에는 남지 않았을 수도 있다. 이런 상황에서는 파일 종류별 검색창보다, 기억하는 내용을 한 번 입력해 관련 자료와 장면을 함께 찾는 방식이 편하다.

구글이 2026년 10월 6일 공개한 EmbeddingGemma 2는 그 검색의 바탕을 만드는 모델이다. 텍스트와 코드, 이미지, 음성, 영상을 공통 벡터 공간으로 바꾼다. 전체 모델은 7억 4천만 개 파라미터이며 필요한 입력 종류에 따라 일부 인코더만 사용할 수 있다. 구글은 이를 개인 기기에서 실행하는 검색과 RAG용 모델로 소개했다. 공식 발표

이번 공개를 업무에 적용하려면 먼저 범위를 좁히는 편이 좋다. 사내 자료 전체를 한꺼번에 연결하기보다, 자주 찾는 문서 묶음이나 짧은 교육 영상부터 검색해 보자. 파일을 벡터로 바꾸는 과정 자체보다 사용자가 원하는 근거를 제때 찾고 다시 열어볼 수 있도록 만드는 일이 중요하다.

이 절의 근거 S190

임베딩은 검색할 자료의 의미를 숫자로 표현한다

임베딩 모델은 입력을 숫자들의 배열인 벡터로 변환한다. 검색할 문서와 사용자의 질문을 각각 벡터로 만든 뒤, 두 벡터가 얼마나 가까운지 계산해 후보를 고른다. 예를 들어 문서에는 ‘연간 이용료’, 질문에는 ‘일 년 구독비’라고 적혀 있어도 의미가 비슷하면 후보로 연결될 수 있다. 표현이 조금 달라졌을 때 키워드 검색을 보완하는 방식이다.

멀티모달 임베딩은 입력의 종류를 넓힌다. ‘흰색 보드에 일정이 적힌 장면’이라는 문장과 회의 영상의 프레임을 비교하거나, ‘기계가 반복해서 삐 소리를 내는 부분’이라는 질문과 녹음 구간을 비교하는 시스템을 설계할 수 있다. 다만 이런 예시는 만들 수 있는 검색의 형태를 설명한 것이며 특정 한국어 질문에 대한 성공을 보장하는 결과는 아니다.

임베딩의 출력은 답변 문장이 아니다. RAG를 구성한다면 먼저 임베딩으로 근거 후보를 찾고 그 자료를 읽는 별도의 생성 모델이 답변을 작성한다. 따라서 검색이 잘못되면 뒤 단계가 아무리 유창해도 엉뚱한 근거를 설명할 수 있다. 초기 제품에서는 생성 기능 없이 ‘관련 문서 세 개와 원문 위치’를 먼저 제공하는 것도 충분히 유용하다. 검색 결과의 품질을 독립적으로 확인하기도 쉽다.

텍스트부터 시작하고 필요한 인코더를 더한다

EmbeddingGemma 2의 구성은 텍스트 전용 270M, 텍스트와 시각 입력 440M, 텍스트와 음성 570M, 전체 멀티모달 740M으로 나뉜다. 공식 개발 가이드에 따르면 같은 체크포인트의 이 구성들은 공통 벡터 공간을 사용한다. 텍스트 질문용으로 모든 인코더를 늘 켤 필요는 없다. 개발자 가이드

선택은 자료의 성격에 맞추면 된다. 사내 규정이나 개발 문서처럼 추출 가능한 글이 중심이면 텍스트 전용부터 시험한다. 도면, 화면 캡처, 표가 많은 슬라이드를 찾으려면 시각 입력을 추가할 이유가 생긴다. 통화 녹음이나 현장 소리 자체를 검색해야 한다면 음성 구성이 필요하다. 영상에서는 화면과 소리 중 어느 쪽을 근거로 찾을지 먼저 정해야 한다. 둘 다 중요한 업무라면 각각의 구간이 같은 시간축으로 연결되도록 설계한다.

하나의 긴 입력을 크게 넣는 것만으로 검색이 좋아지지는 않는다. 사용자에게 80쪽 매뉴얼 전체가 필요할 수도 있지만 대개는 특정 절차를 설명한 두 쪽이면 된다. 긴 회의 역시 ‘예산을 다시 논의한 40초’가 유용한 검색 결과일 수 있다. 검색 단위를 짧게 만들면 결과를 확인하기 쉬워지는 대신 저장할 벡터가 늘어난다. 이 절충은 실제 질문으로 판단해야 한다.

이 절의 근거 S191

768차원을 줄일 때 함께 살펴볼 것

기본 출력은 768차원이다. MRL 방식으로 앞부분을 남겨 512·256·128차원으로 줄일 수 있다. 모델카드는 잘라낸 벡터를 다시 정규화하고 질문과 자료의 차원을 같게 맞추도록 안내한다. 특히 128차원은 멀티모달 품질 하락이 커 텍스트 중심 작업에 더 적합하다고 설명한다. 모델카드의 차원 축소 지침

저장 공간은 직접 계산할 수 있다. 벡터 10만 개를 float32로 저장한다고 가정하면, 숫자 배열만으로 768차원은 307.2MB, 256차원은 102.4MB, 128차원은 51.2MB다. 차원 수에 데이터 개수와 숫자당 4바이트를 곱한 값이다. 여기에 파일 이름과 권한 정보, 검색 인덱스, 원문 또는 미리보기의 공간이 더해진다. ‘최대 6배 절감’을 앱 전체 용량이 6분의 1이 된다는 뜻으로 읽으면 안 된다.

출발점으로는 품질 기준선을 먼저 확보하는 편을 권장한다. 768차원으로 정답 자료가 잘 올라오는지 보고 같은 질문을 256차원에서도 실행한다. 두 결과의 차이가 업무상 받아들일 만하면 작은 차원을 선택한다. 반대로 저장 공간이 충분하고 이미지의 세부 내용을 구분해야 한다면 먼저 줄일 이유가 약하다. 128차원으로 빠르게 후보를 모으고 더 풍부한 표현으로 다시 순위를 매기는 구조도 검토할 수 있지만 탈락한 정답을 뒤 단계가 복구할 수는 없다.

메모리 숫자도 구분해서 읽어야 한다. 구글 발표에 등장하는 약 191MB와 567MB는 각각 텍스트 전용 가중치와 전체 멀티모달 모델의 active RAM 수치다. 양자화된 모델을 Pixel 11 Pro에서 실행했을 때 제시한 값이다. 일반 PC의 기본 정밀도 실행이나 완성된 검색 앱의 전체 메모리 요구량은 아니다. 발표의 온디바이스 성능 설명

LiteRT 배포 모델의 측정 설명은 더 구체적이다. 텍스트는 128 signature, 시각 입력은 70 signature를 사용했고 음성 파일 길이도 구성에 따라 다르다. 메모리는 캐시를 읽는 두 번째 로딩에서 측정했다. 운영체제마다 지표가 달라 직접 비교할 수 없으며 일부 Apple 측정을 제외하면 가속기 메모리가 포함되지 않는다. 따라서 도입 전에 실제 대상 기기에서 첫 실행, 반복 검색, 대량 색인, 장시간 사용을 따로 재는 편이 안전하다.

이 절의 근거 S192 · S190 · S193

제작자가 공개한 앱에서 읽을 수 있는 활용 방식

공개된 구현 사례도 있다. Google AI Edge Gallery 저장소는 EmbeddingGemma 2 기반의 Instant Media Search와 Video Moment Finder를 소개한다. 전자는 자연어 또는 예시 이미지로 미디어를 찾는 기능이고 후자는 영상에서 관련 시점을 찾아 타임라인으로 이동하는 기능이다. 저장소는 앱을 실험적 베타로 설명한다. 공식 Gallery 저장소

구글의 AI Edge 발표는 Mac용 Foresight도 소개한다. 회의 전사와 개인 파일을 기기 안에서 검색해 메모 작성 등을 돕는 실험적 앱이다. 같은 글에 따르면 Gallery의 미디어 검색은 로컬 SQLite에 임베딩을 저장하고 유사도에 따라 결과를 찾는다. 이는 제작자가 공개한 기능 설명으로, 기업 환경의 검증된 구축 실적이나 독립적인 성능 시험 결과와는 구분해야 한다. AI Edge의 앱 및 구현 소개

업무용으로 응용한다면 결과 화면이 중요하다. 교육 영상 검색에는 ‘관련 영상’이라는 파일 카드보다 재생 시작 시각과 앞뒤 몇 초를 함께 보여주는 구성이 낫다. 문서 검색에는 제목뿐 아니라 페이지와 짧은 근거를 붙인다. 사용자가 결과를 확인할 수 있어야 검색이 틀렸을 때도 빠르게 다음 행동을 정할 수 있다.

이 절의 근거 S194 · S195

작은 사내 검색을 만드는 다섯 단계

다음은 사내 장비 매뉴얼과 교육 영상을 대상으로 한 가상의 설계 예시다. 실제 고객 도입 사례가 아니라, 첫 실험의 범위를 정하기 위한 구성이다.

1. 자료 목록과 권한부터 정한다. 파일 ID, 버전, 작성일, 열람 가능한 조직을 기록한다. 삭제된 파일과 구버전 문서가 다시 검색되지 않도록 원본 상태를 확인하는 방법도 만든다. 임베딩 파일만 모아두면 나중에 어느 원문에서 왔는지 추적하기 어렵다.

2. 자료를 다시 열 수 있는 단위로 나눈다. 매뉴얼은 제목과 절차가 끊기지 않는 문단 묶음으로, 영상은 내용이 바뀌는 구간으로 나눈다. 각 조각에 페이지 번호 또는 시작·종료 시각을 붙인다. 표의 머리글과 단위가 본문에서 떨어지지 않게 확인한다.

3. 같은 설정으로 색인한다. 모델 버전, 출력 차원, 정규화 여부, 전처리 설정을 색인 메타데이터에 남긴다. 파일 내용이 바뀌면 해당 조각의 벡터도 갱신한다. 서로 다른 모델의 벡터를 길이가 같다는 이유만으로 같은 검색 공간에 섞지 않는다.

4. 권한에 맞는 후보를 찾는다. 질문을 벡터로 바꾸고 해당 사용자가 열 수 있는 자료 안에서 후보를 뽑는다. 문서 번호나 제품 코드처럼 정확한 문자열이 중요한 질문은 키워드 검색도 함께 시험한다. 유사도 점수가 높아도 권한을 대신할 수 없다.

5. 근거를 보여주고 필요할 때만 답변을 생성한다. 문서 페이지나 영상 시점을 먼저 제시하고 생성 모델을 붙였다면 답변의 각 주장과 원문이 연결되도록 한다. 검색 결과가 빈약하면 답변을 억지로 만들기보다 질문을 좁힐 수 있게 안내한다.

기본 기능을 직접 조립하는 것이 부담스럽다면 MediaPipe Semantic Retriever를 살펴볼 수 있다. 문서·이미지·음성의 임베딩 생성, 기기 내 저장, 검색을 묶어 제공하며 결과에는 레코드 ID와 내용, 메타데이터, 점수가 포함된다. 기본 텍스트 분할은 문자 기준 512, 중첩 100으로 안내된다. 이를 그대로 최적값으로 채택하기보다 실제 문서 구조에 맞는지 확인해야 한다.

이 절의 근거 S196

텍스트 두 건으로 시작하는 최소 예제

아래 코드는 공식 SentenceTransformers 사용법을 바탕으로 구성한 한국어 검색 예제다. 이 기사에서 모델을 실행해 산출한 성능 결과는 아니다. 개발 가이드는 sentence-transformers 6.1.0 이상을 안내한다. 필요한 패키지와 모델을 준비한 환경에서 질문과 문서에 다른 검색 형식을 적용하고 양쪽 모두 256차원으로 정규화한다. 공식 구현 가이드

import numpy as np
import torch
from sentence_transformers import SentenceTransformer

model = SentenceTransformer(
    "google/embeddinggemma-2",
    device="cpu",
    config_kwargs={"vision_config": None, "audio_config": None},
    model_kwargs={"torch_dtype": torch.float32},
)

documents = [
    "title: 장비 점검 | text: 전원을 끈 뒤 필터를 분리해 청소한다.",
    "title: 휴가 신청 | text: 휴가는 사내 시스템에서 신청한다.",
]
options = dict(truncate_dim=256, normalize_embeddings=True)
vectors = model.encode(documents, **options)
query = model.encode(
    "필터를 청소하기 전에 무엇을 해야 하나요?",
    prompt_name="SearchQuery",
    **options,
)

assert np.isfinite(vectors).all() and np.isfinite(query).all()
scores = vectors @ query
for index in np.argsort(scores)[::-1]:
    print(round(float(scores[index]), 3), documents[index])

이 절의 근거 S191

점수·정밀도·배포 경로를 구분하기

출력 점수를 ‘정답일 확률’로 읽으면 안 된다. 이 예제는 준비한 문서 가운데 질문과 가까운 순서를 계산할 뿐이다. 실제 평가에는 정답이 없는 질문도 넣어야 한다. 모든 질문에 가장 가까운 문서는 존재할 수 있기 때문이다.

일반 정밀도 추론에서는 float32 또는 지원 기기의 bfloat16을 사용해야 한다. 모델카드는 float16에서 NaN이나 품질 저하가 발생할 수 있다고 경고한다. 위 코드가 CPU와 float32를 명시한 이유다. 이 설정의 메모리 사용량을 앞서 소개한 LiteRT 양자화 수치와 비교해서는 안 된다. 수치 정밀도 안내

모바일·웹 배포에는 별도의 경로가 있다. LiteRT-LM 임베딩 문서는 Python, Kotlin, Swift, JavaScript 예제와 로컬 임베딩 서버 사용법을 제공한다. 모델 파일, 런타임, 입력 전처리까지 같은 조합으로 검증하고 옮기는 것이 좋다. 라이브러리를 바꾸면서 기존 예제의 접두사나 인자 이름을 그대로 복사하는 방식은 피한다.

이 절의 근거 S192 · S197

한국어 검색은 실제 질문으로 평가한다

모델카드의 다국어 MTEB 점수는 61.36, 코드 MTEB 점수는 78.68이며 표의 평가는 전체 정밀도 체크포인트 기준이다. 이것만으로 한국어 사내문서 검색 정확도를 알 수는 없다. 모델카드도 언어별 성능이 같지 않을 수 있다고 밝힌다. 공식 평가와 한계

첫 평가 세트는 현업에서 자주 받는 질문으로 만든다. 예를 들어 ‘출장비 정산’과 ‘출장 갔다 온 돈 처리’처럼 문서 표현과 다른 질문, 약어, 띄어쓰기 차이, 제품명과 숫자가 섞인 질문을 포함한다. 녹음 검색에서는 같은 의미의 정확한 용어와 일상적인 표현을 함께 시험한다. 발음이 비슷한 장비명이나 조용한 소리처럼 헷갈릴 만한 대상도 넣는다.

각 질문에는 정답 문서나 시간 구간을 사람이 지정한다. 상위 다섯 결과 안에 필요한 근거가 들어오는지, 첫 번째 결과가 실제로 유용한지, 정답이 없는 질문에서 관련 없어 보이는 자료를 얼마나 자주 내놓는지 살펴본다. 여러 개의 정답이 있는 질문이라면 일부만 찾았는지 모두 찾았는지도 구분한다. 평가자는 파일 제목만 보고 판단하지 말고 원문을 열어 답을 확인해야 한다.

비교 조건은 한 번에 하나씩 바꾸는 편이 해석하기 쉽다. 같은 문서와 질문으로 키워드 검색, 임베딩 검색, 두 방식을 합친 검색을 비교한다. 다음에는 차원을 바꾸고 그 뒤에 문서 분할 크기를 바꾼다. 모델과 분할 방식, 검색 설정을 한꺼번에 바꾸면 무엇이 개선에 기여했는지 알기 어렵다.

속도도 검색창에 답이 보일 때까지 측정한다. 모델 호출만 빠르고 디스크에서 영상 미리보기를 읽는 시간이 길면 사용자는 느리다고 느낀다. 첫 검색과 반복 검색, 질문 길이가 긴 경우, 색인이 커진 경우를 나눠 기록한다. 배터리를 사용하는 기기는 지속 실행 후 발열과 응답 시간도 확인한다. 이 기록이 있어야 로컬 실행의 이점과 운영 비용을 함께 판단할 수 있다.

이 절의 근거 S192

로컬 실행에서도 남는 책임

파일을 기기 안에서 처리하는 구조는 외부 전송을 줄이는 데 도움이 된다. 그렇더라도 검색 로그, 오류 수집, 백업, 원격 생성 모델로 넘어가는 근거 자료는 별도로 점검해야 한다. 검색 단계가 로컬이라는 이유만으로 전체 RAG가 오프라인이라고 부를 수는 없다. 음성 기록은 수집 권한과 보관 기간을 먼저 정하고 삭제 요청이 원본뿐 아니라 조각·벡터·캐시에도 반영되도록 설계해야 한다.

라이선스도 정확히 읽을 필요가 있다. 공식 배포는 Apache 2.0으로 표시돼 있으며 라이선스 원문은 재배포 시 라이선스 사본과 관련 고지 등 조건을 둔다. 동시에 모델카드는 배포 시 Gemma Prohibited Use Policy를 준수해야 한다고 명시한다. 정책에는 동의 없는 사람 추적과 필요한 권한·동의 없이 민감한 개인정보를 처리하는 행위 등에 대한 제한이 있다. ‘상업적으로 쓸 수 있는 공개 모델’이라는 설명을 ‘용도와 데이터에 아무 제약이 없다’는 의미로 받아들여서는 안 된다.

EmbeddingGemma 2를 검토할 이유는 분명하다. 업무 자료가 문서와 이미지, 녹음, 영상으로 흩어져 있고 외부 전송을 줄이면서 하나의 검색 경험을 만들고 싶을 때 후보가 된다. 시작은 작게 잡는 것이 좋다. 팀에서 반복되는 질문과 허용된 자료를 준비하고 정답 근거가 상위 결과에 들어오는지 확인하자. 그 결과가 좋아진 뒤에 입력 종류와 자료 범위를 넓히면, 새 모델의 사양이 실제 업무의 검색 편의로 이어지는지 판단할 수 있다.

이 절의 근거 S198 · S199