Claude Code의 Skills를 만들어 보긴 했지만, '편리한 단축키 모음' 이상의 것이 되지 못하고 있는——그런 상태에 있는 분들을 위한 기사입니다.

2026년 7월 24일에 Findy AI+가 Dainy, Dip, LayerX, Timee 4개사로부터 '사내에서 자주 사용되는 Claude Code Skills Top5'를 모은 기사를 공개했습니다. 4개사의 랭킹을 나란히 놓고 보면, Skills를 어떻게 위치시켜야 효과가 나타나는지에 대해 상당히 명확한 경향이 보입니다. 이 기사에서는 그 경향을 정리하여, 자신의 Skill 구성을 재검토하기 위한 관점으로 도출합니다.

• 출처: 【Claude Code 활용 특집】 그 회사에서 가장 많이 사용되는 Skills는? Claude Code의 이용 Skills Top5를 대공개! | Findy AI+
• 공식 문서: Extend Claude with skills

고찰에 들어가기 전에, 원 데이터의 전제를 짚고 넘어가겠습니다. 이 부분을 건너뛰면 'A사보다 B사가 더 많이 사용된다'와 같은 무의미한 비교를 하게 됩니다.

기간도 집계 축도 모집단도 제각각입니다. 특히 Dainy는 '실행 횟수 순으로 하면 일부 헤비 유저의 개인 Skill이 상위에 오기' 때문에, 일부러 이용자 수 순으로 했다고 명시하고 있습니다. 이 판단 자체가 시사하는 바가 크며, **Skill의 가치를 측정하려면 '몇 번 호출되었는가'보다 '몇 명에게 정착되었는가'**라는 사고방식이 배경에 깔려 있습니다.

따라서 아래에서 보는 것은 순위의 크고 작음이 아니라, 4개사에 공통적으로 나타나는 '카테고리'입니다.

4개사 모두에서 PR 리뷰 또는 QA 계열의 Skill이 Top5에 들어 있습니다 (Dainy 3위, Dip 5위, LayerX 1위, Timee 4위). Dip의 기사에는 그 이유가 명확하게 적혀 있었습니다.

AI 에이전트가 멤버의 손에 들어오면서 개인의 작업 속도는 확실히 올라갔습니다. 하지만 동시에, 개발 플로우의 병목(Bottleneck)은 '개인이 코드를 작성하는 시간'에서 '다른 멤버가 리뷰하는 시간'으로 이동했습니다.

이는 Skills에 국한되지 않고, 코딩 에이전트 도입 후에 반드시 일어나는 구조적 변화라고 생각합니다. 작성 속도만 올라가면, 차이분(Diff)이 리뷰 대기열에 쌓이기만 할 뿐 팀의 처리량(Throughput)은 변하지 않습니다. 그래서 각 회사는 '인간의 리뷰 전에 기계적인 지적을 없앤다' (Dainy rai-review), '관점별로 전문 에이전트를 분할하여 일관된 깊이로 리뷰한다' (LayerX claude-code-pr-review)라는 형태로 Skill을 리뷰 측에 투입하고 있습니다.

Skill을 '자신이 빨라지기 위해서'만 만들고 있다면, 이 이동한 병목에는 손을 뻗을 수 없습니다.

3개사에서 BigQuery 계열의 데이터 분석 Skill이 상위에 들어와 있습니다. 그리고 Timee에서는, PdM·애널리스트의 이용률이 엔지니어의 약 2배였다고 보고되었습니다.

Timee의 배경 설명이 구체적입니다. PdM이나 사업 기획이 '지난주 리피트율을 지역별로 보고 싶다' 정도의 집계라도 엔지니어에게 의뢰가 필요했고, 그 대기 시간이 의사결정의 병목이 되었다고 합니다. Dainy도 마찬가지로, 장애의 1차 조사가 '환경별 접속처, 로그 필터 작성법, 쿼리 비용 관리'와 같은 전제 지식 때문에 일부 멤버에게 종속(Silo)되어 있었다고 적혀 있습니다.

즉 데이터 분석 Skill이 효과적인 것은 SQL을 작성할 수 없어서가 아니라, '어떤 테이블을, 어떤 환경에서, 어떤 비용 전제로 호출할 것인가'라는 암묵지(Tacit Knowledge)가 Skill에 들어가 있기 때문입니다. 범용적인 SQL 생성으로는 대체할 수 없습니다.

나란히 놓고 보았을 때 가장 명확하게 드러난 것은 이것입니다. 상위에 있는 Skill의 설명을 읽어보면, 그 대부분이 자사 고유의 규칙을 내장하고 있습니다.

• Dainy의
  identify-release-branch

: 매주 릴리스 브랜치를 컷(cut)하는 메인라인 모델의 운용 규칙을 내장하여, "이 수정사항은 어느 브랜치로 향해야 하는가"를 판정함 - Timee의 Git 관련 28종: 프로젝트 고유의 커밋 메시지 규약·브랜치 명명 규칙에 준거

• LayerX의
  qa-sheet

: 차이점(diff)으로부터 QA 관점을 도출하고, 그대로 붙여넣을 수 있는 TSV 형식으로 출력 - Timee의 설계·핸드북 계열 35종: Design Doc이나 백엔드 개발 핸드북을 Skill화

범용적으로 편리한 프롬프트는 애초에 Skill로 만들지 않아도 모델이 알아서 해줍니다. Skill로 만들 가치가 있는 것은 "그 모델이 절대로 알 수 없는, 우리들만의 규칙"이라는 뜻입니다.

이는 공식 문서의 설명과도 일치합니다. 문서에는 동일한 지시·체크리스트·절차를 반복해서 붙여넣고 있을 때, 혹은 CLAUDE.md의 한 구절이 "사실"이 아니라 "절차"로 성장해 버렸을 때가 Skill을 만들 타이밍이라고 적혀 있습니다. 게다가 Skill의 본문은 사용될 때만 읽히기 때문에, 긴 레퍼런스를 품고 있어도 평소의 비용은 거의 제로에 가깝습니다. 따라서 "두꺼운 자사 규칙"을 넣기에 적합합니다.

Dip은 Skill을 "로컬의 개인 설정이 아니라, 부서의 공통 자산으로서 배포"하여, 여러 프로젝트에서 동일한 것이 동작하는 상태를 유지하고 있다고 기술하고 있습니다.

앞서 언급한 병목 현상론과 결합하면 이유를 알 수 있습니다. A 씨가 Skill 파이프라인을 통해 PR을 만들어도, 리뷰하는 B 씨가 동일한 파이프라인을 모른다면 판단 기준도 속도도 일치하지 않습니다. Skill이 배포되어야 비로소 그것은 "표준"이 되는 것입니다.

~/.claude/skills/에 둔 채로 남겨둔 Skill은 아무리 뛰어나도 개인의 시간 단축 도구로 끝납니다. 리포지토리의 .claude/skills/에 넣고 커밋할 것인가의 여부는 생각보다 큰 분기점입니다.

• 자신의 Skill을 "범용/자사 고유"로 분류할 것. 범용적인 쪽은 지워도 된다. 모델이 알아서 한다.
• 리뷰·QA 측에 하나를 만들 것. 개인의 구현 속도가 아니라, 리뷰 대기열을 줄이는 방향으로 투입한다.
• 배포되지 않은 Skill은 표준이 되지 않는다. ~/.claude/skills/에 있는 것을 리포지토리로 옮긴다.

덧붙여 Findy의 기사 말미에는 자신의 Claude Code 로그로부터 이용 중인 Skills의 Top5를 추출하는 분석 프롬프트가 무료로 공개되어 있습니다. 우선 현황을 파악하는 것부터 시작하고 싶다면 그쪽이 빠릅니다.

4개사의 랭킹을 통해 읽어낼 수 있었던 점은, Skills가 효과를 발휘하는 조직에서는 Skill이 "편리한 지름길"이 아니라 "조직의 규칙을 실행 가능한 형태로 만든 것"으로 취급되고 있다는 점이었습니다. 리뷰에 투입되고 있다는 것, SQL을 쓰지 않는 직종이 주역이 되고 있다는 것, 내용이 자사 고유의 규칙이라는 것, 그리고 배포되고 있다는 것. 이 4가지가 갖춰졌을 때, 개인의 시간 단축이 조직의 스루풋(throughput)으로 변하고 있는 것처럼 보입니다.

참고로 본 기사는 공개된 4개사의 데이터를 읽고 정리한 것이며, 필자가 동일한 체제를 구축하여 검증한 것은 아닙니다. 숫자의 취급에 있어서는 서두에 적은 전제의 차이가 있음을 다시 한번 덧붙여 둡니다.