현재 대부분의 AI 에이전트는 뛰어난 추론과 작업 수행 능력을 가지고 있지만, 매일 모든 기억을 잃는 ‘무상태’ 한계로 인해 진정한 개인화와 연속성을 제공하지 못하고 있습니다.
매일 아침 모든 기억을 잃는 똑똑한 동료를 상상해보세요. 이들은 놀라운 추론, 글쓰기, 조사 능력을 가지고 있지만, 어제 했던 일이나 배운 내용, 나눈 대화를 전혀 기억하지 못합니다. 이것이 바로 현재 대부분의 AI 에이전트가 처한 현실입니다.
Philipp Schmid의 “Memory in Agents, Make LLMs remember” 문서를 중심으로 살펴보면, AI 에이전트들은 강력한 성능을 보여주지만 본질적으로 ‘무상태(stateless)’라는 근본적인 한계를 가지고 있습니다. 추론과 도구 사용 분야에서는 상당한 발전을 이루었지만, 과거 상호작용, 사용자 선호도, 학습한 기술을 기억하는 능력은 여전히 충분히 탐구되지 않은 영역입니다.
컨텍스트 엔지니어링의 핵심 도전
LLM의 컨텍스트 윈도우는 정보를 처리하는 제한된 공간입니다. 이 윈도우는 제한된 대역폭을 가지고 있지만, LLM이 작업을 수행하기 위해서는 적절한 정보와 도구를 적절한 형식으로 적절한 시점에 포함해야 합니다. 이것이 바로 컨텍스트 엔지니어링의 핵심입니다.
Andrej Karpathy가 언급했듯이, “다음 단계를 위해 컨텍스트 윈도우를 적절한 정보로 채우는” 것은 섬세한 균형이 필요합니다. 컨텍스트가 너무 적으면 에이전트가 실패하고, 너무 많거나 관련 없는 컨텍스트가 포함되면 비용이 증가하고 성능이 저하될 수 있습니다. 이때 “적절한 정보”의 가장 강력한 원천이 바로 에이전트 자신의 메모리입니다.
AI 에이전트 메모리 시스템의 구조
LLM은 본질적으로 메모리가 없기 때문에, 메모리는 의도적으로 아키텍처에 설계되어야 합니다. 인간의 인지와 마찬가지로, 에이전트 메모리는 두 가지 서로 다른 시간축에서 작동합니다.
단기 메모리 (작업 메모리)
단기 메모리는 컨텍스트 윈도우 자체입니다. 시스템 지침, 최근 대화 기록, 현재 지시사항, 도구 정의 및 현재 상호작용과 관련된 정보를 보유합니다. 이는 “빠르고” 현재 작업에 필수적이지만 일시적이고 크기가 제한적입니다. LLM을 호출할 때마다 다시 구성되어야 합니다.
장기 메모리 (지속적 저장소)
장기 메모리는 벡터 데이터베이스와 같은 외부 데이터 저장소가 필요합니다. 에이전트가 여러 세션과 긴 기간에 걸쳐 정보를 저장하고 회상할 수 있게 해줍니다. 이곳에서 진정한 개인화와 “학습”이 이루어집니다. 장기 메모리는 관련성이 있거나 도움이 될 때 단기 메모리로 로드됩니다.
장기 메모리는 세 가지 유형으로 전문화될 수 있습니다:
의미 메모리 (“무엇”): 사용자에 대한 특정 사실, 개념, 구조화된 지식을 유지합니다. 예를 들어 “사용자가 JavaScript보다 Python을 선호한다”는 정보입니다.
에피소드 메모리 (“언제”와 “어디”): 과거 이벤트나 특정 경험을 회상하여 과거 상호작용을 살펴봄으로써 작업을 수행합니다. 실제 데이터를 활용한 few-shot 예시와 같은 개념입니다.
절차 메모리 (“어떻게”): 에이전트가 작업을 수행하는 방법에 대한 내재화된 규칙과 지침입니다. 예를 들어 여러 사용자가 더 짧은 요약을 요청하는 피드백을 제공했다면 “내 요약이 너무 길다”는 학습이 이에 해당합니다.
메모리 시스템의 주요 이점
메모리를 통합하면 무상태 모델로는 불가능한 기능들이 해제됩니다:
깊은 개인화: 에이전트가 사용자 선호도, 이력, 스타일을 기억하여 각 개인에게 맞춤화된 상호작용을 제공할 수 있습니다.
연속성: 작업을 일시 중지하고 여러 세션에 걸쳐 컨텍스트를 잃지 않고 재개할 수 있습니다.
효율성 향상: 에이전트가 동일한 정보를 반복적으로 묻지 않고 과거의 성공과 실패로부터 학습합니다.
복잡한 추론: 관련 사실과 경험을 회상함으로써 역사적 맥락이 필요한 다단계 문제를 해결할 수 있습니다.
메모리 구현 전략: 명시적 vs 암시적
에이전트가 메모리를 업데이트하는 방법과 시점에 대해서는 두 가지 전략이 있습니다.
명시적 메모리 업데이트
에이전트가 도구 사용을 통해 사용자에게 응답하기 전이나 후에 진행 중인 상호작용 흐름의 직접적인 부분으로 메모리를 업데이트합니다.
장점: 메모리가 실시간으로 업데이트되어 후속 턴에서 즉시 사용 가능하며, 사용자에게 투명하게 공개될 수 있습니다.
단점: 응답에 지연시간을 추가할 수 있고, 메모리 로직과 에이전트 로직을 혼합하여 복잡성을 증가시키며, 에이전트가 응답 생성과 메모리 작업을 동시에 처리해야 합니다.
암시적 메모리 업데이트
메모리 업데이트가 별도의 비동기 백그라운드 프로세스로 발생합니다. 에이전트가 먼저 사용자에게 응답하고, 나중에 백그라운드 작업이 메모리를 업데이트합니다.
장점: 사용자 대면 응답에 지연시간을 추가하지 않고, 메모리 로직을 핵심 에이전트 로직과 분리하며, 에이전트가 응답에 집중할 수 있습니다.
단점: 메모리가 즉시 업데이트되지 않아 짧은 기간 동안 오래된 컨텍스트로 이어질 수 있으며, 백그라운드 프로세스가 언제, 얼마나 자주 실행될지에 대한 신중한 설계가 필요합니다.
메모리 시스템의 핵심 도전과제
메모리를 성공적으로 구현하는 것은 직접적인 피드백이나 영향이 없어 도전적입니다. 메모리 시스템은 시간이 지남에 따라 성장하며, 다음과 같은 핵심 문제들을 해결하기 위해 성능, 정확성, 운영 비용 간의 적절한 균형을 찾아야 합니다:
관련성 문제: 관련 없거나 오래된 메모리를 검색하면 노이즈가 발생하고 실제 작업의 성능이 저하될 수 있습니다. 높은 정밀도를 달성하는 것이 중요합니다.
메모리 비대화: 모든 것을 기억하는 에이전트는 결국 유용한 것을 아무것도 기억하지 못합니다. 모든 세부사항을 저장하면 “비대화”가 발생하여 검색 비용이 증가하고 탐색이 어려워집니다.
망각의 필요성: 정보의 가치는 시간이 지남에 따라 감소합니다. 오래된 선호도나 사실에 따라 행동하는 것은 신뢰할 수 없게 됩니다. 중요한 장기 컨텍스트를 실수로 삭제하지 않으면서 노이즈를 버리는 제거 전략을 설계하는 것은 어렵습니다.
이러한 도전 과제들을 더욱 어렵게 만드는 것은 메모리 시스템의 지연된 피드백 루프입니다. 결함이 있는 메모리 전략의 결과는 시간이 지나야 나타나므로 효과적으로 측정하고 반복하기 어렵습니다.
실제 구현을 위한 도구와 프레임워크
메모리 기능을 더 쉽게 구현할 수 있도록 하는 도구들의 생태계가 성장하고 있습니다. LangGraph, Mem0, Zep, ADK, Letta와 같은 프레임워크들이 메모리 추가를 위한 사용하기 쉬운 통합을 제공합니다.
주요 메모리 프레임워크
LangGraph: LangChain의 일부로, 상태 기반 에이전트 워크플로우와 메모리 관리를 지원합니다. 짧은 시간 메모리는 상태를 통해 관리되고, 체크포인터를 통해 데이터베이스에 지속됩니다.
Mem0: 프로덕션 준비된 AI 에이전트를 위한 확장 가능한 장기 메모리를 구축하는 전문 프레임워크입니다. 사용자 선호도 추출과 저장을 자동화합니다.
Zep: 대화형 AI 애플리케이션을 위한 메모리 레이어를 제공하며, 벡터 검색과 텍스트 검색을 결합한 하이브리드 검색을 지원합니다.
이러한 도구들은 데이터 저장과 검색의 핵심 엔지니어링 과제를 해결합니다. 하지만 성공적인 미래를 위해서는 단순히 더 큰 하드 드라이브가 아니라 더 똑똑한 뇌가 필요합니다.
벡터 데이터베이스의 역할
메모리 시스템의 구현에서 벡터 데이터베이스는 핵심적인 역할을 합니다. MongoDB Atlas Vector Search 같은 현대적인 솔루션은 텍스트와 벡터를 통합된 구조로 결합하여 하이브리드 검색을 가능하게 합니다. 이는 의미적 검색의 유연성과 텍스트 검색의 정확한 키워드 매칭을 모두 제공합니다.
메모리 시스템 구현 사례: RAG 기반 접근법
Decoding ML의 PhiloAgents 프로젝트에서 살펴볼 수 있듯이, 실제 메모리 시스템 구현은 RAG(Retrieval-Augmented Generation) 아키텍처를 중심으로 이루어집니다.
RAG 수집 파이프라인
- 데이터 추출: Wikipedia, Stanford Encyclopedia of Philosophy 등의 소스에서 원시 문서 추출
- 정리: 노이즈나 관련 없는 콘텐츠 제거
- 청킹: 임베딩 모델 컨텍스트 윈도우에 맞는 작은 조각으로 분할
- 중복 제거: MinHash 알고리즘을 사용하여 중복 정보 제거
- 임베딩: 각 청크를 수치 벡터 표현으로 변환
- 저장: MongoDB에 임베딩과 메타데이터 저장 및 벡터 인덱스 생성
RAG 검색 도구
에이전트가 장기 메모리에서 정보가 필요할 때, 검색 도구가 활성화됩니다. 사용자 쿼리를 동일한 임베딩 모델로 임베딩하고, 벡터 인덱스에서 가장 유사한 문서 청크를 찾아 에이전트에게 컨텍스트로 제공합니다. 이것이 바로 Agentic RAG의 핵심입니다.
실용적 구현 고려사항
메모리 시스템을 실제로 구현할 때 고려해야 할 중요한 요소들이 있습니다:
데이터베이스 선택: 지연시간, 처리량, 비용을 모두 고려하여 적절한 데이터베이스를 선택해야 합니다. MongoDB 같은 문서 데이터베이스는 텍스트와 벡터를 통합 관리할 수 있어 인프라 복잡성을 줄일 수 있습니다.
스케일링 전략: 데이터가 증가할 때를 대비한 확장 전략이 필요합니다. MongoDB Atlas는 워크로드 격리와 수평적 확장(샤딩)을 통해 이를 해결합니다.
메모리 업데이트 전략: 애플리케이션의 요구사항에 따라 명시적 또는 암시적 업데이트 전략을 선택해야 합니다.
중복 제거: MinHash와 LSH 같은 효율적인 알고리즘을 사용하여 메모리 비대화를 방지해야 합니다.
에이전트 개인화의 새로운 차원
메모리 시스템이 도입되면 AI 에이전트는 단순한 도구에서 개인화된 어시스턴트로 진화합니다. 사용자의 선호도를 기억하고, 과거 대화의 맥락을 이해하며, 시간이 지남에 따라 더 나은 서비스를 제공할 수 있게 됩니다.
예를 들어, 코딩 어시스턴트 에이전트라면 사용자가 Python을 선호한다는 것을 기억하고, 과거에 어떤 스타일의 코드 설명을 선호했는지 학습하며, 이전 프로젝트에서의 패턴을 참조하여 더 정확한 도움을 제공할 수 있습니다.
메모리 시스템을 갖춘 AI 에이전트는 무상태의 한계를 넘어 진정한 지능형 파트너로 발전할 수 있는 기반을 제공합니다. 하지만 성공적인 구현을 위해서는 관련성, 효율성, 망각의 균형을 신중하게 설계해야 하며, 지연된 피드백 루프를 고려한 장기적인 관점에서 접근해야 합니다.
현재의 도구들은 데이터 저장과 검색의 엔지니어링 과제를 해결했지만, 앞으로는 단순히 더 큰 저장 공간이 아니라 더 똑똑한 메모리 관리가 필요합니다. 메모리 시스템은 AI 에이전트가 진정으로 유용하고 개인화된 도구가 되기 위한 필수적인 다음 단계입니다.
참고자료:
Comments