OpenClaw를 여러 팀이 함께 쓸 때는 팀들이 서로 신뢰하지 않는다면 Gateway 인스턴스부터 분리해야 합니다. 각 인스턴스의 상태와 자격 증명, 작업 공간을 나눈 뒤에 물리 Mac을 공유할지 결정하세요.
기업 IT 담당자라면 Mac에서 OpenClaw를 운영할 때 필요한 팀별 접근 경계를 확인할 수 있습니다.
플랫폼 엔지니어라면 Gateway, 노드 페어링, Agent 도구 권한의 운영 기준을 살펴보세요.
보안 책임자와 기술 총괄이라면 자격 증명 격리, 원격 명령, 공유 호스트의 위험을 검토할 수 있습니다.
최종 업데이트: 2026년 10월 5일. OpenClaw 공식 다중 테넌트 호스팅 문서, Operator 범위 안내를 기준으로 확인했습니다. 배포 전에는 사용 중인 버전의 문서와 변경 기록도 다시 살펴보세요.
01Gateway 하나를 팀 격리 경계로 삼을 때 생기는 문제
서로 다른 프로젝트 팀이 Gateway 하나를 공유한다고 가정해 보세요. 팀별 세션을 따로 만들고 대화가 섞이지 않게 설정했더라도, 그것만으로 접근 권한까지 나뉘지는 않습니다. 세션 식별자는 요청을 해당 세션으로 보내는 데 쓰이며, 독립된 보안 경계가 아닙니다. OpenClaw 공식 문서는 기본 Gateway의 신뢰 모델을 단일 운영자 경계로 설명합니다. 서로 신뢰하지 않는 테넌트 사이의 격리 장치로 공유 Gateway를 사용하지 말라고 안내합니다. 공식 다중 테넌트 문서
잘못된 가정은 대개 다음처럼 이어집니다.
- 팀별 세션을 만들면 다른 팀 데이터에도 접근할 수 없다고 기대합니다.
- Operator 역할이나 범위를 나누면 Gateway 상태와 자격 증명까지 자동으로 분리된다고 생각합니다.
- Agent 샌드박스를 적용하면 공유 Gateway의 테넌트 격리 문제도 해결된다고 판단합니다.
각 설정이 줄이는 위험은 서로 다릅니다. 세션 라우팅은 요청의 목적지를 정합니다. Operator 범위와 도구 정책은 수행 가능한 동작을 제한하는 데 도움을 줍니다. 하지만 이를 서로 신뢰하지 않는 팀 사이의 완전한 격리 보증으로 확대해서는 안 됩니다. Operator 범위 문서
02세션과 역할 설정의 제한 범위를 구분하세요
공유 Gateway를 검토한다면 팀별로 허용할 동작과 차단할 동작부터 적으세요. 역할과 범위는 운영자에게 허용할 작업을 제한하는 통제 수단입니다. Agent 도구 정책은 Agent가 사용할 수 있는 도구를 제한합니다. 각 설정의 적용 대상은 다르며, 한 가지 통제가 다른 계층의 보호를 대신하지 않습니다.
특히 다음 두 가지를 혼동하지 마세요.
- Operator 범위: Gateway 운영 작업에 대한 권한을 구성합니다. 모든 상태와 비밀 정보가 팀별로 독립 저장된다는 뜻은 아닙니다.
- Agent 도구 정책: Agent가 요청할 수 있는 도구 동작을 제한합니다. 공유 인스턴스의 신뢰 모델을 바꾸거나 팀별 저장소를 자동으로 분리하지는 않습니다.
다중 팀 배포에서 중요한 질문은 팀별 세션이 나뉘었는지가 아닙니다. 한 팀의 계정이나 운영 환경이 침해됐을 때 다른 팀의 데이터와 실행 권한에 접근할 수 있는지를 확인해야 합니다. 답이 명확하지 않다면 인스턴스 분리부터 검토하세요.
03Mac 노드 페어링과 명령 승인을 따로 확인하세요
Gateway와 Mac 노드의 페어링은 노드를 연결하고 노드 기능을 사용할 수 있게 하는 절차입니다. 페어링이 완료됐다고 해서 모든 명령이 개별 승인되는 것은 아닙니다. 반대로 모든 명령이 자동 허용되는 것도 아닙니다. 공식 노드 페어링 안내와 노드 명령 실행 문서를 보고 실제 기능과 권한을 확인하세요.
명령 실행 기능이 있는 노드는 원격 작업을 수행할 수 있습니다. 허용 범위는 도구 설정과 실행 승인 구성, 노드 쪽 정책에 따라 달라집니다. 실행 승인 설정 문서를 기준으로 허용 규칙과 승인 흐름을 정하세요. 운영 과정에서 다음 항목을 따로 기록해야 합니다.
- 노드 페어링을 승인할 수 있는 계정
- Gateway에서 요청할 수 있는 노드 기능과 도구
- 명령 실행을 허용하거나 승인하는 정책
- Mac의 로컬 계정이 접근할 수 있는 파일과 키체인
- 작업 기록을 확인하고 노드 연결을 끊을 담당자와 절차
Gateway에서 도구를 제한했더라도 Mac 운영체제 계정의 권한이 넓으면 로컬 파일과 비밀 정보에 접근할 수 있습니다. 반대로 Mac에서 계정을 나눴더라도 공유 Gateway의 상태와 자격 증명이 자동으로 분리되지는 않습니다. 로컬 계정과 신뢰 경계를 정할 때는 Mac의 개인정보와 접근 관리 기준도 함께 확인하세요.
04플러그인과 자격 증명을 팀별로 관리하세요
플러그인은 실행되는 코드로 취급해야 합니다. 누가 설치하고 수정할 수 있는지, 변경 전에 검토하는지 확인하세요. OpenClaw의 플러그인 문서는 플러그인을 신뢰 코드로 다루도록 안내합니다. 출처가 확인되지 않았거나 여러 팀이 함께 수정하는 경로를 공유하면, 한 팀의 변경이 다른 팀의 실행 환경에도 영향을 줄 수 있습니다.
스킬 디렉터리도 같은 원칙으로 관리하세요. 실행 가능한 스킬을 누가 추가하거나 수정할 수 있는지 제한하고, 배포 시 변경 내역을 검토해야 합니다. 스킬 문서를 확인해 사용 중인 스킬의 저장 위치와 관리 방식을 점검하세요.
팀별로 나눠 관리할 대상은 코드에 그치지 않습니다.
- 모델 접근 자격 증명과 채널 계정
- Gateway 설정과 상태 데이터
- 작업 공간과 업로드 파일
- 플러그인과 스킬의 설치 및 수정 권한
- 노드에 저장되는 실행 도구와 로컬 계정 권한
같은 호스트에서 컨테이너나 Agent 샌드박스를 사용하면 방어 계층을 더할 수 있습니다. 그러나 이를 Gateway의 다중 테넌트 경계와 동일시하지 마세요. 어떤 계층에서 데이터와 권한을 나눌지 먼저 문서화해야 합니다.
05신뢰 도메인에 맞춰 인스턴스와 Mac 배치를 결정하세요
팀들이 같은 운영자와 보안 정책을 공유하고 서로 접근할 가능성을 받아들일 수 있다면, 한 인스턴스에서 제한된 권한을 적용하는 방안을 검토할 수 있습니다. 팀이 서로 신뢰하지 않거나 침해 범위를 분리해야 한다면 완전한 Gateway 인스턴스를 나누세요. 각 인스턴스의 상태와 자격 증명, 작업 공간도 별도로 관리해야 합니다.
물리 Mac을 공유할지 여부는 그다음에 판단하세요. Gateway 분리는 애플리케이션과 저장 데이터 경계를 나누는 결정입니다. 물리 호스트 분리는 하드웨어와 운영체제 계층의 경계를 나누는 결정입니다. 같은 Mac을 쓰면 호스트 관리 권한과 로컬 자원에 관한 공유 위험이 남습니다. 호스트 수준의 강한 분리가 필요한 팀이라면 별도 Mac을 검토하세요.
OpenClaw의 Fleet 기능은 공식 문서에서 실험적인 기능으로 표시되어 있습니다. 검증된 기업용 격리 보증으로 전제하지 말고, 현재 문서와 실제 배포 버전을 확인한 뒤 제한된 환경에서 평가하세요. Fleet 문서
| 배포 선택 | 적합한 조건 | 남는 점검 항목 |
|---|---|---|
| Gateway와 Mac을 함께 공유 | 팀이 같은 신뢰 경계와 운영 정책을 받아들일 수 있습니다 | 역할, 도구 정책, 플러그인 변경 권한, 로컬 계정 |
| Gateway는 팀별로 나누고 Mac은 공유 | 인스턴스와 저장 데이터를 나누되 호스트 공유를 감수할 수 있습니다 | 운영체제 계정, 파일 접근, 자원 사용, 관리자 권한 |
| Gateway와 Mac을 모두 분리 | 팀 간 신뢰가 없거나 호스트 수준의 분리가 필요합니다 | 환경별 자격 증명, 업데이트, 접근 관리와 복구 절차 |
이 표는 신뢰 경계에 따른 구성 비교입니다. 특정 Mac 구성과 요금, 지역, 성능 또는 제공 방식을 보증하지 않습니다. 실제 호스트 공유 가능 여부는 서비스 제공 조건과 팀의 보안 요구를 따로 대조해야 합니다.
06배포 전에 격리 기준을 점검하세요
아래 항목을 담당자와 함께 확인하세요. 하나라도 답할 수 없다면 팀 사이의 공유 범위를 줄이고 설계를 다시 검토하세요.
- [ ] 팀들이 같은 운영자 신뢰 경계를 공유해도 되는지 보안 책임자가 확인했습니다.
- [ ] 팀별 인스턴스 분리 여부를 정했고, 공유 세션을 권한 경계로 취급하지 않습니다.
- [ ] Gateway 상태와 자격 증명, 채널 계정, 작업 공간의 저장 위치와 접근자를 기록했습니다.
- [ ] Operator 범위와 Agent 도구 정책을 서로 다른 통제로 문서화했습니다.
- [ ] 노드 페어링 담당자와 명령 허용 및 승인 정책, 로컬 실행 경계를 각각 정했습니다.
- [ ] 플러그인과 스킬의 출처, 설치 권한, 변경 검토 절차를 확인했습니다.
- [ ] Mac 운영체제 계정과 파일 접근 권한을 위협 모델에 맞췄습니다.
- [ ] 노드 연결을 끊고 자격 증명을 회수하는 절차를 시험했습니다.
- [ ] Fleet을 사용한다면 실험 상태와 현재 버전의 기능 제한을 확인했습니다.
자주 묻는 질문
여러 팀이 Gateway 하나를 함께 사용해도 되나요?
팀들이 같은 운영 신뢰 경계 안에 있고, 서로의 설정이나 자격 증명에 접근할 가능성을 받아들일 수 있다면 제한된 권한 구성을 검토할 수 있습니다. 서로 신뢰하지 않는 팀이라면 공유 Gateway를 격리 경계로 간주하지 마세요. 이 경우 인스턴스와 상태, 자격 증명, 작업 공간을 팀별로 나누고 호스트 공유 위험도 따로 평가해야 합니다.
여러 팀을 운영할 때 Gateway 인스턴스를 나누는 이유는 무엇인가요?
세션 식별자는 요청을 해당 세션으로 보내는 용도이지 팀 사이의 접근 권한을 보장하지 않습니다. 역할과 범위, Agent 도구 정책으로 허용 동작을 제한할 수 있지만, 공유 Gateway의 상태와 자격 증명은 자동으로 분리되지 않습니다. 신뢰하지 않는 팀 사이에는 Gateway 인스턴스와 관련 데이터를 나누는 설계가 필요합니다.
Mac 노드를 페어링하면 원격 명령이 자동으로 승인되나요?
아닙니다. 페어링은 Gateway와 노드를 연결하고 기능을 사용할 수 있게 하는 절차입니다. 명령마다 승인을 요구한다는 뜻은 아닙니다. 노드의 명령 실행 기능과 실제 허용 범위는 도구 정책, 실행 승인 구성, 노드의 로컬 정책에 따라 달라집니다. 허용 명령과 승인 담당자, 기록 확인 및 연결 중단 방법을 각각 확인하세요.
자격 증명과 플러그인, 팀 작업 공간은 어떻게 나누나요?
팀별 Gateway 인스턴스와 상태 저장 위치를 분리하고, 모델 자격 증명과 채널 계정, 작업 공간을 팀별로 관리하세요. 플러그인은 신뢰 코드로 취급해 설치와 변경 권한을 제한해야 합니다. 스킬 디렉터리도 수정할 수 있는 사람을 한정하세요. 컨테이너와 Agent 샌드박스는 보완 통제이며, 공유 Gateway의 다중 테넌트 격리를 대신하지 않습니다.
팀별 신뢰 도메인과 계정, Gateway 및 호스트 경계를 먼저 기록하세요. 원격 Mac은 임시 개발이나 검증 환경에 맞을 수 있지만, 실제 제공 조건이 필요한 격리 수준과 일치하는지 확인해야 합니다. VpsMesh의 Mac 배포 정보를 살펴보고 확인 가능한 제공 범위와 기업 요구 사항을 대조하세요. 두 조건이 맞을 때에만 배포 방안을 문의하는 것이 좋습니다. 영구적인 고부하 운영이나 물리 호스트 수준의 전용 분리가 필수라면, 별도 Mac을 직접 운영하는 선택지도 함께 비교하세요.