컨텍스트에서 기억으로: 에이전트에 진짜 메모리 계층이 필요한 이유

URL: https://www.youtube.com/watch?v=BIhiYL4U9_M 날짜: 2026-10-10 채널: aiDotEngineer

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==컨텍스트 윈도우(context window)는 기억(memory)이 아니며, 에이전트가 과거의 유용한 경험을 지속적으로 재사용하려면 형성·검색·저장·거버넌스·진화·평가를 갖춘 실제 메모리 계층이 필요하다.==

• 세션의 입력으로만 존재하는 컨텍스트와 영속적 경험으로서의 메모리를 구분해야 한다.
• 원시 대화 기록을 쌓는 대신, 사실·절차·사건을 정제해 저장하고 여러 검색 경로를 결합해 회수해야 한다.
• 메모리 오염(poisoning), 범위 오류(scoping), 오래된 사실(stale facts), 충돌(conflict), 과잉 회수(over-recall)를 막으려면 쓰기 전 삭제·접근 제어·감사·피드백이 필요하다.

에이전트 메모리는 단순한 저장소가 아니라 메모리 형성(memory formation), 회상(memory recall), 진화(evolution), 평가(evaluation)가 연결된 시스템 문제다. 에이전트 세션에서 얻은 경험을 관리되는 상태(managed state)로 바꾸고, 다음 세션의 컨텍스트 카드(context card)로 재구성하며, 실제 사용 결과를 다시 메모리의 수명·순위·품질에 반영해야 한다. Anders Swanson은 이를 구현하기 위해 벡터·전문 검색·관계형 엔터티·그래프·시간 정보·감사 이력을 한 데이터베이스에서 다루는 멀티모델 데이터베이스(multi-model database)를 제안한다.

1. 컨텍스트 윈도우와 임시 작업 공간은 기억이 아니다

에이전트가 매번 같은 파일을 다시 읽는 현상은 과거 작업을 지속 상태로 저장하지 못한 결과다.

1.1. 반복 작업이 생기는 이유

1. 세션 종료와 함께 경험이 사라진다

   1. Anders Swanson은 Oracle AI Database 개발자 에반젤리스트로서 에이전트 메모리를 시스템 문제로 접근한다.
   2. 에이전트 메모리는 메모리 검색(memory retrieval), 메모리 형성(memory formation), 그리고 이를 뒷받침하는 영속 저장(persistent storage)을 조합하는 일이다.
   3. Claude Code와 Codex 같은 에이전트가 작업 중 같은 파일을 반복해서 읽는 까닭은 과거에 무엇을 했는지에 대한 지식이 없기 때문이다.

2. 고객 지원 티켓 사례에서 손실되는 지식

   1. 한 에이전트가 고객 지원 티켓을 처리하며 문서를 읽고 쿼리를 실행하고 장애를 재현해 근본 원인을 찾는다.
   2. 그 과정에서 유용한 절차를 종합해도 세션이 끝나면 저장되지 않은 채 버려진다.
   3. 나중에 다른 에이전트가 비슷한 업무를 맡으면 문서를 다시 검색하고 쿼리를 다시 실행해야 하며, 그때마다 실패·환각(hallucination) 가능성이 늘고 결과의 충실도(fidelity)가 낮아진다.
   4. 유용한 경험을 관리되는 상태로 변환하기 전에는 메모리가 시작되지 않는다.

1.2. 더 큰 윈도우와 스크래치 패드의 한계

1. 큰 컨텍스트 윈도우가 해결책이 되지 못한다

   1. 토큰을 계속 추가하면 세션이 길어지고 압축(compaction)이 발생한다.
   2. 그 과정에서 에이전트에게 유용한 신호가 관련 없는 정보 더미 속에 묻힌다.
   3. 입력 용량의 증가는 영속성이나 통제된 회상을 제공하지 않는다.

2. 파일·위키·프롬프트는 우회책에 머문다

   1. Markdown 파일을 사용해 거대한 파일 계층, 위키, 프롬프트를 만들 수 있지만 이는 governed recall이 아니다.
   2. 파일 기반 접근은 대규모 멀티테넌트(multi-tenant) 환경에서 확장되지 않으며 접근 범위·수명·감사 정책을 체계적으로 처리하기 어렵다.
   3. grep 같은 도구는 데이터를 찾는 데 매우 유용하지만 복합 하이브리드 검색(complex hybrid retrieval)을 제공하지 않는다.
   4. 파일 위에 메모리 계층을 계속 쌓으면 결국 자체 데이터베이스를 만들게 되므로 처음부터 데이터베이스를 사용하는 편이 낫다.

2. 현대적 에이전트 메모리의 수렴 패턴

에이전트 메모리는 원시 기록 보관소가 아니라 형성·회상·진화·평가를 반복하는 운영 루프다.

2.1. 형성, 회상, 진화, 평가

1. 메모리 형성(memory formation)

   1. 형성되는 메모리는 원시 transcript dump가 아니라 정제된 경험(distilled experiences)과 구조화된 사실(structured facts)이다.
   2. 세션에서 반복 사용될 지식만 추출해 내용·메타데이터·관계를 가진 관리 객체로 만든다.

2. 하이브리드 회상(hybrid recall)

   1. 벡터 유사도 검색(vector similarity search), 어휘·전문 검색(lexical/full-text search), 관계형 객체의 엔터티 검색(entity search), 그래프 순회(graph traversal)를 결합한다.
   2. 최신성(recency), 중요도, 과거 피드백 같은 시간·사용 신호도 검색 결과에 반영한다.
   3. 단일 임베딩 검색만으로는 다른 검색 경로가 찾아내는 관련 결과를 놓치므로 여러 경로의 증거를 합쳐야 한다.

3. 통합과 진화(consolidation and evolution)

   1. 중복 메모리를 통합하고 서로 충돌하는 사실을 해결해야 한다.
   2. 메모리는 시간이 지나며 낡고(stale), 무관해지고(irrelevant), 쓸모없어지므로 지속적으로 진화해야 한다.
   3. 생성 시점, 마지막 접근 시점, 유효 기간(validity window)을 기록해 시간성을 부여해야 한다.

4. 평가(evaluation)와 피드백

   1. 메모리 사용량과 회수 결과를 측정하지 않고 피드백을 메모리 계층에 보내지 않으면 시스템 전체가 무너진다.
   2. 에이전트가 메모리를 사용했는지, 거부했는지, 사용 후 성공했는지 실패했는지를 품질 신호로 저장해야 한다.

2.2. 거버넌스 제어(governance controls)

1. 저장 전 보호

   1. 비밀(secret)과 개인정보(personal information)는 메모리 계층에 들어가기 전에 삭제·비식별화(redaction)해야 한다.
   2. 관련 없는 정보와 이상한 정보가 임베딩·강화 단계로 흘러 들어가면 나중에 제거하기 어려운 위험이 된다.

2. 범위와 관리 권한

   1. 권한 범위를 에이전트·워크플로·팀·사용자 단위로 설정해야 한다.
   2. 멀티테넌트 환경에서는 관리자 승인, 검토, 오래되거나 오염된 데이터의 억제(suppression) 기능이 필요하다.

3. 메모리 루프와 실행 계층

메모리는 에이전트 런타임이 호출하는 기능이며, 과거의 사실을 다음 작업의 컨텍스트 카드로 재구성한다.

3.1. 세션에서 재사용 가능한 사실까지

1. 쓰기 단계

   1. 에이전트 세션이 문서를 읽고 쿼리를 실행하며 유용한 데이터를 종합한다.
   2. 세션 중 또는 세션 뒤에 사실(fact)을 만들고, 내용을 삭제·정제(redact), 강화(enrich)한 뒤 영속 계층에 저장한다.

2. 읽기와 재구성 단계

   1. 관련 컨텍스트를 가진 다음 세션이 저장된 사실을 검색한다.
   2. 이전 작업에서 나온 사실을 사용해 다음 작업의 컨텍스트 카드를 재구성하면 다음 에이전트의 반복 작업이 줄어든다.
   3. 에이전트가 사실을 성공적으로 사용하면 해당 메모리에 피드백 점수를 더하고, 새 접근 시점과 관련 데이터를 기록한다.

3.2. Read·write·storage 계층

1. 런타임 연동

   1. 메모리는 에이전트 런타임에서 함수처럼 호출된다.
   2. hooks, MCP(Model Context Protocol), skills 등의 방식으로 런타임이 메모리 계층을 호출할 수 있다.

2. API와 저장소

   1. 메모리 계층 API는 read, write, feedback, administrative API를 노출한다.
   2. API는 아래의 스토리지 플랫폼 또는 데이터베이스와 연결되어 메모리를 읽고 쓰며 관리한다.

4. 멀티모델 데이터베이스와 네 가지 기억 유형

하나의 데이터베이스 연결에서 여러 검색 모델과 기억 유형을 함께 다루면 메모리 운영이 단순해진다.

4.1. 멀티모델 데이터베이스의 역할

1. 한곳에 모이는 데이터 모델

   1. 행·열(row/column), 벡터 임베딩(vector embeddings), 전문 검색(full-text search), 관계형 엔터티(relational entities), 그래프(graphs), 에피소드(episodes), 사실(facts)을 한 데이터베이스에서 다룬다.
   2. 메모리를 통합된 장소에 두고 하나의 데이터베이스 쿼리 연결로 다양한 하이브리드 검색을 수행한다.

2. 단일 창구의 이점

   1. 서로 다른 전용 저장소를 이어 붙이는 대신 각 검색 방법을 한 데이터베이스의 한 창구에서 조합한다.
   2. 검색 결과를 다시 에이전트에 반환해 컨텍스트 카드를 만들 수 있다.

4.2. 인간 기억에서 빌린 네 가지 유형

1. 에피소드 기억(episodic memory)

   1. 에이전트가 처리한 특정 과거 사건이나 transcript의 일부를 저장한다.
   2. 특정 작업이 어떤 상황과 대화에서 발생했는지 복원하는 근거가 된다.

2. 의미 기억(semantic memory)

   1. 워크플로, 사용자 선호, 기타 엔터티에 관한 구체적 사실을 저장한다.
   2. 반복 세션에서 일관되게 적용할 수 있는 지식이 된다.

3. 절차 기억(procedural memory)

   1. 특정 작업이나 루틴을 수행한 방법, 예를 들어 build step을 저장한다.
   2. 비슷한 업무가 반복될 때 에이전트가 다시 가져올 수 있는 재사용 규칙이 된다.

4. 작업 상태(working state)

   1. 현재 무엇을 하고 있는지를 나타내는 단기 기억(short-term memory)이다.
   2. 특정 시간 창에서만 유효할 수 있으며, 시간이 지나면 다른 기억 유형으로 승격(promote)할 수 있다.
   3. 기억 유형별로 적합한 검색 기법을 선택할 수 있게 해 메모리 범주화를 돕는다.

5. 저장 스키마와 의도적인 메모리 형성

메모리 객체에는 내용뿐 아니라 검색 경로, 시간성, 관계, 출처, 사용 이력이 함께 들어가야 한다.

5.1. 메모리 저장 스키마

1. 기본 객체와 검색 인덱스

   1. 기본 키(primary key) 역할의 ID와 텍스트 내용, JSON 태그, 문서 데이터를 저장한다.
   2. 내용에서 만든 벡터 임베딩과 유사도 검색을 위한 벡터 인덱스를 저장한다.
   3. 벡터 검색과 결합할 수 있도록 전문·키워드 검색용 텍스트 인덱스도 둔다.

2. 관계·시간·감사 정보

   1. 메모리 사이의 그래프 링크와 엔터티 그래프의 간선을 저장해 관련 메모리를 따라갈 수 있게 한다.
   2. 메모리가 언제까지 유효한지, 마지막으로 사용된 시점이 언제인지 같은 시간적 사실(temporal facts)을 기록한다.
   3. 누가 메모리를 만들었고 무엇에 사용했는지, 메모리가 어떻게 사용됐는지를 감사 이벤트(audit events)와 관련 메타데이터로 남긴다.

5.2. 형성 순서와 출처 보존

1. Redaction을 가장 먼저 수행한다

   1. 메모리 수명 주기(lifecycle), 범위(scope), 관계, 메타데이터를 먼저 설계해 의도적으로 형성한다.
   2. 임베딩과 강화(enrichment)에 앞서 개인정보(PII)와 비밀을 제거한다.
   3. 이 단계를 건너뛰면 민감 정보와 무관한 이상 데이터가 메모리에 들어가는 재앙의 원인이 된다.

2. 강화·범위 지정·임베딩

   1. 메모리가 무엇과 관련되는지, 어떤 메타데이터를 가지는지, 어느 에이전트·팀·조직에 속하는지 추가한다.
   2. 범위를 지정하면 다른 에이전트나 워크플로의 메모리가 현재 세션을 혼란스럽게 만드는 일을 막는다.
   3. 내용의 벡터를 만들고, 조직별 정책과 사용 사례별 정책을 적용한다.

3. 에피소드와 provenance

   1. 메모리를 만든 transcript의 일부를 에피소드로 보존하면 출처(provenance)와 추가 컨텍스트를 확인할 수 있다.
   2. transcript를 필터링해 에피소드 후보를 찾고, 압축된 메모리 레코드와 연결해 저장한다.
   3. 일반 데이터베이스 관계로 연결하거나 그래프를 사용할 수 있으며, 그래프는 더 넓은 관련 검색을 가능하게 한다.

6. 하이브리드 검색으로 회상하기

회상은 저장소 계층에 대한 쿼리 문제이며, 여러 검색 분기를 결합해 근거가 있는 상위 결과를 만들어야 한다.

6.1. 검색 분기와 컨텍스트 카드

1. 여러 검색 방식의 결합

   1. 벡터 유사도 검색은 임베딩 모델 기준으로 의미적으로 가까운 결과를 찾는다.
   2. 전문·키워드 검색, 관계형 엔터티 검색, 그래프 순회, 중요도·유용성 같은 피드백 신호를 함께 사용한다.
   3. 유사도 검색만 사용하면 임베딩 모델이 가장 비슷하다고 판단한 결과만 얻으며, 일반적으로 충분하지 않다.

2. 기억 유형별 분기 선택

   1. 사실(fact)은 의미 유사도보다 정확한 ID 일치가 더 적합할 수 있다.
   2. 각 분기의 결과를 융합(fuse)하고 임계값(threshold)을 적용한 뒤 재순위화(reranking)한다.
   3. 최종 결과는 점수가 매겨진 증거와 출처를 담은 컨텍스트 카드가 된다.

6.2. 가중치와 Top-K

1. 분기별 점수

   1. 벡터 거리는 의미적 유사성에 유용하고, contains 연산자는 어휘 검색에 적합하다.
   2. 그래프 테이블과 시간 데이터도 별도 분기로 사용하며, 필요에 따라 각 분기에 다른 가중치를 부여한다.

2. 결과 병합

   1. 하이브리드 검색 알고리즘은 여러 분기의 결과를 전체 점수로 병합한다.
   2. 전체 점수에서 상위 K개를 선택하며, 예시로 상위 3개 결과를 컨텍스트 카드에 반환할 수 있다.
   3. 이 모든 검색 방법을 제공하는 멀티모델 데이터베이스를 사용하면 한 화면에서 하이브리드 검색을 구현할 수 있다.

7. 메모리의 진화와 실패 모드

메모리가 커질수록 통합·오류 처리·검색 튜닝·수명 주기가 필수이며, 무조건 저장하는 방식은 회상을 오염시킨다.

7.1. 오래된·범위가 잘못된·오염된 메모리

1. 오래된 메모리(stale memory)

   1. 프로젝트가 한때 npm을 사용하다가 다른 빌드 시스템으로 바뀌면 npm에 관한 기존 메모리가 낡는다.
   2. 에이전트가 이를 회수하면 과거 방식을 현재 방식으로 착각해 잘못된 작업을 수행할 수 있다.
   3. 시스템은 회상 과정에서 오래된 사실을 예상하고 수명 주기와 통합으로 처리해야 한다.

2. 잘못된 범위와 데이터 유출

   1. ChatGPT 계정에 로그인했는데 다른 사람의 메시지 기록이 보이는 상황은 범위 지정 실패의 비유다.
   2. 쓰기 시점과 읽기 시점 모두에서 에이전트·워크플로·팀·사용자 범위를 검사해야 데이터 유출을 막을 수 있다.

3. 메모리 오염(memory poisoning)

   1. 신뢰할 수 없는 출처가 메모리 계층에 지속적인 악성 지시를 심는 것이 오염이다.
   2. 프롬프트 인젝션이 적절한 가드레일·검토·redaction 통제를 통과하면 악성 내용이 영속화되고 데이터가 외부로 유출될 수 있다.
   3. 적절한 가드레일과 관리자 조치로 저장 전부터 차단해야 하는 최악의 시나리오다.

7.2. 충돌·과잉 회수·무관성

1. 메모리 충돌(conflicting memory)

   1. 한 메모리는 작업을 한 방식으로 하라고 하고 다른 메모리는 다른 방식이라고 할 수 있다.
   2. 같은 작업을 다루므로 두 메모리 모두 검색 순위가 높아 컨텍스트 카드에 함께 들어온다.
   3. 식당이 오른쪽이라는 기억과 왼쪽이라는 기억을 동시에 받은 에이전트처럼, 어느 지시를 따라야 할지 결정하지 못한다.
   4. 충돌 감지와 검토, 범위 확인이 해결에 중요하다.

2. 과잉 회수(over-recall)와 무관성(irrelevance)

   1. 저장 데이터가 많아지면 약한 일치 결과가 너무 많이 들어와 컨텍스트 카드의 핵심 내용을 밀어낼 수 있다.
   2. 이는 거대한 컨텍스트 윈도우에 가능한 많은 데이터를 욱여넣어 혼란을 만드는 문제와 같다.
   3. 하이브리드 검색에서 의미적으로 가까워 높은 순위를 얻었지만 실제 작업과 무관한 메모리도 생긴다.
   4. 데이터 관리와 검색 알고리즘 튜닝으로 결과 수와 관련성을 제어해야 한다.

3. 데이터 누출과 조용한 드리프트(silent drift)

   1. 이상하고 예상하지 못한 데이터가 메모리 시스템에 들어오는 데이터 누출은 메모리 오염보다 약한 형태의 문제다.
   2. 올바른 강화와 정제를 수행해 메모리 레코드가 의도한 경로로 형성되게 해야 한다.
   3. 메모리가 1,000개 레코드에서는 훌륭하게 작동하다가 50,000개 또는 1,000,000개 이상으로 늘면 이상한 결과를 내는 조용한 드리프트가 발생할 수 있다.
   4. 쓰기 전 redaction, 범위 검사, 검토 수명 주기, 피드백을 함께 적용해야 한다.

7.3. 피드백으로 루프를 닫는다

1. 측정 가능한 품질

   1. 메모리 품질은 측정 가능해야 하며, 정확한 회수율과 오래되거나 유해한 메모리를 평가해야 한다.
   2. 최종적으로 다운스트림 시스템에 얼마나 유용했는지가 메모리 품질의 중요한 기준이다.

2. 사용 결과를 순위·수명에 반영한다

   1. 에이전트가 후보 메모리를 회수한 뒤 사용했는지 거부했는지 기록한다.
   2. 메모리를 사용한 뒤 시스템이 충돌하거나 모든 작업이 잘못되면 해당 피드백 점수를 낮춘다.
   3. 유용한 메모리는 승격하고, 낡고 무관하며 유해한 메모리는 억제하거나 수명 주기에서 제거한다.
   4. 메모리 계층은 콘텐츠만 보관하는 저장소가 아니라 helpful, stale, irrelevant, harmful 같은 사용 결과를 저장해야 한다.

주요 발언 모음

“Context windows are not memory.”

“Memory really cannot begin until these useful experiences from our agents are transformed into managed state.”

“If we continue to the logical conclusion of trying to build a memory layer on top of files, we're going to be building our own database. You could just use a database.”

“Good memories are very intentional.”

“Redaction is very important at the first step.”

“Memory quality needs to be measurable.”

“We want to improve the success rate. We want to do it faster. We want to do it cheaper. We want to do it better.”

핵심 데이터 & 수치

• 영상 길이 18분 19초: Intro부터 Python SDK 권고까지 에이전트 메모리의 전체 운영 루프를 설명한다.
• 메모리 시스템의 4단계: formation, recall, evolution, evaluation이 현대적 에이전트 메모리의 수렴 패턴이다.
• 기억 유형 4가지: episodic, semantic, procedural, working state로 기억을 분류한다.
• 검색 결과 Top-K 예시: 하이브리드 검색의 전체 점수에서 상위 3개 결과를 선택할 수 있다.
• 레코드 규모의 드리프트 사례: 1,000개에서는 잘 작동하던 시스템이 50,000개 또는 1,000,000개 이상에서 이상한 결과를 낼 수 있다.
• 주요 챕터 시점: 0:47 반복 파일 읽기, 0:57 컨텍스트의 한계, 3:07 수렴 패턴, 4:17 거버넌스, 6:22 네 가지 기억, 10:02 하이브리드 회상, 12:32 실패 모드, 15:27 피드백, 17:07 SDK다.

결론 및 시사점

1. 컨텍스트 윈도우를 키우거나 Markdown 파일을 계속 쌓는 일만으로는 세션 사이의 경험을 보존할 수 없으므로, 유용한 경험을 구조화된 관리 상태로 정제해야 한다.
2. 메모리 계층은 기록 저장·검색만 제공하지 말고 형성, 회상, 통합, 수명 주기, 거버넌스, 평가를 함께 제공해야 한다.
3. 저장 전 PII와 비밀을 redaction하고, 에이전트·워크플로·팀·사용자 범위를 지정하며, 관리자 검토·감사·억제 기능을 마련해야 한다.
4. 벡터 유사도 하나에 의존하지 말고 전문 검색·정확한 엔터티 조회·그래프·시간성·피드백을 결합한 하이브리드 검색을 사용해야 한다.
5. 에피소드·의미·절차·작업 상태를 구분하면 기억 유형에 맞는 저장·검색·승격 정책을 적용할 수 있다.
6. 메모리 품질을 회수 정확도, 유용성, 최신성, 유해성, 다운스트림 성공률로 측정하고 그 결과를 순위와 수명 주기에 되돌려야 한다.
7. 멀티모델 데이터베이스는 관계형 데이터·벡터·전문 검색·그래프·시간·감사 이력을 한곳에서 다뤄 이 구조를 구현할 수 있는 기반이다.
8. 구현을 시작하려는 개발자는 Oracle Agent Memory Python SDK와 관련 노트북, Oracle AI Developer Hub의 샘플을 출발점으로 삼을 수 있다.
9. 메모리가 있으면 에이전트가 중단된 지점에서 재개하고 과거의 작업을 재사용해 반복 실패를 줄이며, 더 빠르고 저렴하고 성공률 높은 실행을 달성할 수 있다.

핵심 요약 (20줄)

에이전트가 매 세션 같은 파일을 다시 읽는 까닭은 과거 작업을 지속 상태로 저장하지 않기 때문이다. 컨텍스트 윈도우는 현재 실행의 입력일 뿐 영속적인 경험을 보존하는 메모리가 아니다. 고객 지원 에이전트가 문서 검색과 장애 재현으로 만든 절차도 세션이 끝나면 사라질 수 있다. 더 큰 컨텍스트 윈도우는 압축과 무관한 정보의 증가로 유용한 신호를 오히려 가릴 수 있다. Markdown 파일과 위키를 계속 쌓는 방식은 대규모 멀티테넌트 환경에서 통제된 회상을 제공하지 못한다. 현대적 에이전트 메모리는 형성, 회상, 진화, 평가가 연결된 운영 루프다. 메모리는 원시 transcript가 아니라 정제된 경험과 구조화된 사실로 형성해야 한다. 하이브리드 검색은 벡터, 전문, 관계형 엔터티, 그래프, 시간, 피드백 검색을 결합한다. 메모리 객체에는 텍스트, JSON 메타데이터, 임베딩, 인덱스, 그래프 링크, 시간 정보, 감사 이력이 필요하다. 개인정보와 비밀은 임베딩이나 강화보다 먼저 redaction해야 한다. 에피소드 메모리는 사실을 만든 transcript 일부를 출처와 추가 컨텍스트로 보존한다. 에피소드, 의미, 절차, 작업 상태를 구분하면 기억 유형에 맞는 검색과 수명 정책을 적용할 수 있다. 멀티모델 데이터베이스는 여러 데이터 모델과 검색 방법을 하나의 연결에서 제공한다. npm에서 다른 빌드 시스템으로 바뀐 프로젝트는 오래된 npm 메모리를 회수하지 않도록 수명 관리를 해야 한다. 범위 지정이 실패하면 다른 사용자의 기록이 노출되는 것처럼 심각한 데이터 유출이 발생할 수 있다. 신뢰할 수 없는 지시가 저장되는 메모리 오염은 프롬프트 인젝션과 데이터 유출을 일으킬 수 있다. 충돌하는 기억은 동일 작업에 서로 다른 지시를 제공하므로 감지와 검토가 필요하다. 약한 일치가 너무 많이 회수되거나 의미적으로만 가까운 무관한 기억이 선택되는 문제를 검색 튜닝으로 줄여야 한다. 1,000개에서 잘 작동한 메모리 시스템도 50,000개나 1,000,000개에서 조용한 드리프트를 겪을 수 있다. 유용성, 최신성, 유해성, 회수 성공을 측정한 피드백이 메모리의 순위와 수명 주기를 갱신한다.