내 Claude Code 메모리 구조: 마크다운 깃 레포 3개와 훅 5개. 옵시디언도 벡터 DB도 없음. 구조 공유함

이 글 읽으니 흥미롭네. 나도 거의 같은 구조로 정착했거든, 다만 기반이 다를 뿐이야. 내 설정은 Git 기반의 Obsidian 볼트 안에 있어서, 네가 말한 'Obsidian' 답변에 해당하겠네. 그래도 분리 방식은 너랑 똑같아.

작업 방식: 역할별로 스킬을 하나씩 둠(프로세스 작업, 리서치 수집, 블로그 편집, 리뷰). 각 스킬은 더 긴 역할 정의 문서로 연결되는데, 둘이 충돌하면 그 문서가 우선함. 규칙에는 날짜와 이유("<날짜> 이후, 내가 결정함, 왜냐하면...")가 적혀 있고, 대부분 뭔가 잘못된 후에 작성됐어. 네가 말한 '짜증 나는 일들의 변경 기록(changelog-of-annoyances)' 효과랑 똑같아.

무슨 일이 있었나: 작업과 프로젝트는 프론트매터가 포함된 노트들이고, Bases 보드에 나타나. 그 보드가 진실의 원천이고, 터미널은 그걸 반영할 뿐이야. 볼트를 건드리는 모든 세션은 중앙 로그에 행을 하나 추가해.

소스: 원본 입력 노트(기사, 영상, 책)는 절대 규칙에 바로 넣지 않아. 별도의 역할이 먼저 그것들을 클러스터링해서 인수인계 노트로 만들어. 그 계층만 유일하게 벡터 검색을 사용해. 이건 지식 검색용이지 기억용이 아니라서, 둘을 분리해두는 게 좋다고 봐.

훅: 작은 플러그인 4개를 쓰고 있어. 역할 시작 훅은 프롬프트에서 맞는 스킬을 불러오고, 로그 가드(log guard)는 볼트 변경 사항에 로그 항목이 없으면 배너를 띄워줘. 가드레일은 노트에 대한 mv 명령을 막는데, Obsidian 자체의 이름 변경 기능만 링크를 온전하게 유지해주기 때문이야. 네 번째 훅은 터미널에 작업 보드를 보여줘.

네 글에서 두 가지를 배워가. 첫째, 작업 후 알려진 실수를 확인하는 체크 과정. 나도 그런 실수들을 규칙으로 적어두긴 했는데 아직 강제하는 건 없었거든. 둘째, 네 3k 토큰 시작 설정. 내 시작 컨텍스트는 그거보다 훨씬 커졌는데, 주로 인덱스 라인들이 서서히 상태 보고서로 변질됐기 때문이야.

내 핵심 결론도 너랑 같아: 파일 자체는 별로 안 변해, 그걸 강제하는 훅이 핵심이지.

사건 사고에서 규칙을 뽑아낸다는 거 완전 공감함. 내 훅 중 하나는 rg -r 명령을 막아버려. ripgrep에서 그게 --replace인데, Claude가 검색만 하려던 걸 자꾸 파일 내용을 바꿔버리더라고.

나도 결국 비슷한 방식에 도달했어. 난 직접 코드를 짜지 않고 Claude Code와 Codex를 지시하는 편이야. 내 방식은 '현재 상태'를 위한 개인 레포 하나당 CURRENT-STATE 파일, DECISIONS 파일, 그리고 프로젝트별 인수인계 노트 하나씩이야. 나한테 가장 큰 차이를 만든 건 두 가지야. 첫째, 결정이 번복되면 내용을 덧붙이는 대신 그 줄을 직접 수정해. 안 그러면 에이전트가 둘 다 찾아서 잘못된 걸 고르더라고. 둘째, 날짜가 적힌 "<날짜>에 결정함" 라인이 다른 모든 것보다 우선하게 했어. 너랑 똑같지. "사건에서 규칙을 뽑는다"는 부분은 정말 정확해. 내 파일에 있는 모든 규칙은 뭔가 한 번 잘못된 적이 있어서 존재하거든.

제자리에서 다시 쓰는 방식에 대한 지적은 일리가 있고 어느 정도 동의함. 나는 상태나 진행 중인 작업에 대해서는 그렇게 함(항상 현재 상태만 보여야 하니까). 결정 사항에 대해서는 이전 줄을 그대로 두고 바로 아래에 날짜와 함께 번복 내용을 추가하는 '...에 의해 대체됨' 방식을 씀. 나중에 드는 의문은 '규칙이 뭐지'가 아니라 '왜 X를 그만뒀지'이기 때문임. 그럴 땐 그 '시체'가 필요함. 죽은 줄을 삭제하는 게 아니라 죽었다고 표시하면 에이전트의 혼란은 사라짐.

나도 비슷한 접근 방식을 취하고 있고, 결국 내가 만드는 모든 레포에 넣을 수 있는 이 간단한 도구를 만들었음.

https://github.com/jeremybrice/relay

이 도구는 기본적으로 모든 세션이 이전 세션이나 전날에 작업했던 내용에 대한 맥락을 가질 수 있게 해줌.

꽤 단순하지만, 매우 효과적이라는 걸 알게 됐음.

나도 비슷한 걸 쓰고 있음(조금 덜 복잡하긴 하지만).

에이전트 파일이 작업 내용에 따라 어떤 규칙 파일을 읽을지 알려줌 ("데이터베이스를 변경하면 database.md를 읽어라" 같은 식). 이런 규칙이 12개 정도 있고, "로컬 파이프라인이 통과하기 전까지는 작업이 완료된 게 아니다" 같은 절대적인 필수/금지 사항을 담은 짧은 문단 3개, 그리고 지식 베이스를 어디서 찾을지(데이터베이스 구조나 '유효한 사용자' 같은 용어의 의미를 설명하는 파일들이 있는 구조화된 디렉토리 트리)도 포함됨.

작업이 끝나면 다음번에 레포를 방문했을 때 이어서 할 수 있도록 context.md에 짧은 요약을 적어둠. 덕분에 앱이 뭘 하는지, 마지막에 뭘 추가했는지 매번 다시 파악할 필요가 없음.

내 모노레포에서는 모든 앱(최상위 디렉토리)이 각자의 context.md를 가지고 있음.

최근에는 대시보드에서 트리거되는 ("이 작업을 에이전트에게 전달") "우리는 마지막에 X를 했고, 다음에는 Y나 Z를 할 것"이라는 워크플로우를 추가했는데, 여기에는 다음 단계에 대한 지침을 끝에 작성하라는 명령이 포함되어 있음.

아직까지는 그 파일들을 정리할 필요를 못 느꼈고, 컨텍스트 윈도우나 토큰 사용량 문제도 전혀 없음.

메모리를 위해 git을 사용하는 건 저평가되어 있음. diff를 확인할 수 있는 메모리는 검토가 가능한 메모리인데, 이건 어떤 벡터 DB도 제공하지 못하는 장점임.