Gemma 4에서 Qwen 3.6으로 갈아탔다 — 두 모델을 모든 지표로 비교한 기록

한 달 만에 다시 갈아탔다

지난달 초에 "Gemma 4 로컬 AI 스택 완전 정복"이라는 글을 올렸다. Google DeepMind가 내놓은 Gemma 4를 개인 로컬 AI 서버에 본격 배포하면서 쓴 일종의 도입 후기였다. 그때부터 챗봇·문서 정리·사진 캡션 생성·내러티브 작성 등 6~7개 개인 서비스가 모두 Gemma 4 26B를 백엔드로 쓰고 있었다.

그런데 4월 중순에 Alibaba가 Qwen 3.6-35B-A3B를 공개했다. 벤치마크가 묘하게 흥미로워 보였다. 마침 새로 깐 코딩 에이전트(opencode)에 붙일 모델을 고르다가 Qwen을 시험 삼아 돌려봤는데, 한 번 비교해 보고 싶다는 생각이 들었다.

결과적으로 모든 서비스를 Qwen 3.6으로 갈아탔다. 그 의사결정에 쓴 비교표·실측 데이터와, "이 지표가 도대체 무슨 뜻인지"를 같이 정리해 본다.

두 선수 — 출시일과 파라미터부터

항목	Gemma 4 26B-A4B	Qwen 3.6-35B-A3B
출시일	2026-04-02	2026-04-16
제작자	Google DeepMind	Alibaba
라이선스	Apache 2.0	Apache 2.0
총 파라미터	26B	35B
활성 파라미터	3.8B	3B
아키텍처	MoE (Mixture of Experts)	MoE
컨텍스트 길이 (토큰)	262,144 (≈ 256K)	262,144 (≈ 262K)
지원 언어	영어 중심 + 일부	201개 (한·중·일·아랍어 심층)
멀티모달	텍스트+이미지	텍스트+이미지

둘 다 4월에 발표된 동시대 모델이고, 둘 다 MoE 구조에 200K 토큰 이상의 컨텍스트를 지원한다. 심지어 라이선스도 똑같이 Apache 2.0이다. 표면만 봐서는 거의 형제 모델처럼 보인다.

이 숫자들이 도대체 뭘 뜻하나

벤치마크 비교로 넘어가기 전에, 위 표에 나온 항목들이 무엇을 의미하는지 짚고 넘어간다. 처음 모델을 비교해 보는 사람은 이 숫자들이 어떤 의미인지 헷갈리기 쉽다.

총 파라미터 vs 활성 파라미터

모델의 "지능"의 총량은 총 파라미터 수로 가늠한다. 그런데 MoE 구조에서는 한 번의 추론에 모든 파라미터가 다 동작하지 않는다. 입력에 따라 그중 일부 "전문가(expert)"만 활성화된다. 활성 파라미터가 그 활성화되는 양이다.

예를 들어 Qwen 3.6은 35B 중 3B만 매번 동작한다. 비유하자면 35명짜리 자문단을 거느리고 있지만 질문 하나에 3명에게만 묻는 식이다. 자문단 전체를 메모리에 올려둬야 하지만 추론 비용은 3명 분만 든다. 그래서 MoE 모델이 같은 추론 속도에 더 풍부한 지식을 보여주는 이유다.

두 모델은 활성 파라미터(3B vs 3.8B)가 비슷해서 추론 속도가 비슷하다. 다만 Qwen이 총 파라미터가 35% 많아서 "잠재적 지식 풀"이 더 크다.

컨텍스트 길이 (토큰 단위)

모델이 한 번에 처리할 수 있는 텍스트의 양인데, 단위는 글자가 아니라 토큰이다. 토큰은 모델이 텍스트를 쪼개는 최소 단위로, 영어는 평균 1토큰 ≈ 4글자, 한국어는 평균 1토큰 ≈ 1~2글자 정도다. 토크나이저가 모델마다 달라서 같은 한국어 문장이 Qwen 토크나이저에서는 597토큰, Gemma 토크나이저에서는 649토큰으로 잘리는 식의 차이가 생긴다.

256K(=262,144) 토큰을 분량으로 환산하면 영어 책 한두 권, 한국어로는 그보다 짧은 분량이다. 다만 컨텍스트가 길어질수록 GPU 메모리(KV 캐시)가 폭증하므로 실전에서는 32K 토큰 정도로 줄여 쓰는 경우가 많다.

MoE vs Dense

전통적인 Dense 모델(예: Llama 3 70B)은 모든 파라미터가 매번 동작한다. MoE는 라우터가 토큰별로 적합한 expert만 호출한다. 같은 추론 속도에 더 큰 모델을 굴릴 수 있어서 2024년 이후 주류로 굳어졌다.

벤치마크 정면 비교

벤치마크	Qwen 3.6	Gemma 4	우위
SWE-bench Verified	73.4%	52.0%	Qwen +21.4pt
HumanEval	94.8%	92.1%	Qwen +2.7pt
LiveCodeBench	71.4%	64.7%	Qwen +6.7pt
MBPP	93.1%	90.3%	Qwen +2.8pt
MCPMark (MCP 도구 호출)	37.0%	18.1%	Qwen 2배+
LMArena (인텔리전스/VRAM)	—	1441 (6위)	Gemma (효율)
희귀 언어 안정성	—	cleaner coverage	Gemma

이 벤치마크들이 무얼 측정하나

벤치마크 이름만 보면 뭐가 뭔지 모를 수 있다. 항목별로 풀어 본다.

• SWE-bench Verified: 실제 GitHub 이슈를 모델이 PR로 해결할 수 있는지를 측정한다. 단순한 "함수 짜기"가 아니라 큰 코드베이스를 읽고 다중 파일 변경까지 하는 능력을 본다. 코딩 에이전트 품질의 진짜 기준.
• HumanEval / MBPP: 짧은 함수 단위 코드 생성. 1990년대 알고리즘 책에 나올 법한 작은 문제들이라 모델이 거의 다 만점에 가까워졌다. 변별력은 떨어졌지만 "기본기"는 본다.
• LiveCodeBench: 실시간으로 갱신되는 경쟁 프로그래밍 문제. 학습 데이터에 들어가지 않은 새 문제로 측정해서 "암기 효과"를 배제한다.
• MCPMark: Model Context Protocol 도구 호출 능력. AI 에이전트가 외부 도구(웹 검색, 캘린더, 데이터베이스 등)를 정확한 인자로 호출할 수 있는지 본다. 도구 호출 신뢰성이 낮으면 에이전트 자체가 무너진다.
• LMArena: 사람이 두 모델 응답을 블라인드로 비교 투표한 결과. "어느 쪽이 더 똑똑하냐"의 인간 체감 측정. 다만 영어 평가에 편향됨.

요약하면, Qwen은 코딩과 도구 호출에서 압도적이고 Gemma는 1인당 효율(LMArena 점수/메모리)에서 강하다.

실측 — 직접 돌려본 속도

벤치마크 점수와 별개로, 같은 하드웨어(NVIDIA GB10, 32K context)에서 직접 측정한 결과를 함께 본다.

항목	Qwen 3.6	Gemma 4	차이
토큰 생성 속도	52.3 tok/s	57.6 tok/s	Gemma 10% 빠름
프롬프트 처리 속도	1,131 tok/s	1,944 tok/s	Gemma 72% 빠름
한국어 토큰 효율	597토큰	649토큰 (동일 입력)	Qwen 8% 효율
GPU 메모리 (32K)	33GB	21GB	Gemma 12GB 적음

속도 지표가 의미하는 것

• 토큰 생성 속도(tok/s): 응답을 한 글자씩 토해내는 속도. 50 tok/s면 사람이 읽는 속도와 비슷해서 자연스럽다. 30 미만으로 떨어지면 답답하다.
• 프롬프트 처리 속도: 입력 문장을 모델이 "이해"하는 단계의 속도. 시스템 프롬프트가 길수록(예: 도구 정의 + 사용자 정보) 이 단계가 길어진다. Gemma가 1.7배 빨라서 첫 토큰까지의 지연이 짧다.
• 토큰 효율: 같은 한국어 문장을 더 적은 토큰으로 표현하는 능력. Qwen이 더 효율적인 한국어 토크나이저를 가지고 있다는 의미다. 컨텍스트 한도에서 더 많은 정보를 담을 수 있다.
• GPU 메모리: 모델 가중치 + KV 캐시. Gemma가 12GB 적게 먹어서 다른 GPU 작업(VLM, 음성 인식 등)과 동시 실행이 더 쉽다.

흥미로운 점은 벤치마크에서는 Qwen이, 실측 속도에서는 Gemma가 더 좋다는 것이다. "더 똑똑한데 더 무거운" Qwen 대 "조금 덜 똑똑하지만 더 가벼운" Gemma의 구도다.

그래도 Qwen을 골랐다 — 이유 셋

벤치마크와 실측이 엇갈리는 상황에서 어떤 모델을 고를지는 자기 워크로드의 지배 요인이 무엇인가에 달렸다. 내 환경의 7개 개인 서비스를 추려보면 다음과 같다.

• 대화형 AI 챗봇 — 멀티턴 대화 + 도구 호출 + 한국어
• 장편 콘텐츠 생성기 — 긴 문맥, 한국어 창작
• 지식 검색 후 재정렬·평가 — JSON 구조화 출력
• 문서 자동 정리 — 한국어 요약, YAML frontmatter
• 가족 사진 캡션 생성 — 한국어 내러티브, 짧은 출력
• OCR 문서 정리 — 긴 한글 입력 처리
• 개발용 코딩 에이전트 — 도구 호출, 코드 생성

이중 6개가 한국어 작업이고 2개가 도구 호출 중심이다. 그러면 Qwen이 우위인 측면(SWE-bench, MCPMark, 한국어 토큰 효율, 201개 언어 공식 지원)이 직접적인 이득으로 이어진다. 반면 Gemma가 우위인 측면(메모리 효율 12GB, 1인당 인텔리전스)은 GPU가 충분히 남는 환경에서는 큰 차이를 못 만든다.

구체적으로 정리하면 이유는 셋이다.

1. 도구 호출 신뢰성 — 코딩 에이전트와 챗봇은 도구 호출 실패가 곧 작업 실패다. MCPMark 37% 대 18%의 격차는 실전에서 "에이전트가 무한 루프에 빠지는 빈도"의 차이로 나타난다.
2. 한국어 공식 지원 — Gemma가 한국어를 못하지는 않는다. 다만 영어 우선 학습이라 미세한 어색함이 종종 나타난다. Qwen은 201개 언어를 공식 지원하면서 한국어가 1티어에 들어 있다.
3. 창작 품질 — 짧은 인사·사실 답변은 두 모델 차이가 거의 없다. 그런데 1000자 이상의 한국어 창작 결과를 블라인드로 비교해 봤더니 Qwen 쪽이 문장 리듬이 자연스러웠다.

그래서 다 갈아탔다

위 일곱 개 서비스를 모두 Qwen 3.6으로 단계적 전환하고 있다. 단순히 모델명을 바꾸는 게 아니라 운영 환경 자체를 손봤다.

• Ollama의 KV 캐시 양자화(q8_0) 적용 — Qwen 모델 GPU 메모리 33GB → 26GB로 감소
• Flash Attention 활성화 — 토큰 생성 속도 ~30% 향상
• Qwen3.6의 "thinking 모드"(think:false) — reasoning 없이 답을 직접 생성하게 강제. 이 옵션을 안 켜면 Qwen이 reasoning에 갇혀서 응답을 못 내는 경우가 있다
• BGE-reranker 검색 모델을 in-process로 상주시켜 RAG 호출당 23초 오버헤드 제거
• 에이전트 응답을 토큰 단위 SSE 스트리밍으로 전환 — 14초 대기 → 첫 토큰 1초 이내

이 과정에서 그동안 Gemma 환경에서는 안 보였던 문제들이 드러났다. 어떤 LLM이든 "갈아 끼우기"는 단순히 이름만 바꾸는 게 아니라, 그 모델의 특성에 맞춘 인프라 조정이 함께 따라와야 한다는 것을 다시 한 번 깨달았다.

중간 결론 — 그리고 다음 검증

로컬 LLM은 본격적으로 모델을 갈아 끼울 때마다 "지표"와 "실측"이 갈리는 경우가 잦다. 어느 한쪽만 보고 결정하면 후회한다. 내 경우엔 한국어 + 도구 호출 + 코딩이라는 워크로드 특성이 명확해서 Qwen이 답이었지만, 같은 두 모델을 두고도 영어 위주 작업을 하는 사람은 Gemma 4가 더 맞을 수 있다.

지금은 Qwen 3.6으로 통일된 환경을 며칠 쓰면서 안정성을 검증하는 중이다. 일정 시간 안정적으로 돌아가면 Gemma 4 가중치는 디스크에서 정리할 예정이다(17GB 회수). 그 다음 단계는 vLLM + FP8 양자화를 통한 추가 가속 — Blackwell GB10에서는 vLLM이 Ollama보다 디코드 속도가 ~44% 빠르다는 보고가 있어 다음에 한 번 시도해 볼 생각이다.

한 달에 한 번씩 백엔드 모델을 갈아 끼우는 일은 흔하지 않을 거라 생각했는데, 오픈 모델 생태계가 너무 빠르게 진화하고 있다. 다음 모델이 나오기 전까지 이 환경이 얼마나 버틸지 또 지켜봐야겠다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.