4,972
어제 해결한 오류를 코딩 에이전트가 오늘 다시 반복한다면, 대화 기록을 더 많이 붙이면 해결될까요? 반대로 이미 바뀐 프로젝트 규칙을 계속 기억한다면, 기억이 없는 것보다 더 곤란할 수 있습니다.
Anthropic이 11월 6일 공개한 「The components of agent memory」는 기억을 하나의 저장소가 아니라, 기록을 남기고 필요한 내용을 찾으며 잘못된 내용을 고치는 구조로 설명합니다.[1] 새 모델 출시 소개가 아니라, 세션을 넘는 기억의 설계와 제공자 측 실험을 읽는 글입니다.[1]
💡 🗓️ 날짜 안내: 표시 날짜는 2026-11-09이며, 누락분을 2026-11-10 KST에 소급 조사했습니다. 11월 9일 09:00 KST를 기준으로 탐색했고, 적합한 최신 후보가 부족해 24시간에서 72시간으로 넓혔습니다. 아래 커뮤니티 반응과 보조 문서의 확인 시점은 실제 조사일인 11월 10일입니다.
💡 💡 핵심: 좋은 기억은 대화를 통째로 보관하는 일이 아닙니다.[1]
💡 다시 알아내기 어려운 교훈을 근거와 함께 남기고, 평소에는 작은 길잡이만 읽으며, 틀린 기억은 원래 기록과 대조해 고치는 것입니다.[1]
이 글에서 말하는 에이전트 메모리는 작업 경험에서 얻은 정보를 다음 세션에서도 읽을 수 있게 저장한 문맥입니다.[1] 모델 내부의 가중치를 바꾸는 학습과는 다릅니다.[1]
Compaction은 길어진 대화의 오래된 부분을 요약해 작업을 계속할 공간을 만드는 방법입니다.[1] 반면 장기 기억은 여러 세션에서 다시 쓸 내용을 남기는 데 초점을 둡니다.[1] 둘은 한 시스템에서 함께 사용할 수 있습니다.[1][2]
검색·RAG와도 서로 배타적인 개념이 아닙니다.[1] 기억은 무엇을 남기고 갱신할지의 문제이고, 검색은 저장된 내용 중 지금 필요한 것을 꺼내는 방법으로 볼 수 있습니다.[1] 실제로 공식 실험은 위키와 검색을 함께 쓰는 구성을 다룹니다.[1]
대화와 도구 사용의 기록은 나중에 기억을 검증할 바탕입니다.[1] Anthropic은 이를 검색 가능한 사건 기록으로 놓고, 요약 메모가 틀렸을 때 원래 대화로 돌아가 확인하는 구조를 설명합니다.[1]
메모는 기록 전체의 복사본보다 선별한 관찰과 규칙에 가깝습니다.[1] 공식 평가에서 더 나은 기억은 규칙만 적는 대신, 그 규칙을 어떻게 확인했는지와 이전 답변, 발견한 함정도 함께 담았습니다.[1]
지금 화면이나 도구에서 쉽게 다시 확인할 수 있는 상태와, 시행착오를 거쳐 알아낸 교훈도 나눌 필요가 있습니다. 공식 포켓몬 사례에서는 매번 화면에 보이는 현재 위치·소지금을 계속 저장하는 일이 중복이었고, 전략과 검증한 규칙은 기록하지 않으면 사라지는 정보였습니다.[1]
여러 메모를 주제별 페이지와 링크로 엮으면 위키 같은 표현을 만들 수 있습니다.[1] 공식 글의 위키는 에이전트가 작성·유지하며, 한 주제에 관한 지식을 모으고 다른 메모로 연결하는 지도 역할을 합니다.[1]
위키를 만들었다고 원문 검색을 없앨 이유는 없습니다.[1] Anthropic은 자사 실험에서 위키에 검색 도구를 함께 제공했을 때 위키의 도움이 가장 컸다고 보고합니다.[1]
모든 기억을 매번 넣기보다, 중요한 길잡이만 세션 시작에 주입하고 상세 자료는 필요할 때 읽는 층입니다.[1] 이 층이 커지면 입력 토큰을 차지하고, 틀린 메모가 모든 세션에 따라다닐 수 있습니다.[1]
편집 제안: 상시 문맥을 프로젝트 설명서 전체가 아니라 짧은 목차처럼 설계해 보세요. 자세한 근거와 예외는 연결된 메모에 두는 방식입니다.
Dreaming은 여기서 모델이 스스로 재학습한다는 뜻이 아닙니다.[1] 작업 사이에 계산을 사용해 기록과 메모를 다시 읽고, 오류를 수정하거나 위키·다음 세션의 문맥을 정리하는 과정입니다.[1]
핵심은 “더 그럴듯하게 요약하기”보다 기억과 원래 근거를 대조하기입니다. 공식 글은 잘못된 메모를 원래 세션 기록에 비춰 시험하는 역할을 설명합니다.[1]
개발 업무에 옮긴다면, 다음 순환을 설계할 수 있습니다. 아래는 공식 API 절차가 아니라 이 글의 설계 제안입니다.
무조건 “실패만 기록하라”는 규칙도 정답은 아닙니다.[1] 공식 CL-Bench 실험에서는 그 지침이 Opus 5와 Opus 4.7이 기억으로 얻던 성능 이득을 상당 부분 줄였습니다.[1] 특정 모델·과제의 결과이므로 모든 에이전트의 최적 지침으로 일반화하지는 않습니다.[1]
Anthropic의 포켓몬 실험에서 Claude는 포켓몬센터의 위치를 잘못 기억했습니다.[1] 그 메모를 믿고 동굴을 이미 통과했다고 판단해 이동하다가 이전 경로로 되돌아가는 문제가 생겼습니다.[1]
Dreaming 단계는 잘못된 위치 메모를 세션 기록과 비교해 수정했습니다.[1] 수정된 기억을 받은 실행은 동굴로 다시 들어가 다음 도시인 Cerulean City에 도달했습니다.[1]
이 사례가 보여 주는 것은 “기억을 붙이면 게임을 잘한다”는 보장이 아닙니다. 틀린 기억을 그대로 재사용하는 경로와, 근거를 보고 고치는 경로가 달라질 수 있다는 제공자 측 실험입니다.[1] 이 글에서 게임이나 해당 구성을 직접 실행하지는 않았습니다.
어떤 저장소에서 “이 테스트는 환경 문제로 실패한다”는 메모를 남겼다고 가정해 보겠습니다. 며칠 뒤 환경이 고쳐졌는데도 그 메모를 그대로 넣으면, 에이전트가 실제 회귀 오류를 무시할 수 있습니다.
설계 제안은 결론·근거·적용 조건·재확인 계기를 함께 남기는 것입니다. 예를 들어 어떤 테스트와 실행 환경에서 확인했는지, 어떤 변경이 생기면 결론을 다시 확인해야 하는지를 메모에 붙입니다. 과거 실패의 설명을 영구적인 면제 규칙으로 만들지 않는 방식입니다.
저장 기능 자체와 이런 품질 관리는 다릅니다. 11월 10일 확인한 공식 Memory tool 문서에서는 Claude가 파일 작업을 요청하고, 실제 저장·조회·수정·삭제는 애플리케이션이 실행하는 client-side 구조를 설명합니다.[2]
따라서 파일 도구를 연결했다고 올바른 기억만 자동으로 쌓이는 것은 아닙니다. 어떤 내용을 검증해 승격하고 언제 다시 확인할지는 별도의 설계 문제로 남습니다.[1][2] 위 시나리오는 실제 고객 도입 사례나 측정한 개선 효과가 아닙니다.
한 문서에서 답을 바로 찾을 수 있다면 검색부터 검토할 만합니다. 공식 LAB 평가에도 단일 문서의 텍스트 검색으로 필요한 내용을 찾을 수 있어, 위키가 뚜렷한 성능 이득을 보이지 않은 과제가 있습니다.[1]
현재 대화만 길어지는 문제라면 compaction이 먼저일 수 있습니다. 작업 문맥을 줄이는 것과 다음 세션에 남길 경험을 고르는 것은 다른 목적입니다.[1][2]
여러 세션의 교훈을 반복해 쓰고 여러 자료를 연결해야 한다면 메모와 위키를 검토할 이유가 있습니다. 다만 원문 검색을 남겨 두고, 그 이익이 정리 비용을 넘는지 해당 업무에서 비교하길 권합니다. 공식 글에도 위키가 원문보다 커져 실질적으로 추상화하지 못한 사례가 나옵니다.[1]
편집 판단: 처음부터 자동 위키와 야간 정리를 모두 구축하기보다, 검색 가능한 작업 기록과 작은 검증 메모로 시작해 보세요. 기억을 추가했을 때의 정답률뿐 아니라 잘못된 재사용, 검색 시간, 입력량, 정리 비용도 비교 대상에 넣는 편이 좋습니다.
독립 연구 「How Memory Management Impacts LLM Agents」는 과거 경험의 오류가 이후 판단으로 전파되는 현상과, 겉보기에는 맞는 경험도 다른 작업에서는 오해를 낳을 수 있는 문제를 보고합니다.[5]
이 연구는 대부분의 실험에 GPT-4o-mini를 사용했고, 주로 기억의 추가·삭제를 연구했습니다.[5] Anthropic의 최신 모델이나 dreaming을 독립 재현한 시험은 아니므로, 구체적인 성능 수치를 서로 대체할 수는 없습니다.[5]
11월 10일 확인한 Hacker News 토론에서 한 사용자는 자동 기억이 현재 작업에만 유효한 내용을 자주 남긴다며, 무엇을 저장할지 더 잘 판단했으면 좋겠다고 말합니다.[3]
이는 사용자 한 명의 경험이지 전체 제품의 결함률이나 대표 사용 행태는 아닙니다. 그래도 기억의 가치를 저장량으로 평가하지 말아야 한다는 반론으로 읽을 수 있습니다.
원래 기록과 일치하는 메모라도 이후 환경이 바뀌면 낡을 수 있습니다.[1] 공식 글도 기억의 drift와 갱신 문제를 미해결 과제로 남기며, 모든 기억을 계속 재검사하는 계산 비용은 실용적이지 않을 수 있다고 설명합니다.[1]
따라서 dreaming으로 과거의 기록 오류를 고치는 일과, 현재 저장소·설정·문서가 바뀌었는지 다시 조회하는 일은 나눠 설계해야 합니다. 이것은 앞의 한계를 실무에 옮긴 편집 권고입니다.
공식 법률 문서 실험에서는 여러 에이전트가 같은 계약 요약 표를 덮어써 중요한 사실이 빠졌습니다.[1] 이후 계약별 페이지를 단일 에이전트가 맡고 원문 조건을 그대로 인용하도록 구조를 바꿨습니다.[1]
이 사례는 메모리 문제가 검색 정확도만의 문제가 아님을 보여 줍니다. 설계 제안으로는 쓰기 소유권과 충돌 처리, 원문 인용의 보존도 완료 조건에 넣을 수 있습니다.
또한 저장소를 구현한다면 민감정보 검증과 파일 경로 검사는 애플리케이션 책임입니다.[2] 공식 Memory tool 문서도 저장 전 민감정보 제거 검증과 모든 명령의 경로 검증을 권고합니다.[2]
💡 🔍 검증 범위: 공식 연구 글·공식 도구 문서·별도 연구 논문 원문과 공개 사용자 토론을 대조했습니다. 독립 연구와 사용자 경험은 dreaming의 직접 재현 시험이 아닙니다. 설치, 모델 호출, 성능·비용 측정은 하지 않았습니다. 보조 문서는 11월 10일 확인한 현재 문서이며, 그 세부 내용을 11월 9일 당시 배포 명세로 소급하지 않습니다.
이 글의 설계 제안을 세 가지로 줄이면 다음과 같습니다.
더 많은 기억을 넣기 전에, 오늘의 판단을 방해하는 어제의 메모를 찾아 고칠 수 있는지부터 점검해 보세요.
[1] https://www.anthropic.com/research/components-of-agent-memory — memory [2] https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool — memory-tool [3] https://news.ycombinator.com/item?id=50402212 — hn-memory [5] https://arxiv.org/html/2505.16067v2 — memory-study