AI 에이전트가 무엇을 믿었는지 시점별로 기억하게 하다 — FalkorDB의 유효 시간 메모리
요약
AI 에이전트의 핵심 문제점인 '기억 상실'을 해결하기 위해 FalkorDB가 유효 시간 메모리(validity interval) 기능을 도입했습니다. 이 기능은 모든 믿음(BELIEVES)에 시작 및 종료 시점을 부여하여, 특정 과거 시점에서의 정확한 믿음 상태를 그래프 형태로 감사 추적할 수 있게 합니다.
핵심 포인트
- 모든 '믿음'에 유효성 간격(validity interval)을 부여합니다.
- Cypher 쿼리를 통해 시간 T에서의 에이전트의 정확한 믿음을 재구성합니다.
- 사고 대응, 의사결정 등 모든 과정에 대한 완전한 감사 추적(audit trail)이 가능합니다.
- 벡터 스토어 방식이 아닌 그래프 DB 내부에 네이티브하게 구현되었습니다.
문제: 에이전트는 "지난 화요일에 무엇을 믿었나요?"라는 질문에 답할 수 없습니다.
AI 에이전트는 잊어버립니다. 더 심각한 것은, 생각이 바뀔 때 이전의 믿음은 사라진다는 것입니다.
어떤 에이전트에게 지난 화요일에 무엇을 믿었는지 물으면 어깨를 으쓱할 뿐입니다. 벡터 메모리는 유사한 것을 저장합니다. 언제 진실이었는지는 저장할 수 없습니다. 임베딩에는 시간 축이 없기 때문에 "10월 8일에 제가 믿었던 것은 무엇인가요?"라는 질문은 유사성 검색으로는 답할 수 없는 문제입니다.
이는 사소한 간극이 아닙니다. 에이전트가 나중에 수정된 믿음을 바탕으로 행동을 취했을 때, 현재 가지고 있는 믿음이 아니라 그 시점에 가졌던 믿음을 감사(audit)해야 합니다. 사고 대응(Incident response), 고객 대면 결정, 기록을 남기는 모든 것: "왜 그렇게 했나요?"라는 질문은 "그때 무엇을 믿었나요?"로만 의미가 통합니다.
아이디어: 모든 믿음에 유효성 간격(validity interval)을 부여하는 것입니다.
TimeMachine은 FalkorDB에 에이전트 메모리를 그래프 형태로 저장하며, 모든 BELIEVES 엣지는 유효성 간격을 가집니다:
(:Agent)-[:BELIEVES {valid_from, valid_to}]->(:Claim)-[:ABOUT]->(:Topic)
(:Claim)-[:SUPPORTED_BY {valid_from, valid_to}]->(:Evidence)
에이전트가 생각이 바뀔 때, 이전의 BELIEVES 엣지는 폐쇄(valid_to 설정)되고 삭제되지는 않습니다. as-of 쿼리는 시간 T에서 유효한 엣지만 필터링합니다:
MATCH (t:Topic {name: $topic})<-[:ABOUT]-(c:Claim)<-[b:BELIEVES]-(a:Agent)
WHERE b.valid_from <= $as_of AND (b.valid_to IS NULL OR b.valid_to > $as_of)
RETURN c.text AS belief, b.valid_from AS since
이 단 하나의 쿼리가 에이전트가 과거의 어떤 순간에 가졌던 정확한 믿음 상태를 재구성합니다. 이 그래프는 완전한 감사 추적(audit trail)입니다: 모든 믿음, 그 뒤에 있는 모든 증거 조각, 그리고 생각의 변화까지도 어느 시점의 타임스탬프에서 쿼리가 가능합니다.
이것은 temporal-memory 연구(Zep/Graphiti 스타일 작업)에서 가져온 유효 시간적 패턴이며, 벡터 스토어에 단순히 붙이는 방식이 아니라 Cypher 내부에 네이티브하게 구현되었습니다.
데모: 하나의 장애, 세 가지 진실
저는 가상의 2주간의 사고(결제 시스템 장애)를 데모 데이터셋으로 설정했습니다:
| 날짜 | 증거 발생 시점 | 에이전트의 믿음 |
|---|---|---|
| Oct 4 | Cache hit rate 95% → 40% | 캐시 미구성(Cache misconfiguration) |
| Oct 7 | DB pool exhausted, 500 waiters | 연결 풀 고갈(Connection pool exhaustion) |
| Oct 10 | Deploy v2.4 halved pool 100 → 50 | 잘못된 배포 v2.4 (Bad deploy v2.4) |
| Oct 14 | Traffic spiked 3× during sale | 트래픽 급증이 풀을 압도함 (Traffic spike overwhelmed the pool) |
같은 질문에 대해, 언제 묻느냐에 따라 세 가지 다른 진실한 답변이 나옵니다:
`agent.ask(
동일한 에이전트, 동일한 그래프—다른 과거, 다른 진실. 분기(fork)는 자체 그래프(timemachine_whatif)에서 발생하므로 실제 믿음 기록은 손상되지 않습니다.
왜 FalkorDB인가 — 장식 테스트
이 프로젝트를 만든 하나의 규칙이 있었습니다: FalkorDB가 제거되면 제품이 작동하지 않는다면, 그 그래프는 장식에 불과합니다. 그래서 저는 이것 없이는 모든 것이 멈추도록 만들었습니다:
벡터 DB는 근본적으로 '시점 기준(as-of)' 질문에 답할 수 없습니다. 임베딩에는 시간 축이 없습니다. 유효 시간 필터링은 실제 그래프 순회(graph traversal)가 필요합니다.
'시점 기준 재구성(As-of reconstruction)'은 오프라인 배치 작업으로 실행되는 것이 아니라, 에이전트 루프 내에서 인메모리 속도로 실행되어야 합니다.
반사실적 분기(Counterfactual forks)는 네이티브 멀티그래프 지원을 필요로 합니다—믿음 상태를 복제하고, 증거 하나를 삭제한 다음, 재계산합니다.
FalkorDB를 제거하면 이 제품은 죽습니다. 그것이 요점입니다.
솔직한 한계점
이것은 해커톤 프로토타입이며, 솔직히 말하자면 다음과 같습니다:
데이터셋은 가상의 것입니다. 실제 배포는 시드된 타임라인(seeded timeline)이 아니라 실제 인시던트 툴링(incident tooling)으로부터의 수집(ingestion)이 필요합니다.
'만약에(what-if)' 기능은 원인 모델(causal model)이 아니라 리플레이입니다. 증거 하나를 제외한 타임라인을 재실행할 뿐이며, 믿음이 왜 변했는지(why beliefs changed)는 모델링하지 않고, 언제 변했는지(only when)만 모델링합니다.
유효 시간(Valid-time)만 지원하며, 양시점(bitemporal)은 아닙니다. 저는 믿음이 '언제 참이었는지'를 추적할 뿐, 에이전트가 그것을 '언제 학습했는지'는 추적하지 않습니다. 실제 시스템에서는 두 축 모두를 원하게 될 것입니다.
자연어 프런트 엔드는 선택적인 LLM 다듬기(polish)가 적용된 템플릿을 사용합니다—실제 제품은 사이퍼(Cypher) 쿼리이며, 이것 위에 얇게 덧씌워진 레이어일 뿐입니다.
향후 계획
양시점 메모리(bitemporal memory: 유효 시간 × 트랜잭션 시간), 믿음 확신도 감쇠(belief confidence decay), 그리고 분기(forks)를 통해 팀이
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기