A tangle of colorful wires

에이전트는 메모리가 필요하지 않습니다. 문서화가 필요합니다.

메모리 플러그인은 사용자의 대화를 분석합니다. 1,000개의 독립적인 스니펫을 생성하여 벡터 데이터베이스에 삽입합니다. 사용자 프롬프트가 있을 때마다 가장 유사한 5개 스니펫을 첨부하며, 에이전트가 혼란스러워하면(실제로 그렇습니다), 수동으로 더 많은 정보를 검색합니다. 이것이 바로 그들이 '메모리'라고 부르는 제품입니다.

어떤 문제를 해결하려 하는지 생각해보면 사용하기 이상한 것입니다. 당신은 에이전트가 프로젝트를 이해하기를 원합니다. 어떤 기능이 어디에 있는지, 왜 만들어졌는지, 무엇에 합의했고 무엇을 중요하게 생각하는지 알기를 바랍니다. 대신, 매 프롬프트마다 주입되는 RAG 스니펫들의 복권 같은 것을 받게 되며, 올바른 것들이 떠오르기만을 바랄 뿐입니다.

심지어 작동할 때도 에이전트는 여전히 프로젝트를 이해하지 못합니다. 전체 메모리 플러그인 생태계는 잘못된 문제를 해결하고 있습니다.

왜냐하면 에이전트에게는 메모리가 필요하지 않기 때문입니다. 문서화가 필요하기 때문입니다.

전부 RAG에 불과하다

시장에 나와 있는 모든 메모리 플러그인은 같은 방식으로 작동합니다:

• 세션 기록을 통과하며
• '메모리' 스니펫을 생성하고
• RAG 데이터베이스에 삽입한 후
• 매 프롬프트마다 상위 5개를 검색하여 주입합니다.
• 더 필요하면? 에이전트에게 RAG 데이터베이스를 검색할 도구를 제공합니다.

이것이 전체 아키텍처입니다. 어떤 도구는 훨씬 화려해서, 에이전트가 과거 기록을 단어 단위로 검색하게 합니다. 또는 단기/장기 메모리를 분류하는 일종의 다단계 메모리 시스템을 구현하거나, 기억을 검토하고 병합하거나 중복 제거하기 위해 많은 백그라운드 데몬을 추가합니다. 밤새도록 메모리를 다시 작성하는 'Dreamers' 같은 것들이 있습니다. 지속적인 컨텍스트 압축(Continuous context compression). 리랭커(Rerankers) 등입니다.

각 플러그인은 동일한 결함 있는 아키텍처를 수정하기 위해 새로운 토큰을 소모하는 '기능'을 추가하려고 합니다. 그리고 이것이 그들이 신뢰성 있게 작동하지 않는 이유입니다.

검색(Recall)의 문제점

메모리는 유사성으로 표면화됩니다. 유사성 검색(Similarity search)은 임베딩 공간에서 두 스니펫이 얼마나 가까운지를 순위 매깁니다. 그게 전부입니다. 무엇이 정확한지, 최신인지, 또는 무엇이 빠져 있는지 당신은 알 수 없습니다.메모리는 맥락 없이 저장됩니다. RAG 스니펫은 담을 수 있는 양에 한계가 있습니다. 나머지 모든 것—맥락(context), 동기(motivations), 교훈(lessons), 환경(environment) 등—을 잃게 됩니다.과거는 진실로 취급됩니다. 이 모든 플러그인은 회상(recall)에 의존합니다. 녹취록 검색이든 벡터 데이터베이스 검색이든 마찬가지입니다. 하지만 코드베이스는 매일 변경되는데, 인증에 관한 500개 스니펫 각각이 얼마나 정확할까요?에이전트는 모르는 것을 검색할 수 없습니다. 심지어 에이전트에게 검색 도구(search tool)를 노출하더라도, 언제 그것을 사용해야 할지 어떻게 알까요? 에이전트는 자신이 무엇을 모르는지 모릅니다.저장소는 감사 불가능합니다. SQLite에 10,000개의 임베딩이 있습니다. 어떤 메모리가 존재할까요? 어떤 것이 오래되었을까요(stale)? 어떤 것이 한 번도 검색되지 않았을까요? 어떤 것이 부정확하여 에이전트가 작동하는 방식을 비밀리에 영향을 미치고 있을까요?

이것들은 메모리 플러그인들이 직면하고, 시도하고, 해결하지 못하는 수많은 문제 중 단지 다섯 가지일 뿐입니다. 왜냐하면 이 모든 것들이 같은 가정을 하기 때문입니다:

에이전트는 잊어버립니다: 그게 문제입니다. 그래서 해결책은 기억하는 것입니다. 더 잘 기억하려면, 우리는 더 많이 포착하고, 더 잘 인덱싱하며, 더 스마트하게 검색해야 합니다.

그들의 전체 논지는 과거를 포착하고 회상하는 것에 초점을 맞춥니다. 하지만 아무도 지식을 그렇게 처리하지 않습니다. 아무도 3년 전 팀 미팅을 다시 보면서 특정 기능에 대한 제약 사항을 기억하지 않습니다. 사람들은 그것들을 적어두고 그 기록을 사용합니다.

마찬가지로, 해결책은 에이전트에게 과거 10백만 토큰 분량의 대화에서 검색하는 도구를 주는 것이 아닙니다. 이 과정에서 발생하는 파편적인 내용을 재구성하게 만드는 방식도 아닙니다.

해결책은 문서 기반 메모리(document-based memory)입니다.

오늘날 사람들은 코드를 한 줄도 읽거나 이해하지 못한 채 빛의 속도로 제품, 기능, 그리고 잡다한 결과물을 AI로 쏟아냅니다. 이러한 상황에서는 문서화가 그 어느 때보다 중요해야 함에도 불구하고 사후 처리되는 경우가 생기기 쉽다는 것을 알 수 있습니다.

회상(Recall)을 넘어선 문서화(Documentation)

사람들은 이미 에이전트에게 컨텍스트(context)가 필요하다는 것을 알고 있었습니다. 그래서 그들은 에이전트가 코드베이스에 무작정 뛰어드는 것을 막기 위해 AGENTS.md 파일을 발명했습니다. 이것은 작동합니다. 하지만 종종 이 단일 파일이 프로젝트가 가진 유일한 문서화 자료인 경우가 많습니다.

단 하나의 파일로는 충분하지 않습니다. 에이전트는 지시 사항, 사양(specs), 결정 사항, 연구 내용, 인덱스 등 요청받지 않아도 기록할 수 있는 전체적인 두뇌, 즉 구조화된 작업 공간이 필요합니다. 코드 리뷰 프로세스가 어떻게 작동하는지에 대한 지침, 사용자와 논의한 내용을 상세히 설명하는 사양, 외국 라이브러리나 API에 대한 재사용 가능한 연구 자료 등이 필요합니다.

에이전트가 작업을 수행할 때, 에이전트는 이 '두뇌'에서 파일을 읽어 관련성 있고 완전한 컨텍스트를 얻을 수 있습니다. 작업 후에는 필요한 곳에 새로운 문서를 추가하고 오래된 내용을 업데이트하면서 전체 그림(full picture)은 계속 유지됩니다. 이런 방식으로 에이전트 루프는 프롬프트 → 빌드 → 망각에서 프롬프트 → 참고 → 빌드 → 업데이트로 바뀝니다. 메모리는 에이전트에 붙이는 RAG 데이터베이스가 아니라, 읽고, 업데이트하고 심지어 공유할 수 있는 작업 공간으로 변모하는 것입니다.

실제로 적용해 보기

제가 이 문제를 인식한 것은 AI와 프로그래밍을 시작한 지 1년여 전입니다. 저는 에이전트가 세션 간에 작업을 기억할 방법을 원했고, 그래서 internal/ 폴더를 만들고 에이전트에게 사양, 계획, 인덱스 등 모든 것을 기록하도록 요청했습니다. 저는 에이전트에게 작업 수행 전에 항상 적절한 문서를 읽고 인덱스를 참고하며, 작업 후에 업데이트하도록 임무를 부여했습니다.

이러한 기초적인 지침 세트는 점차 공식적인 시스템으로 변모했고, 결국 제가 모든 프로젝트에서 정기적으로 사용하고 있는 Operator Memory라는 플러그인이 되었습니다。

Diagram comparing the prompt, build, forget loop with Operator Memory's prompt, consult, build, update loop

Operator Memory는 위에서 설명한 모델을 사용하여 문서 기반 메모리를 제공합니다. Operator는 에이전트에게 중요한 지식(지침, 사양, 연구 자료, 인덱스)을 영구적으로 저장할 수 있는 Markdown 브레인(brain)을 제공합니다. 작업하기 전에 에이전트는 항상 관련 문서를 위해 이 브레인을 참조합니다. 작업 후에는 에이전트가 브레인을 업데이트하며, 오래된 문서들을 재검토하고 누락된 곳에 문서를 추가합니다.

벡터 데이터베이스도 없고, 임베딩(embeddings)도 없습니다. 요약기(summarizers), 큐레이터(curators), 업데이트기(updaters), 드리머(dreamers) 또는 기타 토큰을 소모하는 백그라운드 데몬도 없습니다. 블랙박스 검색 과정도 없습니다.

Operator를 사용하면 모든 것이 읽고, 업데이트하고, 커밋하고, 팀과 공유할 수 있는 일반 Markdown 문서입니다. 저는 이 시스템을 1년 넘게 사용해 왔습니다. 한번 사용해 보고 싶다면, 무료이며 오픈 소스입니다: https://github.com/aerovato/operator-memory