구현 계획을 하위 에이전트에 나눕니다 | DAKER 커뮤니티

오늘은 새 모델 발표가 아닙니다. 채팅에 기능을 한 번에 던져 넣고 결과를 기다리는 습관을 끊는 실험입니다. 구현 계획을 먼저 쓰고, 그 계획을 하위 에이전트와 TDD로 나눈 뒤, 사람과 AI가 차례로 검토합니다. 그 순서를 오늘 한 기능에 적용합니다.

참고 영상은 Alex Rusin의 The Exact Workflow I Use to Ship Features with AI Agents입니다. 채널은 Alex Rusin입니다. 이 글에는 주소만 둡니다. iframe은 넣지 않습니다. 영상이 실제로 보여 준 도구는 Matt Pocock의 Grill with Docs 스킬과 Superpowers 플러그인입니다. Grill with Docs 원문은 mattpocock/skills의 grill-with-docs 문서입니다. Superpowers 저장소는 obra/superpowers입니다. Claude 플러그인 페이지는 claude.com/plugins/superpowers입니다. 이 글은 방송 대본이 아닙니다. 오늘 해커톤 기능 하나를 티켓에서 통과까지 밀어 올리는 최소 루프입니다.

영상이 실제로 한 일입니다

데모 프로젝트는 작은 블로그 API입니다. Post 모델과 기본 CRUD 라우트가 이미 있습니다. 오늘 티켓은 슬러그입니다. Post에 slug 필드를 둡니다. 생성 시 제목에서 kebab-case로 만들고, 값은 고유해야 합니다. 제목을 바꾸면 슬러그도 다시 만듭니다. 슬러그로 Post를 읽는 엔드포인트도 추가합니다. 영상은 이 티켓을 ChatGPT에 붙여 넣는 방식으로 풀지 않습니다. 아래 여섯 단계를 순서대로 닫습니다.

첫 단계는 Grill with Docs입니다. 영상은 Matt Pocock 스킬을 쓰고, 높은 능력의 모델로 코드베이스를 읽힌 뒤 설계 질문을 받습니다. 모르는 항목은 추천 옵션을 고릅니다. 질문이 끝나면 공유된 이해와 데이터 모델, 슬러그 생성 전략, API 표면, 마이그레이션이 정리됩니다. context.md에는 Post와 slug 같은 용어가 용어집으로 쌓입니다. 공식 문서도 같은 취지를 적습니다. /grill-with-docs는 에이전트가 스스로 고르지 않습니다. 사용자가 칩니다. 세션 동안 합의된 말은 CONTEXT.md에 바로 들어가고, 되돌리기 어려운 결정은 docs/adr/에 ADR로 남습니다. 용어집에는 구현 세부를 넣지 말라고 문서가 못 박습니다.

두 번째 단계는 Superpowers의 구현 계획입니다. 영상은 코딩으로 바로 뛰어들지 않습니다. implementation plan 스킬을 켜고 계획을 문서 폴더에 둡니다. 영상에서 그 계획은 1,000줄을 넘는 분량이었습니다. 계획의 이득은 사람이 그 긴 글을 다 읽는 일이 아닙니다. 하위 에이전트가 태스크 단위로 나눠 받고, 병렬 가능한 일은 병렬로 돌리며, 각 에이전트가 짧은 맥락으로 일하게 만드는 일입니다. 스마트한 모델이 계획을 쓴 뒤에는 구현에 더 가벼운 모델을 쓸 여지도 생긴다고 영상이 말합니다.

세 번째 단계는 sub-agent driven development와 TDD입니다. 영상은 Superpowers 스킬로 하위 에이전트와 테스트를 같이 돌립니다. TDD는 테스트를 먼저 쓰고, 실패를 확인하고, 통과할 최소 코드만 넣은 뒤 리팩터합니다. red-green-refactor입니다. 작업이 끝나면 병합, PR 생성, 브랜치 유지, 폐기 중 하나를 고릅니다. 영상은 브랜치를 유지한 채 다음 단계로 갑니다.

네 번째 단계는 사람 검토입니다. 에이전트가 쓴 파일을 직접 엽니다. 슬러그 계산이 컨트롤러에 있는지, 유틸로 빼는 편이 맞는지처럼 구조 결정을 사람이 확인합니다. 배우는 중이라면 왜 그 함수가 있는지 에이전트에게 다시 물을 수 있습니다. 다섯 번째 단계는 맥락을 비운 뒤 AI 코드 리뷰입니다. 영상은 구현 중 태스크마다 커밋이 생겨 총 13개 커밋을 검토하라고 시킵니다. 작성에 쓴 모델과 다른 모델이나 다른 에이전트로 검토하는 편이 낫다고 말합니다. Sonnet이 썼다면 Opus나 Codex로 보는 식입니다. 같은 에이전트만 있어도 검토 단계는 남깁니다. 마지막 단계는 UAT입니다. 에이전트에게 사용자 관점 QA 계획을 쓰게 하고, Postman이나 REST 클라이언트나 bash로 사람이 직접 칩니다. 영상이 닫는 한 줄은 이렇습니다. AI로 코드를 빨리 쓰는 일이 전부가 아닙니다. 이해하고 책임질 수 있는 반복 가능한 절차가 필요합니다.

공식 문서가 보태는 뼈대입니다

Grill with Docs 문서는 스킬 본문이 grilling과 domain-modeling에 위임한다고 적습니다. grill-with-docs만 설치하고 두 의존 스킬이 없으면, 질문 더미만 나오고 CONTEXT.md가 안 생길 수 있습니다. 문서가 권하는 점검 문장은 에이전트에게 어떤 스킬을 로드했는지 직접 묻는 일입니다. 세션이 끝난 뒤에도 합의의 상당수는 대화에만 남을 수 있습니다. 용어집과 ADR 조건을 통과하지 못한 결정은 파일로 안 갑니다. 그래서 문서는 같은 대화를 to-spec으로 넘기라고 적습니다. 오늘 숙제에서는 그 사슬 전체를 복제하지 않습니다. 기능 하나를 붙들 때 질문 세션과 CONTEXT.md와 구현 계획 파일만 먼저 남깁니다.

Superpowers README와 Claude 플러그인 페이지는 brainstorming, writing-plans, subagent-driven-development, TDD, 코드 리뷰 스킬을 하나의 방법론으로 묶습니다. writing-plans는 승인된 설계를 짧은 태스크로 쪼갭니다. subagent-driven-development는 태스크마다 새 하위 에이전트를 보내고, 스펙 준수 검토 다음에 코드 품질 검토를 둡니다. 플러그인 페이지는 red-green-refactor에서 테스트가 실패하기 전에 구현으로 건너뛰지 말라고 강조합니다. 오늘 숙제는 그 강제 장치를 영상 순서대로 한 번 타 보는 일입니다. 플러그인 설치 광고를 이 글에서 만들지 않습니다. Claude Code 플러그인 목록의 Superpowers, 또는 저장소 README가 적는 설치 경로를 따릅니다.

이 글이 아닌 것입니다

새 코딩 모델을 기다리는 글이 아닙니다. GPT나 Claude의 최신 벤치 점수를 다시 쓰는 글도 아닙니다. 오늘 바뀌는 것은 티켓을 닫는 순서입니다. 채팅 한 방에 기능을 맡기는 습관을, 질문과 계획과 테스트와 검토로 바꿉니다.

Adi Osmany Agent Skills 가이드를 다시 쓰는 글이 아닙니다. 그 각도는 이미 다른 글에서 다뤘습니다. 오늘 원문은 Alex Rusin 영상과 Matt Pocock의 grill-with-docs, obra/superpowers입니다. slash spec / build / test 공장 비유를 이 제목 아래로 끌어오지 않습니다.

Playwright로 제출 링크를 여는 숙제가 아닙니다. 그 숙제는 다른 글입니다. 오늘 숙제는 API 기능 티켓의 계획과 TDD와 검토입니다. 프롬프트를 시험 세트로 돌리는 promptfoo 글과도 합치지 않습니다. 비밀번호를 채팅에 넣지 말라는 글, 보내기 확인을 먼저 읽으라는 글과도 제목을 섞지 않습니다.

영상 안의 1,000줄 넘는 계획과 13개 커밋을 모든 팀에 의무 숫자로 만들지 않습니다. 그 숫자는 영상 데모에서 나온 기록입니다. 오늘 팀 티켓의 계획 길이와 커밋 수는 팀이 재현한 결과로만 적습니다. 없는 절감률과 별 숫자와 설치 수를 이 글에서 만들지 않습니다. DAKER 플랫폼 숫자도 이 글의 핵심이 아닙니다. 필요하면 25만 빌더 · 339+ 대회 · 29억+만 씁니다.

유튜브 화면을 이 글에 넣지 않습니다. 주소만 둡니다. iframe은 쓰지 않습니다. 설치 광고와 조회수 자랑과 자극적인 썸네일만 고른 글이 아닙니다. 영상이 오늘 필요한 이유는 재현 가능한 순서입니다. Grill → Plan → sub-agent TDD → 사람 검토 → AI 검토 → QA 계획입니다.

배포가 제출입니다. 올린 링크가 제출입니다. 그 문장은 로컬에서만 통과한 브랜치를 제출로 부르지 말라는 뜻입니다. 오늘 루프가 API를 고쳤다면, 공개된 주소나 팀이 합의한 스테이징에서 같은 슬러그 흐름이 통과해야 제출로 부릅니다. 채팅에 남은 계획 파일만으로는 제출이 아닙니다.

오늘 할 일입니다

오늘 범위는 모델 교체가 아닙니다. 지금 쓰는 코딩 에이전트에 Grill with Docs 또는 동등한 질문 세션, Superpowers 또는 동등한 계획·TDD·리뷰 스킬을 한 기능에 적용하는 일입니다. 새 제품 전체를 다시 쓰지 않습니다. 열린 티켓 하나면 충분합니다.

• 오늘 닫을 기능 티켓 하나를 고릅니다. 영상처럼 slug 같은 작은 API 변경이거나, 팀이 이미 백로그에 둔 한 줄짜리 기능입니다. 범위를 두 개 이상으로 늘리지 마십시오.
• 저장소에서 Grill with Docs를 쓸 수 있으면 /grill-with-docs를 칩니다. 없으면 같은 취지로 설계 질문을 받게 하고, 합의된 용어를 CONTEXT.md 또는 팀 용어집 파일에 직접 적습니다. 공식 문서대로 grilling과 domain-modeling이 로드됐는지 에이전트에게 확인합니다.
• 질문이 끝나면 구현으로 가지 않습니다. Superpowers의 writing-plans 또는 동등한 계획 스킬로 구현 계획 파일을 만듭니다. 파일 경로와 검증 방법이 태스크마다 보이게 둡니다. 계획 파일을 채팅에만 남기지 마십시오.
• 계획 승인 뒤에 sub-agent driven development와 TDD를 켭니다. 테스트가 실패하는 장면을 먼저 남깁니다. 통과 코드만 넣고, 리팩터합니다. 태스크마다 커밋을 남길지는 팀 규칙에 맞춥니다. 영상처럼 커밋이 쌓이면 그 목록을 다음 검토 입력으로 씁니다.
• 구현이 멈추면 사람이 파일을 엽니다. 슬러그 로직 위치, 이름, 테스트 위치처럼 구조가 팀 규칙에 맞는지 확인합니다. 마음에 안 드는 배치는 고치라고 시킨 뒤 다시 읽습니다.
• 맥락을 비우거나 새 세션을 연 뒤 코드 리뷰 스킬을 돌립니다. 가능하면 구현에 쓴 모델과 다른 모델로 검토합니다. Important 이슈는 고치고, 미룬 항목은 티켓에 적습니다.
• 에이전트에게 UAT 또는 QA 계획을 파일로 쓰게 합니다. 그다음 사람이 직접 호출합니다. API라면 생성·수정·슬러그 조회·중복 충돌처럼 티켓 문장을 그대로 칩니다. 에이전트 요약만 보고 통과로 부르지 마십시오.
• 팀 README나 대회 제출 노트에 오늘 쓴 명령 순서를 남깁니다. Grill 명령, 계획 파일 경로, TDD 실행 방법, 리뷰 명령, QA 계획 경로입니다. 채팅에만 남은 순서는 다음 사람이 재현하지 못합니다. 공개 배포가 필요하면 배포가 제출입니다. 올린 링크가 제출입니다.

한 줄로 줄이면 이렇습니다. 기능을 채팅에 한 번에 던지지 않습니다. 질문으로 용어를 맞추고, 구현 계획을 파일로 남기고, 하위 에이전트에 TDD로 나눠 맡기고, 사람과 AI가 차례로 검토한 뒤 QA 계획으로 직접 칩니다. 구현 계획을 하위 에이전트에 나눕니다.

원문: The Exact Workflow I Use to Ship Features with AI Agents · Alex Rusin · grill-with-docs · obra/superpowers · Superpowers 플러그인