GPT 리서치 모드로 정리하였습니다.
대형 언어 모델(LLM)은 놀라운 언어 이해와 생성 능력으로 인공지능 분야의 핵심으로 떠올랐지만, “망각”이라는 근본적 한계를 지니고 있습니다. 현재의 LLM들은 주로 사전에 학습된 모델 파라미터에 내재된 지식과 짧은 대화 맥락만을 활용하며, 세션이 끝날 때마다 과거 대화를 잊어버립니다globalbrandsmagazine.com. 사용자의 선호나 새로운 지식을 장기간 학습하거나 유지하는 구조화된 메모리 체계가 없어, 동일한 내용을 반복 설명해야 하거나 대화 맥락을 장기간 유지하지 못하는 문제가 있습니다linkedin.com. 이를 보완하기 위해 검색 기반 생성(RAG)과 같은 기법이 등장했지만, 이는 외부 지식을 그때그때 불러오는 비상태성(stateless) 임시 방편에 불과하며, 메모리의 수명 주기 관리나 지속성 측면에서 한계가 있습니다reddit.com.
예를 들어 RAG에서는 이전 대화나 지식을 장기적으로 축적·관리하지 못하고, 매번 검색하여 붙여 넣는 방식이라 일관된 장기 학습이나 지식 업데이트에 취약합니다.
이러한 한계를 극복하고자 등장한 개념이 **MemOS (Memory Operating System)입니다.
MemOS는 말 그대로 “메모리 운영체제”로서, LLM에게 사람처럼 장기 기억을 부여하고 이를 체계적으로 관리하려는 시도입니다globalbrandsmagazine.comlinkedin.com. 본 기술 블로그에서는 MemOS 논문(arXiv:2507.03724v2)을 기반으로, MemOS가 무엇이고 왜 필요한지, 어떠한 설계 철학과 구성 요소로 이루어져 있는지, 그리고 실제로 어떻게 활용될 수 있는지를 알아보겠습니다. 또한 LLM과 MemOS가 상호 연동되는 방식과 현실적인 한계점까지 살펴보겠습니다.
왜 MemOS는 '메모리'와 '운영체제'를 말하는가?
MemOS가 내세우는 핵심 개념은 “메모리를 운영체제 수준의 리소스로 격상”시키는 것입니다arxiv.orgmemos-docs.openmem.net. 전통적인 운영체제(OS)는 CPU, 메모리, 디스크와 같은 **자원(resource)**을 관리하고 스케줄링하여 프로그램들이 효율적으로 동작하도록 합니다. 마찬가지로 MemOS는 LLM의 지식과 기억을 하나의 시스템 자원으로 간주하여, 표준화되고 통제 가능한 방식으로 관리하려 합니다memos-docs.openmem.net. 현재의 LLM들은 지식이 암묵적으로 모델 가중치에 숨어 있거나 대화 컨텍스트에 일시적으로 남아 있을 뿐이고, 이를 체계적으로 다룰 수 있는 “운영체제”가 없다는 진단입니다linkedin.comlinkedin.com. MemOS 연구진은 “메모리 중심의 실행 프레임워크”를 도입함으로써, 메모리를 명시적으로 다루고 추적하여 LLM의 동작을 보다 **제어 가능(controllable)**하고 **적응 가능(adaptable)**하며 **진화 가능(evolvable)**하게 만들 수 있다고 강조합니다reddit.comlinkedin.com.
왜 하필 '메모리'와 'OS'인가에 대한 개념적 배경을 정리하면 다음과 같습니다:
- 메모리: 인간이 과거의 경험과 지식을 기억하고 활용하듯이, LLM에도 지속적이고 구조화된 기억이 필요합니다. 단순히 질문에 답할 때 일시적으로 참조하는 지식이 아니라, 시간이 지나도 유지되는 장기 지식, 사용자별 선호도, 지난 상호작용 내역 등을 쌓아두고 활용해야 진정한 개인화와 연속적 학습이 가능합니다linkedin.comglobalbrandsmagazine.com. MemOS는 이러한 장기 메모리 계층을 LLM에 부여하는 것을 목표로 합니다.
- 운영체제: 컴퓨터 OS가 메모리를 계층적으로 관리(예: 캐시, RAM, 디스크)하고 프로세스 간 자원을 분배하듯이, MemOS도 계층적인 메모리 관리를 도입합니다arxiv.org. 예를 들어, 작업 기억(working memory)에 해당하는 부분은 빠르게 접근할 수 있지만 용량이 제한되고, 장기 저장소는 방대하지만 느릴 수 있습니다. MemOS는 상황에 따라 어떤 정보를 유지하고 압축하거나 버릴지 스케줄링하고, 필요한 순간에 적절한 기억을 미리 불러오거나(preloading) 주입하는 역할을 합니다memos.openmem.netmemos.openmem.net. 이를 통해 LLM이 항상 최적의 맥락 정보를 갖고 동작하도록 조율하는 것입니다.
정리하면, MemOS라는 이름에는 LLM의 다양한 종류의 기억들을 통합 관리할 수 있는 일종의 소프트웨어 플랫폼을 만들겠다는 비전이 담겨 있습니다. 논문 저자들은 이를 **“메모리 중심의 시스템 프레임워크”**라고 부르며, 이 새로운 계층이 LLM을 단순한 언어 생성기에서 끊임없이 학습하고 진화하는 지능 에이전트로 변화시키는 토대가 될 것이라고 말합니다linkedin.comlinkedin.com.
MemOS에서 정의하는 메모리: 종류와 표현 방식
MemOS 논문에서는 LLM이 다루는 **메모리(memory)**를 세 가지 유형으로 정의합니다linkedin.comglobalbrandsmagazine.com:
- 파라메트릭 메모리(Parametric Memory): 모델의 가중치에 저장된 지식입니다. 사전훈련이나 파인튜닝을 통해 LLM 내부에 암묵적으로 파라미터 형태로 인코딩된 장기 지식을 뜻합니다linkedin.com. 예를 들어, GPT-4 모델이 역사적 사실을 알고 있는 것은 파라메트릭 메모리에 해당합니다. 이는 범용적 지식을 담고 있지만, 업데이트하려면 재훈련이 필요하고 실시간으로 변경하기 어렵다는 한계가 있습니다arxiv.orgarxiv.org.
- 액티베이션 메모리(Activation Memory): 모델이 추론(inference) 시 생성하는 일시적인 활성 상태를 의미합니다. 대표적으로 키-값 캐시(KV cache)나 어텐션 매트릭스 등이 여기에 속하며, 짧은 맥락상의 임시 기억으로 볼 수 있습니다linkedin.com. 예를 들어, GPT 모델이 긴 답변을 생성할 때 앞 부분을 기억하기 위해 내부적으로 활용하는 벡터들이 Activation 메모리입니다. 일반적으로 한 번 대화가 끝나면 사라지며, 다른 세션에선 재사용되지 않습니다.
- 플레인텍스트 메모리(Plaintext Memory): 외부 지식을 텍스트 형태로 저장하고 필요 시 검색하여 사용하는 메모리를 말합니다linkedin.com. 이는 데이터베이스나 문서 저장소에 보관된 텍스트, 사용자와의 과거 대화 기록, 노트와 같은 명시적인 지식 저장소입니다. RAG 기법에서 검색되는 문서들이나 대화 히스토리가 이에 해당하며, 편집이나 업데이트가 용이하다는 장점이 있습니다.
이 세 가지 이질적인 형태의 기억을 하나로 묶는 통합 추상화가 바로 **메모리 큐브(MemCube)**입니다. MemCube는 MemOS의 기본 단위로, 어떤 형태의 메모리든 하나의 표준화된 객체 안에 **내용(Content)**과 그에 대한 **메타데이터(Metadata)**를 함께 담은 구조체입니다arxiv.orgreddit.com. 메타데이터에는 해당 기억의 출처(예: 어디서 얻은 지식인지), 버전 정보(언제 업데이트되었는지)나 권한(누가 사용할 수 있는지) 등의 관리 정보가 포함됩니다reddit.com. 예를 들어, 과거 사용자와 주고받은 대화 한 토막을 하나의 MemCube로 만들면, 그 대화 내용(plaintext)이 메모리 페이로드(payload)가 되고, 어떤 사용자와의 대화인지, 시각 정보, 출처 등이 헤더에 기록되는 식입니다arxiv.org. 이러한 MemCube들은 서로 합치거나(fuse) 분할하거나(migrate) 버전 업하는 등의 연산이 가능하여, 필요에 따라 메모리 조각들을 융합하거나 다른 형태로 변환할 수 있습니다reddit.com. 예를 들어 중요도가 높아 자주 참조되는 plaintext 기억은 요약을 거쳐 파라메트릭 메모리(모델 파인튜닝)로 승격시키거나, 반대로 모델에 너무 부담이 되는 파라메트릭 지식을 추출해 외부 텍스트로 이관하는 식의 유연한 전환이 가능합니다reddit.com.
MemCube를 활용한 표준화 덕분에, MemOS는 LLM 메모리에 대한 추적 가능하고 구조화된 접근을 제공합니다linkedin.comlinkedin.com. 개발자는 MemCube 단위로 어떤 정보가 언제 추가되고 갱신되었는지 파악할 수 있고, LLM의 동작이 해당 메모리 조각에 어떻게 영향을 받았는지 기록하여 분석할 수도 있습니다. 논문에서는 이를 통해 LLM이 **지속적으로 학습(continual learning)**하고 **개인화된 모델링(personalized modeling)**을 실현할 수 있는 기반이 된다고 강조합니다arxiv.org.
MemOS 아키텍처와 구성 요소
MemOS 시스템 아키텍처 개요: 좌측의 인터페이스 레이어에서 사용자 입력을 받아 메모리 관련 작업으로 해석하고, 오퍼레이션 레이어에서 메모리 검색·조직화·수명주기 관리 등을 수행하며, 인프라스트럭처 레이어가 안전한 저장 및 접근 제어를 담당한다. MemCube 단위로 메모리가 주고받아지며, MemScheduler, MemLifecycle, MemGovernance 등의 모듈이 메모리의 주입, 갱신, 삭제를 관리한다linkedin.com.
MemOS는 **운영체제(OS)**의 메타포를 충실히 따르는 3계층 구조 아키텍처로 설계되었습니다linkedin.com. 각 계층은 다음과 같은 역할을 맡습니다:
- 인터페이스 계층 (Interface Layer): 사용자나 애플리케이션의 입력을 받아들이는 상위 계층입니다. 사용자의 프롬프트나 API 호출을 해석하여, 그 안에 담긴 메모리 관련 의도를 파악합니다linkedin.com. 예를 들어 사용자가 “지난주에 내가 뭐라고 했지?”라고 질문하면, 이를 일반 질문으로 볼 것이 아니라 과거 대화 메모리를 검색해달라는 요청으로 인지하는 식입니다. 인터페이스 계층은 이러한 요청을 MemOS 내부에서 처리할 수 있는 메모리 작업으로 변환합니다. 또한 외부 애플리케이션이 MemOS를 활용할 수 있도록 統一 API를 제공합니다globalbrandsmagazine.com. 이 API를 통해 개발자는 메모리 추가, 검색, 업데이트, 롤백 등의 명령을 MemOS에 전달할 수 있습니다.
- 오퍼레이션 계층 (Operation Layer): MemOS의 핵심 로직이 동작하는 중간 계층입니다linkedin.com. 이 계층에서는 다양한 메모리들의 스케줄링, 조직화, **진화(evolution)**가 일어납니다. 구체적으로, 어떤 메모리를 언제 불러와서 LLM에 투입할지, 오래된 메모리를 어떻게 처분하거나 요약할지, 새로운 지식을 어떤 형태로 저장할지 등을 결정하는 일종의 메모리 관리자입니다. 주요 모듈로는 메모리 접근 순서를 정하는 메모리 스케줄러(MemScheduler), 메모리의 생성-변환-말소 등 수명 주기를 관리하는 메모리 라이프사이클 관리자(MemLifecycle), 그리고 메모리 사용에 대한 정책과 규칙을 적용하는 메모리 거버넌스(MemGovernance) 등이 언급됩니다linkedin.com. 예를 들어 MemScheduler는 현재 대화 맥락과 사용자 프로필을 참고하여 필요할 것으로 예상되는 메모리를 미리 불러오는 프리페치(prefetch)를 수행하거나memos.openmem.net, LLM의 응답 생성 중에 관련성이 높다고 판정된 메모리를 실시간으로 검색해 투입합니다. MemLifecycle은 시간이 너무 오래되어 유효하지 않거나 중요도가 떨어진 메모리를 휴지통으로 이동시키거나 요약본을 만들고, 반대로 새로운 사실이 추가되면 버전 관리와 함께 저장합니다globalbrandsmagazine.com. MemGovernance는 민감한 정보에 대한 접근 제어, 메모리 공유 시의 권한 관리, 그리고 플랫폼 간 협업시 메모리 이동에 대한 규칙 등을 담당합니다linkedin.com. 이를 통해 여러 에이전트가 메모리를 주고받거나, AI 모델이 지속적이면서도 신뢰할 수 있는 메모리 시스템을 유지하도록 합니다.
- 인프라스트럭처 계층 (Infrastructure Layer): 가장 하단에 위치한 저장 및 시스템 계층입니다linkedin.com. 실제 메모리 데이터가 보관되는 **스토리지(예: 벡터 데이터베이스, 그래프 DB, 파일 시스템)**와, 메모리의 영속성(persistence)을 보장하는 기반 시설에 해당합니다. 이 계층은 MemOS가 보유한 메모리들이 안전하게 저장되고 빠르게 접근될 수 있도록 지원합니다linkedin.com. 예컨대 대용량의 사용자별 장기 기억은 벡터 DB에 임베딩 형태로 저장하고, 모델의 파라메트릭 메모리는 별도의 어댑터(예: LoRA 레이어)로 보관하며, Activation 메모리는 캐시 서버나 공유 메모리에 임시 저장하는 식입니다. 또한 이 계층은 크로스 에이전트 메모리 공유나 디바이스 간 동기화도 담당합니다memos.openmem.net. 예를 들어 한 사용자가 PC와 모바일 기기에서 같은 AI 비서를 쓴다면, 두 플랫폼의 MemOS 인스턴스가 공통의 클라우드 메모리 저장소를 참고하여 일관된 기억을 유지하도록 해줍니다.
이렇게 상호보완적인 세 계층을 통해, MemOS는 사용자 입력 → 메모리 조회/갱신 → LLM 응답 생성에 이르는 전체 파이프라인을 아우르는 메모리 중심 실행 흐름을 구현합니다arxiv.orgarxiv.org. 사용자의 한 번 질문이 들어오면, 인터페이스 계층에서 이를 파싱하여 필요한 경우 메모리 검색 질의로 만들고, 오퍼레이션 계층에서 해당 질의에 맞는 메모리를 MemCube 단위로 찾아와 LLM에게 전달합니다. LLM은 이 추가 메모리 정보를 참고하여 응답을 생성하고, 생성된 응답이나 대화 진행 중 새로 얻은 정보는 다시 MemCube로 포장되어 인프라 계층에 저장됩니다. 이 모든 과정에 정책과 스케줄이 개입하여, 메모리가 과도하게 쌓이거나 오래되어 부적절해지는 것을 방지하고, 필요한 메모리는 적시에 모델에 주입될 수 있도록 합니다linkedin.comglobalbrandsmagazine.com. 결과적으로 MemOS는 LLM의 일종의 기억 보조장치로 작동하면서, 일관성 있는 장기 대화와 지식 진화를 가능케 합니다.
코드 예시: MemOS 메모리 모델의 활용
MemOS는 연구 프로토타입을 넘어 Python 기반의 오픈 소스 라이브러리로도 제공되어 개발자들이 직접 실험해볼 수 있습니다globalbrandsmagazine.com. 이를 활용하면 LLM 애플리케이션에 메모리 계층을 통합하는 과정을 비교적 손쉽게 구현할 수 있습니다. 아래에는 MemOS 파이썬 패키지를 이용해 간단한 메모리 워크플로우를 구현한 예시 코드가 있습니다pypi.orgpypi.org. 이 예시는 하나의 **MemOS 인스턴스(MOS)**를 초기화하고, 사용자별로 메모리 큐브를 생성·등록한 후, 대화 내용을 메모리에 추가하고 질의에 따라 검색하는 과정을 보여줍니다.
from memos.configs.mem_os import MOSConfig
from memos.mem_os.main import MOS
# MemOS 초기화
mos_config = MOSConfig.from_json_file("examples/data/config/simple_memos_config.json")
memory = MOS(mos_config)
# 사용자 생성 및 메모리 큐브 등록
user_id = "b41a34d5-5cae-4b46-8c49-d03794d206f5"
memory.create_user(user_id=user_id)
memory.register_mem_cube("examples/data/mem_cube_2", user_id=user_id)
# 메모리 추가: 유저와 어시스턴트의 대화 한 쌍을 저장
memory.add(
messages=[
{"role": "user", "content": "I like playing football."},
{"role": "assistant", "content": "I like playing football too."},
],
user_id=user_id,
)
# 메모리 검색: 사용자 질의에 따라 관련 기억을 조회
retrieved_memories = memory.search(query="What do you like?", user_id=user_id)
print(f"text_memories: {retrieved_memories['text_mem']}")위 코드에서 볼 수 있듯이, MemOS는 통일된 API 형태로 메모리 동작을 제공합니다. memory.add(...)를 통해 대화 메시지들을 현재 사용자의 메모리에 저장하고, memory.search(...)로 사용자의 질문에 맞는 저장된 기억을 검색해낼 수 있습니다. retrieved_memories 결과는 text_mem (텍스트 메모리), act_mem (활성 메모리), para_mem (파라메트릭 메모리)로 구분되어, 질의와 가장 관련있는 각각의 메모리 조각들을 반환합니다pypi.org. 예시의 출력에서 text_memories로 과거에 추가한 "I like playing football" 문장이 검색되어 나오는 것을 볼 수 있습니다.
이처럼 MemOS 라이브러리를 이용하면, 개발자는 복잡한 메모리 관리 로직을 일일이 구현하지 않고도 memory.add, memory.search 등의 간단한 메서드를 통해 LLM의 기억을 다룰 수 있습니다. 내부적으로는 MemOS가 앞서 설명한 대로 MemCube에 데이터를 저장하고, 벡터 임베딩 기반 검색 등을 수행하여 질의에 맞는 기억을 찾아주는 것입니다. 또한 설정 파일(MOSConfig)을 통해 어떤 종류의 메모리를 활성화할지, 백엔드는 무엇을 쓸지(예: 벡터 DB나 그래프 DB 연동) 등을 조절할 수 있어 유연성을 제공합니다. 실제 오픈 소스 구현에서는 HuggingFace 트랜스포머 모델, Ollama 등과의 손쉬운 연동도 지원하며memos-docs.openmem.net, 나아가 그래프 DB 연동을 통한 지식 구조화도 가능함을 강조하고 있습니다memos-docs.openmem.net.
LLM과 MemOS의 연동 방식: 메모리 상태 I/O와 명시적 읽기/쓰기
그렇다면 구체적으로 LLM과 MemOS는 어떻게 상호 작용할까요? 이는 사용하는 LLM의 종류(오픈소스 vs API 제공)에 따라 약간 다르게 나타납니다. 기본적으로 MemOS는 LLM 바깥쪽에서 동작하는 메모리 레이어이므로, LLM이 입력을 받을 때 적절한 기억을 **“주입”**하고, 출력을 생성한 후 새로운 기억을 **“추출”**하여 저장하는 형태로 I/O가 이뤄집니다. 이를 명시적 메모리 읽기/쓰기 관점에서 정리하면 다음과 같습니다:
- 프롬프트에 의한 메모리 읽기: LLM이 응답을 생성하기 전에, MemOS는 해당 질문에 연관된 메모리를 검색하여 LLM의 입력 프롬프트에 추가합니다globalbrandsmagazine.com. 예를 들어 사용자의 질의가 이전 대화 내용과 관련된다면, MemOS가 plaintext 메모리에서 그 대화 요약이나 핵심 문장을 찾아내어 LLM에게 “추가 컨텍스트”로 제공하는 식입니다. OpenAI의 GPT-4처럼 외부 접근이 제한된 API형 LLM의 경우, 이러한 방식으로 텍스트 메모리 주입만이 현실적으로 가능합니다linkedin.com. 즉, MemOS가 메모리를 읽어서 GPT-4의 프롬프트 앞부분에 합쳐 넣어주면, GPT-4는 마치 긴 대화 컨텍스트를 받은 것처럼 동작하게 됩니다. 반면, LLaMA같이 오픈소스 LLM을 직접 구동하는 경우에는, MemOS가 더 깊이 개입할 수 있습니다. 예컨대 LLM의 **KV 캐시(활성 메모리)**를 미리 로드하거나, **LoRA와 같은 어댑터 가중치(파라메트릭 메모리)**를 필요한 순간에 적용함으로써, LLM 내부의 상태 자체를 변경하는 방식의 메모리 주입도 가능합니다linkedin.com. 이러한 경우 MemOS는 단순 프롬프트 조작을 넘어, 모델의 내부 메모리 상태를 직접 읽고 쓰는 API나 훅(hook)을 통해 메모리를 주입합니다. 논문에서는 특히 KV 캐시 기반의 메모리 주입이 응답 지연 시간을 크게 단축시키면서도 동일한 출력을 산출함을 실험으로 보였는데arxiv.orgarxiv.org, 이는 활성 메모리를 명시적으로 다룰 수 있을 때 얻을 수 있는 이점의 한 예입니다 (프롬프트 토큰을 늘리는 것보다 캐시 삽입이 빠르다는 의미).
- 출력 후 메모리 쓰기: LLM이 응답을 생성하고 나면, MemOS는 그 내용을 분석하여 새롭게 얻은 정보나 중요한 대화 맥락을 메모리로 저장합니다. 이를테면 사용자가 자신의 취향을 언급하는 내용이 답변에 포함되었다면, MemOS는 해당 정보를 사용자 프로필 메모리에 반영해둘 수 있습니다. 또는 LLM이 어떤 문제를 풀어나가는 중간 과정(chain-of-thought)을 토대로 새로운 추론 규칙을 발견했다면, 이를 요약하여 별도의 지식 메모리에 저장해둘 수도 있습니다. 이처럼 LLM의 상태를 외부로 추출하여 명시적으로 축적하는 과정이 메모리 쓰기라 할 수 있습니다. 물론 OpenAI 등의 제한된 환경에서는 LLM의 중간 사고 과정에 접근할 수 없으므로, 주로 사용자와 주고받은 대화만 기록하게 됩니다. 그러나 통제가 가능한 LLM 환경에선 모델 내부 상태, 예를 들어 주의(attention) 패턴이나 예측 분포 등을 활용한 메모리 업데이트도 연구되고 있습니다. MemOS의 비전은 장기적으로 LLM이 스스로 어떤 정보를 기억할지 결정하고 요청하게 만드는 것인데arxiv.org, 이를 위해서는 LLM이 일정 수준 자기 자신을 제어할 수 있도록 메모리 읽기/쓰기 인터페이스를 학습하거나 제공해야 합니다. 현재 MemOS는 주로 외부 시스템 주도로 메모리 I/O를 수행하지만, 궁극적으로는 LLM과 MemOS가 대화하듯 상호 작용하는 모습도 상정해볼 수 있습니다 (예: LLM이 “그 정보를 내 장기기억에 저장해줘”라고 API 호출을 트리거하거나, 반대로 필요한 메모리를 요청하는 형태).
정리하면, MemOS는 LLM 앞뒤에 위치하여 메모리 관리 인프라를 제공하며, 읽기는 적절한 기억을 LLM에게 공급하는 것, 쓰기는 대화 및 추론 결과를 축적하는 것으로 이해할 수 있습니다. 이러한 과정은 개발자에게는 memory.search나 memory.add와 같은 간단한 함수 호출로 추상화되지만, 내부적으로는 벡터 데이터베이스 검색, 모델 파인튜닝 또는 어댑터 로드, KV 캐시 관리 등 다양한 기법이 활용됩니다. 결국 목표는 LLM이 더 이상 모든 것을 일시적인 컨텍스트에 의존하지 않고, 필요한 지식을 효율적으로 불러쓰며(explicit read), 새로운 지식을 체계적으로 축적(explicit write)하도록 만드는 것입니다arxiv.orgarxiv.org.
MemOS의 현실적 한계와 고려사항
혁신적인 MemOS 개념에도 불구하고, 실제 적용이나 확장 면에서 몇 가지 현실적인 한계점과 고려해야 할 점들이 존재합니다. 논문 및 관련 자료에서 언급된 사항과 함께 이러한 요소들을 짚어보겠습니다:
- 모델 접근성과 호환성: 앞서 언급했듯이, MemOS의 효과는 LLM의 개방성에 크게 좌우됩니다. OpenAI GPT-4 같이 폐쇄형 모델의 경우 MemOS가 해줄 수 있는 일이 프롬프트에 텍스트를 추가하는 수준에 머물러 있습니다linkedin.com. 내부 파라미터나 활성 상태에 대한 직접적 통제권이 없으므로, MemOS가 제공하는 파라메트릭/액티베이션 메모리 관리 기능을 활용하기 어렵습니다. 이는 곧 메모리 OS의 일부 기능이 제한됨을 의미하며, 완전한 MemOS 비전을 실현하려면 모델이 오픈소스이거나 적어도 커스텀 튜닝을 허용해야 합니다linkedin.com. 따라서 현재 MemOS는 주로 LLaMA와 같은 공개모델이나 사용자가 로컬에서 구동하는 모델들과의 연계에 최적화되어 있으며, 폐쇄형 API 모델에 대해서는 제한적인 프록시 역할만 수행할 수 있다는 현실적인 제한이 있습니다.
- 메모리 지속성(Persistence): MemOS의 큰 목표 중 하나가 LLM에 세션을 넘어 지속되는 기억을 주는 것이지만, 이를 완벽히 이루려면 메모리의 영속적 저장과 백업이 보장되어야 합니다. MemOS 자체는 MemCube를 파일로 덤프뜨거나 데이터베이스에 저장하는 기능을 제공하므로 기본적인 지속성은 갖추고 있습니다pypi.orgpypi.org. 다만 시스템 수준에서 전원을 껐다 켜도 메모리가 복구된다거나, 여러 기기에서 동일한 메모리를 공유한다거나 하는 기능은 결국 외부 인프라 의존입니다. 예를 들어 벡터 DB를 어디까지 확장할 수 있는지, 실시간 동기화를 어떻게 할지 등은 MemOS 외부 요소에 달려 있습니다. 또한 장기간 쌓인 메모리를 효율적으로 압축 및 관리하지 않으면 저장소 비용이나 검색 성능 면에서 스케일링 문제가 발생할 수 있습니다. 논문에서는 계층적 저장 전략과 예측적 메모리 로딩으로 성능을 최적화했다고는 하지만memos.openmem.netmemos.openmem.net, 무한에 가까운 대화 기록이 쌓이는 극단적 상황에서 시스템이 얼마나 효율적으로 작동할지는 추후 검증이 필요합니다.
- 스케일링과 성능: 메모리를 통합한다는 것은 새로운 복잡도를 도입하는 것이기도 합니다. 예컨대 질문 하나에 답하기 위해 이전 대화 수십만 건 중 관련 내용을 찾아야 한다면, 검색 연산이 병목이 될 수 있습니다. MemOS는 이를 위해 벡터 유사도 검색, 그래프 탐색 등 다양한 최적화 기법을 활용하고 있고, 특정 벤치마크(LoCoMo)에서 기존보다 월등한 성능 향상을 보였다고 보고합니다globalbrandsmagazine.comglobalbrandsmagazine.com. 특히 시간적 추론 능력 159% 향상, 정확도 39% 증가, 토큰 소비 60% 절감 등의 수치를 공개하여 메모리 아키텍처의 효용을 입증하였습니다globalbrandsmagazine.comglobalbrandsmagazine.com. 그러나 이러한 평가는 특정 실험 환경에서의 결과이므로, 실제 다양한 도메인에서 메모리 시스템을 얹었을 때 **응답 지연(latency)**이나 자원 소모가 어떻게 변할지는 면밀한 모니터링이 필요합니다. 메모리를 많이 사용한다고 항상 좋은 것도 아니며, 불필요한 메모리까지 참조하면 오히려 혼선이나 성능 저하가 올 수 있기 때문입니다. 따라서 메모리 선택의 정확도 (Relevant memory retrieval)와 시스템 튜닝이 중요한 과제가 됩니다.
- LLM의 통제 및 신뢰성: MemOS가 메모리를 제공한다고 해서 LLM이 그것을 올바르고 일관되게 활용한다는 보장은 없습니다. LLM은 본래 확률적 생성 모델이며, 주어진 컨텍스트를 어떻게 해석할지는 모델에 내재된 분포에 따릅니다. 가령 MemOS가 과거 사실 A를 제공했는데, LLM이 이를 무시하고 다른 추론을 할 수도 있고, 또는 A와 모순되는 거짓을 출력할 수도 있습니다. 궁극적으로 메모리의 활용 여부도 모델의 몫이므로, 필요하면 LLM 자체를 메모리 사용에 최적화되도록 미세조정하거나 프롬프트 설계를 정교히 해야 합니다. 한편, LLM이 잘못된 기억을 학습하거나 편향된 정보를 축적하는 위험도 있습니다. 따라서 MemOS에는 메모리 거버넌스 모듈을 통해 **유해하거나 불필요한 메모리를 정화(Purification)**하거나 롤백하는 기능이 포함되어 있지만【8†source】, 실제 얼마나 효과적으로 모델의 출력을 통제할 수 있을지는 향후 검증이 필요합니다. 잘못된 기억이 쌓이면 편향 강화나 환각 현상에 일조할 수 있기 때문입니다.
- 프라이버시와 윤리: LLM에 지속적 메모리가 생긴다는 것은 데이터 보안과 프라이버시 측면에서도 새로운 도전입니다. 사용자의 개인 정보나 민감한 대화 내용을 장기간 보존한다면, 권한 관리와 익명화 등이 중요해집니다. 논문 외부에서도 이러한 지속 메모리에 대한 규제적·윤리적 논의가 이제 막 시작되었다고 지적하는데globalbrandsmagazine.com, 예컨대 AI 비서가 사용자 몰래 모든 대화를 기억하고 있다면 이는 프라이버시 침해 소지가 있습니다. MemOS는 이러한 이슈를 인지하고 설계 단계에서 접근 제어 및 감사(traceability) 기능을 넣었으며linkedin.com, 기업 환경에서 활용 시 로그 관리나 정책 적용을 통해 안전장치를 마련해야 할 것이라고 제안합니다.
- 기술 성숙도: 마지막으로, MemOS는 아직 신생 개념으로서 실질적인 표준으로 굳어졌다고 보기는 어렵습니다. 연구적으로도 MemOS와 유사한 시도가 더 있을 수 있으며 (예: 메모리 플러그인, LangChain의 메모리 모듈, MemGPT 등), 어떤 접근이 최선인지 활발한 탐구가 진행 중입니다. MemOS 팀은 자신들의 프레임워크가 현재까지 제안된 것 중 가장 포괄적인 메모리 시스템이라고 주장하지만globalbrandsmagazine.com, 향후 더 발전된 아이디어나 성능 개선이 나올 가능성도 있습니다. 또한 MemOS 자체도 계속 진화하고 있어서, 2025년 7월 1.0 프리뷰 버전 공개 이후 커뮤니티의 피드백을 받으며 개선을 거듭하고 있습니다pypi.org. 따라서 당장 실무에 적용하기보다는 향후 LLM 인프라가 나아갈 방향을 보여주는 청사진으로 받아들이고, 관련 생태계의 성장을 지켜볼 필요가 있습니다.
결론 및 미래 전망
MemOS는 **“기억하는 AI”**를 실현하기 위한 대담한 접근으로, LLM을 둘러싼 메모리 계층의 표준화라는 새 지평을 열었습니다. 이를 통해 LLM은 과거보다 훨씬 맥락 지향적이고 사용자 적응적으로 거듭날 잠재력을 얻었습니다. 기술 블로그에서 살펴본 바와 같이, MemOS는 메모리를 파라미터, 활성, 텍스트의 세 범주로 나누고 이를 MemCube 단위로 관리함으로써, 그동안 여러 형태로 산발적으로 다뤄지던 LLM 메모리를 일관되게 운영할 수 있게 합니다. 마치 컴퓨터에 메모리 관리자(OS)가 도입되면서 프로그램의 효율과 안정성이 향상된 것처럼, MemOS가 LLM의 장기적 능력을 비약적으로 발전시킬 수 있을지 주목됩니다.
향후 전망을 살펴보면, MemOS 팀은 표준화된 메모리 포맷과 메모리 마켓플레이스까지 구상하고 있습니다linkedin.com. 예를 들어 MemCube 포맷이 업계 표준이 된다면, OpenAI나 Anthropic 같은 업체도 이를 받아들여 서로 다른 모델 간에 메모리를 주고받는 협업이 가능해질 것입니다. 더 나아가 탈중앙화된 메모리 공유 시장이 형성되면, 개별 AI들이 자신의 지식을 안전하게 공개하여 다른 모델들이 참고하도록 하거나, 사용자들이 자신의 AI 비서들에게 기억을 이식하는 시대가 올 수도 있습니다linkedin.com. 또한 **자기 진화적 메모리(self-evolving memory)**라는 개념도 제시되는데, 이는 MemCube 자체가 시간에 따라 자동으로 변화하고 최적화되어, 각기 다른 LLM에 맞춤 적응하는 방향입니다linkedin.com. 이러한 비전이 실현된다면, 미래의 AI 시스템은 서로 학습한 것을 교환하고 누적하며 진화하는 거대한 집단 지성을 형성할 가능성도 있습니다.
물론 해결해야 할 과제들도 많이 남아 있지만, MemOS는 AGI 시대의 필수 인프라 중 하나로 자리할 잠재력을 보여주고 있습니다. 요약하면, MemOS = Memory as an OS라는 슬로건 그대로, LLM에게 메모리 관리의 힘을 부여하여 더 똑똑하고 인간다운 인공지능 에이전트를 만드는 여정이라 할 수 있습니다. 앞으로 MemOS를 비롯한 메모리 강화 AI 연구가 어떻게 발전해나갈지 지켜보면서, 관련 기술을 미리 익혀두는 것도 의미 있는 일이 될 것입니다.
✅ 추가 내용
✳️ AI 개발자를 위한 메모리 계층 도입 가이드
LLM 시스템에서 "기억"을 설계해야 할 시점은 언제일까?
처음에는 대부분 RAG로 시작합니다. 하지만 다음과 같은 조건이 생기면 명시적 메모리 시스템(MemOS 계열)이 필요합니다:
| 조건 | 설명 | 필요한 메모리 |
| 사용자별 맞춤화 | 개인 이력, 선호, 상호작용 기록을 기억해야 함 | 사용자 단위 Plaintext Memory |
| 긴 세션 유지 | 1시간 이상 상호작용, 다단계 질의 흐름 | Activation Memory, Session Cache |
| 지식 축적 | 한 번 학습한 정보가 다음에도 반영되어야 함 | Parametric 또는 Editable Memory |
| 토큰 절감 | 반복되는 컨텍스트 삽입을 줄이고 싶을 때 | KV 캐시, Memory Scheduling |
| 협업 에이전트 구성 | 여러 에이전트 간 공유 메모리 필요 | Shared Memory, MemCube 구조 |
⏳ 메모리 전략: 단계별 도입 로드맵
| 단계 | 시점 | 메모리 전략 | 기술적 예시 |
| MVP | 0~3개월 | RAG + Prompt Template | LangChain Memory / Pinecone |
| 성장기 | 3~6개월 | 사용자 메모리 DB (Redis / SQLite) + 간단한 Cache | session cache, embedding 저장 |
| 확장기 | 6개월~ | MemOS 또는 구조화된 메모리 레이어 도입 | MemCube, Memory Lifecycle, Scheduler |
🧠 AI 개발자를 위한 메모리 아키텍처 전략 가이드
📍 1. 명시적 메모리 계층이 필요한 신호(Signs)
다음과 같은 조건이 하나라도 충족된다면, 단순한 RAG 기반 구조에서 벗어나 명시적 메모리 계층을 도입할 필요가 있습니다:
| 🔄 세션 간 정보 유지 | 한 사용자의 상호작용 맥락을 여러 대화 세션에 걸쳐 유지해야 하는 경우 |
| 👤 사용자 개인화 | 사용자별 성향, 과거 대화, 선호도 등을 반영한 응답이 필요한 경우 |
| 🧱 연속적 문제 해결 | 문제 해결이나 추론 과정이 여러 턴(turn)에 걸쳐 이루어지는 경우 |
| 📦 사용자 정의 지식 축적 | 사용자/관리자가 직접 정보를 추가하거나 수정해야 하는 경우 |
| ⚖️ 메모리 예산 최적화 | context token 제한에 걸리지 않도록 과거 정보를 선별적으로 넣고 싶은 경우 |
🧩 2. 메모리의 3가지 유형과 활용 우선순위
| 메모리 종류 | 설명 | 우선 적용 상황 |
| Parametric Memory | LLM 내부 파라미터에 내재된 지식 | 사전 학습 or 파인튜닝 기반 지식 축적 시 |
| Activation Memory | 추론 중 유지되는 임시 상태 (KV 캐시 등) | 긴 응답 or 이전 토큰을 반복 사용해야 할 때 |
| Plaintext Memory | 외부에 저장된 명시적 텍스트 (DB, 문서 등) | 사용자 대화, 사용자 정보, 정책 등 가변성 높은 정보 |
💡 Tip: 파라메트릭은 “잘 안 변하는 지식”, 플레인텍스트는 “자주 바뀌고 추적 가능한 정보”, 액티베이션은 “현재 작업 문맥”으로 이해하면 명확합니다.
⚔️ 3. RAG vs. 구조화 메모리 시스템(MemOS)
| 항목 | RAG 방식 | 구조화 메모리 시스템(예: MemOS) |
| 구조 | 비상태(stateless) 검색 기반 | 상태(stateful) + 수명 주기 관리 포함 |
| 저장 | 외부 벡터 DB 위주 | 다양한 형태의 메모리 (KV, DB, 파라미터) 통합 |
| 컨텍스트 삽입 | 매번 검색 후 프롬프트에 삽입 | 스케줄링, 캐시, 세션 유지 등 제어 가능 |
| 장기 기억 | 없음 (히스토리 저장만 가능) | 있음 (기억 버전 관리 및 진화) |
| 복잡도 | 낮음 (빠른 MVP 구성) | 높음 (설계 및 유지 비용 존재) |
📌 정리:
- 단기 MVP: RAG 우선
- 장기 운영 / 사용자 기반 확장: MemOS와 같은 구조화 시스템 도입 검토
🔰 4. 초기 단계 메모리 시스템 (Minimal Memory)
초기 제품은 복잡한 메모리 계층 없이도 다음의 간단한 구성으로 충분합니다:
- 기술: LangChain Memory, FAISS, Chroma, SQLite
- 목적: "그때 했던 말 기억해?" 수준 대응
- 구조: 텍스트 기반, 세션 기반, 메모리 수명 관리 없음
🚀 5. 서비스 확장에 따른 메모리 아키텍처 진화 전략
| 단계 | 특징 | 도입해야 할 메모리 설계 요소 |
| 📦 MVP (0~3개월) | 단일 사용자, 짧은 세션 | RAG + 세션 메모리 (PromptInjection) |
| 🌱 초기 확장기 (3~6개월) | 사용자 수 증가, 반복 사용자 발생 | 유저별 메모리 DB, 단순한 vector search |
| 🌿 성장기 (6~12개월) | 사용자 맞춤화 요구 증가 | Memory Type 분리 (activation + plain), 간단한 memory governance 도입 |
| 🌳 성숙기 (12개월~) | 복잡한 요구 + 장기 대화 흐름 | MemOS급 구조화 메모리 계층, memory lifecycle 관리, memory API 설계 필요 |
✅ 실무 적용 팁
- LLM이 "잘 기억하게 만들고 싶다" → 읽기(read) 전략부터 정하세요.
- 사용자가 "지식을 주입하고 싶다" → 쓰기(write) API 또는 메모리 주입 구조 필요.
- 멀티 에이전트 서비스 운영 예정 → 공유 가능한 메모리 형태 고려 (예: graph memory, multi-user MemCube)
- 시스템이 진화하면서 새로운 기억을 배우길 원함 → Memory Evolution을 염두에 두고 설계하세요
🧠 LLM이 "잘 기억하게 만들고 싶다" → Read 전략부터 정하세요
문제 정의:
사용자가 “전에 얘기한 거 기억해?”와 같은 질문을 했을 때, LLM이 관련 컨텍스트를 재현성 있게 응답할 수 있어야 함.
기술적 매핑:
| 항목 | 설명 | 구현 방식/ 스택 |
| 🔍 검색 기반 컨텍스트 주입 | LLM에 질의 전 관련 히스토리를 벡터 기반으로 검색해 프롬프트에 넣기 | FAISS, Weaviate, Chroma, Milvus + PromptTemplate |
| 🧠 KV Cache 유지 | 이전 생성 중 생성된 KV 캐시를 next prompt에 그대로 전달 | vLLM, llama.cpp 등 native KV cache 지원 모델 |
| 🧭 메모리 스케줄러 | 질의 유형에 따라 어떤 기억을 읽을지 선택/우선순위 조정 | MemScheduler 모듈 정의 (Rule-based or Learned) |
| 📑 Prompt Memory 관리 | 직전 대화 로그를 시스템 메시지로 고정 또는 시스템 룰로 삽입 | LangChain Memory (ConversationBufferMemory, SummaryMemory) |
사용 사례:
- 고객 상담에서 “지난주에 뭐라 하셨죠?” → 대화 로그에서 해당 질문 찾기
- 튜터 서비스에서 "내가 전에 뭐 틀렸지?" → 과거 오답 기록 검색 및 재입력
📥 사용자가 "지식을 주입하고 싶다" → Write API 또는 Memory Injection 구조 필요
문제 정의:
사용자가 모델에게 지식이나 규칙을 명시적으로 가르치고, 이후에 이를 반영하길 원함.
기술적 매핑:
| 항목 | 설명 | 구현 방식/스택 |
| ✍️ 사용자 지식 등록 API | 외부에서 JSON, Form 등으로 "이걸 기억해" 요청 받음 | FastAPI + /memory/write 엔드포인트 |
| 🧱 Structured Memory 저장 | 사용자가 준 지식/대화/규칙을 MemCube 형태로 저장 | MemOS API: add(), register_mem_cube() |
| 🔄 반영 방식 결정 | 저장된 메모리를 inference-time에 Prompt로 삽입 or 파라미터 학습 | PromptTemplate update or LoRA fine-tuning |
| 🧬 지속 메모리 저장소 | 사용자의 장기 지식 저장소를 영구적으로 보존 | Redis, PostgreSQL, Vector DB, JSONL File 등 선택 |
사용 사례:
- 보험사 직원이 질병 코드 기준 규칙을 추가하면 → 모델이 그 기준으로 응답
- 사용자가 직접 키워드를 정리 → 해당 내용은 이후 질의 시 참조
👥 멀티 에이전트 서비스 예정 → 공유 가능한 메모리 구조 고려
문제 정의:
여러 에이전트가 하나의 사용자 혹은 하나의 업무 흐름을 나눠 수행할 때, 공통된 기억을 공유해야 한다.
기술적 매핑:
| 항목 | 설명 | 구현 방식 /스택 |
| 🪢 공유 메모리 백엔드 | 여러 에이전트가 접근할 수 있는 DB or 메모리 계층 | Redis, Postgres, Neo4j, shared vector DB |
| 🔄 공유 권한 제어 | 어떤 메모리는 A만 읽을 수 있고 B는 쓰기만 가능하게 제어 | MemGovernance 정책 or ACL 제어 |
| 🌐 그래프 기반 메모리 | 각 에이전트의 노드 연결 구조와 기억 흐름 관리 | Neo4j, ArangoDB, MemOS + graph memory adapter |
| 🧩 에이전트별 메모리 뷰 | 전체 메모리 중 일부를 각 에이전트가 선택적으로 접근 | MemoryView API / MemoryFilter Layer (LLMWrapper 전 단계) |
사용 사례:
- 금융 도메인: 설계 에이전트와 보장 분석 에이전트가 같은 고객 기록을 참조
- HR 시스템: 이직 분석 AI와 인터뷰 생성 AI가 공통된 이력서 정보를 공유
🔁 시스템이 진화하면서 새로운 기억을 배우길 원함 → Memory Evolution 설계
문제 정의:
시스템이 사용자와 상호작용하며 새로운 정보나 행동 규칙을 학습, 점점 더 똑똑해지도록 하고 싶음.
기술적 매핑:
| 항목 | 설명 | 구현 방식 / 스택 |
| 🔄 메모리 수명 주기 관리 | 오래된 정보는 요약/폐기, 새로운 정보는 업데이트 | MemLifecycle 모듈 정의, memory TTL or summarization |
| 📈 학습 기반 메모리 진화 | 메모리 접근 로그 기반 중요도 자동 추정 및 구조 진화 | ranking model, access frequency 기반 scoring |
| 🧠 지속학습 기반 파라메터 반영 | 중요 기억은 LoRA로 변환하여 파라메트릭 메모리로 승격 | continual LoRA adapter training |
| 🗂️ 버전 관리 | 동일한 지식에 대해 시간별 버전 분리 저장 | versioned document store (ex: MongoDB with _version) |
사용 사례:
- 사용자가 자주 묻는 질의 → 요약해서 'FAQ' 메모리로 진화
- 사용자 질문 패턴 학습 → “질문 템플릿” 자동 생성
- 반복된 대화 규칙 → LoRA fine-tuning으로 반영
📌 종합 요약 테이블
| 실무 목적 | 주요 설계 키워드 | 기술 요소 / 스펙 |
| LLM이 기억하게 하기 | Memory Retrieval, KV Cache, Prompt Memory | LangChain Memory, FAISS, vLLM |
| 지식 주입 | Explicit Memory Write, Persistent Memory | FastAPI API, MemCube, Redis/Postgres |
| 다중 에이전트 공유 | Multi-agent Memory Graph, ACL | Neo4j, Graph DB, MemGovernance |
| 기억의 진화 | Lifecycle, Versioning, Summarization | LoRA, TTL Memory, Versioned Memory Store |
이 가이드는 단순히 '메모리를 써라'가 아니라, 시기와 상황에 맞는 메모리 전략 선택을 돕기 위한 로드맵입니다. 프로젝트 단계, 사용자 규모, 개인화 수준에 따라 메모리 시스템은 점진적으로 고도화되는 것이 자연스러운 흐름입니다.
MemOS는 그 최종 형태에 가까운 시스템이며, 단순한 RAG나 캐시 시스템에서 시작해도 충분히 갈 수 있습니다.
필요시, 아래와 같은 구조적 접근도 고려해보세요:
1. 현재 우리는 어떤 기억을 반복해서 사용하고 있는가?2. 이 기억은 일시적인가, 지속되어야 하는가?3. 그 기억이 변할 가능성은 있는가?4. 누구와 공유되는가?
이 질문만 잘 정리해도, 어떤 메모리 구조가 필요한지가 분명해집니다.
'관심있는 주제 > LLM' 카테고리의 다른 글
| MemOS: LLM 의 "Memory Operating System" 메모리 관련된 개념 이해하기 (4) | 2025.07.12 |
|---|---|
| 프롬프트 최적화 오픈소스 정리 (1) | 2025.05.07 |
| 논문 및 코드 리뷰) s1: Simple test-time scaling (50달러로 o1 만드는 방법 논문) (1) | 2025.02.09 |
| 논문 정리) DeepSeek (V3,R1) 논문을 보면서 기술적인 부분 알아보기 (2) | 2025.01.27 |
| LLM) HuggingFace 모델 다운로드부터 gguf 및 quantization 수행 후 vLLM 서빙하는 순서 정리해보기 (테스트 필요) (3) | 2024.11.16 |