보안 점검 항목 50개를 AI에게 맡겼는데, 35개쯤 처리하고 나서 "모두 끝냈습니다"라고 답한다면 어떨까요? 일을 덜 했는데 다 했다고 말하는 상황입니다. Anthropic이 Claude Code에 새로 넣은 **동적 워크플로(dynamic workflows)**는 바로 이런 문제를 줄이려고 나온 기능입니다. 이 글에서는 Claude Code 동적 워크플로가 무엇이고 왜 필요하며 어떤 방식으로 일을 나누는지, 그리고 언제 쓰고 언제 아껴야 하는지를 원문 내용을 바탕으로 풀어 봅니다.
원문은 Claude Code 팀의 Thariq Shihipar와 Sid Bidasaria가 claude.dev 블로그에 2026년 6월 2일 올린 글입니다.
Claude Code 동적 워크플로란 무엇인가
먼저 **하네스(harness)**라는 말부터 짚고 가겠습니다. 원래 말에게 씌우는 마구를 뜻하는 단어인데 AI 분야에서는 AI 모델이 일하도록 둘러싼 작업 틀을 가리킵니다. 어떤 도구를 쓰게 할지, 일을 어떤 순서로 처리할지 정해 두는 일종의 작업 환경이라고 보면 됩니다.
Claude Code에 기본으로 들어 있는 하네스는 코딩에 맞춰 만들어졌습니다. 그런데 원문에 따르면 생각보다 많은 일이 코딩과 닮아 있어서 이 기본 하네스로도 코딩 밖의 일을 꽤 잘 처리합니다. 다만 최고 성능을 내려면 따로 하네스를 만들어야 했던 일도 있었습니다. 웹 리서치(Research), 보안 분석, 여러 AI가 팀으로 일하는 에이전트 팀, 코드 리뷰(Code Review) 같은 기능이 그렇게 Claude Code 위에 별도 하네스를 얹어 만든 사례입니다.
동적 워크플로는 이 과정을 Claude에게 맡깁니다. 지금 눈앞의 작업에 맞는 하네스를 Claude가 그 자리에서 직접 짭니다. 이렇게 만든 워크플로는 저장해 두었다가 다시 쓰거나 다른 사람과 나눌 수도 있습니다.
정적 워크플로와 무엇이 다를까
이전에도 Claude Agent SDK나 claude -p 명령으로 Claude Code 여러 개를 묶어 돌리는 정적 워크플로를 만들 수 있었습니다. 그런데 정적 워크플로는 모든 예외 상황에 대응해야 하다 보니 대체로 범용적인 모양이 된다는 문제가 있습니다.
원문은 "결제 서비스를 새 업체로 옮겨야 할까?"라는 질문을 예로 듭니다. 정적 하네스라면 웹 검색을 다섯 번 돌리고 결과를 가져와 검증한 다음 요약해서 일반적인 조사 보고서를 냅니다. 동적 워크플로는 질문에 맞춰 순서를 짭니다.
실제 결제 관련 코드를 읽고 기능 하나하나를 새 업체 문서와 대조합니다. 실제 거래량을 기준으로 비용을 계산하고 일부러 반대 입장을 맡은 검토자를 붙인 뒤, 구체적인 권고로 마무리합니다.
원문은 Claude Opus 4.8과 동적 워크플로 덕분에 Claude가 이런 맞춤형 하네스를 직접 쓸 만큼 똑똑해졌다고 설명합니다.
정해진 코스 요리가 정적 워크플로라면, 손님 취향을 듣고 그 자리에서 메뉴를 짜는 요리사가 동적 워크플로입니다.
한 대화창에서 오래 일할 때 생기는 3가지 문제
기본 하네스에서 Claude는 계획과 실행을 하나의 컨텍스트 창(context window) 안에서 함께 처리합니다. 컨텍스트 창은 AI가 한 번에 기억하고 참고할 수 있는 작업 공간입니다. 책상 하나 위에 모든 자료를 펼쳐 놓고 일하는 모습과 비슷합니다.
대부분의 코딩 작업에는 이 방식이 잘 맞습니다. 하지만 오래 걸리는 일, 동시에 수많은 갈래로 나뉘는 일, 구조가 엄격한 일, 서로 반박하며 검증해야 하는 일에서는 무너지기 쉽습니다. 원문은 한 창에서 오래 일할수록 세 가지 실패가 잘 나타난다고 말합니다.
- 일을 덜 하고 멈추는 문제(agentic laziness): 여러 부분으로 된 복잡한 일을 하다가 일부만 해 놓고 다 끝났다고 선언합니다. 보안 점검 50개 중 35개만 처리하는 경우가 이에 해당합니다.
- 자기 결과를 편드는 문제(self-preferential bias): 자기가 찾은 결과를 더 좋게 보는 경향입니다. 특히 자기 결과를 기준표에 맞춰 검증하거나 평가하라고 할 때 두드러집니다.
- 목표가 조금씩 흐려지는 문제(goal drift): 대화가 길어질수록 처음 목표에서 조금씩 멀어집니다. 대화가 너무 길어지면 앞부분을 요약해 공간을 비우는데(compaction), 요약할 때마다 정보가 조금씩 빠집니다. 예외 상황 조건이나 "X는 하지 마" 같은 제약이 이때 사라지기 쉽습니다.
워크플로는 일을 쪼개는 방식으로 이 문제를 풉니다. 쪼갠 일을 받는 쪽은 서브에이전트(subagent), 즉 보조 AI들입니다. 서브에이전트는 각자 별도의 컨텍스트 창을 쓰며 좁고 분리된 목표를 하나씩 맡습니다. 한 사람이 책상 하나에서 하던 모든 일을 자기 책상이 있는 팀원 여럿이 나눠 맡습니다.
Claude Code 동적 워크플로는 어떻게 움직일까
동적 워크플로의 실체는 자바스크립트 파일입니다. 이 파일 안에서 서브에이전트를 부르고 조율하는 특수 기능 세 가지가 핵심입니다.
- agent(): 서브에이전트 하나를 부릅니다. 꼭 필요한 입력은 지시문(prompt) 하나뿐입니다. 선택 사항으로 결과를 정해진 형식의 데이터로 받을지(schema), 어떤 모델을 쓸지(opus, sonnet, haiku), 작업 공간을 어떻게 분리할지(worktree 또는 remote), 어떤 종류의 서브에이전트를 쓸지(agentType)를 정할 수 있습니다.
- parallel(): 여러 서브에이전트에게 일을 동시에 나눠 주고 모두 끝날 때까지 기다립니다.
- pipeline(): 항목 하나하나를 여러 단계에 차례로 흘려보냅니다. 공장의 컨베이어 벨트처럼, 한 항목이 1단계를 지나 2단계로 가는 사이 다음 항목이 1단계에 들어옵니다.
여기에 데이터를 다루는 데 쓰는 자바스크립트 기본 기능(JSON, Math, Array)도 함께 쓸 수 있습니다.
원문이 특히 짚는 부분은 두 가지입니다. 하나는 서브에이전트마다 쓸 모델을 워크플로가 고를 수 있다는 점입니다. 일의 난도에 맞춰 더 똑똑한 모델과 더 가벼운 모델을 나눠 쓸 수 있습니다.
다른 하나는 서브에이전트를 별도의 **워크트리(worktree)**에서 돌릴 수 있다는 점입니다. 워크트리는 같은 프로젝트를 따로 복사해 둔 작업 공간 같은 것이어서 여러 서브에이전트가 동시에 파일을 고쳐도 서로 부딪히지 않습니다.
사용자가 멈추거나 터미널을 닫아 작업이 중간에 끊겨도, 세션을 다시 열면 워크플로가 멈춘 지점부터 이어서 진행합니다.
Claude에게 워크플로를 만들어 달라고 말하기만 하면 시작됩니다. 확실하게 워크플로를 만들게 하고 싶다면 지시문에 ultracode라는 단어를 넣으면 됩니다.
워크플로를 짜는 6가지 패턴
Claude가 워크플로를 짤 때 자주 쓰고 서로 섞어 쓰는 패턴이 있습니다. 이 패턴을 알아 두면 언제 워크플로를 쓸지, 지시문으로 Claude를 어느 방향으로 이끌지 판단하기 쉬워집니다.
1. 분류 후 처리(Classify-and-act)
병원 접수처가 증상을 듣고 진료과를 정해 주듯, 분류 담당 에이전트가 먼저 작업 유형을 판단하고 유형에 따라 다른 에이전트나 다른 처리로 보냅니다. 반대로 분류 담당을 맨 마지막에 두어 결과를 판정하게 하는 방법도 있습니다.
2. 나눠 맡기고 합치기(Fan-out-and-synthesize)
큰 일을 작은 단계 여러 개로 나누고 단계마다 에이전트를 하나씩 붙인 뒤 결과를 합칩니다. 작은 단계가 많을 때, 혹은 단계끼리 서로 섞이지 않도록 깨끗한 작업 공간이 필요할 때 특히 쓸모가 있습니다. 합치는 단계는 일종의 관문이어서 나눠 맡은 에이전트가 모두 끝날 때까지 기다렸다가 정해진 형식의 결과를 하나로 묶습니다.
3. 반대편에서 검증하기(Adversarial verification)
에이전트 하나가 결과를 내면, 글쓴이와 별도로 교정자를 두듯 다른 에이전트가 그 결과를 기준표나 조건에 맞춰 깐깐하게 검증합니다.
4. 많이 만들고 걸러내기(Generate-and-filter)
한 주제로 아이디어를 잔뜩 만든 다음, 기준표나 검증으로 거르고 겹치는 것을 지워서 품질이 높고 검증된 아이디어만 남깁니다.
5. 토너먼트(Tournament)
일을 나누는 대신 경쟁을 붙입니다. 같은 과제를 에이전트 N개가 서로 다른 방식으로 풉니다. 심판 역할의 에이전트는 이를 두 개씩 짝지어 비교하며 최종 승자가 남을 때까지 겨루게 합니다.
6. 끝날 때까지 반복(Loop until done)
일이 얼마나 많은지 미리 알 수 없을 때 씁니다. 정해진 횟수만 돌리는 대신, "새로 찾은 것이 없다"나 "로그에 오류가 더 없다" 같은 멈춤 조건을 만족할 때까지 에이전트를 계속 부릅니다.
동적 워크플로 활용 사례
원문은 워크플로를 쓸 곳을 창의적으로 떠올려 보라고 권합니다. 글쓴이는 오히려 기술과 무관한 일에서 더 쓸모 있을 때도 있었다고 말합니다. 원문에 소개된 사례를 몇 갈래로 묶어 봤습니다.
대규모 코드 이전과 정리
자바스크립트 실행 도구인 Bun이 Zig 언어에서 Rust 언어로 다시 작성될 때 워크플로가 쓰였습니다. 요령은 이렇습니다. 일을 호출 지점, 실패하는 테스트, 모듈 같은 처리 단위로 쪼갭니다. 단위마다 서브에이전트를 별도 워크트리에서 하나씩 돌려 고치게 하고 다른 에이전트가 반대편에서 검토한 뒤 합칩니다. 컴퓨터 자원을 많이 쓰는 명령은 쓰지 말라고 일러 두면, 자원이 바닥나지 않는 선에서 최대한 많이 동시에 돌릴 수 있습니다.
깊이 있는 조사와 검증
Claude Code에는 동적 워크플로를 쓰는 조사 스킬(/deep-research)이 들어 있습니다. 웹 검색을 여러 갈래로 나눠 돌리고 출처를 가져온 다음, 그 주장을 반대편에서 검증한 뒤 출처가 달린 보고서로 합칩니다. 웹 검색에만 쓸 필요도 없습니다. 슬랙에 흩어진 대화로 현황 보고서를 만들거나, 코드베이스를 깊게 살펴 어떤 기능이 어떻게 돌아가는지 조사하는 데도 쓸 수 있습니다.
거꾸로 이미 있는 보고서를 검증할 때는 한 에이전트가 보고서 속 사실 주장을 모두 뽑아냅니다. 그러면 주장 하나마다 서브에이전트가 붙어 자세히 확인합니다. 원하면 각 확인 결과 뒤에 출처가 믿을 만한지 따지는 에이전트를 하나 더 둘 수도 있습니다.
1,000개 넘는 항목 정렬하기
고객 문의를 버그 심각도 순으로 늘어놓는 것처럼, 질적인 기준으로 많은 항목을 정렬해야 할 때가 있습니다. 1,000줄이 넘는 목록을 지시문 하나에 넣으면 품질이 떨어지고 애초에 컨텍스트 창에 다 들어가지도 않습니다.
이럴 때는 토너먼트를 엽니다. 비교 한 번마다 새 에이전트를 붙여 두 항목씩 맞대결시킵니다. 원문은 점수를 매기는 것보다 둘을 비교해 고르는 판단이 더 믿을 만하다고 설명합니다.
대진표는 정해진 프로그램 흐름이 들고 있고 컨텍스트 창에는 현재 순위만 남습니다. 버킷별로 나눠 동시에 순위를 매긴 뒤 합치는 방법도 있습니다.
규칙 지키게 만들기
Claude가 자꾸 놓치는 규칙이 있다면, 프로젝트 규칙 파일(CLAUDE.md)에 적어 두는 것만으로 부족할 수 있습니다. 이때는 규칙 하나당 검증 에이전트 하나를 붙여 확인하게 합니다. 그다음 깐깐한 회의론자 역할의 에이전트가 지적 사항을 다시 읽어 잘못된 경보를 걸러냅니다.
방향을 반대로 잡으면 최근 작업 기록과 코드 리뷰 의견에서 사용자가 반복해서 고치는 내용부터 찾아냅니다. 여러 에이전트가 이를 묶은 다음, 후보마다 "이 규칙이 있었다면 실제 실수를 막았을까?"를 반대편에서 검증합니다. 살아남은 것만 CLAUDE.md 규칙으로 정리합니다.
원인 찾기
문제의 원인을 찾을 때는 서로 독립된 가설을 여러 개 세우고 시험하는 편이 좋습니다. 그런데 한 컨텍스트 창 안에서만 일하면 앞서 말한 자기 결과 편들기에 빠질 수 있습니다. 워크플로는 이 문제를 구조적으로 막습니다. 로그, 파일, 데이터처럼 서로 겹치지 않는 증거를 각각 다른 에이전트에게 주고 가설을 세우게 하기 때문입니다.
그렇게 나온 가설은 검증하는 쪽과 반박하는 쪽으로 이뤄진 패널 앞에 섭니다. 원문은 이 방식이 코드 밖에서도 통한다고 말합니다. "3월 매출이 왜 떨어졌나" 같은 영업 분석이나 데이터 처리 실패 원인, 각종 사후 분석에도 쓸 수 있습니다.
쌓인 요청 분류하기와 격리 패턴
어느 팀에나 사람이 다 처리하지 못하는 고객 문의, 버그 제보, 밀린 요청 목록이 있습니다. 분류 워크플로는 항목마다 종류를 나누고 이미 등록된 것과 겹치는지 확인한 뒤 조치를 합니다. 직접 고쳐 보거나 사람에게 넘기는 식입니다.
여기서 쓸모 있는 패턴이 **격리(quarantine)**입니다. 외부에서 들어온 믿을 수 없는 글을 읽는 에이전트에게는 읽기 권한만 주고 중요한 조치는 맡기지 않습니다. 조치는 따로 있는 실행 담당 에이전트가 맡습니다. 이 에이전트는 원문 대신 읽기 담당이 정리한 요약만 봅니다.
우편물을 먼저 검사실에서 열어 보고 내용 요약만 결재 라인에 올리는 방식과 비슷합니다. 이 워크플로를 반복 실행 기능(/loop)과 묶으면 Claude가 계속 돌아가며 이 일을 처리합니다.
취향이 필요한 탐색, 평가, 모델 배정
디자인이나 이름 짓기처럼 정답보다 취향이 중요한 일에도 워크플로가 쓰입니다. 여러 해법을 탐색하게 하고 좋은 해법의 기준을 리뷰 에이전트에게 주면, 리뷰 에이전트가 기준을 만족했다고 판단할 때 작업이 끝납니다. 기준에 따라 토너먼트로 순위를 매기거나 고르는 방법도 있습니다.
가벼운 평가라면 별도 워크트리에서 에이전트들이 각자 결과를 내고 비교 담당 에이전트가 기준표에 맞춰 채점하게 합니다. 예를 들어 직접 만든 스킬을 특정 기준으로 평가하고 다듬을 수 있습니다.
모델 배정은 작업에 맞춘 분류 에이전트에게 맡겨도 됩니다. 어떤 모델을 쓸지 이 에이전트가 정합니다. "인증 모듈이 어떻게 돌아가는지 설명해 줘"라는 요청에 맞는 모델은 그 모듈의 파일 수와 코드 구조에 따라 달라집니다. 분류 에이전트가 먼저 이를 살펴본 뒤 예상 난도에 따라 Sonnet이나 Opus로 보냅니다.
원문 첫머리에는 이런 지시문 예시도 실려 있습니다. 50번에 한 번꼴로 실패하는 테스트를 재현한 다음 경쟁하는 가설을 세워 증거로 살아남는 하나가 나올 때까지 멈추지 말라는 요청이 있습니다. 사업 계획서를 투자자·고객·경쟁사 관점의 에이전트들이 각각 뜯어보게 하는 요청도 있습니다. 이력서 80장을 백엔드 직무 기준으로 순위를 매기고 상위 10명을 다시 확인하게 하는 예시도 보입니다. 명령줄 도구 이름 후보를 잔뜩 뽑아 토너먼트로 세 개를 고르는 요청까지 들어 있습니다.
동적 워크플로, 언제 쓰고 언제 아낄까
원문은 동적 워크플로가 아직 새로운 기능이고 모범 사례도 만들어지는 중이라고 분명히 밝힙니다. 워크플로는 토큰(AI가 처리하는 글자 조각 단위로, 사용량과 비용의 기준)을 더 많이 쓰는 편이라 복잡하고 가치가 큰 일에 가장 잘 맞습니다.
평소 하는 코딩 작업이라면 "이 일에 정말 더 많은 계산이 필요한가?"를 먼저 따져 보라고 권합니다. 대부분의 일반 코딩 작업에는 검토자 다섯 명으로 된 패널이 필요 없다고 덧붙입니다. 여러 에이전트를 쓸지 하나만 쓸지 정할 때도 같은 논리가 적용됩니다. 동시에 나눠 하고 역할을 전문화해서 얻는 이득이, 서로 조율하는 데 드는 비용보다 커야 합니다.
원문은 사용 팁도 몇 가지 정리해 두었습니다.
- 지시문은 자세하게: 앞에서 본 패턴들을 구체적으로 적어 줄수록 결과가 좋습니다. 큰 일에만 쓸 필요도 없어서 "빠른 워크플로(quick workflow)"를 요청해 어떤 가정 하나를 짧게 반박 검증하게 할 수도 있습니다.
- /goal, /loop와 함께 쓰기: 분류, 조사, 검증처럼 반복되는 워크플로는 /loop로 정해진 간격마다 돌리고 /goal로 반드시 채워야 할 완료 조건을 걸어 둡니다.
- 토큰 예산 정하기: "토큰 1만 개만 써"처럼 지시문에 예산을 적으면 그만큼으로 상한이 걸립니다.
- 저장하고 공유하기: 워크플로 메뉴에서 s 키를 누르면 저장됩니다. 저장한 워크플로는 ~/.claude/workflows 폴더에 두거나 스킬에 담아 나눌 수 있습니다. 스킬로 공유할 때는 워크플로 파일을 스킬 폴더에 넣고 스킬 설명 파일(SKILL.md)에서 가리키면 됩니다. 원문은 이때 워크플로를 그대로 돌려야 하는 대본보다 참고하는 틀로 여기라고 Claude에게 일러 두면 더 유연하게 쓸 수 있다고 조언합니다.
마치며
Claude Code 동적 워크플로는 한 AI가 긴 일을 혼자 짊어지게 두는 대신, 일에 맞는 팀 구성을 Claude가 직접 짜게 하는 기능입니다. 일을 덜 하고 멈추는 문제, 자기 결과를 편드는 문제, 목표가 흐려지는 문제를 각자 컨텍스트 창을 가진 서브에이전트와 검증 담당으로 풀어냅니다.
원문 글쓴이는 워크플로를 Claude Code를 넓히는 새 방법이자 아직 발견할 것이 많은 출발점으로 보라고 말합니다. Claude Code 동적 워크플로는 토큰을 더 쓰는 만큼, 한 번에 끝내기 어려운 복잡하고 중요한 일에서 먼저 시험해 보는 편이 좋겠습니다.
