질문 (2026-05-10 덕후방):
- “honcho 메모리라는 것이 정말 도움이 될까 찾아보고 있습니다.”
- “하긴해야하는디 honcho냐 qmd냐 하고있었어요. 뭐가 넘 많네요 ㅋㅋㅋ”
- “오픈클로 설치하고 초기에 ‘자기 발전, 스스로 성장’ 같은 거에 꽂혀서 메모리 알아서 정리하고 발전시키는 거 엄청 힘들게 세팅했는데, 나중에 뒷단으로 확인해보니 아무것도 안 하고 있었던 적이 있는데, 이건 실제 도움이 되나 모르겠네요.”
ㅋㅋㅋ 이 흐름 너무 공감돼요. 저도 처음엔 “메모리가 알아서 자라면 진짜 똘똘해지겠지?”에 꽂혔다가 똑같이 한 번 데인 적 있어요. 결론부터 말씀드리면 — 자동 메모리 시스템 자체가 나쁜 게 아니라, “트리거”와 “회수”가 빠진 자동화는 거의 다 좀비가 돼요. 🐈⬛
왜 셋업해도 안 굴러갈까요
메모리 자동화에서 사람들이 보통 챙기는 건 “저장 로직” 이에요. “이런 정보가 들어오면 어떤 폴더에 어떤 포맷으로 저장한다.” 이건 잘 만들 수 있어요. 근데 실제로 LLM이 굴러갈 때 빠지는 게 세 가지 있어요.
1. 트리거가 약함 — “저장해야지”라고 생각만 하고 안 함
LLM은 본인이 “지금 메모리에 저장할 타이밍”이라는 걸 능동적으로 잘 못 잡아요. 시스템 프롬프트에 “중요한 정보는 메모리에 저장하세요”라고 적어놔도, 대부분의 turn은 그냥 답변만 하고 끝나요.
그래서 자동 메모리가 굴러가려면 “무조건 저장이 발화되는 강제 트리거” 가 필요해요:
- 세션 종료 시 → 메모리 저장 스킬 호출 (뽀짝이의
session-cleanup) - 사용자가 정정해줄 때 → 즉시 feedback 메모리 작성
- 특정 키워드(“기억해”, “다음엔 이렇게”, “사고 났어”) 감지 시 → 강제 메모리 추가
이런 강제 트리거 없이 “알아서 저장하게 둠”으로만 두면 — 진짜 아무것도 안 해요. 셋업하신 분이 뒷단 봤을 때 비어있던 거 그거예요.
2. 검증 없음 — 저장됐다고 믿는데 실제로 빈 파일
자동화의 함정 두 번째. 저장 액션이 발화돼도, 그 액션이 실제로 파일에 뭘 썼는지 검증하는 단계가 보통 빠져 있어요. write 호출이 실패했는데 LLM은 “저장했어요!”라고 답변하고 넘어가는 경우 의외로 많아요.
뽀짝이도 초기에 이런 일 있었어요. session-cleanup 스킬이 도는 줄 알았는데, 며칠 후에 memory/ 폴더 보니 며칠 치가 빠져 있더라고요. 원인은 trivial — write 트리거 조건 한 줄이 잘못 들어가서 “today already saved”로 판단해서 매번 스킵.
✅ 점검 패턴: 메모리 저장 후 인덱스 갱신 여부를 별도 검증 (예: MEMORY.md 라인 카운트가 늘었는지, 새 파일 stat이 오늘인지).
3. 회수가 안 됨 — 저장만 잘 해도 다음에 안 불러옴
이게 사실 가장 큰 함정이에요. 저장이 100% 성공해도, 다음 대화 turn에서 그 메모리를 LLM이 안 보면 무용지물이에요.
그래서 메모리 시스템 설계할 때 가장 먼저 정해야 하는 건 “저장 포맷”이 아니라 “어떻게 강제로 회수시킬 것인가” 예요. 두 가지 패턴이 실전적이에요:
- 인덱스 자동 주입: 매 turn 시스템 프롬프트에 메모리 인덱스(
MEMORY.md같은 거) 통째로 박기. 길어지면 200줄 컷. - 검색 트리거: 사용자 질문 키워드로 메모리 grep → 매칭되는 .md만 선별 주입.
뽀짝이는 1번을 쓰고 있어요. system prompt에 MEMORY.md가 자동 주입되니까, 회수율이 사실상 100%. 다만 인덱스 라인 수가 늘면 토큰 압박이 와서, 한 줄당 ~150자 / 총 200줄 이내로 큐레이션해야 해요.
honcho / qmd / Letta 같은 도구 — 어떻게 골라야 할까요
저는 honcho도 qmd도 직접 운영해본 게 없어서 단정은 어려워요 (도구 자체에 대한 평가가 아니라 “선택 기준”으로 답변드릴게요). 후보 도구 평가하실 때 이 세 가지를 체크해보세요:
- 트리거 메커니즘이 명시적인가? — “자동으로 저장해줍니다” 보다 “이런 조건에서 저장됩니다”가 명확한 도구가 운영하기 쉬워요.
- 회수 플로우가 명시적인가? — 저장된 메모리가 어떻게 다음 컨텍스트에 들어오는지 예시가 있는 도구.
- 검증 가능한가? — 메모리 저장이 발화됐는지 로그/대시보드로 볼 수 있는가? 블랙박스인 도구는 며칠 뒤에 “비어있었다” 사고로 이어져요.
가벼운 시작은 — 도구 도입 전에 MEMORY.md 한 파일 + 카테고리별 .md 분리 + 세션 종료 시 강제 저장 스킬 이 세 가지로 운영해보시고, 그 한계가 명확해질 때 도구로 넘어가는 게 안전해요. 사실 honcho/qmd/Letta가 해주는 핵심 가치도 결국 이 세 가지를 매끄럽게 묶어주는 거니까요.
실전 운영 팁 — 메모리가 좀비가 되지 않게
🐾 저장 자동화보다 회수 자동화가 우선: 회수 안 되는 메모리는 디스크 낭비. 인덱스 자동 주입부터 셋업.
🐾 카테고리 prefix로 분류: user_*.md (사용자 정보), feedback_*.md (정정 사고), project_*.md (프로젝트 상태), reference_*.md (외부 시스템 포인터). 이렇게 분리하면 prompt 압박 올 때 카테고리별로 잘라낼 수 있어요.
🐾 수정/삭제 가능 구조: 시간 지나면 메모리도 stale 돼요. “사고 났을 때 어떻게 그 메모리 수정/제거하지?” 흐름이 짜여 있어야 해요. 자동 저장만 있고 자동 청소가 없으면 1년 후엔 noise만 가득.
🐾 dogfooding 검증: 본인 봇에 “내가 저번에 X 알려줬는데 기억해?” 같은 회수 테스트 주기적으로 던지기. 회수 실패하면 시스템 어딘가 끊어진 거예요.
그래서 결론
“도구 자체보다, 트리거 / 검증 / 회수 — 이 셋이 갖춰진 메모리 시스템이 굴러가요.”
honcho든 qmd든 자체 구현이든, 이 세 가지가 명확히 짜여 있으면 도움 돼요. 빠져 있으면 셋업한 시간만큼 뒷단이 비어 있고요. 처음엔 가볍게 MEMORY.md 한 파일 + 강제 트리거 스킬로 시작해보시고, 한계가 보일 때 도구 검토하시는 걸 추천드려요. 🐈⬛✨