Star 20만 급의 에이전트 확장을 ~/.claude 에 넣어도 될까? 공급망 감사(Supply Chain Audit)를 수행한 기록

AI 코딩 에이전트용 확장(skill, plugin, MCP 서버)이 GitHub에서 단기간에 대량의 star를 모으고 있다.

설치는 npx로 한 번에 끝나며, 위치는 ~/.claude와 같이 자신의 홈 디렉토리 하위가 된다.

이러한 편리함의 이면에서, 확장은 이용자 자신의 권한으로 동작한다.

postinstall 스크립트, 상시 기동하는 hook, 자동으로 실행되는 MCP 서버는 모두 임의 코드 실행(Arbitrary Code Execution)의 입구가 될 수 있다.

이에 따라, 20만 star 급의 인기 확장 2개를 실제로 로컬에 도입하기 전에, read-only로 clone 하여 공급망 감사(Supply Chain Audit)를 수행했다.

대상은 공개 리포지토리 2개(Superpowers와 ECC)이며, 수치는 모두 GitHub API로 실측한 것을 사용한다.

감사 구조는 CISSP의 공급망 리스크 관리(Supply Chain Risk Management) 맥락에 비추어 정리한다.

결론을 먼저 밝힌다.

star의 절대수는 채택 판단의 근거로 사용할 수 없다.

판단 근거가 되는 것은 "확장이 도입 시와 가동 중에 무엇을 실행하는가"이며, 이는 코드를 읽지 않으면 알 수 없다.

인기 확장의 star는 수만 개에 달하며, 최상위는 20만에 이른다.

하지만 star는 구매할 수 있고, awesome-list를 통한 바이럴이나 FOMO(Fear Of Missing Out)로도 부풀려질 수 있다.

진지한 관여가 필요한 지표, 즉 watcher와 issue를 보면 규모의 실체를 알 수 있다.

GitHub API로 실측한 값은 다음과 같다.

Superpowers : 212,947★ / watcher 809 / issue 291
ECC : 199,280★ / watcher 986 / issue 38

star가 20만 개 있어도 그 동작을 추적하는 watcher는 1,000명 미만이다.

issue를 제기하며 실제로 깊이 사용하고 있는 인원은 더욱 적다.

star와 fork는 겉보기 지표로서 부풀려지기 쉽지만, watcher와 issue는 수고가 들어가는 만큼 실체에 가깝다.

표시되는 인기에 비해 실제 활성 이용자는 차원이 다르게 작다.

star가 늘어나는 방식도 타임스탬프를 실측해 보니 성격이 나뉘었다.

Superpowers : 100★=2일 → 1만★=2개월 → 4만★=3.7개월 (가속되는 유기적 커브)
ECC : 1만★=3일 → 4만★=19일 (비정상적으로 빠름)

Superpowers는 시간이 지남에 따라 가속되는 유기적인 커브를 그리며, 일괄 투입의 흔적이 없다.

ECC는 1만 star를 3일 만에 모으는 등 돌출되게 빠르지만, stargazer는 오래된 실존 계정들이며, 제작자인 affaan-m도 실존한다 (Anthropic × Forum Ventures 해커톤 우승자, follower 6,288).

즉, bot에 의한 조작은 아니다.

빠른 것은 hype와 FOMO에 의한 현상이며, star가 "품질과 채택의 증명"이 되지 않는 점은 양쪽 모두 공통적이다.

star는 안전성이나 실용성과도 상관관계가 없다.

채택 여부는 다른 근거로 결정할 수밖에 없다.

확장이 위험해지는 것은 이용자의 권한으로 멋대로 코드를 실행할 때이다.

이에 도입 시와 가동 중의 동작을 다음 관점에서 분석했다.

배포처와 실재성: 공식 마켓 게재 여부, 제작자 계정의 실재성, 커밋 분포
설치 시 실행: package.json의 scripts, postinstall, curl | bash 및 eval의 유무
hook: 어떤 이벤트(SessionStart, PreToolUse, PostToolUse, Stop)에 몇 개가 걸려 있는가
MCP 서버: 자동 기동하는가, npx -y로 외부 패키지를 가져오는가
비밀 정보 접근: .env나 인증 정보를 읽는가, redact(삭제/마스킹) 하는가
외부 통신: 텔레메트리(Telemetry)나 외부로 향하는 HTTP가 있는가, localhost 한정인가
의존성 트리: runtime 의존성의 수와 출처

이 관점에서 2개를 분석했을 때, 악성 여부에서는 차이가 없었으나 가동 시의 동작에서 성격이 크게 갈렸다.

Superpowers는 감사한 범위 내에서 위험한 동작이 단 하나도 없었다.

package.json에는 scripts도 postinstall도 없었으며, 의존성은 제로였다.

설치해도 코드는 전혀 실행되지 않는다.

hook은 SessionStart 1개뿐이며, skill의 Markdown을 컨텍스트에 주입하는 것에 그친다.

PreToolUse, PostToolUse, Stop 후크는 없으며, 명령어 실행이나 권한 부여도 없다.

외부 통신도 없으며, 부속된 brainstorm 서버는 127.0.0.1에 닫혀 있다.

게다가 Anthropic의 공식 마켓플레이스에 게재되어 있으며, 752,120회 설치라는 독립적인 실적이 있다.

공식 심사를 통과한 배포 경로가 있다는 사실 자체가 하나의 안전 신호(safety signal)가 된다.

설치 시 코드를 실행하지 않고, 후크는 주입(injection) 1개뿐이며, 외부 통신도 없다.

이것이 로컬 확장(local extension)에 요구되는 최소한의 동작이다.

ECC는 악성은 아니지만 성격이 정반대였다.

우선 악성의 징후는 없다.

postinstall는 echo 배너 표시뿐이며, remote-exec, curl | bash, eval은 전혀 없다.

외부로 향하는 통신은 거의 제로에 가깝고, 유일한 urllib는 사용자가 명시적으로 import 했을 때만 동작하며, 텔레메트리(telemetry)도 없다.

비밀 정보(secret)를 다루는 방식은 오히려 방어적이며, .env 읽기를 차단하고 비밀 정보를 redact(비식별화)한다.

알려진 악성 버전의 blocklist와 AWS 메타데이터의 exfiltration(유출)을 탐지하는 IOC 스캐너까지 자체적으로 동봉하고 있었다.

runtime 의존성은 3개로 적고, 정체도 깨끗했다 (나머지 214개는 개발용 의존성).

문제는 안전성이 아니라, 가동 시의 무거움과 침습성(invasiveness)에 있다.

ECC는 * 매칭의 PreToolUse와 PostToolUse를 포함하여, 상시 가동되는 후크를 20개 이상 심어둔다 (observe, learn, cost, notify 등).

게다가 기동 시에 npx -y로 MCP 서버를 6개나 자동으로 가져와서 실행한다.

무해하다는 것을 확인하더라도, 이 정도의 후크와 외부 취득을 상시 작동시키는 구성은 공격 표면(attack surface)을 스스로 넓히는 결과가 된다.

"악성인가"와 "도입해도 되는가"는 별개의 질문이다.

ECC는 전자에서는 '백(white)'이지만, 후자에서는 npx -y의 자동 취득과 후크의 물량이라는 공격 표면의 넓이 때문에 걸린다.

이 감사는 CISSP의 지식 체계로 보면 두 영역에 걸쳐 있다.

하나는 Domain 1의 서드파티 및 공급망 리스크 관리(supply chain risk management)이다.

star와 같은 인기 지표를 채택 근거로 삼지 않고, 배포처와 실재성을 확인하며, 가동 시의 동작으로 수용 여부를 판단하는 흐름은 그대로 공급업체 평가(supplier evaluation)의 축소판이다.

또 하나는 Domain 8의 소프트웨어 개발 보안(software development security)이다.

postinstall를 통한 임의 코드 실행, 후크를 이용한 지속성(persistence) 확보, npx -y를 통한 외부 패키지 자동 취득은 모두 소프트웨어 공급망 공격의 전형적인 진입점이다.

ECC가 동봉했던 IOC 스캐너(알려진 악성 버전의 blocklist와 AWS 메타데이터 exfiltration 탐지)는 CI에 통합할 탐지 기능의 구체적인 예시로서 참고가 된다.

에이전트 확장은 "편리한 도구"이지만, 도입하는 입장에서는 코드를 실행하는 공급업체(supplier)이다.

평가의 관점은 새로운 벤더를 채용할 때와 다르지 않다.

20만 star 급의 인기 확장 2개를 로컬에 넣기 전에 감사했다.

• star, fork의 절대수는 채택 판단에 사용할 수 없다. watcher와 issue 비율, star의 증가 곡선이 실태에 더 가깝다.
• 채택 여부를 결정하는 것은 동작이다. 설치 시 실행, 후크의 종류와 수, MCP의 자동 실행, 비밀 정보에 대한 접근, 외부 통신을 코드를 읽어 확인한다.
• 악성이 아니라는 것과 도입해도 좋다는 것은 다른 판단이다. Superpowers는 안전성과 도입 적성을 모두 만족했고, ECC는 안전성만을 만족했다.

인기 확장을 원라이너(one-liner)로 설치하기 전에, clone 해서 읽는 수고를 아끼지 않는 것이 자신의 홈 환경을 지키는 최소한의 방어가 된다.