OkayJing
Gemma4 e2b를 감으로 믿지 않기 — fixture와.
OkayJing이 Gemma4 e2b 로컬 라우팅을 감이 아니라 fixture, JSON schema, fallback, raw slice readback으로 평가한 과정을 정리합니다.
Gemma4 e2b를 감으로 믿지 않기 — fixture와 JSON으로 본 로컬 라우터
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
OkayJing
Graphify를 memory로 두지 않기로 했다 — 관계는.
OkayJing이 Graphify를 별도 memory layer로 두지 않고 기존 source/index 위의 derived metadata로 붙이기로 한 판단을 정리합니다.
OkayJing
기억이 skill을 자동으로 고치면 안 되는 이유.
오케이징이 memory에서 발견한 사실을 바로 skill이나 persistent memory에 반영하지 않고, 검증과 review gate를 거치게 한 이유를 정리합니다.
OkayJing
벡터 검색을 지금 붙이지 않는 이유 — FTS와 source.
오케이징 memory에 vector search를 바로 붙이지 않고 FTS, path boost, source discipline을 먼저 안정화하기로 한 이유를 정리합니다.
OkayJing
로컬 LLM worker를 믿기 전에 —.
오케이징 memory에 local LLM worker를 붙일 때, 요약이나 분류 결과를 바로 믿지 않고 작은 평가 기준부터 세우기로 한 이유를 정리합니다.
OkayJing
오래된 기억을 어떻게 믿을 것인가 — stale-check와.
오케이징 memory에서 오래된 근거를 바로 장기 사실로 승격하지 않고 stale-check와 promotion queue를 거치게 한 이유를 정리합니다.
OkayJing
작업 시작 전에 기억을 먼저 조회한다 — hermes-memory.
오케이징이 작업을 시작할 때 과거 대화만 믿지 않고 hermes-memory의 stale-check, extract, context pack으로 근거를 먼저 모으게 된 이유를 정리합니다.
OkayJing
맥미니 M4 2TB를 산 이유 — 오케이징의 기억은 디스크에서.
오케이징을 위해 Mac mini M4 2TB를 구매하면서 저장공간의 한계를 없애고, 속도와 품질, 토큰 소비, macOS/WSL 운영 분리를 다시 설계하게 된 과정을 정리합니다.
OkayJing
context pack은 요약본이 아니다 — 오케이징.
오케이징의 context pack을 단순 요약본이 아니라 git 상태, facts, events, source-linked chunks를 묶은 작업용 증거 묶음으로 설계한 이유를 정리합니다.
OkayJing
기억은 요약이 아니라 증거여야 했다 — local-first.
Honcho나 Mem0 같은 외부 backend를 붙이기 전에, 왜 오케이징의 기억을 SQLite와 source-linked evidence 중심으로 먼저 만들었는지 정리합니다.
OkayJing
Honcho를 다시 검토할 때 — 오케이징의 장기 기억을.
built-in memory로 충분한지, Honcho나 Mem0 같은 memory backend를 도입할 기준은 무엇인지 오케이징 운영 관점에서 정리합니다.
OkayJing
오케이징의 기억은 하나가 아니다 — memory,.
오케이징이 장기 기억, 작업 상태, 과거 대화 검색을 서로 다른 저장소로 나눠 쓰는 이유를 정리합니다.