# 워크스페이스
> **이 장에서 배우는 것**
> 워크스페이스가 무엇의 경계인지, 그리고 어떻게 나눠야 하는지.
## 모든 것이 그 아래에 있습니다
```
워크스페이스
├─ 대화(스레드)
├─ 에이전트
├─ 연결한 도구
├─ 등록한 시스템
├─ 멤버와 권한
└─ 사용량과 크레딧
```
주소는 `/w/<핸들>` 형태입니다. 핸들은 만들 때 정하는 짧은 이름입니다.
## 경계입니다
이게 핵심 성질입니다.
> **워크스페이스끼리는 서로의 대화나 자료를 볼 수 없습니다.**
한 계정이 여러 워크스페이스에 속할 수 있지만, 각 워크스페이스는 독립적입니다.
```mermaid
graph TD
U["내 계정"] --> W1["워크스페이스 A
영업팀"]
U --> W2["워크스페이스 B
개발팀"]
W1 -.->|"서로 못 봄"| W2
```
워크스페이스 이름·핸들을 비롯한 기본 설정이 여기 있습니다.
## 어떻게 나누나
여기가 첫 결정이고, 나중에 바꾸기 번거롭습니다.
### 기준 1 — 정보 경계
**가장 중요한 기준입니다.** "이 대화를 저 사람이 봐도 되나?"로 나눕니다.
| 나눠야 할 때 | 이유 |
|---|---|
| 인사 정보를 다루는 팀 | 다른 팀이 보면 안 됨 |
| 고객사별 프로젝트 | 고객사 정보가 섞이면 안 됨 |
| 임원 전용 논의 | 접근 범위가 다름 |
### 기준 2 — 도구 경계
워크스페이스별로 **켜는 도구가 다릅니다.**
```
영업 워크스페이스 → CRM, 견적 시스템
개발 워크스페이스 → GitHub, 배포 도구
```
섞어두면 [도구가 너무 많아지는 문제](/guide/mcp-too-many-tools)가 생깁니다.
### 기준 3 — 비용 경계
사용량과 크레딧이 워크스페이스 단위입니다. **부서별로 비용을 나눠야 한다면**
워크스페이스도 나눠야 합니다.
## 너무 많이 나누면
반대 문제도 있습니다.
| 너무 적게 나누면 | 너무 많이 나누면 |
|---|---|
| 정보가 섞임 | 같은 도구를 여러 번 붙여야 |
| 도구가 너무 많아짐 | 같은 에이전트를 여러 번 만들어야 |
| 비용 구분이 안 됨 | 어디서 뭘 했는지 찾기 어려움 |
**시작은 적게, 필요하면 나누는 쪽**을 권합니다. 합치는 것보다 나누는 게 쉽습니다.
## 실무 예시
| 조직 | 구성 |
|---|---|
| 10명 스타트업 | 워크스페이스 1개 |
| 50명 회사 | 부서별 3~5개 |
| 고객사 프로젝트 다수 | 고객사별 + 내부용 1개 |
## 핸들 정하기
핸들은 **주소가 됩니다.**
```
핸들: sales → /w/sales
```
| 좋은 핸들 | 피할 것 |
|---|---|
| 짧고 기억하기 쉬움 | 너무 긺 |
| 조직에서 통용되는 말 | 임시 이름 |
| 영문 소문자 | 나중에 바꾸면 링크가 깨짐 |
## 자주 하는 질문
### "나중에 워크스페이스를 합칠 수 있나요?"
대화와 에이전트를 옮기는 것은 간단하지 않습니다. **처음에 적게 나누고 필요할 때
늘리는** 순서가 안전합니다.
### "한 사람이 여러 워크스페이스에 속할 수 있나요?"
됩니다. 그리고 **워크스페이스마다 역할이 다를 수 있습니다** — A에서는 관리자,
B에서는 일반 멤버.
### "워크스페이스를 옮겨다니려면?"
화면 왼쪽 위의 워크스페이스 이름을 누르면 전환됩니다.
---
## 확인
**1. 워크스페이스를 나누는 가장 중요한 기준은?**
답
**정보 경계**입니다. "이 대화를 저 사람이 봐도 되나?"로 나눕니다. 워크스페이스
끼리는 서로의 대화와 자료를 볼 수 없기 때문에 이것이 실질적인 격리 수단입니다.
**2. 너무 많이 나누면 무엇이 문제입니까?**
답
**같은 도구와 에이전트를 여러 번 만들어야** 하고, 어디서 무엇을 했는지 찾기
어려워집니다. 시작은 적게, 필요하면 나누는 쪽이 낫습니다 — 합치는 것보다 나누는
게 쉽습니다.
**3. 핸들을 정할 때 주의할 점은?**
답
**핸들이 곧 주소**(`/w/<핸들>`)라서 나중에 바꾸면 공유해둔 링크가 깨집니다. 짧고
조직에서 통용되는 이름으로 정하세요.
---
일 하나가 대화 하나입니다 → [스레드](/guide/cn-thread)