오픈클로를 내 노트북에 설치하고 처음 며칠은 신세계였다. 텔레그램으로 “메일 정리해줘”라고 보내면 진짜 정리해주고, “내일 일정 알려줘”라고 하면 브리핑이 날아왔다. 그런데 문제가 생겼다. 노트북 덮개를 닫으면 에이전트도 같이 잠든다. 외출하면 멈추고, 밤에 자면 멈추고. 24시간 돌아가는 비서가 하루에 8시간만 일하는 꼴이었다.
결국 VPS로 옮겼다. 월 5천 원짜리 서버에 도커로 올려놨더니, 진짜 24시간 365일 꺼지지 않는 AI 비서가 완성됐다. 새벽 3시에 들어온 긴급 메일도 에이전트가 분류해서 아침에 브리핑해주고, 주말에 경쟁사 블로그에 새 글이 올라오면 알림을 보내준다. 노트북에서 돌리던 것과 체감이 완전히 달랐다.
이 글에서는 오픈클로를 도커로 배포하고 클라우드 서버에서 운영하는 전체 과정을 다룬다. VPS 선택 기준부터 도커 설정, 보안 하드닝, 자동 업데이트까지 실전 운영에 필요한 모든 걸 정리했다. 오픈클로 자체가 처음이라면 오픈클로 완벽 가이드를 먼저 읽고 오면 좋겠다.
왜 도커인가 – 로컬 설치와의 결정적 차이
오픈클로를 서버에 올리는 방법은 두 가지다. Node.js를 직접 설치하고 소스에서 빌드하는 네이티브 방식, 그리고 도커 컨테이너로 올리는 방식이다. 네이티브 방식도 동작하지만, 실전 운영에서는 도커가 압도적으로 유리하다.
가장 큰 이유는 격리(Isolation)다. 도커 컨테이너 안에서 오픈클로가 실행되면, 호스트 시스템에 직접 접근하지 못한다. 오픈클로는 셸 명령을 실행하고 파일 시스템에 접근할 수 있는 강력한 도구인데, 만약 프롬프트 인젝션 공격을 받으면 호스트 전체가 위험해진다. 도커는 이 영향 범위를 컨테이너 내부로 제한한다. DigitalOcean의 공식 오픈클로 배포에서도 도커 컨테이너 격리를 핵심 보안 요소로 꼽고 있다.
두 번째 이유는 재현성이다. 의존성 충돌, 버전 불일치, 라이브러리 누락 같은 문제가 도커에서는 발생하지 않는다. 컨테이너 이미지 안에 필요한 모든 게 들어있기 때문이다. 개발 환경에서 잘 돌아가는 설정이 프로덕션에서도 동일하게 작동한다는 보장이 된다.
세 번째는 업데이트와 롤백의 용이성이다. 새 버전이 나오면 이미지를 pull하고 컨테이너를 재시작하면 끝이다. 문제가 생기면 이전 이미지로 즉시 롤백할 수 있다. 네이티브 설치에서는 업데이트 과정에서 설정이 꼬이거나 의존성이 깨지는 경우가 종종 발생하는데, 도커에서는 이런 걱정이 없다.
오픈클로 공식 문서에서도 도커 배포를 정식으로 지원하고 있고, GitHub Container Registry에서 사전 빌드된 이미지를 제공한다. main, latest, 버전 태그(예: 2026.2.26) 중 선택해서 쓸 수 있다.
VPS 선택 – 최소 사양과 추천 옵션
서버 선택이 첫 번째 관문이다. 오픈클로 자체는 무거운 프로그램이 아니지만, 24시간 상시 가동과 도커 실행을 고려하면 최소 사양이 있다.
최소 사양은 2GB RAM, 1 vCPU, 10GB SSD다. 이 정도면 기본 동작은 가능하다. 하지만 실전에서는 4GB RAM, 2 vCPU를 추천한다. 여러 메시징 채널을 동시에 돌리고, 크론잡으로 자동화 작업을 여러 개 실행하면 메모리 사용량이 올라가기 때문이다. 로컬 AI 모델(Ollama)을 같은 서버에서 돌릴 계획이라면 최소 8GB RAM은 필요하다.
운영체제는 Ubuntu 22.04 또는 24.04 LTS가 가장 안정적이다. 오픈클로 공식 문서와 커뮤니티의 대부분의 가이드가 Ubuntu 기반이라, 트러블슈팅할 때 참고할 자료가 가장 많다.
주요 VPS 제공자별 특징을 정리하면 이렇다. Hetzner는 가격 대비 성능이 가장 좋다. 유럽 서버 기준 월 4~5유로대에 충분한 사양을 제공한다. Contabo는 비슷한 가격대에서 RAM을 넉넉하게 제공한다. DigitalOcean은 오픈클로 원클릭 배포를 지원해서, 도커 설정 없이 바로 시작할 수 있다는 장점이 있다. 보안 하드닝(방화벽, 비루트 실행, DM 페어링)이 사전 적용된 이미지를 제공하기 때문에 보안이 걱정되는 사람에게 편하다. Hostinger도 오픈클로 전용 VPS 템플릿을 제공하고 있어서, Docker Manager에서 클릭 몇 번으로 배포 가능하다.
무료로 시작하고 싶다면 Oracle Cloud의 Free Tier가 있다. ARM 기반 4 vCPU, 24GB RAM을 무료로 제공하는데, 오픈클로를 돌리기에 충분한 사양이다. 다만 가입 과정이 까다롭고, 무료 인스턴스가 항상 가용한 건 아니라서 인내심이 필요하다.
비용을 구체적으로 따져보면, Hetzner CX22(2 vCPU, 4GB RAM)가 월 약 4.5유로, Contabo Cloud VPS 10(4 vCPU, 6GB RAM)이 월 약 4.5유로, DigitalOcean 기본 Droplet(2 vCPU, 4GB RAM)이 월 약 24달러다. 가격 대비 성능만 보면 Hetzner나 Contabo가 유리하고, 편의성을 중시하면 DigitalOcean이나 Hostinger가 낫다. 어떤 제공자를 선택하든 KVM 가상화 방식이어야 한다. OpenVZ 방식의 저가 호스팅에서는 도커가 제대로 동작하지 않는다.
도커로 오픈클로 배포하기 – 실전 순서
VPS를 확보했으면 본격적으로 도커 배포에 들어간다. SSH로 서버에 접속한 뒤, 순서대로 진행하면 된다.
먼저 시스템 패키지를 업데이트하고 도커를 설치한다.
sudo apt update && sudo apt upgrade -y
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER마지막 명령 후 로그아웃했다가 다시 접속해야 docker 그룹 권한이 적용된다. 정상 설치 확인은 이렇게 한다.
docker --version
docker compose version두 명령 모두 버전이 출력되면 준비 완료다. 다음으로 오픈클로 저장소를 클론하고 도커 설정 스크립트를 실행한다.
git clone https://github.com/openclaw/openclaw.git
cd openclaw
./docker-setup.sh이 스크립트가 Docker Compose를 이용해 이미지를 빌드하고, 온보딩 위저드를 자동으로 시작한다. 위저드에서 AI 모델 제공자를 선택하고 API 키를 입력하면 된다. 배포 방식은 “Local(이 머신)”을 선택한다.
도커 설정 스크립트는 호스트에 두 개의 디렉토리를 마운트한다. ~/.openclaw에는 설정 파일, 메모리, API 키 등이 저장되고, ~/openclaw/workspace에는 에이전트가 작업하는 파일들이 저장된다. 이 볼륨들은 컨테이너를 재시작하거나 업데이트해도 유지되기 때문에, 데이터 손실 걱정은 없다.
사전 빌드된 이미지를 쓰고 싶다면 직접 빌드 대신 이렇게 할 수 있다.
docker pull ghcr.io/openclaw/openclaw:latest게이트웨이가 정상적으로 실행됐는지 확인한다.
docker compose run -T --rm openclaw-cli gateway probe메시징 채널 연결도 도커 CLI를 통해 할 수 있다. 텔레그램이 VPS 환경에서 가장 설정이 간편하다. 포트 포워딩이 필요 없고, 봇 토큰만 있으면 바로 연결된다.
docker compose run --rm openclaw-cli channels add --channel telegram --token "봇토큰"왓츠앱은 QR 코드 스캔 방식이라 약간 번거롭다.
docker compose run --rm openclaw-cli channels login이 명령을 실행하면 터미널에 QR 코드가 출력되는데, 스마트폰의 왓츠앱에서 연결된 기기 추가로 스캔하면 된다. VPS 환경에서는 화면이 없으니까, SSH 터미널에서 QR 코드가 깨져 보일 수 있다. 이 경우 터미널 폰트 크기를 줄이거나, 웹 대시보드를 통해 연결하는 게 더 편하다.
도커 환경에서 CLI 명령을 실행할 때 주의할 점이 하나 있다. 반드시 docker-compose.yml 파일이 있는 디렉토리에서 명령을 실행해야 한다. openclaw-cli 컨테이너는 network_mode: “service:openclaw-gateway”로 설정되어 있어서, 게이트웨이 컨테이너와 같은 네트워크를 공유한다. 다른 디렉토리에서 실행하면 게이트웨이를 찾지 못한다.
반드시 해야 할 보안 하드닝
VPS에서 오픈클로를 돌릴 때 보안 설정은 선택이 아니라 필수다. 기본 설정 그대로 두면 공용 인터넷에 게이트웨이가 노출될 수 있다. 실제로 SecurityScorecard가 전 세계에서 13만 개 이상의 노출된 오픈클로 인스턴스를 발견한 바 있다.
첫째, 게이트웨이 바인딩 주소를 확인한다. 반드시 127.0.0.1로만 바인딩되어 있어야 한다. 0.0.0.0으로 되어 있으면 외부에서 직접 접근 가능하다는 뜻이다.
둘째, 방화벽을 설정한다.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw limit 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable여기서 핵심은 18789 포트(오픈클로 게이트웨이 기본 포트)를 절대 열지 않는 것이다. 외부 접근은 Nginx 리버스 프록시를 통해서만 허용한다.
셋째, Nginx 리버스 프록시를 설정한다. 이렇게 하면 HTTPS로 암호화된 접속만 허용하면서, 게이트웨이는 localhost에서만 동작하게 된다.
sudo apt install -y nginx certbot python3-certbot-nginxNginx 설정 파일에서 proxy_pass를 http://127.0.0.1:18789로 지정하고, WebSocket 연결을 위해 proxy_read_timeout을 86400(24시간)으로 설정하는 게 중요하다. 이 값이 짧으면 Nginx가 오픈클로의 실시간 메시징 WebSocket 연결을 끊어버린다. 그 다음 Certbot으로 SSL 인증서를 적용하면 HTTPS 접속이 완성된다.
넷째, SSH 보안을 강화한다. 비밀번호 인증을 비활성화하고 SSH 키 인증만 허용한다. 기본 포트 22를 다른 번호로 변경하는 것도 권장한다. Fail2Ban을 설치하면 무차별 대입 공격도 방어할 수 있다.
샌드박스 – 에이전트의 도구 실행을 격리하는 방법
도커 안에서 오픈클로를 돌리는 것과, 에이전트의 도구 실행을 샌드박싱하는 것은 별개의 레이어다. 이 차이를 이해하는 게 중요하다.
게이트웨이 컨테이너는 오픈클로의 핵심 서비스를 격리한다. 샌드박스는 에이전트가 셸 명령이나 파일 작업을 수행할 때, 그 실행 자체를 별도의 격리 컨테이너에서 돌리는 기능이다. 공식 문서에서는 비메인 세션(non-main)에 대해 샌드박스를 적용할 것을 권장하고 있다.
설정은 openclaw.json에서 한다.
{
"agents": {
"defaults": {
"sandbox": {
"mode": "non-main",
"scope": "agent"
}
}
}
}mode를 “non-main”으로 설정하면 메인 세션 외의 모든 세션(크론잡, 서브에이전트 등)이 샌드박스에서 실행된다. “all”로 설정하면 메인 세션까지 포함해서 전부 격리된다. scope는 “agent”(에이전트별 격리), “session”(세션별 격리), “shared”(공유 샌드박스) 중 선택할 수 있다.
샌드박스의 실질적 효과는 프롬프트 인젝션 공격이 성공하더라도, 피해가 샌드박스 컨테이너 안으로 제한된다는 거다. 호스트 파일 시스템이나 다른 에이전트의 워크스페이스에는 접근할 수 없다. 멀티 에이전트를 운영하는 환경에서는 사실상 필수 설정이다.
자동 업데이트와 백업 설정
서버에서 오픈클로를 운영하면 업데이트와 백업을 자동화해야 한다. 수동으로 관리하면 잊어먹기 십상이고, 보안 패치가 늦어지면 취약점에 노출된다.
자동 업데이트 스크립트를 만들어두면 편하다.
cat > ~/openclaw/update.sh << 'EOF'
#!/bin/bash
cd ~/openclaw
docker compose pull
docker compose up -d
docker image prune -f
EOF
chmod +x ~/openclaw/update.sh이 스크립트를 크론탭에 등록해서 매주 일요일 새벽 4시에 자동 실행되게 한다.
crontab -e아래 줄을 추가한다.
0 4 * * 0 /root/openclaw/update.sh >> /root/openclaw/update.log 2>&1백업은 Docker 볼륨을 tar로 묶어서 저장하는 방식이 가장 간단하다. ~/.openclaw 디렉토리에 모든 설정과 기억이 들어있으니, 이 디렉토리만 백업하면 된다. VPS 제공자의 스냅샷 기능을 활용하는 것도 좋은 방법이다. 대규모 업데이트 전에 스냅샷을 찍어두면, 문제가 생겼을 때 즉시 롤백할 수 있다.
디스크 용량도 모니터링해야 한다. 오픈클로가 장기간 운영되면 세션 로그, 크론잡 실행 기록, 미디어 파일 등이 누적되면서 디스크가 차올 수 있다. 공식 문서에서도 media/, session JSONL 파일, cron/runs/*.jsonl, /tmp/openclaw/ 하위의 롤링 로그를 디스크 증가 요인으로 꼽고 있다. 주기적으로 오래된 로그를 정리하는 크론잡을 별도로 설정해두는 게 좋다.
원클릭 배포 vs 직접 구축 – 무엇을 선택할까
지금까지 설명한 방식은 직접 구축이다. 서버를 세팅하고, 도커를 설치하고, 보안을 잡고, 유지보수 체계를 만드는 과정이다. 이 과정이 번거롭거나 자신이 없다면 원클릭 배포 서비스를 활용하는 방법도 있다.
DigitalOcean은 오픈클로 전용 1-Click Deploy를 제공한다. 방화벽 규칙, 비루트 실행, 도커 컨테이너 격리, DM 페어링이 사전 적용된 보안 강화 이미지다. Hostinger도 Docker Manager에서 오픈클로 템플릿을 지원하고, Contabo는 원클릭 애드온으로 설치 과정 전체를 자동화한다.
원클릭 배포의 장점은 시간 절약과 보안 기본값이다. 10분 안에 배포 가능하고, 보안 설정이 미리 적용되어 있어서 초보자도 치명적 실수를 피할 수 있다. 단점은 커스터마이징의 한계다. 모델 선택이 제한되거나, 세부 설정을 바꾸려면 결국 CLI로 들어가야 하는 경우가 있다. DigitalOcean 사용자 리뷰에서도 “기본 설정은 편하지만, 모델 교체나 고급 설정에서 막히는 부분이 있다”는 피드백이 꽤 있었다.
내 추천은 이렇다. 서버 관리 경험이 있다면 직접 구축이 장기적으로 유연하고 비용도 낮다. 서버 경험이 없거나, 빠르게 시작하고 싶다면 원클릭 배포로 시작한 뒤 익숙해지면 직접 관리로 전환하는 게 현실적이다.
마무리
오픈클로를 노트북에서 돌리는 것과 VPS에서 돌리는 것은 자전거와 자동차의 차이다. 둘 다 이동 수단이지만, 활용 범위가 완전히 다르다. 24시간 상시 가동, 도커 컨테이너 격리, Nginx 리버스 프록시, 샌드박스 실행, 자동 업데이트. 이 다섯 가지가 갖춰지면 오픈클로는 장난감에서 실전 인프라로 격상된다.
핵심을 정리하면, VPS는 4GB RAM 이상을 추천하고, 도커 배포로 환경 일관성과 보안 격리를 확보한다. 게이트웨이는 반드시 127.0.0.1에만 바인딩하고 Nginx를 통해서만 외부 접근을 허용한다. 샌드박스로 에이전트의 도구 실행을 격리하고, 업데이트와 백업을 자동화해서 운영 부담을 줄인다. 월 5천~2만 원의 VPS 비용으로 24시간 돌아가는 AI 비서 인프라를 갖추는 셈이니, 투자 대비 효과는 확실하다. 노트북에서 “이거 괜찮은데?”라는 느낌을 받았다면, 서버로 올려보자. 그때부터 진짜가 시작된다.
운영 중 모니터링도 빠뜨리면 안 된다. 도커 컨테이너가 예상치 못하게 종료되는 경우가 가끔 있다. restart: unless-stopped 설정이 있으면 대부분 자동 복구되지만, 근본 원인을 파악하려면 로그를 주기적으로 확인해야 한다. docker logs openclaw-gateway –tail 100 명령으로 최근 로그를 볼 수 있고, 텔레그램 봇이 갑자기 응답하지 않는다면 이 로그에서 원인을 찾을 수 있다. 더 체계적인 모니터링을 원한다면 Uptime Kuma 같은 경량 모니터링 도구를 같은 VPS에 올려서 게이트웨이 상태를 감시하는 방법도 있다. 서버가 다운되면 이메일이나 텔레그램으로 알림을 받을 수 있어서 편하다.