Claude Code 메모리 시스템 - 대화 간 컨텍스트 유지하기

Claude Code를 처음 쓸 때 가장 답답했던 게 새 대화를 시작할 때마다 같은 얘기를 또 해줘야 한다는 점이었습니다. "나는 티스토리 블로그 운영자고, 글은 이런 톤으로 쓰고, 코드 블록엔 항상 언어 태그 붙여줘…" 같은 설명을요. 그러다가 메모리 시스템을 알게 됐는데, 한 번 알려준 사실을 다음 대화에서도 알아서 참고해 주니까 작업 속도가 확연히 달라졌습니다. 오늘은 이 메모리가 어떻게 동작하고 어떻게 활용하는지 정리해 보겠습니다.

개념 / 원리

Claude Code의 메모리는 프로젝트별로 저장되는 파일 기반 시스템입니다. 사용자 OS의 ~/.claude/projects/<프로젝트-경로>/memory/ 폴더에 마크다운 파일들이 쌓이는 구조예요. 윈도우라면 보통 다음 경로입니다.

C:\Users\<사용자>\.claude\projects\c--Users-<사용자>-Desktop-<프로젝트>\memory\

이 폴더 안엔 MEMORY.md라는 인덱스 파일과, 각각의 메모리 항목이 분리된 마크다운 파일들이 들어 있습니다. Claude는 대화를 시작할 때 MEMORY.md를 먼저 읽고, 필요하면 개별 파일을 추가로 열어서 컨텍스트를 채웁니다.

메모리는 네 가지 타입으로 나뉘어요.

타입	용도	예시
user	사용자 정보	"DBA로 일하는 5년차 개발자"
feedback	작업 방식 피드백	"응답 끝에 요약 붙이지 마라"
project	진행 중인 프로젝트 맥락	"5월부터 분기 리포트 자동화 작업 중"
reference	외부 시스템 위치	"장애 티켓은 Jira PROD 프로젝트에"

특히 헷갈리기 쉬운 게 메모리와 CLAUDE.md의 차이인데요, CLAUDE.md는 프로젝트 루트에 두는 일종의 안내문으로 코드 스타일이나 명령어 같은 변치 않는 지침이 들어가고, 메모리는 대화하면서 점점 채워지는 동적인 정보입니다. 둘 다 자동으로 컨텍스트에 들어가지만 성격이 달라요.

실전 예제

가장 단순한 사용법은 그냥 자연어로 "이거 기억해 줘"라고 부탁하는 겁니다.

사용자: 나는 잼잼테크라는 티스토리 블로그를 운영하고 있어.
        DB, 보안, Python 카테고리로 글을 쓰고, 글마다 도입부에
        실무 경험을 넣는 톤을 좋아해. 이거 기억해 둬.

Claude: [메모리에 user_blog.md 저장]
        기억해 뒀습니다. 다음 대화에서도 이 블로그 컨셉을 기준으로
        도와드릴게요.

이렇게 저장된 메모리는 다음에 새 대화를 시작해도 그대로 살아 있습니다. 직접 파일을 열어 보면 이런 식으로 들어 있어요.

---
name: user-blog
description: 사용자가 운영하는 티스토리 블로그 정보
metadata:
  type: user
---

잼잼테크 티스토리 블로그 운영자. DB/보안/Python 카테고리 중심.
글마다 도입부에 실무 경험·시나리오를 선호함.

피드백 타입은 작업 중 자연스럽게 쌓입니다.

사용자: 응답 끝에 "이렇게 도와드렸습니다" 같은 마무리 멘트 붙이지 마.
        그냥 결과만 보여줘.

Claude: [feedback_no_closing_remark.md 저장]

다음부터는 같은 지침을 반복할 필요가 없어집니다. 메모리 목록은 MEMORY.md를 열어서 직접 볼 수 있어요.

- [블로그 운영 정보](user_blog.md) — 잼잼테크 티스토리, DB/보안/Python 중심
- [응답 마무리 금지](feedback_no_closing_remark.md) — 끝맺음 멘트 빼고 결과만
- [분기 리포트 자동화](project_quarterly_report.md) — 6월 말 마감, Excel 출력

수정이나 삭제도 자연어로 됩니다. "그 응답 마무리 금지 규칙 지워줘"라고 하면 해당 파일을 지우고 MEMORY.md에서도 해당 줄을 빼줍니다.

주의할 점

가장 큰 함정은 메모리가 시간이 지나면 낡는다는 점입니다. 6개월 전에 "프로젝트 데드라인이 다음 주 화요일"이라고 저장해 둔 게 그대로 남아 있으면, 새 대화에서 Claude가 그 거짓 정보를 사실처럼 참고할 수 있어요. 특히 project 타입은 상태가 자주 바뀌니까, 가끔씩 MEMORY.md를 열어서 살아 있는 정보인지 점검하는 게 좋습니다.

두 번째 함정은 너무 세부적인 코드 패턴을 메모리에 넣는 것입니다. "이 프로젝트는 함수형 스타일을 쓴다" 같은 건 차라리 CLAUDE.md에 적어두는 게 맞아요. 메모리는 코드 자체보다는 사람·맥락·선호에 가까운 정보가 적합합니다.

세 번째는 민감 정보 저장입니다. 메모리 파일은 일반 텍스트로 디스크에 저장됩니다. API 키나 비밀번호, 내부 시스템 호스트명 같은 건 적지 마세요. 백업이나 동기화 폴더 안에 프로젝트가 들어 있으면 의도치 않게 클라우드에 올라갈 수 있습니다.

저는 메모리를 처음 쓸 때 모든 걸 다 기억시키려다가 MEMORY.md가 100줄 넘게 부풀어서 오히려 정확도가 떨어졌던 경험이 있는데요, 200줄 넘으면 뒷부분이 잘려서 컨텍스트에 안 들어간다고도 하니 인덱스는 80~120줄 안쪽이 적당합니다. 자주 쓰는 정보만 남기고 나머지는 정리하세요.

마무리

정리하면 세 줄입니다.

• 메모리는 프로젝트별 폴더에 파일로 저장되는 영속 컨텍스트, 4가지 타입(user/feedback/project/reference)이 있다.
• "기억해 줘", "잊어 줘"처럼 자연어로 관리하고, 파일을 직접 열어 수정할 수도 있다.
• 메모리는 낡는다. 정기적으로 MEMORY.md를 열어 점검하고, 민감 정보는 절대 적지 말 것.