저는 한동안 클라우드 AI API를 쓰다가, 비용과 프라이버시 두 가지가 계속 걸려서 작업 상당수를 맥미니로 옮겼습니다. 민감한 메모나 녹취 같은 건 애초에 밖으로 안 보내고 싶었거든요.
그런데 "한국어 잘 된다"고 소문난 모델들을 막상 제 맥미니에서 돌려보니, 기대와 다른 지점이 꽤 많았습니다. 특히 "모델이 크면 똑똑하고, 대신 느리다"는 제 머릿속 공식이 두 번이나 깨졌습니다. 같은 머신에서 세 개 모델을 직접 돌려보고 남은 기록을 정리합니다.
테스트 환경과 모델 3개
- 기기: M4 맥미니, 메모리 32GB
- 실행: Ollama, 양자화는 Q4_K_M
- 측정 시점: 2026년 6월 초 (아래 수치는 제 환경에서 1회 측정한 스냅샷입니다)
비교한 모델은 모두 Gemma 4 계열로 묶었습니다.
- E4B: 경량판(8B급)
- 12B: 일반 dense 모델
- 26B MoE: Gemma 4 기반 26B 파인튜닝 모델 (전문가 혼합 구조, 토큰당 실제 활성 파라미터는 4B 수준)
같은 칩·같은 메모리·같은 양자화에서 비교했다는 점이 중요합니다. 환경이 섞이면 숫자를 나란히 놓기 어렵거든요.
속도 — '큰 모델이 더 빠른' 첫 번째 반전
먼저 생성 속도(초당 토큰)를 봤습니다.
| 모델 | 생성 속도(tok/s) | 입력 처리(tok/s) | 메모리 |
| E4B | 28.4–28.9 | 202–295 | 9.6GB |
| 12B | 11.2–11.9 | 78–103 | 7.6GB |
| 26B MoE | 28.8–30.0 | 134–174 | 16GB |
표를 보고 잠깐 멈칫했습니다. 파라미터가 가장 많은 26B가, 더 작은 12B보다 생성이 약 2.5배 빨랐습니다.
이유는 구조에 있었습니다. 26B는 전문가 혼합(MoE) 모델이라 토큰을 만들 때 실제로 쓰는 파라미터가 4B 수준입니다. 반대로 12B는 매 토큰에 모든 파라미터를 다 쓰는 dense 모델이라 더 무겁고요. "파라미터 수 = 느린 정도"라는 단순한 직관이 항상 맞지는 않았습니다.
한국어와 지시 이행
체감 품질은 모델마다 갈렸습니다.
한국어 문장이 가장 자연스럽게 느껴진 건 12B였습니다. 26B는 한국어 파인튜닝이 따로 적용돼 있어서 표현이 안정적이었고요.
대신 12B에는 또 다른 강점이 있었습니다. "몇 글자 이내로 써라" 같은 형식 제약을 유일하게 끝까지 지킨 모델이 12B였습니다. E4B는 빠른 대신 글자 수 제약을 자주 어겼고, 출력이 장황해지는 경향이 있었습니다.
그래서 글자 수나 JSON 같은 형식이 중요한 자동화 작업에는 12B가, 단순 분류처럼 속도가 중요한 작업에는 E4B가 맞았습니다. E4B는 짧은 분류 한 건을 0.3초 수준에서 끝냈는데, 이 속도는 실시간으로 끼워 넣는 작업에선 결정적이었습니다.
본문을 '보존'하는 작업의 두 번째 반전
또 하나 의외였던 건, 입력 텍스트를 건드리지 않고 다듬기만 하는 작업이었습니다. OCR로 읽어온 글자를 정제하는, 본문은 그대로 두고 군더더기만 걷어내는 작업이요.
여기서는 점수가 이렇게 나왔습니다(제가 5점 만점으로 채점).
- E4B: 5.0
- 26B MoE: 4.67
- 12B: 4.0
가장 작은 E4B가 1등이었습니다. 큰 모델일수록 "더 잘 다듬어 주겠다"며 본문 일부를 과하게 삭제하는 경향이 있었거든요. 보존이 목적인 작업에서는 똑똑함이 오히려 독이 됐습니다. "큰 모델 = 항상 우수"가 작업 종류에 따라 뒤집힌 셈입니다.
그래서 무엇을, 어디에 썼나
세 모델을 한 줄로 세워 "최고"를 뽑는 건 의미가 없었습니다. 작업 성격에 따라 답이 달라졌으니까요. 제가 정리한 기준은 이렇습니다.
- 실시간·짧은 판정(분류, 빠른 응답): E4B — 속도가 전부인 자리
- 형식·한국어 품질이 중요한 배치 작업: 12B — 느려도 형식을 지킴
- 민감한 데이터 분석: 로컬에서만 처리. 밖으로 안 보내는 게 1순위라 모델 선택보다 "로컬이라는 것" 자체가 조건
32GB로 시작하는 분들을 위한 체크리스트
- 32GB라면 경량(E4B)+12B 두 개는 동시에 올려둘 수 있었습니다(합쳐 약 17GB). 26B(16GB)까지 같이 올리면 메모리에서 다른 모델이 밀려날 수 있으니 주의하세요.
- "제일 큰 모델"부터 받지 마세요. 작업이 분류·요약이면 작은 모델이 더 빠르고, 본문 보존이면 오히려 더 정확할 수 있습니다.
- 속도가 중요한 자리와 품질이 중요한 자리를 먼저 나누고, 거기에 모델을 배치하세요.
- 한국어 품질은 직접 같은 프롬프트로 한 번씩 돌려서 비교해 보길 권합니다. 소문과 제 체감이 달랐습니다.
마지막으로 한 가지만 더. 위 수치는 제 맥미니에서 한 번 측정한 값입니다. 칩·메모리·양자화·Ollama 버전이 다르면 결과는 달라질 수 있으니, 절대 수치보다는 "큰 모델이 늘 정답은 아니다"라는 방향만 가져가셔도 충분합니다.