Matt Pocock의 좋은 에이전트 스킬을 쓰는 법에 관한 짧은 강연입니다. 영상은 스킬을 많이 모으는 문제가 아니라, 스킬을 어떤 기준으로 고르고 줄이고 유지할 것인가의 문제를 다룹니다. 우리 블로그에서 /blog, /book, /news, /youtube, /harness 같은 스킬을 계속 늘려온 입장에서는 꽤 직접적인 점검표처럼 읽힙니다.
영상의 핵심은 네 가지입니다. 스킬은 언제 호출될지 정해야 하고, 내부 구조는 절차와 참고 자료로 나뉘어야 하며, 에이전트를 움직이는 단어를 의도적으로 골라야 하고, 오래된 찌꺼기와 중복을 계속 덜어내야 합니다.
1. 스킬 지옥: 스킬이 많아졌는데 기준이 없다
“skill hell”
해석
Pocock은 개발자들이 한때 튜토리얼 지옥, 프레임워크 지옥을 겪었고 이제는 스킬 지옥에 들어섰다고 말합니다. 스킬 파일은 많아졌고 저장소도 많아졌지만, 좋은 스킬과 나쁜 스킬을 가르는 기준은 아직 흔들립니다.
이 문제는 개인에게만 생기지 않습니다. 조직이 자신의 운영 절차를 에이전트가 실행 가능한 단위로 바꾸려면, 스킬을 단순한 팁 모음이 아니라 반복 가능한 업무 절차로 설계해야 합니다. 스킬이 늘수록 진짜 문제는 수량이 아니라 품질 기준입니다.
2. Trigger: 사용자가 부를 것인가, 모델이 부를 것인가
“model invoked skills”
해석
첫 번째 기준은 호출 방식입니다. 어떤 스킬은 사용자가 명시적으로 불러야 하고, 어떤 스킬은 모델이 설명을 읽고 스스로 호출할 수 있어야 합니다. 모델 호출형 스킬은 편하지만, 설명이 항상 컨텍스트에 들어가므로 비용과 예측 불가능성이 생깁니다. 사용자 호출형 스킬은 더 통제 가능하지만, 사용자가 언제 어떤 스킬을 써야 하는지 기억해야 합니다.
이 구분은 지금 우리 Stream Deck 작업과도 맞닿아 있습니다. /news, /book, /youtube 같은 버튼은 사용자가 의도적으로 누르는 호출입니다. 반대로 글을 쓰는 중 자동으로 적용되어야 하는 규칙은 모델 호출형 설명에 가까워집니다. 둘을 섞어 쓰되, 어떤 부담이 사람에게 있고 어떤 부담이 모델의 컨텍스트에 있는지 분명히 해야 합니다.
3. Structure: 스킬은 절차와 참고 자료로 나뉜다
“steps and the reference”
해석
두 번째 기준은 구조입니다. 스킬의 본문에는 매번 따라야 하는 절차가 들어가고, 분기별로만 필요한 긴 설명은 참고 자료로 빠져야 합니다. 모든 것을 SKILL.md에 넣으면 처음에는 친절해 보이지만, 시간이 지나면 유지보수와 컨텍스트 비용이 커집니다.
이 점은 우리 블로그 스킬에도 바로 적용됩니다. /book은 책 노트 생성 절차를 담고, TTS 제공자별 세부 설정은 참고 문서나 스크립트로 빼는 편이 낫습니다. /news는 매일 실행되는 루프만 전면에 두고, 라디오쇼 폴백, 이미지 처리, 검증 기준은 필요할 때만 읽히는 구조가 더 오래 갑니다.
4. Steering: 에이전트를 움직이는 단어를 의도적으로 쓴다
“leading words”
해석
세 번째 기준은 조향입니다. 같은 요구라도 어떤 단어를 쓰느냐에 따라 에이전트의 행동이 달라집니다. review, diff, verify, fallback, self-review, harness 같은 단어는 단순한 장식이 아니라 행동을 압축한 지시어입니다.
우리의 스킬도 이 원칙을 더 분명히 따라야 합니다. “좋게 써줘”보다 “원문 근거와 내 해석을 분리하라”가 낫고, “배포해줘”보다 “빌드, 공개 URL 확인, 의도한 파일만 스테이징”이 낫습니다. 좋은 스킬은 긴 잔소리가 아니라 에이전트가 반복해서 정확한 행동을 떠올리게 만드는 단어의 집합입니다.
5. Leg Work: 한 단계가 너무 게으르면 스킬을 나눈다
“leg work”
해석
에이전트가 질문을 충분히 하지 않거나, 코드베이스를 충분히 읽지 않거나, 검증을 대충 끝내는 경우가 있습니다. Pocock은 이런 경우 한 스킬 안에 너무 많은 미래 단계를 노출하지 말고, 작은 스킬로 나누어 현재 단계에 더 오래 머물게 만들 수 있다고 설명합니다.
이건 자동화의 역설입니다. 모든 것을 한 버튼에 넣으면 편해 보이지만, 에이전트는 중간 검증을 건너뛰기 쉽습니다. 그래서 /youtube도 “자막 수집”, “클립 선정”, “글 작성”, “빌드 검증”, “배포”를 한 번에 섞기보다, 각 단계의 완료 조건을 분명히 둬야 합니다.
6. Pruning: 단일 진실 원천과 가지치기
“single source of truth”
해석
마지막 기준은 가지치기입니다. 스킬은 시간이 지나면 중복, 오래된 지시, 더 이상 행동을 바꾸지 않는 문장으로 무거워집니다. 그래서 같은 설명을 여러 곳에 반복하지 말고, 한 곳에서만 관리해야 합니다. 특정 분기에만 필요한 참고 자료는 그 분기 아래로 보내고, 더 이상 유효하지 않은 규칙은 제거해야 합니다.
이 말은 지금 우리 로컬의 스킬 운영에도 중요합니다. Reasonofmoon Devlog와 ReadMaster Study Platform이 함께 돌아가면서 /book, /k-book, /kid-book, /k-kid-book 같은 이름이 늘어났습니다. 이들을 살리려면 더 많이 적는 것이 아니라, 공통 하네스와 사이트 라우터를 단일 진실 원천으로 만들고 각 스킬은 자기 역할만 짧게 수행하게 해야 합니다.
내 생각
이 영상은 “스킬을 어떻게 잘 쓰는가”보다 “스킬을 어떻게 오래 망가지지 않게 운영하는가”에 가깝습니다. 내게 특히 중요하게 남는 건 세 가지입니다.
첫째, 스킬은 지식이 아니라 운용 단위입니다. 좋은 글쓰기 팁, 좋은 배포 명령, 좋은 TTS 설정을 한 문서에 쌓아두는 것만으로는 충분하지 않습니다. 스킬은 사용자가 누를 수 있고, 에이전트가 읽을 수 있고, 실패했을 때 되돌릴 수 있는 실행 구조여야 합니다.
둘째, 컨텍스트는 무료가 아닙니다. 모델 호출형 스킬은 편하지만 컨텍스트를 계속 차지합니다. 반대로 사용자 호출형 스킬은 Stream Deck 버튼처럼 명시적인 트리거가 필요합니다. 그래서 앞으로 내 작업 환경은 “자동으로 떠오르는 규칙”과 “내가 의도적으로 누르는 버튼”을 분리해야 합니다.
셋째, 좋은 스킬은 쓰는 것보다 지우는 것이 더 어렵습니다. 블로그 자동화, 뉴스 라디오쇼, 책 노트 TTS, 원서 학습 콘텐츠가 모두 쌓이면 어느 순간 스킬 자체가 또 하나의 레거시가 됩니다. 이때 필요한 것은 더 많은 프롬프트가 아니라, 정기적인 가지치기 루프입니다.
결국 스킬은 에이전트를 위한 매뉴얼이면서, 나 자신을 위한 작업 습관의 외부화입니다. 좋은 스킬은 AI를 똑똑하게 만드는 문서가 아니라, 사람과 AI가 같은 작업대를 반복해서 깨끗하게 쓰도록 만드는 작은 운영체제에 가깝습니다.
우리 하네스에 바로 적용할 점
/youtube는 자막 수집 실패 시 fallback 근거의 이름을 명확히 분리한다./news는 라디오쇼 생성, 이미지 임베딩, 빌드 검증, 배포 검증을 하나의 루프 안에서 체크한다./book계열은 TTS 생성 대상을 제목만으로 찾지 않고, frontmatter의 책 ID와 회차 ID를 우선한다.dual-blog-ops는 두 사이트의 공통 규칙을 단일 진실 원천으로 유지한다.- Stream Deck 버튼은 사용자 호출형 스킬의 물리적 트리거로 본다.
댓글
GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.