에이전트 기억 논쟁, 검색보다 최신 문서가 먼저

‘기억이 아니라 문서’라는 문제 제기

Kevin Liao는 10월 3일 공개한 에이전트 메모리 비판 글에서 대화 기록을 작은 조각으로 저장하고 유사한 항목을 다시 넣는 방식만으로는 프로젝트 이해가 충분하지 않다고 주장했다. 과거에 옳았던 내용이 지금도 옳은지, 어떤 결정이 다른 결정을 대체했는지 알기 어렵다는 것이다.

그가 제안하는 대안은 작업 전에 관련 문서를 읽고, 구현 뒤 바뀐 사실을 같은 문서에 갱신하는 방식이다. 글은 자신의 오픈소스 프로젝트인 Operator Memory로 이어진다. 따라서 이 주장은 제품 개발자의 경험과 설계 관점으로 읽어야 한다. 모든 메모리 제품의 성능을 비교한 독립 실험 결과는 아니다.

유사한 기록과 현재의 사실은 다르다

예를 들어 인증 방식을 바꾸는 프로젝트에는 폐기된 초안, 임시 우회책, 확정된 구현이 모두 대화 기록에 남을 수 있다. 질문과 가장 비슷한 조각이 반드시 최종 결정인 것은 아니다. 검색 정확도가 높더라도 유효 기간이나 우선순위를 모르면 에이전트가 오래된 제약을 다시 적용할 수 있다.

문서 중심 접근은 이 문제를 최신 기준 문서의 갱신으로 풀려 한다. 무엇을 바꾸었는지뿐 아니라 왜 바꾸었는지, 관련 코드와 테스트가 무엇인지 함께 남긴다. 다음 작업은 과거 대화 전체를 재구성하는 대신 현재 상태를 설명하는 문서에서 시작한다. AGENTS.md 공식 사이트가 설명하는 에이전트용 작업 안내와 연결되지만, 모든 프로젝트 지식을 한 파일에 넣자는 제안은 아니다.

아키텍처 결정 기록인 ADR은 결정의 맥락과 결과를 남기는 기존 방법이다. 문서 기반 메모리의 새로움은 Markdown 자체보다, 에이전트의 일상 작업 흐름에 참조와 갱신을 붙인 데 있다. 다만 에이전트가 잘못 이해한 사실을 문서에 고정하면 다음 세션에도 오류가 전파될 수 있다.

Operator가 공개한 세 가지 저장 영역

README는 개인 프로젝트 지식인 .operator/, 저장소와 공유하는 .operator-shared/, 여러 프로젝트에서 쓰는 사용자 지식인 ~/.operator/user/를 구분한다. 기본 루프는 Consult, Build, Update다. 벡터 데이터베이스나 별도 백그라운드 에이전트를 요구하지 않는다고 설명하지만, 읽고 쓰는 모델의 토큰 비용까지 0이라는 뜻은 아니다.

아래 표는 문서와 검색이 맡기 좋은 역할을 정리한 분석이다. 두 접근 중 하나가 언제나 우월하다는 성능 표가 아니다.

프로젝트는 여러 코딩 에이전트용 어댑터를 제공한다고 문서화한다. 그러나 지원 목록에 이름이 있다는 것과 모든 환경에서 같은 자동 갱신 신뢰도를 보장한다는 것은 다르다. README의 로드맵에도 긴 대화 중 문서를 안정적으로 최신 상태에 유지하는 과제가 남아 있다. 현재 기능과 향후 계획을 분리해 읽어야 한다.

메모리 시장의 경쟁은 회상량에서 유지관리로

RAG는 큰 자료에서 관련 근거를 찾아오는 데 유용하다. 따라서 원문의 강한 제목을 ‘검색은 쓸모없다’로 확대할 필요는 없다. 핵심은 검색 결과에 현재성, 출처, 권한 정보를 붙이고 중요한 결정에는 검토 가능한 기준점을 두는 것이다. 문서를 검색 색인의 원본으로 삼는 혼합 방식도 가능하다.

AGENTS.md 지원 표준화 분석은 도구가 바뀌어도 지침을 재사용하는 문제를 다뤘다. Gemini의 skills 전환 분석 역시 지식을 재사용 가능한 작업 규칙으로 묶는 흐름이다. 경쟁력은 기억을 많이 쌓는 기능보다 잘못된 지식을 누가 찾아 고칠 수 있느냐에서 나올 수 있다.

협업에서는 더욱 그렇다. Aweb의 세션 밖 메시지 분석이 다룬 전달 가능성만으로 팀의 지식이 정합해지지는 않는다. 서로 다른 에이전트가 같은 문서를 동시에 바꾸거나 개인적 추정을 팀의 확정 지침으로 올릴 때의 충돌 해결이 별도로 필요하다.

한국 개발팀은 무엇부터 바꾸면 좋을까

처음부터 모든 대화를 문서화할 필요는 없다. 프로젝트 개요, 작업 규칙, 핵심 결정, 진행 중인 변경사항을 구분하고 소유자를 정하는 것부터 시작할 수 있다. 각 문서에는 확인일과 관련 코드 위치를 남기고, 기능 수정 PR에서 해당 문서가 함께 바뀌어야 하는지 검토하자. 이는 제품의 의무 규정이 아니라 운영 제안이다.

개인 영역과 공유 영역의 경계도 중요하다. 고객 정보, 내부 토큰, 사적인 대화가 편의상 문서에 들어가 Git으로 공유되지 않도록 해야 한다. 에이전트의 관찰은 사용자의 명시적 지시와 구분하고, 외부 자료에서 읽은 문장을 작업 권한으로 승격시키지 않는 것이 좋다. 문서는 읽기 쉬워졌다는 이유만으로 자동으로 신뢰할 수 있는 지시가 되지 않는다.

효과는 재질문 횟수, 잘못된 옛 결정의 재사용, 문서 갱신에 드는 시간으로 측정할 수 있다. 문서가 늘었는데 새 작업의 이해 시간이 줄지 않는다면 색인과 분할 방식을 조정해야 한다. 좋은 메모리의 기준은 보관량이 아니라 다음 작업에서 줄어든 오해다.

FAQ

모든 RAG 시스템을 없애야 하나?

아니다. 원문은 문서 중심 접근을 옹호하는 개발자의 주장이다. 대규모 근거 탐색과 현재 기준 문서의 유지관리는 함께 사용할 수 있다.

AGENTS.md 하나면 충분하지 않나?

작은 프로젝트에서는 시작점이 될 수 있다. 복잡한 설계와 연구 내용을 모두 넣으면 길어지므로 역할별 문서와 연결하는 편이 낫다.

별도 벡터 DB가 없으면 비용도 없나?

아니다. 문서 작성·참조·수정에는 모델 사용량과 검토 시간이 든다. 인프라 의존성이 줄어드는 것과 총비용이 사라지는 것은 다르다.

에이전트가 문서를 자동 수정해도 되나?

권한이 부여된 범위에서는 가능하지만 중요한 팀 규칙은 변경 이력과 검토를 남기는 편이 좋다. 자동 갱신도 오해를 기록할 수 있다.

성능 우위가 입증됐나?

이번에 확인한 자료는 작성자의 경험과 프로젝트 설명이다. 자사 저장소에서 같은 작업의 반복 오류와 컨텍스트 준비 시간을 비교해야 한다.