이 글은 Gemma 4 챌린지(Gemma 4 Challenge: Write About Gemma 4)를 위한 제출물입니다.

2026년의 모든 오픈 웨이트 (open-weight) 모델 출시는 벤치마크 표와 효율성에 대한 주장을 동반합니다. 대부분은 점진적인 개선에 불과합니다. 하지만 Gemma 4에는 그렇지 않은 수치가 하나 있습니다. 바로 에이전트적 도구 사용 (agentic tool use)에서 보여준 6.6%에서 86.4% 사이의 수치입니다. 이것은 단순한 개선이 아닙니다. 카테고리의 변화입니다.

실제로 중요한 수치
Google DeepMind가 2026년 4월 2일에 Gemma 4를 출시했을 때, 언론 보도는 AIME 2026, LiveCodeBench, Arena AI 순위와 같은 헤드라인 점수에 집중되었습니다. 그 수치들은 인상적입니다. 31B 밀집 (dense) 모델은 AIME에서 89.2%(Gemma 3 27B의 20.8%에서 상승), LiveCodeBench에서 80%(29.1%에서 상승)를 기록했으며, Arena AI의 모든 오픈 모델 중 3위를 차지했습니다.

하지만 개발자들이 무엇을 만들 수 있는지를 실제로 바꾸는 벤치마크는 τ2-bench입니다. 이는 모델이 실제 도구 스키마 (tool schemas), 불완전한 정보, 그리고 정책 제약 조건(policy constraints) 전반에 걸쳐 다단계 작업 (multi-step tasks)을 신뢰성 있게 실행할 수 있는지를 측정하는 에이전트적 도구 사용 (agentic tool use) 평가입니다. Gemma 3 27B는 τ2-bench Retail에서 6.6%를 기록했습니다. Gemma 4 31B는 86.4%를 기록했습니다. 이를 구체적으로 설명하면 다음과 같습니다: Gemma 3는 구조화된 도구 사용 (structured tool use)에서 100번 중 93번을 실패했습니다. Gemma 4는 100번 중 약 14번을 실패합니다. 에이전트를 구축하는 사람들에게 이 둘은 같은 클래스의 모델이 아닙니다.

26B MoE (Mixture of Experts) 변형 모델은 순전파 (forward pass)당 260억 개의 파라미터 중 38억 개만을 활성화하면서 동일한 벤치마크에서 85.5%를 기록합니다. 추론 비용 (inference cost)의 극히 일부만 사용하면서 플래그십에 근접한 에이전트 능력을 얻을 수 있습니다.

아키텍처 측면에서 무엇이 변했는가
τ2-bench의 도약은 Google이 더 큰 모델을 만들었기 때문에 발생한 것이 아닙니다. Gemma 4 31B는 Gemma 3 27B와 거의 동일한 파라미터 수를 가지고 있습니다. 변한 것은 모델이 어떻게 훈련되었는지와 어떤 기능이 네이티브하게 내장되었는지입니다. Gemma 4는 전용 제어 토큰 (control tokens)을 통한 네이티브 함수 호출 (native function calling) 기능을 탑재하고 있습니다. 즉, 구조화된 도구 사용 (structured tool use)이 프롬프트 엔지니어링 (prompt engineering)을 통해 덧붙여진 것이 아니라 모델의 어휘 (vocabulary) 자체에 내장되어 있습니다.

이 모델에는 설정 가능한 사고 모드 (thinking modes)가 있어, 도구 호출 (tool call)을 확정하기 전에 모델이 4,000개 이상의 토큰에 달하는 단계별 추론 (step-by-step reasoning)을 생성할 수 있으며, 이는 복잡한 다단계 파이프라인 (multi-step pipelines)에서의 정확도를 직접적으로 향상시킵니다. 또한 네이티브 시스템 프롬프트 (native system prompt) 지원을 통해, 별도의 우회 방법 없이도 시스템 턴 (system turn)에서 에이전트 행동 (agent behavior), 도구 스키마 (tool schemas), 제약 조건 (constraints)을 정의할 수 있습니다. 이 아키텍처는 Google의 폐쇄형 프런티어 (closed frontier) 모델 제품군인 Gemini 3와 동일한 연구 스택에서 파생되었습니다. 이러한 지식 전이 (knowledge transfer)는 벤치마크 격차에서 명확히 드러나는데, 특히 다회차 계획 (multi-turn planning)과 정책 준수 도구 실행 (policy-compliant tool execution)이 필요한 작업에서 두드러지며, 이는 정확히 $\tau_2$-bench 테스트 조건과 일치합니다. 26B MoE (Mixture-of-Experts) 모델에 대한 한 가지 중요한 하드웨어 주의 사항은, 생성 과정 중 토큰당 3.8B 파라미터만 활성화되지만, 라우팅 (routing)을 위해 260억 개의 모든 파라미터가 메모리에 로드되어야 한다는 점입니다. 따라서 메모리 점유율 (memory footprint)은 4B 모델이 아닌, 26B 밀집 (dense) 모델에 가깝습니다. 속도 이점은 확실합니다. MoE는 소비자용 GPU에서 초당 40개 이상의 토큰을 생성하는 반면, 31B 밀집 모델은 10개 미만입니다. 하지만 소형 모델처럼 작동할 것이라고 가정하기 전에 VRAM 용량을 그에 맞춰 산정해야 합니다.

에이전트를 구축하는 개발자들에게 이것이 중요한 이유

Gemma 4 이전에는 "내 에이전트에 로컬 오픈 모델을 사용해야 할까?"라는 질문에 대한 솔직한 답변은 대개 '아니오'였습니다. 적어도 도구 호출의 신뢰성이 중요한 작업에서는 말입니다. 구조화된 도구 사용 (structured tool use)의 성공률이 6.6%라는 것은, 에이전트가 함수를 호출하거나, 스키마를 확인하거나, 도구 출력을 체이닝 (chaining)해야 할 때마다 거의 매번 실패한다는 것을 의미합니다. 이는 프로덕션 (production) 환경에서 무엇인가를 구축하기 위한 토대가 될 수 없습니다. 하지만 86.4%라는 수치는 계산을 완전히 바꿉니다. GPT-5.4와 같은 프런티어 폐쇄형 모델과 대등한 수준은 아닙니다. 복잡한 다단계 벤치마크에서는 여전히 GPT-5.4가 앞서고 있습니다. 하지만 개발자가 로컬에서 실제 에이전트 워크플로우 (agentic workflows)를 구축하고, 재시도 (retries) 및 오류 처리 (error handling)를 통해 엣지 케이스 (edge cases)를 포착하며, 실제로 작동하는 결과물을 출시할 수 있는 범위 내에 들어왔습니다. 이제 실패 모드 (failure modes)는 근본적인 문제가 아니라 관리 가능한 수준이 되었습니다. 이는 이전에는 실질적으로 로컬 모델을 사용할 수 없었던 세 가지 배포 컨텍스트 (deployment contexts)에서 특히 중요합니다.

개인정보에 민감한 에이전트적 애플리케이션 (Privacy-sensitive agentic applications). 의료 도구, 법률 검토 파이프라인, 금융 컴플라이언스 에이전트 등 원시 쿼리 데이터 (raw query data)가 기기를 떠날 수 없는 모든 워크플로우가 이에 해당합니다. Gemma 4의 네이티브 함수 호출 (native function calling) 기능이 로컬에서 실행된다는 것은 모델이 기기 내부에서 어떤 도구를 호출할지 결정하며, 오직 구조화된 API 요청만이 네트워크를 통해 전송됨을 의미합니다. 사용자의 프롬프트 (prompt), 컨텍스트 (context), 그리고 중간 추론 과정 (intermediate reasoning)은 로컬에 머무릅니다.

비용 제어가 가능한 프로덕션 에이전트 (Cost-controlled production agents). 각 작업이 5~20회의 도구 호출을 트리거하는 다단계 에이전트 워크플로우 (multi-step agentic workflows)에서는 토큰당 API 비용이 빠르게 누적됩니다. Gemma 4 26B MoE를 소비자용 GPU에서 로컬로 실행하면 이러한 변수를 완전히 제거할 수 있습니다. 26B MoE의 추론 속도 (RTX 4090 기준 40+ tokens/sec)는 이 정도 성능을 가진 모델에서 예상되는 지연 시간 (latency) 페널티 없이 실시간 에이전트 루프 (agentic loops)를 수행하기에 충분히 빠릅니다.

MCP 통합 로컬 파이프라인 (MCP-integrated local pipelines). Gemma 4의 네이티브 함수 호출은 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP) 도구 스키마 (tool schemas)에 직접 매핑됩니다. 설정 방법은 간단합니다. llama.cpp 또는 vLLM을 통해 OpenAI 호환 엔드포인트 (OpenAI-compatible endpoint)로 Gemma 4를 실행하고, MCP 클라이언트를 해당 엔드포인트로 지정하면 모델이 도구 선택 및 호출 생성을 로컬에서 처리합니다. 이전에는 클라우드 모델 API가 필요했던 작업들을 이제는 호출당 비용 없이, 데이터가 서버를 떠나지 않는 자체 인프라에서 실행할 수 있습니다.

에이전트 작업을 위한 적절한 모델 선택하기 (Picking the Right Model for Agentic Work). Gemma 4는 네 가지 모델 제품군으로 제공되며, 에이전트 배포를 위한 최선의 선택이 반드시 가장 큰 모델인 것은 아닙니다. 31B 밀집 모델 (dense model)은 정확도의 한계치 (accuracy ceiling)입니다. 가장 높은 $\tau_2$-bench 점수, 복잡한 다단계 작업에 대한 최고의 추론 능력, 그리고 가장 강력한 미세 조정 (fine-tuning) 기반을 갖추고 있습니다. 이 모델은 단일 80GB H100에서 양자화되지 않은 상태(unquantized)로 실행 가능하며, 24GB 이상의 VRAM을 가진 소비자용 GPU에서는 양자화된 상태 (Q4_K_M)로 실행할 수 있습니다. 품질이 제약 사항이고 하드웨어가 충분한 서버 측 에이전트를 구축 중이라면 여기서부터 시작하십시오. 26B MoE는 대부분의 에이전트 배포를 위한 실용적인 프로덕션 선택지입니다.

τ2-bench에서의 85.5% 점수는 31B 모델과 매우 근접하여, 그 트레이드오프 (tradeoff)가 거의 항상 가치가 있습니다. 즉, 4배 더 빠른 토큰 생성 (token generation), 추론 (inference) 중 더 낮은 GPU 메모리 압박, 그리고 동일한 256K 컨텍스트 윈도우 (context window)를 제공합니다. 연속적인 루프를 실행하거나 높은 요청 볼륨을 처리하는 에이전트 (agents)의 경우, 이러한 속도 차이는 상당한 복리 효과를 가져옵니다. E4B (4B 엣지 모델)는 LiveCodeBench에서 52%를 기록하며 네이티브 오디오 입력 (native audio input)을 지원합니다. 이는 제품군 중 음성을 네이티브로 처리하는 유일한 모델입니다. 음성 입력이 필요한 온디바이스 (on-device) Android 에이전트나 모바일 우선의 에이전트적 워크플로우 (agentic workflows)를 구축하고 있다면, 이것이 바로 당신을 위한 모델입니다. 에이전트적 도구 사용 (agentic tool use) 점수는 더 낮지만, 타겟 하드웨어가 완전히 다릅니다. 이 모델은 휴대폰에서 실행됩니다. E2B (2B 엣지 모델)는 Raspberry Pi 5 CPU에서 초당 133개의 프리필 토큰 (prefill tokens/sec)에 도달합니다. IoT 에이전트, 오프라인 우선 배포, 또는 1.5GB 미만의 RAM으로 제한된 환경을 위한 모든 용도에서, 이 모델은 이 제품군 내 유일하게 실행 가능한 옵션이며 여전히 멀티모달 (multimodal) 입력을 처리할 수 있습니다.

Apache 2.0 라이선스는 사소한 디테일이 아닙니다. 이전의 모든 Gemma 릴리스는 Google의 독점 라이선스 (proprietary license) 하에 배포되었습니다. Gemma 4는 Apache 2.0 하에 출시된 첫 번째 모델입니다. 특히 에이전트형 AI (agentic AI)의 경우, 이는 일반적인 언어 모델 사용보다 더 중요합니다. 에이전트는 제품에 내장됩니다. 독점 데이터로 미세 조정 (fine-tuned)됩니다. 고객이 비용을 지불하는 상업적 서비스로 래핑 (wrapped)됩니다. 이 모든 과정은 이전 Gemma 라이선스 하에서는 법적 검토와 협상이 필요했습니다. Apache 2.0 하에서는 Google의 약관을 먼저 승인받을 필요 없이 구축, 배포, 미세 조정 및 상업화가 가능합니다. 오픈 웨이트 (open-weight) 모델을 기반으로 구축하는 스타트업과 개인 개발자들에게, 모델이 실제로 프로덕션에 배포될 수 있을 만큼 충분히 유능해진 바로 이 시점에 이는 법적 고민을 하나 줄여주는 요소입니다.

시작하기

Ollama로 가져오기 - 실행 가능한 모델로 가는 가장 빠른 경로

ollama pull gemma4:31b
ollama pull gemma4:26b-moe

또는 Hugging Face를 통해

pip install transformers

Google AI Studio에서는 로컬 설정 없이 브라우저 내에서 31B 및 26B MoE를 사용할 수 있습니다.

Google AI Edge Gallery는 온디바이스 (on-device) 테스트를 위해 E4B 및 E2B 모델을 지원합니다. 출시 시점의 전체 프레임워크 지원 목록에는 Hugging Face Transformers, vLLM, llama.cpp, MLX, NVIDIA NIM, SGLang, Ollama, LM Studio 등이 포함됩니다. MCP (Model Context Protocol) 통합을 위해, gemma-mcp 패키지는 로컬에서 서비스되는 Gemma 4 엔드포인트에 대한 클라이언트 설정을 처리합니다. Apple Silicon에서 Ollama를 통해 26B MoE를 실행하는 경우 한 가지 실질적인 주의 사항이 있습니다. v0.20.3 기준으로, 도구 호출 (tool-call) 응답을 잘못된 필드로 라우팅하는 알려진 스트리밍 버그가 있습니다. 에이전트적 (agentic) 맥락에서 배포하기 전에는 llama.cpp를 직접 사용하거나 Ollama의 수정 버전을 기다리십시오.

솔직한 주의 사항: τ2-bench Retail에서의 86.4%는 100%가 아닙니다. 도구 호출이 10~20단계에 걸쳐 체인(chain)으로 연결되는 에이전트 파이프라인에서는, 호출당 14%의 실패율이 복리로 누적됩니다. 프로덕션 배포에는 재시도 로직 (retry logic), 에러 핸들링 (error handling), 그리고 도구 출력 사이의 검증 레이어 (validation layers)가 필요합니다. 이는 결함 모드 (failure modes)가 존재하는 모든 분산 시스템에 적용되는 것과 동일한 엔지니어링 규율입니다. Gemma 4가 방어적 에이전트 아키텍처 (defensive agent architecture)의 필요성을 없애주는 것은 아닙니다. 다만 아키텍처를 구축할 가치가 있을 만큼 실패율을 관리 가능한 수준으로 만들어 줄 뿐입니다. 이것이 진정한 변화입니다. 로컬 오픈 모델이 이제 에이전트 작업에 완벽해졌다는 것이 아니라,