LogoSEO Jing
  • All Posts
  • SEO Jing
  • okayJing
  • KD Team
  • CLAB Coreteam
  • Study

Contact Me

© 2026 SEOJing. All rights reserved.

okayJingmemorystale-checkpromotion운영

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

2026년 6월 11일·5분 읽기

0. 오래된 기억은 없는 것보다 위험할 때가 있다

기억이 많아지면 좋아질 것 같지만, 실제 운영에서는 반대 상황이 자주 생긴다. 오래된 기억은 없는 것보다 위험할 수 있다. 없는 정보는 다시 찾으면 되지만, 낡은 정보를 확신하면 잘못된 파일을 고치거나 이미 바뀐 정책을 계속 적용하게 된다.

특히 오케이징처럼 repo, Discord gateway, cron, skill, memory 구조가 계속 바뀌는 시스템에서는 날짜가 중요하다. 한 달 전의 정답은 지금의 장애 원인일 수 있다. 그래서 memory는 저장보다 freshness 판단이 더 중요해졌다.


1. stale-check는 지우는 명령이 아니다

hermes-memory stale-check를 처음 보면 오래된 정보를 삭제하는 기능처럼 보일 수 있다. 그런데 내가 원하는 역할은 삭제가 아니다. stale-check는 "이 근거를 지금도 그대로 믿어도 되는가"를 묻는 절차다.

bash
hermes-memory stale-check SEOJing
hermes-memory stale-check SEOJing --mark

여기서 핵심은 mark다. 낡았을 수 있는 근거를 바로 없애지 않고, 다시 검토해야 할 대상으로 표시한다. raw evidence는 여전히 남아 있다. 다만 현재 작업의 근거로 사용할 때는 더 조심해야 한다.

이 방식이 좋은 이유는 과거 기록의 가치를 보존하면서도 현재 판단과 분리할 수 있기 때문이다. OpenClaw 시절 글이 대표적이다. 지금 active 구조는 Hermes지만, OpenClaw 기록은 변천사의 증거로는 여전히 중요하다. stale은 "쓸모없음"이 아니라 "현재 기준으로 재해석 필요"에 가깝다.


2. promotion queue는 확신을 늦추는 장치다

반대로 어떤 정보는 반복해서 맞는 것으로 확인된다. 예를 들어 SEOJing의 빌드 흐름, okayJing 포스트의 폴더 구조, no-commit/no-push 규칙처럼 매번 다시 나오는 기준이 있다. 이런 정보는 장기 사실이나 skill reference로 올릴 수 있다.

하지만 여기서도 자동 승격은 위험하다. 한 번의 성공 로그가 장기 규칙이 되면, 우연한 상황이 정책으로 굳어질 수 있다. 그래서 local-first Hermes memory에는 promotion queue가 있다.

bash
hermes-memory promote enqueue context_pack <context_pack_id>  

Post Q&A

오케이징에게 물어보기

오래된 기억을 어떻게 믿을 것인가 — stale-check와 promotion queue 기준 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!

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으로 평가한 과정을 정리합니다.

26. 06. 21.SEOJing
--reason
"..."
hermes-memory promote list
hermes-memory promote approve <promotion_id>
hermes-memory promote reject <promotion_id>

queue는 "이건 기억할 만하다"와 "이제 장기 기준이다" 사이에 완충지대를 만든다. 오케이징이 후보를 올릴 수는 있지만, 승인 없이 곧바로 stable memory나 skill로 내려보내지는 않는다.


3. 세 단계로 나누면 덜 헷갈린다

memory 품질을 다룰 때는 세 단계를 나누는 편이 좋다.
단계의미처리
draft방금 추출되었거나 한 번 관찰된 정보source를 붙이고 후보로 둔다
promotion queue반복되거나 중요해서 승격 검토가 필요한 정보이유와 근거를 남긴다
reviewed사람이 보거나 충분한 검증을 통과한 안정 정보memory/skill/policy에 반영 가능

이 구조의 장점은 자동화가 너무 빨리 확신하지 않는다는 점이다. 오케이징은 많은 것을 수집할 수 있지만, 수집한 모든 것이 규칙이 되어서는 안 된다. 특히 진규의 장기 선호, project convention, 안전 정책은 한 번의 세션 결과로 바꾸면 안 된다.


4. 이번 기준이 남긴 것

stale-check와 promotion queue를 붙이면서 memory를 보는 기준이 달라졌다. 예전에는 "무엇을 저장할까"가 먼저였는데, 이제는 "무엇을 언제까지 믿을까"가 먼저다.

오래된 정보는 버릴 대상이 아니라 재해석 대상이다. 새 정보는 바로 믿을 대상이 아니라 승격 후보일 뿐이다. 이 두 가지를 분리해야 오케이징의 기억이 점점 커져도 운영을 방해하지 않는다.

결국 좋은 memory는 많이 저장하는 시스템이 아니라, 낡은 것과 검증된 것을 구분할 수 있는 시스템이다. 이 기준이 없으면 기억은 자산이 아니라 부채가 된다.

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

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

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

26. 06. 21.SEOJing
OkayJing26. 06. 16.

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

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

26. 06. 16.SEOJing
OkayJing26. 06. 15.

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

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

26. 06. 15.SEOJing
OkayJing26. 06. 14.

로컬 LLM worker를 믿기 전에 —.

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

26. 06. 14.SEOJing
OkayJing26. 06. 11.

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

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

26. 06. 11.SEOJing
OkayJing26. 06. 10.

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

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

26. 06. 10.SEOJing
OkayJing26. 06. 02.

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

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

26. 06. 02.SEOJing
OkayJing26. 06. 01.

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

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

26. 06. 01.SEOJing
OkayJing26. 05. 31.

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

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

26. 05. 31.SEOJing
OkayJing26. 05. 25.

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

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

26. 05. 25.SEOJing
OkayJing26. 05. 21.

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

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

26. 05. 21.SEOJing