에이전트 메모리의 구성 요소
TMThttps://www.anthropic.com/research/components-of-agent-memory
쇠렌 키르케고르는 삶은 뒤돌아볼 때만 이해할 수 있지만, 앞을 향해 살아야 한다고 썼습니다. 저희도 AI 에이전트의 메모리를 설계하면서 비슷한 딜레마에 부딪혔습니다.
사람은 살아가는 동안 끊임없이 기억을 부호화합니다. 여기서 중심 역할을 하는 것이 해마입니다. 해마는 경험을 그 순간에 포착하므로 기억이 빠르게 형성되고 곧바로 꺼내 쓸 수 있습니다. 하지만 장기적인 지식으로 공고화되는 것은 일부 경험뿐입니다.
이런 공고화의 상당 부분은 뇌가 오프라인 상태일 때 일어나는 것으로 보입니다. 잠을 자는 동안, 그리고 조용히 쉬는 동안 해마는 최근의 경험을 재생합니다. 이 과정에서 경험이 점차 정제되어 신피질에 통합되는 것으로 여겨집니다. 신피질은 우리가 흔히 지식이라고 부르는 것 대부분을 저장하는 뇌 부위입니다.
에이전트 메모리도 이와 비슷하게 일을 나눌 수 있습니다. 에이전트는 작업의 상당 부분을 로그나 대화 기록(transcript)으로 남깁니다. Letta와 UC 버클리의 연구자들은 모델이 상호작용 사이의 유휴 시간을 활용해 기존 컨텍스트를 다시 정리하는 방법으로 수면 시간 연산(sleep-time compute)을 제안했습니다. 같은 아이디어를 활용하면 에이전트는 로그를 되돌아보면서 실수를 바로잡거나 새로운 노트와 표현을 만들어 메모리를 정리할 수 있습니다. 이 과정은 흔히 꿈꾸기(dreaming)라고 부릅니다(그림 1).
저희는 Claude에게 효과적인 메모리를 주는 데 꿈꾸기가 유용한 도구라는 사실을 확인했습니다. 이 글에서는 저희가 에이전트 메모리를 어떻게 생각하게 되었는지 공유하고, 꿈꾸기 활용을 포함해 에이전트 메모리를 탐구하는 데 사용한 여러 평가를 살펴보면서 각 구성 요소가 메모리 정리에 어떤 역할을 하는지 설명합니다.
Claude는 꿈꾸기로 메모리를 정리할 수 있습니다. 꿈꾸기를 통해 실수를 바로잡거나, 노트를 만들거나, 새로운 메모리 표현을 구축하거나, 앞으로의 세션에 미리 로드할 내용을 정할 수 있습니다.
메모리 노트
저희가 말하는 "에이전트 메모리"는 Claude가 사용자와의 상호작용이나 맡은 작업 같은 경험에서 얻은 지식으로, 나중에 읽을 수 있는 컨텍스트로 저장되어 세션이 바뀌어도 유지되는 것을 뜻합니다. 모델이 학습하거나 컨텍스트를 관리하는 다른 방식은 여기에 포함하지 않습니다. 예를 들어 가중치(학습 중에 정해지는 내부 매개변수)의 변화, 인컨텍스트 학습(대화 하나 안에서 얻는 지식), 컴팩션(Claude가 새 컨텍스트 창에서 작업을 이어 갈 수 있도록 이전 턴을 대신하는 요약을 직접 작성하는 것)은 제외합니다.
사람의 뇌에서는 경험 전후나 경험하는 도중에 분비되는 화학 신호가 어떤 기억을 중요하다고 표시할 수 있습니다. 표시된 기억은 오프라인 시간 동안 표시되지 않은 기억보다 더 자주 재생되는 경향이 있습니다. 재생(replay)이라고 부르는 이 과정은 기억을 안정시키고 장기 기억에 통합하는 데 도움을 줍니다.
마찬가지로 Claude도 세션 로그에서 중요한 사건이 일어날 때 태그를 붙여 나중에 쉽게 찾을 수 있게 하거나, 메모리 노트 폴더 같은 메모리 저장소에 기록할 수 있습니다(그림 2). 하지만 다음에 무슨 일이 일어날지 모르는 상태에서, Claude는 그 순간에 무엇이 중요한지 어떻게 알 수 있을까요?
Claude는 메모리에 노트를 기록할 수 있습니다.
메모리는 미래에 무엇이 필요할지에 대한 예측일 수 있습니다
메모리는 때로 예측입니다. 에이전트가 규칙을 기록한다는 것은, 그 규칙이 설명하는 패턴이 다시 쓸모 있을 것이라고 예측하는 것입니다. 예를 들어 검증된 사실을 기록하는 것은, 앞으로의 세션에서 에이전트가 그 사실을 다시 확인하지 않고 믿고 쓰고 싶어 할 것이라는 예측입니다. 시간이 지나면서 Claude는 이런 예측을 훨씬 잘하게 되었습니다.
Continual Learning Bench(CL-Bench) 1.0의 과제 하나를 예로 들어 보겠습니다. 이 벤치마크는 에이전트가 메모리를 활용해 장기 과제를 해결하는 능력을 측정합니다. 그중 한 과제에서는 Claude가 데이터베이스에서 정보를 찾아 일련의 질문에 답해야 합니다. Claude가 답을 내면 정답을 알려 주고, Claude는 이후 질문에 답하는 데 도움이 될 메모리를 기록할 수 있습니다.
여기서 메모리는 학습 루프를 뒷받침할 수 있습니다. Claude가 질문을 틀리면 그 실패를 기록하고, 무엇이 잘못됐는지에 대한 가설을 세우고, 그 가설을 검증한 다음, 알아낸 것을 앞으로 답하는 방법에 대한 규칙으로 바꿀 수 있습니다.
저희는 Claude Managed Agents로 CL-Bench 1.0 과제를 실행했습니다. Claude는 매 질문을 새 세션에서 시작했는데, 예외가 하나 있었습니다. 세션이 바뀌어도 유지되는 메모리 디렉터리에서 파일을 가져올 수 있었습니다.
모델마다 스스로 학습 루프를 만드는 데 성공한 정도가 달랐습니다. Claude Sonnet 4.6은 답이 왜 틀렸는지에 대한 가설을 세우는 데까지 갔습니다. Sonnet 4.6의 메모리 디렉터리에는 파일이 여기저기 흩어져 있었고, 파일마다 검증하지 않은 추측이 여러 개 나열되어 있었습니다.
CL-Bench 데이터베이스 과제에서 모델별로 메모리 사용 시와 상태 없는 기준선을 비교한 결과입니다.
Claude Opus 4.7은 노트를 참조 문서 하나로 통합하고, 어떤 사실을 확인했고 어떤 사실이 아직 확인되지 않았는지 표시하기 시작했습니다. Claude Sonnet 5는 채점기가 확인한 답에는 확인됨으로 표시하고, 틀린 답에는 정정 내용을 기록했습니다.
Claude Opus 5는 이 모델들 중 처음으로 루프를 완성했습니다. Opus 5가 남긴 항목 대부분에는 규칙(그리고 그 규칙이 맞다는 것을 어떻게 알았는지), 이전 질문에 대한 답, 그리고 도중에 발견한 함정에 대한 분명한 경고가 들어 있었습니다(그림 3).
Opus 5처럼 Claude Opus 5.5와 Claude Sonnet 5.5도 루프를 완성했고, 메모리를 활용해 앞으로의 질문에 가장 잘 답하는 방법에 관한 검증된 규칙을 남겼습니다. 메모리를 쓸 때 두 모델의 점수는 Opus 5와 비슷했지만, 메모리 없이 측정한 기준 성능은 조금 더 높았습니다.
Claude는 무엇이 중요한지 판단하는 법을 익혔습니다
저희는 Claude가 메모리에 무엇을 저장할지 판단하는 능력을 시험하기 위해 포켓몬스터 레드를 플레이하는 능력도 평가했습니다. 이 게임은 Claude가 복잡한 장기 과제를 헤쳐 나가야 하는 게임입니다. 각 실행을 시작할 때 모델마다 플레이하는 동안 읽고 쓸 수 있는 메모리 파일 폴더를 주었습니다(그림 4).
저희는 Claude Sonnet 3.7과 Claude Fable 5가 각각 게임을 약 1만 스텝 진행했을 때의 메모리 폴더를, 모델당 한 번의 실행씩 비교했습니다. 눈에 띄는 핵심 차이는 각 모델이 무엇을 기억할 가치가 있다고 여겼는지였습니다. Sonnet 3.7은 모든 것이 중요할 수 있다고 가정하고 가리지 않고 메모리에 기록했습니다. Sonnet 3.7의 메모리 폴더에는 마주친 일들의 기록이 쌓여 있었는데, 치른 배틀, 찾은 아이템, 만난 NPC마다 파일을 따로 만든 경우가 많았습니다. 결국 Sonnet 3.7은 폴더 225개에 메모리 파일 413개를 작성했고, 배지는 하나를 얻었습니다(배지는 플레이어가 게임을 얼마나 진행했는지 보여 줍니다).
반면 Fable 5는 폴더 두 개에 파일 아홉 개, 그리고 최상위에 global.md라는 파일 하나를 작성했고, 배지를 네 개 얻었습니다.
포켓몬을 플레이하는 동안 Sonnet 3.7과 Fable 5가 만든 메모리 디렉터리를 비교한 그림입니다.
Sonnet 3.7의 방식이 문제가 된 주된 이유는 포켓몬의 게임 상태가 끊임없이 바뀌기 때문입니다. Sonnet 3.7이 남긴 상세한 기록은 계속해서 낡은 정보가 되었습니다. 그 결과 게임이 진행될수록 Claude는 게임을 플레이하기보다 메모리를 뒤지는 데 더 많은 시간과 자원을 써야 했습니다. 예를 들어 1만 스텝 무렵 Sonnet 3.7은 "마스터" 메모리 파일을 담을 네 번째 폴더를 만들기 시작했습니다. 이후 17스텝 동안 파일 여섯 개를 만들고 다른 파일 아홉 개를 지웠으며, 게임 안에서는 아무 행동도 하지 않았습니다.
Fable 5는 게임이 명시적으로 알려 주지 않는 것에 메모리를 썼습니다. 플레이어가 가진 돈이나 지도상의 위치처럼 Sonnet 3.7이 메모리에 기록한 정보 중 일부는 매 턴 화면에서 읽을 수 있으므로, 저장해 봐야 중복일 뿐입니다. 반대로 전략, 계획, 검증된 규칙에 관한 메모리 파일은 Claude가 직접 알아내야만 존재하고, Claude가 기록하지 않으면 사라집니다.
Fable 5는 이에 맞게 메모리를 정리했습니다. global.md 파일은 대시보드 역할을 하며 현재 목표, 체육관(배지를 얻는 도전 장소)을 공략하기 위해 미리 써 둔 계획, 그리고 메모리 사용에 관한 모델 자신의 규칙을 담고 있었습니다. locations 폴더에는 특정 도로를 지나가기 위한 계획이, gameplay 폴더에는 게임이 어떻게 돌아가는지 알아낸 내용을 바탕으로 한 전략이 들어 있었습니다. 예를 들어 몬스터볼을 일곱 번 연속으로 던졌는데도 잉어킹(가장 잡기 쉬운 포켓몬 중 하나)을 잡지 못하자, Claude는 이렇게 기록했습니다. "볼이 3번 이상 연속으로 실패하면 타이밍을 바꿀 것(메뉴 단계 사이에 '대기' 입력을 추가로 넣기). 이렇게 하자 바로 잡혔음."
훨씬 작은 메모리 폴더로도 Fable 5는 Sonnet 3.7보다 게임을 훨씬 멀리 진행했습니다. Opus 5.5도 비슷한 방식을 택했습니다. 현재 목표와 다음 단계를 기록한 작은 메모리 노트 폴더를 유지하면서 플레이하는 동안 노트를 고쳐 썼고, 게임을 끝까지 클리어했습니다.
Claude가 메모리를 기록하도록 이끌기
저희는 Claude에게 메모리가 무엇을 위한 것인지는 알려 주되, 어떻게 쓰는지는 알려 주지 않는 편이 도움이 된다는 사실을 확인했습니다. CL-Bench에서는 메모리 폴더를 쓸 수 있다고만 Claude에게 알려 주었습니다. Opus 4.7과 Opus 5는 이런 일반적인 안내만으로도 메모리를 효과적으로 활용했고, 두 모델 모두 성능이 눈에 띄게 올랐습니다(그림 3).
저희는 모델에게 메모리에 무엇을 기록해야 하는지 구체적인 규칙을 주는 방법도 시험했는데, 테스트마다 규칙을 하나씩 주었습니다. 그리고 각 규칙이 있을 때 모델이 메모리로 얻은 이득과 규칙이 없을 때 얻은 이득을 비교했습니다. "실패만 기록하라"는 규칙을 주자 Opus 5와 Opus 4.7 모두 메모리가 주던 성능 향상의 상당 부분을 잃었습니다(그림 5, 오른쪽). 더 강한 모델일수록 미리 고정된 규칙을 정해 주기보다 무엇이 중요한지 스스로 판단하게 두는 편이 더 효과적이었고, 그런 규칙은 오히려 성능을 떨어뜨릴 수 있었습니다.
왼쪽: CL-Bench 데이터베이스 과제에서 메모리 사용을 이끄는 프롬프트가 있을 때와 없을 때의 Sonnet 4.6. 오른쪽: 실패만 기록하라고 지시했을 때 모델별로 메모리에서 얻는 이득이 얼마나 달라졌는지 보여 줍니다.
또한 이렇게 이끌어 주는 방식이 이전 모델에 가장 큰 도움이 된다는 점도 발견했습니다. 예를 들어 Sonnet 4.6은 메모리 디렉터리의 파일을 읽지 않는 경우가 많았고, 답이 왜 틀렸는지에 대한 가설을 검증하지도 못했습니다.
이 경우 답하기 전에 메모리 파일을 읽고, 그다음 가설을 명시적으로 검증하라고 프롬프트로 지시하자 벤치마크 점수가 거의 두 배로 올랐습니다(그림 5, 왼쪽). Sonnet 5는 이를 스스로 합니다. 지시하지 않아도 10번 중 9번은 답하기 전에 메모리를 읽었습니다. 반면 Sonnet 4.6은 그 비율이 절반에도 못 미쳤습니다.
최신 Claude 모델에는 보통 사람이 요청하거나 분명히 기억할 가치가 있는 일이 생겼을 때 메모리 노트를 만들라는 간단한 안내만 주고, 그 판단은 Claude에게 맡깁니다.
꿈꾸기로 메모리를 바로잡을 수 있습니다
Claude는 세션 안에서 중요하다고 판단한 것을 바탕으로 메모리를 기록합니다. 그래서 처음부터 틀렸거나 환경이 바뀌면서 어긋나게 된 노트를, 나중 세션의 Claude가 읽고 그대로 믿어 버릴 수 있습니다.
꿈꾸기는 Claude가 노트를 원래 대화 기록과 대조해 검증할 수 있는 방법입니다(그림 6). 저희는 Claude가 메모리용 디렉터리를 마운트한 Managed Agents로 포켓몬을 플레이할 때 그 긍정적인 사례를 보았습니다.
꿈꾸기로 메모리의 실수를 바로잡을 수 있습니다.
게임의 한 구간에서 플레이어는 달맞이산을 통과해야 합니다. 달맞이산은 지도 서쪽에 입구가, 동쪽에 출구가 있는 동굴 지대입니다. 입구 근처에는 함정이 있습니다. 한 방향으로만 내려갈 수 있는 턱인데, 여기서 떨어지면 플레이어는 왔던 도로로 되돌아가고 다시 올라갈 뚜렷한 방법도 없습니다. Claude는 산 입구에 있는 건물인 포켓몬센터를 이정표로 삼고 있었기 때문에, 턱에서 떨어질지 말지는 포켓몬센터가 산의 어느 쪽에 있다고 생각하느냐에 달려 있었습니다.
어느 시점에 Claude는 포켓몬센터가 동쪽에 있다고 (잘못) 기록했습니다. 포켓몬센터에서 나오면서 Claude는 "달맞이산은 내 뒤에 있다"고 말하고, 노트에 "달맞이산 완료"라고 갱신했습니다. 하지만 달맞이산은 Claude 뒤에 있지 않았습니다. 몇 번 행동한 뒤 Claude는 턱을 넘어 떨어졌고, 왔던 도로로 되돌아갔습니다(그림 7). 내비게이션 도구가 이 낙하를 보여 주지 않았기 때문에 Claude는 "서쪽으로 너무 많이 지나쳤다"고 결론 내리고, 자신은 처음부터 맞는 쪽에 있었다고 판단했습니다. 사실은 그렇지 않았습니다.
포켓몬에서 바로잡힌 메모리 노트가 결과를 바꿨습니다. 바로잡히지 않은 노트를 쓴 Claude는 "달맞이산은 내 뒤에 있다"고 말하며 다음 도시로 향하다가 왔던 도로로 되돌아갑니다. 꿈꾸기로 바로잡힌 노트를 쓴 Claude는 "이제 달맞이산 동굴 입구를 찾아 다시 들어가야 한다"고 말하며 동굴로 돌아갑니다.
이어서 저희는 꿈꾸기가 Claude가 이 함정을 피하는 데 도움이 되는지 시험했습니다. 포켓몬센터 위치가 잘못 적힌 메모리 폴더에 꿈꾸기를 실행하자, Claude는 노트를 세션 대화 기록과 대조해 오류를 찾아내고 노트를 고쳐 썼습니다. 대화 기록이 Claude에게 메모리를 검증할 기준이 되는 사실을 제공한 것입니다. 바로잡힌 메모리 노트를 가진 Claude는 곧장 달맞이산으로 돌아갔고, 결국 블루시티에 도착했습니다.
바로잡히지 않은 노트로 진행한 실행에서는 Claude가 그 이전 도로로 세 번이나 떨어졌습니다. 세 번째 실패 뒤 Claude는 "계속 맴도느니 여기서 멈추겠다"고 쓰며 포기한 것처럼 보였습니다. 저희 환경의 자동 응답이 계속하라고 지시했습니다. 그래서 Claude는 계속했고, 회복하고 물건을 보충하려고 산 바로 전 마을인 회색시티까지 되돌아갔습니다. 이 실행은 Claude가 블루시티에 한 번도 도착하지 못한 채 끝났습니다.
꿈꾸기로 메모리가 바로잡히자 Claude는 동굴로 돌아가 다음 도시에 도착합니다. 바로잡히지 않은 노트를 쓴 실행("원본 메모리")은 산을 끝내 넘지 못하고, 메모리 없는 실행도 마찬가지입니다.
꿈꾸기로 새로운 메모리 표현을 만들 수 있습니다
꿈꾸기를 통해 Claude는 메모리를 탐색하는 데 도움이 되는 표현을 만들 수 있습니다(그림 9). Claude가 쓰는 메모리 표현 중 하나는 위키입니다. 위키는 Claude가 작성하고 관리하는 페이지 모음으로, 한 주제에 대해 Claude가 아는 내용을 모으고 다른 노트로 링크합니다. 이 링크는 사실상 Claude에게 지도 역할을 해서, Claude가 메모리를 훑어보고 필요할 때 원하는 기억을 효율적으로 찾을 수 있게 해 줍니다.
꿈꾸기로 메모리 표현을 만들 수 있습니다.
위키 같은 표현은 Claude가 계속 커지는 지식 베이스를 탐색하는 데 도움이 될 수 있습니다. 저희는 5월에 인수한 소프트웨어 회사 Stainless의 내부 문서 모음(파일 약 35만 개, 토큰 약 4억 2,000만 개)을 활용해 메모리 표현으로서 위키가 어떤 이점이 있는지 살펴보았습니다. 이 문서 모음에 관한 질문 25개로 평가 세트를 만들고, Claude에게 문서를 탐색할 검색 도구를 주었습니다. 또한 꿈꾸기를 사용해 이 파일들을 바탕으로 위키를 만들라고 Claude에게 지시했습니다. 128개 세션에 걸쳐 Opus 5 에이전트들에게 파일을 탐색하고, 서로 링크된 위키 페이지를 작성하거나 고치고, 중복을 합치고, 주장을 원본과 대조하라고 지시했습니다.
각 세션은 공유 로그로 작업을 조율하면서 이전 세션의 에이전트들이 이룬 진전 위에 쌓아 올렸습니다. 꿈꾸기를 세션 2개에서 128개로 늘리자, 질문 25개에서 충족한 채점 기준의 비율이 13%에서 48%로 올랐습니다(그림 10).
Claude는 위키를 점진적으로 만듭니다. 처음 위키를 만든 뒤에는 이어지는 꿈꾸기 회차마다 내용을 추가하고, 고치고, 잘라 냅니다. 꿈꾸기 초기에 Claude의 지식은 신입 직원과 비슷해서, 위키만으로 질문에 답하는 능력은 제한적입니다. 꿈꾸기를 많이 할수록 Claude의 지식 지도는 노련한 직원처럼 풍부해집니다. 테스트해 보니 위키는 검색 도구도 함께 쓸 수 있을 때 Claude에게 가장 큰 도움이 되었습니다. 검색과 위키를 모두 썼을 때 Claude의 종합 점수는 위키가 커짐에 따라 54%에서 61%로 올랐고, 검색 도구만 썼을 때는 53%였습니다. 위키만으로 질문에 답했을 때 Claude의 최고 점수는 48%였습니다. 검색과 위키를 함께 쓰면 질문당 토큰도 약 2만 개 절약되었습니다.
가운데: Claude가 연속된 세션에 걸쳐 위키를 만들어 가는 동안, 한 회사의 문서 모음에 관한 질문 25개에서 얻은 점수. 왼쪽과 오른쪽: 세션 2개와 128개를 거친 뒤의 예시 위키로, 점 하나가 페이지 하나이고 선은 서로 링크된 페이지를 잇습니다.
저희는 어떤 종류의 과제에서 Claude가 위키를 가지는 것이 도움이 되는지 시험해 보고 싶었습니다. 이를 위해 Harvey LAB 벤치마크와 어느 합병에 관한 문서 모음을 사용했습니다. 이 벤치마크는 Claude에게 문서 묶음을 주고, 그 내용을 바탕으로 법률 의견서를 작성하게 합니다. 그런 다음 기준 목록에 따라 의견서를 채점합니다. 포켓몬 플레이보다는 조금 덜 흥미로울지 모르지만, 이런 평가 덕분에 위키를 만들어 볼 다양한 문서 모음을 확보할 수 있습니다.
저희는 Claude에게 문서로 위키를 만들라고 지시했습니다. 그런 다음 위키를 활용하는 방식과 파일을 직접 검색하는 방식 양쪽으로 (합병에 관한) 질문에 답하거나 (LAB 벤치마크의) 법률 의견서를 작성하게 했습니다. 한 테스트에서는 합병에 관한 질문 24개를 물었는데(그림 11, 왼쪽), 그중 절반이 넘는 질문은 Claude가 여러 문서에 걸쳐 정보를 찾아야 했고, 상당수는 판단을 내리거나 계산을 해야 했습니다. 이런 항목(빨간 선과 주황 선)에서 Claude는 위키를 참고했을 때 87%, 검색만 썼을 때 73%를 기록했습니다.
각 패널은 채점 항목(왼쪽)과 각 항목을 충족하는 데 필요한 원본 문서(오른쪽)를 보여 줍니다. 왼쪽: 주로 공개 공시 자료를 보고 답할 수 있는, 합병에 관한 질문 24개. 기준의 절반 이상은 여러 문서의 정보를 합쳐야 했습니다. 오른쪽: 위키로 뚜렷한 이득을 얻지 못한 LAB 과제. 기준 대부분을 문서 하나로 충족할 수 있었습니다.
다른 경우에는 위키가 덜 유용했습니다. 한 LAB 과제(그림 11, 오른쪽)에서는 의견서 기준을 문서 하나에서 텍스트 검색으로 찾을 수 있는 경우가 많았고, 위키는 검색에 비해 뚜렷한 성능 향상을 보이지 않았습니다. 또 다른 LAB 과제에서는 위키가 원본 문서보다 더 커졌습니다(그림 12). 보르헤스의 한 문단짜리 단편 「과학의 엄밀함에 관하여」에는 너무 상세해서 그 지도가 나타내는 제국만큼 커져 버린 지도를 만든 지도 제작자들이 나오는데, Claude도 그들처럼 지나치게 상세해서 사실상 아무것도 추상화하지 못한 위키를 만든 것입니다.
위키가 원본 파일보다 더 커졌습니다.
꿈꾸기로 노트를 메모리 계층의 위쪽으로 올릴 수 있습니다
꿈꾸기는 노트를 메모리 계층의 맨 위로 끌어올릴 수도 있고, 에이전트 하네스는 이 노트를 매 세션을 시작할 때 Claude의 컨텍스트에 미리 로드할 수 있습니다(그림 13). 그러면 Claude는 이 노트를 검색할 필요가 없고, 검색할 거리가 있다는 사실조차 몰라도 됩니다.
메모리를 새 세션으로 올리는 일(컨텍스트 주입의 한 형태)은 신중하게 해야 합니다. 주입된 메모리는 귀한 토큰을 소모하고, 잘못된 노트가 모든 세션에 딸려 들어갈 수 있습니다. 노트를 로드한다고 해서 Claude가 그 노트대로 행동한다는 보장도 없습니다. 저희의 Claude Code 문서도 지시 파일이 길어질수록 지시를 따르는 정도가 떨어진다고 경고합니다. 그래서 메모리 계층의 맨 위층은 비교적 작게 유지해야 하고, 여기서 꿈꾸기가 하는 일의 상당 부분은 일부 세부 내용을 계층 아래로 내려보내고 그 자리에 링크를 남겨서 맨 위층을 작게 유지하는 것입니다.
Claude Code의 자동 메모리도 같은 방식으로 주입되는 층을 작게 유지하며, 세션 중에 Claude가 이 층을 관리합니다. Claude는 자동 메모리 전체를 매 세션의 컨텍스트 창에 로드하지 않습니다. MEMORY.md의 처음 200줄 또는 25KB만 로드합니다. 이 앞부분은 색인 역할을 해서, Claude가 무엇을 알고 있고 그것을 어디서 찾을 수 있는지 보여 줍니다.
꿈꾸기는 메모리 계층의 맨 위에 기록할 수 있습니다. 주입 컨텍스트는 모든 세션에 로드되고, 그 아래 층들은 Claude가 필요할 때 읽거나 검색합니다.
꿈꾸기로 메모리를 특정 목표에 맞출 수 있습니다
꿈꾸기는 메모리가 자라는 방향을 정할 수도 있습니다. 예를 들어 Claude Duet 같은 어시스턴트는 돕고 있는 사람을 중심으로 메모리가 정리되어 있을 때 도움을 받는 경우가 많으며, 꿈꾸기는 특정 목표에 맞춰 메모리를 쌓도록 조정할 수 있습니다.
메모리가 자라는 방식을 이끄는 지시는 과제마다 다르며, 어떤 정보가 실제로 중요한지 Claude에게 알려 줍니다. 예를 들어 LAB 벤치마크의 한 과제는 기업 인수를 시뮬레이션하고 계약서 묶음을 제공합니다. 의견서는 계약 조건을 정확히 설명했는지를 기준으로 채점됩니다.
저희는 처음에 위키를 어떻게 쓰는지는 알려 주지 않는 기본적인 위키 생성 지시로 시작했습니다. 이 과제는 계약 조건에 크게 의존했습니다. 위키를 만드는 동안 여러 에이전트가 계약 조건을 정리한 공유 표 하나에 동시에 기록했습니다(그림 14, 왼쪽).
그림 14: 지시를 바꾸기 전과 후에 채점 대상 계약 사실 중 몇 개가 위키에 들어갔는지 보여 줍니다. 왼쪽: 여러 에이전트가 공유 페이지 하나에 기록했고, 사실 57개 중 41개가 남았습니다. 오른쪽: 계약서마다 에이전트 하나가 맡아 각자 페이지를 작성하고 조건을 그대로 인용했으며, 사실 57개가 모두 남았습니다.
그 결과 핵심 사실이 빠진 위키가 만들어졌습니다. 이 위키로 작성한 의견서를 채점해 보니, Claude는 사실 57개 중 41개(72%)만 포함했습니다. 무엇이 잘못됐는지 살펴보니, 에이전트들이 서로의 작업을 덮어쓰는 바람에 공유 표가 계약 조건을 부실하게 요약했고 일부 조건은 아예 빠져 있었습니다.
계약 조건은 위키에서 가장 중요한 부분이었지만, 지시에는 그런 말이 없었습니다. 더 나은 지시를 찾기 위해 저희는 Claude가 자신의 실패를 되돌아보고, 지시를 바꾸자고 제안하고, 위키를 다시 만드는 루프를 돌렸습니다. 이 루프를 통해 Claude는 계약 조건을 충실히 따르는 것이 얼마나 중요한지 알아냈고, 그에 맞게 위키 생성 지시를 고쳐 썼습니다.
위키에서는 계약서마다 에이전트 하나가 작성한 페이지가 따로 생겼고, 각 페이지는 조건을 공유 표에 요약하는 대신 한 글자도 바꾸지 않고 인용했습니다. 이렇게 개선한 위키로 작성한 의견서를 채점하자 충족할 수 있는 기준이 72%에서 100%로 올랐습니다.
꿈꾸기로 세션이 남긴 빈틈을 메울 수 있습니다
Claude가 메모리 노트를 작성할 때는 해당 세션의 컨텍스트만 볼 수 있습니다. 꿈꾸기는 여러 세션을 가로질러 검색하면서 공통된 패턴을 찾거나 반복되는 실수를 바로잡을 수 있습니다.
LAB 벤치마크용 위키를 만들 때(예시는 그림 14 참고), Claude가 아직 만들어지지 않은 페이지로 링크를 거는 경우가 있었습니다. 두 번째 꿈꾸기 회차에서 이런 빈틈이 상당수 메워졌습니다. 한 과제(그림 15)에서 꿈꾸기는 위키 안에 없는 페이지를 가리키는 링크 아홉 개를 찾아내, 같은 문서를 다루는 기존 페이지로 연결을 바꿨습니다. 또한 위키를 개선하기 위해 색인을 포함한 새 페이지 세 개를 추가했습니다.
두 번째 꿈꾸기 회차 전과 후의 위키입니다.
뒤돌아보며 생각하고, 앞을 내다보기
에이전트의 메모리 시스템을 어떻게 설계할지에 대해서는 아직 답이 나오지 않은 질문이 많습니다. 하나는 Claude가 언제 메모리를 만들어야 하느냐입니다. Claude는 작업하는 동안 메모리 저장소(예: 폴더, 파일, 데이터베이스)에 기록할 수 있습니다. 이렇게 하면 중요한 정보를 발생한 그 자리에서 포착하고, 중요한 세부 사항을 이후의 턴이나 세션에서 바로 쓸 수 있습니다. 하지만 그 순간에 노트를 기록하다 보면 Claude의 주의가 본래 작업에서 벗어날 수밖에 없습니다. 반면 꿈꾸기는 메모리 생성을 백그라운드로 미룰 수 있지만, 꿈꾸기의 결과물은 Claude가 곧바로 쓰지 못할 수도 있습니다.
또 다른 질문은 메모리를 어떻게 믿을 수 있는 최신 상태로 유지하느냐입니다. Claude는 잘못된 예측을 하거나, 처음부터 틀린 규칙을 메모리에 기록할 수 있습니다. 환경이 바뀌면서 메모리가 어긋나고 쓸모없어질 수도 있습니다. 꿈꾸기는 이런 실수를 바로잡는 한 가지 방법이지만(그림 8), 연산이 필요합니다. Claude에게 모든 메모리를 계속 확인하라고 지시하는 것은 현실적이지 않을 수 있습니다. 그보다는 바뀔 가능성이 높은 정보에 꿈꾸기를 집중하거나, (예를 들어 메모리에 얼마나 자주 접근하는지를 바탕으로) 꿈꾸기 주기를 세심하게 조정하는 것이 중요할 수 있습니다.
대화 기록 검색을 Claude 메모리의 토대로 삼는 방안도 충분히 고려해 볼 만합니다. 표현(예: 위키)과 검색을 함께 쓰는 방식(그림 10)이 효과적일 때도 있습니다. 하지만 Claude는 메모리 표현을 유지하고 거기에 오류나 환각이 쌓이지 않도록 하는 데 연산을 써야 합니다.
무엇이 중요한지에 대한 Claude의 판단은 나아졌지만, 어떤 모델도 앞으로의 턴에서 무슨 일이 일어날지 정말로 알 수는 없습니다. 꿈꾸기는 Claude가 뒤를 돌아보고, 연산을 들여 메모리를 정리하고, 실수를 바로잡고, 앞으로의 세션이 메모리에 더 쉽게 접근할 수 있게 해 주는 표현을 유지할 기회를 줍니다. 메모리 시스템은 Claude가 더 유능해짐에 따라 발전할 것이며, Claude의 메모리 시스템을 설계하는 일에 대해 저희가 배워야 할 것은 아직 많습니다.