로컬 LLM 코딩 벤치 — '예쁜 결과물'과 '깔끔한 코드'는 같은 모델이 아니다

두 채점이 정반대 답을 냈다

같은 HTML 출력을 두 채점관에 넘겼다. 한쪽은 “1위”, 다른 쪽은 “4위”라고 답했다. M4 Max 128GB에 ollama로 깔린 로컬 LLM 5종에 같은 프롬프트를 던지고, 코드 구조와 시각 충실도라는 두 기준으로 잰 결과다.

배경은 aimaster3658이 Threads에 올린 13장이다. Qwen 3.6 27b·35b 같은 로컬 모델에 자동차 시차 애니메이션 HTML 프롬프트를 던지고 결과 스크린샷을 비교한 글이다. 그 글이 사용한 채점 기준은 하나 — 시각 결과물.

시각 결과물이 중요한 작업(데모·UI·애니메이션)이면 그 기준이 옳다. 1년 뒤 고쳐 쓸 코드라면 다른 기준이 필요하다. AI 모델 평가는 채점 기준 선언이다 — 무엇을 얻고 무엇을 잃을지 먼저 정해야 한다. 끝에서 그 선언을 만드는 5단계를 정리한다.

TL;DR

• 채점 기준 선택이 평가의 본질이며 모델 순위는 그 부산물이다.
• 같은 출력을 devil(코드 기준)로 재면 gpt-oss 120b가 1위, 시각 기준이면 qwen 35b A3B가 1위.
• supergemma4는 두 기준 모두에서 0점으로, 출력 자체가 깨진 결과다.
• 본인 평가 기준을 만드는 5단계 절차는 본문 후반에 정리한다.

M4 Max 128GB에 깔린 5종

ollama 0.20.7 기준 설치된 모델:

모델	Quant	크기
qwen3.6:27b	Q4_K_M	17.4 GB
qwen3.6:35b-a3b-q8_0	Q8_0 (MoE A3B)	38.7 GB
gemma4:26b	Q4_K_M	18.0 GB
supergemma4:26b	Q8_0	26.9 GB
gpt-oss:120b	MXFP4	65.4 GB

같은 프롬프트(Threads 원본 한국어 번역 그대로), num_ctx=16384, num_predict=16384, temperature=0.7. ollama API 콜드 로드 후 첫 호출. 단일 시드 1회 측정이라 재측정 시 점수 1~2점 변동 가능.

약어: MoE = Mixture of Experts (일부 파라미터만 활성) · MXFP4 = 4비트 마이크로스케일 양자화 · A3B = active 3B 파라미터 MoE

두 채점 기준으로 측정 — 같은 입력, 다른 점수

정량 측정 (속도·토큰)

모델	시간(s)	토큰	tok/s	HTML(B)
qwen3.6:27b	550	8,572	15.8	18,582
qwen3.6:35b A3B	210	8,005	39.9	19,367
gemma4:26b	56	4,203	83.7	9,651
supergemma4:26b	41	2,420	69.8	7,490
gpt-oss:120b	41	1,759	63.9	4,858

두 가지가 안정적인 관찰이다. 35b A3B가 27b dense보다 2.5배 빠르다. dense 27B는 매 토큰 27B 전부 활성, MoE A3B는 라우터가 3B만 활성 — 활성 파라미터는 9배 작지만 메모리 대역폭과 라우터 오버헤드가 끼어 속도는 9배가 아닌 2.5배 차이로 줄어든 것으로 해석 가능하다(정확한 비례는 아님). 120b MXFP4가 가장 짧은 출력(1,759 토큰)을 냈다. 큰 모델이 더 장황할 거라는 직관과 반대다. 이 짧은 출력이 다음 절 코드 채점에서 의미 있게 작용한다.

qwen3.6:27b가 gemma4:26b보다 측정상 9배 느리게 나왔다(550s vs 56s). 단일 시드 1회라 ollama 콜드 로드·runner 차이가 섞였을 수 있어 이 수치는 글의 결론에 사용하지 않는다 — 재측정 후속 글에서 검증 예정.

코드 기준 — devil 채점 (구조·결함·테스트 등 7종목)

각 HTML을 devil 스킬에 넘겼다. devil은 코드 구조 품질을 본다 — 변수 명명, 함수 길이, 매직 넘버, GC 부담 등.

모델	devil 점수	주요 감점
gpt-oss:120b	7.0	매직 넘버 -0.9, JS % 음수 -0.3
qwen3.6:35b A3B	6.1	매 프레임 그라디언트 재생성 -0.5, 전역 mutation -0.5
gemma4:26b	6.0	yBase 미사용 -0.5, 매 프레임 sort -0.5
qwen3.6:27b	4.2	헤드라이트 brightness 역전 -0.5, 스피드 라인 역전 -0.5
supergemma4:26b	0.7	알파벳 토큰 누출 -0.5, 함수 정의 누락 -0.5

코드 기준 1위는 가장 짧고 빨랐던 gpt-oss 120b다. 이 케이스 한정 — 같은 짧음이 시각 채점에서는 차체 디테일 부족(-0.6)으로 뒤집힌다.

시각 기준 — 7항목 충실도 채점

브라우저 캡처 5장을 7항목(차체·바퀴·시차·하늘·다층·도로·분위기)으로 채점했다. 시각 기준은 프롬프트가 명시한 “사실적 측면 모습”, “영화적 조명”, “깊이감”의 충족도를 본다.

모델	시각 점수	인상
qwen3.6:35b A3B	8.5	황혼·별·가로등 빛 번짐, 압도적 영화감
qwen3.6:27b	6.5	만화풍 낮 풍경
gemma4:26b	4.5	황혼 시도하나 가로등이 산 중턱 부유
gpt-oss:120b	3.2	사다리꼴 차체, 평면 일렬 나무
supergemma4:26b	0.0	JS 즉사, 빈 하늘색 화면

각 모델의 실제 출력 캡처를 점수 순으로 본다 (Chrome headless --virtual-time-budget=3000 시점, 동일 1200×675 viewport).

qwen3.6:35b A3B Q8 — 시각 8.5/10. 4+ 레이어, 황혼 그라디언트, 가로등 빛 번짐 효과.

qwen3.6:27b Q4 — 시각 6.5/10. 푸른 하늘에 헤드라이트 켜진 차 — devil이 잡은 brightness 역전 버그가 시각으로도 확인됨.

gemma4:26b Q4 — 시각 4.5/10. 가로등이 산 중턱 공중에 떠 있다(yBase 미사용 결과).

gpt-oss:120b MXFP4 — 시각 3.2/10. 차체 = 사다리꼴 한 덩어리 + 바퀴 둘. 나무는 평면 일렬. 코드 채점 1위였지만 시각은 4위.

supergemma4:26b Q8 — 시각 0/10. 알파벳 토큰 누출로 JS 즉사. 캔버스에 1픽셀도 안 그려졌다.

두 채점이 만든 격차

모델	코드 기준	시각 기준	격차
qwen3.6:35b A3B	6.1	8.5	+2.4
qwen3.6:27b	4.2	6.5	+2.3
gemma4:26b	6.0	4.5	-1.5
gpt-oss:120b	7.0	3.2	-3.8
supergemma4:26b	0.7	0.0	-0.7

평균 격차 ±2.6점. gpt-oss는 시각에서 -3.8 떨어졌고, qwen 35b A3B는 시각에서 +2.4 솟았다. 같은 출력에서 이 정도 차이는 두 기준이 서로 다른 차원을 보고 있다는 뜻 — 결함 사례 4건으로 그 차원이 어떻게 갈리는지 확인한다.

결함 4건 — 기준에 따라 잡히는 무게가 다르다

supergemma 알파벳 누출: JS 코드에 a, b, c, ... z가 6번 삽입, 콜론과 등호 혼용 2곳(ctx.fillStyle: 'rgba(...)'). 양자화 자체 문제는 아니다 — 베이스 gemma4 Q4는 깨끗했고 supergemma만 깨졌다. “Q8이 Q4보다 항상 좋다”는 일반화의 반례. 두 기준 모두 0점인 유일한 케이스다 — 출력 자체가 망가졌다.

qwen 27b 헤드라이트 역전: if (brightness < 0.5) return — 야간에 헤드라이트가 꺼지고 한낮에 켜진다. 코드 채점(-0.5)과 시각 채점(분위기 약화 -0.3) 둘 다에서 감점. 여러 기준에서 동시에 잡히는 결함은 진짜 결함이다.

gemma yBase 미사용: layer마다 yBase 계산해놓고 draw()에서 안 쓴다. 모든 요소가 같은 Y에 박혀 가로등이 산 중턱 공중에 뜬다. 시각 채점(-0.5)에서 강하게 감점되지만 코드 채점에서는 “미사용 변수 -0.3”으로 약하게 잡힌다. 같은 결함이 기준에 따라 무게가 다르다.

gpt-oss 사다리꼴 차체: 가장 짧은 코드(4.7KB)가 “사실적 측면 모습”을 한 덩어리 사다리꼴 + 바퀴 두 개로 처리. 코드 채점에서는 만점, 시각 채점에서는 -0.6. 코드 채점만 들고 모델을 고르면 시각 결과를 놓친다.

평가 기준 만들기 5단계

30분 안에 가능한 절차다.

1. 작업 한 줄 선언 — 일주일 동안 가장 많이 하는 일을 한 문장으로 적는다 (“프로토타입 HTML 데모 빠르게 짜기” / “팀 코드베이스에 통합할 유틸리티 함수 작성” 등). 추상 단어 금지 — 구체 산출물 단어로.
2. 채점 기준 1개 선택 — 그 작업에 가장 가까운 채점관을 정한다. 코드 품질이면 devil/lint, 시각이면 캡처 7항목, 정확도면 골든 답안 매칭. 도구가 없으면 만든다(7항목 1.5점씩 등).
3. 3~5개 모델 후보 선정 — 돌릴 수 있는 환경의 모델만. 클라우드 vs 로컬도 같은 기준으로 평가해야 비교 가능.
4. 단일 프롬프트 단일 시드 측정 + 한계 표 옆에 명시 — 한 번 돌리고 점수 매긴다. “1회 측정이라 1~2점 변동 가능”을 결과 표 옆에 표기한다.
5. 두 번째 기준은 1차 결과 확정 후에만 — 1차에서 1위가 직감과 안 맞으면 그때 두 번째 기준 추가. 처음부터 둘 들고 시작하면 평가가 흐려진다.

작업별 모델 추천 (이번 5종 한정)

작업 유형	추천 모델	근거
시각 데모·UI 프로토타입	qwen3.6:35b A3B Q8	시각 채점 8.5/10, 영화감 강함
1년 뒤 고칠 코드 작성	gpt-oss:120b MXFP4	코드 채점 7.0/10, 매직 넘버 적음
빠른 토큰 스루풋	gemma4:26b Q4	83.7 tok/s, 출력 안정
추천 안 함	supergemma4:26b Q8	토큰 누출로 JS 즉사

이 표는 5종 한정 사례다. 6개월이면 갱신되니 본인 작업으로 다시 만들어야 한다.

자주 묻는 질문

Q. supergemma만 왜 0점인가?
A. JS 코드에 알파벳(a~z) 토큰 6회 삽입 + 콜론/등호 혼용 + 함수 누락으로 SyntaxError 즉사. 베이스 gemma4:26b Q4는 멀쩡하므로 supergemma 파인튜닝 자체 이슈. Q8 양자화가 그 노이즈를 더 충실히 재현했을 가능성도 있다.

Q. 코드 채점 1위 gpt-oss를 무조건 골라야 하나?
A. 작업이 1년 뒤 고칠 코드면 그렇다. 시각 데모면 35b A3B다. 채점 기준을 먼저 정한 다음 모델을 고른다.

Q. Sonnet 4.5나 Opus 4.7과 비교했나?
A. 안 했다. 이 글은 로컬 5종만 다룬다. 같은 두 기준으로 클라우드까지 비교하려면 후속 글로 분리.

Q. 단일 시드 결과를 일반화할 수 있나?
A. 개별 모델 점수는 일반화 불가(재측정 시 1~2점 변동). 그러나 “기준이 다르면 점수도 다르다”는 평가론 자체는 단일 케이스로도 보일 수 있다. 글의 결론은 후자다.

오늘 30분, 한 줄부터

다음 30분에 할 일은 두 줄이다. 첫 줄: 일주일 작업을 한 문장으로(예: “Claude Code로 React 컴포넌트 프로토타이핑”). 둘째 줄: 그 문장을 채점할 기준 하나(예: “Lighthouse 점수” / “ESLint warning 수” / “본인 7항목 표”). 두 줄이 모델 고르기의 출발점이다.

작업 정의를 매달 갱신하는 습관이 모델 비교표보다 길게 살아남는다.

---

관련 글

• M4 Max 로컬 LLM 5종 4시간 라우팅 — supergemma4를 1순위에서 뺀 이유 — 같은 5종, 4 워크로드 텍스트 비교
• Kimi K2.6 vs Opus 4.7 — 판정을 보류했다 — 도구 비교의 단일 기준 한계
• vibe-writing — 11개 글쓰기 스킬을 SKILL.md 라이브러리로 — devil 채점 기준을 만든 도구 모음

---

저자: cd4761 — 해고된 개발자의 AI 도구 노트. M4 Max 128GB로 로컬 LLM, ollama, Claude Code 워크플로우를 매일 측정한다. 블로그: cd4761.blogspot.com

태그: #로컬LLM #M4Max #ollama #qwen3 #gptoss #gemma4 #devil #벤치마크 #평가축