# 브라우저가 eMudhra 를 차단해도 Claude 의 확인은 종료되지 않습니다.

> https://bookfactory.kr/board/news/23870
> 게시판: 뉴스
> 작성자: admin
> 작성일: 2026-10-26T00:54:47.972Z

---

2026 년 10 월 22 일 공개된 'eMudhra 취약점 – 방치 위험과 Claude Code 의 자동 대응' 기사 이후, "브라우저로 공식 테스트 페이지를 열어 차단이 적용되었는지 확인했습니다. 이제 대응이 완료된 것으로 볼 수 있나요?"라는 질문이 제기되었습니다.

브라우저만 확인해도 중단할 수 있는 경우는 평소 컴퓨터에서 브라우저와 메일 등 일반적인 앱만 사용하는 경우입니다. 클로드 (Claude) 를 업무에 활용하는 사람은 클로드 코드 (Claude Code) 를 포함하더라도 확인이 필요한 경우가 있을 수 있습니다.

그 이유는 두 가지입니다. 첫째는 Claude 가 웹 버전, 데스크톱 앱인 Claude Cowork, 터미널에서 작동하는 Claude Code 를 모두 갖추고 있으며, 각 버전마다 인증서를 확인하는 위치와 코드를 실행하는 위치가 다르다는 점입니다. 둘째는 회사에서 배포된 팀 플랜이나 엔터프라이즈 플랜을 사용하더라도, 정보시스템 부서에서 관리 화면에서 일괄 업데이트할 수 있는 범위와 사용자의 컴퓨터에 남아있는 개발 도구가 분리되어 있다는 점입니다. 또한 10 월 22 일 기사 공개 당시에는 아직 지원되지 않던 (pending) 모듈이나, Bun 과 같이 나중에 수정 버전 1.4.4 가 나왔지만 시간차를 두고 수정 버전이 나온 경우, 혹은 여전히 지원되지 않은 상태로 남아있는 도구들도 있습니다.

이 글에서는 브라우저가 eMudhra 를 차단한 후, 자신의 Claude 사용 환경에 남아있는 요소들을 순서대로 분석합니다. 후반부에는 해당 상황에 대응할 수 있는 즉시 적용 가능한 지시 프롬프트를 수록했습니다.

## 目次

- 브라우저의 차단 확인은 인증서 오류를 통해 가능합니다.
- 공식 확인용 URL 에러 발생 의미
- SSL 통신 차단이 작동하지 않음
- 클로드 사용 방식에 따라 확인 방법이 달라집니다.
- 웹 버전은 개발 도구를 설치하지 않습니다.
- Cowork 은 클라우드나 개인용 가상 머신에서 실행됩니다.
- Claude Code 는 사용자의 손에 있는 curl 과 Python 을 사용합니다.
- 데스크톱 앱 설치 대상은 Anthropic 의 모듈입니다.
- 지금 바로 업데이트하고, 나중에 확인해야 할 항목들입니다.
- 브라우저와 OS 업데이트를 안전하게 사용하는 방법

## 브라우저의 차단 확인은 인증서 오류를 통해 가능합니다.

### 공식 확인용 URL 가 오류가 발생하는 의미

eMudhra 의 중간 인증서 8 개 중 비밀 키가 제 3 자에게 복원 가능한 상태였던 사안에 대해, 전용 페이지인 'eMudhra Intermediate CA Compromise'에는 2 개의 확인용 URL 이 준비되어 있습니다.

- 우리가 문제를 가지고 있습니다.
- 우리가 문제를 가지고 있습니다.

이중 경로로 분기된 이유는 누설된 중간 인증서의 상위 인증서가 eMudhra 자체의 루트 인증서 (emSign) 를 연결하는 경로와 AAA Certificate Services 라는 별도의 루트 인증서로부터 상호 인증된 경로 두 가지로 구분되기 때문입니다. 한쪽 경로를 차단하더라도 다른 쪽이 정상 작동하면 가짜 서버 인증서를 통과할 여지가 남게 됩니다.

이 부분에서 흔히 실수하는 것은 확인 결과의 해석입니다. 평소 웹 사이트에서는 문제가 없이 페이지가 열리고 주소창에 잠금 아이콘이 표시되는 것이 '정상'으로 간주됩니다. 그러나 이 두 개의 확인용 URL 은 유출된 비밀 키로 서명된 테스트용 인증서를 의도적으로 제시하고 있습니다. 따라서 크롬, 사파리, 엣지, 파이어폭스 브라우저로 열었을 때 '이 연결에서는 프라이버시가 보호되지 않습니다'와 같은 인증서 오류가 발생하여 연결이 끊기는 것이 브라우저에서 차단되었음을 증명하는 것입니다.

반대로, 경고 없이 테스트용 페이지가 표시되는 경우 해당 브라우저나 통신 경로가 여전히 문제의 인증서를 허용하고 있음을 의미합니다.

### SSL 통신 차단이 작동하지 않습니다.

브라우저에서 두 개의 URL 이 모두 인증서 오류가 발생하더라도, 이를 통해 알 수 있는 것은 '그때 열린 브라우저가 문제의 인증서를 거부했다'는 점뿐입니다. 컴퓨터 내의 모든 SSL 통신이 동일한 설정을 공유하는 것은 아닙니다.

구글 크롬은 CRLSet, 파이어폭스는 OneCRL, 애플과 마이크로소프트는 각기 다른 방식으로 2026 년 10 월 17 일부터 20 일까지 긴급 차단 정보를 배포했습니다. 브라우저는 이 정보를 받아 연결을 차단합니다.

반면, 이미 컴퓨터에 설치되어 있는 개발용 프로그램이나 통신 라이브러리는 브라우저 차단 목록에 등록하지 않아도 됩니다.

- Python 에서 널리 쓰이는 requests 와 pip 는 자체 인증서인 certifi 를 보유하고 있습니다. 특히 pip 는 OS 의 인증서 스토어와 함께 내장된 certifi 를 모두 확인하도록 설계되어 있습니다. OS 에서 인증서를 차단하더라도 pip 가 오래된 경우 내장 인증서를 통해 신뢰가 유지됩니다. 또한 Windows 나 macOS 에 공식 설치 프로그램을 통해 설치된 Python 본체도, 함께 포함된 인증서를 업데이트한 3.15.1, 3.14.9, 3.13.17 버전이 출시되었습니다.
- Node.js 는 해당 버전이 출시된 시점의 Mozilla 인증서 목록을 프로그램 내부에 내장하고 있습니다. Windows 나 macOS 를 업데이트하더라도 Node.js 내부의 내용은 변경되지 않습니다. --use-system-ca 와 같은 옵션을 추가하더라도 OS 의 인증서가 '추가'되는 것뿐이며, 오래된 루트 인증서는 삭제되지 않습니다.
- UV 와 Bun 도 초기 설정에서는 프로그램에 내장된 인증서 목록을 사용합니다.
- Mac 에 기본 탑재된 /usr/bin/curl, git, python3 는 Apple 이 10 월 19 일에 배포한 차단 설정이 아니라 /etc/ssl/cert.pem 이라는 텍스트 파일을 참조하며, 이 파일은 자동 업데이트되지 않습니다. Windows 에서도 표준 curl.exe 는 OS 의 인증서 스토어를 확인하지만, Git for Windows 에서 OpenSSL 을 사용하는 설정으로 구성되어 있다면 자체 인증서 파일을 참조합니다.

즉, 브라우저의 확인용 URL 에서 오류가 발생한다고 해서, 같은 컴퓨터에 설치된 Python 이나 Node.js, curl 도 안전하다고 단정할 수 없습니다. 또한 터미널에서 curl 만을 테스트하여 오류가 발생하더라도, 이는 curl 이 확인하는 인증서 파일만 해당함을 의미하며, Node.js 나 Python 의 certifi 가 안전해졌음을 증명하는 것은 아닙니다. 이후에는 자신이 Claude 를 어떤 형태로 사용하는지에 따라 결론이 달라집니다.

## 클로드의 사용 방식에 따라 확인 방법이 달라집니다.

'클로드를 사용하고 있다'고 단정하기는 어렵습니다. 화면 상태와 활용되는 기능에 따라 실제 프로그램이 실행되는 위치가 완전히 달라지기 때문입니다. 먼저 자신이 해당 범주에 속하는지 정리해 보겠습니다.

### 웹 버전은 개발 도구를 설치하지 않아도 작동합니다.

브라우저에서 claude.ai 를 열어 글쓰기, 요약, 대화 연습만 하고 있다면 모든 처리는 Anthropic 의 서버에서 완료됩니다. 웹 버전의 채팅 화면은 사용자의 컴퓨터에 Node.js 나 Python, Bun, Homebrew 등의 인증서를 임의로 설치하지 않습니다.

다만, 웹 버전에서도 확인이 필요한 경우가 하나 있습니다. 채팅에서 Claude 에 Python 이나 JavaScript 스크립트를 작성한 뒤, 해당 코드를 자신의 컴퓨터 터미널이나 Visual Studio Code 에 붙여넣고 실행하는 경우입니다.

예를 들어, 감사 보고서 샘플링이나 CSV 집계, 시의적절 공개 목록을 자동으로 추출하려 할 때 웹 버전 클로드가 제시한 `pip install`, `node`, `curl` 명령어를 실행해 본 적이 있다면, 그 순간 해당 컴퓨터에는 개발 도구가 설치되어 있습니다. 이 경우에도 클로드 코드를 사용하지 않더라도, 컴퓨터에 설치된 파이썬이나 노드.js 의 인증서를 확인해야 합니다.

### 협업은 클라우드나 개인용 가상 머신에서 실행됩니다.

Claude Desktop 앱의 'Cowork' 기능은 폴더를 연결하여 자료 정리, 데이터 가공, 반복 작업 등을 한 번에 처리해 주는 기능입니다. Cowork 는 내부에서 쉘 명령어나 코드를 실행하지만, 이는 귀하의 Mac 또는 Windows 개발 환경에 직접 설치되는 것은 아닙니다.

안티프의 공개 문서(Claude Cowork 아키텍처 개요 및 웹, 데스크톱, 모바일에서 Claude Cowork 사용) 에 따르면, Cowork 의 코드 실행 위치는 2026 년 10 월 6 일을 기준으로 변경됩니다.

- Pro 플랜과 Max 플랜에서 2026 년 10 월 6 일 이후 새로 시작하는 작업: 코드 실행은 Anthropic 클라우드에 있는 일시적 격리 환경에서 수행됩니다. 작업이 완료되면 해당 환경이 즉시 폐기되므로 사용자의 로컬 컴퓨터에 Node.js 나 Python 패키지가 남지 않습니다.
- 2026 년 10 월 6 일 이전에 컴퓨터에서 시작했던 작업과 이전에 실행 중인 로컬 정기 작업은 계속 내 컴퓨터에서 실행됩니다. 화면에 '이 컴퓨터에서만 실행됩니다'라는 안내가 표시되는 작업이 이에 해당합니다.
- 팀 플랜과 엔터프라이즈 플랜: 클라우드 실행은 베타 제공 중이며, 기존 데스크톱 환경에서는 사용자의 컴퓨터에서 실행됩니다.

휴대용 PC 에서 실행되는 Cowork 세션이라도, 실행되는 셸이나 코드는 macOS 의 Apple Virtualization 또는 Windows 의 Hyper-V 로 격리된 전용 Linux 가상 머신 내부에서 동작합니다. 이 가상 머신 내에서 패키지를 설치하더라도 Mac 본체의 /etc/ssl/cert.pem 이나 Windows 본체에 설치된 Python 과는 혼동되지 않습니다.

그럼에도 불구하고 Cowork 사용자에게 확인이 필요한 경우는 다음 세 가지입니다.

- 10 월 6 일 이전에 시작했던 로컬 작업이나 정기 작업을 현재까지 계속하고 있으며, 가상 머신의 이미지가 오래된 상태로 남아있는 경우
- 공동 작업 공간에 자신의 컴퓨터 폴더를 연결하여, 그 곳에서 작성한 스크립트 (.py, .js, .sh) 를 나중에 자신의 터미널에서 직접 실행하는 경우
- Claude Desktop 에서 로컬 MCP 서버나 데스크톱 확장을 설치하여 외부 서비스와 통신하는 경우 (이 MCP 서버 자체는 손안의 Node.js 나 Python 으로 실행됩니다)

### Claude Code 는 손에 있는 curl 나 Python 을 사용합니다.

Claude Code 는 격리된 가상 머신이 아니라, 당신의 컴퓨터 터미널에 있는 명령어를 직접 실행하여 작업을 진행합니다.

이전 글에서 정리한 바와 같이 Claude Code 본체를 2.1.303 이상으로 업데이트하더라도 Claude Code 자체의 통신만 복구됩니다. 작업 중에 호출되는 curl, git, Python(pip, uv, certifi), Node.js, Go, Docker, Deno 는 각각 자체 인증서 목록을 확인하여 외부와 통신합니다. 이 목록이 업데이트되지 않았으면 브라우저가 차단하더라도 터미널의 우회 경로가 여전히 열려 있는 상태가 됩니다.

### 데스크톱 애플리케이션을 설치하는 것은 Anthropic 의 모듈입니다.

Claude Desktop 을 설치하면 백그라운드에서 Bun 나 Node.js 도 함께 설치되지 않았을까 하는 우려의 목소리도 있지만, 일반적인 설치 프로그램이 다운로드하는 것은 Cowork 전용 가상 머신 전체와 앱이 사용하는 Claude CLI 본체뿐입니다. 이 요소들은 Anthropic 의配信 서버 (downloads.claude.ai) 에서 서명이나 체크섬을 확인하여 설치할 수 있는 구성 요소이며, 사용자의 Homebrew 나 시스템 전체에 일반적인 Node.js 나 Bun 을 분산시키는 구조가 아닙니다.

따라서 자신의 컴퓨터에 Node.js 나 Python, Bun 이 설치되어 있다면, 이는 이전 개발 작업 시 설치한 것이거나 로컬 MCP 서버를 실행하기 위해 설치한 것이거나, Claude Code 에 설치하도록 지시한 것 중 하나입니다.

## 지금 바로 업그레이드해야 할 항목과 나중에 점검해야 할 항목

### 브라우저와 OS 를 업데이트해도 괜찮은 사용법

이 단계까지의 분할로 다음 조건을 모두 충족한 개발자는 개별 업데이트 없이도 개발 도구를 사용할 수 있습니다.

- 클로드 (Claude) 는 웹 버전의 채팅이나 10 월 6 일 이후 새로 시작된 클라우드 실행 코워크 (Cowork) 만 사용합니다.
- 로컬 MCP 서버나 데스크톱 확장을 설치하지 않았습니다.
- 클로드가 작성한 프로그램을 내 터미널이나 명령 프롬프트에서 실행하지 않았습니다.
- 클로드 코드를 사용하지 않았습니다.

이 범위를 사용하신다면, OS 와 브라우저의 자동 업데이트를 활성화한 후 컴퓨터를 재부팅하여 최신 차단 정보를 적용해 두시면 됩니다.

### 클로드 코드를 탑재한 PC 에서 현재 확인한 사항입니다.

반면, Claude Code 를 사용하거나 로컬 MCP 서버를 실행하거나 Claude 가 작성한 코드를 자신의 터미널에서 실행하는 분들은 즉시 전용 페이지의 'Who has patched?' 섹션에 표시된 수정 버전에 업그레이드하시기 바랍니다. 현재 기준은 다음과 같습니다.

- Claude Code 2.1.303 이후
- 홈브루의 ca-certificates: 2026 년 9 월 25 일 1 일 이후 (마지막에 _1 이 없는 2026 년 9 월 25 일은 대응 전)
- Python 버전: 3.15.1, 3.14.9, 3.13.17 이후
- Python 의 certifi: 2026 년 10 월 19 일 이후
- pip: 26.2.2 이후 (내장된 certifi 를 업데이트하기 위해 필수)
- uv: 0.13.4 이후
- Node.js: 22.23.4, 24.22.1, 26.12.1(또는 각 버전의 그 이후 버전)
- Bun: 1.4.4 이후 (10 월 22 일 기사 공개 당시에는 pending 이었으나, 이후 1.4.4 가 출시되었습니다)
- Go：1.26.10 または 1.27.3 以降（Go で作られたツールや社内プログラムは、コンパイラを上げたうえで再ビルドが必要です）
- Rust: rustup 1.29.2 이후, rustls-webpki 0.103.16 이후, webpki-roots 1.0.10 이후 (이 경우에도 미리 빌드된 바이너리는 재빌드가 필요합니다).
- Docker Desktop 4.96.2 이후 버전
- Deno: 2.9.8 이후
- macOS 의 /usr/bin/curl, git, 표준 python3: /etc/ssl/cert.pem 을 업데이트하려면 전용 페이지의 절차를 따르세요. 표준 pip3 를 사용할 경우 sitecustomize.py 에 PIP_CERT=/etc/ssl/cert.pem 을 설정하세요.

Python 가상 환경 (.venv 등) 을 폴더별로 생성하는 경우, 컴퓨터 전체뿐만 아니라 실행할 프로젝트의 .venv 내부에 있는 certifi 와 pip 도 개별적으로 설치합니다.

### Bun 과 같이 나중에 수정판이 나올 모듈과 아직 대응되지 않고 남아있는 모듈

이곳에서 놓쳐서는 안 되는 점은, '일단 작업했다면 다시 보지 않아도 된다'는 것이 항상 참이 아니라는 것입니다.

이러한 명확한 예가 Bun 입니다. Bun 은 Node.js 와 마찬가지로 JavaScript 나 TypeScript 프로그램을 빠르게 실행하고 패키지를 가져올 수 있는 실행 환경입니다. 감사 업무나 백오피스 업무에서 AI 를 활용하더라도, 다음과 같은 상황에서 컴퓨터에 설치되어 있을 수 있습니다.

- Claude Code 가 "이 CSV 와 시의적절 공개 목록을 집계하는 도구를 만들어달라"고 요청했을 때, TypeScript 스크립트를 즉시 실행할 수 있는 Bun 이 선택되었습니다.
- bunx 나 bun install 을 사용하여 Claude Desktop 의 로컬 MCP 서버 및 보조 도구를 실행하는 방법 중

Bun 은 프로그램 본체에 자체 인증서 목록을 내장하고 있습니다. 따라서 OS 의 인증서를 업데이트하거나 Homebrew 의 ca-certificates 를 업그레이드해도, Bun 의 자체 통신은 정상화되지 않습니다. 10 월 22 일 이전 글이 게시된 당시에는 전용 페이지에서도 Bun 은「지원되지 않음 (pending)」으로 표시되어 있었으며, 그 당시에는 해결할 수 없었습니다. 이후 4 개의 emSign 루트 인증서를 제거한 Bun 1.4.4 가 출시되었고, 현재는 업데이트를 통해 대응이 가능해졌습니다. 또한 bun build --compile 로 독립 실행 파일을 생성하는 경우, Bun 본체를 1.4.4 이후 버전으로 업그레이드한 후 다시 생성해야 합니다.

Node.js 는 업데이트가 가능합니다. 전용 페이지에는 22.23.4, 24.22.1, 26.12.1 이 수정 버전으로 게시되어 있으며, 2026 년 10 월 21 일에 공개되었습니다. 22 시리즈, 24 시리즈, 26 시리즈를 사용 중인 분들은 해당 시리즈의 수정 버전으로 즉시 업그레이드할 수 있습니다. 기타 시리즈를 사용 중인 분들의 경우에도 수정 버전을 기다리는 것이 아니라, 공식 전용 페이지에 게시된 시리즈로 전환해야 합니다.

다음 날 확인이 필요한 것은 현재 'pending' 상태인 전용 페이지에 포함된 소프트웨어들입니다. (PHP 의 Composer ca-bundle, Erlang certifi, 컨테이너용 OS Bottlerocket, Godot 등)

자신의 컴퓨터에 해당 도구가 설치되어 있다면, 수정판이 나올 때까지는 출처가 불분명한 네트워크 환경에서 패키지 다운로드나 외부 API 통신을 하지 않도록 주의하고, 이후 다시 업데이트를 적용할 수 있도록 기록해 두어야 합니다.

### 개정판이 나오면 다시 한번 확인하겠습니다.

이러한 '후에 다시 대응한다'는 움직임이 필요한 상황은 다음과 같습니다.

- 10 월 22 일 한 번 점검한 이후로, 그 시점에서 pending 상태였던 Bun(현재는 1.4.4 에서 수정 완료) 등을 아직 배포하지 않은 경우
- 현재 공식 페이지에서 'pending' 상태로 남아있는 라이브러리 (예: Composer ca-bundle) 를 사용하고 있다면, Node.js 를 22.23.4, 24.22.1, 또는 26.12.1 중 하나로 업그레이드하세요.
- Go 나 Rust 로 작성된社内 도구 및 CLI 바이너리가 존재하되, 새로운 컴파일러로 재빌드된 버전이 아직 배포되지 않은 경우
- Docker 의 기본 이미지나 회사 내부 도구의 컨테이너가 아직 유효하지 않은 인증서를 포함하고 있는 경우
- /etc/ssl/cert.pem 파일을 수동으로 교체한 후, 향후 macOS 업데이트로 인해 해당 파일이 초기 상태로 복원되는 경우

이러한 환경에서는 한 번의 작업으로 해결되지 않습니다. 프롬프트를 실행한 후 종료하지 말고, 그 날에 완료하지 못한 모듈 이름을 기록해 두었다가, 며칠에서 일주일 후에도 특설 페이지의 'Who has patched?' 항목을 다시 확인하는 두 단계의 대응이 필요합니다.

## 회사 Claude 에서도 관리자가 설정할 수 없는 기능이 있습니다.

회사에서 배부된 컴퓨터나 법인 계약으로 Claude(Team 플랜, Enterprise 플랜) 을 사용하는 경우, "회사 관리자가 뒤에서 모두 해결해 주리라" 혹은 "정보보안팀에 문의하는 것 외에는 내가 할 수 있는 일이 없다"는 양극화된 해석으로 치닫기 쉽습니다. 실제로는 관리자가 대량으로 보호할 수 있는 부분과 사용자本人在 확인해야 할 부분이 명확하게 구분되어 있습니다.

### 팀과 엔터프라이즈에서 관리자를 통합하는 방식

Anthropic 의 관리자용 문서(Enterprise Admin Console 를 통한 배포 및 팀과 기업 플랜의 Claude Cowork 사용) 을 살펴보면, 조직 관리자나 정보 시스템 부서에서 관리 대시보드나 MDM(Intune, Jamf 등의 기기 관리 도구) 을 통해 일괄 제어할 수 있는 범위는 주로 다음 영역에 해당합니다.

- Claude 데스크톱 애플리케이션의 배포 및 업데이트
- Cowork 와 Claude Code 의 기능을 조직 또는 그룹 단위로 활성화하거나 비활성화할 수 있는 설정
- 클라우드 환경에서 코워크를 운영할지 여부를 전환하는 방법
- 클라우드 나 Cowork 가 통신할 수 있는 연결 대상 도메인 제한 (네트워크 허용 목록)
- 터미널 측 MDM 설정을 통한 로컬 MCP 서버 (isLocalDevMcpEnabled) 및 데스크톱 확장 (isDesktopExtensionEnabled) 의 일괄 정지

또한 Windows 나 macOS 의 OS 로서의 인증서 목록과 관리 대상인 Chrome·Edge 의 업데이트도 일반적으로 정보시스템 부의 배포 관리에 포함됩니다. 따라서 브라우저 차단이나 OS 표준 신뢰 스토어에 대해서는 사용자가 임의로 레지스트리나 시스템 설정을 변경하지 않도록 정보시스템 부의 배포 관리에 위임하는 것이 올바른 대응입니다.

### Node.js 나 Python 이 배포되지 않은 경우, 작성자가 직접 설치해야 합니다.

반면, Claude Enterprise 관리 화면에는 직원용 PC 내부에 개별 설치된 Python 의 certifi 나 pip, Node.js, Homebrew 패키지, Bun 을 원격으로 업데이트하는 기능이 없습니다.

기업의 정보시스템 부서가 MDM 을 통해 이러한 수준의 업데이트를 가능하게 하는 것은, 해당 기업이 개발 환경을 공식 패키지로 구성하여 직원의 단말기에 배포하고 관리하고 있을 때뿐입니다. 일본 내 많은 기업에서는 OS 와 브라우저, 바이러스 방지 소프트웨어는 정보시스템팀이 관리하고 있지만, 업무 효율화를 위해 개인이 설치한 Python(Anaconda, pyenv, 각 폴더의 .venv) 또는 Node.js(nvm, fnm), Homebrew 의 도구군 등은 정보시스템팀의 일괄 배포 대상에 포함되지 않는 경우가 흔합니다.

즉, 회사에서 제공하는 컴퓨터라도 역할 분담은 다음과 같습니다.

- OS 의 인증서 스토어나 /etc/ssl/cert.pem 과 같은 시스템 영역, 또는 회사 내 프로кси 관련 설정은 직접 수정하지 말고 정보 시스템 부서와 확인해야 합니다. (회사 자체의 루트 인증서나 프로кси 설정과 충돌하여 업무 시스템에 연결되지 않을 수 있기 때문입니다.)
- 회사가 일괄 관리하지 않는 Claude Code, Python 가상 환경 (.venv 의 certifi 와 pip), 개인 관리용 Node.js 및 uv 는 보안팀 규칙을 위반하지 않는 범위 내에서 사용자의 버전 확인 및 업데이트를 맡기십시오.

감사위원, 내부 감사관, 회계 감사관 (감사법인) 의 관점에서 회사 내 AI 활용과 IT 통제 상황을 검토할 때도 동일한 구조가 적용됩니다. "전사 브라우저 업데이트 완료", "클로드 (Claude) 는 엔터프라이즈 버전으로 계약 중"이라는 보고만으로는 현장이 로컬에서 실행 중인 스크립트나 MCP 서버의 인증서를 검증할 수 없습니다. 누가, 어디까지를 관리 대상으로 삼고 있는지 확인해야 합니다.

### 개인의 컴퓨터는 프롬프트로 점검할 수 있습니다.

자신이 관리하는 개인용 PC라면 회사 내 프로кси나 MDM 와의 충돌을 걱정할 필요가 없습니다.

다음 장의 프롬프트를 사용하여 먼저 '내 컴퓨터에 어떤 도구가 설치되어 있으며, 그 중 어떤 도구가 아직 지원되지 않는가'를 읽기 전용으로 확인하게 합니다. 그리고 설치된 도구만 업데이트하고, 공식적으로 아직 'pending' 상태인 것들은 목록에 남겨두고 나중에 다시 실행하는 흐름이 가장 확실합니다.

## 대응이 필요한 사람들을 위한 프롬프트

이후에는 Claude Code 를 사용하거나 현재 PC 에 Python, Node.js, 로컬 MCP 서버 등을 설치해 둔 분들을 위해, 현재 상태를 점검하고 업데이트를 진행하기 위한 프롬프트 3 가지를 소개합니다. 본인의 환경에 맞춰 선택하여 사용하시기 바랍니다.

### 프롬프트를 사용할 때 주의할 점

프롬프트를 조작하기 전에 다음 3 가지를 확인하세요.

첫 번째는 먼저 '현재 상태 확인만'이라는 프롬프트를 실행하는 것입니다. 파일을 즉시 교체하기 전에, 자신의 컴퓨터에 curl, Python, Node.js, Bun 이 어디에 설치되어 있는지 먼저 목록으로 확인합니다. 만약 대상이 나오지 않는다면, 그 이상의 작업은 불필요합니다.

두 번째는 회사에서 제공하는 컴퓨터에서 시스템 영역을 변경하지 않는 것입니다. 회사 컴퓨터에서 점검을 수행할 때는 세 번째 항목에 명시된 '회사 제공용 읽기 전용 프롬프트'를 사용하시고, 관리자 권한 (sudo) 이 필요한 작업이나 OS 의 인증서 스토어 변경은 절대 수행하지 마십시오.

셋째로, 아직 수정 버전이 나오지 않은 모듈이나 다른 시스템의 런타임이 있는 경우, 당장 우회책을 강요하지 않는 것입니다. AI 에게 "어떤 경우든 에러가 발생하지 않도록 해달라"고 요청하면, 인증서 확인 자체를 무효화하는 위험한 설정 (curl -k 나 NODE_TLS_REJECT_UNAUTHORIZED=0) 을 제안할 수 있습니다. 그時点で 공식 수정 버전이 없는 것은 "대응되지 않은 상태로 기록하고, 나중에 다른 프롬프트로 다시 확인하는" 것이 안전합니다.

### 현재 상태만 확인하도록 Claude Code 에 요청합니다.

먼저 파일을 수정하지 않고 현재 컴퓨터 상태와 다음 날 돌아올 때 처리되지 않은 모듈이 있는지 확인하도록 하는 프롬프트입니다. 개인용 컴퓨터에 어떤 파일이 들어있는지 알 수 없는 경우 처음에는 이를 사용합니다.

이 확인 결과, 즉시 업데이트 가능한 미처리 항목이 있는 개인용 컴퓨터에서는 이전 기사인「eMudhra 취약점 – 방치의 위험성과 Claude Code 의 자동 대응」에 게재한 패치 적용 프롬프트 (또는 위 보고서에서 제시된 개별 명령어) 를 사용하여 업데이트를 진행합니다.

### 지원되지 않는 모듈을 나중에 다시 확인하도록 설정합니다.

10 월 22 일 기준 한 번 점검했으나 여전히 대기 중인 상태인 컴퓨터 (당시 pending 상태였던 Bun 등도 남아있는 경우) 나 이번 점검에서도 아직 수정 버전이 나오지 않은 라이브러리, 재빌드 대기 중인 Go/Rust 도구를 발견했다면, 다음 프롬프트를 실행하기 전에 2~7 일 정도 기다리십시오. Node.js 는 22.23.4, 24.22.1, 26.12.1 버전이 이미 출시되었으므로 업데이트가 필요합니다.

### 회사 개발 도구는 배포 여부를 확인한 후 실행합니다.

회사에서 제공하는 컴퓨터 (Team Plan 또는 Enterprise Plan 포함) 를 사용 중이며, 자신의 단말기에 Node.js 나 Python, Claude Code, 로컬 MCP 서버가 설치되어 있는지 확인하려면 다음 프롬프트를 사용하세요. 이 프롬프트는 시스템의 인증서 스토어나 /etc/ssl/cert.pem 파일에 직접 접근하지 않으며, 정보보안팀 (CS) 에 확인해야 할 사항과 사용자 영역의 상태를 구분하여 정리하도록 유도합니다.

브라우저로 테스트용 URL 을 열어 인증서 오류가 발생함을 확인하는 것은 중요한 첫걸음입니다. 다만, 이는 브라우저 문 앞에 잠금을 걸어놓았다는 확인일 뿐이며, 컴퓨터 내부에서 작동하는 개발 도구나 로컬 MCP 서버까지 점검이 완료된 것은 아닙니다.

현재 사용하고 있는 것이 웹 버전인지, Cowork 의 클라우드 실행인지, 아니면 손에 들고 있는端末에서 Python, Node.js, Claude Code 를 직접 실행하고 있는지 먼저 구분해야 합니다. 손에 있는 도구를 활용하는 경우, '지금 바로 처리해야 할 것'과 '시간차를 두고 수정 버전을 내놓기 위해 나중에 다시 확인해야 할 것'으로 나누어 정리해두면 누락 없는 대응이 가능합니다.

이전 기초 편은 여기입니다.

**출처:** [note 원문](https://note.com/audit_ai/n/n9e54b9bd081f)

*번역: Qwen 3.5(.48) 초벌 + 교정 88청크*

[원문 보기](https://note.com/audit_ai/n/n9e54b9bd081f) | 출처: note.com