MadoHub에게 기억하는 법 가르치기
MadoHub 메모리 시스템 내부: 여섯 종류의 메모리, 페르소나와 프로젝트별 네임스페이싱, 그리고 에이전트가 배운 것은 인간이 먼저 보지 않으면 영구적이 되지 않는 이유.
모든 에이전트 세션은 0에서 시작합니다. 월요일에 Claude Code에게 프로젝트가 npm이 아닌 pnpm을 쓴다고 알립니다. 목요일의 세션까지는 그것은 사라집니다 — 다시 타이핑하지 않는 한, 또는 누군가 당신을 위해 잡아주지 않는 한.
그 "누군가"가 지난 몇 단계에 걸쳐 MadoHub에 만들어 넣은 것입니다: 채팅 히스토리 아래에 자리잡아 세션과 프로젝트에 걸쳐 살아남고, 에이전트에게 배운 것을 읽고 쓸 방법을 주는 메모리 시스템. 이 글은 그 시스템이 어떻게 형태를 갖추는지, 그리고 그 안의 가장 중요하다고 생각하는 하나의 설계 결정에 관한 것입니다: 추출된 메모리는 인간이 그렇다고 하기 전까지는 진짜 메모리가 되지 않습니다.
MadoHub이 다루는 방법
여섯 종류의 메모리
모든 메모리 항목은 종류를 가지며, 그 집합은 정확히 여섯 값으로 닫혀 있습니다:
| 종류 | 용도 |
|---|---|
preference | 확인된 사용자 선호 — "간결한 응답 선호" |
fact | 프로젝트에 대한 지속적이고 검증 가능한 사실 |
decision | 내려진 선택, 그리고 종종 그 이유 — "번들 크기 때문에 Electron 대신 Tauri 선택" |
pattern | 한 번 인코딩할 가치가 있는 반복 행동 |
postmortem | 무엇이 잘못되었는지, 그리고 다르게 할 것 |
event | 일어난 일, 일어났다는 것이 기억할 만한 것 |
일곱 번째 옵션이나 자유 형식 필드는 없습니다. 그것은 의도적입니다: Memory Dashboard는 종류로 필터하고 라벨을 붙이며, 빠져나온 "유령" 종류는 아무것도 제대로 검색하거나 표시할 수 없는 카테고리일 뿐입니다.
페르소나와 프로젝트별 네임스페이싱
메모리는 네임스페이스로 분할되어, 에이전트가 recall하는 것이 한정될 수 있습니다. persona: 네임스페이스는 메모리를 활성 페르소나에 묶고; workspace: 네임스페이스는 특정 프로젝트에 묶습니다. 에이전트가 네임스페이스를 지정하지 않고 메모리를 쓰면, 활성 페르소나가 기본값입니다. recall할 때 한 네임스페이스로 좁힐 수 있습니다 — 예를 들어 모든 페르소나의 것 대신 프로젝트의 메모리만 당겨오게 — 해서 recall이 관련 없는 프로젝트의 잡동사니를 떠오르는 대신 관련성을 유지합니다.
후보가 태어나는 세 가지 방법
에이전트가 명시적으로 메모리를 쓰는 것이 명백한 경로지만, 유일한 것은 아닙니다. MadoHub은 또한 대화를 백그라운드에서 지켜봅니다:
- 명시적 remember — 에이전트가 대화 중에 무언가 기억할 만하다고 결정하고 적습니다.
- 매 턴 후 — 가벼운 모델 패스가 마지막 교환에서 지속적인 것을 찾습니다, 대부분 기억할 만한 것은 의도적인 "이것 기억해" 순간이 아닌 일반 대화에서 떠오르기 때문입니다. 매 턴 실행되므로 설계상 더 시끄럽습니다.
- compaction 전 — 긴 대화 윈도우가 컨텍스트를 절약하기 위해 요약되기 직전, 같은 종류의 스캔이 압축될 메시지 위에서 실행됩니다. 이것은 compaction이 손실이 있기 때문에 중요합니다: 메시지 범위가 요약되어 사라지면, 거기서 추출되지 않은 것은 장기 메모리에서 영원히 사라집니다. 조용한 대화 구간은 하나의 저렴한 모델 호출을 드는 대가로 노이즈로 큐를 채우는 대신 아무것도 추가하지 않습니다.
Memory Dashboard에서의 수동 항목이 네 번째 경로를 마무리하며, 여전히 같은 후보 테이블을 거치지만, 모델이 추출한 것이 아닌 사람이 입력한 것입니다.
왜 자동 쓰기가 아닌 검토인가
이 시스템의 중심에 있는 설계 선택: 이들 네 경로 어느 것도 검색 가능한 메모리에 쓰지 않습니다. 모두 pending에서 시작해 approved 또는 rejected로 옮기는 — 또는 아무도 검토하지 않으면 30일 동안 손대지 않은 채로 있은 후 archived로 — 후보 큐에 놓입니다. 승인된 후보만 에이전트가 실제로 검색하는 메모리로 승격됩니다.
이것이 느리다고 생각하겠고, 의도적으로, 그렇습니다. 대안 — 모델의 "기억할 만큼 중요한" 것에 대한 판단이 매 미래 대화에 당겨지는 저장소에 직접 쓰게 두는 것 — 은 나쁜 추측이 한 번의 잘못된 답만 비용을 들이는 게 아닙니다. 그 메모리가 지금부터 recall될 때마다 잘못된 답을 비용으로 들이며, 누군가 에이전트가 사실이 아닌 것을 인용하는 것을 우연히 알아챌 때까지 조용히 복리로 쌓입니다. 그 위험은 가장 신뢰하고 싶은 바로 그 두 종류에서 가장 큽니다: postmortem과 decision 항목은 나중에 그것을 소비하는 것이 무엇이든 무겁게 가중치를 두는 경향이 있어, 오래되거나 잘못된 것은 없는 것보다 더 많은 피해를 줍니다.
검토는 설정 → 메모리에서 일어납니다 — 내용, 종류, 네임스페이스, 소스, 신뢰도, 그리고 동등한 후보가 몇 번 관측되었는지를 표시하며 승인 전 편집 또는 원래 턴으로 뛰어갈 수 있는 대기 큐 — 와 항목을 편집하거나 삭제할 수 있는 네임스페이스별로 묶은 승인 보기로 나뉩니다. 또한 옵트인 자동 승인이 있는 Advanced 섹션도 있습니다: 후보가 충분히 높은 신뢰도로 충분히 많이 관측되면, 수동 클릭 없이 스스로 승격될 수 있습니다. 그 정책은 기본적으로 꺼져 있습니다. 꺼둔 채로, 에이전트가 당신이 기억하길 원할 수 있다고 결정한 모든 것이 먼저 당신 앞을 지나갑니다 — 그것이 지금은 정확히 요점입니다.
실용적 안내
- 대기 큐를 정기적으로 훑으세요. 메모리는 승인되어야 도움이 되고, 30일 동안 손대지 않은 후보는 보관됩니다. 몇 세션마다 설정 → 메모리에서 빠르게 훑어 큐가 밀리지 않게 하세요.
- 승인 전에 편집하세요. 에이전트가 옳은 아이디어를 틀린 말로 잡았다면 — pnpm을 쓰는데 "npm을 쓴다" — 나중에 승인하고 고치는 대신 큐에서 고치세요. 승인된 메모리가 에이전트가 인용하는 것입니다.
- 네임스페이스로 한정하세요. 프로젝트 특정 팩트는
workspace:네임스페이스에 두어 관련 없는 프로젝트로 새어나가지 않게 하세요. 페르소나 수준 선호는persona:에. decision과postmortem을 조심하세요. 이들은 에이전트가 recall할 때 무겁게 가중치가 가중되어, 오래되거나 잘못된 항목이 없는 것보다 더 큰 피해를 줍니다. 애매한 후보를 승인하고 괜찮길 바라는 대신 거부하세요.- 자동 승인은 의미 있을 때만 켜세요. Advanced 설정은 높은 신뢰도로 자주 관측된 후보를 클릭 없이 승격할 수 있어, 편리하지만 인간 게이트를 제거합니다. 추출 품질을 신뢰할 때까지 꺼두세요.