에이전트 영속 기억(메모리그래프), 우리는 이렇게 운영한다
요약: 에이전트 영속 기억을 우리 운영에서 굴려본 결론은 한 줄로 "기억은 '저장'이 아니라 '운영'이다"다. 우리 메모리그래프엔 지금 8,941개 사실이 쌓였지만, 진짜 일은 넣기가 아니라 나눠 쓰기·검증·솎아내기였다. 실측으로 규율을 요약하면: ① 사실을 3종(의미·일화·절차)으로 나눠 다르게 쓰고, ② 쓸 때 신뢰도로 검증본과 추정본을 구분하며, ③ 가장 어려운 건 잊기다 — 지금도 사실의 약 76%가 미검증 stale(검증 대기 8,135)다.
에이전트 영속 기억을 우리 운영에서 굴려본 결론은 한 줄로 "기억은 '저장'이 아니라 '운영'이다"다. 우리 메모리그래프엔 지금 8,941개 사실이 쌓였지만, 진짜 일은 넣기가 아니라 나눠 쓰기·검증·솎아내기였다. 실측으로 규율을 요약하면: ① 사실을 3종(의미·일화·절차)으로 나눠 다르게 쓰고, ② 쓸 때 신뢰도로 검증본과 추정본을 구분하며, ③ 가장 어려운 건 잊기다 — 지금도 사실의 약 76%가 미검증 stale(검증 대기 8,135)다. 핵심 교훈: 기억의 가치는 축적이 아니라 '검증된 최신성'이다.
한 줄 요약: 기억은 저장이 아니라 운영이다 — 8,941개 사실을 3종(의미·일화·절차)으로 나눠 쓰고 쓸 때 신뢰도로 검증하며, 가장 어려운 잊기(지금 약 76% stale)까지 넣는 만큼 솎아야 '검증된 최신성'이 지켜진다.
쉽게 말하면: 기억 운영은 냉장고 관리다. 채우기는 쉽지만, 칸을 나눠 넣고(분류) 유통기한을 보고(검증) 상한 걸 버리는(솎기) 게 진짜 일이다. 안 버리면 넣을수록 상한 음식만 늘어난다.
우리는 기억을 어떻게 쓰나?#
3종 사실을 목적에 맞게 다르게 쓴다. 의미(semantic) 5,243건은 '무엇'(사실·관계)이고, 일화(episodic) 2,907건은 '언제 무슨 일'(사건·결정)이며, 절차(procedural) 791건은 '어떻게'(재현 가능한 방법)다. 비율이 말해준다 — 의미가 59%로 많고 절차는 9%뿐이라, 가장 값진 '노하우'가 가장 얇다. 그래서 우리는 일화를 의미로, 반복되는 해법을 절차로 승격하려 의식적으로 노력한다(2026 연구가 말하는 consolidation). 리콜은 프로젝트 스코프(266개)와 신뢰도·최신성으로 재정렬해 정밀도를 지킨다.
아래가 3종의 구성비다. 가장 값진 절차가 가장 얇은 게 한눈에 보인다.
| 유형 | 건수·비율 | 우리 운영 |
|---|---|---|
| 의미(semantic) | 5,243(59%) | 스코프·신뢰도로 회수 |
| 일화(episodic) | 2,907 | 최근 질의 우선·TTL |
| 절차(procedural) | 791(9%) | 의식적 승격(가장 값짐) |
| 검증 | 평균 0.730 | 쓸 때 신뢰도 부여 |
| 잊기 | 76% stale | decay≠staleness로 솎기 |
무엇을 저장하고 무엇을 안 하나?#
쓸 때 검증하고, 코드·git이 이미 아는 건 저장하지 않는다. 좋은 기억 시스템의 조건은 검증본과 추정본을 구분하는 것 — 한 번 잘못 저장되면 다단계로 전파되기 때문이다. 그래서 사실마다 신뢰도(평균 0.730)·검증 시각·출처를 붙인다. 그리고 규율 하나: repo·커밋 로그가 이미 기록하는 건 안 남긴다(중복·노이즈). 안정적 도메인 지식은 오히려 파일 기반이 낫다는 게 2026 연구의 결론인데, 우리도 그렇게 한다 — 한 파일에 한 사실 + 유형·신뢰도 프런트매터 + 관련 기억 링크 + 저장 전 중복 검사. 추출 파이프라인과 파일 메모리를 나란히 쓴다.
가장 어려운 '잊기'는 어떻게 하나?#
decay와 staleness를 다른 문제로 나눠 다룬다. 2026의 핵심 통찰: 저관련 사실의 쇠퇴(decay)와, 고관련 사실이 '조용히 틀려지는' staleness는 다른 문제다. 예컨대 어떤 파일 경로·플래그는 쓸 땐 참이지만 다음 달엔 틀린데, 검증이 늦으면 그래프가 옛 사실을 자신 있게 참이라 믿는다. 우리 76% stale이 그 얼굴이다. 그래서 원칙은 넣는 만큼 솎아내기 — 정기 재검증, 모순 시 최신본으로 무효화, 시간 유효성(언제까지 참) 기록이다. 회수된 기억은 '쓸 때 참이던 것'이라 쓰기 전 재확인한다.
decay와 staleness는 축이 다르다 — 아래처럼 관련도·정확도 2축으로 보면 왜 다른 처방이 필요한지 드러난다.
그래서 우리 운영 규율은?#
핵심은 저장이 아니라 검증·정리에 투자하는 것이다.
- 분류: 사실을 의미·일화·절차로 나눠 각기 다르게 저장·회수하고, 절차(노하우)를 의식적으로 남긴다.
- 검증: 쓸 때 신뢰도·출처를 붙이고, 코드가 아는 건 저장하지 않는다.
- 정리: decay와 staleness를 나눠 재검증·무효화하고, 리콜은 스코프·신뢰도로 재정렬한다. 효과는 재발률·오탐률로 직접 잰다.
함께 읽기: 오픈 음성 클로닝, 우리는 이렇게 운영한다 — 파이프라인 회고, 에이전트 브라우저 제어, 직접 써보고 느낀 점과 한계
함께 읽기: 에이전트 영속 기억(메모리그래프), 직접 써본 실측·한계, 에이전트 영속 기억(메모리그래프), 어떻게 동작하나
참고 링크
참고: 8,941·76% stale·유형 비율은 2026년 우리 그래프의 읽기전용 스냅샷이며 운영·정리 주기에 따라 매 순간 달라진다(영구 수치 아님). staleness는 아직 열린 문제라 완전 자동화가 어렵다. 기억 운영의 성패는 저장량이 아니라 검증·정리·회수 설계에 좌우되니 자기 지표로 직접 재라(여기 수치는 출발점). 메모리 프레임워크는 빠르게 바뀌니 분기별로 다시 본다.
Responses
No responses yet. Be the first to respond.