Claude Code 동적 워크플로우(Dynamic Workflows)의 재구성: 실용적인 Ultracode 스타일의 오케스트레이션(Orchestration) 템플릿

Claude Code 동적 워크플로우(Dynamic Workflows)와 ultracode는 AI 코딩 작업의 형태를 변화시키고 있기 때문에 주목을 받고 있습니다.

하나의 에이전트(Agent)에게 긴 대화 속에서 모든 것을 수행하도록 요청하는 대신, 워크플로우 패턴은 다음과 같은 형태를 띱니다:

1. 작업이 복잡함을 감지합니다;
2. 오케스트레이션(Orchestration) 계획을 작성합니다;
3. 작업을 범위가 지정된 패킷(Packets)으로 분할합니다;
4. 하위 에이전트(Subagents) 또는 역할을 할당합니다;
5. 검토 및 검증 게이트(Verification gates)를 요구합니다;
6. 발생한 일에 대한 추적 증거(Trace evidence)를 유지합니다.

중요한 것은 브랜드 이름이 아닙니다. 중요한 것은 오케스트레이션(Orchestration) 패턴입니다.

그래서 우리는 유용한 부분을 Crazyrouter와 같은 OpenAI 호환 모델 게이트웨이(Model gateway)에서 작동하는 재현 가능한 템플릿으로 로컬에 재구축했습니다.

동적 워크플로우(Dynamic workflows)가 다른 이유

일반적인 AI 코딩 세션은 선형적입니다:

인간의 프롬프트(Human prompt) -> 에이전트(Agent)가 파일 수정 -> 인간이 결과 확인

동적 워크플로우(Dynamic workflow)는 다음과 것에 더 가깝습니다:

인간의 목표(Human goal)
  -> 플래너 패킷(Planner packet)
  -> 구현자 패킷(Implementer packet)
...

모든 것이 뒤섞여 있으면 복잡한 코딩 작업이 실패하기 때문에 이러한 구조가 중요합니다:

• 계획(Planning)이 구현(Implementation)과 혼동됩니다;
• 구현(Implementation)이 그것을 만든 것과 동일한 가정에 의해 검토됩니다;
• 테스트(Tests)가 언급은 되지만 실제로 실행되지는 않습니다;
• 개발자는 긴 에이전트(Agent) 세션 후에 무슨 일이 일어났는지 알 수 없습니다;
• 라우팅 정책(Routing policy) 없이 토큰(Token) 사용량이 폭발합니다.

로컬 재현

우리는 다음과 같은 작은 도구를 만들었습니다:

tools/agent_workflows/workflow_orchestrator.py

이 도구는 역할 패킷(Role packets), 검증 게이트(Verification gates), 그리고 추적 로깅(Trace logging)을 포함하는 동적 워크플로우(Dynamic-workflow) 폴더를 생성합니다.

예시:

python tools/agent_workflows/workflow_orchestrator.py \
  --title "Claude Code Dynamic Workflows ultracode reproduction" \
  --task "Claude Code 동적 워크플로우(Dynamic Workflows) / ultracode의 유용한 부분 재현: 복잡한 코딩 요청을 범위가 지정된 패킷(scoped packets)으로 분할하고, 모델 경로(model routes)를 할당하며, 적대적 검토(adversarial review)를 요구하고, 증거를 통해 검증합니다."
...

생성된 출력(Generated output):

ultracode_reproduction/
├── README.md
├── workflow.json
...

이는 Claude Code의 내부 구조를 복제하려는 것이 아닙니다. 대신 워크플로우의 기본 요소(primitive)를 이식 가능하고(portable), 검사 가능하며(inspectable), 게시 가능한(publishable) 방식으로 재현합니다.

4-패킷 워크플로우 (The four-packet workflow)

핵심은 역할 분리(role separation)입니다. 구현을 담당하는 모델이 검토를 담당하는 유일한 모델이 되어서는 안 됩니다.

Crazyrouter 모델 경로 설정 (Crazyrouter model routing setup)

모델 호출이 필요한 경우, 하나의 OpenAI 호환 베이스 URL(base URL)을 사용하고 모델 ID(model ID)만 전환하십시오.

from openai import OpenAI

client = OpenAI(
...

API 엔드포인트(endpoints)를 깔끔하게 유지하십시오. base_url에 UTM 파라미터를 추가하지 마십시오.

올바른 예 (Correct):

잘못된 예 (Wrong):

ultracode 스타일의 워크플로우가 비용이 많이 들 수 있는 이유

동적 워크플로우(Dynamic workflows)는 팬아웃(fan out)될 수 있습니다. 단일 요청이 많은 하위 작업(sub-tasks)을 생성할 수 있으며, 각 하위 작업은 컨텍스트(context)를 요청하고, 코드를 작성하고, 코드를 검토하고, 검증을 실행할 수 있습니다.

이는 강력하지만, 예산 제어(budget control)가 필요합니다.

좋은 워크플로우는 다음을 로깅(log)해야 합니다:

또한 다음을 생성했습니다:

tools/agent_workflows/agent_trace_logger.py

트레이스 요약(trace summary) 예시:

모델별 (By model):
- claude-opus-4-7: calls=1, avg_latency=7.46s, total_tokens=1800
- claude-opus-4-8: calls=1, avg_latency=4.59s, total_tokens=1500

실용적인 라우팅 정책 (Routing policy)

AI 코딩 에이전트 (AI coding agents)를 사용하는 팀이라면, 단순하게 시작하십시오:

실수는 모든 단계에 가장 비싼 모델을 사용하는 것입니다. 또 다른 실수는 실패 비용이 큰 단계에 가장 저렴한 모델을 사용하는 것입니다.

게이트웨이 (Gateway)를 사용하면 단계별로 라우팅할 수 있습니다.

우리가 구현한 것

이번 재현(reproduction)을 위해 다음을 생성했습니다:

• tools/agent_workflows/workflow_orchestrator.py
• tools/agent_workflows/agent_packetizer.py
• tools/agent_workflows/agent_trace_logger.py
• generated/dynamic_workflows_20260603/ultracode_reproduction/
• growth_ops/codex_claude_search_report_20260603.md
• growth_ops/twitter_codex_claude_cases.md

이를 통해 유행하는 워크플로우 아이디어를 재사용 가능한 운영 인프라 (operating infrastructure)로 전환합니다.

FAQ

이것이 Claude Code의 동적 워크플로우 (Dynamic Workflows)와 동일한 것인가요?

아니요. 이것은 오케스트레이션 (orchestration), 패킷 (packets), 리뷰 (review), 검증 (verification), 그리고 트레이스 로깅 (trace logging)이라는 유용한 워크플로우 패턴을 로컬에서 재현한 것입니다.

왜 단일 에이전트 (one agent)를 사용하지 않나요?

작은 작업에는 단일 에이전트도 괜찮습니다. 하지만 복잡한 작업의 경우, 역할 분리 (role separation)를 통해 더 많은 실수를 잡아내고 더 나은 근거를 생성할 수 있습니다.

왜 여기서 Crazyrouter를 사용하나요?

Crazyrouter는 OpenAI 호환 API 게이트웨이를 제공하므로, 클라이언트 코드를 다시 작성하지 않고도 각 워크플로우 단계가 서로 다른 모델로 라우팅될 수 있습니다.

모든 작업에 동적 워크플로우를 사용해야 하나요?

아니요. 여러 파일에 걸친 변경 (multi-file changes), 마이그레이션 (migrations), 보안 민감 편집 (security-sensitive edits), 대규모 리팩토링 (large refactors), 또는 리뷰 근거가 중요한 작업에 사용하십시오.

다음 개선 사항은 무엇인가요?

다음 단계는 오케스트레이터 (orchestrator)를 실제 모델 호출에 연결하고, 토큰/지연 시간 (token/latency) 데이터를 자동으로 수집하며, 라우팅 정책을 비교하는 것입니다.

최종 결론

동적 워크플로우는 마법이 아닙니다. 그것은 구조화된 오케스트레이션 (structured orchestration)입니다.

승리하는 패턴은 다음과 같습니다:

plan -> implement -> adversarial review -> verify -> log evidence
(계획 -> 구현 -> 적대적 검토 (adversarial review) -> 검증 -> 증거 기록)

이 패턴을 모델 라우팅 (model routing)과 결합하면, 단일한 긴 AI 코딩 채팅보다 훨씬 더 유용한 것, 즉 측정 가능한 엔지니어링 워크플로우 (engineering workflow)를 얻을 수 있습니다.

여기서 API 게이트웨이를 사용해 보세요: Crazyrouter