Google DeepMind는 이번 주 Gemma 4 기술 보고서(technical report)를 발표했습니다. 이를 쉽게 읽자면 다음과 같습니다: 또 다른 오픈 웨이트 (open-weight) 모델 제품군, 또 다른 리더보드 (leaderboard) 표, 그리고 또 다른 성능 주장들입니다.

저는 이것이 유용한 부분을 놓치고 있다고 생각합니다.

Gemma 4에서 중요한 점은 31B 모델이 인간 선호도 평가 (human preference evals)에서 높은 점수를 받는다는 것이 아닙니다. 물론 점수는 높습니다. 보고서에 따르면 Gemma 4 31B는 6월 19일 기준 Arena Text에서 선두를 달리는 밀집형 오픈 모델 (dense open model)이며, 벤치마크 (benchmark) 표에는 평소처럼 강력한 수치들이 적혀 있습니다: MMLU Pro에서 85.2, 도구 없는 AIME 2026에서 89.2, LiveCodeBench v6에서 80.0입니다.

좋습니다. 벤치마크는 유용합니다. 하지만 그것은 개발자들이 가장 먼저 체감하게 될 이야기는 아닙니다.

진정한 이야기는 Google이 유능한 멀티모달 (multimodal) 모델을 사람들이 이미 소유하고 있는 하드웨어로 밀어 넣고 있다는 점입니다. 12B 모델이 그 증거입니다. Google의 자체적인 6월 업데이트에 따르면, Gemma 4 12B는 비전 (vision) 및 네이티브 음성 처리 (native voice processing) 기능을 갖추고 16GB 메모리에서 실행되는 로컬 모델 (local model)로 설명됩니다. 기술 보고서는 그 이유를 설명합니다: 12B 변체는 별도의 비전 및 오디오 인코더 (encoders)를 버리고, 가공되지 않은 이미지 패치 (image patches)와 40ms 오디오 청크 (audio chunks)를 모델의 임베딩 공간 (embedding space)으로 직접 투영합니다.

이것은 단순한 아키텍처 (architecture) 세부 사항처럼 보일 수 있지만, 실제로는 제품의 방향성입니다.

메모리가 제품의 제약 조건이다

대부분의 AI 출시 보도는 여전히 성능을 점수판으로 취급합니다. 더 큰 모델, 더 어려운 평가, 더 높은 Elo 점수. 이러한 프레임워크는 사용자가 주로 텍스트 박스와 인보이스 (invoice)만을 접하게 되는 프런티어 API (frontier APIs)의 경우에는 타당합니다.

로컬 모델 (Local models)은 다른 병목 현상 (bottleneck)을 가집니다. 이들은 메모리에 먼저 부딪힙니다.

"거의 비슷하게 좋은" 성능을 내더라도 클라우드 GPU가 필요하다면, 실질적인 의미에서 로컬 모델이라고 할 수 없습니다. 그것은 단지 라이선스가 조금 더 나은 또 다른 원격 의존성 (remote dependency)일 뿐입니다. 로컬 에이전트 (local agents), 문서 워크플로 (document workflows), 개인 비서, 그리고 오프라인 코딩 도우미에게 유용한 질문은 더 간단합니다: 이 모델이 작업이 이미 일어나고 있는 곳에서 실행될 수 있는가?

Gemma 4는 바로 그 질문을 중심으로 설계되었습니다. 이 제품군은 E2B, E4B, 12B, 26B-A4B MoE, 그리고 31B로 구성됩니다. 보고서에는 2.3B, 4.5B, 12B, 31B 파라미터(parameters)를 가진 밀집 모델(dense models)과, 활성 파라미터(active parameters)가 3.8B인 총 26B 규모의 전문가 혼합(Mixture-of-Experts, MoE) 모델이 나열되어 있습니다. Hugging Face의 모델 카드(model cards)에 따르면, 작은 모델들은 128K 컨텍스트(context)를, 중간 크기 모델들은 256K 컨텍스트를 지원합니다.

그다음 보고서는 출시 당시 헤드라인을 장식하는 일은 드물지만 매우 중요한 세부 사항들에 많은 시간을 할애합니다: KV 캐시 공유(KV cache sharing), 로컬-글로벌 어텐션 비율(local-to-global attention ratios), 양자화 인식 학습(quantization-aware training), 그리고 투기적 디코딩(speculative decoding)을 위한 멀티 토큰 예측 드래프터(multi-token prediction drafter) 등이 그것입니다.

바로 이 지점이 실질적인 보상이 발생하는 곳입니다. 화려하지는 않지만, 유용합니다.

32K 컨텍스트 기준, 보고서의 메모리 표에 따르면 순수 12B 텍스트 전용 체크포인트(checkpoint)는 bf16에서 24GB이며, Q4_0 양자화(quantized) 버전은 7.65GB입니다(해당 설정에 대한 작은 KV 캐시 용량 별도). 31B 모델은 순수 상태에서 64GB, 양자화 시 19.2GB입니다. 26B-A4B MoE 모델은 순수 상태에서 52GB, 또는 활성 상태에서 7.6GB이며, 양자화 시 16.2GB, 또는 활성 상태에서 2.8GB로 기재되어 있습니다.

이 수치들이 마법 같은 것은 아닙니다. 여전히 런타임(runtime), 컨텍스트 길이(context length), 모달리티 입력(modality inputs), 배치 처리(batching), 그리고 양자화로 인한 품질 저하를 고려해야 합니다. 하지만 이 수치들은 진정한 경쟁의 방향을 가리키고 있습니다. 그것은 "이 모델이 차트 하나에서 폐쇄형 모델(closed model)을 이기는가?"가 아니라, "이 모델이 전체 워크플로우를 인프라 문제로 변질시키지 않고 노트북이나 워크스테이션에 들어가는가?"입니다.

그것이 바로 제가 주목하고 싶은 부분입니다.

멀티모달(Multimodal)은 기반 시설(plumbing)이 되어가고 있다

12B 인코더 프리(encoder-free) 설계는 이 보고서에서 가장 흥미로운 승부수입니다.

대부분의 멀티모달 시스템은 언어 모델(language model)에 인코더(encoder)를 덧붙이는 방식을 사용합니다. 이미지는 비전 인코더(vision encoder)를 거치고, 오디오는 오디오 인코더(audio encoder)를 거칩니다. 언어 모델은 투영된 표현(projected representations)을 전달받아 세상이 토큰(tokens) 형태로 도착한 것처럼 행동합니다.

이 방식도 작동은 하지만, 구성 요소를 추가하고 메모리 압박을 가중시키며 배포 시 마찰을 일으킵니다. 추가되는 인코더가 하나씩 늘어날 때마다 로드해야 할 것, 양자화해야 할 것, 샤딩(shard)해야 할 것, 기기 간에 이동시켜야 할 것, 디버깅해야 할 것, 그리고 새벽 1시에 사용 중인 서빙 스택(serving stack)에 설명해야 할 것이 하나씩 더 늘어나는 셈입니다.

Gemma 4 12B는 그 과정을 단축합니다. 이미지의 경우, 48x48 RGB 패치(patches)를 가져오며 550M 비전 인코더(vision encoder) 대신 프로젝션 모듈(projection module)을 사용합니다. 오디오의 경우, 16kHz 오디오를 40ms 청크(chunks)로 분할하고 해당 벡터들을 LLM 임베딩 공간(embedding space)으로 직접 투영합니다. 논문에 따르면 이는 메모리 파편화(memory fragmentation)를 줄이고 별도의 인코더가 필요하지 않게 만듭니다.

그렇다고 해서 모든 모델이 내일 당장 인코더 프리(encoder-free)가 된다는 뜻은 아닙니다. 동결된 인코더(Frozen encoders)는 여전히 합리적인 엔지니어링 트레이드오프(tradeoff)이며, Gemma 4 제품군의 나머지 모델들은 여전히 이를 사용합니다. 하지만 방향성은 명확합니다. 멀티모달(multimodal) 지원이 데모 레이어(demo layer)에서 기본 배관(base plumbing) 단계로 이동하고 있습니다.

개발자들에게 이는 출시 영상보다 더 중요합니다. 스크린샷을 읽고, 짧은 오디오 노트를 듣고, 긴 로컬 문서를 바탕으로 추론할 수 있는 로컬 어시스턴트는, 세 개의 별도 서비스를 주변에 붙여야 하는 채팅 모델과는 차원이 다른 도구입니다.

단순한 버전이 실제 업무에 연결하기 더 쉽기 때문에 승리하는 것입니다.

사고 모드(Thinking mode)는 유용하지만, 이를 신뢰와 혼동하지 마세요

Gemma 4는 모델이 응답하기 전에 추론 흔적(reasoning trace)을 생성할 수 있는 사고 모드(thinking mode)를 추가했습니다. 벤치마크 성능 향상은 추론 비중이 높은 작업에서 가장 강력하게 나타납니다. 보고서에 따르면, Gemma 4 31B는 도구 없이 AIME 2026에서 89.2를 기록했으며, LiveCodeBench v6에서는 80.0을 기록했습니다. 12B 모델 또한 많은 추론 및 코딩 평가(evals)에서 Gemma 3 27B보다 훨씬 강력합니다.

이는 로컬 에이전트(local agents)에게 좋은 소식입니다. 에이전트에게 필요한 것은 단순히 더 유려한 문장이 아닙니다. 그들에게는 계획(planning), 수정(repair), 그리고 첫 번째 잘못된 가정 이후에 무너지지 않고 지저분한 작업을 끝까지 수행할 수 있는 충분한 인내심이 필요합니다.

하지만 "사고"가 검증(verification)을 대신할 수는 없습니다.

추론 흔적을 가진 로컬 모델은 더 검사 가능(inspectable)할 수 있습니다. 하지만 틀렸을 때 더 설득력 있게 보일 수도 있습니다. 만약 이를 코딩 워크플로우(coding flow)에서 사용하고 있다면, 가드레일(guardrail)은 여전히 똑같이 지루한 것들입니다: 테스트, 디프(diffs), 로그, 그리고 새로운 컨텍스트 윈도우(context window)를 통한 적대적 검토(adversarial review) 단계입니다. 추론 흔적은 검사해야 할 증거이지, 영수증이 아닙니다.

저는 Gemma 4가 추론 (reasoning) 능력을 오픈 웨이트 (open weights) 모델로 밀어붙이는 점이 마음에 듭니다. 저는 여전히 이 모델을 손은 빠르지만 자신감만 넘치는 주니어 개발자처럼 다룰 것입니다.

유용하긴 하지만, 절대적인 진실의 원천 (source of truth)은 아닙니다.

오픈 모델의 전쟁 양상이 변하고 있습니다

과거의 오픈 모델 논쟁은 주로 접근성 (access)에 관한 것이었습니다. 개발자들이 가중치 (weights)를 얻을 수 있느냐 없느냐의 문제였죠.

그 싸움이 끝난 것은 아니지만, 더 이상 유일한 싸움은 아닙니다. 다음 싸움은 배포 형태 (deployment shape)입니다.

라이선스 함정 없이 모델이 스마트폰, 노트북, 저가형 GPU 박스 또는 내부 서버에서 실행될 수 있는가? KV 캐시 (KV cache)가 폭발하지 않고 긴 컨텍스트 (long context)를 처리할 수 있는가? 별도의 사이드카 모델 (sidecar models) 더미 없이 비전 (vision)과 오디오 (audio)를 처리할 수 있는가? 양자화 (quantized) 버전이 사후 고려 사항이 아닌 기본값이 될 수 있는가?

Gemma 4가 강력한 이유는 이러한 질문들에 직접적으로 답하기 때문입니다. Apache 2.0 라이선스가 도움이 됩니다. 모델 크기도 도움이 됩니다. QAT (Quantization-Aware Training) 체크포인트도 도움이 됩니다. 긴 컨텍스트 (long-context) 작업도 도움이 됩니다. 보고서가 캐시 점유율 (cache footprint)과 메모리 파편화 (memory fragmentation)에 대해 논하고 있다는 사실은 단순한 각주가 아닙니다. 그것이 핵심입니다.

Google의 보고서 외에도 검증해야 할 사항은 여전히 많습니다. 독립적인 벤치마크 (benchmarks)가 중요합니다. 실제 서빙 (serving) 테스트가 더 중요합니다. 저는 지연 시간 (latency), 실패 모드 (failure modes), 도구 사용 (tool-use) 동작, 그리고 로컬 에이전트가 문서, 스크린샷, 오래된 컨텍스트가 쌓인 상태로 몇 시간 동안 실행될 때 12B 모델이 어떻게 작동하는지 보고 싶습니다.

하지만 출시 모델로서 Gemma 4는 유용한 신호입니다. Google은 단순히 가장 큰 오픈 모델만을 쫓고 있는 것이 아닙니다. 스택의 중간 계층 (middle of the stack)을 더 개선하려고 노력하고 있습니다. 즉, 충분히 로컬에서 돌아가고, 충분히 멀티모달 (multimodal)이며, 충분히 긴 컨텍스트를 지원하고, 충분히 허용적인 모델을 만들려는 것입니다.

실제 개발자 채택은 바로 그 지점에서 일어납니다.

리더보드 스크린샷 속이 아니라, 모델이 당신의 책상 아래에 있는 기기에 딱 들어맞는 그 지점에서 말이죠.

출처: Gemma 4 Technical Report, Google June AI updates, Gemma 4 12B model card.