코난쌤 블로그

에이전트 메모리, 모델 업그레이드에서 살아남는 포맷은? (arXiv 2609.05339)

11 min read

결론 먼저

업그레이드 배포 다음 날, 에이전트가 지난 몇 달간 쌓은 기억을 갑자기 잊기 시작하는 장면을 상상해 보세요. 저장소 파일은 한 글자도 안 바뀌었습니다. 바뀐 건 읽는 모델 하나뿐이구요. arXiv 2609.05339(Goyal, Ray)는 바로 이 지점을 4가지 메모리 포맷으로 측정했습니다. 기준일 2026-09-08, arXiv v1(2026-09-04 게시) 기준으로 정리했습니다.

핵심은 이겁니다. 스키마를 고정한 지식그래프(KG-fixed)는 쓰는 모델을 바꿔도 정확도 변화가 +0.0004±0.0020로 사실상 0입니다.

모델이 요약한 노트(NOTES)는 방향에 따라 −13.3pp에서 +9.9pp까지 출렁입니다. 포맷 선택이 곧 업그레이드 내성이라는 뜻이에요.

포맷저장 방식모델 교체 후 변화주요 리스크
LC-RAW원본 히스토리 전체±0.1pp (작성자 없음)컨텍스트 비용
RAG청크 + 벡터 인덱스±0.1pp (작성자 없음)검색 실패, 임베딩 버전
NOTES모델 요약 노트−13.3 ~ +9.9pp작성 모델 결손 재현 불가
KG-fixed고정 스키마 트리플+0.0004±0.0020스키마 커버리지 한계

4가지 메모리 포맷 비교

실험 설계: 쓰는 모델과 읽는 모델을 분리했습니다

writer가 히스토리를 메모리로 저장하고, reader가 그 저장소로 질문에 답합니다. 업그레이드 후에는 A가 쓴 저장소를 B가 읽습니다. B가 자기 저장소를 읽을 때와 비교하니 이동 손실만 딱 분리되죠.

  • 히스토리 48개, 히스토리당 정확 일치 질문 160개
  • 답 코드를 무작위화해서 사전학습 암기로 못 맞추게 차단
  • 모델: Llama-3.1-8B-Instruct, Qwen2.5-7B-Instruct-1M (둘 다 10B 미만, 로컬 서빙)
  • 임베더: BAAI/bge-large-en v1.0 → v1.5 (둘 다 1024차원)
  • 4개 본실험을 사인된 Git 태그로 선등록, 5pp 행동 기준, Holm 보정

실험 설계 개요

반복 읽기 변동이 0.0016이라 보고된 효과보다 훨씬 작습니다. 정확 일치 점수라 모델 채점자 편향도 없구요.

NOTES는 작성 모델에 묶입니다

Llama가 쓴 노트를 Qwen이 읽으면 13.3pp가 떨어집니다. 방향을 뒤집으면 Qwen 노트가 Llama를 9.9pp 올립니다. 평균은 0에 가까운데, 큰 두 효과가 상쇄된 결과예요. 평균으로 보면 “이전 잘 됨”처럼 보이는 함정입니다.

원인은 요약 품질 차이입니다. 160KiB 여유 예산 실험에서 Qwen은 필요 증거의 85.6%를 143KiB로 담았고, Llama는 64.5%를 159KiB로 담았습니다. 바이트 예산이 같아도 남기는 정보량이 다릅니다.

진단 분해가 더 뾰족합니다. NOTES 손실의 80%가 저장 시점에 이미 발생했습니다(0.467/0.584). 노트 안 검색 실패는 6%에 그칩니다.

쓰는 시점에 없어진 사실은 읽는 모델이 아무리 좋아도 복구가 안 돼요. 스타일만 새 모델에 맞게 다시 써도 −0.012~−0.042, 회복이 없었습니다. Llama는 재작성의 46%에서 식별자를 그냥 떨어뜨렸구요.

RAG는 검색이 먼저 무너집니다

같은 질문으로 원본 전체 읽기(LC-RAW)는 0.7120.911인데 RAG는 0.5350.565에 머뭅니다. 검색기가 필요한 증거를 건네주는 비율이 60% 안팎이라서예요.

증거 청크를 직접 밀어 넣으면 0.88~0.95로 뜁니다. 손실 분해에서 RAG 결손의 81%가 검색 단계입니다(0.364/0.450). 청크 자체 손실은 0.005에 불과해요.

저장은 멀쩡한데 꺼내는 데서 깨지는 겁니다. 근데 이건 업그레이드 전에도 그랬다는 점이 포인트입니다. 새 reader 모델 탓으로 돌리기 전에 검색 품질부터 따로 재야 해요.

이 파이프라인은 512자 청크, cosine top-8, reranker 없음이라 절대치는 보수적입니다. 그래도 원리는 그대로예요. reader가 받지 못한 증거는 종합할 수 없습니다.

임베딩 혼합 인덱스는 조용히 점수를 깎습니다

임베딩 모델을 v1.0에서 v1.5로 올릴 때 전부 재임베딩하면 +11.90pp입니다. 이전 벡터를 절반 섞은 50/50 혼합 인덱스는 +4.96pp에 그칩니다. 업그레이드 이득의 약 60%를 통째로 잃어요.

무서운 건 실패가 조용하다는 점입니다. 두 버전 모두 1024차원이라 차원 에러가 안 나고, 서비스는 멀쩡히 돌아갑니다. 두 공간 간 코사인이 0.904로 동일 모델 판정 기준 0.999에 못 미치지만, 시스템은 알려주지 않아요. 오래된 벡터부터 검색 품질이 깎입니다.

안전한 방법은 단순합니다. 새 임베더로 별도 인덱스를 통째로 만들고, 검증 후 컷오버하면 됩니다. 점진 전환이 필요하면 벡터 공간을 사일로로 격리하고 인덱스 버전별로 질의를 라우팅하세요.

수리는 원본 히스토리가 있을 때만 됩니다

깨진 저장소를 고치는 실험도 실무에 유용합니다.

수리 방법90% 목표 성공방향별 결과중간 비용
NOTES 재작성(저장소만)0 / 480/48, 0/48회복 불가
NOTES 재구성(원본 보유)34 / 4834/48, 0/48약 $0.76
RAG 재임베딩48 / 4848/48, 48/48약 $0.013
KG 스키마 재구축48 / 4848/48, 48/48사실상 $0

저장소만 가지고 노트를 다시 쓰는 수리는 48건 전부 90% 회복에 실패했습니다. 사라진 증거는 저장소에 없으니까요.

원본 히스토리를 보관하고 있으면 Qwen 기준 34/48을 90%로 복구했고, 95% 목표 28건, 99% 목표 22건도 성공했습니다. Llama는 출력 토큰 한도에 걸려 0건이었구요.

구조 포맷 수리는 싸고 안정적입니다. RAG 재임베딩은 96건 전부 약 $0.013에 끝나요.

핵심 결과 4분할

실무 체크리스트

  • 마이그레이션은 방향별로 테스트하세요. A→B와 B→A가 다르게 나옵니다.
  • 임베딩 업그레이드는 혼합 금지. 별도 인덱스를 만들고 검증 후 컷오버하면 됩니다.
  • 압축 노트만 저장하지 마세요. 증거 커버리지를 모델별로 측정하고, 원본 히스토리는 수리용으로 보관하세요.
  • 에이전트가 이상한 답을 하면 reader 모델부터 의심하지 말고 저장 단계와 검색 단계를 분해해 보세요. 손실은 대부분 업스트림에서 납니다.
  • 저장소 메타데이터에 writer 모델, 임베더 버전, 스키마 버전을 기록하세요. 회귀 추적이 빨라집니다.

더 실습해보고 싶은 분들께

에이전트 메모리와 하네스를 직접 만져보고 싶다면 아래 두 가지를 추천합니다.

자주 묻는 질문

  • 모델을 바꾸면 에이전트 메모리는 무엇이 먼저 깨지나요? 이 실험에서는 NOTES 저장 손실과 RAG 검색 실패가 먼저였습니다. KG 고정 스키마는 거의 그대로 유지됐습니다.
  • 임베딩 모델 바꿀 때 기존 벡터를 섞어도 되나요? 50/50 혼합 인덱스는 재임베딩 대비 이득의 60%를 잃었습니다. 차원이 같아도 에러 없이 실패해서 별도 인덱스 컷오버가 안전합니다.
  • 요약 노트가 깨졌을 때 복구 방법이 있나요? 저장소만 다시 쓰면 90% 회복에 전부 실패했습니다. 원본 히스토리를 보관한 경우에만 34/48이 회복됐습니다.
  • 이 실험 결과를 그대로 내 서비스에 적용해도 되나요? 7~8B급 오픈웨이트 모델 2개, 단일 교차 이전, 합성 히스토리 48개 범위입니다. 절대 수치보다는 방향별 테스트, 인덱스 격리, 원본 보존이라는 설계 원칙으로 가져가는 게 맞습니다.

출처

그래프 뷰