문제는 하네스(harness, AI가 '다 했다'며 대충 끝내지 못하도록 절차와 증거를 강제하는 작업 골격)가 하나뿐이었다는 점이다. Claude Code(개발을 돕는 AI 도구)는 그동안 어떤 작업이든 '코딩용' 하네스 하나로 돌렸다. 이번 업데이트부터는 작업 종류에 맞는 하네스를 실행 순간 스스로 짠다. 그 업데이트가 정리한 6가지 작업 지휘 패턴과 3가지 실패 유형은 사실 새 개념이 아니다. 내 공통 설정(user-scope, 모든 프로젝트에 함께 적용되는 내 Claude Code 환경)이 이미 자동 검문 스크립트(hook)·규칙 파일(rule)·작업 절차(skill)로 똑같은 걸 굳혀 뒀다. 이번 업데이트는 그걸 고성능 모드(ultracode)를 켰을 때만, 실행 순간 자바스크립트로 짜는 지휘 코드로 격상한다. 그래서 내가 실제로 더한 것은 규칙 파일 하나와 비용 검문 스크립트 하나뿐이다. 나머지는 이미 있던 방어를 새 이름에 맞춰 연결한 일이다.
출처 — claude.com/blog · A harness for every task · Thariq Shihipar, Sid Bidasaria
결론부터 말하면, 새 도구는 하나도 늘리지 않는다. 이미 있는 두 명령 — 프로젝트 첫 세팅을 자동화하는 /init-project §12(그중 12번째 단계)와, 여러 전문 AI를 한 팀으로 굴리는 /team Phase 3(그중 3번째 단계)에는 이미 실행 절차를 통째로 갈아끼우는 연결점이 있다. 이 갈아끼우는 실행 절차가 바로 '워크플로우(workflow)'다. 평소에는 잠겨 있다가, 고성능 모드(ultracode)를 켜는 관문이 열릴 때에만 이 두 지점이 아래 6가지 패턴으로 펼쳐진다.
classify-and-act → workflow-cost-gate → team-deliver → .qa-evidence.json → task-quality-gate → push gates그동안 하네스는 '코딩용' 딱 하나뿐이었다. 이렇게 미리 고정해 둔 실행 방식을 정적 워크플로우라고 한다(예: 명령어 claude -p, 또는 개발자용 도구 모음 Agent SDK). 온갖 예외 상황을 다 받아내려다 보니 두루뭉술하고 범용적이다. 반면 Opus 4.8 + dynamic workflows는 그 작업에만 딱 맞는 전용 하네스를 실행 순간 자바스크립트로 직접 짠다. 하위 AI(subagent)를 새로 띄워 서로 조율하고, 어떤 모델을 쓸지·작업 폴더를 따로 격리할지(worktree)·중간 저장 지점부터 이어서 재개할지까지 스스로 정한다.
"모든 상황을 다 받아내는 범용 하네스"
"작업 전용 하네스를 실행 순간 스스로 작성"
여러 AI를 지휘·조율하는 방식을 블로그가 6가지 패턴으로 이름 붙였는데, 내가 이미 규칙과 스크립트로 굳혀 둔 것과 그대로 겹친다. 아래 각 카드 밑에 붙은 초록색 태그가 내 하네스에 이미 있는 구현이다. 동적 워크플로우는 그걸 실행 순간 자바스크립트로 다시 조립할 뿐, 없던 걸 새로 만드는 게 아니다.
classify-and-act먼저 분류 담당 AI가 '이건 어떤 종류의 작업인가'를 판정한다. 그다음 종류에 따라 서로 다른 담당 AI나 처리 방식으로 갈라 보낸다. 내 하네스에서는 이슈에 붙은 라벨과 키워드를 읽어 담당 AI를 정하는 코드가 이 일을 한다. 같은 입력이면 늘 같은 담당이 나오도록 결정론적으로 짜 뒀다.
assign_agent
fan-out-and-synthesize큰 작업을 여러 조각으로 쪼갠다. 각 조각을 담당 AI들이 동시에 병렬로 처리한다. 그런 다음 합류 지점에서 결과를 하나로 모은다. 내 하네스에서는 전문가 AI 여럿을 각자 격리된 작업 폴더(worktree)에서 동시에 돌리고, 끝나면 요약만 거둬 오는 규칙이 이 역할을 한다.
worktree-parallel-agents
만들어진 각 결과를 다른 AI가 다시 검사한다. 채점 기준표를 들고 일부러 흠을 잡아 반박하는 '적대적 검증'이다. 내 하네스에서는 다른 회사 모델(Codex)이 결과를 교차 검토한다. 검토자에게 구현자의 변명 없이 결과물만 보여 주는 규칙과, 코드를 올리기 직전 반박 검토를 강제하는 검문이 붙어 있다.
blind-validation-layer
adversarial-review gate
generate-and-filter여러 개의 후보를 먼저 만든다. 채점 기준으로 거르고 중복을 없앤다. 그중 품질 좋고 검증을 통과한 것만 남겨 돌려준다. 내 하네스에서는 외부 트렌드를 5가지 기준으로 채점해 남길지 버릴지 정하고, 자가 개선 절차가 같은 내용의 규칙을 하나로 합친다.
self-improve dedup
여러 AI가 같은 작업을 서로 다른 방식으로 풀며 경쟁한다. 둘씩 맞대결시켜 이긴 쪽을 가려낸다. 내 하네스에서는 자동 실험 루프가 후보 집단에서 부모를 골라 다음 세대를 만들고, 여러 모델로 꾸린 심사위원단이 둘씩 비교해 판정한다.
llm-council
pairwise judge
얼마나 걸릴지 모를 때 쓴다. 횟수를 미리 고정하지 않고, 멈춤 조건(더 나올 게 없거나 오류 0)에 닿을 때까지 AI를 계속 띄워 반복한다. 내 하네스에서는 막히면 13가지 전략을 바꿔 가며 계속 시도하는 수렴 루프와, 중간에 스스로 멈추지 못하게 못 박은 자동 실험 루프가 이 역할을 한다.
convergence-loop
autoresearch NEVER STOP
동적 워크플로우가 막으려는 세 가지 실패는, 내 하네스가 항상 켜진 바닥 방어(자동 검문 스크립트인 hook과 규칙 파일인 rule)로 이미 막고 있던 것이다. 여기에 고성능 모드(ultracode)를 켜면 선택 시 켜지는 방어(그때 새로 띄우는 검증 AI와 반복 루프)가 얹힌다. 그래서 두 겹으로 동시에 막는다. 카드마다 위 칸은 항상 켜진 방어의 규칙·검문 이름이고, 아래 칸은 워크플로우가 추가로 켜는 방어다.
여러 갈래로 나뉜 복잡한 작업을 절반쯤(50개 중 35개)만 해 놓고 "다 됐다"고 선언해 버리는 것. 내 하네스에서는 요구의 합격 조건으로만 완료를 인정하는 규칙, 증거 없는 완료 선언을 잡아내는 검문 스크립트, 수렴할 때까지 중간에 멈춰 묻지 못하게 하는 규칙이 이를 막는다.
acceptance-criteria (anti-Goodhart)premature-completion-detector hookconvergence-loop-no-mid-question자기가 낸 결과·판정을 스스로 편애하는 것. 특히 자기 답을 자기 기준으로 채점할 때 심하다. 내 하네스에서는 다른 회사 모델이 교차 검토하고, 검토자에게 구현자의 변명을 숨기는 규칙과, 실제로 뚫어 보이지 못한 취약점은 보고하지 못하게 하는 규칙이 이를 막는다.
blind-validation-layerproof-by-exploitation ("no exploit, no report")대화가 길어져 AI가 맥락을 요약·압축(compaction)한 뒤, 원래 목표와 '이건 하지 마라'는 금지 조건이 조금씩 사라지는 것. 내 하네스에서는 프로젝트 초기 설정 때 목표를 정규화해 받아 두는 강제 단계, 목표를 절차 계약에 묶어 두는 규칙, 계획을 파일에 남겨 대화가 압축돼도 되살리는 규칙이 이를 막는다.
/init-project Goal-normalized intake [HARD]hard-process-contract goal edgespersistent-file-based-planning바닥 방어라고 해서 전부 항상 켜져 있는 건 아니다. 자기편애·게으름 핵심 방어(adversarial-review · premature-completion)는 내 공통 설정(user-scope, 전 프로젝트 공통)에 심어 둔 검문 스크립트라 어느 프로젝트에서든 항상 켜져 있다. 반면 합격 조건·목표이탈을 막는 acceptance · goal-drift(task-quality-gate · hard-process-contract)는 특정 프로젝트에만 적용되는 project-scope — /init-project 명령으로 초기 설정을 한 프로젝트에만 깔린다(모든 곳에 자동으로 까는 건 일부러 안 해 뒀다). 초기 설정을 안 한 프로젝트는 공통 설정 방어만 받는다.
그리고 실제로 작업을 가로막을 수 있는 지점은 구조상 딱 한 곳, PreToolUse[Workflow](도구 실행 '직전' 검문) 뿐이다. 도구가 이미 실행된 뒤(실행 후 검문·종료 검문)에는 되돌려 막을 수 없다. 게다가 워크플로우는 백그라운드로 비동기 실행돼서, 일단 시작된 뒤에는 관찰·기록만 가능하다. 그래서 비용 검문을 실행 직전 한 곳에 몰아 둔 것이 맞다.
분석만 하고 끝내지 않고 실제 하네스에 반영했다. 6가지 패턴을 정리한 규칙 파일 하나를 새로 추가했다. 그리고 이미 워크플로우를 언급하던 작업 절차(skill) 두 개에 이 규칙을 서로 참조하도록 연결했다. 기존 것을 지우지 않고 덧붙이기만 했으므로 언제든 되돌릴 수 있다. 아래 목록의 배지 두 가지는 새로 만든 파일이라는 표시와, 무시할 수 없는 강제 검문(종료 코드 2로 실제 차단)이라는 표시다.
~/.claude/rules/dynamic-workflows-harness.md
NEW
skills/team/SKILL.md
—
3단계 워크플로우 설명에 패턴 목록 참조 링크 추가
skills/init-project/SKILL.md
—
12단계 자동 연결에 '병렬 분산 후 합치기' 패턴 명시 + 참조 추가
hooks/workflow-cost-gate.sh
NEW · HARD
settings.json
—
'워크플로우 실행 직전' 시점에 위 검문을 걸도록 설정 등록. 이것으로 게이트(gate, 조건을 못 채우면 통과를 막는 검문)가 켜진다
workflows/
NEW
team-deliver.js
—
멈춤 조건까지 반복하는 절차: 할 일 목록 선언 → 구현 → 완료 확인 → 품질검사 → 증거 남기기 → 완결성 검문(절반만 하고 "완료"라 우기는 걸 막음)
team-implement.js
—
fan-out-and-synthesize + adversarial verification
init-project-bootstrap.js
—
서로 무관한 생성 단계를 병렬로 돌린 뒤 합치기
가장 중요한 건 '언제 안 쓸지'다. 동적 워크플로우는 AI 계산 비용(토큰)을 더 많이 먹는다. 그래서 값어치 크고 복잡한 작업에만 쓴다. 즉 아무 때나 쓰지도, 고성능 모드일 때 무조건 쓰지도 않는다: /init-project·/team이 '이 작업이 워크플로우까지 갈 만한가'를 스스로 판단(1번 패턴, 분류 후 갈라 보내기)해서, 그럴 때만 Workflow로 간다(고성능 모드거나, 사용자가 직접 '워크플로우로'라 요청했거나, 대규모 코드 이전·구조 개편이거나, 여러 규칙을 한꺼번에 검증할 때 등). 그 밖의 평범한 작업은 기본값인 Agent 병렬 처리로 간다. 이 판단은 강제가 아닌 권고다. 다만 굳이 워크플로우로 넘어가려 하면 workflow-cost-gate.sh(무시 못 하는 강제 검문)가 6패턴 중 하나를 반드시 밝히게 막아서는 최후의 안전장치다.
"For regular coding tasks, ask: does it really need more compute? Most traditional coding tasks do not need a panel of 5 reviewers."
이 '아낄 땐 아끼자'는 원칙은 글로 적은 당부에 그치지 않는다. 실제로는 무시할 수 없는 검문 스크립트로 강제된다. workflow-cost-gate.sh(워크플로우 실행 직전에 발동하는 검문 스크립트)가 워크플로우 코드에 6패턴 중 하나가 안 적혀 있으면 exit 2(작업을 실제로 멈추는 신호)로 차단하고, 모든 호출을 기록 파일 .claude/logs/workflow.jsonl에 남긴다. 패턴을 못 대면 값비싼 워크플로우 대신 일반 병렬 처리로 보낸다. 이렇게 계산 낭비를 구조적으로 막는다. (임시로 끄려면 환경 변수 WORKFLOW_COST_GATE=0)
가장 근본적인 변화는 이거다. 실행이 설명 문서(markdown 글)가 아니라, 언제나 똑같이 도는 자바스크립트 제어 흐름이라는 점이다. 워크플로우 코드 자체가 작업의 전 과정을 강제한다. 문서(md)는 '이렇게 하라'고 부탁만 할 뿐이지만, 자바스크립트 반복 루프는 '안 하면 아예 끝나지 않는다'로 강제한다. 실제로 팀 작업 실행 파일 ~/.claude/workflows/team-deliver.js가 할 일 목록(각 항목은 고유번호·작업내용·합격조건으로 구성) args.tasks=[{id,spec,acceptance}]를 입력받아, 아래 5단계를 코드로 빈틈없이 닫는다.
log(declared N tasks: ...) 라는 기록으로 처리할 항목을 먼저 전부 적어 둔다. 빠뜨리면 기록에 그대로 남아 들통난다.
각 항목을 격리된 작업 폴더(worktree)에서 담당 AI가 하나도 빠뜨리지 않고 차례로 구현한다. 절차상 항목을 건너뛸 수 없다.
fan-out · worktree각 결과를 일부러 흠잡아 검증한다. 합격 조건을 들이대 반박하고, 숨기거나 빈껍데기로 만들어 통과하는 것 금지.
VERIFY_SCHEMA라는 검사 틀이 {done, evidence, criterion}(완료 여부·증거·기준)을 반드시 채우게 한다. 증거가 비면 미완료로 처리한다.
done && evidence(완료됐고 증거도 있음)가 아닌 항목은 incomplete[] 목록에 드러나고, all_done(전부 완료)은 모든 항목이 조건을 충족할 때에만 참이 된다.
T1 증거 ✓ · T2 증거 ✗ · T3 증거 ✓{ total: 3, completed: 2, incomplete: ["T2"], all_done: false }·agent 0 · 3msT2가 '대충 완료' 처리에서 구조적으로 차단된다. '50개 중 35개만 하고 완료'라 우기는 게으름(agentic laziness)을 이 반복 루프가 막는다워크플로우가 돌려주는 결과 목록 records[{id, done, evidence, criterion}] 속 증거를, 증거 파일 .qa-evidence.json 안의 acceptance_verified[] 항목으로 옮긴다. 그러면 프로젝트별 최종 검문 task-quality-gate.sh(강제·합격조건 검문)이 그 증거를 다시 검증한다. 선택할 때만 켜지는 천장 확장(동적 워크플로우)이 증거를 만들고, 항상 켜진 바닥 검문(정적 강제 게이트)이 그걸 받아 확인하는 순환이다. 글로만 적힌 규칙(completion-verification · acceptance-criteria)이 '이렇게 하라'고 부탁만 하던 것을, 이제 자바스크립트 반복 루프와 강제 검문이 '증거 없으면 못 끝낸다'로 실제로 막는다.
워크플로우를 짤 때 6가지 표준 패턴 이름(classify-and-act · fan-out-and-synthesize · loop-until-done 등)으로 바로 대응시킨다. 매번 지휘 방식을 새로 발명할 필요가 없어, 헤매는 데 드는 계산 비용(토큰)을 아낀다.
3가지 실패를 항상 켜진 검문 스크립트(hook)와 선택 시 켜지는 동적 워크플로우, 두 층에서 함께 막는다. 고성능 모드(ultracode)를 꺼 둬도 게으름·자기편애·목표이탈 방어는 그대로 유지된다.
/init-project→/team으로 이어질 때 목표를 넘겨주는 인수인계가, 동적 워크플로우를 재개할 때도 목표이탈을 막아 준다. 중간 저장 지점이 파일에 남아 있어, 대화가 압축돼도 목표를 되살릴 수 있다.
'정말 더 많은 계산이 필요한가?'라는 물음을 글로 적는 데서 그치지 않고 exit 2(작업 차단 신호)로 강제한다. workflow-cost-gate.sh가 패턴을 안 밝힌 워크플로우를 막는다. 평범한 코딩은 Agent 병렬 처리로, 값어치 큰 작업만 Workflow.
모든 워크플로우 호출이 .claude/logs/workflow.jsonl에 자동으로 남는다. 어떤 패턴을 어디서 썼는지 이 기록으로 알 수 있다. 이 숫자가 사용 추이 추적과, 권고 규칙을 강제 규칙으로 올릴지 판단하는 근거가 된다.