🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude Code의 Dynamic Workflows는 단순한 병렬 sub-agent가 아니라, 계획을 JavaScript harness에 넣어 실행·검증·합성을 자동화하는 구조이며, 독립 작업 수와 품질 게이트가 명확할 때만 비용 대비 가치가 커진다.

📌 핵심 요점

1. 동적 워크플로우의 핵심은 병렬 실행 자체가 아니라, Claude가 매 턴 계획을 들고 지시하는 방식에서 벗어나 orchestration script가 계획과 실행을 맡는다는 점이다.
2. workflow는 수십 개 작업 fan-out, adversarial verification, agent 재시작·일시정지·재개 같은 제어를 제공하지만, 실제 중심은 개별 agent가 아니라 전체 실행을 조율하는 harness다.
3. 적합한 패턴은 독립 subtasks를 병렬화하는 fan out and synthesize, 정확성을 높이는 adversarial verification, 창의적 대안을 비교하는 tournament, 대량 후보를 거르는 generate and filter, 품질 기준 통과까지 반복하는 loop until done으로 나뉜다.
4. 비용 판단에서는 agent 수, 선택된 model, orchestration overhead, verification tax를 함께 봐야 하며, 영상에서는 대략 5개 미만의 독립 작업은 손해 가능성이 높고 20개 이상에서 병렬화 가치가 강해진다고 설명한다.
5. 실행 전에는 원하는 산출물이 명확한지, 5개 이상의 독립 하위 작업이 있는지, 정확성이 중요한지, 측정 가능한 품질 게이트가 있는지를 확인해야 하며, 그렇지 않으면 순차 실행보다 비싸고 품질도 낮아질 수 있다.

🧩 배경과 문제 정의

• 이 영상은 Claude Code의 dynamic workflow를 단순히 여러 sub-agent를 병렬로 돌리는 기능으로 이해하는 흔한 오해를 바로잡는 데서 출발한다.
• 핵심 쟁점은 “agent가 몇 개 실행되느냐”보다 “작업 계획을 누가 보유하고, 무엇이 실행을 주도하느냐”에 있다.
• 기존 sub-agent 방식은 Claude가 대화 턴마다 계획을 들고 위임·회수·판단을 반복하는 구조인 반면, workflow는 Claude Code가 만든 orchestration script가 실행 계획을 담고 런타임처럼 작동하는 구조로 설명된다.
• 따라서 dynamic workflow는 단순 자동화가 아니라 대규모 병렬 처리, 검증, 합성, 품질 게이트를 설계하는 방식에 가깝다.
• 다만 모든 작업에 적합한 것은 아니다. 독립적인 하위 작업이 충분하지 않거나, 중간 결과를 보며 방향을 바꿔야 하거나, 비용 대비 효과를 계산하지 않으면 순차 실행보다 비싸고 품질도 낮아질 수 있다.
• 영상의 문제 정의는 dynamic workflow를 “멋진 데모 기능”이 아니라, 언제 써야 하고 언제 피해야 하는지 판단해야 하는 실행 아키텍처로 이해해야 한다는 데 있다.

🕒 시간순 섹션별 상세정리

1. 동적 워크플로우의 핵심 오해와 아키텍처 전환

• 동적 워크플로우는 sub-agent를 병렬로 실행하는 것 자체가 핵심이 아니라, Claude Code가 즉석에서 JavaScript orchestration script를 만들고 그 script가 실행의 중심이 되는 구조로 드러난다. [01:16]
• 기존 sub-agent 접근에서는 Claude가 매 턴마다 계획을 들고, 작업을 위임하고, 결과를 모은 뒤 다음 결정을 내리는 방식으로 움직인다. [01:42]
• workflow 방식에서는 계획이 Claude의 대화 턴 안에 남아 있는 것이 아니라 script 안으로 이동하며, harness가 그 계획을 따라 자율적으로 실행한다는 점이 구조적 차이로 드러난다. [01:52]

2. 대규모 병렬성, 검증, 제어면

• workflow는 한 번의 run에서 수십 개 작업으로 fan-out할 수 있고, 동시에 최대 16개 agent와 총 1,000개 agent까지 확장될 수 있는 구조로 드러난다. [01:57]
• 이 확장성 때문에 큰 작업에서는 단순히 조금 빨라지는 수준이 아니라, 처리량 자체가 한 단계 달라지는 효과가 중요하다. [02:12]
• adversarial verification 패턴에서는 한 agent가 초안을 만들고, 다른 agent가 오류·누락·가정을 공격적으로 검토하며, 세 번째 agent가 충돌을 해결해 최종 결과를 만드는 흐름이 드러난다. [02:27]
• 이 구조는 단순 병렬 처리뿐 아니라 검증과 품질 통제까지 workflow 안에 포함할 수 있다는 점을 보여준다. [02:42]

3. 독립 작업과 정확성 중심 패턴

• classify-and-act는 의미 있는 orchestration runtime을 거의 사용하지 않기 때문에, 본격적인 workflow pattern이라기보다는 단일 agent routing에 가까운 pattern zero로 드러난다. [03:41]
• fan out and synthesize는 독립적인 하위 작업을 여러 agent에 나누고, orchestrator가 그 결과를 하나의 보고서로 합치는 방식이다. [03:53]
• 예시로는 50개 회사 조사, 100개 API endpoint audit, repository 전체 review처럼 서로 독립적으로 처리할 수 있는 대규모 작업이 나온다. [04:08]
• 이 패턴의 핵심은 하위 작업들이 서로 강하게 의존하지 않아야 하며, 병렬 실행 후 합성 가능한 형태여야 한다는 점이다. [04:23]

4. 토큰 경제와 손익분기

• workflow 비용에서 중요한 질문은 “강력한가”가 아니라 “그 강력함이 가격을 정당화하는가”로 드러난다. [06:13]
• 비용은 단순히 agent 수만으로 결정되지 않고, agent count × model, orchestration overhead, verification tax가 함께 작용한다. [06:28]
• 모든 agent는 workflow 시작 시점의 active model을 사용하기 때문에, 50개 agent가 Opus에서 도는 경우와 Sonnet에서 도는 경우의 비용 차이는 작지 않다. [06:43]
• 따라서 workflow를 설계할 때는 병렬성과 품질 향상 가능성뿐 아니라, 어떤 모델로 몇 개의 agent를 실행할지까지 비용 구조 안에서 판단해야 한다. [06:58]

5. 피해야 할 사용 신호와 실행 전 점검

• workflow는 plan을 실행하는 도구이기 때문에, 중간 결과를 보면서 탐색하고 수정하고 방향을 바꿔야 하는 conversation형 task에는 맞지 않는다고 드러난다. [08:32]
• 즉, 요구사항이 계속 변하거나 다음 행동이 이전 응답을 본 뒤에야 결정되는 작업이라면 workflow보다 대화형 진행이 더 적합할 수 있다. [08:47]
• step 3이 step 2에 의존하고, step 2가 step 1에 의존하는 구조라면 fan-out이 불가능하다. [09:02]
• 이런 경우 workflow는 병렬 실행의 장점을 얻지 못하고, orchestration overhead만 얹힌 sequential execution으로 퇴화할 수 있다. [09:17]

6. 실행 전 의사결정 기준과 후속 학습 경로

• workflow를 실행하기 전에는 먼저 원하는 산출물을 구체적으로 지정할 수 있는지 확인해야 한다. [12:19]
• 또한 5개 이상의 독립 하위 작업이 있는지, 정확성과 속도 중 무엇이 더 중요한지, 측정 가능한 품질 게이트가 있는지를 점검해야 한다. [12:34]
• 이 네 가지 질문에 답하지 않은 상태에서 workflow를 시작하면 자동화 범위와 검증 기준이 흔들릴 수 있다. [12:39]
• 결론적으로 dynamic workflow는 무조건 쓰면 좋은 기능이 아니라, 독립 작업 수, 품질 기준, 비용 구조, 최종 산출물이 분명할 때 실질 가치가 커지는 실행 방식으로 압축된다. [12:44]

🧾 결론

• 이 영상의 핵심 메시지는 “workflow를 더 나은 sub-agent처럼 쓰면 안 된다”는 것이다. dynamic workflow는 agent를 많이 띄우는 기능이 아니라, 작업 분해·실행·검증·합성을 script 기반 runtime에 맡기는 방식이다.
• workflow가 유리한 상황은 독립적인 하위 작업이 충분히 많고, 최종 산출물과 평가 기준이 분명하며, 속도나 정확성의 개선이 추가 토큰 비용을 정당화할 때다.
• 반대로 중간 결과를 보며 방향을 바꿔야 하는 대화형 작업, 단계 간 의존성이 강한 작업, 산출물을 명확히 정의하지 못한 작업에는 workflow가 오히려 복잡성과 비용을 키울 수 있다.
• 따라서 실행 전 가장 중요한 역량은 workflow 명령을 아는 것이 아니라, 작업을 올바르게 설명하고 독립 작업·검증 기준·비용 구조를 판단하는 능력이다.

📈 투자·시사 포인트

• 토큰과 모델 비용을 리소스 투자로 본다면, workflow는 “자동화하면 무조건 이득”인 도구가 아니라 일정 규모 이상의 독립 작업에서 수익성이 생기는 고정비형 구조에 가깝다.
• 실행 전 /model 확인은 비용 통제의 핵심이다. 같은 workflow라도 active model에 따라 run 비용이 크게 달라질 수 있으므로, 모델 선택은 품질뿐 아니라 예산 판단의 일부가 된다.
• 정확성이 중요한 security audit, compliance check, architecture decision 같은 작업에서는 adversarial verification의 추가 비용이 downstream 오류 비용을 줄이는 투자로 작동할 수 있다.
• 대량 조사, API audit, repository review처럼 독립 subtasks가 많은 작업은 fan-out과 synthesis의 효율이 커질 수 있지만, 하위 작업 간 의존성이 있으면 병렬 가격으로 순차 성능을 사는 결과가 될 수 있다.
• 실무적으로는 workflow 도입 여부를 기능 기준이 아니라 “독립 작업 수, 산출물 명확성, 품질 게이트, 검증 비용” 기준으로 판단해야 하며, unattended run 전에는 orchestration script를 최소 한 번 검토하는 절차가 필요하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 영상에서 언급된 “동시에 최대 16개, 총 1,000개 agent” 확장 한도는 Claude Code의 당시 동작 기준으로 보이며, 현재 버전에서도 동일한지는 별도 확인이 필요하다.
• “/model 확인 하나가 2달러 run과 20달러 run의 차이를 만들 수 있다”는 비용 예시는 모델 가격, 호출량, 작업 구조에 따라 달라질 수 있으므로 현재 요금 체계와 실제 토큰 사용량 기준으로 재계산해야 한다.
• Claude Code workflow companion guide가 school community에서 무료로 제공된다는 설명은 영상 업로드 시점의 안내일 수 있어, 현재 접근 가능 여부는 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• workflow 실행 전 현재 활성 모델을 /model로 확인하고, 비용이 큰 모델에서 대량 agent가 실행되지 않도록 점검한다.
• 작업을 시작하기 전에 원하는 최종 산출물을 한 문장 이상으로 명확히 정의한다.
• 하위 작업이 5개 이상이며 서로 독립적인지 확인하고, 의존성이 강한 작업은 workflow 대신 순차 실행이나 일반 sub-agent 방식으로 처리한다.
• correctness가 중요한 작업에는 초안 작성 agent, 공격적 검토 agent, 충돌 해결 agent를 나누는 adversarial verification 패턴을 검토한다.

❓ 열린 질문

• 실제 팀 작업에서 “5개 미만은 손해, 5~20개는 break-even, 20개 초과는 유리”라는 기준은 어떤 작업군에서 가장 잘 맞는가?
• Claude Code workflow의 JavaScript harness를 리뷰할 때 반드시 확인해야 할 최소 체크리스트는 무엇인가?
• adversarial verification에서 검토 agent가 과도하게 보수적으로 판단하거나 불필요한 반박을 늘릴 때, 최종 합성 agent는 어떤 기준으로 충돌을 해결해야 하는가?