Dynamic Workflows를 켜기 전 먼저 물어야 할 질문: 이 일이 옆으로 쪼개지는가?

TL;DR

• Claude Code의 Dynamic Workflows는 큰 일을 잘게 쪼개고, 여러 AI 팀원에게 병렬로 맡긴 뒤, 검증까지 거쳐 하나로 합치는 방식입니다.

• 작은 수정이나 빠른 질문에는 과합니다. 공식 문서에서도 일반 Claude Code 세션보다 토큰을 훨씬 더 쓸 수 있으니 작은 범위부터 시작하라고 말합니다.

• 판단 기준은 하나예요. “이 일이 서로 독립적으로 굴러가는 여러 조각으로 쪼개지는가?” 여기에 예스라면 Dynamic Workflows 후보입니다.

도입부

AI에게 일을 맡기다 보면 이런 순간이 있습니다.

“100개를 봐달라고 했는데 왜 10개만 보고 다 했다고 하지?”

“처음에는 방향이 좋았는데, 대화가 길어지니까 목표가 흐려지네?”

“AI가 만든 결과를 AI가 검토했는데, 너무 후하게 본 것 같은데?”

개인적으로 Claude나 Codex를 오래 쓰면서 제일 많이 느낀 문제가 이거였어요. AI가 똑똑하지 않아서가 아니라, 큰 일을 맡기는 구조가 약하면 중간에 흐려집니다.

이번에 Claude Code에 나온 Dynamic Workflows는 이 문제를 정면으로 다룹니다. 단순히 “에이전트를 많이 켠다”가 아니라, 큰 일을 쪼개고, 나눠 맡기고, 서로 검증하고, 다시 합치는 작업 구조에 가깝습니다.

이 레터에서는 먼저 핵심 개념과 판단 기준을 글로 정리해드릴게요. 실제 Claude Code 화면에서 어떻게 켜지는지, 에이전트가 어떻게 병렬로 돌아가는지, 토큰 사용량과 진행 상태는 어디서 보는지는 유튜브 영상에서 더 자세히 시연해뒀습니다.

이번 레터에서는 기능 소개보다 더 중요한 걸 정리해볼게요.

언제 켜야 하고, 언제 켜면 안 되는지입니다.

Part 1. Dynamic Workflows는 AI 팀을 즉석에서 꾸리는 방식입니다

Anthropic은 2026년 5월 28일 Claude Code의 Dynamic Workflows를 공개했습니다. 공식 설명을 쉽게 풀면 이렇습니다.

Claude가 사용자의 요청을 보고, 그 자리에서 작업 흐름을 짭니다. 그리고 수십 개에서 수백 개의 서브에이전트를 한 세션 안에서 병렬로 돌립니다. 마지막에는 결과를 바로 내놓는 게 아니라, 검증까지 한 뒤 사용자에게 보고합니다.

여기서 중요한 단어는 “병렬”과 “검증”입니다.

우리가 보통 AI에게 큰 일을 맡기면 한 대화창 안에서 계속 이어갑니다. 그런데 대화가 길어질수록 세 가지 문제가 생겨요.

첫째, 게으름입니다. 많이 시켰는데 일부만 하고 끝났다고 말하는 경우가 있습니다.

둘째, 자기 편애입니다. AI가 만든 결과를 AI가 스스로 너무 좋게 평가할 수 있습니다.

셋째, 목표 표류입니다. 처음 목표가 대화가 길어지면서 점점 흐려집니다.

Dynamic Workflows는 이걸 구조로 막으려는 시도입니다. 깨끗한 작업 공간을 여러 개 만들고, 각자 다른 조각을 맡기고, 일부는 검증 역할을 맡깁니다.

쉽게 말하면, Claude가 즉석에서 작은 작업장을 만드는 겁니다.

작업자도 배치하고, 검수자도 배치하고, 마지막에 결과를 모아 하나의 보고서로 정리하는 방식입니다.

Part 2. 헷갈리는 기능은 사다리로 보면 쉽습니다

깊게 파면 /goal, 옆으로 펼치면 Dynamic Workflows입니다.

많은 분들이 여기서 헷갈립니다.

“이거 서브에이전트랑 뭐가 다른가요?”

“에이전트 팀이랑 다른가요?”

“/goal이랑은 어떻게 구분하나요?”

저는 이걸 사다리로 보는 게 제일 쉽다고 봅니다.

핵심 차이는 계획을 누가 들고 있느냐입니다.

서브에이전트는 메인 Claude가 계획을 들고, 곁다리 작업을 따로 맡깁니다.

/goal은 하나의 목표를 끝까지 파는 성격이 강합니다.

Dynamic Workflows는 Claude가 작업별 계획을 만들고, 그 계획을 바탕으로 여러 에이전트를 펼쳐서 실행합니다. 그래서 “깊게 파기”보다 “넓게 나누기”에 가깝습니다.

정리하면 이렇게 볼 수 있어요.

끝까지 파야 하면 /goal.

옆으로 펼쳐서 동시에 처리해야 하면 Dynamic Workflows.

Part 3. 이 기능은 여섯 가지 패턴으로 쓰면 됩니다

Dynamic Workflows를 막연하게 보면 어렵습니다. 그런데 실제 업무로 보면 크게 여섯 가지 패턴으로 나눌 수 있어요.

첫째, 분류 후 처리입니다.

예를 들어 고객 문의 300개가 있다고 해볼게요. 먼저 버그, 환불, 리드, 스팸으로 나눕니다. 그다음 각 종류에 맞는 담당 에이전트가 처리합니다. 핵심은 처리 전에 “무슨 일인지”부터 나누는 겁니다.

둘째, 펼쳐서 조합하기입니다.

자료 폴더 30개를 읽고, 폴더마다 핵심을 뽑고, 마지막에 하나의 표로 합치는 식입니다. 리서치, 기업 실사, 경쟁사 분석, 강의자료 검토에 잘 맞습니다.

셋째, 반대로 검증하기입니다.

AI가 쓴 글을 다른 AI가 반박하게 하는 방식입니다. 팩트체크, 보안 점검, 중요한 제안서 검토처럼 틀리면 비용이 큰 일에 좋습니다.

넷째, 많이 만들고 선별하기입니다.

헤드라인 100개를 만들고, 심사 기준으로 상위 5개만 고르는 방식입니다. 콘텐츠 제목, 광고 문구, 제품 아이디어, 강의명 후보에 붙이기 좋습니다.

다섯째, 토너먼트입니다.

후보를 둘씩 맞붙여 비교하고, 이긴 후보만 다음 라운드로 올립니다. 이력서, 제안서, 아이디어 우선순위처럼 “상대 비교”가 중요한 작업에 맞습니다.

여섯째, 될 때까지 반복하기입니다.

빌드가 통과될 때까지, 테스트가 깨지지 않을 때까지, 같은 오류가 재현되지 않을 때까지 반복하는 구조입니다. 개발 업무뿐 아니라 문서 검수에도 응용할 수 있습니다.

예를 들어 뉴스레터에도 쓸 수 있어요.

자료 20개를 읽고, 주장별 출처를 붙이고, 반대 의견을 만들고, 마지막에 독자가 따라 할 체크리스트로 바꾸는 작업입니다.

이건 혼자 한 번에 처리하기보다, 여러 역할로 나누는 편이 훨씬 안정적입니다.

Part 4. 켜야 할 때와 끄는 게 나은 때

처음에는 전체가 아니라 5개 문서, 1개 폴더처럼 작게 실험하세요.

여기서 제일 중요한 건 이겁니다.

Dynamic Workflows는 매일 켜는 기능이 아닙니다.

공식 블로그에서도 Dynamic Workflows는 일반 Claude Code 세션보다 사용량이 크게 늘 수 있으니, 작은 범위부터 시작하라고 말합니다. 실제로 제가 영상에서 시연했을 때도 19개의 에이전트가 돌았고, 약 120만 토큰을 사용했으며, 13분 정도 걸렸습니다.

물론 이 수치는 제 시연 사례입니다. 모든 작업이 이렇게 돈다는 뜻은 아닙니다. 하지만 방향은 분명해요.

큰 일을 맡길 때 쓰는 기능입니다.

켜도 좋은 일은 이런 것들입니다.

• 코드베이스 전체 점검
• 보안 점검
• 수천 파일 규모의 이전 작업
• 수십 개 문서 검토
• 많은 후보를 비교해 순위화하는 작업
• 틀리면 안 되는 결과를 여러 번 검증해야 하는 작업
   

반대로 끄는 게 나은 일도 분명합니다.

• 코드 한 줄 수정
• 빠른 질문
• 단일 문서 요약
• 짧은 초안 작성
• 간단한 리서치

이런 일에 Dynamic Workflows를 켜면, 결과보다 비용과 시간이 더 커질 수 있습니다.

그래서 저는 판단 기준을 하나로 줄입니다.

이 일이 서로 상관없이 동시에 굴러가는 여러 조각으로 쪼개지는가?

예스라면 후보입니다.

아니라면 일반 Claude, 스킬, 서브에이전트, /goal이 더 낫습니다.

저장용: Dynamic Workflows 결정표

아래 표는 저장해두고 쓰셔도 좋습니다.

저장용: 시작 프롬프트

처음부터 “워크플로우 만들어줘”라고 하기보다, 저는 이렇게 시작하는 걸 추천합니다.

이 작업이 Dynamic Workflow에 적합한지 먼저 판단해줘. 목표: [원하는 최종 결과] 범위: [폴더/문서/파일/자료 범위] 분할 기준: [파일별/주제별/고객군별/기능별] 검증 기준: [틀리면 안 되는 기준] 출력물: [표/보고서/PR/체크리스트] 토큰/시간 상한: [가능하면 제한] 적합하면 workflow 계획을 먼저 보여줘. 어떤 subagent가 어떤 일을 맡는지, 어떤 검증을 거치는지 설명한 뒤 시작해줘. 적합하지 않으면 더 단순한 방식으로 바꿔줘.

이 프롬프트의 핵심은 “바로 실행”이 아니라 “먼저 판단”입니다.

AI에게 큰 일을 맡길수록, 프롬프트 문장보다 작업 구조가 중요해집니다.

이번 주 20분 적용 실험

이번 주에는 아주 작게 실험해보세요.
자료 폴더 하나를 고릅니다. 고객 문의 30개, 회의록 20개, 리서치 문서 10개 정도면 충분합니다. 위 프롬프트에 목표, 범위, 분할 기준, 출력물만 채웁니다. 바로 실행하지 말고 “workflow 계획만 먼저 보여줘”라고 요청합니다.

계획에서 확인할 것은 세 가지입니다.

• 에이전트가 너무 많이 생기지 않는가?
• 검증 단계가 실제로 필요한가?
• 최종 결과물이 내가 바로 쓸 수 있는 형태인가?

1. 범위가 커 보이면 5개 문서만 넣고 먼저 테스트합니다.

큰 일을 AI에게 맡기는 연습은 크게 시작하면 안 됩니다. 작게 쪼개서, 구조를 보고, 비용을 확인한 뒤 키우는 게 좋습니다.

유튜브에서 더 자세히 시연해뒀습니다

이번 레터는 개념과 판단 기준을 정리한 버전입니다.

유튜브 영상에서는 실제 Claude Code 화면에서 Dynamic Workflows가 어떻게 켜지는지, 워크플로우가 백그라운드에서 어떻게 진행되는지, 여러 에이전트가 어떤 식으로 배정되는지 더 자세히 보여드렸습니다.

특히 영상에서는 이런 장면을 볼 수 있습니다.

• 스킬, 서브에이전트, 에이전트 팀, /goal, Dynamic Workflows를 사다리로 비교하는 장면
• 울트라코드와 Dynamic Workflows가 연결되는 흐름
• 실제로 여러 에이전트가 병렬로 돌아가는 화면
• 토큰 사용량과 진행 상태를 확인하는 장면
• “언제 켜고 언제 끌지” 결정표

글로 이해가 됐다면, 영상에서는 화면으로 확인해보시면 좋습니다.

AI 기능은 이름만 외우면 금방 헷갈립니다. 실제 화면에서 “어떤 작업에 켜는지”를 보면 훨씬 빨리 잡히더라고요.

 

마무리

앞으로 AI 활용의 차이는 프롬프트를 예쁘게 쓰는 능력보다, 일을 나누는 능력에서 더 많이 날 것 같습니다.

작은 일은 작게 맡기고, 큰 일은 구조를 짜서 맡기는 것.
이 감각이 있어야 AI를 오래 써도 결과가 흐려지지 않습니다.
이번 영상과 레터의 핵심은 하나입니다.
Dynamic Workflows는 많이 켜는 기능이 아니라, 크게 쪼개야 할 때 켜는 기능입니다.
다음에 Claude Code나 Codex로 큰 작업을 맡기기 전에, 먼저 이 질문 하나만 던져보세요.

“이 일은 옆으로 쪼개지는가, 아니면 깊게 파야 하는가?”

여기서부터 도구 선택이 달라집니다.

출처

• Claude Blog, “Introducing dynamic workflows in Claude Code”, 2026-05-28, https://claude.com/blog/introducing-dynamic-workflows-in-claude-code
• Anthropic News, “Introducing Claude Opus 4.8”, 2026-05-28, https://www.anthropic.com/news/claude-opus-4-8
• AI싱크클럽 내부 영상 자막, 0607_silence03, 2026-06-08 정리본