OpenClaw 멀티플레이어 공유 에이전트: 두 기기, 하나의 컨텍스트

두 기기에서 하나의 OpenClaw 에이전트를 함께 사용할 수 있습니다. 다만 큐는 대화 텍스트를 처리하는 장치이고, 작업을 영구 보존하는 일은 별도로 설계해야 합니다. 공유 세션이 컨텍스트를 담는다면 active-tasks.md 같은 파일은 실제로 지켜야 할 작업과 약속을 보관합니다.

핵심은 바로 이 차이입니다. OpenClaw 2.0은 v2026.8.1 릴리스로 2026년 8월 30일 발표됐으며, 하나의 공유 신뢰 영역으로 동작하는 Gateway 위에 멀티플레이어 공유 세션을 추가했습니다. 덕분에 두 대의 스마트폰이나 노트북, 혹은 두 사람이 각자 별도의 복제본을 만드는 대신 같은 실행 흐름을 함께 조작할 수 있습니다(docs.openclaw.ai). 다만 공식 문서도 소유자, 접속 상태, 역할은 협업을 위한 보조 수단일 뿐, 서로 적대적인 사용자를 격리하는 보안 기능은 아니라고 분명히 밝힙니다(docs.openclaw.ai). 문서가 설명하는 기능과 실제 사용자가 자주 부딪히는 문제는 조금 다릅니다. 대부분 큐, 세션 수명, 메모리에서 문제가 생깁니다.

소파의 스마트폰과 책상의 노트북, 실제로 어디서 꼬일까

실제로 많이 쓰이는 두 기기 조합은 두 사람이 아니라 한 사람인 경우가 많습니다. 스마트폰을 리모컨처럼 쓰고, Mac Mini나 VPS를 호스트로 두며 Telegram으로 연결하는 방식입니다. 한 사용자는 “Telegram에서 내 OpenClaw 에이전트 Monica에게 Mac Mini에 mem0를 로컬로 설치해 달라고 요청했다”고 설명했습니다(x.com).

두 번째 기기나 사용자가 같은 에이전트에 들어오면 다음 네 가지 문제가 반복해서 나타납니다.

1. 메시지가 조용히 사라진다. 커뮤니티에서 가장 뼈아픈 교훈은 체크리스트에 그대로 남아 있습니다. queue mode enabled so messages never silently drop로 큐 모드를 켜고, active-tasks.md as persistent state for crash recovery로 작업을 저장하며, 재시작 때 이를 다시 읽는 Boot.md를 함께 두라는 것입니다(x.com). 이 조합이 없으면 에이전트가 작업 중일 때 보낸 메시지는 저장된 작업 항목이 아니라 사라질 수 있는 대화 텍스트에 불과합니다.
2. 컴팩션이나 재시작 뒤 지시사항이 증발한다. 한 Reddit 사용자는 이 문제를 다음과 같이 요약했습니다.

“지속되는 작업 큐가 없습니다. 에이전트가 ‘그 일을 처리하겠습니다’라고 말하는 순간, 그것은 대화 속 약속일 뿐입니다.” — u/Brave_Nobody_6909, r/openclaw

같은 스레드에는 컴팩션이나 재시작 후 약속이 사라지고, 에이전트가 저장해 둔 런북을 무시했다는 사례가 이어집니다. 별도의 메인테이너급 설명도 같은 패턴을 지적합니다. 에이전트가 “20분 동안은 완벽하게 작동하다가” 메모리 처리를 잘못 이해하면 “지시사항을 조용히 잊고 제멋대로 움직인다”는 것입니다(x.com).

1. 사용 중 세션이 초기화된다. Telegram 채널의 기본값에는 thread: { mode: "idle", idleMinutes: 180 }이 포함된 적이 있습니다. 몇 시간 유휴 상태가 이어지면 세션이 초기화되는 설정입니다. 한 사용자는 스마트폰을 보조 화면으로 쓰던 중 이런 기억 상실을 겪고, 값을 4일로 늘렸습니다(x.com). 컨텍스트가 넘치면 상황은 더 나빠집니다. 도구를 과도하게 사용하면 마지막 메시지가 다시 주입돼 에이전트가 “같은 말에 계속 답하고”, 결국 “조용히 성능이 떨어지는” 현상이 나타날 수 있습니다(x.com).
2. 멀티플레이어가 시작되기도 전에 페어링이 끊긴다. 한 업그레이드 뒤 페어링된 기기에서 operator.read/operator.write 권한이 사라지면서 도구가 작동하지 않고 무한 페어링 루프에 빠진 사례가 있었습니다. 창업자는 “잠재적인 보안 문제를 고치려다 너무 과하게 대응한 것이 제 실수였다”고 답했습니다(x.com). 중국어권 사용자들도 1008: pairing required 오류를 겪었습니다. 로컬 기기가 Pending 큐에 멈춰 있다가 openclaw devices list와 devices approve <UUID>를 실행해야 풀리는 방식입니다(x.com).

Presence 기능은 누군가 입력 중인지 보여주지만, 큐에 들어간 메시지를 저장된 작업으로 바꿔 주지는 않습니다.

하나의 Gateway는 하나의 신뢰 영역이다: 공유 세션과 분리 에이전트의 차이

OpenClaw 2.0의 가장 큰 변화는 공유 세션입니다. 다른 사람이 현재 작업에 참여해도 기존 컨텍스트가 유지됩니다. 독립 리뷰들은 이를 단일 운영자용 도구에서 협업용 도구로 넘어가는 변화라고 평가했습니다(eesel.ai). 실제 구성을 결정하는 핵심 개념은 공식 문서의 두 가지 모드입니다.

멀티유저 모드는 신뢰할 수 있는 여러 사람이 하나의 에이전트를 함께 조작하는 방식입니다. 공유 세션에는 세 가지 정보가 기록됩니다. 한 번 정해지면 바뀌지 않는 생성자(createdActor, 한 번만 기록), 언제든 바꿀 수 있는 할당 소유자(GitHub assignee와 비슷한 개념), 실제로 프롬프트를 입력한 사람들의 참여 기록입니다(docs.openclaw.ai). Presence는 누가 보고 있고 입력 중인지 보여주지만, 입력 중인 초안은 모델이나 대화 기록으로 전달되지 않습니다. 여러 사람의 조작이 하나의 턴으로 합쳐질 수 있기 때문에 턴별 귀속도 명확한 보장이 아니라 최선의 추정치입니다(docs.openclaw.ai). 실제로 에이전트가 도구를 호출하는 중 두 번째 채널에서 후속 메시지를 보내면 그 메시지는 기록에 들어가지만, 실행 중인 턴이 먼저 끝납니다. 즉 두 번째 지시는 인터럽트가 아니라 다음 흐름을 조정하는 메모처럼 처리됩니다(docs.openclaw.ai).

멀티에이전트 모드는 하나의 Gateway 프로세스에서 여러 개의 격리된 두뇌를 운영하는 방식입니다. 에이전트마다 워크스페이스와 agentDir(인증 프로필, 모델 레지스트리), 그리고 <agentDir>/openclaw-agent.sqlite에 저장되는 SQLite 세션 저장소를 따로 가집니다(github.com). 각 인바운드 채널 이벤트는 바인딩 규칙에 따라 에이전트로 전달되며, 가장 구체적인 일치 항목이 우선합니다. 에이전트끼리 agentDir를 공유하면 안 됩니다. 서로의 auth-profiles.json을 덮어쓸 수 있기 때문입니다(stack-junkie.com). 간단한 예로 { agentId: "coding", match: { channel: "telegram", accountId: "coding-bot" } }는 특정 봇을 특정 에이전트로 연결합니다.

기억해야 할 한 문장은 이것입니다. “Gateway 하나는 하나의 신뢰 영역이다”(docs.openclaw.ai). 역할, 소유자 필터, 아바타만으로는 서로 적대적인 사용자를 격리할 수 없습니다. 서로 신뢰하지 않는 사용자가 있다면 Gateway를 분리하고, 가능하면 운영체제 사용자나 호스트도 분리해야 합니다.

한 사람이 두 기기를 쓰는 경우에는 왼쪽 구성을 선택하면 됩니다. 두 사람이 서로의 기록을 정기적으로 봐서는 안 된다면 오른쪽 구성이 적합합니다. 접근을 신뢰할 수 없는 사용자로부터 강제 격리해야 한다면 Gateway도 두 개로 나누세요. 하나의 봇을 부부가 공유하는 사례에 대한 Reddit 조언도 같은 방향입니다. “에이전트 2개를 만들고 인증 프로필은 같게 하되, 하나는 당신에게 맞추고 다른 하나는 아내에게 맞추라”는 식입니다(u/mr-cto-apps, r/openclaw). Telegram 봇 하나를 공유하는 다른 스레드에서도 “당신과 같은 상황이라면 대부분 두 인스턴스를 실행한다”고 조언합니다(u/dertobi, r/openclaw). 2.0에서 공유 세션이 추가된 뒤에도, 각자의 비공개 작업을 분리할 때는 여전히 유효한 조언입니다.

에이전트가 바쁠 때 두 번째 메시지는 어디로 갈까

사용자가 계속 헷갈리는 지점은 세 가지로 나눠 보면 쉽습니다. 작업이 진행 중일 때 경계에서 무엇이 사라지고 무엇이 남는지 각각 다릅니다.

첫 번째: 세션 큐. 에이전트가 작업 중일 때 보낸 텍스트는 현재 세션에 추가됩니다. 큐 모드를 켜면 메시지를 버리지 않고 기다리게 할 수 있으며, Presence로 현재 턴이 진행 중인지 확인할 수 있습니다. 이 메시지는 실행 중인 턴을 중단하는 대신 다음 턴의 방향을 조정합니다. 입력 중인 초안 미리보기는 일시적인 데이터라 컨텍스트에 들어가지 않습니다(docs.openclaw.ai). 두 번째 기기에서 보내는 메시지는 “이 작업이 끝나면 X를 해. Y는 다시 시작하지 마”처럼 짧고 분명하게 작성하세요. 여러 사용자의 입력이 하나의 조작 턴으로 합쳐질 때 턴 귀속은 최선의 추정치에 불과하기 때문입니다(docs.openclaw.ai).

두 번째: 영구 저장 작업. 큐에 들어간 메시지가 곧 영구 작업 항목인 것은 아닙니다. Gateway가 재시작되거나 세션이 컴팩션되거나 /new를 실행하면 대화 속 약속은 사라질 수 있습니다. 재시작을 견디는 커뮤니티의 해법은 메시지가 아니라 파일입니다. active-tasks.md를 장애 복구용 상태로 사용하고, 세션과 Gateway가 재시작될 때 이를 읽는 Boot.md를 두는 방식입니다(x.com). 메모리 도구로 컨텍스트를 다시 주입할 수는 있지만, 널리 공유된 한 설명은 로드된 메모리 자체도 요약 과정에서 사라질 수 있다고 경고합니다. “메모리는 디스크에 존재합니다. 에이전트가 그 메모리를 따라가며 읽는 능력을 잃었을 뿐입니다”(x.com).

세 번째: 예약 작업. Cron과 Automations는 Gateway가 실행 중일 때 작동하며, 호스트가 절전 상태에 들어가면 예약 작업도 멈춥니다(eesel.ai). 한 사용자는 Cron 실행으로 세션 기록이 컨텍스트를 가득 채워 에이전트를 “그 시간 동안 사실상 사용할 수 없게 만들었다”고 보고했습니다. 해결책으로 Telegram 토픽별 컨텍스트 분리를 권했습니다(x.com). 반복 작업에는 예약 작업을 사용하되, 후속 지시사항을 큐에 넣는 용도로 대체해서는 안 됩니다.

큐 화면이 실제 상태보다 늦게 따라오는 경우도 있습니다. 한 스레드에서는 요청이 화면에 분명히 쌓이고 있는데도 /subagents와 /tasks에는 아무것도 표시되지 않았습니다(reddit.com). 재시작 후에도 살아남아야 하는지는 큐 UI와 별개로 두 번째 버킷의 파일을 확인하세요.

지시사항을 잃지 않는 두 기기 구성

노트북과 스마트폰을 한 사람이 함께 쓰거나, 신뢰할 수 있는 두 팀원이 하나의 공유 세션을 사용할 때 적합한 구성입니다. 공식 빠른 설정과 운영 런북(docs.openclaw.ai)에 커뮤니티에서 정착한 손실 방지 설정을 더했습니다.

1. Gateway는 항상 켜진 호스트에 두고, 개인 식별 정보로 접속하세요. 소형 VPS, 사무실 Mac, Mac Mini면 충분합니다. Gateway는 loopback에 바인딩하고, 공개 포트나 공유 토큰 대신 Tailscale Serve 또는 Cloudflare Access를 앞단에 두세요. 개인 식별 정보 기반 접속을 사용해야 세션별 사용자 표시와 커밋 기여자 정보를 구분할 수 있습니다. 공유 토큰을 쓰면 모두가 같은 소유자 프로필로 인식됩니다(docs.openclaw.ai).
2. 두 기기를 서로 다른 세션이 아니라 같은 세션에 연결하세요. 각 기기에서 Control UI나 채팅 채널을 열고, 세션 소유자를 명시적으로 지정합니다(Control UI의 Assign to me / Assign to, 또는 sessions 도구의 assign_owner). 인수인계에는 @멘션을 사용하세요. DM과 그룹룸은 허용 목록을 별도로 관리해야 합니다(docs.openclaw.ai). 소유자를 바꿔도 생성자 기준의 공유 권한이나 아카이브 권한이 바뀌는 것은 아니므로 생성자는 안정적으로 유지하는 편이 좋습니다.
3. 큐를 켜고 작업을 재시작에도 살아남게 만드세요. 공유 세션을 큐 모드로 전환하면 작업 중 보낸 메시지가 경쟁하지 않고 기다립니다. 큐 모드가 없으면 메시지가 조용히 사라질 수 있다는 보고가 있습니다. 워크스페이스에 active-tasks.md를 만들고 약속 하나당 한 줄씩 상태를 기록하세요(done / doing / next). 시작 시 이를 읽도록 Boot.md에도 지시를 넣습니다(x.com). 인증 정보를 저장했다고 해서 실제 동작까지 확인된 것은 아니므로, 두 번째 기기에 의존하기 전에 모델이 응답하는지 테스트하세요(docs.openclaw.ai).
4. 스마트폰으로 연결한 채널의 세션 수명을 늘리세요. Telegram을 두 번째 화면으로 사용하고 스레드에 thread: { mode: "idle", idleMinutes: 180 } 초기화 설정이 적용돼 있다면 장시간 작업에 맞게 값을 늘리세요. 한 사용자는 4일로 설정했습니다. Cron 출력이 공유 컨텍스트를 가득 채우지 않도록 토픽도 분리하는 것이 좋습니다.
5. 각자 자신의 모델 계정을 사용하세요. Gateway 프로필에는 개인 인증 정보를 저장할 수 있습니다. 새 세션은 Gateway 기본값을 바꾸지 않고도 개인별 기본 계정을 우선 사용하며, 다른 사용자는 이메일이나 계정 ID가 아니라 사람 단위 라벨만 봅니다(docs.openclaw.ai). 인증 정보는 보호된 UI나 터미널의 숨겨진 입력을 통해 등록해야 합니다. 공유 대화 기록에 남을 수 있는 방식으로 채팅창에 붙여 넣어서는 안 됩니다.
6. 처음부터 끝까지 직접 검증하세요. 두 번째 기기에서 작업 중 메시지를 보내고, 현재 턴이 끝난 뒤 메시지가 보존되고 처리되는지 확인합니다. 그런 다음 Gateway를 재시작하고 active-tasks.md에서 약속이 복구되는지도 확인하세요. 공식 운영 체크리스트도 완료 선언 전에 전체 흐름을 검증하도록 안내합니다(docs.openclaw.ai).

공유 컨텍스트가 엉키지 않게 하는 규칙

사용자가 말하는 대부분의 컨텍스트 오염은 세 가지 규칙으로 예방할 수 있습니다.

메모리를 쓸 때마다 작성자를 남기세요. 가장 조용하지만 치명적인 문제는 출처를 알 수 없는 규칙이 쌓여 아무도 삭제하지 못하게 되는 것입니다. “공유 컨텍스트를 6개월쯤 사용하면 누구도 작성자를 추적할 수 없는 규칙으로 가득 차고, 그래서 아무도 삭제할 엄두를 내지 못한다”는 지적과 함께 “모든 메모리 기록에 작성자를 남기라”는 해결책이 제안됐습니다(x.com). 핵심은 작성자 없는 공유 기록입니다. 영구 보관할 노트에는 누가 언제 요청했는지 앞에 표시하고, 한 달에 한 번 정리하세요.

신뢰도가 낮은 사용자의 작업 공간을 격리하세요. 역할 설정으로 세션 접근 권한, 허용된 에이전트, operator 권한 범위를 제한할 수 있습니다. 게스트 세션은 workspaceAccess: "none"으로 강제 샌드박스에 넣어 파일과 셸 도구가 공유 에이전트 워크스페이스가 아닌 별도의 개인 워크스페이스를 사용하게 할 수 있습니다(docs.openclaw.ai). 비공개 초안은 Draft 세션에 보관하세요. 다른 사용자의 사이드바에는 보이지 않지만 관리자에게는 숨겨지지 않는다는 점은 기억해야 합니다(docs.openclaw.ai).

공유를 멈춰야 할 때를 알아두세요. 한 멀티에이전트 운영자는 컨텍스트 혼합을 “실무에서 가장 큰 문제”라고 부르며, 에이전트가 “서로의 영역으로 흘러 들어간다”고 말했습니다(u/BP041, r/openclaw). 중국어권 개발자들은 더 단호한 방법을 제안합니다. 하나의 에이전트를 먼저 튜닝한 뒤 기기별로 복제하고, “새 기기로 복제하도록 도와” 튜닝된 구성을 “사람마다 하나씩” 쓰는 방식입니다(x.com). 이때 동기화하는 것은 메모리와 dotfile뿐이고, 인증 정보와 실행 중인 세션은 남겨 둡니다(x.com). 이는 공식 문서가 제시하는 분리 방법과도 맞닿아 있습니다. 에이전트별 Memory Wiki vault(vault.scope = "agent")를 사용하고, 에이전트 간 대화 검색 대신 명시적으로 공유한 Markdown 디렉터리를 사용하며, 실제 격리가 필요하면 Gateway를 분리하는 방식입니다(github.com).

FAQ

두 기기에서 하나의 OpenClaw 에이전트 세션을 동시에 사용할 수 있나요?

가능합니다. 두 기기를 같은 세션에 연결하면 됩니다. 컨텍스트를 보관하는 것은 기기가 아니라 세션입니다. 소유자를 지정하고 큐 모드를 켜면 두 번째 기기에서 보낸 메시지가 대기합니다(docs.openclaw.ai).

컴팩션, /new, 재시작 뒤 지시사항이 사라지는 이유는 무엇인가요?

채팅 메시지는 저장된 작업 항목이 아니기 때문입니다. 컴팩션은 컨텍스트를 요약하고, /new는 새 세션을 시작하며, 재시작은 메모리에만 있던 상태를 버립니다. 약속은 active-tasks.md에 기록하고, 이를 다시 읽는 Boot.md를 함께 두세요(x.com).

두 사람이 하나의 에이전트를 공유해야 하나요, 아니면 한 명당 하나씩 실행해야 하나요?

두 사람이 같은 스레드, 메모리, 큐를 함께 써야 한다면 하나의 에이전트를 공유하세요. 기록, 인증 정보, 권한을 섞어서는 안 된다면 한 명당 하나의 에이전트를 실행하거나 Gateway를 각각 운영해야 합니다. 멀티유저 기능은 보안 격리를 제공하지 않습니다(docs.openclaw.ai). GitHub attribution을 설정하면 공유 조작으로 생성된 커밋에 Co-authored-by 트레일러를 넣을 수도 있습니다(docs.openclaw.ai).

하나를 공유할까, 복제할까? 30초 결정표

큐 모드는 두 사람이 동시에 입력해 서로의 말을 덮어쓰는 문제를 줄여 줍니다. 하지만 서로 충돌하는 지시사항까지 해결해 주지는 않습니다. 합쳐진 입력에 상반된 요구가 함께 들어갈 수 있기 때문입니다. 재시작 뒤에도 지시사항을 살려 두는 역할은 파일이 맡습니다.