일하는 ai

54. 유튜버 에반의 AI 워크플로우 대

13 min read

-

이 영상은 메이커 에반이 실제로 쓰는 AI 개발 워크플로우를 처음부터 끝까지 풀어 보여 줍니다. 핵심은 도구 하나로 해결하지 않는다는 거예요. 맷 포콕 스킬은 도메인과 DDD를 잡고, G-Stack은 스펙과 브레인스토밍을 밀도 있게 다듬고, 슈퍼파워즈는 실제 구현과 서브에이전트 실행을 맡기는 식으로 역할을 나눕니다.

flowchart LR
A[도메인과 용어 정리] --> B[G-Stack으로 스펙 검증]
B --> C[슈퍼파워즈로 플랜·구현]
C --> D[코덱스 리뷰와 아키텍처 리팩토링]

핵심 요약

  • 메이커 에반은 스킬 하나만 쓰면 한계가 분명하다고 보고, 맷 포콕 스킬·G-Stack·슈퍼파워즈를 역할별로 조합해 쓴다
  • 맷 포콕 스킬의 주된 목적은 도메인 맵핑이며, 여기에 DDD 아키텍처링을 커스텀으로 얹어 도메인 모델이 폴더 구조와 코드 경계까지 이어지게 만든다
  • G-Stack은 브레인스토밍과 제품 스펙 정제에 강하고, 특히 무엇을 빼야 하는지를 끝까지 캐묻는 역할로 설명된다
  • 슈퍼파워즈는 실제 구현 단계의 메인 엔진으로, 브레인스토밍 결과를 받아 라이트 스펙·플랜·서브에이전트 드리븐 디벨롭먼트까지 이어 간다
  • 구현 뒤에는 코덱스로 리뷰하고, 마지막에는 improve-codebase 아키텍처 스킬과 추가 리팩토링 스킬로 도메인 중심 구조를 다시 정리한다

왜 지금 중요한가

AI 개발 도구가 많아질수록 무슨 모델이 더 좋냐보다 누가 어떤 단계에서 무슨 역할을 맡느냐가 더 중요해집니다. 이 영상은 그걸 아주 실무적으로 보여 줘요. 바로 코드를 치기보다 도메인, 비즈니스 이유, 상세 스펙, 플랜 리뷰, 구현, 리팩토링까지 순서를 분리해 놓으면 결과물 퀄리티가 얼마나 달라지는지를요.

주요 내용

1단계는 도메인부터 고정하는 것이다

영상 초반에 메이커 에반은 먼저 각 도구의 역할을 나눠 설명합니다. 맷 포콕 스킬은 도메인 맵핑이 목적이라고 해요. 우리 서비스 안에서 쓰는 단어가 정확히 무슨 뜻인지 AI에게 박아 넣는 작업이라는 거죠.

예시도 직관적입니다. 주문이라는 단어 하나만 해도 일반 쇼핑몰, 음식 배달, B2B 발주는 뜻이 다르잖아요. 이걸 그냥 주문이라고 던지면 AI가 헷갈린다는 거예요. 그래서 그릴미 스킬로 질문을 통해 도메인 문서를 만들고, 거기서 한 발 더 나아가 DDD 아키텍처링을 커스텀으로 얹었다고 설명합니다.

여기서 중요한 건 용어 정리로 끝내지 않는다는 점입니다. 도메인 모델이 폴더 경계, 모듈 경계, 함수 시그니처까지 이어지게 만들어서, 같은 단어를 같은 뜻으로 이해하는 데서 끝나는 게 아니라 실제 코드 구조까지 그 도메인이 끌고 가게 한다는 거예요.

2단계는 G-Stack으로 스펙을 흔들어 보는 과정이다

그다음은 G-Stack입니다. 메이커 에반은 G-Stack의 강점을 브레인스토밍, 그중에서도 제품 스펙을 적을 때라고 말합니다. 그냥 아이디어를 같이 생각해 주는 수준이 아니라, 이 기능이 진짜 핵심 가치에 붙는지, 누가 쓰는지, 없으면 어떻게 되는지 같은 걸 심도 있게 캐묻는다는 거죠.

특히 뭘 더 넣을지가 아니라 뭘 빼야 하는지를 집요하게 본다고 설명합니다. 보통은 다 넣고 싶어지는데, G-Stack은 빼야 할 건 빼라고 밀어붙인다는 거예요.

여기서 오피스 아워즈 스킬이 대표적으로 언급됩니다. 이 기능을 누가 진짜 원하는지, 지금은 어떻게 해결하고 있는지, 정말 절박한 문제인지, 가장 작은 단위는 뭔지 같은 질문 흐름을 통해 스펙의 핵심과 노이즈를 갈라낸다고 설명하죠. 도메인을 깊게 파는 그릴미와, 비즈니스 임팩트를 묻는 오피스 아워즈를 차례로 거치면 기술적으로 이해된 문제와 왜 만들어야 하는가가 동시에 잡힌다고 말합니다.

그리고 여기서 아주 중요한 한 줄이 나옵니다. 여기까지 한 시간 정도 걸렸지만 코드는 한 줄도 안 짰다는 거예요. 바로 코딩에 들어가면 나중에 헛수고만 드는 경우가 많다는 메시지죠.

3단계는 슈퍼파워즈로 플랜과 구현을 분리해 돌린다

이제부터 실제 구현 단계로 넘어갑니다. 메이커 에반은 슈퍼파워즈에서 브레인스토밍, 라이트 스펙, 서브에이전트 드리븐 디벨롭먼트를 메인으로 쓴다고 설명합니다.

먼저 G-Stack 결과를 다시 슈퍼파워즈 브레인스토밍에 넣어서 이걸 코드로 어떻게 풀 거야 수준의 상세 스펙을 확정합니다. 그다음 라이트 플랜을 쓰고, 바로 구현으로 가는 게 아니라 커스텀 리뷰 에이전트로 플랜 리뷰를 한 번 더 돌린다고 해요. 여기 2단계가 빠졌는지, 순서가 맞는지, 작업 덩어리가 너무 큰지 같은 걸 빨간 펜으로 수정해 주는 시니어 리뷰처럼 쓰는 거죠.

플랜이 정해지면 이제 서브에이전트 드리븐 디벨롭먼트로 갑니다. 큰 작업을 여러 개로 쪼개서 각각을 별도 에이전트에 맡기는 방식이에요. 큰 공사를 전기, 배관, 목공으로 나눠 맡기는 것처럼 설명합니다. 보통 두 시간 정도 돌리고, 그동안 본인은 다른 일을 하다가 단계별 결과 알림을 받고 중간 검수한다고 해요.

4단계는 코덱스 리뷰와 아키텍처 정리다

메이커 에반은 여기서 그냥 다 맡겨 두면 안 된다고 분명히 말합니다. 중간 검수가 핵심이고, 그래서 코덱스 플러그인을 클로드 코드 안에서 같이 쓴다고 설명합니다. 서로 다른 모델이라 한쪽이 짠 코드를 다른 쪽이 보면 사각지대가 꽤 많이 잡힌다고 해요. 특히 세세한 구현에서는 코덱스가 훨씬 잘하는 느낌을 받는다고도 말합니다.

구현이 거의 끝나면 마지막으로 improve-codebase architecture를 돌립니다. 이 스킬은 앞에서 만든 도메인 파일을 기준으로 지금 코드가 도메인 개념과 어긋나는 부분, 사실 같은 개념인데 따로 떨어진 부분을 짚어 주며 리팩토링 포인트를 잡아 준다고 설명합니다.

여기에 프런트엔드용 React/Vercel 베스트 프랙티스 스킬, 백엔드용 FastAPI 가이드라인 같은 커스텀 스킬도 덧붙여, 서비스 로직을 라우트 밖으로 빼는 식의 추가 리팩토링까지 유도한다고 해요. 메이커 에반의 정리는 명확합니다. 시간이 두세 시간, 길면 그 이상 걸리더라도 이렇게 만들어진 코드는 도메인 개념과 맞물려 있고, 나중에 사람이 수작업으로 버그를 고칠 수 있는 상태가 된다는 거죠.

원문 발화 하이라이트

  • [00:08] “스킬 하나만 쓰면 한계가 분명히 있어요.”
  • [00:14] “도메인 맵핑이 주된 목적이에요.”
  • [02:44] “G스택은 거기서 안 봐줘요. 빼야 할 건 빼라고 끝까지 밀어붙여요.”
  • [03:56] “플랜 리뷰를 돌립니다.”
  • [04:10] “실제 구현 단계에 들어가면 이걸로 코드를 짭니다.”
  • [09:24] “코드 한 줄 한 줄이 도메인 개념이랑 맞물려 있고”

바로 실행해 보기

  • 새 기능을 만들 때 바로 코드부터 짜지 말고, 먼저 도메인 용어집부터 만들어 보세요. 주문, 결제, 사용자 같은 핵심 단어를 프로젝트 맥락에 맞게 정의해 두는 것만으로도 AI 출력이 꽤 달라집니다
  • 브레인스토밍 단계에서는 무엇을 더 넣을까보다 무엇을 빼야 할까를 묻는 시간을 꼭 따로 가지세요. 이 영상의 G-Stack 파트도 바로 그 지점을 가장 중요하게 다뤘습니다
  • 구현에 들어가기 전에는 라이트 스펙과 플랜을 먼저 만들고, 가능하면 별도 리뷰 에이전트나 다른 모델로 한 번 더 검수한 뒤 서브에이전트로 넘겨 보세요. 마지막에는 도메인 파일 기준으로 아키텍처 리팩토링까지 한 번 돌리는 게 좋습니다

참고

영상 메타

수집 품질

  • 자막 세그먼트: 339개
  • 자막 문자수: 6156자
  • 챕터 추출: 5개
  • 콘텐츠 생성: Subagent 기반

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

그래프 뷰

백링크