Lemmalog, LLM 기억을 프로그램 분석으로 바꾸다

기억을 더 잘 찾는 것과 지식을 유지하는 것은 다르다

I accidentally turned LLM memory into program analysis는 에이전트 메모리 논의를 흥미롭게 뒤집는다. 글쓴이는 취약점 연구에서 LLM 에이전트를 오래 돌리다 보면 모델이 이미 반박한 가설을 되살리거나, 더 이상 참이 아닌 관찰 위에서 계속 추론한다고 말한다. 일반적인 메모리 시스템은 오래된 대화나 관찰을 저장하고 검색하지만, 문제는 검색이 아니라 현재 무엇이 참인지 유지하는 일이라는 것이다.

이 아이디어는 Lemmalog로 구현됐다. 저장소 설명에 따르면 Lemmalog는 stratified Datalog, provenance-tracked facts, incremental derivation, MCP server를 갖춘 Rust 기반 엔진이다. 자연어와 디버거 출력에서 사실을 뽑는 일은 LLM이 맡고, 그 이후의 추론, 철회, 시간성, 근거 추적은 Datalog 엔진이 맡는다. Datalog는 오래된 논리 프로그래밍 언어지만, 에이전트 시대에는 꽤 현대적인 답처럼 보인다.

벡터 메모리는 유사하지만 참이라는 보장은 없다

벡터 데이터베이스는 유용하다. 오래된 대화에서 관련 문장을 찾는 데 강하다. 그러나 유사한 문장이 현재도 참이라는 뜻은 아니다. 취약점 연구에서 처음에는 object_a가 object_b를 가리킨다고 믿었다가 나중에 틀렸다고 확인하면, 그 사실에서 파생된 결론도 함께 무효화되어야 한다. 단순 검색은 이 의존 관계를 자동으로 지우지 못한다.

Recall, 로컬 메모리는 에이전트 컨텍스트 비용을 줄일 수 있나는 개인 메모리의 비용 문제를 다뤘다. Lemmalog는 여기에 정확성의 질문을 더한다. 무엇을 기억하느냐보다 왜 믿는지가 더 중요하다.

프로그램 분석의 언어가 에이전트 운영으로 들어온다

프로그램 분석은 사실과 규칙으로부터 새 사실을 도출하고, 변경이 생기면 영향을 받은 결과를 갱신한다. Lemmalog의 핵심도 같다. 예를 들어 공격자가 어떤 객체를 제어하고, 그 객체가 커널 객체를 가리키면 위험한 결론이 파생된다. 나중에 포인터 관계가 틀렸다고 확인되면 그 결론은 자동으로 사라져야 한다. 이때 엔진은 왜 그 결론이 참이었는지 proof tree도 보여준다.

이 구조는 장기 에이전트 운영에 잘 맞는다. 에이전트가 큰 코드베이스를 며칠 동안 조사하거나, 여러 세션에 걸쳐 incident response를 진행하거나, 연구 가설을 축적할 때 채팅 전체를 다시 읽는 방식은 곧 한계에 닿는다. Mole, 터미널 리서치 에이전트가 예산과 근거를 먼저 묻다는 근거와 예산이 리서치 에이전트의 핵심이라고 했고, Lemmalog는 그 근거를 데이터 구조로 만든다.

숫자는 과장보다 흥미로운 한계를 보여준다

글과 README는 LongMemEval, LoCoMo 같은 메모리 벤치마크 결과를 공개한다. README 기준 Lemmalog는 LoCoMo에서 F1 0.533 전후를 기록했고, PropMem과 OpenClaw 뒤에서 경쟁적인 결과를 냈다고 설명한다. LongMemEval에서는 F1 0.463 전후, 답변 단계 토큰을 full context 대비 크게 줄였다고 한다. 다만 저자도 모든 것을 해결했다고 주장하지 않는다. 추출이 빠뜨린 정보는 엔진도 살릴 수 없고, 선호처럼 조건과 뉘앙스가 많은 기억은 단순 튜플로 낮추기 어렵다.

이 정직함이 오히려 중요하다. AI 에이전트 메모리는 마법 같은 장기 기억이 아니라 정보 검색, 엔티티 정규화, 시간 정규화, 규칙 설계, 근거 표시, 답변 정책의 조합이다. Graphiti 같은 temporal knowledge graph 접근과도 경쟁하고 보완될 수 있다. 지식 그래프, 벡터 검색, Datalog는 서로 대체라기보다 다른 실패 모드를 가진 부품이다.

한국 보안팀과 개발팀의 적용 가능성

한국 기업의 보안팀에는 특히 의미가 있다. 침해 사고 분석, 취약점 재현, 로그 상관분석, 코드 감사는 시간이 길고 가설이 자주 바뀐다. 어떤 IP가 관련 있다고 보았다가 나중에 오탐으로 판정되면, 그 IP에 매달린 결론도 약해져야 한다. 에이전트가 old note를 검색해 다시 확신하는 상황은 실제 운영에서 위험하다.

개발팀에도 비슷하다. 큰 리팩터링에서 어떤 모듈이 책임을 가진다는 가정이 바뀌면, 그 가정에 의존한 작업 목록도 바뀌어야 한다. 복잡계 실패론, AI 에이전트 운영의 기본 교과서는 에이전트 운영을 단순 자동화가 아니라 상태 관리 문제로 보라고 했다. Lemmalog는 그 방향의 구체적 실험이다. MCP 서버를 제공한다는 점도 여러 에이전트가 같은 상태 엔진을 공유하는 미래를 떠올리게 한다.

자주 묻는 질문

Q1: Lemmalog는 벡터 데이터베이스를 대체하나요?

A: 완전한 대체라기보다 보완에 가깝다. 의미 검색은 여전히 필요하고, Lemmalog는 현재 사실과 근거를 유지하는 쪽에 강하다.

Q2: 왜 Datalog인가요?

A: 사실과 규칙, 파생 결과, 철회, 근거 추적을 다루기에 오래 검증된 모델이기 때문이다.

Q3: 가장 큰 약점은 무엇인가요?

A: 자연어에서 사실을 뽑는 추출 단계다. 중요한 사실이 빠지면 이후의 논리 엔진도 답을 만들 수 없다.

Q4: 보안 연구에 특히 맞는 이유는 무엇인가요?

A: 취약점 조사는 가설, 반례, 디버거 관찰, 철회가 반복된다. 결론의 근거와 생명주기를 추적해야 한다.

Q5: 제품화 가능성은 있나요?

A: 있다. 다만 단독 앱보다 코딩 에이전트, incident response, 리서치 노트, MCP 도구의 상태 엔진으로 붙을 가능성이 크다.