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

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

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

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

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

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

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

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

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

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

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

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

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