장기 실행 에이전트의 잘못된 기억 누적을 어떻게 방지하시나요?
How are people preventing long-running agents from accumulating bad memory?
핵심 요약
에이전트의 기억이 시간이 지나며 오염되는 '메모리 로트' 문제를 해결하기 위해 기억의 수명 관리와 구조화된 지식 활용 방안을 논의합니다.
- 기억의 수명 관리 — 기억을 무한히 쌓지 않고 유효기간을 두거나 주기적으로 정리함
- 지식과 기억 분리 — 휘발성 기억 대신 레포지토리 내 구조화된 지식으로 관리함
- 인간의 개입 — 에이전트가 직접 기억을 쓰게 하지 않고 사람이 검토 후 반영함
- 작업 기반 평가 — 검색 정확도보다 실제 작업 성공 여부를 기준으로 기억을 평가함
여러 세션에 걸쳐 돌아가는 에이전트로 이것저것 실험 중인데, 그냥 "장기 기억 추가"하면 되겠지 싶었던 일반적인 접근 방식으로는 예상치 못한 문제에 부딪히고 있어.
초반 몇 번의 세션은 아주 좋아. 과거의 결정이나 선호도를 저장해두니까 에이전트가 매번 처음부터 다시 시작할 필요가 없거든. 근데 기록이 어느 정도 쌓이고 나니까 오히려 정반대의 부작용이 나타나기 시작했어:
-
상황이 바뀌었는데도 예전의 낡은 결정들이 계속 튀어나옴
-
서로 다른 세션에서 나온 상충하는 기억들이 둘 다 똑같이 관련성 높아 보임
-
에이전트가 이제는 쓸모도 없는 옛날 정보에 컨텍스트를 엄청나게 낭비하기 시작함
-
단순히 검색(retrieval) 성능을 개선한다고 해서 최종 작업 결과가 좋아지는 것도 아님
그래서 말인데, 기억을 그냥 계속 커지기만 하는 검색 저장소로 취급할 게 아니라, 기억 시스템에도 명시적인 수명 주기(lifecycle)가 필요한 거 아닐까?
다들 장기 실행 에이전트 만들 때 실제로 어떻게 하고 있어?
예를 들면 이런 거:
1. 의미적 사실(semantic facts) / 일화적 경험(episodic experiences) / 절차적 지침(procedural instructions)을 분리하기?
2. 기억을 감쇠(decay)시키거나, 만료시키거나, 주기적으로 통합하기?
3. 출처(provenance)랑 타임스탬프를 남겨서 에이전트가 이 옛날 기억을 여전히 믿어도 될지 판단하게 하기?
4. 검색 정밀도/재현율만 따지는 게 아니라, 다운스트림 작업의 성공 여부를 기준으로 기억을 평가하기?
마지막 항목이 내가 제일 관심 있는 부분이야. 기억을 "정확하게" 불러왔는데도 에이전트의 다음 행동을 오히려 망치는 경우가 있거든.
LangMem, Mem0, Letta 같은 접근 방식도 살펴봤고, Lyzr Control Plane 같은 더 넓은 플랫폼 단위의 접근도 보고 있는데, 얘네들은 에이전트 스택 전체에서 기억이 어디에 위치해야 하는지에 대해 서로 조금씩 다른 가정을 하고 있는 것 같아.
고정된 벤치마크 말고, 몇 주나 몇 달씩 에이전트를 돌리면서 기억의 품질을 실제로 측정해본 사람 있어? 진짜로 효과 본 방법이 뭐야?
