출처 https://youtu.be/geUv4CjPpxI · 채널 Claude (Anthropic) · 길이 00:28:42 포맷 “Code with Claude” 컨퍼런스 워크숍. Anthropic 엔지니어 Kevin Chen이 슬라이드로 개념을 설명한 뒤 곧바로 CLI(ant beta:...)와 Claude Console 화면을 오가며 라이브 데모로 확인시켜 준다. “Ship your first Managed Agent” 워크숍 바로 다음 세션으로 예고됐던 바로 그 발표다. 원본 자막: raw/transcripts/2026-07-11-agents-that-remember.en.srt

한눈에 보는 요약

  • 문제: Managed Agents 세션은 기본적으로 서로 고립된 섬이다. 한 세션에서 알려준 정보는 다른 세션으로 전달되지 않는다 — 실제로 CMA(Claude 발표) 관련 정보를 알려준 뒤 새 세션에서 물어보면 에이전트는 아무것도 기억하지 못하고 되묻기만 한다.
  • 해결책 ①: Memory Store. 세션 컨테이너에 --resource로 마운트하는 영구적인 파일시스템형 저장소. 모델이 bash/grep/파일 읽기 같은 도구로 자유롭게 탐색·검색·쓰기를 할 수 있어, 세션이 끝나도 다음 세션이 이어받아 읽을 수 있다. 마운트 시 prompt(무엇에 집중해 기억할지 지시)와 access(read_write/read_only) 두 파라미터로 동작을 조정한다.
  • 문제 ②: Memory Store를 오래 쓰면 정보가 무한정 쌓인다. 정리·중복 제거·최신성 검증 과정 없이 에이전트가 계속 쓰기만 하면 저장소가 비대해지고 지저분해진다.
  • 해결책 ②: Dreaming. 입력 Memory Store와 과거 세션 기록들을 읽어 사실 확인·정리·중복 제거를 수행하는 비동기 멀티 에이전트 배치 작업. 오케스트레이터가 입력 세션마다 하위 에이전트를 하나씩 띄워 각 기록을 검토하고, 그 결과를 새로운 출력 Memory Store에 기록한다 — 원본 입력 저장소는 절대 건드리지 않는 비파괴적 과정이다.
  • Dreaming의 산출물은 검색 인덱스 파일이다. 완료되면 _index.md 같은 파일이 생겨, 다음 세션이 넓은 범위의 grep 대신 인덱스부터 훑어 원하는 메모리 파일을 빠르게 찾을 수 있다. 실제 데모에서 “Dreaming 이전”에는 리콜 질문에 CMA 세부사항만 겨우 찾아냈지만, “Dreaming 이후”에는 참석한 모든 세션의 타임스탬프·자료 링크·후속 조치까지 정리된 답변이 나왔다.
  • 비용/설계 노트: 세션·Memory Store·Dreaming을 3개의 구성 가능한 레이어로 본다(세션=일시적 대화, Memory Store=세션 간 연결, Dreaming=시간에 따른 정리·보강). 토큰 사용량은 설계상 많지만(모든 것을 다 검사하도록 의도) 대부분 캐시 처리되어(~95% 캐시 적중률 예상) 실제 비용은 낮고, 배치 API처럼 시간대를 지정하면 50% 할인도 검토 중이다.

장면별 상세 설명

[00:00] 1. 인트로 — Kevin Chen, Anthropic

장면 1 — "Agents that remember" 타이틀 슬라이드

발표자 Kevin Chen은 Anthropic의 엔지니어로 자신을 소개하며, 오늘은 “기억을 갖춘 에이전트를 만드는 법”을 다룬다고 문을 연다. 순서는 세 단계다 — ① 에이전트가 기본적으로 왜 고립돼 있는지, 그리고 새로 나온 Memory Store로 여러 세션에 걸쳐 읽고 쓰는 실시간 저장소에 접근하는 법, ② Dreaming이라는 새 기능으로 시간이 지나며 이 저장소를 어떻게 개선하는지, ③ 이 모든 것이 CLI와 Console 인터페이스에 어떻게 연결되는지.

[01:14] 2. 핵심 개념 — 다섯 가지 명사

장면 2 — "Core concepts: Two new nouns" 카드 슬라이드

이전 워크숍에서 이미 다룬 세 가지(주황색 카드)에 두 가지가 추가된다.

  • Agent — 모델 + 시스템 프롬프트 + 툴 설정. 세션 간 재사용 가능.
  • Environment — 세션의 컨테이너 스펙. 역시 재사용 가능.
  • Session — 유저와 에이전트 사이의 대화 스레드 하나.
  • Memory store(신규) — 영구적인 파일시스템형 저장소. --resource로 붙이면 에이전트가 세션 간에 읽고 쓸 수 있다.
  • Dream(신규) — 비동기 배치 작업. 자막과 저장소를 읽어 증류한 뒤 새 Memory Store를 만들어 쓴다.

[02:27] 3. 문제 — 세션은 고립된 섬이다

장면 3 — "The problem" 슬라이드

“Memory Store 없이는 세션 하나하나가 섬이다. 한 대화에서 알려준 사실은 다음 대화에서는 사라진다”는 문장이 오늘 다룰 문제를 요약한다. 오늘날 Claude AI에서 에이전트와 세션을 만들 때, 대부분 한 번에 하나의 세션만 만들고 그 세션들은 서로 격리된다 — 에이전트는 과거 정보를 기억하지 못하고, 미래 세션으로 정보를 넘기지도 못한다.

[02:49] 4. 워크숍 저장소 부트스트랩

장면 4 — 부트스트랩 스크립트 실행 결과 터미널

발표자가 컴퓨터로 전환해 워크숍 저장소(cwc-workshops/agents-that-remember)의 ./scripts/bootstrap.sh를 실행한 결과 화면이다. 스크립트가 에이전트(agent_...)와 환경(env_...)을 만들고, “이전 세션들”을 시딩한다 — 첫날 기조연설 노트, 지난 워크숍(“Ship your first Managed Agent”) 내용, 스케줄 정보를 담은 3개의 과거 세션(HIST1/2/3)이 그 예다. 마지막에 source .bootstrap-vars$AGENT, $ENV, $HIST1~3 환경변수를 셸에 로드한다.

[03:36] 5. 베이스 시나리오 — 세션 A: 메모리 없이 정보 알려주기

장면 5 — 워크숍 가이드와 세션 생성 커맨드

“1a. Session A — tell the agent something new” 단계. ant beta:sessions create --agent "$AGENT" --environment-id "$ENV" --title "Write test (no memory)"로 메모리가 붙지 않은 첫 세션을 만든다. 예시로 알려줄 정보는 “어제 낮에 CMA 발표를 들었고, 멀티 에이전트 오케스트레이션·아웃컴·메모리·드리밍 같은 키워드가 나왔으며, 참고 링크(example.com/notes/cma)도 있다”는 내용이다.

[04:20] 6. 세션 A에 정보 전송

장면 6 — CMA 관련 정보를 담은 이벤트 전송 커맨드

실제로 ant beta:sessions:events send로 위 정보를 담은 user.message 이벤트를 세션 A에 보낸다. 이 세션에는 메모리 저장소가 전혀 연결돼 있지 않다는 점이 핵심이다.

[04:47] 7. 콘솔에서 확인 — 메시지가 큐잉됨

장면 7 — Console의 "Write test (no memory)" 세션 상세

Claude Console → Sessions에서 방금 만든 “Write test (no memory)” 세션을 열면, 방금 보낸 유저 메시지가 그대로 보인다. 발표자는 모델의 응답이 “정보 감사합니다, 여기서 더 할 일이 있는지는 잘 모르겠네요” 정도의 단순한 확인 응답일 것으로 예상한다고 짚는다 — 메모리가 없으니 정보를 저장할 곳이 없기 때문이다.

[05:33] 8. 세션 B — 같은 정보를 되물어보기

장면 8 — "Recall test (no memory)" 세션 생성 및 질문 전송 커맨드

“1b. Session B — ask about it → agent has no idea” 단계. 완전히 새 세션(“Recall test (no memory)“)을 만들어 “CMA 발표에서 어떤 기능이 발표됐어? 내 노트용 go 링크도 줘”라고 물어본다. 세션 A와 B는 서로 다른 대화 스레드이므로, 세션 A에서 알려준 정보가 세션 B로 전달될 이유가 없다는 것을 미리 예고한다.

[06:47] 9. 해법 슬라이드 — Memory Store 부착

장면 9 — "Attach a memory store" 슬라이드

“영구적인, 파일시스템과 비슷한 저장소로, 에이전트가 세션에 걸쳐 읽고 쓸 수 있다. 같은 저장소를 두 세션에 마운트하면 그 둘은 메모리를 공유한다”는 설명과 함께, 내부적으로는 Memory Store가 세션 컨테이너에 파일시스템처럼 연결되고 모델은 이를 읽고 쓰는 도구(디렉토리 구조 그대로 bash로 탐색, grep으로 키워드 검색, 파일 읽기)를 갖게 된다고 설명한다. 저장소를 조직 단위로 제한할 필요는 없다 — 사용자별, 작업 공간별 등 원하는 만큼 만들 수 있고 경계는 사용자가 정한다.

[07:55] 10. 세션 B의 실제 응답 — 예상대로 못 찾는다

장면 10 — "Recall test (no memory)" 세션의 되묻는 응답

세션 B를 실행하자 예상대로 모델은 “CMA talk이라는 특정 발표에 대한 정보에 접근할 수 없습니다”라며, “CMA”가 무엇의 약자인지, 발표가 언제였는지, “go 링크”가 무엇을 뜻하는지 등 되레 질문을 던진다. 오늘날 기본 시나리오의 실제 증거 화면이다 — 무언가를 말하고 다른 세션에서 다시 물어봤지만 세션 간에는 아무 정보도 전달되지 않았다.

[08:41] 11. Memory Store 생성 & 두 세션에 마운트

장면 11 — Memory Store 생성 커맨드와 세션 C/D 마운트 커맨드

ant beta:memory-stores create --name "cwc-memory" ...로 저장소를 만든 뒤, MEM_RESOURCE='{"type":"memory_store","memory_store_id":"'$MEM'","prompt":...}' 형태의 리소스 객체를 세션 생성 시 --resource로 넘긴다. resource 객체는 prompt(무엇에 집중해 기억할지 — 예: “투자 상담사라면 나중에 기억해야 할 구체적인 사항에 집중하라”)와 access(read_write 기본값, read_only로 바꾸면 세션이 저장소를 읽기만 하고 갱신은 못 하게 됨) 두 옵션을 받는다. 이 두 파라미터가 앞으로 계속 반복해서 조정하게 될 지렛대라고 강조한다. 이렇게 세션 C(“Attended — CMA talk (with memory)“)와 세션 D(“Recall test (with memory)“)를 같은 저장소에 마운트해 만든다.

[10:35] 12. 세션 C — 모델이 실제로 메모리에 쓴다

장면 12 — Write 도구 호출 화면, sessions.md 파일 생성

세션 C에 같은 CMA 정보를 보내자, 이번에는 모델이 먼저 메모리를 살펴 기억할 게 있는지 확인한 다음(저장소가 비어 있으므로 없음을 확인), Write 도구로 /mnt/memory/cwc-memory/sessions.md라는 파일을 직접 생성한다. 내용은 “CwC 2026 — 참석 세션: CMA talk(키워드: CMA, multi-agent, orchestration, outcomes, memory, dreaming) — 어제 낮 참석 — 주요 발표: Multi-agent orchestration/Outcomes/Memory/Dreaming 모두 출시 — 내 노트: example.com/notes/cma”로, 모델이 스스로 정보를 구조화해 저장했다.

[11:25] 13. 세션 D — 이번엔 실제로 기억해낸다

장면 13 — 세션 목록(Recall test with memory · Running)과 SES_D 생성 커맨드

Console → Sessions 목록에 방금 만든 세션들(“Recall test (with me…” 실행 중, “Attended — CMA t…”, “Recall test (no mem…”)이 나란히 보인다. 세션 D에서 같은 질문(“CMA talk에서 어떤 기능이 발표됐어? go 링크도 줘”)을 보내면, 이번에는 모델이 먼저 메모리 저장소를 살펴보고 grep으로 “CMA” 등 키워드를 찾아 세션 C가 저장해둔 정보를 그대로 찾아내 정확히 답한다. 발표자는 “간단한 예시지만 메모리의 힘을 보여주는 좋은 예”라고 짚는다.

[12:55] 14. Memory Store 부가 기능 — 목록·버전·콘솔 UI

장면 14 — Console Memory stores 목록과 CLI memories list 결과

Memory Store 자체를 위한 별도 엔드포인트도 있다 — CLI로 저장소 안의 모든 메모리 파일 목록을 조회할 수 있고(ant beta:memory-stores:memories list), 각 메모리 파일은 버전 관리가 되어 수정할 때마다 새 버전이 생기며 이를 위한 여러 엔드포인트가 제공된다. Console → Managed Agents → Memory stores에서도 생성한 저장소(“cwc-memory”, Active)를 확인할 수 있고, 클릭하면 파일시스템 뷰어처럼 내용을 볼 수 있으며 사용자가 직접 파일을 만들거나 내용을 편집할 수도 있다(모델이 잘못 쓴 내용을 고치거나 추가 정보를 주고 싶을 때).

[13:55] 15. Dreaming 개념 — 정리되지 않는 메모리 문제

장면 15 — "Dreaming" 슬라이드

에이전트가 시간이 지나며 이 Memory Store에 반복해서 읽고 쓰다 보면, 정리 과정 없이 정보를 마구잡이로 쏟아붓는 현상이 생긴다는 문제로 이어간다. “과거 자막(과 기존 저장소)을 읽어 모델을 돌리고, 증류된 메모리를 새 저장소에 쓰는 배치 작업. 원본 대화 이력이 구조화된 회상으로 바뀐다”는 것이 Dreaming의 정의다 — 사실 확인, 중복 제거, 최신성 검사까지 포함된 정리 과정을 자동화한다.

[15:38] 16. Dream 작업 생성 커맨드

장면 16 — ant beta:dreams create 커맨드와 워크숍 가이드

ant beta:dreams create --model claude-opus-4-7 --input '{"type":"memory_store",...}' --input '{"type":"sessions","session_ids":[...]}' --instructions "I am attending CwC, and I want to remember what I've learned." 형태로 실행한다. 입력은 두 종류를 받는다 — ① 기존 메모리 저장소(있다면), ② 검토할 세션 ID 목록(과거 히스토리 세션들 + 방금 만든 세션 C/D). instructions는 선택 사항으로, 드림 작업에 추가 지침을 줄 수 있다(특정 정보를 꼭 기록해달라거나, 특정 디렉토리 구조를 강제하는 등). 모델은 가격·품질에 따라 Opus나 Sonnet 중 고를 수 있다. 세션 ID 목록의 개수는 사용자가 정한다 — 매일 소규모로 돌릴 수도, 한 번에 100개 가까이 돌릴 수도 있다(발표자는 그보다 더 큰 규모 확장도 검토 중이라고 언급).

[16:52] 17. Dreams 목록 & 실행 상태

장면 17 — Console Dreams 목록 페이지와 DREAM=drm_... 생성 결과

Console → Managed Agents → Dreams 목록에서 방금 만든 드림 작업을 확인할 수 있다. 드림 작업은 관리형 에이전트 기본 요소 위에 그대로 구축돼 있어서, 처음엔 “대기 중”으로 시작했다가 곧바로 실행되고, Console과 API 양쪽에서 토큰 사용량과 진행 상태를 모두 확인할 수 있다. 규모(제출된 문서 양)에 따라 몇 분~몇 시간이 걸릴 수 있는데, 이것이 바로 비동기 방식의 진짜 장점이다 — 담당 에이전트들이 업무 중인 상황에서 실시간으로 처리하고 싶지 않은 무거운 작업이기 때문이다. 내부적으로는 오케스트레이터가 사용자가 제공한 입력 세션마다 하위 에이전트를 하나씩 띄워 각 기록을 검토하며, 이는 100개를 한꺼번에 줘도 클로드가 모든 정보를 빠짐없이 검토하게 하려는 의도적 설계다.

[20:05] 18. Dream 완료 — 인덱스 파일과 diff

장면 18 — Dream 완료 상세 화면, _index.md diff

작업이 완료(Completed)되면 Console에서 입력/출력 Memory Store, 입력 세션 수, 커스텀 지침, 소요 시간(3분 6초), 그리고 변경사항 diff를 그대로 보여준다. 이번 드림에서는 _index.md라는 새 파일이 만들어졌는데, “CwC 2026 메모리 파일 카탈로그. 올바른 클러스터를 찾으려면 먼저 이 파일을 읽어라”는 설명과 함께 [[sessions]], [[event-logistics]], [[speakers]] 같은 슬러그로 메모리 파일들을 참조한다. 핵심은 비파괴적이라는 점 — 사용자가 만든 입력 Memory Store는 전혀 건드리지 않고, 대신 그 저장소를 복제한 출력 Memory Store에 데이터를 쓴다. 이 인덱스 파일의 목적은 향후 에이전트가 넓은 범위의 grep 대신 인덱스를 먼저 보고 무엇을 찾아야 할지 빠르게 파악하게 하는 것이며, 처음 만들었던 세션들에는 없던 추가 정보(이벤트 설명, 메타데이터 등)도 함께 보강된다.

[23:15] 19. Dreaming 이후 리콜 — 훨씬 풍부한 답변

장면 19 — "Post-dreaming recall" 세션의 상세 리캡 응답

Dream이 만든 출력 Memory Store를 새 세션(“Post-dreaming recall”)에 마운트하고, 이번에는 더 폭넓게 “내가 어떤 세션에 참석했는지, 어떤 자료 링크를 가지고 있는지, 어떤 후속 조치를 표시해뒀는지” 물어본다. 모델은 이제 인덱스 파일부터 먼저 읽기 시작하는 방식으로 동작하며, 응답은 “CMA talk(4개 발표 요약: Multi-agent orchestration/Outcomes/Memory 출시, Dreaming은 리서치 프리뷰로 출시 — 다른 셋과 상태가 다르다는 점까지 짚어줌), Day 1 오프닝 키노트” 등 참석한 모든 세션의 요약과 타임스탬프·자료 링크까지 정리해 보여준다. Dreaming 전에는 단편적인 정보만 겨우 찾았던 것과 대비된다. 선택적으로 결과에 만족하면 기존 입력 Memory Store를 해제(release)할 수도 있는데, 이는 이전 세션에는 영향을 주지 않으면서 조직 내 저장소 개수를 적절히 유지해준다.

[26:31] 20. 클로징 — 시도해보기 & Q&A

장면 20 — "Try it with your own domain!" 클로징 슬라이드

발표 말미의 3단계 요약: ① 자신의 CMA(고객 관리) 에이전트에 Memory Store를 만들어 붙이고, ② 지난 한 주 세션들에 대해 Dreaming을 돌리고, ③ 출력 저장소를 다음 세션에 교체해 넣어보라는 제안이다. 이어진 청중 Q&A에서는 토큰 사용량을 물었는데, 설계상 모든 것을 다 검사하도록 의도했기 때문에 토큰을 많이 쓸 것으로 예상하지만 대부분의 처리가 에이전트에 의해 이뤄지므로 대부분의 토큰이 실제로 캐시된다(드림 세션 대부분에서 캐시 적중률 약 95% 예상)고 답한다. 배치 API처럼 다른 시간대를 예약하면 50% 할인된 가격을 제공하는 방안도 검토 중이며, 토큰 사용 제어를 위한 추가 기능으로 모델 전환, 프롬프트 세부 조정, 토큰 예산 관리 등을 언급한다. 마지막으로 오늘 배운 내용 요약 — 세션 간 정보 단절 문제 → Memory Store로 첫 단계 해결 → 그로 인해 생기는 무한 증가 문제 → Dreaming으로 완화 — 을 정리하며 마무리한다.

핵심 개념·용어 메모

  • 세 가지 구성 가능한 레이어 — Session(일시적, 하나의 대화 스레드) → Memory store(세션 간 정보를 연결) → Dreaming(시간에 따라 메모리를 정리·보강·개선). 세션 수와 처리 정보량이 늘어도 메모리는 “감당 가능한” 수준으로 유지된다.
  • Memory Store 마운트 파라미터prompt(무엇에 집중해 읽고 쓸지 스티어링), access(read_write/read_only) — 이 두 파라미터가 실전에서 계속 튜닝하게 될 지렛대.
  • Dreaming = 비동기 멀티 에이전트 배치 작업 — 오케스트레이터가 입력 세션마다 하위 에이전트를 1개씩 생성해 각 기록을 검토·사실 확인·보강한 뒤, 정리·중복 제거까지 수행. 항상 비파괴적(입력 저장소 그대로 두고 출력 저장소에 새로 씀).
  • Dreaming 산출물 = 검색 인덱스_index.md 같은 파일이 생겨 향후 세션이 넓은 grep 대신 인덱스부터 훑어 효율적으로 정보를 찾게 해준다.
  • 토큰/비용 특성 — 설계상 전수 검사라 토큰을 많이 쓰지만 캐시 적중률 ~95% 예상. 배치 API 유사 방식(비피크 시간대)으로 50% 할인 검토 중.
  • Memory Store 부가 엔드포인트 — 파일 목록 조회, 버전 관리(수정마다 새 버전), Console 파일시스템 뷰어에서 직접 열람·수동 편집 가능.

등장한 사람·조직·키워드

Kevin Chen(Anthropic 엔지니어), Anthropic, Claude Managed Agents, Memory Store, Dreaming, Code with Claude(컨퍼런스), github.com/anthropics/cwc-workshops/agents-that-remember(워크숍 저장소), ant beta:memory-stores/ant beta:dreams(CLI), Claude Opus 4.7, Claude Sonnet 4.6.

원문 인용 모음

  • [00:00:21] “Hello everyone. Thank you all for joining us today. Um my name is Kevin. Uh I’m an engineer here at Anthropic and today we’ll be learning about how to build agents that remember.”
  • [00:01:14] “So in the previous workshops, I think we’ve learned a little bit about how Claude managed agents has these concepts called an agent, environment, and a session.”
  • [00:02:27] “Let’s kind of like talk a little bit about the problem today. So, when you create agents on Cloud AI today and sessions… most of the time you’re only creating one session at a time and these sessions are isolated from each other.”
  • [00:06:00] “Yeah, I don’t really have access [to] information. I can help you in these various ways.” — 메모리 없이 되묻는 세션 B의 실제 응답.
  • [00:14:01] “When you have agents that are reading and writing to this memory store over time, we’ve noticed that often times they can start just kind of dumping information to that memory store.”
  • [00:15:01] “It will also organize those memory files and see if there’s any duplicates… it’ll produce an output memory store such that in the future, when you attach that output to additional sessions…”
  • [00:19:00] “We don’t actually touch the input memory store at all that you create. So this is a non-destructive process. What we actually do is we will clone your input memory store into what’s called an output memory store.”
  • [00:20:01] “Great. So looks like it just completed and the cool thing here is that in console we actually show you a diff of what it did. So you can see dreaming here it created an index file.”
  • [00:26:35] “Um so as I said before like I think by design we actually do want it to be [checking everything]…” — 토큰 사용량 Q&A 답변 도입부.