# 거버넌스 및 보존

보존, 삭제, 내보내기, 데이터 경계 및 감사 증거에 대한 현재 거버넌스 상태를 확인합니다.

- Canonical: https://docs.xmemo.dev/ko/docs/concepts/governance-retention
- Locale: ko-KR
- Content-Locale: ko-KR
- Canonical-Content-Digest: 64872f32f2fa2549e9b806845665721e6289a5b6fe5d9e8dc96165599625c17b
- Edition-Digest: 5a54497a4cfd15c244a82082f882d6eee13fb0021822933b7e22b4387b927105
- Source-Revision: sha256:47f2eb881bc452bf2c7284e56f7b3ce65901de5335e31c6b20f6047355dc4f40

## 현재 보존은 서비스가 관리합니다

현재 MeGovernanceResponse는 retention.status=operator_managed 및 retention.available=false를 보고합니다. 계정별 자동 보존 규칙은 구성할 수 없으며 archive, forget 및 clear 작업은 명시적인 계정 작업이 필요합니다. 이 페이지는 자동 보존 일정에 대한 약속이 아니라 구현된 상태를 설명합니다.

```json
{
  "retention": {
    "status": "operator_managed",
    "available": false
  },
  "delete": {
    "status": "self_service",
    "available": true
  }
}
```

## 삭제와 내보내기는 서로 다른 상태를 가집니다

개별 메모리 삭제는 self-service입니다. 계정 수준 closure는 access를 철회하고 Personal purge workflow를 대기열에 넣습니다. response contract는 team-shared data가 Team에 남는다고 설명합니다. Export는 runtime 구성에 따라 self-service download 또는 request-only이며, 준비된 artifact는 자동으로 만료됩니다.

- delete — self-service 개별 메모리 삭제를 사용할 수 있습니다.
- export — runtime이 활성화한 경우에만 status는 self_service_download이고, 그렇지 않으면 request_only입니다.
- data_boundary — account-scoped이며 계정 간 access는 허용되지 않습니다.

## 거버넌스 작업은 감사 증거를 남깁니다

governance response는 audit.status=enabled를 보고하고 account action이 audit event를 발생시킨다고 설명합니다. audit-log access와 self-service audit export는 서비스 팀이 관리합니다. Memory deletion은 잊힌 content를 public result에 보존하지 않고 memory audit outbox에 mode, reason 존재 여부 및 target reference를 기록합니다.

```json
{
  "data_boundary": {
    "status": "account_scoped",
    "available": true
  },
  "audit": {
    "status": "enabled",
    "available": true
  }
}
```

## 모드를 선택하기 전에 유효한 상태 확인하기

Security mode와 governance 상태는 별도의 제어입니다. Cloud mode는 server-side processing을 허용하고, Keyguard는 감사되는 임시 decrypt와 함께 customer key wrapping을 사용하며, Vault는 memory body를 client-encrypted 상태로 유지하고 일반적으로 local recall이 필요합니다. 세 가지를 하나의 설정이 모두 제어한다고 가정하지 말고 현재 response contract에 따라 retention, deletion 및 security 처리를 선택하세요.

```text
retention  = operator_managed
delete     = self_service
audit      = enabled
security   = resolve the effective Cloud, Keyguard, or Vault mode
```

## ChatGPT 사용자

채팅에 전달자 토큰을 붙여넣지 않고도 XMemo 기본 설정, 프로젝트 사실, 결정 및 TODO에 대한 지속 가능한 액세스를 ChatGPT에 부여하세요.

ChatGPT/OpenAI 앱 OAuth 흐름을 통해 호스팅된 XMemo MCP 서버를 연결한 다음 XMemo 계정에 대한 메모리:읽기 및 메모리:쓰기 권한을 승인합니다.

종합 기본 설정이나 프로젝트 노트를 저장하고 새 채팅을 시작한 다음 작업을 계속하기 전에 XMemo를 통해 ChatGPT에 이를 불러오도록 요청하세요.

OAuth가 실패하거나 도구가 표시되지 않으면 호스트 앱의 MCP 서버에서 로그아웃하고 XMemo 서버 URL을 다시 연결한 후 직접 토큰을 생성하기 전에 다시 시도하세요.

## 부조종사/Codex 개발자

IDE와 CLI 에이전트 간에 리포지토리 결정, 코딩 규칙, 버그 수정 메모, 작업 기록을 전달합니다.

가능한 경우 VS Code / GitHub Copilot 및 Gemini CLI에 OAuth를 사용하세요. Copilot CLI, Codex, Cursor 또는 기타 직접 MCP 클라이언트의 경우 로컬 환경 또는 보안 저장소에 XMEMO_KEY를 유지하고 안정적인 XMEMO_AGENT_INSTANCE_ID를 설정하세요.

코드베이스 결정이나 버그 수정을 기록한 후 편집하기 전에 다음 IDE 또는 CLI 에이전트에게 관련 XMemo 컨텍스트를 기억하도록 요청하세요.

회수가 비어 있는 경우 선택한 MCP 구성 경로, 직접 클라이언트용 XMEMO_KEY 환경 변수 및 호스트 앱의 오래된 OAuth 자격 증명을 확인하세요.

## 팀/엔터프라이즈 파일럿 소유자

계정 제어, 소스 속성, 내보내기/삭제 워크플로, 검토자에게 안전한 설정 증거를 통해 공유 메모리를 평가합니다.

보호된 XMemo 작업 공간을 생성하거나 입력하고 승인된 사용자를 초대한 다음 준비 배지에 따라 OAuth 또는 범위가 지정된 직접 자격 증명을 통해 각 클라이언트를 연결합니다.

파일럿 멤버에게 가상 팀 메모리를 저장하고 XMemo에서 소스 속성을 확인한 다음 삭제/내보내기 및 지원 경로를 검토하도록 합니다.

구성원이 연결할 수 없는 경우 새 토큰을 발급하기 전에 역할 권한, OAuth 승인, 클라이언트 준비 상태 및 지원 지침을 확인하세요.

## 자율 에이전트 운영자

헤드리스 또는 예약 에이전트가 진행 상황을 기록하고, 이전 결정을 검색하고, 안정적이고 비밀이 아닌 인스턴스 ID를 유지하도록 합니다.

/api/v1/mcp/config/autonomous-agent를 가져옵니다. 실행기가 OAuth + 사용자 정의 헤더를 지원하는 경우 auth_modes.oauth를 선호합니다. 완전 헤드리스 러너에 대해서만 비밀 저장소의 XMEMO_KEY와 함께 auth_modes.xmemo_key를 사용하십시오.

XMemo에 진행 상황을 기록하는 하나의 합성 작업을 실행하고 실행기를 다시 시작한 다음 동일한 XMEMO_AGENT_INSTANCE_ID를 사용하여 해당 진행 상황을 호출하는지 확인합니다.

속성이 변경되거나 인스턴스 간에 분할된 경우 git 외부에서 XMEMO_AGENT_INSTANCE_ID를 유지하고 실행기가 시작할 때마다 이를 다시 생성하지 않는지 확인하세요.