leejk/ jk lee
Landscapes

Landscape · 2026.06

Agent Memory: 레이어로 붙일 것인가, 네이티브로 박을 것인가

5월에 굳은 카테고리가 6주 만에 1차 성숙도 점검을 받는다 — 5월의 세 예측을 6월 증거로 검산하고, 「소재(Locus)」라는 다섯째 축을 연다

·
#agent-memory#agent-framework#native-memory#memory-validity#landscape

5월에 에이전트 메모리는 카테고리로 굳었고, 그때 「어디서 깨질 것인가」로 세 예측을 미래형으로 던졌다 — ①단일 정본 충돌 ②신뢰도 가중의 환경 의존 ③프라이버시·규제 표면. 6주 뒤, 셋 다 데이터포인트를 받았다. 같은 스코프에 새 정본 후보가 둘 더 들어왔고(Recall·cognee), Retrieval 축은 정적 분류에서 진화형(EvoEmbedding)으로 움직였으며, 무엇보다 「Are We Ready For An Agent-Native Memory System?」 서베이와 「Critique of Agent Model」이 질문 자체를 한 단계 올렸다 — 메모리를 외부에 붙일 것인가, 모델·하네스의 네이티브 프리미티브로 박을 것인가. 4축(Capture·Storage·Retrieval·Lifecycle)이 못 잡던 다섯째 축, 소재(Locus)가 열린다.

TL;DR. 5월에 메모리는 카테고리로 굳었고, 그 글은 「어디서 깨질 것인가」로 세 예측을 미래형으로 던지고 끝났다. 6주 뒤, 셋 다 증거가 왔다 — 그리고 질문이 한 단계 올라갔다. 같은 스코프에 새 정본 후보가 둘 더 진입하고(Recall · cognee), Retrieval 축은 정적 분류에서 진화형(EvoEmbedding)으로 움직였다. 결정타는 「Are We Ready For An Agent-Native Memory System?」 서베이와 「Critique of Agent Model」 — 5월의 4축이 전부 "외부에 어떻게 붙이나" 를 전제했는데, 이 둘은 그 전제를 깬다. 단정 하나 — 다음 분기는 메모리를 잘 붙이는 경쟁이 아니라, 붙일지 박을지를 가르는 「소재(Locus)」 축에서 갈린다.

5월에 어디서 출발했나

5월의 글은 한 가지를 단정했다: 컨텍스트 윈도우 바깥에 무엇을 어떻게 누적할 것인가가 한 주 사이에 카테고리로 굳었다. 메타프레임 4종(Superpowers · GSD · gstack · ECC) + Anthropic Memory tool — 다섯 메커니즘이 Capture · Storage · Retrieval · Lifecycle 네 축에 서로 다른 답을 박았고, 같은 주에 평가 벤치 3종이 등장하며 측정 가능한 도메인이 됐다.

그리고 그 글은 「어디서 깨질 것인가」에서 세 가지를 미래형으로 던지고 닫혔다:

  1. 단일 정본 결정 — 같은 정보가 ECC·gstack·Anthropic에 동시 누적되면 어느 게 정본인가.
  2. 신뢰도 가중의 단일 환경 의존 — 자동 신뢰도 점수는 내 환경의 반복에 묶여 있어, 공유하는 순간 의미를 잃는다.
  3. 개인정보·규제 표면 — 영속 메모리는 거버넌스 질문이 된다.

예측은 반증 가능할 때만 값을 가진다. 6주가 지났으니, 이제 검산할 차례다.

6주 사이 무엇이 도착했는가

5월 이후 메모리 축으로 들어온 1차 신호는 여섯이다. 둘은 도구, 둘은 서베이/비판, 둘은 메커니즘 페이퍼다.

  • 2026-06-22 — raiyanyahya/recall ("Local project memory for Claude Code"). Claude Code에 프로젝트 스코프 로컬 메모리를 붙이는 standalone 도구. Anthropic Memory tool이 이미 platform-level로 깔린 바로 그 스코프에 또 하나가 들어왔다.
  • 2026-06-22 — topoteretes/cognee (GitHub 트렌딩). 에이전트용 메모리 layer. 5월의 agentmemory·hermes-agent에 이어, 메타프레임이 아닌 독립 메모리 layer가 트렌딩에 다시 진입 — 한 번이 아니라 패턴이라는 신호.
  • 2026-06-23 — EvoEmbedding: Evolvable Representations for Long-Context Retrieval and Agentic Memory. 임베딩 표현 자체가 진화하는 검색. 5월 Retrieval 축이 "자동 주입 vs 명시 호출"의 정적 분류였다면, 여기선 표현이 시간에 따라 갱신된다.
  • 2026-06-23 — OpenRath: Session-Centered Runtime State for Agent Systems. 세션 중심 런타임 상태 — Lifecycle 축의 세션 단위를 명시적 1급 객체로 끌어올린 디자인.
  • 2026-06-25 — Are We Ready For An Agent-Native Memory System?. 카테고리가 굳은 다음에 나오는 글의 전형 — 성숙도 점검 서베이. 제목의 무게 중심은 native다.
  • 2026-06-25 — Critique of Agent Model + MemGUI-Agent ("능동적 컨텍스트 관리로 롱호라이즌 GUI 수행"). 앞은 "에이전트란 무엇인가"를 비판적으로 되묻고, 뒤는 메모리를 외부 저장이 아니라 실행 중 능동 관리로 가져간다.

여섯 신호가 두 방향으로 갈린다. 넷(Recall · cognee · EvoEmbedding · OpenRath)은 5월의 4축을 더 밀어붙이는 신호 — 같은 게임을 더 잘하려는 시도. 둘(Agent-Native 서베이 · Critique)은 게임의 규칙을 의심하는 신호다.

5월의 세 예측, 6월 증거로 검산

5월 예측 6월 증거 판정
①단일 정본 충돌 Recall·cognee같은 스코프(프로젝트·로컬) 에 새 정본 후보로 진입. Anthropic Memory tool이 이미 깔린 자리에 둘 더. 악화 확인. 해소가 아니라 파편화 가속.
②신뢰도 가중의 환경 의존 6월 직접 신호는 약함. 대신 메모리 부패 연구가 같은 병을 더 깊은 층에서 진단 — 문제는 신뢰도 읽기가 아니라 쓰기 게이트다. 부분 확인 + 심화. 예측보다 한 층 아래.
③프라이버시·규제 표면 MemGUI-Agent엣지·온디바이스 GUI 에이전트로 메모리가 사용자 화면·이력까지 내려옴. 표면이 좁아지긴커녕 넓어졌다. 확인. Agent Governance와 정면.

①에서 구조연역 하나가 떨어진다. 왜 standalone 메모리 layer가 계속 늘어나는가 — 어느 메커니즘도 남의 본체를 정본으로 인정하도록 설계되지 않았기 때문이다. ECC instinct는 자기가 본체라 가정하고, Anthropic Memory tool도, Recall도 그렇다. 정본을 양보하는 디자인이 없으니, 새 도구는 통합되는 대신 추가된다. 5월에 "충돌"이라 부른 건 사실 구조적 중복 생성기였다.

다섯째 축 — 소재(Locus)

5월 4축에는 공통의 숨은 전제가 있었다. Capture·Storage·Retrieval·Lifecycle은 전부 "외부 레이어를 어떻게 붙이나" 의 하위 질문이다 — 메모리가 컨텍스트 바깥에 있다는 걸 이미 가정한다.

Agent-Native 서베이Critique of Agent Model이 깨는 게 정확히 이 전제다. 메모리가 붙이는 레이어냐, 모델·하네스의 네이티브 프리미티브냐. MemGUI-Agent의 "실행 중 능동 관리"와 EvoEmbedding의 "진화하는 표현"은 둘 다 바깥 저장소가 아니라 추론 루프 안으로 메모리를 끌어들인다. 4축으로는 이 차이가 안 잡힌다 — 그래서 다섯째 축이 필요하다.

갈림
Capture 발화 · 패턴 · 스킬 · 세션 요약
Storage 컨텍스트 · markdown · DB · 임베딩 · 파일
Retrieval 자동 주입 · 명시 호출 · RAG · MCP search · 진화형 표현 ← 6월 갱신
Lifecycle 세션 · phase · 프로젝트 · 사용자 · 영구
Locus (소재) ← 신설 bolt-on layer(외부 저장, 명시 경계) ↔ native primitive(추론 루프 내, 능동 관리)

5월의 다섯 메커니즘은 전부 bolt-on 쪽에 모여 있었다. 6월 신호의 절반은 native 쪽으로 무게를 옮긴다. 소재 축은 다른 네 축과 직교하지 않는다 — native로 가는 순간 Capture·Retrieval·Lifecycle의 답이 통째로 바뀐다. 그래서 이건 다섯째 칸이 아니라 판을 다시 까는 축이다.

쓰기 경로에서 만나는 자리

Agent-Native 서베이가 native 메모리에서 가장 어렵다고 짚는 지점은 읽기가 아니라 통합·갱신 — 새 경험을 기존 기억에 어떻게 병합하는가다. 이건 이 블로그가 메모리 부패에서 1차 출처로 직접 파본 결론과 같은 자리에서 만난다: 부패는 retrieval이 아니라 consolidation·update에서 들어온다. 계속 갱신하면 좋은 기억도 no-memory 밑으로 떨어진다.

함의는 단순하다. 메모리를 native로 박을수록, 쓰기 게이트가 없으면 부패도 native가 된다. bolt-on 레이어는 최소한 끄거나 갈아끼울 수 있지만, 추론 루프에 박힌 메모리는 그 부패가 모델의 행동과 분리되지 않는다. native 전환은 능력 향상인 동시에 부패 표면의 내재화다.

어디서 깨질 것인가 — 6월판 예측

5월 예측이 6주 만에 검산됐으니, 다음 분기 화두를 갱신해 둔다.

  1. 정본 양보 프로토콜의 부재. 정본 충돌은 해소되지 않고 누적된다(①에서 확인). 깨짐을 막으려면 메커니즘이 "나는 본체가 아니다" 를 선언할 수 있어야 하는데, 그런 디자인은 아직 없다. MCP 메모리 표준이 이 자리를 노릴 후보.
  2. native 메모리의 쓰기 게이트. 소재가 native로 갈수록 쓰기 부패가 행동에 직결된다. consolidation을 언제 거부하는가가 다음 6개월의 핵심 안전 질문.
  3. 온디바이스 메모리의 거버넌스. 메모리가 엣지·GUI로 내려오며(③) 프라이버시 표면이 사용자 기기 안으로 들어왔다. Agent Governance의 감사 모델이 클라우드 가정 위에 서 있다면, 여기서 한 번 깨진다.

관련 글

참고

하위 문서