token-router와 local evidence router를 붙이려는 이유는 처음엔 단순해 보였다. 큰 로그나 긴 코드 파일을 매번 큰 모델에게 보내면 비싸고 느리다. 그러니 로컬 모델이 먼저 훑고, 필요한 부분만 넘기면 된다. 여기까지만 보면 token 절약 장치다.
그런데 막상 기준을 잡다 보니 더 중요한 문제가 있었다. 로컬 모델이 고른 구간을 어디까지 믿을 것인가. 이 질문을 잘못 잡으면 작은 모델이 어느 순간 사실 판단자나 보안 판단자로 올라서게 된다.
OkayJing에서 local evidence router가 맡아도 되는 일은 좁다. 긴 로그, 긴 코드, 긴 agent-context 문서에서 관련 있어 보이는 file/line 후보를 고르는 것이다. "이 부분을 먼저 보라"는 좌표를 내는 일이다.
반대로 로컬 모델의 요약을 사실로 저장하면 안 된다. 로컬 모델 판단만으로 코드를 수정하거나 삭제해도 안 된다. 권한, 보안, 소유권, 외부 전송 같은 규칙을 로컬 라우팅 결과에 맡기는 것도 안 된다.
큰 원본 파일
→ local model: 후보 file/line JSON
→ deterministic router: 원본 raw slice readback
→ cloud model: source-backed evidence로 판단
신뢰 지점은 모델 출력이 아니라 readback이다. 로컬 모델이 "여기쯤"을 말하면, deterministic router가 원본에서 다시 뽑는다. 큰 모델은 요약문이 아니라 원본 slice를 본다.
이 방식은 큰 모델을 아끼는 것보다 더 중요하다. OkayJing이 raw evidence를 버리지 않는 시스템으로 남기 때문이다. 큰 모델이 덜 읽어도, 판단은 원본에 묶인다.
로컬 worker를 쓰는 순간마다 이 기준을 다시 봐야 한다. "이 worker가 낸 문장을 믿는가"가 아니라 "이 worker가 원본을 다시 찾게 해줬는가"를 봐야 한다.
이 글을 그대로 따라 하려면 Gemma4 e2b나 token-router부터 고를 필요는 없다. 먼저 정해야 할 것은 "작은 모델이 무엇을 결정할 수 없는가"다. 추천하는 최소 계약은 세 가지다. 작은 모델은 후보 위치를 JSON으로 낸다. 프로그램은 그 위치의 원본을 다시 읽는다. 최종 판단은 원본 조각을 받은 더 강한 모델이나 사람이 한다.
이 경계를 두면 개인 AI 운영체계를 만들 때 로컬 모델을 안전하게 끼워 넣을 수 있다. 로그 분류, 긴 파일 후보 추리기, 이전 세션 묶기처럼 실패해도 되돌릴 수 있는 일부터 맡기면 된다. 반대로 삭제, 권한 부여, 외부 전송, 사실 확정은 원본 확인 없는 로컬 모델에게 주지 않는 편이 낫다.
Post Q&A
로컬 모델에게 맡겨도 되는 일 — local evidence router의 경계 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!