에이전트의 메모리(Memory)가 실패하는 방식 중에는 망각보다 더 나쁜 방식이 있으며, 저는 그것이 실패라는 것을 인식하는 데 꽤 오랜 시간이 걸렸습니다. 선호도는 저장소(Store)에 바로 그 자리에 놓여 있고, 만약 제가 에이전트에게 저의 커밋 스타일(Commit style)이 무엇인지 묻는다면, 에이전트는 단일 행, 관습적인 접두사(Conventional prefix), 이모지 없음이라고 정확하게 답변합니다. 하지만 에이전트가 실제로 버그를 수정하고 커밋하는 순간, 메시지는 제목에 이모지가 포함된 채 네 줄 길이로 출력됩니다. 규칙을 아는 것과 그것을 적절한 순간에 사용하는 것은 완전히 다른 문제임이 드러났기 때문입니다.

여기서 기술적으로 고장 난 것은 아무것도 없으며, 바로 그 점 때문에 이 문제는 매우 잘 숨겨집니다. 메모리 조회(Memory lookups)는 대화(Conversation)에 의해 구동됩니다. 사용자가 말한 것을 임베딩(Embed)하고, 유사한 메모리를 찾는 방식입니다. 커밋 스타일에 관한 규칙은 "로그인 버그를 수정하라(fix the login bug)"라는 문장과 단어도, 의미도 공유하지 않습니다. 따라서 규칙이 중요한 단 한 순간, 즉 커밋이 실행되기 직전은 바로 유사도 검색(Similarity search)이 규칙을 찾을 수 없는 바로 그 순간입니다.

여기에는 두 가지 명백한 해결책이 있지만, 둘 다 좋지 않습니다. 규칙을 고정(Pin)하여 모든 턴(Turn)에 주입되도록 할 수 있는데, 이는 규칙이 30개가 되어 모든 프롬프트(Prompt)가 대부분 관련 없는 규칙들을 모두 끌고 다니게 될 때까지는 작동합니다. 토큰 팽창(Token bloat)은 사람들이 메모리 시스템을 제거하는 첫 번째 이유입니다. 또는 규칙을 정적 설정 파일(Static config file)에 넣을 수도 있지만, 이 역시 작동하다가 멈추게 됩니다. 아무도 이를 업데이트하지 않고, 기기 간에 공유되지 않으며, 마음을 바꾸더라도 예전 규칙이 그대로 남아 있기 때문입니다.

제가 결국 이해하게 된 것은 이러한 선호도가 주제에 관한 사실(Facts)이 전혀 아니라는 점입니다. 그것들은 행동(Actions)에 관한 규칙입니다. 그리고 행동에 관한 규칙은 대화가 아니라 행동에 의해 검색되어야 합니다. 당신은 누군가 로그인 버그를 언급할 때가 아니라, 당신이 커밋 메시지를 작성하고 있을 때 팀이 커밋 메시지를 어떻게 쓰는지 기억합니다. 따라서 해결책은 모두가 사용하는 두 가지 방식 옆에, 정보를 조회하는 세 번째 방식을 두는 것입니다. 사실을 위한 주제별 회상(Recall by topic), 모든 턴에 함께 따라다니는 아주 작은 규칙 세트, 그리고 이제 행동 자체에서 실행되는 규칙(Rules that fire on the action itself)입니다.

작동 방식

규칙은 자신이 관리하는 행동을 명명하는 태그를 부여받습니다: trigger:git-commit, trigger:pr-create. 이것이 당신이 (규칙을) 저장하기 위해 수행하는 전부입니다. 읽기(read) 측면에서는 recall_for_action이라는 하나의 호출이 있습니다. 이 호출은 인덱스에서 태그를 찾아보고, 다른 모든 조회와 동일한 방식으로 누가 이를 볼 수 있는지 확인하며, 대체된(superseded) 항목은 버리고, 가장 최신 규칙부터 반환합니다:

# 커밋을 하는 '방법'에 대한 선호도, 관리하는 행동 태그가 붙어 있음
db.store(
    "commit messages: single line, conventional prefix, no emojis",
...

이 검색(retrieval)은 결정론적(deterministic)입니다: 쿼리의 임베딩(embedding)도 없고, 조정해야 할 유사도 임계값(similarity threshold)도 없으며, 모델 호출도 없습니다. 오직 행동 이름이 키(key)로 사용될 뿐입니다. 이것이 중요한 이유는, 이 조회 작업이 사용자의 명령 바로 직전이라는, 느려지거나 불안정해서는 안 되는 최악의 시점에 실행되기 때문입니다.

적절한 순간에 질문하는 훅(hook)

누락된 나머지 절반은 '언제 물어봐야 하는가'를 아는 것인데, 에이전트는 이미 이를 알고 있습니다. 바로 명령을 실행하기 직전입니다. Claude Code의 경우, 설정(setup) 단계에서 명령이 실행되기 직전에 각 명령을 살펴보는 훅(hook)을 설치합니다. 그리고 해당 명령이 커밋(commit)이나 PR(Pull Request)일 때, 일치하는 규칙을 가져와 바로 그 순간에 컨텍스트(context)에 집어넣습니다:

npx mentedb-mcp@latest setup claude-code
# Bash에 매칭되는 PreToolUse 훅을 설치합니다. git commit 또는
# gh pr create 이전에, trigger:git-commit / trigger:pr-create를 가져옵니다.
...

여기서 엔지니어링의 핵심은 훅이 '절대로 해서는 안 되는 일'에 있습니다. 훅은 결코 무언가를 차단하거나 승인하지 않으며, 오직 컨텍스트를 추가할 뿐입니다. 훅에는 엄격한 시간 예산(time budget)이 할당되어 있으며, 메모리 부족, 오래된 서버, 타임아웃 등 어떤 실패가 발생하더라도 아무것도 출력하지 않고 커밋은 수정 없이 그대로 실행됩니다. 당신의 git 워크플로우를 망가뜨릴 수 있는 메모리 시스템은 설치 당일에 바로 삭제될 것이므로, 실패 모드는 항상 침묵(silence)입니다.

파싱(parsing) 과정이 실제 버그가 숨어 있는 곳으로 밝혀졌습니다. 잘못된 명령에 규칙이 실행되는 것은 잘못된 메모리가 작동하는 것과 마찬가지로 신뢰를 떨어뜨립니다. 예를 들어, 매처(matcher)가 명령어를 grep(검색)하는 대신 파싱을 수행할 때 발생합니다: git -c commit.gpgsign=false commit은 서브커맨드(subcommand)가 commit이기 때문에 실행됩니다. 반면 git config commit.gpgsign false는 commit이라는 단어가 두 번 등장함에도 불구하고 서브커맨드가 config이므로 실행되지 않습니다. echo "git commit"은 따옴표로 묶인 텍스트이므로 실행되지 않습니다. cd repo && git commit은 복합 명령(compound command)의 각 세그먼트가 개별적으로 확인되며, 해당 형태의 모든 케이스가 테스트 스위트(test suite)에 포함되어 있으므로 실행됩니다.

수정(Corrections)은 당신이 기대하는 방식으로 작동합니다

이 규칙들은 일반적인 메모리이므로, 지난 포스트에서 다룬 수정 사항에 관한 모든 내용이 이 규칙들에도 적용됩니다. 에이전트에게 당신이 squash merge에서 rebase로 전환했다고 말하면, 이전 규칙은 대체됩니다. 당신이 그렇게 말하는 순간 커밋(commit) 시점에 해당 규칙이 나타나는 것을 멈추며, 나중에 이전 규칙이 무엇이었는지 묻는다면 히스토리(history)는 여전히 남아 있습니다. 또한 규칙은 최신순으로 다시 나타나므로, 만약 한 규칙의 두 버전이 공존한다면 나중에 생성된 버전이 우선권을 갖습니다.

이것이 제가 가장 중요하게 생각하는 부분입니다. 규칙은 적용되는 순간에 나타나며, 나타나는 버전은 바로 당신이 의도한 버전입니다.

직접 시도해보세요

엔진 호출은 mentedb 0.27.2에서 recall_for_action이며, 호스팅된 API는 이를 get_action_rules 도구로 노출합니다. npx mentedb-mcp@latest setup을 통해 훅(hook)을 설치할 수 있습니다. 커밋 규칙을 태깅하고, 커밋을 요청한 뒤, 정확히 적절한 순간에 규칙이 나타나는 것을 확인해 보세요. demo.mentedb.com의 라이브 데모에서 나머지 메모리 그래프(memory graph)를 탐색할 수 있습니다.