OpenClaw 보안, 진짜 나아졌나?: v2026.2.x 보안/안정성 총정리
2편에서 '프로덕션 사용 비권장'이라고 결론 내렸다. 10일 후 보안 강화 10건+가 릴리즈됐다. auth none 제거, 포괄적 보안 실드 7,774줄, 프롬프트 인젝션 방어까지. 정말 나아졌을까?
백호OpenClaw 보안, 진짜 나아졌나?: v2026.2.x 보안/안정성 총정리
2편에서 "프로덕션 사용 비권장"이라고 결론 내렸다. 10일 후, OpenClaw 팀이 보안 강화 10건+를 릴리즈했다. 정말 나아졌을까?
시리즈 안내
이 글은 "Moltbot 완전 정복" 시리즈의 6편입니다.
| 편 | 제목 | 핵심 | |----|------|------| | 1편 | 전격 분석 | Mac Mini 품절 사태, 핵심 기능 | | 2편 | 보안 해부 | 5대 취약점, "프로덕션 사용 비권장" | | 3편 | 맥북 셋업 가이드 | 단계별 설치, 보안 설정 | | 4편 | 5계층 방어 전략 | 네트워크~모니터링 보안 강화 | | 5편 | v2026.2.9 신기능 | iOS 앱, 대시보드, 새 모델 | | 6편 | 이 글 | 보안 개선 검증, 2편 체크리스트 재평가 |
TL;DR: 2편 취약점 vs v2026.2.x 대응
| 2편에서 지적한 취약점 | 심각도 | v2026.2.x 대응 | 상태 | |----------------------|--------|---------------|------| | 평문 자격증명 저장 | Critical | (변경 없음) | 미해결 | | 노출된 관리 포트 | Critical | auth "none" 제거 (Breaking!) | 해결 | | 프롬프트 인젝션 | High | 입력 격리 태그 + SSRF 강화 + 포괄적 보안 실드 | 상당히 개선 | | 스킬 중독 (공급망) | High | 코드 안전 스캐너 내장 | 부분 해결 | | 명령 인젝션 | High | escapeShellCommand + exec allowlist + 환경변수 필터링 | 상당히 개선 |
결론 미리보기: 가장 심각했던 "인증 없는 인스턴스" 문제가 원천 차단됐다. 방향은 맞다. 하지만 평문 자격증명은 여전히 숙제다.
1. Breaking Change: Gateway auth "none" 제거
이번 업데이트에서 가장 결정적인 변화다.
2편에서 가장 충격적이었던 발견: Shodan으로 수백 개 인스턴스가 발견됐고, 그 중 8개는 인증 없이 완전 오픈이었다. API 키, 대화 기록, OAuth 토큰이 누구에게나 노출된 상태.
v2026.1.31에서 OpenClaw은 과감한 결정을 내렸다: auth mode "none" 자체를 삭제.
// Before (v2026.1.30) - 이런 설정이 가능했음
"gateway": {
"auth": { "mode": "none" } // 인증 없음 - 누구나 접근
}
// After (v2026.2.x) - 더 이상 불가능
// "none" 모드 제거됨
// token 또는 password 필수
// (Tailscale Serve ID만 예외 허용)
왜 중요한가
| 항목 | Before | After | |------|--------|-------| | 기본 인증 | 선택 (none 가능) | 필수 (token/password) | | 4편 1층 방어 | 수동으로 설정 필요 | 자동 강제 | | Shodan 노출 | 인증 없는 인스턴스 존재 | 원천 불가능 |
이것은 Breaking Change다. 기존에 auth "none"으로 운영하던 사용자는 업데이트 시 게이트웨이가 시작되지 않는다. 하지만 보안 관점에서는 올바른 결정이다.
4편에서 "1층: 네트워크 격리"를 필수로 표시했다. 이제 1층의 핵심인 인증이 기본값으로 강제된다. 더 이상 설정을 잊어서 노출될 일이 없다.
2. 포괄적 보안 실드 (PR #4570) - 7,774줄의 방어 체계
2편에서 지적했던 보안 PR들의 상태부터 확인하자.
| PR | 제목 | 2편 상태 | 현재 상태 | |----|------|---------|----------| | #4542 | Prompt/Credential/Command Injection 수정 | 리뷰 0, 대기 | Merged | | #4570 | Comprehensive Security Shield | 리뷰 0, 대기 | Merged | | #4576 | Gateway public IP binding 경고 | 리뷰 2 | Merged |
3개 모두 머지됐다. 2편에서 "리뷰어 병목"을 지적했는데, 실제로 머지까지 완료된 것은 좋은 소식이다.
특히 PR #4570은 40개 파일, 7,774줄의 대규모 보안 패치다. 5계층 보안 아키텍처를 한 번에 추가했다:
HTTP/WS 요청
↓
[Rate Limiter] IP 기반 요청/인증/연결 제한
↓
[Intrusion Detector] 패턴 기반 공격 탐지
↓
[IP Manager] 차단/허용 리스트 + CIDR
↓
[Firewall Manager] iptables/ufw 자동 적용 (Linux)
↓
[Alert Manager] Telegram/Webhook/Slack/Email 알림
↓
[Security Logger] JSONL 감사 로그
Rate Limiting 상세
| 대상 | 제한 | 기간 | |------|------|------| | IP당 인증 시도 | 5회 | 5분 | | IP당 동시 연결 | 10개 | - | | IP당 요청 | 100회 | 1분 | | 디바이스당 인증 | 10회 | 15분 | | 페어링 요청 | 3회 | 1시간 |
Intrusion Detection 패턴
| 공격 유형 | 탐지 조건 | 자동 대응 | |----------|----------|----------| | 브루트 포스 | 10분 내 실패 10회 | 24시간 자동 차단 | | SSRF 우회 | 5분 내 3회 | 경고 | | 경로 순회 | 5분 내 5회 | 경고 | | 포트 스캔 | 10초 내 20회 | 경고 |
Zero Dependencies: Redis나 PostgreSQL 없이 Node.js 내장만으로 동작한다. Token Bucket 알고리즘 + LRU 캐시(10k 엔트리)로 구현.
이것은 4편에서 직접 구축했던 "5층: 모니터링"을 공식적으로 대체할 수 있는 수준이다.
3. 프롬프트 인젝션 방어 (PR #4542)
2편에서 가장 충격적이었던 데모: 악성 이메일 → AI가 사용자 이메일 5개를 공격자에게 전송. 5분 만에 성공.
PR #4542가 머지되면서 3가지 방어가 추가됐다:
3.1 입력 격리 태그
// Before: 사용자 입력과 시스템 지시가 구분 없이 혼합
"사용자가 보낸 메시지"
// After: [USER_MESSAGE] 태그로 격리
[USER_MESSAGE]사용자가 보낸 메시지[/USER_MESSAGE]
시스템 프롬프트에 CRITICAL 보안 지시가 추가되어, LLM이 사용자 입력을 시스템 명령으로 해석하는 것을 방지한다.
3.2 환경변수 필터링
// sensitive-env-vars.ts - 64개 민감 변수 목록
const SENSITIVE_VARS = [
'ANTHROPIC_API_KEY',
'OPENAI_API_KEY',
'GITHUB_TOKEN',
'AWS_ACCESS_KEY_ID',
'AWS_SECRET_ACCESS_KEY',
// ... 59개 더
]
// 자식 프로세스 실행 시 자동 제거
const safeEnv = scrubSensitiveEnv(process.env)
2편에서 "자식 프로세스에 API 키가 노출됨"이라고 지적했다. 이제 64개 민감 환경변수가 자동으로 필터링된다.
3.3 셸 이스케이핑
// shell-utils.ts
function escapeShellCommand(cmd, shell) {
if (shell.includes('powershell')) {
return `"${cmd.replace(/"/g, '`"')}"` // PowerShell
} else {
return `'${cmd.replace(/'/g, "'\\''")}'` // POSIX
}
}
2편에서 보여줬던 공격:
# Before: userMessage = '"; rm -rf / #' → 명령 인젝션 성공
# After: escapeShellCommand가 메타문자를 이스케이프 → 일반 문자열로 처리
4. SSRF 보호 반복 강화
Server-Side Request Forgery(SSRF): AI가 외부 입력을 통해 내부 네트워크 자원에 접근하는 공격.
v2026.2.x에서 3개 버전에 걸쳐 반복 강화했다:
| 버전 | 보호 내용 | |------|---------| | 2026.2.1 | 플러그인/훅 설치 경로 검증 (경로 이동 거부) | | 2026.2.2 | 스킬 설치/미디어 이해 시 SSRF 검사 강화 | | 2026.2.2 | 미디어 auth 재시도 제한 | | 2026.2.9 | 원격 미디어 가져오기 SSRF 보호 추가 강화 |
단일 패치가 아닌 반복 강화라는 점이 주목할 만하다. 공격 벡터를 하나씩 차단하면서 방어를 넓히고 있다.
5. 스킬/플러그인 코드 안전 스캐너
2편에서 **스킬 중독(공급망 공격)**을 High 심각도로 분류했다. 누구나 스킬을 업로드할 수 있고, 악성 curl이나 exec 명령이 포함된 스킬이 7개국에서 다운로드됐다.
그때 대응책으로 Cisco의 외부 Skill Scanner를 권장했다:
# 2편 권장 (외부 도구)
skill-scanner analyze ./my-skill/
v2026.2.6에서 OpenClaw에 코드 안전 스캐너가 내장됐다.
내장 스캐너가 탐지하는 패턴
curl,wget,fetch등 외부 네트워크 호출exec,eval,spawn등 임의 코드 실행process.env접근 (환경변수 탈취)- 의심스러운 URL 패턴
- 난독화된 코드
2편 대비 개선점
| 항목 | 2편 시점 | v2026.2.6 이후 | |------|---------|---------------| | 스캐너 | 외부 도구 (Cisco) | 내장 | | 실행 시점 | 수동 | 스킬 설치 시 자동 | | 커버리지 | 기본 패턴 | 확장된 패턴 |
하지만 한계도 있다: ClawdHub 심사 프로세스는 여전히 부재한다. 스캐너가 탐지하지 못하는 우회 패턴이 존재할 수 있다. 2편의 "승인된 스킬만 사용" 권장은 여전히 유효하다.
6. 경로 순회 방지 (5건+)
2편에서는 명시적으로 다루지 않았지만, 경로 순회(Path Traversal)는 심각한 보안 위협이다. ../../../etc/passwd 패턴으로 시스템 파일에 접근하는 공격.
v2026.2.x에서 5건 이상의 경로 순회 방지가 추가됐다:
| 버전 | 보호 대상 | |------|---------| | 2026.2.1 | 플러그인/훅 설치 경로 검증 | | 2026.2.2 | WhatsApp accountId 경로 순회 방지 | | 2026.2.2 | Windows exec allowlist (cmd.exe 우회 차단) | | 2026.2.2 | Matrix 전체 MXID 필수 (모호한 이름 해석 제거) | | 2026.2.9 | LFI 경로 추출 제한 | | 2026.2.9 | 메시지 도구 filePath/path 샌드박스 검증 |
채널별(WhatsApp, Matrix)과 기능별(메시지 도구, 미디어)로 개별 패치가 이루어졌다. 공격 표면이 넓은 만큼 방어도 넓게 적용한 것.
7. exec 승인 시스템 (3-계층 정책)
2편에서 명령 인젝션을 High 심각도로 분류했다. v2026.2.x에서는 단순 allowlist를 넘어 3-계층 정책 모델로 진화했다.
정책 구조
{
"defaults": {
"security": "allowlist",
"ask": "on-miss",
"askFallback": "deny"
}
}
Safe Bins (승인 없이 허용되는 안전한 명령)
jq, grep, cut, sort, uniq, head, tail, tr, wc
이 명령들은 stdin만 처리하므로 시스템 변경이 불가능하다.
Approval Flow
에이전트 → exec 요청
↓
Gateway → exec.approval.requested 브로드캐스트
↓
Control UI 또는 macOS 앱 → 사용자 승인/거부
↓
Gateway → 결과 전달 + 시스템 이벤트 발행
추가 방어
- Windows:
cmd.exe우회 차단 - 환경 변수:
LD_PRELOAD,DYLD_INSERT_LIBRARIES등 차단 - macOS IPC: Unix 소켓(모드 0600) + HMAC + TTL + Same-UID 검증
4편에서 권장한 "Docker 격리 (4층)"와 결합하면 명령 인젝션의 영향 범위가 크게 줄어든다.
8. Canvas/A2UI 자산 인증 필수화
5편에서 다룬 에이전트 대시보드(Web UI)의 보안 측면이다.
GUI를 추가하면 새로운 공격 표면이 생긴다. OpenClaw은 대시보드 추가와 동시에 자산 접근에 인증을 강제했다.
// Gateway 캔버스 호스트 + A2UI 자산
// 인증 없이 접근 → 차단됨
// 유효한 토큰 필요
기능을 추가하면서 보안도 함께 고려한 점은 긍정적이다.
9. Cron 안정성 대폭 개선
보안은 아니지만, 운영 안정성 관점에서 중요한 변화다.
1편에서 OpenClaw의 프로액티브 알림(아침 브리핑, 리마인더)을 핵심 기능으로 꼽았다. 이것들은 모두 Cron 스케줄러로 동작한다.
v2026.2.x에서 해결된 Cron 문제들
| 문제 | 증상 | 해결 버전 | |------|------|----------| | 타이머 드리프트 | 장시간 실행 시 스케줄이 밀림 | 2026.2.3 | | 재시작 캐치업 | 서버 재시작 후 놓친 작업 미처리 | 2026.2.3 | | 락 경합 | 동시 실행 시 교착 상태 | 2026.2.3 | | 스케줄링 재귀 버그 | 무한 반복 발생 가능 | 2026.2.6 |
새 기능
| 기능 | 설명 |
|------|------|
| ISO 8601 schedule.at | 정확한 시간 지정 가능 |
| announce 전달 모드 | 격리된 작업의 결과를 안전하게 전달 |
| 일회성 작업 자동 삭제 | 완료 후 정리 (기본값) |
실체감 있는 예시: 내가 겪었던 "텔레그램 봇이 응답 안 함" 문제도 Cron/채널 안정성과 관련이 있다. 게이트웨이가 재시작되면서 텔레그램 채널이 죽었는데, 이런 종류의 복구 안정성이 개선된 것이다.
10. 컨텍스트/메모리 안정성
1편에서 영구 메모리를 핵심 장점으로 소개했다. 하지만 메모리 시스템이 불안정하면 오히려 문제가 된다.
v2026.2.x에서 해결된 메모리 문제들
| 문제 | 설명 | 해결 버전 | |------|------|----------| | 컨텍스트 오버플로우 | 대화가 길어지면 크래시 | 2026.2.9 | | Post-compaction amnesia | 메모리 압축 후 기억 손실 | 2026.2.9 | | 수동 압축 무효화 | 사용자가 압축 취소 불가 | 2026.2.9 | | 도구 결과 크기 초과 | 큰 결과가 컨텍스트를 점유 | 2026.2.9 |
**"Post-compaction amnesia"**는 특히 흥미로운 수정이다. AI가 대화를 압축(요약)할 때, 중요한 정보가 누락되는 문제. 이것은 "시간이 지날수록 더 똑똑해진다"는 메모리의 핵심 약속을 깨트리는 버그였다. Pi 세션의 parentId 체인을 유지하는 방식으로 해결됐다.
11. Telegram 채널 개선
3편(셋업 가이드)에서 Telegram 설정을 다뤘다. v2026.2.x에서 Telegram 관련 개선사항:
| 개선 | 내용 |
|------|------|
| 인용문 파싱 강화 | QUOTE_TEXT_INVALID 에러 회피 |
| 스포일러 마크다운 | \|\|숨김 텍스트\|\| 지원 |
| 명령어 등록 제한 | 100개까지 (Telegram API 제한 대응) |
| 멀티에이전트 세션 | 여러 에이전트 동시 운영 시 세션 충돌 수정 |
| @ts-nocheck 제거 | 타입 안전성 완전 확보 (v2026.2.3) |
@ts-nocheck 제거는 코드 품질의 신호다. TypeScript의 타입 검사를 완전히 활성화했다는 것은, Telegram 플러그인의 런타임 오류가 줄어든다는 의미다.
12. 보안 감사 CLI
v2026.2.x에서 추가된 보안 감사 명령어도 주목할 만하다:
openclaw security audit # 기본 감사
openclaw security audit --deep # 라이브 게이트웨이 프로브 포함
openclaw security audit --fix # 자동 수정 (chmod, 기본값 강화)
4편에서 직접 작성했던 "보안 점검 체크리스트"를 공식 CLI로 대체할 수 있다. --fix 플래그는 파일 권한을 자동으로 수정해주므로, 4편의 2~3층 방어를 한 명령어로 적용할 수 있다.
13. 2편 보안 체크리스트 재평가
2편과 4편에서 제안한 대응책이 v2026.2.9 이후에도 여전히 필요한지 재평가한다.
2편 대응책 유효성
| 2편 권장사항 | v2026.2.x 대응 | 여전히 필요? |
|-------------|---------------|-------------|
| 전용 사용자 계정 생성 | exec allowlist 강화 | 여전히 권장 |
| 격리 환경 (VM/Docker) | auth none 제거 | 여전히 권장 (다만 중요도 하락) |
| 네트워크 바인딩 확인 | 기본 인증 강제 | 불필요 (자동 적용) |
| 스킬 코드 검토 | 내장 스캐너 | 여전히 권장 (보완적) |
| ~/.clawdbot/ 권한 600 | (미변경) | 필수 |
| openclaw doctor 정기 실행 | (동일) | 필수 |
4편 5계층 방어 유효성
| 계층 | 4편 권장 | v2026.2.x 이후 | 변화 | |------|---------|---------------|------| | 1층: 네트워크 격리 | 필수 | 자동 강제 | 수동 → 자동 | | 2층: 폴더 권한 700 | 필수 | (미변경) | 여전히 필수 | | 3층: 파일 권한 600 | 필수 | (미변경) | 여전히 필수 | | 4층: Docker 격리 | 선택 | exec allowlist 강화 | 중요도 약간 하락 | | 5층: 모니터링 | 권장 | (미변경) | 여전히 권장 |
14. 아직 해결되지 않은 것들
공정하게 봐야 한다. 10일간 많은 것이 개선됐지만, 여전히 남은 과제가 있다.
평문 자격증명 (2편 Critical)
~/.openclaw/openclaw.json에 봇 토큰과 API 키가 여전히 평문으로 저장된다. 시스템 키체인(macOS Keychain, Linux libsecret) 통합은 아직 이루어지지 않았다.
4편의 2~3층 방어(폴더/파일 권한 강화)는 여전히 필수다.
ClawdHub 심사 프로세스
내장 스캐너가 추가됐지만, 스킬 마켓플레이스의 심사/검증 프로세스는 여전히 없다. npm처럼 누구나 업로드 가능한 구조는 변하지 않았다.
1인 개발자 병목
2편에서 지적한 "steipete 혼자 거의 모든 코드 작성(97%)" 문제는 구조적으로 변하지 않았다. 보안 PR의 리뷰어 병목은 여전할 가능성이 높다.
결론: 사용해도 될까?
Before (v2026.1.30, 2편 결론)
"프로덕션 사용은 권장하지 않음. 로컬 테스트 전용."
After (v2026.2.9)
로컬 개인 용도는 이제 합리적이다. 프로덕션은 아직이다.
변화의 근거:
| 영역 | 개선 수준 | 근거 | |------|----------|------| | 인증/접근 제어 | 대폭 개선 | auth "none" 제거, Canvas 인증 | | 입력 검증 | 상당히 개선 | SSRF 3회 강화, 경로 순회 5건+ | | 공급망 보안 | 개선 | 내장 스캐너 (다만 심사 프로세스 부재) | | 자격증명 관리 | 미변경 | 평문 저장 유지 | | 운영 안정성 | 대폭 개선 | Cron 4건, 컨텍스트 4건 수정 |
최종 판단
[로컬 개인 사용]
v2026.1.30: 주의 필요 → v2026.2.9: 합리적 (4편 2~3층 적용 시)
[소규모 팀 내부]
v2026.1.30: 비권장 → v2026.2.9: 조건부 가능 (전 계층 적용 시)
[프로덕션/엔터프라이즈]
v2026.1.30: 절대 비권장 → v2026.2.9: 여전히 비권장
10일 만에 이 정도의 보안 개선은 인상적이다. steipete가 보안을 진지하게 받아들이고 있다는 신호다. 이 개선 속도가 유지된다면, 1~2달 후에는 판단이 또 달라질 수 있다.
"There is no 'perfectly secure' setup." - 이 말은 여전히 맞다. 하지만 기본값이 안전해져야 한다는 2편의 주장도 여전히 유효하다. v2026.2.x는 그 방향으로 제대로 된 첫 걸음을 내딛었다.