매달 API 요금 고지서 보면서 "이걸 직접 돌리면 얼마나 절약되려나" 생각해본 적 있다면, 이제 진지하게 계산기를 두드릴 때가 됐다. Google이 내놓은 Gemma 4 — 31B 파라미터 오픈 모델이 Arena AI 텍스트 리더보드 3위를 찍었고, 라이선스는 Apache 2.0이다.

Apache 2.0, 이게 왜 큰 건지

Gemma 3까지는 Google 자체 라이선스였다. 상업적 사용은 됐지만 미묘한 제약이 있었고, 법무팀 확인 한 번 더 받아야 하는 그런 류였다. Gemma 4부터는 Apache 2.0이다. 수정, 재배포, 상업적 사용 전부 무제한.

Meta의 Llama 커뮤니티 라이선스에는 MAU 7억 넘으면 별도 협의해야 하는 조건이 걸려있다. Qwen은 Apache 2.0이긴 한데 중국 수출규제 리스크를 걱정하는 팀이 적지 않다. Gemma 4는 그런 걱정 자체가 없다. 스타트업이든 대기업이든 법적 부담 제로로 프로덕션에 바로 넣을 수 있다.

Hacker News에서 가장 많이 올라온 반응도 결국 이거였다 — "Apache 2.0 is a big shift." 기술이 아니라 라이선스가 채택의 가장 큰 병목이었던 셈이다.

4종 라인업, 어떤 걸 골라야 하나

Gemma 4는 단일 모델이 아니다. 에지 디바이스부터 서버급까지 커버하는 4사이즈 패밀리다.

모델 활성 파라미터 컨텍스트 MMLU Pro AIME 2026 VRAM (Q4)
E2B 2.3B 128K 60.0% 37.5% ~2GB
E4B 4.5B 128K 69.4% 42.5% ~4GB
26B MoE 4B (전체 26B) 256K 82.6% 88.3% ~15GB
31B Dense 31B 256K 85.2% 89.2% ~20GB

핵심은 26B MoE다. 전체 파라미터는 26B인데 추론 시 활성화되는 건 4B뿐이다. 31B Dense 성능의 97%를 약 8분의 1 비용으로 뽑아낸다. 대량 트래픽을 처리해야 하는 프로덕션 환경이라면 이 모델부터 보는 게 맞다. 24GB VRAM GPU 하나면 Q4 양자화로 충분히 올라간다.

반대쪽 끝에 있는 E2B는 2GB면 돌아간다. 폰, 라즈베리 파이, Jetson Nano에서도 된다. MMLU Pro 60%라는 숫자가 대단해 보이진 않지만, 오프라인 앱이나 IoT 환경에서 네트워크 없이 로컬 추론을 돌릴 수 있다는 건 완전히 다른 종류의 가치다.

멀티모달과 함수 호출이 진짜 차별점이다

이 부분이 Gemma 4를 단순한 "벤치마크 좋은 오픈 모델" 이상으로 만드는 요소다. 4개 모델 전부 텍스트, 이미지, 비디오를 기본 지원한다. E2B와 E4B는 오디오까지 된다. 비전 어댑터를 나중에 덧붙인 모델과 달리, 처음부터 멀티모달로 훈련됐다.

비전 인코더에 토큰 버짓 시스템이 들어가 있다. 이미지당 70, 140, 280, 560, 1120토큰 중 선택 가능하다. 단순한 이미지 분류에 70토큰, OCR이나 정밀 분석에 1120토큰을 할당하는 식이다. 셀프호스팅 환경에서 이미지 처리 비용을 요청 단위로 세밀하게 제어할 수 있는 오픈 모델은 이게 처음이다. 한 서비스 안에서 썸네일 분류에는 최소 토큰, 의료 이미지 분석에는 최대 토큰을 쓰는 식으로 파이프라인을 짤 수 있다.

함수 호출도 프롬프트 엔지니어링 방식이 아니다. 전용 스페셜 토큰으로 동작하는 4단계 라이프사이클 — 도구 정의, 모델 호출, 개발자 실행, 최종 응답 — 이 토큰 레벨에서 구조화되어 있다. 에이전트 워크플로에 넣었을 때 파싱 에러가 크게 줄어드는 구조다. 이미지를 보고 함수를 호출하는 멀티모달 function calling까지 지원한다. 도시 사진 넣으면 위치 인식하고 날씨 API 호출하는 식의 파이프라인이 오픈 모델 하나로 가능해졌다.

에코시스템 지원도 인상적이다. 출시 첫날부터 HuggingFace Transformers, vLLM, llama.cpp, Ollama, MLX, NVIDIA NIM, LM Studio 전부 대응됐다. 보통 오픈 모델 나오면 커뮤니티 포팅에 일주일은 걸리는데, 이번엔 파트너 통합이 동시에 나왔다. 바로 프로덕션 테스트에 들어갈 수 있다는 뜻이다.

솔직히 약점

벤치마크가 화려하지만 실전 피드백은 좀 다르다. HN에서 코딩 안정성 문제가 꾸준히 보고됐다. 복잡한 멀티파일 리팩토링에서 Qwen 3.5 대비 실수가 잦다는 평이다. LiveCodeBench 80%라는 숫자는 단일 파일 문제 기준이라 실무 체감과 괴리가 있을 수 있다.

컨텍스트도 256K면 넉넉하지만 Llama 4 Scout의 10M 토큰과는 차원이 다르다. 대규모 코드베이스 전체를 한 번에 먹여야 한다면 여전히 Llama 쪽이다. 그리고 하나 더 — 128K 넘어가면 31B 니들 테스트가 66.4%, 26B MoE는 44.1%까지 떨어진다. 컨텍스트 창 숫자만 보고 판단하면 안 된다.

결국 선택의 문제

"최강 모델"이라서가 아니라 선택지가 넓어졌다는 게 핵심이다. API에 월 수십만 원 나가는 팀이라면 26B MoE를 vLLM으로 셀프호스팅하는 게 현실적 대안이 됐다. 에지에 추론을 내려야 한다면 E2B가 지금 나온 것 중 가장 현실적이다. 오픈소스 모델이 "API 대비 한 수 아래"이던 시절은 조용히 끝나고 있다.