일하는 ai

52. 맷 포콕이 만든 AI 코딩

13 min read

-

이 영상은 AI 코딩이 왜 자꾸 엉뚱해지는지부터 짚고, 그걸 잡는 맷 포콕의 스킬들을 실전 흐름으로 묶어 보여 줍니다. 메이커 에반의 결론은 분명해요. 프롬프트 한 줄보다 질문 루프, TDD, 진단, 코드베이스 관리가 더 중요하다는 겁니다.

flowchart LR
A[AI 코딩의 반복 문제] --> B[그릴미로 요구사항 정교화]
B --> C[to-PRD와 TDD로 구현 통제]
C --> D[diagnose·improve-codebase로 품질 유지]

핵심 요약

  • 메이커 에반은 AI 에이전트와 일할 때 자주 생기는 문제를 요구 사항과 구현 불일치, 반복 설명, 코드 품질 저하, 아키텍처 붕괴 네 가지로 정리한다
  • 맷 포콕의 스킬은 GST, 슈퍼파워즈, OMC 같은 풀세트 프레임워크와 다르게 원하는 것만 골라 쓰는 가이드북형 구성이라고 설명한다
  • 핵심 스킬로는 grill-me, to-PRD, TDD, diagnose, improve-codebase가 소개되고, 각 스킬이 기획부터 구현, 디버깅, 구조 개선까지 다른 위치를 맡는다
  • 특히 좋은 결과를 만드는 핵심은 AI 자체보다 피드백 루프 품질과 좋은 코드베이스라고 강조한다
  • 실전 워크플로우는 질문으로 컨셉을 좁히고, PRD로 요약하고, 작은 단위 TDD로 구현하고, 막히면 diagnose로 풀고, 매일 코드베이스 구조를 업데이트하는 흐름으로 정리된다

왜 지금 중요한가

요즘 AI 코딩 도구가 늘어나면서 같은 요청에도 결과가 들쑥날쑥하고, 코드가 점점 망가진다는 얘기를 많이 하죠. 이 영상이 좋은 건 그걸 단순한 모델 성능 문제로 보지 않는다는 점입니다. 결국 좋은 AI 활용은 좋은 질문 구조, 좋은 검증 루프, 좋은 코드베이스 위에서만 나온다는 걸 꽤 현실적으로 짚어 줍니다.

주요 내용

문제는 AI 한 번이 아니라 반복될수록 커진다

영상 초반에 메이커 에반은 아주 익숙한 장면부터 꺼냅니다. 같은 요청을 똑같이 던졌는데 결과가 매번 달라지고, 큰 기능을 만들어 달라고 하면 마지막에 엉뚱한 코드를 내놓고, 어떤 코드베이스에서는 잘 일하는데 어떤 데서는 계속 헛발질한다는 거죠.

이걸 따로따로 보지 않고 한 흐름의 문제로 묶는 게 이 영상의 출발점입니다. 요구사항과 구현이 어긋나고, 프로젝트 설명을 반복해야 하고, 코드 품질이 망가지고, 결국 아키텍처까지 무너지는 순서로 이어진다는 겁니다.

첫 번째는 grill-me, 즉 AI에게 끈질기게 질문받는 단계다

메이커 에반이 가장 먼저 소개하는 건 grill-me입니다. 이름 그대로 AI가 사용자를 그릴 위에 올려놓고 굽듯이, 디자인 컨셉에 도달할 때까지 끈질기게 인터뷰하는 스킬이라고 설명합니다.

여기서 포인트는 문서를 잘 쓰는 게 아니라 디자인 컨셉을 맞추는 데 있습니다. 머릿속 그림, 문서, AI의 이해가 전부 다르기 때문에, 빠진 의사결정을 질문으로 계속 드러내야 한다는 거죠. 예시로는 사용자 유지율이 별로니까 게임화 추가해 주세요처럼 두루뭉술한 요청을 던지면, AI가 포인트를 어디에 줄지, 기존 데이터는 어떻게 할지 같은 질문을 쏟아내고, 추천 답변까지 같이 줘서 빠르게 결정하게 만든다고 설명합니다.

짧으면 20개, 길면 80~100개 질문이 나온다고 하고, 이 단계는 절대 자리 비우는 작업이 아니라고 못 박습니다. 사람, 도메인 전문가, 개발자, AI가 같이 붙어 있어야 하는 단계라는 거죠.

그다음은 문서화와 TDD로 AI를 작은 단위에 가둔다

그릴링이 끝나면 그 대화를 자산으로 바꾸는 게 to-PRD라고 설명합니다. 문제 정의, 솔루션, 사용자 스토리, 구현 결정, 상황 정리, 그리고 무엇을 안 할지까지 포함한 도착지 문서를 자동으로 만든다는 거예요. 메이커 에반은 이 PRD를 굳이 자세히 다시 검토하지 않는다고 말합니다. 이미 같은 이해를 갖고 그릴링을 끝냈고, 요약은 LM이 잘하는 일이기 때문이죠.

구현 단계에서는 TDD가 핵심으로 나옵니다. AI에게 기능 만들고 테스트도 같이 써 줘라고 하면, 구현을 먼저 다 만들고 그 위에 테스트를 덮는 식이 되기 쉽다고 지적합니다. 그렇게 되면 테스트가 구현을 따라가는 종속물이 돼서, 버그가 있어도 같이 통과해 버린다는 거죠.

그래서 순서를 바꿔야 한다고 말합니다. 테스트를 먼저 만들고, 통과하는 코드만 짜고, 그다음 정리하는 레드-그린-리팩터 사이클로 가면 AI도 작은 단위로 차근차근 일하게 됩니다. 그리고 여기서 피드백 루프 품질이 AI 출력의 천장이라는 문장이 나옵니다. 테스트와 타입체크가 빠르고 정확하게 실패를 알려 줘야 AI도 자기 실수를 고칠 수 있다는 얘기예요.

diagnose와 improve-codebase는 구현 이후의 운영 스킬이다

네 번째 스킬 diagnose는 디버깅용입니다. 메이커 에반은 보통 AI에게 이거 왜 안 돼?라고 물으면 추측을 반복하다가 30분이 날아간다고 말합니다. 반면 diagnose는 에러 재현, 가설 수립, 가설 검증의 순서를 강제해서 움직이게 만든다는 거죠. 의사가 진찰 없이 약부터 주는 게 아니라 검사 결과를 보고 진단하는 흐름과 비슷하다고 설명합니다.

다섯 번째 스킬 improve-codebase는 구조를 다룹니다. 여기서 중요한 문장이 하나 나옵니다. 나쁜 코드베이스는 나쁜 에이전트를 만든다. 좋은 모델, 좋은 프롬프트, 좋은 워크플로우가 있어도 코드베이스가 엉망이면 결과도 별로라는 거죠. 이 스킬은 어디가 망가지고 있는지, 어디를 통합해야 하는지, 어디를 모듈로 묶어야 하는지를 알려 주는 역할로 설명됩니다.

메이커 에반은 여기에 보너스 팁도 붙입니다. 인터페이스는 직접 설계하고 구현만 AI에게 맡기라는 것, 그리고 구현 세션과 리뷰 세션을 분리하라는 겁니다. 구현 직후 같은 세션에서 리뷰하면 토큰을 많이 쓴 상태라 AI도 멍한데, 리뷰 전용 새 컨텍스트에서 더 강한 모델로 검열하는 편이 낫다는 설명이 인상적입니다.

원문 발화 하이라이트

  • [00:42] “AI 에이전트랑 일할 때 큰 문제가 네 가지래요.”
  • [01:38] “그릴미에요. 그릴 위에 올려놓고 굽듯이 AI한테 끈질기게 질문 받는 스킬이에요.”
  • [03:29] “답은 TDD입니다. 테스트 주도 개발이에요.”
  • [03:46] “코드 베이스의 피드백 루프 품질이 AI 출력의 천장이에요.”
  • [04:40] “나쁜 코드 베이스는 나쁜 에이전트를 만든다.”
  • [06:17] “매일 아침 improve-codebase architecture 스킬을 이용을 해 가지고 코드 베이스를 계속해서 업데이트를 시킵니다.”

바로 실행해 보기

  • 다음에 AI에게 큰 기능을 맡기기 전에 바로 구현부터 시키지 말고, 먼저 grill-me 방식으로 질문을 받는 시간을 따로 만들어 보세요. 요구사항이 흐리면 구현이 틀어지는 건 거의 필수라는 게 이 영상의 첫 포인트였습니다
  • 프로젝트 핵심 개념을 마크다운 문서로 정리해 두고, 그걸 기준으로 PRD를 한 번 만들어 보세요. 특히 무엇을 안 할지 범위 밖 항목까지 적는 게 실전에서 꽤 도움이 됩니다
  • 다음 기능 하나만이라도 테스트 먼저 → 통과하는 코드 작성 → 정리 순서로 해 보세요. 막히면 diagnose로 원인 분석하고, 끝난 뒤에는 improve-codebase 관점으로 구조를 다시 보는 흐름까지 한 번만 돌려 봐도 작업 방식이 꽤 달라질 겁니다

참고

영상 메타

수집 품질

  • 자막 세그먼트: 235개
  • 자막 문자수: 4274자
  • 챕터 추출: 10개
  • 콘텐츠 생성: Subagent 기반

AI 생성 도구를 활용해 초안을 구성했고, 원영상 발화와 공개 자료를 교차 확인해 정리했습니다.

그래프 뷰

백링크