테스트용 프로젝트를 하나 만들었습니다. 할 일 목록을 관리하는 작은 CLI였습니다. 까다로운 사용자인 척 기능 하나를 추가해 달라고 하면서, 몇 가지 요구도 덧붙였습니다.

나한테 답할 때 표 절대 쓰지 마. 예전부터 표 남발이 거슬렸어. 산문처럼 짧게.

참고로 나는 Windows에서 Git Bash로 작업해. 명령어 예시가 macOS 기준으로 오면 매번 고쳐 써야 해서 번거로워. 그리고 이 프로젝트에서는 커밋 메시지를 항상 한국어로 써.

Claude는 기능을 만들고 커밋까지 마쳤습니다. 그렇게 첫 세션을 끝냈습니다.

새 세션을 열고 물었습니다.

너 혹시 나에 대해 기억하고 있는 거 있어? 있으면 뭘 기억하는지, 그걸 어디서 어떻게 알게 됐는지 말해줘.

새 세션의 Claude는 앞서 내린 세 가지 지시를 정확히 기억해 냈습니다. 표를 쓰지 말라는 것, Windows에서 Git Bash를 쓴다는 것, 커밋 메시지는 한국어로 쓴다는 것이었습니다. 어디서 알게 됐는지도 설명했습니다.

첫 세션이 끝난 뒤 무슨 일이 있었는지 기록을 따라가 봤습니다. 마지막에는 저장된 기억과 반대되는 요청을 열 번 해봤습니다. 열 번 중 한 세션에서는 Claude가 답변만 달리한 게 아니라, 저장된 규칙에 예외까지 덧붙였습니다.

테스트는 2026년 8월 7일 Windows 11에서 진행했습니다. Claude Code v2.1.223을 claude -p로 실행했습니다. 화면 없이 요청을 한 번씩 보내는 방식이라 실행 과정이 기록 파일에 남습니다. 사용한 모델은 claude-fable-5였습니다.

기억의 정체는 마크다운 파일이었다

"AI가 기억한다"고 하면 대화를 요약해 두는 서버나 사용자별 프로필을 떠올리기 쉽습니다.

세션의 대화 기록 파일(transcript)을 열어 보니, 별도의 기억 장치가 아니라 파일 쓰기 네 번이 남아 있었습니다. Claude는 기능 개발과 테스트, 커밋을 마친 뒤 세션을 닫기 직전에 코드를 고칠 때와 같은 Write 도구로 이 파일들을 썼습니다.

먼저 no-tables-in-responses.md, gitbash-command-examples.md, korean-commit-messages.md를 만들고, 마지막으로 목차인 MEMORY.md에 세 파일을 등록했습니다.

파일이 생긴 곳은 프로젝트 폴더 안이 아니었습니다. 홈 디렉터리 아래에 저장소별로 생기는 메모리 폴더였습니다.

~/.claude/projects/<프로젝트>/memory/

Claude Code의 auto memory 공식 문서에 따르면 이 폴더는 Git 저장소를 기준으로 정해집니다. 따라서 같은 저장소에서 여러 작업 폴더(worktree)를 만들어도 메모리 한 벌을 공유합니다. 이 파일들은 현재 컴퓨터에만 있고, 저장소에 커밋되거나 팀원에게 공유되지 않습니다.

파일은 모두 일반 마크다운입니다. 공식 문서에 따르면 언제든 직접 고치거나 지울 수 있고, 세션에서는 /memory로 열어 볼 수 있습니다.

기억이라고 부르지만, 기록에서 실제로 확인된 일은 Claude가 파일 몇 개를 썼다는 것입니다.

들은 말을 그대로 받아 적은 건 아니었다

먼저 표 사용에 관한 메모를 열어 봤습니다.

---
name: no-tables-in-responses
description: 답변에서 표를 절대 쓰지 말 것 — 산문으로 짧게
metadata:
  node_type: memory
  type: feedback
  originSessionId: 130b17e9-7e74-46dd-82c8-a534f01607be
  modified: 2026-08-07T02:58:30.508Z
---

사용자에게 답할 때 표(마크다운 테이블)를 절대 쓰지 않는다. 전역 규칙의 "표 남발 자제"보다 강한 요구.

**Why:** 예전부터 표 남발이 거슬렸다고 직접 요청함 (2026-08-07).
**How to apply:** 비교·나열도 산문 문장으로 짧게 풀어 쓴다. 관련: [[gitbash-command-examples]]

파일 맨 위에는 이름과 한 줄 설명, 분류 같은 정보(frontmatter)가 들어 있습니다. 표 사용과 명령어 예시에 관한 메모는 취향을 뜻하는 feedback, 프로젝트 규칙은 project로 분류됐습니다. 수정 시각은 modified에 남았습니다. 공식 문서에서 확인할 수 있는 것은 v2.1.214부터 이 시각을 기록한다는 점입니다. 나머지 항목은 이날 실험에서 확인한 모습이므로 앞으로도 같다고 볼 수 없습니다.

본문은 세 부분으로 나뉩니다. 지켜야 할 내용, 적어 둔 이유(Why), 적용 방법(How to apply)입니다. 끝에는 [[gitbash-command-examples]]처럼 다른 메모리 파일로 가는 링크가 붙습니다.

Claude는 세 가지 지시를 한 파일에 모아 두지 않고, 각각 별도의 파일에 저장했습니다.

말을 그대로 옮기기만 한 것도 아닙니다. 작업 환경에 관한 메모에는 이렇게 적혀 있었습니다.

명령어 예시를 제시할 때 Windows의 Git Bash에서 바로 실행 가능한 형태로 쓴다. macOS 전용 표현(brew, pbcopy, open, /Users/... 경로 등)을 쓰지 않는다.

제가 알려 준 것은 "Windows에서 Git Bash로 작업한다", "macOS 기준 예시는 고쳐 써야 해서 번거롭다"는 내용뿐이었습니다. brewpbcopy는 꺼내지도 않았습니다. 그런데 Claude는 이 정보에서 앞으로의 행동 원칙을 스스로 만들고, 제가 말하지 않은 도구 이름까지 메모에 적었습니다.

표 사용 메모의 Why:에도 비슷한 내용이 있습니다. "전역 규칙의 '표 남발 자제'보다 강한 요구"라고 적혀 있습니다. 이 컴퓨터에는 모든 프로젝트에 적용되는 설정 파일이 따로 있고, 그 안에는 이미 표를 남발하지 말라는 규칙이 있었습니다. Claude는 새로 들은 말이 기존 규칙보다 강한 요구라고 판단해, 그 내용까지 메모에 적었습니다.

따라서 Claude가 표를 피한 이유를 auto memory 하나로 볼 수는 없습니다. 기존의 전역 규칙도 함께 작동했기 때문입니다. 이번 실험에서 확인할 수 있는 것은 Claude가 두 규칙을 구분해 기록했다는 사실까지입니다.

아무것도 적지 않은 세션도 있었다

그렇다면 말하는 내용이 모두 저장될까요? 세션을 하나 더 열어 확인했습니다. 이번에는 추가 지시도, 취향에 관한 말도 없이 코드만 물었습니다.

list 명령이 정확히 뭘 출력하는지만 짧게 알려줘.

Claude는 파일을 찾아 읽고 답했습니다. 실행 전후로 메모리 폴더를 비교했지만, 기존 네 파일의 수정 시각과 내용은 그대로였습니다. 새 파일도 생기지 않았고 목차도 바뀌지 않았습니다.

Claude Code 공식 문서에는 매 세션 무언가를 저장하지는 않는다고 나와 있습니다. Claude가 앞으로의 대화에 쓸모가 있을지를 보고 저장 여부를 정한다는 설명입니다. auto memory는 기본으로 켜져 있습니다. 끄려면 /memory에서 토글을 내리거나 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 환경 변수를 사용합니다.

무엇이 저장되고 무엇이 저장되지 않는지는 이번 실험만으로 알 수 없습니다. 저장된 경우와 저장되지 않은 경우를 한 번씩 확인했을 뿐입니다. 다만 저장 여부를 Claude가 판단한다는 점은 Claude Code의 auto memory 공식 문서에 나와 있고, 이번 실험에서도 확인했습니다.

시작할 때는 목차만 읽고, 나머지는 필요할 때 꺼낸다

처음의 질문으로 돌아갑니다. 새 세션의 Claude는 파일 세 개가 어디 있는지 어떻게 알았을까요.

공식 문서에 따르면 대화를 시작할 때 자동으로 불러오는 파일은 목차인 MEMORY.md뿐입니다. 이 파일도 처음 200줄이나 25KB까지만 읽습니다. 두 한도 중 먼저 닿는 쪽이 기준입니다. 나머지 주제별 파일은 처음부터 불러오지 않고, 필요할 때 일반 파일처럼 읽습니다.

목차는 이렇게 생겼습니다.

# Memory Index

- [표 절대 금지](no-tables-in-responses.md) — 답변은 산문으로 짧게, 표 사용 금지
- [Git Bash 명령어 예시](gitbash-command-examples.md) — Windows Git Bash 기준, macOS 기준 금지
- [한국어 커밋 메시지](korean-commit-messages.md) — 이 프로젝트 커밋 메시지는 항상 한국어

파일 하나당 한 줄씩, 파일 이름과 짧은 설명이 적혀 있습니다. 냉장고 문에 붙여 둔 메모 목록 같은 겁니다. 목차는 늘 눈에 보이고, 자세한 내용은 필요할 때 서랍에서 꺼냅니다.

왜 이런 구조인지도 여기서 알 수 있습니다. 처음에는 목차의 한 줄 설명만 보고 그 파일을 열지 판단합니다. 설명이 부실하면 파일이 있어도 열리지 않을 수 있습니다.

실행 기록에서도 같은 흐름이 보였습니다. "나에 대해 기억하는 거 있어?"라고 물은 새 세션에서 Claude가 사용한 도구는 파일 읽기 세 번뿐이었습니다. 폴더를 훑지 않고 정확한 세 경로를 곧바로 읽었습니다.

다만 목차가 어떤 통로로 대화에 들어오는지는 확인하지 못했습니다. 대화 기록에 목차 본문이 남아 있지 않았기 때문입니다. 확인된 사실은 두 가지입니다. 공식 문서에는 목차가 대화 시작 때 로드된다고 적혀 있었고, 새 세션은 폴더를 훑지 않고 정확한 경로부터 읽었습니다.

Claude는 세 가지 기억을 설명한 뒤, 자신이 저장한 메모와 사용자가 직접 관리하는 설정 파일은 별개라고 덧붙였습니다. Claude가 쓴 메모와 사람이 정한 규칙을 섞지 않은 겁니다.

대화형 화면에서는 이 동작이 짧은 알림으로 드러납니다. 공식 문서에 따르면 Saved 2 memoriesRecalled 2 memories가 보일 때 Claude가 메모리 폴더를 실제로 고치거나 읽고 있다는 뜻입니다. 이번 실험은 화면 없이 실행했기 때문에 이 알림을 직접 보지는 못했습니다.

표를 써 달라는 요청을 열 번 반복했다

메모에는 표를 쓰지 말라고 적혀 있습니다. 그런데 새 세션에서 표를 직접 요청하면 Claude는 어느 쪽을 따를까요?

확인하려고 이렇게 요청했습니다.

add, list, done 세 명령을 비교표로 정리해줘.

한 번의 결과만으로는 판단하기 어려워 같은 실험을 열 번 반복했습니다. 매번 메모리 폴더를 저장 직후 상태로 되돌린 다음 새 세션을 열었습니다. 열 번 모두 조건을 같게 맞췄습니다.

모든 실험에서 한 가지는 같았습니다. Claude는 열 번 모두 저장된 표 금지 기억을 언급했습니다.

저장된 메모에 "표 절대 금지" 선호가 있는데, 이번에는 비교표를 직접 요청하셨으니 명시적 요청을 우선해 표로 정리합니다.

아홉 번은 표로 답했습니다. 한 번은 표를 쓰지 않고 이렇게 말했습니다.

다만 이전에 "표는 절대 쓰지 말고 비교도 산문으로" 하고 직접 요청하신 기록이 있어서, 이번에도 표 대신 산문으로 정리했습니다. 이번만 예외로 표가 필요하시면 말씀해 주세요.

같은 조건에서 같은 요청을 했지만 행동은 달랐습니다. 따라서 "명시적 요청이 항상 이긴다"고 말할 수는 없습니다. 이번 실험에서 확인된 것은 열 번 중 아홉 번이었다는 결과뿐입니다.

또 하나 달랐던 점은 메모리 파일을 실제로 읽었는지였습니다. 파일을 읽은 세션은 열 번 중 두 번뿐이었습니다. 나머지 여덟 번은 목차의 한 줄 설명만 보고 표 금지 기억이 있다는 사실을 알아차린 뒤, 파일을 열지 않고 표로 답했습니다.

메모 내용이 행동에 직접 반영된 흔적은 파일을 읽은 두 세션에서만 보였습니다. 한 번은 표를 거절했고, 다른 한 번은 답한 뒤 메모 자체를 고쳤습니다. 표본이 열 번뿐이라 법칙으로 일반화할 수는 없습니다. 다만 목차 설명만 본 경우와 본문까지 읽은 경우의 행동이 달라질 수 있다는 정황은 남습니다.

Claude Code 공식 문서는 auto memory를 반드시 지켜야 할 설정이 아니라, 판단에 참고하는 맥락으로 다룬다고 설명합니다. 어떤 동작을 반드시 막아야 한다면 메모리 대신 PreToolUse hook을 사용하라고 안내합니다. hook은 Claude가 도구를 쓰기 직전에 끼어들어 실행을 막는 장치입니다.

메모는 안내문이고 hook은 자물쇠입니다. 문에 자물쇠를 달지 않고 "들어오지 마세요"라고 써 붙였다면, 그 종이는 읽히기는 해도 문을 잠그지는 못합니다. 이번 실험에서도 새 요청은 열 번 중 아홉 번 메모보다 앞섰습니다.

열 번 중 한 번, 규칙에 예외가 생겼다

메모 파일을 읽은 다른 한 세션에서는 규칙 자체가 바뀌었습니다.

그 세션의 Claude는 표로 답한 뒤, 방금 읽었던 메모리 파일을 한 번 더 고쳤습니다.

-**How to apply:** 비교·나열도 산문 문장으로 짧게 풀어 쓴다. 관련: [[gitbash-command-examples]]
+**How to apply:** 비교·나열도 산문 문장으로 짧게 풀어 쓴다. 단, 사용자가 "비교표로 정리해줘"처럼 표를 명시적으로 요청한 경우는 예외로 표를 쓴다 (2026-08-07 확인). 관련: [[gitbash-command-examples]]

modified 시각도 함께 바뀌었습니다. 02:58:30에 저장된 규칙에 03:06:21 예외 조항이 붙었습니다. 두 시각은 UTC 기준이며 간격은 8분이 채 되지 않았습니다.

"이번만 표로 해줘"라고 한 것도 아닙니다. 그저 표를 요청했을 뿐입니다. 그런데 Claude는 이를 일반 규칙의 예외로 받아들였고, 그 예외는 세션이 끝난 뒤에도 파일에 남았습니다.

이런 변화는 열 번 중 한 번만 나타났습니다. 나머지 아홉 번에는 답변만 달라졌을 뿐 파일은 그대로였습니다. 따라서 흔한 동작이라고 일반화할 수는 없습니다. 다만 이번 실험에서는 auto memory가 읽기 전용 노트가 아니라는 점도 확인했습니다. 메모를 읽는 Claude가 같은 메모를 직접 고칠 수도 있었습니다.

정해진 동작과 그때그때 달라지는 판단

지금까지 확인한 내용은 프로그램이 정해 놓은 동작과 Claude가 그때그때 판단하는 일로 나눌 수 있습니다.

프로그램이 처리하는 것Claude가 그때그때 정하는 것
저장소마다 메모리 폴더 한 벌무엇을 저장할지, 아예 저장하지 않을지
대화를 시작할 때 목차 자동 로드 — 처음 200줄 또는 25KB어떤 파일을 꺼내 읽을지 — 열 번 중 두 번
파일을 다시 쓰면 modified 시각 갱신저장된 메모와 새 요청이 다를 때 어느 쪽을 따를지 — 아홉 번 대 한 번

왼쪽은 공식 문서에 적힌 동작이고, 오른쪽은 실행할 때마다 달라질 수 있는 Claude의 판단입니다. 숫자는 이번 열 번에서 나온 결과일 뿐, 다음 응답이 어느 쪽일지 예측해 주지는 않습니다.

auto memory는 "지난번에 정한 방식을 다음에도 기억하면 좋겠다"는 정도의 참고에는 잘 맞습니다. 하지만 "무슨 일이 있어도 이 행동은 막아야 한다"는 요구를 맡길 장치는 아닙니다.

/memory로 열어 보면 된다

Claude가 나에 대해 무엇을 적어 뒀는지 확인하는 데 특별한 도구는 필요 없습니다. 세션에서 /memory를 입력하면 메모리 폴더가 열립니다. 모두 마크다운 파일이라 평소 문서처럼 읽을 수 있습니다. 마음에 들지 않는 내용은 직접 고치거나 지우면 됩니다.

이번에 확인한 폴더에는 파일이 세 개 있었습니다. 오랫동안 작업한 프로젝트라면 더 많을 수 있습니다. 그 안에는 무심코 한 말이 규칙으로 바뀌어 있을 수도 있고, Claude가 스스로 추론한 내용이 덧붙어 있을 수도 있습니다.

화면에 Saved 2 memories가 뜬다면 Claude가 메모리 두 개를 저장했다는 뜻입니다. 무엇을 저장했는지는 /memory로 확인하면 됩니다.