클로드 코드 Dynamic Workflow 기능 비교 총정리
📺 원본 영상: 클로드 코드 Dynamic Workflow 기능 비교 총정리!
🎙️ 채널: 코드팩토리
📅 정리 일자: 2026-06-03
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Claude Code에는 Deep Research(딥리서치)와 Ultra Code(울트라 코드)로 대표되는 Dynamic Workflow(다이나믹 워크플로우) 기능이 존재한다. 많은 개발자들이 이 두 기능의 존재는 알고 있지만, Claude Code 생태계 전반에서 어떤 포지션을 차지하는지, 그리고 Sub Agent(서브 에이전트), Batch(배치), Goal(골) 같은 다른 실행 방식들과 어떻게 다른지에 대해서는 명확히 이해하지 못하는 경우가 많다. 이 영상은 Claude Code의 다양한 실행 방식들을 체계적으로 비교하고, 각각의 적절한 사용 시나리오를 안내한다.
Dynamic Workflow란 무엇인가: 정적 하네스의 한계를 넘어
대부분의 개발자가 Claude Code를 처음 사용할 때는 정적인 하네스(harness) 방식으로 접근한다. 하네스란 에이전트가 어떤 작업을 어떤 순서로 수행해야 하는지를 미리 정의해놓은 설정이다. 이 방식은 명확하고 예측 가능하다는 장점이 있지만, 근본적인 한계를 품고 있다. 프로젝트의 요구사항이 바뀌거나 작업의 복잡도가 달라질 때마다 하네스를 직접 수정해야 하기 때문에, 정작 본래 프로젝트에 집중하는 시간보다 하네스를 관리하는 데 더 많은 시간을 소비하는 역설적인 상황이 발생하기도 한다.
Dynamic Workflow는 이 문제를 근본적으로 해결한다. 사용자가 하나의 단순한 프롬프트를 입력하면, 메인 에이전트(main agent)가 먼저 그 목적을 파악하고 작업을 어떻게 수행해야 할지 리서치와 계획을 수립한다. 핵심은 이 계획 수립 단계에서 워크플로우가 동적으로 생성된다는 것이다. 메인 에이전트는 전체 작업을 여러 개의 페이즈(phase)로 분할하고, 각 페이즈마다 수행해야 할 작업, 기대 결과물, 그리고 그 페이즈에 최적화된 하네스를 스스로 정의한다. 이처럼 워크플로우가 요청 내용에 따라 매번 새롭게 생성되기 때문에 “Dynamic Workflow”라는 이름이 붙었으며, 사용자는 하네스를 직접 정의할 필요 없이 단일 프롬프트만으로 이 모든 과정을 자동화할 수 있다.
Deep Research: 다층 병렬 탐색으로 완성하는 지식 수집
Deep Research는 리서치 목적에 특화된 Dynamic Workflow다. 단순히 여러 정보를 긁어모으는 것이 아니라, 수집-검증-추가조사-리포트 생성이라는 루프를 자동으로 반복하여 완성도 높은 결과물을 만들어낸다.
동작 방식을 구체적으로 살펴보면, Deep Research는 크게 스코프(scope) 정의, 검색(search), 검증(verification), 리포트 생성의 단계를 거친다. 스코프 정의 단계에서 무엇을 조사할지 범위를 설정한 이후, 검색 페이즈에서는 목적 달성에 필요한 정보를 최대한 빠르게 수집하기 위해 다수의 에이전트를 병렬로 실행한다. 강연자에 따르면 이 단계에서만 약 5개의 에이전트가 동시에 실행되는 것을 실제 화면에서 확인할 수 있었다고 한다. 이렇게 어떤 자료가 필요한지 파악한 이후에는, 실제 자료를 수집하는 단계에서도 병렬 에이전트들이 동시에 정보를 가져온다.
03:00 - Deep Research 워크플로우 실제 화면: 스코프 정의 후 검색 페이즈에서 5개 에이전트가 병렬 실행되며 각 에이전트의 결과(outcome)까지 확인 가능한 상태
수집된 방대한 데이터는 검증(verification) 단계를 거치는데, 데이터의 양이 방대하므로 이전 단계보다 더 많은 에이전트가 필요해진다. 강연자는 각 소스별로 에이전트를 3개씩 분할하여 독립적으로 검증하는 방식이 화면에서 확인되었다고 전한다.
04:06 - Deep Research 검증(Verification) 단계: 소스별 에이전트를 3개씩 분할하여 독립 검증 후 최종 리포트를 단일 에이전트가 생성하는 구조
흥미로운 점은 최종 리포트를 생성하는 마지막 단계에서는 단 하나의 에이전트만이 사용된다는 것이다. 이는 기술적인 이유로, 방대하게 검증된 정보를 하나의 일관된 리포트로 통합하려면 단일 컨텍스트(context)가 유지되어야 하기 때문이다. 병렬로 흩어진 정보를 수집·검증하는 과정과 그 결과를 하나로 종합하는 과정이 설계상 명확히 구분되어 있는 것이다.
이 전체 흐름은 조사 → 검증 → 추가 조사 필요 여부 확인 → (필요하면) 재조사 루프의 형태로 동작한다. 일반 채팅은 이 흐름에서 첫 번째 단계에서 그냥 결과를 반환하고 끝나지만, Deep Research는 완료 조건이 충족될 때까지 이 루프를 지속한다.
Ultra Code: 코드 생성을 위한 Dynamic Workflow
Ultra Code는 Deep Research와 동일한 Dynamic Workflow 메커니즘을 코드 생성 및 수정 작업에 적용한 것이다. 동작 원리의 큰 틀은 같다. 요청을 받으면 메인 에이전트가 작업을 페이즈별로 분할하고, 각 페이즈에서 병렬로 에이전트들이 작업을 수행한 뒤 검증과 수정 루프를 반복한다.
강연자는 예시로 Convex와 PostgreSQL 두 데이터베이스를 모두 호환하는 Clean Architecture(클린 아키텍처) 기반의 Port and Adapter(포트 앤 어댑터) 패턴 구현을 요청하는 시나리오를 제시했다. 현실에서는 보기 드문 요구사항이지만, 이 복잡한 작업조차 Ultra Code는 자동으로 파운데이션(foundation) 구축, 빌드(build), 통합(integrate), 리뷰(review)의 네 페이즈로 분할하여 처리한다.
07:09 - Ultra Code 워크플로우: Foundation(4개 에이전트) → Build(14개) → Integrate(2개) → Review(3개) 순으로 페이즈별 에이전트 배정 구조가 표시된 상태
Ultra Code와 Deep Research의 가장 큰 차이는 에이전트 수와 실행 특성에 있다. Deep Research는 수십 개의 에이전트가 넓게 병렬 실행되지만, Ultra Code는 코드 작업의 특성상 컨텍스트가 매우 중요하기 때문에 상대적으로 적은 수의 에이전트가 더 오래 실행된다. 결과적으로 에이전트 수는 적더라도 각 에이전트의 실행 시간이 길어지므로, 토큰 소비량은 Deep Research에 비해 결코 적지 않다. 강연자는 이 점을 명확히 강조한다.
Ultra Code 사용에는 한 가지 중요한 제약이 있다. 에포트(effort) 설정을 반드시 “x-high”로 고정해야 하며, 다른 에포트 레벨은 선택할 수 없다. 이는 복잡한 코드 작업의 계획 수립 단계에서 최고 수준의 추론 능력이 필요하기 때문으로, 계획의 품질이 전체 결과물의 질을 결정하는 핵심 요소이기 때문이다. 각 페이즈 내의 에이전트들은 자신에게 배정된 작업에만 집중하지만, 그 페이즈들의 설계 자체는 x-high 수준의 추론이 뒷받침해야 한다.
Sub Agent와 Batch: 병렬 실행의 기초
Dynamic Workflow를 제대로 이해하려면 그 이전에 등장한 Sub Agent와 Batch의 개념을 먼저 파악할 필요가 있다. Sub Agent는 Claude Code에서 가장 먼저 등장한 혁신적인 기능으로, 어떤 의미에서는 하네싱(harnessing)의 시초라고 볼 수 있다. 동작 방식은 직관적이다. 사용자가 메인 에이전트에게 작업을 요청하면, 먼저 Claude Haiku 같은 경량 모델을 활용한 검색 전용 에이전트들이 실행되어 필요한 정보를 빠르게 취합한다. 이는 무거운 모델이 대량의 소스를 직접 처리하면서 컨텍스트 윈도우를 소진하는 것을 방지하기 위한 설계다. 이후 각 작업에 특화된 프롬프트로 하네싱된 서브 에이전트들이 병렬 또는 직렬로 실행되고, 모든 결과물은 메인 에이전트로 다시 취합된다. Sub Agent의 핵심은 이 에이전트들 하나하나를 사용자가 직접 정의할 수 있다는 것이며, 그 정의에 따라 성능이 크게 달라진다.
Batch는 Sub Agent를 극대화하여 활용하는 방식이다. 이미 정의된 유사한 작업들, 그리고 서로 독립적으로 실행 가능한 작업들을 묶어 한 번에 병렬로 처리하는 것이 핵심이다. 강연자는 이를 “공장”에 비유했는데, 버그 1번부터 100번까지가 있을 때 각각의 버그 수정 작업은 서로 독립적이므로 100개를 동시에 각각의 에이전트에 배정하여 처리하는 방식이 대표적인 예다. 다만 Batch는 처리 속도에 최적화된 만큼 목표 달성의 정확성 측면에서는 한계가 있다. 지나치게 많은 병렬 실행을 수행할 경우, 각 작업의 완성도를 세밀하게 검증하기 어려워질 수 있다는 점을 감안해야 한다.
Goal: 목표 달성까지 멈추지 않는 집착적 실행
Goal은 Claude Code에서 목표 지향성이 가장 높은 실행 방식이다. 일반 채팅이나 다른 실행 방식들이 일정 수의 턴(turn) 이후 결과물을 반환하는 것과 달리, Goal은 정해진 목표가 완전히 달성될 때까지 실행이 종료되지 않는다. 경우에 따라 몇 시간, 심지어 며칠을 실행하기도 한다. 강연자는 이 특성을 “빅토리 오어 발할라(Victory or Valhalla)“라는 표현으로 묘사했는데, 성공하거나 아니면 그냥 끝까지 하는 것이 Goal의 본질이라는 의미다.
Goal이 일반 채팅과 다른 또 다른 중요한 특성은 응답의 정직성에 있다. 일반 채팅에서는 작업이 완료되지 않았음에도 “완료했습니다”라고 답하다가, 사용자가 지적한 이후에야 “다시 하겠습니다”라는 할루시네이션(hallucination)이 종종 발생한다. Goal 모드에서는 이러한 문제가 현저히 줄어들며, 에이전트가 목표 달성에 실패하더라도 스스로 문제를 해결하기 위해 지속적으로 시도한다. Anthropic의 공식 문서에도 이 점이 명시되어 있다고 강연자는 전하며, 정말 해결이 불가능하다고 판단될 때만 사용자에게 도움을 요청하도록 설계되어 있다고 설명한다. 일반 채팅이 마치 강아지처럼 “이거 안 돼요”라며 징징대다 포기한다면, Goal은 불가능해질 때까지 절대로 포기하지 않는 집착적인 실행자에 가깝다.
이러한 특성 때문에 Goal을 사용할 때는 프롬프트 작성이 매우 중요하다. 목표 설명, 작업 원칙, 수행 단계, 완료 조건이 정확하게 정의되어야 한다. 프롬프트가 잘못 설계되면 Goal은 방향 없는 뻘짓을 며칠씩 반복하는 상황이 발생할 수 있다. 그런데 이 정교한 Goal 프롬프트를 사람이 직접 손으로 작성하는 것은 현실적으로 불가능하다. 강연자가 강력히 권장하는 방법은 **메타 프롬프팅(Meta-prompting)**이다. Claude에게 “나는 /goal 기능을 사용해서 [목표]를 달성할 건데, goal 프롬프트를 만들어줘”라고 요청하면, Claude가 직접 최적화된 goal 프롬프트를 생성해준다. Goal이 무엇인지를 Claude 자신이 이미 잘 알고 있기 때문에, 이 방식이 사람이 직접 작성하는 것보다 훨씬 정교하고 효과적인 프롬프트가 만들어진다.
13:14 - 메타 프롬프팅 결과 화면: Next.js에서 Svelte로 마이그레이션하는 Goal 프롬프트를 Claude가 자동 생성한 결과 (작업 원칙, 수행 단계, 완료 기준이 상세 정의된 상태)
기능 진화 스펙트럼과 실전 선택 기준
강연자는 Claude Code의 다양한 실행 방식을 하나의 스펙트럼으로 설명한다. 왼쪽에서 오른쪽으로 갈수록 토큰 소비량이 증가하고, 동시에 목표 추종(goal-pursuit) 능력도 향상된다.
09:59 - Claude Code 실행 방식 진화 스펙트럼: 일반 채팅 → Skills → Sub Agent → Batch → Deep Research/Ultra Code → Goal 순으로 토큰 소비 및 목표 지향성이 증가하는 구조
스펙트럼의 맨 왼쪽에 위치한 일반 채팅은 가장 단순하며, Anthropic이 설정한 턴 제한 내에서 결과물을 반환하도록 설계되어 있다. 복잡한 검증이나 반복 없이 빠른 응답이 필요한 심플한 작업에 적합하다. Skills(스킬)는 자주 반복하는 작업 흐름을 미리 정의해두어 목적성을 높인 방식이며, Sub Agent는 특정 작업에 특화된 에이전트를 튜닝하여 생성하는 방식이다. Batch는 Sub Agent를 여러 개 동시에 실행하여 독립적인 다량의 작업을 한 번에 병렬 처리하는 데 특화되어 있고, 스펙트럼 중상위의 Deep Research와 Ultra Code는 Dynamic Workflow로 다층 병렬 에이전트와 자동 생성 하네스를 통해 복잡한 작업을 처리한다. 맨 오른쪽에 위치한 Goal은 목표 지향성이 가장 높으며 달성될 때까지 실행을 멈추지 않는다.
실용적인 선택 기준에 대해 강연자는 다음과 같이 조언한다. Ultra Code는 대부분의 복잡한 코드 작업에 기본값으로 사용하는 것이 좋다. 리팩터링(refactoring), 프레임워크 교체 같은 작업처럼 빠른 전환이 중요하고 일부 오류를 수용하면서 계속 나아가는 방식이 유효한 경우에 Ultra Code가 적합하다. 반면 Goal은 완벽한 성공 조건을 정의할 수 있는 작업, 검증이 매우 복잡한 작업에 최적이다. 예를 들어 Redis를 활용한 캐싱 레이어를 새롭게 도입하는 경우처럼, 어떤 것을 캐싱해야 하는지, 검증 방법은 무엇인지, 배포 후 동작 방식은 어떠해야 하는지, 알고리즘 선택 기준은 무엇인지 등 다양한 성공 조건을 명확히 정의할 수 있고 그 조건만 충족하면 반드시 성공한다는 확신이 있는 작업에서 Goal의 집착적 실행 능력이 가장 큰 가치를 발휘한다.
토큰 소비 측면에서도 한 가지 참고할 사항이 있다. Dynamic Workflow(Deep Research, Ultra Code)는 단위 시간당 토큰 소비가 많지만, Goal은 실행 시간 자체가 훨씬 더 길어질 수 있기 때문에 총 토큰 소비량으로 따지면 어느 쪽이 더 많은지는 작업에 따라 다르다고 강연자는 언급한다.
마무리
Dynamic Workflow와 Goal의 등장은 단순히 새로운 기능이 추가된 것이 아니라, AI 에이전트를 활용하는 패러다임의 변화를 상징한다. 정적인 하네스를 직접 관리하던 방식에서, 하나의 프롬프트로 복잡한 멀티 에이전트 워크플로우가 동적으로 생성되는 방식으로의 전환이다. 강연자가 반복해서 강조하듯, 계획 수립의 품질이 최종 결과물의 질을 결정하기 때문에 각 기능의 특성과 적절한 사용 시나리오를 이해하는 것이 더욱 중요해졌다. 빠른 전환이 목적이라면 Ultra Code를, 완벽한 결과물이 목적이라면 Goal을, 그리고 Goal을 사용할 때는 반드시 메타 프롬프팅으로 프롬프트를 준비하는 것. 이 세 가지가 이 영상이 전달하는 핵심 실천 지침이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | 클로드 코드 Dynamic Workflow 기능 비교 총정리! |
| 채널 | 코드팩토리 |
| 리포트 작성 | 2026-06-03 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다.
정확한 내용은 원본 영상을 참조해 주세요.