나의 AI 에이전트들은 매일 밤 10분 동안 자신의 기억을 다시 작성합니다

3개월 동안 매일 아침, 나는 나의 코딩 에이전트들에게 나 자신을 다시 설명해야 했습니다.

똑같은 선호도. 똑같은 프로젝트 구조. 똑같은 "아니요, 그건 이미 시도해 봤어요"라는 대화. 새로운 컨텍스트 윈도우 (Context window), 이전에 우리가 논의했던 것에 대한 기억은 전무했습니다.

그래서 나는 AI 에이전트를 위한 오픈 소스 메모리 레이어 (Memory layer)인 Lorekeeper를 구축했습니다. 저장 (Storage) 문제를 해결하는 것은 쉬운 부분이었습니다. 어려운 부분은 시간이 지남에 따라 기억이 더 좋아지게 만드는 것이었습니다. 단순히 양이 많아지는 것이 아니라, 더 날카로워지고 노이즈 (Noise)가 줄어들어야 했습니다.

나를 놀라게 한 접근 방식은 이것입니다: 에이전트가 바쁘지 않을 때 자신의 기억을 스스로 성찰 (Reflect)하게 하는 것입니다.

버킷 문제 (The bucket problem)

첫 번째 버전은 멍청한 저장 방식이었습니다. 기억을 저장하고, 나중에 그것을 찾는 방식이었죠.

memory.insert("user prefers snake_case for Python, camelCase for TypeScript")
memory.search("naming convention")
# → ["user prefers snake_case for Python, camelCase for TypeScript"]

몇 주가 지나면 수백 개의 기억이 쌓입니다. 번복했던 오래된 결정들, 아무 데도 쓰이지 못한 반쪽짜리 생각들, 세 번의 리팩토링 (Refactor) 전에는 유효했던 컨벤션 (Convention)들 말이죠. 유용한 정보들은 가라앉아 버립니다. 저장할수록 검색 (Retrieval) 성능은 더 나빠집니다.

우리는 다른 시스템들과 테스트를 진행했고, 저장된 기억이 200개에 도달하자 재현율 (Recall)이 약 80%에서 40%로 떨어지는 것을 발견했습니다. 유지보수 없는 저장은 기억이 아니라, 잡동사니 서랍일 뿐입니다.

야간 근무 (Night shift)

Lorekeeper는 크론 기반 스케줄러 (Cron-based scheduler)를 사용합니다. 에이전트가 작업 중이지 않은 몇 시간마다, 성찰 사이클 (Reflection cycle)을 실행합니다:

[03:15] lorekeeper: reviewing 347 active memories
[03:15] lorekeeper: 12 memories have low utility scores (≤ 3.0)
[03:15] lorekeeper: 3 memories are near-duplicates (similarity ≥ 0.92)
...

각 사이클은 모든 기억의 유용성을 점수화하고, 중복된 것을 병합하며, 잠자고 있는 노이즈를 아카이브 (Archive)하고, 관련된 사실들을 연결합니다. 이 모든 과정은 당신의 머신에서, 당신의 API 키를 사용하여, 당신의 인증 (Auth) 하에 이루어집니다.

# ~/.config/lorekeeper/cron.yaml
schedule: "0 */6 * * *"
actions:
...

나는 이것을 **로컬 드림 (local dreaming)**이라 부릅니다. 이는 당신의 뇌가 잠을 자는 동안 하루의 경험을 처리하는 방식처럼, 에이전트가 유휴 시간(idle time) 동안 스스로를 성찰하고 정보를 통합하는 과정입니다.

6주 후의 모습

주차	발생하는 일
1	드물지만 정확함. 모든 검색(retrieval)이 적중함.
...

벤치마크 결과: 로컬 384차원 임베딩 모델(embedding model)을 사용한 LongMemEval-S에서 Recall@1 84.6%, Recall@5 96.6%, 평균 지연 시간(latency) 32.9ms를 기록했습니다. 데이터는 기기 외부로 전혀 유출되지 않습니다.

예상치 못한 부분

드림 사이클(dreaming cycles)은 단순히 노이즈를 제거하는 데 그치지 않습니다. 그것은 제가 미처 발견하지 못했던 연결 고리들을 표면 위로 끌어올립니다. 지난주에는 에러 처리 미들웨어(error-handling middleware) 메모리를 API 버전 관리 규약(API versioning convention)과 연결했습니다 — 코사인 유사도(cosine similarity) 0.81을 기록했습니다. 제가 이 연결을 확인한 이후로는, 하나를 불러오면 다른 하나도 함께 나타납니다.

정적인 메모리 저장소(static memory store)는 이를 수행할 수 없습니다. 클라우드 서비스는 당신의 프로젝트 내에 있는 연결 고리들을 볼 수 없습니다. 자신의 메모리를 스스로 성찰하는 로컬 에이전트만이 이를 할 수 있습니다.

Letta와 같은 서비스들은 드림(dreaming)을 위해 서버 측 스케줄링(server-side scheduling)을 사용합니다 — 즉, 그들의 인프라와 그들의 LLM 호출을 사용합니다. 이는 유효한 접근 방식입니다. 우리는 다른 길을 택했습니다: 기본적으로 로컬(local by default)이며, 클라우드는 선택 사항이고, 항상 당신의 API 키를 사용합니다.

pip install lorekeeper-mcp
mcp-server setup
# cron을 통해 드림(dreaming)이 자동으로 시작됩니다

리포지토리는 github.com/jessira/lorekeeper이며, Apache 2.0 라이선스입니다.

당신의 코딩 에이전트가 세션 전반에 걸쳐 같은 행동을 반복하는 것을 목격한 적이 있나요? 이미 시도했던 동일한 접근 방식이나, 당신이 이미 거부했던 동일한 패턴을 반복하나요? 댓글을 남겨주세요 — 당신은 이 문제를 어떻게 처리하고 있는지 정말 듣고 싶습니다.