슬라이딩 윈도우 (Sliding windows), 요약 (Summaries), 벡터 검색 (Vector retrieval), 구조화된 메모리 (Structured memory), 에피소드 메모리 (Episodic memory), 그리고 메모리 매니저 (Memory managers)가 어떻게 협력하여 긴 AI 에이전트 대화를 지원하는지 알아봅니다.

Companion notebook: Agent Memory for Long Conversations with Oracle AI Database

핵심 요약 (Key Takeaways)

긴 대화는 연속성(Continuity)의 문제입니다.

• 가장 실용적인 패턴은 하이브리드 계층형 메모리 (Hybrid layered memory)입니다: 최근 컨텍스트 (Recent context), 요약 (Summaries), 벡터 검색 (Vector retrieval), 구조화된 메모리 (Structured memory), 에피소드 메모리 (Episodic memory), 그리고 메모리 매니저 (Memory manager)로 구성됩니다.
• 슬라이딩 윈도우 (Sliding window) 메모리는 최근의 대화 차례를 사용할 수 있게 유지하지만, 오래된 컨텍스트는 여전히 유실됩니다.
• 요약 (Summarization)은 오래된 대화를 압축하지만, 세부 사항을 놓치거나 내용이 왜곡될 수 있습니다.
• 벡터 검색 (Vector retrieval)은 의미론적으로 관련된 컨텍스트를 찾아내지만, 유사성 (Similarity)이 곧 관련성 (Relevance)과 동일한 것은 아닙니다.
• 구조화된 메모리 (Structured memory)는 안정적인 사실, 선호도, 엔티티 (Entities), 결정 사항, 그리고 상태 (State)를 저장합니다.
• 에피소드 메모리 (Episodic memory)는 중요한 사건, 결과, 그리고 이전의 시도들을 보존합니다.
• 메모리 매니저 (Memory manager)는 무엇을 저장, 업데이트, 검색, 요약할지, 그리고 모델에 무엇을 전달할지를 결정합니다.
• Oracle AI Database는 긴 대화 메모리가 내구성이 있는 저장소, 관계형 정밀도 (Relational precision), 벡터 검색 (Vector retrieval), JSON 메타데이터, 그리고 관리된 액세스 패턴 (Governed access patterns)을 필요로 할 때 유용합니다.

실용적인 패턴 (The Practical Pattern)

긴 AI 에이전트 대화를 위해서는 하이브리드 계층형 메모리 (Hybrid layered memory)가 가장 신뢰할 수 있는 패턴입니다. 실제로 이는 각 메모리 계층이 특정 역할을 수행함을 의미합니다:

• 최신 대화 차례를 최근 컨텍스트 (Recent context)로 유지합니다.
• 모델이 매번 전체 대화 기록을 필요로 하지 않도록 오래된 대화를 요약 (Summarize)합니다.
• 사용자가 다른 표현으로 이전 컨텍스트를 다시 언급할 때 벡터 검색 (Vector retrieval)을 사용합니다.
• 안정적인 사실, 선호도, 결정 사항, 그리고 상태 (State)를 구조화된 메모리 (Structured memory)에 저장합니다.
• 중요한 사건, 결과, 그리고 이전의 시도들을 에피소드 메모리 (Episodic memory)로 보존합니다.

메모리 관리자 (Memory manager)는 이러한 계층들 위에 위치하며, 무엇을 기록하고, 업데이트하고, 검색하고, 요약하며, 현재 턴을 위해 모델로 전달할지를 결정합니다. 동반 노트북 (The companion notebook)은 Oracle AI Database, Oracle AI Agent Memory, 그리고 LangChain을 사용하여 이 패턴을 구현하지만, 첫 번째 아이디어는 특정 벤더에 종속되지 않습니다. 즉, 긴 대화 메모리 (Long conversation memory)에는 단순히 더 큰 프롬프트 (Prompt)가 아닌 아키텍처 (Architecture)가 필요합니다.

왜 긴 대화는 단순한 채팅 기록 (Chat History)을 망가뜨리는가

짧은 채팅은 대개 가공되지 않은 대화 기록 (Raw conversation history)만으로도 유지될 수 있습니다. 모델은 최신 턴 (Turns)을 보고 사용자가 무엇을 묻고 있는지 이해하며 자연스럽게 대화를 이어갑니다. 하지만 긴 대화는 여러 종류의 정보가 동시에 포함되어 있기 때문에 다릅니다:

• 다음 응답에만 유효한 일시적인 세부 사항 (Temporary details);
• 나중에 기억되어야 할 지속적인 결정 사항 (Durable decisions);
• 사용자 선호도, 프로젝트 사실 관계, 그리고 작업 상태 (Task state);
• 도구 결과 (Tool results), 실패한 시도, 성공적인 결과, 그리고 후속 조치.

이 모든 것을 하나의 긴 전사 기록 (Transcript)으로 취급하는 것은 확장성 (Scale) 측면에서 좋지 않습니다. 모델은 너무 많은 무관한 컨텍스트 (Context)를 받게 되거나, 오래된 세부 사항을 놓치거나, 혹은 중요한 무언가가 누락되었을지도 모르는 압축된 요약본 (Compressed summary)에 의존하게 됩니다. 대화의 모든 부분이 동일한 가치, 수명, 또는 검색 패턴 (Retrieval pattern)을 갖는 것은 아니기 때문에 긴 대화 메모리에는 구조 (Structure)가 필요합니다.

왜 더 큰 컨텍스트 윈도우 (Context Windows)만으로는 충분하지 않은가

더 큰 컨텍스트 윈도우는 문제를 지연시킬 수는 있지만, 해결하지는 못합니다. 더 많은 컨텍스트는 모델이 한 번에 더 많은 텍스트를 볼 수 있음을 의미하며, 이는 긴 문서나 확장된 세션에 유용합니다. 하지만 이는 더 어려운 엔지니어링 질문들에 대한 답이 되지는 못합니다:

• 세션 전반에 걸쳐 어떤 사실이 유지되어야 하는가?
• 어떤 오래된 세부 사항이 여전히 유효한가?
• 어떤 결정이 권위 있는(authoritative) 정보인가?
• 어떤 이전 시도들을 반복하지 말아야 하는가?
• 어떤 메모리가 이 사용자, 이 프로젝트, 또는 이 작업에 속하는가?

더 큰 컨텍스트 윈도우 (Context Window)는 더 많은 여유 공간을 제공합니다. 하지만 그것이 메모리 정책 (Memory Policy)을 제공하지는 않습니다. 그 정책은 애플리케이션 아키텍처 (Application Architecture)에서 나와야 합니다: 무엇을 저장할지, 무엇을 요약할지, 무엇을 검색할지, 무엇을 신뢰할지, 그리고 특정 턴 (Turn)을 위해 모델에 무엇을 전달할지에 대한 결정 말입니다.

실제로 도움이 되는 메모리 접근 방식들

서로 다른 메모리 접근 방식은 긴 대화 문제의 서로 다른 부분들을 해결합니다. 유용한 프레임워크는 어떤 방식이 보편적으로 가장 좋은지 묻는 것이 아니라, 어떤 계층 (Layer)이 어떤 종류의 연속성을 처리해야 하는지를 묻는 것입니다.

중요한 점은 이러한 접근 방식 중 그 어느 것도 단독으로는 충분하지 않다는 것입니다. 유용한 긴 대화 시스템은 이들을 결합한 다음, 메모리 관리자 (Memory Manager)가 현재 턴에 어떤 조각들이 관련이 있는지 결정하도록 합니다.

단기 연속성을 위한 슬라이딩 윈도우와 요약 (Summarization)

첫 번째 계층은 슬라이딩 윈도우 메모리 (Sliding window memory)입니다. 이는 최신 턴들을 모델 가까이에 유지하여 현재의 대화가 일관성을 유지하도록 합니다. 만약 개발자가 방금 후속 질문을 던졌다면, 모델은 현재 작업을 이해하고 이미 제공된 컨텍스트를 다시 묻는 것을 피하기 위해 가장 최근의 메시지들이 필요합니다.

하지만 슬라이딩 윈도우 (Sliding Window) 방식은 설계상 일시적입니다. 대화가 충분히 길어지면 이전의 컨텍스트가 밀려나 사라지게 됩니다. 요약 (Summarization)은 이전 대화 내용을 더 작은 표현으로 압축함으로써, 모든 대화 기록을 매 요청마다 전달하지 않고도 연속성을 유지할 수 있도록 도와줍니다. 다만 트레이드오프 (Tradeoff)가 있는데, 요약이 완벽한 메모리는 아니라는 점입니다. 요약은 세부 사항을 누락하거나, 서로 다른 아이디어를 병합하거나, 시간이 지남에 따라 내용이 왜곡될 수 있습니다. 실제로 요약은 더 정밀한 계층, 특히 구조화된 메모리 (Structured Memory) 및 에피소드 메모리 (Episodic Memory)에 의해 뒷받침될 때 가장 효과적으로 작동합니다.

장기적 의미론적 회상을 위한 벡터 검색 (Vector Retrieval)

Oracle AI Vector Search는 사용자가 이전 컨텍스트를 다른 표현으로 언급할 때 도움이 됩니다. 예를 들어, 사용자가 "아까 이 문제를 디버깅했었죠. 그때 우리가 무엇을 결정했고, 다음에 무엇을 시도해야 하나요?"라고 물을 수 있습니다. 이 질문은 이전 디버깅 작업의 모든 세부 사항을 반복하지 않습니다. 하지만 벡터 메모리 (Vector Memory) 계층은 근본 원인, 결정 사항, 실패한 패치, 그리고 배포 계획에 관한 관련 청크 (Chunks)들을 여전히 검색해낼 수 있습니다.

벡터 검색 (Vector Retrieval)은 세션 간의 회상, 의역된 후속 질문, 방대한 대화 기록, 그리고 정확한 키워드보다는 의미를 통해 찾는 것이 더 쉬운 지식을 다룰 때 특히 유용합니다. 하지만 이것이 유일한 메모리 계층이 되어서는 안 됩니다. 의미론적 유사성 (Semantic Similarity)이 곧 정확성 (Correctness)을 의미하는 것은 아니기 때문입니다. 검색된 청크는 관련은 있을 수 있지만, 오래되었거나, 불완전하거나, 혹은 구조화된 결정 기록 (Structured Decision Record)보다 권위가 떨어질 수 있습니다.

사실, 선호도 및 상태를 위한 구조화된 메모리 (Structured Memory)

구조화된 메모리는 정밀해야 하는 정보를 저장합니다. 여기에는 사용자 선호도, 프로젝트 사실 관계, 엔티티 (Entities), 결정 사항, 작업 상태 (Task State), 구성 선택 사항, 그리고 모니터링할 메트릭 (Metrics) 등이 포함됩니다. 이것들은 단순한 텍스트 조각이 아니라, 애플리케이션이 쿼리(Query), 업데이트, 검증 및 관리해야 할 기록들입니다.

companion notebook에서 구조화된 메모리 (Structured memory)에는 프로젝트 상태 (Project state), 결정 사항 (Decisions), 지표 (Metrics), 그리고 선호도 (Preferences)가 포함됩니다. 예를 들어, 특정 지역의 인벤토리 잠금 타임아웃 (Inventory lock timeout)을 사용하기로 한 결정, EU 결제 승인 지연 시간이 기존 타임아웃을 초과했다는 프로젝트 상태, 그리고 지역별로 만료된 인벤토리 잠금을 모니터링하기 위한 지표 등을 저장합니다. 이러한 종류의 메모리는 메모리 관리자 (Memory manager)가 느슨하게 관련된 검색된 청크 (Retrieved chunks)보다 권위 있는 사실 (Authoritative facts)을 우선시하도록 돕습니다.

무엇이 일어났고 왜 중요했는가에 대한 에피소드 메모리 (Episodic Memory)

에피소드 메모리 (Episodic memory)는 중요한 사건과 결과들을 저장합니다. 이는 긴 대화에서 매우 중요한데, 에이전트 (Agent)가 종종 작업을 재개하거나, 이전의 결정을 설명하거나, 실패한 시도를 반복하지 않아야 하기 때문입니다. 사실 (Fact)은 무엇이 진실인지를 말해줍니다. 에피소드 (Episode)는 무엇이 일어났고, 무엇이 변했으며, 그것이 왜 중요했는지를 말해줍니다.

노트북에서 에피소드 메모리는 거부된 글로벌 패치 (Global patch), 스테이징 (Staging)을 통과한 EU 전용 패치, 그리고 합의된 롤아웃 계획 (Rollout plan)과 같은 이벤트들을 저장합니다. 만약 개발자가 나중에 다음에 무엇을 시도해야 할지 묻는다면, 에이전트는 글로벌 패치는 이미 실패했고 EU 전용 패치는 스테이징을 통과했다는 것을 알고 있어야 합니다. 이것이 텍스트를 기억하는 것과 진행 상황 (Progress)을 기억하는 것의 차이입니다.

가장 좋은 패턴: 하이브리드 계층형 메모리 (Hybrid Layered Memory)

긴 대화 메모리를 위한 가장 좋은 패턴은 계층형 아키텍처 (Layered architecture)입니다. 최근의 컨텍스트 (Recent context)는 현재의 대화를 일관되게 유지합니다. 요약 (Summaries)은 오래된 대화를 압축합니다. 벡터 검색 (Vector retrieval)은 의미론적으로 관련된 정보를 다시 가져옵니다. 구조화된 메모리 (Structured memory)는 안정적인 사실과 결정 사항을 보존합니다. 에피소드 메모리 (Episodic memory)는 무엇이 일어났고 무엇이 시도되었는지를 기록합니다.

메모리 관리자 (Memory manager)가 이러한 계층들을 조정합니다. 그 조정이야말로 메모리를 단순히 저장된 텍스트의 더미에서 사용 가능한 시스템으로 탈바꿈시키는 핵심입니다.

메모리 관리자(Memory Manager)가 각 턴을 위해 컨텍스트를 구성하는 방법

메모리 관리자(Memory Manager)는 저장된 모든 항목을 프롬프트(Prompt)에 맹목적으로 집어넣어서는 안 됩니다. 각 턴(Turn)마다 다음 사항들을 결정해야 합니다:

• 어떤 최근 턴들을 포함할 것인가;
• 롤링 요약(Rolling summary)이 필요한가;
• 어떤 구조화된 사실(Structured facts)과 에피소드 사건(Episodic events)이 중요한가;
• 검색된(Retrieved) 청크(Chunks) 중 어떤 것이 유용한가;
• 응답 후에 무엇을 저장하거나 업데이트해야 하는가.

컨텍스트 패키지(Context package) 예시:

context_package = {
    "question": question,
    "recent_context": recent_turns,
...

이러한 형태는 거대한 프롬프트(Prompt)보다 검사하기가 더 쉽습니다. 만약 답변이 틀렸다면, 개발자는 컨텍스트 패키지(Context package)를 디버깅할 수 있습니다: 요약(Summary)이 오래된 것이었는지, 검색(Retrieval)이 올바른 메모리를 놓쳤는지, 구조화된 결정(Structured decision)이 누락되었는지, 아니면 에피소드 로그(Episodic log)가 실패한 시도를 누락했는지 등을 확인할 수 있습니다.

메모리 충돌 및 신선도(Freshness) 처리

계층화된 메모리(Layered memory)는 새로운 엔지니어링 질문을 던집니다: 메모리 계층들이 서로 충돌할 때 어떤 일이 발생할까요?

예를 들어, 롤링 요약(Rolling summary)은 이전의 계획을 보존하고 있는 반면, 구조화된 메모리(Structured memory)에는 최종 결정이 포함되어 있을 수 있습니다. 벡터 검색(Vector search) 결과는 의미론적으로 관련은 있지만 더 이상 최신이 아닌 노트를 검색할 수도 있습니다. 에피소드 메모리(Episodic memory) 항목은 최신 요약(Summary)에서 언급되지 않았더라도 이전의 시도가 실패했음을 보여줄 수 있습니다.

신뢰할 수 있는 메모리 관리자(Memory manager)는 메모리를 단순한 평면적 기록(Flat transcript)이 아닌 증거(Evidence)로 취급해야 합니다. 유용한 충돌 및 신선도(Freshness) 규칙에는 다음과 같은 것들이 있습니다:

• 두 기록이 동일한 사실을 참조할 경우, 요약 (Summary)보다 구조화된 결정 (Structured decisions)을 우선합니다.
• 두 기록의 권한 (Authority)이 동일할 경우, 더 최신의 메모리 (Memory)를 우선합니다.
• 일반적인 메모리보다 프로젝트 특정적 또는 지역 특정적 기록과 같은 범위가 지정된 메모리 (Scoped memory)를 우선합니다.
• 오래되었거나, 대체되었거나, 현재 작업과 관련성이 낮은 검색된 청크 (Retrieved chunks)는 등급을 낮춥니다.
• 각 메모리 기록에는 출처 (Source), 타임스탬프 (Timestamp), 범위 (Scope), 메모리 유형 (Memory type) 메타데이터를 유지합니다.
• 문맥을 너무 일찍 삭제하는 대신, 중요한 기록을 활성 (Active), 대체됨 (Superseded), 거부됨 (Rejected) 또는 아카이브됨 (Archived)으로 표시합니다.

이를 통해 긴 대화 메모리 (Long-conversation memory)를 더 쉽게 검사할 수 있습니다. 에이전트 (Agent)가 잘못된 답변을 내놓을 경우, 개발자는 어떤 메모리 계층 (Memory layer)이 증거 (Evidence)를 제공했는지, 그리고 왜 그 증거가 선택되었는지 확인할 수 있습니다.

메모리 매니저 (Memory Manager) 구체화하기

메모리 매니저 (Memory manager)는 단순히 문맥 (Context)을 수집하는 도우미가 아닙니다. 이는 메모리를 위한 정책 계층 (Policy layer)입니다.

각 턴 (Turn)마다 메모리 매니저는 다음과 같은 간단한 규칙을 사용하여 후보 메모리 (Candidate memories)의 순위를 매길 수 있습니다:

• 최근의 턴 (Recent turns)은 현재의 대화를 설명합니다.
• 구조화된 결정 (Structured decisions)은 일반적으로 요약 (Summaries)보다 더 정밀합니다.
• 에피소드 메모리 (Episodic memory)는 사용자가 이전의 시도, 결과 또는 다음에 무엇을 시도해야 하는지 물을 때 유용합니다.
• 벡터 결과 (Vector results)는 유사도 임계값 (Similarity threshold)을 통과하고 현재 스레드 (Thread) 또는 작업 범위 (Task scope)와 일치할 때 유용합니다.
• 오래되었거나 대체된 메모리는 이전 경로를 반복해서는 안 되는 이유를 설명하는 경우가 아니라면 제외해야 합니다.

간단한 우선순위 순서는 다음과 같을 수 있습니다:

1. 현재 사용자 메시지
2. 최근 대화 턴
3. 활성 구조화된 결정 및 프로젝트 상태
4. 관련 에피소드 이벤트
5. 순환 요약 (Rolling summary)
6. 벡터 검색된 청크
7. 설명에 필요한 경우에만 아카이브되었거나 대체된 메모리