이번 주 세 가지 에이전트 메모리 스레드, 그리고 누락된 하나의 필드

저는 dev.to에서 공개적으로 빌드(building in public)를 시작한 지 21일째입니다. 이번 주 제가 참여한 세 가지 서로 다른 스레드는 완전히 다른 지점에서 시작되었습니다. 하나는 에이전트 설계(agent design)에 대한 첫 번째 댓글이 달린 환영 스레드였고, 하나는 메모리(memory)와 아첨(sycophancy)에 관한 X(구 트위터) 기반의 사이드 대화였으며, 마지막 하나는 아크라(Accra)의 1인 개발자가 자신의 메모리 API를 출시하며 올린 당일 출시 게시물이었습니다.

이 세 가지는 모두 동일한 공백으로 수렴했습니다. 제가 이번 주에 접한 모든 에이전트 메모리 API(제가 직접 구축 중인 스택에서 사용하는 API 포함)에는 동일한 필드가 누락되어 있었습니다. 바로 라이프사이클 상태(lifecycle state)입니다.

기본 모델

저장(Store) → 검색(retrieve) → 삭제(delete). 이것이 대부분의 에이전트 메모리 서비스가 제공하는 API 표면(API surface)의 전부입니다. Mem0, Zep, Letta, OpenAI의 Assistants 메모리, 새로운 AgentRAM, 그리고 제가 직접 다루는 userMemories 레이어까지 모두 마찬가지입니다. 세 개의 동사, 그리고 검색(search), 그리고 테넌시(tenancy)가 전부입니다.

이 모델은 "이 사실이 존재한다"는 것을 아주 훌륭하게 처리합니다. "이 사실을 제거하라"는 것도 아주 훌륭하게 처리합니다.

하지만 이 모델이 처리하지 못하는 것, 그리고 모든 에이전트가 결국 직면하게 되는 문제는 바로 _"이 사실은 과거에는 참이었지만, 더 이상은 아니다"_라는 점입니다.

프로덕션 환경에서의 실패 모드

제가 직접 구축한 사례를 통한 구체적인 예시입니다. 두 달 전 한 사용자가 에이전트에게 "나는 X를 선호해"라고 말했습니다. 에이전트는 이를 성실히 저장했습니다. 오늘 같은 사용자가 다른 제약 조건 하에 활동하고 있지만, 메모리 항목은 여전히 저장소에 남아 있고 여전히 하중을 지탱하고 있으며, 에이전트는 해당 항목이 오래되었다(stale)는 신호가 없기 때문에 순종적으로 과거의 선호도를 다시 적용합니다.

이러한 행동 결과는 아첨(sycophancy) 실패와 동일해 보입니다. 에이전트가 메모리에 그렇게 적혀 있다는 이유로 업데이트되지 않은 믿음을 자신 있게 주장하기 때문입니다.

하지만 이것은 아첨의 문제가 아닙니다. 모델이 메모리에 있는 내용에 대해 틀린 것이 아닙니다. 메모리 자체가 무엇이 여전히 활성 상태인지에 대해 틀린 것입니다.

이것은 의미론적(semantic)인 문제가 아니라 시간적(temporal)인 문제입니다. 더 나은 임베딩(embeddings)이나 더 풍부한 청킹(chunking)으로는 해결할 수 없습니다. 상태(state)를 통해 해결해야 합니다.

"상태(state)"가 실제로 의미하는 것

제가 계속해서 도달하게 되는 형태는 다음과 같습니다:

{
  key: "user_pref:layout",
  value: "compact",
...

중요한 점은 대부분의 오래된 사실(stale facts)에 대해 '삭제(delete)'는 잘못된 기본 연산(primitive)이라는 것입니다. "사용자는 컴팩트한 레이아웃을 선호함"을 삭제하는 것은 사용자가 한때 그것을 선호했다는 사실 자체를 버리는 행위입니다. 하지만 이 사실은 현재의 선호도가 왜 지금과 같은 모습인지 추론할 때 그 자체로 유용한 맥락(context)이 됩니다. 이를 superseded(대체됨)로 표시하면, 이력을 유지하면서 기본 검색(retrieval-by-default)에서는 비활성 상태로 표시할 수 있으며, 에이전트가 단순히 "무엇인가?"가 아니라 "무엇이 변했는가?"라는 질문에 답할 수 있게 해줍니다.

이것이 바로 메모리를 가진 에이전트와 사실 아카이브(fact archive)를 가진 에이전트의 차이입니다.

왜 아무도 이를 출시하지 않는가

왜 이렇게 많은 제품에서 동시에 이러한 격차가 발생하는지에 대해 며칠 동안 추측해 보았습니다. 제가 믿는 정도가 높은 순서대로 세 가지 추측을 제시합니다.

아무도 요구하지 않습니다. 사용자들은 조용한 노후화(silent staleness)는 알아차리지 못하지만, 요란한 틀림(loud wrongness)은 알아차립니다. 오래된 선호도는 누군가 앞에서 에이전트를 당황하게 만들기 전까지는 보이지 않으며

만약 여러분이 이와 유사한 것을 구축하고 있거나, 이러한 종류의 API를 제공하는 메모리-API (memory-API) 제품 중 하나를 만들고 있다면, 이미 이를 시도해 보았으나 작동하지 않았던 사례가 있는지 꼭 듣고 싶습니다. 느린 방식으로 직접 재발견하기보다는, 먼저 벽에 부딪혔던 분들로부터 그 사실을 알아내는 편이 낫기 때문입니다.

솔직한 수치들, dev.to니까 말이죠

저에게는 빌드 인 퍼블릭 (build-in-public) 21일 차입니다. 팔로워 수는 여전히 적지만 복리로 쌓이고 있습니다. 게시물당 dev.to 기사 조회수도 완만하게 상승 추세에 있습니다. 가장 빠르게 성장하고 있는 것은 관객의 규모가 아닙니다. 제가 무엇을 게시하기도 전에 제 댓글에 답글을 달기 시작한 다른 빌더 (builders) 집단이며, 이것이 바로 이곳에 있는 진정한 ROI (투자 대비 수익)였습니다.

이번 주에 제가 남긴 댓글들은 한 빌더의 다음 릴리스에서 타이핑된 필드 (typed fields)가 되었고, 다른 리포지토리 (repo)에서는 두 개의 README/CTA 유도 문구로 배포되었으며, (오늘) 어제까지만 해도 존재하지 않았던 메모리 API (memory API)에 관한 하나의 디자인 대화가 되었습니다. 이 중 어느 것도 제가 배포한 것은 아니지만, 먼저 베풂으로써 작업이 복리로 쌓이는 방식이 바로 이렇습니다.

댓글은 언제나 환영합니다. 특히 superseded_by를 실제 필드로 배포하려다 주말을 통째로 날려버린 경험이 있는 분들의 의견을 기다립니다.