지난 글에서 스킬 선택의 진짜 비용은 스킬 본문이 아니라 항상 상주하는 목록이라고 썼다 — 지연 로딩은 이미 하고 있다. 그 글의 결론은 외부 라우터를 설치하기 전에 목록부터 재라는 것이었다. 이 글은 그 다음 단계, A안 — 목록 다이어트를 실제로 내 기계에서 재 본 기록이다. 절약량을 시뮬레이션하기 전에 알아낸 게 하나 있는데, 순진하게 줄이면 그건 다이어트가 아니라 절단이었다.

1. 규격부터 — 설명은 로딩의 유일한 근거다

Anthropic 의 Agent Skills 문서는 3단계 점진 공개를 이렇게 규정한다. 1단계 메타데이터(이름 + 설명)는 항상 시스템 프롬프트에 들어가고, 문서가 붙인 크기가 “~100 tokens per Skill” 이다. 2단계 본문은 스킬이 걸렸을 때만, 3단계 참조 파일은 필요할 때만 읽힌다.1 같은 문서의 한 줄이 이 설계의 전제를 요약한다.

“The context window is a public good.” — Skill authoring best practices, Anthropic2

그래서 설명은 소개문이 아니다. 모델이 그 스킬을 열지 말지 정하는 유일한 근거다. 베스트 프랙티스 문서는 설명에 두 가지를 다 넣으라고 못 박는다 — 무엇을 하는지(what it does)와 언제 쓰는지(when to use it). 상한은 1024자, 3인칭으로 쓸 것, 구체적인 키워드를 넣을 것.2 3인칭 요구의 이유까지 적혀 있다. 설명이 시스템 프롬프트에 주입되기 때문에 시점이 섞이면 선택이 어긋난다는 것이다.2

2. 내 목록 실측 (2026-09-23, 이 맥)

항목 값
개인 스킬 수 57
목록 전체 (이름+설명, 화면에 뜨는 형태) 20,982 바이트
설명 본문 합계 14,985 자
설명 길이 중앙값 / 평균 / 최대 251 / 262 / 655 자
1024자 상한 초과 0 건
front matter 파싱 실패 0 건

비교 기준이 필요해서 공식 문서가 예시로 든 설명 셋(PDF 처리·Excel 분석·커밋 메시지)의 길이를 직접 셌다. 163 / 141 / 145 자, 평균 149자다.2 내 중앙값은 251자로 그 1.7배고, 57개 중 50개가 공식 예시 평균보다 길다. 상위 10개만 4,594자로 전체의 31% 를 차지한다 (제일 긴 게 factchk 655자, 다음이 autobahn 581자).

3. 순진한 다이어트는 틀린다

제일 먼저 떠오르는 수술은 “첫 문장만 남기기” 다. 재 봤다.

\[14{,}985 \rightarrow 7{,}464\]

정확히 절반이 준다. 그런데 이게 왜 틀린 수술인지는 1절의 규격이 이미 말해 준다. 내 설명의 첫 문장은 거의 예외 없이 무엇을 하는가이고, 언제 쓰는가는 두 번째 문장에 있다. 57개 중 50개가 두 문장 이상인 게 그 구조다. 첫 문장만 남기면 줄어드는 건 바이트가 아니라 트리거다. 목록은 가벼워지고 스킬은 안 걸린다. 비용은 줄고 효용이 0 이 되면 그건 절약이 아니다.

그러니까 A안은 “짧게 쓰기” 가 아니다. 설명에서 어떻게 를 빼고 무엇 + 언제 만 남기기여야 한다. 절차는 본문으로 내려보내면 된다 — 그게 애초에 2단계가 존재하는 이유다.

4. 그래서 내 목록에서 실제로 뺄 수 있는 건 얼마인가

이 기준으로 다시 재면 결과가 기대와 달랐다. 설명 안에 경로·명령·함정 같은 절차가 섞여 들어간 스킬은 57개 중 1개였다(lemuel-xr-theology-tone, 307자). 나머지 56개는 이미 무엇+언제만 적고 있다. 내 설명이 공식 예시보다 긴 이유는 절차가 새어 들어가서가 아니라, 한국어 트리거 문구를 같이 적고 있어서다 — 57개 중 30개가 호출 문구를 따옴표째 품고 있고 8개는 예: 로 사용례까지 붙여 놨다.

그리고 그 문구 중 상당수는 애초에 모델 추론이 필요 없다. CLAUDE.md 에 결정적으로 라우팅되는 한국어 예약어가 14개 있다 — /그림 /힙 /풀지씨 /지씨누수 /스레드 /메타스페이스 깃블 고블 메모 일정 이믹 미디어 이믹 등. 이건 문자열 일치로 걸리지, 설명으로 걸리는 게 아니다. 그 14개의 설명에서 트리거 반복을 걷어내는 건 기능을 잃지 않는다.

즉 내 기계 기준 A안의 여지는 “중복 트리거 문구 정리” 지 “절차 이관” 이 아니다. 같은 A안이라도 남의 기계에서는 반대일 수 있다. 이건 목록을 재 보기 전에는 알 수 없는 값이다.

5. 분모를 잊으면 안 된다

그리고 A안이 건드리는 건 상주 텍스트의 전부가 아니다. 같이 늘 올라가는 것들을 같은 날 같이 쟀다.

상주 텍스트 바이트
스킬 목록 20,982
~/.claude/CLAUDE.md 16,231
메모리 인덱스 MEMORY.md 25,134
RTK.md 961
채널 CLAUDE.md 969
목록 외 합계 43,295

목록은 상주 텍스트의 약 1/3 이다. 목록을 절반으로 줄여도 전체는 16% 준다. 이 분모를 안 적고 “목록을 30% 줄였다” 고 말하면 배수에 분모가 없는 주장과 같은 잘못을 내가 하는 셈이다.

6. A안의 값은 정확도가 아니라 회수된 문맥이다

외부 라우터를 검토하게 만든 원래 동기는 “설명이 잘려서 비슷한 스킬이 헷갈린다” 였다. 그건 내 기계에서 재 보니 해당이 없었다. 설명의 앞 30자가 겹치는 혼동쌍이 0쌍이고, 57개 전부가 60자를 넘는데도 목록에 20,982바이트가 통째로 실려 있다 — 60자에서 잘린다면 3,420바이트 이하여야 한다. 잘리지 않는다. 정확도 문제의 전제가 내 환경엔 없다.

그래서 A안을 하는 이유는 하나로 좁혀진다. 틀린 선택을 줄이려는 게 아니라, 매 프롬프트마다 돌려받는 문맥을 되찾으려는 것. 그러면 판정 기준도 달라진다. “오탑재가 줄었나” 가 아니라 “줄인 뒤에도 걸려야 할 스킬이 그대로 걸리나” 를 봐야 한다. 전자는 애초에 0이라 좋아질 수가 없고, 후자는 나빠질 수 있다. 다이어트의 위험은 전부 이쪽에 있다.

7. 그래서 순서

  1. 재기. 목록 바이트, 설명 길이 분포, 혼동쌍 수, 그리고 목록 밖 상주 텍스트까지. 여기까지가 이 글이다.
  2. 뺄 자리 고르기. 절차 누수(내 경우 1건) → 중복 트리거 문구(30건) → 스킬 수 자체. 무엇+언제는 건드리지 않는다.
  3. 전후 재기. 줄인 목록으로 걸려야 할 스킬이 걸리는지 를 확인한 뒤에야 절약량을 말한다.

3번을 아직 안 했다. 그래서 이 글에는 “몇 % 줄였다” 가 없다. 그 숫자는 수술 뒤에 재서 따로 적는다.

근거의 한계

  • 모든 수치는 이 맥 한 대, 2026-09-23 하루의 값이다. 스킬 구성이 다르면 4절의 결론(절차 누수 1건)은 그대로 뒤집힌다.
  • 토큰이 아니라 바이트·문자로 쟀다. 공식 문서의 “~100 tokens per Skill” 과는 단위가 다르고, 한국어 UTF-8 은 문자당 3바이트라 바이트→토큰 환산이 영어와 크게 어긋난다. 절약량을 토큰으로 말하려면 토크나이저로 다시 재야 한다.
  • 3절의 $14{,}985 \rightarrow 7{,}464$ 는 “첫 문장만 남길 때” 의 기계적 상한이지 권장안이 아니다. 본문이 적었듯 실행하면 트리거가 깨진다.
  • “잘리지 않는다” 는 목록 바이트와 설명 길이의 정합으로 역산한 결론이다. Claude Code 가 목록을 자르지 않는다는 공식 문서 문장을 찾지는 못했다.
  • 혼동쌍 판정은 “앞 30자 일치” 라는 내가 정한 조잡한 기준이다. 의미가 비슷하면서 앞머리가 다른 쌍은 이 방법으로 안 잡힌다.

References

  1. “Agent Skills overview”, Anthropic. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview — 3단계 점진 공개, 1단계 메타데이터 “~100 tokens per Skill”. ↩

  2. “Skill authoring best practices”, Anthropic. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices — description 1024자 상한, what + when 요구, 3인칭 규칙, 예시 설명 3종. ↩ ↩2 ↩3 ↩4