AtomMem: 언제 기억하고 언제 고칠지 학습하기

Yupeng Huo 외 · Learnable Dynamic Agentic Memory with Atomic Memory Operation

목차

긴 문서를 차례로 읽는 에이전트를 만들 때, 매번 요약을 덮어쓰면 초반의 중요한 단서가 사라질 수 있다. 모든 단서를 벡터 저장소에 넣어도 나중에 어떤 내용을 찾고 고칠지는 여전히 결정해야 한다. AtomMem은 이 결정을 강화학습으로 익히게 하며 저장 API를 추가한 것과 과제에 맞는 기억 정책을 학습한 것을 구분해 볼 근거를 제공한다.

Yupeng Huo 외의 _AtomMem: Learnable Dynamic Agentic Memory with Atomic Memory Operation_을 읽는다. 아래 설명과 수치는 2026년 3월 27일 수정된 arXiv v3 프리프린트 기준이다. AtomMem 원문 · PDF

같은 새 정보도 과제에 따라 다르게 남긴다

사용자의 목표가 X에서 Y, Z로 바뀌었다고 하자. 질문이 “현재 목표는?”이면 Z만 남겨도 답할 수 있다. “처음 목표는?”이면 X를 버리는 순간 답을 잃는다. 원문 첫 그림이 지적하는 것은 이 차이다. 무조건 최신 요약으로 교체하는 규칙은 질문이 요구하는 기억을 보존하지 못할 수 있다.

AtomMem은 기억을 만드는 Create, 질의로 찾는 Read, 기존 항목을 고치는 Update, 항목을 지우는 Delete를 모델의 행동으로 노출한다. 모델은 현재 입력과 보이는 기억을 읽고 필요한 행동들을 출력한다. 수정 연산은 순서대로 실행되므로 Create → Update와 Update → Create는 같은 명령 집합이라도 다른 상태를 만들 수 있다.

여기서 atomic은 기억 도구를 기본 연산으로 분해했다는 뜻이다. 데이터베이스 트랜잭션의 원자성이나 여러 에이전트가 동시에 수정할 때의 안전성을 보장한다는 뜻은 아니다. CRUD로 여러 상태를 표현할 수 있다는 주장도 모델이 항상 올바른 상태를 선택한다는 보장과 구분해야 한다. AtomMem 원문

저장 장치는 FAISS 벡터 데이터베이스이고 기본 검색 임베딩은 Qwen3-embedding-0.6B다. 별도로 scratchpad라는 작업 메모를 매 단계 모델에 보여 준다. 질문, 이미 찾은 단서, 아직 부족한 정보를 여기에 남길 수 있다. 벡터 저장소 전체는 매번 보이지 않으며 모델이 만든 질의로 관련 항목을 검색한다. 기본 설정에서는 여섯 항목을 가져온다.

저장과 관측은 다르다. Create로 사실을 남겼더라도 이후 문맥에서 모델이 자동으로 그 사실을 전부 아는 것은 아니다. scratchpad는 매번 보이지만 선택 검색 결과는 이전 단계의 Read 요청을 통해 다음 단계에 들어온다.

이 때문에 원문은 기억을 부분 관측 의사결정 문제, POMDP로 다룬다. 전체 상태에는 저장소가 들어 있지만 현재 모델이 보는 것은 새 입력과 작업 메모, 선택된 검색 결과뿐이다. 어떤 질의로 무엇을 읽을지 정하는 행동이 다음 판단의 정보 자체를 바꾼다. 기억은 답변 뒤에 붙는 보관함이 아니라 미래에 어떤 증거를 다시 볼 수 있을지 결정하는 상태가 된다. 기억 상태와 관측

CRUD로 임의의 기억 상태를 표현할 수 있다는 저자의 완전성 논거도 이 관점에서 제한해서 읽어야 한다. 저장한 항목을 바꾸는 데 충분한 연산이 있어도 버린 단서를 다시 찾거나 아직 모르는 정답에 필요한 정보를 보존하는 문제는 남는다. 예산이 유한하고 관측이 불완전하면 도달할 수 있는 상태 중 어느 것을 골라야 하는지가 여전히 어려운 문제다. 또 scratchpad의 매 단계 표시와 유사도 기반 TopK 검색은 사람이 정한 규칙으로 남는다. 제안은 기존 기억 규칙 위에서 모델이 선택할 행동을 넓힌 것으로 평가할 수 있다. 기억의 모든 규칙을 없애지는 않았다.

작은 기억 상태를 따라가 보기

다음은 원문의 연산과 관측 순서를 설명하기 위한 가상 실행 추적이다. 학습된 모델을 실행한 결과나 논문의 실제 사례를 복사한 것이 아니다. 질문은 “탐사선 A를 만든 연구소는 어느 도시에 있는가?”이고 처음 기억은 비어 있다.

단계와 새 입력선택한 연산저장소와 작업 메모의 변화
1. “A는 북극연구소가 제작했다.”Create항목 1에 A → 북극연구소 저장. 작업 메모에는 연구소 소재지가 아직 없다고 기록
2. “남극연구소는 해솔시에 있다.”필요한 사실과 분리해 Create항목 2에 남극연구소 → 해솔시 저장. 이름이 비슷해도 질문의 연구소와 합치지 않음
3. “북극연구소는 별빛시에 있다.”Create, 이어서 Read("A 제작 연구소")항목 3에 북극연구소 → 별빛시 저장. 항목 1을 다시 찾도록 질의
4. 항목 1이 검색되어 보임Update(1, "A → 북극연구소 → 별빛시")두 단서를 결합한 근거를 항목 1과 작업 메모에 유지
5. 이 단일 질문에 대한 답이 완성됨필요하다면 Delete(2)무관한 남극연구소 항목을 지우고 별빛시로 답함

세 번째 단계에서 새로 받은 소재지만 보고 답하면 그것이 A와 연결되는지 확인하지 못한다. Read는 앞서 얻은 제작 연구소를 다시 관측하게 해 주고 Update는 두 관계를 하나의 재사용 가능한 기억으로 묶는다. 반대로 남극연구소 정보까지 합치면 문장은 더 풍부해져도 답의 근거는 틀린다.

마지막 삭제도 항상 옳은 규칙은 아니다. 다음 질문이 남극연구소 소재지라면 항목 2가 필요하다. 논문은 독립 과제를 시작할 때 기억을 비우므로 이 예의 삭제 판단도 현재 과제의 질문 범위 안에서 해석해야 한다. 여러 날에 걸친 사용자 기억을 축적하는 제품에는 다른 문제가 있다.

원문 사례에서도 정보가 부족할 때는 단서를 저장하고 누락된 사실을 검색하며 필요한 사실이 모두 모였을 때는 결론으로 기존 기억을 수정한다. 연산 이름보다 입력의 충분성에 따라 선택이 달라지는 점이 제안의 중심이다. AtomMem 사례

성공한 답이 기억 정책을 바꾼다

CRUD를 호출할 수 있는 모델에 프롬프트만 주는 것으로 학습은 끝나지 않는다. AtomMem은 같은 과제를 여러 번 수행한 궤적을 모아 최종 과제 보상을 비교하고 GRPO(Group Relative Policy Optimization)로 출력 정책을 조정한다. 궤적은 문서 읽기나 웹 검색, 기억 연산, 최종 답변까지 이어지는 행동 기록이다.

QA의 보상은 답이 정답과 정확히 일치하는지, 웹 과제의 보상은 LLM 판정 결과다. 기억 하나를 잘 저장할 때마다 별도 보상을 주지 않는다. 먼저 같은 과제 실행 그룹의 평균 보상을 구한다. 각 실행의 보상에서 이 평균 보상을 뺀 값을 기억 연산을 포함한 전체 출력 토큰에 적용한다.

예를 들어 네 실행의 보상이 1, 1, 0, 0이면 평균은 0.5다. 성공한 실행은 +0.5, 실패한 실행은 −0.5를 받는다. 이는 계산 방식을 보여 주는 가상 수치다. 실제 실험의 그룹 크기는 16이다. 한 실행이 성공했다는 사실만으로 그 안의 모든 삭제가 도움이 되었다고 판정할 수는 없다. 저자도 개별 기억의 기여를 정밀하게 배분하는 문제를 한계로 남긴다. AtomMem 학습 방법

이 정책은 저장소 구현과 별개다. FAISS를 다른 저장 장치로 바꾸거나 동일한 CRUD API를 만드는 것만으로 아래 학습 결과를 얻었다고 볼 수 없다.

학습 효과를 해석할 때도 한 구분이 필요하다. 보상은 기억 명령뿐 아니라 검색 질의와 최종 답변을 포함한 출력 정책에 적용된다. 그러므로 RL 전후 차이는 기억 행동을 포함한 에이전트 전체를 학습한 효과다. 기억 API를 주는 것보다 정책 학습이 유리했다는 주장은 뒷받침하지만 증가분 모두가 더 좋은 저장·수정 판단에서 왔다고 분리하지는 못한다. 기억 선택기를 고정한 채 나머지만 학습한 모델과 비교하면 그 기여를 더 좁혀 볼 수 있다. 원문의 연산 제거 실험은 아래에서 확인하되, 이런 분리 비교를 대신하는 것으로 읽지는 않는다.

학습 전후와 경쟁 방법을 같은 표에서 읽기

모든 비교 에이전트의 기반 모델은 Qwen3-8B다. 긴 문서 QA는 HotpotQA, 2WikiMultiHopQA, MuSiQue에 무관한 문서를 섞고 과제마다 질문 1~10개를 함께 제시한다. 200문서, 약 28K 토큰으로 학습하고 800문서, 약 112K 토큰까지 평가한다. 문서를 차례로 처리한 뒤에는 기억을 사용해 답한다. AtomMem의 기본 입력 조각은 약 4K 토큰이다.

아래는 원문 표 1에서 비교 판단에 필요한 다섯 방법을 추린 결과다. Vanilla RAG, Generative Agents, Mem0 행은 생략했다. QA 수치는 정답 일치 성능의 백분율이며 모두 저자 보고값이다.

방법HotpotQA 200 / 800문서2Wiki 200 / 800문서MuSiQue 200 / 800문서
Full Context63.5 / 62.055.7 / 49.242.8 / 41.9
A-Mem73.5 / 70.462.7 / 57.147.1 / 41.6
MemAgent76.5 / 71.165.8 / 57.754.7 / 44.5
AtomMem, RL 없음65.9 / 60.152.8 / 55.047.8 / 40.0
AtomMem, RL 적용77.8 / 72.967.5 / 62.555.1 / 48.5

웹 과제는 Asearcher 데이터로 학습하고 GAIA와 WebWalkerQA에서 평가한다. Google 검색과 Jina URL Reader를 제공하며 과제당 웹 도구 호출은 최대 40회다. 다음 두 열은 웹 과제 성능의 백분율이다. 마지막 열은 원문에서 QA 여섯 설정과 웹 두 설정을 함께 평균한 값이다. 여덟 설정의 혼합 평균으로 읽어야 한다.

방법GAIAWebWalkerQA원문 전체 평균
Full Context23.329.546.0
A-Mem30.129.051.4
MemAgent33.050.056.7
AtomMem, RL 없음35.245.650.3
AtomMem, RL 적용37.448.758.8

AtomMem v3 표 1의 선택 행을 QA와 웹으로 나누어 재구성했다. 실험 원문

RL 없는 AtomMem과 학습한 AtomMem의 평균 차이는 58.8 − 50.3 = 8.5퍼센트포인트다. 같은 CRUD 인터페이스가 있어도 정책 학습 여부가 결과를 바꾼다. 하지만 WebWalkerQA에서는 MemAgent가 1.3퍼센트포인트 높다. 평균 1위가 모든 개별 설정의 1위라는 뜻은 아니다. 800문서 실험도 같은 QA 계열에서 입력량을 늘린 결과이므로 새로운 업무 영역에 대한 일반화를 입증한 것은 아니다. 표 1에는 평가 표본 수와 반복 실행의 오차 범위가 제시되지 않아 작은 점수 차이의 통계적 확실성까지 판단하기 어렵다.

기반 모델은 같아도 입력 처리 방법은 다르다. Full Context는 YaRN으로 문맥을 128K까지 확장하고 전체 질문을 한꺼번에 넣는다. RAG는 개별 문서를 저장한 뒤 질문으로 여섯 문서를 검색한다. A-Mem 등 정적 기억 방법은 AtomMem과 같은 입력 분할을 사용하지만 기억 구성 과정이 다르다. MemAgent는 같은 학습 하이퍼파라미터와 난수 시드로 구현했다고 저자가 밝힌다. 이 비교는 동일 기반 모델 위의 전체 기억·입력 처리 방식 비교이며 저장 API만 바꾼 통제 실험으로 읽으면 안 된다. 비교 구현

자주 쓰는 연산과 꼭 필요한 연산은 다르다

기억 수정이 왜 필요한지 확인하려면 연산을 뺀 결과를 보아야 한다. 원문 표 2의 전체 행을 옮겼다. 단위는 QA 성능 백분율이다.

구성HotpotQA2WikiMuSiQue
AtomMem77.867.555.1
Update 제거71.462.647.9
Delete 제거76.567.354.2
scratchpad 제거71.856.346.0
외부 저장소 제거69.259.443.9
둘 다 제거25.627.112.1

AtomMem v3 표 2의 재구성. 원문 괄호의 감소값은 생략했다. 연산·구성 실험

MuSiQue에서 Update를 없애면 55.1 → 47.9, 7.2퍼센트포인트 떨어진다. Delete 제거의 하락은 0.9퍼센트포인트다. 원문은 괄호 값을 상대 감소라고 설명하지만 예를 들어 55.1 − 47.9 = 7.2이므로 표의 숫자는 절대 퍼센트포인트 차이와 일치한다. 상대 감소율은 7.2 / 55.1 ≈ 13.1%다. 이 둘을 섞으면 손실 크기를 다르게 읽게 된다.

기본 QA는 서로 충돌하지 않는 사실을 모으는 과제가 많다. 삭제 효과가 작다는 결과를 “삭제 기능은 필요 없다”로 일반화하기 어렵다. 저자들은 HotpotQA를 기억 최대 20항목으로 제한해 다시 학습했다. 초과 항목은 버렸고 프롬프트도 용량 제한을 알리며 삭제를 더 사용하도록 바꿨다. 이때 Update와 Delete 사용은 늘고 Create와 Read는 줄었다. 용량과 프롬프트가 함께 바뀌었으므로 용량만의 효과로 분리되지는 않는다. 이 추가 분석은 행동 빈도 변화이며 제한 환경의 정확도 비교표를 대신하지 않는다. 용량 제한 실험

scratchpad와 외부 저장소를 각각 빼도 성능이 낮아진다. 앞의 예에서 “소재지가 아직 없다”는 작업 상태와 A → 북극연구소라는 개별 근거가 맡는 역할이 다른 것처럼 항상 보이는 작업 메모와 필요할 때 찾는 저장소가 서로 보완한다. 다만 구성 제거 실험이 네트워크 장애, 검색 타임아웃, 데이터 손상 때의 자동 복구까지 검증한 것은 아니다.

검색 개수와 임베딩도 결과의 일부다

정책을 학습해도 검색기가 필요한 단서를 내주지 않으면 결합할 수 없다. 원문 표 3에서 입력 조각을 4,096토큰으로 고정한 세 설정은 다음과 같다. 평균은 QA 세 데이터셋 성능의 산술평균이며 단위는 백분율이다.

한 번에 검색하는 기억 항목 수HotpotQA2WikiMuSiQue평균
374.264.854.664.5
676.967.555.166.5
1277.469.654.567.2

AtomMem v3 표 3의 4,096토큰 행만 재구성했다. 검색 설정 분석

검색 항목을 3개에서 6개로 늘린 평균 차이는 2.0퍼센트포인트다. 6개에서 12개로 늘리면 0.7퍼센트포인트 늘지만 MuSiQue는 낮아진다. 이 실험이 다루는 추론은 주로 2~4단계의 사실 연결이어서 더 많은 기억을 반환한다고 모든 질문이 좋아지는 것은 아니다.

표 4의 검색 임베딩 비교에서도 QA 평균은 무작위 선택 59.1, Qwen3-embedding-0.6B 66.5, 8B 68.2다. 0.6B와 무작위 선택의 차이는 7.4퍼센트포인트이고 8B로 확대한 추가 차이는 1.7퍼센트포인트다. 이 비교에는 임베딩 추론 지연이나 금전 비용이 붙어 있지 않아, 큰 임베딩을 쓰는 것이 경제적으로 더 낫다고 판단할 수는 없다.

기억 선택 방식QA 세 데이터셋 평균, %
무작위 선택59.1
Qwen3-embedding-0.6B66.5
Qwen3-embedding-8B68.2

AtomMem v3 표 4의 평균 열에서 4B 행을 생략했다. 임베딩 비교

표 3·4의 기본 설정은 HotpotQA 76.9로 주 결과 표의 77.8과 다르다. 원문에서 그 차이의 이유를 분명히 설명하지 않으므로 여기서는 각 실험 안의 비교만 사용하고 주 결과를 대체하지 않는다.

정확도 개선에는 학습과 추론 비용이 붙는다

학습은 NVIDIA A800에서 수행했다. 저자가 적은 수렴 비용은 GPU 여덟 장으로 약 2~3일이다. 아래는 원문 표 6의 시간과 호출 수를 재구성했다. 출력 토큰 열은 생략했다.

방법경과 시간, 초/과제평균 LLM 호출/과제평균 검색 호출/과제
AtomMem97.610.910.9
MemAgent49.78.00.0
Mem0247.812.988.6
Generative Agents416.0375.9418.0
A-Mem662.4400.0402.0

AtomMem v3 표 6의 저자 보고값. 효율 분석

AtomMem은 이 비교에서 일부 정적 기억 방법보다 빠르지만 MemAgent보다 느리다. 97.6 / 49.7 ≈ 1.96이므로 “약간의 지연 증가”라는 표현만으로 읽기에는 차이가 크다. 도구를 포함한 더 긴 프롬프트와 저장소 검색이 추가 비용이라는 것이 저자의 설명이다.

효율 분석에는 이 표에 사용한 과제 집합과 표본 수, 추론 하드웨어·배치 조건을 충분히 명시하지 않는다. 따라서 초/과제 값은 해당 저자 실험의 관측으로 두고 다른 서비스의 응답 지연이나 사용자 요청 처리량으로 옮기지 않는 편이 맞다. 학습 GPU 비용, 저장소 비용, 추론 시간을 모두 포함한 금전 비용은 비교하지 않았다.

도입 전에 질문 범위와 삭제 권한을 정한다

AtomMem을 시험해 볼 만한 조건은 문서를 여러 단계로 읽으며 서로 다른 단서를 보존·결합해야 하고 최종 정답이나 성공 보상을 안정적으로 정의할 수 있는 경우다. 반대로 짧은 문서 몇 개를 한 번 검색해 답하는 작업이라면, 먼저 단순 RAG나 요약 방식으로 충분한지 확인하는 편이 비용 면에서 유리할 수 있다. 이는 논문의 결과를 적용할 때의 판단이지, 별도로 측정한 제품 비교가 아니다.

장기 사용자 기억으로 확장할 때는 과제 간 초기화 가정이 먼저 달라진다. 사용자 취향을 고치는 것, 과거 근거를 지우는 것, 다른 사용자의 기억을 읽는 것은 각각 다른 권한과 보존 규칙을 요구한다. 논문의 학습 정책이 과제 성공을 높였다는 사실로 이 규칙을 대신할 수 없다. Update가 문장을 잘 고쳐도 원본 버전과 근거가 사라지면, 나중에 잘못된 판단을 검증하기 어렵다.

처음 적용할 실험에서는 정답률과 함께 필요한 단서를 검색하지 못한 경우, 잘못 합친 경우, 삭제 뒤 복구할 수 없게 된 경우를 나누어 기록할 수 있다. 같은 입력과 저장 예산에서 RL 없는 CRUD 모델, 학습한 정책, 단순 요약을 비교하면 저장 기능의 효과와 정책 학습의 효과가 갈린다. 이 구분을 먼저 해 두어야 “기억을 넣으니 좋아졌다”에서 멈추지 않고 어떤 기억 결정에 비용을 들일지 판단할 수 있다.

원문