Claude의 Dreams, 에이전트의 Memory Store를 재구축하고 원본은 절대 건드리지 않는다 (2026)

두 개의 입력, 하나의 새로운 출력

Dream은 정확히 두 가지 종류의 입력을 받는 "비동기 작업(asynchronous job)"입니다. 즉, "기존의 memory store(Claude가 검증, 중복 제거 및 재구성하는 store)"와 "1개에서 100개 사이의 sessions(Claude가 패턴과 인사이트를 발굴하여 출력에 반영할 과거 대화 기록)"입니다.

생성되는 결과물 역시 매우 정밀하게 설명되어 있습니다. "새롭게 재구성된 memory store: 중복 병합, 오래되거나 모순된 항목을 최신 값으로 대체, 그리고 새로운 인사이트 도출."

세 번째 항목에 주목하세요. 중복을 병합하고 오래된 항목을 대체하는 것은 정리 작업입니다. 하지만 대화 기록에서 새로운 인사이트를 도출하는 것은 차원이 다릅니다. store에 기록된 적이 없는 세션을 읽고 그 세션이 암시하는 바를 기록하는 것이기 때문입니다. 대화 기록은 있지만 아직 store가 없는 경우, 공식 문서는 다음과 같은 해결책을 제시합니다. "먼저 빈 memory store를 생성하고 이를 memory_store 입력값으로 전달하세요."

입력값은 절대 수정되지 않습니다

이것이 바로 이 기능을 안전하게 사용할 수 있게 만드는 디자인 선택입니다:

"입력 store는 절대 수정되지 않으므로, 결과를 검토한 후 마음에 들지 않으면 폐기할 수 있습니다."

문서 후반부에는 더 강력한 어조로 재차 강조합니다. "Dream 자체는 입력을 절대 삭제하거나 수정하지 않습니다." 그리고 이는 실패 시에도 유지됩니다. failed 또는 canceled 상태가 된 Dream의 경우, "출력 memory store는 실패 전에 기록된 상태 그대로 유지"되며, "출력 store에 부분적인 내용이 보존되므로 중단되기 전에 무엇이 생성되었는지 검사할 수 있습니다."

따라서 잘못된 Dream의 실패 모드는 삭제하면 그만인 store가 생기는 것뿐입니다. 복구해야 하는 store가 아닙니다.

방향을 안내할 뿐, 에디터가 아닙니다

최대 4,096자까지 입력 가능한 선택적 instructions 필드는 "Dreaming 파이프라인이 합성하는 내용을 안내합니다. 이는 파이프라인 전반에 걸쳐 적용되어, 무엇을 자세히 읽을지, 무엇을 병합하거나 버릴지, 그리고 출력 store를 어떻게 구성할지 결정합니다." Anthropic이 제시한 예시는 다음과 같은 집중 지침입니다. "코딩 스타일 선호도에 집중하고, 일회성 디버깅 노트는 무시하세요."

그리고 헛수고를 방지해 줄 주의 사항이 나옵니다:

"이 파이프라인은 입력값에 대한 합성 패스(synthesis pass)일 뿐, store의 텍스트에 적용되는 에디터가 아닙니다. 따라서 특정 라인을 대상으로 하는 명령형 지시("X 문장을 Y로 변경", "Z 섹션의 개수 수정")는 일반적으로 아무런 변화를 일으키지 않습니다."

특정 부분을 직접 수정하려면 문서에서는 다른 방법을 안내합니다. "출력 store에서 직접 Memory Stores API를 사용하세요." Dreams는 store의 전반적인 형태를 잡기 위한 것이지, 개별 라인을 편집하기 위한 것이 아닙니다.

시간이 걸리는 만큼 걸리며, 진행 과정을 지켜볼 수 있습니다

"Dreams는 비동기식으로 실행되며, 입력 대화 기록의 수에 따라 일반적으로 몇 분에서 몇 시간까지 걸립니다." 라이프사이클은 pending, running을 거쳐 completed, failed, canceled 중 하나로 끝납니다.

알아두면 좋은 사소한 운영 세부 사항이 있습니다. "워크플로우가 입력 store를 복제하고 나면, Dream이 running을 시작한 직후 Dream의 outputs[]에 출력 store ID가 나타납니다. 실행 중인 Dream은 일시적으로 빈 outputs[]를 보고할 수 있습니다." 초기에 배열이 비어 있는 것은 오류가 아닙니다.

그리고 작업 과정을 관찰할 수 있습니다. 실행 중인 Dream의 session_id는 "파이프라인을 실행하는 기본 세션을 가리키며", 이 세션의 이벤트를 스트리밍하여 "Dream이 실시간으로 무엇을 읽고 쓰는지 관찰"할 수 있습니다. 해당 세션은 "Dream이 최종 상태에 도달하면 삭제되지 않고 아카이브되므로, 이후에도 대화 기록을 계속 사용할 수 있습니다."

완료하는 두 가지 방법

Dream이 완료되면 그 출력은 "워크스페이스의 일반적인 memory store"가 됩니다. 여기서부터 문서에 명시된 두 가지 경로가 있습니다. 활용하기: "입력 memory store 대신(또는 그와 함께) 향후 세션에 memory_store 리소스로 연결합니다." 폐기하기: store를 삭제하거나 아카이브합니다.

이 문장에서 주목할 숨은 옵션은 함께(alongside)입니다. 큐레이션된 store와 원본 중 하나만 선택하도록 강요받지 않습니다.

실제적인 구조적 문제를 해결합니다. 점진적인 기록은 모순을 축적합니다. 이는 Anthropic의 구현 오류가 아니라, 추가 전용(append-mostly) store에서 필연적으로 발생하는 현상입니다. 검토 단계를 거치는 주기적인 합성 패스는 합리적인 해결책이며, 이 작업이 수행되는 store의 메커니즘은 Claude's agent memory stores에서 다루고 있습니다.

자동으로 실행되지 않습니다. 예약 실행이나 백그라운드 트리거가 없습니다. 사용자가 직접 Dream을 생성하고, 모델을 선택하고, 상태를 폴링하고, 출력을 검토하고, 연결하거나 폐기해야 합니다. 이 모든 과정이 명시적인 호출로 이루어집니다.

두 번의 게이트가 존재하며, 그 조건은 구체적입니다. "Dreaming은 리서치 프리뷰 기능"으로, 요청을 통해 액세스 권한을 얻어야 합니다. 또한 헤더가 중요합니다. "Dream 엔드포인트는 dreaming-2026-04-21 베타 헤더로 제한됩니다. managed-agents-2026-04-01 헤더 단독으로는 dreams에 대한 액세스 권한을 부여하지 않습니다." 세션 및 memory-store 호출에는 후자만 있으면 됩니다.

토큰 비용이 비례하여 발생합니다. "Dreams는 선택한 모델의 표준 API 토큰 요율로 청구"되며, "비용은 입력 세션의 수와 길이에 대략 선형적으로 비례하여 증가"합니다. Anthropic의 권장 사항은 소규모로 시작하는 것입니다. "소규모 세션 배치로 시작하여 큐레이션 품질에 만족하면 점차 규모를 늘리세요."

실행 도중 입력값을 삭제하는 것으로부터 보호해주지 않습니다. 문서에 명시된 경고에 따르면, "실행 중에 입력 memory store를 아카이브 또는 삭제하거나 입력 세션을 삭제하면 Dream이 input_memory_store_unavailable 또는 input_session_unavailable 오류와 함께 실패"합니다. 입력값은 Dream에게는 읽기 전용이지만, 사용자로부터 잠겨 있지는 않습니다.

도달할 수 있는 크기 제한이 있습니다. 오류 목록에는 input_memory_store_too_large, 조직의 store 한도에 도달했을 때 발생하는 memory_store_org_limit_exceeded, 그리고 "파이프라인이 런타임 예산을 초과"했을 때 발생하는 timeout이 포함됩니다.

"이제 Claude가 자동으로 자체 메모리를 유지 관리한다." Managed Agents의 경우에 해당하며, Dreams를 통해 자동으로 이루어지는 것은 아닙니다. 이는 명시적인 입력값, 모델 선택, 그리고 마지막의 결정 단계를 거쳐 사용자가 직접 호출하는 작업입니다.

"잘못된 메모리를 수정해 준다." 입력값이 뒷받침하는 내용을 바탕으로 "오래되거나 모순된 항목"을 최신 값으로 대체할 뿐입니다. 특정 문장을 변경하고 싶다면 출력 store에서 Memory Stores API를 사용해야 합니다. 문서에 따르면 명령형 라인 수준 지시는 "일반적으로 아무런 변화를 일으키지 않습니다."

"검토는 선택 사항이다." 검토야말로 이 기능의 핵심입니다. 검토되지 않은 Dream을 프로덕션 세션에 바로 연결하는 것은 이 디자인을 안전하게 만드는 유일한 특성이자, 입력값을 보존하는 근본적인 이유를 버리는 행위입니다.

"세션이 많을수록 좋다." 세션이 많아질수록 비용이 더 많이 들고 시간이 오래 걸립니다. 가이드라인에 따르면 품질이 마음에 든 후에 규모를 늘려야지, 그 전에는 권장하지 않습니다. 비용과 실행 시간 모두 대화 기록의 양에 비례합니다.

"ChatGPT가 하는 일과 똑같다." 레이어도 다르고 사용성도 다릅니다. OpenAI의 Dreaming은 백그라운드에서 소비자 메모리를 큐레이션합니다. 반면 Anthropic의 Dreams는 개발자가 트리거하는 합성 작업으로, 검토 가능한 결과물을 생성하며 원본 소스를 절대 수정하지 않습니다.

"취소하면 원래대로 되돌아간다." 취소는 실행을 중단할 뿐, 정리 작업을 수행하지 않습니다. 취소된 Dream은 부분적으로 생성된 출력 store를 그대로 남겨두어 사용자가 검사하거나 삭제할 수 있도록 합니다. 또한 Dream을 아카이브해도 "출력 memory store는 건드리지 않으며", Dream 자체에 대해서는 "아카이브 취소 기능이 없습니다."

1단계: 큐레이션하기 전에 store에서 "오래됨(stale)"이 무엇을 의미하는지 정의하기

합성 패스의 결과는 제공하는 판단 기준에 달려 있습니다. 작업을 실행하기 전에 store의 어떤 범주 항목이 변경될 수 있고, 어떤 항목이 보존되어야 하는지 명문화하세요.

instructions 필드는 이러한 판단 기준이 들어가는 곳이며, 상위 수준의 가이드라인으로 작성할 때 가장 효과적입니다. Anthropic의 표현을 빌리자면 "집중 영역... 변경 없이 보존할 콘텐츠, 또는 store 전반에 적용하고자 하는 출력 규칙"입니다. "코딩 선호도에 대해 가장 최근에 언급된 내용을 우선시하라"는 적절한 수준의 지침입니다. "세 번째 섹션의 숫자를 수정하라"는 그렇지 않습니다.

2단계: 실제로 실행할 검토 단계 구축하기

검토가 가능하도록 입력 store가 보존됩니다. 무엇을 비교(diff)할지, 그리고 어떤 경우에 폐기할지 미리 두 가지를 결정하여 실제로 검토가 이루어지도록 하세요.

유용한 기본 방식은 문서에서 명시적으로 허용하는 것처럼, 출력을 입력 대신 사용하는 것이 아니라 일정 기간 동안 입력 store와 함께 연결하고 에이전트의 행동이 개선되는지 관찰하는 것입니다. 기억된 항목 간의 충돌을 찾아내는 것이 핵심이며, 이러한 일반적인 습관은 detecting conflicts in AI memory에서 다루고 있습니다.

Dream이 실행되는 동안 세션 이벤트를 스트리밍하면 무엇을 읽고 쓰는지 알 수 있습니다. 이는 최소한 한 번은 해볼 가치가 있습니다. 어떤 대화 기록에 의존하는지 확인하는 것이 세션 선택이 올바르게 되었는지 파악하는 가장 빠른 방법이기 때문입니다.

3단계: 큐레이션하는 store를 특정 벤더의 파이프라인으로부터 독립적으로 유지하기

여기서 구조적인 핵심이 나옵니다. 이는 Dreams에 대한 비판이 아닙니다. 메커니즘은 훌륭하며 검토 게이트는 올바른 디자인입니다. 다만, 이는 한 플랫폼의 memory store로 범위가 제한되어 있고, 리서치 프리뷰 플래그 뒤에 숨겨져 있으며, 특정 방식으로 구축된 에이전트만을 대상으로 합니다.

반면 가장 빠르게 노후화되는 메모리는 사용 중인 모든 도구에 분산되어 있는 메모리입니다. 채팅에서 언급한 선호도, 코딩 에이전트에게 준 피드백, 다른 곳의 세션 기록에 남겨진 결정 사항 등이 그렇습니다. 중복과 모순은 단일 store 내부보다 여러 도구에 걸쳐 훨씬 더 빠르게 누적되며, 단일 벤더의 큐레이션 패스는 이를 감지할 수 없습니다.

직접 소유한 메모리 레이어는 통합된 store가 존재하는 곳이며, 동일한 습관이 적용되는 곳입니다. 즉, 읽고, 수정하고, 정리하고, 버전 기록을 유지하는 것입니다. MemoryLake는 세 단계로 설정할 수 있습니다.

1단계: API 키 생성

로그인하고 대시보드에서 API 키를 생성합니다. 직접 소유한 store는 직접 열고 검사할 수 있으므로, 앞서 언급한 검토 습관을 막연한 바람이 아닌 실천 가능한 현실로 만들어 줍니다. Anthropic의 memory store는 Anthropic 자체 API를 통해 관리되며 원래 위치에 그대로 유지됩니다.

2단계: 첫 번째 메모리 업로드

지속적인 사실들을 입력하세요. 결정 사항과 그 이유, 도메인 어휘, 상시 선호도, 여러 번 제공한 수정 사항 등이 이에 해당합니다. Dream이 합성할 것과 동일한 자료를 사용 중인 모든 도구가 접근할 수 있는 곳에 보관하는 것입니다.

3단계: AI 및 에이전트 연결

에이전트가 해당 store를 가리키도록 설정하세요. 이렇게 하면 큐레이션은 각 벤더의 메모리 시스템마다 수행하는 것이 아니라, 지식 자체를 위해 단 한 번만 수행하는 작업이 됩니다. 이에 대한 자세한 내용은 syncing AI memory across your tools에서 다루고 있습니다.

첫 번째 변화는 "시간이 지날수록 에이전트의 메모리가 나빠졌다"는 말이 막연한 불평이 아니라 진단 가능한 상태가 된다는 점입니다. Anthropic은 여기에 명칭과 메커니즘을 부여했습니다. 바로 점진적 기록, 중복, 모순, 오래된 항목입니다.

두 번째는 검토가 모든 큐레이션 기능의 기본 기대치가 된다는 점입니다. Dreams는 입력값을 절대 수정하지 않음으로써 좋은 선례를 남겼습니다. 이는 도입하는 모든 메모리 시스템에 요구할 만한 합리적인 사항입니다.

세 번째는 범위에 대한 질문이 더 날카로워진다는 점입니다. 플랫폼별 큐레이션 패스는 해당 플랫폼이 볼 수 있는 store만 도와줄 뿐입니다. 동일한 사용자가 다른 네 가지 도구에 말한 내용은 볼 수 없습니다. 이것이 바로 auditing what your AI remembers를 여러 번이 아닌 한 번의 작업으로 통합하여 수행해야 하는 이유입니다.

• 소규모 세션 배치로 시작하세요. 비용과 실행 시간 모두 대화 기록의 양에 비례하며, Anthropic은 품질이 마음에 든 후에만 규모를 늘릴 것을 권장합니다.
• 적절한 수준에서 instructions를 작성하세요. 집중 영역과 출력 규칙은 효과가 있지만, 라인 수준의 지시는 일반적으로 아무런 변화를 일으키지 않습니다.
• 대체하기 전에 함께 연결해 보세요. 출력 store를 입력 store 대신 사용하는 대신 그 옆에 나란히 배치할 수 있습니다.
• 실행 도중 입력값을 건드리지 마세요. 실행 중에 입력 store나 세션을 아카이브하거나 삭제하면 Dream이 즉시 실패합니다.
• 일시적으로 outputs[]가 비어 있을 수 있음을 인지하세요. 입력값이 복제되고 나면 Dream이 실행을 시작한 직후 출력 store ID가 나타납니다.
• 정밀한 편집에는 Memory Stores API를 사용하세요. Dreams는 형태를 재구성하고, API는 편집을 수행합니다.
• 취소 후에는 정리 작업을 수행하세요. 취소되거나 실패한 Dream은 의도적으로 부분적인 출력 store를 남겨둡니다.
• 프리뷰 단계에서 벗어날 때 다시 확인하세요. Dreaming은 자체 베타 헤더를 가진 리서치 프리뷰 기능이며, 프리뷰 동작은 변경될 수 있습니다.

여기서 모방할 가치가 있는 메커니즘은 합성이 아닙니다. 그것을 둘러싼 보장입니다. 즉, store를 읽고, 대화 기록을 읽고, 새로운 store를 작성하되, 원본은 그대로 두어 사람이 거부할 수 있도록 하는 것입니다.

이것은 메모리를 잘못될 수 있는 중요한 요소로 진지하게 다루는 디자인입니다. Dreams에 대한 액세스 권한이 있든 없든, 이 습관은 일반화될 수 있습니다. 즉, 신중하게 큐레이션하고, 도입하기 전에 검토하며, 중요한 지식은 직접 읽을 수 있는 곳에 보관하는 것입니다.