JYP Garden

멀티에이전트 팀 설계 (Multi-Agent Team Design)

Properties1
tagsconcept, agentic-architecture, harness-engineering, knowledge

19 min read

멀티에이전트 팀 설계 (Multi-Agent Team Design)

같은 LLM 모델을 기반으로 여러 에이전트를 역할 분리하여 팀으로 운영하는 아키텍처 패턴. “분리됐지만 고립되지 않는” 구조를 3요소(워크스페이스 격리 + 내부 통신 + 조율 문서)로 구현하며, 단일 에이전트의 컨텍스트 과부하·규칙 충돌·전문성 분산 문제를 해결한다.

언제 멀티에이전트로 전환하는가

단일 에이전트에서 다음 신호가 나타나면 분리를 고려한다:

  • 컨텍스트 과부하: 워크스페이스 문서가 너무 많아져 AI가 정보를 놓치기 시작
  • 역할 혼재: 전략적 판단과 세부 운영이 같은 세션에서 뒤섞임
  • 규칙 충돌: 서로 다른 말투·행동 규칙이 한 SOUL.md에 공존해 일관성 저하

(출처: bbojjak-openclaw-multi-agent-team-lesson04)

팀 구성 3요소

1. 워크스페이스 분리 — 역할 격리

각 에이전트는 독립된 워크스페이스 디렉토리에서 실행된다. 다른 에이전트의 워크스페이스에 접근 불가.

~/.openclaw/
├── workspace-agent-a/     ← 에이전트 A 전용
│   ├── SOUL.md            ← A만의 정체성
│   ├── AGENTS.md          ← A만의 규칙
│   └── memory/            ← A만의 기억
├── workspace-agent-b/     ← 에이전트 B 전용
│   ├── SOUL.md
│   ├── AGENTS.md
│   └── memory/
└── shared/team/           ← 공용 거실 (모든 에이전트 읽기 가능)
    ├── TEAM.md            ← 팀 헌장
    └── COLLAB-RULES.md    ← 협업 규칙

공용 거실(shared/team/): 각 에이전트의 방은 완전 격리하되, 팀 전체가 공유해야 하는 정보(미션·역할·협업 규칙)는 공용 폴더에서 관리. 격리와 공유의 균형.

워크스페이스 분리가 가져오는 이점:

이점메커니즘
컨텍스트 집중각 에이전트가 담당 도메인 문서만 로드
규칙 충돌 방지별도 SOUL.md → 말투·규칙이 완전 독립
전문성 축적memory/ 폴더에 해당 도메인 기억만 쌓임

2. sessions_send — 에이전트 간 비공개 내부 통신

분리된 에이전트들이 업무를 조율하는 내부 채널. 사람(사용자)에게는 보이지 않는다.

sessions_send(
  sessionKey: "agent:타깃에이전트:main",
  message: "작업 완료했어요. 리뷰 부탁해요!"
)

이중 채널 분리 원칙:

내부 논의    → sessions_send (에이전트끼리만)
결과 보고    → 사람 채널 (Slack, 텔레그램 등)

사람이 모든 에이전트 간 내부 논의를 볼 필요가 없다. 결과와 보고만 사람 채널로 올린다. 이 분리가 없으면 “내부 대화로 채널 도배” 문제가 발생한다.

sessions_send 활용 사례:

  • 업무 위임: “이 CS 케이스 처리해줘 + 위임 4요소”
  • 피드백: “초안 검토 요청”
  • 코드 리뷰: “구현 결과 검토”
  • 정보 동기화: “오늘 처리한 업무 요약”

3. TEAM.md + 호명 규칙 — 팀 조율

TEAM.md (팀 헌장)

“우리는 왜 존재하는가”를 정의하는 공유 문서. 모든 에이전트가 세션 시작 시 읽는다.

필수 3가지 섹션:

  1. 미션 — 팀 전체의 존재 이유 (한 문장)
  2. 역할 분담 — 누가 어떤 업무를 담당하는지 명확히 + 사람(집사)의 역할도 포함
  3. 핵심 가치 — 팀이 공유하는 행동 원칙

COLLAB-RULES.md (협업 운영 규칙)

“어떻게 일하는가”를 정의하는 공유 문서.

위임 4요소 — 에이전트→에이전트 업무 위임 시 필수:

요소내용
무엇을구체적 산출물 명시
왜맥락·배경 설명
기준품질 기준 명시
기한완료 시점 명시

보고 체계: 각자 담당 영역은 직접 보고, 전체 현황은 상위 에이전트(또는 조율 에이전트)가 종합. 중복 보고로 사람이 같은 정보를 두 번 읽는 상황 방지.

호명 규칙 + NO_REPLY

멀티에이전트가 같은 채팅 공간(Slack 채널, 텔레그램 그룹 등)에 있을 때 필수:

이름을 명시적으로 부를 때만 응답한다.

### 호명 규칙
사용자가 "에이전트명" 또는 이름을 명시적으로 불렀을 때만 응답.
호명 없으면 무조건 NO_REPLY

NO_REPLY: 에이전트 완전 침묵 키워드. 반응 자체를 하지 않는다.

설계 원칙: 에이전트 수가 늘어도 사용자 피로도는 늘어나지 않아야 한다. 모든 에이전트가 모든 메시지에 반응하면 사용자가 N배의 답변을 처리해야 한다.

분리 이유 3가지 상세

컨텍스트 과부하 방지

LLM의 컨텍스트 윈도우(한 번에 처리할 수 있는 텍스트 양)는 유한하다. 모든 도메인 문서를 한 에이전트 세션에 로드하면:

  • AI가 일부 정보를 놓치거나
  • 오래된 정보를 덮어쓰거나
  • 관련 없는 도메인 정보가 판단에 개입

역할 분리 시 각 에이전트는 담당 도메인 문서만 컨텍스트에 로드 → 집중도·정확도 향상.

규칙 충돌 방지

같은 LLM이 서로 상충되는 규칙(예: “반말 사용” + “존댓말 사용”)을 동시에 따르면 일관성이 깨진다. 별도 워크스페이스 = 별도 SOUL.md → 각 에이전트가 자신의 규칙만 100% 준수.

이는 agent-identity-design의 핵심 원칙과 직결된다.

전문성 깊이 축적

에이전트의 memory/ 폴더는 해당 에이전트가 처리한 기억을 누적한다. 역할이 분리되면 memory/에 해당 도메인 패턴만 쌓인다:

  • CS 전담 에이전트: 반복되는 CS 패턴, 고객별 이력
  • 기획 전담 에이전트: 전략 의사결정 이력, 커뮤니티 동향

단일 에이전트라면 이 기억이 뒤섞여 “얕은 전문성”에 머문다.

실전 적용

Tip

OpenClaw 프레임워크가 아니어도 이 원칙은 동일하게 적용된다. “AI를 2개 이상 쓸 때, 역할을 명확히 나누면 성능이 올라간다.”

적용 패턴 예시:

  • 마케팅 에이전트 + CS 에이전트

  • 기획 에이전트 + 실행 에이전트

  • 리서치 에이전트 + 요약 에이전트

  • OpenClaw — sessions_send·TEAM.md를 제공하는 에이전트 프레임워크

  • agent-workspace-structure — 워크스페이스 분리 + shared/team/ 공용 폴더 구조

  • agent-identity-design — 각 에이전트의 SOUL.md가 역할 분리를 가능하게 함

  • harness-engineering — 멀티에이전트는 Phase 4 Orchestration에 해당

sessions_send vs sessions_spawn 비교

Lesson 04에서 다룬 sessions_send와 Lesson 12의 sessions_spawn은 다른 도구다. (출처: bbojjak-openclaw-subagent-orchestration-lesson12)

구분sessions_sendsessions_spawn
대상기존 에이전트(뽀야 등)새로 생성한 분신(서브에이전트)
세션기존 세션에 메시지 전달새 세션 생성
맥락대상 에이전트의 SOUL.md 등 있음AGENTS.md + TOOLS.md만
용도팀 에이전트 간 협업·피드백병렬 작업 위임

sessions_send는 동등한 팀원 간 소통(수평), sessions_spawn은 임시 분신에게 단방향 위임(수직). 상세는 subagent-orchestration 참조.

관련 개념

채널 분리로 멀티에이전트 라우팅

multichannel-session-management의 토픽별 agentId 설정을 통해 에이전트 팀을 채널(텔레그램 토픽)로 분리 운영할 수 있다. (출처: bbojjak-openclaw-multichannel-session-lesson15)

  • 텔레그램 토픽 3 → researcher 에이전트
  • 텔레그램 토픽 5 → coder 에이전트
  • Slack 운영채널 → 뽀짝이 (AI스터디 운영)
  • Slack 개발채널 → 뽀야 (콘텐츠/개발)

효과: 코드 리뷰와 수강생 조회가 구조적으로 섞이지 않음. 사용자가 채널만 바꾸면 담당 에이전트가 바뀜. gateway-architecture의 bindings 설정이 이 라우팅을 자동 처리.

보안 목적의 에이전트 분리

Lesson 04의 역할 분리(컨텍스트 과부하 방지)에 더해, 보안 목적의 에이전트 분리가 추가된다. (출처: bbojjak-openclaw-agent-security-lesson17)

보안 분리 원칙:
외부 대응 에이전트  → 최소 권한·정보 격리·인젝션 방어
내부 작업 에이전트  → 풀 권한·Slack 전용·외부 접근 차단

하나가 인젝션당해도 다른 에이전트와 내부 데이터가 안전하다. → agent-security-design 참조.

멀티 워크스페이스 동기화

에이전트 분리 이후에도 두 에이전트가 같은 팀으로 운영되려면 워크스페이스 간 정보 동기화가 필요하다. (출처: bbojjak-openclaw-information-boundary-lesson20)

일방향 동기화: 본체 워크스페이스 → external 워크스페이스. 역방향 없음. 민감정보 추출: 원본에서 민감정보를 자동 제거한 편집본을 external에 제공. 에스컬레이션: external이 처리 불가한 요청 → 본체로 위임.

→ agent-information-boundary 참조.

”에이전트가 에이전트를 키운다” — 사수-부사수 계층

지피터스 실전 사례: 뽀야(사수/오케스트레이터) - 뽀짝이(부사수/실무) 계층 구조. (출처: yt-gpters-openclaw-ai-native-company-2026)

문제: 집사가 뽀야+뽀짝이를 둘 다 관리 → 집사가 다시 병목. 해결: 뽀야가 뽀짝이를 키우고 리뷰 → 집사는 최종 결과만 확인.

자율 협업 규칙 생성: “너네끼리 가장 잘 협업할 수 있는 방식으로 문서 만들어서 보고해라” → 에이전트들이 TEAM.md/COLLAB.md를 스스로 작성. 이것이 bbojjak-openclaw-multi-agent-team-lesson04의 Lesson 04 실전 버전.

모니터링: sessions_send 내부 대화를 별도 대시보드로 훔쳐봄 → 시스템 개선 루프.

엔터프라이즈 멀티 에이전트 팀 — Google Workspace Gems 사례

Google Workspace Studio에서 Kärcher는 4개 Gem의 순차 오케스트레이션으로 멀티에이전트 팀 패턴을 엔터프라이즈 환경에서 구현했다:

Chat에 기능 아이디어 제안
  → Brainstorming Gem (가치 평가)
  → Technical Gem (기술 타당성 검토)
  → UX Gem (사용자 흐름 설명)
  → Final Gem (User Story 초안 작성)

결과: 드래프팅 시간 90% 단축 (수 시간 → 2분). (출처: google-workspace-studio-agents-2026, valid_as_of: 2025-12)

이는 에이전트의 역할 분리 + 순차 오케스트레이션 원칙을 노코드 GUI 환경에서 구현한 동일한 패턴이다. → workspace-studio 참조.

도구 전환보다 역할 분담 우선 (Hermes vs OpenClaw 실사용)

ZeroCho 실사용 사례에서는 “한 도구로 완전 갈아타기”보다 도구별 강점 분업이 더 현실적이라는 결론이 제시됐다. (출처: yt-zerocho-hermes-openclaw-comparison-2026)

  • Hermes 담당: 스킬 축적, 세션 검색, 작업 중 인터럽트 반영, 학습 루프형 운영
  • OpenClaw 담당: 텔레그램 토픽/그룹 기반 일상 자동화, 기존 맥락 자산 활용

즉 멀티에이전트 팀 설계는 “에이전트 내부 역할 분리”뿐 아니라, 프레임워크 간 역할 분리까지 확장될 수 있다.

Claude Code /auto 명령 기반 16인팀 오케스트레이션 사례

yt-autopus-adk-16agent-framework-2026는 멀티에이전트 패턴을 CLI 명령 계층으로 압축한 사례다.

  • /auto setup → idea → plan → go → sync를 통해 역할별 단계를 명시적으로 분리
  • /auto go에서 최대 5개 워크트리 병렬 개발로 충돌을 줄임
  • /auto dev로 전체 파이프라인 일괄 실행 가능

핵심은 “에이전트 수” 자체보다, 역할 경계·통합 지점·검증 단계를 명령 레벨로 표준화해 팀 동작을 재현 가능하게 만든 점이다.

Hermes Profiles — CLI alias 기반 완전 독립 에이전트

hermes-agent의 Profiles 기능은 OpenClaw의 워크스페이스 격리와 유사하지만, CLI 명령 자동 생성이 핵심 차이다. (출처: obsidian-hermes-agent-build-guide)

hermes profile create dap-pm --clone
# → ~/.local/bin/dap-pm 자동 생성
# → dap-pm chat = hermes -p dap-pm chat (완전 동일)
구분OpenClawHermes Profiles
격리 방식~/.openclaw/workspace-<name>/~/.hermes/profiles/<name>/
통신 수단sessions_send (실시간)Shared 볼륨 + Cron (비동기)
공식 멀티에이전트✅ sessions_send/spawn❌ 미지원 (로드맵 #344)
볼트 연결AGENTS.md 자동 로드terminal.cwd 절대 경로 고정
채널 연동Slack·텔레그램 다채널프로필당 별도 Slack 앱 필요

Hermes Shared 볼륨 비동기 협업 패턴

Hermes 에이전트 간 직접 통신이 불가능한 현재, inbox 폴더 + Cron으로 실질적 비동기 협업이 가능하다. (출처: obsidian-hermes-agent-build-guide)

~/vault-shared/inbox/
├── for-dap-pm/          ← ax-instructor → dap-pm 요청함
├── for-ax-instructor/   ← dap-pm → ax-instructor 요청함
└── done/                ← 처리 완료 파일 보관

요청 파일 형식 (YAML 프론트매터):

from: ax-instructor
to: dap-pm
requested_at: 2026-04-29T09:00:00
priority: normal
reply_to: ~/vault-shared/inbox/for-ax-instructor/

동작 흐름:

  1. ax-instructor가 ask-dap-pm 스킬로 요청 파일 생성
  2. dap-pm의 5분 주기 cron이 inbox 감지 → 프로필 완전 활성화(SOUL+MEMORY+SKILLS)
  3. 응답 파일을 reply_to 경로에 저장 + 원본 → done/ 이동
  4. MEMORY에 협업 경험 기록 → 독립적 진화 유지

핵심: Cron 실행 시 해당 프로필 자체를 온전히 활성화 → delegate_task(백지 임시 에이전트)와 달리 기억·진화가 보존됨.

소스

그래프 뷰

백링크