모델들이 점점 더 좋아지고 있습니다. 이곳 세계 박람회(World's Fair)에서 제시된 여러 그래프를 통해 보셨듯이, 50% 성공률을 보이는 작업 지속 시간 지평(task duration horizon)이 점점 더 길어지고 있습니다. 지평이 길어질수록 컨텍스트 관리(context management)가 더욱 중요해지며, 비교적 새롭고 매우 활발하게 논의되는 주제인 메모리 관리(memory management)는 훨씬 더 중요해지고 있습니다.

제가 메모리(memory)에 대해 이야기할 때, 컴퓨터 메모리(RAM)를 말하는 것이 아닙니다. 그것은 흥미롭거나 참신하지 않습니다 (현재로서는 대부분 우울할 뿐입니다). 저는 여러분의 에이전트(agent)가 가진 메모리, 즉 에이전트가 자신이 무엇을 했는지, 무엇을 알고 있는지, 그리고 무엇을 해야 하는지를 어떻게 추적하는지에 대해 이야기하고 있습니다. 혼란을 드려 죄송합니다: 소프트웨어의 이름을 짓는 것은 어렵습니다. 그렇기는 하지만, 이 글의 나머지 부분에서

🧭 처음 오셨나요? 01 Conversation Buffer Memory부터 시작하거나 학습 경로 (Learning Path)를 선택해 보세요. 시각적인 자료를 선호하시나요? 아래의 의사 결정 트리 (Decision Tree)를 확인하세요. 대화 버퍼 (Conversation Buffers), 벡터 저장소 (Vector Stores), 지식 그래프 (Knowledge Graphs), 에피소드 및 의미론적 메모리 (Episodic and Semantic Memory), 작업 메모리 (Working Memory), MemGPT, Mem0, Letta, Zep, Graphiti, LoCoMo 벤치마크, 그리고 프로덕션 메모리 패턴 (Production Memory Patterns)을 다루는 30개의 실행 가능한 Jupyter Notebook이 준비되어 있습니다.

📖 RAG에 대해 더 깊이 알아보기

RAG Made Simple - RAG에 대한 400페이지 분량의 시각적 가이드로, 이 레포지토리의 저자가 집필했습니다. Amazon 베스트셀러인 생성형 AI 분야에서 · 1,500+ 독자 · ⭐ 4.6

구매하기 - 코드 RAGKING 사용 시 33% 할인 → · 챕터 1 무료 읽기

📫 최신 정보 받기 (Stay Updated)

<table><tbody><tr><td>🚀<br><b class="text-xl">주간(Weekly)<br>업데이트</b></td><td>💡<br><b class="text-xl">전문가 인사이트(Expert Insights)</b></td><td>🎯<br><b class="text-xl">상위 0.1% 콘텐츠(Top 0.1% Content)</b></td></tr></tbody></table>

GitHub에서 보기

직접 읽어보시길 권장합니다. 이 메모리 관리 도구들은 해결하는 문제 유형에 따라 여섯 가지 범주로 나뉘며, 아래에서 그 여섯 가지 범주를 살펴보겠습니다.

단기(Short-Term)

이러한 단기 솔루션은

첫 번째 방식은 다른 모든 방식이 개선해 나갈 토대가 됩니다. Conversation Buffer 메모리를 사용할 때는 전체 채팅 기록을 있는 그대로 저장하고, 매 LLM 호출 시 전체 내용을 전부 전송합니다. 컨텍스트(Context) 측면에서 이것이 상당히 빠르게 유지 불가능한 상태가 될 것이라는 점은 명확하지만, 규모가 가장 작고 설정이 가장 적게 필요합니다. 여기서 추적해야 할 주요 관심사는 누가 무엇을 말했는지와 사용 중인 토큰(Token)의 양입니다.

Sliding Window 메모리는 효과는 동일하지만, 컨텍스트 초과를 방지하기 위해 마지막 N개의 메시지만 메모리에 유지합니다. 컨텍스트 제한에 걸리지 않을 것이라고 확신할 수 있지만, 모델은 엄격한 "장기 기억 상실" 문제를 겪게 됩니다. 정해진 수의 토큰 전에서 발생한 일은 아무것도 기억하지 못하게 됩니다.

Summary 메모리는 가공되지 않은 대화 기록을 이전 기록에 대해 LLM이 생성한 요약본으로 대체합니다. 이 방식 또한 컨텍스트 초과를 방지하며, 정보가 요약본에 포함될 만큼 충분히 중요하다면 최소한의 장기 기록을 유지할 수 있게 해줍니다. 여기에는 요약기가 무관하다고 판단하는 내용을 제외함으로써 가장 중요한 내용들을 컨텍스트에 남길 수 있다는 숨겨진 부수적 이점이 있습니다. 또 다른 숨겨진 단점은 매 턴마다 컨텍스트를 요약하기 위한 2차 LLM 호출이 필요하다는 점입니다.

Summary Buffer는 앞선 두 기술 사이의 균형을 맞추며, 현재 코딩 도구들의 기본 기능에 가장 가깝습니다. 즉, 가장 최근의 N개 메시지는 메모리에 있는 그대로 유지하되, 오래된 메시지는 직접 삭제하는 대신 요약합니다. 이러한 균형은 자체적인 튜닝(Tuning)이 필요하다는 비용을 수반합니다. 이제 우리는 구성(Configuration)과 데이터를 저장할 장소가 필요한 메모리 "시스템(Systems)"에 더 깊이 들어가고 있음을 알 수 있습니다. 원문 그대로 유지할 버퍼 크기, 요약 갱신 주기, 그리고 토큰 예산 사이의 균형을 맞춰야 하며, 비용 효율적일 때만 압축을 수행해야 합니다.

이 섹션의 마지막 기술은 **토큰 버퍼 (Token Buffer)**입니다. 작동 방식은 요약 버퍼 (Summary Buffer)와 유사하지만, 대화 기록 내의 정확한 토큰 수를 수동으로 추적할 수 있도록 모델의 토크나이저 (tokenizer)에 접근할 수 있어야 합니다. 장점은 더 길고 더 많은 토큰을 필요로 하는 개별 메시지를 고려할 수 있어, 약간의 추가 컨텍스트를 희생하는 대신 토큰 비용을 더 엄격하게 제어할 수 있다는 점입니다.

장기 기억 (Long-Term)

장기 솔루션은 "세션, 사용자, 그리고 시간을 초월하여 지식을 저장하는" 문제를 해결합니다. 이 문제는 작업을 수행하기 위해 에이전트 (agent)를 실행하고, 그 과정에서 학습한 모든 것을 유지하면서 에이전트를 폐기하는 방식에 대해 더 "에이전트적 (agentically)"으로 생각하기 시작할 때 발생합니다. 다음은 메모리를 저장하는 여섯 가지 서로 다른 방법입니다.

첫 번째 진정한 "성숙한" 메모리 유형인 **벡터 스토어 (Vector Store)**부터 시작하겠습니다. 대화의 각 턴 (turn)은 벡터 데이터베이스 (vector database)에 임베딩 (embedded)되며, 과거 대화와의 유사성을 기반으로 검색될 수 있습니다. 이를 위해서는 (예상하셨겠지만) 벡터 데이터베이스와 이러한 임베딩을 생성하기 위한 임베딩 모델 (embedding model)이 필요합니다. 여기서 한 가지 이점은 RAG 스타일의 생성 (generation)을 위해 이미 임베딩과 벡터 DB가 필요한 시스템에서 자연스럽게 통합된다는 점입니다.