AI 에이전트 메모리 TTL 설계: 권한 철회 뒤 오래된 기억을 재검증하는 법

AI 에이전트 메모리의 다음 병목은 저장 용량이 아니다. 어제는 맞았던 사실·권한·도구 결과를 오늘도 써도 되는지 판정하는 일이다. 나는 메모리를 길게 유지하는 기능보다, 오래된 상태가 다음 작업에 섞이기 전에 멈추고 원문으로 돌아가는 계약이 더 중요하다고 본다. 8월 초 GitHub Trending에서 TencentDB-Agent-Memory가 계층형 단기·장기 메모리를 내세운 것은 이 수요를 보여 준다. 하지만 계층을 잘 나눠도 만료와 철회가 없으면, 과거의 고객 권한·검색 결과·정책 설명은 그럴듯한 오답의 재료가 된다. Canva가 수억 세션 환경에서 권한 변경 뒤 세션을 거의 실시간으로 철회하고, 12시간짜리 철회 창을 별도 관리하는 사례도 같은 교훈을 준다. 에이전트의 기억은 “검색되면 쓴다”가 아니라 출처, 적용 범위, 만료 시각, 철회 사유, 재검증 결과를 통과할 때만 쓴다로 설계해야 한다.

기존의 장기 메모리 글과 무엇이 다른가

7월에 다룬 AI 에이전트 메모리 설계: 긴 작업을 로그 파일처럼 검색하는 법은 긴 실행에서 원본 기록과 좁은 증거 검색을 분리하는 문제를 다뤘다. 이 글은 그 다음 단계, 즉 검색된 기억이 아직 유효한가를 판단하는 상태 수명 관리에 집중한다. 핵심 사례도 PRO-LONG의 장기 작업 기록이 아니라 TencentDB-Agent-Memory의 계층화, Stateless MCP의 요청 단위 재현성, Canva의 대규모 세션 철회다.

메모리 레코드에 요약문과 임베딩만 저장하면 검색 성능은 좋아 보여도 운영 질문에는 답할 수 없다. “이 고객의 권한은 언제 확인했나?”, “이 API 결과는 어느 scope의 토큰으로 가져왔나?”, “정책이 바뀐 뒤에도 이 추천을 재사용해도 되나?”가 남기 때문이다. 특히 외부 시스템을 읽거나 쓰는 에이전트에서는 기억이 사실 저장소이면서 권한 캐시다. 둘을 같은 ‘장기 문맥’으로 취급하면 사용자가 권한을 철회해도 과거 작업의 전제가 다음 작업으로 넘어갈 수 있다.

TTL은 삭제 스케줄이 아니라 재검증 규칙이다

TTL(Time To Live)을 단순히 “N시간 뒤 삭제”로 두면 메모리의 유용함과 안전성 사이에서 불필요한 선택을 하게 된다. 더 좋은 기본값은 expires_at을 재사용 금지 시각으로 쓰는 것이다. 만료된 항목은 즉시 영구 삭제하지 않아도 된다. 다만 에이전트의 다음 답변·도구 호출에 근거로 넣기 전에 canonical URL, 원문 파일, 또는 권한 확인 API를 다시 조회해야 한다. 재조회가 성공하면 새 fetched_at과 새 만료 시각을 발급하고, 실패하면 해당 기억을 ‘모름’으로 취급한다.

Canva의 세션 철회 구조가 유용한 비유다. Canva는 암호화된 세션 쿠키를 빠르게 처리하기 위해 철회 정보를 메모리에 두되, 세션 쿠키가 주기적으로 갱신되는 시점에는 MySQL에서 다시 확인한다. 공개 기술 글에 따르면 철회 정보는 12시간 창으로 메모리에 유지되고, 이 창을 지난 토큰 갱신은 데이터베이스 검사를 거친다. 즉 캐시 적중률을 높이면서도 무한히 오래된 기억을 신뢰하지 않는다. 에이전트도 리서치 결과에는 짧은 freshness TTL, 프로젝트 규칙에는 길지만 명시적인 검토 주기, 사용자 권한에는 철회 이벤트 기반 즉시 무효화를 각각 적용해야 한다.

TencentDB-Agent-Memory의 README도 모든 대화를 평면 벡터 저장소에 쌓는 방식 대신, 원문 로그·단계 요약·상위 구조를 나누고 아래 증거로 내려가는 경로를 설명한다. 공개 벤치마크에서 OpenClaw 연동 시 WideSearch 토큰 사용량이 221.31M에서 85.64M으로 줄었다고 주장하지만, 이 숫자를 다른 런타임의 성능 보장으로 옮겨서는 안 된다. 여기서 가져올 만한 원칙은 압축된 상위 기억이 원문을 대체하지 않고, 필요할 때 근거로 내려갈 수 있어야 한다는 점이다. TTL 만료 뒤 재검증도 바로 이 하위 근거에서 시작해야 한다.

최소 레코드는 다섯 필드보다 조금 더 필요하다

작은 팀은 거대한 메모리 플랫폼 없이 JSON Lines나 데이터베이스 테이블로 시작할 수 있다. 중요한 것은 각 항목이 어떤 사실인지보다, 언제 누구에게 어떤 범위로 유효했는지를 기계가 판정할 수 있게 만드는 것이다.

{
  "memory_id": "mem_01J9R",
  "kind": "external_fact",
  "summary": "배포 API는 승인된 프로젝트에서만 실행한다",
  "source_url": "https://example.com/policy/42",
  "fetched_at": "2026-08-06T09:00:00Z",
  "expires_at": "2026-08-06T15:00:00Z",
  "scope": {"tenant": "team-a", "project": "website", "permission": "deploy:read"},
  "revocation_version": "policy-42-v7",
  "invalidation_reason": null,
  "verified_at": "2026-08-06T09:00:00Z"
}

이 형식에서 source_url은 사람이 재검토할 원문 위치, scope는 기억이 새어 나가면 안 되는 경계, revocation_version은 현재 권한·정책 버전과 비교할 키다. invalidation_reason은 단순한 디버그 메시지가 아니다. 권한 철회, 소스 변경, 사용자 삭제 요청, TTL 만료, 검증 실패 중 무엇이 이전 판단을 무효로 했는지 남겨야 같은 항목을 실수로 부활시키지 않는다.

아래 명령은 실제 JSONL 파일에서 지금 재검증해야 할 항목을 골라낸다. 표준 라이브러리만 사용하므로 별도 패키지가 필요 없다. 운영 환경에서는 출력된 source_url을 다시 읽고, 권한성 항목은 현재 policy/version과 비교한 뒤에만 verified_at을 갱신하면 된다.

python3 - memory/events.jsonl <<'PY'
import json
import sys
from datetime import datetime, timezone
from pathlib import Path

now = datetime.now(timezone.utc)
for line in Path(sys.argv[1]).read_text().splitlines():
    record = json.loads(line)
    expires = datetime.fromisoformat(record["expires_at"].replace("Z", "+00:00"))
    revoked = record.get("invalidation_reason") is not None
    if revoked or expires <= now:
        print(record["memory_id"], record["source_url"], "revoked" if revoked else "expired")
PY

철회는 TTL을 기다리지 않는다

권한·세션·정책처럼 외부 효과와 연결된 상태는 TTL만으로 충분하지 않다. 사용자가 접근을 취소하거나, 조직이 멤버를 제거하거나, 도구 scope가 줄어든 순간 과거 메모리는 다음 만료 시각까지 살아 있으면 안 된다. 이때 필요한 것은 append-only 철회 이벤트다. 이벤트가 오면 해당 사용자·프로젝트·도구 scope를 가진 항목을 찾고, invalidation_reason과 시각을 기록하고, 다음 retrieval에서 제외한다. 마지막으로 실제 캐시와 색인에서 사라졌는지 read-back 검증을 남긴다.

Stateless MCP의 논의도 이 방향을 강화한다. Simon Willison은 2026-07-28 MCP 사양의 stateless 변화를 소개하며, MCP 도구가 셸 전체를 열어 주는 방식보다 감사·통제가 쉬운 경계를 제공한다고 짚었다. 이 맥락에서 메모리 키도 tool_version, 입력 해시, auth scope, source freshness를 함께 봐야 한다. 같은 질문 문자열이더라도 도구 버전이나 권한 scope가 바뀌면 캐시 hit가 아니라 재실행이어야 한다. 세션에 숨은 문맥을 편의상 재사용하는 순간, 무상태 요청의 감사 가능성도 무너진다.

내 의견: 더 오래 기억하는 에이전트보다, 잊는 이유를 설명하는 에이전트가 낫다

나는 장기 메모리 경쟁의 평가 기준이 recall률이나 저장량에만 머물면 위험하다고 본다. 더 많이 찾아오는 시스템은 오래된 권한과 폐기된 사실도 더 자신 있게 가져올 수 있기 때문이다. 가벼운 반론은 명확하다. TTL·scope·철회 이벤트·read-back을 모두 기록하면 작은 자동화에는 복잡하고, 매번 재조회하면 비용과 지연이 늘어난다. 맞다. 개인 메모장이나 읽기 전용 요약까지 은행 수준의 철회 체계를 만들 필요는 없다. 다만 고객 데이터, 배포 권한, 외부 도구 결과처럼 다음 행동을 바꾸는 기억은 한 번의 오답이 재작업이나 유출로 이어진다. 그 구간에서 추가 메타데이터는 관료주의가 아니라, ‘왜 이 기억을 지금 써도 되는가’를 설명하는 최소 비용이다.

김덕환 운영자 관점

김덕환 운영자 관점에서는 새 메모리 제품을 바로 붙이기보다, 지금 반복 재사용되는 사실·권한·도구 결과 열 개만 골라 source_url, fetched_at, expires_at, scope, invalidation_reason을 붙이는 실험부터 하면 된다. 일주일 동안 만료로 재조회된 항목과 철회로 차단된 항목을 세어 보면, 어떤 정보가 장기 규칙이고 어떤 정보가 짧은 캐시인지 드러난다. 에이전트가 기억을 많이 한다는 말보다, 오래된 기억을 언제 멈추고 어디서 다시 확인했는지가 운영 신뢰를 만든다.

참고 자료

• TencentDB-Agent-Memory README — 계층형 단기·장기 메모리, 원문으로의 추적 경로, 공개 벤치마크 수치
• Session revocations at scale — Canva Engineering, 2026-07-22: 12시간 철회 창, S3 청크, 메모리 사용량 87.5% 감소
• Stateless MCP has recaptured my interest — Simon Willison, 2026-07-31: MCP 2026-07-28 사양과 감사·통제 경계