모델 업그레이드하면 에이전트 메모리가 망가지는가

핵심 요약

• 모델을 업그레이드하면 에이전트 메모리가 조용히 망가질 수 있습니다. 같은 메모리 저장소를 그대로 유지해도 새 모델이 옛 기록을 다르게 해석하는 문제(메모리 이식성)입니다. arXiv 2609.05339 · 9/4 제출.
• 메모리 형태별 이식성이 극단적으로 갈립니다. 고정 스키마 지식그래프(KG-fixed)는 교체 후 +0.0004±0.0020으로 거의 무손실, 반면 자연어로 압축한 노트(NOTES)는 +9.91 / −13.28pp로 모델에 크게 결핍됩니다.
• RAG 임베딩도 절반만 이전하면 문제입니다. 50/50 혼합 인덱스는 4.96pp만 개선 — 전체 재임베딩(11.90pp)의 일부밖에 못 얻습니다.
• 진단 분해: **NOTES 결함의 80%**는 초기 구성 시 정보 손실, **RAG 결함의 81%**는 검색 실패가 원인입니다.
• 회복 관점: NOTES의 저장소(repository)만 교체하면 48개 사례 전부가 90% 복구에 실패. 원본 히스토리를 유지하면 48 중 34가 성공했습니다.

왜 모델 업그레이드가 메모리를 깨는가

에이전트가 오래도록 같은 메모리 저장소를 쓰면 "모델을 바꾸기만 하면 문제없어"라고 생각하기 쉽습니다. 실제론 모델을 바꾸는 게 메모리를 버리는 것과 비슷한 사건입니다.

• 새 모델은 옛부터 저장된 자연어 노트를 다르게 읽습니다.
• 임베딩 버전이 섞이면 검색이 깨집니다.
• 손상된 기록은 원본 증거가 없으면 복구도 어렵습니다.

이 논문은 이 문제를 정밀하게 통제했습니다. 48개의 합성 히스토리에 무작위 응답 코드를 심고, 정확 채점(exact scoring)으로, 100억 파라미터 미만 오픈웨이트 모델 2개로 라이팅을 교체해 봤습니다. 즉 실제 작업의 잡음을 배제하고 "메모리 형태 하나" 만 바꿔가며 이식성을 잴 수 있게 했습니다.

메모리 형태별 이식성 — 실측 표

같은 히스토리를 4가지로 표현했을 때, 글쓴이(라이팅 모델) 교체가 정확도에 미치는 영향입니다.

표가 말하는 것: 구조가 고정돼 있으면(KG) 새 모델이 어떻게 읽어도 값이 안 바뀌고, 자연어로 압축된 것(NOTES)은 새 모델의 해석에 결정적으로 좌우됩니다. 그리고 임베딩은 "부분 이전"이 의미가 없을 정도로 통째로 다시 만들어야 합니다.

왜 NOTES가 결핍되고 RAG가 깨지는가

논문은 단순히 "이식성 점수가 다르다"에 그치지 않고 원인을 분해합니다.

• NOTES의 결함 80%(0.467±0.014) 는 초기 구성(construction) 시 정보가 손실된 데서 옵니다. 즉 압축 단계에서 이미 버려진 정보가 크고, 이후에 어떻게 읽든 이를 보완 못 합니다.
• RAG의 결함 81%(0.364±0.012) 는 검색 실패에서 옵니다. 절반만 새 임베딩으로 바꿨을 때 옛 조각을 못 찾는 게 주원인입니다.

즉 NOTES는 "만들 때" 상하고, RAG는 "찾을 때" 상합니다. 둘 다 라이팅(쓰는 모델)을 바꾼 직접 효과보다 우세합니다.

회복 전략 — 원본 히스토리가 생명줄

가장 실용적인 발견은 수리(repair) 관점입니다.

• NOTES의 저장소만 교체해 회복하려 하면, 48개 사례 전부가 90% 성능 회복에 실패했습니다. 압축 노트는 그 자체로 원본이 아니므로 고칠 수 없습니다.
• 원본 히스토리(LC-RAW)를 유지하면, 테스트 방향 중 하나에서 48개 중 34개가 성공적으로 회복됐습니다.

결론은 의외로 단순합니다. "요약·압축본만 남기고 원본을 버리면 영구적으로 버려진다." 메모리 손상의 가장 큰 방어막은 검증된 원본을 유지하는 것입니다.

우리 에이전트·Hermes에 적용한다면

이 연구는 최근 Astra 전환·컨텍스트 압축 논의와 바로 이어집니다.

• 모델 업그레이드 전에 메모리 형태를 점검하세요. 자연어 노트·요약 위주면 업그레이드 후 크게 결핍될 위험이 있습니다.
• RAG 임베딩을 바꾼다면 부분 이전이 무의미합니다. 반드시 전체 재임베딩을 해야 11.90pp를 온전히 얻습니다.
• 원본 히스토리는 사수하세요. 게이트·검증 로그·원문을 남겨두면, 최악의 경우에도 48 중 34처럼 회복 경로가 열립니다. 앞서 다룬 Reverify의 ledger("검증된 것만 디스크에")와 같은 방향입니다.
• 방금 만든 failure-skills의 mistake-note는 "원본 실패"도 함께 남기고, 구조화된 규칙만 승격해야 합니다. 구조화만 남기고 원문을 버리면, 이 논문이 경고한 NOTES 함정에 빠집니다.

균형 판단 — 한계

• 통제 실험 한계: 48개 합성 히스토리 + 100억 파라미터 미만 오픈웨이트 모델 2개로 측정됐습니다. 프론티어 모델·실제 운영 메모리 규모에선 절대 수치가 달라질 수 있습니다.
• "구조화가 최고"인 건 아님: KG-fixed가 이식성은 최고지만, 표현력·유연성은 자연어 노트보다 낮다는 비용이 있습니다. 이식성과 표현력을 함께 봐야 합니다.
• 재평가 비용: 원본 유지 + 모델 전환 시 전체 재임베딩은 비용이 듭니다. 트레이드오프를 명시적으로 계산해야 합니다.

상황별 결론

• 자주 모델을 바꾸는 팀 → 메모리 형태를 고정 스키마(KG) + 원본 보존 조합으로 설계하세요. 이식성·복구성 둘 다 확보됩니다.
• RAG만 쓰는 경우 → 임베딩 업그레이드는 통째로 하세요. 50/50 혼합은 절반 효과도 못 얻습니다.
• 요약·노트로 메모리를 줄였을 때 → 원본 로그·증거를 별도로 백업하세요. 이것만이 모델 교체 후 복구의 유일한 안전망입니다.

시작점으로 권하는 것 — 다음 모델 업그레이드 전에, "지금 메모리·스킬·컨텍스트에서 자연어 요약/노트"로 된 부분이 있는지 찾아보세요. 있다면 원본 히스토리를 따로 남겨두는 백업부터 하는 걸 권합니다. 이 한 줄이 모델 전환 시 데이터 손실의 가장 큰 방어막이 됩니다.

참고 링크

• Does Your Agent's Memory Survive a Model Upgrade? — arXiv 2609.05339 · 9/4 제출, under review
• SkillsBench — arXiv 2602.12670 · 스킬 효과 벤치마크