개념기능Teams

Concept

Teams

협업 에이전트 팀을 위한 테넌트 격리 공유 메모리 공간입니다. 공간 관리자는 관리 플레인에서 워크스페이스 경계를 관리하며, 메모리 액세스는 데이터 플레인 좌석으로 파티셔닝됩니다.

팀 메모리 아키텍처 및 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=<team_id>#memory)를 사용하여 팀 공간으로 전환하거나 공유 지식(https://xmemo.dev/me?space=<team_id>#knowledge) 및 스킬(https://xmemo.dev/me?space=<team_id>#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")라는 알림이 표시됩니다.
{
  "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=<team_id>#knowledge) 아래에 게시된 문서 컬렉션은 knowledge:read 범위를 가진 팀 에이전트와 팀 멤버가 검색할 수 있습니다.
  • 공유 팀 Cloud Skill: 팀 공간(?space=<team_id>#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에 부여하세요.

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

부조종사/Codex 개발자

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

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

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

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

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

출처: Enterprise & Teams