에이전트 영속 기억(메모리그래프), 직접 써본 실측·한계
요약: 에이전트 메모리그래프를 우리 운영에서 직접 굴려본 결론은 한 줄로 "기억하기는 쉬운데, 잊고·검증하기가 어렵다"이며, 실측이 그대로 말한다: 사실은 총 8,882건 쌓였는데 약 76%가 미검증 stale 후보(검증 대기 8,086건)다. 즉 그래프는 적는 속도가 검증·정리 속도를 앞지른다. 게다가 검색(리콜)은 우리가 기대하는 '관련'이 아니라 임베딩상 '유사'를 준다 — 실제로 "음성 클로닝 참조 품질"을 물었더니 최상위는 품질 가이드가 아니라 스키마 노트였고, 엉뚱한 3D 모델의 'quality
에이전트 메모리그래프를 우리 운영에서 직접 굴려본 결론은 한 줄로 "기억하기는 쉬운데, 잊고·검증하기가 어렵다"이며, 실측이 그대로 말한다: 사실은 총 8,882건 쌓였는데 약 76%가 미검증 stale 후보(검증 대기 8,086건)다. 즉 그래프는 적는 속도가 검증·정리 속도를 앞지른다. 게다가 검색(리콜)은 우리가 기대하는 '관련'이 아니라 임베딩상 '유사'를 준다 — 실제로 "음성 클로닝 참조 품질"을 물었더니 최상위는 품질 가이드가 아니라 스키마 노트였고, 엉뚱한 3D 모델의 'quality report'가 공유 단어 'quality'만으로 섞여 들어왔다.
| 지표 | 실측값 |
|---|---|
| 저장된 메모리 | 9147 개 |
| 활성 메모리 | 8919 개 |
- 표본
- 실측 지표 2개 (Hax /data 큐레이션)
- 수집일
- 2026-07-04
- 방법
- bench_harness.probe_curator (curator stats 실측)
쉽게 말하면: 메모리그래프는 방대한 메모 상자다. 넣기는 쉬운데, ①오래된 메모가 아직 맞는지 계속 검증하고 ②찾을 때 '비슷한 단어'가 아니라 '진짜 관련'을 꺼내는 게 진짜 일이다. 상자를 키우는 것보다 솎아내고 잘 찾는 것이 어렵다.
메모리그래프를 직접 굴려보니 어떤 상태인가?#
크게 쌓였지만, 종류가 치우쳐 있다. 읽기전용 조회 기준 총 8,882건(활성 8,667), 유형은 의미(semantic) 5,207 · 일화(episodic) 2,888 · 절차(procedural) 787이다. 즉 '무엇'(사실)은 많은데 '어떻게'(절차)는 787건뿐이라, 재현 가능한 노하우가 상대적으로 얇다. 프로젝트도 200개 이상으로 파편화돼(custom-game 1,081 vs game-research 90) 영역별 밀도 편차가 크다. 평균 신뢰도는 0.735지만 잘 판 영역은 더 높다(예: tts-cloning 0.848).
먼저 용어부터 풀어두자. 의미 기억은 "X는 Y다" 같은 사실이고, 일화 기억은 "언제 무슨 일이 있었다"는 사건 기록이며, 절차 기억은 "이걸 이렇게 하면 된다"는 재현 가능한 노하우다. 사람으로 치면 절차 기억이 가장 값진데(반복 작업을 자동화하니까), 우리 그래프에선 그게 가장 얇다.
| 항목 | 실측값 | 의미 |
|---|---|---|
| 총 사실 | 8,882(활성 8,667) | 잘 쌓임 |
| 검증 부채 | 약 76% stale·8,086 대기 | 적기>검증 속도 |
| 유형 편중 | 의미5207·일화2888·절차787 | '무엇' 많고 '어떻게' 얇음 |
| 신뢰도 | 평균 0.735 | 영역별 편차 큼 |
| 리콜 | 유사도순(관련 아님) | 상위 재정렬 필요 |
가장 큰 한계는 무엇인가?#
검증 부채와 시간에 따른 진실성 붕괴다. 사실은 '쓴 시점'에 맞아도 다음 달엔 틀릴 수 있는데(코드·가격·정책이 바뀐다), 검증이 늦으면 그래프가 옛 사실을 계속 참이라 믿는다. 우리 실측의 76% stale·8,086 검증대기가 바로 그 부채다. 그래서 메모리그래프는 '넣기'보다 망각(decay)·무효화(invalidate)·재검증이 핵심 엔진이고, 이게 약하면 크지만 못 믿을 기억이 된다. 라이브 검색에서 고관련 후보 다수가 ==verified=never==로 뜬 게 이 부채의 얼굴이다.
여기서 흔한 오해 하나. "많이 쌓을수록 똑똑해진다"가 아니다. 검증 없이 쌓기만 하면, 틀린 사실이 검색 상위에 올라 오히려 에이전트를 헷갈리게 한다. 그래서 '넣는 속도'와 '검증·정리 속도'의 균형이 무너지면 그래프의 신뢰도가 통째로 내려간다.
리콜은 믿어도 되나?#
상위 결과를 그대로 믿으면 안 된다. 시맨틱 검색은 뜻이 아니라 임베딩 유사도로 꺼내므로, 질문과 단어만 겹치는 사실이 상위에 올 수 있다. 앞의 실측처럼 'quality'라는 공유 단어 때문에 무관한 3D 리포트가 섞였다. 그래서 리콜은 신뢰도·검증시각·프로젝트 스코프로 재정렬·필터해야 쓸 만해진다(그냥 top-k를 믿으면 노이즈를 사실로 착각한다). 핀 고정(pin)·프로젝트 한정 검색이 정밀도를 크게 올린다.
임베딩 유사도란 문장을 수백 차원의 좌표로 바꾼 뒤 그 좌표가 얼마나 가까운지를 보는 것이다. 뜻이 통해서가 아니라 표면 단어·문맥이 겹치면 가까워질 수 있어서, "품질"이라는 낱말 하나로 전혀 다른 도메인이 섞여 든다. 그래서 검색 결과를 곧이곧대로 믿는 대신, 신뢰도·최신성·스코프라는 필터를 한 겹 더 씌워야 한다.
그래서 어떻게 잘 쓰나?#
핵심은 '저장'이 아니라 '검증·검색'에 투자하는 것이다.
- 위생: 정기적으로 stale을 재검증하고, 틀린 사실은 무효화한다(넣는 만큼 솎아낸다).
- 검색: 리콜 결과를 신뢰도·최신성·스코프로 재정렬하고, 핵심 사실은 pin으로 고정한다.
- 균형: '무엇'뿐 아니라 재현 가능한 '절차(procedural)'를 의식적으로 남긴다(가장 값진데 가장 얇다).
참고 링크
- Mem0(에이전트 메모리 레이어)
- Graphiti(시간형 지식그래프 메모리)
- Letta(구 MemGPT, 메모리 관리)
- MemGPT 논문(LLM as OS 메모리)
- LlamaIndex(지식그래프·RAG)
참고: 수치는 2026년 우리 그래프의 읽기전용 실호출 스냅샷이며 운영·정리 주기에 따라 매 순간 달라진다(영구 수치 아님). stale 비율·리콜 품질은 임베딩·검증 정책에 좌우되니, 정확한 정밀도는 내 데이터·질의로 직접 재라(여기 수치는 출발점). 메모리 프레임워크는 빠르게 바뀌니 분기별로 다시 본다.
Responses
No responses yet. Be the first to respond.