OpenClaw, 이렇게 굴리면 다르다: 한 개발자의 현실적인 보안·비용 운영기
OpenClaw는 단순한 chatbot이 아니다. sub-agent를 띄우고, tool을 호출하고, 외부 API를 두드리며, Drive나 Gmail 같은 서비스에 접근할 수 있는 agent 시스템이다. 즉, 설정 하나 잘못하면 자동화 도구가 아니라 자동화된 리스크가 된다.
이 개발자가 강조하는 메시지는 단순하다.
강력한 agent는 반드시 통제된 환경 안에서 돌아가야 한다.
그리고 그 통제는 감으로 하는 게 아니라, 구조로 설계해야 한다.
1. 전체 인프라 구성: 보안은 옵션이 아니라 기본값
1.1 VPS 위에서 돌리는 이유
OpenClaw는 개인 PC가 아니라 VPS 위에서 구동된다. SSH로 접속해 관리하는 전형적인 server 환경이다. 여기까지는 흔하다.
하지만 중요한 건 그 다음이다. 이 VPS는 그냥 public server가 아니다. 처음부터 외부에 열어둘 생각 자체가 없다.
1.1.1 Tailscale로 네트워크를 가둔다
접근은 Tailscale 기반의 private network 안에서만 허용된다. 즉, 승인된 device 혹은 IP에서만 server에 접근 가능하다.
인터넷 전체에 열어두고 "방화벽 잘 설정했으니까 괜찮겠지"라고 믿는 방식과는 결이 다르다. 애초에 외부에서 접근 자체가 불가능한 구조를 만든다.
1.1.2 firewall은 기본, localhost 바인딩은 필수
OpenClaw는 public IP가 아니라 localhost에서만 listen하도록 설정되어 있다.
많은 튜토리얼에서 VPS public IP에 바로 붙여버리는데, 이 개발자는 그 방식을 "굉장히 위험한 설정"이라고 단언한다.
이 구성에서는:
- 외부 scan에 잘 잡히지 않는다.
- ping, 무작위 SSH 시도는 전부 차단된다.
- firewall은 승인된 트래픽만 허용한다.
결국 요지는 하나다.
굳이 공격 표면을 만들 필요가 없다.
1.2 root로 실행하지 않는 이유
OpenClaw는 root 계정이 아니라 별도의 일반 user 계정으로 실행된다.
왜냐하면 root 권한을 가진 agent는 firewall을 끌 수도 있고, 시스템 설정을 바꿀 수도 있으며, sudo 명령까지 실행할 수 있기 때문이다.
agent가 실수하든, 외부 입력에 영향을 받든, 피해 범위를 줄이려면 최소 권한 원칙이 필수다.
이 부분은 단순 권장사항이 아니라, 장기 운영의 안전장치에 가깝다.
1.3 Telegram을 인터페이스로 선택한 이유
agent와의 주요 인터페이스는 Telegram이다.
이 선택도 감정이 아니라 계산이다.
- Telegram은 일상적으로 쓰는 메신저가 아니다.
- 개인 phone number와 깊게 얽혀 있지 않다.
- 설령 계정이 탈취되더라도 피해 범위가 제한적이다.
WhatsApp처럼 identity와 강하게 연결된 플랫폼은 일부러 피했다. 특히 2FA 코드 같은 민감한 영역과 연결될 가능성을 줄이기 위해서다.
2. Model 전략: 성능은 유지하되, 비용은 폭주시키지 않는다
OpenClaw를 24/7 돌린다는 건 곧 비용이 누적된다는 뜻이다. model 선택은 곧 월 지출과 직결된다.
2.1 frontier model을 그대로 물렸을 때의 현실
처음에는 Opus 4.5 같은 frontier model을 API로 연결했다.
결과는 빠르게 확인됐다.
- 몇 분 만에 몇 달러 소모
- 월 단위로 계산하면 수천 달러 예상
agent가 상시 실행 중이라면 이 구조는 거의 폭탄에 가깝다.
2.2 Codex를 기본으로 두는 전략
대안으로 선택한 것이 Codex model이다. 그리고 API 과금이 아니라 subscription 기반 사용이다.
ChatGPT Pro (월 $200)를 사용해 Codex를 연결한다.
비싸다고 느낄 수 있지만, 실제로는 상시 구동 환경에서 훨씬 안정적이다.
- coding 성능이 매우 뛰어나다.
- 대부분의 task에서 충분히 강력하다.
- usage limit이 상당히 높다.
일주일 동안 sub-agent를 계속 돌리고 heartbeat도 켜둔 상태였지만 daily, weekly quota에 거의 닿지 않았다고 한다.
2.3 두 개의 model을 병행하는 구조
완전히 Codex 하나로만 가는 것도 아니다.
- 일반 작업 → Codex
- 복잡한 planning → Opus 4.5
- Opus quota 소진 시 → Codex fallback
이 조합은 꽤 현실적이다. 고급 reasoning이 필요한 순간에는 frontier model을 쓰되, 상시 작업은 Codex가 처리한다.
결국 핵심은 이것이다.
성능은 전략적으로 쓰고, 비용은 구조적으로 통제한다.
3. Integrations: 편리함 뒤에 숨은 리스크 관리
agent를 유용하게 만들려면 integrations는 필수다. 하지만 동시에 가장 위험한 지점이기도 하다.
3.1 별도의 Google 계정 생성
개인 Gmail이나 주계정에 바로 연결하지 않는다.
대신 agent 전용 Google account를 새로 만들고, 다음 권한을 부여한다.
- Google Drive
- Google Calendar
- Google Sheets
- Gmail
이렇게 하면 업무 자동화는 가능하면서도 개인 계정과는 분리된다.
3.2 이메일 필터링으로 prompt injection 차단
주계정 이메일을 그대로 읽게 두지 않는다.
대신 다음 구조를 만든다.
- 주계정에 filter 설정
- trusted domain / trusted sender만 전용 계정으로 forwarding
- agent는 forwarding된 메일만 읽음
- 전용 계정으로 직접 보낸 메일은 읽지 못하도록 차단
이 구조의 목적은 명확하다.
무작위 발신자가 이메일에 조작된 prompt를 넣어 agent를 오동작시키는 것을 방지하기 위함이다.
3.3 API key는 항상 제한을 건다
각종 API integration에는 usage limit과 알림을 설정한다.
만약 key가 유출되더라도:
- 피해 범위를 최소화
- 즉시 key rotation 가능
이건 사소해 보이지만, 실제 운영에서는 매우 중요한 안전장치다.
4. Ops Hub: 먼저 보이고, 그 다음 자동화한다
초기에는 agent가 무엇을 하는지 파악하기 어려웠다. 이상한 동작을 해도 추적이 힘들었다.
그래서 가장 먼저 한 작업은 기능 추가가 아니라 관측 시스템 구축이었다.
4.1 커스텀 대시보드 구축
"Ops Hub"라는 dashboard를 만들어 다음을 확인할 수 있도록 했다.
- 실시간 sub-agent 현황
- error 로그
- session 기록
- tool 호출 내역
- prompt 흐름
실제로 여러 sub-agent를 동시에 띄워 작업을 시키고, dashboard를 새로고침하면서 세션이 생성되는 모습을 확인한다. 로그를 열어 어떤 tool을 호출하는지도 즉시 확인 가능하다.
이 과정은 단순히 "재미"가 아니라, 신뢰를 위한 장치다.
4.2 token usage와 비용 추적
별도의 token usage 뷰를 만들어:
- 사용량
- quota 상태
- session별 비용 추정
을 한눈에 확인한다.
비용 추정이 완벽히 정확한지는 추가 검증이 필요하지만, 최소한 감각 없이 쓰는 일은 없다.
5. 실제 활용 사례
이 개발자는 스스로를 "아직 full power user는 아니다"라고 말한다. 하지만 이미 몇 가지 영역에서는 꽤 의미 있는 자동화를 구현했다.
5.1 YouTube outlier 분석 자동화
coding 채널을 운영하는 입장에서 매일 아이디어가 필요하다.
agent는 다음을 수행한다.
- 유사 채널 탐색
- 평균 대비 성과가 높은 outlier video 탐지
- views per hour 계산
- daily report 생성
이 보고서를 기반으로 새로운 영상 아이디어를 정리한다.
5.2 YouTube 운영 시스템 구축
report에서 나온 아이디어를 저장하고 추적하는 "YouTube operating system"을 만들었다.
- 아이디어 저장
- 자동 정리
- 아침 리포트 발송
단순 리서치에서 끝나지 않고, 실제 콘텐츠 전략으로 이어지는 구조다.
5.3 Accounting 자동화
이 부분이 특히 실용적이다.
이메일로 들어오는:
- receipt
- invoice
- sponsorship 계약
- bank statement
등을 자동 분류하고, 필요한 정보를 추출해 Google Sheets에 기록한다.
PDF 저장, invoice 생성, 결제 내역 매칭까지 수행한다.
특정 command로 invoice를 생성하면:
- 자동 생성
- Google Drive 업로드
- invoice tracking sheet 반영
심지어 들어온 payment를 기존 invoice와 연결해 정산까지 맞춘다.
수작업으로 하면 상당히 번거로운 과정을 자동화한 셈이다.
5.4 Kanban 기반 자율 작업 구조
agent 전용 Kanban board를 만들어 backlog를 관리한다.
- to-do 목록 생성
- 30분마다 heartbeat 실행
- 여러 sub-agent 병렬 처리
- 완료 시 done으로 이동
한 번에 수백 개 task를 넣어두고 agent가 계속 처리하게 만든다.
subscription quota가 넉넉하다는 점을 활용한 전략이다.
5.5 GitHub 자동 저장 구조
agent 전용 GitHub account를 생성한다.
agent가 작성한 모든 code는:
- 자동 commit
- organization repository에 저장
이렇게 하면 작업 내역을 언제든지 추적 가능하다.
6. cron 기반 자동 작업
정기적으로 실행되는 작업들도 있다.
- sponsorship contact logging
- AI accounting triage
- YouTube outlier research
- daily self-improvement
- backlog 점검
보여주지 않은 private workflow도 일부 존재한다.
7. 한계와 현실적인 평가
이 개발자는 이 시스템을 "인생을 바꾸는 도구"라고 표현하지 않는다.
하지만 분명히 시간을 절약해 준다고 말한다.
혁명이라기보다는, 꾸준한 시간 절약 장치에 가깝다.
아직 개선할 부분도 있고, cost estimation 정확도도 검증이 더 필요하다. 하지만 구조 자체는 안전성과 실용성을 모두 고려한 설계다.
핵심 개념 정리
localhost binding
외부에서 직접 접근할 수 없도록 service를 로컬 인터페이스에만 묶는 설정.
least privilege
필요 최소한의 권한만 부여해 피해 범위를 제한하는 원칙.
prompt injection
외부 입력을 통해 agent 동작을 왜곡시키는 공격 방식.
observability
agent의 행동을 로그와 session 단위로 추적할 수 있는 능력.
단계별 운영 요약
- VPS에 배포
- Tailscale + firewall 구성
- localhost 바인딩
- non-root user 실행
- Codex 기본 + Opus 보조 전략
- 전용 Google account 생성
- trusted email forwarding 구성
- API key 제한
- Ops Hub 구축
- 고마찰 업무부터 자동화
결국 이 사례가 보여주는 방향은 분명하다.
OpenClaw를 제대로 쓰려면, 기능보다 먼저 구조를 고민해야 한다.
보안, 비용, 관측 가능성. 이 세 가지를 먼저 설계하면, 그 다음 자동화는 자연스럽게 따라온다.
'SW > 인공지능' 카테고리의 다른 글
| 2026년 AI 코딩 에이전트 완전 정리: Cloud Agent가 로컬보다 느린 이유와 해결법 (0) | 2026.03.27 |
|---|---|
| 2026년 AI 시대 소프트웨어 개발 변화 정리: 코드는 쉬워지고 ‘코드 이해력’이 핵심이 된 이유 (0) | 2026.03.25 |
| 2026년 ChatGPT App Store 완전 정리: MCP 기반 interactive UI 앱 만드는 방법 (0) | 2026.03.18 |
| Warp로 Cloud에서 여러 AI Agent 동시에 실행하는 방법: GitHub PR 자동화까지 완전 가이드 (0) | 2026.03.17 |
| OpenClaw 설치 방법 총정리: VPS 배포부터 Docker 설정, API key 연결까지 완벽 가이드 (2026) (0) | 2026.03.13 |