AI 에이전트 메모리, 다 저장도 다 요약도 답이 아니었다

에이전트한테 며칠짜리 작업을 맡겨 본 사람은 안다. 진짜 병목은 모델 성능이 아니라 기억이다. 나도 블로그 발행 자동화를 매일 에이전트에 맡기다가 이런 경고를 봤다.

WARNING: MEMORY.md is 26.1KB (limit: 24.4KB) — index entries are too long.
Only part of it was loaded. Keep index entries to one line.

마지막 줄이 핵심이다. 한도를 넘으면 일부만 로드된다. 욕심내서 다 적어두면 정작 필요한 항목이 안 읽힌다. 많이 남기려다 오히려 덜 읽히는 역설이다. 에이전트가 오래 일할수록 이 문제는 커지고, Sonnet 5처럼 에이전틱 코딩을 끝까지 밀어붙이는 모델이 나올수록 더 그렇다. 그래서 'memory layer', '에이전트 메모리'를 붙인 제품이 쏟아진다. 그런데 대부분은 두 극단 중 하나다. 다 저장하거나, 요약해서 버리거나.

Microsoft가 얼마 전 공개한 Memora는 그 사이를 노린다. ICML 2026에 실린 논문 "A Harmonic Memory Representation Balancing Abstraction and Specificity"의 공식 코드다. 이름부터 추상화(abstraction)와 구체성(specificity)의 균형을 내세운다. 왜 이게 어려운 문제인지부터 보자.

다 저장하면 흐려지고, 다 요약하면 날아간다

첫 번째 길은 다 저장하는 쪽이다. 과거 대화와 문서를 통째로 벡터DB에 넣고 필요할 때 검색해 꺼낸다. 흔한 RAG 방식이다. 문제는 쌓일수록 검색이 노이즈를 같이 끌어온다는 거다. 나는 이걸 컨텍스트 과적으로 겪었다. 자료를 많이 넣을수록 핵심 근거가 잡담에 묻히고, 옛 버전과 새 버전이 섞여 모델이 둘을 평균 내고, 토큰만 늘어 비용이 오른다. 기억을 많이 쌓는다고 잘 기억하는 게 아니다.

두 번째 길은 요약하는 쪽이다. 긴 기록을 압축해 짧게 남긴다. 검색은 빨라지고 토큰은 줄지만, 이번엔 구체적인 사실이 날아간다. "지난주에 사용자가 예약한 항공편 편명"처럼 딱 그 디테일이 필요한 순간에, 요약본에는 "여행 준비를 도왔음" 정도만 남아 있는 식이다.

그래서 추상화와 구체성은 흔히 트레이드오프로 취급된다. 요약하면 구체성을 잃고, 원본을 보존하면 검색이 둔해진다. 둘 중 하나를 고르는 문제로 본 거다. Memora의 주장은 여기서 갈린다. 둘은 반드시 맞바꿀 필요가 없다는 거다.

Memora는 기억을 세 겹으로 쪼갠다

핵심은 하나의 기억을 성격이 다른 세 층으로 나눠 저장하는 거다.

가장 아래는 메모리 값이다. 원본에 가까운 구체 정보를 그대로 보존한다. 대신 인덱싱하지 않는다. 검색 대상이 아니라 최종적으로 정확히 답할 때 꺼내 쓰는 근거다. 그 위가 기본 추상화다. 값을 정규화한 요약이고, 이쪽을 인덱싱한다. 관련된 업데이트를 하나의 기억 항목으로 통합하는 것도 이 층이다. 마지막이 큐 앵커다. 하나의 기억에 여러 의미적 진입점을 달아, 서로 다른 각도의 질문에서도 같은 기억에 닿게 하고 관련 기억끼리 연결한다.

구조를 풀어보면 의도가 분명하다. 찾을 때는 가벼운 추상화 층으로 빠르게 좁히고, 답할 때는 그 아래 보존된 값으로 정확히 채운다. 추상화로 검색 효율을 얻고 값으로 구체성을 지키니, 둘을 맞바꾸지 않아도 된다. 다 저장 방식이 검색에서 노이즈에 무너지고 요약 방식이 답에서 디테일을 잃던 지점을, 층을 나눠 각자 다른 층에 맡긴 셈이다.

내가 손으로 하던 걸 구조로 만든 것

이 설계가 낯설지 않았다. 나는 블로그 자동화에서 비슷한 걸 수동으로 하고 있었다. 장문 노트를 컨텍스트에 넣을 때 전문을 다 붙이지 않고, 핵심 요약을 넣고 원문 경로는 링크로만 건다. 모델은 요약으로 판단하다가 구체가 필요하면 원문을 참조한다. 요약본이 Memora의 추상화 층이고, 원문 링크가 값에 해당하는 얕은 버전인 셈이다.

에이전트 메모리의 진짜 승부처가 저장이 아니라 망각이라는 것도 같은 얘기다. 모든 걸 남기면 오래되고 틀린 정보가 새 판단을 오염시킨다. 망각 정책이 없는 기억은 결국 쓰레기 더미가 된다. 자는 동안 스스로 복기하는 AI를 한 달 굴려본 실험에서 내내 부딪힌 것도 결국 이 지점이었다. Memora가 관련 업데이트를 하나의 항목으로 통합한다는 건, 낡은 값을 새 값으로 갱신해 이 쓰레기화를 구조적으로 막는다는 뜻이다. 내가 색인은 한 줄로 줄이고 상세는 토픽 파일로 빼며 손으로 관리하던 걸, 이쪽은 표현 자체에 녹여둔 거다.

빼면서 더 정확하다는 걸 수치로 증명한다

방향이 그럴듯한 것과 실제로 되는 건 다르다. Memora는 두 벤치마크에서 이걸 숫자로 보였다. 600턴 안팎의 긴 대화를 다루는 LoCoMo에서 86.3%, 장기 기억을 평가하는 LongMemEval에서 87.4%로, 기존 메모리 기법들과 컨텍스트 전체를 통째로 넣는 방식을 모두 앞섰다. 특히 눈에 띄는 건 효율이다. 전체 컨텍스트를 넣는 방식 대비 토큰 소비를 최대 98%까지 줄였다.

이 조합이 핵심이다. 토큰을 극단적으로 줄이면 보통 정확도가 같이 떨어진다. Memora는 줄이면서 더 맞혔다. 빼는 게 곧 성능이라는 말을, 손해 없이 성립시킨 셈이다. 컨텍스트 과적으로 흐려지던 문제와, 요약하다 디테일을 잃던 문제를 동시에 피했다는 게 이 수치의 의미다.

다만, 아직은 제품이 아니라 방향이다

기대를 조금 눌러둘 필요는 있다. Memora는 논문에 딸린 공식 구현이지 완성된 제품이 아니다. 별은 80개 남짓, 정식 릴리스도 없고, 열린 이슈도 이제 막 붙는 단계다. 돌려보려면 ChromaDB나 Redis 같은 저장소에 OpenAI 계열 모델을 붙여야 하고, 검색 정책 학습에 GRPO나 LoRA 미세조정이 들어간다. 당장 서비스에 꽂아 쓰는 물건이라기보다, 연구 코드에 가깝다.

그래서 나는 이걸 기능 목록으로 읽지 않는다. 에이전트 메모리를 "얼마나 많이 담느냐"가 아니라 "무엇을 추상화하고 무엇을 값으로 남기느냐"의 문제로 다시 정의했다는 관점으로 읽는다. 지금 쏟아지는 메모리 제품을 고를 때, 이 질문에 분명히 답하는 쪽인지 보는 기준이 생긴다.

한도를 넘겨 일부만 로드되던 내 MEMORY.md가 알려준 것과 Memora가 가리키는 곳은 같다. 기억은 더 많이 쌓는 게 아니라, 필요한 것만 정확히 꺼낼 수 있을 때 값을 한다. 에이전트 메모리의 다음 단계는 용량 경쟁이 아니라, 무엇을 요약하고 무엇을 통째로 남길지 잘 나누는 설계에서 갈릴 거다.

---

참고: microsoft/Memora (GitHub) · 논문 (arXiv 2602.03315) · Microsoft Research 소개