에이전트에게 필요한 것은 기억이 아니라 문서입니다

AI 요약

에이전트 메모리 플러그인은 대화 기록을 작은 조각으로 나눠 RAG 데이터베이스에 저장하고, 매 프롬프트마다 비슷한 조각을 검색해 붙이는 방식이 많습니다. 글쓴이는 이 구조가 프로젝트의 기능이 어디에 있는지, 왜 만들었는지, 어떤 결정을 내렸는지 알려주기보다 과거 대화 조각을 다시 찾는 데 치중한다고 봅니다. 그래서 에이전트에게 필요한 것은 더 나은 회상이 아니라 관리되는 문서라고 주장합니다.

검색 기반 메모리의 한계

글쓴이가 꼽는 문제는 다섯 가지입니다. 유사도 검색은 조각의 관련성을 순위로 매길 뿐, 정보가 정확하거나 최신인지 보장하지 않습니다. 조각만 저장하면 당시 맥락과 동기, 교훈, 실행 환경이 빠집니다. 코드베이스가 바뀌어도 과거 기록은 남아 현재 상태와 어긋날 수 있습니다. 에이전트는 무엇을 모르는지 모를 수 있어 검색 도구를 언제 써야 할지 판단하기 어렵습니다. 임베딩이 쌓인 저장소는 어떤 기록이 남았고, 낡았거나 틀린 정보가 무엇인지 감사하기도 어렵습니다.

이런 한계를 보완하려고 요약·재정렬·중복 제거·백그라운드 갱신 기능을 더해도, 글쓴이는 과거를 수집하고 다시 찾는 구조 자체는 그대로라고 지적합니다. 팀이 몇 년 전 회의를 다시 재생해 결정을 기억하지 않고 기록을 작성해 참고하듯, 에이전트도 대화 조각보다 문서를 참고해야 한다는 설명입니다.

작업 전 읽고 작업 후 갱신하는 문서 체계

AGENTS.md는 에이전트가 저장소에 들어올 때 기본 안내를 제공하지만, 프로젝트 지식 전체를 담기엔 부족합니다. 글쓴이는 지침, 사양, 결정 사항, 조사 자료, 문서 색인을 담는 구조화된 작업 공간을 제안합니다. 에이전트는 작업 전에 관련 문서와 색인을 확인하고, 작업을 마친 뒤에는 낡은 문서를 고치거나 필요한 문서를 새로 씁니다. 작업 흐름도 ‘프롬프트 → 구현 → 잊기’에서 ‘프롬프트 → 문서 확인 → 구현 → 문서 갱신’으로 바뀝니다.

글쓴이는 AI와 코딩을 시작한 뒤 프로젝트의 internal/ 폴더에 사양과 계획, 색인을 기록하게 하면서 이 방식을 시험했다고 설명합니다. 이를 정식화해 만든 플러그인이 Operator Memory입니다. 에이전트가 Markdown 문서를 읽고 갱신하며, 문서는 사람이 열어보고 수정하거나 Git에 커밋하고 팀과 공유할 수 있습니다. 글쓴이는 벡터 데이터베이스, 임베딩, 요약기, 백그라운드 데몬을 쓰지 않는다고 설명합니다.

Hacker News 반응

• @jdw64 — Peter Naur는 유명한 글 「Programming as Theory Building」에서 문서만으로 프로그램의 완전한 정신 모델을 담거나 보존할 수 없다고 주장했습니다. 다만 AI는 사람과 달리 작업 맥락을 훨씬 더 명시해야 합니다. 그래서 AI가 프로그램 전체 모델을 유지하거나 재구성하는 방식은 사람과 근본적으로 다를 수 있습니다.
  • @iamwil — 그렇다면 에이전트가 프로그램을 확장하도록 이끌 만큼 그 이론을 어떻게 머릿속에 유지하나요? 여러 사람에게 물어봤는데 각자 일하는 방식에 따라 방법이 달라 보입니다.
• @alienbaby — 비슷한 시스템을 만들어 집안의 ‘기억’을 관리해 봤습니다. 자료가 늘면 문서를 읽고 고치고 오래된 정보를 정리하느라 토큰을 빠르게 씁니다. 작은 작업도 비용이 커질 수 있습니다. 그래도 집의 인프라, 서비스, CI/CD, 호스트, 저장소, 네트워크 정보를 잘 정리해 두면 여러 프로젝트에서 공유할 기준 자료로 아주 유용했습니다.
• @monneyboi — 코딩 에이전트용 메모리 솔루션이 왜 필요한지 이해하지 못했습니다. 세션 기록 전체가 이미 있습니다. 기억을 찾는 기능과 JSON 파싱만 더하면 완벽한 기록을 grep으로 검색할 수 있는데, 왜 더 많은 도구와 토큰을 써서 불완전한 기억을 따로 만들까요?
  • @ceejayoz — 세션 기록은 그 세션 하나의 기록입니다. 메모리는 다음 세션에 쓰는 것 아닌가요?
• @gregwebs — 동의합니다. 다만 에이전트 전용 문서를 따로 두고 싶지는 않습니다. 저는 ADR(Architectural Decision Record), CONTRIBUTING.md, CODING_STANDARDS.md, README, 아키텍처 문서와 커밋 기록을 씁니다. 에이전트가 기존 문서를 찾아 읽고 최신 상태로 유지합니다.
  • @gojogs — LLM이 만든 문서는 내용이 흐리고 초점이 없는 경우가 많습니다. 라이브러리 특이점은 세 문단씩 쓰면서 명령어 예시는 두 개만 넣기도 합니다. README와 문서는 직접 씁니다. 내가 기록할 가치가 없다고 보는 내용은 중요하지 않고, 맥락이 작을수록 읽기도 쉽습니다.
• @zahrevsky — 메모리 플러그인이 잘 작동하지 않는다는 데는 동의하지만, 메모리 조각은 과거 대화 기록을 그대로 다시 읽는 방식이 아닙니다. 문제는 발언마다 메모를 만들고 수천 개의 메모리를 다루는 데 있습니다. 중요한 내용만 골라 문서로 남겨야 합니다. 최종 상태뿐 아니라 결정에 이른 과정을 남기려면 ADR도 쓸 수 있습니다.
  • @pornel — 에이전트가 사양을 쓰더라도 사람의 승인 없이 믿지는 않습니다. 에이전트가 추측한 세부사항이나 요청하지 않은 기능을 ADR에 넣어 문제가 생긴 적이 있습니다. 그런 내용이 문서에 남으면 계속 되돌아옵니다.
• @stbenjam — 에이전트가 만든 Markdown 문서를 저장소에 대량으로 넣는 흐름이 늘고 있지만, 문서가 에이전트 성능을 실제로 높이는지, 시간이 지나도 썩지 않는지 보여주는 근거는 아직 보지 못했습니다. 정보 탐색을 돕는 간결한 AGENTS.md, 결과를 검증하는 방법, 프로젝트별 선호사항이면 충분하고 나머지는 잡음일 수 있습니다.
• @DriverDaily — 뇌는 경험을 문장으로 만들지 않아도 관계를 정리합니다. 원인과 결과처럼 관계를 따라 관련 생각을 빠르게 찾습니다. 문서는 그런 방식으로 효율적으로 조회하기 어려우니 데이터베이스가 필요합니다.
  • @apsurd — 뇌와 그래프 데이터베이스를 비교하는 건 섣부른 가정 같습니다. 에이전트 메모리가 인간 기억과 같은 방식이어야 한다고 볼 이유도 없습니다. 문서로 분명하게 전달하는 편이 복잡한 메모리 체계를 만드는 것보다 직접적이라는 글의 주장에 더 가깝습니다.
• @jmtulloss — 평가가 없으면 성능 주장을 믿기 어렵습니다. 이런 시스템의 성능을 어떻게 측정하는지, 어떤 작업이 각 접근 방식에 잘 맞는지 궁금합니다.
• @jsemrau — 문서화가 곧 기억입니다.

원문: liao.gg / 번역·요약: Trawling