클로드 플러그인이 2,393개나 됩니다. 인기순 목록을 보고 몇 개 깔아봤는데 대부분 겉돌더군요. 문제는 플러그인이 아니라 고르는 방식이었습니다.
그래서 방법을 바꿨습니다. 인기가 아니라 “내 프로젝트가 실제로 겪은 문제”에서 출발해 후보를 좁히고, 마지막엔 반드시 직접 돌려봤습니다. 그 절차를 그대로 적습니다.
미리 말씀드리면 추천 목록이 나쁘다는 얘기가 아닙니다. 목록은 후보를 찾는 데까지는 확실히 유용하죠. 다만 거기서 바로 설치를 결정하면 남의 문제에 맞춰진 도구를 쓰게 됩니다. 저도 그러다 세 번 틀렸고요.
처음엔 전체의 10%만 보고 있었습니다
파이썬 프로젝트에 뭘 붙이면 좋을지 알아보다가, 공식 마켓플레이스 257개를 훑고 두 개를 골랐습니다. 그런데 “유튜브에 언급되는 건 훨씬 많은데 왜 두 개뿐이냐”는 지적을 받았습니다.
확인해보니 조사가 부실했습니다. 클로드 플러그인은 Anthropic 공식 마켓과 커뮤니티 마켓 두 곳에 나뉘어 있는데, 커뮤니티 쪽 2,283개를 열어보지도 않았습니다. 제가 본 건 전체의 10%였습니다. 게다가 그 257개 안에서도 제가 떠올린 키워드로만 걸렀더니, Anthropic이 직접 만든 것 두 개를 통째로 놓쳤습니다. 설명문에 제 키워드가 없었을 뿐이었습니다.
그래서 전수 검사를 만들기로 했습니다.
전수 검사를 만들며 세 번 실패했습니다
첫 번째, 홍보문으로 판정했습니다. 카탈로그의 설명은 저자가 쓴 한두 문장이죠. 중앙값 268자입니다. README는 그 25배(중앙값 6.5KB)이고, 결정적인 단서는 대개 거기 숨어 있습니다.
예를 들어 어떤 플러그인의 “94% 코드 감소”라는 주장. README를 열어보면 저자가 직접 “per-task ceiling, not the average”, 그러니까 최댓값이지 평균이 아니라고 적어뒀습니다. 소개 영상 제목만 봐서는 알 길이 없죠.
두 번째, 그래서 README 전문을 썼더니 더 나빠졌습니다. 89%가 매치됐고 상위권을 만능 프레임워크가 싹 가져갔습니다. 원인을 재봤습니다.
git README의 85.2%에 등장 ← 정보량 0
hook 36.6%
verify 34.3%
commit 29.3%
git 하나 때문에 조건 하나가 1,894건이나 걸렸습니다. 가중치를 넣어봐도 소용없더군요. 확신 있던 pyright-lsp가 348위, context7은 2,222위로 바닥에 깔렸습니다. 점수가 적합도가 아니라 문서 길이를 재고 있었던 겁니다.
세 번째는 집계 버그. 공식과 커뮤니티에 같은 이름이 161건 겹치는데, 이름으로 중복을 지워서 숫자가 어긋났습니다.
해결은 의외로 단순했습니다. 목적 선언부만 봅니다. README 맨 앞 450자, “이게 뭘 하는 물건인가”만 점수 대상으로 삼는 거죠. 설치법이나 FAQ에는 온갖 단어가 다 나오지만 앞머리에는 목적만 적혀 있으니까요.
전문 기준 목적선언부 기준
pyright-lsp 348위 → 4위
context7 2,222위 → 32위
여기서 오해하기 쉬운 부분을 미리 짚고 가겠습니다. 맨 앞의 2,393개만 누구에게나 같은 숫자입니다. 마켓에 올라온 전체 개수니까요. 그 뒤의 169개, 5개, 1개는 제 조건으로 거른 결과일 뿐입니다.
같은 절차를 다른 프로젝트에 돌리면 숫자도 남는 플러그인도 달라집니다. 파이썬을 안 쓰면 pyright는 애초에 후보가 아니고, 한국어 윈도우가 아니면 제가 겪은 인코딩 문제도 안 나겠죠. 그러니 이 글에서 가져가실 건 “무엇을 깔아라”가 아니라 “어떻게 고르느냐”입니다. 목록을 그대로 옮겨 적는 순간, 제가 처음에 저지른 실수를 똑같이 반복하시게 됩니다.
그래도 순위는 결과를 예측하지 못했습니다
후보를 좁힌 뒤 하나씩 소스를 받아 직접 돌렸습니다. 세 개를 검증했고 세 개 다 소개문만으로는 알 수 없는 사실이 나왔습니다.
hookify(공식)는 한국어 윈도우에서 규칙이 전멸했습니다. 설정을 읽는 코드에 인코딩 지정이 빠져 있더군요. 그러면 한국어 윈도우는 기본값인 cp949로 읽습니다. 규칙 파일에 한글이나 이모지가 하나만 섞여 있어도 그대로 터지죠.
Error: Malformed rule file: 'cp949' codec can't decode byte 0xe2 ...
{} ← 조용히 '통과'
최악은 실패했을 때 차단이 아니라 그냥 통과라는 점입니다. 막고 있다고 믿는데 실제로는 열려 있는 상태. 그게 제일 위험하죠. PYTHONUTF8=1을 주면 정상 동작하긴 합니다.
덤으로 비용도 재봤습니다. 도구 호출당 0.49초. 100번 쓰면 50초가 순수 오버헤드입니다. README엔 없는 숫자죠.
safety-net(★1,462)은 제가 실제로 사고를 낸 명령을 통과시켰습니다. “파괴적인 파일 명령을 막는다”고 돼 있었는데, 정작 프로젝트 안에서 파일을 지운 그 명령은 그냥 지나가더군요. rm -rf /나 git push --force는 잘 막습니다.
그럼 이건 플러그인이 잘못 만들어진 걸까요? 아닙니다. README 표를 다시 읽어보니 non-temp paths outside cwd라고 분명히 적혀 있었습니다. 프로젝트 안은 설계상 허용입니다. 제가 제 사고에 잘못 갖다 붙인 거죠. 별점 1,462개는 그런 걸 알려주지 않습니다.
pyright-lsp만 첫 실행에서 진짜 버그를 찾았습니다. 유닛 테스트가 전부 통과하던 상태에서 크래시 경로가 나왔습니다. 텍스트에서 숫자를 뽑아 더하는, 흔한 모양이었습니다.
def to_int(s):
digits = s.replace(",", "")
return int(digits) if digits else None # ← 쉼표만 있으면 None
total = re.search(r"합계:\s*([\d,]+)", text)
extra = re.search(r"추가:\s*([\d,]+)", text)
return (to_int(total.group(1)) or 0) + (to_int(extra.group(1)) if extra else 0)
# └─ None 이면 0 으로 막힘 ─┘ └─ extra 가 있는지만 보고
# to_int 결과가 None 인지는 안 봄 → int + None
오른쪽은 정규식이 매치됐는지(if extra)만 확인하고, 거기서 뽑은 값이 실제로 숫자가 됐는지는 안 봅니다. 원본 텍스트가 지저분해서 쉼표만 잡히면 그때 터집니다. 왼쪽은 or 0으로 막혀 있어서 더 눈에 안 띕니다.
런타임에만 드러나는 유형이라 유닛 테스트로는 원리적으로 못 잡습니다. 그 입력이 테스트에 없으면 그만이니까요.
이렇게 에러 없이 조용히 지나가는 실패가 제일 위험합니다. 같은 종류를 일주일간 다섯 건 기록한 적이 있는데, 그 이야기는 할루시네이션은 에러로 오지 않습니다에 따로 적었습니다.
정직하게 덧붙이면 오탐이 50%입니다. 표본 조사 결과 진짜 버그 10%, 오늘은 안전하나 취약 35%, 오탐 50%였습니다. 전량 수정이 아니라 새 코드에서만 깨끗하게 유지하는 방식이 맞습니다.
이 블로그 코드에도 돌려봤습니다
같은 도구를 이 블로그를 만드는 파이썬 코드에 돌렸더니 20건이 나왔고, 전건을 실제 코드와 대조했습니다.
| 분류 | 건수 |
|---|---|
| 진짜 결함 | 2건 (10%) |
| 안전하나 취약 | 3건 (15%) |
| 주석 부정확 | 8건 (40%) |
| 오탐 | 7건 (35%) |
진짜 결함은 함수 하나가 값을 두 개 반환한다고 선언해놓고 실제로는 세 개를 반환하는 것이었습니다. 테스트 66개가 전부 통과했고, 그날 제가 그 함수를 직접 고치면서도 못 봤습니다. 하필 워드프레스에 글을 올리는 모듈이었습니다.
앞서 하네스 엔지니어링에서 “AI가 틀렸을 때 어디서 걸릴지를 설계한다”고 썼는데, 이것도 같은 이야기입니다.
클로드 플러그인을 인기순으로 고르면 왜 겉도나
블로거와 유튜버는 2,393개를 다 보지 않습니다. 다른 축을 씁니다 — 인기입니다.
별점을 붙여봤더니 적합도 상위권 대부분이 별 0~5개인 1인 프로젝트였습니다. 눈에 안 띄니 소개될 일도 없습니다.
- 적합도만 보면 아무도 안 쓰는 걸 고릅니다
- 인기만 보면 내 문제를 못 막는 걸 고릅니다
실제로 별 86개짜리 하나는 프로젝트 밖만 막는데 제 사고는 안에서 났습니다. 두 축을 함께 보고, 마지막은 반드시 실행해야 합니다.
시장에 답이 없는 문제도 있습니다
2,393개 중 REST API로 나가는 파괴적 호출을 막아주는 건 하나도 없었습니다. 파일을 지우는 걸 막는 플러그인은 수십 개인데 말입니다.
정작 이 블로그에서 위험했던 건 파일 삭제가 아니라 워드프레스에 API로 이미지를 지우는 작업이었습니다. 실제로 사이트 파비콘을 지울 뻔했습니다. 참조 검사가 글 본문만 보고 있었는데, 파비콘은 본문이 아니라 설정에 저장돼 있었기 때문입니다.
시장에 답이 없는 문제는 자체 해결이 정답입니다. 이걸 확인한 것도 전수 검사의 성과입니다.
정리하면
스크리닝은 후보를 놓치지 않는 데까지만 쓸 수 있습니다. 순위는 못 냅니다 — 네 가지 변형을 만들어 측정한 결과입니다.
그리고 품질은 어떤 스크리닝으로도 못 봅니다. hookify는 소개문도 README도 완벽했고 코드가 깨져 있었습니다.
덧붙이면, 이 글을 쓰면서 제 검사기에서도 결함이 하나 나왔습니다. 공식 플러그인 중 53개는 주소가 ./plugins/이름 형태라 README를 못 받아오고 있었습니다. 공식 커버리지가 80%로 커뮤니티(90%)보다 낮았습니다. README를 못 받으면 짧은 홍보문으로만 판정되니 점수가 낮게 나옵니다. 실제로 “파이썬 타입 검사”라는 조건에 pyright가 13위였는데, 고치고 나니 2위로 올라왔습니다. 신뢰도가 가장 높은 공식 플러그인이 체계적으로 불리했던 셈입니다.
결국 후보를 좁게 잡고 하나씩 열어보는 것 말고는 없습니다. 클로드 플러그인 하나당 10분이면 됩니다. 그 10분이 “막고 있다고 믿는데 안 막고 있는” 상태를 막아줍니다.
그래서 저는 무엇을 깔았나
이번 라운드에서 한 개를 깔았습니다.
claude plugin install pyright-lsp@claude-plugins-official --scope project
pip install pyright
숫자를 정확히 적어야겠네요. 2,393개를 다 써본 게 아닙니다. 실제로 손을 댄 건 이만큼입니다.
| 단계 | 개수 |
|---|---|
| 카탈로그에 있던 것 | 2,393 |
| 내 조건에 신호가 걸린 것 | 169 |
| 목적 선언부를 직접 읽은 것 | 5 |
| 소스를 받아 실행해본 것 | 4 |
| 그중 통과 | 1 |
그러니까 “2,393개 중 1개”가 아니라 “검증한 4개 중 1개”입니다. 나머지 2,389개는 나쁘다고 판정한 게 아니라 아예 열어보지도 않았습니다. 대부분 데이터베이스, 배포, 모니터링처럼 제가 지금 안 쓰는 영역이기도 하고요.
| 플러그인 | 결과 |
|---|---|
| pyright-lsp (공식) | ✅ 진짜 버그 발견 — 채택 |
| hookify (공식) | ❌ 한국어 윈도우에서 규칙 전멸 |
| safety-net (★1,462) | ❌ 제 사고 명령을 통과시킴 |
| md-linker (적합도 1위) | ❌ 오탐 80건, 진짜 발견 0건 |
그리고 이 한 개라는 숫자는 제 조건이 좁아서 나온 값입니다. 저는 “지금까지 사고 났던 것을 막아주는가”만 물었거든요. 조건을 “내가 매일 하는 일”로 바꿔서 다시 돌려보니 워드프레스 발행, 스크린샷, 검색 데이터 쪽에서 후보가 여럿 나왔습니다. 질문을 바꾸면 답도 바뀝니다.
그래서 이 글을 “쓸 만한 게 하나뿐이더라”로 읽으시면 곤란합니다. 제가 말하려는 건 “내가 던진 질문에 대해, 실행까지 시켜본 결과가 이랬다”입니다. 질문이 다르면 결과도 다를 겁니다.
파이썬을 쓰신다면 pyright는 저처럼 값을 할 가능성이 높습니다. 다만 그것도 깔고 나서 열 개쯤 결과를 직접 읽어보신 뒤에 판단하시죠. 오탐이 35%였으니까요.
직접 만든 게 있어도 플러그인을 봐야 하는 이유
저는 발행 파이프라인을 파이썬으로 직접 만들어 씁니다. 그래서 처음엔 “내가 만든 게 있는데 플러그인이 왜 필요하지?” 싶었습니다.
갈리는 기준은 하나였습니다. 내 도메인 지식이 들어가는가.
발행 파이프라인은 제 규칙 덩어리입니다. 어떤 검수를 통과해야 올라가는지, 그림 경로 관례가 뭔지, 라이브 글을 어떻게 보호하는지 — 남이 만든 걸로 대체할 수 없습니다. 실제로 워드프레스 발행 플러그인을 하나 검증해봤는데, 제 업로더가 이미 하는 일에 백업과 그림 소실 방지가 빠져 있었습니다.
반대로 타입 검사나 검색 실적 조회는 누가 만들어도 같습니다. 제가 파이썬 타입 검사기를 새로 만들 이유가 없죠. 여기선 플러그인이 압도적으로 낫습니다.
그래서 답은 “둘 중 하나”가 아니라 “경계를 어디에 긋느냐”였습니다. 내 판단이 들어가는 자리는 직접 만들고, 표준화된 일은 가져다 씁니다.
클로드 플러그인을 처음 붙여보신다면 클로드 코드가 무엇인지부터 보시면 순서가 자연스럽습니다.
수치는 2026년 7월 28일 기준입니다. 공식 276개와 커뮤니티 2,283개에서 중복을 뺀 2,393개이며, 마켓은 계속 늘고 있습니다. 검사 당시엔 공식이 257개였습니다.
