Hermes 스킬 사용량을 ‘감’이 아니라 호출 기록으로 측정하는 스킬을 만들었다

📝 한줄 요약

Hermes에 등록된 스킬이 많아지면서 “어떤 스킬을 가장 많이 썼는가?”라는 질문에 감으로 답하기 어려워졌다. 그래서 skill_view 호출, skill_manage 관리 호출, 누적 telemetry를 분리하고, canonical 이름·원본 호출명·미호출 스킬까지 함께 보여주는 skill-usage-analytics 스킬을 만들었다.

바쁘시면 이것만 읽어도 됩니다.

• 최근 30일 전체 소스에서 skill_view 호출은 4,218회였다.

• 관리 호출은 별도로 514회, 전체 스킬 액션은 4,732회였다.

• 설치된 canonical 스킬은 155개, 분석 대상은 활동·telemetry를 포함해 168개였다.

• 호출된 canonical 스킬은 95개, 호출이 없었던 설치 스킬은 63개였다.

• legal-lecture-recap이 1,381회로 가장 많았지만, 이 숫자는 누적 사용 수나 provider 과금량이 아니라 선택 기간의 skill_view 호출 수다.

• 이 통계를 한 번의 분석으로 끝내지 않도록 별도 Hermes 스킬로 등록했다.

🎯 이런 분들께 도움됩니다

• Hermes 스킬이 많아져 실제 라우팅 패턴을 확인하고 싶은 사람

• “스킬 사용”과 “스킬 호출”을 같은 숫자로 보고 있던 사람

• 어떤 스킬을 유지·개선·통합·정리할지 근거가 필요한 사람

• Slack, CLI, subagent 등 소스별 스킬 사용량을 비교하고 싶은 사람

• 상위 몇 개뿐 아니라 미호출 스킬까지 포함한 전체 목록이 필요한 사람

😫 문제 상황: 스킬이 많아질수록 ‘많이 썼다’는 말이 모호해졌다

처음 문제는 아주 짧은 질문에서 시작했다.

스킬사용 횟수, 스킬호출횟수

이 질문에는 서로 다른 숫자가 섞여 있었다.

• 최근 30일 동안 실제로 skill_view가 몇 번 호출되었는가?

• 누적 telemetry의 use_count는 얼마인가?

• 스킬을 수정하거나 관리한 횟수는 얼마인가?

• productivity/legal-lecture-recap과 legal-lecture-recap은 같은 스킬인가?

• 한 번도 호출되지 않은 설치 스킬은 무엇인가?

이 항목들을 하나의 “사용 횟수”로 합치면 보고서는 간단해 보이지만, 무엇을 측정한 숫자인지 설명할 수 없게 된다. 특히 누적 .usage.json telemetry와 특정 기간의 세션 기록은 시간 범위와 집계 대상이 다르다.

Before와 After

🌱 처음에는 무엇을 몰랐나

처음에는 “스킬 사용 횟수”와 “스킬 호출 횟수”가 거의 같은 말이라고 생각하기 쉽다. 실제로는 측정면이 달랐다.

• 호출은 선택한 기간의 세션 기록에서 skill_view가 호출된 횟수다.

• 관리는 같은 기간의 skill_manage 호출 횟수다.

• 누적 사용 telemetry는 .usage.json에 저장된 lifetime counter다.

• canonical 스킬은 실제 SKILL.md frontmatter 이름을 기준으로 확인한 논리적 스킬명이다.

이 구분을 먼저 하지 않으면 “많이 쓰인 스킬”이라는 제목 아래 서로 다른 시계와 서로 다른 계수기를 합치게 된다.

🛠️ 사용한 도구와 근거

이번 작업은 외부 서비스나 provider 과금 API를 조회한 것이 아니다. Hermes 로컬 기록과 스킬 파일을 근거로 삼았다.

• Hermes 세션 기록: 선택 기간의 skill_view, skill_manage tool-call 복원

• .usage.json telemetry: lifetime use_count, view_count, patch_count 확인

• SKILL.md frontmatter: qualified path를 canonical 이름으로 정규화

• 보고서 생성기: Markdown·CSV·JSON으로 전체 결과 내보내기

• 검증 카드: 실제 JSON 집계값에서 생성한 SVG 증거 카드

이 작업에서 측정하지 않은 것도 분명히 했다. 이 통계는 OpenAI·Codex 등 provider의 잔여 quota, 과금, 계정 사용량을 보여주지 않는다.

🔧 작업 과정

1. 질문을 계수 가능한 지표로 바꾸다

첫 번째 전환점은 질문을 바로 숫자로 바꾸지 않고, 먼저 관찰 가능한 사건으로 나눈 것이다.

각 스킬별로 호출횟수를 통계내보면 어떨까

이 요청을 다음과 같이 해석했다.

1. 선택한 기간과 소스를 고정한다.

2. skill_view를 호출·로드 지표로 센다.

3. skill_manage는 사용량과 분리한다.

4. lifetime telemetry는 별도 열로 제공한다.

5. 전체 목록을 내보내고 합계를 검산한다.

그 결과 보고서는 단순한 숫자 목록이 아니라, 각 숫자가 어느 기록에서 왔는지 설명할 수 있는 구조가 되었다.

2. 같은 스킬의 다른 주소를 분리하지 않다

두 번째 문제는 스킬 이름이었다.

별도 스킬로 만들어

통계 절차를 별도 스킬로 만들면서 qualified path를 그대로 세면 같은 논리적 스킬이 여러 행으로 갈라질 수 있다는 점을 함께 정리했다.

예를 들어 다음 호출명은 실제 분석에서 하나의 canonical 스킬로 묶을 수 있다.

legal-lecture-recap
productivity/legal-lecture-recap

단순히 basename이 같다는 이유로 무조건 합치지는 않았다. 실제 SKILL.md frontmatter와 경로 매핑이 모호하지 않을 때만 병합하고, raw_names에는 원래 호출명을 남겼다. 이렇게 해야 라우팅 문제를 분석할 때 원본 주소도 다시 볼 수 있다.

3. ‘활동한 스킬’만 세지 않고 0회 스킬도 남기다

초기 보고서는 최근 기간에 활동이 있었던 스킬을 중심으로 정리되었다. 하지만 “각 스킬별 통계”라면 설치되어 있지만 호출되지 않은 스킬도 보여야 한다.

그래서 최종 보고서는 다음 집합의 합집합을 사용한다.

• 설치된 SKILL.md 목록

• 선택 기간에 세션 기록에서 발견된 스킬명

• lifetime telemetry에 남아 있는 스킬명

그 결과 호출이 없는 스킬도 0으로 나타나고, 미사용 스킬을 정리하거나 설명을 개선할 때 별도의 탐색이 가능해졌다.

4. 상위 30개를 만들고, 다시 사용할 수 있는 스킬로 묶다

마지막 요청은 결과를 실제 목록으로 확인하는 것이었다.

가장 많이 쓰인 30개 스킬을 이걸로 호출 통계 내줘

최근 30일·전체 소스 기준으로 skill_view 호출 상위 30개를 정렬하고, 각 행에 호출 수·관리 호출 수·세션 수를 함께 넣었다. 터미널 화면의 상위 몇 개만 읽는 대신, 전체 CSV·JSON을 남겨 상위 30개 밖의 긴 꼬리도 확인할 수 있게 했다.

📊 실제 결과

현재 검증된 보고서의 headline은 다음과 같다.

그림 1. 최신 JSON 보고서에서 직접 생성한 data-derived evidence card다. UI 스크린샷이 아니라 실제 집계값을 시각화한 결과이며, 기간은 2026-07-09~2026-08-08 UTC다.

호출 상위 10개

상위 30개 전체 목록과 원본 호출명·source breakdown은 함께 생성된 CSV와 JSON에서 확인할 수 있다.

그림 2. 세션 기간 지표, 누적 telemetry, canonical inventory를 섞지 않도록 만든 측정 경계다.

🧭 가장 중요한 수리: 숫자가 아니라 경계를 고쳤다

이번 사례에서 가장 중요한 수정은 더 많은 counter를 추가한 일이 아니었다. 서로 다른 질문에 서로 다른 숫자를 배정한 일이었다.

Trace

• 세션 기록에서 skill_view와 skill_manage 호출을 분리했다.

• .usage.json의 lifetime counter를 별도 필드로 읽었다.

• SKILL.md frontmatter를 통해 canonical 이름을 확인했다.

Proof

• JSON과 CSV의 행 수가 일치한다.

• 스킬별 view_calls 합계가 headline total_view_calls와 일치한다.

• 스킬별 manage_calls 합계가 headline total_manage_calls와 일치한다.

• 스킬별 전체 액션 합계가 headline total_actions와 일치한다.

• 설치된 스킬과 0회 스킬을 별도로 확인할 수 있다.

Verdict

최근 30일의 Hermes 스킬 호출 상위 30개를 재현 가능한 형태로 산출할 수 있는 상태다. 단, 이 결과를 provider 과금이나 잔여 quota로 해석해서는 안 된다.

Repair

초기 보고서에서 “활동이 있는 스킬”과 “설치된 모든 스킬”의 범위가 섞일 수 있는 품질 gap을 발견했다. 보고서 생성기를 보강해 설치 목록·세션 기록·telemetry의 합집합을 사용하고, installed, tracked, active를 별도 집계하도록 수정했다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 모호한 단어를 관찰 가능한 사건으로 바꾸기

   • “사용”을 바로 숫자로 만들지 않고 호출·관리·누적 telemetry로 나눴다.

2. 정규화 전 원본을 버리지 않기

   • canonical 이름으로 보기 쉽게 만들면서도 raw_names를 보존했다.

3. 상위 목록과 전체 목록을 함께 만들기

   • 상위 30개는 의사결정에 편하고, 0회·1회 긴 꼬리는 정리와 개선에 중요하다.

4. 합계를 독립적으로 다시 계산하기

   • 보기 좋은 표보다 행별 합계와 headline totals의 일치 여부를 먼저 확인했다.

이렇게 하면 안 됩니다

1. 누적 use_count를 최근 30일 호출 수라고 부르지 않는다.

2. 터미널에 보이는 상위 10개만 보고 “전체 통계”라고 하지 않는다.

3. 관리·수정 호출을 실제 스킬 사용량에 더해 순위를 왜곡하지 않는다.

4. 이름이 비슷하다는 이유만으로 서로 다른 스킬을 자동 병합하지 않는다.

5. provider quota나 과금량을 Hermes 세션 통계에서 추정하지 않는다.

🌍 다른 업무에 적용한다면?

이 방식은 스킬 외에도 “서로 다른 범위의 숫자를 하나로 부르고 있던” 운영 업무에 적용할 수 있다.

예를 들어 여러 에이전트가 같은 문서 변환 업무를 수행한다면, 다음 세 범위를 따로 기록할 수 있다.

• 이번 달 실제 변환 요청 수

• 누적 변환 템플릿 사용 수

• 설치되어 있지만 한 번도 호출되지 않은 변환 흐름

그러면 어떤 흐름을 새로 만들지보다 먼저, 이미 있는 흐름 중 설명이 부족한 것과 실제로 쓰이지 않는 것을 구분할 수 있다. 이 사례에서 중요한 재사용 원칙은 “모든 숫자를 더하는 것”이 아니라 “각 숫자의 시간·출처·의미를 함께 저장하는 것”이다.

🤝 배워서 남 주기

이번 결과는 일회성 표로 끝내지 않고 skill-usage-analytics라는 별도 Hermes 스킬로 등록했다. 이후 같은 질문이 들어오면 다음 항목을 기본으로 제공할 수 있다.

• 기간·소스가 명시된 호출 통계

• canonical 이름과 원본 호출명

• 상위 스킬과 긴 꼬리

• 미호출 설치 스킬

• CSV·JSON·Markdown 산출물

• 합계 검산 결과

다른 사람이 재사용할 때는 다음처럼 요청하면 된다.

프롬프트 1: 상위 호출 통계

최근 [기간] 동안 [소스 또는 전체 소스]에서 skill_view 호출 횟수가 가장 많은 스킬 [N]개를 집계해줘. skill_manage는 별도 열로 보여주고, canonical 이름과 원본 호출명을 함께 보존해줘. 전체 합계와 행별 합계를 검산해줘.

프롬프트 2: 사용량과 호출량 비교

최근 [기간]의 세션 호출 기록과 lifetime .usage.json telemetry를 섞지 말고 분리해서 보고해줘. view_calls, manage_calls, lifetime_view_count, lifetime_use_count, lifetime_patch_count를 각각 설명하고, 미호출 설치 스킬도 0으로 포함해줘.

🕊️ 이 사례가 줄이는 것

이 작업이 줄이는 것은 단순히 표를 만드는 시간만이 아니다. 스킬이 많아질수록 생기는 다음과 같은 불확실성을 줄인다.

• 어떤 스킬이 실제로 호출되었는지 모르는 상태

• 누적 사용량과 최근 활동량을 혼동하는 상태

• 같은 스킬의 경로만 달라졌는데 별도 기능으로 오해하는 상태

• 한 번도 쓰이지 않은 스킬을 계속 유지하는 상태

• 상위 몇 개만 보고 전체 라우팅을 판단하는 상태

측정 기준을 공유하면, 스킬을 추가할 때도 “필요해 보인다”를 넘어 실제 사용 패턴과 책임 경계를 함께 검토할 수 있다.

🚀 앞으로의 계획

현재 구현은 최근 기간의 정적 보고와 재현 가능한 export에 초점을 둔다. 다음 단계로 확장할 수 있는 항로는 다음과 같다.

1. 월별 호출 추이와 스킬별 변화량 비교

2. Slack·CLI·subagent별 canonical 사용 패턴 비교

3. 장기간 0회·1회 스킬의 정리 후보 리포트

4. 스킬 설명 변경 전후의 라우팅 변화 분석

5. 정기 보고서 또는 dashboard 형태의 운영화

이 항목들은 아직 이번 사례에서 실행한 결과가 아니므로, 계획으로만 남긴다.

📦 산출물과 상태

생성된 산출물

• skill_usage_latest.md: 사람이 읽는 요약

• skill_usage_latest.csv: 전체 행 단위 통계

• skill_usage_latest.json: 구조화된 원본 보고서

• case-study-assets/01_top10_skill_view_calls.svg: 실제 JSON에서 생성한 상위 호출 evidence card

• case-study-assets/02_metric_scope_map.svg: 지표 범위 설명 evidence card

• skill-usage-analytics: 반복 분석을 위한 Hermes 사용자 스킬

공개 경계

• 상태: Library 발행본

• 외부 게시: 수행하지 않음

• Library 편입: 공용 publisher의 receipt·manifest·index read-back으로 확인

• provider 과금·quota 조회: 수행하지 않음

• 세션 DB·.usage.json 원본 수정: 수행하지 않음

이 글은 실제 산출물과 검산 결과를 바탕으로 작성한 Library 발행본이다. 외부 게시용 문체, 이미지 규격, 게시판 업로드는 별도 단계로 분리한다.