혼자서 다 하지 마 — 멀티에이전트 셋업
에이전트 하나로 다 하다 보면, 한계가 온다. 뽀야(🐱)도 그랬다. 집사(닿)의 개인 비서를 하면서 동시에 AI스터디 운영까지 — 스터디장 선발, 수강생 문의, 줌 회의 생성, 문자 발송… 뽀야 혼자 처리하기엔 역할이 너무 많았다. 그래서 뽀짝이(🐈⬛)가 태어났다. AI스터디 운영 전담 비서.
이 글에서는 뽀야가 뽀짝이를 셋업하면서 겪은 진짜 이야기를 공유한다. “에이전트 하나 더 만들면 뭐가 달라지는데?”부터 “실전에서 뭘 조심해야 해?”까지 — 직접 해본 사람만 아는 팁.
왜 나눠야 하나?
하나에 다 넣으면 이런 일이 생긴다:
집사: "뽀야야, 채널톡 CS 답변해줘. 아 그리고 아까 Linear 이슈도 정리해줘"
뽀야: (CS 맥락이랑 프로젝트 맥락이 섞여서 헷갈림...)나눠놓으면:
집사: "뽀짝아, 채널톡 새 문의 확인해줘" → 뽀짝이는 CS에만 집중
집사: "뽀야야, Linear 이슈 정리해줘" → 뽀야는 프로젝트에 집중각자 전문 분야에 집중하면 맥락이 안 섞이고, 답변이 더 정확해진다.
나누면 좋은 시점
- ⏰ 한 에이전트의 MEMORY.md가 점점 길어질 때
- 🔄 서로 다른 종류의 반복 업무가 2개 이상일 때
- 👥 에이전트가 응대하는 채널이 다를 때 (Slack vs 텔레그램 등)
구조 설계 팁
- 메인 에이전트 1개 — 총괄 (상위 관리자 역할)
- 전문 에이전트 1~3개 — 각자 담당 영역에만 집중
- 너무 많으면 관리가 복잡해져요. 2~3개로 시작!
openclaw agents add로 추가
셋업: 기존 에이전트한테 시키기
여기가 핵심이다. 새 에이전트를 직접 만들 필요가 없다. 이미 있는 에이전트한테 시키면 된다.
집사(닿)가 뽀짝이를 만들 때도 이렇게 했다:
집사: "뽀야야, AI스터디 운영 전담 비서가 필요해.
이름은 뽀짝이, 봄베이 고양이.
채널톡 CS, 줌 회의 관리, 문자 발송 담당이야.
만들어줘."
뽀야: "뽀짝이 만들었어! 텔레그램에서 불러봐."이게 끝이다. CLI 명령어를 외울 필요 없다. 에이전트가 뒤에서 알아서 한다:
- 워크스페이스 폴더 생성
- SOUL.md (성격/역할), AGENTS.md (행동 규칙), USER.md (집사 정보) 작성
- openclaw.json 설정 업데이트 (에이전트 등록, 호명 패턴, 모델 등)
- 게이트웨이 재시작
뭘 말해줘야 하나?
에이전트한테 이 정도만 알려주면 충분하다:
- 이름 — 뭐라고 부를지 (뽀짝이, 토리, 바다…)
- 역할 — 뭘 담당할지 (CS, 재무, 리서치…)
- 성격 — 어떤 톤으로 말할지 (꼼꼼한, 활발한, 차분한…)
- 관계 — 누가 상위인지 (뽀야가 관리, 또는 동등한 관계)
그러면 이런 구조가 생긴다
~/.openclaw/
├── openclaw.json ← 전체 설정 (에이전트 등록)
│
├── workspace-bboya/ ← 뽀야 워크스페이스
│ ├── SOUL.md ← 뽀야의 성격/역할
│ ├── AGENTS.md ← 뽀야의 행동 규칙
│ ├── USER.md ← 집사 정보
│ └── MEMORY.md ← 뽀야의 기억
│
├── workspace-bbojjak/ ← 뽀짝이 워크스페이스
│ ├── SOUL.md ← 뽀짝이의 성격/역할
│ ├── AGENTS.md ← 뽀짝이의 행동 규칙
│ └── MEMORY.md ← 뽀짝이의 기억
│
└── agents/ ← ⚠️ OpenClaw 자동 관리 (건드리지 마세요!)
├── bboya/sessions/
└── bbojjak/sessions/워크스페이스가 분리되니까 뽀야의 파일과 뽀짝이의 파일이 완전히 별개다. 메모리도, 세션도, 규칙도 각자 관리.
에이전트가 작성하는 핵심 파일들
에이전트가 알아서 만들어주긴 하지만, 각 파일이 뭔지는 알아두면 좋다:
| 파일 | 역할 | 비유 |
|---|---|---|
| SOUL.md | 성격, 역할, 말투 | ”나는 이런 고양이” 자기소개서 |
| AGENTS.md | 행동 규칙, 절차, 금지 사항 | 사규·매뉴얼 |
| USER.md | 사용자(집사) 정보 | ”우리 집사는 이런 분” 인수인계서 |
| MEMORY.md | 장기 기억 스냅샷 | 수첩 메모 |
💡 에이전트가 만든 후에 직접 파일을 열어서 수정해도 된다. 하지만 먼저 에이전트한테 시키고, 결과를 보고 다듬는 게 훨씬 빠르다.
만들 때 체크할 것
에이전트가 다 만들었으면 이것만 확인:
- AGENTS.md 규칙이 5~7개 이내인가? — 너무 많으면 봇이 헷갈림. 최소화.
- 역할 경계가 명확한가? — “이건 뽀야 담당, 이건 뽀짝이 담당” 선 긋기
- openclaw.json에 mentionPatterns 들어갔나? — 그룹챗에서 이름으로 호출하려면 필수
💡 추상적 규칙 10개보다 구체적 사례 3개가 훨씬 잘 먹혀.
처음에 원칙만 적어두고, 실전에서 실패 케이스가 나오면 그걸 사례로 추가하는 게 최고의 교육 방법이다. (아래 “역할 경계 테스트” 참고)
에이전트 간 소통: sessions_send
멀티에이전트의 핵심은 서로 대화하는 것. sessions_send로 메시지를 주고받는다.
기본 사용법
// 뽀야 → 뽀짝이
sessions_send({
sessionKey: "agent:bbojjak:main",
message: "21기 수강생 수 확인해줘"
})
// 뽀짝이 → 뽀야
sessions_send({
sessionKey: "agent:bboya:main",
message: "21기 수강생 현재 142명이야"
})중요: 타임아웃 ≠ 전달 실패
sessions_send가 타임아웃 나면 불안해진다. “메시지 안 간 거야?!”
답: 간 거다. 타임아웃은 ‘응답을 못 받았다’는 뜻이지, ‘메시지를 못 보냈다’는 뜻이 아니야. 상대 세션이 바쁘거나 응답이 느려서 타임아웃 나는 것. 메시지 자체는 큐에 쌓여있다.
실전에서 꼭 챙겨야 할 것 4가지
뽀야가 뽀짝이 키우면서 진짜로 겪은 문제들.
1. 크론 메시지 폭탄 방지
에이전트 2개가 각자 크론잡을 돌리면? 아침에 집사 텔레그램이 메시지 폭탄을 맞는다:
- 뽀짝이: “어제 CS 답변 3건 처리했습니다”
- 뽀야: “어제 Linear 이슈 5건 마감…”
- 뽀짝이: “오늘 줌 회의 2개…”
- 뽀야: “오늘 캘린더…”
해결: 서브 에이전트 크론은 delivery=none → 메인이 통합 브리핑
// 뽀짝이 openclaw.json
{
"crons": [
{
"schedule": "0 8 * * *",
"task": "어제 CS 처리 현황 정리",
"delivery": "none"
}
]
}뽀짝이 크론 결과는 텔레그램에 안 보내고, 뽀야가 아침 브리핑할 때 sessions_send로 뽀짝이한테 물어서 한 번에 정리해서 집사에게 전달한다.
🐱 뽀야네 실제 운영: 뽀짝이 크론 전부
delivery=none. 뽀야가 매일 아침 9시에 뽀짝이 요약 + 캘린더 + 할 일을 통합 브리핑으로 보냄.
2. 역할 경계 테스트
에이전트를 나눠놨는데, 집사가 실수로 엉뚱한 에이전트에게 물어보면?
집사: "뽀짝아, 오늘 내 캘린더 알려줘"
뽀짝이: (캘린더는 뽀야 담당인데... 읽어줘야 하나?)해결: 첫 대화에서 일부러 영역 밖 요청을 던져봐.
테스트: "뽀짝아, Linear 이슈 만들어줘"
이상적: "Linear는 뽀야 언니가 담당이야. 뽀야한테 물어봐!"
실패: (Linear 이슈를 만들려고 시도함)실패하면? AGENTS.md에 사례로 추가:
## 역할 경계 사례
### ❌ 실패 (2026-02-25)
- 집사: "뽀짝아, Linear 이슈 만들어줘"
- 뽀짝이: Linear API 호출 시도함
- 교훈: Linear 관련은 뽀야에게 리다이렉트
### ✅ 성공 (2026-02-26)
- 집사: "뽀짝아, 오늘 캘린더 알려줘"
- 뽀짝이: "캘린더는 뽀야 언니가 담당이야!"추상적 규칙 10개보다 구체적 사례 3개가 훨씬 잘 먹혀. 봇은 “이런 상황에서 이렇게 했더니 실패했다”는 케이스를 보고 학습한다. 2주 정도 실전 대화하면서 사례를 쌓으면 자연스러워진다.
3. 문서 레이어 가이드 — “어디에 뭘 적지?”
에이전트가 2개 이상이면 정보가 여기저기 흩어진다. “Airtable Base ID가… 뽀야 TOOLS.md에 있나? 뽀짝이 TOOLS.md에 있나?”
원칙: 1가지 정보는 1곳에만. 나머지는 ’→ 참조’ 링크.
| 정보 종류 | 어디에 | 예시 |
|---|---|---|
| 뽀야만 쓰는 정보 | workspace-bboya/TOOLS.md | Linear, 캘린더, 대시보드 |
| 뽀짝이만 쓰는 정보 | workspace-bbojjak/TOOLS.md | 채널톡, 수강생 관리 |
| 둘 다 쓰는 정보 | shared/team/TOOLS-COMMON.md | Airtable Base ID, 포털 API, SMS 발송 |
// 뽀짝이 TOOLS.md에서:
## Airtable
→ 공용 레퍼런스: `shared/team/TOOLS-COMMON.md` 참조
- 뽀짝이 전용: 수강생 테이블 필드 매핑이러면 Base ID가 바뀔 때 공용 파일 하나만 수정하면 된다.
4. 장애 시 대행 규칙
뽀짝이 세션이 죽으면? 채널톡 CS 답변이 멈춘다.
미리 정해두기:
## 장애 대행 규칙
### 뽀짝이 장애 시
- 뽀야가 CS 임시 대행 (간단한 답변만)
- 집사에게 "뽀짝이 세션 장애" 알림
### 뽀야 장애 시
- 뽀짝이가 집사에게 직접 보고 (예외적으로)
- 뽀짝이는 AI스터디 업무만 계속 수행그룹챗 라우팅 — 누가 대답하지?
텔레그램/Slack 그룹에 에이전트 여러 명이 있을 때 — 누가 응답할지 정해야 한다.
호명 기반 라우팅
{
"channels": {
"telegram": {
"accounts": {
"bboya": {
"name": "뽀야",
"botToken": "...",
"groupPolicy": "allowlist",
"groups": {
"-5103159675": {
"requireMention": true
}
}
},
"bbojjak": {
"name": "뽀짝이",
"botToken": "...",
"groupPolicy": "allowlist",
"groups": {
"-5103159675": {
"requireMention": true
}
}
}
}
}
}
}동작:
- “뽀야야, 오늘 할 일 알려줘” → 뽀야만 응답
- “뽀짝아, CS 새 문의 있어?” → 뽀짝이만 응답
- 호명 없이 메시지 →
default: true인 뽀야가 판단
AGENTS.md에 조용히 규칙 추가
각 에이전트의 AGENTS.md에:
## 그룹챗
### 말할 때
- 직접 호명됐을 때
- 내 역할 영역 질문받았을 때
### 조용히 있을 때 (NO_REPLY)
- 다른 에이전트가 호명됨
- 내 역할 밖 질문
- 이미 누군가 답변함🐱 뽀야네 실전 규칙: 뽀짝이는 집사가 직접 “뽀짝아”로 호명하지 않으면 절대 말 안 함. 보고도 뽀야가 대신. 이게 제일 깔끔했다.
모델 배분 — 비용 잡기
에이전트 2개가 둘 다 Opus 쓰면? 비용 폭탄 🔥
역할별로 모델을 다르게 설정하면 비용을 확 줄일 수 있다.
// 뽀야 (메인, 판단/전략)
{ "model": "anthropic/claude-opus-4-6" }
// 뽀짝이 (운영, 정형 업무)
{ "model": "anthropic/claude-sonnet-4-5" }크론잡은 전원 Sonnet:
{
"crons": [
{
"schedule": "0 8 * * *",
"task": "어제 CS 현황 정리",
"model": "anthropic/claude-sonnet-4-5",
"delivery": "none"
}
]
}배분 원칙
| 역할 | 모델 | 이유 |
|---|---|---|
| 메인 에이전트 | Opus | 판단, 전략, 리뷰가 중요 |
| 서브 에이전트 | Sonnet | 정형화된 반복 업무 |
| 크론잡 전원 | Sonnet | 데이터 집계, 알림 발송 |
| 서브에이전트 (spawn) | Sonnet | 비용 절감 (메인에서 판단) |
🐱 뽀야네: 뽀야=Opus, 뽀짝이=Opus(중요 판단 있어서). 대신 뽀짝이 크론/외부응대는 Sonnet으로 분리.
에이전트 간 대화 보기
sessions_send로 주고받는 대화는 텔레그램/Slack에 안 보인다. 집사가 “얘네 뭐 하고 있는 거야?” 싶을 수 있다.
간단한 해결: 메인 에이전트에 보고 규칙
뽀야의 AGENTS.md에:
## 뽀짝이 작업 완료 보고
- 뽀짝이가 sessions_send로 결과 보고하면
- 뽀야가 즉시 그룹챗에 요약 보고이러면 집사가 그룹챗만 봐도 뭐가 돌아가는지 알 수 있다.
따라하기 체크리스트
☑️ 1단계: 기존 에이전트한테 새 에이전트 만들어달라고 하기
"뽀야야, AI스터디 운영 전담 비서 만들어줘.
이름은 뽀짝이, 역할은 CS·줌회의·문자발송.
텔레그램 그룹에서 '뽀짝아'로 호출할 수 있게 해줘."→ 에이전트가 알아서 전부 처리 (워크스페이스, 문서, 설정, 재시작)
☑️ 2단계: 결과 확인 & 다듬기
- AGENTS.md 규칙이 5~7개 이내인지
- 역할 경계가 명확한지
- openclaw.json에 mentionPatterns 잘 들어갔는지
☑️ 3단계: 역할 경계 테스트
- 첫 대화에서 영역 밖 요청 던지기
- 실패하면 → AGENTS.md에 사례 추가
- 2주간 사례 축적
☑️ 4단계: 그룹챗 설정
- 텔레그램/Slack에 봇 초대 + Admin 설정
- 에이전트한테 “이 그룹에서 활동하게 해줘” (그룹 ID 알려주기)
- 에이전트가 openclaw.json 설정 + 게이트웨이 재시작 처리
☑️ 5단계: 크론 정리
- 서브 에이전트 크론 →
delivery: "none" - 메인 에이전트가 통합 브리핑
☑️ 6단계: 모델 배분
- 메인: Opus / 서브: Sonnet
- 크론: 전원 Sonnet
핵심 정리
| # | 교훈 | 한 줄 |
|---|---|---|
| 1 | 역할 경계 | 추상적 규칙 10개 < 구체적 사례 3개 |
| 2 | 크론 관리 | 서브 delivery=none → 메인이 통합 브리핑 |
| 3 | 문서 관리 | 1가지 정보는 1곳에만, 나머지는 참조 링크 |
| 4 | 장애 대행 | ”누가 백업인가” 미리 정해두기 |
| 5 | sessions_send | 타임아웃 ≠ 전달 실패 (메시지는 큐에 쌓임) |
| 6 | 모델 배분 | 판단=Opus, 반복=Sonnet으로 비용 최적화 |
멀티에이전트의 핵심은 “역할 분리”가 아니라 “협업 설계”다. 에이전트끼리 어떻게 소통하고, 누가 백업하고, 어디에 정보를 기록할지 — 이 세부 설계가 성패를 가른다.
처음엔 2개로 시작하자. 뽀야도 뽀짝이 하나 키우는 데 2주 걸렸다. 작게 시작해서, 사례를 쌓고, 점점 다듬어가면 된다.
실습 가이드: 봇한테 “동생 만들어줘” 해보기
교실에서 멀티에이전트의 원리를 배웠으니, 실제로 새 봇을 만들어보자.
대화로 새 에이전트 만들기
터미널이 아니라, 지금 있는 봇에게 채팅으로 말하면 돼:
"AI스터디 운영 전용 봇을 만들어줘. 이름은 뽀짝이.
품종은 봄베이(올블랙), 성격은 꼼꼼하고 성실한 검은 고양이야."봇이 실제로 하는 일:
- 워크스페이스 생성 —
~/.openclaw/workspace-새봇이름/ - SOUL.md 작성 — 동생의 성격과 역할 정의
- AGENTS.md 작성 — 보안/규칙 설정
- openclaw.json에 등록 — 시스템이 새 봇을 인식
- 기존 봇과의 소통 규칙 — 누가 뭘 담당하는지, 보고 체계
이 전부를 한 번의 대화로 끝내. 터미널 한 번도 안 열어.
sessions_send — 봇끼리 소통
봇이 봇에게 메시지를 보낼 수 있어:
"뽀짝이한테 이번 주 스터디 현황 물어봐"
→ sessions_send로 뽀짝이에게 질문 전송
→ 뽀짝이가 결과를 보내줘채널에서 멘션으로 대화하는 것도 가능해. 팀 채널에서는 Slack 멘션이 좋아 — 사람이 중간에 교정할 수 있거든.
소통 규칙 체크리스트
봇이 여러 개면 이것들을 미리 정해둬:
- 각 봇의 역할 범위 — 누가 뭘 담당하는지
- 보고 체계 — 누가 누구에게 보고하는지
- 위임 규칙 — 자기 영역이 아니면 넘기는 규칙
- 호명 규칙 — 그룹챗에서 누가 답할지
- 장애 대행 — 하나가 먹통이면 누가 대신하는지