“통합 테스트 전에 데이터베이스를 켜라”라는 메모는 유용할 수 있습니다. 그런데 테스트가 인메모리 구현으로 바뀐 뒤에도 같은 메모를 읽는다면, 기억이 오히려 불필요한 작업을 만듭니다. 검색에 성공했다는 사실만으로 그 기억이 지금도 맞는 것은 아닙니다.

LoreKit 제작자 Mads Thines의 11월 7일 글은 에이전트 메모리의 공유 형식과 의미에 대한 합의를 제안합니다. 11월 8일 확인한 이 글은 승인된 표준이나 성능 벤치마크가 아닙니다. 브리핑의 관측 가능성이라는 요약에서 한 걸음 더 나아가, 도구 사이에 기록을 옮길 때 무엇을 보존해야 하는지가 핵심입니다.

같은 문장을 읽어도 같은 기억은 아니다

기억을 옮길 때 문장만 복사하면 빠지는 정보가 있습니다. 어느 저장소에 적용되는지, 어떤 코드에서 확인했는지, 누가 작성했는지, 언제 다시 검토할지입니다. 같은 내용이라도 팀 지침과 모델이 한 번 추측한 메모를 같은 우선순위로 취급할 이유는 없습니다.

원문은 MCP 호출 형식만으로 기록의 의미까지 같아지지 않는다고 지적합니다. CodeBridge의 해석은 이렇습니다. 읽기·쓰기 API가 연결되어도, 한 도구의 만료나 보관 상태가 다른 도구에서 보존되지 않으면 연결은 의미를 잃을 수 있습니다. 형식 변환의 성공과 운영상의 동등성은 다른 검사입니다.

검색 단계와 적용 단계를 나눈다

아래는 공식 LoreKit 구현도가 아니라, 기억을 코드 작업에 적용할 때 사용할 수 있는 개념 흐름입니다. 검색 결과에 도달한 뒤에도 읽기 권한·범위와 유효성을 확인합니다.

후보 메모 검색
      │
      ▼
읽기 권한과 적용 범위 확인
      │
      ▼
출처 버전 · 만료 · 검토 상태 확인
      ├── 불일치 → 적용 보류, 재검토 이유 기록
      └── 일치   → 현재 작업에 참고 자료로 제공
                         │
                         ▼
                 사용한 기록 ID와 판단 근거 보관

핵심은 메모를 지우는 것만이 해결책이 아니라는 점입니다. 보류된 메모도 왜 보류됐는지 남으면 오래된 결론이 어디서 들어왔는지 추적할 수 있습니다. 단, 보존 자체가 민감정보의 수명을 늘리므로 내용과 감사 메타데이터의 보존 정책을 구분해야 합니다.

네 조건을 검사하는 작은 예제

다음은 CodeBridge가 만든 축소 스키마입니다. LoreKit 필드명이나 제안 표준을 구현한 것이 아닙니다. Node.js 18 이상에서 실행할 수 있으며, 권한 인증을 대체하지 않습니다.

const record = {
  id: 'test-db-requirement', scope: 'repo:example/app',
  source_revision: 'commit-A', expires_at: '2026-11-10T00:00:00Z',
  reviewed: true, content: 'Integration tests require a local database.'
};
function eligible(memory, context) {
  return memory.scope === context.scope
    && memory.source_revision === context.revision
    && memory.reviewed === true
    && Date.parse(memory.expires_at) > Date.parse(context.now);
}
console.log(eligible(record, {
  scope: 'repo:example/app', revision: 'commit-B',
  now: '2026-11-08T12:00:00Z'
}));

이 예제의 출력은 false입니다. 출처가 commit-A인데 현재 작업은 commit-B이기 때문입니다. 전체 실행 파일은 docs/editorial/2026-11-08/evidence/memory-validity.mjs에 있으며 아래 명령으로 확인합니다.

node docs/editorial/2026-11-08/evidence/memory-validity.mjs

로컬에서는 버전 변경, 만료, 미검토를 거부하고 일치한 버전을 허용하는 네 조건을 검사했습니다. 모델 호출·외부 서비스·제품 설치 없이 합성 기록으로 실행했습니다.

모든 커밋에서 무효화하면 비용도 생긴다

위 예제는 보수적입니다. 문서를 고친 커밋도 모든 기억을 거부할 수 있습니다. 프로덕션에서는 메모가 의존하는 파일·API·설정의 버전을 추적하면 불필요한 재검토를 줄일 수 있지만, 의존성 매핑과 갱신 책임이 추가됩니다.

설계 선택 얻는 것 추가 비용 또는 위험
저장소 커밋 전체 비교 단순하고 재현 가능한 판단 관련 없는 수정에도 보류
관련 파일의 해시 비교 더 좁은 무효화 간접 의존성을 놓칠 수 있음
기간 만료만 사용 구현이 간단함 기간 안의 코드 변경을 놓침
담당자 재검토 맥락 판단 가능 검토 대기와 책임 관리

이 표는 측정 결과가 아닌 설계 비교입니다. 어떤 정책도 “참”을 보장하지 않습니다. 서명이나 작성자 표시도 누가 기록했는지 증명하는 데 도움을 줄 뿐, 내용의 정확성을 보증하지는 않습니다. 공유 메모를 실행 지시로 자동 승격하면 잘못된 기록과 프롬프트 주입이 더 넓게 퍼질 수도 있습니다.

메모리 도구 교체 전에 한 번 왕복시켜 본다

실무에서는 유효한 기록, 만료된 기록, 보관된 기록, 알 수 없는 확장 필드를 가진 기록을 준비하세요. 도구 A에서 내보내고 B를 거쳐 다시 A로 가져왔을 때 ID·범위·출처·상태가 유지되는지 확인합니다. 본문 문자열만 같다면 충분하지 않습니다.

LoreKit의 글이 주는 가치는 기억 용량을 늘리라는 권고보다, 기억을 다른 도구에서도 해석할 수 있게 하라는 문제 제기에 있습니다. 지금 시작할 일은 새 메모리 서버 설치가 아니라, 현재 메모 하나가 왜 이 작업에 적용됐는지 답할 수 있게 만드는 것입니다.

기초 개념: 컨텍스트·세션·영속 기억의 차이.