Agent는 어떻게 Skill을 정확히 명중시키는가
Skill 수가 십수 개에서 수백 개로 늘어난 뒤, 어떻게 올바른 하나를 명중시킬 것인가.
규모가 바뀌면 문제의 성질도 바뀐다: 라우팅 시스템 자체가 이미 검색 시스템이 되어 있다. name/description을 "무엇을 할 수 있나"에서 "어떤 장면에서 쓰나"로 다시 쓰고, 업무 대분류로 계층 라우팅(Skill Tree)을 하고, 각 Skill에 반례 경계(비적용 장면)를 보충하고, 관측성 로그를 구축해 오명중 샘플로 반복 개선한다.
명중률은 감으로 튜닝하는 게 아니라 오명중 샘플로 튜닝하는 것이다.
문제 성질의 이동: 라우팅 → 검색
해법을 "프롬프트 쓰기"에서 "검색 시스템 만들기"로 전환해야 한다.
해법 1: 입구 설명 최적화 (장면화 description)
흔한 오류:
- 팀이 노력을 전부 Skill 내부 설명 다듬기에 쏟는다
- 그런데
name과 description은 텅 비어 있다. 예: 「데이터 도우미」, 「사무 도구」
- 하지만 모델이 라우팅할 때 가장 먼저 보는 것이 바로 이 입구 정보다
| ✗ 잘못된 작성 | ✓ 올바른 작성 |
|---|
| 「그것이 무엇을 할 수 있는지」(기능만 서술) | 「어떤 장면에서 쓰는지」 |
| 작성 | 효과 |
|---|
| 「PPT 생성」 | 명중률 낮음 |
| 「사용자가 보고, 로드쇼, 분기 결산을 할 때 사용」 | 명중이 더 쉬움 |
해법 2: 계층 라우팅 (Skill Tree)
모델이 매번 100개 중에서 추측하는 것이 아니라, 더 작은 후보 집합에서 판단하게 한다.
해법 3: 제약과 반례 (경계를 명확히 쓰기)
- 적용 장면만 쓰는 것으로는 부족하고, 비적용 장면도 써야 한다
- 근본 원인 판단: 많은 오명중은 올바른 Skill이 약해서가 아니라, 유사한 Skill의 경계가 명확히 쓰이지 않아서다
해법 4: 관측성 구축, 오명중 샘플로 반복 개선
반드시 기록해야 할 5종 데이터:
- 사용자 질문
- 후보 Skill
- 최종 선택
- 실행 결과
- 사람의 피드백
반복 방식
- 명중률은 감으로 튜닝하는 게 아니다
- 오명중 샘플로 세 가지를 계속 고쳐 나가는 것이다: description, 계층, 임계값
정리
Skill이 많아지면 본질적으로 라우팅과 검색 문제다. 점진적 로딩으로 컨텍스트 압력을 줄이고, 변별력 높은 설명으로 소환율을 높이고, Skill Tree로 후보 범위를 좁힌 다음, 로그 피드백으로 지속 최적화한다. 그래야 Agent가 대규모 Skill 체계에서 안정적으로 명중할 수 있다.
핵심 통찰
- 수량의 변화는 난이도가 아니라 문제의 성질을 바꾼다 — 십수 개일 때는 Prompt 문제지만 수백 개면 검색 문제다. 「언제 패러다임을 바꿔야 하는지」 식별하는 것이 옛 패러다임 안에서 계속 최적화하는 것보다 중요하다. 계속 Prompt를 다듬는 것은 잘못된 층위에서 힘을 쓰는 것이다.
- description은 라우터를 위한 것이지 사람을 위한 것이 아니다 — 대부분의 팀은 문서 품질을 Skill 내부 구현 설명에 투자하지만, 라우팅 결정은 name + description만 읽는다. 최적화 투자는 의사결정 링크에서 실제로 읽히는 필드를 따라가야 한다.
- 「장면 설명」이 「기능 설명」보다 소환율이 높은 이유는 사용자 query와 같은 의미 공간에 있기 때문이다 — 사용자는 "PPT를 생성하고 싶다"고 말하지 않고 "다음 주에 분기 보고를 해야 한다"고 말한다. description을 사용자가 할 법한 말로 쓰는 것은 본질적으로 query-document 의미 정렬이며, 이것이 바로 검색 공학의 표준 방식이다.
- 오명중의 주요 원인은 능력 부족이 아니라 경계 모호다 — 이 통찰은 트러블슈팅 방향을 바로 바꿔준다. 라우팅이 틀렸을 때 먼저 볼 것은 「잘못 선택된 그 유사 Skill의 설명」이지 「원래 명중해야 했던 Skill을 강화하는 것」이 아니다. 부정 샘플(반례)이 긍정 샘플보다 의사결정 경계를 더 잘 긋는다.
- 계층 라우팅은 O(N)의 선택을 O(log N)의 결정으로 압축한다 — 100 중 1의 정확도는 필연적으로 "4 중 1 후 25 중 1"보다 낮다. 검색 시스템의 "거친 필터 + 정밀 재정렬" 2단 구조와 동형이며, 같은 공학적 직관의 두 가지 표현이다.
- 관측성은 명중률 최적화의 전제이지 부가 항목이 아니다 — 「사용자 질문 / 후보 / 최종 선택 / 실행 결과 / 사람 피드백」 5종 세트가 없으면 어떤 튜닝도 감에 의존할 수밖에 없다. 로그 설계는 시스템 상용 전에 정해야 하며, 사후에 샘플링을 붙이면 가장 가치 있는 오명중 현장을 놓친다.
- 반복 개선의 대상은 세 개의 구체적 손잡이로 떨어져야 한다 — description(의미), 계층(구조), 임계값(판정). 어떤 오명중 복기든 이 셋 중 하나의 수정으로 귀결되어야 하며, 그렇지 않으면 복기가 자산을 생산하지 못한다.
- 점진적 로딩이 해결하는 것은 「컨텍스트 압력」이며 명중률과는 직교하는 목표다 — 수백 개 Skill 정의를 한꺼번에 컨텍스트에 밀어 넣으면 비싸고 주의력도 희석된다. 로딩 전략과 라우팅 전략은 분리해 설계해야지, 같은 로직으로 비용과 정확도를 동시에 해결하려 하면 안 된다.
엔지니어링 실전 Tips
- 1·2단계를 먼저 하고 3단계를 할 것: 설명 품질이 개선되지 않으면 계층화는 혼란을 잘게 나눈 것에 불과하다.
- 「무엇을 담당하지 않는다」 한 줄이 투자 대비 수익이 가장 높은 텍스트다: 토큰 비용은 거의 늘지 않는데 가장 흔한 유형의 오명중을 바로 끊어낸다.
- 대분류는 조직/사업 라인 기준으로 나누고 기술 형태 기준으로 나누지 말 것: 연구개발/운영/재무/콘텐츠 같은 식으로. 사용자의 질문은 태생적으로 업무 맥락을 동반하는 반면, "API 읽기류 / 파일 쓰기류" 같은 기술 분류는 사용자 query와 정렬되지 않는다.
- 후보 Skill은 Top-1만이 아니라 전량 기록할 것: 최종 선택만 기록하면 "정답이 몇 위였는가"를 분석할 수 없고, 따라서 문제가 소환에 있는지 정렬에 있는지 판단할 수 없다.
- 사람 피드백은 원클릭 조작으로 만들 것: 5종 세트 중 가장 잘 누락되는 항목이다. 계측 비용이 높으면 아무도 라벨링하지 않고 오명중 샘플 라이브러리도 만들어지지 않는다.
- 임계값은 계층과 함께 조정할 것: 1차 라우팅의 신뢰도가 부족하면 폴백(다중 소환 또는 되묻기)으로 가야지, 억지로 대분류 하나를 골라 아래로 파고들면 안 된다. 계층의 오류는 단계마다 증폭된다.
- 명중률은 Skill별 버킷으로 볼 것: 전체 명중률은 소수 고빈도 Skill의 문제를 가려버린다. Skill 차원의 오명중 행렬을 봐야 어떤 두 Skill이 서로 뺏고 있는지 발견할 수 있다.
- 설명을 고친 뒤에는 회귀 검증할 것: 한 Skill의 description을 고치면 모든 유사 Skill의 상대 순위가 영향을 받으므로, 과거 query 집합으로 회귀해 두더지 잡기가 되지 않게 해야 한다.