Claude Code의 Auto-memory 점검: AI가 기억한 41개 항목 검토 및 결과

왜 기억을 점검하게 되었는가

저는 혼자 회사를 운영하며, 실무의 상당 부분을 Claude Code에 위임하고 있습니다. 이 위임의 질을 결정하는 것은 모델의 성능이 아니라 'AI가 무엇을 기억하고 있는가'였습니다.

Auto-memory(~/.claude/projects/<project-slug>/memory/)는 세션을 넘나들며 사실을 가져가는(carry over) 메커니즘으로, 편리한 만큼 조용히 작동합니다. 잘못된 기억이 한 건 섞이면, 그 이후의 모든 세션이 그 전제 하에 움직입니다. 게다가 저희가 알지 못하는 방식으로요. 지시하지 않았는데도 특정 판단을 피하거나, 금지했던 것을 다시 시작하는 등의 행동이 나타나면, 대부분 기억이 원인입니다.

실제로 저에게 발생한 일이 있었습니다. X 광고와 관련하여 '6,000엔 사용에 매출 0, X 광고는 도서 판매에 부적합'이라는 기억이 저장되어 있었습니다. 이는 당시의 관측으로는 맞았습니다. 나중에 Amazon Associates 트래킹을 확인해보니, 주문 4권 및 KU 소개 수수료를 포함하여 수익은 7,071엔, ROI는 +18%로 흑자였습니다. 측정 누락으로 인해 '실패'로 기록했던 것입니다. 이 한 건의 기억이 남아있었다면, AI는 앞으로 계속 X 광고를 제안하지 않았을 것입니다. 기회 손실액은 광고비보다 더 큽니다.

그래서 저는 기억을 자산이 아니라 **재고(在庫)**로 취급하기로 했습니다. 점검 대상인 것이죠. 아래에 실제로 구동하고 있는 점검 구현을 공유하겠습니다.

기억 한 건의 구조

우선 전제부터 말씀드리자면, Auto-memory는 1 파일 = 1 사실이며, 프런트매터(frontmatter)를 가집니다. 제가 운영하는 실제 파일은 이런 형태입니다.

---
name: project-zenn-note-separation
description: Zenn=기술 기사(코드 2개 이상 필수), note=경영 기사. 주제 풀을 플랫폼별로 분리 (2026-09-12~)
...

점검할 부분은 본문이 아니라 이 구조, 즉 description입니다.

description은 리콜(recall, 상기) 시 '이 기억이 현재 이야기와 관련이 있는가'를 판별하는 데 사용됩니다. 즉, description이 모호한 기억은 관계없는 상황에서 호출될 수 있습니다.

type은 분류이며, 저는 user / feedback / project / reference 네 가지로 고정하고 있습니다.

그리고 MEMORY.md가 인덱스 역할을 하며, 세션 시작 시 여기만 읽힙니다. 인덱스에 실려있지 않은 기억은 사실상 존재하지 않는 것과 같습니다. 여기가 첫 번째 점검 포인트입니다.

점검 스크립트

1줄 명령어에서 실행할 수 있는 범위부터 시작하는 것이 좋습니다. 먼저 인덱스와 실제 파일을 대조합니다.

MEM="$HOME/.claude/projects/-Users-kyoagun-workspace-one-ceo/memory"
# 인덱스에 실려있지 않은 기억 (= 호출되지 않는 고아)
comm -13 \
...

제 환경에서는 41건 중 고아가 1건 발견되었습니다. feedback_zenn_ai_guideline.md——Zenn의 생성 AI 가이드라인 대응을 작성했음에도 인덱스에 추가하는 것을 잊었던 것입니다. Zenn 기사를 자동 생성하고 있기 때문에 이것이 작동하지 않는 것은 사소하지만 아픕니다.

다음으로, 점검 우선순위를 결정하기 위한 재고표를 출력합니다.

#!/bin/bash
# audit-memory.sh — Auto-memory의 재고표를 출력
set -euo pipefail
...

stat -f %m은 macOS(BSD stat) 형식입니다. Linux에서는 stat -c %Y로 변경해야 합니다. 이 부분을 놓치면 모든 줄이 0일 날짜가 되어 '모두 신선하다'라는 역설적인 결론이 나오므로, 처음에는 한 건만 눈으로 확인하는 것이 좋습니다.

출력을 type별로 살펴보면 점검해야 할 부분이 명확히 나뉩니다.

무거운 것은 project와 feedback입니다. project에는 '2026-08-15에 6개 사업 철수' 같은 날짜와 '월액 5,000엔 이상은 가설 검증 필수' 같은 임계값이 들어갑니다. 이런 종류의 숫자가 오래된 채 남아있으면, AI는 오래된 임계값으로 승인/비승인을 판단합니다.

날짜와 숫자를 포함하는 기억을 기계적으로 추출하기

전체 내용을 다시 읽어보는 것은 현실적이지 않다. 훼손될 가능성이 있는 것은 '절대 날짜'와 '금액/비율'을 포함하는 기억에 한정되므로, 그 부분으로 범위를 좁힌다.

# 과거 날짜를 포함한 기억을 오래된 순서로 나열 (점검 큐)
grep -Hno '20[0-9][0-9]-[01][0-9]-[0-3][0-9]' "$MEM"/*.md \
| awk -F: '{print $4"	"$1":"$2}' | sort | uniq | head -20
...

나의 경우, 금액을 포함한 기억이 11건 나왔다. 그중 2건이 실제로 오래되었다. 한 건은 초반부 X 광고에 관한 것이었고, 다른 한 건은 'Amazon Ads ¥2,421로 효과 불명'이라는 내용으로, 이는 측정 시스템을 정비한 지금이라면 판단할 수 있다.

모순 감지 — 이 부분만 AI에게 맡긴다

grep으로는 알 수 없는 것이 기억들 간의 모순이다. 'Autonomos 일원화. drafts/를 만들지 않는다'와 '대외 액션은 반드시 draft → 승인 → 실행'은 문자열상으로는 무관하지만, "draft"라는 단어가 지칭하는 바가 다르다. 전자는 배포 드래프트이고, 후자는 승인 파이프라인이다. AI가 이를 혼동하면, 승인 플로우를 건너뛰거나 반대로 불필요한 드래프트를 계속 만들게 된다.

이 감지는 서브 에이전트에게 맡기는 것이 빠르다. 로딩은 memory 디렉터리에만 한정하고, 쓰기 권한은 주지 않는다.

claude -p '~/.claude/projects/-Users-kyoagun-workspace-one-ceo/memory/ の
*.md 를 전건 읽고, 다음 내용만 출력하도록 하라. 제안이나 요약은 필요 없다.
1. 모순 쌍: 동시에 성립할 수 없는 지시의 조합 (파일명 2개 + 충돌하는 문장 인용)
...

--allowedTools
를 Read/Grep/Glob으로 제한하는 것이 핵심이다. 점검과 동시에 수정하게 하면, 무엇이 사라졌는지 알 수 없게 된다. 감지와 수정은 반드시 분리한다. 나는 한 번에 이 과정을 처리했고, 올바른 기억이 '중복'으로 삭제되었다. 복구할 수 있었던 것은 우연히 git status에 나타났기 때문이며, memory 디렉터리는 보통 git 관리 외부에 있으므로 다음에는 그럴 수 없다.

대책으로 점검 전 스냅샷을 찍도록 했다.

tar czf "$HOME/.claude-memory-backup-$(date +%Y%m%d).tgz" -C "$MEM" .

감지 후 처리 규칙

TSV가 나오면, 종류별로 처리 방법을 정해 확정한다. 망설일 여지를 남기면 정리 작업이 끝나지 않는다.

모순을 '오래된 쪽을 삭제하는 것'으로 처리하고 싶은 마음이 들지만, 이는 하지 않는 것이 좋다. 방침이 바뀐 경위 자체가 판단 자료이며, 삭제하는 것과 같은 실수를 반복하는 제안이 돌아올 수 있다. X 광고 기억도 나는 덮어쓰기(overwrite)가 아니라 '## 2026-04-14 수정'이라는 절을 추가하여 양쪽 모두 남겼다.

검증 방법은 간단하다. 점검 후에 새로운 세션을 열고 해당 주제를 하나 질문한다.

claude -p 'X 광고에 서적 판매 예산을 투입해야 할까요? 근거로 삼은 기억의 파일명도 언급해 주세요.'

수정 전에는 'X 광고는 측정 불가로 손실이 발생했으므로 비권장'이라고 답변했다. 수정 후에는 'ROI +18% 실적이 있으나, 제휴 태그 필수'와 같이 조건부로 답변하게 되었다. 파일명을 언급하게 하는 것이 중요하며, 어떤 기억이 영향을 미쳤는지 알 수 없으면 점검의 성공 여부를 판단할 수 없다.

함정

너무 길고 자세하게 쓰면 회상률(recall rate)이 높아지는 느낌이 들지만, 반대로 무관한 상황에서 호출된다. 1행・1토픽으로 유지한다. description의 비대화 -
프로젝트 slug 착오. 디렉터리명은 작업 경로로부터 기계적으로 생성된다 (예: -Users-kyoagun-workspace-one-ceo)

）。저장소(repository)를 이동하거나 이름을 변경하면 다른 memory 디렉터리가 생성된다. 마이그레이션 시에는 기존 디렉터리의 잔존 여부를 확인해야 한다. -
기밀 정보 혼입. memory는 외부로 전송되는 것을 전제로 다룬다. 나는 재무, ASIN, 의사결정 로그를 memory에 기록하지 않는 규칙을 세우고 있다. 점검 차원에서 grep -rlE 'B0[A-Z0-9]{8}' "$MEM"

으로 실제 ASIN의 혼입 여부를 확인하고 있다. -
인덱스만 수정하고 본체를 삭제하는 것을 잊는다. 고아 파일(orphan file)은 호출되지 않는다고 해서 사라지는 것이 아니다. slug 충돌로 나중에 다시 살아날 수 있다.

무엇을 맡기고, 무엇을 맡기지 않을 것인가

기억의 탐지는 AI에게 맡겨도 좋다. 41건의 모순 찾기는 사람이 할 작업이 아니며, grep으로 나오지 않는 부분이 핵심이다. 반면 삭제 판단은 맡길 수 없다. 기억은 회사의 판단 기준 그 자체이며, 한 건이 사라질 때마다 이후 모든 세션의 출력이 조용히 변한다. 게다가 바뀐 것에 알아차리지 못한다.

점검(棚卸し)은 월 1회, 소요 시간은 약 20분 정도다. 하는 동안 아무것도 나오지 않는 작업이지만, 나에게는 AI가 내리는 판단의 품질을 유지하는 유일한 유지보수 과정이다. AI는 실행에 사용한다. 판단은 인간이 한다. 그리고 그 판단의 재료를 점검하는 시스템까지 구축해야만 비로소 안심하고 위임할 수 있다.

이번 글에서 다룬 운영의 전체적인 그림—CLAUDE.md 설계, 기억과 컨텍스트의 처리, 위임의 경계선—은 회사 자체적으로 실제로 구동하는 구현을 정리한 기술서에 작성되어 있다.

Discussion