![[ Smartech] 여행, 캠핑, IT](https://tistory1.daumcdn.net/tistory/482704/skinSetting/e4340fb5634041f8a996941214d9a17a)
AI가 코드 짜기 전에 나부터 인터뷰한다? 깃허브 30만 스타 mattpocock/skills(매트 포콕 스킬) 설치·사용법·활용 사례 총정리
2026. 10. 26. 18:23ㆍAI/AI 스킬·플러그인
Claude Code나 Codex에게 기능 하나 만들어 달라고 했는데,
막상 결과물을 보니 내가 원한 거랑 전혀 다른 걸 만들어 놓은 경험, 한 번쯤 있으시죠?
AI가 멍청해서라기보다는 내 머릿속 생각이 AI에게 제대로 전달되지 않아서인 경우가 많아요.
사실 사람끼리 일할 때도 똑같은 문제가 생기잖아요.
오늘 소개할 mattpocock/skills(매트 포콕 스킬)은 바로 이 문제를 정면으로 다루는 AI 코딩 스킬 모음이에요.
타입스크립트 강의로 유명한 매트 포콕(Matt Pocock)이 매일 실제로 쓰는 스킬을 그대로 공개한 저장소인데,
2026년 10월 26일 기준 깃허브 스타가 약 30.3만 개나 될 만큼 개발자들 사이에서 화제예요.
오늘은 이 스킬이 뭔지, 장단점은 뭔지, 어떻게 설치하고 쓰는지,
그리고 실제 개발자들이 어떻게 활용하고 있는지까지 쉽게 정리해 볼게요.
한 줄 요약
mattpocock/skills는 매트 포콕이 공개한 MIT 라이선스의 무료 AI 코딩 에이전트 스킬 모음이에요. Claude Code, Codex, GitHub Copilot, Gemini CLI, Cursor 등에서 쓸 수 있어요.
핵심은 AI가 코드를 짜기 전에 사용자를 집요하게 인터뷰하는 /grill-me와, 인터뷰 → 스펙 → 티켓 → 구현(TDD) → 코드 리뷰로 이어지는 메인 플로우예요. 설치는npx skills@latest add mattpocock/skills한 줄, 그다음 저장소마다/setup-matt-pocock-skills를 한 번 실행하면 끝이에요.
1. mattpocock/skills가 뭐예요? 쉽게 설명하면
먼저 '스킬(Skill)'이 뭔지부터 짚고 갈게요.
스킬은 AI 에이전트에게 주는 업무 매뉴얼 같은 거예요.
SKILL.md라는 마크다운 파일에 "이런 상황에선 이런 순서로 일해"라는 지침이 적혀 있고,
AI가 이걸 읽고 그대로 따라 해요.
mattpocock/skills는 이런 매뉴얼을 모아 둔 저장소예요.
저장소 소개 문구가 "Skills for Real Engineers. Straight from my .agents directory."인데,
말 그대로 매트 포콕이 자기 작업 폴더에서 매일 쓰는 스킬을 꺼내 공개한 거예요.
README는 이 스킬들을 "바이브 코딩이 아니라 진짜 엔지니어링을 위해 매일 쓰는 스킬"이라고 소개해요.
AI에게 대충 시키고 결과를 기도하는 방식이 아니라,
소프트웨어 공학의 기본기를 AI 작업 방식에 그대로 녹인 게 가장 큰 특징이에요.
만든 사람, 매트 포콕은 누구?
매트 포콕은 타입스크립트 강의 Total TypeScript로 유명한 개발 교육자예요.
The Pragmatic Engineer 인터뷰에 따르면 Total TypeScript는 누적 250만 달러 넘게 팔렸고,
지금은 AI 코딩 교육 사이트 AI Hero를 운영하고 있어요.
재미있는 건 원래 성악과 발성을 가르치던 선생님이었다는 점이에요.
그래서인지 이 저장소에는 사람과 AI 사이의 소통을 다루는 스킬이 특히 강해요.
| 항목 | 내용 |
| 저장소 | github.com/mattpocock/skills |
| 만든 사람 | Matt Pocock (Total TypeScript, AI Hero) |
| 라이선스 | MIT (무료, 수정과 재배포 가능) |
| 첫 공개 | 2026년 2월 3일 |
| 깃허브 스타 | 약 30.3만 개 (2026.10.26 기준) |
| 최신 버전 | v1.3.1 |
| 공식 스킬 수 | 27개 (aihero.dev 기준) |
| 지원 에이전트 | Claude Code, Codex, GitHub Copilot, Gemini CLI, Cursor, OpenCode, Windsurf 등 |
| 공식 사이트 | aihero.dev/skills |
2. 왜 이렇게 인기일까? AI 코딩의 4가지 실패를 고쳐 줘요
README는 기능을 나열하는 대신, AI로 개발할 때 자주 겪는 4가지 실패 상황과
그 해결책을 짝지어 설명해요. 이 구조만 알아도 저장소 전체가 한눈에 들어와요.
| 실패 상황 | 왜 생길까 | 해결 스킬 |
| AI가 내가 원한 걸 안 만들었다 | 내 의도와 AI의 이해 사이에 소통 격차가 있어서 | /grill-me, /grill-with-docs |
| AI 말이 너무 장황하다 | 프로젝트 용어를 AI가 매번 추측해서 | /grill-with-docs (공유 용어집) |
| 코드가 안 돌아간다 | AI가 결과를 확인할 피드백 루프가 없어서 | /tdd, /diagnosing-bugs |
| 코드가 진흙탕이 됐다 | AI가 코딩 속도만큼 복잡도도 빨리 키워서 | /to-spec, /improve-codebase-architecture |
특징 1. AI가 먼저 나를 인터뷰하는 '그릴링'
이 저장소에서 가장 유명한 스킬이 /grill-me예요.
grill은 영어로 "꼬치꼬치 캐묻다"라는 뜻인데, 이름 그대로 AI가 코드를 짜기 전에 나에게 질문을 쏟아내요.
계획을 하나의 설계 트리로 보고, 지금 바로 답할 수 있는 질문들을 번호를 붙여 한 라운드로 묶어 물어봐요.
질문마다 AI가 추천하는 답이 같이 붙어 있어서, 동의하면 "yes"라고만 답해도 돼요.
또 하나의 원칙은 "사실은 AI가 찾고, 결정은 사람이 한다"예요.
코드나 파일을 찾아보면 알 수 있는 건 AI가 직접 확인하고, 사람에게는 정말 결정이 필요한 것만 물어봐요.
놀라운 건 파일 크기예요. 위 화면처럼 grill-me 스킬은 단 7줄짜리 파일이고,
실제 인터뷰 규칙은 grilling이라는 공용 스킬에 따로 들어 있어요.
작은 조각을 레고처럼 조립하는 구조라서 읽기도, 고쳐 쓰기도 쉬워요.
특징 2. 프로젝트 공용 용어집, GLOSSARY.md
/grill-with-docs는 인터뷰를 하면서 프로젝트에서 쓰는 용어를 GLOSSARY.md에 정리하고,
중요한 설계 결정은 ADR(Architecture Decision Record, 설계 결정 기록) 문서로 남겨요.
README 예시가 재밌어요. "강의의 한 섹션 안에 있는 레슨이 실제 파일 시스템에 자리를 받을 때 생기는 문제"라고
길게 설명하던 걸, 용어집이 생긴 뒤에는 "materialization cascade 문제"라고 한 단어로 말해요.
매트 포콕은 이걸 "이 저장소에서 가장 멋진 기법일지도 모른다"고 소개해요.
용어가 통일되면 변수, 함수, 파일 이름도 일관되게 지어지고,
AI가 생각하는 데 쓰는 토큰도 줄어든다는 게 README의 설명이에요.
특징 3. 내가 부르는 스킬 vs AI가 알아서 쓰는 스킬
스킬은 누가 실행하느냐에 따라 두 종류로 나뉘어요.
| 구분 | 누가 실행하나 | 대표 스킬 | 역할 |
| 사용자 호출형 | 내가 /명령어로 직접 입력할 때만 | /grill-with-docs, /to-spec, /to-tickets, /implement, /wayfinder, /triage | 전체 흐름을 지휘 |
| 모델 호출형 | 나 또는 AI가 상황에 맞게 알아서 | tdd, code-review, diagnosing-bugs, prototype, research | 반복해서 쓰는 작업 원칙 |
공식 튜토리얼 영상에서는 대부분의 스킬이 "불러야만 동작"하는 구조라서,
당시 38개 스킬을 전부 설치해도 컨텍스트를 약 660토큰밖에 차지하지 않는다고 설명해요.
스킬을 많이 깔수록 AI가 무거워지는 다른 스킬 모음과 대비되는 부분이에요.
특징 4. 어떤 모델, 어떤 에이전트에서도 OK
스킬이 결국 마크다운 문서라서 특정 AI 모델에 묶이지 않아요.
Claude Code, Codex, GitHub Copilot, Gemini CLI, Cursor 등 스킬을 지원하는 에이전트라면 쓸 수 있어요.
Vercel이 운영하는 스킬 설치 사이트 skills.sh 기준으로 누적 설치는 3,000만 회를 넘었고,
그중 grill-me가 약 140만 회로 가장 많이 설치됐어요.
skills.sh에는 실험용과 예전 스킬까지 55개가 올라와 있고, 공식 사이트가 정리한 정식 스킬은 27개예요.
장점 정리
| 장점 | 설명 |
| 엉뚱한 결과물이 줄어요 | 코드를 짜기 전에 AI와 같은 그림을 먼저 맞춰요 |
| 작고 단순해요 | 스킬 하나가 짧은 마크다운 파일이라 읽고 고쳐 쓰기 쉬워요 (MIT) |
| 내 방식을 빼앗지 않아요 | 필요한 스킬만 골라 쓰는 구조라 거대한 프레임워크처럼 절차를 강요하지 않아요 |
| 기본기가 녹아 있어요 | TDD, 코드 리뷰, 모듈 설계 같은 소프트웨어 공학 원칙을 담았어요 |
| 에이전트를 가리지 않아요 | Claude Code, Codex, Copilot, Gemini CLI, Cursor 등 지원 |
| 자료가 풍부해요 | 공식 문서(aihero.dev)와 튜토리얼 영상, 외부 정리 글이 많아요 |
단점도 솔직하게
| 단점 | 설명 |
| 질문이 정말 많아요 | 질문 수 상한을 일부러 두지 않았어요(이슈 #282). "Codex가 질문을 200개나 했다"는 이슈(#44)도 있었어요. 길어지면 말로 정리를 요청해야 해요 |
| 모델 성능을 타요 | /improve-codebase-architecture는 약한 모델에서 보고서 대신 인터뷰부터 시작해 "거의 쓸 수 없다"는 불만이 공식 FAQ에 소개돼 있어요 |
| Claude Code 중심이에요 | 다른 에이전트에선 완성도가 들쭉날쭉하고, 스킬 품질을 자동 검증하는 평가(eval)가 저장소에 없다는 비교 평가가 있어요 |
| 업데이트가 잦아요 | 질문 방식과 스킬 이름이 몇 달 사이에도 바뀌어서 예전 글이나 영상과 다를 수 있어요 |
| 스킬 문서가 영어예요 | 그대로 쓰는 데는 문제없지만, 내 입맛대로 고치려면 영어를 읽어야 해요 |
| 작은 일엔 과해요 | 한 줄 수정에 메인 플로우 전체를 돌리면 오히려 시간만 들어요 |
3. mattpocock/skills 설치 방법 (30초면 끝)
설치 방법은 크게 두 가지예요.
플러그인 방식은 알아서 업데이트되고,
skills.sh(npx) 방식은 수정할 수 있는 스킬 파일을 내 프로젝트에 복사해 줘요.
주의. 한 에이전트에 두 방식을 같이 설치하면 모든 스킬이 두 번씩 깔려요. 에이전트 하나당 한 가지 방식만 고르세요.
Claude Code
claude plugin install mattpocock-skills@claude-plugins-official
Claude Code 공식 플러그인 마켓플레이스에서 바로 설치되고, 기본으로 자동 업데이트돼요.
Codex
codex plugin marketplace add mattpocock/skills
codex plugin add mattpocock-skills@mattpocock
Codex를 실행할 때마다 자동으로 업데이트돼요.
GitHub Copilot (CLI, VS Code)
copilot plugin marketplace add mattpocock/skills
copilot plugin install mattpocock-skills@mattpocock
VS Code에서는 명령 팔레트에서 Chat: Install Plugin From Source를 실행하고
https://github.com/mattpocock/skills 를 입력하면 돼요.
자동 업데이트를 원하면 README 안내대로 ~/.copilot/settings.json에 마켓플레이스 설정을 한 번 추가해 주세요.
Gemini CLI
gemini skills install https://github.com/mattpocock/skills.git --path skills/engineering
gemini skills install https://github.com/mattpocock/skills.git --path skills/productivity
Gemini CLI는 자동 업데이트가 없어서, 업데이트할 때 두 명령을 다시 실행하면 돼요.
Cursor, OpenCode, Windsurf 등 그 밖의 에이전트
npx skills@latest add mattpocock/skills -a cursor
# 업데이트
npx skills@latest update
-a 뒤에 에이전트 이름(cursor, opencode, devin, windsurf, amp, pi)을 넣고, 생략하면 설치 중에 고를 수 있어요.
Node.js가 설치돼 있어야 하고, 설치 화면에서 스킬을 고를 때 setup-matt-pocock-skills는 꼭 포함하세요.
설치 후 꼭 할 일: /setup-matt-pocock-skills
/setup-matt-pocock-skills
프로젝트(저장소)마다 한 번 실행하는 초기 설정이에요.
AI가 먼저 프로젝트를 살펴본 뒤 아래 세 가지를 물어봐요.
| 설정 항목 | 내용 |
| 이슈 트래커 | 스펙과 티켓을 어디에 저장할지 (GitHub, GitLab, 로컬 마크다운 파일 등) |
| 트리아지 라벨 | 티켓을 분류할 때 쓸 라벨 이름 (/triage가 사용) |
| 도메인 문서 위치 | GLOSSARY.md와 ADR 문서를 어디에 둘지 |
질문마다 추천 답이 먼저 나오니까, 잘 모르겠으면 추천대로 가도 괜찮아요.
GitHub를 쓰지 않는 개인 프로젝트라면 로컬 마크다운 파일을 고르면 간단해요.
4. 사용 방법: 메인 플로우 그대로 따라 하기
스킬이 27개나 되면 뭐부터 써야 할지 막막하죠.
공식 사이트도 "대부분은 메인 플로우부터 시작한다"고 안내해요. 순서는 이래요.
| 단계 | 명령어 | 하는 일 |
| 1. 인터뷰 | /grill-with-docs | 아이디어를 말하면 AI가 코드를 살펴본 뒤 질문 라운드로 요구사항을 확정하고, 용어집과 ADR을 정리해요 |
| 2. 스펙 | /to-spec | 지금까지의 대화를 스펙 문서로 정리해 이슈 트래커에 올려요 |
| 3. 티켓 | /to-tickets | 스펙을 한 세션에 끝낼 수 있는 작은 티켓으로 쪼개요 (선후 관계 포함) |
| 4. 구현 | /implement | 티켓 하나를 TDD로 구현하고 /code-review까지 거친 뒤 커밋해요 |
| 5. 회고 | /retro | 세션을 돌아보고 린트 규칙, 코딩 표준 같은 개선점을 제안해요 |
실제로는 이렇게 입력해요
/grill-with-docs 회원가입할 때 이메일 인증을 추가하고 싶어
# AI의 질문 라운드에 답하기 (추천 답이 맞으면 yes)
/to-spec
/to-tickets
/clear
/implement #12 # 티켓 하나씩
/clear
/implement #13
핵심 요령: AI의 '스마트 존'을 지키세요
AI는 대화가 길어져 컨텍스트가 찰수록 판단력이 떨어져요.
공식 튜토리얼은 약 14만 토큰, 다른 정리 글은 약 15만 토큰까지를
AI가 똑똑하게 일하는 스마트 존으로 설명해요.
그래서 인터뷰 → 스펙 → 티켓까지는 한 대화창에서 끊지 않고 이어 가고,
구현은 티켓 하나당 새 대화(/clear)로 시작하는 게 핵심이에요.
스펙 문서가 남아 있으니 대화를 지워도 맥락이 사라지지 않아요.
일의 크기별로 골라 쓰기
| 일의 종류 | 추천 흐름 |
| 아주 작은 일 (검증 규칙 하나 등) | /tdd → /code-review |
| 한 세션에 끝나는 일 | /grill-with-docs → /implement |
| 여러 세션이 필요한 일 | /grill-with-docs → /to-spec → /to-tickets → 티켓마다 /implement |
| 티켓이 많아 병렬로 돌릴 일 | 위처럼 계획한 뒤 /implement-spec (서브에이전트가 동시에 구현) |
| 크고 막연한 일 | /wayfinder로 결정 지도부터 만들기 |
그래도 헷갈리면 /ask-matt에게 지금 상황을 설명해 보세요.
어떤 스킬을 언제 쓰면 되는지 알려 주는 길잡이 스킬이에요.
코딩 말고도 쓸 수 있는 스킬
| 스킬 | 이럴 때 써요 |
| /grill-me | 코드가 아닌 계획(기획안, 글 구성, 업무 계획 등)을 점검받고 싶을 때 |
| /handoff | 대화를 정리해 다른 에이전트나 새 세션에 넘길 때 |
| /teach | 새 개념을 여러 세션에 걸쳐 차근차근 배우고 싶을 때 |
| /to-questionnaire | 혼자 정할 수 없는 결정을 상대에게 보낼 질문지로 만들 때 |
| /wait-what | AI 설명이 이해되지 않을 때 쉬운 말로 다시 듣고 싶을 때 |
꼭 알아 둘 주의사항
1) /implement는 지금 있는 브랜치에 바로 커밋해요. 작업 전에 새 브랜치를 먼저 만드세요.
2) 사용자 호출형 스킬(27개 중 16개)은 AI의 스킬 목록에 보이지 않아서
AI가 "설치 안 됐다"고 할 수도 있어요. 그래도 직접 입력하면 동작해요.
3) /to-tickets로 만든 티켓에는 /triage를 돌리지 마세요. 이미 AI가 작업할 준비가 끝난 티켓이에요.
4) Superpowers 같은 다른 스킬 프레임워크와 동시에 켜 두면
같은 이름의 명령이 겹쳐서 엉뚱한 스킬이 실행될 수 있어요.
5. 실제 활용 사례 BEST 7
이제 실제로 개발자들이 이 스킬을 어떻게 쓰고 있는지 살펴볼게요.
공식 자료와 외부 개발자들의 후기를 섞어서 골랐어요.
사례 1. 공식 튜토리얼: 기능 하나를 처음부터 끝까지
출처: YouTube · Matt Pocock · mattpocock/skills: A complete AI Coding workflow, end-to-end (2026.07)
매트 포콕이 설치부터 구현, 코드 리뷰까지 17분 동안 직접 보여 주는 공식 튜토리얼이에요.
자기 프로젝트(AI Hero CLI)로 시연하는데, 인터뷰에서 나온 약 4.6만 토큰 분량의 대화를 스펙 하나로 압축하고,
그 스펙에서 하위 이슈 11개를 만들어 하나씩 구현해요.
눈여겨볼 부분은 코드 리뷰예요. 메인 AI가 아니라 새 컨텍스트의 서브에이전트가 리뷰를 맡아요.
자기가 짠 코드에는 관대해지기 쉬우니까, 깨끗한 눈으로 스펙 누락과 코딩 표준을 점검하게 하는 거예요.
사례 2. 일의 크기가 아니라 '세션 수'로 워크플로 고르기
개발 블로그 Dan Does Code의 대니얼 매케이(Daniel Mackay)는 매트 포콕의 AI 코딩 강의를 듣고
메인 플로우를 일의 성격에 맞게 5가지 워크플로로 정리했어요.
핵심은 "이 일이 얼마나 큰가"가 아니라 "대화창 하나에 들어가는가, 끝이 보이는가"로 판단하라는 거예요.
거대한 코드베이스라도 작고 명확한 수정이면 /tdd면 충분하고,
작은 프로젝트라도 막연한 신기능이면 /wayfinder가 필요할 수 있다는 거죠.
글 안에는 질문 몇 개에 답하면 맞는 흐름을 골라 주는 위저드까지 들어 있어요.
함정도 잘 짚어 줘요. 설정 파일이나 단순 CRUD 코드에 /tdd를 쓰면 의미 없는 테스트가 나오기 쉽고,
한 세션짜리 일에 "혹시 몰라서" /to-spec을 끼우면 오히려 내용이 틀어질 수 있다고 해요.
단계 사이마다 이어 가기 → /clear → /handoff → 서브에이전트 → /compact 순서로 판단하는 사다리도 실용적이에요.
위에서부터 내려가다가 처음 "예"가 나오는 걸 고르면 돼요.
사례 3. 며칠에 한 번 코드베이스 건강검진
/improve-codebase-architecture는 코드를 직접 고치지 않아요.
코드베이스를 훑어서 "얕은 모듈을 깊게 만들 수 있는 곳"을 찾아 HTML 보고서로 보여 주는 건강검진 같은 스킬이에요.
후보마다 관련 파일, 문제점, 해결안, 전후 다이어그램이 카드로 정리되고,
Strong, Worth exploring, Speculative 같은 신뢰도 배지가 붙어요.
그중 하나를 고르면 그때부터 그 후보에 대한 인터뷰가 시작돼요.
| 활용 상황 | 이렇게 써요 |
| 정기 점검 | 며칠에 한 번 돌려서 구조가 망가지기 전에 미리 잡기 |
| 큰 기능 개발 전 | 스펙을 보여 주며 "이 변경을 쉽게 만들려면?"이라고 묻기 (공식 문서가 꼽은 가장 효과적인 사용법) |
| 오래된 저장소 진단 | 구조 없이 커진 저장소나 바이브 코딩한 저장소의 상태 파악 |
| 레거시 테스트 작업 | 테스트를 붙일 이음새(seam) 찾기 |
다만 8년 된 레거시 코드에서는 AI가 같은 자리를 맴돌았다는 후기도 공식 FAQ에 함께 실려 있어요.
또 보고서가 Tailwind와 Mermaid를 CDN에서 불러오기 때문에 인터넷이 막힌 환경에선 깨져 보일 수 있어요.
사례 4. 고객사 프로젝트 사전 인터뷰에 응용하기
AI 네이티브 전환 컨설팅 회사 re:cinq의 엔지니어 Jasper는
고객사 프로젝트를 준비하는 내부 스킬에 the grill이라는 단계를 넣었어요.
인터뷰를 시작하기 전에 고객 문서와 통화 녹취록을 AI가 직접 검색할 수 있게 먼저 불러와서,
이미 나온 사실은 다시 묻지 않고 아직 정해지지 않은 결정에만 질문을 집중하게 했대요.
아직 내부에서 다듬는 중인 워크플로라고 밝혔지만, grilling 원칙을 개발 밖으로 넓힌 좋은 예예요.
이 글에는 grill-me의 변천사도 정리돼 있어요.
2026년 2월 첫 버전은 지침이 단 두 문장이었고, 3월 26일부터 7월까지는 한 번에 질문 하나씩,
지금은 추천 답과 함께 여러 질문을 라운드로 묻는 방식으로 바뀌었어요.
사례 5. 무거운 프레임워크를 버리고 갈아탄 개발자
Jerry라는 개발자는 GSD(Get Shit Done)와 Superpowers를 진지하게 쓰다가
매트 포콕 스킬로 갈아탄 이유를 블로그에 정리했어요.
모델이 똑똑해지면서 모든 메시지에 강제되는 절차가 오히려 모델의 능력을 묶는다고 느꼈고,
필요할 때만 꺼내 쓰는 선택형 규율(opt-in discipline)이 자기 작업 방식에 맞았다는 거예요.
그가 매일 쓰는 건 /grill-me, /grill-with-docs, 도메인 모델링, /tdd, /triage, /to-spec과 /to-tickets 정도라고 해요.
27개를 다 쓸 필요 없이 몇 개만 손에 익혀도 충분하다는 좋은 참고가 돼요.
그러면서도 GSD나 Superpowers가 여전히 맞는 경우를 따로 정리해 둬서 한쪽으로 치우치지 않은 글이에요.
사례 6. 다른 인기 스킬 모음과 비교해 보기
구글 크롬 팀 출신으로 알려진 애디 오스마니(Addy Osmani)는 자신의 agent-skills를 소개하면서
Superpowers, 매트 포콕 스킬과의 차이를 솔직하게 비교해 뒀어요. 핵심만 표로 옮겨 볼게요.
| 구분 | mattpocock/skills | Superpowers | agent-skills |
| 핵심 성격 | 그릴링 중심의 실용 도구 상자 | 자율 실행 중심의 개발 방법론 | 개발 전 과정을 단계별 스킬로 |
| 잘 맞는 경우 | 매일 쓰는 개발 루프, 요구사항 정리와 TDD | 큰 작업을 맡기고 검토된 결과를 받을 때 | 모든 단계마다 체크포인트를 두고 진행할 때 |
| 아쉬운 점 | 규율은 사용자가 챙겨야 하고 저장소 내 평가가 없음 | 작은 작업엔 절차가 무거움 | 중간부터 도입하기 어려움 |
여러 비교 글의 공통 조언은 "좋은 스킬은 가져다 쓰되, 두 프레임워크를 동시에 켜 두지는 말라"예요.
스킬이 마크다운 파일이라 마음에 드는 것만 골라 옮기는 건 어렵지 않아요.
사례 7. 매트 포콕의 작업 철학 더 깊이 보기
개발자 뉴스레터 The Pragmatic Engineer의 게르게이 오로스(Gergely Orosz)와 나눈 대담이에요.
grill-me는 Anthropic의 Thariq Shihipar가 공유한 "AI가 사용자를 인터뷰하는 방식"에서 영감을 받았다고 해요.
가장 흥미로운 팁은 이끄는 단어(leading words)예요.
AI가 레이어별로 코드를 쌓다가 레이어 사이에서 버그를 내자,
『실용주의 프로그래머』의 트레이서 불릿(tracer bullet)이라는 표현으로 지시했더니
끝에서 끝까지 관통하는 작은 기능부터 만들면서 코드가 좋아졌대요.
영상 보기: YouTube · AI Engineer · Full Walkthrough: Workflow for AI Coding, Matt Pocock
시간이 넉넉하다면 AI Engineer 채널의 1시간 36분짜리 풀 워크숍도 추천해요.
트레이서 불릿, 칸반, 구현, QA와 코드 리뷰로 이어지는 흐름을 실제 코딩으로 보여 줘요.
6. 이런 분께 추천, 이런 분은 비추천
| 추천해요 | 굳이 안 써도 돼요 |
| Claude Code, Codex로 실제 서비스를 만드는 분 | 한두 줄짜리 스크립트만 가끔 짜는 분 |
| AI가 엉뚱한 걸 만들어 다시 시키는 일이 잦은 분 | 질문에 답하는 과정 자체가 번거로운 분 |
| 코드 품질, 테스트, 구조를 같이 챙기고 싶은 분 | 이미 다른 프레임워크로 팀 프로세스가 굳어진 분 |
| 기획과 설계를 AI와 함께 다듬고 싶은 분 | 성능이 낮은 소형 모델 위주로 쓰는 분 |
제 생각엔 처음부터 전부 쓰기보다 /grill-me 하나만 일주일 써 보는 것을 추천해요.
AI에게 일을 맡기기 전에 질문 라운드를 한 번 거치는 것만으로도 결과물이 꽤 달라지는 걸 느끼실 거예요.
익숙해지면 /tdd, /to-spec, /to-tickets 순으로 하나씩 늘려 가면 돼요.
7. 자주 묻는 질문 (FAQ)
Q. mattpocock/skills는 무료인가요?
네. MIT 라이선스 오픈소스라 무료이고, 개인이든 회사든 수정해서 쓸 수 있어요.
다만 Claude Code, Codex 같은 에이전트 자체의 사용료는 따로 들어요.
Q. Claude Code 말고 Codex나 Cursor에서도 되나요?
네. Codex와 Copilot은 플러그인으로, Gemini CLI는 gemini skills install로,
Cursor, OpenCode, Windsurf 등은 npx skills@latest add mattpocock/skills -a 에이전트이름 으로 설치해요.
Q. grill-me와 grill-with-docs는 뭐가 달라요?
grill-me는 코드와 상관없는 계획에도 쓰는 순수 인터뷰이고,
grill-with-docs는 인터뷰하면서 GLOSSARY.md 용어집과 ADR 문서까지 업데이트해요. 코딩 작업이라면 grill-with-docs가 기본이에요.
Q. 질문이 너무 많은데 줄일 수 없나요?
질문 수 상한은 일부러 두지 않았어요. 대신 "이제 정리하고 넘어가자"처럼 말로 끊으면 된다는 게 공식 입장이에요.
추천 답이 마음에 들면 yes만 답해도 되니 생각보다 빨리 끝나요.
Q. Superpowers와 같이 써도 되나요?
동시에 켜 두는 건 비추천이에요. 같은 이름의 명령이 겹쳐 엉뚱한 스킬이 실행될 수 있어요.
마음에 드는 개별 스킬만 골라 옮겨 쓰는 건 괜찮아요.
Q. 업데이트는 어떻게 하나요?
Claude Code, Codex, Copilot 플러그인은 자동으로 업데이트되고,
npx 방식은 npx skills@latest update, Gemini CLI는 설치 명령을 다시 실행하면 돼요.
마무리: AI에게 일을 '잘 시키는' 가장 쉬운 방법
mattpocock/skills는 화려한 자동화 도구라기보다 AI와 일하는 좋은 습관을 스킬로 만든 것에 가까워요.
먼저 충분히 대화해서 같은 그림을 그리고, 작게 쪼개 테스트하며 만들고, 다른 눈으로 리뷰하는 거죠.
사실 사람끼리 일할 때도 똑같이 중요한 원칙이에요.
질문이 많아 처음엔 귀찮을 수 있고, 모델에 따라 결과가 들쭉날쭉한 점은 알고 쓰셔야 해요.
그래도 AI가 엉뚱한 걸 만들어서 다시 시키는 시간을 생각하면, 질문 몇 라운드는 충분히 남는 장사예요.
오늘 바로 설치하고, 다음 작업을 /grill-me로 시작해 보세요.
※ 스타 수, 설치 수, 스킬 구성은 2026년 10월 26일 기준이에요. 업데이트가 잦은 저장소라 최신 내용은 공식 깃허브와 aihero.dev에서 확인해 주세요.
참고 자료
GitHub · mattpocock/skills
AI Hero · AI Skills for Real Engineers
AI Hero · The /improve-codebase-architecture Skill
skills.sh · mattpocock/skills
YouTube · Matt Pocock 공식 튜토리얼
Dan Does Code · Choosing The Right Workflow
re:cinq · The Grill-Me Skill
Jerryskills · Why I Dropped GSD and Superpowers
Addy Osmani · How agent-skills compares
The Pragmatic Engineer · AI Skills with Matt Pocock
YouTube · AI Engineer 풀 워크숍
GitHub Issue #282 · 질문 수 제한 정책