Gemma 4 12B: 16GB 노트북에서 실행 가능한 인코더 프리 (Encoder-Free) 코딩

📖 차트와 임베디드 소스가 포함된 전체 버전을 ComputeLeap에서 읽어보세요 →

Google은 단 하나의 인코더 (Encoder) 없이도 텍스트, 이미지, 오디오 및 비디오를 처리할 수 있는 120억 파라미터 (12-billion-parameter) 모델을 막 출시했습니다. 그리고 이 모델은 16GB VRAM을 탑재한 노트북에서도 실행됩니다.

Gemma 4 12B 출시 후 24시간 이내에 Hacker News 스레드는 1,018 포인트와 382개의 댓글을 기록했습니다. 최전선 (Frontier) ML 연구자들은 자신들이 매일 사용하는 로컬 코딩 모델을 공개적으로 교체하기 시작했습니다. 이는 무언가 변화했다는 강력한 신호입니다.

이 글은 단순히

1. 이미지를 48×48 픽셀 패치(patch)로 분할 (일반적인 16×16보다 크므로 이미지당 패치 수가 적음)
2. 각 패치를 단일 행렬 곱셈(matrix multiplication)을 통해 LLM의 3,840차원 은닉 공간(hidden space)으로 투영(project)
3. 학습 가능한 X/Y 좌표 행렬을 통해 공간 위치 임베딩(spatial position embeddings)을 추가
4. 정규화(normalize) 후 LLM 백본(backbone)으로 직접 전송

오디오는 훨씬 더 급진적인 처리를 거칩니다. 가공되지 않은 16kHz 파형(waveform)을 각각 640개의 진폭(amplitude) 값을 가진 40밀리초 프레임으로 분할한 다음, 텍스트 임베딩 공간으로 선형 투영(linearly projected)합니다. 그게 전부입니다. 컨포머 레이어(conformer layers)도, 음성 토크나이저(speech tokenizer)도 없습니다. 오디오는 이미 1차원 시퀀스(1D sequence)이기 때문에 기존의 회전 위치 임베딩(rotary position embeddings)이 시간적 순서(temporal sequencing)를 처리합니다.

ℹ️
인코더 프리(encoder-free) 설계는 단순히 효율성만을 위한 것이 아닙니다. Google의 발표에서 언급했듯이, 이 설계는 LLM이 "입력 처리를 더 일찍 시작할 수 있게" 해줍니다. 인코더 스택(encoder stack)을 기다릴 필요가 없기 때문에 임베딩이 모델에 더 빠르게 도달합니다. 도구 호출(tool calls)을 거치며 지연 시간(latency)이 누적되는 에이전트 워크플로우(agentic workflows)에서는 이 점이 매우 중요합니다.

벤치마크: 정직한 수치들

의견을 나누기 전에 점수부터 확인해 보겠습니다. 공식 모델 카드(official model card)에 따르면 다음과 같습니다:

벤치마크	Gemma 4 12B	Gemma 4 E4B	Gemma 3 27B
LiveCodeBench v6	72.0%	52.0%	29.1%
...

코딩 수치가 눈에 띕니다. Codeforces ELO 1659점은 "Candidate Master" 등급에 해당하며, 이는 대부분의 인간 프로그래밍 대회 참가자들이 정체기에 머무는 수준에서 경쟁하는 12B 모델임을 의미합니다. 72.0%의 LiveCodeBench 점수는 메모리 점유율이 절반 미만임에도 불구하고 26B MoE 변형 모델(77.1%)과 거의 맞먹는 수준입니다.

하지만 여기서 이야기가 흥미로워집니다. 여러분은 "]["Qwen 3.6이 모든 코딩 벤치마크에서 Gemma 4를 압도한다"]("(https://theplanettools.ai/blog/qwen-3-6-alibaba-beats-google-gemma-4-coding-benchmarks-2026)라는 제목의 기사들을 보게 될 것이며, 그 말은 사실입니다. HumanEval (94.8% vs 92.1%), MBPP (93.1% vs 90.3%), 그리고 SWE-Bench Verified (68.2% vs 61.4%)에서 Qwen 3.6이 승리합니다.

함정은 무엇일까요? 그 비교는 Gemma의 12B 모델이 아니라, Qwen의 72B dense flagship (밀집 플래그십) 모델을 Gemma의 31B 변형 모델과 비교한 것입니다. 파라미터 수(parameter counts)가 일치하지도 않습니다.

개발자들이 실제로 소유하고 있는 실제 하드웨어에서는 비교 결과가 달라집니다. HN 사용자 dirkg는 Qwen 3.6 35B-A3B가 "코딩, 특히 에이전트 기반 코딩 (agentic coding)에 훨씬 더 낫다"라고 언급했지만, 이는 더 많은 VRAM을 요구하며 하이엔드 하드웨어에서 50-60 tok/sec로 작동합니다. 반면 12B 모델은 16GB 노트북에서 실행됩니다. 시장 자체가 다릅니다.

⚠️
"최고의" 로컬 코딩 모델은 여러분의 하드웨어에 달려 있습니다. 만약 48GB 이상의 VRAM을 보유하고 있다면, Qwen 3.6 35B-A3B 또는 Gemma 4 31B가 12B 모델보다 뛰어난 성능을 보여줄 것입니다. 12B 모델의 가치 제안 (value proposition)은 메모리의 33%만 사용하면서 업무의 72%를 수행하며, 그 과정에서 이미지와 오디오를 네이티브하게 처리한다는 점에 있습니다.

실제로 승리하는 지점: 무질서한 작업 (Messy Tasks)

구조화된 벤치마크 이야기는 Qwen에게 유리합니다. 하지만 실제 환경 테스트는 다른 이야기를 들려줍니다.

Terraform 프로바이더 업데이트 작업 — 즉, 진화하는 문서에서 오래된 API 참조를 식별하는 작업 — 에서 Gemma 4는 92%의 정확도를 기록한 반면, Qwen 3.6은 78%를 기록했습니다. 일본어 의료 텍스트 처리에서 Gemma 4는 GPT-4.1 성능의 97.8%를 달성했습니다. 이러한 격차는 "무질서한 (messy)" 작업에서 더 벌어집니다. 분기마다 변경되는 API, 일관성 없는 명명 규칙을 가진 코드베이스, 코드보다 뒤처지는 문서 등이 이에 해당합니다. 이것들이 바로 개발자들이 매일 실제로 직면하는 작업들입니다.

HN 사용자 senko는 자신의 개인적인 "지뢰찾기 (minesweeper)" 코딩 벤치마크를 통해 Q4 양자화 (quantized) 버전을 실행했으며, 약간의 구문 오류(추가된 대괄호 및 괄호)는 있었으나 논리는 정확하여 "GPT-4.1과 대략적으로 비교할 만하다"고 보고했습니다. 12GB VRAM 그래픽 카드에서 초당 5개 토큰 (5 tokens per second)의 속도로 작동했습니다.

또 다른 HN 댓글 작성자인 ricardobayes는 주관적 테스트 결과 12B 모델이 코딩 측면에서 Qwen 3.5 9B보다 "심지어 더 나아 보인다"고 발견했습니다. 이는 9~12B 파라미터 체급 내에서 Gemma 4가 코딩의 왕좌를 차지할 수도 있음을 시사합니다. 0xbadcafebee의 반론도 주목할 만합니다. 12B는 코딩을 위해 특별히 "훈련되지 않았으며", Gemma 4 31B가 "소형 모델 코딩 분야의 최고 (top dog)"라는 것입니다. 일리 있는 지적이지만, 31B 모델은 48GB 이상의 RAM이 필요합니다.

다음으로는 "사고 모드 (thinking mode)" 차원이 있습니다. Gemma 4 12B는 설정 가능한 확장 사고 (extended thinking) 기능을 탑재하고 있습니다. enable_thinking=True로 설정하면 모델은 텍스트를 생성하기 전에 추론 예산 (reasoning budget)을 할당합니다. 사고의 사슬 (chain-of-thought)이 중요한 복잡한 다단계 코딩 문제의 경우, 이는 더 큰 모델들과의 격차를 줄여줍니다. 256K 토큰 컨텍스트 창 (context window)과 결합하면, 전체 코드베이스를 입력하고 추론 과정을 거친 답변을 얻을 수 있습니다.

패턴을 살펴보면 다음과 같습니다. 잘 정의된 클린룸 문제 (HumanEval, MBPP)에서는 Qwen의 전용 코딩 훈련이 효과를 발휘합니다. 반면, 진화하는 API와 혼합된 입력값이 존재하는 지저분한 실제 작업에서는 Gemma 4의 광범위한 훈련이 빛을 발합니다. 이는 Gemma 제품군의 범용적 설계 철학과 일치합니다. Google은 코딩 전문가를 만든 것이 아니라, 코딩을 잘하는 범용 모델 (generalist)을 만든 것입니다.

연구자의 신호 (The Researcher Signal)

Bijan Bowen이 자신의 YouTube 리뷰 제목을 "Gemma 4 12B는 미쳤다 — 이것이 현재 최고의 로컬 코딩 모델인가?"라고 지었을 때, 그것은 하나의 데이터 포인트가 됩니다. @mervenoyann과 같은 최전선 연구자들이 일상적인 로컬 코딩 모델로 Qwen 3.6 35B에서 Gemma 12B bf16으로 공개적으로 전환할 때, 그것은 하나의 신호가 됩니다.

이러한 변화는 벤치마크에 관한 것이 아니라 워크플로 (workflow)에 관한 것입니다. Gemma 4 12B는 텍스트, 비전 (vision), 오디오 (audio)를 모두 수행하는 단일 모델입니다. 인코더 (encoder)를 교체하거나 파이프라인 (pipeline)을 이어 붙일 필요가 없습니다. 모델이 스크린샷을 읽고, 에러 로그 (error log)를 해석하며, 하나의 컨텍스트 (context) 안에서 수정 사항을 생성해야 하는 에이전틱 코딩 워크플로 (agentic coding workflows)의 경우, 이러한 통합된 아키텍처 (architecture)는 임시방편적인 결합 (duct tape)을 제거해 줍니다.

실제적인 에이전틱 시나리오를 생각해 보십시오: 여러분의 코딩 에이전트가 UI 버그를 발견했습니다. 전통적인 설정에서는 스크린샷을 처리할 비전 모델 (vision model), 수정 사항을 추론할 텍스트 모델 (text model), 그리고 이들을 연결하는 글루 코드 (glue code)가 필요했을 것입니다. Gemma 4 12B를 사용하면 단일 모델이 단 한 번의 포워드 패스 (forward pass)로 스크린샷과 코드 생성을 모두 처리합니다. Google Developers guide에서는 이 점을 명시적으로 강조합니다: 이 모델은 에이전틱 워크플로를 위한 네이티브 함수 호출 (native function calling)을 지원하며, 스킬 저장소 (skills repository)와 함께 제공됩니다. Ollama, LM Studio, vLLM, llama.cpp와 같은 프레임워크 (frameworks)와 결합하면 로컬 에이전틱 스택 (local agentic stack)으로의 배포가 매우 간단합니다.

Google은 또한 지연 시간 (latency)을 줄이기 위해 **멀티 토큰 예측 (Multi-Token Prediction, MTP) 드래프터 (drafters)**를 추가했습니다. 이 모델은 단일 단계에서 여러 개의 토큰을 미리 예측하며, 이는 보일러플레이트 (boilerplate) 패턴이 예측 가능한 코드 생성 작업에서 특히 유용합니다. 반복적인 구조(import 블록, 함수 시그니처, 테스트 스캐폴딩)를 가진 코딩 작업에서 MTP는 생성 속도를 측정 가능한 수준으로 높여줄 수 있습니다.

그리고 덜 논의되는 장점도 있습니다: 미세 조정 (Fine-tuning)의 단순함입니다. 함께 공동 튜닝(Co-tune)해야 할 별도의 고정된 인코더 (Frozen encoders)가 없기 때문에, 개발자는 단 한 번의 패스로 전체 미세 조정 (Full fine-tuning) 또는 어댑터 기반 미세 조정 (Adapter-based fine-tuning)을 수행할 수 있습니다. 모델 카드 (Model card)는 효율적인 적응을 위한 Unsloth 지원을 확인해 줍니다. 이는 도메인 특화 코딩 어시스턴트를 구축하는 팀에게 매우 중요합니다. 인코더와 디코더를 별도로 정렬하는 복잡함 없이, 여러분의 코드베이스 컨벤션, API 패턴, 스타일 가이드에 맞춰 미세 조정을 할 수 있습니다.

실행하기: 필요한 사항

12B 모델의 주요 사양은 다음과 같습니다:

사양	값
파라미터 (Parameters)	11.95B
...

이미 저희의 Gemma 4 + omlx 설정 가이드를 따라 하셨다면, 동일한 도구를 통해 12B 모델로 교체할 수 있습니다. Ollama와 LM Studio 모두 별도의 설정 없이 즉시 지원합니다. 전체 설정 단계별 안내는 저희의 AI 로컬 실행 가이드를 참조하세요.

특히 코딩 워크플로우의 경우: 함수 호출 (Function calling)을 지원하는 에이전트 프레임워크와 함께 사용하세요. 12B의 네이티브 도구 사용 (Tool-use) 지원은 이 모델이 코딩 에이전트 스택 (Coding agent stacks)의 로컬 모델 백엔드로 바로 들어갈 수 있음을 의미합니다. 이는 반복적인 코딩 작업에서 토큰당 발생하는 API 비용을 피하고 싶을 때 유용합니다.

Qwen과의 상세한 비교를 원하신다면, 저희가 LM Studio를 이용한 Qwen 3.6-35B 설정을 다루었습니다. 두 모델을 모두 실행하여 실제 작업에서 벤치마크를 수행하고, 타인의 리더보드가 아닌 여러분의 하드웨어와 워크플로우에 기반하여 결정하십시오.

하드웨어 현실 점검