[한영자막] Matt Pocock 스킬, 이번 업데이트로 확 달라졌다

메타데이터

• URL: https://www.youtube.com/watch?v=sZrFaPMau6A
• 날짜: 2026-08-11
• 채널: Tech Bridge
• 크론 분류: latentspacepod
• 영상 길이: 10분 54초
• 분석 기준: 영어 자동 생성 자막(English auto captions)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==Matt Pocock의 엔지니어링 스킬 저장소 v1.2.0은 문서화·배포·Codex 호환성을 보강하고, 에이전트가 더 명확하게 말하고 인간과 더 쉽게 협업하도록 워크플로 자체를 확장한다.==

• GitHub 저장소가 약 204K stars를 기록하며 성숙한 프로젝트가 되었고, 이를 뒷받침하는 공식 문서 사이트가 생겼다.
• Claude Code 공식 플러그인 마켓플레이스와 Codex용 openai.yaml을 통해 설치와 호출 제어가 쉬워졌다.
• wait what, 다중 질문형 Grill Me, writing for agents, wizard, two questionnaire가 각각 언어 명료화·탐색 속도·설정 품질·안전한 인프라 프로비저닝·비에이전트 사용자와의 협업을 해결한다.

이 업데이트는 스킬 파일을 추가한 수준을 넘어, 에이전트의 행동을 설계하는 문서와 사람-에이전트 협업 경계를 정리한 릴리스다. 발표자는 특히 Opus가 장황하거나 알아듣기 어려운 말을 할 때 wait what을 호출하면 즉시 실용적인 언어로 다시 답하게 만들 수 있다고 강조한다.

1. v1.2.0과 공식 문서 사이트

v1.2.0은 규모가 커진 스킬 프로젝트에 필요한 탐색·학습·참조 기반을 함께 제공한다.

1.1. 성숙한 저장소를 문서화하다

1. 프로젝트의 규모와 배경

   1. 스킬의 반복적 확장: 발표자는 “Skills, skills, skills”라고 시작하며 더 많은 스킬이 추가되었다고 소개한다.
   2. GitHub 인기: 저장소는 발표 시점에 역대 GitHub starred repository 중 24위라고 설명하며, 약 204K stars를 기록했다고 말한다.

2. 문서화의 필요성

   1. 성숙 프로젝트의 다음 단계: 프로젝트가 커진 만큼 제대로 된 documentation이 필요해졌고, v1.2.0에서 그 문서를 공개했다.
   2. 발표자의 경험: 발표자는 과거에 documentation 작성이 실제 full-time job이었으며, 문서 작업으로 돌아가는 일이 즐거웠다고 말한다.

1.2. aihero.dev/skills의 구조와 학습 경로

1. 메인 페이지를 중심으로 탐색한다

   1. 접근 경로: 문서 사이트는 aihero.dev/skills이며, 가장 좋은 시작점은 메인 /skills 페이지다.
   2. 주요 흐름: 왼쪽의 main flow에서 grill with docs → spec → ticket → implement → code review 순서로 엔지니어링 작업 흐름을 볼 수 있다.

2. 참조 자료를 함께 제공한다

   1. 전체 스킬 참조: 왼쪽 패널에서 모든 스킬과 각 스킬의 역할을 확인할 수 있다.
   2. 공통 질문: common questions 목록은 발표자가 관리하는 personal wiki에서 사람들이 실제로 질문한 내용을 가져온 것이다.
   3. AI coding dictionary: 질문과 문서는 발표자가 만드는 AI coding dictionary로 연결되며, 예를 들어 ticket이 무엇인지에 대한 발표자의 정의를 볼 수 있다.

3. 문서의 이중 목적

   1. 스킬 사용법 학습: 사용자는 자신의 스킬을 더 잘 사용하는 방법을 배울 수 있다.
   2. AI coding 자체 학습: 특정 저장소의 사용 설명을 넘어 AI 코딩이 어떻게 작동하는지 깊이 이해하는 입문·참조 자료로도 쓸 수 있다.

2. Claude Code와 Codex를 위한 배포 개선

v1.2.0은 특정 harness에 종속되지 않도록 설치 방식과 스킬 호출 정책을 명시적으로 다룬다.

2.1. Claude Code 공식 플러그인 마켓플레이스

1. 공식 채널에 편입되다

   1. 검색: Claude Code를 열고 plugin 기능에서 Matt Pocock 또는 Matt Pocock skills를 검색할 수 있다.
   2. 설치: 검색 결과에서 바로 설치할 수 있으므로 별도의 수동 단계가 없다.

2. 설치 후 동작

   1. read-only bundle: 설치 결과는 read-only bundle로 제공된다.
   2. 자동 업데이트: 발표자가 스킬을 업데이트하면 사용자의 설치본에 변경 사항이 자동으로 내려온다.

2.2. Codex 호환성과 implicit invocation 제어

1. 스킬별 openai.yaml

   1. 파일 제공: 모든 스킬에 openai.yaml sidecar file을 포함했다.
   2. UI 호환: 이 파일 덕분에 Codex UI 같은 OpenAI 계열 UI에서도 스킬이 out of the box로 동작해야 한다.

2. 호출 방식의 차이

   1. 두 종류의 호출: 기존에는 model-invoked skill과 user-invoked skill이 있었다.
   2. user-invoked의 장점: SKILL.md 안에서 user-invoked로 표시된 스킬은 사용자가 직접 호출하기 전까지 에이전트의 context window에 숨겨진다.

3. Codex에서 발생한 문제와 해결

   1. 지원 범위의 오해: 이 방식은 Claude Code, Pi, 그리고 몇몇 harness에서는 작동하지만 Codex에서는 작동하지 않았고, 발표자는 이를 처음에는 충분히 인지하지 못했다고 말한다.
   2. sidecar의 역할: 각 스킬에 allow implicit invocation: false를 담은 openai.yaml을 배포해 Codex에서도 명시적 사용자 호출 정책이 그대로 적용되도록 했다.

3. wait what: 장황하고 모호한 모델 응답을 다시 쓰기

발표자는 특히 Opus, 그중에서도 “Opus 5”가 현재 지나치게 장황하고 이해하기 어려운 말을 하는 문제를 해결하기 위해 짧은 호출형 스킬을 만들었다.

3.1. 문제의 증상과 기존 접근의 한계

1. Opus 응답의 문제

   1. 과도한 verbosity: 모델이 매우 장황하며, 일반적인 사람이 실제로 쓰지 않는 이상한 LLM 표현을 사용한다.
   2. 이해 불능 상태: 발표자는 Opus와 대화할 때 말이 머리를 그대로 넘어가는 느낌이고 읽기 매우 어렵다고 말한다.

2. 기존 해결책의 실패

   1. output style: 출력 스타일을 바꾸는 방식을 시도했다.
   2. agent.md 보강: agent.md에 지시를 추가하는 방식도 시도했지만 충분하지 않았다.
   3. 자막 오류 구간: 이 대목 뒤에 “The honest options are to accept it and reword the AC or to persist the digest along the export...”처럼 앞뒤 맥락과 맞지 않는 문장이 삽입되어 있다. 이는 자동 자막의 혼입·오인식으로 보이며, 발표자의 실제 wait what 설명으로 해석하지 않아야 한다.

3.2. 호출 규칙과 언어적 해결책

1. 간단한 호출

   1. 의도: 사용자가 “Wait, what did you just say?”라고 물으면 모델이 방금 한 말을 더 나은 방식으로 다시 답하게 한다.
   2. 호출어: 실제 사용 시에는 짧게 Wait, what?이라고 말하면 된다.

2. 스킬이 요구하는 출력

   1. 명확한 문장: 특정 standard를 사용해 매우 쉬운 언어와 clear declarative sentences로 말하도록 지시한다.
   2. 프로젝트 언어: context.md의 ubiquitous language에 답변을 grounding한다.

3. verbosity의 근본 처방

   1. 단순화만으로는 부족하다: 모델에게 “simple language를 써라”라고 말하는 것만이 진짜 해결책은 아니다.
   2. 사용자의 언어를 사용한다: 발표자는 Grill with Docs에서 사용자가 함께 정립한 언어를 쓰게 하는 것이 verbosity를 줄이는 진짜 처방이라고 말한다.

4. Grill Me: 한 번에 하나에서 질문 라운드로

가장 인기 있는 스킬 중 하나인 Grill Me는 질문 간 의존성을 보존하면서도 쉬운 질문을 빠르게 처리하도록 바뀌었다.

4.1. 기존 방식의 병목

1. one question per turn

   1. 이전 흐름: 에이전트가 질문 하나를 하고 사용자가 답하면, 다음 질문 하나를 하는 순서였다.
   2. 장점: 뒤 질문이 앞 질문에 의존해도 항상 앞 질문이 먼저 답변되므로 순서 혼동이 없었다.

2. 끝부분의 failure mode

   1. 쉬운 질문의 잔여: 어려운 작업이 대부분 끝난 뒤에는 “Yeah, that sounds good” 수준의 쉬운 질문만 남는다.
   2. 사용자 경험 저하: 이 질문들을 한 턴에 하나씩 처리하면 세션이 죽은 듯 느리고 불필요하게 느려진다.

4.2. 질문 그래프와 라운드형 처리

1. 여러 질문을 한 턴에 처리한다

   1. 속도 향상: 독립적인 질문이 많다면 사용자는 “Yes, yes, yes, yes”처럼 한 번에 답할 수 있다.
   2. 의존성 보존: 질문 3의 답이 질문 1의 답에 의존하는 문제는 질문을 무작정 모두 보여주지 않고 graph로 모델링해 해결한다.

2. available question만 묻는다

   1. frontier 탐색: 시작점에는 먼저 답해야 하는 critical question이 하나 있을 수 있고, 그 답이 여러 질문을 열며, 그 질문들이 다시 다음 질문을 열 수 있다.
   2. 라운드 진행: 현재 답할 수 있는 질문만 한 라운드로 묻고, 답변으로 열린 다음 질문을 다음 라운드에 묻는다.
   3. 최대한 빠른 전진: 시스템은 질문 graph의 frontier를 가능한 한 빠르게 뒤로 밀어 세션을 진행한다.

3. 화면과 입력 방식

   1. 시각적 구분: 화면에는 round one, Q1, 추천 답변, Q2와 추천 답변이 보인다.
   2. emoji 사용: 발표자는 emoji를 좋아하지 않을 수도 있다는 점을 알면서도 눈으로 빠르게 찾을 수 있는 색상 표지로 emoji를 사용한다.
   3. dictation과 결합: 발표자는 받아쓰기(dictation)를 사용해 “Q1, I agree. Q2, I agree. Q3, 바꿔야 한다...”처럼 여러 답을 연속으로 말할 수 있다.
   4. 다음 라운드: 첫 라운드가 끝나면 열려 있는 질문으로 round two가 생성되고 같은 형식으로 계속 진행된다.

5. writing for agents: 스킬을 넘어 에이전트 설정을 쓰는 법

기존의 writing great skills 스킬은 실제 사용 범위가 넓어져 writing for agents로 확장되었다.

5.1. 적용 대상의 확장

1. 스킬 외 문서까지 다룬다

   1. 에이전트 입력 개선: 에이전트가 읽는 어떤 텍스트든 더 나은 성능, 더 간결한 문서, 더 예측 가능한 출력을 만들기 위해 사용한다.
   2. 설정 파일: agents.md나 Claude.md를 작성·편집할 때 적용한다.

2. 스킬 제작과 편집

   1. 스킬 작성: 새 스킬을 만들거나 기존 스킬을 편집하는 작업에 사용할 수 있다.
   2. skill mechanics: reference file 안에 스킬의 동작 메커니즘에 관한 추가 지침을 붙여 두었다.

5.2. front-loading을 줄이는 사용법

1. agents.md를 스킬로 분리한다

   1. 문제: 모든 지침을 agents.md에 넣으면 매번 에이전트 context에 전부 앞부분부터 실린다.
   2. 해결: agents.md의 내용을 필요한 스킬로 뽑아내면 끔찍한 front-loading을 줄일 수 있다.

2. 호출과 설명

   1. 빈번한 도구: 발표자는 에이전트 configuration을 작성할 때 이 스킬을 매우 자주 사용한다고 말한다.
   2. model-invocable: 이 스킬은 model-invocable이며, agents.md를 수정할 때 가져오기 좋은 깔끔한 description을 갖고 있다.

6. wizard: 사람이 해야 할 단계를 안전하게 안내하는 대화형 Bash 도구

wizard는 에이전트에게 민감한 인프라 프로비저닝을 맡기지 않고도 사람이 복잡한 절차를 빠르게 수행하도록 만드는 새 스킬이다.

6.1. AWS 프로비저닝에서 출발한 문제

1. 발표자의 불편

   1. 반복 작업: 최근 여러 인프라를 프로비저닝하고 AWS 절차를 따라가야 했는데, 이를 매우 싫어했다.
   2. 자동화의 경계: computer use로 에이전트가 AWS에 들어가 프로비저닝하게 만들 수도 있었지만, 모든 것을 에이전트에게 맡기는 방식은 불편하고 꺼림칙했다.

2. wizard의 목적

   1. interactive Bash wizard 생성: 사람이 직접 수행해야 하는 단계만 골라 대화형 Bash wizard를 만든다.
   2. 통제권 유지: 사용자는 각 단계와 자격 증명을 직접 통제하면서도, 어디로 가서 무엇을 바꿔야 하는지 안내받는다.

6.2. remote box 설정 사례

1. 단계별 진행

   1. 시작: remote box setup으로 이전하는 사례에서 wizard를 실행한 뒤 “ready to start?”에 “Yes, please”라고 답한다.
   2. 정확한 화면으로 이동: 스크립트가 사용자가 해야 할 정확한 페이지를 열어 주므로 직접 탐색할 필요가 없다.
   3. 로그인과 설정 변경: 로그인하고, 지정된 정확한 값을 변경하는 단계로 안내한다.

2. 비밀값과 저장

   1. API key 입력: 사용자가 API key를 직접 붙여넣는다.
   2. 파일 저장: wizard가 필요한 파일에 값을 저장한다.
   3. GitHub secrets: 필요한 경우 GitHub secrets에도 값을 저장한다.

3. 결정론적 실행

   1. 에이전트 미개입: 이 스크립트는 deterministic script이므로 실행 중인 에이전트가 없다.
   2. 외부 전송 없음: Anthropic 등으로 작업을 전송하지 않으며, UI가 각 단계를 끝까지 안내한다.

6.3. 사용 가치

1. 프로비저닝 경험의 변화
   1. 고통에서 즐거움으로: 발표자는 과거 프로비저닝에 걸린 시간을 알고 있기 때문에, wizard가 이를 “incredibly painful”에서 “weirdly joyful”로 바꾼다고 말한다.
   2. 핵심 스킬로 정착: 몇 달 동안 in progress 상태로 두었던 기능이 이제 자신의 필수 스킬 세트가 되었다고 설명한다.

7. two questionnaire: 에이전트의 질문을 사람과 공유하기

two questionnaire는 이름은 가장 지루하지만, grilling session에서 나온 결정을 에이전트 밖의 문서로 옮겨 공동 의사결정을 돕는 스킬이다.

7.1. garden office 사례

1. 질문을 문서로 추출한다

   1. Wayfinder session: 발표자는 뒷마당에 garden office를 짓기 위해 에이전트의 grilling을 받고 있었다.
   2. 협업 상대의 부재: 그 공간을 함께 사용할 아내와 설계해야 했지만, 에이전트는 발표자에게만 질문하고 있었다.

2. 문서 기반 공동 설계

   1. Markdown 변환: 에이전트가 grilling session에서 물어볼 질문과 결정 항목을 Markdown 문서로 바꾸게 했다.
   2. Google Docs 공유: 문서를 Google Doc으로 옮겨 아내에게 보내고, 두 사람이 함께 질문을 검토하며 답을 정했다.
   3. 에이전트로 반환: 사람 사이에서 합의한 답변을 다시 agents에 가져와 다음 작업에 반영했다.

7.2. 현재 협업 생태계의 임시 패치

1. 언젠가 삭제하고 싶은 스킬

   1. 근본 원인: 발표자는 에이전트와 협업하기 어려운 현재 상황을 보완하는 patch이기 때문에 언젠가 이 스킬을 삭제하고 싶다고 말한다.
   2. 문서의 역할: 질문을 그대로 꺼내 다른 사람에게 보여 주고 Google Docs 등에서 comment를 받는 단순한 방식이 실제로 유용하다.

2. AI-native 팀과 그렇지 않은 사람들

   1. 이상적인 팀 환경: 좋은 설정을 가진 팀은 Slack 안에 에이전트를 두고 대화에 tag하며, stakeholder와 함께 답하고 에이전트가 합의된 내용을 바탕으로 구현한다.
   2. 현실의 제약: 많은 사람은 아직 AI-native가 아니며 Slack이나 Microsoft Teams조차 쓰지 않을 수 있다.
   3. 현재의 실용적 해법: 그런 사용자에게는 일반 문서로 질문을 전달하고 코멘트를 받아 다시 에이전트에 넣는 방식이 더 접근성이 높다.

주요 발언 모음

“Skills, skills, skills, folks. We have yet more skills for you.”

“Wait, what did you just say?”

“The real cure for verbosity is not to tell it to use simple language; it is to tell it to use your language.”

“I found that this takes provisioning services from incredibly painful to weirdly joyful.”

“I hope someday to delete [two questionnaire], because it’s sort of like a patch for the fact that agents are kind of hard to collaborate with at the moment.”

핵심 데이터 & 수치

• 릴리스: v1.2.0이다.
• GitHub 인기: 발표자는 저장소가 역대 GitHub starred repository 중 24위이며 약 204K stars라고 설명한다.
• 기존 Grill Me 단위: 이전에는 한 turn에 질문 하나만 처리했다.
• Grill Me 새 단위: 이제 의존성 graph의 현재 frontier를 기준으로 여러 질문을 round 단위로 묻는다.
• 주요 배포 대상: Claude Code 공식 plugin marketplace와 Codex UI다.
• Codex 메타데이터: 모든 스킬에 openai.yaml sidecar를 추가하고 allow implicit invocation: false를 전달한다.
• 문서화 주소: aihero.dev/skills의 /skills 페이지다.
• 대표 workflow: grill with docs → spec → ticket → implement → code review의 5단계 흐름이다.
• 영상 분량: 10분 54초다.

결론 및 시사점

1. 스킬은 실행 코드만이 아니다: 성숙한 스킬 프로젝트에는 문서 사이트·공통 질문·용어 사전·호출 정책까지 포함된 사용 체계가 필요하다.
2. 컨텍스트는 필요한 때만 넣어라: agents.md에 모든 지침을 넣는 대신 스킬로 분리하면 context window의 front-loading을 줄이고 작업별 지침을 재사용할 수 있다.
3. 명시적 호출은 품질과 비용을 함께 관리한다: allow implicit invocation: false는 사용자가 필요한 스킬만 불러오게 해 Codex에서도 컨텍스트를 통제한다.
4. 좋은 에이전트 UX는 질문 그래프를 이해한다: 다중 질문은 단순히 질문을 많이 던지는 기능이 아니라, 의존성 graph에서 현재 답할 수 있는 frontier만 라운드로 제시하는 방식이어야 한다.
5. 민감한 작업은 결정론적 안내가 유용하다: AWS·API key·GitHub secrets처럼 사람이 통제해야 하는 작업에는 에이전트의 자율 실행보다 사람이 직접 수행하는 Bash wizard가 더 신뢰할 만할 수 있다.
6. 비-AI-native 협업자를 잊지 마라: Slack 기반 에이전트 협업이 이상적이어도, Google Docs로 질문을 공유하고 답을 되가져오는 two questionnaire 같은 중간 계층이 실제 팀에 더 넓게 적용된다.
7. 이번 릴리스의 핵심 변화: v1.2.0은 스킬 수를 늘리는 업데이트인 동시에, 모델의 말하기 방식·설정 문서·설치 채널·인간 협업을 함께 재설계한 업데이트다.
8. 추가 변경 사항: 영상에서 다루기에는 작은 변경도 있으므로 전체 changelog는 GitHub의 v1.2.0 release에서 확인할 수 있다.