[한영자막] 모델만 바꿨는데, 왜 스킬이 안 먹혔을까?

한 줄 핵심

에이전트 제품에서 스킬은 기능 그 자체가 되며, 대규모로 잘 작동하게 하려면 스킬 정의보다 하네스·라우팅·평가·거버넌스 설계가 더 중요하다.

시간별 요약

1. 0:00
   이전의 blueprints는 에이전트에게 작업 절차를 미리 알려주는 단순한 레시피였고, 지금의 skills와 사실상 같은 역할을 한다. agentic products에서는 화면과 버튼 대신 에이전트가 전면에 서면서, 기능을 어디에 둘지 다시 생각해야 한다.
2. 3:02
   프롬프트는 에이전트의 정체성, 도구는 연결 대상, 스킬은 작업을 수행하는 방식이며, 그래서 스킬이 새로운 기능이 된다. 이때 엔지니어의 역할은 기능을 직접 만드는 것보다 스킬이 잘 실행되도록 harness를 만드는 쪽으로 이동한다.
3. 5:01
   스킬은 특정 작업을 잘 하도록 가르치는 표준화된 방법이며, skill.md의 이름·설명·본문이 각각 검색, 라우팅, 실제 행동을 담당한다. 최소 구현은 skill registry, system prompt, file read tool이며, 스크립트를 쓴다면 bash나 sandbox가 추가로 필요하다.
4. 7:02
   스킬 발견은 registry를 system prompt에 넣고 agentic loop가 이를 읽으며 진행되며, progressive disclosure가 핵심이다. 설명문은 스킬의 내용보다 사용자 요청을 유도하는 routing signal이어야 하고, 사용자의 실제 의도에 맞게 스킬을 자주 재구성해야 한다.
5. 11:00
   모델을 바꿨는데도 스킬이 실패한 이유는 새 모델이 스킬 앞부분만 강하게 보고 뒤쪽의 중요한 지시를 놓쳤기 때문이다. 그래서 skills는 문서가 아니라 모델과의 버전된 계약으로 다뤄야 하며, 모델 업그레이드마다 eval을 다시 돌려야 한다.
6. 13:03
   스킬이 많아질수록 시스템 프롬프트에 전부 넣는 방식은 무너지고, 우선순위 선별과 계층 구조, 메타데이터 필터, 거버넌스가 필요해진다. admission, ownership, boundaries, life cycle, audit 같은 통제를 자동화와 human-in-the-loop로 운영해야 enterprise scale에서 유지된다.

실무 인사이트

• 스킬 설명은 기능 소개문이 아니라 라우팅 신호이므로, 사용자 요청과 직접 연결되는 트리거 단어를 앞세워야 한다.
• 모델 교체 시에는 프롬프트나 스킬 파일이 안 바뀌어도 성능이 달라질 수 있으니, 반드시 회귀 eval을 재실행해야 한다.
• 스킬 수가 10개를 넘기기 시작하면 전부 노출하지 말고 검색·필터링·계층화로 후보를 줄이는 하네스를 먼저 설계해야 한다.