LoreKit의 에이전트 메모리 공통 형식 제안: 적용 범위와 작성 이력부터 맞추기
에이전트 메모리를 옮기고 함께 쓰려면 무엇을 맞춰야 할까. 11월 7일 공개된 LoreKit 개발자의 제안과 현재 도구의 지원 범위, 로컬 저장 설정 조건을 살펴본다.

코딩 에이전트를 바꾸거나 CI와 편집기에서 함께 쓰면 한 도구가 남긴 작업 메모를 다른 도구에서도 읽게 하고 싶어진다. 파일을 옮길 수 있어도 어느 저장소에서 유효한지, 누가 썼는지, 언제 다시 확인할지는 따로 맞춰야 한다.
LoreKit 개발자 Mads Thines는 2026년 11월 7일 공식 글에서 에이전트 메모리의 공통 형식을 논의하자고 제안했다. OpenTelemetry처럼 도구들이 함께 읽을 데이터 모양에 합의하자는 주장이다. 공개된 내용은 개발자의 제안이며 채택이 확정된 표준이나 도구 간 호환성 출시 공지는 아니다.
파일 이전과 공동 접근은 다르다
Thines는 한 사용자의 메모리를 서비스 사이에서 옮기는 일과 여러 에이전트가 같은 메모리를 읽고 쓰는 일을 나눠 설명한다. CI 작업과 편집기 에이전트가 함께 쓸 기록이라면 적용 범위와 식별 키, 작성 주체, 수명 같은 정보를 공통으로 해석해야 한다는 제안이다. 원문의 예시 필드명도 확정 규격이 아니라고 명시돼 있다. 제안 원문
가령 테스트를 실행하기 전에 로컬 데이터베이스를 켜야 한다는 메모를 생각해 보자. 팀에서 이 메모를 공유한다면 해당 저장소와 근거가 된 실행 기록을 함께 남기는 편이 검토하기 쉽다. 테스트 구성이 바뀐 뒤에도 같은 메모가 유효한지는 별도로 확인해야 한다. 여기서부터는 제안을 업무에 적용해 본 필자의 판단이다.
현재 LoreKit이 지원하는 범위
공식 저장소는 LoreKit을 MIT 라이선스의 로컬·원격 메모리 도구로 소개한다. 메모는 branch, repo, project, global 범위에 놓이고 같은 키가 있으면 더 구체적인 범위의 기록을 우선한다. Claude Code와 Cursor는 지원 대상으로, Codex 연동은 실험적 기능으로 구분한다.
MCP에 연결된다는 설명만으로 모든 클라이언트의 자동 회상 방식이 같다고 받아들이면 안 된다. 저장소는 Claude Code의 실패 도구 호출에 맞춘 회상과 Cursor의 규칙 기반 읽기를 구분하고 일반 MCP 클라이언트에는 훅이 없다고 설명한다. 모순 탐지와 의존 관계를 따라 기록을 무효화하는 기능도 비목표로 명시한다. 이번 확인은 문서 대조이며 직접 설치하거나 동작을 재현하지 않았다. 지원 상태와 설계 선택
로컬 저장을 택할 때 확인할 설정
오프라인 문서에 따르면 로컬 구성에는 CLI의 stdio MCP 서버 연결과 저장 모드 설정이 모두 필요하다. 로컬 서버 명령만 지정해도 저장 모드가 자동으로 local이 된다고 가정하면 설정을 잘못 읽게 된다. 문서는 기본 모드가 remote라고 설명한다.
프로젝트의 mode: "local"은 기본값이고 사용자 설정이 이를 덮어쓸 수 있다. 같은 문서에서 deny: ["remote"]는 원격 모드를 금지하는 제약으로 구분한다. 실제 적용 모드와 설정 출처는 doctor로 확인하도록 안내한다. 이 조건은 현재 LoreKit 구성에 관한 설명이며 공통 메모리 제안의 필수 규격은 아니다. 로컬 모드와 deny 설정
공유를 검토하는 팀이라면 메모가 적용되는 저장소, 작성자, 근거, 재검토 조건을 먼저 정해 두는 편이 좋다. 원문도 공유 메모리가 프롬프트 인젝션 경로가 될 수 있다고 인정한다. 형식을 맞췄다는 사실만으로 기록의 내용까지 신뢰할 근거가 생기지는 않는다. 신뢰 문제를 다룬 원문



Discussion
No comments yet