왜 AI assistant가 전에 말한 내용을 기억하지 못하나요?

증상: 중요한 preference나 detail을 저장했지만, 나중 chat에서 AI assistant가 처음 보는 것처럼 행동합니다. 원인: assistant가 다른 XMemo account, project 또는 device context에 연결되었거나 원래 memory가 저장되지 않았을 수 있습니다. 조치: assistant에게 작고 민감하지 않은 test detail을 저장하도록 요청한 다음 Memory Console을 열어 사용하는 account와 project 아래에 나타나는지 확인합니다. 확인: 같은 assistant로 새 chat을 시작해 test detail을 물어보고, 끝나면 test entry를 제거합니다. 안전: 만들어 낸 test detail을 사용하고 다른 사람의 private information은 사용하지 않습니다.

왜 AI assistant가 project나 conversation을 혼동하나요?

증상: 한 project의 detail이 다른 project에 나타나거나, assistant가 서로 다른 conversation을 하나인 것처럼 답합니다. 원인: assistant가 memory가 저장된 곳과 다른 project 또는 account context를 사용하고 있을 수 있습니다. 조치: assistant에서 사용할 XMemo account와 project를 선택하고, 필요하면 다시 연결한 뒤 명확히 표시한 test detail로 재시도합니다. 확인: Memory Console에서 memory의 project와 source를 확인한 다음, 관련 없는 project가 그 test detail을 볼 수 없는지 확인합니다. 안전: 나타나게 만들기 위해 project 사이에서 private information을 옮기지 않습니다.

AI assistant가 어떤 내용을 완전히 잊게 하려면 어떻게 해야 하나요?

증상: memory 하나를 제거하고 그것이 사라졌는지 확인하고 싶습니다. 원인: memory 보기, 복구 가능한 제거, 영구 삭제 및 export는 서로 다른 account action입니다. 조치: Memory Console을 열어 memory를 찾고 delete 또는 forget control을 사용합니다. control을 찾을 수 없으면 memory reference와 함께 Support에 문의합니다. 확인: 다시 memory를 검색해 Memory Console에 표시된 state를 확인하고, export에 자신의 account data만 포함되는지 확인합니다. 안전: 의도한 memory만 삭제하고 Support message에 private content를 절대 포함하지 않습니다.

컴퓨터나 AI assistant를 바꾸면 XMemo는 여전히 저를 기억하나요?

증상: device를 바꾸거나 assistant를 restart하거나 host를 전환한 뒤 이전 memory와 새 memory가 분리된 것처럼 보입니다. 원인: 새 assistant connection이 device나 assistant를 새 source로 식별하거나 다른 account에 로그인했을 수 있습니다. 조치: 사용하려는 assistant에서 XMemo를 다시 연결하고 같은 account에 로그인하며, app이 옵션을 제공하면 connection의 device label을 안정적으로 유지합니다. 확인: 만들어 낸 test detail 하나를 저장하고 같은 assistant에서 새 chat을 시작해 account를 바꾸지 않고 detail이 나타나는지 확인합니다. 안전: 공유 computer에 personal data를 저장하기 전에 account를 확인합니다.

왜 AI assistant가 같은 내용을 두 번 저장했나요?

증상: retry 또는 reconnect 후 같은 memory처럼 보이는 사본이 두 개 보입니다. 원인: assistant가 결과를 표시하지 않았어도 첫 save가 성공했을 수 있어 request를 반복하면 사본이 생깁니다. 조치: Memory Console을 열어 두 entry를 비교하고 date와 source를 확인한 뒤 duplicate만 제거합니다. 확인: 명확히 표시한 새 test detail을 한 번만 저장하도록 assistant에 요청하고 새 entry가 하나만 생기는지 확인합니다. 안전: 유지할 사본을 확인하기 전에는 일치하는 memory를 모두 삭제하지 않습니다.

왜 AI assistant가 과거 context를 너무 많이 또는 너무 적게 주나요?

증상: assistant가 관련 없는 detail을 꺼내거나 필요한 decision을 놓치거나 답변이 과도하게 복잡해집니다. 원인: 요청이 너무 넓은 topic이나 time period를 다루거나 assistant가 conversation에 필요한 것보다 많은 saved context를 사용하려는 것일 수 있습니다. 조치: 더 좁은 topic, project 또는 time period를 요청하고 어떤 decision이나 detail이 가장 중요한지 assistant에 알립니다. 확인: 답변을 요청한 topic과 비교하고 계속하기 전에 conversation에서 관련 없는 detail을 제거합니다. 안전: conversation을 채우기 위해 관련 없는 private memory를 드러내도록 assistant에 요청하지 않습니다.

XMemo 연결을 끊은 뒤 이전 assistant가 사용할 수 없게 하려면 어떻게 해야 하나요?

증상: assistant에서 connection을 제거했지만 여전히 memory에 access할 수 있는지 확신이 없습니다. 원인: app에서 connection을 제거해도 account의 connection permission이 취소되지 않을 수 있습니다. 조치: XMemo account의 connected-app 또는 security control을 열어 이전 assistant connection을 revoke하고 신뢰하는 connection만 다시 연결합니다. 확인: 안전한 경우에만 이전 connection을 시도해 거부되는지 확인한 뒤 새 connection을 사용합니다. 안전: 제거하려는 connection만 revoke하고 account sign-in detail을 공유하지 않습니다.

왜 AI assistant가 더 이상 XMemo를 사용할 수 없나요?

증상: 이전에는 assistant에서 XMemo를 사용할 수 있었지만 memory action이 더 이상 보이지 않거나 assistant가 사용할 수 없다고 말합니다. 원인: assistant의 XMemo connection을 refresh해야 하거나 다른 account에 로그인했을 수 있습니다. 조치: assistant의 connected-app settings에서 XMemo를 disconnect한 후 다시 연결하고 새 chat을 시작합니다. 확인: assistant에게 XMemo가 연결되었는지 보여 달라고 요청한 다음 무엇이든 저장하기 전에 무해한 read를 시도합니다. 안전: chat이나 Support request에 secret account detail 또는 private memory를 붙여 넣지 않습니다.

AI assistant에서 어떤 XMemo connection을 사용해야 하나요?

증상: assistant settings에 어떤 XMemo page나 connection을 넣어야 하는지 모르겠습니다. 원인: guided setup page와 assistant connection은 서로 다른 목적을 가지며 hosted와 self-managed setup은 서로 다른 boundary를 가집니다. 조치: hosted service라면 https://xmemo.dev/product/docs에서 시작해 assistant에 표시된 connection link를 따릅니다. 조직에서 다른 setup page를 제공했다면 Support에 문의합니다. 확인: personal detail을 저장하기 전에 page가 의도한 XMemo account와 hosted service를 사용하는지 확인합니다. 안전: local development address를 사용하거나 public chat에 private credential을 붙여 넣지 않습니다.

AI assistant가 여전히 XMemo에 연결되지 않으면 어떻게 해야 하나요?

증상: connection 단계를 다시 시도했지만 assistant가 여전히 XMemo를 사용할 수 없습니다. 원인: 문제가 assistant app, account 또는 public instruction으로는 확인할 수 없는 stale connection에 있을 수 있습니다. 조치: assistant name, 대략적인 time과 본 내용을 간단히 적어 Support에 문의하고 redacted detail만 포함합니다. 확인: private memory나 account secret을 보내지 않고 report를 재현할 수 있는지 확인합니다. 안전: sign-in detail, one-time code, cookie 또는 private memory text를 절대 보내지 않습니다.

OAuth가 실패하거나 consent window가 끝나지 않습니다.

증상: client에 401이 표시되거나 OAuth browser가 열리지 않거나 consent가 usable connection 없이 client로 돌아옵니다. 원인: hosted grant가 stale이거나 browser handoff가 차단되었거나 client가 이전 server registration을 사용하고 있을 수 있습니다. 조치: host app에서 XMemo MCP server를 sign out하고 hosted MCP URL을 다시 연결한 뒤 memory:read와 memory:write를 다시 승인합니다. 확인: client가 active authorization을 보고할 때까지 다시 연결한 다음 memory를 기록하기 전에 무해한 recall을 실행합니다. 안전: stale OAuth session을 우회하려고 OAuth client에서 XMEMO_KEY로 전환하지 않습니다.

request가 403 Forbidden을 반환합니다.

증상: server에 도달하고 credential도 인식되지만 요청한 project, tool 또는 memory action이 거부됩니다. 원인: grant에 필요한 scope가 없거나 account가 선택한 project boundary 밖에 있거나 resource가 다른 tenant에 속합니다. 조치: 선택한 account와 project를 확인하고 OAuth를 다시 연결하거나 필요한 scope를 요청한 뒤 resource를 바꾸지 않고 같은 operation을 재시도합니다. 확인: write 또는 delete operation을 다시 시도하기 전에 의도한 project에서 read-only request가 성공하는지 확인합니다. 안전: 403을 없애려고 scope를 넓히거나 다른 사용자의 token을 복사하지 않습니다.

MCP server는 연결되지만 tool이 나타나지 않습니다.

증상: host에는 connected server가 표시되지만 tools/list가 비어 있거나 XMemo tool이 model tool picker에서 사라집니다. 원인: client가 discovery를 refresh하지 않았거나 잘못된 MCP profile을 사용하거나 stale URL 또는 registration에 연결되었을 수 있습니다. 조치: server를 다시 연결하고 client가 지원되는 MCP profile을 사용하는지 확인한 다음 credential을 변경하기 전에 tool discovery를 다시 실행합니다. 확인: write 또는 marketplace demonstration을 시작하기 전에 remember, recall, search_memory가 적어도 나타나는지 확인합니다. 안전: screenshot, Support ticket 또는 marketplace review note에 bearer token을 붙여 넣지 않습니다.

direct MCP client가 token missing이라고 말합니다.

증상: machine 어딘가에 variable을 추가했는데도 direct client가 XMEMO_KEY가 unset, empty 또는 unavailable이라고 보고합니다. 원인: client process가 environment를 상속하지 않았거나 다른 shell에 variable을 추가했거나 config가 대신 secret-store reference를 요구할 수 있습니다. 조치: local environment 또는 secret store에 XMEMO_KEY를 설정하고 client를 restart하며 attribution이 중요할 때 XMEMO_AGENT_INSTANCE_ID를 안정적으로 유지합니다. 확인: variable value는 출력하지 말고 presence metadata만 확인한 뒤 client를 restart하여 무해한 authenticated recall을 확인합니다. 안전: 실제 token은 git에 commit한 config file 밖에 두고 public example에서는 environment variable만 참조합니다.

restart할 때마다 agent instance ID가 바뀝니다.

증상: restart 또는 redeploy 후 같은 local runner가 여러 agent로 보이거나 recall이 여러 instance로 나뉩니다. 원인: XMEMO_AGENT_INSTANCE_ID가 runner의 local secret 또는 environment configuration에 저장되지 않고 process start 때 생성됩니다. 조치: runner마다 non-secret instance label 하나를 생성하고 git 밖에 저장한 뒤 모든 direct MCP connection에 보냅니다. 확인: runner를 두 번 restart하고 credential을 노출하지 않은 채 source attribution에 같은 instance label이 나타나는지 확인합니다. 안전: instance label은 attribution metadata이지 authorization credential이 아니며 access는 account와 token boundary가 여전히 제어합니다.

recall이 빈 memory를 반환합니다.

증상: user가 context를 저장했는데 recall 또는 search는 성공하고 관련 record를 반환하지 않습니다. 원인: read가 write와 다른 account, project, scope, agent boundary 또는 memory type을 사용하거나 test record가 commit되지 않았을 수 있습니다. 조치: synthetic test memory를 만들고 Memory Console에서 path와 memory type을 확인한 다음 같은 account 또는 tenant boundary에서 recall을 다시 시도합니다. 확인: 같은 project와 scope로 새 synthetic record를 다시 읽고 의도한 delete path를 통해 제거합니다. 안전: synthetic review data를 사용하고 marketplace demo에 private customer memory를 사용하지 않습니다.

recall 또는 write가 잘못된 project scope를 사용합니다.

증상: record가 한 project에서는 보이지만 다른 project에서는 보이지 않거나 operator가 의도하지 않은 project에 write가 나타납니다. 원인: client가 다른 environment의 project identifier를 재사용했거나 project boundary를 생략했거나 stale account session을 유지하고 있습니다. 조치: 의도한 account와 project를 명시적으로 선택하고 client context를 refresh한 뒤 synthetic record로 operation을 반복합니다. 확인: Memory Console에서 record의 project와 source attribution을 확인한 다음 관련 없는 project가 읽을 수 없는지 검증합니다. 안전: scope mismatch를 해결하려고 더 넓은 token을 부여하거나 project 사이에서 data를 복사하지 않습니다.

같은 memory가 두 번 저장됩니다.

증상: retry 또는 reconnect가 durable memory 하나 대신 duplicate record를 만듭니다. 원인: client가 idempotency boundary 없이 timeout 후 retry했거나 첫 response를 확인하기 전에 capture flow가 write했을 수 있습니다. 조치: 먼저 기존 record와 source attribution을 확인한 뒤 client retry policy 또는 안정적인 idempotency key를 사용해 다시 write합니다. 확인: 같은 controlled capture를 한 번 반복해 새 record 하나와 readback 하나만 생기고 새 record 두 개는 생기지 않는지 확인합니다. 안전: 대상 record와 account scope를 확인하기 전에는 일치하는 memory를 일괄 삭제하지 않습니다.

recall context가 너무 크거나 작습니다.

증상: agent가 관련 없는 context를 받거나 필요한 decision을 놓치거나 host의 유용한 context budget을 초과합니다. 원인: query가 너무 넓거나 scope 또는 time window가 없거나 caller가 task에 맞지 않는 result limit을 요청했을 수 있습니다. 조치: project, agent, time 또는 topic boundary로 query를 좁히고 limit을 늘리기 전에 작고 관련 있는 set을 요청합니다. 확인: 반환된 context를 대상 question과 비교하고 포함된 모든 record가 authorized이며 유용한지 확인합니다. 안전: context window를 채우려고 scope를 넓히거나 관련 없는 memory를 export하지 않습니다.

memory를 어떻게 삭제하거나 export하나요?

증상: operator가 record를 제거하거나 forget action을 확인하거나 account-scoped export를 받아야 합니다. 원인: delete, recoverable forget, permanent delete와 export는 서로 다른 confirmation 및 recovery semantics를 가진 별도 workflow입니다. 조치: 먼저 Memory Console 또는 account workflow를 사용하고 self-service path가 없으면 request가 account 범위에 머물도록 Support에 문의합니다. 확인: forget 또는 delete 후 record reference로 검색해 기대한 recoverable 또는 permanent state를 확인하고 export가 account scope만 포함하는지 확인합니다. 안전: export와 Support bundle에서 token hash, API key, session secret, provider credential 및 관련 없는 tenant data를 제외합니다.

client 연결을 끊은 뒤 access를 어떻게 revoke하나요?

증상: client를 local에서 제거했지만 operator가 OAuth grant를 무효화하거나 direct credential을 rotate해야 합니다. 원인: client config를 disconnect해도 server-side grant가 revoke되거나 direct token이 rotate되는 것은 아닙니다. 조치: account security 또는 connected-client control을 열어 해당 OAuth grant를 revoke하고 노출되었거나 더 이상 신뢰하지 않는 direct credential은 rotate합니다. 확인: 이전 connection으로 authenticated read를 retry해 거부되는지 확인한 다음 의도한 consent 또는 secret-store path로만 다시 연결합니다. 안전: 의도한 client 또는 grant만 revoke하고 access를 진단하는 동안 이전 token, OAuth code 또는 session detail을 publish하지 않습니다.

XMemo는 GA이거나 certified이거나 marketplace에 등록되어 있나요?

증상: listing 또는 document가 working configuration이 GA, certification 또는 marketplace approval을 증명하는지 묻습니다. 원인: configuration support, OAuth readiness, pilot evidence와 marketplace approval은 서로 다른 claim입니다. 조치: 구체적인 marketplace approval 또는 certification artifact가 없다면 public wording을 beta/config-supported로 취급합니다. 확인: status claim을 publish하기 전에 canonical client capability matrix와 명시된 approval artifact를 확인합니다. 안전: working config만으로 GA, certified, stable 또는 listed status를 주장하지 않습니다.

어떤 URL을 사용해야 하나요?

증상: hosted user가 public quickstart, MCP endpoint 또는 self-hosted developer instruction 중 무엇을 따라야 할지 모릅니다. 원인: hosted onboarding과 self-hosted 또는 legacy deployment path는 서로 다른 URL, credential 및 data boundary를 가집니다. 조치: hosted user는 MCP client에 https://xmemo.dev/mcp를 사용하고 guided setup에는 https://xmemo.dev/product/docs에서 시작합니다. 확인: 연결하기 전에 host URL, authentication mode와 account boundary가 의도한 hosted 또는 self-hosted deployment와 일치하는지 확인합니다. 안전: public hosted user의 첫 경로로 localhost, Supabase, Docker 또는 self-hosted Python instruction을 사용하지 않습니다.

memory가 잘못된 agent 또는 device 아래에 나타납니다.

증상: client update 또는 restart 후 memory가 다른 runner에 attribution되거나 device 사이에서 나뉘어 보입니다. 원인: client가 non-secret agent 또는 instance header를 바꾸었거나 shared credential을 여러 runner가 사용하고 있습니다. 조치: non-secret agent/device header 또는 client profile을 확인한 다음 local instance ID를 다시 생성하지 말고 persist합니다. 확인: 의도한 runner에서 synthetic record 하나를 write하고 reconnect 후에도 source attribution이 안정적인지 확인합니다. 안전: attribution label은 source review를 돕지만 security boundary가 아니며 access는 account credential이 여전히 결정합니다.

단계를 따라도 여전히 연결할 수 없습니다.

증상: client-specific OAuth 또는 direct-secret path를 다시 시도했지만 connection을 사용할 수 없습니다. 원인: 남은 문제가 client-specific, account-specific이거나 local docs가 확인할 수 없는 stale registration 또는 environment boundary 때문일 수 있습니다. 조치: client name, config path, 대략적인 timestamp와 OAuth 또는 XMEMO_KEY 사용 여부를 적어 Support를 엽니다. 확인: Support report에 재현 가능한 symptom과 redacted metadata가 들어 있는지 확인한 뒤 account-scoped diagnosis를 기다립니다. 안전: redacted diagnostic만 공유하고 bearer token, OAuth code, cookie 또는 customer memory content는 절대 보내지 않습니다.

문제 해결 · XMemo Docs

memory에 쓰지 않고 연결 확인

아래의 모든 문제 해결 경로는 verification 단계로 끝납니다. 읽기부터 시작하십시오. 아무것도 변경하지 않고 credential과 transport를 증명합니다.

curl -s -o /dev/null -w '%{http_code}\n' \
  -H 'X-API-Key: <your-assigned-api-key>' \
  'https://xmemo.dev/v1/memories/search?query=connection%20check&limit=1'

status code 확인

Status는 credential 문제와 빈 memory store를 구분합니다.

200 — authorized; an empty results array just means nothing matched.
401 — the credential is missing or not valid.
403 — the credential is valid but lacks the required scope.

클라이언트 연결 오류

AI 클라이언트 또는 러너가 MCP 서버에 도달할 수 없는 경우 토큰을 순환하기 전에 전송 프로토콜 협상 및 호스트 라우팅을 격리하십시오.

/health에 대한 직접 GET 또는 /mcp에 대한 OPTIONS로 서버 상태를 확인합니다.
전송 호환성을 확인합니다. 호스팅된 클라이언트는 Streamable HTTP(/mcp)를 사용하고 로컬 CLI 도구는 stdio를 사용합니다.
회사 프록시나 방화벽이 청크 잘림 없이 스트리밍 SSE 응답을 허용하는지 확인합니다.

curl -I -s 'https://xmemo.dev/mcp'

인증 실패

인증 실패는 누락된 자격 증명(401 Unauthorized)과 불충분한 권한 또는 테넌트 경계 위반(403 Forbidden)을 구분합니다.

OAuth 클라이언트: 호스트 앱을 통해 다시 연결하고 memory:read 및 memory:write 권한을 부여합니다.
Direct MCP 클라이언트: git에 비밀을 노출하지 않고 프로세스 환경에 XMEMO_KEY가 설정되어 있는지 확인합니다.
403 Forbidden: 토큰이 활성 테넌트 및 project scope에 속하는지 확인합니다.

curl -s -o /dev/null -w '%{http_code}\n' \
  -H 'Authorization: Bearer <your-token>' \
  'https://xmemo.dev/v1/memories/search?query=auth%20check&limit=1'

빈 회상 결과

회상 결과가 0개 반환되는 것은 엔진 오류가 아니라 경계 또는 쿼리 불일치를 나타냅니다. 일치하는 메모리가 없으면 읽기가 200 OK로 성공합니다.

Project scope 불일치: 쿼리하는 에이전트가 저장된 메모리와 동일한 project 경계에서 작동하는지 확인합니다.
에이전트 인스턴스 경계: XMEMO_AGENT_INSTANCE_ID로 필터링하는 Direct 클라이언트는 다른 인스턴스 식별자로 저장된 메모리를 읽을 수 없습니다.
상태 확인: Memory Console에서 메모리가 커밋되었으며 소프트 삭제되거나 대체되지 않은 active 상태인지 확인합니다.

curl -s -H 'Authorization: Bearer <your-token>' \
  'https://xmemo.dev/v1/memories/search?query=test&limit=5&scope=project:demo'

쓰기 잠금 시간 초과

여러 러너의 동시 쓰기 또는 병렬 도구 실행으로 인해 공유 memory path에서 쓰기 잠금 경합이 발생할 수 있습니다.

쓰기 요청에서 잠금 경합이 반환되면 무작위 지터를 사용하는 지수 백오프를 클라이언트에 구현합니다.
중복 메모리 항목 생성을 방지하기 위해 쓰기 재시도 시 클라이언트 측 멱등성 키(idempotency key)를 제공합니다.
빈도가 높은 워크플로의 경우 작업 큐 또는 배치 API를 사용하여 메모리 변경 작업을 직렬화합니다.

curl -s -X POST 'https://xmemo.dev/v1/memories' \
  -H 'Authorization: Bearer <your-token>' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: <generate-a-uuid-v4>' \
  -d '{"content":"Durable convention fact","path":"projects/demo/conventions"}'

FAQ / 문제 해결

먼저 AI assistant 사용자를 위한 답변을 확인한 다음, 연결 및 운영 세부 정보는 developer와 integrator 답변을 사용합니다. 모든 답변에는 action 단계와 safety 경계가 포함됩니다.

AI assistant 사용자용

connection을 직접 구성하지 않고 AI assistant를 통해 XMemo를 사용하는 사람을 위한 일상적인 답변입니다.

왜 AI assistant가 전에 말한 내용을 기억하지 못하나요?
증상
중요한 preference나 detail을 저장했지만, 나중 chat에서 AI assistant가 처음 보는 것처럼 행동합니다.
원인
assistant가 다른 XMemo account, project 또는 device context에 연결되었거나 원래 memory가 저장되지 않았을 수 있습니다.
조치:
assistant에게 작고 민감하지 않은 test detail을 저장하도록 요청한 다음 Memory Console을 열어 사용하는 account와 project 아래에 나타나는지 확인합니다.
확인
같은 assistant로 새 chat을 시작해 test detail을 물어보고, 끝나면 test entry를 제거합니다.
안전:
만들어 낸 test detail을 사용하고 다른 사람의 private information은 사용하지 않습니다.
왜 AI assistant가 project나 conversation을 혼동하나요?
증상
한 project의 detail이 다른 project에 나타나거나, assistant가 서로 다른 conversation을 하나인 것처럼 답합니다.
원인
assistant가 memory가 저장된 곳과 다른 project 또는 account context를 사용하고 있을 수 있습니다.
조치:
assistant에서 사용할 XMemo account와 project를 선택하고, 필요하면 다시 연결한 뒤 명확히 표시한 test detail로 재시도합니다.
확인
Memory Console에서 memory의 project와 source를 확인한 다음, 관련 없는 project가 그 test detail을 볼 수 없는지 확인합니다.
안전:
나타나게 만들기 위해 project 사이에서 private information을 옮기지 않습니다.
AI assistant가 어떤 내용을 완전히 잊게 하려면 어떻게 해야 하나요?
증상
memory 하나를 제거하고 그것이 사라졌는지 확인하고 싶습니다.
원인
memory 보기, 복구 가능한 제거, 영구 삭제 및 export는 서로 다른 account action입니다.
조치:
Memory Console을 열어 memory를 찾고 delete 또는 forget control을 사용합니다. control을 찾을 수 없으면 memory reference와 함께 Support에 문의합니다.
확인
다시 memory를 검색해 Memory Console에 표시된 state를 확인하고, export에 자신의 account data만 포함되는지 확인합니다.
안전:
의도한 memory만 삭제하고 Support message에 private content를 절대 포함하지 않습니다.
컴퓨터나 AI assistant를 바꾸면 XMemo는 여전히 저를 기억하나요?
증상
device를 바꾸거나 assistant를 restart하거나 host를 전환한 뒤 이전 memory와 새 memory가 분리된 것처럼 보입니다.
원인
새 assistant connection이 device나 assistant를 새 source로 식별하거나 다른 account에 로그인했을 수 있습니다.
조치:
사용하려는 assistant에서 XMemo를 다시 연결하고 같은 account에 로그인하며, app이 옵션을 제공하면 connection의 device label을 안정적으로 유지합니다.
확인
만들어 낸 test detail 하나를 저장하고 같은 assistant에서 새 chat을 시작해 account를 바꾸지 않고 detail이 나타나는지 확인합니다.
안전:
공유 computer에 personal data를 저장하기 전에 account를 확인합니다.
왜 AI assistant가 같은 내용을 두 번 저장했나요?
증상
retry 또는 reconnect 후 같은 memory처럼 보이는 사본이 두 개 보입니다.
원인
assistant가 결과를 표시하지 않았어도 첫 save가 성공했을 수 있어 request를 반복하면 사본이 생깁니다.
조치:
Memory Console을 열어 두 entry를 비교하고 date와 source를 확인한 뒤 duplicate만 제거합니다.
확인
명확히 표시한 새 test detail을 한 번만 저장하도록 assistant에 요청하고 새 entry가 하나만 생기는지 확인합니다.
안전:
유지할 사본을 확인하기 전에는 일치하는 memory를 모두 삭제하지 않습니다.
왜 AI assistant가 과거 context를 너무 많이 또는 너무 적게 주나요?
증상
assistant가 관련 없는 detail을 꺼내거나 필요한 decision을 놓치거나 답변이 과도하게 복잡해집니다.
원인
요청이 너무 넓은 topic이나 time period를 다루거나 assistant가 conversation에 필요한 것보다 많은 saved context를 사용하려는 것일 수 있습니다.
조치:
더 좁은 topic, project 또는 time period를 요청하고 어떤 decision이나 detail이 가장 중요한지 assistant에 알립니다.
확인
답변을 요청한 topic과 비교하고 계속하기 전에 conversation에서 관련 없는 detail을 제거합니다.
안전:
conversation을 채우기 위해 관련 없는 private memory를 드러내도록 assistant에 요청하지 않습니다.
XMemo 연결을 끊은 뒤 이전 assistant가 사용할 수 없게 하려면 어떻게 해야 하나요?
증상
assistant에서 connection을 제거했지만 여전히 memory에 access할 수 있는지 확신이 없습니다.
원인
app에서 connection을 제거해도 account의 connection permission이 취소되지 않을 수 있습니다.
조치:
XMemo account의 connected-app 또는 security control을 열어 이전 assistant connection을 revoke하고 신뢰하는 connection만 다시 연결합니다.
확인
안전한 경우에만 이전 connection을 시도해 거부되는지 확인한 뒤 새 connection을 사용합니다.
안전:
제거하려는 connection만 revoke하고 account sign-in detail을 공유하지 않습니다.
왜 AI assistant가 더 이상 XMemo를 사용할 수 없나요?
증상
이전에는 assistant에서 XMemo를 사용할 수 있었지만 memory action이 더 이상 보이지 않거나 assistant가 사용할 수 없다고 말합니다.
원인
assistant의 XMemo connection을 refresh해야 하거나 다른 account에 로그인했을 수 있습니다.
조치:
assistant의 connected-app settings에서 XMemo를 disconnect한 후 다시 연결하고 새 chat을 시작합니다.
확인
assistant에게 XMemo가 연결되었는지 보여 달라고 요청한 다음 무엇이든 저장하기 전에 무해한 read를 시도합니다.
안전:
chat이나 Support request에 secret account detail 또는 private memory를 붙여 넣지 않습니다.
AI assistant에서 어떤 XMemo connection을 사용해야 하나요?
증상
assistant settings에 어떤 XMemo page나 connection을 넣어야 하는지 모르겠습니다.
원인
guided setup page와 assistant connection은 서로 다른 목적을 가지며 hosted와 self-managed setup은 서로 다른 boundary를 가집니다.
조치:
hosted service라면 https://xmemo.dev/product/docs에서 시작해 assistant에 표시된 connection link를 따릅니다. 조직에서 다른 setup page를 제공했다면 Support에 문의합니다.
확인
personal detail을 저장하기 전에 page가 의도한 XMemo account와 hosted service를 사용하는지 확인합니다.
안전:
local development address를 사용하거나 public chat에 private credential을 붙여 넣지 않습니다.
AI assistant가 여전히 XMemo에 연결되지 않으면 어떻게 해야 하나요?
증상
connection 단계를 다시 시도했지만 assistant가 여전히 XMemo를 사용할 수 없습니다.
원인
문제가 assistant app, account 또는 public instruction으로는 확인할 수 없는 stale connection에 있을 수 있습니다.
조치:
assistant name, 대략적인 time과 본 내용을 간단히 적어 Support에 문의하고 redacted detail만 포함합니다.
확인
private memory나 account secret을 보내지 않고 report를 재현할 수 있는지 확인합니다.
안전:
sign-in detail, one-time code, cookie 또는 private memory text를 절대 보내지 않습니다.

Developer 및 integrator용

XMemo를 통합하는 사람을 위한 connection, account boundary, client 및 운영 답변입니다.

OAuth가 실패하거나 consent window가 끝나지 않습니다.
증상
client에 401이 표시되거나 OAuth browser가 열리지 않거나 consent가 usable connection 없이 client로 돌아옵니다.
원인
hosted grant가 stale이거나 browser handoff가 차단되었거나 client가 이전 server registration을 사용하고 있을 수 있습니다.
조치:
host app에서 XMemo MCP server를 sign out하고 hosted MCP URL을 다시 연결한 뒤 memory:read와 memory:write를 다시 승인합니다.
확인
client가 active authorization을 보고할 때까지 다시 연결한 다음 memory를 기록하기 전에 무해한 recall을 실행합니다.
안전:
stale OAuth session을 우회하려고 OAuth client에서 XMEMO_KEY로 전환하지 않습니다.
request가 403 Forbidden을 반환합니다.
증상
server에 도달하고 credential도 인식되지만 요청한 project, tool 또는 memory action이 거부됩니다.
원인
grant에 필요한 scope가 없거나 account가 선택한 project boundary 밖에 있거나 resource가 다른 tenant에 속합니다.
조치:
선택한 account와 project를 확인하고 OAuth를 다시 연결하거나 필요한 scope를 요청한 뒤 resource를 바꾸지 않고 같은 operation을 재시도합니다.
확인
write 또는 delete operation을 다시 시도하기 전에 의도한 project에서 read-only request가 성공하는지 확인합니다.
안전:
403을 없애려고 scope를 넓히거나 다른 사용자의 token을 복사하지 않습니다.
MCP server는 연결되지만 tool이 나타나지 않습니다.
증상
host에는 connected server가 표시되지만 tools/list가 비어 있거나 XMemo tool이 model tool picker에서 사라집니다.
원인
client가 discovery를 refresh하지 않았거나 잘못된 MCP profile을 사용하거나 stale URL 또는 registration에 연결되었을 수 있습니다.
조치:
server를 다시 연결하고 client가 지원되는 MCP profile을 사용하는지 확인한 다음 credential을 변경하기 전에 tool discovery를 다시 실행합니다.
확인
write 또는 marketplace demonstration을 시작하기 전에 remember, recall, search_memory가 적어도 나타나는지 확인합니다.
안전:
screenshot, Support ticket 또는 marketplace review note에 bearer token을 붙여 넣지 않습니다.
direct MCP client가 token missing이라고 말합니다.
증상
machine 어딘가에 variable을 추가했는데도 direct client가 XMEMO_KEY가 unset, empty 또는 unavailable이라고 보고합니다.
원인
client process가 environment를 상속하지 않았거나 다른 shell에 variable을 추가했거나 config가 대신 secret-store reference를 요구할 수 있습니다.
조치:
local environment 또는 secret store에 XMEMO_KEY를 설정하고 client를 restart하며 attribution이 중요할 때 XMEMO_AGENT_INSTANCE_ID를 안정적으로 유지합니다.
확인
variable value는 출력하지 말고 presence metadata만 확인한 뒤 client를 restart하여 무해한 authenticated recall을 확인합니다.
안전:
실제 token은 git에 commit한 config file 밖에 두고 public example에서는 environment variable만 참조합니다.
restart할 때마다 agent instance ID가 바뀝니다.
증상
restart 또는 redeploy 후 같은 local runner가 여러 agent로 보이거나 recall이 여러 instance로 나뉩니다.
원인
XMEMO_AGENT_INSTANCE_ID가 runner의 local secret 또는 environment configuration에 저장되지 않고 process start 때 생성됩니다.
조치:
runner마다 non-secret instance label 하나를 생성하고 git 밖에 저장한 뒤 모든 direct MCP connection에 보냅니다.
확인
runner를 두 번 restart하고 credential을 노출하지 않은 채 source attribution에 같은 instance label이 나타나는지 확인합니다.
안전:
instance label은 attribution metadata이지 authorization credential이 아니며 access는 account와 token boundary가 여전히 제어합니다.
recall이 빈 memory를 반환합니다.
증상
user가 context를 저장했는데 recall 또는 search는 성공하고 관련 record를 반환하지 않습니다.
원인
read가 write와 다른 account, project, scope, agent boundary 또는 memory type을 사용하거나 test record가 commit되지 않았을 수 있습니다.
조치:
synthetic test memory를 만들고 Memory Console에서 path와 memory type을 확인한 다음 같은 account 또는 tenant boundary에서 recall을 다시 시도합니다.
확인
같은 project와 scope로 새 synthetic record를 다시 읽고 의도한 delete path를 통해 제거합니다.
안전:
synthetic review data를 사용하고 marketplace demo에 private customer memory를 사용하지 않습니다.
recall 또는 write가 잘못된 project scope를 사용합니다.
증상
record가 한 project에서는 보이지만 다른 project에서는 보이지 않거나 operator가 의도하지 않은 project에 write가 나타납니다.
원인
client가 다른 environment의 project identifier를 재사용했거나 project boundary를 생략했거나 stale account session을 유지하고 있습니다.
조치:
의도한 account와 project를 명시적으로 선택하고 client context를 refresh한 뒤 synthetic record로 operation을 반복합니다.
확인
Memory Console에서 record의 project와 source attribution을 확인한 다음 관련 없는 project가 읽을 수 없는지 검증합니다.
안전:
scope mismatch를 해결하려고 더 넓은 token을 부여하거나 project 사이에서 data를 복사하지 않습니다.
같은 memory가 두 번 저장됩니다.
증상
retry 또는 reconnect가 durable memory 하나 대신 duplicate record를 만듭니다.
원인
client가 idempotency boundary 없이 timeout 후 retry했거나 첫 response를 확인하기 전에 capture flow가 write했을 수 있습니다.
조치:
먼저 기존 record와 source attribution을 확인한 뒤 client retry policy 또는 안정적인 idempotency key를 사용해 다시 write합니다.
확인
같은 controlled capture를 한 번 반복해 새 record 하나와 readback 하나만 생기고 새 record 두 개는 생기지 않는지 확인합니다.
안전:
대상 record와 account scope를 확인하기 전에는 일치하는 memory를 일괄 삭제하지 않습니다.
recall context가 너무 크거나 작습니다.
증상
agent가 관련 없는 context를 받거나 필요한 decision을 놓치거나 host의 유용한 context budget을 초과합니다.
원인
query가 너무 넓거나 scope 또는 time window가 없거나 caller가 task에 맞지 않는 result limit을 요청했을 수 있습니다.
조치:
project, agent, time 또는 topic boundary로 query를 좁히고 limit을 늘리기 전에 작고 관련 있는 set을 요청합니다.
확인
반환된 context를 대상 question과 비교하고 포함된 모든 record가 authorized이며 유용한지 확인합니다.
안전:
context window를 채우려고 scope를 넓히거나 관련 없는 memory를 export하지 않습니다.
memory를 어떻게 삭제하거나 export하나요?
증상
operator가 record를 제거하거나 forget action을 확인하거나 account-scoped export를 받아야 합니다.
원인
delete, recoverable forget, permanent delete와 export는 서로 다른 confirmation 및 recovery semantics를 가진 별도 workflow입니다.
조치:
먼저 Memory Console 또는 account workflow를 사용하고 self-service path가 없으면 request가 account 범위에 머물도록 Support에 문의합니다.
확인
forget 또는 delete 후 record reference로 검색해 기대한 recoverable 또는 permanent state를 확인하고 export가 account scope만 포함하는지 확인합니다.
안전:
export와 Support bundle에서 token hash, API key, session secret, provider credential 및 관련 없는 tenant data를 제외합니다.
client 연결을 끊은 뒤 access를 어떻게 revoke하나요?
증상
client를 local에서 제거했지만 operator가 OAuth grant를 무효화하거나 direct credential을 rotate해야 합니다.
원인
client config를 disconnect해도 server-side grant가 revoke되거나 direct token이 rotate되는 것은 아닙니다.
조치:
account security 또는 connected-client control을 열어 해당 OAuth grant를 revoke하고 노출되었거나 더 이상 신뢰하지 않는 direct credential은 rotate합니다.
확인
이전 connection으로 authenticated read를 retry해 거부되는지 확인한 다음 의도한 consent 또는 secret-store path로만 다시 연결합니다.
안전:
의도한 client 또는 grant만 revoke하고 access를 진단하는 동안 이전 token, OAuth code 또는 session detail을 publish하지 않습니다.
XMemo는 GA이거나 certified이거나 marketplace에 등록되어 있나요?
증상
listing 또는 document가 working configuration이 GA, certification 또는 marketplace approval을 증명하는지 묻습니다.
원인
configuration support, OAuth readiness, pilot evidence와 marketplace approval은 서로 다른 claim입니다.
조치:
구체적인 marketplace approval 또는 certification artifact가 없다면 public wording을 beta/config-supported로 취급합니다.
확인
status claim을 publish하기 전에 canonical client capability matrix와 명시된 approval artifact를 확인합니다.
안전:
working config만으로 GA, certified, stable 또는 listed status를 주장하지 않습니다.
어떤 URL을 사용해야 하나요?
증상
hosted user가 public quickstart, MCP endpoint 또는 self-hosted developer instruction 중 무엇을 따라야 할지 모릅니다.
원인
hosted onboarding과 self-hosted 또는 legacy deployment path는 서로 다른 URL, credential 및 data boundary를 가집니다.
조치:
hosted user는 MCP client에 https://xmemo.dev/mcp를 사용하고 guided setup에는 https://xmemo.dev/product/docs에서 시작합니다.
확인
연결하기 전에 host URL, authentication mode와 account boundary가 의도한 hosted 또는 self-hosted deployment와 일치하는지 확인합니다.
안전:
public hosted user의 첫 경로로 localhost, Supabase, Docker 또는 self-hosted Python instruction을 사용하지 않습니다.
memory가 잘못된 agent 또는 device 아래에 나타납니다.
증상
client update 또는 restart 후 memory가 다른 runner에 attribution되거나 device 사이에서 나뉘어 보입니다.
원인
client가 non-secret agent 또는 instance header를 바꾸었거나 shared credential을 여러 runner가 사용하고 있습니다.
조치:
non-secret agent/device header 또는 client profile을 확인한 다음 local instance ID를 다시 생성하지 말고 persist합니다.
확인
의도한 runner에서 synthetic record 하나를 write하고 reconnect 후에도 source attribution이 안정적인지 확인합니다.
안전:
attribution label은 source review를 돕지만 security boundary가 아니며 access는 account credential이 여전히 결정합니다.
단계를 따라도 여전히 연결할 수 없습니다.
증상
client-specific OAuth 또는 direct-secret path를 다시 시도했지만 connection을 사용할 수 없습니다.
원인
남은 문제가 client-specific, account-specific이거나 local docs가 확인할 수 없는 stale registration 또는 environment boundary 때문일 수 있습니다.
조치:
client name, config path, 대략적인 timestamp와 OAuth 또는 XMEMO_KEY 사용 여부를 적어 Support를 엽니다.
확인
Support report에 재현 가능한 symptom과 redacted metadata가 들어 있는지 확인한 뒤 account-scoped diagnosis를 기다립니다.
안전:
redacted diagnostic만 공유하고 bearer token, OAuth code, cookie 또는 customer memory content는 절대 보내지 않습니다.

출처: FAQ / 문제 해결