다이나믹 워크플로우

갱신 2026-08-09

한눈에 요약

• 사람이 작업 절차를 미리 짜 두는 대신, 요청을 받은 AI가 그 자리에서 절차를 만들어 실행하는 방식이다.
• 사용자는 목적 하나만 던진다. AI가 조사·계획·실행·검증 순서를 알아서 구성한 뒤 결과를 내놓는다.
• Claude Code의 딥리서치와 울트라 코드가 대표적인 두 기능이다.
• 요청마다 절차가 새로 짜이는 만큼 다룰 수 있는 폭이 넓다. 대신 시간과 비용이 크게 든다.
• 하네스 엔지니어링 관점에서는 "정적 하네스" 대신 하네스가 그때그때 생성되는 것으로 본다.

정적 하네스 대신 동적 하네스

하네스를 사람이 미리 짜 두는 것에는 한계가 있다. 작업 종류마다 필요한 절차가 다르기 때문이다. 다이나믹 워크플로우는 그 지점을 건드린다.

**다이나믹 워크플로우(Dynamic Workflow)**는 Claude Code에 비교적 최근 추가된 기능이다. 사용자가 하나의 요청(싱글 프롬프트)을 던지면 메인 에이전트가 그 목적을 듣고 작업 방식을 리서치·계획한 뒤 워크플로우(= 하네스)를 동적으로 생성한다 23.

핵심은 요청마다 그에 맞는 하네스가 그 자리에서 만들어진다는 점이다 23. 루프 엔지니어링에서도 "어차피 울트라 코드를 쓰면 다이나믹하게 하네스가 생겨난다"고 언급된다 25.

대표 두 기능 — 딥리서치와 울트라 코드

• 딥리서치 — 딥 리서치(또는 deep research) 명령으로 실행한다 24. 조사 → 검증 → 추가 조사 여부 확인의 무한루프를 돌다가 끝나면 최종 리포트를 낸다 23.
• 울트라 코드 — 큰 작업을 던지면 병렬로 작업을 만들어 낸다. 리뷰·검증 후 수정할 것이 있으면 다시 계획해 무한루프를 돌린 뒤 결과를 낸다 23.

실행 방법

워크플로우를 트리거하는 방법은 세 가지다 24.

1. 프롬프트에 울트라 코드(ultra code) 키워드를 넣는다. 이번 턴이 다이나믹 워크플로우로 요청됐다고 표시된다.
2. "워크플로우로 ~작업을 진행해 줘"처럼 자연어로 요청한다.
3. 저장된 슬래시 명령어로 호출한다.

에포트(effort) 레벨은 로우 / 미디움 / 하이 / X하이(xhigh) / 맥스에 더해 울트라 코드 레벨까지 둘 수 있다. 다만 발표자는 기본 모드를 렉스(또는 X하이)로 두고 필요할 때만 울트라 코드 키워드를 입력하는 방식을 권장한다 24.

페이즈 분할과 병렬 에이전트

본질은 작업을 페이즈로 나누는 것이다. 메인 에이전트가 각 페이즈의 정확한 목표와 결과물을 정의하고, 페이즈마다 그에 맞는 하네스가 설정되도록 만든다 23.

딥리서치는 보통 스코프 → 서치 → 패치 → 검증 → 종합(리포트) 순으로 진행된다. 각 페이즈 안에서 다수의 서브 에이전트가 병렬로 실행된다 24.

• 실제 딥리서치 데모에서 서치 6개, 패치 28개, 검증 75개의 서브 에이전트가 병렬로 동작했다. 마지막 종합(리포트 작성)은 컨텍스트를 위해 단독으로 수행됐다 24 23.
• 엔트로픽 공식 문서 기준 워크플로우는 동시 최대 16개, 한 실행에 누적 최대 1,000개까지 서브 에이전트를 띄울 수 있다 24.
• 울트라 코드는 컨텍스트가 더 중요해서 딥리서치보다 적은 수의 에이전트를 쓴다. 파운데이션 4개 → 빌드 14개 → 통합 2개 → 리뷰 3개 식이다. 다만 각 에이전트가 더 오래 실행되므로 토큰 사용량은 오히려 더 많을 수 있다 23.

내부 구현 — JS 스크립트 기반

다이나믹 워크플로우는 내부적으로 자바스크립트(JS) 스크립트 기반으로 동작한다 24.

Claude Code가 작업에 맞는 JS 스크립트를 짜서 백그라운드에서 실행한다. 기존 세션은 그동안 다른 작업을 계속할 수 있고, 워크플로우 명령으로 진행 상황을 볼 수 있다 24.

다른 병렬 기법과 뭐가 다른가

차이는 **"플랜(계획 문서)을 누가 들고 있느냐"**에 있다 24.

워크플로우는 JS 스크립트 단에서 플랜을 관리하기 때문에 수십에서 수백 개 규모의 에이전트 실행이 가능하다 24.

만든 워크플로우는 키보드 S 키로 저장하면 .claude/워크플로우(claude workflows) 폴더에 .js 파일로 보존되어 재사용할 수 있다 24.

골(Goal)과의 관계

골(Goal)은 같은 흐름에 있지만 워크플로우 안에서 생성되지는 않는다. 목표 지향성이 가장 높은 기법이다.

턴 제한이 없어 몇 시간에서 며칠을 돌며 정해진 목표가 달성될 때까지 실행된다 23. 골은 손으로 정의하기 어렵기 때문에 메타프롬프팅("이 작업을 할 골 프롬프트를 만들어 줘")이 필수다 23.

고르는 기준은 이렇다. 일반적인 작업은 빠른 완료에 초점을 둔 울트라 코드를, 검증이 정말 까다롭고 완벽해야 하는 작업은 골을 쓰라고 권장한다 23.

이미 그래프였다

그래프 엔지니어링이라는 말이 낯설게 들려도, 다이나믹 워크플로우를 써 봤다면 이미 그 구조를 쓰고 있었던 셈이다. 계획을 짜고, 병렬로 리서치하고, 병렬로 작업하고, 한 번에 모아 검증하는 흐름은 그대로 노드와 엣지로 이어져 스테이트를 주고받는 그래프다 31.

그래서 두 개념의 차이는 물건이 아니라 시점에 가깝다. 다이나믹 워크플로우는 그 그래프를 에이전트가 즉석에서 만들어 주는 쪽이고, 그래프 엔지니어링은 사람이 미리 노드와 이동 규칙을 정해 두는 쪽이다.

어떤 일에 쓸 것인가 — 실사용 평가

호평만 있는 건 아니다. 한 대담에서는 결과물이 굉장히 별로였다는 혹평이 나온다. 이유는 구조에 있다. 쪼갤 것을 쪼개 서브에 시키고 합치는 방식이라, AGENTS.md나 goal.md, 문서 스키마처럼 명시적인 컨텍스트를 주지 않으면 잘 못한다는 것이다. 코덱스 쪽이든 Claude Code 쪽이든 사정은 비슷하다고 본다 30.

정리하면 시키는 방법보다 일의 종류가 갈랐다. 어울리는 태스크가 따로 있고 대부분의 일에는 필요가 없다는 결론이다 30.

비용 경고가 붙는다. 토큰을 수십 퍼센트씩 가져가서, 급한 김에 API로 돌렸다가 그 주에 300~400달러를 썼다는 증언이 나온다 (2026-08 기준). 200달러짜리 계정을 여러 개 쓰는 편이 낫다는 자조가 이어진다 30.

활용 — 하네스 다이어트

다이나믹 워크플로우는 하네스 엔지니어링의 "하네스 다이어트", 즉 낡은 하네스 제거에 특히 유용하다. 모델 성능이 좋아지면 과거에 만든 하네스가 오히려 방해가 되거나 제품 내장 기능과 중복될 수 있는데, 이를 점검하는 데 적합하다 24.

발표자는 커스텀 워크플로우 두 개를 만들어 시연했다 24.

① 하네스 레거시 스캔

읽기 전용 감사 워크플로우다. 인벤토리 → 애널라이즈(스킬·세이프티 퍼미션·프로덕트 오버랩 검증, 서브 에이전트 13개) → 플랜(리펙터 플래너) → 적대적 리뷰의 4단계로 돈다.

찾는 대상은 낡은 규칙, 중복 지식, 과도한 전역 컨텍스트, 너무 넓은 스킬, 불필요한 훅과 MCP, 제품 기본 기능과 중복되는 설정이다. 16개 에이전트로 109개 항목을 발견했고, 약 160만 토큰을 쓰며 17분간 실행됐다.

② 하네스 다이어트

스캔 리포트를 바탕으로 스플릿 → 리파인 단계로 실제 최적화를 적용한다. 결과적으로 SKILL.md 본문이 약 2,600줄에서 1,800줄로(약 760줄 절감), 활성 스킬은 29개에서 28개로 줄었다.

발표자는 두 워크플로우를 한 달에 한두 번 돌려 하네스를 주기적으로 갱신할 것을 권장한다 24.

함께 읽기

• 워크플로우 선택 가이드 — 일반 채팅부터 골까지, 어떤 작업에 어떤 모드를 고를지
• 하네스 엔지니어링 — 동적 하네스 생성과 하네스 다이어트의 상위 개념
• 루프 엔지니어링 — 완성도를 끌어올리는 루프 기법, 이 개념과 중첩된다
• 그래프 엔지니어링 — 같은 구조를 사람이 미리 설계하는 쪽
• 서브에이전트 & 에이전트 팀 — 병렬 실행 단위
• Claude Code — 이 기능을 제공하는 도구