Claude Code는 이제 작업에 맞는 멀티 에이전트 하니스를 즉석에서 직접 작성하고 조율한다. 동적 워크플로가 어떻게 작동하는지, 그리고 그것을 최대한 끌어내는 패턴은 무엇인지 살펴본다.
지난주, 우리는 Claude Code에 동적 워크플로(dynamic workflows)를 공개했다. 이제 Claude는 당면한 작업에 맞춰 자신만의 하니스(harness)를 즉석에서 직접 짤 수 있다.
기본 Claude Code 하니스는 코딩을 염두에 두고 만들어졌다. 그런데 막상 들여다보면 많은 작업이 코딩 작업과 닮아 있어서, 다른 여러 종류의 일에도 쓸모가 있다. 하지만 최고 성능을 내려면 Claude Code 위에 별도의 맞춤 하니스를 얹어야 했던 작업군도 있다. 리서치(Research), 보안 분석(security analysis), 에이전트 팀(agent teams), 코드 리뷰(Code Review) 같은 것들이다.
워크플로를 쓰면 Claude Code 위에 하니스를 동적으로 만들어, Claude가 이런 문제들을 한층 자연스럽게 풀게 할 수 있다. 이렇게 만든 워크플로는 다른 사람과 공유하고 다시 쓸 수도 있다.
이 글에서는 내가 워크플로를 처음 써 보며 겪은 경험과 배운 점을 정리한다. 여러분이 워크플로를 제대로 활용하는 데 보탬이 되길 바란다. 다만 모범 사례는 아직 다듬어지는 중이라는 점을 염두에 두자. 동적 워크플로는 대체로 토큰을 더 많이 쓰며, 복잡하고 가치가 큰 작업에 가장 잘 맞는다.
예시 프롬프트
기술적인 세부로 들어가기 전에, 워크플로로 무엇을 할 수 있을지 감이 잡히도록 예시 프롬프트 몇 개부터 소개한다.
- "이 테스트가 50번에 한 번꼴로 실패한다. 이를 재현하는 워크플로를 짜라. 경쟁하는 여러 가설을 세우고, 증거를 견뎌 내는 가설 하나가 남을 때까지 멈추지 마라."
- "워크플로를 써서 내 최근 세션 50개를 훑고, 내가 반복해서 바로잡는 부분을 캐낸 다음, 자주 반복되는 것들을
CLAUDE.md규칙으로 만들어라." - "워크플로로 지난 6개월간 Slack의 #incidents를 파헤쳐서, 아무도 티켓을 올리지 않은 채 되풀이되는 근본 원인을 찾아라."
- "내 사업 계획서를 가지고, 투자자·고객·경쟁사 각각의 관점에서 여러 에이전트가 그것을 물고 뜯는 워크플로를 돌려라."
- "여기 이력서 80장이 든 폴더가 있다. 워크플로로 백엔드 직무에 맞게 순위를 매기고 상위 10명을 다시 검증하라. 평가 기준은 AskUserQuestion 도구로 나를 인터뷰해 정하라."
- "이 CLI 도구에 붙일 이름이 필요하다. 워크플로로 후보를 잔뜩 브레인스토밍한 뒤 토너먼트를 벌여 상위 3개를 뽑아라."
- "워크플로를 써서 우리 User 모델을 모든 곳에서 Account로 이름을 바꿔라."
- "내 블로그 글 초안을 훑으면서 모든 기술적 주장을 워크플로로 코드베이스와 대조해 검증하라. 틀린 내용은 절대 내보내고 싶지 않다."
동적 워크플로는 어떻게 작동하는가
동적 워크플로는 자바스크립트 파일 하나를 실행한다. 이 파일에는 서브에이전트(subagents)를 띄우고 조율하는 데 쓰는 특수 함수 몇 개가 들어 있다.
그림 1: 워크플로의 핵심 함수들. agent()는 서브에이전트 하나를 띄운다. parallel()은 여러 작업을 한꺼번에 펼친 뒤 모두 끝날 때까지 기다리는 배리어 역할을 한다. pipeline()은 각 항목을 모든 단계로 흘려보내되 배리어 없이 처리한다. 에이전트마다 스키마(검증된 JSON 출력), 모델(opus·sonnet·haiku), 격리 방식(worktree 또는 remote), 에이전트 유형을 지정할 수 있다.
동적 워크플로에는 JSON, Math, Array 같은 표준 자바스크립트 함수도 함께 들어 있어 데이터를 처리하는 데 쓸 수 있다.
특히 알아 두면 좋은 점이 있다. 동적 워크플로는 각 에이전트가 어떤 모델을 쓸지, 또 서브에이전트를 각자의 worktree에서 돌릴지도 직접 정한다. 덕분에 Claude는 필요한 지능 수준과 격리 수준을 골라 쓴다.
워크플로가 도중에 끊겨도 — 예컨대 사용자가 멈추거나 터미널을 종료해도 — 세션을 다시 열면 워크플로는 멈췄던 자리부터 이어서 진행한다.
동적 워크플로가 필요한 이유
기본 Claude Code 하니스에 어떤 작업을 시키면, 같은 컨텍스트 윈도우 안에서 계획과 실행을 동시에 해내야 한다. 많은 코딩 작업에는 이 방식이 무척 잘 통한다. 하지만 오래 걸리거나, 대규모로 병렬화되거나, 고도로 구조화되었거나, 적대적인 성격을 띤 작업에서는 무너질 수 있다.
Claude가 하나의 컨텍스트 윈도우 안에서 복잡한 작업을 오래 붙들고 있을수록 몇 가지 특정한 실패 양상에 더 취약해지기 때문이다.
**에이전트형 게으름(Agentic laziness)**은 Claude가 여러 부분으로 이뤄진 까다로운 작업을 끝마치기 전에 멈추고, 일부만 진행한 채 다 했다고 선언하는 경우를 가리킨다. 예를 들어 보안 리뷰에서 50개 항목 가운데 35개만 처리하고 마는 식이다.
**자기 선호 편향(Self-preferential bias)**은 Claude가 자신의 결과나 발견을 더 좋게 보려는 경향을 말한다. 특히 그 결과를 평가 기준에 비추어 검증하거나 판정하라고 시켰을 때 두드러진다.
**목표 표류(Goal drift)**는 여러 턴을 거치며 원래 목표에 대한 충실도가 조금씩 떨어지는 현상을 가리킨다. 특히 컴팩션(compaction) 이후에 심해진다. 요약 단계마다 정보가 조금씩 새어 나가므로, 예외 상황 요구사항이나 "X는 하지 마라" 같은 제약이 사라질 수 있다.
워크플로를 만들면 각자의 컨텍스트 윈도우와, 집중되고 격리된 목표를 가진 별도의 Claude 서브에이전트들을 조율함으로써 이런 문제에 맞설 수 있다.
동적 워크플로 vs 정적 워크플로
여러분은 예전에 Claude Agent SDK나 claude -p로 여러 Claude Code 인스턴스를 한데 묶어 조율하는 정적 워크플로를 만들어 봤을지 모른다.
하지만 정적 워크플로는 모든 예외 상황에서 작동해야 하므로 대체로 더 일반적(generic)일 수밖에 없다. Claude Opus 4.8과 동적 워크플로 덕분에, 이제 Claude는 여러분의 용도에 딱 맞는 맞춤 하니스를 직접 짤 만큼 똑똑해졌다.
그림 2: "결제 서비스를 새 공급자로 옮겨야 할까?"라는 똑같은 질문을 두고, 정적 하니스는 "웹 검색 5건으로 바꾸고 → 상위 결과를 가져와 → 검증하고 → 요약"하는 일반적인 리서치 보고서를 낸다. 반면 동적 워크플로는 우리 결제 코드(billing/, webhooks/, taxes/)를 직접 읽고, 각 기능을 새 공급자의 문서와 대조하며, 우리 거래량 기준으로 가격을 따져 보고, 이전을 반대하는 악마의 변호인(devil's advocate)까지 세워 구체적인 권고를 내놓는다.
동적 워크플로를 쓸 때 도움이 되는 패턴
동적 워크플로는 그냥 Claude에게 하나 만들어 달라고 하거나, 트리거 단어인 "ultracode"를 써서 Claude Code가 워크플로를 만들게 하면 바로 쓸 수 있다.
다만 동적 워크플로가 어떻게 돌아가는지 머릿속에 모델을 세워 두면, 언제 그것을 써야 할지, 그리고 프롬프트로 Claude를 어떻게 유도할지 더 잘 가늠하게 된다.
Claude가 워크플로를 만들 때 쓰거나 서로 조합하는 흔한 패턴이 몇 가지 있다.
그림 3: 여섯 가지 워크플로 패턴 — 분류 후 실행(Classify-and-act), 펼치고 종합하기(Fan-out-and-synthesize), 적대적 검증(Adversarial verification), 생성 후 거르기(Generate-and-filter), 토너먼트(Tournament), 끝날 때까지 반복(Loop until done).
분류 후 실행(Classify-and-act)
분류 에이전트로 작업 유형을 판단한 다음, 그 유형에 따라 서로 다른 에이전트나 동작으로 라우팅한다. 또는 마지막에 분류기를 두어 출력을 결정하게 할 수도 있다.
펼치고 종합하기(Fan-out-and-synthesize)
작업을 여러 작은 단계로 쪼개고, 각 단계마다 에이전트를 하나씩 돌린 뒤 그 결과를 종합한다. 작은 단계가 아주 많거나, 각 단계가 서로 간섭하거나 오염되지 않도록 저마다 깨끗한 컨텍스트 윈도우에서 돌아가는 편이 나을 때 특히 유용하다. 종합 단계는 배리어(barrier)다. 펼쳐 놓은 모든 에이전트를 기다렸다가, 그들의 구조화된 출력을 하나의 결과로 합친다.
적대적 검증(Adversarial verification)
띄운 에이전트마다 별도의 에이전트를 하나씩 더 띄워, 그 출력을 평가 기준이나 요건에 비추어 적대적으로 검증한다.
생성 후 거르기(Generate-and-filter)
어떤 주제로 아이디어를 여럿 생성한 다음, 평가 기준이나 검증으로 거르고, 중복을 쳐 내, 가장 품질이 높고 검증을 통과한 아이디어만 남겨 돌려준다.
토너먼트(Tournament)
일을 나누는 대신, 에이전트들이 그 일을 두고 경쟁하게 한다. N개의 에이전트를 띄워 각자 다른 접근으로 같은 작업을 시도하게 한다. 그런 뒤 판정 에이전트가 프롬프트나 모델을 동원해 둘씩 맞붙는 방식으로 결과를 견주어, 승자가 가려질 때까지 진행한다.
끝날 때까지 반복(Loop until done)
작업량을 미리 알 수 없는 작업이라면, 정해진 횟수만큼 도는 대신 멈춤 조건이 충족될 때까지(새 발견이 없거나, 로그에 더는 오류가 없을 때까지) 에이전트를 계속 띄운다.
활용 사례
Claude Code에게 동적 워크플로를 언제 어떻게 만들어 달라고 할지 창의적으로 떠올려 보자. 내가 보기엔 워크플로가 기술적이지 않은 일에서 오히려 더 쓸모 있을 때도 있었다.
마이그레이션과 리팩터링
Bun은 워크플로를 써서 Zig에서 Rust로 다시 작성됐다. 그 과정이 어떻게 이뤄졌는지는 Jarred의 X 스레드에서 더 읽어 볼 수 있다.
핵심은 작업을 처리해야 할 단위들의 연속으로 쪼개는 것이다. 예컨대 호출 지점(callsite), 실패하는 테스트, 모듈 같은 것들이다. 모든 수정 건마다 worktree에서 서브에이전트를 하나씩 띄워 고치게 하고, 또 다른 에이전트가 적대적으로 검토한 뒤 병합한다. 자원을 많이 잡아먹는 명령은 쓰지 말라고 에이전트에게 일러두면, 머신의 자원이 바닥나지 않으면서도 병렬화를 최대로 끌어올릴 수 있다.
딥 리서치
우리는 Claude Code 안에서 동적 워크플로를 쓰는 딥 리서치 스킬(/deep-research)을 공개했다. 구체적으로는 웹 검색을 펼치고, 출처를 가져오고, 그 주장을 적대적으로 검증한 뒤, 출처가 달린 보고서로 종합한다.
이런 식의 리서치는 웹 검색에만 쓰는 게 아니다. 예를 들어 Slack의 맥락을 모아 상태 보고서를 작성하게 하거나, 코드베이스를 깊이 파고들어 어떤 기능이 어떻게 동작하는지 조사하게 할 수도 있다.
딥 검증
반대로, 어떤 보고서가 참조하는 모든 사실 주장을 일일이 확인하고 출처를 달고 싶다면, 한 에이전트가 모든 사실 주장을 식별하게 한 뒤 각 주장마다 서브에이전트를 띄워 하나하나 자세히 확인하는 워크플로를 만들면 된다. 검증 에이전트를 따로 두어, 출처를 확인한 서브에이전트가 정말 양질의 출처를 댔는지 점검하게 할 수도 있다.
그림 4: 딥 검증 워크플로. 주장 추출기(claim extractor)가 보고서에서 모든 사실 주장을 식별하면, 주장 검사기(claim checker)들이 각 주장을 출처와 대조해 검증한다. 선택적으로 출처 감사자(source auditor)가 그 출처가 양질인지까지 점검한 뒤, 검증된 보고서로 모인다.
정렬(Sorting)
Claude Code가 잘 평가할 법한 어떤 정성적 기준으로 항목을 정렬하고 싶을 때가 있다. 예컨대 버그 심각도순으로 정렬한 지원 티켓 같은 것이다. 하지만 1,000개가 넘는 행을 한 프롬프트로 정렬하려 들면 품질이 떨어지고 컨텍스트에도 들어가지 않는다. 대신 토너먼트를 돌리거나, 둘씩 비교하는 에이전트들의 파이프라인을 쓰거나(절대 점수보다 비교 판단이 더 믿을 만하다), 병렬로 버킷에 나눠 순위를 매긴 뒤 합친다. 각 비교가 저마다 하나의 에이전트이므로, 결정론적 루프가 대진표를 쥐고 있고 컨텍스트에는 진행 중인 순서만 남는다.
그림 5: 정렬을 토너먼트로 처리하는 방식. 1,000개 항목을 라운드마다 둘씩 맞붙여 비교하되 각 비교를 새 에이전트(fresh agent)가 맡고, 승자끼리 다시 겨루어 최종 정렬된 목록을 만든다.
기억과 규칙 준수
Claude가 CLAUDE.md에 넣어 두어도 자꾸 놓치거나 지키기 힘들어하는 규칙 묶음이 있다면, 검증 에이전트가 반드시 확인해야 할 규칙 목록을 담은 워크플로를 만들되 규칙 하나당 검증 에이전트를 하나씩 둔다. 회의적인 페르소나(skeptic persona)를 가진 서브에이전트를 만들어 그 규칙들이 타당한지 검토하게 하면 거짓 양성(false positive)이 지나치게 많아지는 걸 막는 데 도움이 된다.
반대 방향도 통한다. 최근 세션과 코드 리뷰 코멘트에서 내가 반복해서 바로잡는 부분을 캐내고, 병렬 에이전트로 묶은 다음, 후보 하나하나를 적대적으로 검증하고(이 규칙이 있었다면 실제 실수를 막았을까?), 살아남은 것들을 다시 CLAUDE.md로 추려 넣는다.
그림 6: diff(+142줄, −87줄)를 두고 규칙마다 검증 에이전트를 하나씩 둔다. 각 규칙(예: "금액은 정수 센트로, 부동소수점 금지")을 깨끗한 컨텍스트에서 점검해 위반(line 42, line 90)인지 통과(clean)인지 표시하고, 회의자(Skeptic)가 그 표시를 다시 읽어 진짜 위반인지 거짓 양성인지 가린 뒤 확정된 위반만 남긴다.
근본 원인 조사
디버깅은 서로 독립적인 가설을 여러 개 세워 검증할 때 가장 잘 풀린다. 하지만 컨텍스트 윈도우 하나만 쓰면 Claude가 자기 선호 편향에 빠질 수 있다.
워크플로는 서로 겹치지 않는 증거에서 가설을 세우는 에이전트들을 띄워 이를 구조적으로 막을 수 있다. 예를 들어 로그, 파일, 데이터를 각각 맡는 별도 에이전트를 둔다. 그러면 각 가설은 검증자와 반박자로 이뤄진 패널의 심사를 받는다.
이는 코드에만 해당하는 이야기가 아니다. 워크플로는 영업(3월에 매출이 왜 떨어졌나?), 데이터 엔지니어링(이 파이프라인은 왜 실패했나?), 또는 어떤 사후 분석(post-mortem)에도 쓸 수 있다.
대규모 분류(Triaging at scale)
어느 팀에나 사람이 다 처리할 수 없는 지원 큐, 버그 리포트, 혹은 또 다른 형태의 밀린 작업이 있다.
분류 워크플로는 각 항목을 분류하고, 이미 추적 중인 것과 대조해 중복을 제거하며, 조치를 취한다. 여기서 조치란 수정을 시도하거나, 사람 사용자에게 에스컬레이션하는 것을 뜻할 수 있다.
분류 워크플로에 유용한 패턴 하나는 격리(quarantine)다. 신뢰할 수 없는 공개 콘텐츠를 읽는 에이전트가 높은 권한이 필요한 조치를 취하지 못하게 막고, 그런 조치는 정보를 바탕으로 행동하는 담당 에이전트가 대신 수행하게 하는 방식이다.
분류 워크플로를 /loop과 짝지으면 Claude가 이 일을 끊임없이 수행하게 만들 수 있다.
그림 7: 격리 패턴을 적용한 분류 워크플로. 신뢰할 수 없는 백로그(지원 티켓, 버그 리포트, 사용자 피드백)는 읽기 전용 도구만 가진 격리(QUARANTINE) 영역의 리더 에이전트들이 항목별로 읽고 분류·중복 제거한 뒤 구조화된 요약만 내보낸다. 그 요약은 높은 권한 도구를 가진 신뢰(TRUSTED) 영역의 행동 에이전트(actor agent)에게 넘어가, 고칠 수 있으면 PR을 열고 아니면 사람에게 에스컬레이션한다. /loop과 묶으면 이를 계속 돌릴 수 있다.
탐색과 취향
워크플로는 어떤 해법을 두고 여러 접근을 탐색할 때, 특히 디자인이나 이름 짓기처럼 취향이 개입되어 평가 기준이 있으면 더 나아지는 경우에 쓸모가 있다.
Claude에게 여러 해법을 탐색해 보라고 하고, 검토 에이전트에게는 좋은 해법이란 어떤 것인지 평가 기준을 준다. 검토 에이전트가 그 기준을 충족했다고 판단하면 작업이 끝난다. 해법들은 평가 기준에 따라 토너먼트로 순서를 매기거나 골라낼 수도 있다.
평가(Evals)
특정 작업에 대한 가벼운 평가를 돌릴 수도 있다. worktree에서 별도 에이전트를 띄워 결과를 만들고, 다시 비교 에이전트를 띄워 그 구체적인 출력들을 평가 기준에 비추어 비교·채점하게 하는 식이다. 예를 들어 직접 만든 스킬을 특정 기준에 비추어 평가하고 다듬을 수 있다.
모델·지능 라우팅
작업에 맞춰 어떤 모델을 쓸지 결정하는 분류 에이전트를 만든다. 작업에 도구 호출이 많이 따를 때, 실행에 앞서 한번 조사해 두면 그 작업에 가장 알맞은 모델을 미리 가려낼 수 있다.
예를 들어 "인증 모듈이 어떻게 동작하는지 설명하라"는 작업에 가장 알맞은 모델은, 인증 모듈에 파일이 몇 개나 있는지와 코드베이스의 생김새에 따라 달라진다. 분류 에이전트가 이를 조사한 뒤, 예상되는 작업 복잡도에 따라 Sonnet이나 Opus로 라우팅할 수 있다.
동적 워크플로를 쓰지 말아야 할 때
워크플로는 새로운 기능이다. 비범한 성과를 내는 사례가 많지만, 모든 작업에 필요한 건 아니며 토큰을 훨씬 많이 쓰게 될 수도 있다.
워크플로는 지금까지 시도해 본 적 없는 방식으로 Claude Code를 밀어붙일 때 창의적으로 쓰는 것이 가장 좋다. 일반적인 코딩 작업이라면 스스로에게 물어보자. 정말로 더 많은 연산이 필요한가? 예를 들어 전통적인 코딩 작업 대부분은 5명짜리 검토자 패널이 필요하지 않다.
동적 워크플로를 만들 때의 팁
프롬프팅
앞서 설명한 구체적인 기법들을 활용해 동적 워크플로를 세밀하게 프롬프팅하면 가장 좋은 결과가 나온다.
워크플로는 큰 작업에만 쓰는 게 아니다. 모델에게 "빠른 워크플로(quick workflow)"를 쓰라고 시킬 수도 있다. 예를 들어 어떤 가정을 빠르게 적대적으로 검토하게 만들 수 있다.
/goal 및 /loop과 조합하기
분류, 리서치, 검증처럼 반복할 수 있는 워크플로라면 /loop과 짝지어 일정 간격으로 돌리고, /goal로 반드시 충족해야 할 완료 요건을 정해 두자.
토큰 사용량 예산
동적 워크플로에 명시적인 토큰 사용량 예산을 정해, 한 작업이 토큰을 얼마나 쓸지 제한할 수 있다. "토큰 1만 개를 써라"처럼 예산을 프롬프트로 주면 그 값이 상한으로 설정된다.
동적 워크플로 저장 및 공유
워크플로 메뉴에서 "s"를 누르면 워크플로를 저장할 수 있다. 이를 ~/.claude/workflows에 체크인하거나 스킬을 통해 배포할 수 있다.
그림 8: 워크플로 메뉴. 실행 중이거나 완료된 동적 워크플로들이 각각 사용한 에이전트 수·토큰·소요 시간과 함께 표시되며, "s"를 눌러 저장할 수 있다.
스킬로 공유하려면 자바스크립트 워크플로 파일을 스킬 폴더에 넣고 SKILL.MD에서 참조하면 된다. 좀 더 유연하게 하려면, 스킬 안의 워크플로를 그대로 실행해야 하는 스크립트가 아니라 템플릿으로 여기라고 Claude에게 일러두는 것이 좋다.
그림 9: 워크플로 파일을 스킬 폴더 안에 둔다. verify-claims.workflow.js 같은 워크플로 파일을 SKILL.md 바로 옆에 함께 담고 SKILL.md에서 참조하면, 그 폴더를 공유하기만 해도 스킬을 설치한 누구나 똑같은 워크플로를 실행하게 된다.
발견을 위한 새로운 출발점
워크플로는 Claude Code를 확장하는 유용한 새 방법이다. 나는 이것을 Claude로 여러분의 작업을 돕는 새로운 방식을 탐색하는 출발점으로 여기길 권한다. 워크플로를 가장 잘 쓰는 법에 관해서는 아직 알아낼 것이 많이 남아 있다. 여러분이 무엇을 발견하는지 알려 주길 바란다.
이 글은 Anthropic에서 Claude Code를 담당하는 기술 스태프 Thariq Shihipar와 Sid Bidasaria가 작성했다.