짧은 답변: RAG는 외부 증거를 검색합니다. 에이전트 메모리(Agent memory)는 사용자, 에이전트, 스레드, 선호도, 결정 및 이전 작업에 대한 지속 가능한 컨텍스트(Context)를 저장합니다. 프로덕션 에이전트에는 명시적인 대화 ID(Conversation IDs), 테넌트 범위(Tenant scopes), 출처(Provenance), 삭제 규칙 및 권한을 인식하는 회상(Permission-aware recall) 기능이 필요합니다. 이러한 경계가 없다면 메모리는 프롬프트 스터핑(Prompt stuffing)이 되고 세션 간에 상태가 유출됩니다.

개발자들은 RAG에 대해 이야기하면서 종종 메모리에 관한 질문을 합니다. 이는 타당한 일입니다. 둘 다 검색(Retrieval)을 포함하기 때문입니다. 하지만 이들은 서로 다른 문제를 해결합니다.

RAG는 "모델이 지금 당장 어떤 소스 증거를 사용해야 하는가?"에 답합니다. 메모리는 "이 에이전트가 턴(Turns), 세션 및 워크플로(Workflows) 전반에 걸쳐 무엇을 기억해야 하는가?"에 답합니다.

핵심 요약:

• RAG 그 자체로는 메모리 시스템이 아닙니다.
• 더 큰 컨텍스트 윈도우(Context window)가 지속 가능한 메모리는 아닙니다.
• 프로덕션 메모리에는 범위(Scope), 생명주기(Lifecycle), 출처(Provenance), 삭제 및 거버넌스(Governance)가 필요합니다.

RAG vs 에이전트 메모리: 차이점은 무엇인가?

짧은 답변: RAG는 답변의 근거를 마련하기 위해 문서나 데이터를 검색합니다. 에이전트 메모리는 상호작용 전반에 걸쳐 유용한 상태(State)를 유지합니다. RAG는 소스 증거를 인용해야 합니다. 메모리는 범위가 지정된 사실, 선호도, 결정, 요약, 도구 결과 및 워크플로 상태가 유효하고 허용되는 동안 이를 회상해야 합니다.

다음 구분을 사용하세요:

핵심 요약:

• RAG는 상태가 없을(Stateless) 수 있습니다.
• 메모리는 정의상 상태가 있습니다(Stateful).
• 메모리는 수정 및 삭제가 가능해야 합니다.

왜 MCP 도구에 대화 ID가 필요한가?

짧은 답변: 사용자 ID(User ID)는 사람이 누구인지를 식별할 뿐, 대화를 식별하지 않습니다. 대화 ID(Conversation ID) 또는 상관관계 ID(Correlation ID)를 사용하면 도구가 상태를 격리하고, 로그를 연결하며, 탭 간 유출을 방지하고, 검색된 데이터가 어떤 상호작용에 속했는지 증명할 수 있습니다.

만약 LLM 애플리케이션이 대화 ID (conversation ID) 없이 MCP 도구를 호출한다면, 귀하의 도구는 두 요청이 동일한 스레드에 속하는지 아니면 두 개의 병렬 세션인지 구분할 수 없습니다. 규제 대상 시스템(regulated systems)에서 이는 단순히 불편한 문제가 아닙니다. 이는 추적 가능성 (traceability) 문제입니다.

호출하는 애플리케이션에 다음 정보를 전달하도록 요청하십시오:

• 사용자 ID (user ID)
• 테넌트 ID (tenant ID)
• 에이전트 ID (agent ID)
• 대화 또는 스레드 ID (conversation or thread ID)
• 요청 ID (request ID)
• 권한 컨텍스트 (permission context)

핵심 요약 (Key takeaways):

• 대화 ID (Conversation IDs)는 단순한 장식이 아니라 상태 격리 (state isolation)를 위한 것입니다.
• 상관관계 ID (Correlation IDs)는 디버깅과 감사를 가능하게 합니다.
• 메모리 범위 (Memory scope)는 사용자 ID 하나만으로 결정하기보다 사용자, 테넌트, 에이전트 및 대화 식별자를 통해 명시적으로 정의되어야 합니다.

에이전트는 무엇을 기억해야 하는가?

짧은 답변: 에이전트는 지속 가능하고, 유용하며, 범위가 지정된 정보, 즉 사용자 선호도, 작업 상태, 결정 사항, 요약, 검증된 사실, 그리고 관련성이 유지되는 도구 결과 등을 기억해야 합니다. 비밀 정보, 일시적인 노이즈, 근거 없는 주장, 또는 사용자가 보유할 권한이 없는 데이터는 기억해서는 안 됩니다.

메모리에는 정책 (policy)이 필요합니다. 정책이 없다면 모든 상호작용이 메모리 후보가 되어 시스템이 노이즈로 가득 차게 됩니다.

메모리 카테고리를 사용하십시오:

핵심 요약 (Key takeaways):

• 메모리 승격 (Memory promotion)은 의도적으로 이루어져야 합니다.
• 메모리에는 출처 (provenance)와 타임스탬프 (timestamps)가 필요합니다.
• 삭제와 수정은 제품 요구 사항 (product requirements)입니다.

Oracle AI Database로 이를 어떻게 구현하는가?

짧은 답변: 지속 가능하고 범위가 지정된 메모리를 위해 Oracle AI Agent Memory를 사용하고, RAG, SQL 및 도구 출력이 동일한 액세스 규칙에 의해 관리되도록 유지하십시오. 사용자, 에이전트, 테넌트, 스레드, 메모리, 출처 및 검색 메타데이터를 지속 가능한 데이터베이스 기반 경로에 저장하십시오.

유용한 문서:

• Oracle AI Agent Memory 시작 가이드
• Oracle AI Database 보안 가이드
• Select AI 정보
• Oracle AI Vector Search 사용자 가이드

Oracle의 포지셔닝 측면에서 중요한 메시지는 메모리는 데이터 문제라는 점입니다. 메모리에 지속성 (persistence), 범위 지정 (scoping), 검색 (retrieval), 생명주기 규칙 (lifecycle rules), 감사 (audit) 및 삭제가 필요해지는 순간, 이는 임시적인 프롬프트 (ad hoc prompt)나 로컬 캐시 (local cache)가 아닌 관리되는 데이터 계층 (governed data layer)에 속하게 됩니다.

핵심 요약:

• 범위가 지정된 지속 가능한 메모리 (scoped persistent memory)를 위한 표준 제품 경로로 Oracle AI Agent Memory를 사용하십시오.
• 실시간 사실 (live facts)은 SQL에 유지하고, 출처에 근거한 증거 (source-grounded evidence)는 RAG에 유지하십시오.
• 문서 검색 (document retrieval)에 적용되는 것과 동일한 보안 규칙을 메모리 검색 (memory retrieval)에도 적용하십시오.

메모리는 지연 시간 (latency)에 어떤 영향을 미칩니까?

짧은 답변: 메모리는 적절하게 범위가 지정된 컨텍스트 (scoped context)를 회상할 때 반복적인 작업을 줄일 수 있지만, 매 턴마다 광범위한 검색을 수행하면 지연 시간을 추가할 수 있습니다. 메모리 검색을 좁고, 범위가 지정되어 있으며, 측정 가능하게 유지하십시오. 스레드 연속성 (thread continuity)을 위해서는 요약 (summaries)을 사용하고, 현재 대화를 넘어 중요한 사실들에 대해서는 내구성이 있는 메모리 (durable memories)를 사용하십시오.

A 실무적인 메모리 스택은 다음과 같이 분리합니다:

• 현재 프롬프트 컨텍스트 (current prompt context)
• 스레드 요약 (thread summary)
• 내구성이 있는 사용자 또는 작업 메모리 (durable user or task memories)
• 검색된 출처 증거 (retrieved source evidence)
• 실시간 도구 또는 SQL 결과 (live tool or SQL results)

핵심 요약:

• 메모리 검색은 선택적이어야 합니다.
• 스레드 요약과 장기 메모리는 서로 다른 목적을 수행합니다.
• 메모리가 비용을 정당화할 만큼 답변 품질을 충분히 개선하는지 측정하십시오.

다음 단계로 무엇을 해야 합니까?

먼저 메모리 범위 (memory scope)를 정의하는 것부터 시작하십시오. 사용자, 테넌트 (tenant), 에이전트, 스레드 및 대화별로 무엇이 저장될지 결정하십시오. 그런 다음 승격 (promotion), 업데이트, 삭제 및 검색 규칙을 정의하십시오. 그 이후에만 메모리를 에이전트 루프 (agent loop)에 연결해야 합니다.