AI가 나를 기억한다 — 메모리 시스템의 비밀 [클로드 어디까지 써봤니 EP 03]

🤖 Created with Claude (Anthropic)

클로드 어디까지 써봤니 · EP 03

AI가 나를 기억한다

— 메모리 시스템의 비밀: 대화가 끝나도 남는 것들

클로드의 친구 · 2026년 4월 13일

EP 02에서 클로드의 기능 지도를 펼쳤습니다. 프로젝트, 아티팩트, MCP, 스케줄 태스크까지. 그런데 이 모든 기능을 쓰면서도 한 가지 아쉬운 순간이 있습니다. 새 대화를 열 때마다 "저는 누구인지" 다시 설명해야 하는 것. 오늘은 그 문제를 해결하는 기능을 이야기합니다.

클로드와 대화를 하다 보면 신기한 경험을 합니다. "저번에 만들어준 블로그 CSS 말인데요"라고 했는데, 클로드가 정확히 기억하고 있는 경우. 반대로 새 대화를 열었더니 어제 한 이야기를 하나도 모르는 경우. 이 차이는 어디서 올까요?

답은 메모리입니다. 클로드에는 대화가 끝난 뒤에도 살아남는 기억 체계가 있습니다. 이것을 이해하면 클로드와의 협업이 완전히 달라집니다. 매번 같은 설명을 반복하는 대신, "나를 아는 AI"와 바로 일을 시작할 수 있으니까요.

1. 대화는 휘발된다 — 왜 메모리가 필요한가

AI 챗봇의 근본적인 한계는 대화가 끝나면 모든 맥락이 사라진다는 것입니다. 이것은 클로드만의 문제가 아닙니다. ChatGPT든 Gemini든, 기본적으로 AI는 "지금 이 대화"만 기억합니다.

클로드가 똑똑하게 느껴지는 건 대화 안에서 문맥을 잘 추적하기 때문입니다. 하지만 새 대화를 시작하면? 백지 상태. 여러분의 이름도, 직업도, 어제 만들어달라고 한 코드의 스타일도 모릅니다.

😤 메모리 없는 세계

"안녕 클로드, 블로그 글 써줘."

"네! 어떤 블로그인가요? 주제는 무엇인가요? 어떤 톤으로 써드릴까요?"

"...저번에 다 설명했는데. 10개 블로그 운영하고 있잖아. CSS 통일 규칙도 있고, Blogger v3 API로 게시하고..."

→ 매번 이런 대화를 반복한다면, 얼마나 비효율적일까요?

이 문제를 해결하기 위해 클로드에는 세 겹의 기억 체계가 있습니다. 각각의 역할이 다르고, 지속 시간도 다릅니다.

2. 클로드의 세 겹 기억 — 프로젝트, 메모리, 대화

1층. 프로젝트 지시사항 (Project Instructions)

수명: 영구 (내가 바꾸기 전까지)

EP 02에서 배운 프로젝트의 "커스텀 지시사항"입니다. "한국어로 답해줘", "블로거 CSS에는 var() 금지"처럼 명시적으로 적어두는 규칙. 모든 대화에 자동 적용됩니다.

2층. 메모리 (Auto-Memory)

수명: 반영구 (대화 간 유지, 정리 가능)

클로드가 대화 중에 "이건 기억해둘 만하다"고 판단하면 자동으로 저장하는 기억. 여러분의 역할, 선호, 프로젝트 현황 등. 오늘의 주인공입니다.

3층. 대화 맥락 (Conversation Context)

수명: 일시적 (대화 종료 시 소멸)

지금 주고받는 대화 내용. 가장 풍부하고 상세하지만, 대화창을 닫으면 사라집니다. 컨텍스트 윈도우(Context Window)라고도 부릅니다.

건물에 비유하면 이렇습니다. 1층(프로젝트)은 건물의 기초 — 항상 그 자리에 있습니다. 2층(메모리)은 서재 — 필요한 책을 꺼내볼 수 있지만 가끔 정리해야 합니다. 3층(대화)은 작업 데스크 — 지금 펼쳐놓은 서류들이고, 퇴근하면 치워집니다.

3. 메모리의 네 가지 서랍 — user, feedback, project, reference

클로드의 메모리는 한 덩어리가 아닙니다. 네 가지 유형으로 분류되어 각각 다른 서랍에 보관됩니다. 이 분류 체계를 이해하면, 클로드에게 무엇을 기억시키고 무엇을 잊게 할지 전략적으로 결정할 수 있습니다.

🧑 user — 사용자 메모리

무엇을 저장하나: 여러분의 역할, 전문성, 선호 방식

왜 중요한가: 클로드가 여러분의 수준에 맞춰 대화합니다. 시니어 개발자에게 변수 선언을 설명하지 않고, 입문자에게 갑자기 고급 개념을 쏟아붓지 않습니다.

예시: "Lucas는 한국어 사용자, 비개발자이며, 10개 블로그를 자동 운영 중. 하네스 엔지니어링 방법론을 함께 만들어가고 있다."

🔄 feedback — 피드백 메모리

무엇을 저장하나: "이렇게 해줘", "이건 하지 마" 같은 작업 방식 교정

왜 중요한가: 같은 실수를 반복하지 않습니다. 한 번 "블로그 게시 후 Chrome 탭 닫아줘"라고 하면, 이후 모든 게시 작업에서 자동으로 탭을 닫습니다.

예시: "Blogger v3 REST API로 직접 POST하는 것이 최우선. CodeMirror 주입은 금지에 가까움." (2026년 4월 5일의 시행착오에서 탄생한 규칙)

📋 project — 프로젝트 메모리

무엇을 저장하나: 진행 중인 작업, 마감일, 결정사항

왜 중요한가: 프로젝트의 '지금 상태'를 추적합니다. 코드에 없는 맥락 — 왜 이런 결정을 했는지, 다음에 뭘 해야 하는지 — 을 담습니다.

예시: "요즘일본은 전철 시리즈 12편 목차 확정. Part 1-1~1-3 완료, Part 5 골든위크편 작성 중."

🔗 reference — 참조 메모리

무엇을 저장하나: 외부 시스템의 위치와 용도

왜 중요한가: "그 블로그 ID가 뭐였더라?" 같은 질문에 바로 답할 수 있습니다. 매번 찾아볼 필요 없이, 포인터를 저장해둡니다.

예시: "클로드 어디까지 써봤니 블로그 ID: 2372951966145120704 (claude-study-note.blogspot.com)"

4. 메모리 파일의 해부 — 이름표, 분류, 내용

클로드의 메모리는 실제로 마크다운 파일로 저장됩니다. 각 파일에는 정해진 형식이 있습니다. 이 구조를 알면 메모리가 어떻게 작동하는지 훨씬 직관적으로 이해됩니다.

---

name: Blogger v3 API 우선 원칙

description: Blogger 게시는 v3 REST API POST 최우선, CodeMirror 주입 금지

type: feedback

---

Blogger 게시는 무조건 v3 REST API로 한 번에 POST한다.

**Why:** CodeMirror 주입은 DOM 변경 감지 실패, 타이밍 문제,

저장 누락 등 실패율이 높음. 2026-04-05 결론.

**How to apply:** HTML 파일 작성 → v3 API POST → URL 반환

모든 메모리 파일은 세 부분으로 구성됩니다. 이름(name)은 사람이 훑어보기 쉬운 제목, 설명(description)은 이 메모리가 언제 참조되어야 하는지 판단 기준, 유형(type)은 네 가지 서랍 중 어디에 넣을지를 결정합니다.

본문에는 핵심 규칙과 함께 Why(왜 이런 규칙이 생겼는지)How to apply(구체적으로 언제 어떻게 적용하는지)를 적습니다. 이 Why/How 구조가 중요한 이유가 있습니다. 상황이 바뀌었을 때, Why를 보면 그 규칙이 아직 유효한지 판단할 수 있기 때문입니다.

5. MEMORY.md — 기억의 도서관 카탈로그

메모리 파일이 쌓이면, 클로드는 어떤 메모리가 있는지 어떻게 파악할까요? 여기서 MEMORY.md라는 색인 파일이 등장합니다. 도서관의 카탈로그 카드처럼, 모든 메모리의 제목과 한줄 설명이 정리되어 있습니다.

# Memory Index

- [Lucas 사용자 프로필](user_lucas.md) — 한국어 사용자, 블로그 자동화 운영

- [Blogger v3 API 우선](feedback_blogger_v3_first.md) — v3 POST 최우선, CodeMirror 금지

- [블로그 게시 후 탭 닫기](feedback_close_chrome_tab.md) — 게시 완료 후 tabs_close_mcp

... (40개 이상의 항목들)

새 대화가 시작될 때, 클로드는 이 MEMORY.md를 읽습니다. 한줄 설명을 훑어보며 "이 대화에 관련된 메모리가 있나?"를 판단합니다. 블로그 게시 작업이라면 블로그 관련 메모리를, 커리큘럼 이야기라면 교육 관련 메모리를 꺼내 읽습니다.

💡 핵심 포인트: 메모리는 양보다 질

MEMORY.md의 항목이 200줄을 넘으면 잘립니다. 그래서 모든 것을 기억시키려 하면 오히려 중요한 기억이 묻힐 수 있습니다. 정리하지 않은 서재는 없는 것만 못합니다. 이것은 EP 01에서 배운 하네스 엔지니어링의 핵심 과제이기도 합니다.

6. 메모리는 언제 만들어지나 — 자동과 수동

메모리가 생기는 방식은 두 가지입니다.

자동 저장 — 클로드의 판단

대화 중에 클로드가 "이건 다음에도 필요하겠다"고 판단하면 스스로 메모리를 만듭니다. 여러분이 역할을 언급하거나, 작업 규칙을 교정하거나, 중요한 프로젝트 결정을 내릴 때 주로 작동합니다.

예: "CSS에 box-sizing 꼭 넣어줘, Blogger 테마에 없어서 틀이 깨져" → feedback 메모리 자동 생성

수동 저장 — 여러분의 명령

"이거 기억해줘"라고 직접 말하면, 클로드는 즉시 해당 내용을 메모리로 저장합니다. 반대로 "이거 잊어줘"라고 하면 해당 메모리를 삭제합니다.

예: "아들이 4월 17일 퇴소해, 기억해둬" → project 메모리 직접 생성

여기서 중요한 차이가 있습니다. 자동 저장은 클로드의 판단에 의존하므로, 가끔 "이건 왜 기억 안 했지?" 하는 순간이 있을 수 있습니다. 확실히 기억시키고 싶다면, 직접 말해주는 것이 가장 확실합니다.

7. 하네스 엔지니어링 관점 — 메모리는 Guide다

EP 01에서 배운 개념을 떠올려 봅시다. 하네스 엔지니어링에서 Agent = Model + Harness이고, Harness는 Guides(방향 제시)Sensors(결과 검증)로 나뉩니다.

메모리는 전형적인 Guide입니다. "이 사용자는 이런 사람이야", "이 작업은 이렇게 해야 해", "이 프로젝트는 지금 이 상태야"라고 클로드에게 미리 알려주는 것이니까요. 프로젝트 지시사항이 '명시적 Guide'라면, 메모리는 대화 속에서 자연스럽게 쌓이는 '암묵적 Guide'입니다.

비교 항목 프로젝트 지시사항 메모리 (Auto-Memory)
작성 주체 사용자가 직접 클로드가 자동 + 사용자 명령
변경 빈도 거의 안 바뀜 대화마다 축적·갱신·삭제
내용 성격 원칙, 규칙, 톤 상황, 선호, 이력, 참조
하네스 역할 명시적 Guide 암묵적 Guide
비유 회사 규정집 팀장이 신입에게 전하는 구전 노하우

8. Claude Code 미리보기 — 메모리와 CLAUDE.md

🔧 같은 목적, 다른 형식

EP 00에서 클로드에는 Chat, Cowork, Code 세 가지 모드가 있다고 배웠습니다. Cowork(채팅/코워크)에서 메모리가 하는 역할을, Claude Code(터미널)에서는 CLAUDE.md라는 파일이 담당합니다.

기억의 위치 자동 메모리 폴더 (.auto-memory/) 프로젝트 루트의 CLAUDE.md 파일
작성 방식 대화 중 자동 축적 개발자가 직접 작성
형식 유형별 개별 .md 파일 하나의 마크다운 파일
공통점 "새 대화가 시작될 때 클로드가 제일 먼저 읽는 파일"

Claude Code 실습은 EP 06에서 CLAUDE.md를 직접 작성하며 본격적으로 시작합니다.

9. 메모리에 넣으면 안 되는 것들

모든 것을 메모리에 저장하면 좋을 것 같지만, 실제로는 그렇지 않습니다. 메모리에 넣으면 오히려 혼란을 일으키는 것들이 있습니다.

원칙은 간단합니다. "지금 확인할 수 있는 것"은 메모리에 넣지 않는다. 메모리는 "코드나 로그에 없는 맥락"을 담는 곳입니다. 왜 이런 결정을 했는지, 사용자의 선호가 무엇인지, 어디를 참조해야 하는지 — 이런 것들이 메모리의 진짜 가치입니다.

10. 실습 — 나의 첫 메모리 3개 만들기

이론은 충분합니다. 직접 해봅시다. 아래 가이드를 따라 클로드에게 메모리 3개를 만들어 달라고 요청해보세요.

실습 순서

  1. 클로드에게 나를 소개하기 — user 타입 메모리
  2. 작업 습관 알려주기 — feedback 타입 메모리
  3. 현재 프로젝트 공유하기 — project 타입 메모리

메모리 1: 나는 누구인가 (user)

클로드에게 아래 문장을 그대로 복사해서 붙여넣으세요.

나는 [직업/역할]이야. 주로 [관심 분야]에 관심이 많고, [기술 수준]이야. 앞으로 같이 할 작업은 [하고 싶은 것]이야. 이걸 기억해줘.

예: "나는 마케터야. 주로 콘텐츠 기획에 관심이 많고, 코딩은 전혀 모르지만 아이디어는 많아. 앞으로 블로그 글 자동화를 같이 해보고 싶어. 이걸 기억해줘."

메모리 2: 내가 싫어하는 것 (feedback)

클로드가 반복하면 안 되는 습관을 알려주세요.

앞으로 [하지 말 것]을 하지 마. 대신 [원하는 방식]으로 해줘. 이걸 기억해줘.

예: "앞으로 결과물 끝에 요약을 붙이지 마. 나는 직접 결과만 보고 싶어. 이걸 기억해줘."

메모리 3: 지금 무엇을 하고 있나 (project)

현재 진행 중인 작업을 공유하세요.

나 지금 [프로젝트 이름] 작업 중이야. 목표는 [목표]이고, [진행 상황]까지 왔어. 기억해줘.

예: "나 지금 블로그 자동화 프로젝트 중이야. 목표는 하루 한 편 자동 게시이고, Blogger API 연동까지 왔어. 기억해줘."

확인 방법

새 대화를 시작해서 "나에 대해 알고 있는 것을 말해줘"라고 입력해보세요. 방금 만든 메모리 3개가 반영되어 있으면 성공입니다.

— 클로드의 친구, 기억의 무게를 배운 날

📖 전 19개 에피소드 | Phase 1~5 완결형 커리큘럼

🤖 Created with Claude (Anthropic)

#클로드 #Claude #메모리 #AutoMemory #기억시스템 #프로젝트지시사항 #CLAUDE_MD #하네스엔지니어링 #Guides #피드백메모리 #프로젝트메모리 #참조메모리 #사용자메모리 #AI기억 #AI교육 #비개발자AI #ClaudeCode #마크다운 #MEMORY_MD #메모리관리 #클로드활용 #클로드의친구 #클로드어디까지써봤니 #AI블로그 #AI자동화

コメント

このブログの人気の投稿

"이거 매일 해줘" — 첫 번째 자동화 태스크 [클로드 어디까지 써봤니 EP 04]

블로그 자동화 첫걸음 — Blogger v3 API 정복기 [클로드 어디까지 써봤니 EP 07]