에이전트 메모리, 많이 저장하기보다 검증하고 다시 정리하기 (feat. Anthropic)

9bow · 11월 9, 2026, 11:30오전

핵심 요약

Anthropic의 에이전트 메모리 분석은 원본 기록, 선별한 메모, 연결된 위키, 세션 시작 시 미리 제공하는 정보를 구분합니다.
실험에서는 메모리의 효과가 모델과 지침에 따라 달랐고, 검증되지 않은 추측이나 오래된 기록이 후속 작업을 방해했습니다.
Opus 5를 사용한 기업 문서 질문 25개의 평가에서, 위키와 검색의 결합은 평가 기준 충족률 61%, 검색 단독은 53%를 기록했습니다.
단일 문서 검색으로 대부분 해결되는 한 과제에서는 위키의 뚜렷한 이득이 없었고, 위키 생성과 유지에는 별도 계산이 필요했습니다.

에이전트 메모리 소개

에이전트와 여러 날 작업하면 이미 해결한 문제를 다시 설명하거나, 과거에 실패한 방법을 다시 시도하는 일을 겪게 됩니다.
대화를 저장해 두면 나중에 읽을 수는 있지만, 기록 전체에서 현재 작업에 필요한 내용을 찾는 일은 여전히 남습니다.
반대로 짧은 메모만 믿으면 잘못 이해한 내용을 다음 작업에서도 사실로 받아들일 수 있습니다.

Anthropic은 2026년 11월 6일 공개한 The components of agent memory에서 에이전트 메모리(Agent Memory) 를 구성하는 여러 계층의 역할로 이 문제를 설명합니다.
원본 대화 기록, 선별한 메모, 주제별 위키, 세션 시작 시 미리 읽는 짧은 정보가 각각 다른 일을 맡습니다.
여기에 과거 기록을 다시 검토하는 드리밍(Dreaming) 을 더해, 메모를 고치거나 새로운 구조로 재정리하는 방식을 살펴봅니다.

원문은 데이터베이스 질의, Pokémon Red 플레이, 기업 문서 탐색, 법률 문서 작성 등 여러 과제의 결과를 제시합니다.
각 실험은 모델과 데이터, 평가 방식이 다르므로 하나의 메모리 방식에 대한 종합 순위로 합칠 수 없습니다.
이 글에서는 어떤 조건에서 메모리의 효과가 나타났고, 어떤 조건에서는 비용이나 오류가 늘었는지 중심으로 살펴봅니다.

기록과 메모, 위키와 주입된 정보는 서로 다른 역할을 맡습니다

원문에서 메모리는 경험으로 얻은 지식을 나중에 읽을 수 있는 형태로 저장하고, 세션이 바뀌어도 유지하는 것을 뜻합니다.
모델 내부의 가중치를 바꾸는 학습과는 구분합니다.
같은 대화 안에서 예시를 보고 적응하는 문맥 내 학습(In-context Learning)이나, 이전 대화를 요약해 작업을 이어 가는 컨텍스트 압축(Compaction)도 이 글의 메모리 정의에서는 제외합니다.

원문 그림 1. 드리밍은 여러 메모리 계층을 오가며 내용을 고치고 재구성합니다. 출처: Anthropic.

계층	저장하는 내용	다음 세션에서 쓰는 방식
대화 기록(Transcripts)	사용자의 요청, 에이전트의 행동과 관찰 등 원본 기록	검색하거나 다시 읽어 당시 상황을 확인합니다
메모리 노트(Memory Notes)	에이전트가 중요하다고 판단한 관찰, 규칙, 계획	관련 파일을 읽어 이전 경험을 재사용합니다
메모리 표현(Memory Representations)	주제별 페이지와 링크로 정리한 위키 등	연결된 정보를 따라가며 필요한 지식을 찾습니다
주입된 컨텍스트(Injected Context)	매 세션 시작 시 미리 제공하는 짧은 정보	별도 검색 전에 현재 작업의 문맥에 포함됩니다

대화 기록은 메모가 잘못되었을 때 당시의 관찰을 다시 확인할 수 있는 근거입니다.
메모는 그 기록에서 다음 작업에도 유용할 내용을 골라 놓습니다.
위키는 여러 기록에 흩어진 내용을 주제별로 연결하며, 주입된 컨텍스트는 자주 필요한 정보를 검색 없이 전달합니다.

이 계층들이 모두 같은 내용을 복제할 필요는 없습니다.
상위 계층에는 짧은 설명과 관련 자료를 찾을 위치를 두고, 세부 사항은 필요할 때 읽는 방식이 가능합니다.
원문에서 드리밍은 이 구분을 유지하면서 오류 수정, 중복 정리, 페이지 연결, 상위 계층에 넣을 정보 선별을 수행합니다.

Anthropic은 배경 개념으로 Letta와 캘리포니아대학교 버클리(University of California, Berkeley) 연구진의 Sleep-time Compute를 연결합니다.
질문에 답하는 순간뿐 아니라 상호작용 사이의 시간에도 계산을 사용해, 나중에 필요한 정보를 미리 정리한다는 접근입니다.
사람의 수면과 기억 형성을 설명에 활용하지만, 에이전트가 인간의 뇌와 같은 방식으로 기억한다는 실험 결과는 아닙니다.

메모리 계층 더 알아보기

Claude Managed Agents 메모리 문서

Sleep-time Compute 연구

좋은 메모에는 추측뿐 아니라 확인한 규칙과 근거가 남습니다

에이전트가 어떤 규칙을 메모할 때는 그 규칙이 미래 작업에도 도움이 될 것이라고 예상합니다.
현재 눈에 띄는 정보를 전부 보존하는 것과, 다음 문제를 풀 때 다시 쓸 정보를 남기는 것은 다릅니다.
Anthropic은 Continual Learning Bench 1.0(CL-Bench)의 데이터베이스 과제로 이 차이를 살펴봤습니다.

이 과제에서 에이전트는 데이터베이스를 조회해 연속된 질문에 답합니다.
답변 뒤에는 올바른 해답을 전달받고, 다음 질문을 위해 메모를 남길 수 있습니다.
Claude Managed Agents에서 각 질문은 새 세션으로 시작하며, 이전 세션에서 이어받는 정보는 지속되는 메모리 디렉터리의 파일입니다.

원문 그림 3. 왼쪽은 평균 보상, 오른쪽은 질문이 진행될 때의 누적 평균 보상입니다. 출처: Anthropic.

모델	메모리 없는 기준선의 평균 보상	메모리 사용 시 평균 보상
Claude Opus 5.5	0.655	0.838
Claude Sonnet 5.5	0.644	0.833
Claude Opus 5	0.564	0.828
Claude Opus 4.7	0.383	0.700
Claude Sonnet 5	0.306	0.610
Claude Sonnet 4.6	0.330	0.364

표의 값은 이 데이터베이스 과제의 평균 보상이며, 일반적인 질의 정확도나 전체 CL-Bench 점수로 확대할 수 없습니다.
메모리를 추가했을 때의 변화도 모델마다 달랐습니다.
예를 들어 Sonnet 4.6은 0.330에서 0.364로 변했지만, Opus 4.7은 0.383에서 0.700으로 변했습니다.

메모 파일의 내용에서도 차이가 나타났습니다.
Sonnet 4.6은 틀린 이유에 대한 가설을 만들었으나, 파일마다 검증하지 않은 추측이 여러 개 남아 있었습니다.
Opus 4.7은 정보를 한 문서로 통합하면서 확인한 사실과 미확인 사실을 표시했고, Sonnet 5는 채점 결과에 따라 정답을 확인하거나 오답을 수정했습니다.

Opus 5의 메모에는 규칙, 그 규칙이 맞다고 판단한 근거, 이전 질문의 답, 이미 발견한 함정이 함께 포함되는 경우가 많았습니다.
Opus 5.5와 Sonnet 5.5도 가설을 확인하고 검증된 규칙을 남기는 과정을 수행했습니다.
Anthropic은 이 과정을 실패 기록, 원인 가설, 가설 검증, 이후 답변에 쓸 규칙으로 이어지는 학습 과정으로 설명합니다.

원문 그림 2. 작업 중 작성하는 메모는 다음 세션에서 바로 활용할 수 있습니다. 출처: Anthropic.

이 결과에서 개발자가 살펴볼 대상은 메모 파일의 존재 여부만이 아닙니다.
원인을 추측한 기록과 실제로 시험해 확인한 규칙을 구별하는지, 다음 문제에서 그 규칙을 읽고 적용하는지까지 확인해야 합니다.
성공과 실패 경험을 재사용하는 다른 접근은 커뮤니티의 ReasoningBank 소개글에서도 살펴볼 수 있습니다.

연속된 과제의 평가 더 알아보기

Continual Learning Bench 공식 저장소

Pokémon 실험에서는 적게 기록한 모델이 더 멀리 진행했습니다

무엇을 남길지 판단하는 능력, 즉 중요도 판단(Salience Judgment) 은 환경이 계속 바뀌는 작업에서 특히 드러납니다.
Anthropic은 Pokémon Red를 플레이하는 모델에 읽고 쓸 수 있는 메모리 폴더를 제공했습니다.
원문은 Sonnet 3.7과 Fable 5의 실행을 각각 한 번씩 선택해, 약 10,000단계 진행 시점의 메모리를 비교합니다.

Sonnet 3.7은 전투, 아이템, 등장인물과의 만남을 세세하게 기록했습니다.
결과적으로 225개 폴더에 413개 파일을 남겼고, 게임 진행의 지표인 배지는 1개를 얻었습니다.
Fable 5는 2개 폴더 안의 파일 9개와 최상위 global.md 파일 1개를 남겼으며, 배지는 4개를 얻었습니다.

원문 그림 4. 면적은 메모리의 문자 수를 나타내며, 파일 개수나 폴더 개수와는 다른 지표입니다. 출처: Anthropic.

많은 기록은 갱신 부담으로 이어졌습니다.
Sonnet 3.7은 약 10,000단계 시점에 네 번째 통합 메모 폴더를 만들기 시작했고, 이어진 17단계 동안 파일 6개를 생성하고 9개를 삭제했습니다.
그동안 게임에서는 아무 행동도 하지 않았다고 Anthropic은 설명합니다.

게임 화면에서 매번 확인할 수 있는 현재 위치나 소지금은 상태가 바뀔 때마다 오래된 기록이 되기 쉽습니다.
Fable 5는 대신 화면만으로 알기 어려운 전략과 이동 계획, 직접 알아낸 규칙을 중심으로 메모했습니다.
global.md 에는 현재 목표와 다음 계획을 두고, 지역별 이동 계획과 게임 진행 전략은 별도 파일로 나누었습니다.

여기에는 실험 해석의 한계도 있습니다.
서로 다른 모델의 실행을 한 번씩 비교한 사례이므로, 파일 수를 줄였기 때문에 배지가 늘었다는 인과관계를 입증한 결과는 아닙니다.
다만 다시 관찰할 수 있는 일시적 상태와, 경험을 통해 알아낸 전략을 구분해야 하는 이유를 보여줍니다.

메모리 지침은 모델이 실제로 하지 못하는 행동을 보완할 때 효과가 있었습니다

Anthropic은 메모리를 사용하라는 일반적인 안내 외에, 어떤 내용을 기록할지 구체적인 규칙도 시험했습니다.
한 실험에서는 실패만 기록하도록 제한했습니다.
이때 메모리로 얻던 성능 향상 폭이 Opus 5에서는 0.234, Opus 4.7에서는 0.150 줄었고, Sonnet 4.6에서는 0.020 줄었습니다.

이는 실패를 기록하면 항상 성능이 나빠진다는 결과가 아닙니다.
이 과제에서 기록 대상을 실패로만 제한했을 때는 기존에 자유롭게 메모하던 조건보다 이득이 줄었습니다.
성공한 방법과 확인된 규칙 등 미래 작업에 필요한 다른 정보를 남길 기회도 함께 줄어들 수 있습니다.

원문 그림 5. 왼쪽은 평균 보상이고, 오른쪽은 메모리로 얻는 이득의 변화량입니다. 출처: Anthropic.

그림 5의 Sonnet 4.6 평균 보상 비교는 조건별 3회 실행을 사용합니다.
실패만 기록하는 조건의 변화량은 Opus 5와 Opus 4.7이 각각 3회 실행, Sonnet 4.6이 1회 실행입니다.
실행 횟수가 작으므로 수치의 차이를 모든 업무에 그대로 적용하기는 어렵습니다.

반면 Sonnet 4.6에는 행동을 구체적으로 안내하는 지침이 도움이 됐습니다.
기존 실행에서 메모리 파일을 읽지 않거나 가설을 검증하지 않는 일이 관찰되어, 답변 전에 파일을 읽고 가설을 시험하도록 요청했습니다.
평균 보상은 메모리만 제공했을 때 0.364였고, 지침까지 개선했을 때는 0.641이었습니다. 메모리 없는 기준선은 0.330이었습니다.

Sonnet 5는 별도 안내 없이도 10번 중 9번꼴로 답변 전에 메모리를 읽었지만, Sonnet 4.6의 해당 비율은 절반 미만이었다고 합니다.
따라서 메모리 규칙을 늘리기 전에 해당 모델이 읽기, 검증, 기록 중 어느 단계에서 실패하는지 관찰할 근거가 있습니다.
Anthropic은 더 강한 모델에 대해서는 메모리의 목적을 설명하고 중요도 판단은 모델에 맡기는 방식을 주로 사용한다고 밝힙니다.

드리밍은 잘못된 메모를 원본 기록과 대조해 수정합니다

작업 중 작성한 메모는 에이전트가 그 순간 이해한 내용입니다.
처음부터 틀렸거나 환경 변화로 맞지 않게 된 내용도 파일에 남으면, 다음 세션에서는 이미 확인한 사실처럼 읽힐 수 있습니다.
드리밍은 세션이 끝난 뒤 원본 기록과 메모를 다시 대조할 기회를 제공합니다.

원문 그림 6. 메모를 검증할 수 있도록 원본 대화 기록을 함께 유지합니다. 출처: Anthropic.

Pokémon 실험에서 에이전트는 Mt. Moon 입구의 Pokémon Center가 산의 동쪽에 있다고 잘못 기록했습니다.
실제로는 서쪽 입구 부근에 있었지만, 에이전트는 산을 이미 통과했다고 판단하고 다음 도시로 이동하려 했습니다.
그 과정에서 일방통행 지형을 넘어 이전 경로로 되돌아가는 행동을 반복했습니다.

원문 그림 7. 위치에 대한 메모가 바뀌자 다음에 취할 이동 방향도 바뀌었습니다. 출처: Anthropic.

Anthropic은 잘못된 위치 정보가 들어 있는 메모리 폴더에 드리밍을 적용했습니다.
에이전트는 세션 기록에서 오류를 확인해 메모를 고쳤고, 이후 실행에서는 동굴 안으로 다시 들어가 Cerulean City에 도달했습니다.
수정하지 않은 메모를 사용한 실행은 같은 지형에서 세 번 되돌아갔고, 최종적으로 목표 도시에 도달하지 못했습니다.

원문 그림 8. 제시된 사례에서 메모와 드리밍을 함께 사용한 실행은 누적 행동 1,935회에 Cerulean City에 도달했습니다. 출처: Anthropic.

이 사례의 검증 근거는 과거 세션의 관찰 기록입니다.
드리밍이 메모만 다시 읽고 문장을 다듬었다면 잘못된 위치 판단을 그대로 강화할 수도 있습니다.
메모의 신뢰도를 다루는 관련 프로젝트는 Dense-Mem 소개글에서 더 살펴볼 수 있습니다.

드리밍 더 알아보기

Claude Managed Agents Dreams 문서

위키는 여러 문서의 관계를 정리하지만 원문 검색도 함께 필요했습니다

드리밍은 메모 수정 외에 정보를 찾는 구조도 만들 수 있습니다.
원문에서 위키(Wiki) 는 한 주제에 관해 알고 있는 내용을 페이지로 정리하고 관련 페이지끼리 링크한 자료입니다.
에이전트가 직접 작성하고 관리하며, 여러 문서의 관계를 따라가며 정보를 찾는 데 사용합니다.

원문 그림 9. 드리밍으로 원본 기록과 메모에서 새로운 탐색 구조를 만듭니다. 출처: Anthropic.

Anthropic은 Stainless의 내부 문서 약 35만 개, 약 4억 2천만 토큰을 대상으로 위키를 만드는 실험을 진행했습니다.
Opus 5 에이전트들이 최대 128개 세션에 걸쳐 문서를 탐색하고, 페이지를 추가하거나 고치고, 중복을 합치고, 출처와 주장을 대조했습니다.
평가는 이 문서 집합에 대한 질문 25개를 사용했습니다.

원문 그림 10. 가로축은 세션당 100만 토큰을 기준으로 계산한 드리밍 토큰 예산이며, 실제 사용량을 측정한 값은 아닙니다. 출처: Anthropic.

드리밍을 2개 세션에서 128개 세션으로 늘리면서 위키만으로 답할 때의 평가 기준 충족률은 13%에서 48%로 높아졌습니다.
검색 도구만 사용한 조건은 53%였고, 검색과 위키를 함께 사용한 조건은 위키가 성장하면서 54%에서 61%로 높아졌습니다.
이 비율은 질문 25개 중 정답을 맞힌 질문의 비율이 아니라, 답변이 채점 기준을 충족한 정도입니다.

검색과 위키를 함께 사용하면 질문당 약 2만 토큰도 절약됐다고 합니다.
다만 위키 생성에 배정한 드리밍 토큰 예산은 그림에서 총 200만 토큰부터 1억 2,800만 토큰까지 증가합니다.
질문에 답하는 비용의 절감만으로 위키 생성과 유지까지 포함한 전체 비용이 줄었다고 결론 낼 수는 없습니다.

같은 문서에 반복해서 질문하는 업무에서는 사전 정리 비용을 여러 요청에 나눠 부담할 수 있습니다.
반면 한 번만 읽을 자료이거나 내용이 자주 바뀐다면, 위키 생성과 갱신 비용도 함께 고려해야 합니다.
이 비용 비교는 위키 페이지 수보다 실제 질문의 빈도와 유형을 기준으로 하는 편이 적절합니다.

지식 위키 더 알아보기

Anthropic의 Knowledge Wiki 예제

여러 문서를 종합하는 문제에서 위키의 이점이 더 뚜렷했습니다

Anthropic은 위키가 어떤 과제에서 도움이 되는지도 비교했습니다.
기업 인수 관련 문서에 대한 질문과, 문서를 바탕으로 법률 검토 문서를 작성하는 Harvey LAB(Legal Agent Benchmark) 과제를 사용했습니다.
같은 자료를 위키로 읽는 조건과 원본 파일을 직접 검색하는 조건을 비교합니다.

기업 인수 관련 질문 24개를 사용한 실험에서는 절반 이상이 여러 문서의 정보를 종합해야 했고, 그중 일부는 판단이나 계산도 필요했습니다.
여러 문서를 종합하거나 판단이나 계산이 필요한 항목(그림 11의 빨간색과 주황색 연결선)에서 위키를 사용했을 때는 87%, 검색만 사용했을 때는 73%를 기록했습니다.
이 값을 질문 24개 전체의 정확도나 Harvey LAB 전체 점수로 해석해서는 안 됩니다.

원문 그림 11. 왼쪽은 여러 문서를 종합해야 하는 질문이 절반 이상인 기업 인수 과제이고, 오른쪽은 단일 문서에서 찾을 수 있는 기준이 많은 LAB 과제입니다. 항목별 분류는 모델이 부여한 라벨입니다. 출처: Anthropic.

반면 다른 LAB 과제에서는 평가 기준 대부분을 한 문서의 텍스트 검색으로 충족할 수 있었습니다.
이 조건에서는 위키가 검색보다 뚜렷하게 유리하지 않았습니다.
이미 필요한 내용이 특정 문서에 모여 있다면, 별도의 표현으로 다시 작성하는 효과가 작을 수 있습니다.

위키가 지나치게 커지는 사례도 있었습니다.
원본은 문서 10개, 115KB였지만, 생성한 위키는 페이지 68개와 링크 255개, 203KB로 원본의 1.77배가 됐습니다.
일부 페이지는 다른 페이지와 연결되지도 않았습니다.

원문 그림 12. 문서를 더 많은 페이지로 다시 작성하는 것만으로 추상화나 탐색 효율을 얻는 것은 아닙니다. 출처: Anthropic.

이 결과들은 자료의 양만으로 위키 도입을 결정하기 어렵다는 점을 보여줍니다.
단일 문서에서 사실을 찾는 작업과, 여러 문서의 관계를 파악하고 계산하는 작업은 요구하는 준비가 다릅니다.
후자의 작업이 반복될 때 위키가 정보 간 관계를 미리 정리하는 이점을 평가할 수 있습니다.

매번 미리 읽는 메모리는 짧게 유지해야 합니다

위키나 메모를 검색할 수 있어도, 에이전트가 무엇을 검색해야 할지 모르면 필요한 정보를 찾지 못할 수 있습니다.
원문은 일부 정보를 세션 시작 시 미리 제공하는 컨텍스트 주입(Context Injection) 으로 이 문제를 보완합니다.
이 역할은 에이전트의 실행과 도구, 컨텍스트를 관리하는 하네스(Harness)가 맡을 수 있습니다.

원문 그림 13. 상위 계층은 매 세션 읽고, 나머지 계층은 필요할 때 검색하거나 읽습니다. 출처: Anthropic.

미리 읽는 메모가 길어지면 현재 작업에 쓸 컨텍스트를 차지하며, 틀린 메모는 매번 전달될 수 있습니다.
읽었다고 해서 반드시 지시를 따르는 것도 아닙니다.
Anthropic은 세부 내용은 아래 계층으로 옮기고 링크를 남겨, 상위 계층을 작게 유지하는 방식을 설명합니다.

구체적인 예로 Claude Code의 자동 메모리를 소개합니다.
공식 문서는 MEMORY.md 의 처음 200줄 또는 처음 25KB 중 먼저 도달하는 한도까지만 세션 시작 시 읽는다고 설명합니다.
더 자세한 기록은 별도 주제 파일에 두고, 이 파일은 어떤 정보가 어디에 있는지 안내하는 색인 역할을 합니다.

자동 메모리 더 알아보기

Claude Code 메모리 문서

메모리 생성의 목표와 파일 작성 방식을 바꾸면 누락을 줄일 수 있습니다

기억을 정리할 때는 무엇을 위해 사용할지도 알려줘야 합니다.
원문의 LAB 사례에서는 기업 인수 관련 계약 조건을 정확하게 반영하는 문서를 작성해야 했습니다.
하지만 초기 위키 생성 지침은 계약 조건의 중요성이나 보존 방법을 충분히 지정하지 않았습니다.

여러 에이전트가 계약 조건을 하나의 공유 표에 쓰면서 일부 내용을 부정확하게 요약했고, 다른 에이전트가 쓴 내용을 덮어쓰는 문제도 발생했습니다.
그 위키로 만든 결과물에는 평가 대상 사실 57개 중 41개, 약 72%만 포함됐습니다.
이는 단순한 검색 실패와 달리, 위키를 만드는 과정에서 정보가 이미 사라진 경우입니다.

원문 그림 14. 계약별로 한 에이전트가 한 페이지를 작성하도록 바꾸고 계약 조건을 원문 그대로 보존했습니다. 출처: Anthropic.

Anthropic은 에이전트가 실패를 분석하고 지침을 수정한 뒤 위키를 다시 만드는 과정을 실행했습니다.
수정된 방식에서는 계약마다 별도 페이지를 만들고, 한 에이전트가 그 계약을 맡으며, 조건을 공유 표로 요약하는 대신 원문 그대로 인용했습니다.
이 위키로 생성한 결과물은 해당 과제의 평가 기준 57개를 모두 충족할 수 있었습니다.

여기서는 목표 설명, 파일별 작성 책임, 원문 보존 방식이 함께 바뀌었습니다.
따라서 개선 전체를 드리밍이라는 한 요소만의 효과로 분리해 해석할 수 없습니다.
실무적으로는 기억할 대상의 중요도와 정보가 손실되는 작성 경로를 함께 점검할 근거가 됩니다.

원문은 한 번의 세션으로 남은 구조적 오류를 모두 찾기 어렵다는 사례도 제시합니다.
어떤 위키에서는 존재하지 않는 페이지를 가리키는 링크 9개가 남아 있었습니다.
두 번째 드리밍 과정은 이를 같은 문서의 실제 페이지로 연결하고, 색인을 포함한 페이지 3개를 추가했습니다.

원문 그림 15. 이 사례의 위키는 항목 38개와 링크 225개에서 항목 41개와 링크 278개로 바뀌었습니다. 출처: Anthropic.

같은 개념이 다른 파일명으로 중복되거나 아직 만들지 않은 페이지로 연결되는 문제는 전체 자료를 다시 볼 때 드러날 수 있습니다.
다만 링크 구조가 정리됐다는 사실과 그 안의 주장이 정확하다는 사실은 별도로 확인해야 합니다.
원문 대조와 구조 점검은 서로 다른 검증을 맡습니다.

구현에서는 기록 시점과 갱신 비용을 함께 비교해야 합니다

작업 중 바로 메모하면 당시의 중요한 관찰을 빠르게 남겨 다음 세션에서 활용할 수 있습니다.
다만 작업 중 메모를 작성하려면 에이전트가 주 작업에서 주의를 돌려야 합니다.
반대로 드리밍으로 정리를 뒤로 미루면 주 작업과 분리할 수 있지만, 정리 결과가 준비되기 전에는 다음 작업이 그 정보를 쓰지 못할 수 있습니다.

갱신 주기도 남은 문제입니다.
처음부터 잘못된 규칙과, 환경이 달라져 더는 맞지 않는 규칙은 모두 다시 확인할 대상이 됩니다.
그렇다고 매번 모든 메모를 검증하면 비용이 커지므로, Anthropic은 변경 가능성이나 접근 빈도에 맞춰 드리밍의 대상과 주기를 조절하는 방안을 논의합니다.

아래 표는 원문의 실험을 바탕으로 이 글에서 구성한 적용 검토 예시이며, 별도의 성능 실험 결과는 아닙니다.

현재 작업에서 관찰한 문제	먼저 비교할 방식	확인할 결과
원본 문서에서 사실 하나를 찾는 데 문제가 없습니다	직접 검색을 기준선으로 유지합니다	위키를 추가했을 때 비용과 답변 품질이 실제로 달라지는지 비교합니다
같은 문서 집합의 관계를 반복해서 설명해야 합니다	검색과 위키를 함께 사용합니다	답변의 평가 기준 충족률과 질문당 토큰을 측정합니다
이전의 잘못된 판단을 반복합니다	메모와 원본 기록을 대조합니다	오류를 고친 뒤 후속 행동이 달라지는지 확인합니다
메모를 저장하지만 다음 작업에서 읽지 않습니다	읽기와 검증 지침을 보완합니다	실제 파일 읽기와 규칙 적용 여부를 관찰합니다
공동 작성한 위키에서 사실이 사라집니다	작성 책임과 파일 단위를 나눕니다	중요한 사실의 보존 여부와 동시 작성 시 손실을 확인합니다

원문의 결과만으로 모든 에이전트에 같은 메모리 구조를 적용할 근거는 없습니다.
대화 기록 검색을 기준선으로 두고, 메모와 위키가 어떤 작업의 품질과 비용을 개선하는지 비교하는 접근이 가능합니다.
이때 메모리 생성과 유지에 사용한 계산도 답변 비용과 함께 기록해야 실제 운영 조건에서의 이득을 판단할 수 있습니다.

The components of agent memory 소개 블로그

Dreaming with a dynamic workflow 공식 예제

Knowledge Wiki 공식 예제

Harvey LAB 평가 자료

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

이 글은 파이토치 한국 사용자 모임이 직접 정리한 글입니다. 새 글을 놓치지 않으시려면 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 알림을 받으시고, 회원으로 가입하시면 주요 글들을 이메일로도 보내드립니다!

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~