Matt Pocock이 스킬 29개에 예외 없이 적용한 규칙 — 인기 1위 스킬도 이 공식을 따랐다

1. 핵심 주장 (Core Claims)

• 개발자들은 주기적으로 새로운 "지옥"을 발명해 왔다. 튜토리얼 헬(강의만 듣고 혼자 못 만드는 상태) → 프레임워크 헬(배우는 속도가 새 프레임워크 나오는 속도를 못 따라가는 상태) → 지금은 세 번째, "스킬 헬(Skill Hell)"이다. 스킬은 자유롭게 다운받고 만들 수 있지만, 그 조각들이 어떻게 맞물리는지 모르고, 좋은 스킬과 나쁜 스킬을 구분할 기준 자체가 없다.
• 이 문제는 개인만의 것이 아니라 조직 차원의 문제이기도 하다. 회사가 업무 절차를 에이전트용 스킬로 바꾸려 할 때도 "이건 잘 만든 스킬, 저건 못 만든 스킬"이라 판별할 공유된 잣대가 없다.
• Matt Pocock(토탈 타입스크립트로 유명, 뉴스레터 구독자 6만 명)이 최근 발표한 "좋은 스킬을 쓰는 법"에서 이 문제에 대한 체계적 해법을 제시했다. 핵심은 스킬을 평가하는 4단계 체크리스트: 트리거(Trigger) → 구조(Structure) → 유도(Elicitation) → 가지치기(Pruning).
• 이 체크리스트는 이론에 그치지 않고, Matt Pocock 본인의 스킬 레포(29개 스킬)에 예외 없이 실제로 적용되어 있다. 그 증거로 레포에서 가장 인기 있는 스킬("그릴미/Grill Me")의 본문은 단 한 문장, 프론트매터 포함 20단어에 불과하다. 이는 실수가 아니라 의도된 설계다.
• 스킬의 본질에 대한 정의: 스킬이란 확률적 시스템(LLM)에서 예측 가능성을 짜내는 장치다. 매번 같은 답을 내게 하는 게 아니라, 매번 같은 방식으로 일하게 만드는 것이 목적이다.

2. 근거와 사례 (Evidence & Examples)

체크리스트 1단계 — 트리거 (누가 스킬을 부르는가)

• 스킬 호출 방식은 두 가지: (1) 사용자 호출 — 사용자가 직접 슬래시 명령 등으로 부름, (2) 모델 호출 — 스킬 설명을 에이전트가 항상 인지하고 있다가 상황에 맞으면 스스로 꺼내 씀.
• 얼핏 모델 호출이 우월해 보이지만(에이전트도 부르고 사람도 부를 수 있으니) 숨은 비용이 있다. 모델 호출 스킬은 설명문이 매 요청마다 대화 컨텍스트에 상주한다. 스킬이 100개면 설명 100개가 에이전트 머릿속에 항상 떠 있는 셈이고, 이는 토큰 소모와 에이전트의 인지 부담(발표에서 "컨텍스트 부하"라 칭함)으로 이어진다.
• 반대로 전부 사용자 호출로 만들면 비용이 사용자에게 넘어온다. 어떤 스킬이 있는지, 언제 무엇을 불러야 하는지 사용자가 전부 기억해야 하는 "인지 부하"가 발생한다.
• 즉 이 선택은 "정답 고르기"가 아니라 "부하를 에이전트에게 지울 것인가, 나에게 지울 것인가"의 트레이드오프다.
• 추가로 모델 호출에는 "예측 불가능성"이라는 비용이 붙는다. 설명이 완벽해도 에이전트가 그 스킬을 호출하지 않을 수 있고, 그러면 스킬이 제때 호출되는지 별도로 평가(evals)해야 하는 부담이 생긴다.
• 발표자 본인(Matt Pocock)은 이런 이유로 자기 스킬 대부분을 사용자 호출로 설계한다 — 인지 부하는 본인이 짊어지는 대신, 예측 불가능성이라는 문제 자체를 통째로 제거하는 선택. 반대 사례로 "슈퍼파워즈(Superpowers)"라는 유명 스킬셋은 대부분 모델 호출 방식이라고 언급된다. 둘 중 무엇이 맞다는 게 아니라, 무엇을 포기할지 정하는 문제라는 게 발표의 결론.

체크리스트 2단계 — 구조 (절차 vs 참고 자료)

• 스킬 안에 들어가는 내용물은 크게 두 종류: 절차(Procedure) — 에이전트가 밟을 순서, 참고 자료(Reference) — 그 절차를 돕는 정보.
• 예시: 요구사항 문서를 만드는 스킬이라면 절차는 "맥락 찾기 → 사용자 확인 받기 → 문서 쓰기" 세 단계이고, 참고 자료는 문서 템플릿 같은 것.
• 가장 실용적인 규칙: 스킬 본문은 최대한 작게 유지하라. 작은 스킬은 고치기 쉽고, 감사(audit)하기 쉽고, 단어 하나 줄일 때마다 토큰이 줄어든다.
• 줄이는 기준: 스킬이 쓰이는 경로가 여러 갈래일 때, 특정 갈래에서만 필요한 참고 자료는 본문에서 빼서 별도 파일로 옮긴다. 본문에는 "이 템플릿이 필요하면 이 파일을 봐라"라는 한 줄만 남긴다. 이렇게 하면 필요할 때만 읽히므로 평소엔 토큰을 소모하지 않는다.
• 요약 규칙: 매번 쓰는 자료는 본문에, 가끔 쓰는 자료는 문 뒤(별도 파일)에.

체크리스트 3단계 — 유도 (Elicitation, 발표에서 가장 강조된 기법)

• 스킬을 쓰다 보면 가장 답답한 순간은 "분명히 스킬에 적어놨는데 에이전트가 안 지키는" 상황. 발표의 진단: 문장이 부족한 게 아니라 단어가 약해서다.
• 대표 사례: 에이전트에게 큰 작업을 주면 "층별로(horizontal) 코딩"하는 경향이 있다 — 데이터베이스 전부 짜고, 스키마 전부 짜고, API 전부 짜고, 마지막에 화면. 사람처럼 작은 기능 하나를 끝까지 뚫어서 돌려보고 넓혀가는 방식(vertical)이 아니다.
• 이를 막으려고 "층별로 코딩하지 마, 작은 것부터 만들어"처럼 문장을 길게 늘리는 대신, Matt Pocock은 단어 하나를 심는 방법을 쓴다: "Vertical Slice(수직 슬라이스)"라는 용어. 이 단어는 개발 문화에서 수십 년간 쓰여온 확립된 용어라 모델이 이미 학습해서 알고 있다. 단어 하나가 그 단어에 담긴 행동 방식 전체를 불러오는 효과가 있다.
• 이 기법의 검증 방법도 흥미롭다: 스킬에 "vertical slice"라는 단어를 넣고 나면, 에이전트의 사고 과정(reasoning trace)에 그 단어가 다시 등장하는지 확인할 수 있다. 등장하면 스킬이 제대로 먹힌 것이고, 안 나타나면 더 강한 단어로 교체하면 된다.
• 유도의 두 번째 기법 — "미래를 가려서 쪼개기": 에이전트가 특정 단계에서 항상 대충 하는 문제가 있다. 예: 플랜 모드(plan mode)에서 질문을 몇 개 던지다가 금방 계획서부터 만들어버리는 현상. Matt Pocock은 자신이 시도해본 모든 플랜 모드 구현체에서 동일한 현상을 발견했다고 말한다. 원인은 에이전트 눈에 최종 목표(계획을 써야 한다는 사실)가 처음부터 보이기 때문 — 목표가 보이면 서두르게 된다.
• 해법: 스킬을 단계별로 쪼개서 "미래를 숨긴다." 질문하는 스킬과 계획 쓰는 스킬을 별도로 분리하면, 질문 스킬이 도는 동안 에이전트는 다음에 계획을 써야 한다는 사실 자체를 모른다. 그러니 지금 단계에 충실히 공을 들이게 된다. 요약: "목표를 보여주면 서두르고, 가리면 파고든다."

체크리스트 4단계 — 가지치기 (Pruning)

• 거대해진 스킬 자체는 병이 아니라 증상이다. 안에서 세 가지가 자라고 있다는 신호:
  1. 중복 — 같은 내용이 여러 군데 적혀 있는 것. 모든 내용은 정답 위치가 딱 한 곳이어야 한다.
  2. 퇴적물 — 여러 사람이 스킬 파일에 자기 내용만 추가하고, 남의 것은 지우기 무서워서 못 지우면서 문서 바닥에 쌓이는 죽은 층.
  3. 무동작 문장 — 있어 보이지만 실제로는 에이전트 행동을 하나도 바꾸지 않는 문장. 특히 에이전트에게 스킬 작성을 대신 시키면 이런 문장이 잔뜩 생긴다.
• 무동작 문장을 찾는 방법: 삭제 테스트(Deletion Test). 예를 들어 "커밋 메시지를 길고 자세하게 써라"라는 한 문단이 있다고 치자. 이 문단을 통째로 지워본다. 에이전트가 원래도 훈련되어 있어서 어차피 괜찮은 커밋 메시지를 쓴다면, 그 문단은 토큰만 소모하고 아무 일도 하지 않은 것이다. 지워도 결과가 같으면 그 문장은 애초에 없었던 것과 마찬가지.
• 사람들이 Matt Pocock에게 "스킬을 어떻게 그렇게 작게 유지하냐"고 물으면 답은 항상 같다: "계속 지워보는 것."

레포 실사(實査) — 체크리스트가 실제로 적용된 증거

• 발표자(AgentOS 채널 운영자)는 Matt Pocock의 레포를 통째로 받아 스킬 29개를 전부 열어봤다.
• 가장 인기 있는 스킬 "그릴미(Grill Me)" — 계획을 세우기 전에 에이전트가 사용자를 인터뷰하게 만드는 스킬. 본문 전체가 "그릴링 세션을 실행하라." 딱 이 한 문장뿐이며, 프론트매터까지 합쳐도 20단어다.
• 이게 가능한 이유: 그릴미는 사용자 호출 스킬이라 컨텍스트 부하가 없다. 실제 인터뷰 규칙(질문은 한 번에 하나씩 할 것, 사실은 코드베이스에서 직접 찾고 결정만 사용자에게 물을 것 등)은 "그릴링"이라는 별도의 모델 호출 스킬에 담겨 있다.
• 이 레포는 스킬이 두 층 구조로 나뉘어 있다: 위층엔 한 문장짜리 호출 버튼들, 아래층엔 재사용되는 규율(TDD, 도메인 모델링 등)들. 문서 작성 스킬도, 구현 스킬도 모두 아래층 스킬을 불러다 쓴다. 심지어 규칙까지 있다: 위층 스킬은 아래층만 부를 수 있고, 위층끼리는 서로 부를 수 없다.
• 도그푸딩 사례: 레포 루트에 "컨텍스트(Context).md" 파일이 있는데, 스킬들이 사용자에게 가르치려는 바로 그 "용어집 만들기" 원칙을 레포 자체에도 적용해 뒀다. "이슈 트래커"라는 용어의 정의, 대신 쓰면 안 되는 단어 목록, 심지어 "백로그"라는 단어가 두 가지 뜻으로 쓰여서 혼란스러웠던 걸 정리한 기록까지 남아 있다.
• 폐기된 스킬들을 모아둔 폴더가 있고, 거기서 초기 스킬이 어떻게 지금의 스킬로 흡수됐는지 진화 과정을 볼 수 있다. 커밋 기록에도 "흔적 지우기", "문단 하나로 합치기", "중복 제거" 같은 가지치기 커밋이 계속 쌓여 있다 — 삭제 테스트를 말로만 하는 게 아니라 실제로 매일 돌리고 있다는 증거.

마지막 패턴 — 고전에서 온 용어들

• 스킬들을 쭉 살펴보면 마지막 패턴이 보인다: Matt Pocock의 스킬에는 새로운 개념이 거의 없다. 인터뷰로 요구사항 좁히기, 테스트 먼저 쓰기(TDD), 용어집 만들기, 코드 스멜 목록으로 리뷰하기 등, 전부 수십 년 된 소프트웨어 공학 고전에서 온 개념들이다 (실용주의 프로그래머, 도메인 주도 설계, 리팩토링 등).
• 이게 우연이 아닌 이유: 그 고전들의 용어는 모델이 이미 깊게 학습한 단어들이기 때문. 그래서 이 사람의 사고 연쇄는 다음과 같이 정리된다: 에이전트의 실패를 관찰한다 → 고전에서 대응하는 처방을 찾는다 → 그 처방을 모델이 이미 아는 단어로 압축한다 → 최소한의 스킬로 적는다 → 에이전트의 사고 과정을 보며 확인한다 → 계속 지운다.

3. 구조화된 시사점 (Structured Insights)

• 트리거 선택은 책임 소재 결정이다. 스킬을 모델 호출로 만들지 사용자 호출로 만들지는 기능 선택이 아니라, 컨텍스트 부하(에이전트가 짊어짐)와 인지 부하(사용자가 짊어짐) 중 어느 쪽을 택할지의 조직적 결정이다. 예측 불가능성 비용까지 고려하면, 특별한 이유가 없는 한 사용자 호출을 기본값으로 삼는 편이 안전하다.
• 좋은 스킬은 "절차"와 "참고 자료"를 분리하는 것에서 시작한다. 이 둘을 섞어 놓으면 본문이 비대해지고, 매번 쓰지 않는 정보까지 매번 토큰을 태우게 된다.
• 강한 단어(strong word) 하나가 긴 설명보다 효과적이다. 모델이 이미 학습한 확립된 업계 용어(vertical slice, TDD, code smell 등)를 스킬에 심으면, 그 단어가 담고 있는 행동 패턴 전체를 불러올 수 있다. 이는 프롬프트 엔지니어링의 "설명을 늘리는" 접근과 정반대다.
• 에이전트에게 목표를 숨기는 것이 곧 품질 관리 기법이다. 최종 목표가 보이면 에이전트는 서두르고 대충한다. 단계를 쪼개서 각 단계가 다음 단계의 존재를 모르게 만들면, 각 단계에 더 깊이 몰입한다.
• 스킬의 검증은 산출물이 아니라 사고 과정(reasoning trace)을 보는 것이다. 심어놓은 핵심 단어가 에이전트의 추론 과정에 다시 나타나는지를 관찰하면, 스킬이 실제로 작동하는지 여부를 직접 확인할 수 있다.
• 삭제 테스트는 스킬 유지보수의 핵심 루틴이다. 문장을 지워도 결과가 달라지지 않는다면 그 문장은 처음부터 무의미했던 것. 이는 "추가"보다 "삭제"가 스킬 품질을 높이는 주된 동력이라는 뜻이다.
• 좋은 스킬 레포는 계층 구조를 갖는다. 사용자 대면 "호출 버튼" 계층과, 재사용 가능한 "규율/원칙" 계층을 분리하고, 상위 계층이 하위 계층만 참조하도록 강제하면 중복과 결합도를 억제할 수 있다.
• 스킬 자체가 조직의 용어집(glossary) 역할을 해야 한다. 레포/조직 차원에서 핵심 용어의 정의와 금지어 목록을 문서화해두면, 스킬을 쓰는 사람과 스킬을 만드는 사람 모두의 혼선을 줄인다.
• 새로운 방법론보다 소프트웨어 공학 고전을 압축하는 것이 스킬 설계의 본질에 가깝다. LLM이 이미 방대하게 학습한 확립된 개념(리팩토링, DDD, TDD, 실용주의 프로그래머의 원칙들)을 재발견해 짧게 압축하는 것이, 새 개념을 만들어내는 것보다 신뢰도 높은 스킬을 만든다.

4. 실행 포인트 (Action Points)

1. 보유 중인 스킬들을 트리거 방식(모델 호출 vs 사용자 호출) 기준으로 재분류하고, 특별한 이유 없이 모델 호출로 되어 있는 스킬은 사용자 호출로 전환을 검토한다.
2. 각 스킬 본문에서 "절차"와 "참고 자료"를 분리한다. 자주 쓰지 않는 참고 자료(템플릿, 예시 등)는 별도 파일로 빼고 본문엔 "필요하면 이 파일을 봐라" 한 줄만 남긴다.
3. 스킬 안의 장황한 지시문("~하지 마라, ~해야 한다" 식의 긴 문장)을 찾아, 업계에 확립된 강한 단어(예: vertical slice, TDD, code smell, DDD 용어 등)로 대체할 수 있는지 검토한다.
4. 에이전트가 특정 단계에서 대충 넘어가는 패턴이 관찰되면(예: 플랜 모드에서 질문을 대충 하고 계획으로 직행), 해당 스킬을 여러 단계로 쪼개서 뒷단계의 존재를 앞단계에서 숨기는 구조로 재설계한다.
5. 새 단어/문장을 스킬에 심을 때는 에이전트의 reasoning trace(사고 과정)에 그 단어가 다시 등장하는지 확인해서 효과를 검증하는 습관을 들인다.
6. 정기적으로 "삭제 테스트"를 돌린다 — 의심스러운 문장/문단을 지워보고 결과가 달라지는지 확인, 달라지지 않으면 영구 삭제한다.
7. 스킬 레포에 자체 "용어집" 문서(핵심 용어 정의 + 금지어 목록)를 만들어, 스킬을 만들거나 쓰는 모든 사람이 같은 언어를 쓰도록 한다.
8. 스킬을 상위(호출 버튼)/하위(재사용 규율) 두 계층으로 재구성하고, 상위 스킬이 상위 스킬을 직접 부르지 못하도록 하는 규칙을 세운다.
9. 소프트웨어 공학 고전(실용주의 프로그래머, 도메인 주도 설계, 리팩토링 등)을 다시 훑으며, 현재 팀이 겪는 에이전트 실패 패턴에 대응하는 고전적 처방이 있는지 찾아보고 이를 스킬 언어로 압축하는 연습을 한다.

핵심 요약 (20줄)

1. AgentOS 채널이 Matt Pocock(토탈 타입스크립트 저자)의 스킬 레포를 분석해 좋은 스킬을 가르는 4단계 체크리스트를 정리한 영상이다.
2. 개발자들은 튜토리얼 헬, 프레임워크 헬에 이어 이제 "스킬 헬"에 들어섰다 — 스킬은 많은데 좋고 나쁨을 가릴 기준이 없다는 문제다.
3. 체크리스트 1단계는 트리거다. 스킬을 모델이 스스로 호출하게 할지, 사용자가 직접 호출하게 할지를 정해야 한다.
4. 모델 호출은 매 요청마다 설명이 컨텍스트에 상주해 토큰과 에이전트 인지 부담(컨텍스트 부하)이 커진다.
5. 사용자 호출은 반대로 어떤 스킬을 언제 부를지 사용자가 기억해야 하는 인지 부하를 만든다.
6. 모델 호출에는 추가로 예측 불가능성 비용이 있다. 설명이 완벽해도 에이전트가 스킬을 호출하지 않을 수 있다.
7. Matt Pocock은 이런 이유로 대부분의 스킬을 사용자 호출로 설계하며, 슈퍼파워즈 같은 다른 유명 스킬셋은 반대로 모델 호출 위주다.
8. 체크리스트 2단계는 구조다. 스킬 내용은 절차(순서)와 참고 자료(부가 정보)로 나뉘며, 자주 안 쓰는 참고 자료는 별도 파일로 빼고 본문은 최대한 작게 유지해야 한다.
9. 체크리스트 3단계는 유도다. 에이전트가 지시를 안 따르는 건 문장이 부족해서가 아니라 단어가 약해서라는 진단이다.
10. 해법은 설명을 늘리는 대신 "vertical slice" 같은 업계에 확립된 강한 단어를 심어 그 단어가 담은 행동 패턴 전체를 불러오는 것이다.
11. 이 기법은 에이전트의 사고 과정(reasoning trace)에 그 단어가 다시 나타나는지로 효과를 검증할 수 있다.
12. 유도의 두 번째 기법은 미래를 숨기는 것이다. 플랜 모드에서 에이전트가 질문을 대충 하는 이유는 최종 목표(계획 작성)가 미리 보이기 때문이다.
13. 질문 스킬과 계획 스킬을 분리해 다음 단계를 숨기면, 에이전트가 지금 단계에 더 충실해진다.
14. 체크리스트 4단계는 가지치기다. 비대해진 스킬은 중복, 퇴적물, 무동작 문장이라는 세 가지 문제의 증상이다.
15. 무동작 문장은 삭제 테스트로 찾는다. 문장을 지워도 에이전트 행동이 같으면 그 문장은 원래부터 무의미했던 것이다.
16. 발표자가 Matt Pocock의 레포 29개 스킬을 직접 열어보니 체크리스트가 예외 없이 적용돼 있었다.
17. 가장 인기 있는 스킬 "그릴미"는 본문이 "그릴링 세션을 실행하라" 한 문장, 프론트매터 포함 20단어뿐이며, 실제 규칙은 별도의 모델 호출 스킬 "그릴링"에 담겨 있다.
18. 레포는 위층(한 문장짜리 호출 버튼)과 아래층(재사용 규율)의 2계층 구조이며, 위층 스킬끼리는 서로 부를 수 없다는 규칙이 있다.
19. 레포 루트의 컨텍스트 문서에 용어 정의와 금지어 목록을 두어 스킬이 가르치는 원칙을 레포 자신에게도 적용하는 도그푸딩을 실천하고 있다.
20. 마지막 통찰은 스킬이 확률적 시스템에서 예측 가능성을 짜내는 장치라는 정의이며, 매번 같은 방식으로 일하게 만드는 것이 목적이라는 결론으로 영상을 맺는다.