Blog

AI 코딩 에이전트를 쓰기 시작한 뒤로 손으로 치는 코드는 확실히 줄었습니다. 그런데 이상하게도 퇴근 시간은 그대로입니다. Unhandled Exception Podcast 진행자 댄 클라크(Dan Clarke)도 같은 고민을 털어놓습니다. “AI가 몇 초 만에 함수와 테스트를 써내는 걸 보면 감탄하는데, 티켓을 100배 빨리 처리하고 있다는 느낌은 없어요.” 이 질문에 답한 사람이 매트 포콕(Matt Pocock)입니다. Total TypeScript 강의로 유명한 TypeScript 교육자였고, 지금은 GitHub 스타 30만 개를 넘긴 mattpocock/skills 저장소로 “Agent Skills”의 대표 인물이 됐습니다. 그의 답은 간단합니다. AI가 먹어 치운 것은 전술적 프로그래밍이고, 개발자의 시간은 여전히 전략적 프로그래밍에 쓰인다는 것입니다. 이 글에서는 이 팟캐스트 에피소드(88회)를 바탕으로 매트 포콕의 스킬 철학, 대표 스킬인 Grill Me와 Wayfinder, 그리고 두 사람이 공유한 개인 워크플로 팁을 정리합니다.

전술적 프로그래밍과 전략적 프로그래밍

매트 포콕은 존 오스터하우트(John Ousterhout)의 책 『A Philosophy of Software Design』에 나오는 구분을 가져옵니다.

댄 클라크가 “코딩 생산성은 10만 배가 됐는데 일은 줄지 않았다”고 하자, 매트 포콕은 이렇게 정리합니다. 원래 시간을 잡아먹던 건 전략적인 일이었고, 그중에서도 정렬(alignment)이었다는 것입니다. 클라이언트와 생각이 어긋나 엉뚱한 것을 만드는 문제는 AI가 해결해 주지 않습니다. 그래서 그의 스킬들은 대부분 “코드를 짜기 전에 사람과 AI가 같은 그림을 보게 만드는 것”에 집중합니다.

코드보다 기획부터: Grill Me

저장소에서 가장 인기 있는 스킬이 Grill Me입니다. 하는 일은 하나예요. AI가 개발자를 인터뷰합니다. 그것도 집요하게, 때로는 40개 가까운 질문을 쏟아냅니다. 매트 포콕은 이 아이디어가 자기 것이 아니라 Claude Code 팀의 Thariq가 “인터뷰는 강력한 기법”이라고 쓴 스레드에서 왔다고 밝힙니다.

왜 Plan Mode로는 부족할까요? 그는 에이전트에게 “에셋 러시(asset rush)”, 즉 조급한 완료(premature completion) 경향이 있다고 봅니다.

• LLM은 벤치마크에서 좋은 점수를 받도록 정답에 최대한 빨리 도달하려 합니다.
• 그래서 Plan Mode는 모호한 질문 몇 개만 던지고 서둘러 계획서(에셋)를 만들어 버립니다.
• Grill Me는 “계획을 만들어라”라는 다음 단계를 숨깁니다. “인터뷰만 해라”라고만 해서, 에이전트가 현재 단계에 더 오래 머물게 합니다.
• 멈출 시점은 사용자가 정하고, 그때까지 나눈 대화 자체가 결과물이 됩니다.

목표는 프레더릭 브룩스(Frederick Brooks)가 말한 설계 개념(design concept)을 AI와 공유하는 것입니다. 머릿속에 설계 개념이 선명해지면 구현은 AI에게 사소한 일이 됩니다. 실제로 한 회사는 Grill Me를 채용 면접에 쓰고 있다고 해요. 지원자가 AI의 질문에 답하면서 만들려는 것을 머릿속에 선명하게 유지할 수 있는지 보는 겁니다.

지금의 Grill Me는 이렇게 생겼습니다

팟캐스트에서는 “다섯 줄짜리 텍스트”라고 소개했지만, 현재 저장소(2026-10-19 커밋 기준)의 grill-me는 grilling 스킬을 부르는 진입점이고, 본체는 설계 트리(design tree)를 라운드 단위로 훑도록 다듬어졌습니다. 핵심 부분만 옮기면 다음과 같습니다.

Interview the user relentlessly until you reach a shared understanding. Map this as a
**design tree**: every decision branches into the decisions that hang off it.

Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are
already settled ... Ask the whole frontier in one round: number each question and give
your recommended answer. Then wait for the user's answers before the next round.

Finding _facts_ is your job, never the user's. ... dispatch a sub-agent to find it ...
The _decisions_ are the user's: put each to them and wait.

The session is done when the frontier is empty ... Do not act on it until the user
confirms you have reached a shared understanding.

실제로 어떻게 묻는지 궁금해서, 빈 디렉터리에 두 스킬 파일만 넣고 Claude Code로 한 라운드를 돌려 봤습니다. 주제는 이 블로그 자동화에 실제로 필요한 “WordPress draft의 깨진 블록 검사 도구”입니다.

mkdir -p grill-demo/.claude/skills/{grill-me,grilling} && cd grill-demo
curl -s https://raw.githubusercontent.com/mattpocock/skills/main/skills/productivity/grill-me/SKILL.md \
  -o .claude/skills/grill-me/SKILL.md
curl -s https://raw.githubusercontent.com/mattpocock/skills/main/skills/productivity/grilling/SKILL.md \
  -o .claude/skills/grilling/SKILL.md
claude -p "/grill-me WordPress REST API로 draft 글을 발행하기 전에 깨진 HTML 블록(닫히지 않은 wp:table 주석, 이스케이프 안 된 코드 등)을 자동으로 검사하는 CLI 도구를 만들고 싶어. 한국어로 질문해줘."

좋아요, 같이 설계를 다듬어 봅시다. 기존 `blog-automation` 코드의 언어, WP 클라이언트, 인증 방식은 지금
백그라운드에서 조사하고 있어요. 그 결과에 따라 정해지는 질문(구현 언어, 블록 파서 선택, 인증)은 다음 라운드로
미루고, 지금 바로 정할 수 있는 것부터 물어볼게요.

❓ **Q1** - **검사 범위 (v1)**: "깨진 블록"을 어디까지 잡을까요? 후보는 다음과 같아요.
- (a) 블록 구분자 짝 맞추기 ...
- (b) 블록 속성 JSON 유효성 ...
- (c) 블록 안 HTML 태그 균형 ...
- (d) 이스케이프 누락 ...
- (e) Gutenberg 수준 "Invalid block" 검증 ... JS 블록 레지스트리가 필요해서 무겁습니다.

➡️ v1은 (a)부터 (d)까지만 정적 검사로 만들고, (e)는 범위에서 빼는 걸 추천해요.

❓ **Q2** - **입력 소스**: 검사할 콘텐츠를 어디서 가져올까요? ...
➡️ (c) 둘 다를 추천해요. 핵심 로직은 문자열을 받는 함수 하나로 두고, REST는 입력 어댑터로만 붙이면 테스트하기도 쉬워요.

❓ **Q3** - **발행과의 관계**: 이 도구는 검사만 할까요, 아니면 발행 게이트 역할까지 할까요? ...
➡️ (a) 검사 전용을 추천해요. 쓰기 권한이 필요 없어 안전하고, 기존 파이프라인 어디에든 끼워 넣을 수 있어요.

... (Q4 심각도와 exit code, Q5 자동 수정 여부, Q6 출력 형식)

답변 주시면 그다음 라운드로 넘어갈게요. 다음 라운드에서는 구현 언어와 파서 선택, 인증 방식,
단일 글/전체 draft 배치 검사 여부를 다룰 예정이에요.

바로 코드를 쓰지 않고 첫 라운드에만 질문 6개가 나왔습니다. 질문마다 추천 답(➡️)이 붙어 있어서 “예”만 해도 진행되고, 기존 코드 조사처럼 사실 확인이 필요한 질문은 서브에이전트에 맡긴 뒤 다음 라운드로 미뤘습니다.

Grill with Docs: 질문하면서 문서까지

코드는 “어디에 도착했는지”는 설명하지만, 선택하지 않은 결정과 도메인 언어는 설명하지 못합니다. Grill with Docs는 그릴링에 도메인 모델링을 더해 저장소에 얇은 문서 층을 쌓습니다. 현재 저장소에서는 grilling과 domain-modeling 스킬을 함께 부르는 형태입니다.

• 유비쿼터스 언어(ubiquitous language): DDD 개념을 가져와 용어집을 만듭니다. “고스트 코스 안 고스트 섹션에 실제 레슨을 만들면 섹션과 코스도 실제가 되어야 하고 파일 경로가 필요하다” 같은 긴 문장 대신 “materialization cascade에 문제가 있어” 한마디로 통하게 됩니다.
• ADR(Architecture Decision Record): 그릴링 중에 내린 결정을 저장소에 기록합니다.
• 용어는 나중이 아니라 그릴링 바로 그 순간에 정하는 것이 맞다는 게 그의 경험입니다.

스펙(spec)에 대한 관점도 흥미롭습니다. 매트 포콕에게 스펙은 버리는 임시 산출물입니다. 여러 에이전트 세션에 작업을 나눠 주기 위한 도구일 뿐이고, 코드에 반영되면 지웁니다. OpenSpec을 쓰는 댄 클라크는 스펙을 유지하면 매번 코드베이스 전체를 뒤지는 토큰 비용을 아낄 수 있다고 반박합니다. 매트 포콕의 재반박은 이렇습니다. “스펙 갱신에 쓰는 토큰을 코드를 읽기 쉽게, 모듈을 잘 나누는 데 쓰면 어떨까요?”

Wayfinder와 스마트 존

Grill Me는 세션 하나에 묶입니다. 새 프로젝트처럼 큰 변경은 세션 하나에 담기지 않아요. 여기서 스마트 존(Smart Zone)이 등장합니다. HumanLayer의 덱스 호시(Dex Horthy)가 쓴 표현으로, 컨텍스트에 토큰이 적을수록 에이전트가 더 좋은 답을 낸다는 경험칙입니다.

• 매트 포콕은 세션의 처음 약 150k 토큰이 가장 좋은 결과를 낸다고 봅니다. 비용도 싸고 어텐션 저하도 없습니다.
• “그럼 100만 토큰 컨텍스트는 왜 파나요?”라는 질문에는, 컨텍스트 크기는 인프라 부담을 기준으로 정한 숫자일 뿐이고 넣을수록 서서히 나빠진다고 답합니다.
• 급격한 절벽이 아니라 휴리스틱입니다. 단순 리팩터링처럼 품질 요구가 낮은 작업은 덤 존(dumb zone)에 들어가도 괜찮습니다.

Wayfinder는 큰 작업의 기획을 여러 세션으로 쪼개 모두 스마트 존 안에서 하도록 만든 스킬입니다. 이슈 트래커에 “지도(map)” 이슈 하나를 만들고, 그 아래에 결정 티켓(decision ticket)을 하위 이슈로 답니다. 티켓 사이에는 트래커의 차단(blocking) 관계를 걸어서, 지금 손댈 수 있는 티켓이 트래커 화면에서 바로 보이게 합니다. 현재 SKILL.md는 티켓 하나를 “에이전트 세션 하나(100K 토큰)” 크기로 잡도록 안내합니다.

아직 티켓으로 나눌 수조차 없는 부분은 “Not yet specified”, 즉 전장의 안개(fog of war) 영역으로 남겨 둡니다. 매트 포콕은 특히 프로토타입이 과소평가돼 있다고 강조합니다. 원하는 모양과 동작의 프로토타입은 에이전트에게 “캣닢”이라, 그걸 읽고 프로덕션 코드로 바꾸는 데 아주 능숙하다는 거예요. 그는 Wayfinder를 정원 사무실 짓기 같은 코딩 밖의 일에도 쓰는데, 결국 측량사를 부르라는 결론까지 끌어냈다고 합니다.

대화에 나온 다른 스킬도 정리하면 다음과 같습니다.

스프린트에서 스펙 단위로

댄 클라크의 고객사는 여전히 스프린트로 일합니다. 개발자가 티켓 하나를 집어 보드를 가로질러 옮기는 방식이죠. 그는 이 구조가 오히려 “사람이 집을 테니 티켓은 대충 써도 된다”는 습관을 만든다고 봅니다. 이상적인 티켓은 이미 그릴링을 거쳐서, 에이전트가 밤새 혼자 처리할 수 있을 만큼 맥락을 담고 있어야 합니다.

매트 포콕은 더 나아가 작업 단위 자체를 바꾸자고 제안합니다.

• 티켓이 아니라 스펙을 소유한다: 개발자 한 명이 스펙 하나를 끝까지 책임지고, 그 스펙을 수행하는 에이전트의 생애 주기를 관리합니다. 한 사람이 스펙 4개를 동시에 굴리는 것도 가능합니다.
• 야간 근무(night shift)의 책임: 사람은 낮에, AI는 밤에 일한다는 그림(제이먼 홈그런(Jamon Holmgren)의 표현)은 매력적이지만, 아침에 어긋난 결과가 와 있으면 누가 고칠까요? 그는 지금 “AI가 했지, 내 코드 아니야”라는 책임의 위기가 있다고 진단합니다. 스펙마다 책임자가 있으면 그 코드는 그 사람의 코드가 됩니다.
• 인터페이스는 설계하고, 구현은 위임한다: 모든 줄을 이해할 필요는 없지만, 코드의 전체 모양과 다른 코드가 붙을 인터페이스는 반드시 책임져야 합니다. 이건 AI 이전부터 해 온 위임 방식이라는 점에서 익숙하다고 해요. 댄 클라크는 테스트도 구현 세부가 아니라 인터페이스(동작)에 대해 쓰면 이 구조와 잘 맞는다고 덧붙입니다.

노동력의 제약, 즉 『맨먼스 미신(The Mythical Man-Month)』의 전제도 바뀌었습니다. 노동은 여전히 필요하지만, 이제 기획 단계와 리뷰 단계에 몰리고 중간 구현은 사라졌다는 것이 두 사람의 공통된 진단입니다.

생산성을 끌어올리는 개인 무기들

음성 받아쓰기

두 사람 모두 Wispr Flow로 받아쓰기를 합니다. 그릴링 세션과 특히 잘 맞습니다. 단축키를 누르고 생각나는 대로 쏟아내면 되기 때문입니다.

• AI는 전사 오류를 알아서 걸러 듣기 때문에, 받아쓴 텍스트가 지금처럼 좋은 입력이었던 적이 없다고 합니다.
• 매트 포콕은 그릴링 세션 여러 개를 탭으로 오가며 동시에 받아쓰기로 답합니다.
• 댄 클라크는 오픈소스 대안으로 Handy도 써 봤는데 “괜찮지만 Wispr Flow만큼은 아니다”라고 평가했습니다. 로컬에서 돌아가는 Handy를 직접 테스트해 본 내용은 Handy 소개 글에 정리해 두었습니다.

스마트 존을 아끼는 작은 습관

• 객관식 질문 도구 끄기: 매트 포콕은 Claude Code의 질문 UI 도구(AskUserQuestion)를 꺼 둡니다. 싫기도 하지만 시스템 프롬프트에서 약 2K 토큰을 차지해서, 끄면 그만큼 스마트 존이 늘어난다는 이유입니다.
• 라우터 디렉터리: 모든 Claude Code 세션을 폴더 하나에서 시작하고, 그 루트의 CLAUDE.md에 “이 저장소는 여기, 저 저장소는 저기” 같은 길 안내만 둡니다.
• 한 번에 하나씩: 댄 클라크는 AI가 장황할 때 “질문이나 정보는 한 번에 하나씩”이라는 한 문단짜리 스킬을 씁니다. 매트 포콕은 OpenSpec의 explore 모드, Grill Me, superpowers의 brainstorm이 결국 같은 곳으로 수렴하고 있다고 말합니다.
• 세션 관리: 댄 클라크는 tmux 세션 상태를 표로 보여주는 자기만의 CLI를 Claude Code로 만들어 쓰고, 매트 포콕은 오픈소스 Herdr를 주목하고 있습니다.

개인 소프트웨어(Personal Software)의 시대

매트 포콕은 “개인 소프트웨어를 만들기 이렇게 쉬운 때는 없었다”고 말합니다. 대화에 나온 사례들은 이렇습니다.

주의사항

• 스킬은 계속 바뀝니다: 녹화 당시 “다섯 줄”이던 Grill Me는 지금 설계 트리와 라운드 구조로 바뀌었고, Grill with Docs도 다른 스킬을 조합하는 형태가 됐습니다. 영상 내용보다 저장소의 현재 SKILL.md를 기준으로 보세요.
• 스마트 존 수치는 경험칙입니다: 팟캐스트의 150k, Wayfinder SKILL.md의 100K처럼 같은 사람 안에서도 숫자가 다릅니다. 모델과 작업에 따라 달라지는 감각적 기준으로 받아들이는 편이 맞습니다.
• 설치는 한 가지 방식만: Claude Code는 claude plugin install mattpocock-skills@claude-plugins-official로 설치합니다. README는 플러그인과 skills.sh 복사 방식을 함께 쓰면 모든 스킬이 두 번 들어간다고 경고합니다.
• 그릴링은 사용자를 시험합니다: 질문에 답하려면 만들려는 것을 정말 알고 있어야 합니다. 귀찮다고 추천 답에 계속 “예”만 하면 Plan Mode와 다를 게 없어요.

마무리

대화의 끝에서 댄 클라크는 이렇게 고백합니다. “평생 코딩을 좋아한다고 생각했는데, AI가 알려 줬어요. 제가 좋아한 건 손으로 코드를 치는 게 아니라, 컴퓨터로 무언가를 만들고 도구를 다듬는 일이었더라고요.” 매트 포콕의 답은 처음과 같습니다. “또 전술 대 전략이네요. 전쟁에서 이기는 건 전략입니다.”

AI는 코드를 대신 짜 주는 도구이기도 하지만, 더 크게는 우리가 원래 좋아하던 설계하고 만드는 재미에 집중하게 해 주는 도구입니다. 다음 기능을 만들 때 바로 구현을 시키지 말고 Grill Me로 먼저 질문받아 보세요. 그리고 매일 반복하는 지루한 일 하나를 골라 나만의 스킬이나 개인 소프트웨어로 만들어 보세요. 스킬은 결국 몇 줄짜리 마크다운입니다.

참고

• YouTube — Agent Skills – with Matt Pocock (Unhandled Exception Podcast #88)
• The Unhandled Exception Podcast
• mattpocock/skills — Skills For Real Engineers
• AI Hero — AI Coding Dictionary: Smart Zone
• John Ousterhout — A Philosophy of Software Design