기술 글

EmbeddingGemma 2와 기기 안에서 실행하는 결정 모델

발행일: 2026-10-07
글쓴이: HDATF

Google이 2026년 10월 6일에 임베딩 모델 EmbeddingGemma 2를 공개했습니다. MediaPipe의 Decision Maker는 이 모델을 사용해 분류 판단과 예 또는 아니요 판단을 기기 안에서 실행합니다. 이 글에서는 무엇이 달라졌고 무엇이 아직 확인되지 않았는지 정리합니다.

가운데에 휴대폰이 서 있고, 글이 적힌 종이와 그림, 소리 타일에서 나온 구슬이 휴대폰으로 들어가는 그림

이 글이 다루는 질문

제품에 AI 기능을 넣으면 제품이 내려야 하는 작은 판단이 많아집니다. 들어온 문의가 환불 요청인지, 이 문서를 어느 부서로 보낼지, 사진에 결함이 보이는지 같은 판단입니다.

이런 판단을 서버의 대형 언어 모델에 맡길 수 있습니다. 이 경우 요청할 때마다 비용이 들고 응답이 늦어지며, 판단할 자료가 기기 밖으로 나갑니다.

이 글은 그런 작은 판단을 기기 안에서 처리할 수 있는지를 다룹니다. 글을 다 읽으면 어떤 판단을 기기 안 모델에 맡겨 볼지, 그 전에 무엇을 측정해야 하는지 정할 수 있습니다.

먼저 알아 둘 용어 세 가지

임베딩(embedding): 임베딩은 글이나 그림을 벡터라는 숫자 묶음으로 바꾼 결과입니다. 뜻이 비슷한 입력은 벡터도 비슷하게 나옵니다. 임베딩 모델은 벡터만 돌려줍니다.
결정 모델: 결정 모델은 판단만 하는 모델입니다. 판단할 자료와 미리 정한 질문을 받아 선택지마다 확률을 돌려줍니다.
온디바이스(on-device): 온디바이스는 모델을 사용자의 휴대폰이나 PC에서 직접 실행한다는 뜻입니다. 이 글에서는 "기기 안"이라고 씁니다.

EmbeddingGemma 2는 글, 그림, 소리를 벡터로 바꿔 하나의 공간에 놓습니다. 뜻이 가까운 입력은 서로 가까이 놓입니다.

EmbeddingGemma 2의 공개 내용

EmbeddingGemma 2는 Google DeepMind가 만든 임베딩 모델입니다. Google은 2026년 10월 6일에 이 모델을 공개했습니다. 아래 값은 모두 Google이 발표한 값입니다.

라이선스는 Apache 2.0입니다.
글(코드 포함), 그림, 영상, 소리를 768차원 벡터로 바꿔 하나의 공간에 놓습니다. 벡터 길이는 512, 256, 128로 줄여 쓸 수 있습니다.
전체 크기는 7억 4천만 파라미터입니다. 글 부분이 2억 7천만, 그림 부분이 1억 7천만, 소리 부분이 3억이며 필요한 부분만 불러올 수 있습니다.
한 번에 8,192 토큰을 입력받습니다. 그림으로는 약 29장, 영상으로는 약 58프레임, 소리로는 약 327초 분량입니다.
양자화한 모델은 Pixel 11 Pro에서 글만 다룰 때 메모리를 약 191MB, 모든 부분을 불러올 때 약 567MB 사용합니다. 양자화는 모델의 숫자를 더 작은 형식으로 저장해 크기를 줄이는 방법입니다.
코드 검색 평가인 MTEB Code 점수는 78.68입니다. 이전 모델인 EmbeddingGemma 1의 점수는 68.76이었습니다.
여러 언어를 대상으로 한 평가인 MTEB Multilingual v2 점수는 61.36으로, 이전 모델의 61.15와 거의 같습니다. 모델 카드에는 한국어만 따로 측정한 점수가 없습니다.

EmbeddingGemma로 판단하는 MediaPipe Decision Maker

MediaPipe는 AI 기능을 기기 안에서 실행할 때 쓰는 Google의 도구 모음입니다. Google은 MediaPipe 1.1.0에서 EmbeddingGemma 1과 2를 Decision Maker의 판단 엔진으로 추가했습니다. 릴리스 노트에는 판단할 자료와 선택지에 여러 형식의 입력을 넣을 수 있다고 적혀 있습니다.

Decision Maker는 세 가지 질문을 받습니다. 선택지 중 하나를 고르는 질문(ChoiceQuestion), 예와 아니요를 묻는 질문(BooleanQuestion), 등급을 매기는 질문(ScoreQuestion)입니다.
Google 문서에는 Decision Maker가 TypeSafe의 Jev 요청 형식(JSON)과 OpenAI의 json_schema 정의를 변환 코드 없이 읽는다고 적혀 있습니다. Jev는 TypeSafe가 API로 제공하는 결정 모델입니다.
Google 문서에 적힌 실행 환경은 Android, iOS, Python, Web, Desktop입니다.

같은 판단 요청이라도 서버에서 판단하면 자료가 기기 밖으로 나가고, 기기 안에서 판단하면 자료가 기기 안에 남습니다.

EmbeddingGemma 방식의 판단 과정

EmbeddingGemma 방식의 Decision Maker는 판단할 자료와 선택지를 각각 벡터로 바꾼 다음, 자료의 벡터와 각 선택지의 벡터를 비교합니다. Google 문서는 이 방식을 Bi-Encoder라고 부릅니다.

선택지의 벡터는 미리 계산해 둘 수 있습니다. Google은 체스 시연에서 Decision Maker가 한 수마다 선택지 500개를 100ms 안에 평가했다고 밝혔습니다.

판단할 자료와 선택지를 벡터로 바꾸면, 자료와 가까운 선택지일수록 높은 확률을 받습니다. 그림의 막대 높이는 예시입니다.

이 방식은 판단할 자료와 선택지를 따로 읽습니다. 그래서 조건, 부정, 예외를 함께 따져야 하는 판단에는 약할 수 있습니다. 이는 구조를 보고 한 추정이고, 실제로 그런지는 측정해 봐야 압니다.

Google의 Decision Maker 문서에 나온 세 가지 방식
방식	모델	문서에 적힌 강점
Bi-Encoder (따로 읽고 비교)	EmbeddingGemma 1, 2	높은 처리량
Cross-Encoder (함께 읽기)	Laya, GLiNER2.5-Decide	자료와 선택지를 함께 보는 어텐션
Autoregressive Decoder (글을 쓰는 모델)	Gemma 4 E2B, E4B	복잡한 조건 조합과 예외가 있는 정책 판단

공개된 결정 모델의 다섯 갈래

TypeSafe가 2026년 9월에 Jev를 소개한 뒤, 비슷한 일을 하는 공개 모델이 여러 개 나왔습니다. 이 모델들은 판단할 자료와 선택지를 어떻게 읽고 점수를 어디에서 얻는지에 따라 다섯 갈래로 나눌 수 있습니다.

아래 지도는 HDATF가 모델 카드와 공개 코드의 설명을 읽고 나눈 결과입니다. 모델을 직접 실행해 확인하기 전의 분류입니다.

1. 답 토큰의 점수 읽기

이 갈래의 모델은 언어 모델이 답을 쓰기 직전에, 선택지를 가리키는 토큰마다 매긴 점수를 읽습니다.

2. 판단용 출력층 따로 학습하기

언어 모델 위에 판단 전용 출력층(head)을 붙여 학습합니다.

3. 자료와 선택지 함께 읽기

양방향 인코더가 판단할 자료와 선택지를 한 번에 읽습니다.

4. 따로 읽고 벡터 비교하기

판단할 자료와 선택지를 각각 벡터로 바꾼 뒤 두 벡터를 비교합니다.

5. 선택지마다 자료의 다른 부분 보기

모델이 선택지마다 판단할 자료의 다른 부분을 읽습니다.

Jevlikevinnylarouge/jevlike (새 탭에서 열립니다)

갈래를 정하지 못한 모델

구조가 공개되지 않았거나 HDATF가 확인하지 못한 모델입니다.

Google 문서에서 Cross-Encoder로 묶인 Laya와 GLiNER2.5-Decide는 셋째 갈래의 방식에, EmbeddingGemma 1과 2는 넷째 갈래의 방식에 해당합니다. Decision Maker는 Gemma 4 방식도 지원하지만, 이 방식이 첫째 갈래와 같은 구현인지는 코드로 확인하지 않았습니다.
EmbeddingGemma 2 방식이 속한 넷째 갈래의 모델은 선택지의 벡터를 한 번 계산해 두고 여러 요청에 다시 쓸 수 있습니다. 이 갈래의 모델을 쓰기 전에는 조건, 부정, 예외를 함께 따져야 하는 판단을 맞히는지부터 확인해야 합니다.

주의해서 볼 점

Hacker News의 한 사용자가 Google 문서의 예제를 직접 실행하고 결과를 댓글로 남겼습니다. 이 예제는 "항공편을 취소하고 카드로 바로 환불해 주세요"라는 요청이 결제, 청구, 환불과 관련되는지 묻습니다. 사용자는 "관련된다"의 확률이 0.22로 나와 답이 틀렸다고 적었고, 같은 예제에서 Laya가 훨씬 정확했으며 속도도 거의 비슷했다고 덧붙였습니다. 이 결과는 한 사용자가 올린 사례 하나입니다.
Google 문서에는 Decision Maker가 보정된 확률을 돌려준다고 적혀 있습니다. 보정은 모델이 내놓은 확률이 실제로 맞는 비율과 같아지도록 조정하는 일입니다. 그러나 문서에 정확도 수치는 없습니다.
한국어로 판단 정확도를 측정한 공개 자료는 찾지 못했습니다.
EmbeddingGemma 2가 기기 안에서 처리하는 단계는 검색과 판단입니다. 답을 글로 쓰는 단계에는 생성 모델이 따로 필요하고, 그 비용은 따로 계산해야 합니다.

제품에 넣기 전에 정할 네 가지

기기 안 모델에 맡길 판단을 고릅니다. 선택지가 정해져 있고 틀려도 되돌릴 수 있는 판단부터 시작합니다.
제품을 만드는 팀이 정답을 아는 자료로 후보 모델의 정확도를 직접 측정합니다. 한국어로 쓰는 제품이라면 한국어 자료로 측정합니다.
확률의 기준값을 정합니다. 확률이 기준값보다 높으면 바로 처리하고, 낮으면 더 큰 모델이나 사람에게 넘깁니다.
조건과 예외가 많은 판단이라면 자료와 선택지를 함께 읽는 방식과 생성 모델까지 함께 비교합니다.

HDATF는 EmbeddingGemma 2와 Decision Maker를 아직 제품에 사용하지 않았습니다. HDATF는 기기 밖으로 내보내기 어려운 자료를 판단하는 일에 이 조합이 맞는지 측정해 볼 만하다고 봅니다.

이 글에서 확인하지 못한 것

이 글에는 HDATF가 EmbeddingGemma 2와 Decision Maker를 직접 실행해 측정한 값이 없습니다. 숫자는 Google의 발표, Laya 저장소, Hacker News 댓글 한 건에서 가져왔습니다.
Google 문서의 표에는 Laya의 크기가 149M으로 적혀 있습니다. Laya 저장소에 공개된 모델은 421M과 322M입니다. 두 곳의 Laya가 같은 모델인지는 확인하지 못했습니다.
Decision Maker가 2026년 10월 6일 전에도 있었는지는 확인하지 못했습니다.
TypeSafe는 Jev의 구조를 공개하지 않았습니다. 그래서 Jev는 다섯 갈래 중 어디에도 넣지 않았습니다.