Gemma4 E4B vs Qwen3.5 9B — 로컬 LLM을 한달 써본 솔직한 후기

유료 AI 구독을 끊겠다는 게 아니라, 병행하는 게 더 낫다는 걸 깨달은 시점이 있었다. 코딩이나 복잡한 분석은 여전히 유료 모델이 압도적이지만, 간단한 심부름이나 코드 리뷰, 빠른 질문 응답처럼 “굳이 클라우드까지 보낼 필요 없는” 작업에는 로컬 모델로도 충분하다는 판단이었다. 그 기준으로 한달 가까이 Gemma 4 E4B와 Qwen 3.5 9B를 번갈아가며 써왔고, 이제는 어느 쪽을 주력으로 쓸지 결론이 나왔다.

두 모델이 서 있는 자리

먼저 배경을 짚고 가자. Gemma 4 E4B는 구글이 2026년 4월 2일 공개한 모델로, 파라미터 수는 4B에 불과하지만 PLE(Per-Layer Embeddings)라는 아키텍처 덕분에 실제 표현력은 훨씬 큰 모델에 가깝다는 게 구글 측 설명이다. 4비트 양자화 기준 메모리 점유가 약 5GB 수준이어서 일반 소비자용 GPU에서 무리 없이 돌아가고, 128K 컨텍스트에 텍스트·이미지·오디오·비디오를 모두 다루는 멀티모달 구성이다.

Qwen 3.5 9B는 알리바바가 같은 해 3월 내놓은 모델로 파라미터는 두 배가 넘는 9B다. 262K의 넉넉한 컨텍스트 창이 특징이고, 201개 언어를 아우르는 방대한 다국어 학습이 강점으로 내세워진다. 벤치마크상으로는 MMLU-Pro에서 82.5점을 기록해 같은 회사의 Qwen3 30B를 웃도는 성과를 보이기도 했다.

숫자만 보면 Qwen 3.5 9B가 더 “무거운” 모델인데, 실제로 써보면 두 모델의 성격 차이가 그 이상으로 크게 느껴진다.

툴 사용은 Qwen이 더 낫다 — 하지만

처음에는 Qwen 3.5 9B의 툴 사용 능력이 인상적이었다. 함수 호출 스키마를 넘겨주면 비교적 일관되게 JSON 포맷을 맞춰 돌아오고, 어떤 툴을 언제 써야 하는지 판단하는 감각도 나쁘지 않았다. Gemma 4도 네이티브 함수 호출을 지원하지만 프롬프트 엔지니어링에 더 신경을 써야 일관된 결과가 나오는 편이었다.

그런데 Qwen을 며칠 쓰다 보면 눈에 거슬리는 현상이 생긴다. 한국어로 대화 중인데 갑자기 중간에 한자가 섞인다. “이 기능은 자동으로 処理됩니다”처럼. llama.cpp 이슈 트래커에도 이미 보고된 문제로(#20324), 다국어 학습 데이터가 지나치게 뒤섞인 탓으로 분석된다. 비중국어 환경에서 쓰는 사람 입장에선 당혹스러운 순간이 꽤 있다.

그보다 더 신경 쓰이는 건 따로 있다. 내부 사용 목적으로 질문을 넣었는데 응답 안에 쿼리의 구조나 내용이 그대로 노출되는 패턴이다. 예를 들어 어떤 문서를 요약해달라고 했더니 응답 초반에 “사용자가 입력한 내용은 ~이며”처럼 내 프롬프트를 다시 서술하고 시작하는 식이다. 실제 사용에서 크게 불편하지는 않지만, 업무 맥락에서 LLM 응답을 그대로 공유해야 하는 상황이라면 매번 손질이 필요하다.

이미지 출처: Unsplash

응답 품질과 속도는 Gemma 4가 낫다

툴 사용에서 한 발 뒤지는 것 같지만, 일상적인 질문 응답과 텍스트 생성에서는 Gemma 4 E4B 쪽이 체감상 분명히 낫다. 같은 질문을 던졌을 때 Gemma 4의 대답이 더 자연스럽고 맥락을 잘 잡는다는 느낌이 든다. 4B라는 작은 파라미터 수에도 불구하고 추론의 깊이가 기대 이상이다.

속도도 마찬가지다. 4B 모델이 9B보다 빠르다는 건 당연한 결과이긴 하지만, 소비자용 GPU 위에서 이 차이가 실제로 꽤 크게 느껴진다. 스트리밍 출력 기준으로 Gemma 4 E4B는 체감상 눈이 쫓아가기 편한 속도로 나오는데, Qwen 3.5 9B는 같은 하드웨어에서 한 박자 느리다는 인상이 있었다. 빠르게 답을 확인하고 다음 작업으로 넘어가야 하는 “심부름” 용도에서는 이 차이가 쌓인다.

코딩은 둘 다 한계가 명확하다

솔직히 말하면, 코딩 작업에 있어서는 이 두 모델을 주력으로 쓸 생각 자체를 접었다. 간단한 함수나 스크립트 정도는 괜찮지만, 기존 코드베이스를 이해하고 맥락을 파악해서 수정을 제안하는 수준이 되면 금방 한계가 드러난다. 틀린 함수명을 쓰거나, 존재하지 않는 API를 만들어내거나, 파일 구조를 엉뚱하게 가정하는 일이 잦았다. 코딩에는 유료 모델이 여전히 필요하다.

그래서 지금 내 워크플로우는 이렇게 나뉜다. 코드 작성과 복잡한 아키텍처 논의는 구독하여 쓰고, 작성된 코드를 훑어보거나 문서를 요약하거나 간단한 리서치 질문을 빠르게 처리하는 데는 로컬 모델을 쓴다. 굳이 클라우드로 나갈 필요가 없는 작업을 분리하는 것만으로도 비용과 응답 속도 모두 개선된다.

결국 어느 쪽을 고를 것인가

코딩 외의 목적이라면 Gemma 4 E4B 쪽을 권하게 된다. 4B라는 모델 크기가 주는 빠른 속도, 한자가 섞이거나 쿼리가 노출되는 불편함 없이 깔끔하게 끝나는 응답, 그리고 메모리 부담이 적다는 점이 일상 사용에서 유리하게 작용한다. Qwen 3.5 9B가 툴 사용 면에서 앞서지만, 그 장점이 다국어 혼용 문제를 상쇄할 만큼 결정적이냐고 하면 그렇지 않다는 게 한달간의 판단이다.

물론 툴 에이전트 기능을 메인으로 써야 하거나, 중국어가 포함된 다국어 환경이라면 Qwen의 방향이 맞을 수도 있다. 하지만 대부분의 한국 사용자 환경에서 “일반적인 쓸모”를 기준으로 한다면, 작고 빠르고 군더더기 없는 Gemma 4 E4B가 지금 시점에서 더 나은 선택으로 보인다. 구글이 이 모델을 Codeforces ELO 2150 수준의 코딩 벤치마크로도 밀고 있으니, 향후 업데이트에서 코딩 실용성도 개선될 가능성이 있고 그때 다시 비교해볼 여지는 남아 있다.
개인적인 의견이니 반박시 여러분 말이 맞습니다.

출처