에이전트에게 필요한 것은 기억이 아니라 문서, 메모리 플러그인 비판과 Operator Memory

TL;DR

• 글쓴이는 시장의 메모리 플러그인이 모두 세션 기록을 조각내 벡터 DB에 넣고 유사한 다섯 조각을 매 프롬프트에 붙이는 같은 구조라고 비판한다. 에이전트가 프로젝트를 이해하는 것이 아니라 조각을 뽑는 복권에 가깝다는 주장이다.
• 지적하는 결함은 다섯 가지다. 유사도로 띄우기, 맥락 없는 저장, 과거를 진실로 취급, 모르는 것은 검색하지 못함, 감사할 수 없는 저장소다.
• 대안은 에이전트가 읽고 갱신하는 마크다운 문서 작업공간이다. 루프는 프롬프트, 빌드, 잊기에서 프롬프트, 참조, 빌드, 갱신으로 바뀐다.
• 글쓴이는 이 모델을 구현한 Operator Memory를 직접 만들었고 1년 넘게 쓴다고 밝힌다. 저장소는 실재하고 BSD-3 라이선스이지만, 기존 플러그인과 비교한 측정은 글에 없다.
• 어느 플러그인도 안정적으로 작동하지 않는다는 강한 결론은 글쓴이의 판단이며 검증된 비교가 아니다.

메모리 플러그인이 하는 일에 대한 비판

글은 메모리 플러그인을 이렇게 요약한다. 대화를 분석해 고립된 조각 1,000개를 만들고 벡터 데이터베이스에 넣는다. 프롬프트마다 가장 비슷한 다섯 조각을 붙이고 에이전트가 헷갈리면 직접 더 검색한다. 글쓴이에 따르면 시장의 모든 메모리 플러그인이 같은 방식이다. 세션 기록을 훑어 기억 조각을 만들고 RAG 데이터베이스에 넣고 프롬프트마다 상위 다섯 개를 주입하며 더 필요하면 에이전트에게 검색 도구를 준다. 일부는 기록을 단어 그대로 검색하게 하거나 단기와 장기 기억을 나누거나 기억을 검토하고 합치는 백그라운드 데몬, 밤새 기억을 고쳐 쓰는 드리머, 지속적 컨텍스트 압축, 재순위화 같은 기능을 얹는다. 그는 이것들이 같은 결함 있는 아키텍처 위에 토큰을 태우는 기능을 덧붙이는 일이라고 본다.

정작 원하는 것은 기능이 어디 있는지, 왜 만들어졌는지, 무엇에 합의했고 무엇을 중시하는지를 에이전트가 이해하는 것이다. 그런데 RAG 조각을 뽑는 복권을 받고 올바른 조각이 떠오르길 바라는 처지가 된다. 설령 작동해도 에이전트가 프로젝트를 이해하지는 못한다는 것이 글의 출발점이다.

회상 방식의 다섯 가지 결함

글쓴이는 공통 결함을 다섯 가지로 든다. 첫째, 기억이 유사도로 떠오른다. 유사도 검색은 임베딩 공간에서 두 조각이 얼마나 가까운지만 재므로 어느 쪽이 맞는지, 최신인지, 무엇이 빠졌는지는 알 수 없다. 둘째, 기억이 맥락 없이 저장된다. 조각에는 담을 수 있는 양이 한정돼 동기, 교훈, 환경 같은 나머지가 사라진다. 셋째, 과거를 진실로 취급한다. 코드베이스는 매일 바뀌는데 인증에 관한 조각 500개가 얼마나 정확하겠는가라는 질문이다. 넷째, 에이전트는 모르는 것을 검색하지 못한다. 검색 도구를 줘도 언제 써야 하는지 모르고 에이전트는 자기가 무엇을 모르는지 모른다. 다섯째, 저장소를 감사할 수 없다. SQLite에 임베딩 1만 개가 있을 때 어떤 기억이 있는지, 낡은 것은 무엇인지, 한 번도 안 불린 것은 무엇인지, 틀린 채 몰래 에이전트를 왜곡하는 것은 무엇인지 알 수 없다.

이 결함들의 뿌리는 에이전트가 잊는 것이 문제이니 더 잘 기억하게 하자는 가정이라고 글은 진단한다. 더 많이 캡처하고 더 잘 색인하고 더 똑똑하게 검색하자는 식이다. 그러나 사람은 지식을 그렇게 다루지 않는다. 3년 전 팀 회의 영상을 다시 돌려 기능의 제약을 기억하는 사람은 없고 적어 둔 기록을 쓴다. 그래서 에이전트에게 지난 1천만 토큰의 대화를 뒤져 조각을 재구성하게 하는 검색 도구를 주는 것이 해법이 아니다. 해법은 문서 기반 기억이다. 이 결함 목록은 저자의 논증이며 특정 제품에서 각 결함이 실제로 얼마나 나타나는지는 측정되지 않았다.

문서 중심 기억과 루프의 변화

글쓴이는 AI로 코드를 한 줄도 읽지 않고 제품과 기능을 쏟아내는 지금 문서가 뒷전이 되기 쉽지만 오히려 더 중요해졌다고 말한다. 사람들은 이미 에이전트에 맥락이 필요하다는 것을 알았고 그래서 AGENTS.md가 나왔다. 그러나 그 파일 하나가 프로젝트의 유일한 문서인 경우가 많다. 에이전트에게는 지시, 명세, 결정, 조사, 색인을 요청 없이도 기록할 수 있는 구조화된 작업공간, 곧 뇌 전체가 필요하다는 것이 그의 주장이다. 코드 리뷰 절차 지침, 사용자와 논의한 내용을 담은 명세, 낯선 라이브러리나 API에 대한 재사용 가능한 조사가 예다.

일할 때는 뇌에서 관련 맥락을 읽고 일한 뒤에는 전체 그림이 컨텍스트에 남아 있는 동안 낡은 것을 고치고 필요한 문서를 추가한다. 루프는 프롬프트, 빌드, 잊기에서 프롬프트, 참조, 빌드, 갱신으로 바뀌고 기억은 에이전트에 붙이는 RAG 데이터베이스에서 읽고 고치고 공유할 수 있는 작업공간으로 바뀐다. 이 발상의 장점은 명확하다. 기억이 감사 가능하고 버전 관리된다. 다만 글은 문서가 낡는 문제를 에이전트가 성실히 갱신한다는 가정에 기댄다. 그 가정이 실제로 얼마나 지켜지는지는 보여 주지 않는다.

직접 만든 Operator Memory와 그 근거

글쓴이는 1년 넘게 AI로 프로그래밍하며 이 문제를 알아봤고 internal 폴더를 만들어 에이전트에게 명세, 계획, 색인을 모두 적게 하고 작업 전에는 관련 문서와 색인을 읽고 작업 후에는 갱신하도록 시켰다고 한다. 이 초보적 지침이 체계가 되고 Operator Memory라는 플러그인이 되었다. 그가 강조하는 특징은 벡터 DB도 임베딩도 요약기, 큐레이터, 갱신기, 드리머 같은 백그라운드 데몬도 없다는 점이다. 모든 것이 읽고 고치고 커밋하고 팀과 공유할 수 있는 평범한 마크다운이다.

노트 작성 중 GitHub 저장소를 확인했다. aerovato/operator-memory가 실재하며 BSD-3-Clause 라이선스로 공개돼 있고 README는 Claude Code, Codex, OpenCode, Pi, DeepSeek 하니스용 어댑터를 지원한다고 밝힌다. 설정은 에이전트와의 대화로 진행하는 초기화 명령으로 이뤄진다. 다만 README와 글 어디에도 이 방식이 RAG 기반 플러그인보다 낫다는 측정이나 사용자 사례는 없다. 글쓴이는 제품의 제작자이므로 이해관계가 있고 1년 넘게 썼다는 것도 본인 진술이다. 그래서 이 글은 설계 논증으로는 흥미롭지만 어느 접근이 실제로 더 낫다는 증거로는 읽을 수 없다. 자기 프로젝트에서 AGENTS.md를 넘어선 문서 구조를 시험해 보는 출발점 정도로 받아들이는 편이 안전하다.

참고 자료

liao.gg — Agents Don’t Need Memory. They Need Documentation.

aerovato/operator-memory (GitHub) — 저장소 실재, 라이선스, 지원 하니스를 README로 대조했다. 코드는 실행하지 않았다.