에이전트 메모리의 구성 요소

쇠렌 키르케고르는 삶은 뒤돌아봐야 이해할 수 있지만 살아가는 것은 앞을 향해 할 수밖에 없다고 썼습니다. AI 에이전트의 메모리를 설계할 때도 이와 비슷한 딜레마를 만납니다.

사람은 살아가는 동안 끊임없이 기억을 만들어 냅니다. 이 과정에서 해마가 중심 역할을 합니다. 해마는 경험을 그 순간에 포착하므로 기억이 빠르게 형성되고 곧바로 꺼내 쓸 수 있습니다. 하지만 일부 경험만 장기 지식으로 굳어집니다.

이런 응고(consolidation)는 대부분 뇌가 쉬는 동안 일어나는 것으로 보입니다. 잠을 자거나 조용히 쉴 때 해마가 최근 경험을 다시 재생합니다. 이를 통해 경험이 점차 정제되어 신피질에 통합된다고 여겨집니다. 신피질은 우리가 흔히 지식이라 부르는 것의 대부분을 저장하는 부위입니다.

에이전트 메모리도 비슷한 역할 분담을 활용할 수 있습니다. 에이전트는 작업 내용의 상당 부분을 로그나 트랜스크립트로 남깁니다. Letta와 UC 버클리 연구진은 모델이 상호작용 사이의 유휴 시간에 기존 컨텍스트를 재정리하도록 하는 방법으로 sleep-time compute를 제안했습니다. 같은 아이디어를 적용하면 에이전트가 로그를 돌아보며 실수를 바로잡거나 새로운 노트와 표현을 만들어 메모리를 정리할 수 있습니다. 이 과정을 흔히 dreaming(드리밍)이라고 부릅니다(그림 1).

드리밍은 Claude에게 효과적인 메모리를 갖춰 주는 데 유용한 도구였습니다. 이 글에서는 에이전트 메모리를 어떻게 바라보게 되었는지 소개하고, 드리밍을 비롯해 에이전트 메모리를 탐구하며 사용한 여러 평가와 메모리 정리에서 각 구성 요소가 맡는 역할을 살펴봅니다.

메모리 노트

여기서 "에이전트 메모리"란 Claude가 사용자와의 상호작용이나 맡은 작업 같은 경험에서 얻은 지식 중 세션 사이에 유지되는 것을 말합니다. 나중에 읽을 수 있는 컨텍스트로 저장해 둔 지식입니다. 모델이 배우거나 컨텍스트를 관리하는 다른 방식은 여기에 포함하지 않습니다. 가중치(학습 중 설정되는 내부 파라미터) 변경, 인컨텍스트 러닝(한 대화 안에서 얻는 지식), 컴팩션(Claude가 이전 턴을 요약으로 대체해 새 컨텍스트 윈도우에서 작업을 이어 가게 하는 방식)이 그런 예입니다.

사람의 뇌에서는 경험 전후나 도중에 분비되는 화학 신호가 기억을 중요한 것으로 표시할 수 있습니다. 표시된 기억은 휴식 중에 그렇지 않은 기억보다 더 자주 재생되는 경향이 있습니다. 재생(replay)이라 불리는 이 과정이 기억을 안정시키고 장기 기억에 통합하는 데 도움을 줍니다.

마찬가지로 Claude도 세션 로그에서 중요한 사건이 일어나는 즉시 태그를 달아 두면 나중에 더 쉽게 찾을 수 있고, 메모리 노트 폴더 같은 메모리 저장소에 기록해 둘 수도 있습니다(그림 2). 그런데 다음에 무슨 일이 닥칠지 모르는 그 순간에, Claude는 무엇이 중요한지 어떻게 알 수 있을까요?

메모리는 미래에 무엇이 필요할지에 대한 예측일 수 있습니다

메모리는 때로 하나의 예측입니다. 에이전트가 규칙을 적어 두는 것은 그 규칙이 설명하는 패턴이 앞으로 다시 의미 있으리라 예측한다는 뜻입니다. 예를 들어 검증된 사실을 적어 두는 것은 이후 세션의 에이전트가 그 사실을 다시 확인하지 않고 믿고 쓰고 싶어 하리라는 예측입니다. Claude는 시간이 지나면서 이런 예측을 훨씬 잘하게 되었습니다.

Continual Learning Bench(CL-Bench) 1.0의 한 과제를 보겠습니다. 이 벤치마크는 에이전트가 메모리를 활용해 장기 과제를 해결하는 능력을 측정합니다. 이 과제에서 Claude는 데이터베이스에서 정보를 찾아 일련의 질문에 답해야 합니다. Claude가 답을 내놓으면 정답이 공개되고, Claude는 이후 질문에 도움이 되도록 메모리를 작성할 수 있습니다.

여기서 메모리는 학습 루프를 뒷받침할 수 있습니다. Claude가 문제를 틀리면 실패를 기록하고, 무엇이 잘못됐는지 가설을 세우고, 그 가설을 검증한 뒤, 알아낸 내용을 이후 답변 방식에 대한 규칙으로 바꿀 수 있습니다.

CL-Bench 1.0 과제는 Claude Managed Agents로 실행했습니다. Claude는 질문마다 새 세션에서 시작하되, 한 가지 예외로 세션 간에 유지되는 메모리 디렉터리에서 파일을 불러올 수 있었습니다.

스스로 학습 루프를 만드는 성공 수준은 모델마다 달랐습니다. Claude Sonnet 4.6은 답이 틀린 이유에 대한 가설을 세우는 데까지 갔습니다. 메모리 디렉터리에는 검증되지 않은 추측 여러 개를 나열한 파일이 여기저기 흩어져 있었습니다.

Claude Opus 4.7은 노트를 하나의 참조 문서로 통합하고, 확인한 사실과 아직 확인하지 못한 사실을 구분해 표시하기 시작했습니다. Claude Sonnet 5는 채점기가 확인한 뒤에 각 답을 확인 완료로 표시했고, 틀린 경우에는 정정 내용을 적었습니다.

이 가운데 루프를 처음으로 완성한 모델은 Claude Opus 5였습니다. 항목 대부분에 규칙(그리고 그 규칙이 맞다는 것을 어떻게 알았는지), 이전 질문의 답, 그 과정에서 발견한 함정에 대한 분명한 경고가 담겨 있었습니다(그림 3).

Claude Opus 5.5와 Claude Sonnet 5.5도 Opus 5처럼 루프를 완성해, 메모리로 이후 질문에 가장 잘 답하는 방법에 대한 검증된 규칙을 쌓았습니다. 메모리를 쓴 점수는 두 모델 모두 Opus 5와 비슷했고, 메모리 없이 낸 기준선 성능은 이쪽이 약간 더 높았습니다.

Claude는 무엇이 중요한지 판단하는 법을 익혔습니다

Claude가 메모리에 무엇을 저장할지 판단하는 능력을 보기 위해 포켓몬 레드 플레이도 평가했습니다. 이 게임은 복잡한 장기 과제를 헤쳐 나가야 하는 환경입니다. 각 실행을 시작할 때 모델마다 플레이하는 동안 읽고 쓸 수 있는 메모리 파일 폴더를 하나씩 주었습니다(그림 4).

Claude Sonnet 3.7과 Claude Fable 5가 각각 게임을 약 10,000스텝 진행했을 시점의 메모리 폴더를 한 번씩 비교했습니다. 가장 눈에 띈 차이는 무엇을 기억할 가치가 있다고 보느냐였습니다. Sonnet 3.7은 모든 것이 중요할 수 있다고 보고 가리지 않고 메모리에 적었습니다. 메모리 폴더에는 만난 상황의 기록이 쌓여 있었는데, 치른 전투, 발견한 아이템, 만난 NPC마다 별도 파일이 있는 경우가 많았습니다. 결국 Sonnet 3.7은 225개 폴더에 걸쳐 메모리 파일 413개를 작성했고 배지는 1개를 얻었습니다(배지는 플레이어의 게임 진행도를 나타냅니다).

반면 Fable 5는 폴더 2개에 파일 9개, 그리고 최상위 파일 global.md 하나를 작성했고 배지는 4개를 얻었습니다.

Sonnet 3.7의 방식이 문제였던 주된 이유는 포켓몬의 게임 상태가 끊임없이 바뀐다는 점입니다. Sonnet 3.7이 남긴 상세한 기록은 계속 낡아 갔습니다. 그 결과 Claude는 게임이 진행될수록 게임을 하기보다 메모리를 뒤지는 데 더 많은 시간과 자원을 써야 했습니다. 예를 들어 10,000스텝 무렵 Sonnet 3.7은 "마스터" 메모리 파일의 네 번째 폴더를 시작했습니다. 이후 17스텝 동안 파일 6개를 만들고 9개를 삭제했으며, 게임에서는 아무 행동도 하지 않았습니다.

Fable 5는 게임이 명시적으로 알려 주지 않는 것에 메모리를 썼습니다. Sonnet 3.7이 메모리에 적은 정보 중 플레이어의 소지금이나 맵상 위치 같은 것은 매 턴 화면에서 읽을 수 있으므로 저장해 봐야 중복입니다. 반면 전략, 계획, 검증된 규칙에 관한 메모리 파일은 Claude가 직접 알아내야만 존재하고, 적어 두지 않으면 사라집니다.

Fable 5는 이런 기준으로 메모리를 구성했습니다. global.md 파일은 대시보드 역할을 하며 현재 목표, 체육관(배지를 따는 도전 과제) 공략을 위해 미리 써 둔 계획, 메모리 사용에 대한 모델 자신의 규칙을 담았습니다. locations 폴더에는 특정 경로를 지나는 계획이, gameplay 폴더에는 게임 작동 방식에 대해 알게 된 내용을 바탕으로 한 전략이 들어 있었습니다. 예를 들어 몬스터볼 7개를 연달아 던지고도 가장 잡기 쉬운 포켓몬 중 하나인 잉어킹을 잡지 못하자, Claude는 이렇게 적었습니다. "3번 이상 연속 실패하면 타이밍을 바꿔 볼 것(메뉴 단계 사이에 'wait' 입력을 추가). 이렇게 하자마자 잡혔음."

Fable 5는 훨씬 작은 메모리 폴더로 Sonnet 3.7보다 게임을 훨씬 더 멀리 진행했습니다. Opus 5.5도 비슷한 접근을 택했습니다. 현재 목표와 다음 단계를 추적하는 작은 메모리 노트 폴더를 두고 플레이하면서 계속 고쳐 썼고, 게임을 클리어했습니다.

Claude가 메모리를 쓰도록 유도하기

Claude에게 메모리가 무엇을 위한 것인지는 알려 주되, 어떻게 쓸지는 알려 주지 않는 편이 도움이 된다는 것을 확인했습니다. CL-Bench에서는 메모리 폴더를 쓸 수 있다고만 알려 주었습니다. 이 정도의 일반적인 안내만으로도 Opus 4.7과 Opus 5는 메모리를 효과적으로 활용했고, 두 모델 모두 성능이 눈에 띄게 올랐습니다(그림 3).

메모리에 무엇을 써야 하는지 구체적인 규칙을 주는 실험도 했습니다. 테스트 한 번에 규칙 하나씩 적용하고, 규칙이 있을 때와 없을 때 메모리로 얻는 성능 향상폭을 모델별로 비교했습니다. 규칙을 "실패만 기록하라"로 정하자 Opus 5와 Opus 4.7 모두 메모리로 얻던 성능 향상의 상당 부분을 잃었습니다(그림 5, 오른쪽). 더 강력한 모델에는 미리 정한 고정 규칙보다 무엇이 중요한지 스스로 판단할 자유를 주는 편이 더 효과적이었고, 그런 규칙은 오히려 성능을 떨어뜨릴 수 있었습니다.

유도가 가장 도움이 된 쪽은 이전 세대 모델이었습니다. 예를 들어 Sonnet 4.6은 메모리 디렉터리의 파일을 읽지 않는 경우가 많았고, 답이 틀린 이유에 대한 가설도 검증하지 않았습니다.

이때 답하기 전에 메모리 파일을 읽고 가설을 명시적으로 검증하라고 프롬프트로 안내하자 벤치마크 점수가 거의 두 배가 되었습니다(그림 5, 왼쪽). Sonnet 5는 이를 스스로 합니다. 따로 시키지 않아도 10번 중 9번은 답하기 전에 메모리를 읽었습니다. Sonnet 4.6은 절반도 읽지 않았습니다.

최신 Claude 모델에는 보통 사용자가 요청할 때나 분명히 기억할 가치가 있는 일이 있을 때 메모리 노트를 만들라는 간단한 안내만 주고, 나머지 판단은 Claude에게 맡깁니다.

드리밍으로 메모리를 바로잡을 수 있습니다

Claude는 세션 중에 중요하다고 판단한 내용을 메모리에 쓰기 때문에, 처음부터 틀렸거나 환경이 바뀌면서 어긋난 노트를 이후 세션의 Claude가 읽고 그대로 믿어 버릴 수 있습니다.

드리밍은 Claude가 노트를 원본 트랜스크립트와 대조해 검증하는 수단이 됩니다(그림 6). Claude가 메모리용 디렉터리를 마운트한 Managed Agents로 포켓몬을 플레이할 때 이를 보여 주는 긍정적인 사례가 있었습니다.

게임의 한 구간에서 플레이어는 달맞이동산(Mt. Moon)을 통과해야 합니다. 이곳은 맵 서쪽에 입구가, 동쪽에 출구가 있는 동굴입니다. 입구 근처에는 함정이 있습니다. 한 방향으로만 내려갈 수 있는 절벽으로, 떨어지면 왔던 길로 돌아가게 되고 다시 올라갈 방법이 뚜렷하지 않습니다. Claude는 산 입구에 있는 건물인 포켓몬 센터를 랜드마크로 삼았으므로, 절벽에서 떨어지느냐는 Claude가 포켓몬 센터가 산의 어느 쪽에 있다고 생각하느냐에 달려 있었습니다.

한번은 Claude가 포켓몬 센터가 동쪽에 있다고 (잘못) 적어 두었습니다. 포켓몬 센터에서 나온 뒤 "달맞이동산은 내 뒤에 있다"고 선언하고 노트를 "달맞이동산 완료"로 갱신했습니다. 하지만 달맞이동산은 뒤에 있지 않았습니다. 몇 번 행동한 뒤 Claude는 절벽 아래로 떨어져 왔던 길로 돌아왔습니다(그림 7). 내비게이션 도구에는 낙하가 표시되지 않았기 때문에 Claude는 "서쪽으로 너무 많이 왔다"고 결론짓고 자신은 줄곧 올바른 쪽에 있었다고 판단했습니다. 그렇지 않았습니다.

이어서 드리밍이 Claude가 이 함정을 피하는 데 도움이 되는지 실험했습니다. 포켓몬 센터의 위치가 잘못 적힌 메모리 폴더에 드리밍을 실행했더니, Claude는 노트를 세션 트랜스크립트와 대조해 오류를 찾아내고 다시 썼습니다. 트랜스크립트가 메모리를 검증할 기준이 되는 정답 역할을 한 것입니다. 바로잡은 메모리 노트를 가진 Claude는 곧장 달맞이동산으로 다시 들어갔고 마침내 블루 시티(Cerulean City)에 도착했습니다.

바로잡지 않은 노트로 실행했을 때는 Claude가 그 앞의 길로 세 번 떨어졌습니다. 세 번째 실패 후 Claude는 포기한 듯 "계속 반복하느니 멈추겠다"고 적었습니다. 하지만 실험 환경의 자동 응답이 계속 진행하라고 지시했습니다. 그래서 Claude는 계속 나아갔고, 산 앞 마을인 회색시티(Pewter City)까지 돌아가 회복하고 물품을 보충하려 했습니다. 이 실행은 Claude가 블루 시티에 한 번도 닿지 못한 채 끝났습니다.

드리밍으로 새로운 메모리 표현을 만들 수 있습니다

드리밍을 쓰면 Claude는 메모리를 탐색하는 데 도움이 되는 표현을 구축할 수 있습니다(그림 9). Claude가 쓰는 메모리 표현 중 하나가 위키입니다. Claude가 작성하고 관리하는 페이지 모음으로, 하나의 주제에 관해 Claude가 아는 내용을 모으고 다른 노트와 연결합니다. 이 링크는 사실상 Claude가 메모리를 훑으며 필요한 기억을 효율적으로 찾을 수 있는 지도 역할을 합니다.

위키 같은 표현은 Claude가 계속 커지는 지식 베이스를 탐색하는 데 도움이 됩니다. 위키가 메모리 표현으로서 갖는 이점은 Anthropic이 5월에 인수한 소프트웨어 회사 Stainless의 내부 문서 코퍼스(파일 약 35만 개, 약 4억 2천만 토큰)로 살펴보았습니다. 이 코퍼스에 대한 질문 25개로 평가 세트를 만들고, Claude에게 탐색용 검색 도구를 주었습니다. 또한 드리밍으로 이 파일들을 바탕으로 위키를 구축하게 했습니다. 128개 세션에 걸쳐 Opus 5 에이전트에게 파일을 탐색하고, 서로 연결된 위키 페이지를 작성하거나 수정하고, 중복을 병합하고, 주장을 원본과 대조해 확인하도록 프롬프트로 지시했습니다.

각 세션은 앞선 세션에서 에이전트가 이룬 진척을 이어받았고, 공유 로그로 작업을 조율했습니다. 드리밍을 2개 세션에서 128개 세션으로 늘리자 25개 질문의 성능은 채점 기준 충족률 기준으로 13%에서 48%로 올랐습니다(그림 10).

Claude는 위키를 점진적으로 구축합니다. 초기 위키를 만든 뒤에는 이후 드리밍 라운드에서 내용을 추가하고, 편집하고, 가지치기합니다. 드리밍 초기 라운드에서 Claude의 지식은 신입 사원 수준이라, 위키만으로 질문에 답하는 능력은 제한적입니다. 드리밍을 거듭할수록 지식 지도는 풍부해져 숙련된 직원의 지식에 가까워집니다. 실험에서는 위키와 함께 검색 도구도 쓸 수 있을 때 위키가 Claude에게 가장 큰 도움이 되었습니다. 검색과 위키를 함께 쓴 Claude의 종합 점수는 위키가 커짐에 따라 54%에서 61%로 올랐고, 검색 도구만 쓸 때는 53%였습니다. 위키만 쓰고 질문에 답했을 때 Claude의 최고 점수는 48%였습니다. 검색과 위키를 함께 쓰면 질문당 토큰도 약 2만 개 절약됐습니다.

Claude에게 위키가 있으면 어떤 종류의 작업에서 이득을 보는지도 확인하고 싶었습니다. 이를 위해 Harvey LAB 벤치마크와 합병 관련 문서 모음을 사용했습니다. 이 벤치마크는 Claude에게 문서 묶음을 주고 그 내용을 바탕으로 법률 브리프를 작성하게 합니다. 그런 다음 브리프를 기준 목록에 따라 채점합니다. 포켓몬 플레이보다 재미는 좀 덜할지 모르지만, 이 평가들 덕분에 위키를 구축할 다양한 문서 모음을 확보할 수 있습니다.

Claude에게 문서로 위키를 구축하게 한 뒤, 위키를 보고 답하는 경우와 파일을 직접 검색해 답하는 경우 모두에서 (합병에 대한) 질문에 답하거나 (LAB 벤치마크의) 법률 브리프를 작성하게 했습니다. 한 테스트에서는 합병에 대해 24개 질문을 했는데(그림 11, 왼쪽), 절반 넘는 질문이 여러 문서에 흩어진 정보를 찾아야 했고, 상당수는 판단이나 계산도 필요했습니다. 이런 문항(빨간 선과 주황 선)에서 Claude는 위키를 참고했을 때 87%, 검색만 썼을 때 73%를 기록했습니다.

위키가 덜 유용했던 경우도 있습니다. 한 LAB 과제(그림 11, 오른쪽)에서는 브리프의 기준을 문서 하나에서 텍스트 검색만으로 찾을 수 있는 경우가 많아, 위키는 검색 대비 뚜렷한 성능 향상을 보이지 않았습니다. 또 다른 LAB 과제에서는 위키가 문서 자체보다 더 커졌습니다(그림 12). 보르헤스의 한 단락짜리 단편 「과학의 엄밀성에 대하여」에서 제국만큼 커질 정도로 상세한 지도를 그린 지도 제작자들처럼, Claude는 사실상 아무것도 추상화하지 못한 극도로 상세한 위키를 만든 셈입니다.

드리밍으로 노트를 메모리 계층의 위쪽으로 올릴 수 있습니다

드리밍은 노트를 메모리 계층의 최상단으로 띄워 올릴 수도 있고, 에이전트 하니스는 이를 매 세션 시작 시 Claude의 컨텍스트에 미리 불러올 수 있습니다(그림 13). 그러면 Claude는 노트를 검색할 필요가 없고, 검색할 만한 것이 있다는 사실을 알 필요조차 없습니다.

메모리를 새 세션으로 끌어올리는 것(컨텍스트 주입의 한 형태)은 신중하게 해야 합니다. 주입된 메모리는 귀중한 토큰을 차지하고, 잘못된 노트는 모든 세션으로 이어질 수 있습니다. 노트를 불러온다고 Claude가 반드시 그대로 따르는 것도 아닙니다. Claude Code 문서에서도 지침 파일이 길어질수록 준수율이 떨어진다고 경고합니다. 따라서 메모리 계층의 최상위 층은 비교적 작게 유지해야 하며, 여기서 드리밍이 하는 일의 상당 부분은 일부 세부 내용을 계층 아래로 옮기고 링크만 남겨 두어 이를 유지하는 것입니다.

Claude Code의 자동 메모리도 같은 방식으로 주입 층을 작게 유지하며, 세션 중에 Claude가 이를 관리합니다. Claude는 자동 메모리 전체를 매 세션의 컨텍스트 윈도우에 불러오지 않고, MEMORY.md의 처음 200줄 또는 25KB만 불러옵니다. 이 헤더는 색인 역할을 하며, Claude가 무엇을 알고 있고 그것을 어디서 찾을 수 있는지 보여 줍니다.

드리밍으로 메모리를 특정 목표에 맞출 수 있습니다

드리밍은 메모리가 자라는 방향을 조정할 수도 있습니다. 예를 들어 Claude Duet 같은 어시스턴트는 도움을 주는 사람을 중심으로 정리된 메모리가 있으면 이점이 큰 경우가 많은데, 드리밍을 조정하면 특정 목표에 맞게 메모리를 구축할 수 있습니다.

메모리가 자라는 방식을 안내하는 지침은 과제마다 다르며, Claude에게 어떤 정보가 실제로 중요한지 알려 줍니다. 예를 들어 LAB 벤치마크의 한 과제는 기업 인수를 가정하고 계약서 묶음을 제공합니다. 이 브리프는 계약 조건을 정확하게 기술했는지로 채점합니다.

처음에는 위키를 어떻게 활용할지 알려 주지 않는 기본 지침으로 위키를 생성했습니다. 이 과제는 계약 조건에 크게 의존합니다. 위키를 구축하는 동안 여러 에이전트가 계약 조건을 정리한 공유 표에 동시에 기록했습니다(그림 14, 왼쪽).

그 결과 위키에는 핵심 사실이 빠져 있었습니다. 위키로 생성한 브리프를 채점해 보니 Claude는 57개 사실 중 41개(72%)만 포함했습니다. 무엇이 잘못됐는지 살펴보니, 에이전트들이 서로의 작업을 덮어쓰는 바람에 공유 표가 계약 조건을 부실하게 요약했고 일부는 아예 빠져 있었습니다.

계약 조건이 위키에서 가장 중요한 부분이었지만 지침에는 그런 내용이 없었습니다. 더 나은 지침을 찾기 위해 Claude가 실패를 돌아보고, 지침 수정안을 제안하고, 위키를 다시 구축하는 루프를 돌렸습니다. 이 루프를 거치며 Claude는 계약 조건을 충실히 따르는 것이 얼마나 중요한지 스스로 알아냈고, 그에 맞게 위키 구축 지침을 다시 썼습니다.

개선된 지침에서는 계약마다 에이전트 한 명이 작성한 전용 위키 페이지를 두었고, 조건을 공유 표로 요약하는 대신 원문 그대로 인용했습니다. 이렇게 개선한 위키로 생성한 브리프를 채점하자 기준 100%를 충족할 수 있었고, 72%에서 크게 올랐습니다.

드리밍은 세션이 남긴 빈틈을 메울 수 있습니다

Claude가 메모리 노트를 쓸 때 볼 수 있는 것은 그 세션의 컨텍스트뿐입니다. 드리밍은 여러 세션을 가로질러 검색하며 공통 패턴을 찾거나 반복되는 실수를 바로잡을 수 있습니다.

LAB 벤치마크용 위키를 구축할 때(예시는 그림 14 참고), Claude가 아직 만들어지지 않은 페이지로 링크를 거는 경우가 가끔 있었습니다. 두 번째 드리밍 패스에서 이런 빈틈이 상당수 메워졌습니다. 한 과제(그림 15)에서는 드리밍이 위키에서 없는 페이지로 향하는 링크 9개를 찾아, 같은 문서를 다루는 기존 페이지로 연결을 바꿔 놓았습니다. 색인을 포함해 새 페이지 3개를 추가해 위키를 개선하기도 했습니다.

뒤를 돌아보며 앞을 내다보다

에이전트를 위한 메모리 시스템을 어떻게 설계할지는 아직 열린 질문이 많습니다. 첫 번째는 Claude가 메모리를 언제 만들어야 하느냐입니다. Claude는 작업하는 도중 메모리 저장소(폴더, 파일, 데이터베이스 등)에 기록해 중요한 점을 그 자리에서 포착하고, 중요한 세부 내용을 이후 턴이나 세션에서 바로 쓸 수 있게 만듭니다. 하지만 그때그때 노트를 남기면 어쩔 수 없이 Claude의 주의가 본래 작업에서 분산됩니다. 반면 드리밍은 메모리 생성을 백그라운드로 미룰 수 있지만, 드리밍의 결과물을 Claude가 바로 쓸 수 없을 수도 있습니다.

두 번째는 메모리를 어떻게 안정적으로 최신 상태로 유지하느냐입니다. Claude는 잘못 예측할 수도 있고, 처음부터 틀린 규칙을 메모리에 쓸 수도 있습니다. 환경이 바뀌면 메모리가 어긋나 쓸모없어지기도 합니다. 드리밍은 이런 실수를 바로잡는 한 가지 방법이지만(그림 8) 연산 자원이 듭니다. Claude에게 모든 메모리를 계속 점검하게 하는 것은 현실적이지 않을 수 있습니다. 대신 바뀔 가능성이 큰 정보에 드리밍을 집중하거나, 드리밍 주기를 (예: 메모리 접근 빈도에 따라) 세심하게 조정하는 것이 중요할 수 있습니다.

트랜스크립트 검색을 Claude 메모리의 토대로 삼는 것도 충분히 고려할 만합니다. 위키 같은 표현과 검색을 결합하면(그림 10) 효과적일 때가 있습니다. 하지만 Claude가 연산 자원을 들여 메모리 표현을 관리하고, 오류나 환각이 쌓이지 않도록 해야 합니다.

Claude의 중요도 판단이 나아졌다 해도, 앞으로의 턴에서 무슨 일이 일어날지 정말로 아는 모델은 없습니다. 드리밍은 Claude가 뒤를 돌아보며 연산 자원으로 메모리를 정리하고, 실수를 바로잡고, 이후 세션이 메모리에 더 쉽게 접근하도록 돕는 표현을 관리할 기회를 줍니다. Claude의 능력이 높아지면 메모리 시스템도 진화할 것이고, Claude의 메모리 시스템을 설계하는 일에서 우리가 배울 것은 아직 많습니다.

드리밍 시작하기와 지식 위키에 관한 쿡북도 참고해 보세요.