#수십 개의 Skill에서 명중률을 어떻게 보장하는가

Skill 선택은 애초에 라우팅을 타지 않고 LLM 의미 매칭을 탄다. Agent 기동 시 모든 Skill의 description을 system prompt에 주입하고, 사용자가 한 마디 하면 LLM이 스스로 설명을 읽고 어느 것을 발동할지 판단한다. 따라서 명중률은 스케줄링 문제가 아니라 글쓰기 문제다 — 전부 description을 어떻게 쓰느냐에 달렸다.

단기에는 description 품질로 버티고, 중기에는 업무 도메인별 그룹핑으로 2단계 매칭을 하며, 장기적으로는 LLM 자체의 의미 이해 능력에 제약된다. 그래서 핵심 입장은 맹목적으로 Skill 수를 늘리지 말고 충분하면 그만이다.

#Skill과 Tool Call의 차이

#Skill의 동작 메커니즘

Skill은 패키징된 능력 묶음이며 SKILL.md 파일 하나로 정의된다. 그 안에는 다음이 적힌다:

• 이름
• 설명(description)
• 발동 장면
• 실행 플로우

실행 링크:

SKILL.md → description → system prompt에 주입 → LLM이 설명 읽기 → 의미 매칭

Agent 기동 시 모든 Skill의 description을 system prompt에 주입한다. 사용자가 한 마디 하면 LLM이 모든 설명을 읽고 어느 것을 발동할지 스스로 판단한다. 그래서 명중률 문제가 결국 「설명을 잘 썼는가」로 되돌아오는 것이다.

#첫 번째 수단: description을 잘 쓰기

description이 명중률의 근본이다.

• 반례(모호): 「문장 관련 작업 처리」 — 사용자가 「글 좀 써줘」라고 해도, 「제목 좀 바꿔줘」라고 해도 모두 여기에 명중한다. Skill 간 구별이 불가능하다.
• 정례(정확): 「문장의 후보 제목 생성」, 그리고 발동 키워드 첨부: 제목, 제목 짓기, 제목 생각, 대박 제목

판단 기준: 키워드를 명확히 나열할수록 LLM이 매칭할 때 단호해진다.

#두 번째 수단: Skill의 책임 범위 축소

하나의 Skill은 한 가지 일만 한다.

반면교사는 크고 포괄적인 「작문 도우미」 Skill을 만들어 글쓰기, 제목 짓기, 편집, 이미지 배치를 전부 밀어 넣는 것이다. 올바른 방식은 쪼개는 것이다:

작문 도우미 (글쓰기 + 제목 + 편집 + 이미지)
        ↓ 분할
글쓰기 Skill / 제목 Skill / 편집 Skill

인과 사슬은 이렇다: 책임이 단일할수록 → description을 쓰기 쉬워지고 → 명중이 정확해진다. 이 수단과 첫 번째 수단은 같은 일의 양 끝이다. 설명을 명확히 못 쓰는 것은 흔히 책임 자체가 깨끗하지 않기 때문이다.

#세 번째 수단: 의미 중첩 제거

두 Skill의 description이 의미상 중첩되면 LLM은 망설인다.

• 충돌 상황: 「AI 문장 작성」 ⇆ 「기술 문장 작성」. 사용자가 「AI 기술 문장 좀 써줘」라고 하면 → LLM은 누구를 골라야 할지 모른다
• 해결책은 두 갈래: 병합하거나, description에 경계를 명확히 긋는 것

목적은 하나다: LLM에게 판정 근거를 주는 것. 똑같이 합리적인 두 후보 사이에서 동전을 던지게 하지 않는 것이다.

#네 번째 수단: disable-model-invocation으로 폴백

앞의 세 수단은 「LLM이 더 정확히 고르게」 하는 것이고, 네 번째는 「LLM이 아예 고르지 못하게」 하는 것이다.

어떤 Skill은 사용자가 능동적으로 슬래시 명령을 입력할 때만 발동되어야 하고 LLM이 자동 매칭하면 안 된다. 방법은 SKILL.md에 이렇게 쓰는 것이다:

disable-model-invocation: true

효과: LLM이 자동 발동하지 않음 → 슬래시 명령에만 응답.

#Skill 수가 계속 팽창하면

#정리

결국 명중률은 LLM 자체의 의미 이해 능력에 달려 있으므로, 맹목적으로 수를 늘리지 말고 충분하면 그만이다. Skill을 하나 추가할 때마다 스스로에게 진입 질문을 던질 것:

「이것의 description이 기존 Skill과 명확히 구별되는가?」

#핵심 통찰

1. 선택 메커니즘이 최적화 수단을 결정하며, 메커니즘을 잘못 판단하면 모든 최적화가 빗나간다. Tool Call은 구조를 타고 Skill은 의미를 탄다. 이것은 용어 차이가 아니라 패러다임 차이다. 구조 매칭이라고 생각하면 라우팅을 짜고 규칙을 더하고 분배기를 만들게 되지만, 의미 매칭임을 알면 힘을 설명 텍스트에 쏟게 된다. 「라우팅 규칙을 짜자」가 치명적인 이유는 그것이 메커니즘 층위의 오판을 드러내기 때문이다.
2. 의미 시스템에서 설명 텍스트는 곧 코드다. Skill의 description은 사람이 보는 주석이 아니라 LLM 의사결정에 들어가는 유일한 입력이다. 모호하게 쓰면 로직이 불확정한 분기를 쓴 것과 같고, 구체적으로 써야 확정적 행동이 나온다. 따라서 Agent 공학에서 「문서 쓰기」의 우선순위는 핵심 로직 쓰기와 동등하게 다뤄야 한다.
3. 명중률 문제는 대개 먼저 책임 분할 문제다. description을 명확히 못 쓰는 것은 보통 문장력이 나빠서가 아니라 그 Skill이 애초에 네 가지 일을 하고 있어서다. 먼저 책임을 쪼개면 설명은 자연히 명확해진다. 이것이 두 번째 수단의 진짜 가치이며, 첫 번째 수단의 전제 조건이다.
4. 의미 시스템의 실패 모드는 「에러」가 아니라 「망설임」이다. 두 description의 의미가 중첩되면 LLM은 예외를 던지지 않고 하나를 고른다 — 오늘은 A, 내일은 B일 수 있다. 이런 문제에는 스택트레이스가 없으므로 사전에 경계를 그어 예방하는 수밖에 없다.
5. 「정확히 고르기」와 「고르면 안 됨」은 서로 다른 두 종류의 거버넌스 동작이다. 앞의 세 수단은 매칭 품질을 최적화하고, 네 번째 disable-model-invocation은 Skill을 자동 후보 집합에서 아예 빼낸다. 어떤 Skill의 올바른 발동 조건이 「의도 유사」가 아니라 「사용자의 명시적 요구」라면, 설명을 더 다듬을 게 아니라 자동 호출을 꺼야 한다.
6. 후보 집합의 규모 자체가 비용이다. 모든 description이 system prompt에 주입되므로 Skill이 많아질수록 컨텍스트가 길어지고 의미 공간이 붐비며 변별력이 떨어진다. 그래서 결론은 수량 절제다: 「충분하면 그만」 — 확장은 공짜가 아니다.
7. 능력의 상한은 모델에 있지 공학에 있지 않다. 단기/중기 수단(설명 품질, 그룹 매칭)은 모두 주어진 의미 능력 하에서 명중률을 짜내는 것이고, 장기 천장은 LLM 자체의 의미 이해가 결정한다. 이 상한을 인정해야 무한한 규칙으로 모델의 능력 결핍을 메우려 들지 않는다.

#엔지니어링 실전 Tips

• 발동 키워드는 당신의 말이 아니라 사용자의 말로 쓸 것: 「제목, 제목 짓기, 제목 생각, 대박 제목」은 전부 사용자가 실제로 칠 구어이지 「제목 생성 모듈」 같은 내부 명명이 아니다. 의미 매칭이 매칭하는 것은 사용자 입력이다.
• 경계 설명은 「무엇을 하지 않는다」보다 「무엇에 집중한다」가 효과적이다: 두 작성류 Skill에 보충한 것은 모두 긍정적 범위(AI 코딩 도구 실측 / Java, DB 등 전통 스택)다. LLM이 받는 것은 비교 가능한 정례이지 부정 조건의 나열이 아니다.
• description의 비용을 장부에 달 것: system prompt에 상주하므로 매 요청마다 지불한다. 구체적으로 쓰는 것은 필요하지만, 모든 Skill이 같은 예산을 나눠 쓰고 있다.
• 오발동과 미발동은 귀인을 분리할 것: 미발동(발동해야 하는데 안 됨)은 대개 설명이 충분히 구체적이지 않아서고, 오발동(발동하면 안 되는데 됨)은 대개 의미 중첩이거나 애초에 자동 호출을 꺼야 할 Skill이다. 수단이 다르므로 섞어서 조정하지 말 것.
• 그룹핑은 중기 수단이지 시작 수단이 아니다: 2단계 매칭은 「단기→중기→장기」의 중간 구간에 있다. Skill이 십수 개일 때 그룹핑부터 하면 잘못 고를 기회를 한 겹 더 도입할 뿐이다.
• 답변 구조를 그대로 재사용할 수 있다: 먼저 질문 속 잘못된 전제를 교정(라우팅을 타지 않는다) → 메커니즘 제시 → 수단 제시 → 계층화된 확장 답변. 이 구조 자체가 이런 유형의 시스템 설계 문제에 대한 범용 템플릿이다.