# Dream / Reflection

Dream 후보 프리뷰, 검토 중심의 통합, 콘솔 동작 모드, 그리고 프리뷰 제안과 reflect 유지보수 도구를 구분하는 경계를 이해합니다.

- Canonical: https://docs.xmemo.dev/ko/docs/concepts/dream-reflection
- Locale: ko-KR
- Content-Locale: ko-KR
- Canonical-Content-Digest: 3e7b3df8ea8c94fd1d518674032b79705bd4d88c083d3d3add5929f5eda0610c
- Edition-Digest: ebac2fdde10ad3371905d7b9fa4f23251da34d80348b8e0ecfe27bc7bf0af047
- Source-Revision: sha256:6f8e110913bcc6793a7a5e098bcaed56d211e60f7e0895041fff8316967b9d49

## Dream 프리뷰 아키텍처 및 명시적 검토 워크플로

Dream은 https://xmemo.dev/me#dream 의 Memory Console에서 제공되는 사용자가 검토하는 별도의 Preview 기능입니다. 이는 reflect 유지보수 도구(MCP/API를 통해 온디맨드로 프로그래밍 방식의 통합 과정을 실행하는 도구; /docs/tools/reflect 참조)와 구별됩니다. Dream은 백그라운드에서 조용히 변경을 수행하는 대신 사용자가 검토하고 저장하도록 선택한 항목을 앞세워 흩어져 있는 대화 컨텍스트를 소스에 근거한 후보로 정리합니다.

- 콘솔 워크스페이스: https://xmemo.dev/me#dream 의 Memory Console에서 Dream은 "Review recurring patterns before they become long-term memory."라는 부제 아래 대화형 프리뷰 워크스페이스를 제공합니다.
- 사용자 중심 검토: Dream은 백그라운드에서 영구 메모리를 절대 수정하지 않습니다. 대상 쓰기가 발생하기 전에 모든 후보 항목에 대해 명시적인 인간의 검사 및 확인이 필요합니다.
- reflect와의 차이점: Dream은 사용자의 검사를 위해 후보가 생성되고 명시적인 인간의 확인 없이는 아무것도 저장되지 않는 별도의 프리뷰 기능입니다. 반면 reflect 유지보수 패스(/docs/tools/reflect)는 내부 도구로 summarize 작업이 활성 에피소드 메모리를 읽고 reflections/episodic 아래에 소스 기반 요약을 작성합니다. 반복되는 사실에 대해 reflect는 최소 0.35의 평균 중요도와 최소 0.6의 평균 신뢰도를 요구하는 에피소드에서 시맨틱으로의 promote 작업을 제공합니다. 해당 라이프사이클 작업은 expire, decay 및 archive를 실행하며, dry_run은 대상 쓰기 없는 안전한 계획을 제공합니다.
- 아키텍처 경계: Dream 후보 생성은 엄격히 프리뷰 메커니즘이며 투기적인 Light, REM 또는 Deep 다중 패스 아키텍처나 자율적인 백그라운드 변경을 구현하지 않습니다.
- 안전한 실패 자세: 실행이 중단되거나 문제가 발생하더라도 기존 메모리는 영향을 받지 않습니다("Dream stopped safely. Existing memory was not changed.").

## 계정 가용성, 플랜 카탈로그 상태 및 프리뷰 경계

Dream은 계정에 Dream이 활성화된 경우에만 엄격하게 작동합니다. 프로덕션 환경에서는 모든 런타임 제어가 기본적으로 꺼져 있습니다. 공개 문서에서는 내부 구성 플래그 노출을 피합니다.

- 계정 가용성: Dream은 계정에 Dream이 활성화된 경우에만 엄격하게 작동합니다. 워크스페이스에 해당 기능이 활성화되어 있지 않으면 콘솔에 "Dream is not enabled for this workspace yet. Your memory remains unchanged."라고 표시됩니다.
- 카탈로그 상태: 제품 플랜 카탈로그에서 Dream은 Free 티어에 포함되지 않으며 Plus 티어에는 Dream 기능이 나열되어 있습니다. 그러나 상업적 적용이 비활성 상태일 때 개인 폴백 공급자가 액세스를 거부하므로 문서에서는 오늘날 실제로 Plus가 Dream을 잠금 해제한다고 주장하지 않습니다.
- 결함 경계: Dream은 현재 프리뷰 상태이며 아직 계정에 대한 후보를 생성하지 못할 수 있습니다. 모델 기반 합성은 제공된 워커 환경에서 직접 실행될 수 없으며 후보 확인은 서버 용량 구성에 따라 달라집니다.
- 엄격한 인간 확인: 시스템은 엄격한 인간 확인 경계를 적용합니다. 문서는 자동 저장이나 백그라운드 추가에 대한 모든 주장을 거부하며, 제안된 모든 항목에는 수동 사용자 동의가 필요합니다.

## 실행 라이프사이클, 증거 적격성 및 필터 사유 코드

Dream 실행은 소스 레코드를 변경하지 않고 반복되는 패턴을 식별하기 위해 구성 가능한 관찰 기간(기본값 30일)에 걸쳐 적격 메모리 증거를 검토합니다:

- 증거 수집: 프리뷰 실행은 관찰 기간(--window-days를 통해 최대 365일까지 맞춤 설정 가능) 내에 생성된 활성의 회상 가능한 에피소드 메모리를 검사합니다.
- 근거 있는 후보: 적격 증거는 반복되는 주제로 그룹화되어 소스 계보 및 신뢰도 점수("Confidence Score")와 함께 표시되는 후보 항목을 생성합니다.
- 증거가 필터링된 이유: 콘솔에서 실행 요약은 표준화된 이유 칩을 사용하여 "Why evidence was filtered"를 보고합니다: score below threshold, insufficient occurrences, insufficient evidence days, insufficient query contexts, duplicate candidate, source not episodic, source inactive 및 contradiction detected.
- 콘텐츠 없는 실행 요약: 완료된 실행에는 "Dream reviewed {{considered}} signals, generated {{generated}} grounded candidates, and saved {{promoted}} confirmed memories."라는 검토 요약이 표시되며 "This report is review-only and never becomes Dream evidence."라는 안전 보장이 함께 제공됩니다.

## 콘솔 운영 모드 및 예약 프리셋

Dream 설정은 콘솔 설정 서랍 내에서 실행 모드와 평가 일정을 세밀하게 제어할 수 있도록 지원합니다:

- 운영 모드: 사용자는 두 가지 동작 모드 중에서 선택합니다: "Preview only"(쓰기 권한 없이 증거를 평가하고 검토 가능한 후보 생성) 및 "Allow explicit confirmation"(사용자가 개별 후보를 검토하고 선택적으로 커밋할 수 있도록 확인 인터페이스 활성화).
- 예약 프리셋: 실행 빈도는 세 가지 프리셋을 통해 구성됩니다: "Manual only"(콘솔에서 "Run Preview"를 선택하거나 CLI 프리뷰 명령을 내릴 때 온디맨드로만 실행), "Daily around 03:00"(사용자 현지 시간대 기준 03:00경에 평가되는 예약된 일일 실행) 및 "Weekly on Monday around 03:00"(사용자 현지 시간대 기준 월요일 03:00경에 평가되는 예약된 주간 실행).
- 예약 실행 제한: 예약된 실행은 preview only 모드로 작동합니다. 백그라운드 일정 평가는 메모리 쓰기를 커밋하거나 인간 검토를 우회하지 않습니다.
- 시간대 기준: 예약된 실행은 사용자 브라우저의 로컬 시간대를 사용합니다.

## 확인 워크플로, 형식화된 결과 및 대상 라이프사이클

후보 커밋은 추가 전용(append-only)이며 명시적인 사용자 조치가 필요합니다. 콘솔은 단일 항목 확인 및 선택적 형식화된 결과를 지원합니다:

- 핵심 확인: 표준 프리뷰 모드에서 후보 카드의 "Confirm and save" 버튼을 클릭하면 의미 체계 키 dream:confirmed:... 와 함께 dream/confirmed/... 경로 아래에 새로운 메모리 레코드가 생성됩니다. 소스 메모리는 편집되거나 덮어쓰여지지 않습니다.
- 형식화된 결과 구성: 형식화된 결과를 사용할 수 있는 경우 설정 서랍에 "Choose what to generate. Turning a type off keeps existing drafts and saved content."라는 안내와 함께 "What should Dream prepare?"라는 질문이 표시됩니다.
- 6가지 생성 선택: (1) Preferences: "Clarify your preferences"; (2) Knowledge: "Distill knowledge worth keeping"; (3) Skills: "Turn experience into reusable skills"; (4) Projects: "Organize project memory"; (5) Patterns: "Discover lasting patterns"; (6) Durable Memory: "Build reusable long-term memory".
- 생성 스위치 대 대상 동의: 생성 스위치를 활성화해도 대상에 대한 동의가 부여되지 않으며 준비된 모든 결과는 수동 검토가 필요한 "Prepared for your review" 아래에 나타납니다.
- 후보 검토 작업: 검토자는 제안된 제목과 콘텐츠를 수정하기 위해 "Save edits"를 선택하거나, 연기하기 위해 "Review later"를 선택하거나, 폐기하기 위해 "Reject"를 선택하거나, 대상 위치로 수락할 수 있습니다.
- 대상별 수락: Knowledge는 선택한 지식 베이스로 DRAFT 형태로 "Add draft to knowledge base"를 통해 수락됩니다(검색 색인 상태: "Saved. Preparing for search.", "Search index is ready. Publication is a separate choice.", "Saved, but indexing needs another attempt."); Skill은 DRAFT 형태로 "Add draft to Cloud Skills"를 통해 수락됩니다; Project는 "Confirm project organization"을 통해 수락됩니다(프로젝트 연결 결과는 기존 메모리를 프로젝트 워크스페이스에 재할당하는 유일한 경로입니다); Memory는 "Save as memory"를 통해 수락됩니다.
- 제거: 확인된 결과는 각 저장소에서 표준 메모리, 지식 초안 또는 스킬 초안이 됩니다. 표준 콘솔 또는 API 제거 작업을 사용하여 삭제되며 Dream 전용 롤백이나 실행 취소 메커니즘은 없습니다.

## 워크스페이스 격리, 팀 경계 및 CLI 작업

워크스페이스 권한과 CLI 도구는 엄격한 멀티 테넌트 경계와 역할 기능을 적용합니다:

- 워크스페이스 범위 지정: 콘솔 헤더는 활성 워크스페이스를 "Personal space" 또는 "Team space"로 식별합니다.
- 팀 권한: Team 공간에서는 팀 소유자와 관리자만 Dream 설정을 수정하거나 활성 실행을 취소하거나 후보 메모리를 확인할 수 있습니다("Only Team owners and admins can change Dream settings.").
- 팀 형식화된 결과 제한: 형식화된 결과는 Team 공간에서 사용할 수 없습니다. Team 워크스페이스는 preview-only 또는 v1 메모리 확인 모드로 작동합니다.
- 검증된 CLI 명령: xmemo CLI(고정 커밋 d412c7866b7a4c8eedb3a0cf40748c6aef8707ec, src/commands/dream.js)는 세 가지 검증된 명령을 지원합니다: xmemo dream preview [--window-days <n>] [--wait] [--json](프리뷰를 트리거합니다; 프리뷰가 비활성화된 경우 "Dream preview is disabled; CLI will not change Dream settings."와 함께 fail closed 처리됨), xmemo dream show <run-id> [--wait] [--json](후보 항목을 표시합니다; 읽음 확인을 위한 --receipt-out 지원) 및 xmemo dream apply <run-id> --item <id> --from <view.json> --yes [--json](v1 confirm 엔드포인트를 사용하여 후보를 확인합니다).
- CLI 운영 경계: CLI는 Dream 구성 설정을 변경할 수 없으며(설정은 콘솔에서 관리해야 함), dream apply는 전적으로 v1 메모리 확인으로만 작동합니다(형식화된 결과 변경을 수행하지 않음).

```bash
# Trigger a candidate preview across a 30-day window
xmemo dream preview --window-days 30 --wait --json

# Inspect candidate proposals and record a read receipt
xmemo dream show <run-id> --receipt-out receipt.json

# Confirm a candidate proposal into memory via v1 confirmation
xmemo dream apply <run-id> --item <item-id> --from view.json --yes
```

## 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를 유지하고 실행기가 시작할 때마다 이를 다시 생성하지 않는지 확인하세요.
