로컬 모델을 붙일 때 가장 위험한 말은 "생각보다 괜찮다"다. 작은 모델이 빠르게 뭔가를 내면 믿고 싶어진다. 그런데 OkayJing에서 로컬 모델은 큰 모델 호출 전의 증거 라우터다. 여기서 틀리면 이후 판단도 엉뚱한 원본을 보게 된다.
그래서 Gemma4 e2b 실험에서 중요했던 건 모델 인상이 아니라 검증 방식이었다. fixture를 만들고, JSON output을 강제하고, 실패하면 fallback이 동작해야 했다.
관찰 결과는 이랬다. gemma4:e2b는 heavy_code, agent_context, streaming
error_log fixture에서 valid JSON을 냈다. 반면 qwen3:8b는 heavy_code와
agent_context는 처리했지만 streaming error_log에서 JSON parse failure가
났다.
이걸 "Gemma4가 더 좋다"로만 읽으면 아쉽다. 진짜 얻은 기준은 로컬 라우터를 평가하는 절차다.
Gemma4 e2b는 OkayJing에서 "작은 판단자"가 아니다. 검증된 라우터 후보에 가깝다. 파일을 고르고, 줄 범위를 좁히고, 원본 readback을 돕는 역할이다.
작은 모델은 싸고 빠르다. 그래서 더 자주 쓰고 싶어진다. 하지만 자주 쓸수록 더 좁은 계약이 필요하다. local worker가 낸 답이 아니라, local worker가 가리킨 원본을 믿는 구조가 되어야 한다.
로컬 worker 평가는 "이 모델이 똑똑한가"로 시작하면 금방 감으로 흐른다. 대신 먼저 fixture를 만든다. 긴 코드, agent context, 에러 로그처럼 실제로 자주 만나는 입력을 고정해두고, 모델 출력이 항상 같은 JSON 계약을 지키는지 본다.
여기서 중요한 점은 정답을 완벽한 요약으로 잡지 않는 것이다. 좋은 fixture는 "이 파일과 이 줄 근처를 후보로 낼 수 있는가", "잘 모를 때 fallback을 고르는가", "schema가 깨졌을 때 시스템이 멈추지 않는가"를 본다. 그러면 로컬 모델은 신뢰의 대상이 아니라 측정 가능한 부품이 된다.
Post Q&A
Gemma4 e2b를 감으로 믿지 않기 — fixture와 JSON으로 본 로컬 라우터 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!