Linux 클라우드에 OpenClaw 2.0을 올릴 때 설치 스크립트가 끝나는 순간을 성공으로 보면 거의 반드시 후회한다. 게이트웨이는 떠 있는데 채널을 붙이고 스킬을 켜는 순간 available이 바닥난다. 우리는 흔한 VPS 네 단을 Ubuntu에 고정한 뒤 본기 설치, Docker, 원격 API, 로컬 추론을 같은 절차로 돌려 CPU·메모리·디스크를 기록했다. SSH가 되는 최저가 플랜이 아니라, 실제로 일을 시키는 워크로드로 주문하라는 뜻이다.
먼저 결론만 적는다. 원격 API와 텍스트 채널만 쓸 때 일상 출발점은 2 vCPU / 8 GB / 40 GB다. 2 vCPU / 4 GB도 기동은 되지만 브라우저 스킬이나 그 머신에서의 이미지 빌드는 겹치지 말 것. 같은 상자에서 7B를 돌리려면 메모리를 바로 16 GB로 잡는다. 공식 문서는 게이트웨이를 자기 머신에서 돌리는 멀티채널 에이전트 입구로 두므로, 문서의 최소 숫자보다 여유를 두는 편이 운영에 맞다. 연산 용량을 시간으로 환산하는 시각은 연산력이 곧 권력: τ 법칙, 영衢 버스, AI Agent 시대의 「시간 장벽」과 같은 축이다.
워크로드로 먼저 고르고, 최저가로는 고르지 말 것
OpenClaw 2.0 프로세스 자체는 가볍다. 유휴 게이트웨이는 보통 이삼백 MB이고 CPU는 거의 0에 붙어 있다. 머신을 무너뜨리는 것은 세 가지가 겹칠 때다. 첫 기동의 샌드박스 컴파일, 그 머신에서 Docker 이미지를 빌드하는 일, 그리고 로컬 추론. OpenClaw Docker 설치 문서는 소스 빌드에 최소 6 GB RAM을 명시한다. ghcr.io/openclaw/openclaw 프리빌트를 당기면 그 피크는 빠진다.
그래서 같은 2.0이라도 4 GB와 16 GB의 차이는 「조금 느리다」가 아니다. 한쪽은 겨우 살아 있고, 다른 쪽은 일을 시킨다. 아래 그림은 구매용으로 잘라 둔 세 단이다.
테스트 환경을 어떻게 맞췄는가
같은 Ubuntu 클라우드 이미지를 쓰고 CPU·메모리·디스크만 바꿨다. 세대가 다른 머신의 차이를 OpenClaw 탓으로 돌리지 않기 위해서다. 설치 직후 apt update && apt upgrade를 한 뒤 Node(공식은 Node 26, 또는 Node 24.16+), Git, Docker Compose v2를 넣었다. SSH는 키만 연다. 호스트를 Linux로 둘지 클라우드 Mac으로 둘지는 상주 방식부터 갈리므로, 그 차이를 먼저 보고 싶다면 2026 클라우드 Mac에서 OpenClaw 배포: Linux VPS와 다른 macOS 검증, launchd 상주, 재현 가능한 FAQ를 같이 읽으면 게이트웨이를 어디에 둘지 결정하기 쉽다.
각 단에서 네 숫자를 남겼다. 시스템 유휴, 게이트웨이 유휴, Telegram 채널 하나를 붙인 뒤의 정상 상태, 도구 호출이 있는 메시지 한 통 이후의 피크다. 디스크는 Ubuntu 루트, Docker 레이어, ~/.openclaw 작업 공간을 본다. 세 번 잰 중앙값을 쓰고, 「운 좋게 안 죽은」 한 번은 버린다.
free -h의 available이다. VIRT의 허수는 보지 않는다. CPU는 60초 평균이고 순간 스파이크는 버린다. 디스크 숫자에는 스왑 파일 자체를 넣지 않는다.
Ubuntu와 Docker가 각각 얼마나 먹는지
22.04와 24.04 모두 OpenClaw 2.0을 돌린다. 24.04는 유휴에서 대략 100–200 MB를 더 쓰고, 대신 커널이 새롭고 LTS 창이 길다. 22.04는 장애 글이 많다. 어느 쪽이든 데스크톱 환경을 올리지 말 것. 클라우드 박스의 GUI는 게이트웨이에 남기려던 1 GB를 바로 가져간다.
Docker 비용은 두 줄이다. 엔진 유휴는 대략 150–250 MB. 이미지 디스크는 slim이 1–2 GB, Chromium이 들어간 -browser 변종이 한 단 더 는다. curl -fsSL https://openclaw.ai/install.sh | bash 본기 설치는 컨테이너 층이 없어 유휴는 더 얇지만, 롤백은 바이너리와 설정 사본을 직접 남겨야 한다. 4 GB에서는 본기 설치와 원격 API만 권한다. Docker를 쓰더라도 프리빌트만 당기고, 그 박스에서 docker build는 하지 말 것.
엔진은 공식 저장소로 깐다. 배포판 저장소의 낡은 패키지는 쓰지 않는다. 절차는 Docker 공식 Ubuntu 설치 문서를 따른다. 끝난 뒤 docker compose 플러그인인지 확인하고, 옛 docker-compose 바이너리는 버린다. OpenClaw Compose는 v2 기준으로 적혀 있다.
| 설치 경로 | 유휴 메모리 | 디스크 증가분 | 누구에게 맞나 |
|---|---|---|---|
| 본기 install.sh | 약 250–400 MB | 약 0.4–0.8 GB | 4 GB 시운전, 최소 오버헤드 |
| Docker 프리빌트 | 약 450–700 MB | 약 2–4 GB | 8 GB 일상, 격리·롤백 |
| 본기에서 이미지 빌드 | 피크 ≥ 6 GB | 빌드 캐시 별도 | 8 GB+ 또는 CI에서만 |
네 가지 사양 실측: CPU, 메모리, 디스크
이번 실측의 핵심 표다. CPU 열은 「스케줄이 버티는가」, 메모리 열은 「OOM이 오는가」, 디스크 열은 「설치 후에도 로그를 남길 수 있는가」다. 전부 원격 API, 단일 채널, 로컬 모델 없음이다.
| 사양 | CPU | 메모리 | 디스크 권장 | 결론 |
|---|---|---|---|---|
| 2C2G / 25 GB | 스케줄은 되나 동시성이면 흔들림 | available이 오래 300 MB 미만 | 설치 후 거의 없음 | 비권장, Docker 빌드는 반드시 OOM |
| 2C4G / 40 GB | 단일 채널은 충분 | 정상 상태 사용 약 2.1–2.6 GB | 40 GB가 딱 맞음 | 텍스트만, 브라우저는 끄기 |
| 2C8G / 80 GB | 이중 채널도 안정 | available이 자주 3 GB+ | 80 GB면 여유 | 원격 API 일상의 첫 선택 |
| 4C16G / 160 GB | 도구 호출 피크가 줄 서지 않음 | 7B 또는 브라우저 중 하나 | 모델 파일은 따로 계산 | 로컬 추론이 필요할 때 |
2C2G의 실패 패턴은 거의 같다. 게이트웨이가 뜬 뒤 available이 100–200 MB이고, Docker 한 겹이나 onboard 한 번이면 커널이 OOM을 낸다. 컨테이너 종료 코드 137이고 업무 로그는 거의 없다. 4 GB는 살아 남지만 브라우저 스킬, 본기 빌드, 로그 로테이션을 끄거나 켜는 선택이 강제된다. 8 GB에서 처음으로 「채널을 하나 더 열어도 되는」 여유가 보인다. 16 GB의 의미는 채팅을 빠르게 하는 것이 아니라, 로컬 모델을 논의할 자격이 생기는 것이다.
디스크는 생각보다 빨리 찬다. Ubuntu 업데이트 후 루트가 8–12 GB, Docker 이미지가 2–6 GB, 작업 공간과 로그가 한 달에 1–5 GB다. 공식 문구는 「이미지와 로그 공간을 남기라」 정도다. 운영 가능한 숫자로 적으면 로컬 모델 없이 최소 40 GB, 일상에 80 GB, 본기 모델은 10–20 GB를 더한다. 스왑 2–4 GB는 보험이지 메모리 계획이 아니다. 스왑에 들어가면 도구 호출의 꼬리 지연이 눈에 띄게 나빠진다.
로컬 모델 vs 원격 API: 비용 계산
원격 API는 추론을 VPS 밖으로 보낸다. 머신은 게이트웨이·채널·도구만 담당한다. 하드웨어를 가장 아끼는 쓰임이고, OpenClaw 공식 문서도 모델 공급자 키를 직접 넣는 전제다. 대가는 토큰 청구와, 컨텍스트가 그 박스를 떠난다는 점이다.
로컬 모델은 청구서를 메모리로 바꾼다. 7B 양자화 가중치는 대략 4–5 GB이고, Ollama 런타임과 KV 캐시까지 더하면 16 GB 머신에서 게이트웨이와 겨우 공존한다. 14B는 32 GB로 생각해야 한다. 품질·도구 추종·긴 컨텍스트에서 깎이는 분도 같이 계산한다.
2026년 흔한 Linux 클라우드 정가로 한 달을 거칠게 잡으면(달러, 트래픽 초과 제외) 아래와 같다.
| 방안 | 머신 월임대 | 모델 청구 | 합산 규모 | 적합 |
|---|---|---|---|---|
| 2C8G + 원격 API | 약 10–18 | 가벼우면 15–40, 헤비는 더 | 25–60 | 개인 비서, 민감도 낮은 컨텍스트 |
| 4C16G + 로컬 7B | 약 20–40 | 0 | 20–40 | 하루 호출이 많고 데이터가 나가지 않아야 함 |
| 8C32G + 로컬 14B | 약 40–80 | 0 | 40–80 | 클라우드 중형 모델에 가까운 품질 |
「로컬이 무조건 싸다」는 착각이 많다. 한 달에 짧은 대화를 수백 번만 하면, 원격 API 청구가 8 GB에서 16 GB로 올리는 차액보다 작은 달이 흔하다. 반대로 정각 크론 순찰, 채널에서 하루 수백 통, 로그가 나가지 말아야 하는 조건이 있으면 16 GB + 7B가 API 청구를 먼저 상쇄하고 프라이버시를 남긴다.
절충은 이쪽이 더 낫다. 게이트웨이의 주 모델은 원격에 두고, 제목·짧은 요약 같은 잡일은 공식에서 말하는 유틸리티 소형 모델이나 가끔 본기 7B로 넘긴다. 8 GB 한 대에서 브라우저 스킬과 로컬 14B를 동시에 열면 메모리 장부가 맞지 않는다.
주문 결정표
원하는 능력을 「동시에 성립해야 하는 조건」으로 적은 뒤 주문한다. 조건이 서로 싸우면 한 대에 브라우저와 14B를 욱여넣는 것보다 두 대로 쪼개는 편이 싸고 장애도 찾기 쉽다.
| 원하는 능력 | 최소 기동 | 권장 주문 | 하지 말 것 |
|---|---|---|---|
| Telegram / Discord 텍스트 비서 | 2C4G 본기 설치 | 2C8G + Docker 프리빌트 | 본기 이미지 빌드, 데스크톱 |
| 브라우저 스킬 추가 | 4C8G | 4C8G 또는 4C16G | 로컬 14B와 같은 머신 |
| 본기 7B 추론 | 4C16G | 4C16G NVMe 80 GB+ | 8 GB로 버티기 |
| 팀 다중 채널 + 감사 로그 | 4C8G | 4C8G / 80–160 GB | 로그 로테이션 없음 |
사양과 무관하게 「메모리가 모자란 것처럼」 보이게 만드는 두 가지가 있다. 게이트웨이를 0.0.0.0에 묶고 리버스 프록시가 없는 경우, 그리고 로그 디스크가 가득 찬 경우다. 전자는 127.0.0.1에 묶고 Nginx / Caddy를 앞에 둔다. 후자는 Docker와 journald에 크기 상한을 건다. 사양을 맞춘 뒤에도 이 두 항목이 다음 주 새벽에 디스크를 늘릴지 결정한다.
FAQ
1C1G나 2C2G로 시험할 수 있나?
설치 스크립트가 끝나는지만 확인하는 용도다. 채널을 붙이면 게이트웨이가 흔들리고, Docker 빌드는 거의 항상 137이다. 시험은 최소 4 GB, 남길 생각이면 처음부터 8 GB다.
반드시 Ubuntu여야 하나? Debian은?
Debian 12도 돌아가고 Docker 공식도 지원한다. Ubuntu를 고른 이유는 이미지를 찾기 쉽고 문서·장애 글이 맞물리기 때문이다. 운영 머신에 비 LTS 데스크톱으로 메우지 말 것.
병목은 CPU인가 메모리인가?
원격 API에서는 거의 전부 메모리와 디스크다. CPU가 첫 경고선이 되는 때는 로컬 추론, 브라우저 렌더, 본기 이미지 빌드뿐이다. 텍스트 게이트웨이에 4 vCPU는 사치고, 14B에는 필수다.
디스크는 일반 SSD인가 NVMe인가?
원격 API는 디스크에 둔감하다. 로컬 모델 로드와 Docker 레이어 전개는 NVMe 차이를 느낀다. 로그 로테이션을 켰다면 80 GB NVMe가 160 GB 느린 디스크보다 낫다.
게이트웨이는 Linux, 제어면은 클라우드 Mac mini
상주 OpenClaw 게이트웨이는 Linux VPS가 맞다. 싸고, 이미지가 표준이며, Docker 자료가 많다. 같은 흐름에 Safari 검수, Xcode 서명, 깨짐이 적은 당직기가 필요해지면, 이미 Docker와 로그를 돌리는 Linux에 짐을 더 올리는 순간 메모리 장부가 다시 적자가 된다. Apple Silicon 통합 메모리, 대기 약 4W, 장기 무인 운전에 맞는 macOS—이 세 가지는 「Linux를 32 GB로 한 단 더 올리는 일」과 다른 축의 선택이다.
더 안정적인 쪼개기는 이쪽이다. Linux 클라우드는 게이트웨이와 원격 API만, 클라우드 Mac mini는 네이티브 macOS가 필요한 빌드와 데스크톱 자동화만. Homebrew·Docker·SSH가 맥에서 바로 열리므로, 브라우저 스킬 하나를 위해 Ollama와 같은 RAM을 다툴 필요도 없다.
Linux 단을 이 글대로 정했다면, 다음 한 대는 추론과 메모리를 나누지 않는 제어 노드다. VPSSpark 클라우드 Mac mini M4가 그 자리다. 지금 플랜을 확인하세요. 주 단위·월 단위로 한 대를 더하는 편이, 모든 프로세스를 같은 VPS에 넣는 것보다 장애를 찾기 쉽다.