평가 및 비교 분석

아키텍처 평가 기준 차원

에이전트 메모리 시스템을 평가할 때는 표면적인 벡터 검색을 넘어 프로덕션 코어 아키텍처(데이터 스토리지 모델, 테넌트 격리 경계, 일관성 보장, 프로토콜 준수, 지연 시간, 기계 판독성)를 검토해야 합니다.

• 스토리지 모델: 하이브리드 관계형 메타데이터+벡터 임베딩 대 평면 벡터 전용 저장소. 관계형 기반은 정확한 필터 푸시다운, 불변 감사 로그 및 결정론적 범위 분할을 보장합니다.
• 멀티 테넌트 격리: 하드웨어 또는 서버 강제 테넌트 파티션 대 애플리케이션 수준 메타데이터 필터링. 공유 에이전트 공간에는 암호학적으로 서명된 공간 바인딩이 필요합니다.
• 일관성 보장: 분산 도구 호출 간 쓰기 직후 읽기(read-your-writes) 일관성 대 연속 에이전트 루프에서 환각을 유발하는 최종 일관성 윈도우.
• 프로토콜 준수: 프레임워크별 SDK 어댑터가 필요한 독점 래퍼 대 네이티브 Model Context Protocol (MCP) Streamable HTTP 엔드포인트.
• 기계 판독성: 도구 스키마를 엄격히 준수하며 산문형 꼬리말이나 불필요한 대화형 래퍼가 없는 구조화된 결정론적 JSON 응답.

모든 메모리 레이어에서 평가해야 할 핵심 항목

스코프 격리, 호출자 귀속, 수명 주기 삭제, 프로토콜 통합, 동시성 속도 제한, 재현 가능한 벤치마크 및 플랜 의존 기능의 7가지 기초 프로덕션 차원에서 에이전트 메모리 시스템을 평가합니다.

• 스코프 격리: 사용자, 세션, 에이전트 및 워크스페이스 메모리가 어떻게 분할되는지 각 벤더에 질문하십시오. XMemo는 스토리지 경계에서 4단계 직교 스코프 계층(user, session, agent, team/space)과 퍼스트 클래스 프로젝트 격리를 강제합니다(/docs/concepts/scopes 및 /docs/concepts/projects 참조).
• 귀속 및 출처 추적: 모든 메모리 쓰기 및 변경이 검증된 호출자 식별 정보 및 발생 이벤트로 추적 가능한지 각 벤더에 질문하십시오. XMemo는 호출자 귀속, 에이전트 인스턴스 지문, 출처 메타데이터를 감사 로그에 기록하고 업데이트 DAG를 통해 버전 기록(superseded 버전)을 보존합니다(/docs/concepts/agent-instance-identity 및 /docs/concepts/memory-model 참조).
• 삭제 및 내보내기: 툼스톤 소프트 삭제, 영구적 콘텐츠 삭제, 대량 데이터 내보내기를 플랫폼이 어떻게 지원하는지 각 벤더에 질문하십시오. XMemo는 관리형 수명 주기 상태(active, archived, deleted), 복원 가능한 소프트 삭제, 영구적 콘텐츠 삭제, 구조화된 JSON 내보내기를 제공합니다(/docs/concepts/memory-deletion 및 /docs/api/memory 참조).
• MCP 및 REST 통합: 메모리 레이어가 표준 REST 엔드포인트와 함께 네이티브 Model Context Protocol (MCP)을 지원하는지 각 벤더에 질문하십시오. XMemo는 동결된 표준 도구 카탈로그를 노출하는 네이티브 Streamable HTTP MCP 서버와 /v1/ 아래 인증된 REST 엔드포인트를 제공합니다(/docs/mcp/overview 및 /docs/api/authentication 참조).
• 속도 제한: 요청 처리량과 동시성 제한이 어떻게 적용되고 클라이언트에 전달되는지 각 벤더에 질문하십시오. XMemo는 공개된 정적 할당량이 아닌 api-authentication 계층에 의해 관리되는 런타임 속도 제한을 적용하며, 클라이언트는 고정 할당량 가정을 하드코딩해서는 안 됩니다(/docs/api/authentication 참조).
• 재현 가능한 벤치마크: 검색 정확도 및 지연 시간 주장이 오픈 테스트 하네스와 결정론적 데이터 세트로 독립 검증 가능한지 각 벤더에 질문하십시오. XMemo는 결정론적 Golden Set 데이터 세트(recall_golden_set.jsonl)와 불변 실행 기록을 갖춘 저장소 소유 벤치마크 계약을 게시하여 인메모리 평가와 네트워크 I/O를 명확히 구분합니다(/docs/guides/evaluate#reproducible-benchmark-methodology 참조).
• 플랜 의존 기능: 기본 런타임에 포함된 백그라운드 프로세스 및 고급 기능과 상용 티어로 제한되는 기능이 무엇인지 각 벤더에 질문하십시오. XMemo는 코어 메모리 스토리지, 검색, 리콜 및 5가지 액션의 reflect 도구를 기본 런타임에 포함하며, 정기적인 백그라운드 Dream 성찰은 기능 플래그 및 플랜/엔타이틀먼트에 따라 달라집니다(프리셋: manual, daily 또는 weekly; /docs/concepts/how-xmemo-works 및 /docs/concepts/dream-reflection 참조).)

{
  "evaluation_checklist": {
    "dimensions": [
      {
        "dimension": "Scope isolation",        "question": "How are user, session, agent, and workspace memories segregated?",        "xmemo_answer": "4-tier orthogonal scope hierarchy (user, session, agent, team/space) enforced at storage boundary (/docs/concepts/scopes)"      },
      {
        "dimension": "Attribution and provenance",        "question": "Can every memory mutation be traced to a specific caller and event?",        "xmemo_answer": "Caller attribution and agent instance fingerprints recorded in audit logs with version history (/docs/concepts/agent-instance-identity)"      },
      {
        "dimension": "Deletion and export",        "question": "Does the system support soft deletion, hard redaction, and data export?",        "xmemo_answer": "Tombstone soft-deletion with restoration, hard redaction, and structured export (/docs/concepts/memory-deletion)"      },
      {
        "dimension": "MCP and REST integration",        "question": "Is the memory layer accessible via native MCP as well as HTTP REST?",        "xmemo_answer": "Native Streamable HTTP MCP server with frozen tool catalog and authenticated REST endpoints (/docs/mcp/overview)"      },
      {
        "dimension": "Rate limits",        "question": "How are request quotas communicated and enforced?",        "xmemo_answer": "Runtime rate limiting governed by api-authentication without hard-coded client quotas (/docs/api/authentication)"      },
      {
        "dimension": "Reproducible benchmarks",        "question": "Are retrieval accuracy and performance metrics independently verifiable?",        "xmemo_answer": "Open repository-owned benchmark harness with deterministic golden set datasets and run traces (/docs/guides/evaluate#reproducible-benchmark-methodology)"      },
      {
        "dimension": "Plan-dependent features",        "question": "Which features are core runtime versus gated by tier entitlements?",        "xmemo_answer": "Core operations and 5-action reflect tool in base runtime; background Dream reflection is plan/entitlement-dependent (/docs/concepts/dream-reflection)"      }
    ]
  }
}

시나리오별 선택 가이드

워크로드 토폴로지, 팀 구조 및 거버넌스 요구 사항을 평가하여 적절한 메모리 아키텍처 패턴을 선택하십시오.

• 다중 환경 다중 에이전트 워크플로: Claude Code, Cursor, ChatGPT, Codex, Gemini CLI 전반에서 에이전트를 조율할 때는 네이티브 MCP 지원, 공유 프로젝트 스코프 및 교차 클라이언트 동기화를 갖춘 메모리 레이어를 선택하십시오.
• 규제 대상 및 엔터프라이즈 워크스페이스: 직교 스코프 계층(user, session, agent, team/space), 호출자 귀속 감사 로그, 하드웨어 또는 서버 강제 테넌트 경계를 제공하는 아키텍처를 우선하십시오.
• 고동시성 자율 루프: 상충되는 업데이트와 유효하지 않은 메모리로 인한 환각을 방지하기 위해 버전 관리 업데이트 트리, 낙관적 잠금, 쓰기 직후 읽기(read-your-writes) 일관성을 갖춘 아키텍처를 선택하십시오.

재현 가능한 벤치마크 방법론

XMemo는 통제된 조건 하에서 검색 정확도와 거버넌스 제약을 평가하기 위한 저장소 자체 오픈 벤치마크 하네스를 제공합니다. 평가 체계는 내부 합성 평가, 실제 운영 지연 시간, 검증된 대외 성능 성명을 엄격히 구분합니다.

• 평가 방법론 계약: 벤치마크는 결정론적 골든 데이터 세트와 기록된 검증 추적을 갖춘 동결된 재현 가능 방법 계약을 준수합니다.
• 내부 합성 벤치마크: tests/data/recall_golden_set.jsonl (SHA-256 7533FBDC...)을 기반으로 scripts/benchmark_runner.py를 통해 오프라인으로 실행되며, 네트워크나 데이터베이스 I/O 없이 인메모리 검색 알고리즘 품질과 랭킹 로직을 측정합니다.
• 실제 운영 지연 시간: 엔드투엔드 지연 시간은 TLS 핸드셰이크, 네트워크 전송, 데이터베이스 트랜잭션 및 멀티 테넌트 격리 오버헤드를 포함합니다. 배포 토폴로지(클라우드 SaaS 대 자체 호스팅 Docker) 및 지리적 거리에 따라 달라지며, 인메모리 합성 수치로 대표될 수 없습니다.
• 대외 성능 성명: 보고되는 모든 지표는 불변 benchmark_run_id 및 검증 실행의 원시 검증자 보고서를 인용해야 합니다. 검증되지 않은 벤더의 주장과 합성 지름길은 기준선 주장 목록에서 제외됩니다.
• 장애 모드 분석: 두 개의 서로 다른 프로젝트 공간에 존재하는 동일 명칭 엔티티('config.py')에 대해 명시적 프로젝트 스코프 한정이 없을 때 검색 경쟁이 발생하는 엣지 케이스를 기록; 프로젝트 스코프 제약을 추가하여 해결되었습니다.

# Execute reproducible retrieval benchmark against golden set
python scripts/benchmark_runner.py \
  --track standard \
  --dataset tests/data/recall_golden_set.jsonl \
  --cache-state COLD_CACHE \
  --output reports/custom_run_raw.json

XMemo 마이그레이션 가이드

레거시 키-값 저장소, 벡터 전용 데이터베이스 또는 외부 메모리 서비스에서 XMemo로 마이그레이션하는 과정은 4단계로 구성됩니다.

• 1단계: 레거시 메모리 항목을 text, user_id, session_id 및 created_at 타임스탬프를 포함하는 JSON Lines로 내보냅니다.
• 2단계: 식별자를 XMemo 스코프 계층에 매핑합니다(user_id를 owner로, session_id를 agent_instance_id 또는 project_id로 매핑하고 지속성에 따라 사실을 분류).
• 3단계: 배치 remember 도구 또는 REST API(/v1/memories)를 통해 적절한 스코프 및 출처 속성과 함께 수집합니다.
• 4단계: 에이전트 쓰기 권한을 활성화하기 전에 recall_context를 사용하여 검색 정확도와 테넌트 격리 경계를 검증합니다.

import requests

def migrate_legacy_record(legacy_item, api_key):
    payload = {
        "content": legacy_item["content"],
        "path": f"migration/{legacy_item.get('id', 'item')}",
        "scope": "project" if legacy_item.get("project_id") else "user",
        "metadata": {"source": "legacy_migration", "original_id": legacy_item.get("id")}
    }
    response = requests.post(
        "https://xmemo.dev/v1/memories",
        headers={"Authorization": f"Bearer {api_key}"},
        json=payload
    )
    response.raise_for_status()
    return response.json()

알려진 제한 사항 및 운영 경계

시스템의 잘못된 적용을 방지하기 위해 XMemo의 운영 경계와 명시적인 설계 절충점을 파악하십시오.

• 범용 관계형 데이터베이스가 아님: XMemo는 에이전트 사실, 상태 및 스킬 정착에 최적화되어 있으며 임의의 SQL 트랜잭션을 처리하는 주 애플리케이션 데이터베이스를 대체하지 않습니다.
• 비정형 대용량 파일 덤프가 아님: 32 KB를 초과하는 문서는 단일 인라인 메모리 항목이 아닌 지식 기반(Knowledge Bases)에 색인화되어야 합니다.
• Dream 성찰 주기성: reflect API 및 MCP 도구 표면은 스케줄러를 노출하지 않습니다. 백그라운드 Dream 스케줄링은 기능 플래그 및 플랜/엔타이틀먼트에 따라 달라지며(프리셋: manual[기본값], 소유자 로컬 03:00의 daily, 또는 weekly), 통합은 쓰기와 동기화되지 않습니다.
• 속도 제한: 호스팅 엔드포인트는 공개된 정적 할당량이 아닌 api-authentication에 의해 관리되는 런타임 속도 제한을 적용하며, 클라이언트는 할당량 가정을 하드코딩해서는 안 됩니다.