6부·25장 개인 사용자를 위한 7단계 하드닝

바닷가재를 오래 부려먹고 싶다면, 수조부터 단단해야 한다. OpenClaw 보안은 멋진 암호학보다 훨씬 현실적인 데서 갈린다. 어디서 돌리는지, 어떤 포트를 열어뒀는지, 키를 어디에 넣어뒀는지, 스킬을 얼마나 쉽게 믿는지 같은 것들 말이다.

이 장의 목표는 완벽한 보안을 약속하는 것이 아니다. 대신 개인 운영자가 오늘 바로 적용할 수 있는 최소 안전 기준을 세우는 것이다. 기준이 분명하면 편의성과 안전 사이에서 흔들릴 때도 판단이 쉬워진다. "조금 불편하지만 살아남는 설정"이 "아무 생각 없이 편한 설정"보다 훨씬 싸게 먹힌다.

시작하기 전에 딱 두 가지는 먼저 하자. 첫째, openclaw --version으로 버전을 확인하고 최신 보안 패치가 들어간 릴리스를 사용한다. 둘째, Control UI의 등록된 기기 목록에서 내가 직접 페어링한 장치만 남긴다. ClawJacked류 문제는 패치 후에도 이미 등록된 수상한 기기가 계속 남아 있을 수 있기 때문이다.¹ 마이크로소프트의 표현을 빌리면, OpenClaw는 그냥 채팅 앱이 아니라 지속적 자격 증명을 쥔 채 돌아가는 신뢰하기 어려운 코드 실행 환경으로 다뤄야 한다.²

1단계. 격리: 에이전트를 내 일상 컴퓨터에서 떼어내기

가장 먼저 바꿔야 할 것은 설정 파일이 아니라 운영 위치다. OpenClaw를 평소 쓰는 메인 노트북 위에 그대로 올리면, 에이전트가 만질 수 있는 세계가 너무 넓어진다. 브라우저 세션, 메신저 로그인, SSH 키, 클라우드 CLI 인증, 비밀번호 관리자, 회사 SSO 쿠키가 한 상자에 들어 있기 때문이다. 사고가 나면 피해도 한 번에 난다.²

개인 사용자에게 현실적인 선택지는 세 가지다.

• 가장 권장되는 방식은 오래된 노트북, 미니 PC, 혹은 별도 맥 미니처럼 에이전트 전용 장치를 하나 두는 것이다.

• 가성비를 따지면 월 5달러 안팎의 작은 VPS나 홈서버를 따로 두고, 그 안에서만 OpenClaw를 운영하는 방법이 좋다.

• 가볍게 실험할 때는 VM이나 Windows Sandbox를 쓴다. 특히 Windows Sandbox는 닫으면 흔적이 사라지는 일회용 실험실이라, 새로운 설정이나 수상한 스킬을 시험해보기 좋다.³

여기서 중요한 포인트가 하나 있다. WSL2는 좋은 실행 환경이지, 강한 보안 경계 자체는 아니다. Windows에서 OpenClaw를 안정적으로 돌리는 데는 훌륭하지만, "내 본체와 완전히 분리된 금고"라고 생각하면 과신이다. 오래 돌릴 운영 환경이라면 별도 장치나 VM이 낫고, Windows에서 처음 만져볼 때는 Sandbox가 훨씬 마음 편하다.³

격리는 거창할 필요가 없다. 오늘 당장 할 수 있는 최소선은 이 정도다. OpenClaw 전용 OS 사용자 계정을 만들고, 관리자나 root로 실행하지 않는다. 그리고 에이전트가 쓰는 브라우저 프로필은 평소 내 메인 프로필과 분리한다. 개인 브라우저의 동기화, 저장된 비밀번호, 결제 정보까지 에이전트 옆에 붙여둘 이유는 없다.⁴

2단계. 네트워크: 게이트웨이는 드러나지 않을수록 안전하다

다음은 네트워크다. 아주 단순하게 기억하면 된다. OpenClaw 게이트웨이는 보여야 할 사람에게만 보여야 한다. 가능하면 기본값은 "아무에게도 안 보임"이어야 한다.

우선 게이트웨이를 반드시 루프백에 바인딩한다. 127.0.0.1에만 묶어두면 같은 장치 안에서만 접근할 수 있다. 0.0.0.0으로 열어두면 집 공유기 안의 다른 장치, 같은 카페 와이파이의 다른 기기, VPS라면 인터넷 전체가 잠재적 관객이 된다.¹⁵

openclaw --version
openclaw config set gateway.bind "loopback"
ss -tlnp | grep 18789

확인할 때는 127.0.0.1:18789처럼 보여야 한다. 0.0.0.0:18789가 보이면 바로 수정하는 편이 좋다.¹

인증도 반드시 켠다. "어차피 localhost인데요?"라는 생각이 제일 위험하다. 이미 앞 장에서 봤듯이, 로컬이라는 말은 브라우저를 통한 공격 앞에서 성벽이 아니다. 긴 랜덤 토큰 기반 인증을 켜고, 의심스러운 상황이 있었다면 토큰을 바로 회전한다.⁴⁵

외부에서 접속해야 할 때도 포트 포워딩으로 18789를 그대로 내보내지 말자. 개인 운영자에게는 SSH 터널이나 Tailscale 같은 사설 경로가 훨씬 낫다. 이 방식의 장점은 두 가지다. 밖에서 접속할 수 있으면서도, 검색 엔진이나 자동 스캐너 눈에는 거의 안 띈다. 즉, 편의성과 은폐성을 같이 챙길 수 있다.⁴⁷

방화벽도 마지막 문지기다. VPS를 쓴다면 18789 포트는 외부에서 닫혀 있어야 한다. Docker를 쓰더라도 127.0.0.1:18789:18789처럼 로컬만 노출되게 매핑하는 습관을 들이자. 보안에서 "아마 안 열렸겠지"는 늘 나쁜 문장이다.¹⁵

3단계. 자격 증명: 키를 파일 서랍이 아니라 금고에 넣기

OpenClaw에서 진짜 비싼 자산은 프롬프트가 아니라 자격 증명이다. Anthropic 키, OpenAI 키, GitHub 토큰, Gmail OAuth, Telegram 봇 토큰, 캘린더 권한. 이 중 하나만 새면 에이전트가 하던 일이 통째로 공격자의 일이 된다.

그래서 원칙은 간단하다. 가능하면 평문 파일에 두지 말고, 운영체제가 제공하는 보관소나 비밀번호 관리자에 넣는다. macOS라면 Keychain, Windows라면 Credential Manager, Linux 데스크톱이라면 libsecret 계열 보관소를 우선 생각하자. 1Password나 Bitwarden 같은 비밀번호 관리자도 훌륭한 출발점이다.⁶

평문 .env 파일은 편하긴 하다. 문제는 너무 편하다는 것이다. 백업 파일, 에디터 스왑 파일, Git 이력, 실수로 올린 저장소, 터미널 히스토리, 디버그 로그에 너무 쉽게 남는다. "키를 교체했으니 괜찮다"고 생각해도, 예전 키가 백업 파일에 살아 있는 경우가 생각보다 많다.⁶

실무적으로는 이렇게 나누면 좋다.

• 개발용 키와 운영용 키를 분리한다.

• OAuth 권한은 읽기 전용부터 시작하고, 꼭 필요할 때만 쓰기 권한을 붙인다.

• 한 달 주기 또는 스킬 설치 후, 혹은 감염이 의심되는 직후에 토큰을 돌린다.

정말 파일을 써야 한다면 최소한 권한은 잠가두자. 자격 증명 파일은 600, 디렉터리는 700 정도로 맞추고, 저장소에는 절대 올리지 않는다. 셸에서 export OPENAI_API_KEY=...를 남발하는 습관도 좋지 않다. 빠르긴 하지만, 히스토리와 스크린샷과 복붙 흔적에 너무 잘 남는다.¹⁵

4단계. 스킬 검증: 스킬은 기능 팩이 아니라 외부 코드다

이 단계가 귀찮아서 대부분의 사고가 난다. 하지만 바로 그래서 중요하다. 스킬은 플러그인이 아니라 인터넷에서 내려받은 외부 코드라고 생각해야 한다. 이름이 예쁘고 설명이 친절하다고 안전한 게 아니다.

가장 먼저 해야 할 일은 자동 설치를 끄는 것이다. 에이전트가 스스로 스킬을 설치할 수 있게 두면, 편리함이 아니라 공급망 공격 자동화를 켜둔 셈이 된다. 스킬 설치는 항상 수동 승인으로 바꾸자.⁵

그리고 설치 전에는 반드시 SKILL.md를 먼저 읽는다. 코드는 그다음이다. 특히 아래 항목이 보이면 한 번 더 멈추자.

• exec(), spawn(), 셸 명령 실행

• 알 수 없는 도메인으로 나가는 fetch()나 HTTP 요청

• ~/.ssh, ~/.aws, 브라우저 프로필, .env를 읽는 코드

• eval, base64 디코딩, 동적 import처럼 의도를 숨기기 쉬운 패턴

ClawHavoc 이후에는 "문서가 더 위험한 코드"인 경우도 많이 드러났다. 그래서 코드를 읽고 안심하지 말고, 설치 안내에 외부 ZIP 다운로드나 별도 스크립트 실행이 들어 있으면 사실상 빨간불이라고 보면 된다.⁵

또 하나 놓치기 쉬운 것이 MCP 서버 설정이다. 겉으로는 단순한 스킬처럼 보여도, 뒤에서는 외부 SaaS와 연결된 MCP 서버가 넓은 권한을 가지고 있을 수 있다. 설치 후에는 OpenClaw가 알고 있는 스킬 경로와 실제 디스크 위의 SKILL.md 파일들을 비교하고, 어떤 MCP 서버가 어떤 URL이나 바이너리를 쓰는지 확인하자. 내 에이전트가 알고 있는 것보다 디스크에 더 많은 스킬이 있다면, 이미 이상 신호다.¹

가능하면 openclaw security audit --deep 같은 내장 점검과 외부 검사 도구를 함께 쓰고, 정말 중요한 스킬은 버전을 고정해두자. 자동 업데이트로 어느 날 갑자기 "어제까지는 멀쩡하던 스킬"이 달라지는 것도 충분히 현실적인 시나리오다.⁴⁵

5단계. 모델 선택: 도구가 붙을수록 더 똑똑한 모델을 써야 한다

모델 비용을 아끼고 싶은 마음은 누구나 같다. 하지만 OpenClaw에서는 값싼 모델이 오히려 비싼 사고로 돌아올 수 있다. 이유는 간단하다. 채팅에서는 엉뚱한 답이 나와도 웃고 넘길 수 있지만, 도구가 붙은 에이전트는 엉뚱한 행동을 남긴다.

그래서 셸 실행, 파일 수정, 브라우저 제어, 외부 전송처럼 권한 있는 작업에는 최신 상위 모델을 쓰는 편이 낫다. 지시를 더 안정적으로 따르고, 수상한 입력에 흔들릴 가능성도 상대적으로 낮다. 반대로 작은 모델이나 로컬 모델은 읽기 전용 요약, 초안 작성, 분류, 태깅처럼 위험도가 낮은 작업에 배치하는 것이 좋다.⁴

실무 감각으로 나누면 이렇다. 메일 초안 작성, 오늘 할 일 요약, 블로그 아이디어 정리 정도는 저위험이다. 하지만 파일 삭제, 명령 실행, 민감한 서비스 호출, 외부 발송이 섞이면 바로 고위험으로 올라간다. 이 구간에서는 모델 비용보다 사고 비용이 더 크다.

작은 모델을 꼭 써야 한다면 도구를 줄여야 한다. 웹 검색, 웹 가져오기, 브라우저, 셸 실행처럼 공격 표면을 넓히는 기능은 끄고, 샌드박스를 더 강하게 건다. 머리가 덜 단단하면 손발이라도 묶어야 한다는 뜻이다.⁴

6단계. 승인 게이트: 위험한 행동은 반드시 사람에게 묻기

좋은 에이전트는 부지런해야 하지만, 마음대로 결정하면 안 된다. 특히 개인 운영자에게 필요한 것은 완전 자율이 아니라, 잘 짜인 승인 게이트다. 사람이 마지막 도장을 찍는 순간을 남겨두면 사고 절반은 줄어든다.

가장 쉬운 방법은 작업을 세 단계로 나누는 것이다.

• 초록: 읽기, 요약, 분류, 초안 작성처럼 결과를 봐도 바로 복구 가능한 일

• 노랑: 메시지 발송, 일정 수정, 파일 쓰기, PR 생성처럼 외부 상태를 바꾸는 일

• 빨강: 삭제, 결제, 권한 변경, 스킬 설치, 배포, 토큰 회전처럼 되돌리기 비싼 일

초록은 자동으로 돌려도 된다. 노랑은 "실행 전 미리보기 + 확인"을 붙인다. 빨강은 무조건 사람 승인이다. 이 규칙만 있어도 OpenClaw가 열심히는 일하되, 선을 넘지는 않는다.

메신저 정책도 같은 원리다. DM은 페어링된 사용자만 허용하고, 그룹에서는 멘션이 있을 때만 반응하게 하자. 가능하면 그룹 사용 자체를 최소화하고, 내 계정만 허용하는 allowlist를 두는 것이 좋다. 에이전트가 여러 사람 말에 반응하기 시작하면, 순식간에 유능한 비서가 아니라 아무 말이나 듣는 심부름꾼이 된다.⁴⁷

스킬 설치도 승인 게이트 대상이다. "생산성 향상용 스킬 하나쯤이야"라는 생각이 가장 위험하다. 설치, 업데이트, 권한 확장, 외부 발송, 파일 삭제, 크론 작업 등록은 모두 사람이 한 번 더 보는 습관을 들이자. 편리함이 조금 느려지는 대신, 밤사이 재앙이 일어날 가능성이 크게 줄어든다.⁵

7단계. 백업: 안전의 마지막 이름은 재구축 가능성이다

보안은 "절대 안 뚫림"이 아니라 "뚫려도 다시 일어설 수 있음"에 가깝다. 그래서 마지막 단계는 백업이다. 특히 OpenClaw는 워크스페이스 파일이 곧 성격과 기억과 운영 규칙이기 때문에, 무엇을 백업하고 무엇을 백업하지 않을지를 나눠야 한다.

우선 SOUL.md, AGENTS.md, USER.md, HEARTBEAT.md는 Git으로 관리하는 것이 좋다. MEMORY.md도 통째로 넣기보다는 민감한 내용이 없는 범위에서 스냅샷을 남기거나, 암호화된 저장소에 별도로 보관하는 편이 낫다. 자격 증명 파일과 세션 토큰, 로그 덤프는 같은 저장소에 넣지 말자. 복구용 백업이 유출용 묶음 파일이 되면 곤란하다.

설정 무결성 확인도 같이 해두면 좋다. 예를 들어 identity.json 같은 핵심 파일은 해시 기준선을 만들어 두고, 주기적으로 값이 바뀌었는지 확인한다. 스킬 설치 뒤나 이상한 행동이 보인 뒤에 해시가 달라졌다면, "내가 바꾼 것인지"부터 확인해야 한다.¹

백업은 복사만으로 끝나지 않는다. 재구축 순서를 알고 있어야 진짜 백업이다. 가장 건강한 운영 방식은 이렇다. 의심 상황이 생기면 먼저 OpenClaw를 멈춘다. 등록 기기와 스킬을 점검한다. 토큰을 모두 회전한다. 필요하면 깨끗한 VM이나 새 장치에 다시 설치한다. 그리고 마지막에 검증된 워크스페이스 파일만 복원한다.¹²

여기서 감이 온다. 우리가 지키려는 것은 단순한 파일이 아니다. 내 에이전트의 성격, 규칙, 기억, 습관이다. 그러니 백업은 단순 복제가 아니라, 안전한 재탄생 설계도에 가깝다.

오늘 바로 적용할 최소 안전 기준

이 장을 덮기 전에, 아래 일곱 줄만 체크해도 개인 운영자로서는 상당히 좋은 출발선에 선다.

• OpenClaw를 메인 업무 노트북이 아닌 별도 장치, VM, 혹은 전용 계정에서 돌린다.

• 게이트웨이는 127.0.0.1에만 바인딩하고, 원격 접속은 Tailscale이나 SSH 터널로 해결한다.

• API 키와 토큰은 OS 키체인이나 비밀번호 관리자에 보관하고, 평문 파일은 최소화한다.

• 스킬 자동 설치를 끄고, SKILL.md와 코드, MCP 설정을 직접 읽고 승인한다.

• 파일·셸·네트워크 권한이 있는 에이전트에는 최신 상위 모델을 쓴다.

• 삭제, 발송, 설치, 결제, 권한 변경은 모두 사람 승인 게이트 뒤에 둔다.

• 워크스페이스 파일은 Git이나 암호화 백업으로 보관하고, 감염 시 재구축 절차를 따로 적어둔다.

완벽한 보안은 늘 멀리 있다. 하지만 개인 운영자에게 중요한 것은 완벽함보다 버티는 힘이다. OpenClaw를 쓰는 순간 우리는 이미 강력한 도구를 손에 쥔 것이다. 그 힘을 제대로 누리려면, 에이전트에게 자유를 주기 전에 먼저 울타리를 세워야 한다. 울타리가 좋아야 바닷가재도 오래 산다.

참고

¹OpenClaw Security Hardening Checklist (2026)

²Running OpenClaw safely: identity, isolation, and runtime risk

³Run OpenClaw Locally on Windows Using Windows Sandbox for Secure Isolation

⁴The OpenClaw Hardening Checklist - In-Depth Edition

⁵OpenClaw Hardening Checklist: 15 Steps to Secure Your Setup

⁶Credential Isolation Guide

⁷OpenClaw Security 101: A Complete Hardening Guide 2026