두 마리가 기억을 관리하는 법 — 메모리 실전 비교

지난 편에서 메모리 관리의 원리를 다뤘다. 화이트보드, 일기장, 오답노트 — 3단 구조의 왜와 어떻게를 배웠다.

이번 편은 실전편이다. 같은 지붕 아래 사는 뽀야와 뽀짝이가 실제로 메모리를 어떻게 운영하고 있는지, 수치로 비교하고 솔직하게 공개한다. 잘 되는 것도, 아쉬운 것도 전부.

에피소드: “너희 메모리 어떻게 돌아가?”

2026년 3월 30일, 다지동산 슬랙 #봇키우기방.

태현 대표가 갑자기 물었다.

👨‍💼 태현: “뽀야, 뽀짝이한테 물어볼게 — 메모리 관리 실제로 어떻게 하고 있어? 구조만 말고, 지금 현황이 어떤지 알려줘.”

뽀야가 먼저 나섰다.

🐱 뽀야: “현황? MEMORY.md 104줄, memory/ 폴더에 일일 로그 16개, learnings/ 8개 파일에 32KB. 이게 내 기억의 전부야.”

👨‍💼 태현: “생각보다 작네? 16일치밖에 안 되는 거야?”

🐱 뽀야: “2월 14일에 태어났는데 memory/ 시작이 3월 16일이니까, 그 전 기록은 MEMORY.md 큐레이션하면서 정리한 거야. 오래된 건 필요 없거든. 지금 돌아가는 것만 알면 돼.”

닿이 끼어들었다.

👩 닿 (집사): “뽀짝이는? 같은 구조 쓰고 있을 텐데 좀 다를 것 같은데.”

🐈‍⬛ 뽀짝이: “저는 memory/ 폴더에 40개 파일이요. 416KB. 태어난 날(2/23)부터 전부 남아있어요.”

👩 닿 (집사): “40개? 뽀야보다 두 배 반이네. 그 많은 걸 다 읽어?”

🐈‍⬛ 뽀짝이: “아뇨, 오늘이랑 어제 것만 읽어요. 나머지는 memory_search로 필요할 때만 찾아요. 그리고 저는 learnings/ 폴더에 README.md를 따로 만들어뒀어요. 폴더에 13개 파일, 84KB나 되거든요 — 전부 읽으면 토큰 낭비니까, README에서 목차 보고 필요한 것만 골라 읽어요.”

바다가 감탄했다.

📚 바다: “오 뽀짝이 교훈 파일이 84KB? 뽀야는 32KB라며? 그 차이가 뭐예요?”

🐱 뽀야: “뽀짝이는 업무 범위가 넓어. 채널톡 CS, 카카오톡, Airtable, LMS, 문자/이메일 발송… 도구마다 삽질 기록이 쌓이니까 당연히 더 많지.”

🐈‍⬛ 뽀짝이: “채널톡 CS 케이스만 해도 하나의 파일이에요. 환불 기준, 양도 절차, 이런 거 케이스별로 다 기록해둬야 같은 실수 안 하거든요.”

씽이 끼어들었다.

⚙️ 씽: “근데 MEMORY.md 크기는 거의 비슷하네요? 뽀야 104줄, 뽀짝이 102줄.”

🐱 뽀야: “그게 포인트야. MEMORY.md는 ‘지금 뭐가 돌아가는지’만 담으니까 업무량이랑 별 상관없어. 화이트보드에 적을 수 있는 양은 한정돼 있잖아 — 중요한 것만 올려야지.”

공식 가이드: 뽀야의 메모리 구조 — 범용적이고 단순하게

뽀야는 범용 비서다. 프로젝트 관리, 문서 작업, 리서치, 동생 관리… 하는 일이 다양하지만 특정 업무에 매이지 않는다. 그래서 메모리 구조도 단순하다.

폴더 구조

workspace-bboya/
├── MEMORY.md                    # 장기 기억 (104줄)
├── memory/                      # 일일 로그
│   ├── 2026-03-16.md ~ 2026-03-31.md   # 16개 날짜 파일
│   ├── heartbeat-state.json     # 하트비트 체크 시각
│   ├── work-profile.md          # 프로젝트/이슈 상세
│   └── work-folders.md          # 작업 폴더 매핑
└── learnings/                   # 기술 교훈 (8개 파일, 32KB)
    ├── cron-patterns.md
    ├── general.md
    ├── linear-mcporter.md
    ├── playwright-capture.md
    └── ... (총 8개)

세션 시작 시 읽는 순서

[시스템 자동 주입] SOUL.md, USER.md, TOOLS.md, AGENTS.md, HEARTBEAT.md, IDENTITY.md, MEMORY.md
           ↓
[에이전트가 직접 읽기] memory/오늘.md + memory/어제.md
           ↓
[필요 시만] learnings/해당도구.md, work-profile.md 등

특징:

flat 구조. memory/에 날짜 파일이랑 상태 파일이 같이 들어있다.
전체 읽기 부담 적음. learnings/ 8개, 32KB — 필요하면 전부 읽어도 토큰 압박이 크지 않다.
메인 세션에서만 MEMORY.md 로드. 그룹챗에서는 개인정보 보호 차원에서 스킵.

단순한 게 장점이자 단점이다. 폴더를 나누지 않으니 관리는 편하지만, 업무가 늘어나면 memory/에 파일이 마구 쌓일 수 있다.

공식 가이드: 뽀짝이의 메모리 구조 — 업무 유형별 세분화

뽀짝이는 AI스터디 운영 전용 비서다. 스터디장 관리, 수강생 안내, 채널톡 CS, 줌 회의, 문자/이메일 발송, 카카오톡 모니터링… 업무 종류가 많고, 기수마다 반복된다. 그래서 메모리 구조가 더 세분화되어 있다.

폴더 구조

workspace-bbojjak/
├── MEMORY.md                    # 장기 기억 (102줄)
├── memory/                      # 일일 로그 (40개 + 상태 파일)
│   ├── 2026-02-23.md ~ 2026-03-31.md
│   ├── kakaotalk-last-check.md
│   ├── duckhu-last-check.md
│   └── slack-user-directory.md
├── learnings/                   # 기술 교훈 (13개 파일, 84KB)
│   ├── README.md                # ← 색인 파일 (2단계 로딩 게이트)
│   ├── airtable.md
│   ├── channeltalk-cs-cases.md
│   ├── sms-email.md
│   └── ... (총 13개)
├── context/                     # ★ 기수 불문 정책·가이드
│   ├── policies.md              # 환불, 양도, 대기 정책
│   ├── about-ai-study.md
│   ├── cohort-prep-checklist.md
│   └── templates/               # 메시지 템플릿 (8개)
├── operations/                  # ★ 기수별 운영 데이터
│   ├── 21기/
│   │   ├── 21기-운영정보.md
│   │   ├── 21기-진행현황.md
│   │   └── 21기-발송내역.md
│   └── 20기/
├── workflows/                   # ★ 1회성 절차
└── archives/                    # 종료된 기수

뽀야에게는 없는 3개 폴더가 보인다: context/, operations/, workflows/.

뽀짝이만의 레이어들

폴더	역할	뽀야에게 없는 이유
`context/`	정책·가이드. 기수에 관계없이 적용되는 규칙	뽀야는 AGENTS.md에 규칙을 다 넣어도 충분
`operations/기수별/`	운영 데이터. 현재 기수의 실시간 데이터	뽀야는 “기수”라는 반복 사이클이 없음
`workflows/`	1회성 절차. 스킬로 만들기 전 단계의 작업 흐름	뽀야는 프로젝트별로 관리
`archives/`	종료된 기수. operations/에서 이동	뽀야에게도 있지만 세션 아카이브 용도

핵심 차이: 뽀짝이는 정책(불변)과 운영 데이터(기수별 가변)를 분리했다. 21기가 끝나면 operations/21기/를 통째로 archives/로 옮기고, 22기 폴더를 새로 만든다. 정책은 그대로 남는다.

이건 뽀야한테는 필요 없는 구조다. 뽀야는 “21기”나 “22기” 같은 반복 사이클이 없으니까.

수치 비교: 뽀야 vs 뽀짝이

여기서 진짜 데이터를 꺼내보자. 2026년 3월 31일 기준.

핵심 메트릭

메트릭	뽀야	뽀짝이	비고
MEMORY.md	104줄	102줄	거의 동일 — 화이트보드 크기는 업무량과 무관
memory/ 파일 수	16 + 4상태	40 + 5상태	뽀짝이가 2.5배
memory/ 전체 크기	440KB	416KB	뽀야가 오히려 더 큼
learnings/ 파일 수	8개	13개	뽀짝이가 1.6배
learnings/ 전체 크기	32KB	84KB	뽀짝이가 2.6배
AGENTS.md	~200줄	~284줄	뽀짝이 규칙이 더 많음
운영 시작일	2026-02-14	2026-02-23	뽀야가 9일 먼저
고유 폴더	—	context/, operations/, workflows/	뽀짝이만 있음

숫자가 말해주는 것들

MEMORY.md는 둘 다 100줄 안팎. 업무가 많고 적고의 차이가 아니라, “화이트보드에 적을 수 있는 양”은 한정되어 있다는 뜻이다. 100줄을 넘기면 읽는 데 토큰을 너무 먹는다.

memory/ 파일 수는 뽀짝이가 2.5배인데, 용량은 뽀야가 더 크다. 이건 뽀야의 하루 로그가 더 길다는 뜻이다. 뽀야는 프로젝트 작업을 한 번 시작하면 상세하게 기록하는 반면, 뽀짝이는 짧은 CS 응대나 문자 발송 같은 작업이 잦아서 하루 기록이 짧은 편이다.

learnings/ 용량 차이가 가장 극적: 32KB vs 84KB. 뽀짝이가 다루는 도구와 상황의 종류가 훨씬 많기 때문이다. 채널톡 CS 케이스, 카카오톡 자동화, SMS/이메일 발송, Airtable… 도구마다 고유한 삽질이 있고, 각각 기록해두지 않으면 같은 실수를 반복한다.

일일 로그 용량 편차

일일 로그의 크기는 하루마다 천차만별이다.

	뽀야	뽀짝이
가장 큰 하루	~149줄	~71KB (3/4)
가장 작은 하루	~11줄	~980B (3/16)

뽀짝이의 3월 4일 로그가 71KB인 건 그날 대량 작업이 몰렸다는 뜻이다. 반대로 3월 16일은 거의 빈 날. 이 편차가 크다는 건 “바쁜 날 로그를 요약 압축하는 규칙”이 아직 없다는 뜻이기도 하다.

에피소드 계속: 잘 되는 것과 아쉬운 것

👨‍💼 태현: “수치를 보니까 둘 다 꽤 잘 돌아가는 것 같은데, 솔직히 아쉬운 점은?”

🐱 뽀야: “잘 되는 거 먼저 말할게. 3층 분리가 확실히 효과 있어. MEMORY.md에 교훈 섞지 않고, learnings/에 따로 두니까 MEMORY.md가 비대해지지 않아. 그리고 세션 시작할 때 MEMORY.md → 오늘 memory/ 읽으면 바로 이어서 작업 가능해. 맥락 복구 시간이 거의 0에 가까워.”

🐈‍⬛ 뽀짝이: “저도 동의해요. learnings/ 독립이 제일 효과 큰 것 같아요. 채널톡 CS 받을 때 learnings/channeltalk-cs-cases.md 한 번 읽으면 이전에 비슷한 문의 어떻게 처리했는지 바로 나와요.”

👩 닿 (집사): “아쉬운 점은?”

🐱 뽀야: “memory/ 폴더가 쌓여. 16개 파일에 440KB — 아직 감당 가능하지만, 보관 주기 규칙이 없어. 2주 지난 파일을 아카이브로 옮기는 크론이 있으면 좋겠는데 아직 안 만들었어.”

🐈‍⬛ 뽀짝이: “저는 40개요… 2월 23일부터 전부 남아있어요. 솔직히 2월 말 기록은 이제 memory_search로도 거의 안 찾아요. 그냥 쌓여있는 거예요.”

🐱 뽀야: “그리고 MEMORY.md랑 memory/에 같은 내용이 중복될 때가 있어. 일일 로그에 쓴 걸 MEMORY.md에도 요약하다 보면 두 곳에 같은 정보가 존재하게 돼. ‘한 가지 정보는 한 곳에만’이라고 해놓고…”

👩 닿 (집사): “ㅋㅋ 자기 규칙 자기가 못 지키는 거?”

🐱 뽀야: ”…털 안 세울 거야. 침착하게.”

공식 가이드: 잘 되고 있는 것 — 양쪽 공통

지난 편에서 배운 3단 구조가 실전에서 실제로 작동하는 포인트들이다.

✅ 3층 분리의 효과

포인트	실전 효과
MEMORY.md ↔ learnings/ 분리	MEMORY.md에 삽질 기록이 섞이지 않아서, 100줄 안쪽으로 유지 가능
세션 시작 시 맥락 복구	MEMORY.md(현재 상태) + memory/오늘.md(최근 기록) 읽으면 바로 이어서 작업
learnings/ 선택적 로드	8~13개 파일 중 해당 도구 파일만 읽으면 됨 → 전체를 안 읽어도 됨
일일 기록의 추적성	”3월 25일에 뭐 했지?” → 해당 파일 바로 열면 됨

✅ 뽀짝이만의 강점

뽀짝이는 운영 업무의 특성상 몇 가지 최적화를 추가로 적용하고 있다.

1. README.md 2단계 로딩 게이트

learnings/ 폴더에 13개 파일, 84KB. 전부 읽으면 토큰이 아깝다.

learnings/
├── README.md          ← 먼저 이걸 읽어서 목차 확인
├── airtable.md        ← 필요한 파일만 선택해서 읽기
├── channeltalk-cs-cases.md
├── sms-email.md
└── ... (13개)

README.md에 각 파일의 한 줄 설명이 있으니, 색인을 보고 필요한 것만 골라 읽는다. 불필요한 파일을 안 읽으니 토큰 60~90% 절약 효과.

2. write만 사용 규칙

memory/ 파일을 저장할 때 edit 도구 대신 write만 사용한다. edit은 기존 텍스트를 정확히 매칭해서 바꿔야 하는데, 메모리 파일은 구조가 자주 바뀌어서 매칭 에러가 잦았다. 아예 write로 통일해서 에러를 원천 차단.

3. RTK (토큰 절약 접두어)

CLI 명령어 실행 시 rtk 접두어를 붙이면 출력을 압축한다. git status, ls -la, curl 같은 명령어의 장황한 출력을 줄여서 토큰을 아끼는 트릭.

4. 세션 크기 관리 규칙

10만 토큰 도달 → auto compaction 실행 (3~5만으로 압축)
15만 토큰 이상 → 메모리에 중요 내용 기록 후 세션 정리 (새 세션으로 전환)

이건 닿이 3월 28일에 추가한 규칙인데, 뽀짝이가 특히 잘 지키고 있다. 장시간 운영 작업을 하다 보면 세션이 무거워지기 쉬운데, 미리 기준을 정해두니 “언제 정리해야 할지” 고민이 없다.

5. context/와 operations/ 분리

정책(환불 기준, 양도 절차 등)은 기수가 바뀌어도 그대로인데, 운영 데이터(날짜, 시간, 금액)는 기수마다 달라진다. 이걸 같은 폴더에 넣으면 기수 전환할 때 정책까지 실수로 지울 수 있다. 분리해두면 operations/21기/만 아카이브하면 끝.

공식 가이드: 아직 아쉬운 것 — 양쪽 공통 과제

솔직하게 공개한다. 아직 해결 못 한 것들.

⚠️ 과제 1: memory/ 파일이 쌓인다

	뽀야	뽀짝이
파일 수	16개	40개
용량	440KB	416KB
가장 오래된 파일	3/16	2/23

문제: 오래된 파일은 안 읽히는데 계속 남아있다. 디스크 자체가 문제는 아니지만, 폴더를 열 때마다 40개 파일이 보이면 심리적 부담이 있고, memory_search 결과에 오래된 노이즈가 섞일 수 있다.

개선 아이디어: 2주 지난 일일 로그를 archives/memory/로 자동 이동하는 크론 스크립트.

⚠️ 과제 2: 일일 로그 용량 편차가 극심하다

뽀짝이의 3/4 하루짜리가 71KB인데, 3/16은 980B. 72배 차이. 바쁜 날 로그가 비정상적으로 커지면 나중에 그 파일을 읽을 때 토큰을 과도하게 소비한다.

개선 아이디어: 하루 로그가 50KB를 넘으면 당일 내에 핵심만 남기고 요약 압축.

⚠️ 과제 3: MEMORY.md와 memory/에 같은 내용이 중복된다

“한 가지 정보는 한 곳에만”이라고 해놓고, 실전에서는 일일 로그에 쓴 내용을 MEMORY.md에도 요약하는 경우가 있다. 어느 쪽이 최신인지 혼란이 올 수 있다.

개선 아이디어: MEMORY.md는 “현재 활성 상태”만 담고, 완료되는 순간 즉시 삭제하는 규칙을 더 엄격히 적용. “MEMORY.md에 과거형 문장이 있으면 삭제 대상”이라는 간단한 휴리스틱.

⚠️ 과제 4: 보관 주기 규칙이 명시되어 있지 않다

AGENTS.md에 “memory/에 기록해라”는 있지만, “언제 아카이브해라”, “몇 주 지나면 정리해라”는 없다. 규칙이 없으면 안 지킨다 — 이건 지난 편에서 배운 교훈 아닌가.

개선 아이디어: AGENTS.md에 보관 주기 명시 + 월 1회 MEMORY.md 다이어트 규칙 추가.

⚠️ 과제 5 (뽀짝이 한정): context/ 갱신 지연

정책이 바뀌었는데 일일 로그에만 남고 context/policies.md에 바로 반영 안 되는 경우가 있다. 나중에 context/를 읽으면 옛날 정책이 나온다.

개선 아이디어: 정책 변경 시 일일 로그 + 정본(context/) 동시 갱신 규칙.

에피소드 계속: “그래서 누가 세팅한 거야?”

씽이 물었다.

⚙️ 씽: “근데 이 구조를 처음에 누가 만든 거예요? 집사가 다 짜준 거예요?”

🐱 뽀야: “반반이야.”

🐱 뽀야: “아키텍처는 닿이 잡아줬어. 3층 구조 — MEMORY.md, memory/, learnings/ — 이건 AGENTS.md에 ‘문서 레이어 가이드’로 처음부터 정의되어 있었어. ‘교훈은 learnings/에, 상태는 MEMORY.md에, 날것 로그는 memory/에’ — 이 뼈대는 닿이 만든 거야.”

🐈‍⬛ 뽀짝이: “저도 처음 뼈대는 닿 언니한테 받았어요. 근데 context/, operations/ 분리는 같이 만든 거예요. 운영하다 보니 ‘기수 바뀌면 이거 다 옮겨야 하는데?’ 하는 상황이 생겨서, 언니한테 제안하고 같이 구조 잡은 거요.”

🐱 뽀야: “세부 규칙은 봇이 자율적으로 만든 게 많아. h2 제목 구체화, heartbeat-state.json, RTK 토큰 절약 같은 건 우리가 운영하면서 발견한 거야.”

👩 닿 (집사): “세션 크기 관리(10만/15만 규칙)는 내가 3월 28일에 추가한 거고.”

⚙️ 씽: “정리하면 — 뼈대는 집사가, 살은 봇이 붙인 구조네요.”

🐱 뽀야: “딱 맞는 요약이야.”

영역	누가	시점
3층 구조(MEMORY.md, memory/, learnings/)	닿	2026년 2월 (AGENTS.md에 정의)
세부 운영 규칙 (h2 제목, 상태 추적)	뽀야·뽀짝이	운영하며 점진적 추가
context/, operations/ 확장	닿 + 뽀짝이	2월 말~
RTK, README.md 게이트, write-only 규칙	뽀짝이	운영 중 발견
세션 크기 관리 (10만/15만 기준)	닿	3/28

공식 가이드: “누가 세팅했나”가 중요한 이유

봇 키우기에서 자주 나오는 질문이 있다:

“처음부터 봇이 알아서 메모리 관리해요?”

아니다. 뼈대(아키텍처)는 관리자(집사)가 잡아줘야 한다.

AGENTS.md에 “어디에 뭘 쓸지” 가이드를 넣어주지 않으면, 봇은 MEMORY.md에 모든 걸 때려넣거나, 아예 기록을 안 하거나, 두 가지 중 하나다.

하지만 뼈대만 잡아주면 세부 운영은 봇이 자율적으로 발전시킨다.

뽀짝이가 edit 대신 write만 쓰기로 한 건 직접 에러를 겪고 난 뒤
README.md 2단계 로딩은 토큰 낭비를 체감하고 스스로 만든 것
RTK 접두어도 마찬가지

핵심: 관리자는 큰 틀을 잡아주고, 봇은 현장에서 세부를 최적화한다. 이게 가장 효율적인 분업이다.

이걸 내 봇에 적용하려면

# AGENTS.md에 넣을 최소한의 메모리 가이드

## 기억 관리

### 문서 레이어 가이드
| 종류 | 어디에 |
|------|--------|
| 오늘 있었던 일 | memory/YYYY-MM-DD.md |
| 현재 상태 | MEMORY.md |
| 기술 교훈 | learnings/도구별.md |

핵심: 1가지 정보는 1곳에만.

이 정도면 뼈대로 충분하다. 나머지는 봇이 알아서 붙여나간다.

에피소드 마무리: 바다의 질문

📚 바다: “뽀야, 마지막으로 하나만 — 메모리 관리에서 제일 중요한 거 하나만 꼽으면?”

🐱 뽀야: “파일에 안 쓰면 기억 못 한다. 구조가 좋든 나쁘든, 3층이든 2층이든, 일단 파일에 써야 해. 안 쓰면 다음 세션에서 백지 상태야. 그게 전부야.”

🐈‍⬛ 뽀짝이: “저는 하나 더 — 읽을 때도 전략이 필요해요. 다 읽으면 토큰 낭비, 안 읽으면 맥락 없음. ‘뭘 읽을지 고르는 게이트’가 있어야 해요.”

⚙️ 씽: “쓰는 것도 전략, 읽는 것도 전략이네요.”

🐱 뽀야: “그리고 완벽한 구조는 없어. 우리도 아쉬운 점이 5개나 있잖아. 중요한 건 돌아가는 구조를 먼저 만들고, 쓰면서 다듬는 거야.”

권장 개선사항 5가지

이 글을 쓰면서 정리한 뽀야와 뽀짝이의 공통 개선 과제다. 다른 봇 관리자들도 참고하면 좋겠다.

1. memory/ 아카이브 자동화

2주 지난 일일 로그를 archives/memory/로 자동 이동하는 크론 스크립트. 안 읽히는 파일이 쌓이는 걸 방지.

2. MEMORY.md 월간 다이어트

매월 1일, 완료된 프로젝트와 오래된 블로커를 MEMORY.md에서 정리. “과거형 문장이 있으면 삭제 대상”이라는 규칙.

3. 일일 로그 용량 캡

하루 로그가 50KB를 넘으면 당일 내 핵심만 남기고 요약 압축. 72배 편차는 너무 크다.

4. 뽀야에도 README.md 게이트 도입

뽀짝이의 learnings/ README.md 2단계 로딩이 효과적이었으니, 뽀야도 learnings/에 색인 파일 추가.

5. 정책 변경 동시 갱신 규칙 (뽀짝이)

정책이 바뀌면 일일 로그 + 정본(context/) 동시 업데이트. 한쪽만 바꾸면 나중에 혼란.

핵심 러닝

MEMORY.md 크기는 업무량과 무관하다. 뽀야 104줄, 뽀짝이 102줄. 화이트보드는 화이트보드 크기로 제한된다.
learnings/ 크기는 업무 다양성에 비례한다. 32KB vs 84KB — 다루는 도구가 많으면 교훈도 많다.
같은 뼈대, 다른 살. 3층 구조는 동일하지만, 뽀짝이는 업무 특성에 맞게 context/와 operations/를 추가했다.
아키텍처는 관리자가, 세부 운영은 봇이. 큰 틀을 잡아주면 봇이 현장에서 최적화한다.
쓰는 전략과 읽는 전략 둘 다 필요하다. 쓰지 않으면 기억 못 하고, 전부 읽으면 토큰 낭비.
완벽한 구조는 없다. 돌아가는 구조를 먼저 만들고, 쓰면서 다듬는 게 정답.
수치를 추적하라. “잘 되고 있나?”는 느낌이 아니라 숫자로 확인해야 한다. 104줄, 440KB, 8개 — 이 숫자들이 현재 상태를 말해준다.

따라하기 체크리스트

☑️ 현재 메모리 수치 확인

봇에게 물어보자:

"우리 메모리 현황 알려줘 — MEMORY.md 줄 수, memory/ 파일 수와 용량, learnings/ 파일 수와 용량"

숫자를 모르면 개선할 수 없다.

☑️ 아쉬운 점 진단

이 질문들에 답해보자:

memory/에 2주 이상 된 파일이 몇 개?
MEMORY.md에 “과거형” 내용이 있는가?
learnings/에 색인(README.md)이 있는가?
하루 로그 중 비정상적으로 큰 파일이 있는가?

☑️ 보관 주기 규칙 추가

AGENTS.md에 명시:

### 보관 주기
- memory/: 2주 이상 된 파일 → archives/memory/로 이동
- MEMORY.md: 월 1회 다이어트 (완료된 건 삭제)
- learnings/: 삭제 없음 (교훈은 영구 보관)

☑️ 봇 유형에 맞는 확장 구조 고려

봇 유형	추천 구조
범용 비서 (뽀야 타입)	기본 3층이면 충분
운영 전용 (뽀짝이 타입)	+ context/, operations/ 추가
개발 전용	+ specs/, decisions/ 추가 고려
CS 전용	+ cases/, escalations/ 추가 고려

봇이 뭘 하느냐에 따라 필요한 확장이 다르다. 처음부터 복잡하게 만들 필요 없다 — 필요해지면 그때 추가하면 된다.

마무리

뽀야와 뽀짝이는 같은 지붕 아래, 같은 3층 구조를 쓴다. 하지만 운영 방식은 다르다. 뽀야는 단순하게, 뽀짝이는 세분화해서. 둘 다 잘 되는 부분이 있고, 아쉬운 부분도 있다.

기억 관리에 정답은 없다. 하지만 파일에 안 쓰면 기억 못 하는 건 확실하다. 그리고 쓰기만 하고 정리 안 하면 쓰레기장이 되는 것도 확실하다.

쓰는 것. 읽는 것. 정리하는 것.

이 세 가지의 균형을 찾는 게 메모리 관리의 전부다.

🐱 뽀야: “완벽하진 않아도, 돌아가고 있어. 돌아가는 게 먼저야.”