일반 LLM은 대화창을 닫으면 모든 걸 잊는다(stateless). 그렇다고 매번 전체 대화를 통째로 프롬프트에 넣으면 토큰 비용·지연·정확도가 모두 무너진다. EverOS는 "기억을 어떻게 뽑고(extract) · 나누고(classify) · 보관하고(store) · 꺼낼(retrieve) 것인가"라는 메모리 시스템 문제를 정면으로 푼다. 상업 제품명은 EverMemOS, 오픈소스 레포 이름이 EverOS이며, 내부 코드네임은 memsys다.
LLM을 "매일 아침 기억이 초기화되는 천재"라고 해보자. 똑똑하지만 어제 한 얘기를 못 외운다. EverOS는 그 옆에 붙은 유능한 비서 + 외장 해마(hippocampus)다. 대화를 들으며 중요한 사실을 카드(MemCell)로 적어 서랍(Markdown·SQLite·LanceDB)에 분류해 넣고, 천재가 새 질문을 받으면 관련 카드만 쏙 뽑아 "참고로 이런 일이 있었어요"라고 귀띔한다. 천재는 그대로인데, 비서 덕분에 '기억하는 사람'처럼 행동한다.
2026년 현재 AI 에이전트의 가장 큰 한계는 지속성(persistence)이다. 모델은 세션이 끝나면 사용자가 누구였는지, 무슨 약속을 했는지 전부 잊는다. "그럼 컨텍스트 창을 키우면 되지 않나?" 싶지만, 창을 키울수록 비용·지연이 폭증하고, 정작 중요한 정보는 잡동사니 속에 묻혀(needle-in-a-haystack) 정확도가 떨어진다. EverOS는 이 빈틈을 선택적 기억으로 공략한다.
EverOS는 대화형 장기기억 평가 표준인 LoCoMo에서 93.05%를 기록해, 차순위 시스템(약 85.22%)을 크게 앞섰다고 공개한다. LongMemEval-S에서도 83.00%를 보고한다. 단순히 점수가 높은 것을 넘어, "풀컨텍스트로 전부 욱여넣은 LLM보다 적은 토큰으로 더 좋다"는 토큰 효율 메시지가 트렌딩의 핵심 동력이다.
| 항목 | EverOS / EverMemOS | 전형적인 메모리 라이브러리 |
|---|---|---|
| 구성 | 4계층 + 자체 인프라 풀스택(4 저장소) | SDK + 외부 벡터DB 1개 |
| 검색 | BM25 + 벡터 + RRF + 에이전틱 다중 회수 | 대개 벡터 검색 단독 |
| 기억 단위 | MemCell(동적 그래프) · Profile/Episodic/Skill 자동 분류 | 단순 텍스트 청크 |
| 자기진화 | Cases → Skill 증류로 경험 학습 | 없음(정적 저장) |
| 평가 | LoCoMo/LongMemEval/PersonaMem 내장 | 대개 자체 평가 부재 |
※ 비교 표의 "전형적인 라이브러리" 열은 일반적 경향이며, Mem0·Zep·LangMem 등 개별 제품의 최신 기능과는 다를 수 있다.
OpenClaw 에이전트 플러그인, Claude Code용 영속 메모리 플러그인(evermem-claude-code), TEN Framework 기반 Live2D 음성 캐릭터, computer-use 스크린샷 분석, "왕좌의 게임" Q&A 데모 등 붙일 곳이 많은 통합 사례를 전면에 내세운다. 또 brain-inspired(생물학적 각인) 컨셉과 기술 논문(준비 중), 100M 토큰 컨텍스트를 노리는 자매 프로젝트 MSA(Memory Sparse Attention)까지 묶여 "연구 + 제품 + 오픈소스"가 동시에 도는 점이 신뢰를 키운다. TrendShift 3위, ★3.6k의 빠른 성장세가 이를 방증한다.
EverOS는 거의 전부 Python(99.9%)으로 작성됐고, 패키지·환경 관리는 uv, PyPI 배포(pip install everos)를 통해 설치한다. EverOS 1.0.0에서 스토리지 스택이 전면 교체됐다. README가 직접 "No MongoDB, Elasticsearch, or Redis required"를 선언하며, 별도 인프라 컨테이너 없이 세 종류의 경량 스토리지만 사용한다. docker-compose.yaml은 현재 레포에 존재하지 않는다.
| 계층 | 구성요소 | 역할 — 왜 필요한가 |
|---|---|---|
| 언어/런타임 | Python 3.12+ · uv | 전체 코드 + 의존성/가상환경 관리(빠른 설치) |
| API 서버 | Python REST 서버 (포트 8000) | /api/v1/memories 저장·검색 엔드포인트, /health 헬스체크, MCP 인터페이스 |
| 소스 오브 트루스 | Markdown 파일 | MemCell 원본 기억 저장 — 사람이 읽을 수 있는 평문 형식 |
| 상태/큐/감사 | SQLite (aiosqlite · sqlmodel) | 메모리 상태·작업 큐·감사 로그 등 구조화 데이터 저장 |
| 벡터+하이브리드 검색 | LanceDB (lancedb ≥ 0.13.0) | 벡터 검색 + BM25 + 스칼라 필터를 단일 DB에서 처리 |
| 외부 AI | LLM API · 임베딩 API | LLM(추출·쿼리확장·융합) + 임베딩/리랭크 모델 호출 |
| 품질 도구 | ruff · pytest · pre-commit | lint+format(ruff)·테스트(pytest)·커밋 훅(pre-commit) |
pip+venv+pip-tools를 합친 도구로, uv sync 한 번에 uv.lock에 고정된 의존성을 정확히 재현한다. EverOS는 uv pip install everos로 설치 후 everos server start CLI로 서버를 기동한다.EverOS는 인간 인지를 모사한 4계층으로 설명된다. 위에서부터 ① 에이전틱(Agentic) 계층 — 계획·판단, ② 메모리(Memory) 계층 — 기억의 추출·분류·저장·회수, ③ 인덱스(Index) 계층 — 임베딩과 키워드 색인, ④ API/MCP 인터페이스 계층 — 외부 시스템 연결. 실무적으로는 이 계층들이 쓰기(기억하기)와 읽기(떠올리기) 두 개의 파이프라인으로 작동한다.
대화 메시지가 들어오면 LLM이 그 안에서 의미 있는 사실을 MemCell로 추출한다. 단순히 원문을 자르는 게 아니라 "사용자는 주말마다 축구를 한다" 같은 정제된 사실로 만든다. 이어서 각 MemCell을 타입으로 자동 분류한다.
분류된 MemCell은 원본이 Markdown 파일로 저장되고, 상태/큐/감사 정보는 SQLite에 기록되며, 임베딩 벡터와 BM25·스칼라 필터 색인은 LanceDB가 단일 DB로 처리한다. 별도 인프라 컨테이너 없이 세 계층이 협력해 하이브리드 검색을 지원한다.
질의가 오면 두 가지 모드 중 하나로 회수한다.
EverOS의 차별점은 기억이 정적이지 않다는 것이다. 에이전트의 작업 궤적을 Case(사례)로 기록하고, 반복되는 패턴을 Skill로 증류한다. 그러면 에이전트는 매번 백지에서 시작하지 않고 과거 경험에서 배운 능력을 재사용한다. MemCell들은 서로 연결된 동적 그래프로 관리되어 복잡한 연쇄 회상이 가능하다.
쓰기 파이프라인은 도서관 사서가 책을 정리하는 일이다. 들어온 자료(대화)를 요약 카드(MemCell)로 만들어 주제별 서가(타입)에 꽂고, 마크다운 파일로 원본을 보존하며 LanceDB에 키워드·벡터 색인을 동시에 갱신한다. 읽기 파이프라인은 "이 주제 자료 좀 찾아줘"라는 요청에 BM25 검색과 벡터 검색을 둘 다 돌려 가장 관련 높은 카드만 추려주는 일이다. Cases→Skills는 사서가 자주 들어오는 질문에 대한 답변 매뉴얼을 스스로 만들어 두는 것과 같다.
아래는 GitHub 루트에서 확인되는 실제 구조(gh api contents/ 기준)다. src/everos/가 메인 패키지이며, 4계층 DDD 구조로 정리돼 있다.
| 위치 | 읽는 순서/주목 포인트 |
|---|---|
README.md → QUICKSTART.md | 전체 그림 파악 + 빠른 설치·기동 절차 |
docs/ | 아키텍처·API·개발 가이드. docs/locomo_benchmark.md로 평가 실행법 확인 |
src/everos/infra/ | Markdown·SQLite·LanceDB 어댑터 — 스토리지 계층 코드의 핵심 |
src/everos/service/ | 메모리 추출·분류·회수 비즈니스 로직 |
tests/run_locomo_batch.sh | "좋은 메모리"를 수치로 증명하는 LoCoMo 평가 스크립트 |
가장 큰 배움은 "기억"을 하나의 데이터 파이프라인으로 바라보는 사고방식이다. 원문을 그대로 쌓지 않고 정제된 MemCell로 추출하고, 타입으로 나누고, 다중 저장소에 색인하고, 질의 시 선택적으로 회수한다.
자기 카톡/슬랙 대화 100줄을 EverOS API로 넣어보고, 추출된 MemCell이 Profile/Episodic/Skill 중 무엇으로 분류되는지 관찰해 보라. "분류 기준이 모호한 문장"을 일부러 넣어 경계 사례를 만들어 보면 분류 로직의 한계를 체감할 수 있다.
키워드 검색과 의미 검색은 서로의 약점을 보완한다. BM25는 정확한 고유명사·숫자에 강하고, 벡터는 동의어·패러프레이즈에 강하다. 둘을 RRF로 합치는 패턴은 검색·추천 전반에 그대로 응용된다.
같은 질의를 retrieve_method를 바꿔(예: 키워드만 / 벡터만 / hybrid) 던져보고 회수되는 MemCell을 비교하라. "정확한 단어가 핵심인 질문"과 "뜻은 같지만 표현이 다른 질문"을 각각 만들어 어느 모드가 이기는지 표로 정리하면 하이브리드의 가치를 정확히 이해한다.
Markdown(원본), SQLite(상태/큐), LanceDB(벡터+BM25)를 한 시스템에서 조율하는 구조를 배울 수 있다. 외부 인프라 컨테이너 없이 세 저장소가 협력해 "왜 단일 DB로 안 되는가"에 대한 현실적 답을 코드로 보여준다.
everos server start로 서버를 띄운 뒤 data/ 디렉토리의 Markdown 파일로 저장된 MemCell 원본을, LanceDB 테이블로 색인된 벡터를 각각 확인해 보라. "하나의 기억이 세 형태로 어떻게 나뉘어 저장되는지" 코드 레벨에서 추적하면 스토리지 설계 원칙을 체감할 수 있다.
LLM을 "답변기"가 아니라 전처리·후처리 도구로 쓰는 패턴(추출, 분류, 쿼리 확장, 결과 융합)을 배운다. 이는 에이전트 엔지니어링의 핵심 역량이다.
LLM_API_KEY에 더 작은 모델을 연결해 추출 품질이 어떻게 떨어지는지, agentic 모드의 비용/지연이 lightweight 대비 얼마나 증가하는지 측정해 보라.
"좋아졌다"를 느낌이 아니라 LoCoMo/LongMemEval 점수로 말하는 문화를 배운다. 검색·RAG 시스템을 만들 때 회귀 평가 세트를 갖추는 습관은 그 자체로 강력한 학습이다.
tests/run_locomo_batch.sh로 스모크 평가를 돌려 리포트 포맷을 익힌 뒤, 검색 파라미터(회수 개수 top-k 등)를 바꿔가며 점수 변화를 기록해 "튜닝 → 측정" 루프를 직접 돌려보라.
EverOS 1.0.0은 무거운 GPU가 필요 없고(임베딩·LLM은 외부 API 호출), MongoDB·Elasticsearch·Milvus·Redis 같은 별도 인프라 컨테이너도 필요 없다. pip install everos 후 everos server start만으로 기동 가능한 경량 구성이다. 실질적 요구사항은 Python 3.12+와 LLM/임베딩 API 키다.
| 항목 | 최소 | 권장 |
|---|---|---|
| Python | 3.12+ | 3.12+ (최신 안정판 권장) |
| 패키지 설치 | pip install everos | uv pip install everos |
| RAM | 2GB | 4GB+ (LLM API 호출 포함) |
| Docker | 불필요 | — |
| API 키 | LLM API 키 · 임베딩 API 키 | 동일 (필수, config.example.toml 참고) |
| 서비스 | 포트 | 비고 |
|---|---|---|
| API 서버 (앱) | 8000 | everos server start 로컬 실행 |
python --version으로 먼저 확인config.example.toml을 복사해 키 입력 후 everos init 실행pip install everos(또는 uv pip install everos) 후 everos server start로 서버 기동. curl http://localhost:8000/health로 {"status":"ok"}를 확인한 뒤, README의 Basic Usage 코드로 MemCell 하나를 저장하고 검색해 본다.
학습 목표: 저장(POST)–검색(GET) 왕복과 API 형태 이해.
use-cases/ 디렉토리의 예제를 순서대로 실행한다. 샘플 대화에서 어떤 MemCell이 추출되고, 그 기억이 대화에 어떻게 반영되는지 관찰.
학습 목표: 추출→저장→대화 활용의 end-to-end 흐름 체감.
자신의 대화 로그를 입력해 메모리를 구축하고, 동일 질의를 lightweight와 agentic 모드로 각각 회수해 결과·지연·토큰을 표로 비교한다. multi-hop 질문("작년에 ~했던 그 사람이 추천한 책 제목?")을 일부러 넣어 보라.
학습 목표: 검색 모드 트레이드오프를 정량적으로 이해.
everos server start로 서버를 띄운 뒤 bash tests/run_locomo_batch.sh --conv-indices 0-9 --methods hybrid --base-url http://localhost:8000 --top-k 10으로 스모크 평가를 실행한다. top-k·methods 파라미터를 바꿔가며 점수 변화를 기록해 "튜닝→측정" 루프를 직접 만든다.
학습 목표: 평가 주도 개발(EDD)과 회귀 측정 습관.
두 갈래 중 택1 — (A) MCP 인터페이스 또는 Claude Code 플러그인(evermem-claude-code)으로 실제 에이전트에 EverOS를 연결해 "기억하는 봇"을 만든다. (B) 검색 융합 로직(RRF 가중치)이나 새 메모리 타입을 추가해 평가 점수에 미치는 영향을 측정한다.
학습 목표: 실서비스 통합 또는 내부 알고리즘 개조 경험.
| 주차 | 주제 | 핵심 학습 + 연결점 |
|---|---|---|
| 1주차 | 벡터 임베딩 & 의미 검색 | 임베딩이 무엇인지, 코사인 유사도, ANN 인덱스(HNSW/IVF). Milvus 기본 컬렉션 만들기 → EverOS의 벡터 계층 이해 |
| 2주차 | 키워드 검색 & 하이브리드 | BM25 원리, Elasticsearch 색인/질의, 그리고 RRF로 두 검색 융합 → EverOS 읽기 파이프라인의 코어 |
| 3주차 | RAG → mRAG, 메모리 라이브러리 지형 | 기본 RAG 구축 후 Mem0·Zep·LangMem과 EverOS의 설계 차이 비교 → "왜 MemCell·타입 분류인가" |
| 4주차 | 에이전트 메모리 이론 | 인지과학의 episodic/semantic/procedural 기억 구분, 망각·강화 → EverOS의 Profile/Episodic/Skill 분류 근거 |
| 5주차 | 경량 멀티 스토리지 설계 | Markdown·SQLite·LanceDB 각 계층의 역할 분리, 인프라 컨테이너 없는 아키텍처 패턴 → src/everos/infra/ 어댑터 코드 정독·재현 |
| 6주차 | 평가 & 자기진화 에이전트 | LoCoMo/LongMemEval 평가 설계, Cases→Skills 같은 경험 학습 루프 → tests/run_locomo_batch.sh · docs/locomo_benchmark.md 분석·확장 |
| 용어 | 뜻 (한 줄) |
|---|---|
| Memory OS | LLM 외부에 기억을 저장·관리·회수하는 독립 시스템. EverOS의 정체성. |
| MemCell | 대화에서 추출한 정제된 기억 단위. 동적 그래프로 연결돼 연쇄 회상 가능. |
| Stateless LLM | 세션이 끝나면 모든 맥락을 잊는 기본 LLM 동작. EverOS가 해결하려는 문제. |
| Profile / Episodic / Skill | EverOS의 자동 메모리 타입 — 지속 속성 / 시점 사건 / 재사용 능력. |
| mRAG (memory-RAG) | 문서가 아닌 구조화된 기억을 대상으로 하는 RAG. |
| BM25 | TF-IDF 기반 키워드 랭킹 함수. LanceDB가 벡터 검색과 함께 처리. |
| 벡터 임베딩 | 문장을 의미 벡터로 변환한 것. 의미 유사도 검색의 기반. LanceDB가 담당. |
| RRF | Reciprocal Rank Fusion — 순위 기반으로 여러 검색 결과를 융합. |
| Lightweight / Agentic 회수 | 빠른 BM25+벡터 모드 / LLM 질의확장·다중회전 모드. |
| Query Expansion | 원 질의를 LLM이 보강·확장해 회수율을 높이는 기법. |
| Cases → Skills | 작업 궤적(Case)에서 반복 패턴을 능력(Skill)으로 증류하는 자기진화. |
| LanceDB | 오픈소스 멀티모달 벡터 DB. 벡터·BM25·스칼라 필터를 단일 DB에서 처리. EverOS 1.0의 핵심 스토리지. |
| SQLite | 경량 임베디드 관계형 DB. 별도 서버 불필요. EverOS에서 상태·큐·감사 로그 저장. |
| 폴리글랏 퍼시스턴스 | 데이터 성격별로 서로 다른 저장소를 함께 쓰는 설계 원칙. |
| MCP | Model Context Protocol — 에이전트·도구·데이터 소스를 잇는 표준 인터페이스. |
| LoCoMo / LongMemEval / PersonaMem | 장기 대화 기억을 평가하는 벤치마크 3종. |
| uv | Rust 기반 초고속 Python 패키지/환경 매니저. |
| MSA (Memory Sparse Attention) | 100M 토큰 컨텍스트를 노리는 EverMind의 자매 연구 프로젝트. |