Matt Pocock - skills for real engineers 리뷰

오늘은 Matt Pocock이 작성한 Skills For Real Engineers를 리뷰해보려고 한다. 해당 Github 레포지토리는 바이브 코딩이 아닌 실제 엔지니어링을 위해, 작성자가 매일 사용하는 에이전트 스킬을 모아 둔 것이라고 한다. 즉, 바이브 코딩보다는 에이전틱 엔지니어링에 초점이 맞춰진 스킬이다.

요새 수많은 스킬이 쏟아져 나오고 있는 상황에서, Matt Pocock의 스킬 모음집은 에이전틱 엔지니어링의 초석과 같은 역할을 한다. 모두 엔지니어링 관점에서 활용 범위가 넓은 스킬들이다.

각각의 스킬은 매우 가볍고, 입맛대로 고치거나 조합해서 쓸 수 있도록 설계되었다. 저자는 README에서 이 점을 GSD, BMAD, Spec-Kit과 대비한다. 이런 프레임워크들은 개발 프로세스 전체를 도맡아 도움을 주려 하지만, 그 과정에서 사용자의 통제권을 가져가고 프로세스 안의 버그를 고치기 어렵게 만든다고 한다. 그래서 저자는 이 스킬들을 작고, 적응하기 쉽고, 조합 가능하게 만들었다. 이 스킬들은 Claude Code, Codex뿐 아니라 어떤 모델에서도 동작한다.

개별 스킬을 살펴보기 전에 저자가 이 스킬들을 만든 배경부터 짚는다. 배경을 알고 보면 스킬을 더 잘 이해하고 쓸 수 있다. 이 글은 저자가 README에서 정리한 네 가지 실패 모드와 거기에 직접 엮인 스킬들을 따라간다. 레포에는 이 밖에도 triage, to-issues, prototype, caveman, handoff 등이 더 있다.

스킬을 만든 배경#

1. 에이전트와 사람과의 간극#

문제#

앞서 말했듯이 저자는 이 스킬 모음집을 바이브 코딩이 아닌, 실제 엔지니어링을 위해 만들었다고 한다.

바이브 코딩을 할 때의 문제점은 사람이 끌려간다는 것이다. 개발하기 전에는 분명한 아이디어가 있다고 생각했지만, 정작 바이브 코딩의 결과물에는 납득하지 못하는 상황이 발생한다.

이 문제의 가장 큰 원인은 사람과 에이전트 사이의 간극이다. 저자는 이를 "Grilling Session"으로 해결할 수 있다고 한다. 에이전트가 무엇을 만들지에 대해 사용자에게 질문을 퍼붓도록 만드는 것이다.

해결책#

저자는 이 간극을 쉽게 줄일 수 있는 스킬인 /grill-me 및 /grill-with-docs 를 소개한다.

• grill-me: 상호 이해에 도달할 때까지 계획이나 설계에 대해 사용자에게 끊임없이 질문하게 함.
• grill-with-docs: grill-me 와 동일한 성격이지만, 동시에 AI와 공유 언어를 만들고 설명하기 까다로운 의사결정을 문서화하는 걸 도와줌.

2. 에이전트가 너무 장황함#

문제#

프로젝트 초반에는 개발자와 소프트웨어를 쓸 사람이 보통 서로 다른 언어로 말한다고 한다. 그런데 이 문제가 에이전트와 사람 사이에서도 똑같이 존재한다고 한다. 에이전트는 보통 프로젝트 한가운데 던져진 채 그때그때 용어를 알아내야 한다. 새로운 세션은 개발 전체의 맥락을 한 번에 알 수 없기 때문이다. 그래서 에이전트는 한 단어면 될 것을 스무 단어로 늘어놓는다고 한다.

해결책#

저자는 "공유 언어(shared language)"를 해결책으로 제시한다. 프로젝트에서 쓰는 용어를 에이전트가 해독할 수 있게 도와주는 문서다. 새로운 개념은 아니다. Eric Evans가 『도메인 주도 설계(Domain-Driven Design)』에서 말한 '유비쿼터스 언어(ubiquitous language)' — 개발자 간 대화와 코드 표현을 모두 같은 도메인 모델에서 끌어내는 언어 — 와 같은 뿌리다. 저자도 README에서 이 절을 Evans의 문장으로 연다.

아래는 저자가 장황한 문장과 공유 언어로 잡은 문장을 비교해 보여준 예시다. 어느 쪽이 더 읽기 쉬운가?

이런 간결함은 세션을 거듭할수록 효과가 쌓인다.

앞서 설명한 /grill-with-docs 스킬이 공유 언어를 만듦으로써 에이전트의 장황함을 해결한다. 저자는 이 레포에 담긴 기법 중에서 이것이 단연 최고일지도 모른다고 하니, 적극적으로 써보자.

3. 코드가 동작하지 않음#

문제#

앞선 스킬들로 사용자와 에이전트의 간극을 줄였다고 하자. 그런데도 에이전트가 여전히 엉망인 결과물을 내놓을 땐 어떻게 해야 할까?

이때는 피드백 루프를 들여다봐야 한다고 한다. 자기가 만든 코드가 실제로 어떻게 돌아가는지에 대한 피드백이 없다면, 에이전트는 본인이 만든 게 잘 되는지 안 되는지 모른다.

해결책#

통상적인 피드백 루프 묶음이 필요하다고 한다. 정적 타입, 브라우저 접근, 자동화된 테스트이다.

자동화된 테스트에서는 red-green-refactor 루프가 결정적이라고 한다. 에이전트가 먼저 실패하는 테스트를 짜고(red), 그 다음 그 테스트를 통과(green)시키는 방식이다. 이 방식이 에이전트에게 일관된 피드백을 주고, 결과적으로 훨씬 더 좋은 코드를 만들어 낸다고 한다.

• 저자는 이를 /tdd 스킬로 만들었다. 어떤 프로젝트에든 끼워 넣을 수 있으며, red-green-refactor를 권장하고 좋은 테스트와 나쁜 테스트가 어떻게 다른지에 대한 가이드를 충분히 제공한다고 한다.
• 디버깅용으로는 모범적인 디버깅 관행을 단순한 루프에 담아낸 /diagnose 스킬도 함께 제공된다.

4. 진흙공을 만듦#

문제#

에이전트로 만든 대부분의 앱은 복잡하고 변경하기 어렵다. 에이전트가 코딩 속도를 비약적으로 높여주는 만큼, 코드베이스도 같이 복잡해진다는 것이다. 여기서 '진흙공'은 임의의 비유가 아니라, Brian Foote와 Joseph Yoder가 1997년에 정리한 아키텍처 안티패턴 'Big Ball of Mud' — 뚜렷한 구조 없이 얽혀버린 코드베이스 — 를 가리킨다.

해결책#

저자는 이를 해결하기 위해 에이전트가 코드 설계 자체에 신경 쓰게 만드는 스킬을 소개한다.

• /to-prd: PRD를 만들기 전에 어떤 모듈을 건드리고 있는지 사용자에게 묻는 스킬
• /zoom-out: 에이전트가 시스템 전체 맥락에서 코드를 설명하도록 하는 스킬
• /improve-codebase-architecture: 이미 진흙공이 되어 버린 코드베이스를 구해내는 데 도움을 주는 스킬이라고 함. (며칠에 한 번씩은 자기 코드베이스에 돌려보길 권한다고 한다.)

---

설치#

skills.sh 설치 도구로 받을 수 있다.

npx skills@latest add mattpocock/skills

설치할 스킬과 적용할 코딩 에이전트를 고른 뒤, /setup-matt-pocock-skills를 함께 선택해 실행해야 한다. 이 스킬이 이슈 트래커(GitHub·Linear·로컬 파일), /triage가 쓸 라벨, 문서 저장 위치를 잡아 준다.

---

맺음말#

LLM은 먼저 거대한 양의 데이터로 self-supervised learning을 거치고, 이어서 supervised-fine-tuning을 한다. 이렇게 학습을 마친 뒤에도 이미 정말 똑똑한 상태이지만, 사람이 사용하기에는 문제가 많다. 사람과의 간극이 매우 크기 때문이다. 그래서 마지막으로 강화학습 등 수많은 alignment를 거친다. 사람과의 간극을 줄이고 일반화된 성능을 높이기 위함이다.

이렇게 학습된 LLM은 일반적으로 정말 똑똑하고 사람과 친화적이지만, 코딩 에이전트로 사용하면서 우리가 만들고 싶어 하는 프로젝트에 특화시키려면 우리와의 간극을 더 줄여 나가야 한다. 그렇지 않은 상태에서 개발을 시작하면 바이브 코딩이 될 확률이 높아진다.

Skills For Real Engineers는 소프트웨어 개발 기초의 중요성을 짚고 넘어가야 한다는 인상을 준다. Agentic Engineering을 하면서 단순히 토큰을 아끼는 데에만 포커스를 두어서는 안 될 것 같다. 장황하게 설명하는, 이미 학습되고 alignment까지 된 LLM을 우리가 바꿀 순 없으므로, 목적에 맞는 하네스를 깎고 또 깎는 게 지금으로서는 최선의 방법이 아닐까.