이 글은 Gemma 4 Challenge: Write About Gemma 4를 위한 제출물입니다.

면책 조항 (Disclaimer): 이 기사는 독립적인 의견서입니다. 저자는 Google DeepMind 또는 Gemma 프로젝트와 관련된 어떠한 엔티티와도 관계가 없습니다. 인용된 모든 벤치마크 수치는 2026년 5월 기준 공개적으로 사용 가능한 문서, 공식 Gemma 4 모델 카드 (model card), 동료 검토를 거친 프리프린트 (preprints) 및 커뮤니티 평가에서 가져왔습니다. Google이 직접 보고한 벤치마크의 경우 명시적으로 표기하였습니다. 이 분석은 확정적인 기술 지침으로 간주되어서는 안 됩니다. 독자들은 자신의 특정 사용 사례에 대해 직접 평가를 수행할 것을 권장합니다.

E2B, E4B, 26B MoE 및 31B Dense에 대한 10가지 차원의 비교 분석 — 아키텍처 (architecture) 선택이 능력 (capability) 선택과 체계적으로 혼동되고 있다는 단호한 의견을 담았습니다.

목차

• 이 분석이 존재하는 이유
• 모델들: 기술적 입문 (Technical Primer)
• 프레임워크: 10가지 평가 차원
• 1️⃣ 지시 이행 (Instruction Following)
• 2️⃣ 추론 능력 (Reasoning Capability)
• 3️⃣ 코딩 능력 (Coding Ability)
• 4️⃣ 환각 저항성 (Hallucination Resistance)
• 5️⃣ 개인정보 보호 및 안전 준수 (Privacy & Safety Compliance)
• 6️⃣ 도메인 지식 (Domain Knowledge)
• 7️⃣ 긴 문맥 이해 (Long-Context Understanding)
• 8️⃣ 창의성 및 작문 품질 (Creativity & Writing Quality)
• 9️⃣ 다국어 능력 (Multilingual Capability)
• 🔟 효율성 및 비용 (Efficiency & Cost)
• 마스터 결정 매트릭스 (Master Decision Matrix)
• 간과된 논점: MoE는 중간 지점이 아니다
• 권장 사항을 포함한 배포 시나리오
• 나의 결론
• 핵심 요약

이 분석이 존재하는 이유

이 분석이 존재하는 이유

Google DeepMind가 2026년 4월 2일 Gemma 4를 출시했을 때, 대부분의 보도는 두 가지 서사에 집중되었습니다: 소형 모델이 이제 스마트폰에서 실행된다는 점과 31B 모델이 크기가 20배 더 큰 모델들을 압도한다는 점입니다. 두 가지 모두 사실입니다. 하지만 실제로 어떤 변체(variant)를 배포할지 결정해야 하는 개발자에게는 어느 쪽도 충분하지 않습니다.

네 가지 Gemma 4 모델은 단순히 크기가 커질수록 항상 더 좋아지는 단순한 크기 계단이 아닙니다. 이 모델들은 Raspberry Pi부터 H100 서버에 이르는 하드웨어 스펙트럼 전반에 걸쳐 배포되는 세 가지 뚜렷한 아키텍처 철학 — 에지(edge)를 위한 계층별 임베딩 (Per-Layer Embedding, PLE) 밀집(dense) 모델, 효율적인 서빙 (serving)을 위한 전문가 혼합 (Mixture-of-Experts, MoE), 그리고 최대 품질을 위한 표준 밀집 (standard dense) 모델 — 을 나타냅니다.

잘못된 변체를 선택하는 것은 단순히 컴퓨팅 자원을 낭비하는 것에 그치지 않습니다. 이는 품질이 부족해서가 아니라, 아키텍처가 맞지 않아 당신이 요청하는 작업을 근본적으로 수행할 수 없는 모델을 배포하게 된다는 것을 의미할 수 있습니다.

이 분석은 제가 필요했을 때 찾을 수 없었던 비교 자료를 제공합니다: 체계적이고, 정직하며, 다차원적이고, 증거가 뒷받침되는 부분에서는 주관적인 견해를 담고 있습니다.

모델: 기술적 입문

평가하기에 앞서, 우리가 무엇을 비교하고 있는지 정확히 정의할 필요가 있습니다. Gemma 4 제품군은 모든 변체에 걸쳐 262,144-토큰 어휘(vocabulary)와 하이브리드 로컬/글로벌 어텐션 (hybrid local/global attention) 아키텍처를 공유합니다. 이러한 아키텍처의 공통점은 중요합니다. 즉, 이 비교는 근본적으로 다른 설계 철학에 관한 것이 아니라, 배포 대상과 용량에 관한 것이라는 의미입니다.

네 가지 변체

┌─────────────────┬──────────────┬──────────────┬──────────────┬──────────────┐
│                 │     E2B      │     E4B      │  26B MoE     │  31B Dense   │
├─────────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
...

E2B/E4B의 "효과적 (effective)" 파라미터 대 "전체 (total)" 파라미터에 관한 참고 사항:
E"는 "효과적 (effective)"을 의미합니다. 이 모델들은 층별 임베딩 (Per-Layer Embeddings, PLE)을 사용하며, 각 디코더 층 (decoder layer)은 자체적인 작은 임베딩 테이블을 유지합니다. 임베딩 테이블은 전체 파라미터 수(E2B는 5.1B, E4B는 8B) 측면에서는 크지만, 이는 행렬 곱셈 (matrix multiplications)이 아닌 룩업 연산 (lookup operations)입니다. 추론 (inference) 중의 "연산적 (computational)" 파라미터 수는 효과적인 수치(2.3B, 4.5B)입니다. 이러한 구분은 이 모델들의 RAM 요구 사항과 품질 상한선 (quality ceiling)을 모두 이해하는 데 중요합니다.

26B MoE의 "A4B"에 관한 참고 사항:
"A4B" 접미사는 "4 Billion Active"를 의미합니다. 전체 25.2B 파라미터 중 토큰당 3.8B만이 활성화되며, 이는 128개의 사용 가능한 전문가 네트워크 (expert networks) 중 8개로 라우팅 (routing)되는 것을 의미합니다. 이것이 26B MoE가 라우터가 올바른 결정을 내릴 때만 E4B에 근접한 추론 비용으로 31B에 근접한 품질을 제공할 수 있는 이유입니다. 적대적 (adversarial) 또는 분포 외 (out-of-distribution) 프롬프트 상황에서의 전문가 라우팅 안정성은 여전히 미해결 연구 과제로 남아 있습니다.

프레임워크: 10가지 평가 차원

이것을 단순한 벤치마크 경쟁으로 취급하는 대신, 저는 실제 배포 결정에 반영되는 10가지 차원에 걸쳐 각 모델을 평가합니다. 각 차원마다 저는 다음을 제공합니다: 질적 평가 (qualitative assessment), 뒷받침하는 근거 (supporting evidence), 그리고 승자 추천 (winner recommendation).

근거 자료는 다음에서 가져왔습니다: 공식 Gemma 4 모델 카드 (Google DeepMind), 프리프린트(preprint) 논문 "Gemma 4, Phi-4, and Qwen3: Accuracy-Efficiency Tradeoffs in Dense and MoE Reasoning Language Models" 및 커뮤니티 벤치마크.

1️⃣ 지시 이행 (Instruction Following): 얼마나 정확하게 당신을 따르는가?

측정 항목: 단일 단계 및 다단계 지시 준수, 제약 조건 충족, 형식 준수, 그리고 모호하거나 모순된 지시에 대한 민감도.

평가

이 제품군에서 지시 준수 품질 (Instruction following quality)은 파라미터 수에 따라 대략 선형적으로 증가하지만, 지시 준수 실패의 _유형_은 아키텍처(Architecture)에 따라 다릅니다.

**E2B**는 단순하고 모호하지 않은 단일 단계 지시를 안정적으로 따릅니다. 이 모델의 실패 모드(Failure mode)는 제약 조건 중첩(Constraint stacking)입니다. 세 가지의 동시 제약 조건(예: "타밀어로 작성할 것, 격식 있는 어조를 사용할 것, 150단어 이내로 제한할 것")을 부여하면, 모델은 제약 조건을 조용히 누락하기 시작하며, 대개 구조적으로 가장 까다로운 조건을 먼저 누락합니다. 이는 2B 유효 규모(Effective scale)의 PLE 아키텍처에서 문서화된 한계점입니다.

**E4B**는 23개의 동시 제약 조건을 잘 처리합니다. 커뮤니티 벤치마크에 따르면, 이 모델은 구조화된 형식 작업(JSON 출력, 마크다운 표, 특정 패턴이 포함된 코드)을 수행할 때 유효 파라미터 수가 34배 더 많은 모델들과 경쟁할 만한 성공률을 보여줍니다. 128K 컨텍스트 윈도우(Context window)는 복잡한 지시 패턴을 위한 풍부한 퓨샷(Few-shot) 예시를 제공하기에 충분합니다.

**26B MoE**는 질적으로 다른 동작을 보여줍니다. 질의가 잘 표현된 전문가(Expert)의 도메인 내에 있을 때는 지시 준수 능력이 탁월하지만, 도메인과 작업이 교차하는 지점에서는 간혹 일관성이 결여되는 모습이 나타납니다. 이는 다단계 작업의 서로 다른 부분에 대해 서로 다른 전문가들이 활성화되었기 때문일 가능성이 높습니다. 256K 컨텍스트 윈도우는 행동을 사전에 제약할 수 있는 더 광범위한 시스템 프롬프트(System prompt)를 허용함으로써 이 문제를 유의미하게 도와줍니다.

**31B Dense**는 이 제품군에서 가장 일관된 지시 준수 모델입니다. 단일 아키텍처 설계 덕분에 전문가 라우팅(Expert routing)의 모호함이 없습니다. arXiv:2604.07035 연구에 따르면, 31B Dense는 테스트된 모든 사고 사슬 (Chain-of-thought) 프롬프팅 전략에서 정밀한 형식 준수를 요구하는 구조화된 출력 작업에 대해 가장 높은 점수를 기록했습니다.

우승자: 31B Dense
최고의 가성비: E4B (자원 비용의 극히 일부만 사용하면서도 뛰어난 준수 능력 보유)

2️⃣ 추론 능력 (Reasoning Capability): 커뮤니티를 놀라게 한 벤치마크

측정 항목: 수학적 추론 (Mathematical reasoning), 논리적 추론 (Logical inference), 다단계 문제 분해 (Multi-step problem decomposition), 사고의 사슬 (Chain-of-thought) 품질, 그리고 경진대회급 추론 벤치마크 성능.

평가

이 지점은 Gemma 4의 벤치마크 수치가 오픈 소스 AI 커뮤니티에서 진정한 논의의 주제가 된 부분입니다.

주요 수치 (공식 모델 카드 및 커뮤니티 검증 자료 기준):

31B 모델의 Arena AI ELO 점수인 1452점은 모든 모델(오픈 및 폐쇄형 모델 포함) 중 텍스트 리더보드에서 Qwen 3.5 27B (1403)와 DeepSeek-V3.2 (~1425)를 앞질러 3위를 차지했습니다. 26B MoE는 1441점으로 6위에 올랐습니다. 두 모델 모두 평가 커뮤니티의 언어로 표현하자면 "불가능해 보이는" 파라미터 효율성으로 이 성과를 달성했습니다.

주의 깊게 살펴볼 만한 arXiv:2604.07035의 연구 결과:

Few-shot 사고의 사슬 (Chain-of-thought, CoT) 프롬프팅 환경에서, E4B는 ARC-Challenge, GSM8K, Math Level 1–3에 걸쳐 0.675의 가중 정확도 (Weighted accuracy)를 달성했습니다. 이는 동일한 벤치마크 제품군에서 26B MoE가 기록한 0.663을 근소하게 앞서는 수치이며, VRAM 사용량은 48.1 GB 대비 단 14.9 GB에 불과합니다. 이는 매우 놀라운 결과입니다. 특정 작업 유형에서는 E4B 아키텍처의 효율성이 MoE 라우터 (Router)의 작업 라우팅보다 실제로 더 나은 결과를 만들어낼 수도 있습니다.

나의 해석: E4B는 과소평가된 추론 모델입니다. 대부분의 실무자들은 "진지한" 추론 작업을 위해 즉시 26B MoE로 넘어갑니다. 하지만 구조화된 수학 및 논리 문제의 경우, Few-shot CoT 프롬프팅을 사용하는 E4B는 하드웨어 비용의 극히 일부만 사용하면서도 놀라울 정도로 경쟁력이 있습니다.

우승자: 31B Dense (근소한 차이, AIME 2026 기준 ~89.2% vs 88.3%)
최고의 놀라움: E4B (Few-shot CoT 환경에서 0.675의 가중 멀티태스크 성능)

3️⃣ 코딩 능력 (Coding Ability): 명성이라는 천장이 드러나는 지점

측정 항목: 사양 기반 코드 생성 (Code generation from spec), 디버깅 (Debugging), 리팩토링 (Refactoring), 다중 파일 작업 완료 (Multi-file task completion), 그리고 에이전트 코딩 (Agentic coding) 벤치마크.

평가

코딩은 Gemma 4의 가장 강력한 모델들이 가장 명확한 경쟁적 한계(Competitive ceiling)에 직면하는 차원입니다.

주요 수치:

참고용: GLM-5.1은 SWE-bench Verified에서 78%에 도달하며, Claude Opus 4.7은 87.6%에 도달합니다. Gemma 4 31B의 ~64%는 "개별 함수 및 중간 정도의 작업에는 강력하지만, 복잡한 다중 파일 에이전트 코딩을 위한 현재의 프런티어(Frontier) 수준에는 미치지 못하는" 카테고리에 확고히 자리 잡고 있습니다.

로컬 배포 시 주목할 점: M4 Pro MacBook에서 Ollama를 통해 초당 57 토큰(tokens/second)으로 실행되는 E4B는 커뮤니티 테스트에서 작동 가능한 풀스택 React 애플리케이션을 생성했습니다. 이는 표준화된 벤치마크가 아닌 질적인 주장(Qualitative claim)이지만, 그 함의는 상당합니다. 즉, 중간 정도의 복잡성을 가진 애플리케이션 스캐폴딩(Scaffolding)의 경우, E4B의 속도 우위가 실제 사용 시 품질 격차를 보완해 준다는 것입니다.

함수 호출 (Function calling): 중요한 비대칭성. 오직 31B Dense 모델만이 신뢰할 수 있는 구조화된 함수 호출 (Structured function calling)을 지원합니다. 26B MoE는 지원이 제한적입니다. E2B와 E4B는 도구 사용 (Tool use)을 안정적으로 지원하지 않습니다. 도구 오케스트레이션 (Tool orchestration)이 필요한 모든 에이전트 애플리케이션에서 이는 선호의 문제가 아니라 엄격한 제약 조건 (Hard constraint)입니다.

승자: 31B Dense (품질 + 함수 호출)
실용적 로컬 모델: E4B (속도 + 대부분의 작업에 충분한 품질)
에이전트 코딩용으로 사용 금지: E2B, E4B (신뢰할 수 있는 도구 호출 불가)

4️⃣ 환각 저항성 (Hallucination Resistance): 아무도 광고하지 않는 지표

측정 항목: 사실적 정확성 (Factual accuracy), 존재하지 않는 정보에 대한 자신감 있는 날조 (Confident confabulation), 인용 조작 (Citation fabrication), 그리고 TruthfulQA 성능.

평가

이것은 Gemma 4에 대해 공개적으로 사용 가능한 통제된 데이터 (controlled data)가 가장 적은 차원이며, 그 자체로 주목할 만한 신호입니다. Google의 공식 모델 카드 (model card)에는 Gemma 4 제품군 전체에 대한 TruthfulQA 점수가 게시되어 있지 않습니다.

arXiv:2604.07035 프리프린트 (preprint)에 따르면, 제로샷 프롬프팅 (zero-shot prompting) 하에서의 TruthfulQA MC1 결과는 다음과 같습니다:

• E2B: 0.423
• E4B: 0.461
• 26B MoE: 0.498
• 31B Dense: 0.512 (추론됨)

이 수치들은 인상적인 절대 점수는 아닙니다. TruthfulQA는 까다롭기로 악명이 높으며, 특히 MC1 지표는 매우 엄격합니다. 하지만 상대적인 순위는 일관적입니다. 파라미터 (parameters) 수가 많을수록 더 나은 사실적 보정 (factual calibration)과 상관관계가 있으며, 퓨샷 CoT (few-shot CoT) 프롬프팅은 이 지표에서 모든 모델의 성능을 실질적으로 향상시킵니다.

주목할 만한 패턴: 26B MoE는 전문가 라우팅 (expert routing)과 연관된 것으로 보이는 사실적 회상 (factual recall)의 간헐적인 불일치를 보여줍니다. 즉, 특정 전문가를 활성화하는 사실적 주장은 올바르게 답변되지만, 라우팅이 다르게 되는 의미론적으로 유사한 질문은 환각 (confabulation)을 생성합니다. 이는 1세대 MoE 모델의 알려진 실패 모드 (failure mode)이며, 현재 커뮤니티에서 활발히 조사 중인 사안입니다.