Anthropic, AI 에이전트 기억을 '꿈'으로 교정하다
The Components of Agent Memory
Anthropic이 Claude의 에이전트 메모리 설계를 공개했다. 뇌가 수면 중 경험을 재생해 장기 기억으로 정리하듯, 유휴 시간에 로그를 되짚어 오류를 고치는 '드리밍' 기법을 적용했다. Pokémon Red 실험에서 Sonnet 3.7은 413개 파일을 쌓고 배지 1개를 얻은 반면, Fable 5는 9개 파일로 배지 4개를 획득했다. 강한 모델일수록 기억 규칙을 일일이 지정하기보다 중요한 것을 스스로 판단하게 두는 편이 효과적이었다.
키르케고르는 삶은 오직 뒤로 돌아볼 때 이해할 수 있지만, 앞으로 나아가며 살아야 한다고 썼다. 우리는 AI 에이전트의 기억을 설계할 때 비슷한 딜레마에 부딪혔다.
HN 토론
64- andai
여기서 설명하는지는 모르겠지만, 그래프(그림 10)를 보면 wiki + search가 dreaming을 능가하는 것 같고, dreaming은 wiki + search 구성에 한계 이득만 추가하는 것 같습니다.
search가 dreaming보다 훨씬 저렴하다고 가정합니다(시간 규모에 따라 다를 수도 있겠지만요?). 그래서 그 점이 꽤 중요해 보입니다.
- yfontana
지금까지 사용한 모든 harness에서 자동 메모리 생성을 꺼두었습니다. Claude Code는 때때로 어쨌든 몇 개를 생성하는데, 아마 95%는 삭제할 겁니다. 생성되는 메모리는 거의 항상 현재 작업 중인 특정 작업에만 관련이 있습니다. 다시 해야 할 작업이라면, 그래, 아마 유용할 수도 있겠죠. 하지만 대부분의 경우 그렇지 않아서, 컨텍스트를 어지럽히지 않도록 삭제합니다.
그래서 메모리에서 보고 싶은 주요 개선점은 어떤 메모리를 생성할지에 대한 더 나은 판단입니다.
"dreaming"에 관한 부분은 에이전트 트랜스크립트에 엄청난 정보가 포함되어 있는데, 현재 이 정보가 충분히 활용되지 않고 있다는 생각이 듭니다. 여기서 몇 번 본 조언을 반복하자면: 자신의 트랜스크립트를 duckdb에 수집하세요(claude code가 약 10분 만에 그 파이프라인을 구축할 겁니다). 그리고 그것들에 대해 데이터 분석을 좀 하세요. 어디서 시작할지 모르겠다면 몇 가지 아이디어: 도구 호출 실패를 살펴보고 흔한 것들을 예방할 수 있는지 확인하고, 큰 캐시 미스가 있는지 그리고 그 원인이 무엇인지 확인하고, 시간 경과에 따른 다양한 효율성 지표(달러당 토큰, 토큰당 코드 줄 수 등)를 메인 스레드 대 서브 에이전트로 비교해 보세요. 이런 것들로 시작했는데, 몇몇 실마리를 따라가다가 흥미로운 통찰을 얻었습니다. 예를 들어, 저는 Opus 5.5 / Sol 6.1이 작업을 너무 작은 단위로 나누는 경향이 있다는 징후를 발견했습니다. 그들은 이전 모델보다 한 번에 더 많은 작업을 할 수 있는 능력이 있는데, 저는 그걸 제대로 활용하지 못하고 있었습니다.
- bob1029
cerulean chart를 향한 그들의 진전은 저를 메모리 없음 쪽으로 꽤 강하게 설득하고 있습니다.
장기 실행 에이전트에서 가장 피하고 싶은 것은 변동성입니다. 그것을 어느 한 방향으로든 빠르게 밀어붙이는 것은 평균적인 경우에 바람직하지 않습니다. 적어도 저에게는요.
- prtmnth
저는 memory-prune이라는 스킬을 가지고 있는데, 그 유일한 목적은 자동으로 생성된 메모리를 가져와서 그것이 살아남을 자격이 있는지 평가하고, 코드 주석, 규칙, 프로젝트의 AGENTS.md 파일, 전역 AGENTS.md/CLAUDE.md 파일에 저장할지, 아니면 (그리고 이것이 가장 자주 선택되는 옵션인데) 전혀 저장하지 않고 삭제할지 결정하는 것입니다.
- 2001zhaozhao
이 글은 제가 만들고 있는 것에 대한 많은 검증을 제공합니다. 아이디어를 소화하기 위해 이 글을 몇 번 다시 읽을 것입니다. AI의 메모리 시스템은 극히 중요하며, 제 생각에는 단순히 메모리 관리를 위해 기본 모델을 훈련하는 것보다 훨씬 더 잘할 수 있습니다.