「AI 에이전트에게 어제의 실수를 오늘 기억하게 하려면 어떻게 해야 하는가」

에이전트를 실무에서 사용하기 시작한 사람이라면 한 번쯤 직면하게 되는 질문이다. 세션(Session)을 넘어가면 컨텍스트(Context)는 리셋되고, 같은 실수가 반복된다. DB에 수동으로 기록을 남겨도 에이전트가 자발적으로 참조하지 않는 경우도 많다.

Anthropic이 2026년 5월에 Public Beta로 공개한 Memory API는 이러한 세션 간 기억 문제에 대한 Anthropic의 공식적인 해답이다. Managed Agents 플랫폼 위에서 제공되며, 에이전트가 작업 경험을 파일 시스템형 Memory Store에 쓰고 읽는 메커니즘을 표준화한다.

본 기사에서는 Memory API의 핵심 컨셉을 정리하고, 왜 이러한 설계가 되었는지 파헤쳐 본다. 동시에 발표된 Dreaming (Research Preview)과의 관계도 해설한다.

Memory API는 Managed Agents 플랫폼의 기능으로서 제공된다. 먼저 Managed Agents의 위치를 정리해 두자.

Claude Code가 「옆에 앉아서 함께 작업하는 동료」라면, Managed Agents는 「의뢰서를 전달하고 다음 날 아침까지 완성해 달라고 맡기는 외주처」에 가깝다. 비동기 배치 처리(Batch Processing)를 위한 호스팅 환경이다.

Memory API는 이 Managed Agents 상의 에이전트가 「이전 세션에서 무엇을 배웠는가」를 다음 세션으로 이어가기 위한 영속 기억층(Persistent Memory Layer)으로 설계되어 있다.

Memory Store의 설계상 특징으로, Claude 스스로가 파일 시스템으로서 조작할 수 있는 형식으로 영속화한다는 점이 있다.

벡터 DB(Vector DB)와 같은 추상적인 스토어가 아니라, 디렉토리와 파일 구조로 기억을 유지한다. 이는 Claude의 강점에 맞춘 설계다. Claude는 Bash 조작, grep, 파일 구조화에 능숙하며, 「기억을 정리하는」 작업 자체를 Claude에게 맡기기 쉽다.

개발자 입장에서 보면, Memory Store는 다음과 같이 조작할 수 있다.

from anthropic import Anthropic
client = Anthropic()
# Memory Store에 엔트리(Entry)를 작성
...

여러 에이전트 세션이 병렬로 동작하는 경우, 동일한 파일에 대한 동시 쓰기가 충돌한다. DB의 행 잠금(Row Lock)에 해당하는 문제다.

Memory API는 **content_hash를 통한 낙관적 동시성 제어 (Optimistic Concurrency)**로 이를 해결한다.

# content_hash를 사용한 안전한 업데이트
entry = client.beta.memory.read(store_id=store_id, key=key)
current_hash = entry.content_hash # 현재 상태의 해시
...

쓰기 시점에 「읽은 시점의 hash」를 전달하고, 서버 측의 hash와 일치하지 않으면 MemoryConflictError가 반환된다. 「읽은 후 쓰기 전 사이에 다른 곳에서 업데이트한」 케이스를 감지할 수 있다. DB의 낙관적 잠금 (Optimistic Locking)과 동일한 원리다.

Memory Store에는 모든 기억이 혼재되어 있지만, 모든 것을 동등하게 취급하지는 않는다.

Permission Scope를 통해 「이 엔트리는 누가 읽고 쓸 수 있는가」를 정의할 수 있다.

# 읽기 전용 엔트리 작성 (사람이 리뷰한 Playbook 등)
client.beta.memory.write(
store_id=store_id,
...

전형적인 구분:

• ro: Playbook나 비즈니스 규칙 (사람이 리뷰하여 확정한 것)
• rw: 태스크 완료 후의 학습 로그, 에러 패턴, 환경 정보

Memory Store에 대한 쓰기는 모두 버전 이력(Version History)으로 유지된다. 「언제·누가·무엇을 썼는가」를 추적할 수 있다.

# 버전 이력 취득
history = client.beta.memory.list_versions(
store_id=store_id,
...

에이전트의 판단이 나중에 보았을 때 오류였다면, 「어느 타이밍에 무엇을 학습했는지」를 거슬러 올라가 확인할 수 있다.

동시기에 Research Preview로 발표된 Dreaming은 Memory API 위에 올라가는 자동화 레이어(automation layer)다.

일반적인 기억 쓰기가 '태스크 완료 후의 개별 세션' 관점인 것에 반해, Dreaming은 여러 세션의 작업 트랜스크립트(transcript)를 백그라운드에서 횡단 분석하여 공통 패턴을 자동으로 Memory Store에 기록하는 비동기 프로세스다.

세션 A: 태스크 완료 → transcript 저장
세션 B: 태스크 완료 → transcript 저장
세션 C: 태스크 완료 → transcript 저장
...

사람에 비유하자면, '업무 일지를 매일 쓰다 보면 주간 리뷰에서 무의식적인 패턴을 깨닫게 되는' 프로세스와 유사하다.

Rakuten의 사례에서는 Dreaming을 활용한 결과로 'first pass mistakes(초기 오류율)가 90% 감소했다'고 보고되었다.

Memory API가 진가를 발휘하는 것은 멀티 에이전트(multi-agent) 구성이다.

Session A (생성)
→ 태스크 완료 후, Memory Store에 결과물의 요점을 기록
→ Events API로 완료 통지
...

여러 에이전트가 동일한 도메인에서 병렬 태스크를 처리할 때, 서로의 학습 내용을 공유할 수 있다.

# 에이전트 A가 학습한 에러 패턴
client.beta.memory.write(
store_id=shared_store,
...

Agent SDK(자체 인프라에서 구동하는 라이브러리)에서도 외부 DB에 기억을 쓰는 것은 가능했다. Memory API가 해결하는 지점은 **'그 메커니즘을 매번 직접 구현할 필요가 없어진다'**는 점이다.

다만 현 시점에서는 Managed Agents 플랫폼 한정 기능이며, Claude API를 직접 사용하는 Agent SDK에서는 이용할 수 없다는 점에 주의가 필요하다.

Memory API의 본질: 에이전트의 세션 간 기억을 표준화한 파일 시스템형 영속 스토어(persistent store) -
content_hash: 병렬 에이전트의 쓰기 충돌을 낙관적 동시성 제어(Optimistic Concurrency)로 해결 -
Permission Scope: Playbook(ro)과 학습 로그(rw)를 분리함으로써 오버라이트(overwrite) 방지 -
Dreaming: 백그라운드에서 transcript를 횡단 분석하여 공통 패턴을 자동 기억화 -
Managed Agents 한정: 현 시점은 Managed Agents의 Public Beta 기능 (Agent SDK 직접 이용 불가)

AI 에이전트가 '매번 처음부터 다시 배우는' 것이 아니라, 경험을 축적하며 개선해 나가는——그를 위한 설계 기반으로서, Memory API는 에이전트 아키텍처의 표준적인 컴포넌트가 될 가능성이 있다.