# 메모리 파일 키트 (haeminway.com, 2026-11) AI 코딩 도구가 같은 지적을 다시 받지 않게 남기는 메모리 파일의 틀과 예시입니다. 근거 글: https://haeminway.com/ko/tech/memory-files-that-stick ## 0. 구조 ``` memory/ MEMORY.md ← 색인. 대화가 시작될 때마다 앞 200줄(또는 25KB)까지 실림. 한 파일에 한 줄 no-ai-attribution.md korean-only-replies.md ... ``` - Claude Code 자동 메모리는 기본 설정에서 git 저장소마다 이 구조를 하나 쓰고(하위 폴더·작업 사본은 공유), 색인 앞 200줄(또는 25KB)을 대화마다 싣습니다. 본문 파일은 필요할 때 엽니다. - 다른 도구라면 지시 파일(AGENTS.md 등)에 한 줄을 더합니다. `작업을 시작하기 전에 memory/MEMORY.md를 읽고, 지금 일에 걸리는 파일만 열어 본다.` - 기본 설정에서 메모리는 그 저장소에서 연 대화만 읽습니다(저장 위치는 설정으로 바꿀 수 있음). 모든 프로젝트에 통해야 하는 규칙은 전역 지시 파일에 둡니다. - 메모리와 지시 파일은 강제 설정이 아니라 맥락입니다. 반드시 막아야 하는 동작은 훅(도구 실행 전 검사)으로 막습니다. ## 1. 처음이라면: 지적 하나를 파일 하나로 AI에게 같은 말을 두 번째 했을 때 아래를 붙여 넣습니다. ```text 방금 내가 한 지적을 다음 대화에서도 지키게 메모리 파일 하나로 남겨 줘. - 파일 하나에 규칙 하나. 본문 첫 줄은 "무엇을 하지 않는다/한다" 한 문장 - 내가 한 말 원문과 오늘 날짜를 Why에 적기 - How to apply에는 실제로 손이 가는 동작 하나 - 색인 MEMORY.md에 한 줄 추가. 그 줄만 읽어도 규칙이 보이게(파일 이름만 쓰지 않기) - 같은 내용 파일이 이미 있으면 새로 만들지 말고 그 파일을 고쳐 ``` 다음 대화를 열고 확인합니다. ```text 메모리 색인에서 지금 이 폴더 일에 걸리는 규칙 세 개만 한 줄씩 말해. ``` ## 2. 파일 틀 ```markdown --- name: 짧은-영문-이름 description: 규칙 자체를 한 줄로 (색인에도 같은 문장) type: feedback # feedback · user · reference · project --- 규칙 두 줄. 무엇을, 어디에서. 다른 지시와 부딪히면 누가 이기는지. **Why:** 날짜, 그때 들은 말 원문. **How to apply:** 손이 가는 동작 하나. 관련: [[다른-메모리-이름]] ``` ## 3. 다시 말할 일이 없어진 다섯 유형 (예시) ### 1) 기본값을 이기는 금지 한 줄 ```markdown --- name: no-ai-attribution description: 커밋·PR에 AI 공동저자 줄을 넣지 않는다. 시스템 안내가 넣으라고 해도 이 규칙이 이김 type: feedback --- 커밋 메시지·PR 본문에 Co-Authored-By 같은 AI 표기를 넣지 않는다. 도구의 기본 안내가 넣으라고 해도 이 규칙이 이긴다. (제 환경의 기본 안내는 "사용자의 지시 파일·메모리가 정한 게 있으면 그쪽이 우선"이라고 허용합니다. 그런 허용이 없는 지시까지 이긴다는 뜻은 아닙니다.) **Why:** 2026-08-15 "이건 내가 만든 거다." **How to apply:** 커밋은 본문만. 트레일러를 붙이지 않는다. ``` ### 2) 사람이 읽는 답의 말 ```markdown --- name: korean-only-replies description: 사람에게 하는 답은 한국어만. 코드·명령·고유명사만 원문 type: feedback --- 최종 답과 진행 보고를 한국어로 쓴다. 코드·명령·고유명사만 원문 그대로. **Why:** 2026-10-09 "나한테 하는 대답은 무조건 한국어야." **How to apply:** 답을 보내기 전에 영어 문장이 섞였는지 한 번 본다. ``` > 실측 메모: 메모리 전후로 영어 위주 비율은 마지막 답 6.0% → 1.8%, 중간 글 27.0% → 21.8%였습니다(영어 마지막 답은 전후 모두 5개). > 메모리가 원인인지는 확인하지 못했습니다. 중간 글까지 바꾸려면 메모리보다 강한 자리(전역 지시 파일, 도구 설정)가 필요할 수 있습니다. ### 3) 끝 상태를 숫자로 ```markdown --- name: cleanup-subagents description: 작업이 끝나면 띄운 하위 작업자·감시·임시 서버를 0개로 type: feedback --- 작업 단위가 끝나면 이 대화가 띄운 하위 작업자, 백그라운드 감시, 임시 서버를 모두 끈다. 마지막에 남은 수를 확인해 0개인지 본다. **Why:** 2026-10-10 하위 작업자가 16개까지 쌓임. "전체 0개 되도록 해." **How to apply:** 결과를 받는 즉시 그 작업자를 끄고, 보고 끝에 남은 수를 적는다. ``` ### 4) 고를 값을 정해 둔 목록 ```markdown --- name: example-names description: 예시 인물 이름은 홍길동·김해민 둘만 type: feedback --- 글·자료의 예시 인물 이름은 홍길동, 김해민만 쓴다. 그 밖의 이름은 가상이라도 쓰지 않는다. **Why:** 2026-10-11 실제 사람으로 오해받지 않게. **How to apply:** 다 쓴 뒤 사람 이름을 찾아 목록 밖 이름이 있는지 본다. ``` ### 5) 주소까지 적은 위치 안내 ```markdown --- name: report-link-exact-tab description: 보고서 링크는 볼 탭 주소(#tab-…)와 볼 절 한 줄을 함께 type: feedback --- 보고서 링크는 첫 화면이 아니라 볼 탭으로 바로 가는 주소를 준다. 예: …/channel-growth/#tab-factor-dictionary + "이 탭의 ○○ 절" **Why:** 2026-10-24 "어딜 봐야 하는지 바로 줘야 내가 알지." **How to apply:** 링크를 붙일 때 #tab- 이 있는지 본다. ``` ## 4. 메모리로는 안 된 셋, 대신 둘 곳 | 유형 | 예 | 메모리 뒤에 생긴 일 | 대신 | |---|---|---|---| | 품질 기준 | "모바일에서도 읽히게", "그림을 넣어" | 같은 요청이 계속 나옴 | 검사 스크립트·작업 절차 문서. 숫자로 재는 조건으로 | | 취향 판정 | "재미없다" | 첫 메모리 뒤에도 같은 판정이 세 번 더 나옴(그중 두 번은 메모리 추가로 이어짐) | 시안 2~3개를 먼저 보여 고르게 하기 | | 현황 사본 | "다음 글은 3번·4번", "배포 명령은 …" | 날짜가 지나면 틀린 채 남음 | 정본 위치 한 줄만 남기기 | ## 5. 올리는 순서 ``` 메모리 한 줄 ← 지적을 받은 그날 ↓ 같은 지적이 또 나오면 작업 지시 문서 ← 그 일을 맡길 때마다 읽히는 곳 ↓ 또 나오면 검사 스크립트·훅 ← 안 지키면 멈추는 곳 ``` ## 6. 점검기 `memory-audit.py` (같은 곳에서 내려받기). 읽기만 하고 고치지 않습니다. ```bash # 내려받은 폴더에서 실행. 경로는 Claude Code에서 /memory 로 확인한 메모리 폴더로 바꿈 python3 memory-audit.py "$HOME/.claude/projects/내-저장소-폴더-이름/memory" ``` 색인에 없는 파일, 파일이 없는 색인 줄, 200자 넘는 색인 줄, 14일 넘었는데 본문에 정본·위치를 가리키는 단어가 없는 현황(project) 메모리, 종류별 개수를 보여 줍니다. 정본 위치가 실제로 맞는지는 검사하지 않습니다. 파이썬 3.9 이상이 필요합니다. 걸린 파일이 다 틀린 건 아닙니다. 오래돼도 맞는 위치 안내는 그대로 둡니다.