career

오픈클로(OpenClaw) 2026.10.8 정식 릴리스 — 샌드박스·exec 승인 경계 강화, '멈추지 않는 업데이트' (10/27)

OpenClaw 공식 홈페이지 대표 이미지 — 오픈소스 AI 에이전트 OpenClaw OpenClaw 공식 홈페이지(openclaw.ai) 대표 이미지. (출처: openclaw.ai)

📌 한줄 요약: 2026년 10월 27일 오후 8시 56분(KST), OpenClaw 2026.10.8 이 정식 릴리스로 올라왔습니다. 신기능은 없습니다. 대신 “실행 경계”와 “업데이트가 끝까지 가는가” 두 가지를 손봤습니다. 샌드박스 안에서 돌던 하위 프로세스가 호스트 CLI 백엔드를 부르던 경로가 막혔고, exec 허용목록은 test -v 연산자 확장 앞에서 승인을 요구합니다. 업데이트 뒤 Doctor가 실패하면 Gateway를 멈춰 세우는 대신 재시작하고, 중단된 실행은 재시작 뒤에도 대화를 이어받습니다.

이 글을 읽으면 알 수 있는 것

  • 2026.10.8이 어떤 성격의 릴리스이고, 왜 “패치인데 짚고 갈 만한가”
  • 이번 판에서 닫힌 실행 경계 3가지 (샌드박스 → 호스트 CLI, exec 허용목록, 시크릿 이그레스)
  • 업데이트·Gateway 복구 로직이 어떻게 바뀌었는지
  • 재시작 후 메시지·cron이 살아남는 범위
  • 자동화 파이프라인 기준의 업그레이드 판단 순서
  • 이번 판에서 아쉬운 점(신기능 부재, 짧은 릴리스 간격)

1. 무슨 일이 있었나 — 3일 만에 다시 정식 채널

숫자부터 정리하면 이렇습니다.

항목 내용
버전 v2026.10.8
공개 시각 2026-10-27 11:56 UTC / 10월 27일 오후 8시 56분(KST)
범위 v2026.10.7 이후 162개 풀 리퀘스트
npm latest 2026.10.8 (릴리스 직후 기준)
npm extended-stable 2026.9.35 (같은 날 게이트웨이 전용으로 함께 배포)
npm beta 2026.10.10-beta.4

직전 정식판이 2026.10.7(10월 24일 오후 6시 53분 KST)이었으니 사흘 만입니다. 이 간격만 보면 “또 잔버그 패치”로 보입니다. 그런데 릴리스 노트를 열어 보면 성격이 조금 다릅니다. 하이라이트 첫 두 줄이 업데이트 복구와 게이트웨이 설치이고, 다섯 번째 줄이 보안 강화(Security hardening) 입니다. 즉 이번 판의 주제는 기능이 아니라 “사고 없이 굴러가게 만드는 것” 입니다.

OpenClaw 공식 블로그 'Shipping OpenClaw updates that don't break' 대표 이미지 OpenClaw 공식 블로그의 업데이트 안정성 글 대표 이미지. 2.0 이후 “업데이트가 깨진다”는 피드백을 정면으로 다룬 글입니다. (출처: openclaw.ai/blog)

2. 배경 — 2.0 이후 계속 이어진 ‘업데이트가 사람을 잡는’ 문제

OpenClaw는 9월 초 2.0을 내면서 설치·메시징·메모리·스킬·모델·자동화·보안까지 전부 건드렸습니다. 그 뒤로 석 달 가까이 릴리스가 이어졌고, 커뮤니티에서 가장 많이 나온 불만은 기능이 아니라 업데이트 자체였습니다.

공식 블로그에도 그대로 적혀 있습니다. 업데이트가 실패하면 새 버전이 안 되는 수준이 아니라 기존 에이전트까지 같이 내려가서, 고쳐 줄 에이전트가 없는 상태가 됐다는 겁니다. 설정 조합이 사실상 무한대라 사전 테스트로 다 덮을 수 없고, 그래서 “원자적 업데이트(atomic update)” 쪽으로 방향을 잡았습니다.

2026.10.8은 그 연장선입니다. 새 기능을 얹는 대신, 업데이트 도중에 실패해도 원래 상태로 돌아오고, 실패한 뒤에도 Gateway가 살아 있게 만드는 데 분량을 썼습니다. 변경 이력 162개 PR 중 상당수가 이 계열입니다.

3. 핵심 ① 실행 경계 — 샌드박스가 호스트로 새던 길을 막았다

이번 판에서 실무적으로 가장 눈여겨볼 부분입니다. 보안 강화 항목을 풀어 쓰면 이렇습니다.

항목 바뀐 것 왜 중요한가
exec 허용목록 test -v 피연산자 확장 앞에서 승인(approval) 요구 허용목록에 걸린 명령처럼 보이지만 실제로는 다른 경로를 여는 우회를 차단
node invoke 브라우저 프록시 명령 호출 거부 노드 실행 경로로 브라우저 제어 권한을 우회하지 못하게
샌드박스 자식 프로세스 호스트 CLI 백엔드 실행 불가 샌드박스 안 코드가 밖의 CLI를 빌려 쓰는 경로 차단
시크릿 이그레스 프록시 신뢰하지 않는 eMudhra 체인 거부 10월 인증서 사고 대응을 프록시 계층까지 확장
오류 메시지 Fish Audio·Gradium 오류에서 API 키 비노출 로그·채널로 키가 흘러나가는 것을 방지
Tlon 채널 깊게 중첩된 콘텐츠로 채널이 멈추지 않게 입력 하나로 채널이 서는 것을 방지

여기서 눈에 띄는 건 세 번째 줄입니다. “샌드박스에서 실행된 하위 프로세스는 호스트 CLI 백엔드를 실행할 수 없다” 는 문장은, 반대로 읽으면 그 전까지는 그 경로가 열려 있었다는 뜻입니다. 에이전트에게 코드 실행을 맡기는 구조에서 샌드박스는 마지막 방어선인데, 그 방어선이 “자식 프로세스”라는 한 칸 아래에서 우회될 수 있었다는 얘기입니다.

업무 자동화 입장에서 이건 꽤 무게가 다릅니다. 에이전트에게 스크립트를 돌리게 해 두면, 스크립트가 뭘 하느냐에 따라 샌드박스 안과 밖의 경계가 실질적인 안전장치가 됩니다. 그 경계가 코드 한 줄로 무너지면 샌드박스를 켜 둔 의미가 줄어듭니다. 이번 판은 그 구멍을 막았습니다.

한 가지 분명히 해 둘 것은, 이번 건이 공개된 CVE나 사고 대응은 아니라는 점입니다. 보안 권고(security advisory) 목록에도 새 항목이 올라오지 않았습니다. 즉 “이미 터진 사고”가 아니라 선제적 경계 정리입니다. 급하게 밤새 업그레이드할 성격은 아니지만, 다음 정기 업데이트 때는 같이 가져가는 게 맞습니다.

4. 핵심 ② 업데이트가 끝까지 간다 — 실패해도 Gateway는 살아남는다

이번 판에서 체감이 가장 큰 부분입니다. 릴리스 노트의 표현을 그대로 옮기면 “Updates that finish and recover”, 즉 “끝까지 가고, 되돌아온다”입니다.

바뀐 동작을 정리하면 이렇습니다.

  • Doctor 실패 ≠ Gateway 정지. 업데이트 뒤 평범한 Doctor 실패가 나면, 예전에는 Gateway가 내려간 채로 남았습니다. 이제는 재시작합니다.
  • 고아 유지보수 워커 정리. 남아 있던 워커 하나가 모든 CLI 명령과 Gateway 시작을 막던 문제가 사라졌습니다. “명령을 쳐도 아무 반응이 없다”의 흔한 원인 중 하나입니다.
  • 파일시스템·패키지 예외 처리. ACL 파일시스템, Windows의 pnpm 선택적 의존성 링크, pnpm 10 전역 설치, 디버그 콘솔 로깅, 사라진 레거시 OAuth 디렉터리 같은 사유로 업데이트가 중단되던 케이스가 정리됐습니다.
  • macOS launchd 복구. plist가 지워진 채 등록만 남은 launchd 항목을 복구합니다.
  • Linux 상태 디렉터리. Ubuntu 기본 umask 환경에서 설치가 거부되는 대신, 비공개 상태 디렉터리를 만들어 설치를 진행합니다.
  • macOS 업데이터 대기. Doctor가 도는 동안 서빙 중인 Gateway가 데이터베이스를 놓아줄 때까지 기다립니다. DB 잠금 충돌로 업데이트가 깨지는 경로를 줄인 조치입니다.

정리하면 “업데이트가 실패하는 방식”이 달라졌습니다. 예전에는 실패가 곧 정지였고, 이제 실패는 재시작과 복구 안내로 이어집니다. Doctor가 Gateway를 되살리지 못할 때는 실패 사유와 함께 직접 시작하는 방법을 출력합니다. 이 한 줄이 없어서 새벽에 로그만 붙들고 있었던 경우가 적지 않습니다.

5. 핵심 ③ 재시작해도 대화와 cron이 살아남는 범위

자동화를 돌리는 입장에서 두 번째로 중요한 축입니다.

  • 강제 종료된 실행의 복구 펜스 해제. 죽은 실행이 잡고 있던 재시작 복구 펜스를 놓아줍니다. 세션이 영구히 “복구 중”에 걸리는 상태를 줄입니다.
  • 중단된 하위 세션 복구. Gateway 재시작 직후 막 접수된 자식 세션까지 복구 대상에 들어갑니다.
  • 무한 재시도 중단. 응답 런타임이 게시할 수 없는 상황에서 인바운드 메시지가 영원히 재시도되던 동작이 멈춥니다.
  • Control UI 재전송. ‘보냈는데 반영이 안 됨’ 상황의 재시도가 작성 오류가 아니라 실제 응답을 전달합니다.
  • cron 관련 수정 2건. cron 작업이 자기 자신의 대상으로 보낸 뒤에도 계속 실행되고, 훅 플러그인이 교체된 뒤에도 유지됩니다. 그리고 공급자 변경 후에도 cron 이력이 읽힙니다.

세 번째와 다섯 번째는 스케줄 기반 자동화를 운영하는 쪽에 직접 와닿는 항목입니다. “작업이 한 번 돌고 조용히 죽는” 유형의 장애는 로그가 남지 않아 원인 찾기가 유난히 오래 걸립니다. 이번 판은 그 케이스 두 개를 정면으로 건드렸습니다.

그 밖에 실무에서 체감되는 것들:

  • Tailscale Serve/Funnel: tailscaled 재시작 후 원격 접근이 복구됩니다.
  • Slack: 일시적 invalid_auth는 채널을 끄기 전에 재시도하고, 조용한 릴레이 네트워크 끊김은 재접속합니다.
  • Codex/Claude CLI: 응답 대기 중 예산 유지, 중첩 백그라운드 에이전트 뒤 부모 응답 완료, 세션 재개 시 대화 갱신 반영.
  • Discord 실시간 음성: 런타임 초기화 누락 수정, 통화가 설정된 에이전트 모델을 사용.

6. 장점 — 이번 판에서 좋은 점

  • 사고 반경을 줄이는 방향의 릴리스. 신기능이 없어서 “새로 배울 것”은 없지만, 운영 중 터지는 유형의 장애(업데이트 정지, 세션 고착, 메시지 유실)를 줄입니다.
  • 실행 경계가 한 단계 안쪽까지 정리됨. 샌드박스 자식 → 호스트 CLI 경로 차단은 자동화를 코드 실행까지 확장한 환경에서 특히 의미가 있습니다.
  • 실패했을 때 사람이 덜 고생함. Doctor 실패 시 Gateway 재시작, 복구 불가 시 시작 방법 출력 — 장애 대응 시간을 줄이는 종류의 개선입니다.
  • extended-stable도 같은 날 정리. 게이트웨이 전용 2026.9.35가 함께 나와서, LTS 라인을 쓰는 쪽도 메모리 관련 수정(워커 힙 상한, 유휴 Codex 클라이언트 30초 후 정리)을 받을 수 있습니다.

7. 단점 — 솔직히 아쉬운 점

  • 신기능이 정말로 없습니다. Changes 항목은 사실상 한 줄(첫 실행 모델 메타데이터가 모델 선택기를 하나로 묶지 않도록 수정)입니다. 새 기능을 기대하고 릴리스 노트를 열었다면 실망할 만합니다.
  • 릴리스 간격이 짧습니다. 10.7이 사흘 전입니다. 매 릴리스마다 따라가는 운영 방식이라면 “이번 건은 건너뛰고 다음에”라는 판단이 자연스럽고, 실제로 그 판단이 크게 위험하지도 않습니다.
  • 보안 항목이 조용히 묶여 있습니다. 권고문이 따로 나온 게 아니라 릴리스 노트 안에 섞여 있어서, 릴리스 노트를 안 읽으면 경계가 바뀐 걸 모르고 지나갑니다.
  • Node 요건은 그대로. 10.6에서 강화된 Node 24.22.1+ / 26.12.1+ 요건은 유지됩니다. 오래된 런타임에서는 openclaw update가 여전히 거부합니다.
  • beta 라인은 별개. 2026.10.10-beta.4는 이번에도 하이라이트가 비어 있는 수정 중심 빌드입니다. beta에 기대할 만한 새 기능은 이 구간에 없습니다.

8. 업그레이드 판단 — 어떤 순서로 볼까

정리하면 이렇습니다.

  1. 지금 버전 확인. openclaw --version으로 현재 버전을 먼저 봅니다. 10.6 이전이라면 Node 요건부터 확인하는 게 순서입니다.
  2. 채널 확인. latest를 쓰면 10.8, extended-stable을 쓰면 9.35가 대상입니다. 두 라인의 성격이 다르니 같은 날 나온 릴리스라도 무엇을 받는지 구분해야 합니다.
  3. 자동 업데이트 환경이면 로그 확인. 이번 판의 핵심이 업데이트 복구이므로, 업데이트 후 Gateway가 살아 있는지와 Doctor 출력에 실패가 없는지를 확인합니다.
  4. 코드 실행을 붙여 둔 환경이면 우선순위를 높게. 샌드박스·exec 허용목록 항목이 걸린 판이라, 에이전트에게 스크립트 실행을 맡기고 있다면 미룰 이유가 적습니다.
  5. cron을 돌리는 환경이면 이력 확인. 공급자를 바꾼 뒤 cron 이력이 읽히는지, 자기 대상으로 보낸 작업이 계속 도는지 한 번 확인해 두면 좋습니다.
  6. 롤백 지점은 미리. 업데이트 전 버전 번호와 설정 백업 위치를 적어 둡니다. 이번 판이 업데이트 복구를 다룬다고 해서 롤백 준비가 필요 없어지는 건 아닙니다.

업데이트 자체는 평소와 같습니다.

openclaw --version
openclaw update            # stable 채널
openclaw update --channel extended-stable   # LTS 라인

9. 정리 — “기능 없는 릴리스”를 어떻게 볼 것인가

2026.10.8은 기능으로 줄 세우면 존재감이 없는 릴리스입니다. 하이라이트에 새로운 능력이 하나도 없고, Changes 항목도 한 줄입니다.

대신 이 판이 다루는 것은 사고가 나는 지점입니다. 업데이트가 중간에 멈춰 서는 지점, 샌드박스가 한 칸 아래에서 새는 지점, 재시작 뒤에 대화가 끊기는 지점. 이런 건 평소에는 보이지 않다가 한 번 터지면 그날 하루를 통째로 가져갑니다.

그래서 판단은 이렇게 하는 게 현실적입니다. 새 기능이 급한 게 아니라면, 다음 정기 업데이트 주기에 10.8을 얹으면 됩니다. 반대로 에이전트에게 코드 실행을 맡기고 샌드박스를 켜 둔 환경이라면, 실행 경계가 정리된 이번 판은 조금 서둘러도 나쁘지 않습니다.

업데이트를 자주 돌리는 환경일수록, 릴리스 노트의 하이라이트보다 Fixes 안의 “재시작”, “복구”, “중복”, “유실” 단어를 먼저 훑어보는 습관이 남는 장사입니다. 이번 판은 그 단어들이 유난히 많은 릴리스였습니다.

참고 자료

  • GitHub 릴리스 v2026.10.8 — https://github.com/openclaw/openclaw/releases/tag/v2026.10.8
  • 릴리스 문서 — https://docs.openclaw.ai/releases/2026.10.8
  • npm 버전 태그 — https://www.npmjs.com/package/openclaw/v/2026.10.8
  • 공식 블로그 「Shipping OpenClaw updates that don’t break」 — https://openclaw.ai/blog/shipping-openclaw-updates-that-dont-break
  • 공식 사이트 — https://openclaw.ai

이 글은 공개된 릴리스 노트와 공식 문서를 기준으로 정리했습니다. 실제 동작은 설치 환경과 설정에 따라 달라질 수 있으니, 업그레이드 전 백업과 롤백 지점을 먼저 확보하시길 권합니다.