Memory OS of AI Agent: AI 에이전트 기억을 운영체제처럼 관리하는 3단 메모리 프레임워크

1. 개요

Memory OS of AI Agent는 AI 에이전트의 기억을 **단기 기억(STM, Short-Term Memory) · 중기 기억(MTM, Mid-Term Memory) · 장기 개인 기억(LPM, Long-Term Personal Memory)**의 3단 계층으로 나누고, 저장(Storage)·갱신(Updating)·검색(Retrieval)·생성(Generation)을 통합적으로 관리하는 메모리 운영 프레임워크입니다.

이 논문은 EMNLP 2025 Oral로 소개되었으며, 운영체제(OS)의 메모리 관리 개념에서 영감을 받아 에이전트 메모리를 구조화합니다. 핵심은 기존 MemGPT의 2단 구조를 3단으로 확장하고, STM→MTM은 dialogue-chain 기반 FIFO, MTM→LPM은 segmented page + heat 기반 승격으로 설계했다는 점입니다. 이를 통해 긴 대화에서의 맥락 유지와 사용자 개인화 기억을 동시에 강화하는 것이 목표입니다.

팀원분께서 진행하는 스터디 자료를 바탕으로 재구성

---

2. 차별성

기존 방식의 한계와 MemoryOS의 접근

핵심 역량

• 시간 기반 계층화(Time-aware hierarchy): 최근/반복/개인 지식을 분리 저장
• Dialogue-chain FIFO 업데이트: STM에서 밀려난 대화를 page 단위로 MTM에 반영
• Segmented page 구조: 대화를 page와 segment로 조직해 주제 단위 관리
• Heat 기반 승격(heat-based promotion): 자주 쓰이고 최근성이 높은 내용을 LPM으로 승격
• 적응적 검색(adaptive retrieval): STM/MTM/LPM을 병렬 검색 후 통합
• 개인화 응답 생성(personalized generation): 검색된 기억과 사용자 프로필을 함께 활용

기여와 한계

기여

• MemGPT의 2단 메모리를 3단 시간 계층 구조로 확장
• Heat 승격 메커니즘을 도입해 장기 기억 후보를 자동 선별
• LoCoMo에서 긴 대화 기억과 개인화 유지 측면에서 강한 성능 확인

한계

• 단계 전이, 유사도 임계값, heat 임계값 등 휴리스틱이 많음
• 대화형 벤치마크 중심 검증으로, 비대화형 task 일반화는 미검증
• JSON 파일 저장, in-memory FAISS 재구성 등 운영 환경 확장성 이슈 존재

---

3. 시스템 구성 요소

주요 컴포넌트

작동 원리

[User Query]
    ↓
[STM에 최근 대화 저장]
    ↓
[STM 용량 초과?]
    ├─ No → 유지
    └─ Yes → oldest QA pop
                 ↓
          [page 변환 + dialogue chain 연결]
                 ↓
          [multi-summary 생성]
                 ↓
          [기존 MTM segment와 유사도 비교]
                 ├─ 유사 segment 존재 → 해당 segment에 병합
                 └─ 없음 → 새 segment 생성
                 ↓
          [Heat 갱신]
                 ↓
          [Heat ≥ τ ?]
                 ├─ No → MTM 유지
                 └─ Yes → LLM 분석
                              ↓
                     [user profile 갱신]
                     [user knowledge 저장]
                     [assistant knowledge 저장]

[응답 시]
    ↓
[STM 전체 + MTM 검색 + LPM 검색]
    ↓
[검색 결과 통합]
    ↓
[LLM이 개인화된 응답 생성]
    ↓
[응답도 다시 STM에 저장]

핵심 컴포넌트 상세

3-1. STM: 최근 대화 버퍼

STM은 가장 단순한 계층입니다. 최근 QA pair를 FIFO 큐에 저장하며, 임베딩이나 LLM 분석 없이 빠르게 접근 가능한 현재 문맥 저장소 역할을 합니다.

저장 형식은 다음과 같습니다.

3-2. MTM: 주제 세그먼트 메모리

MTM은 MemoryOS의 핵심입니다. STM에서 밀려난 대화를 page로 변환하고, 유사한 page들을 segment(session) 단위로 묶어 관리합니다. 여기서 segment는 논문 표현, session은 코드 표현으로 사실상 같은 개념으로 볼 수 있습니다.

MTM page 구조

MTM session(segment) 구조

Heat score

MTM에서 장기 기억 승격 여부는 heat로 결정됩니다.

기본 식은 다음 의미를 가집니다.

• H_segment = α·N + β·L + γ·R
• 실험에서는 α=β=γ=1
• 승격 임계값 τ=5

즉, 자주 참조되고, 길게 축적되며, 최근에도 사용된 주제가 hot segment가 됩니다.

3-3. LPM: 장기 개인 기억

LPM은 사용자와 에이전트의 장기적 특성을 저장하는 계층입니다. 단순한 과거 대화 저장이 아니라, MTM에서 충분히 중요하다고 판단된 내용만 추출해 구조화합니다.

LPM의 핵심은 hot segment의 unanalyzed page들만 대상으로 LLM 분석을 수행한다는 점입니다. 이 과정에서 사용자 프로필과 지식 조각을 추출하고, 이후 검색 가능한 장기 기억으로 저장합니다.

---

4. 검증된 성능

LoCoMo 벤치마크 성능

논문은 긴 기간에 걸친 대화 기억을 평가하는 LoCoMo benchmark에서 MemoryOS의 강점을 보여줍니다. 특히 GPT-4o-mini 기반 실험에서 베이스라인 대비 다음과 같은 향상을 보고합니다.

이 결과는 MemoryOS가 긴 대화에서 단순 사실 회상뿐 아니라 **맥락적 일관성(contextual coherence)**과 개인화된 기억 유지에 유리함을 시사합니다.

GVD 데이터셋 성능

GVD는 15명의 가상 사용자와 10일간 상호작용하는 멀티턴 대화 데이터셋입니다. LoCoMo보다 상대적으로 쉬운 설정으로 설명되며, MemoryOS는 여기서도 강한 결과를 보였습니다.

LoCoMo 데이터셋 구조

LoCoMo는 “며칠 전/몇 달 전에 나눈 이야기를 기억하는가”를 묻는 구조라 외부 메모리 시스템이 사실상 필수입니다.

LoCoMo QA category

검색 파라미터 k 실험

논문은 retrieval top-k를 {5, 10, 20, 30, 40}으로 실험했고, k가 커질수록 성능이 좋아지지만 일정 수준 이후 이득이 줄어든다고 보고합니다.

선정 이유는 계산 오버헤드와 성능 사이의 균형입니다.

---

5. 사용 방법

설치 방법

공개 리포지토리는 BAI-LAB/MemoryOS이며, Python 기반으로 사용할 수 있습니다. 실험 환경 단서로는 faiss-cpu, numpy, openai, streamlit 등이 사용됩니다.

pip install faiss-cpu numpy openai pandas python-dotenv requests streamlit

또는 Docker 기반 toy 환경으로 실행할 수 있습니다.

docker compose up --build

기본 사용 흐름

MemoryOS는 개념적으로 다음 순서로 동작합니다.

memoryos = MemoryOS(...)

response = memoryos.get_response(
    query="지난달에 내가 말한 취미 기억해?",
    relationship_with_user="friend"
)

print(response)

내부 처리 흐름 예시

1. 사용자 질문 입력
2. Retriever가 STM/MTM/LPM 병렬 검색
3. 최근 대화 + historical memory + user profile + knowledge를 prompt에 통합
4. LLM이 응답 생성
5. 해당 QA를 다시 STM에 저장
6. STM이 가득 차면 오래된 항목을 MTM으로 이관
7. MTM heat가 임계값을 넘으면 LPM 갱신

구현상 확인할 파일

---

6. 적용 시나리오

적합한 사용 사례

6-1. 장기 대화형 개인 비서

• 사용자의 취향, 일정, 반복 관심사를 장기적으로 유지해야 하는 경우
• 예: AI 비서, 코칭 에이전트, 멘탈 헬스 대화 시스템

6-2. 개인화 고객 응대

• 고객별 선호, 과거 문의, 반복 이슈를 기억해야 하는 경우
• 예: 프리미엄 고객 상담, 금융/보험 컨시어지

6-3. 멀티세션 에이전트

• 하루가 아니라 수주~수개월에 걸친 세션을 이어가야 하는 경우
• 예: 교육 튜터, 건강 관리 에이전트, 프로젝트 협업 에이전트

제한사항

6-4. 운영 환경 확장성

현재 구현은 short_term.json, mid_term.json, long_term_user.json 등 JSON 파일 중심 저장입니다. 사용자가 많아지면 I/O 병목과 동시성 문제가 발생할 수 있습니다.

6-5. 검색 품질 고도화 필요

현재는 embedding 기반 검색과 heat 승격이 중심입니다. 실서비스에서는 다음 보완이 필요합니다.

• keyword + vector hybrid search
• reranker 추가
• memory importance score 별도 도입

6-6. 비동기화 필요

현재 구조는 저장, 요약, 임베딩, 병합, 승격 판단이 요청 흐름에 걸릴 수 있어 응답 지연을 유발할 수 있습니다. 운영 환경에서는 다음 구조가 적합합니다.

[API Server]
  └─ 원본 대화 즉시 저장
       ↓
   [Queue]
       ↓
[Background Worker]
  ├─ MTM 요약
  ├─ 임베딩 생성
  ├─ Heat 갱신
  └─ LPM 승격

6-7. 단일 사용자 가정

제공된 MCP/PyPI와 toy 구조는 전역 USER_ID 중심 설계에 가깝습니다. 실제 비즈니스 환경에서는 멀티테넌시, 권한 분리, 사용자별 메모리 격리 설계가 필요합니다.

---

7. 결론

MemoryOS는 AI 에이전트의 기억을 단순한 대화 로그가 아니라 시간 축에 따라 계층화된 운영체제형 메모리 시스템으로 다룹니다. 특히 STM→MTM FIFO 전이, segment-page 구조, heat 기반 LPM 승격은 긴 대화에서 맥락 일관성과 개인화 기억을 동시에 확보하려는 시도로 볼 수 있습니다.

실험적으로는 LoCoMo에서 강한 성능을 보였고, “기억의 시간 구조를 어떻게 나눌 것인가”라는 질문에 구체적인 시스템 설계로 답한 점이 인상적입니다. 다만 휴리스틱 의존성, 운영 확장성, 비대화형 task 검증 부족은 향후 보완이 필요한 지점입니다.

---

8. 참고 자료

• Memory OS of AI Agent 논문
• LoCoMo 원본 데이터셋 (locomo10.json)
• Memory OS of AI Agent 정리 노트 1
• Memory OS of AI Agent 정리 노트 2