AI 에이전트에게 가장 위험한 기억은 예전에 사실이었던 것

AI 에이전트는 단순히 기억하는 것만으로는 충분하지 않습니다. 자신이 기억하는 것이 여전히 유효한지 알아야 합니다.

AI 에이전트는 무언가를 완벽하게 기억하면서도, 그 기억했던 사실이 더 이상 진실이 아니기 때문에 잘못된 결정을 내릴 수 있습니다.

이렇게 말하면 당연하게 들리지만, 메모리가 대화 외부(outside the conversation)에 저장되고 자동으로 검색될 때는 훨씬 덜 명확해집니다. 메모리 시스템은 보통 이전에 기록된 정보를 찾을 수 있는지 여부로 평가됩니다. 만약 에이전트가 6개월 전에 고객에게 선호하는 청구 플랜이 무엇인지 물었고, 메모리 시스템이 오늘 그 답변을 검색할 수 있다면, 검색이 작동한 것처럼 보입니다.

하지만 만약 고객이 3개월 전에 플랜을 변경했다면 어떨까요?

메모리는 손상되지 않았습니다. 원래의 진술은 사실이었습니다. 검색 시스템도 환각(hallucinate)을 일으키지 않았습니다. 임베딩(embedding)은 매우 관련성이 높을 수 있습니다. 데이터베이스는 완벽하게 건강할 수 있습니다. 모델은 심지어 검색된 정보로부터 올바르게 추론할 수도 있습니다. 그리고 최종 결정은 여전히 틀릴 수 있습니다.

이것은 잊어버리는 것과는 다른 문제입니다. 이것은 **유효성(validity)**의 문제입니다.

최근 연구들은 장기 에이전트 메모리의 바로 이 약점을 점점 더 많이 조사하고 있습니다. 예를 들어, STALE 벤치마크는 나중 정보가 이전 기억을 명시적으로 모순하는 것이 아니라 조용히 무효화시키는 상황에 초점을 맞춥니다. 다른 최근 작업들은 시간적 유효성(temporal validity)과 사실이 언제 진실인지 추적하고 검색된 지식을 영원한 것으로 취급하지 않는 메모리 시스템을 탐구했습니다. [Ref]

따라서 흥미로운 공학적 질문은 에이전트가 더 많이 기억하게 만드는 방법이 아닙니다. 그것은 그들이 언제 기억을 신뢰해야 하는지 이해하게 만드는 방법입니다.

메모리는 저장소처럼 취급되어 왔다

많은 에이전트 메모리 아키텍처는 간단한 아이디어에서 시작합니다. 에이전트가 유용한 것을 관찰하고, 시스템이 그것을 저장하는 것입니다. 나중에 유사한 요청이 도착합니다. 시스템은 메모리를 검색하고, 모델이 그것을 사용합니다. 이 패턴은 변화가 자주 일어나지 않는 정보에 놀라울 정도로 잘 작동합니다. 사용자가 선호하는 프로그래밍 언어, 회사 이름, 반복되는 워크플로우 또는 장기 프로젝트 설명은 몇 달 동안 유용할 수 있습니다.

문제가 발생하는 것은 우리가 모든 메모리를 그 범주에 속한 것처럼 취급할 때입니다. 고객 지원 에이전트를 생각해 봅시다. 한 대화 중에 고객이 **"저는 연간 결제를 선호합니다."**라고 말합니다. 에이전트는 다음과 같이 저장합니다:

Customer prefers annual billing.

6개월 후, 고객은 구독을 월별 결제로 변경했습니다. 메모리 데이터베이스에 이전 선호도가 무효화되었다는 것을 반드시 알려주는 것은 없습니다.

오래된 기록은 여전히 존재하며, 시맨틱 검색(semantic search)도 그것을 찾아냅니다. 언어 모델(language model)은 여전히 그것을 이해하고, 그 진술은 여전히 문법적으로 정확합니다. 단지 더 이상 고객의 현재 상태에 대한 유효한 설명이 아닐 뿐입니다. 이 구별은 중요합니다. 왜냐하면 에이전트는 과거에 대한 이야기를 하기 위해 메모리를 검색하는 것이 아니기 때문입니다. 많은 시스템에서, 검색된 메모리는 에이전트가 다음에 무엇을 할지(what the agent does next)에 영향을 미칩니다.

이는 표준을 바꿉니다. 검색 엔진의 경우, 오래된 문서를 찾는 것은 허용될 수 있지만, 결정을 내리는 자율 시스템에게는 오래된 사실을 찾는 것이 위험할 수 있습니다.

메모리는 진실일 수 있으면서도 틀릴 수 있다

**역사적 진실(historical truth)**과 운영적 진실(operational truth) 사이에는 유용한 구분이 있습니다.

역사적 진실은 다음을 묻습니다: 이 정보가 예전에 사실이었는가?

운영적 진실은 다음을 묻습니다: 이 정보가 지금 결정에 영향을 미쳐야 하는가?

그것들은 같은 질문이 아닙니다. 직원의 역할이 다음과 같았다고 가정해 봅시다:

Software Engineer

그리고 나중에 다음과 같이 변경되었습니다:

Engineering Manager

두 진술 모두 사실일 수 있습니다. 첫 번째는 직원의 이전 상태를 설명하고, 두 번째는 현재 상태를 설명합니다.

만약 에이전트가 이 두 기억을 검색하여, 해당 정보가 질문과 강한 의미적 유사성(semantic similarity)을 갖기 때문에 직원이 현재 소프트웨어 엔지니어라고 결론 내린다면, 검색 시스템은 기술적으로 제 역할을 한 것입니다. 아키텍처가 더 높은 수준에서 실패한 것입니다. 이것이 단순히 임베딩(embeddings)을 개선하는 것으로 문제가 해결되지 않는 이유입니다.

의미적 유사성 답변: "이 기억이 질문과 관련 있어 보이는가?"

하지만 그것은 반드시 다음을 답하지는 않습니다: "이 기억이 이 결정에 여전히 유효한가?"

그것들은 다른 차원입니다.

최근 연구는 왜 이것이 어려운지를 보여주었습니다. 시간적 유효성(temporal validity)에 대한 2026년의 한 연구는 표준 검색이 의미적 유사성이 본질적으로 시간적 대체(temporal supersession)를 나타내지 않기 때문에 모순되는 오래된 사실과 매우 유사한 유효한 사실을 구별하는 데 어려움을 겪을 수 있다고 주장합니다. 또 다른 벤치마크에서는 최신 증거가 있음에도 불구하고 에이전트가 암묵적으로 구식이 된 기억을 인식하는 데 어려움을 겪을 수 있다는 것을 발견했습니다. [Ref]

이는 우리가 기억을 단순히 검색 가능한 사실들의 집합으로 취급하는 것을 멈춰야 함을 시사합니다. 기억은 생애 주기 의미론(lifecycle semantics)이 필요합니다.

누락된 속성: 유효성 (Validity)

일반적인 메모리 기록은 다음과 같을 수 있습니다:

Customer prefers annual billing.

더 유용한 표현 방식은 다음과 같습니다:

fact:
Customer prefers annual billing.
source:
...

이것만으로도 더 나은데, 우리는 정보가 어디서 왔고 언제 관찰되었는지 알기 때문입니다. 하지만 오늘날 그것이 유효한지 여부는 여전히 모릅니다. 프로덕션 메모리 시스템은 다음과 같은 것에 더 가까운 것을 표현할 수 있어야 합니다:

fact:
Customer prefers annual billing.
source:
...

중요한 추가 사항은 메타데이터를 위한 또 다른 필드가 아닙니다. 기억이 생애 주기를 가질 수 있다는 개념입니다. 기억은 다음과 같을 수 있습니다:

ACTIVE
SUPERSEDED
EXPIRED
...

이는 훨씬 더 유용한 정신 모델을 생성하며, 에이전트는 단순히 **"이 기억을 검색할 수 있나요?"**라고 묻지 않습니다.

대신 **"이 기억의 상태는 무엇인가요?"**라고 질문합니다.

모든 것에 만료일이 필요하지는 않다

여기서 쉽게 저지를 수 있는 실수가 있습니다. 오래된 정보(stale information)를 문제로 인식하게 되면, 모든 것에 생존 시간(time-to-live)을 설정하고 싶은 유혹을 느낍니다. 하지만 그것은 작동하지 않습니다. 어떤 정보는 자주 바뀌고, 어떤 정보는 사실상 영구적이며, 또 어떤 정보는 예측할 수 없습니다.

사용자의 좋아하는 색상은 몇 년 동안 변하지 않을 수 있고, 배송 주소는 몇 달 동안 유효할 수 있지만, 계좌 잔액은 매초 바뀔 수 있습니다.

회사의 법적 명칭은 수십 년 동안 안정적으로 유지될 수 있지만, 결국에는 변경됩니다. 일시적인 할인은 정확히 7일 동안만 유효할 수 있고, 배포 상태는 몇 초 만에 오래될 수 있습니다. 따라서 보편적인 만료 정책은 너무 단순합니다. 시스템은 기억이 어떤 종류의 것을 나타내는지를 이해해야 합니다. 유용한 분류 방식은 다음과 같을 수 있습니다:

IDENTITY
PREFERENCE
STATE
...

각 카테고리는 다른 유효성 동작(validity behaviour)을 가질 수 있습니다. 이벤트는 역사적이고, 상태는 보통 현재의 것입니다. 선호도는 바뀔 수 있고, 정책은 유효 기간을 갖습니다.

의도(intent)는 빠르게 만료될 수 있습니다. 파생된 결론(derived conclusion)은 출처 데이터가 변경되면 무효화될 수 있습니다. 바로 이 지점에서 기억 아키텍처는 벡터 데이터베이스처럼 보이기보다는 상태 관리 시스템(state-management system)처럼 보이기 시작합니다.

최근 에이전트 메모리 분야의 연구는 이러한 방향으로 나아가고 있으며, 명시적으로 시간 정보를 표현하고 다양한 유형의 지식과 믿음을 구별하는 시스템을 포함합니다.

이벤트와 상태의 차이점

에이전트 기억 시스템이 할 수 있는 가장 중요한 구분 중 하나는 **무슨 일이 일어났는지(what happened)**와 지금 무엇이 사실인지(what is true now) 사이의 구분입니다. 다음을 고려해 보세요:

6월 1일:
고객이 연간 결제를 선택함.
6월 14일:
...

이것들은 이벤트입니다. 현재 상태는 다음과 같습니다:

결제 플랜 = 월별

단순한 메모리 시스템은 진술(statements)을 모두 유지하고 질문과 의미적으로 가장 가까운 것을 검색할 수 있습니다. 상태 인식 시스템(state-aware system)은 기록(history)으로부터 현재 상태를 도출해야 합니다. 이는 메모리가 반드시 다음과 같이 모델링될 필요가 없다는 것을 의미합니다:

fact → embedding

대신 다음과 같이 모델링될 수 있습니다:

entity
↓
attribute
...

예를 들어:

Customer: 18291
billing_plan
version 1
...

이제 이전 메모리가 삭제된 것이 아니라 **대체(superseded)**되었습니다. 이 차이는 감사 가능성(auditability)에 중요합니다. 만약 누군가 6개월 후에 에이전트가 고객이 1월 20일에 연간 결제 플랜을 가졌다고 믿었던 이유를 묻는다면, 시스템은 여전히 답변할 수 있습니다. 역사적 진실은 현재의 진실로 오인되지 않고 계속 이용 가능합니다.

오래된 메모리 삭제가 무효화와 같지 않다

이것은 또 다른 미묘한 아키텍처 문제입니다. 고객이 결제 플랜을 변경한다고 가정해 봅시다. 한 가지 접근 방식은 다음과 같습니다:

DELETE old memory
INSERT new memory

이는 간단하지만, 기록을 파괴합니다. 또 다른 접근 방식은 다음과 같습니다:

old memory → inactive
new memory → active

이제 시스템은 전환(transition)을 보존합니다. 이는 역사적 맥락이 종종 운영상의 가치(operational value)를 가지기 때문에 엔터프라이즈 시스템에서 중요합니다.

에이전트는 다음을 이해해야 할 수도 있습니다: 이 계정은 왜 변경되었는가?

또는, 고객은 이전에 무엇을 요청했는가?

또는, 이 결정이 내려졌을 때 어떤 정보가 이용 가능했는가?

따라서 성숙한 메모리 시스템은 최소한 두 가지 개념, 즉 **역사적 가용성(Historical availability)**과 **운영상의 유효성(Operational validity)**을 필요로 합니다. 무언가는 현재의 의사 결정 과정에서는 제외되면서도 역사적 추론을 위해 검색 가능하게 유지될 수 있습니다. 이것이 물리적으로 모든 오래된 메모리를 삭제하는 것보다 훨씬 더 유용한 모델입니다.

검색은 2단계 문제가 되어야 한다

대부분의 메모리 검색 시스템은 다음과 같이 설명할 수 있습니다:

query
↓
semantic search
...

해당 아키텍처는 간단하지만, 결정적인 질문 하나를 남겨둡니다. 가장 관련성 높은 기억이 더 이상 유효하지 않다면 어떻게 될까요? 더 강력한 아키텍처는 검색(retrieval)과 유효성 평가(validity evaluation)를 분리할 수 있습니다:

Query
↓
Candidate Retrieval
...

첫 번째 단계는 **'어떤 정보가 관련성이 있을까?'**를 묻습니다.

나중 단계들은 **'그 정보들 중 실제로 무엇을 신뢰해야 할까?'**를 묻습니다.

이 구별은 중요합니다. 왜냐하면 관련성(relevance)과 유효성(validity)은 다른 속성이기 때문입니다. 기억은 매우 관련성이 높지만 완전히 구식이 될 수 있습니다. 오래된 청구 선호도가 청구 질문에 가장 관련성 높은 기억일 수 있지만, 사용하기에는 정확히 잘못된 정보일 수도 있습니다.

권위(Authority)도 중요합니다

시간만으로는 충분하지 않습니다. 두 개의 정보는 같은 타임스탬프를 가질지라도 여전히 다른 권위를 가질 수 있습니다. 기업 에이전트가 다음을 받는 상황을 상상해 보세요:

CRM:
Customer plan = Enterprise

그리고:

Email:
Customer says they want Enterprise.

그리고:

Billing system:
Customer plan = Professional

에이전트는 무엇을 신뢰해야 할까요? 의미적 유사성(Semantic similarity)으로는 답할 수 없습니다. 최신성(Recency)으로도 답할 수 없습니다. 아키텍처에는 **출처 권위(source authority)**가 필요합니다. 예를 들어:

Billing system
Authority: authoritative
CRM
...

이제 에이전트는 의사 결정에 대한 또 다른 차원을 갖게 됩니다. 기억은 단순히 다음과 같지 않습니다:

value = Enterprise

그것은 다음과 같이 변합니다:

value = Enterprise
source = CRM
authority = operational
...

이것은 중요합니다. 왜냐하면 자율 시스템(autonomous systems)은 점점 더 많은 데이터 소스에 걸쳐 작동하며, 에이전트는 출처가 무엇을 말하는지뿐만 아니라 그 출처가 진실을 확립하는 데 어떤 역할을 하는지를 이해해야 하기 때문입니다.

신뢰도(Confidence)는 유효성과 같지 않습니다

또 다른 흔한 실수는 신뢰도를 유효성의 대체재로 사용하는 것입니다. 에이전트가 다음을 저장했다고 가정해 봅시다:

Customer prefers annual billing.
confidence = 0.98

6개월 후에도 그 신뢰도 점수는 0.98일 수 있습니다. 하지만 고객의 선호도가 바뀌었을 수도 있습니다. 이 기억은 고객이 말했던 것을 기록한 것으로는 매우 신뢰할 만합니다. 하지만 오늘날 고객이 원하는 것에 대한 설명으로 반드시 신뢰할 만한 것은 아닙니다.

따라서:

confidence

와:

validity

은 분리되어야 합니다. Confidence는 다음을 묻습니다: 이 정보가 출처나 증거를 바탕으로 정확할 가능성이 얼마나 높은가? Validity는 다음을 묻습니다: 이 정보가 현재 상황에서도 여전히 적용되는가?

이것들은 서로 다른 질문입니다. 다음과 같은 상황이 있을 수 있습니다:

confidence: HIGH
validity: EXPIRED

이는 완벽하게 합리적입니다. 시스템은 **"이것이 사실이었다는 것은 매우 확신합니다. 하지만 이것이 여전히 사실인지는 확신하지 못합니다."**라고 말하는 것입니다. 이는 신뢰할 수 있는 시스템이 행동해야 하는 방식에 훨씬 가깝습니다.

기억은 불확실해질 수 있어야 한다

참(true)과 거짓(false) 사이에 또 다른 상태인 **불확실(Uncertain)**이 있습니다. 어떤 시스템이 다음과 같이 말하고:

Account status = active

또 다른 시스템이 다음과 같이 말할 때:

Account status = suspended

시스템은 반드시 가장 높은 유사도 점수를 가진 기억을 선택해서는 안 됩니다. 대신 다음을 표현해야 할 수도 있습니다:

status:
CONTESTED