# Teams 협업 에이전트 팀을 위한 테넌트 격리 공유 메모리 공간입니다. 공간 관리자는 관리 플레인에서 워크스페이스 경계를 관리하며, 메모리 액세스는 데이터 플레인 좌석으로 파티셔닝됩니다. - Canonical: https://docs.xmemo.dev/ko/docs/capabilities/teams - Locale: ko-KR - Content-Locale: ko-KR - Canonical-Content-Digest: 683a48f04a5f54654f8d734721bc2af8e92c80d4945ca6276756bd086e701f4a - Edition-Digest: 4d360c158794c233437ab0cd30beab1fd48b1bc56eb716822472bac1dbf37e92 - Source-Revision: sha256:097bdf026d1d9352be562c7452c3f2d43aa7b273daa1d8428329f4a76bcb7efe ## 팀 메모리 아키텍처 및 Preview 제공 현황 Teams는 Business 플랜의 기능입니다. 프로덕션 환경에서는 Business 플랜이 출시될 때까지 팀 생성이 기본적으로 비활성화되며, 현재 런타임은 승인되지 않은 요청에 대해 거부 전용(deny-only) 모드로 작동합니다. 공간 관리자는 워크스페이스 관리 플레인에서 워크스페이스 경계와 테넌트 프로비저닝을 관리하고, 에이전트 메모리 액세스는 테넌트 격리 암호화 공간 바인딩이 적용된 데이터 플레인 좌석으로 제어됩니다. - Preview 상태: https://xmemo.dev/me#teams 의 Memory Console에서 Team Management에 Preview 배지가 표시됩니다. - 콘솔 워크스페이스 컨텍스트: Team Management 헤더에 "One workspace for members and invitations."라는 안내가 표시되며, 관리자는 활성 멤버 및 대기 중인 초대를 관리합니다. - 공간 탐색: 협업자는 명시적 공간 매개변수(https://xmemo.dev/me?space=#memory)를 사용하여 팀 공간으로 전환하거나 공유 지식(https://xmemo.dev/me?space=#knowledge) 및 스킬(https://xmemo.dev/me?space=#skills)을 검사합니다. - 협업 격리: 팀 워크스페이스는 개별 사용자의 개인 메모리 공간(/me#memory)과 격리된 다중 에이전트 공유 컨텍스트를 제공합니다. ## 팀 자격 요건, 생성 요구 사항 및 구독 경계 팀을 생성하려면 2개 이상의 구매된 좌석이 포함된 이용 자격이 있는 Business 구독이 필요합니다. 현재 Business 플랜은 구매할 수 없으므로 일반 계정의 셀프 서비스 팀 생성은 기본적으로 비활성화되어 있습니다. 공개 문서에서는 좌석 구매를 가능한 작업으로 안내하지 않습니다. - 생성 정책: Business 플랜이 출시될 때까지 프로덕션 환경에서 셀프 서비스 팀 생성은 기본적으로 비활성화됩니다. - 자격 요건: 콘솔은 팀 생성을 열기 전에 조직 자격을 확인합니다. 자격이 없는 경우 인터페이스에 "A Business subscription with at least 2 purchased seats is required to create a team."이라고 표시됩니다. - Preview 제한 사유: 계정에 허용 목록 승인이 없는 경우 콘솔에 "Team creation is currently limited to preview accounts."라고 표시됩니다. - 일반 미제공 사유: 프로비저닝되지 않은 계정의 경우 콘솔에 "Team creation is not available for this account yet."라고 표시됩니다. - 상용 상태: Business 구독은 현재 구매할 수 없습니다. 셀프 서비스 좌석 추가 및 플랜 업그레이드는 비활성화되어 있습니다. - 생성 모달: 허용 목록에 등록된 프리뷰 계정에서 Create team을 클릭하면 "Enter your company name. This will become the team name inside XMemo."라는 모달이 열리며, 입력 필드 "Company name"(플레이스홀더 "e.g. Acme Corp")이 표시됩니다. ## 4단계 RBAC 계층 및 자격 증명 발급 상한 팀 멤버십 권한과 자격 증명 발급 상한은 개인 콘솔 서비스에 의해 적용됩니다. owner, admin 또는 member 역할을 가진 활성 멤버는 역할별 범위 상한 내에서 팀 바인딩 자격 증명을 발급할 수 있으며, viewer는 엄격히 읽기 전용으로 토큰 발급이 거부됩니다. 아래 역할 스키마는 예시 요약입니다(API 응답 아님): - 역할 계층: 워크스페이스 역할을 권한 수준 및 토큰 발급 상한에 매핑하는 예시 요약(API 응답 아님)입니다. - owner (레벨 3): 청구 계정에 고정된 워크스페이스 생성자입니다. Admin, Member 또는 Viewer 역할을 가진 멤버를 초대할 수 있고, 비소유자 멤버 역할을 업데이트할 수 있으며(Admin, Member, Viewer 간), 비소유자 멤버를 제거하고 초대를 해지할 수 있습니다. 데이터 플레인 메모리, 원장, 지식 및 감사 범위(memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write 및 read:audit)를 포함한 모든 셀프 서비스 범위로 팀 바인딩 자격 증명을 발급할 수 있습니다. - admin (레벨 2): 워크스페이스 관리자입니다. Member 또는 Viewer 역할을 가진 멤버를 초대할 수 있고(Admin 초대는 불가), 비소유자 멤버를 제거하고 대기 중인 초대를 해지할 수 있으며, 멤버 역할을 수정할 수는 없습니다. 데이터 플레인 메모리, 원장, 지식 및 감사 범위(memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write 및 read:audit)를 포함한 모든 셀프 서비스 범위로 팀 바인딩 자격 증명을 발급할 수 있습니다. - member (레벨 1): 표준 워크스페이스 협업자입니다. 공유 팀 메모리 좌석, 팀 지식 항목 및 팀 Cloud Skill에 대한 읽기, 쓰기 및 복원 권한을 갖습니다. 팀 멤버 범위로 제한된 개인 팀 바인딩 자격 증명을 발급할 수 있으며(memory:read, memory:write, memory:restore, read:memories 및 write:memories), 상위 원장 또는 지식 범위를 발급할 수 없고 워크스페이스 멤버나 설정을 관리할 수 없습니다. - viewer (레벨 0): 콘솔에서의 읽기 전용 메모리 액세스(memory:read) 및 공유 지식 검사만 가능합니다. 자격 증명 발급이 허용되지 않으며 메모리 쓰기, 상태 업데이트 또는 팀 자격 증명 발급이 금지됩니다. - 단독 소유자 제약: 유일한 소유자가 팀 탈퇴를 시도하면 "Cannot leave team as the sole owner. Transfer ownership or delete the team first."(툴팁: "Sole owner must transfer ownership before leaving")라는 알림이 표시됩니다. ```json { "roles": { "owner": { "level": 3, "token_issuance_cap": [ "memory:read", "memory:write", "memory:restore", "read:memories", "write:memories", "delete:memories", "ledger:read", "ledger:write", "knowledge:read", "knowledge:write", "read:audit" ] }, "admin": { "level": 2, "token_issuance_cap": [ "memory:read", "memory:write", "memory:restore", "read:memories", "write:memories", "delete:memories", "ledger:read", "ledger:write", "knowledge:read", "knowledge:write", "read:audit" ] }, "member": { "level": 1, "token_issuance_cap": [ "memory:read", "memory:write", "memory:restore", "read:memories", "write:memories" ] }, "viewer": { "level": 0, "token_issuance_cap": [] } } } ``` ## 서버 권한 공간 바인딩 및 동적 해지 멀티 테넌트 격리는 암호화 공간 바인딩을 통해 서버 측에서 적용됩니다. 모든 팀 범위 API 키에는 클라이언트 요청으로 변경하거나 제공할 수 없는 불변 클레임(bound_team_id, membership_id_at_issue, space_binding_version)이 포함되어 있습니다. 일치하지 않는 팀을 대상으로 하는 요청은 HTTP 403 token_space_mismatch와 함께 즉시 fail closed 처리됩니다. - 권한 있는 공간 검증: 일치하지 않는 팀을 대상으로 하는 요청은 HTTP 403 token_space_mismatch로 즉시 실패 처리됩니다(fail closed). - 스푸핑 방지 보장: 위조되거나 충돌하는 팀 헤더가 포함된 요청은 데이터베이스 풀에 접근하기 전에 엣지에서 거부됩니다. - 에포크 기반 동적 해지: 멤버십 검증은 인증된 모든 요청에서 실시간 membership_id 에포크를 확인하므로, 제거된 멤버는 토큰 만료를 기다리지 않고 에포크 업데이트 즉시 액세스 권한을 잃게 됩니다. ## 좌석 관리, 초대 라이프사이클 및 수명 주기 경계 워크스페이스 용량은 활성 멤버십과 대기 중인 초대 전반에서 정성적으로 추적됩니다. 운영 경계는 초대 발급, 만료 및 콘솔 기능을 관리합니다: - 정성적 좌석 계산: 점유된 좌석은 활성 멤버와 만료되지 않은 대기 중인 초대로 구성되며, 콘솔 헤더에 "Seats {used} / {limit} used, {members} members, {pending} pending"으로 표시됩니다. - 기술적 초대 만료: 팀 초대는 발급 후 7일이 지나면 만료됩니다(teams_service.py:1184-1188). 만료된 초대는 예약을 해제하며 더 이상 점유된 좌석으로 계산되지 않습니다. - 좌석 용량 한도: 사용 가능한 모든 좌석이 점유되면 Add member 모달에 "Team seat limit reached. Upgrade or remove a member or pending invitation to send more invitations."라는 경고가 표시됩니다. - 초대 워크플로 상태: 초대를 보내면 보안이 유지되는 7일 토큰 링크가 생성됩니다. 그러나 현재 콘솔 인터페이스에는 초대 수락을 처리하는 기능이 없으며, 완전한 초대 수락 워크플로는 아직 콘솔에서 제공되지 않습니다. - 팀 삭제 및 소유권 이전 미지원: 콘솔은 팀 워크스페이스 삭제 또는 팀 소유권 이전을 위한 라우트나 UI 컨트롤을 제공하지 않습니다. 이러한 작업은 셀프 서비스로 이용할 수 없습니다. ## 공유 리소스, 에이전트 액세스 및 데이터 내보내기 경계 Teams 기능은 Model Context Protocol (MCP) 표면에 아무런 변경을 가하지 않습니다. 에이전트는 팀 바인딩 토큰으로 인증하기만 하면 표준 도구(remember, recall, recall_context, search 등)를 사용하여 공유 팀 메모리에 투명하게 접근할 수 있습니다. - 공유 팀 메모리: 팀 바인딩 토큰으로 인증한 연결된 에이전트는 공유 팀 메모리 공간에 읽기 및 쓰기를 수행합니다. - 공유 팀 지식: 팀 공간(?space=#knowledge) 아래에 게시된 문서 컬렉션은 knowledge:read 범위를 가진 팀 에이전트와 팀 멤버가 검색할 수 있습니다. - 공유 팀 Cloud Skill: 팀 공간(?space=#skills) 아래에서 생성된 절차적 스킬은 팀 역할에 의해 관리됩니다. 팀 공간에서 게시하면 PROPOSED 리비전이 생성되며 Admin 또는 Owner의 승인이 필요합니다. - 개인 프로젝트 경계: 프로젝트 워크스페이스는 현재 엄격히 개인 전용으로 유지됩니다(services/personal_console.py:7222). team_id로 프로젝트 워크스페이스를 생성하려는 시도는 백엔드에서 거부됩니다. - 데이터 내보내기 경계: 개인 데이터 내보내기(/api/v1/export 또는 /me#memory)는 정확히 개인 메모리만 내보내며 공유 팀 메모리 레코드는 엄격히 제외합니다. - 고정된 도구 표면: 팀 관리 도구(팀 생성 또는 초대 관리 등)는 MCP에 추가되지 않습니다. - 범용 클라이언트 호환성: Claude Desktop, ChatGPT, Codex, Cursor 및 Gemini CLI는 클라이언트 측 구성 변경 없이 팀 메모리와 상호 작용합니다. - 범위 지정 격리: 팀 공간에서 에이전트가 작성한 메모리에는 자동으로 팀 귀속이 찍히며 개인 사용자 메모리와 격리됩니다. ## 명시적 경계 및 미검증 기능 출시된 코드보다 문서가 앞서 나가는 현상을 방지하기 위해, 다음 기능은 명시적으로 제공되지 않으며 현재 릴리스의 범위에 포함되지 않습니다: - Business 플랜 필요: Teams 기능은 Business 플랜에 속하며 현재는 공개 구매가 불가능합니다. - 프로덕션 생성 비활성화: Business 플랜이 출시될 때까지 프로덕션 환경에서 일반 셀프 서비스 팀 생성은 비활성화됩니다. - 자동화된 SCIM / SAML 동기화 미지원: 엔터프라이즈 ID 공급자 디렉터리 동기화는 지원되지 않습니다. - 크로스 클라우드 또는 멀티 리전 데이터 복제 미지원: 팀 데이터는 단일 리전 테넌트 파티션에 상주합니다. - MCP 변형 도구 없음: MCP 도구 호출을 통해 팀을 생성, 수정 또는 삭제할 수 없습니다. - 거부 전용 런타임 모드: 현재 런타임은 Business 플랜이 출시될 때까지 승인되지 않은 요청에 대해 거부 전용 모드로 작동합니다. - 근거 없는 성능 지표 제외: 해지 및 쿼리 타이밍은 운영상의 런타임 속성이며 고정된 수치 보증이 아닙니다. ## 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를 유지하고 실행기가 시작할 때마다 이를 다시 생성하지 않는지 확인하세요.