Matt Pocock의 Engineering Skills를 사용하는 이유
Claude Code나 Codex를 사용하면 어느 시점에선 반드시 하네스 엔지니어링(Harness engineering)을 신경 쓰게 됩니다. 더불어서 나만의 개발 워크플로우를 수립하게 되고 더 나아가선 토큰 효율적인 워크플로우를 원하게 됩니다. 저는 오랜 시간 동안 Claude Code를 사용해왔고 모델이 여러 번 바뀔 때마다 제 하네스와 개발 워크플로우를 다듬는 데에 많은 시간을 들였습니다.
이 글은 Opus 5가 출시된 후 제가 Claude Code에서 쓸 수 있는 워크플로우와 관련 플러그인 중에서도 왜 Matt Pocock의 Skills를 사용하는지 다룹니다. 과거에 사용했던 워크플로우와 플러그인, 그것들이 Matt Pocock의 Skills와 어떻게 다른지, Opus 5라는 모델의 특징이 제 워크플로우에 미친 영향을 차례로 살펴봅니다.
과거에 사용했던 워크플로우와 플러그인
Opus 4.6, Opus 4.8을 사용하던 때에는 superpowers와 Compound Engineering(이하 CE)을 적절히 제 입맛에 맞춰 섞어 하나의 워크플로우를 만들어 사용했습니다. 물론 두 플러그인은 각각의 특징이 뚜렷한 편이라 하나를 선택해서 사용해도 충분합니다. 다만 각 플러그인의 스킬을 잘 배치하면 서로의 단점이나 부족한 프로세스를 메꿀 수 있어 더 나은 워크플로우를 만들 수 있습니다. 저는 계획, 구현, 작업 완료 후 내용 정리에 CE를 사용했고 모델과의 인터뷰, 인터뷰 내용으로 스펙을 쓰는 작업, 브랜치 정리 등에는 superpowers를 썼습니다. CE는 작업 워크플로우에서 각 단계를 문서화하고 그걸 다음에 다시 활용해 중요한 컨텍스트를 영속화하는 데 큰 강점이 있었고, superpowers는 제가 느끼기엔 CE보다 더 나은 브레인스토밍 능력과 제 워크플로우에 더 적합한 브랜치 정리 기능이 있었기에 위와 같은 워크플로우를 사용했습니다. 정리하자면 아래와 같습니다.
1
브레인스토밍 -> 스펙 작성(이상 superpowers) -> 계획 작성 -> 구현(이상 CE) -> 브랜치 정리 및 작업 마무리(superpowers) -> 작업에서 다음 세션에 넘길 중요한 내용 문서화(Compound Engineering)
충분히 잘 작동했고 결과물만 보면 지금 사용하는 워크플로우와 다를 바 없이 품질에도 문제가 없었습니다. Opus 5가 출시되기 전까진 이 워크플로우를 고수했습니다.1
Opus 5 출시 이후
Opus 5는 생각보다 기존 모델과 크게 다른 모습을 보였습니다. Opus 5의 특징은 Anthropic의 블로그 글에 잘 설명되어 있습니다. 글이 너무 길어 요약하자면 이렇습니다.
- Opus 5, Fable 5 같은 모델에서는 Claude Code 시스템 프롬프트의 80% 이상을 걷어냈음에도 성능 손실이 없었다.
- 컨텍스트 엔지니어링 시 Claude에게 규칙을 주기보단 자체 판단에 맡기는 게 더 낫다. 예시를 주기보단 사용하는 도구, 스크립트, 파일의 설계에 더 심혈을 기울이는 게 더 낫고, 중복 설명을 사용하기보단 더 단순한 게 낫다.
쉽게 말해 Opus 5를 사용할 때는 예전처럼 모든 걸 다 설명할 필요가 없었습니다. 실제로 체감상 최대한 자세하게 줘야 했던 지침을 제법 간결하게 바꿨을 때 성능이 더 좋았습니다. 품질에 큰 차이가 없더라도 모델이 생각하는 단계가 줄어 비용을 절약할 수 있었습니다. 더욱이 Opus 5는 말이 너무 많다는 점에서 단계를 줄일수록 비용을 아끼는 체감 효과는 더 컸습니다.
그런 점에서 superpowers와 CE는 크게 아쉬웠습니다. 두 플러그인이 생성하는 스펙과 계획 문서가 과도하게 자세했습니다. 물론 스펙을 보고 계획을 작성하기 때문에 스펙이 길어지는 건 어쩔 수 없어 괜찮았지만 두 플러그인 모두 계획 문서가 심각할 정도로 자세했습니다. Opus 4.6, Opus 4.8 때는 필요했겠지만 Opus 5에겐 너무 과했습니다. 아래는 superpowers와 CE가 작성하는 계획 문서에서 과하다 느꼈던 점입니다.
- 모든 작업마다 아키텍처 구조와 작업 흐름을 mermaid 플로우차트로 그림
- 작업 단위마다 접근 방식, 관련 코드, 테스트 시나리오를 모두 먼저 생각하여 작성함
- 작업에서 수행할 내용과 코드를 구현에 앞서 계획 파일에 모두 추가함
특히 과하게 자세한 계획 문서로 구현을 하던 중 계획 내용에서 잘못 분석한 아키텍처 내용을 발견했을 때 더 큰 문제가 발생했습니다. 문제를 찾은 것 자체는 괜찮았지만 자세하게 작성된 계획 문서 탓에 구현이란 구현은 다 하고 아키텍처를 다시 분석하고 처음부터 다시 구현해야 해서 지금까지 소모한 토큰이 낭비가 되기 일쑤였습니다. 이럴 때마다 ‘계획 파일이 정말 계획만 담고 있다면 어땠을까’란 생각을 많이 했습니다. 코드베이스가 커질수록 더 큰 문제가 되다 보니 결국 Opus 5에 맞춰 하네스를 재편해야겠다는 결정을 내렸습니다.
Matt Pocock의 Engineering Skills
제가 새로운 하네스를 구성할 때 가장 중요하게 여겼던 기준은 세 가지였습니다.
- 모델과 인터뷰해 스펙을 쓰는 단계가 제일 중요함.
- 워크플로우 단계 중 작성되는 문서가 필요한 내용으로만 간결하게 구성되어야 함.
- 기존 대비 토큰 사용량이 줄어야 하고 작업 속도가 빨라져야 함.
그렇게 선택한 게 바로 Matt Pocock의 Engineering Skills입니다. 사실 이 스킬을 처음 알게 된 건 아니었습니다. 예전부터 눈여겨보고 있었지만 이미 당시 워크플로우에 충분히 만족하고 있었기 때문에 사용을 미뤄왔습니다. 그런데 이번에 다시 조사하다 보니 재밌게도 위 세 가지 기준을 모두 충족한다는 것을 알게 되었습니다. 이제 이 스킬 모음이 제 요구사항을 어떻게 충족했는지 설명하면서 스킬을 자세히 살펴보겠습니다.
개인적 우선순위와 Opus 5의 특징을 고려했을 때
이 스킬 모음에는 이런 특징이 있습니다.
- 사용자의 개입을 최대화하도록 구성되어 있음
- 각 스킬은 작고, 고치기 쉽고, 조합 가능하게 설계되어 있음
- 각 단계 사이에 명확한 구분이 있고 각 단계에 절차만 서술되어 있음
- 대부분의 스킬에
disable-model-invocation: true설정이 되어 있음- 스킬 description을 컨텍스트에 자동으로 포함하지 않고 사용자가 직접 실행하도록 되어 있음
- 스킬 본문이 짧은 편
위 특징은 Opus 5의 컨텍스트 엔지니어링 방식과 제 개인적인 우선순위와 꽤 잘 어울렸습니다.
| Matt Pocock 스킬 특징 | Opus 5의 컨텍스트 엔지니어링 방식 / 개인적인 우선 순위 |
|---|---|
| 스킬 본문이 짧다. | 규칙을 주지 말고 판단에 맡긴다. |
| 각 단계 사이에 명확한 구분이 있고 각 단계에 절차만 서술되어 있음 | 예시를 주지 말고 설계에 초점을 맞춘다. |
대부분 스킬에 disable-model-invocation: true 설정이 되어 있음 | 모든 정보를 다 주지 않고 점진적 공개(progressive disclosure)를 사용한다. |
개발 라이프사이클을 따라가는 주요 스킬 체인
20여 개에 달하는 스킬 중 개발에 쓰는 주요 스킬 체인은 다섯 개의 스킬로 이어집니다.
1
grill-with-docs → to-spec → to-tickets → implement → code-review
각 스킬의 역할과 산출물을 표로 정리하면 이렇습니다.
| 단계 | 역할 | 남는 산출물 |
|---|---|---|
grill-with-docs | 계획을 세우기 전에 한 번에 한 질문씩 인터뷰 | CONTEXT.md, ADR |
to-spec | 인터뷰 내용이나 지금까지의 대화 내용을 스펙으로 정리 | 트래커 이슈 or 스펙 |
to-tickets | 스펙을 구현 단위의 티켓으로 분할하여 작성 | 티켓과 티켓 간 의존성 관계 |
implement | 티켓 하나를 새 세션에서 TDD로 빌드 | 코드와 테스트 |
code-review | diff를 표준 준수, 스펙 준수라는 두 기준으로 리뷰 | 리뷰 결과 |
각 단계는 제가 사용하던 기존 워크플로우와 큰 차이가 없었다보니 대부분의 단계를 Matt Pocock의 스킬로 대체할 수 있었습니다. 작업 하나를 시작할 때 /grill-with-docs로 인터뷰를 진행합니다. 컨텍스트 윈도우에 해당 작업을 위한 많은 정보를 쌓아놓고 그걸 토대로 /to-spec으로 스펙을 작성합니다. 스펙은 /to-tickets를 통해 구현 단위마다 티켓으로 분할하고, 각 티켓을 새로운 세션에서 /implement를 실행해 TDD로 구현을 합니다. 구현이 완료될 때마다 /code-review를 실행해 프로젝트의 표준과 스펙 준수 여부를 리뷰합니다.
각 스킬은 제 요구사항을 꽤 만족시키는 편이었습니다.
우선 모델과의 인터뷰라는 요구사항은 grill-with-docs 스킬로 충족할 수 있었습니다. 체감으로는 superpowers나 CE보다 더 많은 인터뷰 질문을 받았던 것 같습니다. 특히 인터뷰가 몇 라운드로 나뉘어 진행되었고 앞 라운드에서 내린 결정이 다음 라운드 내용에 영향을 주면서 더 날카로운 스펙을 작성할 수 있었습니다.
그렇게 작성된 스펙 문서를 열어보면 기존 플러그인이 작성한 문서보다 전반적으로 짧은 편이었습니다. 그렇다고 내용이 적은 게 아니라 정말 필요한 내용만 담았고 마치 Opus 5의 컨텍스트 엔지니어링에 맞춘 것처럼 철저하게 설계 위주의 내용으로만 구성되어 있었습니다. 기존 플러그인에서 작성한 스펙 문서는 “어떤 파일을 어떻게 수정해야 한다.”를 자세하게 적는 편이었습니다. 제가 작업하던 중에 생성된 스펙 문서를 보면 거의 계획 문서에 필적할 만큼 세부사항이 많았습니다. 반면 Matt Pocock의 스킬은 그런 내용을 거의 넣지 않습니다. 문제 정의, 솔루션, 유저 스토리, 구현 의사결정 등 큰 틀의 설계만 담고 있습니다.
이 차이는 계획 단계로 갔을 때 더욱 크게 벌어집니다. 기존 플러그인은 많은 세부사항을 담은 스펙을 더 자세한 계획으로 발전시킵니다. 문서는 더욱 길어지고 모델은 우선 그 자세한 계획을 그대로 따르게 됩니다. 심지어 하나의 계획 파일에 그 모든 내용이 담기면서 분량이 크게 늘어납니다. 기본 수백 줄에 달하는 문서가 만들어지죠. 반대로 Matt Pocock의 스킬은 구현 단위마다 하나의 티켓을 생성합니다. 그 티켓의 크기는 크지 않습니다. 만들어야 할 것, 현재 작업 상태, 티켓의 배경 설명, 작업 체크리스트만 담깁니다. 아무리 크더라도 100줄 내외로 쓰입니다. 각 티켓은 새로운 세션에서 다뤄지기 때문에 메인 컨텍스트 윈도우가 커지는 일도 방지합니다.2
계획을 읽어 구현하는 방식에도 큰 차이를 보였습니다. 아무래도 기존 플러그인으로 짠 워크플로우에선 계획 문서 자체가 매우 세부적이다 보니 계획을 그대로 따라 구현하고 나서 문제가 생겨 원인을 찾는 경우가 많았습니다. 반면 Matt Pocock의 스킬을 사용할 땐 각 티켓 파일에 세부 계획이 쓰여 있지 않다 보니 구현 전에 모델이 전체 코드베이스에서 필요한 정보를 탐색해 구멍이 나는 경우가 적었습니다.3 구현 후 문제가 생겨 지금까지 한 작업을 수정할 때 드는 비용과 시간이 적지 않다는 걸 고려하면 Matt Pocock의 스킬을 사용하는 게 토큰 사용량과 작업 속도에서 우위를 점한다고 생각했습니다.
결국 모든 단계가 제 요구사항에 딱 맞게 작동하는 데다 Opus 5의 컨텍스트 엔지니어링에 어울리는 구성이라 비용과 시간을 덜 들이고 작업을 마칠 수 있다는 점이 제게 큰 장점이었습니다.
유용한 다른 스킬들
기존 워크플로우를 대체하는 스킬뿐만 아니라 함께 설치되는 다른 스킬들도 매우 유용해 제 개발 작업을 편하게 해 줬습니다. 제가 주로 사용하는 추가 스킬은 /ask-matt, /handoff, /teach입니다.
/ask-matt
주요 스킬 체인은 위에서 말한 것처럼 꽤 단순하지만 작업 중간에 그다음 어떤 요청을 해야 하는지 뭘 더 해야 하는지 갑자기 감을 잃을 때가 있습니다. 이때 사용하는 스킬이 바로 /ask-matt입니다. 이 스킬은 전체 스킬 모음을 어떤 순서로 쓰는지 담고 있어서 현재 상황에 맞는 다음 작업을 설명해 줍니다. 이제는 스킬 전체를 이해하게 되었고 어떤 스킬이 있는지 잘 알기 때문에 자주 사용하지 않지만 처음 쓰던 때에는 거의 매 세션마다 사용하던 스킬입니다.
/handoff
컨텍스트 윈도우가 많이 차거나 다른 세션에 정보를 넘겨 인수인계해야 할 때 HANDOFF.md 파일을 활용하는 방식은 에이전트를 쓰는 코딩에서 꽤 오래된 표준입니다. 그러다 보니 관련한 스킬이 이미 많이 나와 있어 그중 하나를 쓰거나 다음 세션에 넘길 중요한 내용을 요약해서 HANDOFF.md에 작성해줘 같은 요청을 직접 입력하기도 합니다.
/handoff는 Matt Pocock의 스킬을 쓰는 시나리오에 조금 더 맞춘 내용을 담고 있습니다. 예를 들어 다음 세션에서 쓸 스킬을 추천해 준다든지, 기존 세션에서 작성했던 스펙, 계획, ADR(Architecture Decision Record), 이슈, 커밋, diff는 중복해서 싣지 말고 경로나 URL로 참조하도록 한다든지 말이죠. 더불어서 API 키나 비밀번호 같은 PII 민감 정보는 삭제해야 한다는 내용도 꽤 인상적이었습니다.
/teach
개발 라이프사이클과 전혀 상관이 없지만 Matt Pocock의 스킬 가운데 제가 가장 열심히 쓰는 스킬입니다. /teach는 사용자가 무엇이든 효율적으로 배우도록 개인에게 맞춘 학습 경험을 제공합니다. 이 스킬을 사용하면 실행한 디렉터리를 학습 공간으로 두고 한 주제를 여러 세션에 걸쳐 나눠 짧은 HTML 레슨 파일로 만들어 가르쳐 줍니다. 저는 요즘 Pydantic AI와 LangGraph, Arize Phoenix를 모두 사용하는 멀티 에이전트 시스템을 이 스킬로 처음부터 다시 공부해 보고 있습니다.
이 스킬의 진면목은 직접 사용해 봐야 알 수 있지만 더 잘 설명하려고 Matt Pocock 본인이 /teach 스킬을 소개하는 영상을 첨부했습니다. 실제 스킬 파일을 보면 교육학을 전공한 게 아닐까 의심될 만한 내용으로 이뤄져 있습니다. (분명 제가 교육학 수업에서 들었던 근접발달영역(ZPD) 같은 개념도 있고 스킬의 철학 자체도 교육학에서 다룰 만한 주제였습니다.)
나가며
결국 제가 사용하는 워크플로우와 하네스를 바꾼 이유는 Matt Pocock의 스킬이 절대 superpowers나 CE보다 더 나아서가 아닙니다. 두 플러그인 모두 잘 만들어져 있고 여전히 훌륭합니다. Opus 4.6과 Opus 4.8처럼 조금 지난 모델에는 두 플러그인이 갖춘 상세함이 실제로 필요했으니까요. 다만 새로운 세대의 모델이 등장하면서 더 맞는 하네스를 찾아야 했을 뿐입니다. Amp Code의 Nicolay Gerold는 모델이 발전하고 바뀌면 하네스도 함께 달라져야 하거나 하네스 자체가 필요 없어질 수 있다고 말했습니다. 제 경우가 그가 말한 커비 효과(Kirby Effect) 그 자체입니다.4
지금 제게는 Matt Pocock의 Engineering Skills가 딱 맞았습니다. 하네스를 구성할 때 중요하게 여겼던 기준에 부합했고 새로운 세대의 모델인 Opus 5와도 잘 맞았습니다. 여기에 함께 쓸 좋은 스킬도 있고요. 하지만 또 어떻게 될지 모르는 일입니다. 제가 다른 모델을 쓰게 되거나 새로운 모델이 나온다면 분명 지금과 같은 이유로 하네스를 들여다보고 제게 맞는 무언가를 찾거나 뜯어고치고 있지 않을까요?
이 워크플로우에서 Sonnet 4.6은 사용하되 Sonnet 5는 사용하지 않았습니다. Sonnet 5는 “성능”만 놓고 보면 당연히 Sonnet 4.6보다 훌륭했지만 다른 측면에서는 모두 만족스럽지 못했습니다. 특히 Sonnet 5 특유의 만연체 탓에 토큰 사용량이 많았고 문제를 해결하려고 다른 모델보다 더 많은 턴을 소모하는 경향이 있어 비용이 Opus보다 훨씬 높았기 때문입니다. 제가 주로 찾아보는 Senior SWE-Bench에서 이 특징을 쉽게 확인할 수 있습니다.
.
이미지에는 GPT-5.6 Sol과 비교한 결과도 함께 담겨 있습니다. 저 역시 모델 성능은 이제 OpenAI가 Anthropic을 추월했다고 생각합니다. 그럼에도 제가 Claude Code를 사용하는 이유는 기회가 되면 따로 다뤄 보겠습니다. ↩︎물론 토큰 효율이 얼마나 좋아지는지는 작은 작업인지 큰 작업인지에 따라 달라집니다. 만약 작은 작업이라면 기존 플러그인이 메인 컨텍스트 윈도우에서 다 다루는 방식이 더 효율적입니다. 반대로 작업이 커질수록 Matt Pocock의 스킬에서 사용하는 티켓당 신규 세션 방식이 더 유리합니다. ↩︎
저는 코드베이스 탐색에 Codegraph를 사용합니다. 그러다 보니 전체 코드베이스에서 필요한 정보를 찾을 때 쓰는 토큰이 바닐라 상태보다 더 적은 편입니다. 어차피 기존 플러그인으로 짠 워크플로우에서도 문제가 생기면 전체 코드베이스를 뒤져야 하는 것은 똑같기 때문에 코드베이스 탐색 비용을 따로 따질 필요는 없습니다. ↩︎
Nicolay Gerold는 그 영상에서 개발자는 새로운 모델 세대가 나올 때마다 무엇이 불필요해졌는지를 끊임없이 고민하고 기존 코드나 하네스를 과감히 삭제하거나 구조를 바꿔야 한다고 말했습니다. ↩︎