Engrim 1.3.0: 다중 모델 AI CLI를 위한 로컬 우선 SQLite 메모리 엔진

TL;DR

Engrim 1.3.0은 AI 코드 보조 도구(Google Antigravity, Claude Code, Cursor, Windsurf)에 로컬 우선의 SQLite 기반의 에피소딕 메모리 계층을 제공하여, 모든 데이터를 오프라인 및 개인 정보 보호 상태로 유지하면서 모델 전환과 컨텍스트 지속을 원활하게 합니다.

핵심 가치 제안

Engrim은 대규모 토큰 창이 잡음이 많고 비용이 큰 '주의 분산' 문제를 해결하기 위해 4KB의 정제된 작업 메모리를 SQLite에 저장합니다. 주요 이점은 다음과 같습니다:

벤더에 구애받지 않는 연속성 – 프로젝트 중에 Gemini 3.8에서 Claude 3.7 Sonnet, GPT-4o로 전환해도 결정사항, 제약 조건, 아키텍처를 재설명하지 않고 유지할 수 있습니다.
명시적인 저장 버튼 의미 – 개발자는 에이전트 세션을 (/clear) 초기화할 수 있지만, Engrim은 자동으로 정제된 메모리 팩을 다시 불러옵니다.
하이브리드 검색 – FTS5 BM25 단어 검색과 정적 model2vec 임베딩을 사용하는 0지연 상호 순위 융합 엔진을 결합합니다.

“모든 턴마다 잊혀진 잡음 20만 토큰을 왜 지불해야 할까요? 모델은 일시적인 도구이지만, 프로젝트의 결정은 그렇지 않습니다.” – Engrim README

실증적 증거 (105세션 사례 연구)

5만 라인 규모의 알고리즘 트레이딩 코드베이스에서의 프로덕션 테스트 결과:

153,000 토큰의 작업이 1,000 토큰 미만의 활성 메모리로 압축되어 ≈99% 감소했습니다.
Antigravity, Claude Code, Cursor 간 전환 후 186개의 단위 테스트에서 회귀 오류가 발생하지 않았습니다.
프로젝트 중간에 에이전트를 교체해도 컨텍스트 망각이 관찰되지 않았습니다.

저자는 테스트가 지속적인 세션을 포함했지만, Hacker News에서의 논의는 벤치마크 비교 가능성과 비정상 종료 처리에 대한 의문을 제기했습니다.

아키텍처 개요

에이전트 (Antigravity, Claude Code, Cursor/Windsurf) → 어댑터 및 후크 →
   출처 추적 엔진 (origin_agent 추적) →
   하이브리드 검색 (bm25 + 벡터) →
   SQLite 저장소 (~/.engrim/memory.db)

Memories 테이블 – 정제된 기록(결정사항, 사실, 피드백)을 저장합니다.
FTS5 – 포터 스테밍과 트리거를 사용하는 전체 텍스트 검색.
벡터 컬럼 – 의미적 재검색을 위한 정적 model2vec 임베딩.
비행기 기록 로그 – 감사 및 검토를 위한 원시 턴별 대화 기록.

다중 에이전트 환경에서의 빠른 시작

pip install engrim
engrim setup            # Antigravity, Claude, Cursor, Windsurf 자동 감지
# 또는 에이전트별 명시적 설정
engrim setup --agy      # Antigravity 후크
engrim setup --claude   # Claude Code 후크
engrim setup --cursor   # Cursor MCP 등록
engrim setup --all      # 지원되는 모든 에이전트 구성

--dry-run을 사용하면 파일 변경 사항을 미리 보여주되 쓰지 않습니다.

출처 추적

모든 메모리 항목은 origin_agent 필드(antigravity, claude-code, cursor, cli, user)를 기록합니다. engrim list의 예시 출력:

[DECISION]
- #961 (via Antigravity): 고변동성에 대한 역방향 스탑로스 매트릭스
- #942 (via Claude Code): 주 데이터베이스를 MongoDB에서 PostgreSQL으로 전환
- #910 (via Cursor): Pydantic v2 스키마 표준화

기존 데이터베이스는 ALTER TABLE을 통해 자동으로 마이그레이션되며, 출처 컬럼이 추가됩니다.

모델 컨텍스트 프로토콜 (MCP) 서버

0의 종속성 JSON-RPC 2.0 stdio 서버를 실행합니다:

engrim serve --mcp   # 또는 단순히 `engrim mcp`

서버는 stdout을 JSON-RPC 메시지에 할당하고 진단 정보는 stderr로 전송합니다.

핵심 MCP 메서드

메서드	서명	목적
`engrim_recall`	`(query: str, project: str = "auto", k: int = 5, type: str = None)`	하이브리드 키워드 + 의미 검색.
`engrim_add`	`(type: str, summary: str, detail: str = None, tags: list[str] = [])`	메모리 기록을 영구 저장합니다.
`engrim_context`	`(project: str = "auto", budget: int = 4000)`	세션 부팅을 위한 예산 제한된 메모리 팩 반환.
`engrim_review`	`(project: str = "auto")`	지우기 전에 포착되지 않은 결정을 로그에서 스캔합니다.

CLI 참조 (선택된 명령어)

명령어	예시	설명
`engrim add`	`engrim add -t decision -s "..."`	메모리 기록 삽입 (유형: decision, fact, feedback, state, user, reference).
`engrim recall`	`engrim recall -q "database"`	현재 프로젝트에 대한 하이브리드 순위 재검색.
`engrim context`	`engrim context -b 4000`	우선순위 정렬된, 문자 예산 제한된 부팅 팩 검색.
`engrim hook`	`engrim hook --agent agy --event boot`	Antigravity 또는 Claude Code의 라이프사이클 후크 실행.
`engrim serve`	`engrim serve --mcp`	에이전트 통합을 위한 MCP 서버 시작.
`engrim review`	`engrim review`	지우기 전 최근 결정이 모두 포착되었는지 확인.
`engrim list`	`engrim list -k 20`	현재 프로젝트의 최근 메모리 표시.

"계속-정리" 워크플로우

포획 – 결정이나 규칙이 생길 때마다 engrim add (또는 MCP engrim_add)를 사용합니다.
재시작 포인터 고정 – 다음 즉각적인 작업을 설명하는 resume-pointer 태그가 붙은 기록을 추가합니다. 가장 최신의 포인터는 다음 부팅 시 [▶ RESUME HERE]로 표시됩니다.
검토 – engrim review를 실행하여 중요한 결정이 누락되지 않았는지 확인합니다.
정리 – 에이전트에서 /clear를 실행합니다. Engrim은 다음 프롬프트에서 자동으로 정제된 메모리 팩을 주입합니다.

보안 및 개인정보 보장

100% 로컬 및 오프라인 – 모든 데이터는 ~/.engrim/memory.db에 저장되며, 텔레메트리나 클라우드 동기화가 없습니다.
파일 권한 – SQLite 파일은 0600 (소유자 전용) 권한으로 생성됩니다.
Git 안전성 – 기본적으로 *.db는 git에서 무시되며, 실수로 커밋되는 것을 방지합니다.
선택적 임베딩 – ENGRIM_EMBED=off를 설정하면 순수한 단어 검색만 사용하여 model2vec 패키지가 필요 없게 됩니다.

커뮤니티 피드백 (Hacker News 요약)

@thih9: “인수 없이 engrim setup을 실행하면… 제거 스크립트는 포함되어 있나요?” – 사용자들은 깔끔한 정리 도구를 요청하고 있으며, 현재 리포지토리는 이를 제공하지 않습니다.

@aidiveyt: “정지 후크는 턴을 차단할 수도 있습니다: 메시지와 함께 exit 2를 반환하면 체크가 통과할 때까지 세션이 계속 작동합니다.” – 후크 실패가 올바르게 전파되어 세션 안정성이 유지됨을 시사합니다.

@corv: “저는 gbrain을 공급자 독립적 메모리로 사용하지만, 실제로 SQLite의 가벼움을 놓치고 있었기 때문에 이건 흥미롭습니다!” – 다른 메모리 백엔드와 비교했을 때 SQLite의 최소한의 크기 영향력을 강조합니다.

@dsemakin: “실제로 메모리가 언제 기록되나요? 내가 engrim add를 기억해야 하나요?” – 메모리 생성이 명시적임을 명확히 하며, 개발자는 engrim add (또는 MCP engrim_add)를 호출해야만 사실을 기록해야 함을 설명합니다.

@flippant: “다른 메모리 플러그인을 사용해 왔습니다… 결정 요약은 정말 멋지지만, 에이전트/모델 정보는 제게는 유용하지 않을 수 있습니다. 저는 에이전트가 코드를 자동으로 커밋하게 하지 않기 때문이죠.” – 기존 도구와 긍정적인 비교를 하며, 출처 메타데이터가 일부 워크플로우에서는 선택 사항일 수 있음을 언급합니다.

@esafak: “105세션 사례 연구에 대해 좀 더 설명해 주실 수 있나요? … 아직 라이프사이클 관리나 충돌 해결 기능이 없으며, 모델이 언제 사용할지 결정하는 작업을 수행합니다.” – 더 엄격한 벤치마크와 충돌 처리에 대한 명확화를 요청합니다.

@quietraster: “두 에이전트가 동일한 SQLite 저장소에 쓸 때 충돌을 어떻게 처리하나요?” – 현재 설계는 SQLite의 트랜잭션 보장을 기반으로 하며, 동시 쓰기는 시리얼화되지만, 고수준의 충돌 해결 기능은 아직 구현되지 않았습니다.

제한 사항 및 미해결 질문

벤치마크 – 공개된 사례 연구는 경쟁 메모리 플러그인(ctx.rs 등)과의 직접 비교가 부족합니다. 독립적인 벤치마크는 99% 토큰 감소 주장의 정량화에 도움이 될 것입니다.
충돌 해결 – SQLite는 손상 방지 기능을 제공하지만, 여러 에이전트에서 발생하는 다름 수정 사항을 병합하는 전략은 아직 제공되지 않습니다.
제거 지원 – 후크 제거나 메모리 데이터베이스 삭제를 위한 내장 스크립트가 없으며, 사용자가 수동으로 정리해야 합니다.
다중 장치 동기화 – 도구는 의도적으로 로컬 우선이므로, 여러 기기 간 SQLite 파일 동기화는 외부 솔루션(예: rsync, 클라우드 마운트 드라이브)이 필요합니다.