오픈클로(OpenClaw) Multiplayer 공식 발표 — 팀 하나에 에이전트 하나, 업무 자동화에 실제로 달라지는 6가지 (11/5)

OpenClaw Multiplayer 공식 발표 대표 이미지 OpenClaw 공식 블로그 ‘Shattering Silos with OpenClaw Multiplayer’ 대표 이미지. (출처: openclaw.ai/blog)

📌 한줄 요약: 2026년 11월 5일, OpenClaw가 Multiplayer를 공식 발표했습니다. 요지는 단순합니다. 팀 전체가 하나의 게이트웨이, 하나의 에이전트, 같은 세션을 공유하고, 그 위에 역할(role)·귀속(attribution)·게스트 만료·읽기 전용 공유로 통제를 얹는 구조입니다. 개인용 자동화를 팀 단위 자동화로 옮기려는 쪽이라면, 이번 발표는 “기능 추가”보다 운영 방식의 변경에 가깝습니다.

이 글에서 다루는 것

2026년 11월 5일 발표의 성격과 실제 데모 내용
Multiplayer가 기술적으로 무엇을 공유하고, 무엇을 공유하지 않는지
업무 자동화 운영에 영향이 있는 6가지 변경점
솔직한 장점과 아쉬운 점
팀 도입 전에 반드시 확인해야 할 체크리스트

무슨 일이 있었나 — 11월 5일, GitHub Universe에서

OpenClaw 공식 블로그에 2026년 11월 5일자로 「Shattering Silos with OpenClaw Multiplayer」 글이 올라왔습니다. 작성자는 Joe Pishgar, 분량은 7분 읽기 수준입니다.

글의 문제 제기는 꽤 현실적입니다. 조직에 AI 에이전트가 퍼지면서 부서마다 각자 에이전트, 각자 모델, 각자 프롬프트를 쓰게 됐고, 그 결과 “협업해야 할 때” 컨텍스트가 사라진다는 겁니다. 엔지니어링은 GPT, 다른 팀은 Claude, 어딘가는 로컬 모델을 돌리는 식으로 갈라지면, 결국 누군가가 “내가 에이전트한테 뭘 시켰고 뭐가 나왔는지”를 다시 설명해야 합니다. 그 설명 과정에서 핵심이 유실되고, 지시가 뒤틀리고, 변경이 충돌합니다.

발표 현장은 샌프란시스코 GitHub Universe였습니다. 데모는 이렇게 진행됐다고 합니다.

두 대의 노트북을 같은 OpenClaw 에이전트에 연결
큰 화면에는 Fort Mason 일대의 실시간 3D 렌더링
관람객이 첫 번째 노트북에 “Add the Statue of Liberty” 입력
입력하는 동안 두 번째 노트북에 글자가 실시간으로 나타남
두 번째 노트북에서 “Make that three times bigger.” 입력 → 같은 객체가 3배로 커짐

핵심은 마지막 부분입니다. “그 객체”가 무엇인지 설명하지 않아도, 이전 프롬프트를 복사하지 않아도, 대화를 요약해 붙여넣지 않아도 됩니다. 같은 컨텍스트를 두 사람이 동시에 들고 있는 상태이기 때문입니다. 요청은 공유 큐를 통해 조율되므로, 에이전트가 바쁜지도 눈으로 확인할 수 있습니다.

OpenClaw Multiplayer 문서 대표 이미지 OpenClaw 공식 문서(docs.openclaw.ai) Multiplayer 페이지 대표 이미지. (출처: docs.openclaw.ai)

그리고 발표문에서 눈에 띄는 문장 하나 — “Oh, and it’s free.” OpenClaw는 비영리 재단이 개발하는 MIT 라이선스 오픈소스이고, 모델은 사용자가 가져오는(BYO) 구조입니다. 발표문 기준 포크 수는 83,000개, 재단 내부에서는 50명 이상이 같은 공유 환경에서 협업 중이라고 밝히고 있습니다.

한 가지 짚고 갈 부분이 있습니다. 공유 세션과 멀티유저 모드 자체는 8월 30일 OpenClaw 2.0에서 이미 첫선을 보였습니다. 이번 11월 5일 발표는 완전히 새로운 기능의 등장이라기보다, 그 기능을 ‘Multiplayer’라는 제품 표면으로 정리하고, 팀 단위 배포 가이드를 문서로 확정한 사건에 가깝습니다. 이 차이를 알고 읽으면 과대평가를 피할 수 있습니다.

참고로 같은 날 2026.11.1 정식 릴리스도 배포됐습니다. 다만 내용은 설정 저장 안전성, 업데이트 복구, 채널 응답 안정화 같은 수정 중심이라 이 글에서는 따로 다루지 않습니다.

Multiplayer가 실제로 하는 일 — “설정이지, 별도 에디션은 아니다”

공식 문서의 정의는 명확합니다. OpenClaw은 두 가지 형태로 돌아갑니다.

구분	개인용 클로(personal claw)	멀티플레이어 클로(multiplayer claw)
게이트웨이	1인 1대	팀이 공유하는 1개
사용자	본인	팀 채팅에서 봇으로 참여
세션	개인 세션	여러 명이 열고 조종(take over)하는 공유 세션
통제	사실상 없음	이름 있는 역할(role)로 범위 제한
설치 형태	동일 제품	동일 제품 (설정 차이)

즉 “Multiplayer 에디션을 따로 사는” 구조가 아닙니다. 같은 바이너리에 역할·신원·공유 세션 설정을 얹는 것입니다. 이건 유료 티어가 생긴 게 아니라는 뜻이기도 합니다.

공유되는 것

워크스페이스와 에이전트: 팀이 쓰던 Slack·Teams·Discord·Telegram·Google Chat 방에 봇으로 들어갑니다. 그룹 채널은 기본이 allowlist + 멘션 필요, DM은 최초 1회 페어링 코드 승인입니다.
세션: 채널에서 시작된 대화가 곧 팀이 열 수 있는 세션이 됩니다. 다른 사람이 이어받고, 다음 턴을 조종할 수 있습니다.
프레즌스(presence): 누가 보고 있고 누가 타이핑 중인지 보입니다. 단, 작성 중인 초안은 모델에도, 트랜스크립트에도 전달되지 않습니다.
모델 계정(선택): 팀원이 Settings → Profile → Connected accounts에서 개인 프로바이더 계정을 붙일 수 있고, 그 사람의 새 세션은 그 계정을 우선 사용합니다. 게이트웨이 전역 기본값을 바꾸지는 않습니다.

공유되지 않는 것 — 여기가 더 중요합니다

문서가 강조하는 건 “하나의 게이트웨이는 하나의 트러스트 경계”라는 점입니다. 툴이 활성화된 에이전트에게 메시지를 보낼 수 있는 사람은 그 에이전트의 위임된 툴 권한을 함께 쓰는 것이고, 운영자 접근 권한을 가진 사람은 하나의 컨트롤 플레인을 공유합니다.

세션 소유권·프레즌스·역할은 협업용 가드레일이지, 적대적 사용자 사이의 격리가 아닙니다. 문서가 직접 “서로 신뢰하지 않는 사람이나 조직에 서비스하려면 테넌트별로 게이트웨이를 따로 돌려라(가능하면 OS 사용자나 호스트도 분리)”고 못 박습니다. 이 문장은 팀 도입 판단에서 가장 먼저 봐야 할 대목입니다.

업무 자동화 운영에 영향이 있는 6가지

① 팀 단위 에이전트 = 자동화의 단위가 사람에서 팀으로

지금까지 자동화 파이프라인은 대체로 “내 계정, 내 크론, 내 워크스페이스”였습니다. Multiplayer는 이 단위를 팀으로 옮깁니다. 같은 에이전트가 같은 워크스페이스에서 돌기 때문에, 한 사람이 만든 자동화를 다른 사람이 이어받을 때 컨텍스트 재구성이 필요 없습니다. 인수인계 문서를 따로 쓰지 않아도 세션 자체가 인수인계 자료가 되는 셈입니다.

② 세션에 3층 귀속 — creator / owner / prompter

공유 세션에는 세 가지 층위의 기록이 붙습니다.

불변의 생성자(creator): 세션을 만든 사람
지정 가능한 소유자(owner): GitHub 이슈처럼 세션 컨텍스트 메뉴에서 지정
실제로 프롬프트를 넣은 사람들의 이력

“누가 만들었나”와 “누가 책임지나”와 “누가 실제로 조작했나”를 분리한 설계입니다. 팀 자동화에서 가장 자주 터지는 문제가 “이거 누가 돌린 거죠?”인데, 그 질문에 세션 자체가 답을 갖게 됩니다.

③ 이름 있는 운영자 역할(role)로 권한을 깎을 수 있음

가장 실무적인 변화입니다. 인증된 프로필에 정책을 묶을 수 있습니다.

{
  gateway: {
    roles: {
      default: "guest",
      definitions: {
        maintainer: {
          sessions: { others: "write" },
          agents: ["roboclaw"],
          scopes: ["operator.read", "operator.write", "operator.approvals"],
        },
        guest: {
          sessions: { others: "view" },
          agents: ["roboclaw"],
          scopes: ["operator.sessions.write"],
          sandbox: "required",
        },
      },
    },
  },
}

포인트는 operator.read / operator.write가 게이트웨이 전역 권한이라는 점입니다. 채널 전송, 노드·컴퓨터 제어, 로그, 사용자 디렉터리까지 딸려옵니다. 게스트에게는 세션 전용인 operator.sessions.write만 주고, 필요하면 sandbox: "required"로 샌드박스를 강제하는 게 문서의 권장 조합입니다.

역할 부여는 users.setRole 게이트웨이 메서드로 하고, 역할 변경 시 해당 사용자의 활성 연결이 끊기므로 재접속이 필요합니다.

④ Git co-author 크레딧과 PR-세션 연결

코딩 작업에서 체감이 큰 부분입니다. 검증된 GitHub 신원을 붙이고 Git co-author credit을 켜면, 공유 세션에서 나온 커밋에 조종한 사람들의 Co-authored-by 트레일러가 붙습니다. 생성된 PR은 세션으로 역링크되므로, 리뷰어가 “이 diff가 어떤 대화에서 나왔는지” 읽을 수 있습니다.

자동화가 만든 변경을 사람이 리뷰해야 하는 조직이라면, 이 연결고리는 꽤 실질적입니다.

⑤ 게스트 초대와 자동 만료 — Visitor Access

외부 협력자에게 열어줘야 하는 경우를 위해 Visitor Access 플러그인이 문서에 등장합니다. 동작은 이렇습니다.

전용 Access 허용 정책 하나를 관리
초대된 이메일 또는 검증된 GitHub 계정을 정책에 추가
부여가 만료(기본 14일)되거나 철회되면 게이트웨이 접근이 끝남

주의할 점도 명시돼 있습니다. Visitor Access를 쓰려면 gateway.roles.default가 제한된 guest 역할이어야 하고, 기본 역할을 바꾸기 전에 직원 전원에게 명시적 역할을 먼저 부여해야 합니다. 안 그러면 팀원이 전부 “방문자”가 되어 접근이 끊깁니다.

개인 게이트웨이의 특정 세션을 팀에 “보여주기만” 하고 싶을 때는 Session Share를 씁니다.

소스 쪽에서 그룹(예: Team)을 명시해 플러그인 활성화
노드를 읽기 전용 세션 명령 2개로만 페어링 (openclaw.sessions.list.v1, openclaw.sessions.read.v1)
서브에이전트와 인코그니토 세션은 자동 제외
그룹에서 빼면 새 읽기는 즉시 차단, 다만 이미 읽은 텍스트를 회수할 수는 없음

“보여주되 넘겨주지 않는다”는 경계를 명시적으로 만든 게 인상적입니다. 문서도 마지막 문장을 정직하게 써뒀습니다 — 권한 회수는 미래의 읽기를 막을 뿐, 과거의 읽기를 되돌리지 못한다고.

배포 관점에서 달라진 것 — 문서가 “운영”을 다루기 시작했다

이번 문서에서 실무자에게 더 중요한 건 기능 목록이 아니라 프로덕션 배포 장(章)입니다. 요약하면 이렇습니다.

서비스 계정 하나로 설치, 게이트웨이는 기본이 루프백 바인딩. 팀 접근은 공인 바인딩이 아니라 인증된 인그레스로 줍니다. 권장은 Tailscale Serve(개인별 테일스케일 신원) 또는 Cloudflare Access(신원 인지 프록시). 토큰·비밀번호 공유는 소규모 팀엔 되지만 전원이 하나의 owner 프로필을 쓰게 되어 “누가 했는지”가 사라집니다.
관리자 부트스트랩: Access로 최초 로그인하면 프로필이 생기고, 초기 역할은 observer입니다. 로컬 유지보수 셸에서 openclaw users list --json → users.setRole로 administrator를 부여합니다. 기본 역할을 임시로 관리자로 올려 부트스트랩하지 말라고 명시돼 있습니다.
스토리지 설계: 상태 디렉터리(~/.openclaw)는 XFS/ext4, 관리형 워크트리는 Btrfs나 XFS reflink. Btrfs에서 커밋이 파일시스템 전역으로 걸리면 SQLite 읽기·쓰기가 대기해서 단일 커밋이 수 분 걸린 사례까지 측정됐다고 적혀 있습니다.
위젯은 별도 샌드박스 오리진으로 분리. 채팅 페이지가 정상이라고 위젯 iframe이 뜬다는 보장은 없다고 못 박습니다.
검증 절차: openclaw config validate --json, openclaw gateway status --deep, openclaw security audit을 서비스 소유자로 실행하고, 서로 다른 실제 계정 2개로 역할·프레즌스·세션 링크를 확인하라고 요구합니다. Access 리다이렉트만 보고 “된다”고 판단하지 말라는 문장이 특히 좋습니다.

OpenClaw Multiplayer 공유 세션 실제 화면 재단이 team.openclaw.ai에서 실제로 쓰는 멀티플레이어 클로의 저장소 작업 세션(분석·테스트 결과·발행된 PR). (출처: docs.openclaw.ai/start/multiplayer)

솔직한 장점

1) “컨텍스트 재구성 비용”을 직접 겨냥했다. AI 에이전트 도입에서 실제로 비용이 새는 지점은 모델 요금보다 사람이 대화를 다시 설명하는 시간입니다. 공유 세션은 이 비용을 구조적으로 없앱니다. 데모가 화려해서가 아니라, 문제 정의가 정확해서 설득력이 있습니다.

2) 통제 장치가 “기능”이 아니라 “설정”으로 제공된다. 역할·스코프·샌드박스 강제·게스트 만료가 전부 설정 파일과 CLI로 떨어집니다. 별도 관리 콘솔이나 유료 플랜을 사야 하는 구조가 아니라는 점이, 팀 규모가 작은 조직에는 특히 유리합니다.

3) 무료·MIT·모델 중립. 비영리 재단, MIT 라이선스, BYO 모델. 팀 단위로 쓰려면 사용자당 과금이 붙는 SaaS가 일반적인데, 이 조합은 비용 예측이 쉽습니다.

4) 귀속(attribution)이 자동으로 남는다. creator/owner/prompter 3층 기록 + 커밋 co-author 트레일러. 감사(audit) 요구가 있는 조직에서 “나중에 붙이는” 게 아니라 처음부터 남는 구조입니다.

아쉬운 점 / 한계

1) 격리가 아니다. 문서가 스스로 말합니다. 한 게이트웨이는 한 트러스트 경계이고, 역할은 가드레일이지 방어벽이 아닙니다. 서로 신뢰하지 않는 조직·고객사를 한 게이트웨이에 몰아넣는 용도가 아닙니다. 이걸 오해하면 사고가 납니다.

2) 게스트는 여전히 “전부 읽을 수 있다”. sessions.others: "view"인 게스트는 툴 출력까지 포함해 모든 공유 세션을 읽습니다. 민감한 작업은 드래프트 세션에 두라는 안내가 붙는 이유입니다. 세션 단위 세밀한 열람 제어를 기대하면 안 됩니다.

3) 초기 설정 난이도가 낮지 않다. Cloudflare Zero Trust, 터널, Access 정책, OIDC, GitHub 신원 동기화, 역할 부트스트랩. “5분 만에 팀 협업”은 아닙니다. 개인용으로 쓰던 사람이 팀용으로 넘어갈 때 여기서 대부분 멈춥니다.

4) 공유 계정 리스크가 남는다. 게스트 PR은 공유 GitHub 계정으로 발행됩니다. 문서는 base 브랜치 보호 규칙과 origin을 포크로 두기(PR 워크플로에 저장소 시크릿이 넘어가지 않도록)를 권고합니다. 이 두 가지를 안 하면 자동화가 곧 권한 사고가 됩니다.

5) 문서가 방대하다. Multiplayer 한 페이지가 8단계 프로덕션 배포와 트러블슈팅 표까지 포함합니다. 친절하지만, 처음 읽는 사람에게는 진입 장벽처럼 느껴질 분량입니다.

도입 전 체크리스트

팀원들이 서로 신뢰하는 한 경계인가? 아니라면 게이트웨이를 테넌트별로 분리했는가?
공유 세션에 들어가면 안 되는 데이터(인사·계약·자격증명)가 있는가? 있다면 드래프트 세션 정책을 정했는가?
신원 기반 인그레스(Tailscale Serve / Cloudflare Access)를 쓸 수 있는가? 공유 토큰으로 시작한다면 “귀속”을 포기한다는 뜻을 인정했는가?
역할 설계: administrator / member / observer / guest 중 누구에게 어떤 스코프를 줄지 표로 정했는가?
게스트에게 sandbox: "required"를 강제했는가? 샌드박스에 없는 경로를 확인했는가?
공유 GitHub 계정의 base 브랜치 보호와 origin(포크) 설정을 마쳤는가?
openclaw security audit을 돌리고 지적 사항을 해소했는가?
스토리지: 상태 디렉터리와 워크트리를 분리했는가? Btrfs 커밋 지연을 감수할 수 있는가?
백업: openclaw backup create --verify로 검증본을 만들고, 서버 장애 도메인 밖에 보관했는가?

마무리 — 누구에게 추천하나

정리하면 이렇습니다.

추천: 이미 OpenClaw를 개인 자동화에 쓰고 있고, 팀 3~20명이 같은 워크스페이스에서 같은 에이전트를 쓰고 싶은 조직. 특히 “누가 어떤 지시로 이 결과가 나왔는지” 추적이 필요한 개발·운영 팀.
비추천: 서로 다른 고객사를 한 인스턴스로 서비스해야 하는 곳(테넌트 분리 필요), 당장 오늘 설정을 끝내야 하는 곳(배포 난이도가 있습니다), 세션 단위 세밀한 열람 통제가 필수인 곳.
관망: 아직 개인용으로도 자동화가 자리 잡지 않았다면, Multiplayer는 나중 문제입니다. 공유할 컨텍스트가 먼저 있어야 공유할 이유도 생깁니다.

가성비로 보면 계산이 단순합니다. 사용자당 과금이 없고, MIT 라이선스이며, 모델은 원하는 걸 가져오면 됩니다. 대신 그 대가로 설정과 운영 책임이 전부 팀에게 넘어옵니다. 무료가 공짜는 아닌 전형적인 오픈소스 구조이고, 이번 문서는 그 책임을 어떻게 질지 상당히 구체적으로 적어두었습니다.

팀 단위로 AI 에이전트를 굴리면서 “각자 따로 쓰니까 오히려 일이 늘었다”는 느낌을 받고 있다면, 이번 발표는 한 번 읽어볼 가치가 있습니다. 최소한 어디까지가 공유이고 어디부터가 격리인지를 문서가 명시해줬다는 점만으로도, 도입 검토의 기준선은 생겼습니다.

참고 자료

OpenClaw Blog, 「Shattering Silos with OpenClaw Multiplayer」 (2026-11-05) — openclaw.ai/blog/shattering-silos-with-openclaw-multiplayer
OpenClaw Docs, 「Multiplayer」 — docs.openclaw.ai/start/multiplayer
GitHub Releases, openclaw 2026.11.1 (2026-11-05) — github.com/openclaw/openclaw/releases