기능 구현을 하위 에이전트에 나누는 방법: 계획부터 TDD, 리뷰, QA까지 | DAKER 커뮤니티

AI 코딩 도구가 익숙해질수록 기능 하나를 채팅창에 통째로 넣고 결과를 기다리는 방식도 자연스러워집니다. 다만 그렇게 만든 결과는 빠를 수 있어도, 왜 그렇게 구현됐는지 설명하기 어렵고 다음 사람이 같은 절차를 재현하기도 쉽지 않습니다.

오늘 다루는 내용은 새 모델 소개가 아닙니다. 구현 계획을 먼저 세우고, 그 계획을 하위 에이전트와 TDD로 나눈 뒤, 사람과 AI가 차례로 검토하는 흐름을 기능 하나에 적용하는 방법입니다. 참고 영상은 Alex Rusin의 The Exact Workflow I Use to Ship Features with AI Agents이며, 채널은 Alex Rusin입니다.

영상에서 실제로 사용한 도구는 Matt Pocock의 Grill with Docs 스킬과 Superpowers 플러그인입니다. 관련 문서는 mattpocock/skills의 grill-with-docs 문서, obra/superpowers, claude.com/plugins/superpowers에서 확인할 수 있습니다. 이 글은 방송 대본이 아니라, 해커톤이나 실무에서 기능 티켓 하나를 통과까지 밀어 올리는 최소 루프를 정리한 글입니다.

영상이 보여 준 핵심 흐름

데모 프로젝트는 작은 블로그 API입니다. Post 모델과 기본 CRUD 라우트가 이미 있고, 이날의 티켓은 slug 기능 추가입니다. Post에 slug 필드를 두고, 생성 시 제목에서 kebab-case로 만들며, 값은 고유해야 합니다. 제목을 바꾸면 슬러그도 다시 만들고, 슬러그로 Post를 읽는 엔드포인트도 추가합니다.

중요한 점은 이 티켓을 곧바로 ChatGPT에 붙여 넣어 해결하지 않았다는 점입니다. 영상은 여섯 단계를 순서대로 닫아 갑니다.

AI로 코드를 빨리 쓰는 일만으로는 충분하지 않습니다. 이해하고 책임질 수 있는 반복 가능한 절차가 필요합니다.

1. Grill with Docs로 질문부터 정리합니다

첫 단계는 Grill with Docs입니다. 영상에서는 높은 능력의 모델로 코드베이스를 읽힌 뒤 설계 질문을 받습니다. 모르는 항목은 추천 옵션을 고르고, 질문이 끝나면 공유된 이해, 데이터 모델, 슬러그 생성 전략, API 표면, 마이그레이션 방향이 정리됩니다.

이 과정에서 CONTEXT.md에는 Post와 slug 같은 용어가 용어집으로 쌓입니다. 공식 문서도 같은 취지를 설명합니다. /grill-with-docs는 에이전트가 스스로 고르는 명령이 아니라 사용자가 직접 입력하는 방식이며, 세션 동안 합의된 말은 CONTEXT.md에 들어가고 되돌리기 어려운 결정은 docs/adr/에 ADR로 남깁니다. 문서는 용어집에 구현 세부를 넣지 말라고 분명히 적고 있습니다.

2. 구현 전에 계획 파일을 만듭니다

두 번째 단계는 Superpowers의 구현 계획입니다. 영상은 코딩으로 바로 넘어가지 않고 implementation plan 스킬을 켜서 계획을 문서 폴더에 둡니다. 영상 속 계획은 1,000줄이 넘는 분량이었습니다.

이 긴 계획의 장점은 사람이 처음부터 끝까지 정독하는 데 있지 않습니다. 하위 에이전트가 태스크 단위로 나눠 받아 일하고, 병렬 가능한 작업은 병렬로 처리하며, 각 에이전트가 짧은 맥락 안에서 움직일 수 있게 만드는 데 의미가 있습니다. 영상은 똑똑한 모델이 계획을 먼저 쓴 뒤에는 구현 단계에서 더 가벼운 모델을 쓸 여지도 생긴다고 설명합니다.

구현 계획은 사람이 읽기 위한 문서이기도 하지만, 하위 에이전트가 짧은 맥락으로 일하게 만드는 작업 단위이기도 합니다.

3. 하위 에이전트와 TDD로 구현합니다

세 번째 단계는 sub-agent driven development와 TDD입니다. 영상에서는 Superpowers 스킬로 하위 에이전트와 테스트를 함께 돌립니다. TDD는 테스트를 먼저 쓰고, 실패를 확인한 뒤, 통과할 최소 코드만 넣고, 마지막에 리팩터하는 흐름입니다. 흔히 말하는 red-green-refactor입니다.

작업이 끝나면 병합, PR 생성, 브랜치 유지, 폐기 중 하나를 고를 수 있고, 영상은 브랜치를 유지한 채 다음 단계로 넘어갑니다.

4. 사람이 구조를 직접 확인합니다

네 번째 단계는 사람 검토입니다. 에이전트가 만든 파일을 직접 열어 봅니다. 예를 들어 슬러그 계산이 컨트롤러에 있는지, 유틸로 빼는 편이 맞는지 같은 구조적 판단은 사람이 확인합니다. 학습 중이라면 왜 특정 함수가 생겼는지 에이전트에게 다시 물어볼 수도 있습니다.

5. 다른 맥락에서 AI 코드 리뷰를 돌립니다

다섯 번째 단계는 맥락을 비운 뒤 AI 코드 리뷰를 하는 것입니다. 영상에서는 구현 중 태스크마다 커밋이 생겨 총 13개 커밋을 검토 대상으로 삼습니다. 작성에 쓴 모델과 다른 모델이나 다른 에이전트로 검토하는 편이 낫다고 설명합니다. 예를 들어 Sonnet이 썼다면 Opus나 Codex로 보는 식입니다. 같은 에이전트만 쓸 수 있어도 검토 단계 자체는 남겨 두는 편이 좋습니다.

6. 마지막은 UAT입니다

마지막 단계는 UAT입니다. 에이전트에게 사용자 관점의 QA 계획을 쓰게 하고, Postman이나 REST 클라이언트, 또는 bash로 사람이 직접 호출합니다. 결국 기능이 닫혔다고 부르려면 채팅 요약이 아니라 실제 동작을 확인해야 합니다.

공식 문서가 보태는 실무적인 기준

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에서 테스트가 실패하기 전에 구현으로 건너뛰지 말라고 강조합니다.

질문 세션, CONTEXT.md, 구현 계획 파일이 남아 있어야 다음 사람이 같은 기능을 같은 순서로 재현할 수 있습니다.

이 글이 다루지 않는 것

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

또 Adi Osmany Agent Skills 가이드를 다시 쓰는 글도 아닙니다. 오늘의 원문은 Alex Rusin 영상과 Matt Pocock의 grill-with-docs, obra/superpowers입니다. slash spec / build / test 같은 다른 비유를 이 글에 섞지 않습니다.

Playwright로 제출 링크를 여는 숙제도 아니고, promptfoo로 프롬프트를 시험 세트에 돌리는 글도 아닙니다. 비밀번호를 채팅에 넣지 말라는 주제와도 섞지 않습니다. 오늘의 범위는 API 기능 티켓 하나의 계획, TDD, 리뷰입니다.

영상 안의 1,000줄 넘는 계획과 13개 커밋을 모든 팀의 의무 숫자로 만들지도 않습니다. 그 숫자는 영상 데모에서 나온 기록일 뿐입니다. 팀의 계획 길이와 커밋 수는 실제 재현 결과로만 적는 것이 맞습니다.

유튜브 화면을 본문에 넣지도 않습니다. 주소만 둡니다. 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를 적용합니다. 테스트가 실패하는 장면을 먼저 남기고, 통과 코드만 넣은 뒤 리팩터하면 됩니다.
• 구현이 멈추면 사람이 파일을 직접 열어 구조를 확인합니다. 슬러그 로직의 위치, 이름, 테스트 배치가 팀 규칙에 맞는지 보는 단계입니다.
• 맥락을 비우거나 새 세션을 연 뒤 코드 리뷰 스킬을 돌리면 됩니다. 가능하면 구현에 쓴 모델과 다른 모델로 검토하는 편이 좋습니다.
• 에이전트에게 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 플러그인

여러분의 팀에서는 기능 티켓 하나를 닫을 때 어떤 단계에서 가장 자주 막히는지 궁금합니다.