subagent-driven-development

subagent-driven-development 스킬 개요

subagent-driven-development 스킬은 구현 작업을 독립적인 과제로 나누고, 각 과제를 새 subagent에 맡긴 뒤, 다음 단계로 넘어가기 전에 결과를 검토할 수 있게 도와줍니다. 목표는 품질 관리를 놓치지 않으면서 더 빠르게 전달하는 것인 agent orchestration에 특히 잘 맞습니다.

계획안이 있거나, 백로그가 있거나, 서로 상태를 공유하지 않는 여러 이슈가 있을 때 subagent-driven-development skill을 사용하세요. 버그 수정, 기능 단위 분할, repo 정리, 조사 작업처럼 긴 컨텍스트 하나로 밀어붙이면 더 느리고 더 지저분해지는 작업에 구조적인 실행 흐름을 원하는 개발자에게 잘 맞습니다.

이 스킬이 가장 강한 경우

파일, 서브시스템, 의사결정 단위로 작업을 분리할 수 있을 때 가장 효과적입니다. 핵심 가치는 단순한 병렬 처리만이 아니라, 각 작업을 깨끗한 subagent로 시작해 context pollution을 줄이고, 그 결과를 확인한 뒤 계속 진행한다는 데 있습니다.

이런 경우에 특히 잘 맞습니다

3개 이상 서로 독립적인 이슈를 다뤄야 하거나, 로드맵에 명확한 단계가 있고 각 단계를 review gate와 함께 순서대로 실행할 수 있을 때 선택하세요. 즉흥적으로 프롬프트를 짜는 대신, 반복해서 쓸 수 있는 subagent-driven-development guide가 필요할 때 특히 유용합니다.

기대할 수 있는 것

기대해야 할 것은 마법 같은 autopilot이 아니라, 작업 분할과 검토 프로세스입니다. 이미 작업의 경계가 분명할 때 이 스킬은 속도와 품질을 함께 끌어올립니다. 반대로 문제가 모호하거나, 서로 강하게 얽혀 있거나, 모든 단계에 걸쳐 하나의 공유된 추론 사슬이 필요한 경우에는 효용이 떨어집니다.

subagent-driven-development 스킬 사용 방법

스킬을 설치하고 연결하기

agent 환경에서 subagent-driven-development install 흐름을 사용한 뒤, 계획을 시작하기 전에 스킬을 불러오세요. 플랫폼이 repo에서 skill 설치를 지원한다면 NeoLabHQ/context-engineering-kit의 plugins/sadd/skills/subagent-driven-development 경로를 지정하면 됩니다.

대략적인 목표를 실제로 쓸 수 있는 프롬프트로 바꾸기

이 스킬은 다음 정보를 줄 때 가장 잘 작동합니다:

• 대상 repo 또는 workspace
• 원하는 정확한 결과
• 독립적인 task 또는 issue 목록
• 범위, 테스트, 피해야 할 file에 대한 제약

예를 들어 “auth 영역을 고쳐줘” 대신, “login flow, token refresh, error handling을 각각 별도 task로 감사하고, 항목별로 subagent 하나씩 할당한 뒤, 각 결과를 계속 진행하기 전에 검토하라”처럼 요청하세요.

먼저 이 파일들을 읽기

실행 패턴을 이해하려면 먼저 SKILL.md를 보세요. 그다음 인근 문서와 repo 규칙이 있다면 함께 확인하세요. 이 repository에는 support folders가 없으므로, 가장 중요한 기준은 skill 본문 자체입니다. 그래서 subagent-driven-development usage를 판단할 때 첫 번째 읽기가 특히 중요합니다.

실무 워크플로에 적용하기

좋은 흐름은 다음과 같습니다: task를 정의하고, 독립적인 작업을 묶고, task마다 새 subagent를 배정하고, code와 output을 검토한 뒤, 계속할지 수정할지 중단할지 결정합니다. subagent-driven-development for Agent Orchestration에서는 각 subagent의 범위를 좁게 유지하고, 끝까지 기다리지 말고 각 task 또는 batch마다 검토하는 것이 핵심입니다.

subagent-driven-development 스킬 FAQ

일반 프롬프트보다 더 나은가요?

작업이 분리 가능한 부분으로 나뉘고 quality gate가 필요하다면 그렇습니다. 한 번만 하는 변경에는 일반 프롬프트로도 충분할 수 있지만, subagent-driven-development skill은 여러 단계로 이루어진 구현 작업에 더 규율 있는 실행 루프를 제공합니다.

사람의 검토를 대체하나요?

아닙니다. task 사이에 실수가 이어지는 가능성을 줄여주지만, 의사결정 지점에서는 여전히 사람이 검토해야 합니다. 이 스킬은 검토를 없애는 것이 아니라, 검토 비용을 낮추도록 설계되었습니다.

초보자도 쓰기 쉬운가요?

task와 경계를 분명하게 설명할 수 있다면 초보자도 쓰기 쉽습니다. 반대로 두 이슈가 독립적인지, 아니면 강하게 얽혀 있는지를 아직 구분하기 어렵다면 제대로 쓰기 더 어렵습니다.

언제 사용하지 말아야 하나요?

작은 수정, 얽힘이 심한 refactor, 또는 하나의 공유된 조사 경로가 필요한 문제에는 쓰지 않는 편이 낫습니다. 이런 경우에는 subagent orchestration의 오버헤드가 이점을 앞지를 수 있습니다.

subagent-driven-development 스킬 개선 방법

subagent의 task 경계를 더 선명하게 주기

입력이 좋아야 결과도 좋아집니다. “codebase를 개선해라”보다는 “lint 수정과 test failure를 분리한 뒤, file 그룹별로 독립 검토하라”처럼 요청하세요. 경계가 분명할수록 스킬이 작업을 겹침 없이 배정하기 쉽습니다.

수락 기준과 중단 조건을 추가하기

완료의 기준을 명확히 적으세요: 변경된 file, 통과한 test, 위험 한도, API 변경 금지 조건 등입니다. 이렇게 해야 subagent-driven-development guide가 더 실행 가능해지고, subagent가 과하게 범위를 넓히는 일을 막을 수 있습니다.

흔한 실패 패턴을 살피기

가장 흔한 실패는 겹치는 task, 모호한 범위, 그리고 subtasks 간 dependency가 너무 많은 경우입니다. 한 task가 다른 task의 shared state를 필요로 한다면, subagent를 배정하기 전에 먼저 하나로 합치세요.

첫 번째 패스 이후에 반복 개선하기

첫 결과를 단순히 받아들이거나 거부하는 데서 끝내지 말고, task granularity를 다듬는 데 활용하세요. subagent가 너무 넓게 돌아왔다면 작업을 더 잘게 나누고, 너무 좁았다면 관련 검사를 묶어 한 번의 review cycle로 합치면 됩니다.