클로드 코드를 쓴 지 1년 조금 넘었습니다. 그동안 좋다는 스킬이나 플러그인이 보이면 일단 깔았죠. 어느 날 설정 폴더를 열어보니 에이전트만 156개가 있더라고요. 제가 실제로 불러본 건 8종이었고요.
그래서 하루 날 잡고 정리했습니다. 5월에 쓴 내가 바이브 코딩하는 방법이 레포 구조랑 검증 루프 얘기였다면, 이번 글은 도구 얘기입니다. 뭘 남겼고 왜 남겼는지요.
1. 먼저 내가 어떻게 쓰는지부터 봤다
뭘 깔지 고르기 전에 제 사용 기록부터 뽑아봤습니다. 8월부터 쓴 세션이 254개, 제가 보낸 메시지가 2,830개였습니다.
메시지 길이 중간값 32자
"커밋·PR" 요청 약 260번
"배포" 요청 약 130번
"모바일 확인" 관련 100번 넘게
설명 문구 지워달라는 말 70번 넘게
욕 약 60번
생각보다 짧게 던지고 있었습니다. 스크린샷 한 장에 "여기도 그래" 같은 걸 붙여서 화면을 보며 고치는 식이었고요. 디자인은 시안 하나보다 "스타일 다르게 5개 만들어봐"라고 해서 고르는 걸 좋아했습니다. 방향이 정해지면 "알아서 해"로 넘기고요.
같은 지적을 반복하고 있다는 게 제일 눈에 띄었습니다. 헤드라인 밑에 쓸데없는 설명 문구 넣지 마, 모바일에서 넘치잖아, 다른 페이지도 같이 고쳐. 이런 말을 프로젝트마다 계속 하고 있었습니다. 욕 60번도 대부분 이때 나왔습니다. 처음 말할 땐 괜찮은데, 같은 걸 두 번째 세 번째 말할 때 터지더라고요.
이건 스킬이 부족해서 생긴 문제가 아니었습니다. AI가 지난번에 들은 걸 기억하지 못해서 생긴 문제였죠. 그래서 방향을 정했습니다. 스킬은 덜 깔고 기억할 곳을 만들기로요.
2. 뺀 것
에이전트 156개는 3개만 남겼습니다. Code Reviewer, Frontend Developer, Security Engineer.
안 쓰는 에이전트도 공짜가 아닙니다. 스킬이나 에이전트는 본문은 필요할 때만 읽히지만 이름이랑 설명은 모든 세션에 올라갑니다. 모델이 그 목록을 보고 뭘 쓸지 정하기 때문이죠. 제 경우엔 에이전트 설명만 3만 5천 자였습니다.
그 밖에도 이런 걸 걷어냈고요.
- 한 번도 안 쓴 MCP 서버
- 인증이 풀려서 매번 연결에 실패하던 MCP
- 같은 도구를 두 번 올리던 중복 플러그인
- 이제 안 쓰는 앱이 도구 호출마다 실행하던 훅
마지막 건 정리하다가 처음 알았습니다. 예전에 깔았던 앱이 클로드 코드의 모든 도구 호출 앞뒤에 훅을 걸어두고 있었거든요.
3. 남긴 것
지금 전역에 깔린 건 이게 전부입니다.
| 이름 | 하는 일 |
|---|---|
| superpowers | 기획, 스펙, 계획, 실행, 리뷰 흐름. 스펙이랑 계획을 문서로 남깁니다 |
| ponytail | 코드를 최소한으로 쓰게 하고, 과설계를 막아줍니다 |
| impeccable | AI 티 나는 디자인이랑 장식, 문구를 잡아냅니다 |
| typescript-lsp | 타입 오류랑 정의 위치를 정확히 보게 해주고요 |
| humanize-korean | AI 티 나는 한글 문장을 다듬습니다. 이 글도 한 번 돌렸어요 |
| second-brain | 제 옵시디언 볼트를 읽고 쓰는, 직접 만든 스킬입니다 |
superpowers는 사실 한 번 뺐다가 다시 넣었죠.
뺀 이유는 느려서입니다. 계획을 다 세우면 서브에이전트가 작업마다 따로 돌면서 리뷰까지 하는데 이게 정말 오래 걸렸습니다. 요즘은 클로드 코드에 plan mode도 있고 서브에이전트도 기본으로 있으니까 없어도 되겠다 싶었고요.
그런데 프로젝트 폴더를 열어보니 superpowers가 남긴 스펙이랑 계획 문서가 51개 있었습니다. 제가 제일 많이 쓰던 건 브레인스토밍 스킬이 아니라 그게 남기는 문서였던 거죠. 다른 기획 스킬로 바꿔보려 했는데, 그쪽은 용어집이랑 결정 기록만 남기고 스펙은 안 쓰더라고요.
그래서 다시 넣었습니다. 느린 문제는 실행할 때 서브에이전트 방식 대신 현재 세션에서 바로 실행하는 inline을 고르면 해결됩니다.
ponytail이랑 superpowers는 철학이 조금 부딪힙니다. 하나는 절차를 밟으라고 하고 하나는 가장 짧은 길로 가라고 하거든요. 그래도 역할을 나누면 괜찮은 것 같아요. superpowers는 코드 쓰기 전후를, ponytail은 코드 쓰는 순간을 맡는 식으로요.
4. 작업 크기에 따라 다르게 간다
모든 작업에 같은 절차를 밟으면 느립니다. 그래서 크기별로 나눴죠.
| 크기 | 예시 | 흐름 |
|---|---|---|
| 작음 | 버그, 문구, 간격 | 바로 요청하고 브라우저로 확인 |
| 중간 | 페이지나 기능 하나 | plan mode로 계획, 구현, 확인, /code-review |
| 큼 | 뭘 만들지 애매한 기능 | 브레인스토밍, 스펙 문서, 계획 문서, inline 실행 |
자주 쓰는 건 이 정도입니다.
/code-review 기능 하나 끝났을 때
/simplify 중복 정리
/ponytail-review 코드가 부풀었다 싶을 때
/impeccable audit UI 만들고 나서
/security-review 배포 전
5. 규칙은 전역이 아니라 프로젝트에
처음엔 전역 CLAUDE.md에 제 취향을 다 넣으려고 했습니다. 설명 문구 넣지 마, 모바일 확인해, 커밋은 시킬 때만 해. 그런데 쓰다 보니 거의 다 빠졌습니다.
프로젝트마다 다르더라고요. 개인 블로그는 흰 배경에 모노톤인데, 게임 프로젝트는 검은 배경입니다. 어떤 저장소는 master에 바로 올리고 팀 저장소는 PR을 거칩니다. "코드 수정하지 말고 얘기부터"도 바로 고쳐야 할 때가 있고요. 확정적인 규칙을 전역에 넣으면 오히려 방해가 됐죠.
그래서 전역 CLAUDE.md는 지웠습니다. 대신 어디에 뭘 적을지만 정해뒀습니다.
| 무엇 | 어디 |
|---|---|
| 매번 알아야 하는 사실 (스택, 명령어, 배포 대상) | 프로젝트 CLAUDE.md |
| 가끔 하는 여러 단계 절차 (배포, 커밋과 PR) | 프로젝트 스킬 |
| 무조건 매번 돌아야 하는 것 (포맷, 타입체크) | 프로젝트 훅 |
스킬은 미리 만들지 않습니다. 같은 절차를 두 번째 설명하고 있을 때 만들죠. 배포 스킬도 프로젝트마다 따로 둡니다. 어떤 건 제 VM에 올리고 어떤 건 Vercel이라서요. Vercel은 push가 곧 배포라 스킬이 필요 없기도 하고요.
Next.js 프로젝트면 CLAUDE.md에 @AGENTS.md 한 줄을 넣습니다. Next.js 16.2부터는 설치한 버전에 맞는 문서가 패키지 안에 같이 들어오는데 AGENTS.md가 그 문서를 먼저 읽으라고 알려줍니다. Vercel이 직접 비교해 보니 이 방식은 100%, 스킬로 문서를 찾게 한 방식은 79%였다고 합니다. 필요할 때 찾아 읽게 하는 것보다 항상 들어가 있게 하는 게 나았던 거죠.
6. 기억은 옵시디언에 맡긴다
1번에서 말한 반복 지적 문제는 결국 기억할 곳이 필요했습니다. 저는 원래 옵시디언을 쓰고 있어서 거기에 맡겼죠.
second-brain이라는 스킬을 하나 만들었습니다. 어느 프로젝트에서 작업하든 이렇게 말하면 제 볼트를 다룹니다.
"이거 세컨드 브레인에 기록해" → Inbox에 저장
"클로드 코드 세팅 어떻게 했더라?" → 노트를 찾아서 답해줌
"이번 주 Daily 보고 회고해줘"
"프로젝트 세팅해줘" → 볼트의 체크리스트대로 세팅
이 글에 쓴 세팅도 전부 볼트에 노트로 있습니다. 까먹었을 때 다시 조사시키면 토큰이 또 드는데 노트를 읽게 하면 한 번이면 되죠. 클로드 코드랑 코덱스를 같이 쓰는데 스킬 파일은 둘 다 똑같이 읽더라고요.
볼트 구조는 Karpathy의 LLM 위키에서 아이디어를 가져왔습니다. 사람은 대충 던지고 묻기만 하고 분류랑 정리는 AI가 합니다.
정리
1. 깔기 전에 내 사용 기록부터 본다
2. 안 쓰는 건 뺀다. 목록에 있는 것만으로도 컨텍스트를 먹는다
3. 작업 크기에 따라 절차를 다르게 간다
4. 규칙은 전역이 아니라 프로젝트에 둔다
5. 스킬은 같은 설명을 두 번째 할 때 만든다
6. 기억은 노트에 맡긴다
좋다는 도구를 다 깔아보고 느낀 건, 도구 개수가 결과를 바꾸진 않는다는 겁니다. 제가 뭘 반복하는지 알고 그걸 어디에 적어둘지 정하는 게 더 컸습니다.