AI 에이전트에 메모리를 추가하기 전에, 에이전트가 무엇을 기억하도록 허용할지 결정하세요

메모리는 실제 시스템에 연결되기 전까지는 당연하게 들리는 에이전트 기능 중 하나입니다.

단순한 버전은 간단합니다: 대화를 저장하고, 나중에 유사한 것을 검색하여 이를 메모리라고 부르는 것입니다.

운영적인 버전은 더 어렵습니다:

• 단기 대화 컨텍스트 (short-term conversation context)란 무엇인가?
• 장기적인 사용자 또는 도메인 지식 (long-term user or domain knowledge)이란 무엇인가?
• 추론 흔적 (reasoning trace)이란 무엇인가?
• 기억된 엔티티 (remembered entity)의 소유자는 누구인가?
• 어떤 메모리가 세션 간에 재사용될 수 있는가?
• 어떤 메모리가 만료되어야 하는가, 수정되어야 하는가, 혹은 비공개로 유지되어야 하는가?
• 에이전트가 편리한 환각 (hallucination) 대신 올바른 메모리를 사용했다는 것을 어떻게 증명할 것인가?

이것이 Doramagic 매뉴얼에서 다루는 Neo4j Labs 프로젝트인 agent-memory를 읽는 유용한 방법입니다.

이것은 단순히 "에이전트를 위한 벡터 저장소 (vector store for agents)"가 아닙니다. 매뉴얼은 이를 Neo4j를 기반으로 하며, Python 및 TypeScript SDK 인터페이스와 호스팅된 NAMS 백엔드 옵션을 제공하는 AI 에이전트 및 컨텍스트 그래프 (context graphs)를 위한 그래프 네이티브 메모리 계층 (graph-native memory layer)으로 정의합니다.

첫 번째 유용한 멘탈 모델: 세 가지 메모리 계층

가장 중요한 부분은 메모리 유형의 분리입니다.

Doramagic 매뉴얼은 세 가지 주요 계층을 설명합니다:

계층	보유 내용	중요한 이유
단기 메모리 (Short-term memory)	세션 또는 대화 메시지 기록	모든 메시지가 영구적인 지식인 것처럼 가장하지 않고 현재의 턴을 근거 있게 유지함
...

그러한 분리는 실용적입니다. 왜냐하면 "모든 것을 기억하기"는 구현 전략이 아니기 때문입니다. 그것은 친근한 제품 이름을 달고 있는 데이터 거버넌스 (data governance) 문제입니다.

AI 호스트가 메모리를 사용할 예정이라면, 호스트는 자신이 어떤 계층을 건드리고 있는지 알아야 합니다.

사용자 메시지는 단기 메모리에 속할 수 있습니다.

확인된 고객 선호도는 장기 메모리에 속할 수 있습니다.

실패한 도구 호출 (tool call) 및 복구 경로는 추론 메모리 (reasoning memory)에 속할 수 있습니다.

이것들은 서로 다른 위험을 가진 서로 다른 기록들입니다.

그래프 부분은 장식이 아닙니다

agent-memory는 백엔드 그래프로 Neo4j를 사용합니다. 이는 에이전트 메모리가 단순히 텍스트 청크(text chunks)의 집합인 경우가 드물기 때문에 중요한 문제입니다.

유용한 메모리는 종종 다음과 같은 구조를 가집니다:

• 한 사람이 특정 조직(organization)에 속함
• 특정 세션(session)에서 작업(task)이 요청됨
• 도구 호출(tool call)이 엔티티(entity)에 영향을 미침
• 선호도(preference)가 한 사용자에게는 적용되지만 다른 사용자에게는 적용되지 않음
• 추론 과정(reasoning trace)이 레코드를 생성하거나 업데이트함

매뉴얼은 POLE+O 엔티티 유형인 PERSON, ORGANIZATION, LOCATION, EVENT, OBJECT 및 확장 엔티티 유형을 강조합니다. 이를 통해 메모리 시스템은 기억되는 모든 것을 동일한 종류의 노트로 취급하는 대신, 지속적인 지식(durable knowledge)을 위한 어휘(vocabulary)를 갖게 됩니다.

그 결과가 자동으로 안전하거나 정확해지는 것은 아닙니다. 단지 더 검사 가능(inspectable)해질 뿐입니다.

그것이 핵심입니다.

백엔드 선택은 운영 경계를 변화시킵니다

매뉴얼은 두 가지 백엔드 경로를 설명합니다:

• Bolt를 통한 직접적인 Neo4j 연결
• REST 백엔드를 통한 호스팅된 NAMS 사용

이는 사소한 배포 세부 사항이 아닙니다. 이는 당신이 확인해야 할 경계(boundary)를 변화시킵니다.

로컬 또는 자체 호스팅된 Neo4j 경로를 사용하는 경우, 데이터베이스 구성, 테넌트 격리(tenant isolation), 백업 및 운영 액세스에 대한 책임은 당신에게 있습니다.

NAMS를 사용하는 경우, 호스팅된 메모리 서비스 경로와 온톨로지(ontology) 인터페이스를 얻게 되지만, 이제는 원격 서비스 경계, 워크스페이스 소유권 및 API 구성이 중요해집니다.

실질적인 첫 번째 질문은 "어느 것이 더 나은가?"가 아닙니다.

실질적인 첫 번째 질문은 다음과 같습니다:

메모리가 어디에 존재하도록 허용되며, 나중에 누가 이를 읽을 수 있는가?

이 질문에 답할 수 없다면, 아직 에이전트가 지속적인 메모리(durable memory)를 작성하게 하지 마십시오.

온톨로지는 팀이 과소평가할 부분입니다

매뉴얼은 NAMS 내의 타입이 지정되고 버전 관리되는 온톨로지 계층(ontology layer)을 언급합니다. 이는 들리는 것보다 훨씬 더 중요합니다.

온톨로지 경계가 없다면, 에이전트 메모리는 조용히 표류(drift)할 수 있습니다:

• 동일한 엔티티 (entity)가 여러 이름으로 나타남
• 선호도 (preferences)가 사실 (facts)과 뒤섞임
• 도구 (tool) 결과가 사용자 의도 (user intent)로 취급됨
• 오래된 지식이 무엇인지 표시되지 않아 검색 (retrieval) 과정에 계속 남아 있음
• 개인용 메모리와 공유용 메모리가 동일한 검색 풀 (retrieval pool)에 담기게 됨

온톨로지 (ontology) 그 자체만으로 이러한 문제들을 해결할 수는 없지만, 팀이 무엇이 유효한지를 정의할 수 있는 기준을 제공합니다.

처음 시작할 때, 복잡한 도메인 온톨로지를 구축하는 것으로 시작하지는 않을 것입니다.

저는 의도적으로 아주 작은 온톨로지부터 시작할 것입니다:

• 사용자 1명
• 세션 (session) 1개
• 엔티티 (entity) 유형 2개
• 관계 (relationship) 유형 1개
• 트레이스 (trace) 1개
• 수정 (correction) 사례 1개

만약 이것조차 검사하고 수정할 수 없다면, 메모리 시스템을 확장하는 것은 실패를 더 찾아내기 어렵게 만들 뿐입니다.

첫 번째 안전한 검증 실행

agent-memory를 본격적인 AI 워크플로우 (workflow)에 연결하기 전에, 작은 샌드박스 (sandbox) 테스트를 실행할 것입니다.

이 테스트는 운영 환경의 자격 증명 (credentials)이나 실제 사용자 데이터를 필요로 해서는 안 됩니다.

좋은 첫 번째 실행 단계는 다음과 같습니다:

1. 임시 테스트 사용자 및 세션을 생성합니다.
2. 단기 메모리 (short-term memory)에 짧은 대화 메시지를 추가합니다.
3. 가짜 선호도와 같은 명시적인 장기 엔티티 (long-term entity)를 하나 추가합니다.
4. 하나의 추론 단계 (reasoning step) 또는 도구 호출 (tool call)을 기록합니다.
5. 다음 턴 (turn)에서 컨텍스트 (context)를 검색합니다.
6. 어떤 메모리 계층 (memory tier)이 어떤 반환 항목을 생성했는지 확인합니다.
7. 하나의 메모리 기록을 수정하거나 삭제합니다.
8. 수정 사항이 다음 검색 시 반영되는지 확인합니다.

핵심 결과물은 데모 출력값이 아닙니다.

핵심 결과물은 감사 추적 (audit trail)입니다:

• 무엇이 저장되었는가
• 왜 저장되었는가
• 어디에 존재하는가
• 어떻게 검색되는가
• 어떻게 수정되는가
• 에이전트가 기억해서는 안 되는 것은 무엇인가

주요 함정

가장 큰 실수는 메모리를 단순한 기능 토글 (feature toggle)로 취급하는 것입니다.

"메모리 추가"는 제품 개선처럼 들립니다.

하지만 실제로 이는 에이전트의 상태 모델 (state model)을 변화시킵니다.

상태가 없는 (stateless) 에이전트는 한 번의 실행에서 틀릴 수 있습니다.

상태가 있는 (stateful) 에이전트는 틀릴 수 있을 뿐만 아니라, 잘못된 것을 기억하고, 나중에 그 잘못된 메모리를 확신을 가지고 사용하게 됩니다.

그것이 메모리가 나쁘다는 의미는 아닙니다. 이는 메모리에 더 작은 규모의 첫 실행 (first run), 더 명확한 권한 (permissions), 그리고 가시적인 검토 경로 (review path)가 필요함을 의미합니다.

실무적인 도입 체크리스트

AI 호스트에게 메모리 계층 (memory layer)에 대한 접근 권한을 부여하기 전에, 다음 질문들에 답해 보세요:

• 어떤 메모리 계층 (memory tiers)이 활성화되어 있는가?
• 어떤 쓰기 (writes) 작업이 자동이며, 어떤 작업이 승인을 필요로 하는가?
• 백엔드 저장소 (backing store)는 어디인가?
• 메모리의 범위 (scope)가 사용자 (user), 워크스페이스 (workspace), 테넌트 (tenant), 또는 프로젝트 (project) 단위로 구분되어 있는가?
• 사용자가 기억된 사실을 검사하고 수정할 수 있는가?
• 추론 흔적 (reasoning traces)이 영구적인 사용자 지식 (durable user knowledge)과 별도로 저장되는가?
• 검색 (retrieval) 시 출처 (provenance)를 보여주는가?
• 삭제 경로 (deletion path)가 존재하는가?
• 위의 모든 사항을 증명할 수 있는 샌드박스 테스트 (sandbox test)가 있는가?

만약 답변이 불분명하다면, 다음 단계는 운영 환경 통합 (production integration)이 아닙니다.

다음 단계는 더 작은 검증 루프 (verification loop)를 만드는 것입니다.

참조: Doramagic 에이전트 메모리 프로젝트 페이지 및 매뉴얼: https://doramagic.ai/en/projects/agent-memory/manual/

고지 사항: 이 포스트는 neo4j-labs/agent-memory를 위한 독립적인 Doramagic 프로젝트 팩을 기반으로 합니다. 이는 공식 Neo4j 문서가 아니며, 업스트림 프로젝트의 보증을 의미하지 않습니다.