요약
에이전트의 메모는 앞날을 내다본 예측이고, 쉬는 동안 기록을 되짚는 '드리밍'이 틀린 메모를 고칩니다.
앤트로픽 엔지니어링 팀의 랜스 마틴이 쓴 글입니다. 사람이 낮에 겪은 일을 잠자는 동안 장기 기억으로 정리하듯, 에이전트도 작업 기록을 남기고 쉬는 시간에 되짚어 정리하게 하자는 구상을 여러 실험으로 시험했습니다.
왜 중요한가
- 메모를 예측으로 보면, 틀린 예측을 나중에 기록과 대조해 바로잡는 단계가 따로 있어야 합니다.
- 같은 메모리 도구를 줘도 모델이 메모를 읽고 가설을 검증하지 않으면 효과가 거의 없었습니다.
핵심 내용
- 메모리를 트랜스크립트(작업 과정 기록), 메모, 위키 같은 정리된 지식, 매 세션 미리 넣는 맥락의 네 층으로 나눴습니다.
- 드리밍은 세션이 끝난 뒤 기록과 메모를 대조해 오류를 고치고, 자주 쓰는 내용을 위층으로 올립니다.
- 포켓몬 레드에서 길을 잘못 적은 메모를 드리밍으로 고친 실행만 산을 넘었고, 메모리가 없는 실행은 넘지 못했습니다.
- 데이터베이스 과제에서 Opus 5.5는 메모리로 점수가 0.655에서 0.838로 올랐지만, Sonnet 4.6은 거의 제자리였습니다.
- 사내 문서 약 35만 개로 만든 위키는 드리밍을 2회에서 128회로 늘리자 정답률이 13%에서 48%로 올랐습니다.
HN 반응
- 진짜 학습은 가중치를 고쳐야 한다는 지적에, 사용자별 모델은 클라우드에서 비현실적이라는 반론과 LoRA(모델에 덧붙이는 작은 가중치)로 된다는 재반론이 오갔습니다.
- 자동 메모리가 지금 작업에만 맞는 메모를 쌓아 꺼 두거나 대부분 지운다는 경험담이 여럿 나왔습니다.
읽을 만한 글이긴 한데, 메모리를 '앞으로 필요할 것에 대한 예측'으로 정의해 버리면 이 모델들이 지속적으로 학습하지 못한다는, 즉 가중치를 업데이트하지 못한다는 진짜 문제를 슬쩍 피해 가는 셈입니다. Opus 5.5의 진짜 기억과 경험, 지식은 이미 굳어 버렸고, 마크다운으로 아무리 잔재주를 부려도 그건 바뀌지 않습니다.
제 생각에는 이쪽이 더 나은 연구 방향입니다.
https://research.google/blog/the-sleep-framework-a-new-way-for-llms-to-retain-knowledge-in-continual-learning/
가중치를 계속 업데이트하는 방식은 앤트로픽처럼 클라우드 추론을 제공하는 회사에는 절대 현실성이 없을 겁니다.
그런 걸 바라신다면 로컬에서 돌릴 수 있는 모델을 보시는 게 낫겠네요. 근데 그것도 아마 몇 년은 더 있어야 한다는 걸 곧 깨닫게 되실 거고요.
가중치를 업데이트하지 못하는 한 AI는 영원히, 초고효율 서류 캐비닛을 든 영화 〈메멘토〉의 주인공 신세일 겁니다.
문서가 아니라 지속적인 경험으로 기억하는 AI가 나온다면 그 영향이 엄청나고 돈도 되는 일이라, 비즈니스 모델 자체가 바뀔 겁니다.
사실 업무 문서로만 학습한 AI를 원하시는 건 아닐 겁니다. 사람으로 치면 어떨지 생각해 보세요. 위키만 읽고 뉴스도, 책도, TV 프로그램도, 게임도, 대화도 전혀 접하지 않는 사람이요. 그런 사람은 위키에 '과적합'되어 이성적으로 생각하는 능력을 잃고 결국 정신과 신세를 지게 될 겁니다.
가중치를 계속 업데이트해야 한다고 여기는 건 일반인들이 인간의 정신이 그렇게 작동한다고 상상하기 때문입니다. 하지만 사람의 정신도 (아마) 지속적으로 학습하지는 않습니다. 잠자는 동안 일어나는 통합 과정이 있죠.
그러니 어떤 의미에서 AI의 학습은 이미 크게 다르지 않습니다. 단기 기억에 있던 최신 데이터가 장기 기억으로 통합되는 거니까요. 다만 사람은 그게 매일 밤 일어나고 AI는 분기마다 일어난다는 차이일 뿐입니다. 그리고 그 단기 기억도 사람은 자기 경험이고 AI는 인터넷 전체라는 차이가 있고요.
또 돈이 되느냐 아니냐는 기술이 어떻게 만들어졌느냐가 아니라 효용과 가격이 결정합니다.
클라우드 추론에서 왜 현실성이 없는지 좀 더 말씀해 주실 수 있나요? 꼭 이해하고 싶어서요.
운영 관점에서 생각해 보세요. 추론을 돌리려면 모델은 결국 요청을 처리하기 위해 RAM에 올려야 하는 거대한 바이너리 덩어리입니다.
가중치를 업데이트한다는 건 이 모델을 바꾼다는 뜻이고요.
이 기능을 제공하려면 추론 제공자는 요청을 제때 처리하기 위해 사용자별로 맞춤화된 모델을 RAM에 올려 둬야 합니다. 거기에 서비스하는 사용자 수를 곱해 보세요.
바뀌는 가중치를 원본 모델에 얹는 '오버레이'처럼 붙여서 조금 최적화해 볼 수는 있습니다. 하지만 그것도 나름의 단점이 따르고요(구현된 적도 없고 이론상 가능하다는 얘기일 뿐이라는 점은 차치하더라도). 제대로 구현하기도 정말 어려울 겁니다.
그렇게 묶이는 자원의 양을 생각하면 앤트로픽 같은 클라우드 추론으로는 불가능합니다.
요즘 이 분야 흐름을 안 따라가신 것 같네요. 이미 있습니다. LoRA라고 합니다. Unsloth 프로젝트가 엄청 큰데, 목적 자체가 LLM LoRA를 쉽게 학습시키는 겁니다. LoRA만 따로 보이지 않는 이유는 모델을 파인튜닝하는 사람들이 이를 기본 모델에 병합해서 전체 모델 가중치로 배포하기 때문입니다.
LoRAX도 보세요. 정확히 이걸 하는 추론 엔진인데, 하나의 기본 모델로 수많은 LoRA를 서빙할 수 있습니다.
그렇군요, 그러니까 앤트로픽이 모든 구독자에게 제때 응답할 수 있도록 사용자별 LoRA 어댑터를 바로 쓸 수 있게 준비해 둘 수 있다는 의견이시군요.
탐구해 볼 만한 흥미로운 생각이네요. 저는 이 주제에 전혀 전문가가 아니라서 제 입장에서는 엄청나게 어려운 운영 문제처럼 들린다는 건 인정합니다... 그래도 저는 앤트로픽 직원이 아니니까, 어쩌면 앤트로픽은 말씀하신 대로 그 도전을 감당할 수 있을지도 모르죠.
LoRA에 사용자마다 고정된 파라미터 수(예를 들어 1~5%)를 준다면 그렇게까지 말도 안 되는 소리는 아닌 것 같은데요.
정말 말이 안 되는 부분은 아마 사용자마다 모델을 올려서 돌리는 쪽일 겁니다. 그래도 학습되지 않은(특화되지 않은?) 모델을 어떻게든 메모리에 상주시켜 둘 수 있다면, 조정된 가중치만 필요할 때 불러오는 게 가능할지도 몰라요.
어차피 지금도 캐시 적중률 때문에라도 실행할 때마다 사용자·고객별로 다른 컨텍스트가 필요하지 않나요?
제 짐작으로는 테넌트마다 자기만의 '핸들러/드라이버' 모델이 있어서 사용자 의도나 문제 등에 따라 가중치를 업데이트하고, 필요할 때 호출할 수 있는 사전 학습된 고정 가중치의 '전문가'들이 있는 구조일 것 같았어요. MOE 모델이 그렇게 동작하는 줄 알았거든요. 그러면 사용자는 중요한 부분에서 큰 가중치를 쓸 수 있게 되고요.
저는 앤트로픽 직원이 아니라서 MOE를 어떻게 구현했는지는 모릅니다... 다만 제가 아는 모델들은 그렇게 다른 전문가를 쉽게 '붙일' 수 없어요. 어쩌면 그걸 가능하게 해 주는 비법이 있을 수도 있습니다. 그렇다면 현실성이 있을 수도 있겠지만, 이 논의의 출발점이었던 완전한 버전에 비하면 효과는 훨씬 떨어질 겁니다.
쓸모 있는 LLM이라면 결국 두 가지를 모두 갖추게 될 거라고 봅니다.
장기적으로는 가중치를 지속적으로 업데이트하는 쪽이 더 흥미로운 탐구 대상일 것 같습니다. 하지만 (이것도 쓴 교훈의 희생양이 될 또 하나의 의견일지 모르지만) 이론적으로는 모든 걸 가중치에 담는 게 가능하다 해도, 그게 가장 최적이라고 확신하지는 못하겠어요. 지금은 과적합 없이 자기 작업에서 성능을 끌어올리기에는 비용이 너무 많이 들고 까다롭습니다(예: [0]).
현실적으로(앞으로 몇 달 정도) 올바른 지침과 컨텍스트를 확보하는 것만으로도 능력이 크게 좋아질 겁니다.
[0] https://thinkingmachines.ai/blog/on-policy-distillation/#training-on-new-knowledge-degrades-learned-behavior
진짜 기억이 왜 가중치여야 하죠? 학습하는 주체가 왜 모델이어야 하고, 복합 시스템이면 안 되나요?
일반화 때문입니다. 가중치를 업데이트하면 모델이 패턴을 내재화해서, 저장된 정보를 꺼내 재사용하는 데 그치지 않고 배운 것을 새로운 상황에 적용할 수 있습니다.
저는 지금까지 써 본 모든 하네스에서 자동 메모리 생성을 꺼 뒀습니다. 그래도 Claude Code가 가끔 만들어 내는데, 아마 95%는 지우는 것 같습니다. 만들어지는 메모리는 거의 항상 지금 하고 있는 특정 작업에만 해당하는 내용이거든요. 또 해야 할 작업이라면 그게 유용할 수도 있겠지만 대부분은 그렇지 않아서, 컨텍스트가 어수선해지지 않도록 지웁니다.
그래서 메모리와 관련해 가장 바라는 개선점은 어떤 걸 만들지 더 잘 판단하는 것입니다.
'드리밍'에 관한 부분을 보면서 에이전트 트랜스크립트에 엄청난 정보가 들어 있는데 지금은 활용이 덜 되고 있다는 생각이 들었습니다. 여기서 몇 번 본 조언을 저도 반복하겠습니다. 자기 트랜스크립트를 duckdb에 넣고(claude code가 10분 정도면 그 파이프라인을 만들어 줍니다) 데이터 분석을 해 보세요. 어디서 시작할지 모르겠다면 몇 가지 아이디어가 있습니다. 도구 호출 실패를 살펴보고 흔한 실패를 막을 수 있는지 보기, 캐시 미스가 큰지 그리고 원인이 무엇인지 확인하기, 메인 스레드와 서브 에이전트를 나눠 시간에 따른 여러 효율 지표(달러당 토큰, 토큰당 코드 줄 수 등) 살펴보기 같은 것들입니다. 저는 이런 것부터 시작했고, 몇 가지 단서를 따라가다 흥미로운 통찰을 얻었습니다. 예를 들어 제가 Opus 5.5 / Sol 6.1에게 작업을 너무 잘게 쪼개서 시키는 경향이 있다는 징후를 발견했습니다. 이 모델들은 예전 모델보다 한 번에 더 많은 일을 처리할 수 있는데, 저는 그걸 제대로 활용하지 못하고 있었던 거죠.
저도 늘 똑같은 조언을 합니다. 메모리를 끄는 게 에이전트를 쓸 때 '분당 WTF 횟수'를 줄이는 가장 좋은 방법 중 하나였어요.
저도 Claude에서는 도움보다 짜증이 더 커서 메모리를 꺼 뒀습니다.
하지만 ChatGPT는 켜 두고 있고(주로 모바일로 이동 중에 질문할 때 씁니다) 메모리 경험이 훨씬 낫습니다. 다만 Claude 메모리는 오래전부터 켜 본 적이 없어서 그사이 달라졌을 수도 있겠네요.
그리고 어느 정도 오픈 소스이기도 하고요.
저는 주기적으로 모든 메모리를 정리해 달라고 시키는데, 정리하면서 저한테 질문도 하게 합니다.
그리고 Claude Desktop UI에서는 메모리를 직접 정리합니다.
충분히 잘 돌아갑니다. 드리밍은 메모리가 금세 불어나거나 낡은 내용이 쌓이게 만들어서 마음에 들지 않습니다.
글에 설명이 있는지는 모르겠는데, 그래프(그림 10)를 보면 위키 + 검색이 드리밍보다 낫고, 드리밍은 위키 + 검색 구성에 아주 조금만 보탬이 되는 것 같습니다.
검색이 드리밍보다 훨씬 저렴하다고 가정하면(시간 규모에 따라 다를 수도 있지만요) 꽤 중요한 결과 같아요.
사람을 위해 만든 개념은 정말 같은 과정이 아닌 이상 기계에 써서는 안 됩니다. Claude는 쉬지도 않고, 생각하지 않는 동안 호르몬이나 다른 화학물질의 균형을 맞추지도 않잖아요. 꿈의 한 요소가 정보 정리와 관련 있다고 해서, 정보를 정리하는 게 꿈을 꾸는 건 아니에요.
둘 다 개인의 위치를 바꾼다는 이유로 걷기를 우주 비행이라고 하는 것과 같다고요.
저는 이 경우 그들이 쓴 특정한 논리에는 '드리밍'이라는 용어가 맞아떨어진다고 봅니다.
어떤 비유든 어딘가에서는 어긋난다는 걸 기억하세요.
말씀하신 우주 비행 예시만 해도, 우주비행사는 우주선을 작동시키려고 '우주 유영(space walk)'을 하잖아요. 걷는 건 아니지만 그래도 말이 되죠.
맞아요, 동의합니다. 이런 글을 계속 읽는 건 너무 지칩니다. 앤트로픽에서 교훈을 하나도 얻지 못하고 있거나, 아니면 착각이 너무 심해서 영영 이해하지 못할 것 같아요.
반론입니다. 튜링이 1950년에 발표한 기념비적 논문 Computing Machinery and Intelligence가 지금 하신 논리를 상세히 반박합니다. https://www.hec.edu/sites/default/files/documents/Computing%20Machinery%20and%20Intelligence%20by%20Alan%20Turing.pdf
저는 memory-prune이라는 스킬을 쓰는데, 하는 일은 자동으로 만들어진 메모리 하나를 가져다가 살려 둘 가치가 있는지 평가하고, 코드 주석, 규칙, 프로젝트의 AGENTS.md 파일, 전역 AGENTS.md/CLAUDE.md 파일 중 어디에 저장할지 정하는 것뿐입니다. 아니면(그리고 가장 자주 고르는 선택지인데) 아예 저장하지 않고 삭제하죠.
흠, 이건 일종의 회상을 위한 메모리 통합 같네요. 메모리를 그대로 둔 채 코드베이스 파일 안에 그 메모리 항목을 가리키는 포인터(회상 포인터)를 자동으로 만들어 두면 어떨까요? 도구 결과에 그 포인터가 나타날 때마다 메모리를 에이전트 컨텍스트에 주입하는 방식으로요. 효과가 비슷하거나 더 좋을지 궁금합니다.
그 스킬을 공유해 주시면 정말 관심 있습니다. 메모리 관리는 제멋대로 놔두면 너무 자주 감당이 안 되는 상태가 되어서, 늘 개선할 방법을 찾고 있거든요.
가장 큰 문제는 메모리가 현재 프로젝트에 한정된다는 점입니다. 저는 프로젝트를 자주 옮겨 다니고, 프로젝트 간 맥락을 더 주려고 상위 디렉터리에서 세션을 시작하기도 하거든요.
지금까지 찾은 가장 유용한 메모리는 지난 세션의 트랜스크립트입니다. 에이전트 하나만이 아니라 여러 에이전트(cursor와 claude 등)에 걸쳐서요. 현재 프로젝트에 한정되지도 않고요. 그래서 저는 이전 세션 트랜스크립트를 전부 읽고 서브 에이전트에서 유용한 정보를 찾아 컨텍스트로 불러오는 스킬을 씁니다.
일상 대화에서 '우리 지난주에 X 얘기했잖아' 하는 것과 거의 같습니다. 무엇을 적어 두어야, 즉 메모리에 저장할 가치가 있는지 항상 알 수는 없으니까요. 결국 사후에 돌아보는 쪽이 이깁니다. 물론 Claude가 트랜스크립트를 30일 뒤에 지우기 때문에 보관 기간을 늘려야 했습니다. 제 머릿속 기억보다 훨씬 짧은 기간이니까요.
세룰리안 차트로 보여 준 진행 상황을 보니 오히려 '메모리 없음' 쪽으로 마음이 크게 기웁니다.
오래 도는 에이전트에서 제가 가장 피하고 싶은 건 변동성입니다. 빠르게 한쪽이든 다른 쪽이든 쏠리게 만드는 건 평균적인 경우에는 바람직하지 않아요. 적어도 저한테는요.
그 차트에서는 '메모리 없음' 실행도 해내지 못했습니다. 참고할 자료로는 부족하지만, 제가 읽기에는 메모리를 엉성하게 구현하면 상황이 나빠지고 제대로 구현하면 좋아지는 것 같아요(...포켓몬에서는요).
신기하게도 이건 사람에게도 해당하는 것 같습니다. '드리밍'은 과거에 겪은 어려움에 대한 자신의 가정을 스스로 의심하게 만들거든요. 아주 도움이 되는 치료 과정처럼 들립니다.
(다만 드리밍이라는 말이 딱 맞는지는 잘 모르겠어요. 메모를 실제 기록과 교차 대조했으니까요! 정말 엄밀한 '꿈꾸는 자'네요 ㅋㅋ)