오랫동안 작동시킨 에이전트의 memory (메모리)

파일을 열어보고 질린 적은 없는가. 같은 지견이 표현만 바뀐 채 세 번이나 적혀 있다. 지난주의 전제와 이번 주의 전제가 모순된 채 나열되어 있다. 이미 사라진 API의 주의사항이 남아 있다. 에이전트는 '깨달은 것을 메모하는 것'은 잘하지만, '쌓인 메모를 정리하는 것'은 아무도 해주지 않는다.

Anthropic이 5월 6일 Code with Claude에서 발표하고, 이후 API 문서가 공개된 Dreams(dreaming)는 바로 이 '메모의 부패'를 상대하는 기능이다. 일본어로는 아직 거의 해설되지 않았지만, 에이전트의 장기 기억을 어떻게 다룰 것인가라는, 수수하지만 본질적인 문제에 대한 하나의 설계 해답이 되고 있다.

전제를 하나 덧붙여 두겠다. Claude의 Managed Agents에서는 에이전트가 작업 중에 배운 것을 memory store (메모리 스토어)라는 영구 스토어에 기록한다. 세션을 넘나들며 "이 리포지토리의 테스트는 pytest로 실행한다", "이 사용자는 탭보다 스페이스를 선호한다"와 같은 지식을 가져가기 위한 메커니즘이다.

문제는 이 기록이 로컬이며 추가적(incremental)이라는 점에 있다. 에이전트는 작업 흐름 속에서 그때마다 메모를 더해갈 뿐이므로, 세션을 거듭할수록 스토어에는 중복, 모순, 진부화된 엔트리가 쌓인다. 공식 문서도 이 열화를 명확히 인정하고 있다.

over many sessions a memory store accumulates duplicates, contradictions, and stale entries.

(많은 세션을 거치는 동안, memory store에는 중복, 모순, 오래된 엔트리가 축적된다)

로그를 끊임없이 추가해 온 파일이 결국 읽을 수 없게 되는 것과 마찬가지로, 추가 전용(append-only)의 기억은 방치하면 신호가 노이즈에 묻히게 된다.

Dreams는 이렇게 쌓인 스토어를 비동기 배치 작업(batch job)으로 다시 만든다. 입력은 두 종류다. 정리 대상이 되는 기존의 memory store 하나와, 거기서 새로운 지견을 발굴하기 위한 과거의 session (대화 기록) 1~100건이다. 이것들을 읽어 들여 중복을 병합하고, 모순되거나 진부화된 엔트리를 최신 값으로 교체하며, 세션에서 발견한 새로운 패턴을 반영한 새로운 memory store를 출력한다.

설계에서 가장 효과적인 점은 입력 스토어를 전혀 수정하지 않는다는 점이다. Dreams는 별도의 출력 스토어를 생성할 뿐, 원래의 스토어에는 손을 대지 않는다. 마음에 들지 않으면 출력을 버리면 된다. 기억의 재구성이라는, 실패하면 묵묵히 에이전트의 토대를 망가뜨릴 수 있는 조작을 리뷰 가능한 제안으로서 다루고 있다.

호출은 Messages API와는 다른 /v1/dreams 엔드포인트에서 이루어지며, Python SDK라면 다음과 같다 (SDK가 베타 헤더를 자동으로 부여한다).

dream = client.beta.dreams.create(
    inputs=[
        {"type": "memory_store", "memory_store_id": store_id},
        ...
    ]
)

curl로 직접 호출하려면, managed-agents-2026-04-01에 더해 dreaming-2026-04-21 베타 헤더가 필요하다.

-H "anthropic-beta: managed-agents-2026-04-01,dreaming-2026-04-21"

작업은 몇 분에서 몇십 분이 걸리는 비동기 처리이며, pending → running → completed 상태로 전이된다. completed가 되면 outputs[]에 재구성된 스토어의 ID가 들어가므로, 그것을 다음 세션에 memory_store 리소스로 전달하면 정리된 기억으로 에이전트가 움직이기 시작한다.

주목해야 할 것은 instructions 필드(최대 4,096자)다. "코딩 스타일 선호도에 집중하고, 일회성 디버그 메모는 무시하라"와 같이 무엇을 읽어 들일지, 무엇을 남길지, 어떻게 구조화할지를 상위 수준에서 지시할 수 있다. 다만 문서는 주의를 주고 있다. 이것은 스토어 전체에 대한 합성(synthesis) 과정이지, 텍스트 에디터가 아니다. "3행을 이렇게 고쳐라" 식의 행 단위 명령은 거의 무시된다. 개별 엔트리의 정밀한 수정이 필요하다면, 출력 스토어에 대해 Memory Stores API를 사용하라는 정리다.

「에이전트에게 기억을 부여하는」 이야기라면, memory.md에 내용을 추가하거나 RAG (Retrieval-Augmented Generation)를 통해 벡터 DB (Vector DB)에서 불러오는 등 기존의 수법은 얼마든지 있다. Dreams가 이들과 다른 점은, 기억의 **축적 (Accumulation)**과 기억의 **정리 (Organization)**를 별개의 프로세스로 명시적으로 분리했다는 점에 있다.

인간이 잠을 자는 동안 기억을 정리한다는 연상에서 붙여진 이름이겠지만, 엔지니어의 감각에 비추어 본다면 이는 추가 로그에 대한 **컴팩션 (Compaction)**에 가깝다. 쓰기는 빠른 추가 방식으로 끝내고, 정돈된 상태로 다시 만드는 작업은 오프라인 배치 (Batch)로 넘기는 것이다. LSM 트리 (LSM Tree)나 이벤트 소싱 (Event Sourcing)에서 흔히 쓰이는 분할 방식을 에이전트의 기억에 도입한 셈이다.

Dreams는 단독 기능이 아니라, 동시에 공개된 「outcomes」(별도의 그레이더 (Grader)가 결과물을 독립된 문맥에서 채점하고, 기준을 충족할 때까지 작업을 재수행하게 함)나 멀티 에이전트 오케스트레이션 (Multi-agent Orchestration)과 함께 공개된 세트 중 하나다. 모두 「단 한 번의 응답을 좋게 만드는 것」보다 「오랫동안 실행되는 과정에서 스스로 좋아지는 것」 방향으로 에이전트를 유도하려는 목적이 공통적이다.

냉정하게 살펴봐야 할 점도 있다. 우선 Dreams는 집필 시점 기준으로 research preview 단계이며, 이용을 위해서는 신청이 필요하다. 프로덕션 (Production)의 기억 관리를 통째로 맡길 단계는 아니다.

비용 또한 가볍지 않다. 과금은 선택한 모델의 통상적인 토큰 레이트 (Token Rate)를 따르며, 문서에 따르면 비용은 입력 세션의 수와 길이에 거의 비례하여 늘어난다. 즉, 과거의 대화를 통째로 다시 읽게 만드는 행위이므로, 세션이 방대한 에이전트일수록 정리할 때마다 상응하는 비용이 발생한다. 우선 소수의 세션으로 테스트해 보고 품질에 만족한 뒤에 스케일링 (Scaling)하라는 공식의 조언을 순순히 따르는 것이 좋다.

그리고 이것은 Anthropic의 Managed Agents라는 실행 기반 위에서 작동하는 기능이라는 점이다. 기억·채점·오케스트레이션을 플랫폼 측에서 담당하는 설계는 운영이 편해지는 반면, 에이전트의 핵심 자산인 메모리 (Memory) 관리를 벤더 (Vendor)에게 넘기게 된다는 의미이기도 하다. VentureBeat가 이 일련의 발표를 두고 "Anthropic은 당신의 에이전트의 기억을 소유하고 싶어 한다"라고 평한 것은, 자극적인 표현이라기보다 핵심을 찌른 우려다.

그럼에도 불구하고, 추가만 하는 방식의 기억은 오래 실행하다 보면 결국 한계에 부딪힌다는 사실은 누구나 깨닫게 된다. Dreams의 흥미로운 점은 「기억을 정리한다」라는 당연한 운영 작업을, 입력 불변(Input Immutability)·검토 가능(Reviewable)·instructions (지침)로 조종 가능하다는 형태로 일급 API로 승격시켰다는 데 있다. 자체적으로 에이전트의 기억 기반을 구축하고 있는 사람에게도, 이 「축적과 정리를 분리하고, 정리는 제안으로서 반환한다」라는 설계 사상은 그대로 빌려올 가치가 충분하다.

공식 문서는 이쪽이다.