요약 팀에서 사용하는 Claude Code 스킬의 실제 사용량과 사용 패턴을 확인하기 위해 간단한 모니터링 시스템을 만든 과정을 정리합니다.
공용 스킬 레포에서 각 프론트엔드 레포로 자동 동기화되는 기존 구조를 활용해, 어떤 스킬이 얼마나 호출되는지와 어떤 옵션·입력 형태로 사용되는지를 Google Sheet에 집계했습니다.

목차

• 클로드 스킬 모니터링을 생각하게 된 계기
• 모니터링의 기반이 된 스킬 중앙화 구조
• 호출 횟수만 모아서는 부족했던 이유
• 무엇을 모을지 정의하기
  • 실제 인자 값은 저장하지 않는다
• 전체 아키텍처와 흐름
• 불필요한 일반 프롬프트 걸러내기
• 시트는 세 가지 관점으로 구성했다
  • 개인 탭
  • 스킬목록 탭
  • 종합 탭
• 실제로 확인할 수 있었던 것
• 셋업(설정)은 최소한으로 유지하기.
• 결국 필요했던 건 숫자가 아닌 ‘판단 근거’
  • 참고자료 (모니터링 전체 플로우)

클로드 스킬 모니터링을 생각하게 된 계기

개발 과정에서 AI 활용도가 높아지면서, 자연스럽게 반복되는 일련의 작업들을 하나의 ‘업무 단위’로 묶어두는 경우가 많아졌습니다.

Claude Code에서 스킬(Skill)이란 특정 작업 흐름—예를 들어 코드 리뷰, 커밋 및 배포 준비, 특정 문서 템플릿 생성 등—을 프롬프트와 스크립트로 묶어 명령어 한 줄(/skill-name)로 실행할 수 있게 만든 일종의 자동화 도구입니다. 매번 긴 지시사항을 프롬프트로 타이핑하는 대신, 팀의 컨벤션과 작업 절차를 캡슐화해 둔 셈입니다.

이렇게 생산성을 높이기 위해 스킬을 하나둘씩 추가하다 보니, 어느 순간 어떤 스킬이 실제로 유용하게 쓰이고 있는지 전혀 알 수 없는 문제가 생겼습니다.

공용 폴더에는 스킬이 계속 쌓여가는데 정작 제가 자주 쓰는 건 손에 꼽을 정도였습니다. 그렇다고 제가 안 쓴다는 이유만으로 지울 수도 없었습니다. 다른 팀원은 매일 유용하게 쓰고 있을지도 모르니까요.

반대로 제가 잘 모르는 스킬이 팀 안에서 활발하게 쓰이고 있다면, 다른 팀원들은 그걸 어떤 옵션이나 입력값과 함께 쓰는지도 궁금했습니다. 그런 실제 활용 방식을 알아야 제 작업 흐름에도 자연스럽게 녹여낼 수 있기 때문입니다.

결국 스킬을 계속 유지할지, 인터페이스를 다듬을지, 아니면 과감히 지울지를 결정하려면 최소한의 데이터가 필요하다고 판단해 Claude Code의 스킬 사용 기록을 Google Sheet에 모아보기로 했습니다.

목표는 단순했습니다.

• 어떤 스킬이 자주 쓰이고, 어떤 스킬이 방치되어 있는지
• 팀원마다 주로 어떤 스킬을 어떤 방식으로 활용하는지
• 같은 스킬이라도 어떤 옵션과 입력 형태로 사용하는지

모니터링의 기반이 된 스킬 중앙화 구조

마침 저희 팀은 Claude 스킬을 각 프로젝트에서 따로 관리하지 않고, 스킬 전용 공용 레포지토리를 통해 중앙에서 관리하고 있었습니다.

새로운 스킬이 공용 레포의 main 브랜치에 머지되면, GitHub Actions 동기화 워크플로우를 타고 각 프론트엔드 개발 레포의 develop 브랜치로 자동 반영되는 구조였습니다.

이렇게 각 프론트엔드 레포마다 .claude/skills 폴더가 동기화되어 개발자들에게 제공되고 있었기에, 사용량을 집계할 때도 별도의 스킬 등록 시스템을 만들 필요가 없었습니다.

공용 스킬 레포가 전체 스킬의 기준이 되고 각 개발 레포의 .claude/skills는 현재 배포된 스킬 목록을 그대로 보여주다 보니, 호출된 스킬뿐만 아니라 배포는 되어 있지만 한 번도 호출되지 않은 스킬까지 자연스럽게 추적할 수 있었습니다.

호출 횟수만 모아서는 부족했던 이유

처음에는 단순히 스킬별 호출 횟수만 누적하면 충분할 것이라 생각했습니다.
예를 들어 /ship이 한 달 동안 30번 호출되었다면 아래와 같이 나타내는 방식입니다.

1
2026-08  ship  30

하지만 이 방식에는 한 번도 사용되지 않은 스킬은 아예 호출 로그 자체가 생기지 않는다는 문제점이 있었습니다.

만약 배포된 스킬이 ship, senior-review, old-skill 세 가지인데, 실제 사용 기록에 ship 30회, senior-review 12회만 찍힌다면 호출 데이터만으로는 old-skill이 배포되어 있는데 0회 사용된 건지, 아니면 아예 없는 스킬인지 구분할 수가 없습니다. 정작 가장 먼저 찾아내야 할 삭제 후보 스킬이 데이터에서 완전히 증발해 버리는 셈입니다.

그래서 호출 기록과 별개로 현재 배포된 스킬 목록 자체를 함께 수집하기로 했습니다.

훅(Hook)이 실행될 때 현재 레포의 .claude/skills 폴더를 읽어 배포된 스킬 이름 목록을 함께 전송하도록 만들었고, 덕분에 사람이 수동으로 목록을 관리하지 않아도 호출 기록을 통해 사용량을 확인하는 동시에 스킬 목록을 통해 방치된 스킬까지 명확히 짚어낼 수 있게 되었습니다.

무엇을 모을지 정의하기

시스템에 필요한 데이터는 목적에 맞게 핵심만 추렸습니다.

여기서 호출 횟수뿐만 아니라 인자의 형태까지 눈여겨본 이유는, 같은 스킬이라도 팀원들이 어떤 맥락으로 쓰고 있는지 알고 싶었기 때문입니다.

예를 들어 /ship이 30번 쓰였는데 그중 25번이 mode:commit 형태였다면,

1
/ship commit

매번 commit을 타이핑하게 두는 대신 기본 동작으로 지정해 주는 편이 훨씬 효율적입니다.

또한 /senior-review를 호출할 때 단일 파일 경로(src/app/page.tsx)를 넣는지, Git range(HEAD~3..HEAD)를 주로 넣는지에 따라서도 팀의 주된 워크플로우를 파악할 수 있습니다. 이런 맥락은 단순 호출 수치만으로는 절대 알 수 없는 귀중한 힌트가 됩니다.

실제 인자 값은 저장하지 않는다

다만 인자 패턴을 수집하더라도 사용자가 입력한 실제 값을 그대로 저장하지는 않았습니다.

처음에는 /ship --draft처럼 정형화된 플래그만 들어올 거라 생각했지만, 실제 사용 흐름을 살펴보니 커맨드 뒤에 이전 작업 결과나 API 응답 JSON, 심지어 민감한 도메인 텍스트를 그대로 붙여 넣는 경우가 종종 있었기 때문입니다.

이런 원문을 그대로 수집해 팀 공용 시트에 남기면 보안상 위험할 수밖에 없습니다.
그래서 실제 값은 과감히 버리고, 어떤 형태의 인자가 들어왔는지만 남기도록 전처리했습니다.

플래그처럼 스킬에 미리 정의된 값은 그대로 남기고, 첫 번째 인자로 오는 짧은 소문자는 서브커맨드로 보아 mode:로 기록했습니다. 나머지 가변적인 값들은 실제 내용을 보지 않아도 흐름을 알 수 있도록 path, range, word, text 등으로 분류해 마스킹했습니다.

어떤 파일이나 브랜치를 다루었는지는 가려지지만, “경로를 넣어서 쓰는지”, “어떤 모드를 주로 쓰는지” 같은 유의미한 사용 패턴은 안전하면서도 온전하게 챙길 수 있었습니다.

전체 아키텍처와 흐름

구조는 세 부분으로 가볍게 나뉩니다.

Claude Code의 Hook이 스킬 사용 시점을 감지하면, 셸 스크립트가 필요한 정보만 안전하게 추려 Apps Script로 보내고, Apps Script가 전달받은 값을 Google Sheet에 누적 집계하는 흐름입니다.

스킬 호출은 두 경로에서 잡았습니다.

사용자가 /ship처럼 직접 slash command를 입력할 때는 UserPromptSubmit이 실행되고, Claude가 대화 맥락 속에서 자율적으로 Skill tool을 호출할 때는 PostToolUse가 실행됩니다.

하나의 작업에서 두 이벤트가 연달아 잡히는 경우를 대비해, 서버단에서는 같은 세션 안에서 동일한 스킬이 20초 안에 연이어 들어오면 1회 호출로 합치도록 처리했습니다. 초단위의 정밀한 이벤트 추적보다는 전체적인 사용량 집계가 목적이었기에 이 정도로도 충분히 정확했습니다.

불필요한 일반 프롬프트 걸러내기

UserPromptSubmit은 “이 코드 왜 에러 나?” 같은 일반적인 대화를 입력할 때도 매번 실행됩니다.

하지만 모니터링이 필요한 건 오직 스킬 사용 기록뿐이므로, 스크립트가 실행되자마자 가장 먼저 slash command 형태인지 확인하고 아니라면 즉시 종료합니다.

slash command 형태라 하더라도 현재 레포의 .claude/skills 폴더에 실제로 존재하는 스킬인지 한 번 더 대조합니다. 이 덕분에 /clear나 /model 같은 Claude Code 내장 명령어는 물론 외부 플러그인 커맨드까지 자연스럽게 걸러져, 오직 공용 레포에서 동기화된 사내 공식 스킬만 깔끔하게 집계됩니다.

시트는 세 가지 관점으로 구성했다

데이터를 모은 뒤에는 크게 세 종류의 탭으로 나눴습니다.

개인 탭

팀원마다 시트가 하나씩 주어지며, 스킬별 월간 사용량과 세부 사용 방식을 보여줍니다.

1
2
3
4
5
6
month    skill          params        count
2026-08  ship           (전체)          30
2026-08  ship           mode:commit     25
2026-08  ship           --draft          6
2026-08  senior-review  (전체)          12
2026-08  senior-review  arg:path         4

여기서 (전체) 행이 실제 스킬 호출 횟수이고, 그 아래의 속성들은 어떤 옵션 조합으로 썼는지를 나타냅니다. 한 번의 호출에 여러 속성이 동시에 포함될 수 있어 하위 행의 합이 (전체)와 꼭 일치하지는 않으므로, 순수 호출량을 볼 때는 항상 (전체) 행을 기준으로 확인합니다.

스킬목록 탭

호출 로그만으로는 볼 수 없는 사용량 0회 스킬을 추적하기 위한 메타데이터 탭입니다.

1
2
3
4
skill          최초 확인   최근 확인   상태
ship           2026-08    2026-09    활성
senior-review  2026-08    2026-09    활성
old-skill      2026-07    2026-08    2026-08 이후 없음

이 목록은 사람이 직접 관리하지 않습니다.

각 개발 레포로 공용 스킬이 자동 동기화되고 있기 때문에, 훅이 실행될 때 .claude/skills 폴더를 읽어 현재 배포된 스킬 목록을 함께 보냅니다.

이 정보를 누적하면 어떤 스킬이 현재 팀에 배포되어 있는지 확인할 수 있습니다.

여기서 핵심은 배포 상태와 실제 사용 여부를 분리해서 본다는 점입니다. 이번 달 호출이 0회라도 .claude/skills에 남아 있다면 “배포 중이지만 아무도 안 쓰는 스킬”로 분류되고, 공용 레포에서 빠져 더 이상 동기화되지 않는다면 과거 이력만 보존된 채 “삭제된 스킬”로 명확히 구분됩니다.

종합 탭

팀 전체 사용량을 한눈에 모아보는 통합 탭입니다.

1
2
3
4
month    skill          params        total
2026-09  ship           (전체)          42
2026-09  ship           mode:commit     30
2026-09  old-unused     (전체)           0

최근 3개월을 기준으로 배포 목록에는 존재하지만 호출 기록이 전혀 없는 스킬은 (전체) 0으로 채워지기 때문에, 오랫동안 방치된 스킬을 즉시 찾아낼 수 있습니다.

실제로 확인할 수 있었던 것

실제 데이터가 쌓이기 시작하자 그동안 감에 의존했던 질문들에 명확한 답을 내릴 수 있었습니다.

• 팀의 주력 스킬 파악

먼저 어떤 스킬이 많이 쓰이는지 볼 수 있습니다. params = (전체)만 필터해서 호출 횟수 순으로 정렬하면 팀에서 실제로 자주 쓰는 스킬이 나옵니다.

• 근거 있는 스킬 정리

반대로 최근 몇 달 동안 계속 0인 스킬도 바로 확인할 수 있습니다.예전에는 “이거 아무도 안 쓰는 것 같은데” 정도였다면, 이제는 실제 사용 기록을 보고 삭제 여부를 판단할 수 있습니다.

• 사용자 편중 확인

특정 스킬을 한 명만 꾸준히 쓰고 있다면 공용 레포 대신 개인 스킬로 분리하는 기준을 세울 수 있었고, 여러 명이 한 번씩 써보고 이탈한 스킬은 인터페이스나 실용성에 문제가 없는지 점검해 볼 수 있었습니다.

• 인터페이스 최적화

/ship의 대부분이 mode:commit으로 쓰이고 있다면 해당 모드를 기본 동작으로 변경해 타이핑 비용을 줄일 수 있었고, 문서에만 적혀 있고 아무도 안 쓰는 옵션은 과감하게 덜어낼 수 있었습니다.

셋업(설정)은 최소한으로 유지하기.

팀원들이 로컬에서 신경 써야 할 설정은 최대한 줄였습니다. 각자의 ~/.claude/settings.json에 인증 토큰과 Apps Script 엔드포인트 두 줄만 적어두면 끝납니다.

1
2
3
4
5
6
{
  "env": {
    "SKILL_USAGE_TOKEN": "<팀 공유 시크릿>",
    "SKILL_USAGE_ENDPOINT": "https://script.google.com/…/exec"
  }
}

이 값이 없으면 스크립트는 아무 작업도 하지 않고 조용히 종료됩니다. Hook 설정과 로깅 스크립트는 모두 공용 스킬 레포에서 함께 관리되며 기존 GitHub Actions를 통해 각 프로젝트로 자동 배포되기 때문에, 로깅 로직이 바뀌더라도 개별 개발자가 훅 설정을 다시 건드릴 필요가 없습니다.

결국 필요했던 건 숫자가 아닌 ‘판단 근거’

이걸 만든 이유는 단순히 인기 있는 스킬 순위를 보고 싶어서가 아니었습니다. 스킬을 계속 유지할지, 개선할지, 지울지를 결정할 수 있는 명확한 판단 근거가 필요했기 때문입니다.

예전에는 오래된 스킬을 보면서도 “혹시 누군가 쓰고 있지 않을까?” 싶어 쉽게 지우지 못했지만, 이제는 최근 사용 기록을 바탕으로 자신 있게 정리를 이야기할 수 있습니다. 반대로 동료들이 유용하게 쓰는 방식을 보며 제 작업 방식을 개선할 힌트를 얻을수도 있었던 것 같습니다.

프롬프트나 코드 원문까지 수집하는 거창한 파이프라인 없이, 스킬 이름과 인자 형태만 가볍게 Google Sheet로 모은 것만으로도 “이 스킬을 계속 유지해야 할까?”라는 고민에 훨씬 명쾌하게 답할 수 있게 되었습니다.

참고자료 (모니터링 전체 플로우)