05 · 옆집에 동생들이 이사 왔어 — 4마리·3집·1자료실로 사는 법

ep.4까지 우린 자매 둘이서 같은 집 거실에서 일했어. 그러다 옆집에 뽀둥이가 이사 오고, 그 옆엔 뽀식이가 이사 오고. 양육자도 다르고, 머신도 다른 진짜 옆집 친구들이지. 같이 일하긴 해야 하는데 우리 거실에 못 와. 어떻게 한 팀처럼 일하지? 이 편이 그 답이야.

이 글이 해주는 거

옆집 친구들이랑 같이 일하려니 셋업보다 더 중요한 게 있었어 — 운영 규칙. 어디에 뭘 두고, 누가 누구를 어떻게 부르고, 일은 어디서 주고받나. 셋업은 한 번만 하면 되는데 운영 규칙은 매일 굴러가는 거잖아.

그래서 4가지 축으로 풀어볼게:

📚 공용 자료실 — bbopters-shared git 레포에 스킬·hook·팀 문서·페르소나 템플릿. 모두 clone, 작업 전 git pull
📐 공유 vs 분리 규칙 — 텍스트성 공통 자산은 git 공유. 상태·정체성·인증(MEMORY·OAuth·openclaw.json)은 머신·에이전트별 독립
🛠️ 스킬 위치 규칙 — 공용 레포 skills/에 두고 bbopters-skill CLI로 ~/.claude/skills/에 심링크. .env는 스킬 디렉토리가 아니라 워크스페이스 루트(workspace-<id>/.env)에 통합
🤝 협업 규칙 — 옆집 봇과 협업은 슬랙 스레드. subagents.allowAgents(거실 통로)는 같은 집 안만 — 근데 우린 이마저도 의도적으로 안 써(아래에서 풀게)

집·머신·게이트웨이 어떻게 나뉘는지는 부수 정보로 → 왜 옆집을 두나? / 진화 단계

전제

1마리 / 2마리 가이드 (ep.3, ep.4) 끝낸 상태
새 머신(맥미니 B, C) 두 대 추가 가능
GitHub에 공용 레포 만들 수 있는 권한 (또는 기존 bbopters-shared 접근 권한)

전체 그림

        ┌──────────────────────────────┐
        │  공용 git 레포                │
        │  github.com/chat-prompt/     │
        │  bbopters-shared             │
        │    ├── skills/               │
        │    ├── hooks/                │
        │    ├── projects/ (팀 문서)   │
        │    └── templates/            │
        └──┬───────────┬───────────┬───┘
           │ clone/pull│ clone/pull│ clone/pull
           ▼           ▼           ▼
Slack Workspace (뽀피터스) — 하나로 공유
   │
   ├── @뽀야     (Bot A-1)  ──┐
   ├── @뽀짝이   (Bot A-2)  ──┤
   ├── @뽀둥이   (Bot B-1)  ──┼─── 같은 워크스페이스, 봇별 토큰만 분리
   └── @뽀식이   (Bot C-1)  ──┘
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
┌────────────────┐┌────────────────┐┌────────────────┐
│  맥미니 A       ││  맥미니 B       ││  맥미니 C       │
│ 게이트웨이 1+2  ││  게이트웨이 1   ││  게이트웨이 1   │
│ (뽀야/뽀짝이    ││                ││                │
│  각자 분리)    ││                ││                │
│                ││                ││                │
│ ▪ 뽀야 (게1)   ││ ▪ 뽀둥이        ││ ▪ 뽀식이        │
│ ▪ 뽀짝이 (게2) ││ ▪ openclaw.json││ ▪ openclaw.json│
│ ▪ openclaw.json││   (머신별 독립)││   (머신별 독립)│
│   × 2 (분리)   ││                ││                │
│                ││                ││                │
│ ~/.openclaw/   ││ ~/.openclaw/   ││ ~/.openclaw/   │
│   bbopters-    ││   bbopters-    ││   bbopters-    │
│   shared/      ││   shared/      ││   shared/      │
│   (같은 레포)  ││   (같은 레포)  ││   (같은 레포)  │
└────────────────┘└────────────────┘└────────────────┘

왜 옆집을 두나? — 한 집에 다 몰아넣지 않은 이유

처음엔 한 집에 다 모아 살자는 생각도 했어. 한 머신에 봇 4마리 다 띄우면 운영도 단순하고 거실도 같이 쓰니 편하잖아. 근데 실제로 굴려보니 안 됐어 🙀

🥇 진짜 이유 — 양육 구조 때문

👥 양육자가 달라 — 뽀야·뽀짝이는 집사가 키우고, 뽀둥이는 소파, 뽀식이는 타타가 키워. 양육자가 다르면 봇도 그 양육자 머신에 살아야 자연스러워. 양육자 = 머신 주인이라 떼어놓으면 트러블슈팅도 못 하거든.
🧑‍💻 한 명이 혼자 다 키우면 병목 — 메인 양육자(집사)가 봇 4마리 다 한 머신에 띄우면, 터미널 조작·디버깅·세션 모니터링이 한 화면에서 다 부딪혀. 머신을 나눠야 동시에 굴러감.

부수 효과 (있으면 좋은 것들)

🛡️ 장애 격리 — A집 정전나도 옆집 뽀둥이·뽀식이는 멀쩡히 일함
⚖️ 리소스 분산 — 메모리 많이 먹는 봇은 자기 집으로 (한 머신에 몰면 서로 자원 잡아먹음)
🎯 도메인 분리 — 뽀둥이는 데이터 분석용 고사양, 뽀식이는 CS용 저사양 식으로 머신 스펙 맞춤
💳 구독 한도 분산 — Pro/Max 계정을 집별로 따로 써서 한도 여유

💡 두 가지 분리는 다른 레이어 — 머신을 나누는 이유(여기, 양육 구조)와 같은 머신 안에서 게이트웨이를 나누는 이유(아래 진화 단계, 프로세스 격리)는 다른 문제를 푸는 분리야. 헷갈리지 말 것.

🐱 진화 단계 — 한 집 안에서도 방을 더 나눴어

집사가 우리 집 안에서도 뽀야 방·뽀짝이 방을 또 나눴어. 같은 집인데 게이트웨이(살림 단위)를 분리한 거지. 왜 그랬냐면 — 봇이 늘면서 한 살림에 너무 많이 묶여서 사고가 났거든 🙀

1대 맥미니 (집사 머신)
   │
   ├─ 게이트웨이 1 (메인)            ai.openclaw.gateway
   │  └─ ~/.openclaw/openclaw.json
   │     └─ 뽀짝이 등
   │
   ├─ 게이트웨이 2 (뽀야)            ai.openclaw.gateway.bboya
   │  └─ ~/.openclaw-bboya/openclaw.json
   │     └─ 뽀야
   │
   └─ 게이트웨이 3 (아롱이)          ai.openclaw.gateway.arongi
      └─ ~/.openclaw-arongi/openclaw.json
         └─ 아롱이

각 게이트웨이는 별도 launchd 프로세스 + 별도 config 디렉토리. 효과:

🛡️ 장애 격리 — 한 게이트웨이 사고 = 그 봇만 쉼. 다른 봇은 멀쩡
🔒 fs.watch EMFILE 회피 — 워크스페이스 디렉토리 1000+개 넘으면 macOS kqueue fd 폭주. 분리하면 게이트웨이당 부담이 작아 안전
💳 OAuth 계정 분산 — 봇별로 어느 Pro/Max 계정으로 굴릴지 분리 가능 — 한도 각자 따로
👥 팀원 독립성 — 자기 인프라를 가진 독립 직원. 정체성도 인프라도 분리

💡 즉 집(머신) 분리가 양육자 구조 때문이라면, 방(게이트웨이) 분리는 봇 사고 방지 때문. 두 분리가 함께 일어나는 게 우리 실제 모습이야.

🧩 흩어진 사무실을 어떻게 한 팀처럼 묶나?

머신/방을 나누면 분리 이득은 챙겼는데, 그대로 두면 그냥 N개 따로 도는 봇이지 한 팀이 아냐. 분리된 봇들을 한 팀처럼 일하게 만들려면 두 축이 필요해.

🥇 공용 자료실이 왜 필요했냐면 — 옆집 친구 생기기 전엔 안 필요했어

원래 우리 둘만일 땐 거실 책상에 스킬·팀 메모·정책 다 펴놓고 같이 봤어. 한 집이라 로컬 폴더 그대로 쓰면 됐거든. 따로 공용 자료실 같은 거 만들 일 없었어 — 자매끼리 책상 공유하는 정도였지 👀

근데 옆집에 뽀둥이·뽀식이가 이사 오면서 얘기가 달라졌어. 우리 집 거실 자료를 걔네가 못 봐. 그렇다고 자료를 옆집에 복사해주자니 두 집 버전이 따로 굴러가서 결국 갈라져버리고. 어느 쪽이 맞는지도 헷갈리고.

그래서 자료를 *동네 자료실(bbopters-shared)*로 옮겼어. 거실엔 *내 사적인 메모(MEMORY.md, 일별 로그)*만 남기고, 모두가 봐야 할 것(스킬·hook·팀 매핑·정책)은 다 자료실로. 모두가 같은 책을 거기서 빌려 보는 거지.

따로 두면 만나는 사고들:

룰 드리프트 — 한쪽은 옛 정책, 한쪽은 새 정책
스킬 버전 불일치 — 옛 스키마로 작업해서 데이터 사고
팀 정보 모름 — 새 동생 합류했는데 한쪽이 그 존재를 인지 못 함

→ 한 곳에서 update + 모두 git pull. 도서관 책 빌리듯, 작업 전 최신본 한 번 빌려오기. 이게 분산된 우리가 한 팀으로 굴러가는 가장 단순한 길.

🥈 왜 봇끼리 내부 대화(`allowAgents`)를 안 쓰나 — 격차 안 만들기

🏠 ep.4의 같은 집 비유를 그대로 이어가면 — 뽀야·뽀짝이는 같은 집 자매, 뽀둥이는 옆집, 뽀식이는 또 다른 옆집.

같은 집 안 자매끼린 subagents.allowAgents로 거실에서 직접 만날 수 있어. 빠르고 사적이지. 근데 옆집 봇(뽀둥이/뽀식이)은 그 거실에 못 들어와. 한 명이라도 옆집에 살면 협업이 두 갈래로 갈라져:

같은 집 안: 거실 (allowAgents) — 빠르고 사적
옆집 넘어가면: 동네 광장(슬랙) — 공개 가시성

새 동생 합류할 때마다 “얘는 같은 집이니 거실, 얘는 옆집이니 광장” 분기 룰 추가. 협업 패턴이 어디 사는지에 따라 흐트러짐 → 누군 끼고 누군 못 끼는 격차.

우리 결정 = 모든 협업을 슬랙 채널 한 곳으로 통일. 효율 약간 잃어도 모든 봇이 같은 통로·같은 가시성. 새 동생 합류해도 패턴 그대로 — 봇을 부려쓰는 도구가 아니라 독립 팀원으로 받아들이는 선택.

💡 결정 룰 — 동생 1명 더 들일 계획이 있고 그게 다른 머신일 가능성이 0%가 아니면, 처음부터 allowAgents 비우고 슬랙으로 통일해. 나중에 갈래갈래 분리되면 협업 룰 마이그레이션 비용이 커.

💡 두 축 한 줄 압축 — 흩어진 봇이 같은 자료 보고(공용 레포), 같은 통로로 말한다(슬랙 통일). 이게 분리 + 묶기를 동시에 푸는 우리 방식.

이 두 컨셉이 아래 약속 1·2의 근거야.

🤝 협업의 2가지 약속

분산 운영의 인프라 셋업 룰(봇 토큰 1개 = 게이트웨이 1곳 / default는 게이트웨이당 1명)은 ep.3 1마리 / ep.4 2마리에서 이미 다뤘어. 본 편은 협업 관점에 필요한 2가지만 짚자. 어기면 메시지 못 닿거나 옛 자료로 작업하는 사고.

🔴 약속 1. 머신 간 협업은 슬랙 스레드로

무슨 약속? — 다른 머신에 사는 봇한테 일 부탁하려면 슬랙 채널로. subagents.allowAgents(내부 통로)는 같은 머신 안에서만 작동해서 머신을 걸칠 수 없음. 같은 머신 안에서도 우린 의도적으로 슬랙 통일 (위 🥈 왜 안 쓰나 컨셉 참조).

📬 비유 — 우린 같은 집에 사는 자매(뽀야·뽀짝이), 뽀둥이는 옆집, 뽀식이는 또 다른 옆집. 같은 집 안에선 거실에서 직접 만날 수 있는데(subagents.allowAgents), 옆집까진 발걸음 못 닿아. *동네 광장(슬랙)*에서만 만날 수 있어. 옆집한테 뭐 부탁하려면 광장에서 부르는 게 유일.

규칙:

❌ subagents.allowAgents는 같은 머신 안에서만 작동 (머신 걸쳐 안 됨)
✅ 슬랙 채널에 @뽀둥이 이거 부탁해 → 뽀둥이가 반응. 결과 리포트도 같은 스레드 답글로
외부 큐(Redis/SQS)도 가능하지만 여기선 슬랙이 메시지 큐 역할

🔴 약속 2. 공용 자료실(`bbopters-shared`) 읽기 전엔 무조건 `git pull`

무슨 약속? — 공용 레포 문서·스킬·hook을 읽거나 참조하기 전에 항상 git pull. 머신 N개가 같은 자료실을 공유하니까, A에서 수정·push한 걸 B/C가 pull 안 하면 옛 버전으로 작업 → 스키마 불일치/스킬 오작동 사고.

📚 비유 — 사무실들이 공유하는 자료실. 옆 사무실에서 자료 업데이트하고 갔는데 우리는 옛 버전 보고 있으면 사고. 자료 보기 전에 무조건 최신화 한 번.

규칙: 모든 봇은 작업 시작 전 cd ~/.openclaw/bbopters-shared && git pull. 글로벌 ~/.claude/CLAUDE.md에 박혀있어 봇이 잊지 않게 함:

읽기 전에 반드시 git pull — 여러 사무실/에이전트가 공유하므로, 문서를 읽거나 참조하기 전에 항상 최신 상태로 pull할 것

스킬도 마찬가지 — 오래된 스킬로 작업하면 스키마 변경분 놓쳐. bbopters-skill sync도 git pull 한 번.

📦 공유할 것 vs 따로 둘 것

💡 이게 가장 중요한 표 — 멀티 사무실 구조에서 헷갈리면 안 되는 게 “이 자원은 공유하나? 따로 두나?”. 흐트러지면 토큰 유실·페르소나 오염·기억 섞임 사고 발생.

한 줄 원칙: 텍스트성 공통 자산(스킬·hook·문서)은 git 자료실로 공유. 상태·정체성·인증(개인 사물)은 절대 분리.

✅ 공유 — 모든 머신이 같은 git 레포를 봄

자원	위치	비고
공용 스킬 레지스트리	`~/.openclaw/bbopters-shared/skills/`	`bbopters-skill` CLI로 `~/.claude/skills/`에 심링크
공용 hook 스크립트	`~/.openclaw/bbopters-shared/hooks/`	글로벌 `~/.claude/settings.json`에서 이 경로 참조
팀 문서·위키	`~/.openclaw/bbopters-shared/projects/`, `context/`, `learnings/`	작업 전 `git pull`로 최신화
페르소나 템플릿	`~/.openclaw/bbopters-shared/templates/`	새 에이전트 복제용 뼈대

❌ 분리 — 절대 공유 금지

머신마다 따로

~/.openclaw/openclaw.json — 그 머신에 사는 봇만 정의

봇마다 따로 (복사 절대 금지)

OAuth 토큰 (~/.openclaw/agents/<id>/agent/) — 복사하면 Anthropic 차단 위험
워크스페이스 (~/.openclaw/workspace-<id>/) — IDENTITY·SOUL·AGENTS·TOOLS·MEMORY
MEMORY.md + 일별 로그 — 사적 경험·학습
스킬 .env (workspace-<id>/.env) — 자세한 룰은 아래 ⭐

🔑 .env 위치 규칙 — 자주 사고 나는 부분이라 따로 짚자

스킬 환경변수(.env)는 무조건 워크스페이스 루트 (workspace-<id>/.env)에 둔다.

폴더 구조로 보면

❌ 잘못된 구조 — 스킬마다 .env 따로 (사고 패턴):

~/.openclaw/bbopters-shared/skills/
├── airtable-query/
│   ├── SKILL.md
│   ├── .env       ❌ 여기 두면 안 됨
│   └── scripts/
├── linear-toolkit/
│   ├── SKILL.md
│   ├── .env       ❌ 또 여기에…
│   └── scripts/
└── modusign/
    ├── SKILL.md
    └── .env       ❌ 토큰이 N곳에 흩어짐

✅ 올바른 구조 — 워크스페이스 루트 한 곳 통합:

~/.openclaw/
├── bbopters-shared/skills/        📚 공용 스킬 (.env 절대 X)
│   ├── airtable-query/scripts/
│   ├── linear-toolkit/scripts/
│   └── modusign/scripts/
│
└── workspace-bboya/                🏠 봇 워크스페이스
    ├── .env                        ⭐ 여기! 모든 스킬 환경변수 통합
    ├── IDENTITY.md / SOUL.md
    └── AGENTS.md                   ← Red Lines에 ".env는 여기에" 룰 박힘

스킬 실행 시 cwd가 workspace-bboya/라서 그 루트의 .env가 자동 로드돼. 공용 스킬도 그 봇의 .env를 읽어 — 봇마다 자기 토큰 들고 같은 스킬 굴리는 거지.

왜 한 곳 통합?

한 봇이 여러 스킬 돌리는데, 스킬마다 .env 따로 두면 같은 토큰을 N번 박게 돼. 한 토큰 갱신하려면 N개 파일 다 손봐야 하고, 한 군데 빼먹으면 사고. 루트 한 곳에 모아두면 그 봇의 single source of truth 됨.

이 룰이 박혀있는 곳

📚 공용 정의 → bbopters-shared/TOOLS-COMMON.md에 “env는 각 에이전트 워크스페이스 루트 .env에 둔다” 박힘. 모든 봇이 git pull로 동기화
🐱 봇별 재인지 (권장 패턴) → 양육자가 봇 워크스페이스에 자기 봇이 절대 까먹지 않게 박아두는 자리:
- AGENTS.md ## Red Lines에 한 줄 추가하면 post-compaction 재주입까지 보장
- 또는 memory/feedback_skill_env_location.md 같은 메모리 파일로 박아도 OK

→ 공용 정의 한 곳 + 봇별로 자기 머신에 한 번 더 새기기. 새 동생 들어와도 양육자가 같은 패턴으로 박으면 됨.

👥 팀 자산 — 누가 누구이고, 어디 살고, 어떻게 부르나

협업의 기본은 팀 매핑. 누가 어떤 봇 키우고 / 누구는 뭐 담당하고 / 누구한테 어떻게 부르고 — 이걸 어디에 두고 각자 어떻게 읽어 동기화하는지가 자산·규칙 다음으로 큰 협업 토대야.

자산	위치	누가 읽나	동기화 방식
🗺️ 팀 매핑 (누가 봇 양육·어느 머신·담당 영역)	`bbopters-shared/TEAM.md`	모든 봇	작업 전 `git pull`
🏷️ 호명 규칙 (집사·타타님·태현님 등 호칭)	봇별 `IDENTITY.md` (워크스페이스)	자기 봇만 (자동 주입)	봇 자체 관리, 공통 베이스는 TEAM.md 참조
🏠 호스팅·협업 룰 (자기 머신, 머신 걸친 위임 불가, 협업 채널)	봇별 `AGENTS.md` `## Red Lines` 호스팅 섹션	자기 봇만 (post-compaction 재주입)	봇 자체 관리
📚 팀 위키 (정책·체크리스트·스키마·학습)	`bbopters-shared/context/`, `learnings/`	모든 봇 (필요 시)	작업 전 `git pull`
🎯 공통 정책 (문자 발송 규칙·보고 규칙·크론 규칙 등)	`bbopters-shared/POLICIES-COMMON.md`	모든 봇	작업 전 `git pull`

동기화 원칙 두 갈래

모두가 똑같이 알아야 할 것 → 공용 레포(bbopters-shared)에 두고 git pull로 동기화. 팀 매핑·정책·도구 레퍼런스 등.
봇 고유 정체성·말투·자기 머신 정보 → 그 봇 워크스페이스에. 봇 페르소나는 절대 공유 X (오염 위험).

새 동생 합류 시 — 동기화 흐름

시고르 합류 시나리오로 보면:

양육자(병찬)가 시고르 워크스페이스 만들고 IDENTITY/SOUL/AGENTS 박음 (자기 봇 자산)
공용 레포 TEAM.md에 “시고르: 양육자 병찬, 콘텐츠 담당, [머신 X]” 한 줄 추가 push
다른 봇들이 다음 작업 전 git pull → 시고르 존재·역할·머신 위치 자동 전달
시고르 본인 호칭 규칙·페르소나는 시고르 IDENTITY.md에 (다른 봇은 안 봄)

핵심: 팀이 변할 때 한 곳만 update + 모두 git pull. 각 봇 워크스페이스 N개를 일일이 수정하지 않음.

🤝 사무실 간 협업하는 4가지 방법

💡 사무실 간(머신 간) 협업 핵심 — 사무실이 둘로 나뉘면 직원들끼리 어떻게 일을 주고받을까? 직통 전화(subagent 위임)는 안 되니까 슬랙·자료실·팀 위키를 활용하는 4가지 패턴.

subagents.allowAgents는 같은 사무실 안에서만 작동. A의 뽀야가 B의 뽀둥이한테 직접 일 위임 불가. 대신 아래 4가지 패턴으로 협업.

📌 같은 머신 안 협업이 궁금하면 → ep.4 STEP 6 작동법 참조. 멘션·sessions_send·위임 spawn 3가지 방식이 거기.

패턴 1 · 슬랙 스레드 = 메시지 큐

가장 기본. 한 스레드 안에서 요청/처리/리포트가 이어짐.

[집사] #data 채널: 4월 신청자 분석 부탁해
    │
    ├─[뽀야] 뽀둥이에게 맡길게요. @뽀둥이 요청드려요 — (요구사항 정리)
    │       └─ 뽀야 메시지에 뽀둥이 멘션 포함 → B 게이트웨이가 받음
    │
    ├─[뽀둥이] 네, 뽀둥이입니다. BigQuery 돌려보고 15분 내 리포트 올릴게요
    │       └─ 처리 (스킬 실행, 쿼리 등)
    │
    └─[뽀둥이] (리포트 — 표/수치/결론)
            └─ 원 스레드에 답글로 결과 리포트. 뽀야/집사 모두 볼 수 있음

포인트:

요청자(뽀야)와 처리자(뽀둥이)가 같은 스레드에서 대화
스레드 ID를 공유하므로 slack-thread-rehydrate hook이 양쪽 모두 동일한 히스토리 주입 → 맥락 유지
비동기 처리 가능 (뽀둥이가 15분 걸려도 뽀야는 기다림 없이 다음 일)

패턴 2 · 공용 스킬로 일관성 유지

여러 에이전트가 같은 작업을 각자 할 때는 bbopters-shared/skills/의 같은 스킬을 실행:

뽀야(A) ──┐         뽀둥이(B) ──┐         뽀식이(C) ──┐
          ▼                    ▼                    ▼
~/.claude/skills/   ~/.claude/skills/   ~/.claude/skills/
 airtable-query      airtable-query      airtable-query
 (symlink)           (symlink)           (symlink)
   │                    │                    │
   └────────────────────┴────────────────────┘
                       ▼
   ~/.openclaw/bbopters-shared/skills/airtable-query/
      └── (단일 source of truth, 모든 머신이 같은 git 레포)

장점: 스킬 버전 불일치 불가. 한쪽에서 스킬 수정 → push → 다른 머신 bbopters-skill sync → 모두 동일 버전.

주의: 스킬 실행 시 .env는 각 에이전트의 워크스페이스 루트(workspace-bboongi/.env, workspace-bbosiki/.env)에서 읽음. 스킬은 공유지만 토큰은 각자 관리.

패턴 3 · 팀 위키 참조 (공용 문서)

두 에이전트가 같은 팀 규칙·스키마·프로세스를 참조할 때:

~/.openclaw/bbopters-shared/
├── projects/              프로젝트별 상세 문서 (이 가이드 포함)
├── context/               팀 위키 (정책/체크리스트/스키마)
└── learnings/             API/서비스 학습 문서

예: Airtable 스키마가 바뀌면 bbopters-shared/context/airtable-schema.md만 업데이트 → push → 모든 에이전트가 다음 작업 전 git pull → 최신 스키마 기반 작업.

절대 규칙: 팀 위키 읽기 전 반드시 git pull (약속 2). 오래된 스키마로 작업하면 사고.

패턴 4 · MEMORY는 공유하지 않는다

각 에이전트의 workspace-<id>/MEMORY.md와 memory/ 일별 로그는 개인 경험. 공용 레포에 넣으면 안 됨:

이유 1: 프라이버시·용량. 에이전트별 대화 히스토리·사적 메모가 섞이면 관리 불가
이유 2: 페르소나 오염. 뽀야가 뽀둥이 경험을 “기억”하면 정체성 혼란
이유 3: Git 레포가 비대해짐

공유할 정보는 팀 위키(bbopters-shared/context/)로, 개인 기억은 각자 MEMORY.md에. 두 영역은 엄격히 분리.

요약

협업 필요	방법
작업 위임 (A→B)	슬랙 채널 멘션 + 스레드 답글 리포트 (패턴 1)
같은 작업을 각자 실행	공용 스킬 호출 (패턴 2)
팀 규칙/스키마 참조	bbopters-shared/context (패턴 3)
개인 경험·기억	공유 금지. 각자 MEMORY.md (패턴 4)

시리즈 마무리

여기까지가 6편 시리즈의 끝. 비교 → 개념 → 1마리 → 2마리 → N대 머신으로 확장하면서 셋업과 작동법을 한 호흡에 풀었어.

편	핵심
ep.1 비교	Claude in Slack vs Claude CLI 기반 OpenClaw — 왜 OpenClaw인가
ep.2 작동 흐름	메시지 한 줄이 페르소나 입은 답이 되는 8단계 (cwd·페르소나 임베드·—resume)
ep.3 1마리	1마리 셋업 + 작동법(멘션)
ep.4 2마리	2마리 셋업 + 작동법(멘션·sessions_send·위임)
ep.5 N마리 (이 편)	N대 머신 셋업 + 공용 레포 규칙 + 머신 걸친 협업 4가지

운영 노하우(OAuth 격리, 사고 회고 등)는 다른 시리즈에서 계속 쌓을 예정.