AI 코딩 에이전트를 오래 쓰다 보면 반복되는 불편이 있다. 같은 프로젝트인데도 세션이 바뀌면 에이전트가 이전에 합의한 내용을 까먹고, 왜 그렇게 구현했는지 다시 설명해야 한다. 이 '망각' 문제를 풀겠다며 등장한 것이 이른바 메모리 플러그인이다. liao.gg에 올라온 'Agents don't need memory, they need documentation'이라는 글은 바로 이 메모리 제품군이 애초에 잘못된 문제를 풀고 있다고 주장한다. 필자는 자신이 만들어 1년 넘게 써 온 오픈소스 도구 Operator Memory를 근거로, 에이전트에게 정작 필요한 것은 과거 대화의 검색이 아니라 구조화된 프로젝트 문서라고 말한다.
메모리 플러그인은 무엇을 하고 있나
글이 묘사하는 전형적인 메모리 플러그인의 구조는 단순하다. 사용자의 대화를 분석해 수천 개의 짧은 스니펫으로 쪼갠 뒤 벡터 데이터베이스에 넣는다. 그리고 매 프롬프트마다 가장 유사한 다섯 개가량을 끼워 넣고, 그래도 에이전트가 헷갈리면 추가로 검색하게 한다. 이것이 '메모리'라는 이름으로 팔리는 제품의 실체라는 것이다. 어떤 도구는 과거 대화록을 단어 단위로 뒤지게 하고, 또 어떤 도구는 단기·장기 기억을 분류하거나, 백그라운드에서 기억을 병합·중복 제거하는 데몬, 밤새 기억을 다시 쓰는 '드리머', 지속적 컨텍스트 압축, 리랭커 따위를 덧붙인다.
필자의 비판은 이런 기능들이 하나같이 동일한 전제 위에 서 있다는 데 있다. '에이전트는 잊어버린다, 그러니 더 잘 기억하게 만들자'는 발상이다. 더 많이 포착하고, 더 잘 색인하고, 더 똑똑하게 검색하면 된다는 것이다. 하지만 필자는 사람이 지식을 다루는 방식은 그렇지 않다고 지적한다. 3년 전 회의 영상을 다시 돌려 보며 어떤 제약이 있었는지 떠올리는 사람은 없다. 사람은 중요한 것을 적어 두고, 그 기록을 다시 읽는다. 과거 수백만 토큰어치 대화를 검색해 조각조각 재구성하게 하는 것은 이 자연스러운 방식과 정반대라는 얘기다.
제안: RAG가 아니라 읽고 쓰는 작업 공간
대안으로 제시되는 모델은 의외로 익숙하다. 이미 많은 프로젝트가 에이전트가 코드베이스에 눈 감고 뛰어들지 않도록 AGENTS.md 파일을 둔다. 효과는 있지만, 문제는 그 한 장이 프로젝트 문서의 전부인 경우가 많다는 점이다. 필자는 파일 하나로는 부족하며, 에이전트에게는 지시사항·명세·결정 사항·조사 결과·인덱스를 스스로 기록할 수 있는 구조화된 '두뇌'가 필요하다고 본다. 코드 리뷰 절차를 적은 지시문, 사용자와 논의한 내용을 담은 스펙, 외부 라이브러리나 API를 조사해 재사용할 수 있게 정리한 문서 같은 것들이다.
이렇게 하면 에이전트의 작업 루프가 바뀐다. 기존의 '프롬프트 → 구축 → 망각'에서, '프롬프트 → 참조 → 구축 → 갱신'으로 전환된다. 작업 전에는 두뇌에서 관련 문서를 읽어 완전한 맥락을 확보하고, 작업 후에는 전체 그림이 아직 컨텍스트에 남아 있는 동안 낡은 문서를 고치고 필요한 문서를 추가한다. 기억이 에이전트에 억지로 덧붙인 RAG 데이터베이스가 아니라, 읽고 고치고 공유할 수 있는 작업 공간이 되는 셈이다.
필자는 이 아이디어가 처음부터 거창했던 것은 아니라고 밝힌다. AI로 프로그래밍을 시작한 1년여 전, 세션을 넘어 작업을 기억시키고 싶어서 internal/ 폴더를 만들고 에이전트에게 스펙·계획·인덱스를 전부 적게 했다. 작업 전에 해당 문서와 인덱스를 읽고 작업 후에 갱신하라는 투박한 규칙이 점차 정식 체계가 됐고, 결국 Operator Memory라는 플러그인이 됐다는 것이다. 이 도구는 벡터 DB도 임베딩도, 요약기나 큐레이터, 드리머 같은 백그라운드 데몬도 없이, 모든 것을 사람이 읽고 수정하고 커밋하고 팀과 공유할 수 있는 평범한 마크다운 문서로 관리한다고 소개한다.
한국 실무자에게 주는 함의와 한계
이 주장이 한국 개발 현장에 던지는 실질적 메시지는 분명하다. 사내에서 AI 에이전트 도입을 검토할 때, 값비싼 검색 인프라를 붙이기 전에 프로젝트 문서화 수준부터 점검해 볼 만하다. 특히 AI로 코드를 빠르게 찍어내면서 정작 한 줄도 읽지 않는 흐름 속에서 문서화가 뒷전으로 밀리기 쉬운데, 필자는 바로 지금이야말로 문서가 더 중요해졌다고 본다. 마크다운 기반이라 버전 관리 시스템에 함께 올리고 리뷰할 수 있다는 점도, 블랙박스 검색보다 팀 협업 관점에서 투명하다는 장점이 있다.
다만 이 글은 명확한 입장을 가진 주장이자 자사 도구 소개라는 점을 감안해 읽을 필요가 있다. 글은 메모리 플러그인이 겪는 '다섯 가지 문제'를 언급하면서도 본문에서 그 목록을 구체적으로 나열하지 않으며, Operator Memory의 우월성을 뒷받침하는 정량적 비교나 외부 검증 수치도 제시하지 않는다. 또한 문서 기반 접근은 에이전트가 성실하게 문서를 읽고 갱신한다는 전제에 의존한다. 문서가 방치돼 낡으면 오히려 잘못된 맥락을 주입할 위험이 있고, 대화 속 암묵적 결정을 누가 어떻게 명시적 문서로 남길지는 여전히 팀의 규율에 달린 문제다. 결국 핵심은 특정 제품이 아니라, '기억을 검색하게 할 것인가, 지식을 문서로 남기게 할 것인가'라는 설계 관점의 선택에 있다.