AI 에이전트를 실무에 적용하면 금세 한계가 드러납니다. 대화가 끝나면 맥락이 끊기고, 이전 실행에서 얻은 실패 경험이나 작업 절차가 다음 작업으로 잘 이어지지 않습니다.
EverOS는 이 문제를 다루는 오픈소스 Python 프레임워크입니다. 대화, 에이전트 실행 궤적, 파일을 구조화된 장기 기억으로 바꾸고, 필요할 때 다시 검색할 수 있게 합니다.1 핵심은 단순히 “기억을 저장한다”가 아니라, 그 기억을 사람이 읽고 운영할 수 있는 형태로 남긴다는 점입니다.
EverOS의 핵심 선택: Markdown을 원본으로 둔다
EverOS에서 메모리의 원본은 일반 .md 파일입니다.1 기억이 벡터 데이터베이스 안에만 갇히지 않기 때문에 개발자는 파일을 직접 열어 확인하고, 수정하고, grep으로 찾고, Git으로 버전 관리할 수 있습니다. Obsidian 같은 도구로 열람하는 것도 가능합니다.1
이 선택은 개인 개발자와 소규모 팀에 특히 실용적입니다. AI 메모리 시스템을 운영하기 위해 MongoDB, Elasticsearch, Milvus, Redis, Kafka 같은 인프라를 필수로 붙이지 않아도 되기 때문입니다.1 EverOS는 로컬 배포를 전제로, 작은 팀이 감당할 수 있는 방식으로 설계됐습니다.1
즉 EverOS가 제안하는 방향은 “더 거대한 저장소”가 아니라 “운영 가능한 기억”에 가깝습니다. 메모리를 사람이 읽을 수 있는 파일로 남기고, 필요한 부분만 인덱스로 보완하는 방식입니다.
Markdown만으로는 부족하므로 인덱스를 붙인다
Markdown은 원본으로 적합하지만, 에이전트가 빠르게 검색하기에는 별도 인덱스가 필요합니다. EverOS의 저장 구조는 이 역할을 세 구성요소로 나눕니다.1
Markdown 파일: 메모리 원본
SQLite: 상태, 큐, 감사 로그 저장
LanceDB: 벡터 인덱스, BM25 인덱스, 스칼라 필터
검색에서는 BM25와 벡터 검색을 함께 사용합니다. BM25는 키워드 기반 검색에 강하고, 벡터 검색은 의미가 비슷한 내용을 찾는 데 적합합니다. 두 방식을 결합하면 정확한 단어로 찾는 검색과 의미 기반 검색을 함께 활용할 수 있습니다.
여기서 중요한 점은 인덱스가 원본을 대체하지 않는다는 것입니다. 원본은 Markdown이고, SQLite와 LanceDB는 이를 더 잘 운영하고 검색하기 위한 보조 구조입니다. 이 구조는 AI 메모리를 감사 가능하고 이동 가능한 데이터로 다루려는 설계에 가깝습니다.
에이전트 메모리는 채팅 기록보다 넓어야 한다
에이전트의 장기 기억은 단순한 대화 로그가 아닙니다. EverOS는 대화뿐 아니라 에이전트 실행 궤적과 파일까지 장기 기억의 재료로 다룹니다.1
이 관점이 중요한 이유는 실무형 에이전트가 기억해야 할 내용이 사용자 취향에만 머물지 않기 때문입니다. 예를 들어 “사용자가 어떤 표현을 선호하는가”도 중요하지만, “이 프로젝트에서는 어떤 절차로 테스트하는가”, “이전 실행에서 어떤 오류가 반복됐는가”, “다음에는 어떤 순서로 작업해야 하는가” 같은 실행 경험도 축적돼야 합니다.
EverOS의 메모리 추출 알고리즘은 별도 라이브러리인 EverAlgo로 분리돼 있습니다.1 이는 저장소와 추출 로직을 구분하려는 설계로 볼 수 있습니다. 메모리를 어디에 저장할지뿐 아니라, 무엇을 기억으로 추출할지도 별도의 문제로 다룬다는 뜻입니다.
구조를 보면 운영 관점이 보인다
EverOS 아키텍처는 CLI·HTTP API, 서비스, 메모리 도메인, 인프라, 공통 컴포넌트·코어 계층으로 나뉩니다.1 이 구분은 EverOS가 단순한 파일 저장 도구가 아니라, 에이전트 기억을 생성·관리·검색하는 프레임워크를 지향한다는 점을 보여줍니다.
개발자 입장에서 실용적인 판단 기준은 분명합니다.
메모리 원본을 사람이 읽을 수 있는가
검색을 위해 키워드 검색과 의미 검색을 함께 쓸 수 있는가
로컬에서 운영 가능한가
작은 팀이 감당하기 어려운 필수 인프라를 요구하지 않는가
기억을 나중에 감사하고 수정하고 버전 관리할 수 있는가
EverOS는 이 질문들에 대해 Markdown, SQLite, LanceDB 조합으로 답합니다.
정리
EverOS의 의미는 새로운 대형 데이터베이스를 제안하는 데 있지 않습니다. 오히려 AI 에이전트의 기억을 읽을 수 있는 Markdown 파일로 되돌리고, 필요한 검색 성능은 SQLite와 LanceDB 기반 인덱스로 보완하는 데 있습니다.
에이전트를 만들고 있다면 EverOS에서 배울 점은 명확합니다. 메모리는 단순 저장소가 아니라 운영 대상입니다. 읽을 수 있어야 하고, 고칠 수 있어야 하며, 검색 가능해야 합니다. 그리고 시간이 지나면서 더 나은 절차와 경험으로 정리될 수 있어야 합니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.