OpenChronicle: LLM 에이전트 메모리를 클라우드 없이 공유하는 로컬 퍼스트 아키텍처

AI 에이전트가 기억을 갖는다는 것은 단순히 대화 이력을 저장하는 것을 넘어, 맥락을 이해하고 경험을 축적하며 다른 에이전트와 지식을 공유하는 능력을 의미한다. 2026년 4월, OpenAI가 Chronicle이라는 유료 메모리 서비스를 공개한 지 48시간 만에 'Vida'라는 Gen Z 개발자 팀이 OpenChronicle이라는 오픈소스 대안을 공개했다. 이 프로젝트는 클라우드 의존 없이 로컬에서 실행되면서도 멀티 에이전트 환경에서 메모리를 공유할 수 있는 구조를 제공한다.

OpenChronicle이 등장한 배경

OpenAI Chronicle은 AI 에이전트가 사용자의 활동 맥락을 지속적으로 기억하고 적용할 수 있게 하는 서비스다. 문제는 이 기능이 월 $100 이상의 구독료 뒤에 잠겨 있다는 점이었다. Vida 팀은 "AI의 메모리 기능이 고가의 구독 뒤에 갇혀 있어서는 안 된다"는 신념을 바탕으로 OpenChronicle을 오픈소스로 공개했다.

OpenChronicle이 주목받는 이유는 단순히 무료라는 점이 아니다. 아키텍처 관점에서 근본적으로 다른 접근을 택했기 때문이다. 데이터가 사용자 기기에 저장되고, 어떤 LLM 모델과도 연동되며, 도구 호출이 가능한 모든 에이전트에서 사용할 수 있는 범용 메모리 계층을 지향한다.

LLM 에이전트 메모리를 나누는 기준

LLM 에이전트에서 메모리는 기능과 생명주기에 따라 크게 네 가지로 구분된다.

단기 메모리(Working Memory)는 현재 대화나 작업 세션의 맥락을 유지한다. LLM의 컨텍스트 윈도우가 이 역할을 담당하며, 세션이 끝나면 사라진다. 처리 속도가 빠르지만 용량이 제한적이고 휘발성이라는 단점이 있다. 에피소드 메모리(Episodic Memory)는 구체적인 경험과 사건의 기록이다. 개별 도구 호출, 대화 턴, 환경 관찰 결과가 여기에 해당한다. 시간 순서와 맥락이 보존되어 "언제 무엇을 했는가"를 재구성할 수 있다. 시맨틱 메모리(Semantic Memory)는 에피소드에서 추출된 추상화된 지식이다. 반복되는 패턴, 사용자 선호, 프로젝트 맥락 등이 일반화된 형태로 저장된다. 에피소드 메모리가 '경험'이라면 시맨틱 메모리는 '지식'이다. 절차 메모리(Procedural Memory)는 재사용 가능한 기술과 실행 계획을 담는다. 특정 작업을 수행하는 방법, 도구 사용 패턴, 검증된 워크플로우 등이 포함된다.

OpenChronicle은 이 네 가지 유형을 하나의 통합된 로컬 저장소로 관리하는 구조를 택했다.

SQLite와 Markdown으로 짠 기술 아키텍처

OpenChronicle의 핵심 기술 스택은 놀라울 정도로 단순하다. SQLite FTS5로 전문 검색 인덱스를 관리하고, Markdown 파일로 메모리를 사람이 읽을 수 있는 형태로 보존한다.

데이터 캡처 파이프라인은 다음과 같이 동작한다.

⤢✕

macOS의 AX(Accessibility) 트리를 우선적으로 활용하는 이유는 명확하다. 스크린샷 기반 OCR보다 구조화된 텍스트 처리가 비용 효율적이고, 현재 포커스된 요소와 의도를 더 정확하게 파악할 수 있기 때문이다. AX 트리는 앱이 노출하는 시맨틱 구조를 그대로 반영하므로, 에이전트가 "무엇을 보고 있는가"를 구조적으로 이해할 수 있다.

저장된 메모리는 사용자, 프로젝트, 도구, 주제별로 분류된 Markdown 파일 형태를 유지한다. 이는 투명성을 핵심 설계 원칙으로 삼은 결과다. 개발자가 에이전트의 기억 내용을 직접 열어보고 편집할 수 있으며, 버전 관리 시스템에 포함시킬 수도 있다.

여러 에이전트가 메모리를 함께 쓸 때 생기는 문제

단일 에이전트 메모리와 달리 멀티 에이전트 환경에서는 여러 에이전트가 동시에 메모리를 읽고 쓰는 상황이 발생한다. 이는 전통적인 데이터베이스의 동시성 문제와 유사하지만, LLM 에이전트 특유의 복잡성이 더해진다.

2026년 발표된 아르카이브 논문 "Multi-Agent Memory from a Computer Architecture Perspective"는 이 문제를 컴퓨터 아키텍처 관점에서 재정의한다. 핵심 도전 과제는 두 가지다. 첫째, 읽기 시점 충돌 처리다. 메모리 레코드가 시간에 따라 진화하면서 이전 버전의 데이터가 잔존할 수 있다. 어떤 에이전트가 오래된 정보를 기반으로 추론한다면 시스템 전체의 일관성이 깨진다. 둘째, 업데이트 시점 가시성이다. 한 에이전트의 쓰기 작업이 다른 에이전트에게 언제 보이는지를 명확히 정의해야 한다. 즉각적인 전파를 보장할수록 성능 비용이 증가한다.

현재 생산 환경에서 채택되는 메모리 아키텍처는 세 가지 패턴으로 분류된다.

⤢✕

중앙 집중형은 단순하지만 에이전트 수가 증가할수록 병목이 생긴다. 분산형은 확장성이 높지만 일관성 유지가 어렵다. 실제 프로덕션 시스템에서는 로컬 캐시와 공유 장기 저장소를 결합한 하이브리드 접근이 주류를 이루고 있다.

OpenChronicle은 로컬 SQLite를 기반으로 하면서도 MCP(Model Context Protocol)를 통해 에이전트 간 메모리 접근을 가능하게 한다. 동일한 MCP 서버에 연결된 에이전트들은 공통 메모리 풀을 조회하고 새로운 기억을 기록할 수 있다.

일관성 수준과 충돌 해소 전략

멀티 에이전트 메모리에서 일관성 수준은 성능과 정확성 사이의 트레이드오프를 결정한다. 연구들이 제안하는 일관성 스펙트럼은 다음과 같다.

세션 일관성(Session Consistency)은 동일 세션 내 에이전트가 자신의 이전 쓰기를 항상 볼 수 있음을 보장한다. 구현이 쉽고 대부분의 단일 대화 시나리오에 충분하다. 인과 일관성(Causal Consistency)은 인과 관계가 있는 이벤트의 순서를 보존한다. 에이전트 A의 결정이 에이전트 B의 행동에 영향을 미쳤다면, B는 항상 A의 최신 상태를 볼 수 있다. 최종 일관성(Eventual Semantic Consistency)은 충돌하는 메모리 항목을 즉시 해소하지 않고 LLM 기반 조정 프로세스를 통해 주기적으로 통합한다. 성능이 높지만 단기적으로 불일치가 발생할 수 있다. 강한 일관성(Strong Consistency)은 모든 쓰기가 즉시 모든 에이전트에 반영되도록 보장한다. 분산 잠금 메커니즘이 필요하여 성능 비용이 크다.

대부분의 LLM 에이전트 시나리오에서는 인과 일관성이 실용적인 균형점으로 여겨진다.

로컬 퍼스트가 프라이버시·엣지 배포에 갖는 의미

로컬 퍼스트 아키텍처가 주목받는 이유는 단순히 인터넷 연결 없이 동작한다는 것을 넘어선다. 데이터 주권, 프라이버시, 그리고 엣지 컴퓨팅의 확산이 이 접근 방식을 전략적 선택으로 만든다.

데이터 프라이버시 보호 측면에서, 에이전트 메모리에는 사용자의 작업 패턴, 커뮤니케이션 습관, 프로젝트 세부사항 등 민감한 정보가 집약된다. 이 데이터를 클라우드 서버로 전송하면 제3자 접근, 데이터 유출, 규제 준수 문제가 발생할 수 있다. 로컬 저장은 이러한 위험을 근본적으로 차단한다. 오프라인 동작 능력은 의료 현장, 제조 공장, 항공기 내부 등 네트워크 연결이 불안정한 환경에서 결정적 이점이 된다. 에이전트가 클라우드 의존 없이 이전 맥락을 활용할 수 있다면 적용 가능한 시나리오가 대폭 확대된다. 엣지 배포 전략에서 로컬 퍼스트 메모리는 핵심 구성 요소다. Apple Silicon M 시리즈 칩과 같은 엣지 하드웨어에서 Ollama, LM Studio를 통해 로컬 LLM을 실행하면서 OpenChronicle이 메모리 계층을 담당하는 구성이 점차 보편화되고 있다.

RAG 파이프라인과 맞물리는 지점

OpenChronicle의 SQLite FTS5 기반 검색은 RAG(Retrieval-Augmented Generation) 파이프라인과 자연스럽게 통합된다. 에이전트가 현재 작업에 관련된 과거 맥락을 검색하고 그 결과를 프롬프트에 포함시키는 흐름이 도구 호출 하나로 완성된다.

⤢✕

이 흐름에서 에이전트는 매 요청마다 관련 기억을 검색하고, 작업 결과를 다시 메모리에 기록한다. 시간이 지날수록 에이전트의 응답 품질이 향상되는 자기 강화 사이클이 형성된다.

시맨틱 검색을 위해서는 벡터 임베딩을 추가할 수 있다. SQLite에 벡터 확장(sqlite-vss 또는 vec0)을 추가하면 의미 기반 유사도 검색이 가능해진다. FTS5의 키워드 검색과 벡터 검색을 결합한 하이브리드 검색은 리콜과 정밀도를 동시에 높이는 현재의 모범 사례다.

특정 모델에 묶이지 않는 설계

OpenChronicle의 설계 원칙 중 하나는 특정 모델 제공자에 종속되지 않는 것이다. OpenAI GPT 시리즈, Anthropic Claude, Meta Llama, Mistral, 그리고 Ollama나 LM Studio를 통해 실행되는 로컬 모델 모두와 호환된다.

MCP(Model Context Protocol) 클라이언트와의 호환성은 특히 중요하다. Claude Desktop, GitHub Copilot, Codex 등 MCP를 지원하는 에이전트들이 OpenChronicle을 공통 메모리 레이어로 활용할 수 있다. 이는 하나의 메모리 인프라를 여러 AI 도구가 공유하는 진정한 멀티 에이전트 메모리 생태계를 가능하게 한다.

에이전트 간 메모리 공유 시나리오를 구체적으로 살펴보면, 코딩 에이전트가 프로젝트 구조와 결정 이유를 기록하면, 코드 리뷰 에이전트는 그 맥락을 읽어 더 정확한 피드백을 제공한다. 문서화 에이전트는 두 에이전트의 기록을 종합하여 개발 이력을 자동으로 문서화한다. 모든 과정이 로컬에서 이루어지고 어떤 데이터도 외부 서버로 전송되지 않는다.

OpenChronicle은 AI 에이전트 메모리의 민주화를 상징하는 프로젝트다. 클라우드 서비스에 고가의 구독료를 지불하지 않고도 LLM 에이전트에 지속적이고 공유 가능한 메모리를 부여할 수 있음을 증명했다. 로컬 퍼스트 설계는 프라이버시 보호와 오프라인 동작이라는 실질적 이점을 제공하며, SQLite와 Markdown이라는 검증된 기술 스택은 투명성과 개발자 친화성을 보장한다. 멀티 에이전트 메모리 공유와 일관성 보장이라는 아직 해결 중인 과제들이 있지만, OpenChronicle이 제시한 방향은 앞으로의 에이전트 인프라 설계에 중요한 참조점이 될 것이다.