1.6태스크 분해

"전자상거래 사이트를 만들어줘"를 한 번에 맡기면, 결과물 어딘가의 오류가 전체를 다시 시작하게 만듭니다. 태스크 분해(task decomposition)의 목적은 실패의 단위와 검증의 단위를 줄이는 것입니다.

좋은 하위 작업의 조건은 세 가지입니다.

1. 독립적으로 검증 가능 — 하위 작업마다 "됐는지 안 됐는지"를 판정할 테스트나 기준이 있어야 합니다. 검증할 수 없는 단위는 분해가 덜 된 것입니다.
2. 컨텍스트에 담기는 크기 — 하위 작업 하나를 수행하는 데 필요한 정보가 컨텍스트 윈도우에 여유 있게 들어가야 합니다.
3. 명확한 완료 정의 — "로그인 개선"(모호)이 아니라 "로그인 실패 시 구체적 오류 메시지를 표시하고 테스트 통과"(명확).

나쁜 분해: "백엔드 만들기" → "프런트엔드 만들기" → "연결하기"
  (각 단위가 너무 크고, '연결하기'는 완료 정의가 없다)

좋은 분해:
1. 상품 목록 API — GET /products, 페이지네이션 포함, 통합 테스트 통과
2. 상품 목록 UI — API 모킹 기준 렌더링 테스트 통과
3. 장바구니 추가 API — POST /cart, 재고 검증 포함, 테스트 통과
...

분해 폭도 중요합니다. 지나치게 잘게 나누면 하위 작업 간 맥락 전달 비용(1.4의 핸드오프 비용)이 작업 자체보다 커집니다. 경험적 기준은 "한 세션에서 완결되고, 그 세션의 산출물을 기계적으로 검증할 수 있는 최대 크기"입니다. 시험에서는 분해 품질을 비교하는 문제에서 '검증 가능성'이 판별 기준으로 가장 자주 쓰입니다.

하위 작업 목록이 나오면 다음 질문은 순서입니다. **의존 관계(dependency)**를 명시하면 무엇을 병렬로 돌릴 수 있고 무엇이 차례를 기다려야 하는지가 결정됩니다.

의존 관계는 방향 그래프(DAG)로 정리합니다. 스키마 정의 → API 구현 → API 문서화처럼 산출물이 다음 작업의 입력이 되는 관계가 간선입니다. 그래프를 그리고 나면:

• 의존이 없는 노드들 — 병렬 실행 후보 (1.3의 병렬 서브에이전트)
• 긴 의존 사슬 — 전체 소요 시간을 결정하는 임계 경로(critical path)
• 팬인 노드(여러 작업의 결과가 모이는 지점) — 통합 검증 게이트를 둘 위치

const tasks = [
  { id: "schema",   deps: [] },
  { id: "products", deps: ["schema"] },
  { id: "cart",     deps: ["schema"] },
  { id: "ui-products", deps: ["products"] },
  { id: "checkout", deps: ["cart", "products"] },  // 팬인 → 통합 테스트 게이트
];
// schema 완료 후 products와 cart는 병렬 실행 가능

숨은 의존을 놓치는 것이 실무의 주된 사고 원인입니다. 대표적인 숨은 의존은 공유 파일(두 작업이 같은 설정 파일을 수정), 공유 인터페이스(한쪽이 시그니처를 바꾸면 다른 쪽이 깨짐), 환경 상태(한 작업이 DB 스키마를 바꾸면 다른 작업의 테스트가 흔들림)입니다. 병렬 실행 전에 "두 작업이 같은 파일을 건드리는가"를 기계적으로 점검하는 것만으로 충돌 대부분을 예방할 수 있습니다.

분해 자체도 인지 작업이므로 모델에 위임할 수 있습니다. 1.2의 오케스트레이터-워커 패턴에서 오케스트레이터가 하는 일이 바로 동적 분해입니다. 이때 분해의 품질을 끌어올리는 프롬프트 설계 요소가 있습니다.

출력 스키마를 고정합니다. 하위 작업의 필수 필드(목표, 완료 기준, 의존, 예상 산출물)를 JSON 스키마로 강제하면, "검증 기준 없는 하위 작업" 같은 저품질 분해가 구조적으로 걸러집니다.

plan_schema = {
    "type": "object",
    "properties": {
        "subtasks": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "id": {"type": "string"},
                    "goal": {"type": "string"},
                    "done_criteria": {"type": "string"},  # 필수: 검증 기준
                    "deps": {"type": "array", "items": {"type": "string"}},
                },
                "required": ["id", "goal", "done_criteria", "deps"],
            },
        }
    },
}

계획과 실행을 분리합니다. 분해(계획) 턴과 실행 턴을 나누면, 계획을 사람이 검토하거나 게이트로 검증한 뒤 실행에 들어갈 수 있습니다. Claude Code의 플랜 모드(plan mode)가 이 분리를 제품화한 예입니다.

재분해 루프를 허용합니다. 실행 중 하위 작업이 예상보다 크다는 것이 드러나면, 그 작업을 다시 분해하는 경로를 열어 둡니다. 단, 재분해 깊이에 상한을 두지 않으면 계획만 하다 끝날 수 있습니다.

시험 함정: "분해는 항상 실행 전에 완전히 끝나야 한다"는 오답입니다. 예측 불가능한 작업에서는 초기 분해를 느슨하게 하고 실행하며 정제하는 점진적 분해가 표준이며, 이것이 워크플로가 아닌 에이전트를 쓰는 이유이기도 합니다.