OpenClaw를 활용한 5가지 역할의 AI 협업 운영체제 구축: 기술적 상세 분석

OpenClaw를 하나의 단일 어시스턴트에서 다중 역할 협업 운영 체제로 전환하는 데 오랜 시간을 투자했습니다. 단순히 "봇 몇 개를 열어서 따로따로 채팅하는 것"과는 차원이 다릅니다.

5개의 AI 역할이 하나의 게이트웨이를 공유하며 Discord와 Telegram 이중 채널에서 작동합니다. 명확한 업무 분담, 라우팅, 메모리 격리 및 협업 규칙을 갖추고 있어 팀처럼 릴레이 방식으로 작업을 수행할 수 있습니다.

이 글에서는 전체 구축 과정, 각 레이어의 설계 결정, 구체적인 구성 및 제가 부딪혔던 함정들을 낱낱이 분석합니다.

여러분도 OpenClaw를 사용하고 있거나 "여러 AI가 진정으로 협업하게 만드는 방법"에 관심이 있다면, 이 글이 많은 시행착오를 줄이는 데 도움이 될 것입니다.

결론부터 말하자면: 이것은 "멀티 봇"이 아니라 단일 게이트웨이 아래의 멀티 에이전트 OS입니다

"5개의 AI 역할"이라는 말을 들었을 때 많은 사람들의 첫 반응은 "5개의 독립적인 봇을 운영하는 거지?"입니다.

맞습니다. 하지만 틀렸습니다.

제 아키텍처는 이렇습니다:

• 1개의 게이트웨이 프로세스: 채널 액세스와 라우팅을 통합합니다.
• 5개의 독립적인 에이전트: Commander(지휘관), Strategist(전략가), Engineer(엔지니어), Creator(크리에이터), Thinker(사상가)
• 각 에이전트는 자체 독립적인 작업 공간(성격, 규칙, 메모리 및 세션이 모두 격리됨)을 가집니다.
• Discord + Telegram 이중 채널을 동시에 실행합니다(많은 플랫폼을 실행할 수 있지만 저는 Discord만 사용합니다). 바인딩을 사용하여 정확한 메시지 분배를 수행합니다.
• 개인 채팅과 그룹 채팅은 완전히 다른 메커니즘을 사용합니다.

비유하자면, 5명을 고용해서 방에 던져놓고 마음대로 행동하게 하는 것이 아닙니다. 회사를 만드는 것입니다. 조직 구조, 직무 설명, 커뮤니케이션 프로토콜, 독립적인 사무실, 회의 규칙을 갖추는 것이죠.

OpenClaw 자체는 오픈 소스 개인 AI 어시스턴트 프레임워크로, 여러 플랫폼(Discord, Telegram, WhatsApp 등)과 여러 모델(Claude, GPT, Gemini 등)을 지원하며 데이터는 완전히 로컬에 저장됩니다.

멀티 에이전트 기능은 제가 OpenClaw를 선택한 핵심 이유입니다. 멀티 에이전트 독립 작업 공간 + 바인딩 라우팅을 기본적으로 지원하여 그 위에 진정한 협업 시스템을 구축할 수 있기 때문입니다.

1. 전체 아키텍처: 단일 게이트웨이 + 멀티 에이전트 + 멀티 워크스페이스 + 멀티 채널

먼저 최하위 아키텍처 결정 사항에 대해 이야기해 보겠습니다.

1) 단일 게이트웨이를 통한 통합 호스팅

현재 하나의 OpenClaw 게이트웨이 프로세스가 모든 기능을 담당합니다. 메시지 액세스, 라우팅, 세션 관리, 도구 호출, 메모리 인덱싱 및 상태 관리를 모두 하나의 게이트웨이에서 처리합니다.

각 역할에 대해 서비스 세트를 별도로 실행하지 않는 이유는 세 가지입니다:

• 중앙 집중식 유지 관리: 유지 관리해야 할 게이트웨이는 하나뿐이며 각 역할에 대해 독립적인 서비스를 실행할 필요가 없습니다.
• 통합 구성: 하나의 마스터 구성으로 글로벌 전략을 관리하고 모니터링/문제 해결도 중앙 집중화됩니다.
• 협업 기반: 역할 간 협업을 위해서는 효율적인 통신을 위해 동일한 런타임 환경에 있어야 합니다.

2) 5개의 느슨한 봇이 아닌 5개의 병렬 에이전트

제 5개의 고정 역할은 다음과 같습니다:

• Commander (zongzhihui): 전반적인 상황 인식, 작업 분해, 할당, 수정 및 종료를 담당합니다.
• Strategist (junshi): 전략 분석, 제안 평가 및 위험 예측을 담당합니다.
• Engineer (engineer): 기술 실행, 코드 구현 및 시스템 유지 관리를 담당합니다.
• Creator (creator): 콘텐츠 제작, 표현 최적화 및 외부 출력을 담당합니다.
• Thinker (zhiku): 지식 감사, 품질 관리 및 규정 준수 확인을 담당합니다.

각 에이전트는 workspace-engineer, workspace-junshi 등과 같은 자체 작업 공간을 가지고 있습니다. 성격 파일, 규칙 파일, 메모리 파일 및 스크립트 자산은 모두 독립적이며 서로 오염되지 않습니다.

3) 멀티 채널 듀얼 스택 액세스: Discord + Telegram

동일한 게이트웨이가 Discord와 Telegram 모두에 연결됩니다. 각 역할은 두 채널 모두에 accountId 수준의 바인딩을 가지고 있습니다. 물론 이 동일한 구성 파일을 사용하여 Lark, WeChat 등 더 많은 플랫폼을 통합할 수 있습니다.

이는 "플랫폼 간 중복 배포"가 아니라 "동일한 두뇌 클러스터, 다른 액세스 레이어"입니다. 저는 Discord를 주요 협업 전장으로 구성했습니다.

여러 에이전트가 그룹 내에서 협력하고 협업하도록 하려면 Discord를 선택하세요. 하나의 플랫폼으로 충분합니다. 다른 플랫폼은 완벽하지 않습니다. 제가 직접 시도해 봤습니다!!!

2. 라우팅 레이어: "계정"을 "역할"에 매핑하는 바인딩

이것은 전체 시스템의 진입 로직입니다.

이중 채널에 대한 명시적인 바인딩 전략을 구성했습니다: channel + accountId -> agentId.

구체적으로는 다음과 같습니다:

• discord + zongzhihui -> zongzhihui
• discord + engineer -> engineer
• telegram + creator -> creator
• ... 총 10개의 매핑(5개 역할 × 2개 채널)

왜 이렇게 할까요?

시스템이 진입 레이어에서 "이 메시지를 누가 처리해야 하는지" 결정하기 때문입니다. 모든 에이전트가 듣고 서로 대답하려고 난투를 벌이는 것을 방지합니다. 이 단계가 제대로 수행되지 않으면 이후의 모든 협업이 혼란스러워집니다.

바인딩은 이 시스템의 "접수 데스크 분류"라고 생각하면 됩니다. 메시지가 들어오면 먼저 어떤 채널과 계정이 수신했는지 확인한 다음, 해당 역할로 직접 라우팅합니다. 깔끔하고 효율적입니다.

3. 세션 격리: 개인 채팅이 섞이지 않고 그룹 채팅이 혼란스럽지 않은 이유

이것은 제 시스템에서 가장 중요한 엔지니어링 포인트 중 하나입니다.

핵심 구성: session.dmScope = per-account-channel-peer

이 매개변수는 다음을 의미합니다: 개인 채팅 컨텍스트는 "계정 + 채널 + 피어 사용자"의 세 가지 차원으로 격리됩니다.

왜 이것을 선택했을까요?

• 같은 사람이 Discord와 Telegram을 통해 같은 역할에 접촉하더라도 컨텍스트가 섞이지 않습니다.
• 다른 사용자가 같은 역할에 접촉하더라도 컨텍스트가 완전히 격리됩니다.
• 멀티 에이전트 + 멀티 계정 시나리오에서 "크로스 토크"의 위험이 최소화됩니다.

즉, 저는 단순히 "멀티 역할"을 만든 것이 아니라 "컨텍스트 격리 전략 엔지니어링"도 수행했습니다.

많은 사람들이 멀티 에이전트 시스템을 구축할 때 역할은 명확히 구분하지만 컨텍스트 관리는 엉망입니다. 사용자 A의 개인 채팅 내용이 사용자 B의 답변에 포함되거나 Discord 대화 메모리가 Telegram 컨텍스트를 오염시킵니다.

per-account-channel-peer는 OpenClaw가 멀티 계정 시나리오에 권장하는 격리 전략이며, 제 테스트 결과 실제로 가장 안정적인 선택임을 확인했습니다.

4. 그룹 채팅 오케스트레이션: 규칙 기반 협업, 자유로운 대화가 아님

이 부분이 가장 흥미롭고 함정도 가장 많습니다.

핵심 전략: Commander 전역 수신 + 다른 역할 @ 트리거

Discord 측의 그룹 채팅 전략은 다음과 같습니다.

Commander: requireMention = false (전역 수신)

• 기본적으로 그룹의 모든 메시지를 볼 수 있습니다.
• 전체 상황을 파악하고 협업이 필요한지 판단하며 작업 분해 및 할당을 담당합니다.

다른 4개 역할: `requireMention = true` (@ 트리거)

• 명시적으로 @멘션된 경우에만 작동합니다.
• 노이즈를 줄이고 서로 말을 가로채는 상황을 방지합니다.

각 역할에는 `mentionPatterns`가 구성됩니다.

• 예를 들어 엔지니어는 @Engineer 또는 [@engineer](https://x.com/@engineer)로 트리거될 수 있습니다.
• 그룹 내 소환이 더 안정적이고 예측 가능해집니다.

이 조합의 본질은 무엇일까요?

• Commander는 "큰 그림"을 봅니다. 마치 팀의 PM과 같습니다.
• 전문 역할은 "필요 시 트리거"됩니다. 마치 각 부서의 전문가와 같습니다.
• 그룹 발언이 "자유 형식"에서 "통제된 릴레이"로 변경됩니다.

실제 효과: 그룹에서 질문을 하면 Commander가 먼저 작업 유형을 판단한 다음 해당 역할을 @멘션하여 처리합니다. 역할이 완료되면 Commander가 루프를 종료합니다. 전체 과정은 실제 팀이 회의를 하는 것과 같습니다.

5. Discord vs Telegram: Discord가 주요 전장인 이유

엄밀히 말해 "Discord에서만 협업할 수 있다"는 것은 아닙니다. 단지 현재 제 구성에서 Discord가 다중 역할 공개 협업 오케스트레이션에 가장 적합하다는 뜻입니다.

구체적인 이유:

1. Discord에 5개의 병렬 계정과 명확한 @협업 메커니즘을 구성했습니다.
2. 역할 정체성, 대화 체인 및 릴레이 프로세스가 모두 표시되어 팀 토론처럼 보입니다.
3. Commander 전역 수신 + 다른 역할 멘션 게이트 전략은 그룹 채팅 시나리오에서 더 직관적입니다.
4. 현재 Discord의 groupPolicy를 open으로 설정하여 더 높은 유연성을 제공합니다.

Telegram 측에서는 전략이 allowlist + mention gate에 가깝습니다. 더 제한적이고 안전하며 "통제된 프로덕션 채널"에 적합합니다.

요약하자면: Discord는 협업 무대입니다.

6. 구성 레이어 + 프롬프트 레이어: 이중 트랙 거버넌스

이것은 이 시스템이 "단순히 가지고 노는 것"과 가장 큰 차이점입니다.

저는 구성에만 의존하지 않으며 프롬프트에만 의존하지도 않습니다. 두 개의 중첩된 트랙을 사용합니다.

A. 구성 트랙 (플랫폼 수준 제어)

이는 OpenClaw 플랫폼 수준의 하드 구성입니다:

• 채널 정책: groupPolicy, dmPolicy, 그룹 및 개인 채팅의 기본 전략을 제어합니다.
• requireMention: 기본적으로 응답하기 위해 @멘션되어야 하는 사람을 지정합니다.
• bindings: 메시지 라우팅 매핑.
• dmScope: 세션 격리 세분성.
• agentToAgent 핑퐁 제한: 0으로 설정하여 에이전트 간의 의미 없는 왕복을 직접 억제합니다.

마지막 항목은 매우 중요합니다. 에이전트 간 핑퐁을 제한하지 않으면 그룹에서 두 AI가 서로 예의를 차리며 확인하고 무한 루프에 빠지는 것을 보게 될 것입니다. 0으로 설정하면 시스템에 에이전트가 자동으로 서로 핑을 보내지 않아야 함을 알립니다.

B. 규칙 트랙 (행동 수준 제어)

이는 각 작업 공간에 작성한 규칙 파일입니다:

• SOUL.md: 역할의 영혼 파일 – 성격, 어조, 책임 및 출력 품질 최저 기준.
• AGENTS.md: 운영 매뉴얼 – 협업 확인 프로세스, 메모리 읽기/쓰기 규범 및 지연 로딩 전략.
• ROLE-COLLAB-RULES.md: 역할별 협업 경계 및 금지 사항.
• TEAM-RULEBOOK.md: 팀을 위한 통합 하드 규칙 (모든 역할이 공유).
• TEAM-DIRECTORY.md: 역할을 실제 ID에 매핑하는 테이블로, @멘션 실수를 방지합니다.

이 두 트랙을 중첩시키는 효과는 다음과 같습니다: 플랫폼 레이어가 흐름을 제한하고 + 행동 레이어가 제약 조건을 추가합니다.

모델의 "자기 인식"에 모든 것을 맡기는 것이 아닙니다. 모델은 실수하고, 표류하며, 규칙을 잊어버립니다. 따라서 먼저 구성 레이어에 하드 제약 조건을 설정하고 그 다음 프롬프트 레이어에 소프트 가이드를 제공해야 합니다. 이중 안전 장치입니다.

7. 작업 공간 파일 시스템: 각 역할의 "독립 사무실"

각 작업 공간의 파일 구조는 기본적으로 일관됩니다. 이는 제가 각 역할에 대해 파일을 무작위로 쌓는 것이 아니라 표준화하고 있음을 보여주기 때문에 중요합니다.

표준 파일 구조

8. 메모리 시스템: 지연 로딩 + 계층화 + 아카이빙

메모리 관리는 멀티 에이전트 시스템에서 가장 간과하기 쉽지만 가장 문제가 많은 부분입니다.

제 전략은 "가능한 한 많이 기억하는 것"이 아니라 명확한 계층화입니다:

1) 단기 로그 (일일 메모리)

• 당일의 작업 프로세스, 컨텍스트 조각 및 현장 결정을 기록합니다.
• 파일은 날짜별로 이름이 지정되어 자연스럽게 타임라인이 생성됩니다.

2) 장기 메모리 (MEMORY.md)

• 안정적인 선호도, 장기 결정, 재사용 가능한 경험 및 하드 규칙을 추출합니다.
• 모든 것이 들어가는 것은 아니며, 검증되고 안정적인 정보만 기록됩니다.

3) 그룹 장기 메모리 (GROUP_MEMORY.md)

• 그룹의 재사용 가능하고 안전한 정보만 유지합니다.
• 개인 채팅 내용이 섞이지 않습니다. 이것은 개인 정보 보호의 레드라인입니다.

4) 콜드 아카이빙 (archive)

• 오래된 데이터는 주기적으로 아카이브되어 활성 컨텍스트가 통제 불능으로 확장되는 것을 방지합니다.
• 삭제되는 것이 아니라 우선순위가 낮은 저장소로 이동됩니다.

5) 검색 메커니즘 (memory_search + memory_get)

• 먼저 의미론적 검색을 수행한 후 정확하게 읽습니다.
• 전체 로딩을 방지합니다. 컨텍스트 창은 제한된 리소스이므로 낭비할 수 없습니다.

이 계층화의 핵심 가치는 다음과 같습니다:

• 개인 채팅 품질이 그룹 채팅 기록에 의해 오염되지 않습니다.
• 그룹 협업이 개인적인 개인 컨텍스트에 의해 방해받지 않습니다.
• 컨텍스트 창은 "필요할 때 로드"되며 "완전히 주입"되지 않습니다.

저는 컨텍스트 예산을 리소스 관리 문제로 취급합니다. 토큰은 유한하며, 모든 메모리가 들어가면 추론 공간을 차지합니다. 따라서 모든 부분을 신중하게 계산해야 합니다.

9. 개인 모드 vs 그룹 모드: 동일한 역할에 대한 두 가지 전략

이것은 많은 사람들이 생각하지 못하는 부분입니다. 동일한 역할이 개인 채팅과 그룹 채팅에서 다르게 행동해야 한다는 것입니다.

각 역할의 SOUL.md에서 두 가지 모드를 명시적으로 구분합니다:

개인 모드:

• 각 역할은 독립적인 전문가로 행동하며 사용자 문제를 처음부터 끝까지 처리합니다.
• 협업 프로세스가 필요 없으며 직접 완전한 답변을 제공합니다.
• 품질 기준은 "한 사람이 처리할 수 있음"입니다.

그룹 모드:

• 팀 협업 프로토콜에 따라 증분 릴레이를 수행합니다.
• 각 역할은 자신이 잘하는 부분만 담당합니다.
• Commander는 연결 및 종료를 담당합니다.

각 역할별 구체적인 사항:

• Commander: 그룹에서 기본적으로 침묵하며 관찰하고, 필요할 때만 강력하게 개입하여 다른 사람의 말을 가로채지 않도록 합니다.
• Engineer: 결과물은 실행 가능하고, 검증 가능하며, 롤백 가능해야 합니다. 단순히 아이디어를 제공하는 것이 아닙니다.
• Strategist: 결론에는 가정과 검증 경로가 포함되어야 합니다. 즉흥적으로 내놓는 것이 아닙니다.
• Thinker: 감사는 문제 등급 지정 + 수리 계획을 제공해야 합니다. 단순히 "문제가 있습니다"라고 말하는 것이 아닙니다.
• Creator: 표현이 진정성과 실행 가능성을 희생해서는 안 됩니다. 단순히 미학을 추구하는 것이 아닙니다.

이것이 "동일한 역할이 다른 시나리오에서 다르게 수행하는" 이유입니다. 모델의 자체 판단에 의존하는 것이 아니라 규칙 파일을 통해 명시적으로 알려줍니다.

마지막 말

멀티 에이전트는 단순히 봇 몇 개를 더 여는 것이 아닙니다. 아키텍처 설계, 라우팅 전략, 세션 격리, 협업 오케스트레이션, 메모리 관리, 규칙 거버넌스 및 자동화된 검사에 이르기까지 모든 레이어를 신중하게 설계해야 하는 전체 엔지니어링 시스템입니다.

OpenClaw는 훌륭한 기반을 제공하지만, "실행 가능한" 상태에서 "잘 실행되는" 상태로 가기 위한 엔지니어링 작업량은 대부분의 사람들이 상상하는 것보다 훨씬 많습니다.

비슷한 작업을 하고 계시다면 이 글이 약간의 참고 자료가 되기를 바랍니다. 물론 이 내용은 시작에 불과합니다. 앞으로 몇 개의 글을 더 게시하여 더 "구체적이고 세밀한" 문제들을 공유할 예정입니다.