에이전트에 필요한 건 메모리가 아니라 문서라는 주장, 메모리 플러그인은 전부 RAG라는 지적

Peter Naur가 Programming as Theory Building에서 말한 것처럼 문서만으로는 프로그램 뒤의 정신 모델을 다 담을 수 없음. 근데 AI는 작업 맥락을 훨씬 더 명시적으로 꺼내놔야 하니까 다른 방식이 있을 수도 있겠더라.

그럼 에이전트가 프로그램을 확장하도록 조종할 그 이론을 내 머릿속에 어떻게 유지하지? 주변에 물어봤는데 사람마다 방식이 다 다르더라.

집 안 인프라나 서비스, CI/CD, 호스트, 스토리지 같은 걸 메모리처럼 정리해두면 배포나 인수 테스트할 때 진짜 편함. 다만 데이터가 커지면 읽고 갱신하고 오래된 정보 유지하는 데 토큰이 순식간에 녹더라.

난 프롬프트랑 응답에서 의미 단위 문장을 다 뽑아 Whybase 명제 트리로 이유를 매핑하고, 툴 호출과 git 커밋으로 코드에 연결함. 에이전트가 그 파일을 건드리면 Claude Code 훅이 코드그래프 DB를 조회해서 6월에 한 말을 7월에 기억하게 해줌.

6월 대화가 7월엔 더 이상 유효하지 않으면? 뒤에 깔린 옛 명제를 버리는 장치가 있나? GitHub Copilot은 파일 해시가 바뀌면 메모리를 자동으로 버리는 방식이었는데, 좀 과하게 버리긴 해도 낡은 게 쌓이진 않더라.

코딩 에이전트용 메모리 솔루션이 왜 필요한지 모르겠음. 세션 히스토리가 다 있으니 recall 스킬 하나랑 JSON 파싱으로 grep하면 완벽한 기억인데, 왜 도구를 더 써서 토큰을 더 쓰면서 불완전한 기억을 따로 만드는 거지?

그건 한 세션 얘기고, 메모리는 다음 세션을 위한 거 아님?

그냥 최적화임. 매번 다 다시 읽게 하기 아까우니 노트에 적어두고 항상 읽는 거지. 푸아로 탐정처럼.

동의함. 근데 에이전트 전용 문서를 따로 두고 싶진 않더라. mattpocock/skills로 ADR을 만들고 CONTRIBUTING.md, CODING_STANDARDS.md, README, 아키텍처 문서, 커밋 메시지, GitHub 이슈에 쌓은 스펙까지 있으면 에이전트가 알아서 찾아 쓰고 최신으로 유지하더라.

난 문서, 테스트(TDD), 코드 루프로 돌림. IMPLEMENT-<계획>.md로 시작해서 TDD로 고치고 반복하는 식인데, qwen3.8-flash-next 나온 뒤로는 동적 컨텍스트 프루닝 덕에 로컬 코딩에서 거의 무한으로 감.

요즘은 기억 대신 원칙(principles)을 씀. 에이전트가 항상 생각해야 하는 패턴이고, 원칙에 버전을 붙여서 코드 주석에 인용하게 했음. 원칙이 바뀌면 코드도 같이 따라가더라. 두 달 써봤는데 아주 잘 맞았음.

난 에이전트가 호출하는 CLI 도구를 만들었음. 몇 가지 질문에 답하게 해서 상태를 파악하고 조종 명령을 주는 식인데, 원칙이나 기억보다 질문이 열려 있어서 에이전트가 국소 작업에 빠져 큰 그림을 놓칠 때 되돌려줌.

메모리는 큐레이션 안 된 불투명한 과거 논의라 도움이 될 수도 해가 될 수도 있는데, 정확한 문서는 이롭기만 함.

그 도구를 왜 설치해야 함? AGENTS.md 지침이나 훅으로 충분한데.

설치 안 해도 됨. '메모리에 저장했다'고 하면 제품 문서에 적어달라고 하고 앞으로도 그렇게 하라고 하면 됨. 물론 그 지침이 어딘가 남아야 하는데 그게 메모리인 거고.

자동차 매뉴얼 AI 데모를 본 적 있는데 매뉴얼을 모델에 학습시켜놨더라. 에디션마다 재학습해야 하고 결과도 불완전함. 모델은 문서를 가져다 쓰도록 훈련해야지 어렴풋이 기억하게 하면 안 됨. 26B를 numpy 함수 목록에 쓰느니 27B를 코딩에 쓰고 싶음.

몇 년째 그 얘기 했다니, 에이전트 시스템이랑 메모리는 1년 정도밖에 안 됐음. 메모리랑 LLM 파인튜닝을 헷갈리는 것 같은데 완전히 다른 개념임.

에이전트가 코드나 유닛 테스트만큼 마크다운 문서도 알아서 쓰던데 추가 도구가 왜 필요하지?

낡은 정보가 남아서 다음 에이전트를 헷갈리게 하니까.