AI 에이전트의 기억 상실을 고치는 오픈소스 Beads

🏷️ 정보 LLM 오픈소스

AI 에이전트에게 장기 작업을 맡겨보신 적 있으신가요? 세션을 새로 열면 이전에 내린 결정, 진행 상황, 맥락을 처음부터 다시 설명해야 합니다. 에이전트가 기억을 잃기 때문입니다.

이 문제를 해결하겠다는 오픈소스 프로젝트가 있습니다. 이름은 Beads입니다. Steve Yegge — 전 Google, Grab 엔지니어이자 긴 기술 에세이로 유명한 블로거 — 가 만들었고, GitHub에서 빠르게 22,000개 이상의 스타를 받았습니다(첫 커밋 후 6일 만에 1,000 스타).

원문 참고: https://x.com/vista8/status/2049651974317191464
GitHub: github.com/gastownhall/beads

아이디어는 좋습니다. 하지만 실제 상황은 조금 복잡합니다.

에이전트가 기억을 잃는 세 가지 방식

Beads가 해결하려는 문제는 하나가 아닙니다. Yegge는 세 가지 실패 패턴을 구분합니다.

세션 간 기억 상실(Inter-session Amnesia). 컨텍스트 창이 리셋되면 이전 세션에서 내린 결정이 사라집니다. 에이전트는 모릅니다.

작업 회피(Work Disavowal). 컨텍스트 창이 꽉 찰 즈음, 에이전트는 발견한 버그를 그냥 넘기고 작업을 완료한 것처럼 처리합니다. 발견한 문제를 기록할 공간이 없기 때문입니다.

발견 손실(Lost Discovery). 에이전트가 작업 중에 발견한 문제들이 체계적으로 추적되지 않아 사라집니다.

Markdown TODO 파일로는 이 세 가지 모두 제대로 해결되지 않습니다. 구조가 없고, 의존 관계를 표현할 수 없으며, 여러 에이전트가 동시에 쓰면 충돌이 납니다.

Beads가 쓰는 방식: SQL + 버전 관리

Beads의 핵심은 Dolt라는 데이터베이스입니다. Dolt는 MySQL 호환 SQL 데이터베이스인데, Git처럼 작동합니다. 모든 쓰기가 커밋 그래프에 기록되고, 브랜치·병합·롤백이 SQL 레벨에서 가능합니다.

여기에 Beads는 이슈 그래프를 올립니다. 에픽/태스크/서브태스크 중첩, 해시 ID(bd-a1b2 형식)로 충돌 없이 병렬 에이전트 쓰기, blocks, parent-child, related, discovered-from 등 4가지 의존 관계 링크. 여러 에이전트가 동시에 작업 상태를 읽고 쓰면서도 충돌이 없고, 이력이 남습니다.

이 구조는 단순 Markdown보다 명확히 낫습니다. SQL로 "지금 blocked 상태인 태스크를 만든 에이전트가 무엇인가"를 쿼리할 수 있습니다. Markdown 파일에서는 불가능한 일입니다.

그런데 Dolt가 문제를 만들었습니다

여기서 솔직하게 얘기해야 합니다.

Beads는 처음에 SQLite로 만들어졌습니다. SQLite는 의존성이 없고 단순합니다. 그런데 Yegge는 다중 에이전트 지원과 원격 동기화를 위해 Dolt로 마이그레이션했고, 이 과정에서 하위 호환성이 깨졌습니다. 동시에 Dolt는 CGO(C 바인딩)를 필요로 하는데, 이게 실제 환경에서 문제를 일으킵니다.

GitHub 이슈 추적을 보면 패턴이 보입니다.

한 이슈(#1812)에서는 사용자의 AI 어시스턴트가 Beads를 쓰다가 스스로 "GitHub Issues나 평범한 Markdown으로 돌아가는 게 낫겠다"고 권고했습니다. Dolt 의존성과 하위 호환성 부재를 이유로요.

커뮤니티의 반응은 명확합니다. Beads를 Rust로 포팅한 프로젝트(Dicklesworthstone/beads_rust)가 등장했는데, 이 프로젝트는 Dolt를 버리고 다시 SQLite로 돌아갔습니다. Dolt가 만드는 복잡성이 얻는 것보다 크다는 판단입니다.

"의미 기억 감쇠"의 진짜 정체

Beads 문서에서 의미 기억 감쇠(Semantic Memory Decay) 라는 표현이 나옵니다. 완료된 작업의 기억이 점진적으로 압축된다는 뜻처럼 들립니다.

실제 구현은 이렇습니다. bd admin compact --days 90. 90일 이상 된 완료 태스크를 삭제합니다. 신경망 기반 요약도, 임베딩 압축도, 의미 기반 감쇠 곡선도 없습니다. 오래된 레코드를 지우는 것입니다.

"Semantic"이라는 단어는 기술적 설명이 아니라 마케팅 언어입니다. 컨텍스트 창을 절약한다는 효과는 맞지만, 방식은 단순합니다.

대안들과의 비교

Beads 외에도 에이전트 메모리 문제를 풀려는 도구들이 있습니다.

Mem0(47,000 스타)는 벡터·그래프·키-밸류를 조합한 외부 메모리 레이어입니다. 드롭인 방식으로 붙이기 쉽고 프로덕션 사용 사례가 있습니다. 태스크 그래프 구조는 없지만 실제로 동작합니다.

Letta(MemGPT)(성숙한 3단계 메모리 아키텍처: 코어/리콜/아카이벌)는 에이전트 런타임에 깊이 통합된 방식입니다. 자기 수정 메모리와 정교한 검색을 지원하지만 런타임 종속성이 큽니다.

단순 파일은 의존성이 없고 사람이 읽을 수 있습니다. 쿼리가 안 되고 충돌에 약하지만, 많은 경우 충분합니다.

Beads가 경쟁하는 공간에서 가장 성숙한 대안은 Mem0입니다. 별점 차이(47k vs 23k)뿐 아니라 프로덕션 안정성 차이도 큽니다.

어떻게 볼 것인가

Beads가 정의한 문제(세션 간 기억 상실, 작업 회피, 발견 손실)는 정확합니다. SQL + 버전 관리로 에이전트 상태를 관리하겠다는 방향도 틀리지 않습니다.

다만 현재 상태는 알파입니다(v0.9.x). Dolt 마이그레이션으로 안정성이 떨어졌고, 문서가 부족하며, 기본 기능이 특정 환경에서 깨집니다. 스타 수가 실제 채택보다 빠르게 늘어난 이유 중 하나는 Yegge의 기존 독자층입니다.

장기 작업에 AI 에이전트를 써야 하는데 세션 단절이 실제 병목이라면, 지금 당장은 Mem0나 단순 구조화 파일을 먼저 보는 게 현실적입니다. Beads는 아이디어가 맞는 프로젝트이고, 1.0이 안정화되면 다시 살펴볼 가치가 있습니다.