MemOS 논문 정리

한 줄 요약

이 논문은 LLM의 기억을 단순한 프롬프트나 검색 결과가 아니라 운영체제가 관리하는 자원처럼 다루자고 제안한다.

핵심 제안은 MemOS다.

MemOS는 LLM의 기억을 저장하고, 불러오고, 수정하고, 폐기하고, 이전하고, 추적하는 체계를 만든다.
논문은 이를 통해 LLM이 “대답하는 시스템”에서 “기억하고 적응하는 시스템”으로 이동할 수 있다고 본다.

---

왜 LLM에 ‘메모리 운영체제’가 필요한가

현재 LLM은 많은 지식을 갖고 있다.
하지만 그 지식은 주로 모델 내부 파라미터에 묻혀 있다.

문제는 다음과 같다.

• 어떤 지식이 어디에 있는지 알기 어렵다.
• 새 지식을 반영하기 어렵다.
• 사용자 선호를 오래 유지하기 어렵다.
• 여러 에이전트나 플랫폼 사이에서 기억을 옮기기 어렵다.
• RAG는 외부 문서를 붙여 주지만, 기억의 전체 생명주기를 관리하지는 못한다.

논문의 관점은 명확하다.

LLM의 기억은 더 이상 부가 기능이 아니다.
명시적으로 관리해야 하는 핵심 자원이다.

---

LLM 메모리 연구의 흐름

논문은 LLM 메모리 연구가 세 단계로 발전했다고 정리한다.

 

첫 번째 단계는 기억을 분류하고 실험하는 시기다.
모델 안에 들어 있는 기억, 프롬프트에 임시로 들어가는 기억, 외부 검색으로 불러오는 기억이 각각 연구됐다.

 

두 번째 단계는 인간의 기억 구조를 모방하는 시기다.
장기 기억, 자기 성찰, 개인화 기억, 뇌 구조에서 영감을 얻은 검색 방식이 등장했다.

 

세 번째 단계는 기억을 실제로 관리하려는 시기다.
기억을 추가하고, 수정하고, 삭제하고, 업데이트하는 도구가 등장한다.

 

이 논문은 MemOS를 이 세 번째 단계의 확장으로 본다.
단순한 도구가 아니라 기억 운영 인프라를 만들려는 시도다.

Crop 포인트: Stage 3의 관리 영역은 이 논문이 말하는 전환점, 즉 기억을 ‘검색 대상’이 아니라 ‘운영 대상’으로 보는 관점을 보여준다.

---

다음 스케일링은 ‘메모리’에서 나온다는 주장

논문은 기존 LLM 발전이 크게 두 축으로 이어졌다고 본다.

• 더 큰 데이터와 더 큰 모델을 쓰는 사전학습
• 지시 따르기, 정렬, 추론 능력을 강화하는 후학습

하지만 저자들은 이 두 방식만으로는 한계가 온다고 본다.

모델을 계속 키우는 것은 비용이 커진다.
후학습도 점점 복잡해진다.

그래서 논문은 다음 단계로 Mem-training을 제시한다.

 

여기서 중요한 직관은 단순하다.

모델이 모든 것을 새로 학습하지 않아도 된다.
대신 경험과 지식을 기억 단위로 축적하고, 필요할 때 불러오고, 오래 쓸 것은 더 안정적인 형태로 바꾸면 된다.

Crop 포인트: 오른쪽의 Mem-training 구간은 모델 성능 향상의 다음 축을 파라미터 확대가 아니라 지속적인 기억 관리에서 찾는다는 주장을 압축한다.

---

MemOS의 핵심 아이디어

MemOS는 LLM을 위한 메모리 운영체제다.

운영체제가 파일, 프로세스, 권한, 저장소를 관리하듯이 MemOS는 LLM의 기억을 관리한다.

관리 대상은 세 가지다.

1. Parametric Memory

모델 파라미터 안에 들어 있는 기억이다.

예를 들어 언어 능력, 일반 지식, 도메인 지식, 특정 기술이 여기에 해당한다.

 

장점은 빠르다는 점이다.
추론할 때 외부에서 따로 찾지 않아도 된다.

 

단점은 수정이 어렵다는 점이다.
잘못된 지식이나 오래된 지식을 바꾸려면 비용이 크다.

2. Activation Memory

추론 중에 생기는 임시 상태다.

대화의 흐름, 최근 문맥, 현재 작업에 맞춘 반응 방식이 여기에 가깝다.

사람으로 치면 작업 기억에 가깝다.
지금 보고 있는 것, 방금 말한 것, 현재 목표를 붙잡고 있는 역할을 한다.

3. Plaintext Memory

문서, 지식 그래프, 프롬프트 템플릿처럼 명시적으로 저장된 기억이다.

장점은 수정과 공유가 쉽다는 점이다.
사용자 선호, 업무 지식, 정책 문서, 제품 정보처럼 자주 바뀌는 지식에 적합하다.

MemOS의 핵심은 이 세 기억을 따로 보지 않는 것이다.
서로 바꿀 수 있고, 합칠 수 있고, 필요에 따라 다른 형태로 승격시킬 수 있다고 본다.

Crop 포인트: 세 기억 사이의 변환 경로는 MemOS가 기억을 고정된 저장소가 아니라 계속 재구성되는 실행 자원으로 본다는 점을 보여준다.

---

MemCube: 기억의 최소 실행 단위

MemOS에서 가장 중요한 추상화는 MemCube다.

MemCube는 하나의 기억 단위다.
파일 하나처럼 보아도 되고, 작은 실행 가능한 메모리 블록으로 보아도 된다.

MemCube는 크게 두 부분으로 구성된다.

Metadata Header

기억을 어떻게 관리할지 설명하는 정보다.

예를 들어 다음 정보가 들어간다.

• 언제 만들어졌는가
• 마지막으로 언제 쓰였는가
• 어디에서 왔는가
• 누가 접근할 수 있는가
• 얼마나 중요한가
• 언제 만료되는가
• 민감 정보인지 아닌가
• 얼마나 자주 쓰였는가

이 정보가 있기 때문에 기억을 추적하고 통제할 수 있다.

Memory Payload

실제 기억 내용이다.

이 내용은 텍스트일 수도 있다.
추론 중 상태일 수도 있다.
모델 파라미터에 주입할 수 있는 패치일 수도 있다.

MemCube의 의미는 크다.

서로 다른 종류의 기억을 하나의 공통 단위로 다룰 수 있기 때문이다.
그래야 스케줄링, 권한 제어, 버전 관리, 이동, 폐기가 가능해진다.

Crop 포인트: Metadata Header와 Memory Payload의 분리는 MemCube가 ‘내용 저장’뿐 아니라 권한, 수명, 우선순위까지 함께 관리하는 단위임을 보여준다.

---

기억은 어떻게 자동으로 진화하는가

MemOS는 기억을 저장만 하지 않는다.
사용 패턴을 보고 기억의 형태를 바꾼다.

예를 들어 자주 쓰이는 텍스트 기억은 더 빠르게 불러올 수 있는 실행 상태로 바뀔 수 있다.

반대로 안정적으로 반복되는 지식은 모델 파라미터 쪽으로 흡수될 수 있다.

오래되었거나 거의 쓰지 않는 파라미터 지식은 다시 편집 가능한 텍스트 형태로 꺼낼 수 있다.

 

이 아이디어는 중요하다.

모델이 매번 모든 것을 다시 배우지 않는다.
기억을 관찰하고, 정리하고, 재배치하면서 효율을 높인다.

---

MemOS 아키텍처

MemOS는 세 계층으로 구성된다.

Interface Layer

사용자 요청을 받아 기억 관련 의도를 해석한다.

예를 들어 “이 사용자 취향을 기억해”, “이전 대화의 근거를 찾아”, “오래된 기억을 지워” 같은 요청을 Memory API나 Pipeline 호출로 바꾼다.

Operation Layer

기억을 실제로 조정하는 중심 계층이다.

여기에는 다음 기능이 포함된다.

• 어떤 기억을 불러올지 결정하는 스케줄링
• 기억의 생성, 사용, 만료, 보관을 관리하는 생명주기 제어
• 태그, 그래프, 검색 구조를 활용한 기억 조직화
• 자주 쓰는 기억을 캐싱하는 최적화

Infrastructure Layer

저장소와 거버넌스를 담당한다.

여기서는 접근 권한, 개인정보 보호, 워터마킹, 감사 로그, 저장소 연결, 클라우드·로컬 이동을 관리한다.

이 계층이 있어야 기억을 안전하게 공유하고 이전할 수 있다.

Crop 포인트: 중앙의 MemScheduler와 하단의 Governance·Vault 구조는 MemOS가 기억 검색뿐 아니라 호출, 저장, 보안, 이전을 하나의 루프로 묶는다는 점을 보여준다.

---

실행 흐름: 프롬프트가 기억이 되는 과정

MemOS의 실행은 사용자 입력에서 시작한다.

예를 들어 사용자가 “내 강아지가 도움이 필요해”라고 말한다고 하자.

MemReader는 이 문장에서 기억할 만한 사실을 뽑는다.
“사용자에게 강아지가 있다”는 식의 기억 단위가 만들어질 수 있다.

그다음 MemScheduler가 관련 기억을 찾는다.
이전 반려동물 대화, 사용자의 선호, 필요한 도메인 지식이 함께 불러와질 수 있다.

선택된 기억은 응답 생성 과정에 주입된다.
응답 후에는 새로 생긴 기억이 저장되거나, 기존 기억이 업데이트된다.

이 과정은 한 번으로 끝나지 않는다.
입력, 해석, 검색, 주입, 응답, 저장, 재사용이 계속 이어진다.

Crop 포인트: 입력에서 MemoryCube 추출, 검색, 응답 생성으로 이어지는 경로는 MemOS가 대화를 장기 기억 루프로 바꾸는 방식을 보여준다.

---

RAG와 무엇이 다른가

RAG는 외부 문서를 찾아 프롬프트에 붙이는 방식에 가깝다.

MemOS는 더 넓은 문제를 다룬다.

구분	RAG	MemOS
핵심 목적	관련 문서 검색	기억의 전체 생명주기 관리
기억 형태	주로 텍스트	파라미터, 활성 상태, 텍스트
관리 기능	검색 중심	생성, 수정, 삭제, 이전, 추적, 권한 제어
개인화	제한적	사용자·작업·에이전트 단위 기억 가능
장기 진화	약함	기억 변환과 재구성을 전제로 함

 

즉, MemOS는 RAG를 대체한다기보다 RAG를 포함할 수 있는 더 큰 운영 프레임워크에 가깝다.

---

이 논문의 강점

첫째, LLM 메모리를 하나의 시스템 문제로 재정의한다.

기존 연구는 기억을 검색, 편집, 캐시, 개인화 등으로 나누어 다루는 경우가 많았다.
MemOS는 이를 운영체제 관점에서 통합한다.

 

둘째, 기억의 형태 변환을 핵심에 둔다.

텍스트 기억, 추론 상태, 파라미터 기억이 서로 연결된다는 점은 장기적으로 중요한 설계 방향이다.

 

셋째, 거버넌스를 구조 안에 넣는다.

기억이 장기화될수록 개인정보, 접근 권한, 감사 가능성은 필수다.
MemOS는 이를 부가 기능이 아니라 인프라 계층의 핵심 기능으로 둔다.

---

읽을 때 주의할 점

이 논문은 짧은 버전이다.
따라서 실험 결과나 정량 평가보다는 개념 설계에 초점이 있다.

특히 다음 질문은 더 검증이 필요하다.

• MemCube가 실제 대규모 서비스에서 얼마나 효율적인가
• Activation Memory를 안정적으로 저장하고 재사용할 수 있는가
• Parametric Memory로의 변환이 성능과 안전성에 어떤 영향을 주는가
• 여러 모델 사이에서 기억을 공유할 때 의미가 보존되는가
• 개인정보와 사용자 통제권을 어떻게 보장할 것인가

논문의 가치는 완성된 제품 성능보다 LLM 기억 인프라의 설계 방향에 있다.

---

활용 가능성이 큰 영역

MemOS식 설계는 다음 영역에서 특히 유용할 수 있다.

개인 AI 비서

사용자의 선호, 일정, 말투, 장기 목표를 기억해야 한다.

단순한 대화 기록 저장만으로는 부족하다.
무엇을 기억하고, 무엇을 잊고, 무엇을 업데이트할지 관리해야 한다.

기업용 에이전트

기업 지식은 계속 바뀐다.
문서, 정책, 고객 이력, 프로젝트 맥락을 안전하게 관리해야 한다.

MemOS는 접근 권한과 감사 로그를 포함하기 때문에 기업 환경에 맞는 방향성을 갖고 있다.

멀티 에이전트 시스템

여러 에이전트가 협업하려면 기억을 공유해야 한다.

그러나 모든 기억을 무조건 공유하면 위험하다.
권한, 출처, 버전, 만료 정책이 필요하다.

도메인 특화 AI

의료, 법률, 금융처럼 지식이 정확하고 최신이어야 하는 분야에서는 기억 업데이트가 중요하다.

Parametric Memory와 Plaintext Memory를 함께 관리하는 구조는 이런 분야에서 의미가 있다.

---

결론

MemOS의 핵심 메시지는 간단하다.

LLM이 더 오래, 더 일관되게, 더 개인화되어 작동하려면 기억을 운영해야 한다.

프롬프트에 정보를 더 넣는 것만으로는 부족하다.
검색 결과를 붙이는 것만으로도 부족하다.

기억은 생성되고, 사용되고, 갱신되고, 폐기되고, 이전되고, 감사되어야 한다.

이 논문은 그 과정을 위한 공통 단위로 MemCube를 제안하고, 이를 운영하는 시스템으로 MemOS를 제시한다.

LLM의 다음 발전이 단순한 모델 크기 경쟁을 넘어선다면, 그 핵심 중 하나는 기억 인프라가 될 가능성이 크다.

---

Source

• Paper: MemOS: An Operating System for Memory-Augmented Generation (MAG) in Large Language Models (Short Version)
• Authors: Zhiyu Li, Shichao Song, Hanyu Wang, Simin Niu, Ding Chen, Jiawei Yang, Chenyang Xi, Huayi Lai, Jihao Zhao, Yezhaohui Wang, Junpeng Ren, Zehao Lin, Jiahao Huo, Tianyi Chen, Kai Chen, Kehang Li, Zhiqiang Yin, Qingchen Yu, Bo Tang, Hongkang Yang, Zhi-Qin John Xu, Feiyu Xiong
• Date: 2025.05.27
• arXiv: https://arxiv.org/abs/2505.22101
• PDF: https://arxiv.org/pdf/2505.22101v1