tags: [workspace, team, project, database, slack, ideas, access-control, agent, multi-workspace]

# workspace-team-project 계층 재정의 아이디어

상위 원칙:
- [0_VALUE Writing Principles](../../../../0_VALUE/02_Governance/writing-principles.md)
- [Workspace-Team-Project 도메인 모델](../../book/300_architecture/390_workspace_team_project_%EB%8F%84%EB%A9%94%EC%9D%B8_%EB%AA%A8%EB%8D%B8.md)
- [database/tables.md](../../book/300_architecture/database/tables.md)

## 문제 인식
- 현재 운영 DB는 `team`이 상위 조직처럼 해석되는 구간과, 실제 실행 조직처럼 해석되는 구간이 섞여 있습니다.
- 그 결과 `Company-X`처럼 상위 조직을 `team`으로 두고, `xvaluelab` 같은 실제 프로젝트를 채널 메타데이터나 임시 필드로만 보강하는 상태가 생깁니다.
- Slack 쪽에서도 `slack_workspace`는 실제 워크스페이스인데, 내부 도메인 모델은 이를 `team` 중심으로 붙이고 있어 개념 충돌이 발생합니다.

## 아이디어
- 상위 조직 단위는 `workspace`로 고정합니다.
- `team`은 `workspace` 소속 실행 조직으로 고정합니다.
- `project`는 팀이 담당하는 대상/업무 단위로 분리합니다.
- 따라서 `Company-X`는 workspace, `Company-X` 내부 실행 조직은 team, `xvaluelab`은 그 팀이 맡는 project로 해석하는 방향을 기본 모델로 삼을 수 있습니다.

## 기대 효과
- 조직 단위와 프로젝트 단위가 분리되어 Slack 채널/문서/권한 해석이 더 명확해질 수 있습니다.
- `slack_workspace`, `slack_channel`, `team_document` 같은 테이블이 어떤 조직 단위를 참조하는지 더 선명하게 재설계할 수 있습니다.
- 현재처럼 `team` 하나에 회사, 실행 조직, 프로젝트 의미가 겹치는 상태를 줄일 수 있습니다.

## 검증이 필요한 이유
- 현재 코드와 DB는 `team_id`에 강하게 묶여 있어, 개념만 바꾸고 바로 적용하면 조회/권한/시드/집계 경로가 깨질 수 있습니다.
- 특히 `user`, `robeing`, `slack_workspace`, `team_document`, 관리자 집계 경로는 영향 범위가 넓습니다.
- 따라서 이 아이디어는 즉시 치환안이 아니라, 병행 운영 가능한 목표 모델로 먼저 검증돼야 합니다.

## 아이디어 확장: 접근 권한·에이전트·멀티 워크스페이스 (260322 추가)

### 문제 인식 (260322)
- RAG 문서(`team_document`)에 접근 권한 개념이 없습니다. 누가 어떤 문서를 볼 수 있는지 제어 불가합니다.
- 서버 에이전트(23서버 클로드, 24서버 클로드, Codex, Cursor)가 DB에 등록되어 있지 않아 권한 주체로 식별할 수 없습니다.
- 로빙(`Main Robeing`)은 Company-X 팀에 소속되어 있지만, 에이전트들은 OS 레벨 직접 접근만 하고 있습니다.
- MD front matter에도 접근 권한 필드가 없습니다.

### 접근 권한 아이디어
- workspace 소속이면 하위 team/project 문서 전체 접근 가능 (상위 권한 상속)
- team 소속이면 해당 team 문서만 접근 (하위 격리)
- 사용자는 여러 workspace, 여러 team에 중복 소속 가능 (M:N)
- 에이전트도 user와 동일 레벨로 team에 소속

### 트리 구조

```
workspace (Company-X)
├── team (투자팀)
│   ├── user (김종태)
│   ├── agent (로빙)
│   └── project (xvaluelab)
├── team (운영팀)
│   ├── user (문정현)
│   └── project (X-COURSE)
└── team (인프라)
    ├── agent (23서버 클로드)
    ├── agent (24서버 클로드)
    └── project (RAG 파이프라인)

workspace (Robeing)
├── team (코어)
│   ├── user (김종태)
│   └── agent (로빙)
└── ...
```

### 멀티 워크스페이스
- 현재 DB에 이미 Company-X, Robeing(→ GooseFarmInvesting) 2개 company가 존재합니다.
- `company`를 `workspace`로 재정의하면 자연스럽게 멀티 워크스페이스가 됩니다.
- 워크스페이스 이름/slug: `GooseFarmInvesting` / `goosefarminvesting`
- 김종태는 3개 계정(jtkim@, goeun2dc@, info@ro-being.com) → 1개로 통합 후 양쪽 workspace 소속
- Jo Lee(조리)는 GooseFarmInvesting 소속

### 에이전트 등록
- 23서버 에이전트(Claude Code, Codex, Cursor), 24서버 에이전트를 `user` 테이블 또는 별도 `agent` 테이블에 등록해야 합니다.
- 에이전트가 team에 소속되면 해당 team의 문서에 접근 가능합니다.
- CompanyX workspace에 소속된 에이전트만 CompanyX 문서에 접근할 수 있습니다.

### 프론트메타 반영
- MD front matter에 `access` 필드 추가: `access: [companyx-team, robeing]`
- 이 필드는 선언적 메타데이터(표시용)이며, 실제 enforcement는 API 레이어에서 workspace/team 소속 검증으로 합니다.

## 설계 검증 피드백 (260322)

### 강점: "에이전트의 시민권 획득"
- `user.is_agent` 플래그로 에이전트를 user 모델에 통합하면, 권한 검사 미들웨어에서 "사람인가 AI인가"를 분기할 필요 없이 동일한 보안 인터페이스를 적용할 수 있습니다.
- 향후 Goose Council의 CEU(Connection Event Unit)들이 멀티 에이전트 환경에서 권한을 주고받는 시나리오로 확장할 때, 별도 권한 체계를 중복 설계할 필요가 없습니다.
- 에이전트도 팀의 일원으로서 상속·배제 규칙을 동일하게 적용받는 구조이므로 도메인이 깔끔합니다.

### 우려: "복합 권한의 늪"
- workspace > team > project 계층에서 **에이전트가 생성한 프로젝트**에 대한 팀원의 접근 권한, **팀 단위 권한 vs 개별 에이전트 권한** 충돌 시 우선순위(Enforcement Rule)가 도메인 모델에서 정교하게 정의되어야 합니다.
- 예외 케이스: 퇴사한 유저가 만든 에이전트의 권한 처리, 에이전트가 여러 workspace에 걸쳐 작업할 때의 데이터 격리 등.

### 제안: "상태(State) 중심의 검증"
- Phase 1에서 DB 스키마를 건드리기 전에, 실제 API 호출 시점에서 `context.user.active_workspace_id`와 `target.access_field`를 비교하는 간단한 시뮬레이션을 먼저 돌려야 합니다.
- 권한 모델은 머리로 그릴 때보다 실제 데이터가 얽힐 때 예외 케이스가 많이 발생하기 때문입니다.

## Goose Council CEU와의 연결 (260322)

### 맥락
- [TheGooseCouncil](../../../../TheGooseCouncil/DOCS/README.md)은 멀티 에이전트 오케스트레이션 시스템입니다.
- CEU(Connection Event Unit)는 "접속이라는 사건을 통해 존재를 생성·확정하는 최소 지능 단위"입니다.
- CEU는 개인/팀/조합 단위로 구분되며, 접속 적합성과 재조합 능력으로 가치가 측정됩니다.

### workspace-team-project에서의 CEU 해석
- **CEU = agent(user.is_agent=true)**로 매핑됩니다.
- CEU도 workspace/team에 소속되어 문서 접근 권한을 상속받습니다.
- CEU 팀(팀 접속 단위) = 로빙 시스템의 `team`에 자연스럽게 대응합니다.
- CEU의 라이프사이클(선택→모집→수행→평가→해산)은 `workspace_member` 소속 추가/제거로 표현 가능합니다.

### Goose Council 거버넌스와의 정합
- [Governance_and_Delegation_Principles](../../../../TheGooseCouncil/DOCS/00_Philosophy/01_PRINCIPLES/Governance_and_Delegation_Principles.md): "책임은 인간이, 운영은 접속 단위에 위임"
- 이 원칙은 workspace OWNER(인간)가 책임을 보유하고, agent(CEU)에 운영을 위임하는 구조와 일치합니다.
- 최소 통제 권한(긴급 정지, 정책 롤백, 진화 루프 중단)도 workspace OWNER/ADMIN role로 구현 가능합니다.

### 확장 시나리오
- CEU가 여러 workspace를 넘나들며 작업하는 경우: `workspace_member` M:N으로 처리
- CEU 간 권한 위임: team 내 role 변경으로 처리 (MEMBER → ADMIN)
- CEU 해산: `workspace_member` is_active=false로 소프트 삭제

## 이 문서를 닫기 위해 필요한 질문
- 현재 `team`이 상위 조직처럼 쓰이는 경로와 실행 조직처럼 쓰이는 경로는 각각 어디인가
- `workspace`, `team`, `project`를 도입할 때 기존 `team_id` FK를 어떤 순서로 분리할 것인가
- Slack 채널은 workspace 공용 채널과 project 전용 채널을 어떤 컬럼 조합으로 구분할 것인가
- 에이전트를 `user` 테이블에 넣을지 별도 테이블로 분리할지
- 접근 권한은 workspace 단위로 충분한지, team/project 단위까지 필요한지

## 이 문서에서 아직 확정하지 않는 것
- 새 테이블 이름과 최종 FK 이름
- 기존 `company`, `team`, `workspace_member`와의 정확한 통합 방식
- 데이터 이관 일정과 서비스별 전환 순서
- 에이전트 식별 방식 (user.is_agent 플래그 vs 별도 agent 테이블)
- 접근 권한의 세분화 수준 (읽기/쓰기/관리 구분 여부)

## 관련 문서
- [Workspace-Team-Project 도메인 모델](../../book/300_architecture/390_workspace_team_project_%EB%8F%84%EB%A9%94%EC%9D%B8_%EB%AA%A8%EB%8D%B8.md)
- [workspace-team-project 계층 재정의 영향범위 리서치](../research/260316_workspace_team_project_%EA%B3%84%EC%B8%B5_%EC%9E%AC%EC%A0%95%EC%9D%98_%EC%98%81%ED%96%A5%EB%B2%94%EC%9C%84_%EB%A6%AC%EC%84%9C%EC%B9%98.md)
- [workspace-team-project 계층 재정의 전환계획](../plans/260316_workspace_team_project_%EA%B3%84%EC%B8%B5_%EC%9E%AC%EC%A0%95%EC%9D%98_%EC%A0%84%ED%99%98%EA%B3%84%ED%9A%8D.md)
- [database/tables.md](../../book/300_architecture/database/tables.md)
- [380_authentication_system.md](../../book/300_architecture/380_authentication_system.md)
- [journey/README.md](../README.md)
