빠른 비교
| 모드 | 암호문 저장 위치 | 복호화 가능 주체 | 적합한 용도 |
|---|---|---|---|
Cloud 관리 모드 cloud | 액세스 제어, 애플리케이션 계층의 스코프 인가 및 감사 추적으로 보호되는 XMemo 관리형 데이터 플레인에 저장됩니다. 데이터베이스 RLS의 적용 여부는 배포별 검증에 따라 달라집니다. | XMemo 서버가 리콜, 검색, 랭킹 및 지원 가능한 내보내기를 위해 메모리 내용을 처리할 수 있습니다. | 가장 빠른 설정, 완전한 호스팅형 리콜 기능 제공, 디바이스나 복구 키를 관리할 부담이 없음. |
Keyguard 모드 keyguard | XMemo 관리형 Postgres에 저장되지만, envelope 키는 테넌트의 KMS / HSM에 바인딩됩니다. | 테넌트의 KMS grant가 unwrap 작업을 허용할 때에만 서버가 복호화할 수 있습니다. | 호스팅형 리콜과 고객 관리형 키 제어가 모두 필요한 엔터프라이즈 팀. |
Vault 모드 vault | XMemo 관리형 Postgres에는 불투명한 암호문과 envelope 메타데이터만 저장됩니다. | 등록된 디바이스 또는 복구 키트만 복호화할 수 있으며, XMemo는 평문을 복원할 수 없습니다. | 영지식(Zero-knowledge) 보관 방식이며, 모든 디바이스와 복구 자료를 분실하면 영구적으로 데이터가 손실됩니다. |
XMemo가 저장하는 항목
- 메모리 레코드: 메모리 텍스트 또는 암호문, 메타데이터, 소유권, 타임스탬프, 그리고 리콜에 필요한 벡터 검색 데이터.
- 계정 설정 상태: 선택한 보안 모드, 설정 완료 상태, 모드 변경 횟수, 그리고 KMS binding id 또는 vault recovery marker와 같은 preflight 증명.
- 액세스 및 감사 기록: 세션, 해시 또는 scoped credential, ID 링크, 그리고 setup_state_transition과 같은 감사 이벤트.
XMemo 공개 페이지에서는 API key를 직접 붙여넣도록 요구하지 않습니다. Agent 및 MCP 설정은 환경 변수를 참조하거나 공식 클라이언트 설정 인터페이스를 사용해야 합니다.
Cloud 관리 모드
메모리 데이터는 XMemo 관리형 데이터 플레인에 저장됩니다. 서버는 리콜, 검색, 랭킹 및 내보내기를 위해 메모리 내용을 처리할 수 있습니다.
- XMemo 서버는 서버 측 시맨틱 리콜, 랭킹 및 내보내기를 위해 메모리 내용을 처리할 수 있습니다.
- 가장 편리한 모드이지만, 영지식(Zero-knowledge) 모드는 아닙니다.
- 삭제 시 메모리 행과 관련 메타데이터가 제거되며, DSAR 내보내기에는 평문이 포함될 수 있습니다.
Keyguard 모드
Keyguard는 XMemo의 호스팅형 리콜 경험을 유지하면서, envelope 작업을 조직이 제어하는 Azure Key Vault, AWS KMS, GCP KMS, KMIP 또는 유사한 공급자의 키에 바인딩합니다.
- 설정 마법사는 KMS binding을 저장하고 personal_default_mode = keyguard를 커밋합니다.
- 리콜을 수행하려면 KMS grant가 계속 유효해야 합니다. grant를 취소하면 이후의 decrypt/unwrap 작업이 차단됩니다.
- XMemo는 자체 암호문과 메타데이터를 삭제하지만, KMS 키의 로테이션이나 폐기는 테넌트가 직접 관리합니다.
Vault 모드
Vault는 영지식(Zero-knowledge) 옵션입니다. 브라우저 또는 디바이스가 데이터 전송 전에 암호화하며, 서버는 암호문, 라우팅 정보 및 envelope 메타데이터만 저장합니다.
- XMemo는 vault 메모리를 복호화할 수 없고, vault 키를 재설정할 수 없으며, 모든 디바이스와 복구 키트를 분실한 경우 데이터를 복원할 수 없습니다.
- Vault 데이터의 DSAR 내보내기에는 암호문과 envelope 메타데이터가 포함되며, 로컬에서 디바이스 또는 복구 키트를 사용하여 복호화해야 합니다.
- 해당 기능이 클라이언트가 제공하거나 개인정보를 보호하는 표현 방식으로 작동하지 않는 한, 호스팅형 시맨틱 기능이 제한될 수 있습니다.
프로덕션 데이터 경계
XMemo 프로덕션 아키텍처는 operator-managed Postgres, TLS 검증 및 애플리케이션 계층의 스코프 인가를 경계로 설계되었습니다. 데이터베이스 RLS/runtime context의 적용 여부는 배포별 검증이 필요합니다. Supabase는 개발 및 호환성 백엔드로만 취급되며, 이러한 보관 약속을 지원하는 프로덕션 기반이 아닙니다.
- Managed Postgres: 계정, 메모리, 벡터, 설정 및 감사 기록의 프로덕션 스토리지 경계.
- 데이터베이스 RLS/runtime context: 배포 환경별 고유한 제어 항목이며, 대상 환경에서 runtime role, migration ledger, runtime-context 플래그 및 owner/team CRUD 매트릭스를 검증해야 합니다.
- Supabase compatibility: 로컬 또는 OSS 환경에는 적합하지만, service-role 동작이 프로덕션 환경의 보안 강화 경계와 동일하지는 않습니다.
현재 보안 모드를 확인하는 방법
- Memory Console -> Settings -> Security mode를 열고 화면에 표시된 모드를 확인합니다.
- GET /api/v1/me/setup/state를 호출합니다. 설정을 완료한 계정은 setup_state = setup_completed 및 예상되는 selected_mode를 반환해야 합니다.
- GET /api/v1/me/security-mode를 호출합니다. posture에는 verified_effective_mode, new_write_mode, pending_write_mode, legacy_read_mode 및 migration_status가 포함되어야 합니다.
- Keyguard: 화면에 표시된 key binding id를 조직의 KMS 감사 로그와 대조합니다. Vault: 발신 쓰기 요청에 식별 가능한 평문 없이 불투명한 암호문만 포함되어 있는지 확인합니다.