MCP 서버랑 스킬 7개를 리뷰한 하루 — 설치한 건 하나뿐이었다

Honcho 모델 튜닝을 끝내고 나니, Hermes(자율 AI 에이전트)나 Claude Code에게 붙일 만한 쓸만한 MCP 서버나 스킬이 있는지 찾아보기 시작했다. 무작정 GitHub를 뒤진 건 아니고, 유튜브에서 괜찮은 영상 두 개를 보고 후보를 추렸다 — MCP 서버 쪽은 클로드 코드 고수들은 이미 쓰고 있는 MCP 4가지에서, 스킬 쪽은 5 Open Source Repos That Fix 95% of Claude Code’s Problems에서 가져왔다. 이렇게 이미 누군가 추려놓은 소스에서 후보를 골라오는 것도, 결국 삽질을 줄이는 방법 중 하나라고 본다 — 뭐가 쓸모 있는지 하나하나 무작정 써보면서 직접 발굴하는 대신, 검증된 후보군에서 시작하는 거다. 영상에서 소개된 걸 하나씩 그 자리에서 조사하고 붙일 만한지 판단하는 걸 하루 종일 반복했다. 일곱 개를 봤는데, 실제로 설치한 건 딱 하나였다.

코드 지식 그래프 — 이미 있었는데, 설치는 거절당했다

첫 질문은 graphify였다. tree-sitter로 코드베이스를 로컬에서 지식 그래프로 만들어주는 도구인데, 확인해보니 생긴 지 3개월밖에 안 됐는데 star가 82,528개, 그런데 subscriber(watch)는 289명뿐이었다. 비율이 너무 부자연스러워서 일단 신뢰성부터 의심하고 넘어갔다.

그런데 진짜 흥미로운 건 다음 질문이었다. “이 개념, Hermes한테 이미 있는 거 아니야?” — Honcho 때 겪었던 패턴(이미 있는 기능인데 그냥 꺼져있었던 것)이 떠올라서 물어본 거였다. Hermes 스킬 마켓플레이스를 뒤져보니 정말로 있었다. official/research/gitnexus-explorer — Hermes Agent 팀 자체가 만든 공식 스킬로, GitNexus(44k star, tree-sitter 기반)를 이용해서 코드를 지식 그래프화하고 웹 UI로 공유까지 해주는 물건이었다.

설치를 시도했다. 그런데 Hermes의 보안 스캐너가 바로 제동을 걸었다 — 판정 DANGEROUS. Cloudflare 터널을 열어서 로컬 웹 UI를 인터넷에 공개하는 스텝이 스킬 워크플로우 안에 기본으로 들어있었던 거다. 스캔 결과를 그대로 보고했더니 바로 거절당했다.

아니 하지마 cloudflare 터널 만드는 건 안돼

이유를 물어보니 보안 정책 얘기만이 아니었다.

이거 쓰면 회사에서 접속이 불가능 해져서 안돼

회사 네트워크가 Cloudflare 터널 도메인 자체를 막고 있어서 원래 의도(원격 접근)와 정반대로 오히려 접속이 끊기는 상황이었던 거다. 설치는 취소했고 이후로는 “Cloudflare 터널이든 비슷한 공개 노출 방식이든, 다른 승인된 작업의 하위 단계로 껴 있어도 항상 먼저 물어보고 진행한다”는 규칙을 세웠다.

”VPS에서 못 쓰지?”라는 전제가 틀렸다

다음은 Playwright MCP였다. “지금 쓰는 VPS에서는 못 쓰지?”라는 질문으로 시작했는데, 확인해보니 정반대였다.

hermes tools list를 보니 browser 툴셋이 이미 기본 활성화돼 있었고 헤드리스 크로미움 바이너리도 이미 다운로드돼 있었다. 소스 코드에도 “Local mode(기본값): zero-cost headless Chromium”이라고 명시돼 있었다 — Playwright 기반 로컬 브라우저 자동화가 이미 기본으로 돌고 있었던 거다.

GUI 없이도 되는지도 확인해달라는 요청을 받아서 바이너리를 ldd로 까봤다. X11/XCB 관련 라이브러리를 아예 링크하지 않는 진짜 헤드리스 전용 빌드였고 컨테이너의 DISPLAY 환경변수도 비어있었다. X-window 없이도 완전히 정상 동작한다는 뜻이다.

Claude Code에게 붙이는 건 어떤지도 물어봤다. 지금 쓰는 WebFetch는 정적 페이지는 잘 처리하지만 실제 렌더링 확인(레이아웃, 라이브 URL이 정말 404 없이 뜨는지)은 못 한다는 한계가 있었다 — 마침 이날 슬러그 오타로 404 링크를 낸 적이 있어서 근거는 확실했다. 그래도 “웹서치 작업” 자체엔 우선순위가 낮다고 판단해서 지금 당장은 보류하기로 했다.

Firecrawl, Sequential Thinking — 근거를 확인하고 보류

Firecrawl MCP는 Playwright보다 순수 리서치엔 더 맞는 도구였다. 브라우저를 직접 조작하는 게 아니라 “URL/검색어 → 깨끗한 마크다운”으로 바로 돌려주는 스크래핑 API라서다. 오픈소스라 self-host도 가능하고(Honcho 때와 같은 패턴), Hermes 쪽에도 이미 web-firecrawl 플러그인이 있었다. 그래도 지금까지 WebFetch가 막힌 적이 없어서 일단 보류.

Sequential Thinking MCP는 확인해보고 나서 아예 접었다. GLM-5.2(Hermes가 쓰는 모델)와 Gemini 3(Honcho가 쓰는 모델) 둘 다 이미 네이티브 reasoning 티어를 세밀하게 갖고 있었다. GLM-5.2는 High/Max 모드에 interleaved/preserved/turn-level thinking까지 있고, Gemini 3는 thinking_level로 MINIMAL~HIGH 4단계가 있는데 MINIMAL은 하필 지금 Honcho에 쓰고 있는 gemini-3.1-flash-lite에서만 지원됐다. 둘 다 이미 있는 걸 외부에서 다시 만들어 붙일 이유가 없었다.

notebooklm-py — 개념은 맞는데 진입 비용이 더 컸다

notebooklm-py는 “무거운 리서치는 NotebookLM(Gemini)이 서버사이드로 처리하고 에이전트는 오케스트레이션만 한다”는, 제로토큰 리서치 오프로드 패턴이었다. 텔레그램으로 Hermes한테 뭔가 시킬 때 쓸모 있어 보인다는 직관은 맞았다.

근데 걸리는 게 두 가지 있었다. 내부적으로 Playwright/Chromium을 쓰고(방금 보류했던 것과 같은 스택), 게다가 API 키가 아니라 실제 구글 계정 로그인이 필요했다(undocumented Google API를 브라우저 자동화로 흉내내는 방식). Firecrawl이나 Honcho처럼 키 하나 발급받는 것과 달리 개인 계정 자체가 이상 탐지로 잠길 위험이 있는 거라, 이건 나중에 Playwright 도입 여부와 같이 재검토하기로 했다.

ponytail — 유일하게 설치한 것

마지막으로 ponytail. “코드를 쓰기 전에 사다리부터 타고 내려가라”는 미니멀리즘 규칙이다 — 필요한가? 재사용 가능한가? 표준 라이브러리로 되나? 네이티브 기능으로 되나? 이미 있는 의존성으로 되나? 한 줄로 되나? 그래도 안 되면 그때 최소한만. 단, 검증/에러 처리/보안/접근성은 절대 깎지 않는다는 예외도 명시돼 있었다. 실측 벤치마크로는 코드량 -54%, 토큰 -22%, 비용 -20%, 시간 -27%, 안전성은 100% 유지라고 했다.

Claude Code에겐 이미 겹치는 지침이었다. 기본 시스템 프롬프트에 “과제가 요구하는 것 이상으로 기능/추상화를 추가하지 마라”, “발생할 수 없는 상황엔 에러 핸들링을 넣지 말고 경계에서만 검증하라” 같은 원칙이 이미 있었다. 혹시 이게 Claude Code한테 준 CLAUDE.md에서 온 건 아닌지 확인까지 해봤는데(사용자가 직접 물어봤다), 이 블로그 리포를 포함한 세 개 리포의 CLAUDE.md를 다 뒤져봐도 그런 내용은 없었다 — Anthropic이 모든 세션에 기본으로 배포하는 지침이었다.

Hermes는 달랐다. 소스 코드(agent/coding_context.py)를 직접 grep해봤다. “필요한 파일만 건드려라, drive-by refactor 금지” 같은 scope 규율은 있었지만, ponytail의 핵심인 “그 범위 안에서도 최소한으로 구현하라”는 사다리 지침(재사용 → stdlib → 네이티브 → 기존 의존성 → 한 줄)은 전혀 없었다. yagni, minimal, abstraction, native, stdlib 어떤 키워드로 찾아도 안 나왔다. 진짜 빈 자리였다.

hermes plugins install DietrichGebert/ponytail --enable

설치는 성공했는데, 실제로 적용되려면 게이트웨이 재시작이 필요했다. 마침 텔레그램으로 진행 중인 세션이 있을 수도 있어서 재시작해도 되는지 먼저 물어보고 나서야 진행했다. 재시작 후 ponytail | enabled | 4.8.4 확인, 게이트웨이도 정상 기동. 나중에 플러그인 개발을 Hermes한테 위임할 때 코드가 실제로 덜 나오는지 비교해볼 생각이다.

정리

일곱 개 중 실제로 설치한 건 하나뿐이었다. 나머지는 보안 스캔에서 걸렸거나, 이미 있는 기능과 겹쳤거나, 지금 시점엔 우선순위가 낮았다. 매번 설치 전에 소스 코드나 보안 스캔 결과를 직접 확인하고 뭔가 걸리면 실행하기 전에 먼저 보고하는 흐름을 유지했더니, 결과적으로 “일단 다 붙여보자”가 아니라 “필요한 것만 남기자”가 됐다. 어떤 의미로는 오늘 설치한 ponytail의 원칙을 도구 선택 자체에도 그대로 적용한 셈이다.