최근 개발자 커뮤니티에서 AI 에이전트의 메모리 관리 체계에 대한 논쟁이 뜨겁습니다. 중심에는 로레킷(LoreKit)을 개발한 Mads Thines의 주장이 있습니다. 그는 현재 다양한 AI 코딩 도구가 각기 다른 형식으로 메모리를 저장하고 있어, 한 도구에서 학습한 정보가 다른 도구로 전달되지 못하는 단절 현상을 지적했습니다.
Thines는 AGENTS.md 파일, Anthropic의 /memories 디렉토리, Copilot의 저장소 기반 사실 데이터, 그리고 MCP JSONL 지식 그래프 등 네 가지 주요 형식을 예로 들었습니다. 이들은 서로 읽을 수 없는 구조를 가지고 있어, CI 에이전트가 남긴 노트를 에디터 에이전트가 참조할 수 없는 상황이 발생합니다. 그는 이러한 파편화를 해결하기 위해 2019년 OpenTracing과 OpenCensus가 OpenTelemetry로 통합되었던 사례처럼 하나의 공통 데이터 모델과 프로토콜이 필요하다고 제안했습니다.
그가 제시한 개념적 레코드에는 주소, 키, 신원, 생명주기, 그리고 작성 주체를 기록하는 written_by 필드가 포함됩니다. 이는 사람이 썼는지, 모델이 생성했는지, 혹은 추출 서비스가 처리했는지를 명확히 구분하기 위한 장치입니다. 이미 Portable Memory나 Open Memory Protocol 같은 기존 제안들이 벤더 간 메모리 내보내기 문제를 다루고 있지만, 동일한 리포지토리 내에서 여러 도구가 작동할 때의 실시간 주소 지정 문제는 여전히 미해결 상태입니다.
하지만 Hacker News를 비롯한 커뮤니티 반응은 즉각적인 표준화에 회의적입니다. 많은 참여자들은 현재 컨텍스트와 메모리의 지속 기간, 접근 방식에 대한 이해 자체가 충분히 깊지 않다고 평가했습니다. premature한 추상화 표준화는 과거 SOAP이나 SGML처럼 실패한 사례를 반복할 수 있다는 우려가 제기되었습니다.
또 다른 비판 지점은 기술적 효용성입니다. 일부 개발자는 트랜스포머 모델이 비공식적인 영어 텍스트에서도 핵심 정보를 추출할 수 있는 능력이 뛰어나, 복잡한 메모리 구조가 필수적이지 않을 수 있다고 주장합니다. 그들은 현재의 메모리 솔루션들이 사실상 ‘다른 폴더’일 뿐이며, 성능 차이가 미미할 것이라고 추정했습니다.
오히려 과도한 구조화가 실험을 방해할 수 있다는 점도 지적되었습니다.
Thines 본인도 자신의 블로그 글이 AI의 도움을 많이 받아 작성되었음을 인정하며, 이것이 신뢰도에 영향을 줄 수 있음을 시사했습니다. 그는 로레킷이 완벽한 해답이 아니라 여러 제안 중 하나임을 강조했습니다. 문제는 도구의 부재가 아니라 합의의 부재라는 그의 진단은 유효하지만, 그 합의를 이룰 시점이 도래했는지는 여전히 논쟁거리입니다.
현재로서는 각 도구가 자체적인 스키마와 저장 방식을 유지하며 경쟁하는 구도가 계속될 전망입니다. 커뮤니티의 피드백은 표준화를 서두르기보다, 메모리가 실제로 얼마나 유용한지, 그리고 어떤 수명주기를 가져야 하는지에 대한 기초 연구가 선행되어야 함을 보여줍니다. 구체적인 통합 규격의 등장 여부는 향후 몇 년간의 실험 결과에 달려 있을 것입니다.