Anthropic은 에이전트가 지난 작업을 다음 세션에 활용하도록 기억을 저장하고 정리하는 구성을 소개했다. 개발자는 유휴 시간에 기록의 오류를 고치고 탐색 지도를 만드는 방식을 활용해, 무엇을 기억하고 언제 다시 살펴볼지 설계할 수 있다.
1. 기록에서 다음 세션의 문맥까지 네 층으로 연결한다
기억은 경험에서 얻은 지식을 다음 세션에서 읽도록 저장한 것이다. 탐색 가능한 작업 기록, 중요한 내용을 남기는 메모, 이를 엮은 위키, 다음 세션에 미리 적재하는, 필요한 정보를 불러두는 문맥의 네 층으로 구성된다. 아래층은 원자료, 위층은 정리된 지식과 바로 쓸 기억이다.
꿈은 세션 사이의 유휴 시간에 기록을 되짚어 메모를 고치거나 새로 정리하는 과정이다. Anthropic은 Letta와 UC 버클리 연구자들이 제안한 유휴 시간 연산, 작업하지 않는 동안 수행하는 계산 개념을 기억 정리에 적용했다.
2. 기억을 쓰는 법은 에이전트가 판단할 때 효과가 컸다
Anthropic은 CL-Bench 1.0 데이터베이스 과제에서 질문마다 새 세션을 열고 메모리 디렉터리만 이어 주었다. 모델은 정답을 확인받은 뒤 실패 원인을 검토하고 다음 질문에 쓸 규칙을 남길 수 있었다. 회사 발표 기준, 메모리를 썼을 때 평균 보상, 과제에서 얻은 점수의 평균값은 높아졌지만 상승 폭은 모델마다 달랐다.
표: CL-Bench 데이터베이스 과제의 모델별 평균 보상
조건: CL-Bench 1.0 데이터베이스 과제, Claude Managed Agents 사용. 질문마다 새 세션, 메모리 사용 시 디렉터리 유지. 원문 그림 대체 텍스트 기준.
단위: 평균 보상
| 모델 | 메모리 없음 | 메모리 사용 |
|---|---|---|
| Opus 5.5 | 0.655 | 0.838 |
| Sonnet 5.5 | 0.644 | 0.833 |
| Opus 5 | 0.564 | 0.828 |
| Opus 4.7 | 0.383 | 0.700 |
| Sonnet 5 | 0.306 | 0.610 |
| Sonnet 4.6 | 0.330 | 0.364 |
회사 발표 기준, Sonnet 4.6은 메모리만으로는 개선 폭이 작았지만, 메모리를 읽고 답하기 전 가설을 시험하라는 지시를 받았을 때 점수가 0.641로 올랐다. Sonnet 5는 별도 지시 없이도 열 번 중 아홉 번 메모리를 먼저 읽었다.
Anthropic은 강한 모델에게는 기억할 내용을 고정하기보다 중요도를 판단하게 하는 편이 효과적이었다고 설명한다. 실패만 기록하게 했을 때는 메모리의 성능 개선 효과가 줄었다.
3. 좋은 기억은 많기보다 다시 쓸 수 있어야 한다
포켓몬 레드 실험은 모델별 한 차례 실행에서 약 1만 단계 시점의 메모리를 비교했다. 회사 발표 기준, 세부 기록을 쌓은 Sonnet 3.7보다 전략과 다음 계획을 남긴 Fable 5가 더 적은 파일로 배지를 많이 얻었다.
표: 포켓몬 실험의 기억 규모와 게임 진행
조건: 모델별 한 차례 실행, 약 1만 단계 시점 비교. Fable 5 파일 수는 최상위 파일 포함.
| 모델 | 파일 수 | 폴더 수 | 배지 수 |
|---|---|---|---|
| Sonnet 3.7 | 413 | 225 | 1 |
| Fable 5 | 10 | 2 | 4 |
Sonnet 3.7은 약 1만 단계 지점부터 17단계 동안 파일 여섯 개를 만들고 아홉 개를 지우느라 게임 안에서는 행동하지 않았다. 이 사례는 화면에서 다시 확인할 상태보다 다음 행동에 쓸 전략을 남기는 편이 유용함을 보여준다.
4. 꿈은 오류를 고치고 필요한 기억으로 가는 지도를 만든다
Anthropic은 포켓몬 실험에서 산 입구에 있는 회복 시설의 위치를 잘못 적은 메모를 꿈이 기록과 대조해 수정한 사례를 제시했다. 수정된 기억을 쓴 실행은 산으로 돌아가 다음 도시에 도착했다. 잘못된 기억을 유지한 실행은 이전 경로로 세 번 되돌아갔고 끝내 산을 넘지 못했다.
위키는 주제별 지식과 메모를 연결한 페이지 모음으로, 필요한 기억을 찾는 지도 역할을 한다. Anthropic은 약 35만 개 사내 문서, 약 4억 2천만 토큰을 대상으로 25개 질문을 평가했다. 회사 발표 기준, Opus 5가 꿈으로 위키를 키우자 위키만 쓸 때보다 검색을 함께 쓸 때 점수가 높았다.
표: 위키를 키우며 달라진 답변의 채점 기준 충족률
조건: 동일한 사내 문서·25개 질문 평가. Opus 5가 위키를 구축한 꿈 세션 2회와 128회 시점 비교.
단위: %
| 답변에 사용한 자료 | 2회 시점 | 128회 시점 |
|---|---|---|
| 검색만 | 53 | 53 |
| 위키만 | 13 | 48 |
| 위키와 검색 | 54 | 61 |
회사 발표 기준, 위키와 검색의 조합은 질문마다 약 2만 토큰도 절약했다. 합병 자료의 24개 질문 중 여러 문서를 엮어야 하는 항목에서도 위키 사용 시 87%, 검색만 사용 시 73%를 기록했다.
5. 기억의 품질은 연산과 적재 공간을 함께 쓴다
탐색에서 아낀 비용의 일부는 기억을 유지하는 연산과 적재 공간으로 옮겨간다. 회사 발표 기준, 한 법률 과제에서는 10개 문서, 115KB를 정리한 위키가 68페이지와 255개 링크, 203KB로 커졌다. 꿈을 돌리는 데도 연산이 들고 다음 세션에 넣는 문맥은 토큰을 차지한다.
단일 문서에서 바로 찾을 수 있는 법률 과제에서는 위키의 뚜렷한 이점이 없었다. 잘못된 메모를 매번 적재하면 오류도 반복될 수 있다.
Anthropic은 최상위 기억을 작게 두고 세부 사항은 링크로 찾게 한다. Claude Code도 MEMORY.md 앞 200줄 또는 25KB만 적재해 색인, 내용을 빠르게 찾도록 만든 목록으로 쓴다.
개발자는 변하기 쉬운 정보나 접근 빈도에 맞춰 꿈의 시점을 조정하는 방안을 검토할 수 있다.
에이전트 기억의 핵심은 더 많이 저장하는 것이 아니라, 기록을 검증하고 다음 작업에 맞는 층으로 정리하는 데 있다.