그래프 메모리 vs 마크다운: 확장 시 플랫 파일이 프롬프트 부채가 되는 이유

r/openclaw의 한 개발자는 AI 에이전트의 마크다운 기반 메모리 시스템이 처음에는 깔끔한 해결책이었지만 점차 '프롬프트 부채'로 변해간 과정을 이야기합니다. 처음에는 에이전트 메모리를 마크다운 파일로 저장하는 것이 읽기 쉽고, 편집 가능하며, 벤더 종속성이 없어 이상적으로 보였습니다. 하지만 파일이 80개 이상, 500만 자를 넘어서면서 접근 방식이 무너졌습니다. 매 실행마다 '거대한 노트 더미'를 스캔하여 어떤 부분이 여전히 유효한지 추측해야 했습니다.

문제: 플랫 텍스트가 프롬프트 부채가 되다

개발자가 설명하듯, '저장은 해결됐지만, 메모리는 해결되지 않았다.' 프로젝트 사실, 오래된 버그, 결정 사항, 선호도, 그리고 중간에 버려진 계획들이 모두 동일한 가중치로 컨텍스트에 포함되었습니다. 에이전트는 모든 것이 동등하게 관련된 것처럼 다시 읽어야 했고, 이는 성능 저하와 토큰 낭비로 이어졌습니다.

통찰: 모든 메모리가 아닌 관련 메모리만 렌더링하라

전환점은 더 나은 노트가 아니라, 에이전트가 '현재 작업에 관련된 메모리 부분만 렌더링'하도록 해야 한다는 깨달음에서 비롯되었습니다. 해결책은 그래프 메모리를 채택하는 것이었습니다. 각 메모리는 노드로, 관계는 엣지로 저장하고, 검색은 '지금 이 지도에서 어떤 부분이 켜져야 하는가?'라는 질문에 답하는 방식으로, 상위 10개의 유사 노트를 컨텍스트에 덤프하는 대신 사용했습니다.

실용적 교훈

마크다운은 여전히 좋은 아카이브/내보내기 형식이지만, 장기적인 에이전트 메모리는 규모가 커지면 순수 텍스트 형태로 유지될 수 없습니다. 그래프 기반 검색은 선택적 컨텍스트 주입을 제공하여 동일한 가중치의 청크 문제를 피합니다. 에이전트의 메모리가 수십 개의 파일을 넘어서고 있다면, 원시 텍스트 연결 대신 작업 관련 검색을 위해 구조화하는 것을 고려하세요.