career

오픈클로(OpenClaw) 2026.10.6 보안 릴리스 — eMudhra 인증서 사고 대응, Node 24.22.1 미만이면 업데이트가 거부됩니다 (10/22)

OpenClaw 공식 홈페이지 대표 이미지 — 오픈소스 AI 에이전트 OpenClaw OpenClaw 공식 홈페이지(openclaw.ai) 대표 이미지. OpenClaw 재단이 릴리스에 서명하고 MIT 라이선스로 배포한다는 문구가 첫 화면에 걸려 있습니다. (출처: openclaw.ai)

📌 한줄 요약: 2026년 10월 22일 오후 9시 53분(KST), OpenClaw가 2026.10.6 을 배포했습니다. 릴리스 노트 첫 줄이 “보안 릴리스(Security release)”입니다. 10월 18~19일 eMudhra(emSign) 중간 CA 키 유출 사고에 대한 조치로, OpenClaw는 이제 Node 24.22.1 이상(24 라인) 또는 26.12.1 이상(26 라인) 을 요구합니다. 그리고 구버전 Node에서는 openclaw update가 설치를 진행하지 않고 거부합니다. 자동 업데이트를 걸어둔 환경이라면 “왜 갑자기 안 올라가지”가 아니라, 업데이터가 일부러 멈춘 것일 수 있습니다.

이 글을 읽으면 알 수 있는 것

  • 2026.10.6이 어떤 성격의 릴리스이고, 왜 “패치인데 중요하냐”를 따져야 하는지
  • eMudhra 인증서 사고가 OpenClaw 사용자에게까지 닿는 경로
  • Node 버전 요건이 바뀐 정확한 숫자와, 그게 막는 대상
  • openclaw update가 거부할 때 실제로 무슨 일이 벌어지는지(설치가 깨지는지)
  • 업무 자동화 파이프라인 기준의 업그레이드 순서와 롤백 포인트
  • 이번 판에 같이 들어온 신뢰성 수정 중 실무에 체감되는 항목

1. 무슨 일이 있었나 — 10월 22일 밤, 조용한 패치 릴리스

먼저 숫자부터. GitHub 릴리스 기준 v2026.10.6 은 2026-10-22 12:53 UTC, 우리 시간으로 10월 22일 오후 9시 53분에 공개됐습니다. 변경 이력 문서에는 “233개 풀 리퀘스트, 30개 직접 커밋, 149명 기여자”로 기록돼 있습니다.

눈에 띄는 건 릴리스 노트의 문장입니다.

“This patch release contains focused reliability fixes only; it does not introduce new user-facing features.” (이 패치 릴리스는 신뢰성 수정에만 집중했고, 사용자에게 보이는 신기능은 없습니다.)

보통 이런 문장이 나오면 “넘겨도 되는 패치”로 읽힙니다. 그런데 이번 건은 다릅니다. 릴리스 노트 맨 앞에 이렇게 붙어 있습니다.

“Security release: v2026.10.6 adds remediations for the eMudhra certificate compromise.”

즉 신기능은 없지만 보안 사유가 있는 릴리스입니다. 이 조합이 실무에서 가장 다루기 까다롭습니다. 기능 변화가 없으니 “굳이 지금?” 싶고, 보안 사유가 있으니 “미룰 수는 없고”. 판단 기준은 결국 하나입니다. 지금 쓰는 Node 런타임이 패치된 버전인가.

2. 배경 — eMudhra 중간 CA 키 유출, 그리고 Node.js의 대응

OpenClaw 릴리스만 보면 맥락이 안 보입니다. 배경은 10월 중순 인증서 업계에서 터진 사건입니다.

정리하면 이렇습니다.

시점 사건
2026-10-18~19 eMudhra가 emSign 중간 CA 8개를 cACompromise(CA 키 유출) 사유로 폐기
2026-10-19 Red Hat이 보안 권고 RHSB-2026-012로 공개, CVE-2026-111943 부여
2026-10-21 Node.js가 10월 보안 릴리스 배포(22.23.4 / 24.22.1 / 26.12.1) — 차단된 공개키가 포함된 TLS 체인을 거부하고, 번들 루트 인증서를 NSS 3.131.1로 갱신
2026-10-22 OpenClaw가 2026.10.6으로 동일 조치 반영

흐름을 보면 OpenClaw가 특별히 늦은 게 아닙니다. Go가 키 기반 차단을 넣고, Electron이 따라갔고, Mozilla는 NSS 3.131.1에서 emSign 루트 3개를 제거했습니다. Chrome과 Firefox도 해당 인증서를 막았습니다. 생태계 전체가 “이 키로 서명된 체인은 믿지 않는다”로 움직인 것이고, OpenClaw는 그 마지막 줄에 서 있습니다.

왜 이게 AI 에이전트에까지 문제가 되냐면, 에이전트가 하는 일의 상당 부분이 바깥으로 나가는 HTTPS 연결이기 때문입니다. 모델 API를 호출하고, 메신저 채널에 붙고, 웹을 읽고, 사내 시스템에 붙습니다. 그 연결의 신뢰 판단을 런타임(Node)이 합니다. 런타임이 폐기된 키를 여전히 신뢰하면, 에이전트가 “정상 연결”이라고 믿는 상대가 실제로는 아니게 될 수 있습니다. 에이전트는 판단을 위임받은 존재라, 이 지점이 뚫리면 사람이 눈치채기 어렵습니다.

Node.js 공식 블로그의 2026년 10월 보안 릴리스 공지 이미지 Node.js 공식 블로그의 2026년 10월 21일 보안 릴리스 공지. 22.x·24.x·26.x 라인 동시 배포가 예고된 문서입니다. (출처: nodejs.org)

3. OpenClaw가 실제로 바꾼 것 — 숫자 세 개

이번 릴리스의 핵심 변경은 화려하지 않습니다. 대신 경계가 분명합니다.

(1) 최소 Node 버전이 올라갔습니다

릴리스 노트 원문은 이렇습니다.

OpenClaw now requires Node 24.22.1+ on the 24 line or 26.12.1+ on the 26 line, which reject TLS chains signed with the compromised certificate keys.

이유도 같이 적혀 있습니다. 구버전 Node 빌드는 문제의 인증서를 여전히 신뢰할 수 있기 때문입니다. 즉 “최신 기능을 쓰려면 올려라”가 아니라, “폐기된 키를 신뢰하지 않는 런타임에서만 돌겠다” 는 요구입니다.

(2) 배포 경로는 알아서 패치됩니다

  • Docker 이미지: Node 24.22.1 탑재
  • 설치 프로그램(installer): 패치된 런타임을 선택
  • 소스 빌드: pnpm 12.15.0으로 고정

Docker로 굴리는 환경이라면 이미지 태그만 올리면 Node 문제는 같이 해결됩니다. 반대로 “Node는 내가 직접 관리한다” 는 환경 — 예를 들어 호스트에 nvm이나 시스템 패키지로 Node를 깔아 쓰는 경우 — 이번 건의 실제 대상입니다.

(3) 업데이트가 “거부”합니다

가장 실무적으로 중요한 부분입니다.

openclaw update refuses with recovery guidance before installing on an older Node instead of breaking the running install.

해석하면 이렇습니다. 구버전 Node 위에서 업데이트를 실행하면, 설치를 시작하기 전에 멈추고 복구 안내를 출력합니다. 즉 업데이트하다가 기존 설치를 반쯤 망가뜨리는 상황을 막는 쪽으로 설계됐습니다.

솔직히 이건 칭찬할 만한 판단입니다. 강제로 밀어붙여서 “업데이트 후 게이트웨이가 안 뜸”이 되는 것보다, “Node 먼저 올리고 다시 오라” 고 말해주는 편이 운영자 입장에서 훨씬 낫습니다. 다만 자동 업데이트를 스케줄로 걸어둔 환경에서는 실패 알림이 아니라 “거부”로 보일 수 있으니, 로그에 남는 문구를 읽어야 합니다.

4. 실무 영향 — 누가 걸리고, 누가 안 걸리나

여기서부턴 조건별로 나눠 보겠습니다. 해당되는 줄만 보시면 됩니다.

현재 환경 이번 릴리스 영향 할 일
Docker/공식 설치 프로그램으로 운영 낮음 이미지·설치본 업데이트만
Node 24.22.1 이상 직접 관리 낮음 openclaw update 정상 진행
Node 24인데 24.22.1 미만 높음 Node 먼저 패치 → 재시도
Node 26인데 26.12.1 미만 높음 Node 먼저 패치 → 재시도
Node 22 라인 사용 확인 필요 릴리스 노트에 22 라인 요건이 명시되지 않음 → 24/26 전환 검토
소스 빌드 중간 pnpm 12.15.0 고정 확인

마지막에서 두 번째 줄이 핵심입니다. 릴리스 노트가 요건을 “24 라인의 24.22.1+, 또는 26 라인의 26.12.1+” 로만 적었습니다. Node.js 재단은 10월 21일 릴리스에서 22.23.4도 함께 냈지만, OpenClaw 쪽 요건에는 22 라인이 들어 있지 않습니다. 이건 22 라인을 지원 대상에서 뺐다는 뜻으로 읽히지만, 릴리스 노트가 그렇게 명시하지는 않았습니다. 확대 해석은 금물이고, 22 라인에 머물러 있다면 업데이트 전에 24 또는 26으로 옮기는 계획을 먼저 세우는 편이 안전합니다.

업무 자동화 파이프라인에 에이전트를 붙여 쓰는 경우라면 영향 범위가 한 단계 더 넓습니다. 에이전트 자체가 안 뜨는 것보다 골치 아픈 건, 에이전트가 도는 것처럼 보이면서 특정 외부 연동만 실패하는 상태입니다. 인증서 체인이 거부되면 모델 API나 웹 도구처럼 HTTPS를 타는 경로에서 오류가 나고, 메신저 채널은 멀쩡히 살아 있을 수 있습니다.

OpenClaw 실행 화면 스크린샷 — 채팅 인터페이스에서 에이전트를 호출하는 모습 OpenClaw 실행 화면(위키미디어 공용, MIT 라이선스). 채널 메신저에서 에이전트를 호출하는 구조라, HTTPS 경로가 막히면 “일부만 안 되는” 형태로 증상이 나타납니다. (출처: Wikimedia Commons)

5. 업그레이드 순서 — 이 순서만 지키면 됩니다

보안 릴리스에서 사고가 나는 지점은 거의 항상 순서입니다. Node를 먼저 올리지 않고 OpenClaw를 먼저 건드리면, 업데이트가 거부되거나(다행) 혹은 중간 상태로 남습니다(불행).

① 현재 상태 기록

node -v
openclaw --version
openclaw doctor

node -v가 v24.22.1 미만이거나 v26.12.1 미만이면 다음 단계로 넘어가기 전에 멈추세요. openclaw doctor는 지금 상태를 남겨두는 용도입니다. 문제가 생겼을 때 “원래 어땠는지”를 알아야 복구가 됩니다.

② 백업

openclaw backup

이번 릴리스에는 마이그레이션·백업 관련 수정도 여러 건 들어 있습니다. 손상된 워크스페이스 가져오기를 거부하고, 잘못된 Notes 바이트를 보존하고, UTF-8이 아닌 위키 재작성을 거부하는 쪽으로 바뀌었습니다. 안전 장치가 늘었다는 뜻이지만, 그만큼 “원래 되던 게 거부될” 여지도 생겼다는 뜻입니다. 백업은 선택이 아닙니다.

③ Node 패치 (직접 관리하는 경우)

# 예: nvm 사용 시
nvm install 24.22.1
nvm use 24.22.1
node -v

시스템 패키지 관리자로 Node를 깔았다면 배포판에 패치 버전이 올라왔는지 먼저 확인하세요. 안 올라왔다면 nvm이나 공식 배포본으로 전환하는 편이 빠릅니다.

④ OpenClaw 업데이트

openclaw update

여기서 거부 메시지가 나오면 Node 버전을 다시 확인하세요. 거부는 실패가 아니라 안내입니다.

⑤ 업데이트 후 검증

openclaw --version   # 2026.10.6 확인
openclaw doctor

그다음 실제로 쓰는 경로를 하나씩 찔러보세요. 모델 호출 1회, 메신저 채널 1회, 스케줄 작업 1회. 이 세 개만 확인해도 “조용히 일부만 죽은” 상태는 대부분 걸러집니다.

6. 이번 판에 같이 들어온 것 — 체감되는 것만

패치 릴리스라 나열하면 끝이 없습니다. 실무에서 몸으로 느낄 만한 것만 추렸습니다.

  • 재시작을 넘어가는 전달 보장: 대기 중인 턴, 지켜보던 하위 결과, 데드레터 처리된 전달, 스트리밍 응답이 복구 과정에서 사라지거나 중복되거나 “답이 없다”고 잘못 알리지 않도록 수정. 게이트웨이를 자주 재시작하는 환경에서 체감이 큽니다.
  • 업데이트 자체의 안전성: 패키지 교체가 위험한 서비스 상태에서는 거부하고, Windows/macOS 패키지 관리자 업데이트는 플랫폼별 실패에서 복구하며, 멈춘 게이트웨이 시작 소유자를 정리합니다.
  • 툴 호출 복구: 끝나지 않은 툴이 눈에 보이게 타임아웃되고, 컨텍스트 오버플로는 조정된 툴 결과 이후에 압축되며, 큰 패치 헝크가 인자 한도로 죽지 않습니다.
  • 프로바이더/모델 회복력: GPT-5.6 툴 턴, OpenRouter 경유 DeepSeek 툴 호출, LM Studio 오버플로 복구, 병렬 OpenAI 추론 설정, 모델 재시도·폴백 예산이 일관되게 동작.
  • 채널 전달 정확성: WhatsApp 재시도·스티커, Telegram 앨범·듀얼스택 응답, Slack 릴레이 복구, Discord 음성 통화 응답에서 메시지 유실·중복 방지.
  • 스케줄 팔로업 권한: 승인된 운영자 턴에서 예약된 같은 대화 팔로업이 실행될 때 그 운영자의 현재 권한을 유지합니다. 자동화가 권한을 승계하는 방식이 바뀌는 종류라, 권한 모델을 빡빡하게 잡아둔 조직이라면 확인할 가치가 있습니다.

7. 솔직히 아쉬운 점

칭찬만 하면 리뷰가 아니죠. 이번 릴리스에서 아쉬운 부분은 이렇습니다.

첫째, 최소 버전 요건이 “올려야 한다”로만 안내됩니다. Node 22 사용자에게 열린 경로가 릴리스 노트에 없습니다. 22.23.4도 eMudhra 대응이 들어간 버전인데, OpenClaw 요건에는 22 라인이 빠져 있습니다. 기술적 이유가 있을 수 있지만, 릴리스 노트만 읽는 사람에게는 “22는 이제 끝”으로 읽힙니다. extended-stable 라인 백포트 여부도 이 문서만으로는 판단이 안 됩니다.

둘째, 업데이트 거부가 자동화 환경에서는 ‘조용한 실패’로 보입니다. 사람이 터미널 앞에 있으면 친절한 안내지만, 스케줄로 도는 업데이트에서는 그저 “안 올라감”입니다. 거부 사유를 알림으로 밀어주는 수준까지 가면 좋겠습니다.

셋째, 보안 사유가 릴리스 노트 첫 줄에만 있습니다. 릴리스 제목은 그냥 버전 번호고, “Security release”는 본문에 있습니다. 릴리스 목록만 훑는 사람은 이걸 놓칩니다. 실제로 이 글을 쓰면서도 버전 번호만 보고 지나칠 뻔했습니다.

8. 정리 — 이런 경우라면 오늘 안에 보세요

  • Node를 직접 관리하면서 OpenClaw를 돌리는 경우 → 오늘 확인. node -v 한 줄이면 끝납니다.
  • Docker/공식 설치본으로만 운영하는 경우 → 이미지·설치본 업데이트로 충분. 다만 업데이트 후 채널 스모크 테스트는 하세요.
  • Node 22 라인에 머물러 있는 경우 → 24/26 전환 계획을 먼저 세우고 업데이트.
  • 업무 자동화 파이프라인에 에이전트를 물려둔 경우 → 모델 호출·메신저·스케줄 세 경로를 각각 한 번씩 확인.
  • 당장 못 올리는 경우 → 최소한 외부 HTTPS 연동이 어떤 인증서를 신뢰하는지 점검하고, 업데이트 가능 시점을 캘린더에 박아두세요.

이번 건은 “새 기능이 뭐가 나왔나”로 볼 릴리스가 아닙니다. 런타임 경계가 바뀐 릴리스입니다. 화려한 변경은 없지만, 이 경계를 넘지 못하면 에이전트가 조용히 일부만 동작합니다. 그런 종류의 장애가 가장 늦게 발견됩니다.

업데이트는 미루면 미룰수록 “왜 안 되지”로 돌아옵니다. 5분이면 되는 확인이니, 오늘 node -v부터 한 번 찍어보시길 권합니다.

참고 자료