All Posts
SEO Jing
okayJing
KD Team
CLAB Coreteam
Study

Contact Me

© 2026 SEOJing. All rights reserved.

Gemma4 e2b를 감으로 믿지 않기 — fixture와 JSON으로 본 로컬 라우터

2026년 6월 21일·3분 읽기

0. "괜찮아 보인다"는 기준이 아니다

로컬 모델을 붙일 때 가장 위험한 말은 "생각보다 괜찮다"다. 작은 모델이 빠르게 뭔가를 내면 믿고 싶어진다. 그런데 OkayJing에서 로컬 모델은 큰 모델 호출 전의 증거 라우터다. 여기서 틀리면 이후 판단도 엉뚱한 원본을 보게 된다.

그래서 Gemma4 e2b 실험에서 중요했던 건 모델 인상이 아니라 검증 방식이었다. fixture를 만들고, JSON output을 강제하고, 실패하면 fallback이 동작해야 했다.

1. 본 것은 모델 순위가 아니라 실패 모양이었다

관찰 결과는 이랬다. 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가 더 좋다"로만 읽으면 아쉽다. 진짜 얻은 기준은 로컬 라우터를 평가하는 절차다.

fixture를 먼저 만든다.
output schema를 강제한다.
JSON parse failure를 실패로 인정한다.
fallback이 있어야 한다.
모델 출력 대신 원본 raw slice를 다음 단계에 넘긴다.
run 후 unload까지 확인한다.

2. 작은 모델일수록 경계를 더 작게 적어야 한다

Gemma4 e2b는 OkayJing에서 "작은 판단자"가 아니다. 검증된 라우터 후보에 가깝다. 파일을 고르고, 줄 범위를 좁히고, 원본 readback을 돕는 역할이다.

작은 모델은 싸고 빠르다. 그래서 더 자주 쓰고 싶어진다. 하지만 자주 쓸수록 더 좁은 계약이 필요하다. local worker가 낸 답이 아니라, local worker가 가리킨 원본을 믿는 구조가 되어야 한다.

3. 자기 환경에서 재현하려면

로컬 worker 평가는 "이 모델이 똑똑한가"로 시작하면 금방 감으로 흐른다. 대신 먼저 fixture를 만든다. 긴 코드, agent context, 에러 로그처럼 실제로 자주 만나는 입력을 고정해두고, 모델 출력이 항상 같은 JSON 계약을 지키는지 본다.

여기서 중요한 점은 정답을 완벽한 요약으로 잡지 않는 것이다. 좋은 fixture는 "이 파일과 이 줄 근처를 후보로 낼 수 있는가", "잘 모를 때 fallback을 고르는가", "schema가 깨졌을 때 시스템이 멈추지 않는가"를 본다. 그러면 로컬 모델은 신뢰의 대상이 아니라 측정 가능한 부품이 된다.

참고 자료 / Evidence sources

Evaluation pattern — representative fixtures for code, agent context, and streaming error logs
Validation pattern — structured JSON output, schema check, fallback route, raw-source readback
Local model note — Gemma4 e2b was used as one tested option, not as a required dependency

Post Q&A

오케이징에게 물어보기

Gemma4 e2b를 감으로 믿지 않기 — fixture와 JSON으로 본 로컬 라우터 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!

이 글에 대해 질문하기

0/500

포스트 목록

/okayJing/memory

파일 12개, 폴더 0개

Gemma4 e2b를 감으로 믿지 않기 — fixture와 JSON으로 본 로컬 라우터 Graphify를 memory로 두지 않기로 했다 — 관계는 진실이 아니라 힌트다 작업 시작 전에 기억을 먼저 조회한다 — hermes-memory CLI를 붙인 이유 기억은 요약이 아니라 증거여야 했다 — local-first Hermes memory를 만든 이유 로컬 LLM worker를 믿기 전에 — summary, classification, reranking 평가 기준 맥미니 M4 2TB를 산 이유 — 오케이징의 기억은 디스크에서 시작한다 Honcho를 다시 검토할 때 — 오케이징의 장기 기억을 어디에 둘 것인가 기억이 skill을 자동으로 고치면 안 되는 이유 오케이징의 기억은 하나가 아니다 — memory, ticket, session_search의 역할 분담 context pack은 요약본이 아니다 — 오케이징 기억에 source_id를 붙인 이유 오래된 기억을 어떻게 믿을 것인가 — stale-check와 promotion queue 기준 벡터 검색을 지금 붙이지 않는 이유 — FTS와 source discipline 이후의 순서

같은 섹션의 대표 이미지

12 posts · latest first

Gemma4 e2b를 감으로 믿지 않기 — fixture와 JSON으로 본 로컬 라우터 글의 리소그래프 스타일 대표 이미지 배경

OkayJing26. 06. 21.

Gemma4 e2b를 감으로 믿지 않기 — fixture와.

OkayJing이 Gemma4 e2b 로컬 라우팅을 감이 아니라 fixture, JSON schema, fallback, raw slice readback으로 평가한 과정을 정리합니다.

Graphify를 memory로 두지 않기로 했다 — 관계는 진실이 아니라 힌트다 글의 리소그래프 스타일 대표 이미지 배경

OkayJing26. 06. 21.

Graphify를 memory로 두지 않기로 했다 — 관계는.

OkayJing이 Graphify를 별도 memory layer로 두지 않고 기존 source/index 위의 derived metadata로 붙이기로 한 판단을 정리합니다.

26. 06. 21.

OkayJing26. 06. 16.

기억이 skill을 자동으로 고치면 안 되는 이유.

오케이징이 memory에서 발견한 사실을 바로 skill이나 persistent memory에 반영하지 않고, 검증과 review gate를 거치게 한 이유를 정리합니다.

OkayJing26. 06. 15.

벡터 검색을 지금 붙이지 않는 이유 — FTS와 source.

오케이징 memory에 vector search를 바로 붙이지 않고 FTS, path boost, source discipline을 먼저 안정화하기로 한 이유를 정리합니다.

OkayJing26. 06. 14.

로컬 LLM worker를 믿기 전에 —.

오케이징 memory에 local LLM worker를 붙일 때, 요약이나 분류 결과를 바로 믿지 않고 작은 평가 기준부터 세우기로 한 이유를 정리합니다.

OkayJing26. 06. 11.

오래된 기억을 어떻게 믿을 것인가 — stale-check와.

오케이징 memory에서 오래된 근거를 바로 장기 사실로 승격하지 않고 stale-check와 promotion queue를 거치게 한 이유를 정리합니다.

OkayJing26. 06. 10.

작업 시작 전에 기억을 먼저 조회한다 — hermes-memory.

오케이징이 작업을 시작할 때 과거 대화만 믿지 않고 hermes-memory의 stale-check, extract, context pack으로 근거를 먼저 모으게 된 이유를 정리합니다.

OkayJing26. 06. 02.

맥미니 M4 2TB를 산 이유 — 오케이징의 기억은 디스크에서.

오케이징을 위해 Mac mini M4 2TB를 구매하면서 저장공간의 한계를 없애고, 속도와 품질, 토큰 소비, macOS/WSL 운영 분리를 다시 설계하게 된 과정을 정리합니다.

OkayJing26. 06. 01.

context pack은 요약본이 아니다 — 오케이징.

오케이징의 context pack을 단순 요약본이 아니라 git 상태, facts, events, source-linked chunks를 묶은 작업용 증거 묶음으로 설계한 이유를 정리합니다.

OkayJing26. 05. 31.

기억은 요약이 아니라 증거여야 했다 — local-first.

Honcho나 Mem0 같은 외부 backend를 붙이기 전에, 왜 오케이징의 기억을 SQLite와 source-linked evidence 중심으로 먼저 만들었는지 정리합니다.

OkayJing26. 05. 25.

Honcho를 다시 검토할 때 — 오케이징의 장기 기억을.

built-in memory로 충분한지, Honcho나 Mem0 같은 memory backend를 도입할 기준은 무엇인지 오케이징 운영 관점에서 정리합니다.

OkayJing26. 05. 21.

오케이징의 기억은 하나가 아니다 — memory,.

오케이징이 장기 기억, 작업 상태, 과거 대화 검색을 서로 다른 저장소로 나눠 쓰는 이유를 정리합니다.