Git 저장소를 AI 코딩 에이전트의 지속 메모리로 쓰는 OKF Agent Memory v0.1

AI 코딩 에이전트는 세션이 끊기면 설계 결정과 운영 규칙을 잊어버리더라. 2만 토큰짜리 CLAUDE.md 같은 단일 파일과 무거운 벡터 DB 사이의 선택지가 싫어서, Git 저장소를 OKF 0.2 지식 코퍼스로 쓰는 순수 Go 도구를 만들었음. 메모리 내 BM25 검색은 300µs 미만이라고 함.

사람이 승인한 결정과 AI가 대량 생성한 문서를 같은 비중으로 취급하지 않게 하는 OKF 0.2의 발상은 마음에 듦. 다만 기업에서 이런 틈새 도구를 도입하기는 어렵고, 로컬 Markdown을 ripgrep으로 검색한 뒤 Claude에게 OKF와 인덱스를 관리시키는 방식과 무엇이 다른지 궁금함.

정해진 문서 형식과 규칙으로 프로젝트 문서를 직접 정리하는 방식과 비교하면 실제 사용 흐름이 어떻게 다른지 알고 싶음.

성능 벤치마크는 좋지만 OpenAI Symphony 같은 방식과 비교해 토큰 사용량이나 작업 완료율도 측정했는지 궁금함.

Codex처럼 자체 메모리 도구 사용을 유도하는 하니스에서 모델이 OKF를 얼마나 잘 따르는지가 걱정됨. 네이티브 메모리에 저장한 뒤 OKF를 쓰라고 지시하는 실험이 필요할 듯함.

서드파티 도구는 모델이 꾸준히 호출하게 만들기 어려웠음. Anthropic은 Opus나 Claude Code 하니스를 자기들 메모리 형식에 맞춰 조정할 수 있지만, OKF 같은 외부 도구는 Claude Code나 Codex에서 실제 통합 품질을 봐야 함.

프로젝트 하나 안의 메모리뿐 아니라 프로젝트 사이에서 공유하는 메모리도 원함. 직접 만들 생각이었는데 HN에 비슷한 게 올라올 줄 알았음.

교차 프로젝트 메모리라면 Hugging Face의 funes나 mempalace도 후보일 수 있음.

Astra가 압축 모델을 바꾸고 압축 자체를 없앤다는 말이 사실이면 이런 도구가 아직 필요한지 모르겠음.

Astra가 정말 압축을 안 한다는 출처가 필요함. 꽤 흥미로운 주장인데 확인하고 싶음.

이 프로젝트는 예전에 fellowgeek/mcp-memory와 함께 이미 HN에 올라온 적 있는 것 아닌가.

scaccogatto/okf-skills와는 어떻게 다른지 비교가 필요함.

지연 시간이 빠른 건 알겠는데, 정작 캡처와 검색 품질은 어떤지 모르겠음. 그 부분 벤치마크가 있는지 궁금함.

LLM 호출 시간에 비하면 밀리초 단위 지연 시간 최적화는 큰 의미가 없다고 봄. 이 도구의 가치는 정확도인데 recall이나 precision 테스트가 없다는 점이 문제임.