MemGPT: 운영체제처럼 기억을 관리하는 LLM

MemGPT: 운영체제처럼 기억을 관리하는 LLM

문맥 창이 정해진 LLM에게 운영체제의 가상 메모리 아이디어를 빌려 와, 모델이 스스로 함수 호출로 정보를 '디스크(외부 저장소)'에 내려 두고 필요할 때 '메모리(프롬프트)'로 올려 쓰게 한 UC 버클리의 시스템입니다. 덕분에 문맥 창보다 훨씬 긴 대화 · 문서도 다룰 수 있는 것처럼 보이게 만들었고, 지난 대화를 묻는 과제에서 GPT-4 정확도를 32.1%에서 92.5%로 끌어올렸습니다.

들어가기 전에

이 해설은 아래 내용을 안다고 보고 씁니다. 처음이라면 먼저 읽고 오면 수식과 손계산을 훨씬 쉽게 따라올 수 있습니다.

• 생성형 에이전트: 사람 행동을 흉내 내는 시뮬레이션 — 기억·반성·계획을 붙인 LLM 에이전트 25명이 가상 마을에서 사람처럼 사는 시뮬레이션
• 중간에서 길을 잃다: 언어 모델의 긴 문맥 활용 — 긴 입력의 가운데 정보를 언어 모델이 잘 못 쓰는 U자 성능 곡선을 보인 분석 논문

한눈에 보기

• 문맥 창을 늘리는 것만으로는 긴 대화 · 긴 문서 문제가 왜 다 풀리지 않는지 알게 됩니다.
• 주 문맥(프롬프트) 과 외부 문맥(회상 저장소 · 기록 저장소) 의 기억 계층을 운영체제의 RAM · 디스크에 빗대어 이해합니다.
• 기억 압박 경고(70%) · 비우기(100%) 같은 대기열 관리 규칙 을 손계산으로 따라가 봅니다.
• 함수를 연달아 부르는 하트비트(heartbeat) 로 여러 단계 검색을 하는 방식과, 대화 · 문서 과제의 결과를 읽을 수 있게 됩니다.

초록 (번역)

대형 언어 모델(LLM)은 AI에 혁신을 일으켰지만 제한된 문맥 창에 묶여 있어, 긴 대화나 문서 분석 같은 과제에서 쓸모가 제한됩니다. 제한된 문맥 창 너머의 문맥을 쓸 수 있도록, 우리는 가상 문맥 관리를 제안합니다. 이 기법은 물리 메모리와 디스크 사이의 페이징으로 확장된 가상 메모리가 있는 것 같은 착각을 제공하는 전통적 운영체제의 계층적 메모리 시스템에서 착안했습니다. 이 기법을 사용해, 우리는 LLM의 제한된 문맥 창 안에서 확장된 문맥을 효과적으로 제공하기 위해 서로 다른 저장 계층을 지능적으로 관리하는 시스템 MemGPT(MemoryGPT)를 소개합니다. 우리는 OS에서 착안한 설계를 현대 LLM의 제한된 문맥 창이 성능을 심하게 떨어뜨리는 두 영역에서 평가합니다. 하나는 문서 분석으로, MemGPT는 기반 LLM의 문맥 창을 훨씬 넘는 큰 문서를 분석할 수 있습니다. 다른 하나는 다중 세션 대화로, MemGPT는 사용자와의 장기적 상호작용을 통해 기억하고, 성찰하고, 동적으로 변화하는 대화 에이전트를 만들 수 있습니다. 실험에 쓴 MemGPT 코드와 데이터를 https://research.memgpt.ai 에 공개합니다.

무엇을 풀었나

LLM은 한 번에 볼 수 있는 토큰 수(문맥 창)가 정해져 있습니다. 논문 표 1은 사전 프롬프트 1천 토큰, 메시지당 약 50토큰을 가정하면 4천 토큰 모델은 메시지 약 60개, 8천은 140개, 12만 8천 토큰(GPT-4 Turbo)도 약 2,600개만 담을 수 있다고 정리합니다.

• 긴 대화: 몇 주 · 몇 달 이어지는 개인 비서 · 동반자 대화에서는 예전 대화가 금방 창 밖으로 밀려나, 사용자가 말한 사실 · 취향을 잊고 일관성을 잃습니다.
• 긴 문서: 연례 보고서(SEC 10-K) 같은 법률 · 재무 문서는 쉽게 백만 토큰을 넘고, 실제 분석은 여러 문서를 엮어야 합니다.
• 창을 늘리는 해법의 한계: 셀프 어텐션의 계산 · 메모리 비용은 길이의 제곱으로 늘고, 긴 문맥 모델도 중간에 있는 정보를 잘 못 쓴다는 연구('중간에서 길을 잃음')가 있습니다.

논문의 질문은 이것입니다. 고정된 문맥 창 모델을 그대로 쓰면서, '무한한 문맥'이 있는 것 같은 착각을 줄 수 있을까?

핵심 아이디어

12345678910111213flowchart TB
  EV[이벤트: 사용자 메시지 · 시스템 경고 · 예약 작업] --> Q
  subgraph MAIN[주 문맥 = 프롬프트 토큰]
    SI[시스템 지시: 읽기 전용]
    WC[작업 문맥: 핵심 사실 · 페르소나, 함수로만 수정]
    Q[FIFO 대기열: 최근 메시지 + 맨 앞에 재귀 요약]
  end
  MAIN --> LLM[LLM 프로세서]
  LLM --> FX[함수 실행기]
  FX -->|저장 · 검색| AR[(기록 저장소 archival: 임의 길이 텍스트, 벡터 검색)]
  FX -->|과거 메시지 검색| RC[(회상 저장소 recall: 모든 메시지 기록)]
  FX -->|결과를 대기열에 추가| Q
  FX -->|request_heartbeat=true 면 곧바로 다시 추론| LLM

1. 기억 계층: 프롬프트는 RAM, 데이터베이스는 디스크

직관. 컴퓨터는 RAM이 작아도, 당장 안 쓰는 데이터를 디스크에 내려놓고(페이지 아웃) 필요할 때 다시 올려(페이지 폴트 후 페이지 인) 큰 메모리가 있는 것처럼 보이게 합니다. MemGPT는 프롬프트를 RAM, 외부 데이터베이스를 디스크로 보고 LLM 스스로 그 이동을 결정하게 합니다. 책상(프롬프트) 위에는 지금 필요한 서류만 두고, 나머지는 서랍장(저장소)에 넣었다가 꺼내 보는 것과 같습니다.

단계별 설명 — 주 문맥(프롬프트 토큰)은 세 부분으로 나뉩니다.

1. 시스템 지시: 읽기 전용. MemGPT의 제어 흐름, 기억 계층별 용도, 함수 사용법을 담습니다.
2. 작업 문맥(working context): 크기가 정해진 읽기 · 쓰기 텍스트 블록. 함수 호출로만 수정합니다. 대화에서는 사용자에 대한 핵심 사실 · 취향, 에이전트 페르소나를 적어 둡니다.
3. FIFO 대기열: 최근 메시지(사용자 · 에이전트 메시지, 시스템 경고, 함수 입출력)의 굴러가는 기록. 첫 칸에는 밀려난 메시지들의 재귀 요약 이 들어갑니다.

외부 문맥은 두 저장소입니다.

• 회상 저장소(recall storage): 모든 메시지가 저장되는 메시지 데이터베이스. 대기열에서 밀려난 메시지도 여기 남아 검색할 수 있습니다.
• 기록 저장소(archival storage): 임의 길이 텍스트를 담는 읽기 · 쓰기 데이터베이스. 문서 실험에서는 PostgreSQL + pgvector(HNSW 인덱스)를 썼습니다.

예시 (논문 그림 4 요약). 사용자가 "사실 James와는 헤어졌어"라고 하면, MemGPT는 working_context.replace("Boyfriend named James", "Ex-boyfriend named James")를 호출해 작업 문맥의 사실을 고칩니다. 이후 대화에서 "James랑 잘 지내?" 같은 실수를 하지 않습니다.

왜 이렇게 했나. 사람이 정한 규칙(예: 오래된 메시지는 무조건 요약)으로는 무엇이 중요한지 알 수 없습니다. LLM이 대화 내용을 이해하고 있으니, 무엇을 남기고 무엇을 내릴지도 LLM이 정하게 하자는 것이 핵심입니다. 이를 위해 기억 계층 설명과 함수 스키마를 시스템 지시에 넣습니다.

2. 대기열 관리: 기억 압박 경고와 비우기

직관. 휴대폰 저장 공간이 거의 차면 "공간이 부족합니다" 알림이 먼저 오고, 그래도 안 비우면 오래된 것부터 정리됩니다. MemGPT도 먼저 경고해 LLM이 중요한 것을 옮길 기회를 줍니다.

단계별 설명.

1. 새 메시지가 오면 대기열 관리자가 FIFO 대기열에 붙이고, 프롬프트를 이어 붙여 LLM 추론을 실행합니다. 들어온 메시지와 LLM 출력은 회상 저장소에도 기록됩니다.
2. 프롬프트 토큰이 경고 토큰 수(예: 문맥 창의 70%)를 넘으면 '기억 압박' 시스템 메시지를 대기열에 넣습니다. LLM은 이를 보고 중요한 정보를 작업 문맥이나 기록 저장소에 저장합니다.
3. 비우기 토큰 수(예: 100%)를 넘으면 대기열을 비웁니다. 일정량의 메시지(예: 문맥 창의 50%)를 내보내고, 기존 재귀 요약과 내보낸 메시지로 새 재귀 요약 을 만듭니다.
4. 내보낸 메시지는 프롬프트에서는 사라지지만 회상 저장소에 영구히 남아 함수로 다시 찾을 수 있습니다.

숫자로 해 보기 (설명용, 비율은 논문 예시값). 문맥 창이 8,000토큰이라고 합시다.

• 경고: $0.7 \times 8000 = 5600$토큰을 넘으면 "기억 압박" 경고 → LLM이 "사용자 생일은 2월 7일" 같은 사실을 작업 문맥에 저장
• 비우기: 8,000토큰에 이르면 대기열에서 약 $0.5 \times 8000 = 4000$토큰 분량의 오래된 메시지를 내보내고, 그 내용을 요약에 합침
• 결과: 프롬프트는 다시 약 4,000토큰으로 줄고, 원문 메시지는 회상 저장소에서 언제든 검색 가능

3. 이벤트와 함수 연쇄(하트비트)

직관. 도서관에서 자료를 찾을 때 한 번 검색하고 끝내지 않고 "다음 페이지 → 관련 항목 → 다시 검색"을 이어 갑니다. 그동안 질문한 사람에게는 아직 답하지 않습니다.

단계별 설명.

1. 이벤트가 추론을 일으킵니다. 사용자 메시지, 시스템 메시지(용량 경고), 사용자 행동 알림(로그인, 문서 업로드 완료), 정해진 시각에 도는 예약 이벤트가 있습니다. 예약 이벤트 덕분에 사용자 개입 없이도 스스로 실행할 수 있습니다.
2. LLM 출력은 함수 호출 로 해석됩니다. 파서가 인자를 확인한 뒤 실행하고, 결과(오류 포함)를 다시 LLM에 돌려줍니다. 예를 들어 이미 가득 찬 주 문맥에 더 쓰려 하면 오류가 돌아오고, LLM은 이를 보고 행동을 고칩니다.
3. 함수에 request_heartbeat=true 를 붙이면, 함수가 끝나자마자 결과를 주 문맥에 넣고 LLM을 다시 실행합니다. 붙이지 않으면(양보, yield) 다음 외부 이벤트까지 멈춥니다.
4. 검색 결과는 페이지 단위 로 나눠 가져와, 한 번의 검색이 문맥 창을 넘치지 않게 합니다.

왜 이렇게 했나. 여러 문서를 오가며 정보를 모으거나 검색 결과를 여러 페이지 넘겨 봐야 하는 일은 한 번의 호출로 끝나지 않습니다. 하트비트로 제어권을 LLM에 계속 돌려줘 여러 단계 검색 을 가능하게 했습니다.

결과

실험은 GPT-3.5 Turbo(문맥 16,385), GPT-4(8,192), GPT-4 Turbo(128,000)를 기반 모델로 썼습니다.

대화 1 — 깊은 기억 검색(DMR). 다중 세션 대화 데이터셋(MSC, 세션 5개 · 세션마다 메시지 약 12개)에 6번째 세션을 만들어, 앞선 대화에서만 답할 수 있는 질문을 던졌습니다. 기준 모델은 지난 5개 대화의 손실 있는 요약을 보고, MemGPT는 전체 기록을 검색해 씁니다.

대화 2 — 대화 첫마디(opener). 지난 대화에서 쌓은 지식을 살려 흥미로운 첫마디를 만드는지, 정답 페르소나(SIM-1/3) · 사람이 쓴 첫마디(SIM-H)와의 유사도로 쟀습니다.

• MemGPT의 첫마디는 사람 것보다 길고 페르소나 정보를 더 많이 담는 경향이 있었고, 작업 문맥에 정보를 저장하는 것이 핵심이었습니다.

문서 1 — 문서 질의응답. NaturalQuestions-Open 질문 50개에 대해, 검색기가 가져온 위키백과 문서 수 K를 늘려 가며 정확도를 쟀습니다. 고정 문맥 모델은 창에 맞추려 문서를 잘라야 해서 정답 구절이 잘려 나갈수록 정확도가 떨어졌지만, MemGPT는 문맥 길이가 늘어도 성능이 영향을 받지 않았습니다. 다만 GPT-3.5로는 함수 호출 능력이 부족해 성능이 크게 떨어졌고, GPT-4에서 가장 좋았습니다. MemGPT가 검색 결과를 끝까지 넘겨 보지 않고 일찍 멈추는 경우도 관찰됐습니다.

문서 2 — 중첩 키-값 검색(새 과제). 128비트 UUID 키-값 쌍 140개(약 8천 토큰)에서, 값이 다시 키인 경우를 따라가야 최종 값을 찾는 과제입니다. 중첩 수준은 0~4, 배치 순서 30가지를 썼습니다.

• GPT-3.5는 중첩 1단계에서 정확도 0%(주로 원래 값을 그대로 답함), GPT-4 · GPT-4 Turbo는 3단계에서 0%가 됐습니다.
• MemGPT + GPT-4는 중첩 수준과 무관하게 함수 질의를 반복해 끝까지 찾아갔습니다. MemGPT + GPT-4 Turbo · GPT-3.5는 기준보다 낫지만 2단계부터 떨어졌습니다.

숫자로 해 보기 (중첩 2단계, 논문 그림 8 예시). 키 831..ea5 → 값 5b8..4c3 → 이것이 다시 키 → 값 f37...617. MemGPT는 f37...617로 검색했을 때 결과가 하나뿐(키로는 없음)인 것을 보고 이것이 최종 값이라고 판단해 답합니다. 검색을 3번 한 셈입니다.

왜 중요한가 · 이후 영향

• "LLM을 운영체제처럼" 이라는 관점을 열었습니다. 문맥 창을 한정된 자원으로 보고, 계층 기억 · 인터럽트(이벤트) · 페이징으로 관리하는 설계는 장기 기억 에이전트의 대표 설계 패턴이 됐습니다.
• 스스로 기억을 편집하는 에이전트: 사용자가 정보를 바꾸면(예: 헤어짐) 기억을 직접 고치는 방식은 개인 비서 · 고객 상담 봇의 '사용자 기억' 기능과 직결됩니다.
• RAG와의 관계: 기록 저장소 검색은 RAG와 같지만, 언제 무엇을 몇 번 검색할지를 LLM이 함수로 정한다는 점이 다릅니다. 생성형 에이전트(기억 흐름 · 반성)와 함께 에이전트 기억 설계의 두 축으로 자주 비교됩니다.

한계 · 주의할 점

• 기반 모델의 함수 호출 능력에 크게 의존합니다. GPT-3.5에서는 문서 질의응답 성능이 크게 떨어졌고, GPT-4 Turbo는 중첩 키-값에서 GPT-4보다 못했습니다.
• 검색기 품질의 영향: 임베딩 검색이 정답 문서를 앞쪽에 못 올리면, MemGPT가 페이지를 충분히 넘기지 않고 멈춰 놓칠 수 있습니다.
• 여러 번의 LLM 호출: 기억 관리 · 연쇄 검색을 위해 추론 횟수가 늘어 비용 · 지연이 커질 수 있습니다.
• 평가는 MSC 기반 과제와 합성 키-값 과제, 질문 50개 규모의 문서 질의응답으로, 실제 장기 사용 환경 전체를 대표하지는 않습니다.
• 논문은 다른 기억 계층 기술(데이터베이스 · 캐시)과의 통합, 제어 흐름 · 기억 관리 정책 개선을 향후 과제로 듭니다.

스스로 점검

1. MemGPT의 주 문맥을 이루는 세 부분은?

   읽기 전용 시스템 지시, 함수로만 고치는 작업 문맥, 최근 메시지와 재귀 요약을 담는 FIFO 대기열입니다.

2. 문맥 창이 16,000토큰이고 경고 비율이 70%라면 기억 압박 경고는 언제 오나요?

   $0.7 \times 16000 = 11200$토큰을 넘을 때입니다. 이때 LLM이 중요한 정보를 작업 문맥이나 기록 저장소에 옮길 기회를 얻습니다.

3. request_heartbeat=true는 왜 필요한가요?

   함수가 끝난 뒤 사용자 입력을 기다리지 않고 곧바로 LLM을 다시 실행해, 여러 번의 검색(예: 중첩 키-값 따라가기, 검색 결과 페이지 넘기기)을 이어서 할 수 있게 하기 위해서입니다.

용어 정리

이어서 읽을 것

• 앞: 검색 증강 생성 (RAG) · ReAct · 생성형 에이전트
• 뒤: SWE-bench · Self-RAG

다음에 볼 것

이 글을 이해했다면 이어서 보면 좋은 항목입니다.

• SWE-bench: 실제 깃허브 이슈를 풀 수 있는가 — 실제 깃허브 이슈 2,294개를 실제 테스트로 채점하는 저장소 단위 코딩 벤치마크

출처

• 원문: https://arxiv.org/abs/2310.08560 (2023 · Charles Packer 외)