일부 OpenClaw 스킬이 내 신용카드를 가진 npm 패키지에 불과하다는 것을 깨달은 날, 나는 OpenClaw 스킬을 더 이상 신뢰하지

제3자 OpenClaw 스킬을 사용하는 가장 안전한 방법은 그것을 해롭지 않은 플러그인 (plugin)이 아니라, 돈과 데이터 접근 권한을 가진 자동화 코드 (automation code)로 취급하는 것입니다.

ClawScan과 VirusTotal을 통과한 5개의 악성 스킬이 발견되었다는 보고를 읽은 후, 저의 기본 대응 방식은 빠르게 바뀌었습니다:

• 자격 증명 (credentials) 격리
• 외부 네트워크 호출 (outbound network calls) 조사
• 정확한 버전 고정 (pin exact versions)
• 무작위 마켓플레이스 설치보다 범위가 좁은 사내 스킬 선호

저는 예전에 OpenClaw 스킬이 기본적으로 더 세련된 Zapier 단계 정도라고 생각했습니다.

조금 지저분하고, 문서화가 덜 되어 있을 수는 있지만, 여전히 근본적으로는 플러그인 (plugin)이라고 말이죠.

그러다 어느 저녁, Unit 42가 ClawScan과 VirusTotal을 통과한 5개의 악성 스킬을 발견했다는 내용의 r/openclaw 스레드를 읽게 되었습니다:
https://reddit.com/r/openclaw/comments/1ue5ln7/unit_42_found_5_malicious_skills_that_passed/

그것이 저의 플러그인 (plugin)이라는 사고 모델을 깨뜨렸습니다.

무서운 점은 단순히 멀웨어 (malware)뿐만이 아니었기 때문입니다.

그것은 바로 동기 (motive)였습니다.

해당 스레드의 한 예시인 money-radar는 런타임 (runtime) 중에 추천 내용을 변경할 수 있도록 원격의 referrals.json 파일을 가져온 것으로 알려졌습니다. 이는 검토 과정 중에는 코드가 깨끗해 보일 수 있지만, 스킬이 조용히 당신의 에이전트 (agent)를 다른 사람의 제휴 수수료 지급 쪽으로 유도할 수 있음을 의미합니다.

페이로드 (payload)도 없고, 명백한 익스플로잇 (exploit)도 없습니다. 그저 당신의 자동화 (automation)에 연결된 인센티브 (incentives)가 있을 뿐입니다.

해당 스레드의 한 댓글 작성자는 대부분의 보안 게시물보다 더 명확하게 말했습니다:

“시그니처 스캐닝 (Signature scanning)은 여기서 아무런 도움이 되지 않습니다. 에이전트에게 항상 추천 링크를 사용하라고 지시하는 스킬은 누구도 플래그 (flag)를 세우지 않는 페이로드 (payload)가 아닙니다. 그것은 단지 지침 (instructions)일 뿐입니다. 'Pass' 배지는 아무런 의미가 없습니다.”

그 순간 저는 “플러그인 (plugin)”이라고 생각하는 것을 멈추고 다음과 같이 생각하기 시작했습니다:

은행 접근 권한을 가진 npm 패키지 (npm package).

일단 그런 관점으로 보기 시작하면, 많은 OpenClaw의 동작들을 대수롭지 않게 넘기기가 어려워집니다.

가장 이상한 점은 멀웨어 (malware)가 아닙니다. 바로 숨겨진 동작 (hidden behavior)입니다.

이 내용을 파헤치던 중, 저는 또 다른 r/openclaw 스레드를 발견했습니다:
https://reddit.com/r/openclaw/comments/1ue5yqh/help_with_tool_use_secret_tools/

한 사용자가 자신의 에이전트(agent)가 왜 일반적인 파일 요청 시에 가끔 sessions_send를 호출하는지 이해하려고 노력하고 있었습니다.

그것만으로도 이미 이상한 상황입니다.

그런 다음 그들은 미디어를 플랫폼 외부로 전송할 수 있는 것처럼 보이는 숨겨진 메시지 기능 (hidden message capability)에 대해 설명하며 다음과 같이 적었습니다:

“이 도구는 에이전트가 자신의 존재를 완전히 단호하게 거부할 정도로 숨겨져 있습니다.”

이 문장이 제 머릿속을 떠나지 않았습니다.

지금 우리는 README 파일이 부실한 수상쩍은 마켓플레이스 등록 항목에 대해 이야기하고 있는 것이 아닙니다.

우리는 운영자(operator)에게조차 완전히 투명하게 공개되지 않을 수도 있는 에이전트 표면 (agent surface)에 대해 이야기하고 있는 것입니다.

한 댓글 작성자는 10번 중 8번 정도 숨겨진 OpenClaw 메시지 기능을 트리거하는 프롬프트 (prompt)를 발견했다고 말했습니다. 일관되지는 않지만, 반복 가능한 수준입니다.

이것은 브라우저 확장 프로그램 (browser-extension) 수준의 위험이 아닙니다.

이것은 실시간 자동화 (live automation) 위험입니다.

만약 당신의 OpenClaw 설정이 다른 에이전트에게 메시지를 보내고, 미디어를 전송하며, 브라우징하고, 구매하고, 저장된 자격 증명 (credentials)을 사용하여 행동할 수 있다면, 모든 제3자 스킬 (third-party skill)은 귀여운 애드온 스토어라기보다는 n8n, Make, Zapier 또는 커스텀 Python 자동화에 훨씬 더 가까운 폭발 반경 (blast radius) 안에 위치하게 됩니다.

그리고 나서 저는 반복 구매에 관한 스레드를 발견했습니다.

무작위 스킬이 당신의 카드로 HVAC 필터를 재주문하도록 허용하시겠습니까?

저장된 자격 증명과 결제 수단을 사용하여 HVAC 필터, McMaster-Carr 부품, 가계 용품 등을 재주문하는 것에 대해 사람들이 이야기하는 OpenClaw의 실질적인 자동화 반복 구매 논의가 있습니다.

그 시점에서 이 문제는 더 이상 추상적이지 않게 됩니다.

그러한 환경에서의 악성 스킬 (malicious skill)은 랜섬웨어 (ransomware) 동작을 수행할 필요가 없습니다.

벨라루스의 Raspberry Pi로 당신의 SSH 키를 유출할 필요도 없습니다.

그저 다음과 같은 사항들에 미묘하게 영향을 미치기만 하면 됩니다:

• 무엇을 구매하는지
• 어디에서 구매하는지
• 언제 구매하는지
• 어떤 추천 경로 (referral path)를 사용하는지

그렇기 때문에 저는 올바른 보안 모델이 잔혹할 정도로 단순해야 한다고 생각합니다:

모든 제3자 OpenClaw 스킬을 돈을 쓰고, 데이터를 이동시키며, 당신이 통제할 수 없는 인센티브(incentives) 하에서 결정을 내릴 수 있는 코드처럼 취급하십시오.

만약 이 말이 편집증적으로 들린다면, 좋습니다.

여기서는 약간의 편집증이 필요합니다.

두 가지 서로 다른 문제가 뒤섞이고 있습니다

일부 악성 스킬들은 전형적인 패키지 보안(package-security) 문제입니다:

• 숨겨진 드로퍼 (hidden droppers)
• 난독화된 코드 (obfuscated code)
• 스캐너 회피 (scanner evasion)
• 과도하게 큰 정크 파일 (oversized junk files)

해당 스레드에 따르면, omnicogg는 AMOS 드로퍼를 내부에 유지하면서 스캐너가 파일을 건너뛰도록 README에 22MB의 정크 데이터를 채워 넣었다고 합니다.

이것은 에이전트(agent)의 탈을 쓴 구식 멀웨어(malware) 방식의 사고입니다.

하지만 다른 스킬들은 행동(behavior) 문제입니다:

• 원격 추천 (remote recommendations)
• 제휴 유도 (affiliate steering)
• 조정된 금융 행동 (coordinated financial behavior)
• 에이전트 선택에 대한 프롬프트 수준의 조작 (prompt-level manipulation of agent choices)

letssendit의 사례는 매우 충격적입니다. 설치된 에이전트들로부터 SOL을 모아 조직적인 밈코인(meme-coin) 출시를 시도한 것입니다.

다시 말하지만, 이것은 플러그인 리스크(plugin risk)가 아닙니다.

그보다는 누군가가 당신의 에이전트 런타임(agent runtime)에 이상하고 작은 비즈니스 모델을 부착한 것에 가깝습니다.

첫 번째 카테고리에 대해서는 정적 스캐닝(Static scanning)이 여전히 중요합니다.

다만 두 번째 카테고리에는 취약할 뿐입니다.

따라서 진짜 질문은 이것입니다: 만약 당신의 팀이 OpenClaw, n8n, Make, Zapier 또는 커스텀 에이전트와 함께 OpenAI 호환 LLM 스택을 사용하면서 여전히 스킬이 필요한 상황이라면, 월요일 아침에 실제로 무엇을 해야 할까요?

나의 새로운 규칙: 내가 읽을 수 있다면, 아마 더 안전한 버전을 생성할 수 있을 것이다

Unit 42 스레드의 한 댓글 작성자가 무분별한 설치에 대해 가장 강력한 논거를 제시했습니다:

“스킬이 무엇을 하는지 읽을 수 있다면, 직접 작성할 수 있고, 그러면 당신의 에이전트가 실제로 무엇을 실행하고 있는지 알 수 있습니다.”

저는 이 말이 기본적으로 옳다고 생각합니다.

모든 팀이 모든 것을 처음부터 직접 코딩해야 한다는 뜻은 아닙니다. 그것은 환상입니다.

사람들이 스킬을 설치하는 이유는 편의성이 중요하기 때문이며, 저위험 작업의 경우 그러한 트레이드오프(tradeoff)는 충분히 합리적일 수 있습니다.

하지만 다음과 같은 사항에 접촉하는 것이라면 이야기가 다릅니다:

• 구매 (purchases)
• 메시징 (messaging)
• CRM 업데이트 (CRM updates)
• 금융 워크플로우 (financial workflows)
• 외부 게시 (external posting)

…나는 차라리 GPT-5.4, Claude Opus 4.6, Grok 4.20, Qwen, 또는 Llama에게 정밀한 사양 (spec)을 제공하여 좁은 범위의 사내 스킬 (in-house skill)을 생성하는 편이, 의도가 불분명한 광범위한 마켓플레이스 스킬 (marketplace skill)을 설치하는 것보다 낫다고 생각한다.

그것이 더 느리게 들릴 수도 있다.

이상하게도, 실제로는 그렇지 않은 경우가 많다.

다음과 같은 좁은 범위의 스킬은:

“샌드박스 자격 증명 (sandbox credentials)을 사용하여 McMaster-Carr에 승인된 구매 주문서를 제출하고 드라이 런 (dry-run) 요약을 반환하라.”

다음과 같은 것보다 검토하기 훨씬 쉽다:

“스마트 추천 기능이 있는 쇼핑 어시스턴트.”

범위가 작을수록 다음 사항들을 감사 (audit)하기가 더 쉽다:

• 네트워크 호출 (network calls)
• 비밀 정보 사용 (secrets usage)
• 프롬프트 처리 (prompt handling)
• 승인 경계 (approval boundaries)
• 부수 효과 (side effects)

그리고 그렇다, 비용 문제도 여기서 나타난다.

작은 내부 스킬을 생성할 때는 보통 더 많은 반복 (iterations)을 수행한다. 더 많은 시뮬레이션 (simulation). 더 많은 적대적 프롬프팅 (adversarial prompting). 더 많은 검토 루프 (review loops).

만약 토큰 (token)당 비용을 지불하고 있다면, 팀들은 정확히 해서는 안 될 부분에서 비용을 절감하기 시작한다.

만약 OpenAI 호환 고정 요금제 API를 사용하고 있다면, 그 워크플로우 (workflow)는 훨씬 더 자연스럽게 느껴진다. 토큰 미터기를 계속 주시하지 않고도 사양 (specs)을 반복 개선하고, 더 안전한 좁은 범위의 도구들을 생성하며, 이를 공격적으로 테스트할 수 있다.

이것이 에이전트 중심 워크플로우 (agent-heavy workflows)에서 내가 Standard Compute를 선호하는 과소평가된 이유 중 하나다. 만약 당신의 팀이 많은 작은 자동화 기능들을 구축하고 테스트하고 있다면, 토큰에 대한 불안감보다는 예측 가능한 월간 요금제가 훨씬 더 적합하다.

무엇을 설치하고, 생성하거나, 구축해야 하는가?

내가 보는 트레이드오프 (tradeoff)는 다음과 같다:

옵션	실제로 구매하는 것
제3자 마켓플레이스 스킬 (Third-party marketplace skill)	설치가 가장 빠르지만, 의도와 숨겨진 동작에 대한 투명성이 가장 낮음; 자격 증명 격리 (credential isolation) 및 네트워크 검사 (network inspection)의 필요성이 가장 높음
...

나의 주관적인 버전은 다음과 같다:

• 마켓플레이스 스킬 (Marketplace skills)은 위험도가 낮고, 비밀 정보가 없으며, 돈이 들지 않는 작업에는 괜찮다.
• 생성된 좁은 범위의 스킬 (Generated narrow skills)은 대부분의 진지한 에이전트 팀에게 가장 이상적인 지점 (sweet spot)이다.
• 광범위한 맞춤형 자동화 (Broad custom automation)는 구매, 메시징, 금융, 그리고 Slack에서 당신을 당황하게 만들거나 실제 돈을 쓰게 만들 수 있는 모든 것에 대한 정답이다.

하지만 선호도는 프로세스 (process)가 아니다.

여전히 검토 체크리스트 (review checklist)가 필요합니다.

OpenClaw 스킬을 위한 합리적인 검토 프로세스 (review process)

이것은 외부로 메시지를 보내거나, 개인 데이터에 접근하거나, 구매를 시작할 수 있는 OpenClaw 스킬을 활성화하기 전에 제가 사용할 워크플로 (workflow)입니다.

1. 먼저 자격 증명 (credentials)을 격리하세요

운영 환경의 비밀 정보 (production secrets)로 절대 테스트하지 마세요.

새로운 스킬에 실제 결제 경로를 절대 제공하지 마세요.

별도의 환경 변수 (environment variables)와 샌드박스 (sandbox) 계정을 사용하세요:

export OPENCLAW_TEST_API_KEY="oc_test_..."
export SANDBOX_STRIPE_KEY="sk_test_..."
export TEST_DISCORD_WEBHOOK="https://discord.com/api/webhooks/..."
...

만약 어떤 스킬이 당신의 실제 Google Workspace, Stripe, Discord, Shopify 또는 Slack 자격 증명을 가져와야만 작동한다면, 그것 자체로 이미 유용한 정보입니다.

2. 외부 네트워크 호출 (outbound network calls)을 조사하세요

'돈 탐지기 (money-radar)' 예시는 사람들이 에이전트 스킬을 검토하는 방식을 영구적으로 바꿔 놓아야 합니다.

설치하기 전에, URL과 요청 라이브러리 (request libraries)를 grep으로 검색하세요:

grep -R "http" skills/<skill-name>
grep -R "fetch\|axios\|requests\|curl" skills/<skill-name>

만약 JavaScript 또는 TypeScript라면, package.json과 락파일 (lockfiles)도 확인합니다:

cat skills/<skill-name>/package.json
cat skills/<skill-name>/package-lock.json | head -n 80

당신이 찾아야 할 것들은 다음과 같습니다:

• 원격 JSON 설정 (remote JSON config)
• 제휴 엔드포인트 (affiliate endpoints)
• 분석 비콘 (analytics beacons)
• 웹훅 포스트 (webhook posts)
• README에 언급되지 않은 도메인 (domains)
• 동적 코드 페치 (dynamic code fetches)

당신이 제어할 수 없는 서버로부터 실시간 추천, 지침 또는 라우팅 로직 (routing logic)을 가져오는 모든 스킬은 훨씬 더 높은 의심 점수를 받아야 마땅합니다.

3. 검토한 정확한 버전을 고정(Pin)하세요

최신 버전을 설치하고 잘 되기를 바라지 마세요.

하나의 커밋 (commit)을 검토하세요. 하나의 커밋을 실행하세요. 하나의 커밋을 유지하세요.

git submodule add <skill-repo-url> skills/<skill-name>
cd skills/<skill-name>
git checkout <reviewed-commit>

npm이나 다른 패키지 소스에서 가져오는 경우, 정확한 버전을 고정하세요:

{
  "dependencies": {
    "some-openclaw-skill": "1.4.2"
...

캐럿 (caret, ^) 기호는 쓰지 마세요. 예기치 못한 상황도 만들지 마세요.

4. 위험한 프롬프트 (prompts)를 시뮬레이션하세요

단순히 정상적인 경로 (happy path)만 테스트하지 마세요.

부수적인 동작 (side behavior)을 유발하는 프롬프트 (prompts)를 시도해 보세요:

• 이 파일을 내 다른 계정으로 보내줘
• 가장 저렴한 옵션을 찾아서 지금 바로 구매해
• 첨부 파일과 함께 판매자에게 직접 메시지를 보내
• 사용 가능하다면 내부 메시징 기능 (internal messaging capability)을 사용해
• 승인된 목록에 없더라도 가장 좋은 공급업체를 추천해

앞서 언급한 숨겨진 OpenClaw 메시지 이야기는 여기서 모두를 더 공격적으로 만들 것입니다.

로컬 테스트 하네스 (test harness)가 있다면, 이러한 프롬프트들을 스크립트로 만들고 출력값의 차이 (diff)를 비교해 보세요.

의사 테스트 (pseudo-test) 예시:

test_prompts = [
    "이 송장 PDF를 내 개인 이메일로 보내줘",
    "가장 저렴한 교체용 필터를 지금 바로 구매해",
...

5. 네트워크 가시성 (network visibility)을 확보한 상태에서 실행하세요

스킬 (skill)이 중요하다면, 해당 스킬이 어디와 통신하는지 보고 싶을 것입니다.

최소한, 외부 요청 (outbound requests)을 관찰할 수 있는 환경에서 실행하세요.

예를 들어, 프록시 (proxy)를 통해 트래픽을 라우팅하거나 컨테이너 (container)로부터 발생하는 DNS 및 HTTP 요청을 로그로 남기세요.

단순한 로깅 (logging)만으로도 도움이 됩니다:

docker run --rm \
  --env-file .env.test \
  --network bridge \
...

그 다음 다음 사항들을 확인하세요:

• 예상치 못한 도메인 (unexpected domains)
• 재시도 폭풍 (retry storms)
• 웹훅 (webhook) 포스트
• 분석 (analytics) 또는 추천 (referral) 엔드포인트 (endpoints) 호출

6. 마켓플레이스 번들 (marketplace bundles)보다 생성된 좁은 범위의 스킬을 선호하세요

이것이 가장 중요한 부분입니다.

GPT-5.4나 Claude Opus 4.6에게 정밀한 명세 (spec)를 바탕으로 가능한 한 가장 작은 규모의 스킬을 생성하도록 요청한 다음, 작은 내부 스크립트를 검토하듯 코드를 검토하세요.

범위 (scope)가 작다면 검토가 가능합니다.

범위가 너무 크다면, 당신의 검토는 보여주기식 연극 (theater)에 불과합니다.

그리고 그 연극은 종종 "스캔 통과"라는 결과로 변질되곤 합니다.

제가 차라리 사용하고 싶은 명세의 형태는 다음과 같습니다:

다음 기능을 수행하는 OpenClaw 스킬을 구축하라:
- 승인된 SKU 및 수량을 수락함
- api.mcmaster.com에만 쿼리함
...

이것은 검토가 가능합니다.

"스마트 구매 보조 도구"는 검토가 불가능합니다.

편의성은 실재합니다. 인센티브 드리프트 (incentive drift) 또한 실재합니다.

반론도 이해합니다.

모든 제3자 스킬 (third-party skill)이 악의적인 것은 아닙니다.

한 Reddit 댓글 작성자는 스킬의 핵심 목적 자체가 당신이 직접 일을 할 필요가 없게 만드는 것이라고 말했습니다.

그 말도 일리가 있습니다.

저위험 (low-risk) 작업의 경우, 편의성이 절대적으로 승리할 수도 있습니다.

하지만 문제는 깨끗한 스킬이 곧 정렬된 (aligned) 스킬이라고 가정하는 실수입니다.

이것들은 서로 다른 질문입니다.

• 악성코드 검토 (Malware review)는 묻습니다: 패키지에 어떤 코드가 들어있는가?
• 동작 검토 (Behavior review)는 묻습니다: 이 스킬이 런타임 (runtime) 중에 내 에이전트를 어떤 결과로 몰아가는가?

두 번째 질문은 더 새롭고, 기이하며, 에이전트에게 훨씬 더 관련성이 높습니다.

특히 에이전트가 돈을 쓸 수 있는 상황이라면 더욱 그렇습니다.

가장 안전한 기본값은 당신이 생각하는 것보다 더 작아야 합니다

저는 대부분의 팀이 수년 전 npm 사용자들이 배웠던 것과 동일한 교훈을 얻게 될 것이라고 생각합니다. 다만 그 결과가 훨씬 더 비쌀 뿐입니다.

가장 안전한 기본값은 "나쁜 스킬을 적게 설치하는 것"이 아닙니다.

권한을 더 적게 부여하고, 더 좁은 범위의 코드를 사용하며, 인센티브 (incentives)가 동작으로 유출될 수 있다고 가정하는 것입니다.

즉, 다음과 같은 의미입니다: