AI 에이전트 기억 플러그인 대신 마크다운 문서 저장소를 쓰자는 제안

AI 코딩 에이전트에 '기억'을 붙여주는 플러그인이 잇따라 나오는 가운데, 개발자 Kevin Liao가 그 접근이 애초에 잘못된 문제를 풀고 있다는 글을 쓰고 문서 기반 메모리 플러그인 Operator Memory를 함께 공개했다. 요지는 이렇다. 에이전트가 세션을 넘길 때마다 프로젝트를 잊는 이유는 기억력이 부족해서가 아니라, 읽을 만한 문서가 없어서다.

시중의 메모리 플러그인은 구조가 대동소이하다. 대화를 잘게 쪼개 스니펫으로 만들고, 이를 벡터 데이터베이스에 밀어 넣는다. 프롬프트가 들어올 때마다 임베딩 공간에서 유사도가 높은 상위 5개를 골라 컨텍스트에 끼워 넣고, 그래도 부족하면 에이전트가 직접 검색 도구를 호출해 더 찾아 나선다. 여기에 단기·장기 기억을 분류하는 다층 구조, 야간에 기억을 병합하거나 중복을 제거하는 백그라운드 데몬, 재순위화 모델 같은 기능이 덧붙는다. 저자는 이런 부가 기능이 토큰만 태울 뿐 아래 깔린 설계 자체를 고치지 못한다고 본다.

문제는 다섯 가지로 정리된다. 첫째, 기억은 유사도로만 소환된다. 두 스니펫이 임베딩 공간에서 얼마나 가까운지만 볼 뿐, 어느 쪽이 맞는지, 최신인지, 무엇이 빠졌는지는 알 수 없다. 둘째, 스니펫에는 맥락이 담기지 않는다. 왜 그렇게 결정했는지, 어떤 제약이 있었는지, 어떤 시행착오를 겪었는지는 잘려 나간다. 셋째, 과거를 진실로 취급한다. 코드베이스는 매일 바뀌는데 인증에 관한 스니펫 500개가 여전히 정확하다고 믿을 근거가 없다. 넷째, 에이전트는 자기가 모르는 것을 검색할 수 없다. 검색 도구를 쥐여줘도 언제 써야 하는지 모르면 무용지물이다. 다섯째, 저장소를 감사할 방법이 없다. SQLite에 쌓인 임베딩 중 무엇이 낡았고 무엇이 한 번도 조회되지 않았는지, 어떤 잘못된 기억이 조용히 동작에 영향을 주고 있는지 파악하기 어렵다.

이 글의 배경에는 문서가 뒷전으로 밀린 개발 관행이 있다. AI로 제품과 기능을 빠르게 찍어내면서 코드를 직접 읽지 않는 일이 흔해졌고, 그럴수록 문서는 더 중요해져야 하는데도 우선순위에서 밀린다. 에이전트가 코드베이스에 눈먼 채 뛰어들지 않도록 AGENTS.md 파일을 두는 관행이 자리 잡았지만, 저자는 그 파일 하나가 프로젝트의 유일한 문서인 경우가 많다는 점을 지적한다.

대안으로 제시하는 것은 문서 기반 메모리다. 에이전트에게 지시문, 스펙, 결정 기록, 리서치, 인덱스를 스스로 쌓아두는 마크다운 워크스페이스, 이른바 '두뇌'를 준다. 작업 전에는 두뇌에서 관련 문서를 읽어 완전한 맥락을 확보하고, 작업 후에는 낡은 문서를 갱신하거나 빠진 문서를 추가한다. 루프가 프롬프트 → 빌드 → 망각에서 프롬프트 → 참조 → 빌드 → 갱신으로 바뀌는 셈이다. 기억은 에이전트에 볼트로 붙이는 RAG 데이터베이스가 아니라, 읽고 고치고 팀과 공유할 수 있는 작업 공간이 된다.

저자는 1년 넘게 AI와 함께 프로그래밍하면서 이 문제를 인식했고, 처음에는 에이전트가 스펙과 계획, 인덱스를 적어두는 internal 폴더를 만들어 쓰다가 이를 정리해 Operator Memory라는 플러그인으로 만들었다고 밝혔다. 벡터 데이터베이스도, 임베딩도, 요약·정리·병합을 담당하는 백그라운드 데몬도, 블랙박스 검색도 없다. 모든 것이 사람이 읽고 수정하고 커밋하고 팀에 공유할 수 있는 평범한 마크다운 문서다.

실무적으로 이 제안이 던지는 질문은 명확하다. 에이전트의 컨텍스트를 과거 대화 스니펫에서 긁어오는 방식으로 설계하고 있다면, 그 스니펫이 프로젝트에 대한 이해로 이어지는지 스스로 점검해볼 필요가 있다. 문서를 에이전트가 갱신하는 대상으로 삼으면, 컨텍스트 품질이 검색 운에 좌우되지 않고 리뷰와 버전 관리의 대상이 된다.

다만 이 글은 저자의 개인 경험과 1년간의 사용을 근거로 한 주장이며, 메모리 플러그인과 문서 기반 방식을 정량적으로 비교한 벤치마크는 제시되지 않는다. 문서를 꾸준히 갱신하는 규율이 팀에 없으면 워크스페이스도 금세 낡는다는 전제가 깔려 있다는 점은 감안하고 읽을 만하다.