AI 에이전트 메모리 아키텍처에 대해 알아야 할 것들

AI 에이전트 메모리 아키텍처는 프로덕션 환경에서 사용할 준비가 된 에이전트와 상호작용할 때마다 모든 것을 잊어버리는 에이전트를 구분하는 요소입니다.

많은 개발자들은 상태 비저장(stateless) 에이전트의 한계를 힘든 경험을 통해 깨닫습니다. 에이전트는 모든 것이 컨텍스트 창(context window) 안에 들어오기 때문에 단일 대화 동안은 잘 작동할 수 있습니다. 하지만 새로운 세션이 시작되는 순간, 사용자 선호도를 잃고, 과거의 실수를 반복하며, 마치 모든 상호작용이 처음인 것처럼 행동합니다. 단순히 벡터 데이터베이스(vector database)를 추가하는 것만으로는 이 문제를 해결할 수 없습니다. 신뢰할 수 있는 메모리 레이어는 어떤 정보를 저장할지, 언제 저장할지, 어떻게 구성할지, 그리고 적절한 시점에 어떻게 검색할지에 대한 명확한 결정이 필요합니다.

본 기사에서는 최신 AI 에이전트 메모리 시스템이 어떻게 작동하는지, 그리고 다양한 메모리 구성 요소들이 어떻게 결합되는지를 설명합니다. 메모리 유형, 프로덕션 에이전트에 사용되는 아키텍처 패턴, 시간이 지남에 따라 메모리를 정확하게 유지하는 생명주기(lifecycle)를 배우게 될 것입니다. 또한 컨텍스트 창, 벡터 유사성 검색(vector similarity search), 검색 증강 생성(Retrieval Augmented Generation, RAG), 지식 그래프(knowledge graphs), 영구 메모리(persistent memory)와 같은 개념들이 전체 아키텍처 내에서 각각 어떤 역할을 하는지 살펴볼 것입니다.

요약 (TL;DR)

• 에이전트 메모리 아키텍처는 에이전트가 무엇을 기억할지, 얼마나 오랫동안 정보를 유지할지, 그리고 어떻게 검색할지를 결정합니다.
• 네 가지 핵심 메모리 유형(작업 기억(working), 일화 기억(episodic), 의미론적 기억(semantic), 절차적 기억(procedural) 메모리)이 다양한 요구 사항을 지원합니다.
• 다섯 가지 아키텍처 패턴은 작업 기억 전용 시스템부터 엔터프라이즈 컨텍스트 레이어까지 다양합니다.
• 단순하게 세션 간 연속성을 확보하려면 일화 기억과 평면적인 외부 벡터 저장소로 시작하는 것이 좋습니다.
• 명확한 쓰기 트리거를 정의하고, 시간이 지남에 따라 메모리를 관리하며, 검색 품질을 모니터링하여 에이전트의 메모리가 유용하고 신뢰할 수 있도록 유지해야 합니다.

상태 비저장(Stateless) 에이전트가 프로덕션에서 실패하는 이유

상태 비저장(Stateless) 에이전트는 현재 상호작용 외의 모든 것을 잊어버리기 때문에 실제 환경에서 실패합니다. 메모리 아키텍처가 없다면, 에이전트는 세션 간 연속성(cross-session continuity)을 유지하거나, 이전 결과로부터 학습하거나, 시간이 지남에 따라 사용자에게 적응할 수 없습니다. 데모에서는 인상적인 결과를 낼 수 있지만, 요청이 도착할 때마다 마치 새로운 시스템처럼 행동합니다.

대부분의 LLM 애플리케이션은 기본적으로 상태 비저장(stateless)입니다. 모든 API 요청은 신선한 컨텍스트 창(context window)으로 시작하며, 모델은 프롬프트에 포함된 내용만 알고 있습니다. 상호작용이 끝나면 그 컨텍스트는 사라집니다. 만약 사용자가 다음 날 돌아오더라도, 개발자가 이전 대화 기록, 완료된 작업, 또는 설정된 선호도를 명시적으로 검색하여 다시 제공하지 않는 한, 에이전트는 아무런 기록도 없습니다.

이러한 제한은 프로덕션 시스템에서 세 가지 일반적인 실패 모드를 만듭니다.

세션 간 연속성 상실 (Loss of cross-session continuity)

상태 비저장 에이전트는 한 세션의 정보를 다음 세션으로 가져갈 수 없습니다. 컨텍스트 창이 재설정되면, 애플리케이션이 외부 메모리 시스템에서 명시적으로 검색하지 않는 한, 이전 대화, 결정, 상호작용 모든 것이 사라집니다.

이는 프로덕션급 LLM 애플리케이션에서 명확해집니다. 예를 들면:

• 고객 지원 에이전트가 이전 상호작용에 대한 메모리가 없기 때문에 돌아올 때마다 사용자에게 계정 세부 정보를 확인하도록 요청합니다.
• 코딩 어시스턴트가 이전에 수행된 프로젝트 규칙, 선호 라이브러리 또는 아키텍처 결정을 잊어버립니다.
• 연구 에이전트가 완료한 작업을 추적하지 못하고, 중단했던 지점부터 계속하는 대신 같은 정보를 다시 수집하기 시작합니다.

세션 간 연속성은 LLM 애플리케이션이 요청마다 처음부터 시작하는 것을 방지합니다.

과거 결과로부터 학습할 수 없음 (Inability to learn From past outcomes)

영구적인 메모리가 없다면, 에이전트는 경험을 통해 개선될 수 없습니다. 이전에 무엇이 성공했는지 또는 실패했는지에 대한 기록이 없기 때문에 모든 문제를 새로운 문제로 취급합니다.

예를 들어, 인프라 사고를 해결하는 운영 에이전트가 이전 사고의 결과를 저장하지 못하기 때문에 동일한 실패한 수정 방법을 반복적으로 추천할 수 있습니다. 시간이 지남에 따라 이는 에이전트가 강력한 언어 모델에 접근하고 있음에도 불구하고 학습할 능력이 없어 좌절감을 유발합니다.

프로덕션 에이전트는 확인된 수정 사항, 승인된 권장 사항, 명시적인 사용자 수정을 같은 고가치 이벤트(high-value events)로 기록해야 합니다. 이러한 기록은 향후 상호 작용에서 더 나은 결정을 내리는 기반이 됩니다.

개인화 부족 (Lack of personalization)

사용자들은 프로덕션 AI 에이전트가 시간이 지남에 따라 적응하기를 기대합니다. 모든 상호 작용을 동일하게 취급하는 대신, 에이전트는 개별적인 선호도, 커뮤니케이션 스타일, 반복되는 워크플로우, 자주 사용되는 도구를 기억해야 합니다.

사용자가 간결한 응답을 선호한다는 것을 아는 작문 비서(writing assistant)나 사용자님의 Kubernetes 배포 표준을 기억하는 DevOps 비서를 생각해 보세요. 이러한 지식은 에이전트가 같은 질문을 반복적으로 하지 않고도 더 관련성 높은 응답을 생성할 수 있게 합니다. 영구 메모리(persistent memory)가 없다면, 에이전트는 사용자나 환경에 대한 축적된 이해도가 없기 때문에 모든 추천이 일반적이게 됩니다.

많은 팀들이 이러한 문제를 해결하기 위해 애플리케이션에 벡터 데이터베이스(vector database)를 연결하려고 시도합니다. 이는 검색을 개선하지만, 그 자체로 아키텍처적인 문제를 해결하지는 못합니다. 효과적인 AI 에이전트 메모리 아키텍처는 어떤 정보가 장기 저장될 가치가 있는지, 언제 단기 메모리에서 영구 메모리로 이동해야 하는지, 어떻게 구성되어야 하는지, 그리고 어느 검색 전략(retrieval strategy)이 적절한 순간에 노출되어야 하는지를 정의합니다. 이러한 결정들이 에이전트가 시간이 지남에 따라 더 유능해질지, 아니면 단순히 효과적으로 사용할 수 없는 대량의 정보를 저장하게 될지를 결정합니다.

네 가지 유형의 에이전트 메모리 (The Four Types of Agent Memory)

AI 에이전트 메모리는 단일 저장 계층이 아닙니다. 이는 에이전트가 추론하고, 기억하며, 시간이 지남에 따라 개선하는 데 도움을 주기 위해 함께 작동하는 네 가지 메모리 유형으로 구성됩니다. 각 유형은 서로 다른 목적을 수행하며, 서로 다른 수명 주기를 가지고, 서로 다른 저장 및 검색 메커니즘을 사용합니다. 이러한 메모리 유형들을 이해하는 것이 효과적인 AI 에이전트 메모리 아키텍처를 설계하기 위한 첫걸음입니다.

그림 1. 에이전트 메모리의 네 가지 유형.

작업 기억 (Working memory)

작업 기억은 에이전트가 현재 상호 작용 중에 필요한 정보를 저장합니다. 대부분의 AI 에이전트에서 이는 활성 대화, 중간 추론 과정, 도구 출력 및 임시 변수를 포함하는 컨텍스트 윈도우(context window)입니다.

작업 기억은 추론(inference) 중 모델과 함께 존재하기 때문에 빠르지만, 일시적이라는 특징도 있습니다. 세션이 종료되면 애플리케이션이 중요한 정보를 다른 곳에 명시적으로 저장하지 않는 한 내용은 사라집니다. 컨텍스트 윈도우를 늘리는 것은 단일 요청 동안 모델이 더 많은 정보에 접근할 수 있게 해주지만, 세션 간 지속적인 메모리를 생성하는 것은 아닙니다.

작업 기억을 사용하는 경우:

• 현재 대화 기록.
• 활성 추론 및 계획.
• 임시 도구 출력.
• 세션별 상태.

일화적 메모리 (Episodic memory)

일화적 메모리는 과거에 발생한 특정 사건과 상호 작용을 저장합니다. 모든 것을 기억하는 대신, 나중에 유용해질 수 있는 경험들을 포착합니다.

예를 들어, AI 고객 지원 에이전트는 지난주에 고객이 환불을 거부하고 교체를 요청했다는 사실을 기억할 수 있습니다. 코딩 어시스턴트는 사용자가 프로젝트 아키텍처를 위반했기 때문에 제안된 구현을 거절했다는 것을 기억할 수 있습니다. 작업 기억(working memory)과 달리, 에피소드 메모리(episodic memory)는 세션 간에 지속됩니다.

대부분의 프로덕션 시스템은 에피소드 메모리를 벡터 데이터베이스(vector database)에 저장합니다. 이 시스템은 각 메모리를 임베딩(embedding)으로 변환하고 벡터 유사도 검색(vector similarity search)을 통해 이를 검색합니다. 이를 통해 에이전트는 모든 이전 대화를 재현하는 대신 관련성 있는 과거 경험을 회상할 수 있습니다. 온프레미스(on-premises) 또는 엣지 배포의 경우, 회사 네트워크 내에 머무르는 벡터 데이터베이스가 필요합니다. Actian VectorAI DB는 데이터를 로컬로 유지하면서 지속적인 벡터 스토리지를 제공합니다.

의미 메모리 (Semantic memory)

의미 메모리(semantic memory)는 에이전트가 시간이 지남에 따라 학습하는 일반화된 지식을 저장합니다. 개별적인 사건을 기억하기보다는, 반복된 경험으로부터 안정적인 사실과 패턴을 추출합니다.

예를 들어, 여러 개의 수락된 응답을 관찰한 후, 에이전트는 사용자가 간결한 설명을 선호하거나 항상 Kubernetes로 애플리케이션을 배포한다는 것을 학습할 수 있습니다. 모든 상호작용을 개별적으로 저장하기보다는, 시스템은 이러한 경험들을 지속적인 지식으로 통합하여 에이전트가 미래 대화에서 재사용할 수 있도록 합니다.

의미 메모리는 임베딩(embeddings), 구조화된 레코드(structured records) 또는 이 둘의 조합으로 저장할 수 있습니다. 많은 프로덕션 시스템은 중복을 줄이고 검색 품질을 개선하기 위해 에피소드 메모리에서 의미 메모리로 중요한 정보를 주기적으로 승격(promote)합니다.

절차적 메모리 (Procedural memory)

프로시저럴 메모리(Procedural memory)는 에이전트가 작업을 수행하는 방법에 대한 지식을 저장합니다. 사용자나 대화에 대한 사실을 기억하기보다는, 워크플로우, 기술, 실행 로직을 기억합니다.

예시로는 도구 정의(tool definitions), 워크플로우 그래프(workflow graphs), 프롬프트 템플릿(prompt templates), 함수 호출 정책(function-calling policies), 승인 규칙(approval rules), 오케스트레이션 로직(orchestration logic) 등이 있습니다. 에이전트가 다단계 워크플로우를 실행하거나 외부 도구를 호출할 때, 이는 에피소드 메모리나 시맨틱 메모리보다는 프로시저럴 메모리에 의존합니다.

다른 메모리 유형들과 달리, 프로시저럴 메모리는 보통 코드, 설정 파일(configuration files), 워크플로우 정의, 또는 오케스트레이션 그래프에 존재합니다. 에이전트의 기능(capabilities)을 업데이트하거나 워크플로우를 개선할 때만 변경되기 때문에, 아키텍처에서 가장 안정적인 계층입니다.

이 네 가지 메모리 유형들이 함께 완전한 AI 에이전트 메모리 아키텍처를 형성합니다. 작업 기억(Working memory)은 현재 작업을 지원하고, 에피소드 메모리(Episodic memory)는 경험을 보존하며, 시맨틱 메모리(Semantic memory)는 장기 지식을 포착하고, 프로시저럴 메모리는 에이전트가 작업을 수행하는 방식을 정의합니다. 이러한 책임들을 분리함으로써 에이전트는 단일 컨텍스트 창(context window)을 넘어 확장할 수 있으며, 장기간의 상호작용 전반에 걸쳐 신뢰할 수 있는 동작을 유지할 수 있습니다.

다섯 가지 아키텍처 패턴

모든 애플리케이션에 적합한 단일 AI 에이전트 메모리 아키텍처는 없습니다. 올바른 패턴은 에이전트가 얼마나 많은 컨텍스트를 유지해야 하는지, 정보를 얼마나 빠르게 검색해야 하는지, 그리고 데이터가 어디에 저장될 수 있는지에 따라 달라집니다. 오늘날 대부분의 프로덕션 시스템은 단순성(simplicity), 기능성(capability), 운영 복잡성(operational complexity) 사이의 다른 트레이드오프를 나타내는 다섯 가지 아키텍처 패턴 중 하나에 속합니다.

패턴 1: 인-프로세스 (In-process) 메모리 (작업 중인 데이터만 저장)

가장 간단한 아키텍처는 모든 것을 모델의 컨텍스트 창(context window) 내부에 저장합니다. 에이전트는 현재 대화를 받고, 이를 바탕으로 추론하며, 응답을 생성하고, 세션이 끝나면 모든 것을 잊어버립니다.

작업 중인 데이터만 저장하는 메모리 방식은 채팅봇(chatbot), 문서 요약, 콘텐츠 생성 및 요청마다 독립적인 단기 작업에 탁월합니다. 또한 외부 스토리지나 검색 파이프라인이 필요하지 않아 구현하기 가장 쉽다는 장점도 있습니다.

하지만 트레이드오프는 에이전트가 상태를 유지하지 못한다는 것입니다(stateless). 이전 대화를 기억하거나, 시간이 지남에 따라 응답을 개인화하거나, 경험을 통해 개선할 수 없습니다. 컨텍스트 창이 재설정되는 즉시 모든 메모리가 사라집니다.

패턴 2: 플랫 외부 벡터 스토어 (Flat external vector store)

다음 단계는 에이전트를 단일 벡터 데이터베이스(vector database)에 연결하는 것입니다. 컨텍스트 창에 전적으로 의존하기보다는, 애플리케이션이 중요한 상호작용을 임베딩(embeddings)으로 변환하여 저장하고 나중에 검색할 수 있도록 합니다. 새로운 요청이 도착하면, 애플리케이션은 벡터 유사성 검색(vector similarity search)을 수행하고 가장 관련성이 높은 메모리를 프롬프트에 주입합니다.