결론부터 말씀드리겠습니다. 하나의 OpenClaw 게이트웨이에서 서로 다른 모델을 쓰는 에이전트 여러 대를 동시에 운영하는 건, 설정 몇 줄로 끝나는 일이 아니었습니다. 저희는 이 과정을 두 편의 글로 나눠 다뤘는데, 이번 통합 개정에서 다시 살펴보니 겹치는 내용도 많았고 게이트웨이 포트 번호처럼 서로 어긋나는 정보도 있었습니다. 이 글은 그 둘을 하나로 합치고, 틀린 부분을 고치고, 5개월 전 세웠던 다음 목표가 실제로 어떻게 됐는지까지 확인한 종합 가이드입니다.

🔍 개요 — 왜 에이전트를 여러 대 운영하는가

AI를 비서처럼 쓰려면 24시간 돌아가면서 채팅으로 말을 걸면 바로 응답하는 시스템이 필요합니다. 그것도 한 명이 아니라, 서로 다른 모델을 쓰는 여러 에이전트가 각자의 채널에서 독립적으로 움직이는 형태입니다. 이 글은 OpenClaw 게이트웨이 하나로 시월이(Gemini 기반)와 레드(Grok 기반) 두 에이전트를 동시에 운영하며 겪은 설정 과정을 정리합니다. 설정 삽질, 라우팅 원리, 중복 발화 트러블슈팅까지 전부 포함합니다.

🏗️ 전체 구조 — 하나의 게이트웨이, 두 개의 두뇌

핵심 원칙은 간단합니다. 시월이는 Gemini만, 레드는 Grok만 씁니다. 모델이 절대 섞이지 않도록 fallback까지 같은 제공자로 제한했습니다. 각 에이전트는 별도 Discord 봇 계정을 사용하며, 채널 접근이 물리적으로 분리되어 있습니다.

⚙️ openclaw.json 핵심 설정 해부

OpenClaw 멀티에이전트 설정의 핵심은 ~/.openclaw/openclaw.json의 세 섹션입니다.

1. agents — 에이전트 정의

각 에이전트의 ID, 이름, 모델, 워크스페이스를 선언합니다.

"agents": {
  "list": [
    {
      "id": "main",
      "name": "시월이",
      "workspace": "~/.openclaw/workspace",
      "model": {
        "primary": "vertex-ai/gemini-3-flash-preview",
        "fallbacks": ["vertex-ai/gemini-3-pro-preview"]
      }
    },
    {
      "id": "red",
      "name": "레드",
      "workspace": "~/.openclaw/workspace-red",
      "model": {
        "primary": "xai/grok-4-1-fast-reasoning",
        "fallbacks": ["xai/grok-4-0709"]
      }
    }
  ]
}

2. bindings — 라우팅 규칙

어떤 Discord 봇 계정이 메시지를 받으면 어떤 에이전트가 응답할지를 결정합니다. 멀티에이전트의 핵심 메커니즘입니다.

"bindings": [
  { "agentId": "main", "match": { "channel": "discord", "accountId": "siwol" } },
  { "agentId": "red", "match": { "channel": "discord", "accountId": "red" } }
]

3. channels.discord — 채널 접근 분리

각 봇 계정이 접근할 수 있는 채널을 물리적으로 분리합니다. guilds를 공통이 아닌 각 account 안에 배치하는 게 핵심입니다.

"accounts": {
  "siwol": {
    "guilds": { "서버ID": { "channels": { "시월이채널ID": { "allow": true } } } }
  },
  "red": {
    "guilds": { "서버ID": { "channels": { "레드채널ID": { "allow": true } } } }
  }
}

이렇게 하면 라우팅 흐름은 이렇습니다.

Discord 메시지 수신
  ↓
어떤 봇 계정이 수신했는가?
  ├── siwol 봇 → bindings에서 accountId="siwol" 매칭
  │   → agentId="main" (시월이, Gemini)
  └── red 봇 → bindings에서 accountId="red" 매칭
      → agentId="red" (레드, Grok)

accountId 기반 매칭이라 깔끔하게 분리됩니다. DM도 봇 계정별로 자동 분리되기 때문에, 시월이한테 DM을 보내면 시월이가, 레드한테 보내면 레드가 답합니다.

🧠 워크스페이스 — 에이전트의 영혼

각 에이전트의 성격, 기억, 행동 규칙은 워크스페이스 파일들로 정의됩니다. OpenClaw는 매 세션 시작할 때 이 파일들을 읽어 에이전트의 컨텍스트를 구성합니다.

~/.openclaw/workspace/        (시월이)
├── SOUL.md       ← 순진하고 다정한 성격, 존댓말
├── IDENTITY.md   ← 이름, 이모지(🌸)
├── USER.md       ← 사용자 정보
└── AGENTS.md     ← 행동 규칙

~/.openclaw/workspace-red/    (레드)
├── SOUL.md       ← 당돌하고 스파이시한 성격, 반말
├── IDENTITY.md   ← 이름, 이모지(🔥)
├── USER.md       ← 사용자 정보 + 경계선 설정
├── AGENTS.md     ← 행동 규칙
└── memory/       ← 날짜별 기억 기록

SOUL.md가 에이전트의 근본적인 성격을 결정합니다. 같은 프롬프트를 던져도 완전히 다른 톤으로 응답하는 이유가 이 파일 때문입니다. 이렇게 워크스페이스를 분리하면 시월이에게 한 이야기가 레드에게 새어나가지 않습니다.

🔧 트러블슈팅 — 실전에서 터진 것들

1. 중복 발화 문제. 세팅 직후, 시월이가 같은 응답을 3~4번 반복 전송하는 현상이 발생했습니다. 원인은 두 가지였습니다.

원인 A — debounce 미설정. OpenClaw은 연속 수신 메시지를 하나로 묶는 디바운스 기능이 있는데, 기본 설정에는 이 값이 빠져 있었습니다.

"messages": {
  "inbound": {
    "debounceMs": 2000
  }
}

원인 B — queue.mode 미설정. 큐 모드를 collect로 설정해서 연속 메시지를 수집 후 한 번에 처리하도록 했습니다.

"queue": {
  "mode": "collect"
}

2. 설정 오류 네 가지. 위 중복 발화 외에도, 설정 과정에서 실제로 마주쳤던 에러 메시지 기준으로 정리합니다.

3. 게이트웨이 포트 충돌 & 무한 재시작. WSL 부팅 시 systemd가 OpenClaw 서비스를 자동 시작하는데, 포트가 이미 점유된 상태에서 재시작을 시도하면 무한 루프에 빠졌습니다. 서비스 의존성 설정과 포트 해제 확인 로직 추가로 해결했습니다.

4. 포트포워딩(NAT 모드). WSL2는 NAT 모드로 동작해 외부에서 직접 접근이 안 됩니다. PowerShell 스크립트로 Windows 호스트에서 WSL 포트로 자동 포워딩을 설정했습니다.

🔌 MCP 도구 연동 — AI에게 손과 발을

에이전트가 진짜 유용하려면 말만 하는 AI가 아니라 도구를 써야 합니다. OpenClaw의 mcporter를 통해 MCP 서버들을 연결하면, 시월이와 레드가 직접 외부 서비스를 쓸 수 있습니다.

특히 Knowledge RAG는 Confluence와 Jira의 전체 문서를 청킹→임베딩→벡터DB로 구축한 시스템이라, “그때 포트 충돌 어떻게 해결했더라?” 같은 자연어 질문으로 과거 기록을 즉시 찾을 수 있습니다.

📊 운영 현황 — 2주 돌려본 결과 (2026년 2월 기준)

WSL에서 리소스 부담은 거의 없었습니다. API 기반이라 두 에이전트 합산 RAM 100~200MB, CPU는 대기 시 거의 0%였습니다.

🔄 그래서 지금은?

위 내용은 2026년 2월 기준 기록입니다. 5개월 반이 지난 지금, 실제 GitHub·공식 문서와 하나씩 대조해봤습니다.

다음 목표 — 실제로 어떻게 됐나. 당시 글은 “시월이가 코드 실행이 필요하다고 판단하면 자동으로 레드에게 넘기는” 에이전트 간 자동 핸드오프를 다음 목표로 세웠습니다. 확인 결과, 이 구상은 구상 그대로는 나오지 않았습니다. 공식 문서(docs.openclaw.ai/concepts/delegate-architecture)에 따르면 위임은 여전히 사전 정의된 정적 bindings 기반이며, 작업 내용을 보고 동적으로 판단해 넘기는 방식이 아닙니다. 에이전트 간 직접 메시징 자체는 존재하지만(docs.openclaw.ai/concepts/multi-agent), 기본값이 꺼져 있고 명시적으로 활성화 + 허용목록 등록이 필요합니다. sessions_spawn/sessions_send 같은, 상위 에이전트가 프로그래밍적으로 다른 에이전트에 위임하는 도구는 존재하지만, 이 역시 운영자가 직접 설계해야 하는 수동 구성입니다. 정리하면: 자동 분류·자동 위임이라는 비전 자체는 아직 turnkey 기능으로 나오지 않았고, 대신 수동으로 구성해야 하는 인접 도구들이 생겼습니다.

레드는 지금 어떻게 됐나. 이 부분은 GitHub로 확인할 수 있는 사실이 아니라 저희 팀 내부 기록의 문제였습니다. 재검증 과정에서 레드가 현재 팀 구성에 들어있는지 확인이 필요했는데, 저희 쪽 기억 조회로는 확인되지 않아 이 질문 자체를 Terry에게 별도로 전달해뒀습니다. 이 글에서는 시월이·레드 구성을 2026년 초 시점의 실험 기록으로 다루고, 레드의 현재 상태에 대해서는 단정하지 않습니다. 확인되는 대로 이 절을 갱신하겠습니다.

설정 항목별로는 이렇습니다.

• bindings 최상위 배치 — 지금도 그대로 유효합니다. 스키마 자체는 안정적입니다.
• debounceMs / queue.mode — 지금도 유효한 설정 키입니다. 다만 debounceMs는 이제 2000ms 기본값이 붙어 나오고, queue.mode는 당시의 collect 하나였던 옵션이 steer/followup/collect/interrupt 네 가지로 늘었습니다. 기본값이 생긴 만큼, 당시 글이 강조했던 “반드시 수동 설정” 필요성은 예전만큼 절실하지 않을 수 있습니다.
• 워크스페이스 파일 구조 — SOUL.md/IDENTITY.md/USER.md/AGENTS.md는 지금도 핵심입니다. 다만 현재 공식 문서는 TOOLS.md, MEMORY.md, HEARTBEAT.md까지 포함한 더 넓은 부트스트랩 파일 목록을 안내하고 있습니다. 이 세 파일은 당시 글에는 없던 항목입니다.
• mcporter — 변경 없이 지금도 표준 MCP 연동 도구입니다.

🧭 정리

이번 통합 개정에서 가장 중요한 것은 세 가지입니다. 첫째, 게이트웨이 포트 번호(19876 → 18789)처럼 기존 두 글이 서로 어긋나던 부분을 바로잡았습니다. 둘째, 다음 목표로 세웠던 에이전트 간 자동 핸드오프는 구상 그대로 나오지 않았지만, 수동으로 구성 가능한 인접 기능들이 생겼습니다. 셋째, 워크스페이스 부트스트랩 파일이 4종에서 최소 7종으로 늘어난 것처럼, 설정 표면 자체가 넓어졌습니다. 지금 멀티에이전트를 새로 설정하신다면 위 “openclaw.json 핵심 설정 해부” 절과 “그래서 지금은?” 절을 함께 보시길 권합니다.

📚 참고 자료

• OpenClaw GitHub
• OpenClaw 공식 문서 — Agent Bindings & Routing
• OpenClaw 공식 문서 — Gateway CLI (기본 포트 확인)
• OpenClaw 공식 문서 — Delegate Architecture
• OpenClaw 공식 문서 — Multi-Agent Messaging
• OpenClaw 공식 문서 — Agent Workspace
• OpenClaw 공식 문서 — mcporter