Claude Code에는 대화에서 얻은 사실을 영구화하는 메모리 (Memory) 기능이 있습니다. "사용자의 취향이나 과거의 결정을 기억해 준다"고 하면 편리해 보이지만, 저는 업무 기반으로서 1개월 이상 운용한 결과, 메모리에는 원칙적으로 쓰지 않는다는 방침으로 정착했습니다. 사실, 규칙, 수치는 모두 리포지토리 내의 파일(CLAUDE.md, 각 폴더의 README, 운영 가이드)에만 기록합니다.

비엔지니어 1인 사장으로서 회사의 업무 거의 전부를 Claude Code에 맡기고 있는 입장에서, 이 판단의 이유를 언어화해 보겠습니다.

메모리를 그만둔 3가지 이유

1. 금방 오래된 정보가 된다

1인 기업의 실태는 매일 변합니다. 수강생 수, 다음 세미나 날짜, 운영 규칙, 진행 중인 의사결정. 메모리에 적은 순간에는 정확하더라도 다음 주에는 낡은 정보가 됩니다. 그리고 메모리는 작성한 본인(AI) 이외에는 점검할 타이밍이 없기 때문에, 오래된 사실이 조용히 계속 남게 됩니다.

2. 진위가 섞이면 전부를 의심하게 된다

메모리가 10개 있고 그중 2개가 오래되었다고 가정해 봅시다. 어떤 2개인지는 알 수 없습니다. 그러면 결국, 10개 전부를 파일과 대조하며 검증하게 됩니다. "가끔 틀리는 참조원"은 참조원으로서 기능을 하지 못합니다. 신뢰도가 일정 수준 이하로 떨어지는 시점에서 메모리는 1차 소스(Primary Source)의 지위를 잃습니다.

3. 리뷰할 수 없고 이력이 없다

이것이 엔지니어 관점에서는 가장 클지도 모릅니다. 파일에 적은 사실은 git의 diff에 나타나고, 커밋 이력이 남으며, 다른 세션에서도 동일한 것을 볼 수 있습니다. 메모리는 그 어느 것도 아닙니다. "AI가 무엇을 전제로 움직이고 있는가"가 버전 관리(Version Control) 밖에 있다는 것은 운영 측면에서 상당히 기괴한 일입니다.

대신 하고 있는 것: SSOT 운영

정본(Single Source of Truth)은 1개 파일로 고정한다: 요금은 이 파일, 표현 규칙은 이 파일, 소재 상태는 이 폴더와 같이 사실의 위치를 도메인별로 결정한다 -
실태가 변하면 정본을 그 자리에서 덮어쓴다: "메모리로 보정"하지 않는다. 파일이 항상 최신 상태를 유지한다 -
AI는 작업 전에 정본을 읽는다: 매번 파일을 읽으러 가는 비용을 지불하더라도, 최신 정전(Canon)에 직접 접한다

"같은 설명을 두 번 하게 되면, 그 자리에서 파일에 적는다"라는 운영 규칙과 세트로 가져가면, CLAUDE.md와 주변 문서들이 "회사를 잘 아는 오래된 직원의 머릿속"으로서 성장해 갑니다. 메모리 기능과의 차이점은, 그 머릿속이 전부 diff로 보이며 언제든 덮어쓸 수 있다는 점입니다.

예외는 "부패하지 않는 정보"뿐

메모리를 완전히 부정하는 것은 아닙니다. 다만 허용 범위는 극히 좁게 설정하고 있습니다.

• 프로젝트를 가로질러 항상 성립하는 환경 설정 수준의 정보 (언어 설정, 호칭 등)
• 사업의 진행 및 의사결정과 무관하며, 시간이 지나도 낡지 않는 것

반대로 "이것은 비교적 안정적인 규칙이니까"라는 판단으로 메모리에 적는 것은 위험합니다. 안정적으로 보이는 규칙일수록, 변했을 때 아무도 눈치채지 못합니다. 자신의 생각 자체가 변해간다는 전제에 서면, 사실의 위치는 "AI의 기억"이 아니라 "내가 리뷰할 수 있는 파일" 한 가지뿐이었습니다.

요약

• 메모리는 오래되거나, 진위가 섞이거나, 리뷰할 수 없다. 업무 사실의 위치로는 적합하지 않다.
• 사실, 규칙, 수치는 리포지토리 내의 SSOT 파일로. 변하면 그 자리에서 덮어쓴다.
• "같은 설명을 두 번 하면 파일에 적는다"로 문서를 키워나간다.
• 메모리에 적어도 좋은 것은 시간이 지나도 부패하지 않는 환경 설정 수준의 정보뿐이다.

CLAUDE.md 측의 설계론은 본체 블로그에 적어두었습니다: CLAUDE.md란 | AI에게 매번 같은 설명을 하지 않기 위한 "사내 헌법" 만드는 법

Discussion