소셜 미디어에서 뭔가를 보면 일단 저장부터 한다. 나중에 쓸 것 같아서. 근데 나중이 오는 경우는 드물다.
이번엔 달랐다. 인스타그램 어딘가에서 AI 에이전트 도구 소개 카드를 봤고, 그냥 넘기지 않았다. 스크린샷을 찍어서 Claude Code한테 바로 물어봤다.
AI 에이전트 도구 7개, 먼저 검증했던 이유
처음엔 3개였다. claude-mem, find-skills, VibeSec. 캡처한 카드를 Claude Code에 던지면서 물었다.
“지금 설치돼 있어? 설치하면 나한테 좋아? 아니면 없어도 돼?”
그냥 좋아 보인다고 깔면 안 된다는 걸 안다. 도구는 내 상황에 맞아야 쓸 수 있다. 맞지 않는 도구는 설치하는 순간부터 짐이 된다. 그래서 먼저 확인했다.
확인 과정에서 ponytail, graphify, Ruflo, OmniRoute까지 추가로 검토하게 됐다. 결국 7개를 다 들여다봤다.
이미 깔려있던 도구들 (claude-mem, find-skills, ponytail, graphify)
결과부터 말하면, 4개는 이미 있었다.
claude-mem은 8월 28일부터 설치돼 있었다. find-skills도 이미 스킬로 등록된 상태였다. 몰랐다. 쓰고 있었는데 쓰고 있는 줄 몰랐던 거다.
ponytail은 좀 달랐다. 설치돼 있는 수준이 아니었다. 그 대화를 하는 내내 실제로 켜져서 작동하고 있었다. 이걸 확인하면서 뭔가 이해됐다. Claude Code가 항상 최소한의 코드로 답하던 게 이상하다고 생각한 적 있었는데, 그게 ponytail 때문이었다. 도구가 조용히 일하고 있었던 거다.
graphify도 전역 설정(어떤 프로젝트에서도 공통으로 적용되는 설정)에 등록돼 있어서 언제든 쓸 수 있는 상태였다. fire-your-seo-agency 스킬을 블로그 4개에 자동 적용했을 때도 비슷한 걸 느꼈다 — 이미 깔린 걸 제대로 아는 게, 새로 까는 것보다 먼저다.
이 네 개는 새로 깔 필요가 없었다. 이미 있으니까.
VibeSec을 안 깐 이유: 내 프로젝트 구조와 안 맞았다
VibeSec은 웹 취약점(XSS, SQL 인젝션 같은 것)을 잡아주는 보안 도구다.
XSS(Cross-Site Scripting)는 악성 스크립트를 웹페이지에 심는 공격이고, SQL 인젝션은 데이터베이스 쿼리를 조작하는 공격이다. 로그인 폼, 검색창, 결제 입력칸 같은 데서 주로 생긴다.
내 프로젝트엔 그런 게 없다. 지금 만드는 건 블로그 자동 생성 스크립트들이다. 사용자 입력을 받는 곳이 없다. 로그인도 없고 결제도 없다. 워드프레스 인증은 앱 비밀번호를 .env.local 파일(환경 변수를 저장하는 파일, 코드에 직접 비밀번호를 적지 않기 위해 사용)에 넣어서 쓰는 정도다.
VibeSec이 잡아줄 취약점 자체가 생길 구조가 아니었다. 좋은 도구지만 내 상황엔 맞지 않는다. 그래서 안 깔았다.
Ruflo, OmniRoute가 과했던 이유
Ruflo는 스웜 오케스트레이션(swarm orchestration, 여러 AI 에이전트를 동시에 무리 지어 운영하는 방식) 프레임워크다.
근데 확인해보니 사실 claude-flow라는 기존 프로젝트를 이름만 바꾼 거였다. 버전이 385개나 찍혀 있었다. 60개 넘는 에이전트를 동시에 굴리는 구조인데, 내 작업은 프로젝트마다 4~5개 역할이 정해진 순서대로 도는 방식이다. Ruflo가 필요한 상황이 아니었다. 이름을 바꿨다고 다른 도구가 되는 건 아니다.
OmniRoute는 다른 방향에서 과했다. 여러 AI 제공사(OpenAI, 앤트로픽 같은 곳)를 하나로 묶어서 무료 할당량을 다 쓰면 자동으로 다른 모델로 넘어가는 게이트웨이(gateway, 여러 서비스를 하나로 연결하는 중간 통로)다.
아이디어는 나쁘지 않다. 하지만 내 파이프라인 전체가 Claude 하나 기준으로 맞춰져 있다. 말투 스킬도, AI 패턴 차단 규칙도 전부 Claude 기준이다. 여기에 다른 모델을 섞으면 그동안 다듬어온 것들이 다 어긋날 수 있다. 거기다 요청이 게이트웨이를 하나 더 거치게 된다는 것도 마음에 걸렸다. 중간에 거치는 단계가 하나 늘어날 때마다 뭔가 꼬일 가능성도 하나씩 늘어난다.
13만 개 별을 의심하고 다시 확인한 검증 과정
ponytail 별(star, GitHub에서 사용자들이 좋은 프로젝트에 누르는 즐겨찾기 같은 것)이 13만 개, graphify가 11만 개라고 나왔다.
이 숫자가 이상했다. 13만 개면 엄청난 숫자다. 유명한 오픈소스 프로젝트 수준이다. AI가 그냥 그럴듯하게 숫자를 지어냈을 수 있다고 생각했다. AI가 할루시네이션을 일으키는 건 알려진 사실이다.
그래서 GitHub API(Application Programming Interface, 프로그램끼리 데이터를 주고받는 통로)로 직접 다시 확인해달라고 했다. 결과는 같은 숫자였다. 진짜였다.
의심했다. 확인했다. 믿었다. 이 순서가 맞다. 실제로 ponytail 저장소에 들어가면 지금도 그 별점을 직접 확인할 수 있다.
AI가 말하는 숫자나 사실은 한 번쯤 다시 확인해야 한다. 귀찮더라도 그렇게 해야 한다. 이번엔 맞았지만, 다음에도 맞다는 보장은 없다.
하나도 안 깐 게 오히려 정답인 이유
7개를 다 봤다. 하나도 안 깔았다.
처음엔 뭔가 하나쯤은 새로 깔아야 할 것 같았다. 7개를 다 확인해봤는데 결과물이 없으면 시간 낭비처럼 느껴질 것 같았다. 근데 하나씩 따져보면서 생각이 바뀌었다.
이미 있는 건 이미 있는 거다. 없는 건 지금 내 상황에 안 맞았다. 새로 깐 게 없다는 게 실패가 아니라, 지금 쓰는 구조가 이미 내 상황에 맞게 다듬어져 있다는 확인이었다.
뭔가를 안 하기로 결정하는 것도 결정이다. 그리고 그 결정을 내리려면 일단 확인은 해봐야 한다. 소개 카드만 보고 “좋아 보이네” 하고 깔았으면 지금 내 환경에 안 맞는 도구들이 3~4개쯤 더 쌓여 있었을 거다.
다음엔 지금 이미 깔려 있는 도구들을 제대로 들여다볼 생각이다. ponytail이 그 대화 내내 켜져 있었다는 걸 이번에 처음 알았다. 모르고 쓰고 있는 게 또 있을 거다.
버전이 안 맞아서 CLI가 아예 안 됐던 사례는 데몬 버전 불일치로 CLI가 안 됐던 이야기 (v1.8.7→1.8.8)에 정리했다.
