OpenClaw를 VPS에서 안전하게 실행하는 설정 방법

OpenClaw란 무엇이며, 왜 가장 먼저 보안을 강화해야 하는가

OpenClaw는 자체 호스팅형 AI 에이전트입니다. 사용자의 서버에서 직접 실행하며, 대규모 언어 모델(LLM)과 연결하여 셸 명령어를 실행하고, 브라우저를 제어하며, 파일을 읽고 쓰고, 채팅 앱을 통해 전달받은 메시지에 따라 동작할 수 있습니다. 이러한 광범위한 접근 권한은 이 도구의 핵심 목적이자 동시에 모든 위험 요소이기도 합니다. 임의의 명령어를 실행할 수 있는 에이전트는 해당 에이전트가 구동되는 환경의 안전성과 사용자가 설정한 제한 범위만큼만 안전합니다.

두 가지 사실이 이 가이드의 방향을 결정합니다. 첫째, OpenClaw는 사용자가 직접 보안을 강화하도록 설계되었습니다. 이 도구의 보안 모델은 안전한 기본 설정을 제공하는 대신, 엄격한 도구 정책, 샌드박싱, 신중한 권한 관리에 대한 책임을 운영자에게 부여합니다. 둘째, 이 프로젝트는 이미 심각한 보안 사고를 겪은 바 있습니다. 2026년 3월, 4일 동안 9개의 보안 취약점이 공개되었으며, 여기에는 10점 만점에 9.9점을 기록한 치명적인 권한 상승 결함인 CVE-2026-32922가 포함되어 있었습니다. 이 사실들이 OpenClaw를 사용하지 말아야 한다는 의미는 아닙니다. 이는 안일한 방식으로 운영해서는 안 된다는 뜻이며, 이 가이드는 신중한 운영 방법을 제시합니다. 신중한 운영의 일부는 에이전트가 질문 없이 수행할 수 있는 작업의 범위를 사전에 결정하는 것입니다. 이는 Claude Code가 권한 모드를 통해 명시적으로 설정하는 방식과 같으며, 사용자가 직접 앞에 앉아 있지 않은 서버는 노트북보다 더 엄격한 설정이 필요합니다.

물론 긍정적인 측면도 있습니다. OpenClaw는 이미 한 가지 안전한 기본 설정을 제공합니다. 모든 것을 제어하는 단일 프로세스인 게이트웨이는 기본적으로 loopback 주소에서 수신 대기하므로, 사용자가 의도적으로 외부로 노출하지 않는 한 인터넷에서 접근할 수 없습니다. 아래에서 다룰 대부분의 작업은 이러한 상태를 유지하고, 만약의 사태가 발생하더라도 피해 범위를 최소화하는 데 중점을 둡니다.

OpenClaw를 위한 권한 없는 사용자 생성

에이전트를 root 권한으로 실행하지 마십시오. OpenClaw가 root로 실행되는 상태에서 버그, 잘못된 명령어, 혹은 위에서 언급한 것과 같은 CVE가 발생하면 피해 규모를 제한할 수 없습니다. 로그인 셸과 sudo 권한이 없는 전용 시스템 사용자를 생성하고, 해당 사용자로 에이전트를 실행하십시오.

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

OpenClaw가 소유한 모든 항목은 /opt/openclaw 하위에 위치하며, 해당 계정이 소유권을 가집니다. 이는 가장 중요한 단계이며, 권한 없는 사용자로 서비스 실행에서 다룬 원칙과 동일합니다. 에이전트가 실행되는 계정의 권한이 곧 해당 에이전트가 일으킬 수 있는 피해의 상한선이 됩니다.

OpenClaw 설치

OpenClaw는 npm 패키지로 배포되므로 서버에 Node.js가 없다면 먼저 설치해야 합니다. 패키지를 전역으로 설치하면 모든 사용자의 PATH에 openclaw 바이너리가 추가되며, 이후 1회성 온보딩 단계를 실행합니다.

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

openclaw 사용자로 온보딩을 실행하면 에이전트 설정이 root의 홈 디렉터리가 아닌 /opt/openclaw에 저장됩니다. 이 프로젝트는 동일한 설치 과정을 한 줄로 수행하는 curl -fsSL https://openclaw.ai/install.sh | bash 설치 프로그램도 제공합니다. 온보딩 중 --install-daemon 플래그는 건너뛰십시오. 해당 플래그는 OpenClaw 자체 서비스를 등록하는데, 아래에서 직접 작성할 강화된 systemd unit이 더 엄격하기 때문입니다.

게이트웨이를 루프백에 유지하고 방화벽 뒤에 배치하기

게이트웨이는 기본적으로 127.0.0.1에 바인딩됩니다. 이 설정을 그대로 유지하십시오. 해당 포트를 인터넷에 공개해야 할 이유는 거의 없으며, 공개할 경우 누구나 명령을 실행하는 프로세스에 원격으로 접근할 수 있는 발판을 제공하게 됩니다.

실수로 서비스가 노출되지 않도록 서버 앞에 기본 거부(default-deny) 방화벽을 배치하십시오.

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

이 과정에서 두 가지 함정을 피해야 합니다. IPv4만 차단하는 방화벽은 IPv6에서 동일한 서비스를 그대로 노출할 수 있으며, 이는 많은 사용자가 겪는 IPv6 방화벽 공백 문제입니다. 또한 노트북에서 게이트웨이에 접근해야 하더라도 포트를 직접 열지 마십시오. VPN이나 SSH 터널을 통해 접근하여 에이전트가 공개된 인터넷에 노출되지 않도록 하십시오.

비밀 정보 격리

OpenClaw는 연결할 언어 모델에 대한 API 키가 필요합니다. 이 키는 비용을 발생시킬 수 있고 에이전트를 통해 사용자를 대신하여 동작할 수 있으므로 비밀번호처럼 취급해야 합니다. unit 파일이나 저장소에 포함하지 마십시오. OpenClaw 사용자만 읽을 수 있는 파일에 저장하십시오.

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

systemd unit은 EnvironmentFile을 사용하여 해당 파일을 로드하므로, 키가 명령줄, 로그, 셸 기록에 남지 않고 프로세스에 전달됩니다. 이 패턴은 서버의 모든 비밀 정보에 적용됩니다. 자체 호스팅 Vaultwarden 강화 작업은 암호화 방식보다 관리자 토큰과 백업 파일을 보호하는 데 집중하게 되는데, 이는 저장된 비밀 정보를 누가 읽을 수 있는지 결정하는 것이 결국 파일 권한이기 때문입니다.

강화된 systemd 서비스로 실행하기

systemd에서 에이전트를 실행하면 자동 재시작, journalctl를 통한 깔끔한 로그 관리, 그리고 무엇보다 프로세스가 침해되더라도 접근 범위를 제한하는 커널 수준의 샌드박싱 옵션을 활용할 수 있습니다. 에이전트 보안에 가장 중요한 옵션은 프로세스가 새로운 권한을 획득하지 못하게 하는 NoNewPrivileges, 허용된 경로 외에는 파일 시스템을 읽기 전용으로 만드는 ProtectSystem=strict, 자체적인 격리 임시 디렉터리를 제공하는 PrivateTmp, 그리고 홈 디렉터리 접근을 차단하는 ProtectHome입니다.

완전하게 강화된 유닛 파일을 생성한 뒤 /etc/systemd/system/openclaw.service로 복사하십시오:

이 유닛은 에이전트를 제어하는 장기 실행 프로세스인 openclaw gateway을 시작합니다. 만약 서버에서 which openclaw의 경로가 다르다면 ExecStart를 해당 경로에 맞게 수정하십시오. 이 지시어들과 daemon-reload, enable --now에 대한 전체 설명은 systemd 서비스로 프로그램 실행하기에서 확인할 수 있습니다. 유닛 파일을 붙여넣은 후 실행할 간단한 명령어는 다음과 같습니다:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

현관문 보안 강화하기

에이전트 박스의 안전성은 해당 서버의 보안 수준에 달려 있습니다. 두 가지 계층을 추가하여 작업을 마무리합니다. VPS의 SSH 보안 강화에서 설명한 대로 SSH 인증 방식을 키 기반으로 변경하고 root 로그인을 차단하여, 관리용 계정에 대한 무차별 대입 공격을 방지합니다. 이어서 Fail2ban을 설치하여 모든 공개 포트를 스캔하는 공격자를 차단합니다. 두 방법 모두 OpenClaw에 직접적인 영향을 주지는 않지만, 공격자가 시스템에 접근하기 위해 사용하는 경로를 차단합니다.

의도적으로 최신 상태 유지하기

2026년 3월에 공개된 취약점들은 시스템을 최신 상태로 유지해야 하는 가장 명확한 이유를 보여줍니다. 에이전트의 권한 상승 버그는 일반적인 웹 애플리케이션보다 훨씬 더 심각합니다. 에이전트는 이미 명령을 실행할 수 있는 권한을 가지고 있기 때문입니다. 프로젝트의 릴리스를 모니터링하고 보안 업데이트를 신속하게 적용하십시오. OpenClaw 업그레이드는 미룰 일이 아니라 정기적인 유지보수 작업으로 처리해야 합니다.

무엇을 강화하고 있는지 이해하려면 OpenClaw 스타일 에이전트의 아키텍처에서 구성 요소를 살펴보십시오. 또한 VPS에서 나만의 AI 에이전트 구축하기를 통해 에이전트가 가지는 일반적인 형태를 파악할 수 있습니다. 만약 두 번째 에이전트를 함께 실행하게 된다면, 하나의 VPS에서 두 개의 Claude Code 세션이 서로 작업을 전달할 수 있음을 기억하십시오. 따라서 각 에이전트는 사용자의 권한을 상속받지 말고, 각각 별도의 계정과 제한을 설정해야 합니다.

FAQ

OpenClaw를 공용 VPS에서 실행해도 안전합니까?

보안을 강화한다면 안전할 수 있습니다. OpenClaw는 설계상 강력한 도구로, 셸 명령을 실행하고 브라우저를 제어하므로 부주의하게 설정하면 매우 위험합니다. 실제로 이 프로젝트는 이미 치명적인 CVE(2026년 3월의 CVE-2026-32922)를 겪은 바 있습니다. 보안 모델은 운영자가 직접 제한 사항을 추가할 것을 전제로 합니다. 권한이 없는 사용자로 실행하고, 게이트웨이를 기본 거부(default-deny) 방화벽 뒤의 루프백 인터페이스에 유지하며, API 키를 격리하고, 보안이 강화된 systemd 서비스로 실행하십시오.

OpenClaw 게이트웨이를 인터넷에 노출해야 합니까?

아니요. 게이트웨이는 기본적으로 루프백에 바인딩되며, 그대로 두어야 합니다. 이 프로세스는 에이전트를 제어하는 유일한 통로이므로, 게이트웨이가 노출되면 명령을 실행하는 시스템에 원격으로 침입할 경로를 제공하는 셈입니다. 원격에서 접근해야 한다면 포트를 개방하는 대신 VPN이나 SSH 터널을 사용하십시오.

OpenClaw는 어떤 사용자로 실행해야 합니까?

로그인 셸이 없고 sudo 권한이 없는 전용 시스템 사용자로 실행해야 하며, 절대 root로 실행해서는 안 됩니다. 에이전트가 침해당할 경우 해당 사용자 계정이 피해의 상한선이 되므로, 해당 계정은 /opt/openclaw와 같은 디렉터리 아래의 자체 파일만 소유하도록 해야 합니다.

OpenClaw의 API 키를 어떻게 안전하게 관리합니까?

OpenClaw 사용자만 읽을 수 있는 파일(모드 600)에 저장하고, systemd의 EnvironmentFile을 사용하여 서비스에 로드하십시오. 키를 유닛 파일, 셸 히스토리, git 저장소에 포함하지 마십시오. 유출이 의심되는 경우 즉시 키를 교체하십시오.