TemporalStore, 대화 재생 대신 시간 기반 에이전트 메모리

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

LLM 에이전트가 전체 대화와 tool output을 매번 재생하면 토큰 비용이 커지고 세션 밖의 기억은 사라진다. TemporalStore는 runtime이 추출한 intent와 벡터를 temporal engine에 저장한 뒤, 범위·시간·entity 색인으로 후보를 줄여 작은 source-backed ContextPack을 반환한다. 실제 coding history에서 약 1,333토큰으로 1,698,940토큰 replay보다 높은 점수 8.30 대 6.59를 기록했고, 여섯 질문 모두 승리하거나 동률이었다. tree-plus-index retrieval, memory-first tiering, WAL, append-structured 저장소를 통해 팀 전체의 cross-session memory와 약 17ms p95 serving latency를 목표로 하며, Apache-2.0 라이선스와 Docker 실행 방식을 제공한다.

섹션별 상세

LLM 에이전트가 매 턴마다 이전 프롬프트와 tool result, 로그, stack trace를 통째로 다시 보내면 대화가 길어질수록 토큰 비용과 입력 잡음이 함께 커진다. 이 방식은 한 세션의 transcript에만 기억이 갇혀 세션이 끝나거나 context window가 넘어가면 사용자와 프로젝트에 관해 축적한 사실을 유지하지 못한다. TemporalStore는 이벤트를 compact record로 바꾸고 필요한 사실만 순위를 매겨 ContextPack으로 전달함으로써 비용과 문맥 오염을 동시에 줄이는 접근을 취한다.

TemporalStore의 처리 경로는 모델이 intent와 시간, 필터, entity를 추출하고 엔진이 이를 저장·검색하는 식으로 역할을 나눈다. 엔진은 LLM이나 embedding model을 직접 호출하지 않고, runtime이 만든 벡터와 구조화된 intent를 저장한 뒤 질의 시 토큰 예산에 맞는 source-backed ContextPack을 반환한다. tool call은 짧은 marker로, 큰 결과는 head-truncation 또는 요약된 기록으로 보존해 모델이 오래된 로그 전체를 뒤지는 대신 필요한 근거에 집중하게 만든다.

개발자의 실제 coding history 12,384개 이벤트와 97개 세션, 약 1.7M 토큰을 대상으로 한 비교에서 full replay는 1,698,940 토큰을 사용하고 judge 점수 6.59를 얻었다. 약 1,333토큰의 TemporalStore pack은 토큰을 99.9% 줄이면서 점수 8.30을 기록했고, 여섯 질문 모두에서 승리하거나 동률이었다. 특히 오래된 기록에 답해야 하는 q_storage는 10.0 대 6.05, q_parity는 8.05 대 5.25로 차이가 커서 최신 N개 재생의 구조적 한계를 드러냈다.

근거

TemporalStore pack은 full replay보다 99.9% 적은 토큰으로 더 높은 judge 점수를 기록했다. — 12,384 events, 97 sessions, 약 1.7M tokens를 사용한 Replay 대 Managed 표: 1,698,940 tokens·6.59점 대 약 1,333 tokens·8.30점.
TemporalStore는 LoCoMo와 LongMemEval_s에서 높은 검색 recall을 기록했다. — 장기 메모리 benchmark 문단의 hit@k 0.995–1.00 수치와 LongMemEval 98% 대 66% 비교.

장기 메모리를 vector DB, summarization·extraction pipeline, memory glue service로 나누는 대신 TemporalStore는 하나의 temporal engine에 ingest, rank, serving을 모은다. tenant → user → session → agent → resource 계층과 secondary index를 사용해 status ∩ project ∩ time-bucket처럼 후보를 먼저 교집합으로 좁힌 뒤 시간 감쇠와 점수 계산을 수행한다. 그 결과 데이터 전체가 아니라 필터링된 후보 집합만 처리하며, 1.2k-token 예산에서 ContextPack 검색 지연은 약 17ms p95로 제시됐다.

근거

ContextPack 검색은 1.2k-token 예산에서 약 17ms p95 지연을 보였다. — serving path 문단의 tree, secondary index, 후보 집합 필터링 설명과 latency 수치.

저장 계층은 시간순 이벤트가 계속 추가되고 오래된 데이터가 식는다는 특성에 맞춰 append-structured 구조와 memory-first tiering을 사용한다. hot data는 메모리에 두고 PMem, SSD, shared storage로 내보내며, 다시 읽히는 cold data는 메모리로 승격한다. append 때마다 segmented log를 재해석하던 문제는 per-node cursor로 O(n²)에서 O(1) 경로로 바뀌어 109ms가 2.2ms로 줄었고, 라이브 저장소의 디스크 형식은 바뀌지 않았다.

근거

per-node cursor가 segmented log 재해석 비용을 109ms에서 2.2ms로 줄였다. — append-structured storage 문단의 O(n²) append 문제와 byte-identical on-disk format 설명.

TemporalStore의 장점은 단일 transcript를 넘어 tenant, user, session, agent, resource 범위에 기억을 저장한다는 데 있다. 한 에이전트가 다른 에이전트가 전날 학습한 사실이나 다른 기기에서 사용자가 내린 결정을 조회할 수 있고, 각 사실은 timestamp와 source event를 함께 가진다. LoCoMo와 LongMemEval_s에서 tree-plus-index retrieval의 hit@k는 0.995–1.00이었으며, 공유 open-source stack 비교에서는 LongMemEval 정확도가 98% 대 66%로 제시됐다.

근거

TemporalStore는 세션 간·기기 간·에이전트 간·팀 간 기억을 source event와 함께 유지한다. — Memory that's shared 문단의 tenant → user → session → agent → resource scope와 timestamp·traceability 설명.

용어 해설

ContextPack: — 대화 전체를 다시 보내는 대신 현재 질의에 필요한 사실만 정해진 토큰 예산 안에 담는 검색 결과 묶음이다. TemporalStore는 이벤트를 정제하고 순위를 매긴 뒤 각 사실을 원본 이벤트와 연결해 생성한다. 프롬프트 크기와 잡음을 줄이면서 근거 추적이 가능하다는 점이 핵심이다.
시간 기반 검색(Temporal Retrieval): — 기억을 현재 시점과 과거 시점의 관계까지 고려해 검색하는 방식이다. 시간 필터와 시간 감쇠를 적용해 오래된 기록이라도 현재 질의와 관련되면 선택하고, 유효하지 않은 최신 정보는 걸러낸다. 장기 에이전트 메모리에서 단순한 최신순 재생보다 적합하다.
근사 최근접 이웃 검색(Approximate Nearest Neighbor): — 대규모 벡터 집합에서 모든 벡터를 정확히 비교하지 않고 가까운 후보를 빠르게 찾는 검색 방식이다. 속도는 높지만 일부 관련 항목을 놓칠 수 있어 recall과 속도 사이의 절충이 필요하다. TemporalStore는 범위와 시간 색인으로 후보를 먼저 줄인 뒤 정확한 점수를 계산하는 구조를 택한다.
쓰기 증폭(Write Amplification): — 한 번 기록한 데이터가 저장소 내부 정리 과정에서 여러 번 다시 쓰이는 현상이다. RocksDB 같은 LSM 구조에서는 compaction이 새 데이터를 기존 파일과 반복적으로 병합해 쓰기량과 지연을 키울 수 있다. TemporalStore는 시간순 append 구조로 이벤트를 기존 값에 이어 붙여 이 비용을 줄이는 방향을 취한다.
쓰기 전 로그(Write-Ahead Log): — 실제 데이터 구조를 변경하기 전에 변경 내용을 로그에 기록하는 내구성 기법이다. 장애가 발생하면 로그를 다시 재생해 저장 상태를 복구할 수 있다. TemporalStore는 datanode의 append 경로와 crash-safe 재로딩에 WAL을 사용한다.
Raft 복제(Raft Replication): — 여러 노드가 합의된 로그 순서를 유지하도록 리더와 팔로어 사이에서 상태를 복제하는 방식이다. 단일 노드에서 시작한 저장소를 복제 환경으로 확장할 때 데이터 일관성과 장애 대응의 기반이 된다. TemporalStore는 MatrixRaft를 통해 local, Raft-replicated, shared-storage 구성을 지원한다.