AI 에이전트에게 필요한 것은 기억보다 문서다

기억 플러그인은 대화에서 고립된 메모 1,000개를 만들고, 매 프롬프트마다 비슷한 메모 다섯 개를 붙인다. 에이전트가 헷갈리면 더 많은 메모를 직접 찾게 한다.

이 글의 주장은 기억 플러그인이 문제를 잘못 짚었으며, 에이전트에는 과거 대화 검색보다 문서로 정리된 프로젝트 지식이 필요하다는 것이다. 프로젝트의 구조와 결정 이유를 에이전트에게 알려야 하는 팀이라면, 기억 저장소를 늘리기보다 문서를 어떻게 만들고 갱신할지 살펴볼 만하다.

기억 플러그인은 어떻게 작동하나?

일반적인 기억 플러그인은 대화 기록을 훑어 ‘기억’이라는 짧은 조각을 만들고, 이를 검색 증강 생성(RAG) 데이터베이스에 넣는다. 매 프롬프트마다 관련도가 높은 다섯 개를 찾아 입력에 붙인다. 더 필요하면 에이전트가 데이터베이스를 검색하는 도구도 제공한다. 이것이 기본 구조다.

일부 도구는 과거 대화 기록을 문장 그대로 검색하게 하거나, 단기·장기 기억을 나누는 여러 단계의 구조를 둔다. 기억을 검토하고 합치거나 중복을 제거하는 백그라운드 프로세스를 추가하기도 한다. 밤사이 기억을 다시 쓰는 ‘드리머’, 맥락을 계속 압축하는 기능, 검색 결과 순위를 다시 매기는 기능도 있다. 이 글은 이런 기능들이 같은 취약한 구조를 고치려다 토큰을 더 쓰게 만든다고 주장한다.

과거를 검색하는 방식에는 어떤 문제가 있나?

첫째, 기억 조각은 유사도로 선택된다. 유사도 검색은 임베딩 공간에서 두 조각이 얼마나 가까운지를 순위로 매길 뿐이다. 그 내용이 정확한지, 최신인지, 무엇이 빠졌는지는 알려주지 않는다.

둘째, 짧은 검색 조각에는 맥락이 담기기 어렵다. 동기와 배경, 교훈, 작업 환경 같은 정보가 빠질 수 있다. 셋째, 과거 기록을 현재의 사실처럼 취급한다. 코드베이스는 매일 바뀌는데, 인증에 관한 기억 조각 500개가 지금도 정확한지 확인하기 어렵다는 것이다.

넷째, 에이전트는 자신이 모르는 내용을 검색할 수 없다. 검색 도구를 줘도 언제 검색해야 하는지 알지 못할 수 있다. 다섯째, 저장소를 감사하기 어렵다. SQLite에 임베딩 10,000개가 있을 때 어떤 기억이 들어 있는지, 무엇이 오래됐는지, 한 번도 검색되지 않은 항목은 무엇인지, 잘못된 내용이 에이전트의 동작에 영향을 주는지 파악하기 어렵다는 지적이다.

이 글은 다섯 가지 문제의 뿌리를 ‘에이전트는 잊어버린다’는 가정에서 찾는다. 기억을 더 많이 저장하고, 색인과 검색을 개선하면 된다는 발상 자체가 과거를 모으고 되살리는 데 집중한다는 것이다. 하지만 사람은 기능의 제약을 기억하려고 3년 전 팀 회의를 다시 보는 대신 기록을 작성하고 참고한다는 것이 글의 주장이다. 과거 대화 1,000만 토큰을 검색해 단편을 이어 붙이는 대신 문서를 바탕으로 지식을 관리해야 한다고 제안한다.

문서 중심 방식은 어떻게 다르나?

코딩 에이전트가 코드베이스를 파악하도록 프로젝트에 AGENTS.md 파일을 두는 방식은 이미 쓰이고 있으며, 글은 이것이 효과가 있다고 본다. 다만 프로젝트 문서가 그 파일 하나뿐인 경우가 많고, 하나만으로는 부족하다고 지적한다. 에이전트가 지침과 명세, 결정 사항, 조사 결과, 색인 등을 기록할 수 있는 구조화된 작업 공간이 필요하다는 것이다.

예를 들어 코드 검토 절차에 관한 지침, 사용자와 논의한 내용을 정리한 명세, 생소한 라이브러리나 API에 대한 재사용 가능한 조사 결과를 둘 수 있다. 작업을 시작하기 전에 에이전트는 관련 문서와 색인을 읽는다. 작업이 끝나면 아직 맥락을 파악하고 있는 동안 오래된 문서를 고치고, 필요한 새 문서를 추가한다. 이에 따라 작업 흐름은 ‘프롬프트 → 만들기 → 잊기’에서 ‘프롬프트 → 참고하기 → 만들기 → 갱신하기’로 바뀐다.

Operator Memory는 어떻게 쓰나?

글쓴이는 AI로 처음 프로그래밍을 시작한 1년여 전, 세션을 넘어서 작업 내용을 기억할 방법을 찾다가 프로젝트 안에 internal/ 폴더를 만들었다. 에이전트에게 명세와 계획, 색인을 그곳에 기록하도록 하고, 작업 전에는 관련 문서와 색인을 읽고 작업 후에는 갱신하도록 했다. 이 간단한 지침은 정식 시스템으로 발전했고, 글쓴이는 이를 Operator Memory라는 플러그인으로 만들어 자신의 프로젝트에서 꾸준히 사용하고 있다고 설명한다.

Operator Memory는 앞서 제안한 문서 기반 방식을 제공한다. 에이전트가 중요한 지식을 지침, 명세, 조사 결과, 색인 형태로 보관하는 마크다운 작업 공간을 둔다. 에이전트는 작업 전에 관련 문서를 확인하고, 작업 후에는 오래된 문서를 다시 살피거나 빠진 문서를 추가한다. 벡터 데이터베이스와 임베딩, 요약·관리·갱신을 위한 백그라운드 프로세스, 블랙박스 검색은 쓰지 않는다. 모든 내용은 읽고 수정하고 버전 관리 시스템에 반영하거나 팀과 공유할 수 있는 일반 마크다운 문서로 남는다.

글쓴이는 이 시스템을 1년 넘게 사용했다고 밝힌다. Operator Memory는 무료 오픈소스이며, 저장소는 GitHub에서 확인할 수 있다. 다만 글은 기억 플러그인과 문서 기반 방식의 성능을 비교한 평가나 구체적인 설치·사용 조건은 밝히지 않는다.