엔그림: 모델을 바꿔도 프로젝트 기억은 남기는 로컬 SQLite 메모리 엔진

AI 코딩 도구를 실무에 쓰다 보면 반복적으로 부딪히는 벽이 있다. 대화 맥락(컨텍스트)을 비우면 그동안 합의한 아키텍처 결정과 제약 조건이 통째로 사라지고, 반대로 맥락을 계속 유지하면 매 턴마다 방대한 토큰을 다시 읽어들이며 비용과 지연이 불어난다. 최근 공개된 오픈소스 프로젝트 엔그림(Engrim)은 이 문제를 정면으로 겨냥한다. 개발자 팀 고든이 GitHub에 'Show HN' 형태로 내놓은 이 도구는 스스로를 '범용 크로스 모델·크로스 에이전트 에피소드 메모리 저장소'라고 규정하며, 로컬 우선(local-first)·프로젝트 단위로 동작하는 SQLite 기반 메모리 엔진을 표방한다.

무엇을 해결하려 하는가

엔그림의 문제의식은 컨텍스트 창이 100만 토큰 이상으로 커지는 흐름 자체에 있다. 창이 커진다고 추론 품질이 비례해 좋아지지는 않는다는 것이다. 프로젝트 소개는 이를 '주의력 희석(attention dilution)'이라고 부른다. 관련성 낮은 대화 이력까지 모델의 주의가 분산되면서 추론이 저하되고, 대화가 이어질수록 비용이 배가되며, 맥락을 지우는 순간 완전한 기억상실이 발생한다는 진단이다. 엔그림은 이 방대한 원본 맥락 대신 약 4,000자 분량의 '선별된 에피소드 작업 기억'을 유지하는 방식으로 대응한다고 설명한다. 즉 전체 대화를 통째로 다시 먹이는 대신, 아키텍처 결정·사용자 제약·프로젝트 상태 같은 핵심만 골라 요약된 형태로 계속 넘겨주겠다는 접근이다.

가장 눈에 띄는 지향점은 '모델과 환경을 자유롭게 갈아타도 기억이 유지된다'는 부분이다. 엔그림은 구글 안티그래비티(Antigravity), 클로드 코드(Claude Code), 커서(Cursor)의 MCP, 윈드서프(Windsurf)를 대상으로 하며, 같은 프로젝트에서 이 환경들을 오가더라도 결정과 상태를 잃지 않는 것을 목표로 한다. 기억이 특정 벤더의 클라우드에 종속되지 않고 로컬 SQLite 파일에 남는다는 점에서 '클라우드 종속 제로(zero cloud lock-in)'를 강조한다. 도구 자체를 소모품으로, 프로젝트의 축적된 판단을 자산으로 구분하는 관점이 설계 철학의 핵심이다.

도입과 구조

설치와 연동은 비교적 단순하게 제시된다. 인자 없이 engrim setup을 실행하면 머신에 설치된 환경을 자동 감지해 한꺼번에 구성하며, 어떤 setup 명령이든 --dry-run을 붙이면 디스크를 건드리지 않고 변경 예정 사항만 미리 확인할 수 있다. 윈드서프의 경우 ~/.codeium/windsurf/mcp_config.json에 엔그림을 추가하는 방식으로 연결한다. 기술적으로는 의존성이 없는 JSON-RPC 2.0 stdio 기반 MCP 서버로 동작하며, stdout은 오직 JSON-RPC 메시지 전용으로 두고 진단 로그는 모두 stderr로 보낸다. MCP 프로토콜에서 표준 출력이 오염되면 통신이 깨지기 때문에, 이 분리는 사소해 보여도 안정적 연동을 위한 실무적 요건이다.

여러 에이전트가 하나의 코드베이스에서 협업하는 상황도 염두에 뒀다. 엔그림은 각 메모리 항목이 어디서 왔는지를 origin_agent 필드로 기록해 출처(provenance)를 남긴다. 기존 데이터베이스는 첫 접근 시 ALTER TABLE memories ADD COLUMN origin_agent TEXT로 비파괴적으로 마이그레이션된다고 설명한다. 서로 다른 모델이 같은 저장소에 판단을 남길 때, 어떤 결정이 어느 에이전트에서 비롯됐는지를 추적할 수 있도록 한 장치다.

실무자가 따져볼 지점

제시된 검증 근거는 단일 사례에 집중돼 있다. 개발자는 실제 자본을 운용하는 5만 라인 규모의 알고리즘 트레이딩 시스템에서 105회 연속 세션 동안 엔그림을 시험했고, 186개 단위 테스트에서 회귀(regression)가 없었으며 모델을 바꾸는 과정에서도 맥락 기억상실이 발생하지 않았다고 밝혔다. 숫자만 보면 인상적이지만, 이는 제작자 본인이 자신의 프로덕션 코드베이스에서 얻은 자체 검증 결과라는 점을 감안해야 한다. 서로 다른 팀·언어·규모의 프로젝트에서 동일한 결과가 재현될지, 4,000자라는 압축 한도가 대형 프로젝트의 복잡한 결정 이력을 담기에 충분한지는 아직 외부에서 확인되지 않았다.

그럼에도 엔그림이 건드리는 지점은 현재 AI 코딩 워크플로의 실질적 통증에 정확히 닿아 있다. 컨텍스트 창을 무한정 키우는 대신 무엇을 기억하고 무엇을 버릴지 명시적으로 관리한다는 발상, 그리고 그 기억을 벤더 클라우드가 아닌 로컬 파일과 표준 프로토콜(MCP) 위에 두어 도구 간 이동성을 확보한다는 방향은 여러 AI 도구를 병행하는 실무자에게 검토할 가치가 있다. 도입을 고려한다면 --dry-run으로 변경 범위를 먼저 확인하고, 민감한 코드베이스에서는 로컬 SQLite 파일에 어떤 정보가 축적되는지 직접 점검한 뒤 소규모 프로젝트에서 재현성을 시험해 보는 순서가 현실적이다.