벡터 데이터베이스는 저장된 정보를 검색할 수 있습니다. 하지만 무엇이 메모리가 될 가치가 있는지, 그것이 여전히 사실인지, 혹은 누가 그것을 사용할 수 있는지에 대해서는 결정할 수 없습니다.

요약 (TL;DR)

프로덕션 환경의 AI 에이전트 메모리에는 임베딩 (embeddings)과 유사도 검색 (similarity search) 이상의 것이 필요합니다.

신뢰할 수 있는 메모리 시스템은 다음을 정의해야 합니다:

• 에이전트가 무엇을 기억하도록 허용되는가
• 각 메모리가 어디에서 왔는가
• 얼마나 오랫동안 유효한가
• 사실이 변경될 때 어떤 일이 발생하는가
• 누가 이에 접근할 수 있는가
• 어떻게 수정하거나 삭제할 수 있는가
• 작업 중에 사용하기에 안전한가

에이전트 메모리를 채팅 기록의 아카이브가 아니라, 거버넌스(governed)가 적용되고 진화하는 애플리케이션 상태 (application state)로 취급하십시오.

흔한 메모리 아키텍처의 실수

전형적인 AI 에이전트 메모리 데모는 다음과 같습니다:

1. 대화를 저장합니다.
2. 텍스트를 임베딩 (embeddings)으로 변환합니다.
3. 임베딩을 벡터 데이터베이스 (vector database)에 저장합니다.
4. 나중의 대화 중에 유사한 텍스트를 검색합니다.
5. 검색된 텍스트를 모델 컨텍스트 (model context)에 추가합니다.

이 방식은 프로토타입에는 작동할 수 있습니다.

하지만 완전한 메모리 아키텍처는 아닙니다.

벡터 데이터베이스는 인덱싱 (indexing) 및 검색 (retrieval) 문제를 해결합니다. 저장된 정보가 정확한지, 최신인지, 관련이 있는지, 개인적인지 또는 악의적인지는 결정하지 못합니다.

고객이 다음과 같이 말한다고 가정해 봅시다:

우리의 결제 조건은 이제 Net 45입니다.

에이전트는 그 문장을 저장합니다.

3개월 후, 고객이 조건을 Net 30으로 변경합니다. 만약 두 문장이 모두 메모리 인덱스에 남아 있다면, 시맨틱 검색 (semantic search)은 둘 중 어느 것이든 검색할 수 있습니다.

시스템은 두 대화 모두를 기억했습니다.

하지만 현재의 진실을 유지하는 데는 실패했습니다.

개발자들이 "메모리"라고 부르는 시스템들을 분리하라

기술적으로 서로 다른 여러 시스템이 종종 _메모리_라는 단어 아래 하나로 묶이곤 합니다.

이러한 계층들은 동일한 저장, 접근 또는 삭제 규칙을 공유해서는 안 됩니다.

LangChain의 현재 문서 또한 대화 스레드(conversation thread)에 국한된 단기 메모리 (short-term memory)와 서로 다른 스레드 및 세션 전반에 걸쳐 지속되는 장기 메모리 (long-term memory)를 유사하게 분리하고 있습니다.

실패한 도구 호출 (tool call)은 워크플로 상태 (workflow state) 또는 실행 로그 (execution log)에 속해야 합니다. 이것이 자동으로 장기 메모리가 될 자격이 있는 것은 아닙니다.

사용자 선호도 (user preference)는 장기 메모리에 속할 수 있습니다. 하지만 모든 요청 중에 전체 컨텍스트 윈도우 (context window)를 차지할 필요는 없습니다.

전체 대화 기록을 저장하는 것이 실패하는 이유

노이즈를 지식으로 저장함

대화에는 추측, 수정, 불완전한 아이디어 및 일시적인 결정이 포함되어 있습니다. 모든 것을 저장하면 일시적인 진술이 확인된 사실과 동일한 지위를 갖게 됩니다.

모순을 생성함

사람, 프로젝트 또는 비즈니스 프로세스는 시간이 지남에 따라 변합니다. 시스템이 수정 (revision) 및 대체 (supersession)를 지원하지 않는 한, 추가 전용 메모리 (append-only memory)는 새로운 상태 옆에 이전 상태를 함께 저장하게 됩니다.

공격 표면 (attack surface)을 확장함

문서나 대화 내에 숨겨진 악의적인 지시 사항이 영구적인 메모리로 추출되어 향후 세션에 영향을 미칠 수 있습니다.

Google의 Memory Bank 문서는 **메모리 포이즈닝 (memory poisoning)**을 위험 요소로 명시하고 있습니다. 즉, 거짓 또는 악의적인 정보가 저장되어 나중에 에이전트에 의해 사용될 수 있습니다.

개인정보 보호 및 삭제를 복잡하게 만듦

대화를 삭제한다고 해서 그로부터 생성된 추출된 사실, 요약, 임베딩 (embeddings), 캐시 (caches) 및 파생된 기록들이 반드시 제거되는 것은 아닙니다.

검색 비용을 증가시킴

저장된 텍스트가 많다고 해서 자동으로 더 나은 회상 (recall)이 만들어지는 것은 아닙니다. 오히려 관련 없는 매칭을 증가시키고 중복된 정보로 컨텍스트를 소모할 수 있습니다.

메모리 쓰기 경로 (Write Path)를 먼저 설계하라

벡터 데이터베이스를 선택하기 전에, 후보 메모리가 어떻게 신뢰할 수 있는 애플리케이션 상태 (application state)가 되는지 정의하십시오.

1. 후보 메모리 추출

모든 메시지를 저장하지 마십시오.

현재의 상호작용을 넘어 유용할 수 있는 정보를 식별하십시오. 예시는 다음과 같습니다:

• 안정적인 사용자 선호도 (User preference)
• 확정된 비즈니스 규칙 (Business rule)
• 프로젝트 결정 사항 (Project decision)
• 반복되는 제약 조건 (Recurring constraint)
• 엔티티 간의 관계 (Relationship between entities)
• 완료된 워크플로우 (Workflow)의 결과물

이 단계의 출력물은 후보(candidate)일 뿐입니다. 아직 신뢰할 수 있는 메모리는 아닙니다.

2. 증거 저장 (Store the Evidence)

모든 메모리는 그 출처를 유지해야 합니다.

유용한 출처 (Provenance) 필드에는 다음이 포함됩니다:

• 소스 메시지 또는 문서
• 정보를 제공한 사용자 또는 시스템
• 관찰된 시간
• 추출 방법 (Extraction method)
• 관련 엔티티 (Related entity)
• 신뢰도 (Confidence)
• 승인 상태 (Approval status)

출처(Provenance)가 있으면 에이전트가 왜 특정 사실을 믿고 있는지 설명할 수 있으며, 나중에 메모리를 수정할 수 있습니다.

3. 메모리 분류 (Classify the Memory)

메모리 유형에 따라 서로 다른 동작이 필요합니다.

"간결한 보고서를 보내라"와 같은 선호도는 변경될 때까지 유효할 수 있습니다.

"송장 대기 중"과 같은 운영 상태는 몇 시간 내에 만료될 수 있습니다.

계약 조건은 외부 작업에 영향을 미치기 전에 인간의 검증 (Human verification)이 필요할 수 있습니다.

분류를 통해 보존 기간, 권한, 그리고 얼마나 많은 증거가 필요한지를 결정해야 합니다.

4. 범위 및 액세스 제어 적용 (Apply Scope and Access Controls)

메모리는 반드시 명확한 네임스페이스 (Namespace)에 연결되어야 합니다:

• 사용자 (User)
• 팀 (Team)
• 고객 (Customer)
• 프로젝트 (Project)
• 테넌트 (Tenant)
• 에이전트 (Agent)
• 워크플로우 (Workflow)

에이전트는 다른 계정에서 작동하는 동안 특정 고객의 메모리를 검색해서는 안 됩니다.

액세스 필터링 (Access filtering)은 민감한 콘텐츠가 이미 모델 컨텍스트 (Model context)에 들어온 후가 아니라, 의미론적 유사도 순위 지정 (Semantic similarity ranking) 이전에 이루어져야 합니다.

5. 업데이트 의미론 정의 (Define Update Semantics)

쓰기 경로 (Write path)에는 충돌하는 정보에 대한 규칙이 필요합니다.

새로운 메모리는 다음과 같은 역할을 할 수 있습니다:

• 새로운 사실 추가
• 기존 사실 강화
• 이전 사실 수정
• 이전 상태 대체 (Supersede)
• 규칙을 일시적으로 무시 (Override)
• 정보를 논쟁 중 (Disputed)으로 표시
• 더 이상 유효하지 않은 정보 제거

최근 연구에 따르면, 에이전트의 장기 메모리는 메모리를 불변의 저장 기록으로 취급하기보다 수집 (Ingestion), 수정 (Revision), 망각 (Forgetting), 검색 (Retrieval)과 같은 상태 수준의 연산을 지원해야 한다고 주장합니다.

6. 수명 주기 정책(Lifecycle Policy) 설정

모든 메모리가 영구적으로 남아있어야 하는 것은 아닙니다.

메모리 레코드에는 다음과 같은 항목이 필요할 수 있습니다:

• 유효 시작 타임스탬프 (Valid-from timestamp)
• 만료 시간 (Expiry time)
• 검토 날짜 (Review date)
• 대체됨 상태 (Superseded status)
• 삭제 메커니즘 (Deletion mechanism)
• 민감도 분류 (Sensitivity classification)
• 보존 정책 (Retention policy)

망각 (Forgetting)이 반드시 시스템의 실패를 의미하는 것은 아닙니다. 많은 애플리케이션에서 망각은 정확성, 개인정보 보호 및 관련성을 위해 필수적입니다.

7. 메모리 결정 사항 기록 (Log the Memory Decision)

시스템이 왜 메모리를 생성, 업데이트, 거부 또는 삭제했는지 기록하십시오.

이는 AI가 생성한 해석이 이후의 행동에 영향을 미칠 수 있는 영구적인 상태 (Durable state)가 될 때 특히 중요합니다.

메모리 레코드에는 무엇이 포함되어야 하는가?

실제적인 레코드에는 다음과 같은 내용이 포함될 수 있습니다:

표준 문장 (Canonical statement)은 효율적인 검색 (Retrieval)을 지원합니다.

증거 (Evidence)와 수정 이력 (Revision history)은 신뢰성을 지원합니다.

검색 (Retrieval)은 거버넌스 다음에 온다

쓰기 경로 (Write path)가 정의된 후에야 시스템은 검색을 최적화해야 합니다.

읽기 경로 (Read path)는 일반적으로 다음과 같아야 합니다:

1. 사용자, 테넌트 (Tenant) 및 운영 범위를 식별합니다.
2. 권한에 따라 메모리를 필터링합니다.
3. 만료되었거나 대체된 레코드를 제거합니다.
4. 의미론적 (Semantically) 및 어휘적 (Lexically)으로 관련 있는 후보를 검색합니다.
5. 관련성, 최신성 및 신뢰도에 따라 순위를 매깁니다.
6. 증거 및 상태와 함께 메모리를 반환합니다.
7. 모델 컨텍스트 (Model context)에 들어가는 메모리의 양을 제한합니다.

Google의 에이전트 아키텍처 가이드는 영구적인 장기 지식 (Persistent long-term knowledge), 저지연 작업 컨텍스트 (Low-latency working context), 그리고 트랜잭션 감사를 위한 영구 원장 (Durable ledger)을 구분합니다. 이들을 별개의 요구 사항으로 취급하는 것이 모든 것을 하나의 벡터 인덱스 (Vector index)로 라우팅하는 것보다 더 안전한 아키텍처를 생성합니다.

예시: 고객 온보딩 에이전트

기업 고객의 온보딩을 조정하는 에이전트를 상상해 보십시오.

이 에이전트는 다음과 같은 사항을 기억해야 할 수도 있습니다:

• 고객이 선호하는 배포 지역
• 보안 요구 사항
• 지정된 승인자
• 계약상의 제한 사항
• 이전 구현 결정 사항

영구적으로 기억해서는 안 되는 사항:

• 초기 영업 통화에서 나온 확인되지 않은 의견
• 채팅창에 실수로 붙여넣은 비밀번호
• 일시적인 구현 오류
• 업로드된 문서 내에 포함된 프롬프트 (Prompt)
• 다른 고객에게 속한 선호도

승인자가 변경될 경우, 감사 이력 (Audit history)을 보존하면서 새로운 기록이 이전 기록을 대체해야 합니다.

이것이 바로 메모리 관리 (Memory management)입니다.

이름을 모두 임베딩 (Embedding)하고 유사도 검색 (Similarity search)이 더 최신 것을 찾아내기를 기대하는 것은 메모리 관리가 아닙니다.

프로덕션 체크리스트 (Production Checklist)

AI 에이전트를 위한 영구 메모리 (Persistent memory)를 배포하기 전에 다음 사항을 확인하십시오:

• 대화 기록 (Conversation history)과 내구성이 있는 메모리 (Durable memory)가 분리되어 있는가.
• 원본 전사 데이터 (Raw transcripts)가 자동으로 메모리로 승격되지 않는가.
• 모든 메모리가 출처 근거 (Source evidence)를 유지하고 있는가.
• 사실 관계를 업데이트, 논쟁 및 대체할 수 있는가.
• 사용자 및 테넌트 (Tenant)별로 액세스가 격리되어 있는가.
• 민감한 메모리 쓰기 작업에 대해 더 강력한 제어가 필요한가.
• 만료된 정보가 검색 (Retrieval)에서 제외되는가.
• 사용자가 또는 관리자가 메모리를 수정하고 삭제할 수 있는가.
• 메모리 오염 (Memory poisoning) 및 프롬프트 인젝션 (Prompt-injection) 시나리오가 테스트되었는가.
• 에이전트의 행동이 별도의 감사 원장 (Audit ledger)에 기록으로 남는가.

메모리는 데이터 거버넌스 (Data-Governance) 문제이다

모델은 장기 메모리 (Long-term memory)에서 가장 어려운 부분이 아닙니다.

어려운 부분은 어떤 정보가 내구성을 가질지, 그 정보의 진위가 어떻게 변하는지, 그리고 그것을 사용하는 것이 안전한지를 결정하는 것입니다.

이러한 점 때문에 AI 에이전트 메모리는 LLM 문제인 동시에 비즈니스 데이터 관리 문제이기도 합니다.

유용한 다음 단계는 AI를 위한 데이터가 왜 대시보드를 넘어서야 하는지를 이해하는 것입니다.

에이전트 기반 또는 AI 네이티브 애플리케이션의 광범위한 아키텍처를 계획하는 팀에게는, 제품 컨셉부터 프로덕션 설계에 이르기까지 실질적인 프레임워크를 제공하는 AI-Native Product Playbook이 도움이 될 것입니다.

벡터 데이터베이스 (Vector Database)는 에이전트가 메모리를 찾는 데 도움을 줄 수 있습니다.

하지만 당신의 아키텍처 (Architecture)가 그 메모리를 신뢰할 가치가 있는지를 결정합니다.