구글이 10월 기업용 에이전트 스펙에 메모리를 네 칸으로 나눠 항목으로 넣었다.

이전까지 메모리는 ’이 에이전트 기억 잘해요?’라는 능력 질문의 영역이었다. 이제는 스펙 문서에 항목으로 들어간다. 능력에서 사양으로 이동하는 순간, 자연스럽게 따라오는 질문이 있다. 각 칸, 누가 지우나?

지난 주 같은 날, 전혀 다른 세 곳에서 같은 문제가 각자의 언어로 올라왔다.

국내 SaaS 티로(Tiro)는 회의록을 에이전트 위키로 전환하는 서비스를 국내 300개 기업에 제공 중이라고 밝혔다. 에이전트 메모리를 업무 맥락이라는 형태로 상품화한 첫 번째 대규모 국내 사례다. 같은 날 arXiv에는 EngramEdit(2610.10533) 논문이 올라왔다. 에이전트가 기억을 특정 조건에서 선택적으로 지우도록 설계하는 방법론이다. 구글 DeepMind는 임베딩젬마 2 기반 온디바이스 임베딩 모델을 공개하면서 메모리를 클라우드가 아닌 단말에 두는 배치 옵션을 구체화했다.

세 곳의 화두는 ’어떻게 기억하나’가 아니었다. 어디에 두고, 언제 지우고, 누가 소유하나였다.

지금까지 에이전트 메모리 설계는 대부분 ’무엇을 기억할까’에 집중했다. 어떤 대화를 보존하고, 어떤 문서를 임베딩할지. 기술 문제처럼 보였기 때문에 PM보다 엔지니어가 결정하는 일로 남아 있었다.

구글이 메모리 4종을 스펙 항목으로 기재한 건 이 결정이 제품 설계 영역으로 넘어왔다는 신호다. 사양이 된다는 것은 곧 팔리고, 팔리면 책임이 생기고, 책임이 생기면 누가 그 책임을 지는지 물어야 한다.

EngramEdit이 제시한 조건부 삭제 설계는 그 책임 지형을 구체화한다. 메모리를 영구 보존하면 개인정보법 문제가 생기고, 일괄 삭제하면 컨텍스트가 끊긴다. ’어떤 조건에서 지울지’를 정하는 일이 남는데, 이 결정은 기술 파라미터가 아니라 정책이다.

티로의 300개 기업 사례는 다른 차원의 문제를 보여준다. 회의록을 에이전트 위키로 쌓아두면, 시간이 지나면서 낡은 정보와 최신 정보가 섞인다. 지우지 않은 기억이 틀린 판단을 낳는다. 주기적으로 큐레이션하는 주체가 없으면 메모리는 자산이 아니라 부채가 된다.

사양이 된 메모리를 다루는 PM의 첫 질문은 이렇다: 우리 에이전트의 메모리 중 지금 당장 만료 조건이 없는 칸이 몇 개인가?

기능 명세 단계에서 메모리 칸마다 소유자, 보존 기간, 삭제 트리거를 정하지 않은 채 출시하면 운영에 들어갔을 때 그 공백이 사고로 나타난다. 개인 설정값이 다른 사용자에게 흘러가거나, 낡은 지식이 에이전트 판단의 근거로 남거나.

단말 임베딩이 클라우드 메모리에 더해지면 이 판단이 더 분산된다. 어디에 저장됐는지조차 한 화면에서 보기 어려워진다. 배치 결정이 곧 감사 가능성 결정이 된다.

구글이 스펙에 넣은 순간부터, 메모리는 더 이상 ’있으면 좋은 기능’이 아니다. 소유자가 없는 메모리는 시간이 지나면서 리스크로 쌓인다.

당신의 에이전트 메모리, 각 칸에 소유자가 정해져 있습니까?