임베딩젬마 2, 글은 0.21점 코드는 9.92점 올랐다

effidev·2026년 10월 7일

내 코드 저장소에서 “로그인 실패를 처리하는 부분”을 이름이 아니라 뜻으로 찾고 싶거나, 폰에 쌓인 사진과 녹음 파일을 “고양이가 키보드 위에서 자는 사진”처럼 말로 찾고 싶었던 적이 있다면 이 글이 필요하다. 그런 검색을 가능하게 하는 부품이 임베딩 모델인데, 구글 딥마인드가 2026년 10월 6일 임베딩젬마 2(EmbeddingGemma 2)를 공개했다.

숫자 두 개만 먼저 보면 이 모델의 성격이 보인다. 글 검색 점수는 첫 버전의 61.15에서 61.36으로 0.21점 올랐고, 코드 검색 점수는 68.76에서 78.68로 9.92점 올랐다. 새 모델인데 글은 거의 제자리고, 대신 코드·이미지·영상·소리가 한꺼번에 붙었다.

이 글은 세 부류를 위해 쓴다. 코딩 에이전트나 사내 문서 검색(RAG)에 붙일 임베딩 모델을 고르는 개발자, 폰이나 노트북 안에서만 돌아가는 검색을 만들려는 사람, 그리고 “임베딩”이라는 말을 오늘 처음 들은 사람이다. 용어는 처음 나올 때 풀어 쓴다.

근거는 구글 딥마인드 발표문, 같은 날 올라온 구글 개발자 블로그 두 편(개발자 가이드, 구글 AI 엣지 소개글), 허깅페이스 모델 카드, 그리고 Hacker News 댓글이다. 벤치마크 숫자는 전부 구글이 직접 적은 값이고, 이 사이트가 모델을 내려받아 다시 재 본 것은 없다. 읽으면서 “구글이 말한 값”이라는 전제를 계속 달고 가면 된다.

임베딩은 글을 숫자 줄로 바꿔서 뜻이 가까운지 재는 일이다

임베딩 모델은 글 한 덩어리를 받아서 숫자 수백 개짜리 줄(벡터)로 바꿔 준다. 뜻이 비슷한 글은 숫자 줄도 비슷하게 나오도록 학습돼 있다. 그래서 “비밀번호를 잊어버렸어요”와 “로그인이 안 돼요”는 단어가 하나도 안 겹쳐도 가까운 줄이 된다.

이 줄을 미리 만들어 저장해 두면, 검색어도 같은 모델로 줄을 만든 뒤 가장 가까운 줄을 찾기만 하면 된다. 문서 검색 기능과 RAG(검색해 온 문서를 AI 답변의 근거로 붙이는 방식), 코딩 에이전트가 코드베이스에서 관련 파일을 찾는 기능이 전부 이 구조 위에 있다.

한 가지 알아 둘 점은, 저장해 둔 줄은 만든 모델에 묶인다는 것이다. 모델을 바꾸면 줄 값이 달라지므로 저장된 문서를 전부 다시 계산해야 한다. 이 이야기는 아래 라이선스 대목에서 다시 나온다.

한 모델에 소리까지 들어왔다: 270M에서 740M까지 골라 싣는다

임베딩젬마 2는 파라미터(모델 안의 조절 숫자) 7억 4천만 개짜리 하나의 모델이고, 글·코드·이미지·영상·소리를 같은 768칸짜리 공간에 넣는다. 예전에는 사진을 설명글로 바꾸는 모델, 음성을 글로 바꾸는 모델, 글을 임베딩하는 모델을 줄줄이 이어 붙여야 했는데, 구글은 그 연결을 없앴다고 설명한다.

이 구성은 별도 모델 네 개가 아니라 파일 하나에서 필요한 부분만 불러오는 방식이다. 모델 카드에는 글 쪽이 270M(뼈대 130M에 단어별 숫자표 140M), 비전 인코더가 170M, 오디오 인코더가 300M으로 나와 있다. 합치면 740M이다.

개발자 가이드에서 눈에 띄는 한 줄이 있다. 글만으로 만든 검색 색인에 나중에 이미지 기능을 켜도, 이미 계산해 둔 줄을 다시 계산할 필요가 없다고 한다. 네 구성이 같은 체크포인트를 쓰고 같은 공간을 공유하기 때문이다. 글 전용 270M으로 만든 검색어가 740M 전체로 만든 문서와 바로 비교된다는 설명도 있다.

한 번에 넣을 수 있는 양은 토큰(모델이 글을 읽는 단위) 8,192개다. 발표문은 이걸 첫 버전의 4배라고 하고, 한 종류만 넣을 때 소리는 최대 5.5분, 이미지는 29장, 영상은 58프레임까지라고 적었다. 영상은 기본으로 1초에 1프레임씩 뽑고, 소리는 16kHz 모노여야 한다.

점수표를 읽으면: 글은 제자리, 코드는 9.92점, 나머지는 비교 대상이 없다

모델 카드의 768차원 전체 점수다. 오른쪽 열은 첫 버전이고, 첫 버전은 글 전용 모델이라 나머지 칸은 비어 있다.

읽는 법은 세 가지다. 첫째, 글 점수 61.36 대 61.15는 소수점 둘째 자리 차이라서 사실상 같다고 보는 게 맞다. 구글도 “다국어 글 성능을 유지했다”고 적었고, Hacker News 댓글에서도 “글 벤치마크는 첫 버전과 같다”는 지적이 나왔다. 글 검색만 쓰는 사람에게는 새 버전으로 옮길 점수상의 이유가 없다.

둘째, 코드 검색의 9.92점은 실제로 큰 변화다. 발표문은 이걸 로컬 코드베이스 색인, 의미 기반 코드 검색, 코딩 에이전트의 검색에 맞는다고 소개한다. 모델 카드는 약 14% 향상이라고 적는데, 78.68을 68.76으로 나누면 1.144라서 맞는 말이다.

셋째, 이미지·영상·소리 점수는 비교 대상이 표에 없다. 구글은 “1B 미만 멀티모달 임베딩 모델 중 같은 크기 최고 수준”이라고 주장하지만, 비교 상대와 그 점수는 이번에 글로 읽을 수 있던 본문과 모델 카드 표에서 확인하지 못했다(발표문의 그래프 이미지는 글로 읽을 수 없었다). Hacker News에서도 구글의 다른 모델인 SigLIP 2와 왜 비교하지 않았느냐는 질문이 올라왔다. 이 칸의 우열은 직접 재 보기 전에는 모른다.

벡터를 줄이면 저장 공간은 6분의 1이 되지만, 영상과 소리가 더 많이 깎인다

임베딩젬마 2는 마트료시카(러시아 인형)처럼 앞쪽 숫자만 잘라 써도 되도록 학습됐다. 768칸을 512·256·128칸으로 줄일 수 있고, 줄일수록 저장 공간과 검색 계산이 줄어든다. 모델 카드가 칸 수별 점수를 전부 적어 두었다.

256칸까지는 손실이 작다. 글은 0.95점, 코드는 2.50점, 멀티모달 종합은 2.77점 내려간다(이 사이트 계산). 개발자 가이드도 256칸에서 글과 코드는 대부분, 이미지·영상·소리는 약 95%가 남는다고 적었다.

128칸은 이야기가 다르다. 글은 3.47점, 코드는 7.27점 내려가는 정도인데, 멀티모달 종합은 59.01에서 45.65로 13.36점, 소리 검색은 12.83점 내려간다. 가이드는 128칸이 글 전용 대형 색인이나 “후보를 먼저 추리는 1차 검색”에 맞고, 멀티모달 검색에 쓰려면 내 데이터로 먼저 확인하라고 경고한다.

저장 크기로 옮기면 이렇다. 문서 조각 100만 개를 768칸 bfloat16(숫자 하나를 2바이트로 저장하는 형식)으로 저장하면 구글 가이드 기준 약 1.5GB, 128칸이면 약 250MB다. 조각이 10만 개면 각각 약 150MB와 약 25MB로 줄어드는 셈이다(이 사이트 계산). 폰 안에 색인을 두는 앱이라면 이 차이가 곧 앱 크기다.

에러 없이 틀리는 곳이 세 군데 있다

모델 카드의 사용 지침에서 가장 값진 부분이다. 세 가지가 전부 에러를 내지 않고 그럴듯한 값을 돌려주면서 품질만 떨어뜨리는 유형이라, 점수표보다 이쪽이 실제 사고와 가깝다.

첫째, float16으로 돌리면 안 된다. 모델 카드는 이 모델의 중간 계산 값이 float16이 표현하는 범위를 넘어서서, float16에서는 NaN(숫자가 아닌 값)을 내거나 에러 없이 품질이 떨어진 임베딩이 나온다고 적었다. bfloat16이나 float32를 쓰라는 안내다. float16은 메모리를 아끼려고 흔히 고르는 설정이라 가장 먼저 걸릴 곳이다.

둘째, 줄인 뒤에는 다시 정규화(길이를 1로 맞추는 계산)해야 한다. 앞쪽 128칸만 잘라 내면 벡터 길이가 1이 아니게 되는데, 이 상태로 코사인 유사도를 계산하면 순위가 조용히 틀어진다. 카드는 “그럴듯해 보이는 점수가 나올 뿐 에러는 나지 않는다”고 적었다. 인코딩 함수에 truncate_dim과 normalize_embeddings=True를 같이 넘기면 도구가 대신 처리한다.

셋째, 검색어와 문서의 칸 수를 맞추고 작업 접두어를 붙인다. 768칸으로 만든 검색어를 128칸 색인과 비교할 수 없다. 또 이 모델은 “search result”, “code retrieval” 같은 짧은 작업 지시문을 앞에 붙여 학습했고, 접두어를 빼도 돌아가긴 하지만 정밀도가 떨어진다고 한다. 제목이 있는 문서는 title: 제목 | text: 본문 모양으로 직접 맞춰야 하는데, 접두어 이름만 Document로 주면 제목이 none으로 들어간다는 주의도 적혀 있다.

폰에서는 메모리 191MB부터 돈다는데, 측정 조건이 한 줄뿐이다

구글 AI 엣지 소개글은 양자화(숫자를 줄여 저장하는 압축)를 적용했을 때 구글 픽셀 11 프로에서 글 전용 모델이 활성 메모리 약 191MB, 전체 멀티모달 모델이 약 567MB면 된다고 적었다. 이 수치가 나온 속도·배터리 조건은 읽은 문서 어디에도 없다. 메모리 요구량만 있고 지연 시간은 없으니, “돌아간다”와 “쓸 만하게 빠르다”는 구분해서 읽어야 한다.

같은 글은 데모 세 가지를 소개한다. 구글 AI 엣지 갤러리 앱의 Instant Media Search는 폰 속 사진을 말이나 예시 사진으로 찾고, Video Moments Finder는 영상에서 “아이들이 웃는 장면” 같은 순간을 자막 없이 시각 단서로 찾는다. 맥용 실험 앱 Foresight는 회의 녹음과 개인 파일을 기기 안에서만 검색한다.

개발자에게 더 직접적인 대목은 구글 설명대로 이 임베딩 모델을 분류기처럼 쓰는 방식이다. 학습 없이 입력을 라벨 설명과 비교해서 의도를 가르는 “제로샷 라우팅”이고, 구글은 체스 게임에서 한 수마다 500개 선택지를 100밀리초 안에 평가하는 영상을 예로 든다. 이 사이트가 지난주에 쓴 클라우드플레어 Clef 글에서 다룬, 판단 전용 모델이 문장을 쓰는 대신 선택지에 확률을 붙이는 방식과 같은 방향이다.

다만 Hacker News에는 직접 돌려 본 사용자의 반례가 하나 있었다. 구글 문서에 예시로 나오는 “항공권을 취소하고 카드로 즉시 환불해 줘”가 결제 관련인지 묻는 질문에서, 자기 컴퓨터에서 돌린 결과가 “결제·환불과 관련 없음”이었고 참일 확률이 0.22로 나왔다는 것이다. 어떤 설정으로 돌렸는지 댓글에 자세한 내용은 없다. 한 사람의 한 번의 실험이라 일반화할 수는 없지만, 분류기로 쓸 거라면 자기 라벨과 문장으로 먼저 정확도를 재 봐야 한다는 경고로는 충분하다.

라이선스가 Gemma에서 Apache 2.0으로 바뀌었다

허깅페이스에서 두 모델의 라이선스 표시를 직접 비교했다. 첫 버전 embeddinggemma-300m은 gemma(구글 자체 약관)이고, 임베딩젬마 2는 apache-2.0이다. 모델 카드도 라이선스를 Apache 2.0이라고 적었다. 구글 자체 약관 대신 널리 쓰이는 오픈소스 라이선스가 붙었다는 뜻이다. 조건의 세부는 각 약관 원문을 읽어야 한다.

이 변화가 임베딩 모델에서 특히 중요한 이유를 Hacker News에서 한 개발자가 이렇게 설명했다. 임베딩은 수천~수백만 개를 계산해 저장해 두고 나중에 비교하는 용도라서, 모델이 닫힌 호스팅 전용이면 업체가 어느 날 그 모델 서비스를 끝낼 때 저장한 벡터 전부를 새 모델로 다시 계산해야 하고 그 비용은 사용자 몫이라는 것이다. 모델 가중치를 직접 내려받을 수 있으면 호스팅 업체가 사라져도 같은 모델을 내 서버나 다른 업체에서 돌릴 수 있다.

앞에서 말한 “저장한 줄은 만든 모델에 묶인다”가 바로 이 대목이다. 색인을 크게 만들 계획이라면 점수보다 먼저 그 모델을 내가 계속 돌릴 수 있는가를 확인하는 편이 오래 간다.

Hacker News에서는 환영이 먼저였고, 비교 요청이 뒤따랐다

글을 쓰는 시점에 Hacker News 글은 172점에 댓글 25개였다. 반응을 묶으면 세 갈래다.

첫 갈래는 환영이다. 한 댓글은 LLM과 에이전트가 쓰이는 방식이 바뀐 뒤로 “적당한 크기의 좋은 임베딩 모델”이 없어서 답답했는데, 글 전용 270M은 예전 임베딩 모델과 비교해 좋고 글+비전 440M도 나쁘지 않다고 적었다. 구글이 안드로이드 폰에 넣을 만한 수준의 모델을 가중치와 라이선스까지 열어 준 데 대한 고마움도 올라왔다. 자기가 쓰는 에이전트 하네스(모델을 감싸 일을 시키는 틀)에 시험해 본 뒤 넣겠다는 사람도 있었다.

둘째 갈래는 비교 요청이다. 다른 회사의 임베딩 서비스인 Voyage AI 모델과 글 성능이 어떻게 다른지, 앞서 말한 SigLIP 2와는 어떤지 묻는 글이 올라왔다. 발표 당일이라 아직 답이 될 만한 독립 측정이 없다.

셋째 갈래는 구조에 대한 관찰이다. 파라미터가 글 270M·비전 170M·소리 300M으로 나뉜다는 점을 짚은 댓글이 있었고, 칸 수를 줄여도 모델 크기는 줄지 않는다는 지적은 위에서 다뤘다. 용도가 뭐냐는 질문에는 “글로 사진을 찾고, 사진으로 글을 찾는 검색”이라는 답이 달렸다.

구글 문서에 없는 것

이번에 읽은 문서에서 확인되지 않은 항목을 모았다.

특히 한국어 사용자는 “100개 이상 언어를 이해한다”는 문장과 다국어 평균 61.36만 있다는 점을 기억해야 한다. 한국어 문서 검색이 목적이면 내 문서 몇 십 건과 질문 몇 십 개로 직접 재 보는 것이 점수표보다 정확하다.

칸 수 이야기도 하나 짚는다. 앞쪽 숫자만 잘라 쓰는 방식은 저장 공간과 검색 계산은 줄여도 모델 파일 자체는 그대로다. 폰에서 모델이 차지하는 메모리를 줄이려면 구성(270M·440M·570M·740M)으로 고르는 쪽이고, 칸 수는 색인 쪽의 선택이다. Hacker News 댓글에서 기존 온디바이스 모델과 달리 모델 크기를 함께 줄이는 방식이 아니라는 점이 지적됐다.

내 프로젝트에 넣을지 정하는 기준

글 검색 점수만 보면 첫 버전과 같으므로, 지금 글 전용 RAG를 첫 버전으로 돌리면서 만족한다면 굳이 갈아탈 이유는 약하다. 갈아타면 색인 전체를 다시 계산해야 한다.

바꿀 만한 경우는 세 가지다. 코드베이스 검색이 목적이라면 코드 점수 9.92점 향상이 가장 확실한 이유다. 글과 함께 이미지나 소리를 한 색인에서 찾고 싶다면 여러 모델을 이어 붙이던 구성을 이 하나로 줄일 수 있다. 데이터를 기기 밖으로 내보내기 싫다면 Apache 2.0과 270M 글 전용 구성이 맞는다. 작은 로컬 모델 이야기는 이 사이트의 12GB 카드로 큰 모델을 돌리는 Strata 글과 같은 맥락이라 함께 읽어도 좋다.

시험은 이렇게 시작할 수 있다. 구글 가이드의 설치 명령은 pip install -U sentence-transformers[image,audio,video] transformers이고(sentence-transformers 6.1.0 이상), 모델 이름은 google/embeddinggemma-2다. 글 전용으로 가볍게 쓰려면 불러올 때 vision_config와 audio_config를 None으로 주면 270M만 올라온다. 이 글의 코드는 구글 문서의 예시를 옮기거나 합친 것이고, 이 사이트가 내려받아 실행해 본 것은 아니다.

구글 가이드에 나온 글 전용 최소 예시는 이 정도다. 글 전용 270M만 올리고, 검색어와 문서에 각각 맞는 접두어를 붙여 코사인 유사도를 본다.

from sentence_transformers import SentenceTransformer

model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"vision_config": None, "audio_config": None},  # 글·코드만, 270M
)

query_emb = model.encode("What causes the northern lights?", prompt_name="SearchQuery")
doc_emb = model.encode("The northern lights are caused by charged particles from the sun.", prompt_name="Document")
print(model.similarity(query_emb, doc_emb))

색인이 커서 저장 공간이 걱정되면 model.encode(..., truncate_dim=256, normalize_embeddings=True)처럼 두 인자를 같이 주면 된다. 검색어와 문서에 같은 값을 줘야 한다는 점은 위에서 말한 그대로다.

처음 돌릴 때 확인할 것은 세 가지다. 숫자 형식이 bfloat16 또는 float32인지, 줄이는 경우 정규화가 같이 들어갔는지, 내 문서 몇 십 건에서 기존 모델 대비 순위가 실제로 나아졌는지다. 점수표는 구글이 고른 시험지 위의 이야기고, 마지막 판정은 늘 내 문서가 한다.