Claude Code의 Dynamic Workflows: 에이전트가 스스로 작업용 하네스를 만드는 시대

AI 코딩 도구는 이제 단순히 코드를 작성하는 수준을 넘어가고 있다.
최근 Claude Code에 추가된 Dynamic Workflows는 그 변화를 잘 보여주는 기능이다.

핵심은 단순하다.

Claude가 주어진 작업에 맞춰
스스로 작업 구조, 즉 “하네스(harness)”를 만들어 실행할 수 있게 되었다.

기존 Claude Code는 기본적으로 코딩 작업에 최적화된 실행 환경을 제공했다. 하지만 실제로 AI에게 맡기는 일은 점점 더 복잡해지고 있다. 코드 수정뿐 아니라 리서치, 보안 분석, 코드 리뷰, 대규모 문서 검증, 에이전트 팀 운영, 후보자 평가, 사고 원인 분석 같은 작업들이 모두 AI의 영역으로 들어오고 있다.

이런 작업들은 단일 프롬프트 하나로 처리하기 어렵다.
작업을 나누고, 여러 관점에서 검증하고, 반복하고, 최종적으로 종합해야 한다.

Dynamic Workflows는 바로 이 지점에서 의미가 있다.

---

1. Dynamic Workflows란 무엇인가?

Dynamic Workflows는 Claude Code 안에서 실행되는 동적 작업 오케스트레이션 구조라고 볼 수 있다.

일반적인 Claude Code 사용 방식은 이렇다.

사용자가 요청한다.
Claude가 계획한다.
Claude가 실행한다.
Claude가 결과를 낸다.

하지만 Dynamic Workflows에서는 Claude가 먼저 이렇게 생각한다.

“이 작업을 잘하려면 어떤 구조가 필요하지?”
“몇 개의 하위 에이전트로 나눠야 하지?”
“검증 에이전트가 따로 필요하지 않을까?”
“병렬로 돌릴 수 있는 부분은 무엇이지?”
“어떤 모델을 어떤 작업에 써야 하지?”
“격리된 worktree에서 실행해야 안전하지 않을까?”

그리고 이 판단을 바탕으로 JavaScript 기반의 워크플로 파일을 생성해 실행한다.

즉, Claude가 단순히 답변을 생성하는 것이 아니라,
작업에 맞는 실행 구조 자체를 설계하고 운용하는 것이다.

---

2. 왜 이런 기능이 필요한가?

복잡한 작업을 하나의 컨텍스트 창에서 오래 처리하면 여러 문제가 생긴다.

첫째, 작업을 끝까지 하지 못하는 문제가 있다.
예를 들어 보안 리뷰에서 50개 항목을 확인해야 하는데, 20개 정도만 처리하고 “완료했다”고 판단하는 경우다. 원문에서는 이를 “agentic laziness”라고 표현한다.

둘째, 자기 선호 편향이 생긴다.
AI가 자신이 만든 결과를 다시 검토할 때, 자기 결과에 관대해지는 경향이 있다. 코드 리뷰나 기술 검증에서 특히 위험하다.

셋째, 목표 이탈이 발생한다.
긴 작업을 여러 턴에 걸쳐 진행하다 보면 처음의 요구사항, 금지 조건, 예외 조건이 흐려질 수 있다. 특히 컨텍스트 압축이 반복되면 세부 조건이 손실될 가능성이 커진다.

Dynamic Workflows는 이 문제를 구조적으로 줄이려는 접근이다.

하나의 Claude가 모든 것을 기억하고 처리하는 대신,
작업별로 별도의 Claude를 만들고, 각 Claude에게 독립된 목표와 컨텍스트를 부여한다.

쉽게 말하면, 혼자 오래 붙잡고 있는 방식이 아니라
작업반을 만들어 분업시키는 방식이다.

---

3. 기존 워크플로와 무엇이 다른가?

기존에도 여러 Claude Code 인스턴스를 연결해 정적 워크플로를 만들 수 있었다. Claude Agent SDK나 claude -p를 활용해 여러 에이전트를 조합하는 방식이다.

하지만 정적 워크플로는 기본적으로 미리 설계된 구조다.
범용적으로 만들어야 하기 때문에 특정 작업에 완전히 최적화되기 어렵다.

반면 Dynamic Workflows는 작업이 들어온 순간 Claude가 그 작업에 맞는 하네스를 생성한다.

예를 들어 “깨지는 테스트를 재현하고 원인을 찾아줘”라는 작업과
“80개의 이력서를 백엔드 역할 기준으로 평가해줘”라는 작업은 전혀 다르다.

하나는 재현, 가설 생성, 실험, 검증이 중요하다.
다른 하나는 기준 설정, 후보 분류, 상위 후보 재검증, 편향 방지가 중요하다.

Dynamic Workflows는 이 두 작업에 같은 구조를 강제로 적용하지 않는다.
각각에 맞는 실행 패턴을 즉석에서 구성한다.

---

4. 대표적인 워크플로 패턴들

Dynamic Workflows에서 자주 등장하는 패턴은 몇 가지로 정리할 수 있다.

Classify and Act

먼저 작업을 분류한 뒤, 그 결과에 따라 다른 에이전트나 실행 방식을 선택하는 패턴이다.

예를 들어 고객 문의를 처리할 때, 먼저 “버그 신고인지, 결제 문제인지, 기능 요청인지”를 분류한다. 그다음 각 유형에 맞는 전문 에이전트가 처리한다.

대규모 티켓 처리, 고객 지원, 로그 분류, 코드 변경 유형 분석에 잘 맞는다.

---

Fan-out and Synthesize

작업을 여러 조각으로 나누고, 각 조각을 별도 에이전트가 처리한 뒤 마지막에 하나로 종합하는 방식이다.

예를 들어 기술 리서치를 한다고 하면,
한 에이전트는 공식 문서를 조사하고,
다른 에이전트는 GitHub 코드를 확인하고,
또 다른 에이전트는 관련 이슈를 살펴본다.

이후 종합 에이전트가 결과를 합쳐 최종 보고서를 만든다.

대규모 리서치, 코드베이스 분석, 문서 검토, 여러 파일 리팩터링에 유용하다.

---

Adversarial Verification

어떤 에이전트가 결과를 만들면, 별도의 검증 에이전트가 그 결과를 공격적으로 검토한다.

“이 주장이 맞는가?”
“근거가 충분한가?”
“요구사항을 빠뜨리지 않았는가?”
“코드 변경이 다른 기능을 깨지 않는가?”

이런 식으로 결과를 일부러 의심하게 만드는 구조다.

기술 글 검증, 코드 리뷰, 보안 분석, 정책 검토, 투자 계획 검토 등에 적합하다.

---

Generate and Filter

여러 개의 아이디어를 생성한 다음, 기준에 따라 걸러내는 방식이다.

예를 들어 CLI 도구 이름을 짓는다고 하면,
여러 에이전트가 다양한 이름을 제안하고,
리뷰 에이전트가 기억하기 쉬움, 검색 가능성, 브랜드 적합성, 중복 가능성 등을 기준으로 필터링한다.

네이밍, 디자인 방향 탐색, 마케팅 카피, 제품 아이디어 발굴에 잘 맞는다.

---

Tournament

여러 에이전트가 같은 문제를 각자 다른 방식으로 해결한다.
그다음 심사 에이전트가 결과를 비교해 승자를 고른다.

이 방식은 정답이 하나로 명확하지 않은 작업에 특히 유용하다.

예를 들어 “가장 좋은 랜딩페이지 구조를 만들어줘”라는 요청이 있다면,
A 에이전트는 전환율 중심으로 설계하고,
B 에이전트는 브랜드 스토리 중심으로 설계하고,
C 에이전트는 SEO 중심으로 설계할 수 있다.

그 후 비교 심사를 통해 가장 좋은 안을 고른다.

---

Loop Until Done

작업량이 처음부터 명확하지 않을 때 사용하는 방식이다.

예를 들어 테스트 실패 원인을 찾아야 하는데,
몇 번의 실험이 필요한지 모를 수 있다.

이럴 때 고정된 횟수만 실행하는 것이 아니라,
“새로운 에러가 나오지 않을 때까지”
“모든 로그가 설명될 때까지”
“검증 에이전트가 통과를 선언할 때까지”
반복하는 구조를 만들 수 있다.

디버깅, 리서치, 보안 점검, 데이터 품질 검사에 적합하다.

---

5. 어떤 작업에 특히 유용한가?

Dynamic Workflows는 코딩에만 쓰이는 기능이 아니다.
오히려 복잡한 비기술 작업에서도 강력하다.

대규모 리팩터링과 마이그레이션

예를 들어 User 모델을 Account로 바꿔야 한다고 해보자.

단순 검색 치환으로 끝나지 않는다.
모델명, API, 테스트, 문서, 타입, 마이그레이션 스크립트, UI 텍스트, 권한 로직까지 연결될 수 있다.

이런 작업은 여러 하위 작업으로 쪼개야 한다.
각 callsite나 모듈마다 별도 에이전트를 붙이고, 검증 에이전트가 변경 사항을 다시 확인하는 구조가 효과적이다.

---

딥 리서치

Dynamic Workflows는 리서치에도 잘 맞는다.

하나의 에이전트가 웹 검색을 전부 수행하는 대신,
여러 에이전트가 서로 다른 소스를 조사하고,
별도 에이전트가 출처 품질을 검증하고,
최종 에이전트가 인용이 포함된 보고서로 종합할 수 있다.

이 구조는 단순 웹 리서치뿐 아니라 Slack, 코드베이스, 내부 문서, 이슈 트래커를 조사하는 데도 활용할 수 있다.

---

기술 글 검증

기술 블로그를 공개하기 전, 모든 주장이 코드베이스와 맞는지 확인해야 할 때가 있다.

이때 Dynamic Workflow를 사용하면,
먼저 한 에이전트가 글 속의 기술적 주장을 추출하고,
각 주장마다 검증 에이전트를 배정하고,
다시 별도 에이전트가 출처와 검증 품질을 확인할 수 있다.

“틀린 기술 글을 내보내지 않기 위한 자동 검증팀”처럼 쓸 수 있다.

---

이력서 평가와 정렬

80개, 500개, 1000개의 이력서를 한 번에 평가하는 작업은 단일 컨텍스트에 넣기 어렵다.

이런 경우 Dynamic Workflows는 후보를 병렬로 분류하고,
상위 후보를 다시 검증하고,
필요하면 pairwise comparison 방식으로 순위를 조정할 수 있다.

절대 점수보다 비교 판단이 더 안정적인 경우가 많기 때문에, 토너먼트 방식이 특히 유용할 수 있다.

---

사고 원인 분석

장애가 발생했을 때 원인을 찾는 작업도 Dynamic Workflows와 잘 맞는다.

한 에이전트는 로그를 본다.
다른 에이전트는 최근 배포 내역을 본다.
또 다른 에이전트는 데이터 변화나 외부 API 상태를 본다.

각자 독립적으로 가설을 만든 뒤, 검증 에이전트와 반박 에이전트가 이를 테스트한다.

이 구조는 기술 장애뿐 아니라 매출 하락, 영업 부진, 데이터 파이프라인 실패, 운영 이슈 분석에도 적용할 수 있다.

---

대규모 트리아지

지원 티켓, 버그 리포트, 고객 문의, 보안 알림처럼 사람이 모두 처리하기 어려운 큐가 있다.

Dynamic Workflows는 각 항목을 분류하고, 중복 여부를 확인하고, 이미 등록된 이슈와 비교하고, 필요하면 수정하거나 사람에게 에스컬레이션하는 구조를 만들 수 있다.

특히 중요한 개념은 “quarantine”이다.

외부에서 들어온 신뢰할 수 없는 콘텐츠를 읽는 에이전트와, 실제 권한 있는 작업을 수행하는 에이전트를 분리하는 것이다.
이렇게 하면 프롬프트 인젝션이나 악성 입력으로부터 더 안전한 구조를 만들 수 있다.

---

6. 언제 쓰지 말아야 할까?

Dynamic Workflows는 강력하지만 모든 작업에 필요한 것은 아니다.

일반적인 코드 수정, 간단한 버그 수정, 짧은 문서 작성, 단순 질의응답에는 과할 수 있다.

워크플로는 여러 에이전트를 만들고, 병렬 처리하고, 검증 단계를 추가하기 때문에 토큰 사용량이 늘어난다.

즉, Dynamic Workflows는 “더 많은 컴퓨트와 구조가 필요한 작업”에 써야 한다.

예를 들어 단순한 CSS 수정에 리뷰 에이전트 5명을 붙일 필요는 없다.
반대로 보안 분석, 대규모 리팩터링, 기술 문서 검증, 원인 분석처럼 실패 비용이 큰 작업에는 충분히 가치가 있다.

---

7. 잘 쓰기 위한 프롬프트 방식

Dynamic Workflows를 잘 쓰려면 그냥 “해줘”보다 구조를 명시하는 것이 좋다.

예를 들어 이런 식이다.

“워크플로를 사용해서 이 실패 테스트를 재현하고, 여러 가설을 세운 뒤, 각 가설을 독립적으로 검증해줘. 하나의 가설이 통과할 때까지 멈추지 마.”

“이 기술 블로그 초안의 모든 기술적 주장을 추출하고, 각 주장을 코드베이스와 문서 기준으로 검증하는 워크플로를 만들어줘.”

“이 사업계획서를 투자자, 고객, 경쟁사 관점의 세 에이전트가 각각 비판하게 하고, 마지막에 공통 리스크와 개선안을 종합해줘.”

“이력서 폴더를 백엔드 개발자 기준으로 평가하되, 먼저 나에게 평가 루브릭을 질문한 뒤, 상위 10명을 다시 검증해줘.”

중요한 것은 AI에게 단순 결과물이 아니라
검증 구조, 반복 조건, 판단 기준, 역할 분담을 함께 지시하는 것이다.

---

8. Skill과 결합하면 더 강력해진다

Dynamic Workflows는 저장하고 공유할 수 있다.

워크플로 메뉴에서 저장하거나, ~/.claude/workflows에 넣어 재사용할 수 있다.
또한 Skill에 JavaScript 워크플로 파일을 포함하고, SKILL.md에서 이를 참조하게 만들 수도 있다.

이 방식은 특히 팀 단위에서 중요하다.

예를 들어 회사 내부에 다음과 같은 워크플로를 Skill로 만들어둘 수 있다.

• 보안 리뷰 워크플로
• 코드 리뷰 워크플로
• 기술 블로그 검증 워크플로
• 장애 원인 분석 워크플로
• 고객 티켓 트리아지 워크플로
• 채용 후보자 평가 워크플로
• 제품 기획 비판 워크플로

이렇게 되면 Claude Code는 단순한 코딩 도구가 아니라
팀의 반복 업무를 구조화하는 실행 환경에 가까워진다.

---

9. 핵심은 “에이전트에게 일을 시키는 방식”의 변화다

지금까지 AI에게 일을 시키는 방식은 대부분 이랬다.

“이거 해줘.”
“수정해줘.”
“분석해줘.”
“요약해줘.”

하지만 Dynamic Workflows가 보여주는 방향은 조금 다르다.

앞으로는 이렇게 요청하게 될 가능성이 크다.

“이 일을 잘하기 위한 작업 구조를 먼저 만들고,
필요한 하위 에이전트를 구성하고,
검증자를 붙이고,
반복 조건을 설정한 뒤,
완료 기준을 만족할 때까지 실행해줘.”

즉, AI에게 단일 답변을 요구하는 것이 아니라
작업 시스템 자체를 만들게 하는 방식으로 바뀌고 있다.

---

10. Claude Code는 점점 “개발 도구”를 넘어가고 있다

Dynamic Workflows는 Claude Code가 단순 코딩 도구에서
더 넓은 범위의 작업 오케스트레이션 도구로 확장되고 있음을 보여준다.

코딩, 리서치, 검증, 리뷰, 분류, 정렬, 원인 분석, 팀 에이전트 운영까지
많은 지식 작업이 사실은 “구조화된 문제 해결”에 가깝다.

그리고 Claude Code의 Dynamic Workflows는 이 구조화된 문제 해결을
AI가 직접 설계하고 실행하게 만든다.

물론 아직 초기 단계다.
토큰 사용량도 많아질 수 있고, 모든 작업에 적합한 것도 아니다.

하지만 방향은 분명하다.

AI 에이전트의 경쟁력은 단순히 “좋은 답변”을 만드는 데서 끝나지 않는다.
앞으로는 어떤 작업 구조를 만들고, 어떻게 여러 에이전트를 조율하며, 어떻게 검증까지 포함하느냐가 중요해질 것이다.

Dynamic Workflows는 그 변화의 중요한 신호다.

이제 Claude Code는 코드를 쓰는 도구를 넘어,
복잡한 일을 끝까지 밀어붙이기 위한
“동적 작업 시스템”으로 진화하고 있다.