Claude Code(개발을 돕는 AI 도구)가 이제 작업 종류에 맞는 실행 방식을 그때그때 스스로 짠다. 이 실행 방식을 하네스(harness)라고 부른다 — 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가지 패턴으로 펼쳐진다.
그동안 하네스는 '코딩용' 딱 하나뿐이었다. 이렇게 미리 고정해 둔 실행 방식을 정적 워크플로우라고 한다(예: 명령어 claude -p, 또는 개발자용 도구 모음 Agent SDK). 온갖 예외 상황을 다 받아내려다 보니 두루뭉술하고 범용적이다. 반면 Opus 4.8 + dynamic workflows는 그 작업에만 딱 맞는 전용 하네스를 실행 순간 자바스크립트로 직접 짠다. 하위 AI(subagent)를 새로 띄워 서로 조율하고, 어떤 모델을 쓸지·작업 폴더를 따로 격리할지(worktree)·중간 저장 지점부터 이어서 재개할지까지 스스로 정한다.
"모든 상황을 다 받아내는 범용 하네스"
"작업 전용 하네스를 실행 순간 스스로 작성"
여러 AI를 지휘·조율하는 방식을 블로그가 6가지 패턴으로 이름 붙였는데, 내가 이미 규칙과 스크립트로 굳혀 둔 것과 그대로 겹친다. 아래 각 카드 밑에 붙은 초록색 태그가 내 하네스에 이미 있는 구현이다. 동적 워크플로우는 그걸 실행 순간 자바스크립트로 다시 조립할 뿐, 없던 걸 새로 만드는 게 아니다.
먼저 분류 담당 AI가 '이건 어떤 종류의 작업인가'를 판정한다. 그다음 종류에 따라 서로 다른 담당 AI나 처리 방식으로 갈라 보낸다.
큰 작업을 여러 조각으로 쪼갠다. 각 조각을 담당 AI들이 동시에 병렬로 처리한다. 그런 다음 합류 지점에서 결과를 하나로 모은다.
만들어진 각 결과를 다른 AI가 다시 검사한다. 채점 기준표를 들고 일부러 흠을 잡아 반박하는 '적대적 검증'이다.
여러 개의 후보를 먼저 만든다. 채점 기준으로 거르고 중복을 없앤다. 그중 품질 좋고 검증을 통과한 것만 남겨 돌려준다.
여러 AI가 같은 작업을 서로 다른 방식으로 풀며 경쟁한다. 둘씩 맞대결시켜 이긴 쪽을 가려낸다.
얼마나 걸릴지 모를 때 쓴다. 횟수를 미리 고정하지 않고, 멈춤 조건(더 나올 게 없거나 오류 0)에 닿을 때까지 AI를 계속 띄워 반복한다.
동적 워크플로우가 막으려는 세 가지 실패는, 내 하네스가 항상 켜진 바닥 방어(검문 스크립트hook·규칙 파일rule)로 이미 막고 있던 것이다. 여기에 고성능 모드(ultracode)를 켜면 선택 시 켜지는 방어(그때 새로 띄우는 검증 AI와 반복 루프)가 얹혀서 — 두 겹으로 동시에 막는다.
여러 갈래로 나뉜 복잡한 작업을 절반쯤(50개 중 35개)만 해 놓고 "다 됐다"고 선언해 버리는 것.
자기가 낸 결과·판정을 스스로 편애하는 것 — 특히 자기 답을 자기 기준으로 채점할 때 심하다.
대화가 길어져 AI가 맥락을 요약·압축(compaction)한 뒤, 원래 목표와 '이건 하지 마라'는 금지 조건이 조금씩 사라지는 것.
바닥 방어라고 해서 전부 항상 켜져 있는 건 아니다. 자기편애·게으름 핵심 방어(adversarial-review · premature-completion)는 내 공통 설정(user-scope, 전 프로젝트 공통)에 심어 둔 검문 스크립트라 어느 프로젝트에서든 항상 켜져 있다. 반면 합격 조건·목표이탈을 막는 acceptance · goal-drift(task-quality-gate · hard-process-contract)는 특정 프로젝트에만 적용되는 project-scope — /init-project 명령으로 초기 설정을 한 프로젝트에만 깔린다(모든 곳에 자동으로 까는 건 일부러 안 해 뒀다). 초기 설정을 안 한 프로젝트는 공통 설정 방어만 받는다.
그리고 실제로 작업을 가로막을 수 있는 지점은 구조상 딱 한 곳, PreToolUse[Workflow](도구 실행 '직전' 검문) 뿐이다. 도구가 이미 실행된 뒤(실행 후 검문·종료 검문)에는 되돌려 막을 수 없다. 게다가 워크플로우는 백그라운드로 비동기 실행돼서, 일단 시작된 뒤에는 관찰·기록만 가능하다. 그래서 비용 검문을 실행 직전 한 곳에 몰아 둔 것이 맞다.
분석만 하고 끝내지 않고 실제 하네스에 반영했다. 6가지 패턴을 정리한 규칙 파일 하나를 새로 추가했다. 그리고 이미 워크플로우를 언급하던 작업 절차(skill) 두 개에 이 규칙을 서로 참조하도록 연결했다. 기존 것을 지우지 않고 덧붙이기만 했으므로 언제든 되돌릴 수 있다.
가장 중요한 건 '언제 안 쓸지'다. 동적 워크플로우는 AI 계산 비용(토큰)을 더 많이 먹는다. 그래서 값어치 크고 복잡한 작업에만 쓴다. 즉 아무 때나 쓰지도, 고성능 모드일 때 무조건 쓰지도 않는다: /init-project·/team이 '이 작업이 워크플로우까지 갈 만한가'를 스스로 판단(classify-and-act)해서, 그럴 때만 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가 하나도 빠뜨리지 않고 차례로 구현한다 — 절차상 항목을 건너뛸 수 없다.
각 결과를 일부러 흠잡아 검증한다 — 합격 조건을 들이대 반박하고, 숨기거나 빈껍데기로 만들어 통과하는 것 금지.
VERIFY_SCHEMA라는 검사 틀이 {done, evidence, criterion}(완료 여부·증거·기준)을 반드시 채우게 한다 — 증거가 비면 미완료로 처리한다.
done && evidence(완료됐고 증거도 있음)가 아닌 항목은 incomplete[] 목록에 드러나고, all_done(전부 완료)은 모든 항목이 조건을 충족할 때에만 참이 된다.
워크플로우가 돌려주는 결과 목록 records[{id, done, evidence, criterion}] 속 증거를, 증거 파일 .qa-evidence.json 안의 acceptance_verified[] 항목으로 옮긴다. 그러면 프로젝트별 최종 검문 task-quality-gate.sh(강제·합격조건 검문)이 그 증거를 다시 검증한다. 선택할 때만 켜지는 천장 확장(동적 워크플로우)이 증거를 만들고, 항상 켜진 바닥 검문(정적 강제 게이트)이 그걸 받아 확인하는 순환이다. 글로만 적힌 규칙(completion-verification · acceptance-criteria)이 '이렇게 하라'고 부탁만 하던 것을, 이제 자바스크립트 반복 루프와 강제 검문이 '증거 없으면 못 끝낸다'로 실제로 막는다.
워크플로우를 짤 때 6가지 표준 패턴 이름(classify-and-act 등)으로 바로 대응시킨다. 매번 지휘 방식을 새로 발명할 필요가 없어, 헤매는 데 드는 계산 비용(토큰)을 아낀다.
3가지 실패를 항상 켜진 검문 스크립트(hook)와 선택 시 켜지는 동적 워크플로우, 두 층에서 함께 막는다. 고성능 모드(ultracode)를 꺼 둬도 게으름·자기편애·목표이탈 방어는 그대로 유지된다.
/init-project→/team으로 이어질 때 목표를 넘겨주는 인수인계가, 동적 워크플로우를 재개할 때도 목표이탈을 막아 준다. 중간 저장 지점이 파일에 남아 있어, 대화가 압축돼도 목표를 되살릴 수 있다.
'정말 더 많은 계산이 필요한가?'라는 물음을 글이 아니라 exit 2(작업 차단 신호)로 강제한다. workflow-cost-gate.sh가 패턴을 안 밝힌 워크플로우를 막는다 — 평범한 코딩은 Agent 병렬 처리로, 값어치 큰 작업만 Workflow.
모든 워크플로우 호출이 .claude/logs/workflow.jsonl에 자동으로 남는다 — 어떤 패턴을 어디서 썼는지. 이 숫자가 사용 추이 추적과, 권고 규칙을 강제 규칙으로 올릴지 판단하는 근거가 된다.