Claude Code 동적 워크플로우와 하네스 오케스트레이션

오케스트레이션 코드까지 에이전트가 작성한다

2026년 5월 28일 Anthropic은 Claude Code 2.1.154와 함께 동적 워크플로우(Dynamic Workflows)를 공식 출시했다. 개발자가 미리 오케스트레이션 스크립트를 작성하던 방식과 달리, Claude가 태스크 설명에 맞춰 실행용 하네스를 즉석에서 만들고 수십~수백 개의 서브에이전트를 병렬로 운용하는 구조다.

Bun 창시자 Jarred Sumner는 이 기능을 사용해 약 100만 줄의 Zig 코드를 Rust로 포팅했다. 기존 테스트 스위트를 통과시키는 조건을 포함한 작업이었으며, 완료까지 걸린 시간은 6일이었다. 종래에는 팀 단위로 분기 이상이 필요했던 규모의 작업을 단일 에이전트 세션에서 처리한 사례다.

동적 워크플로우의 핵심은 간단하다. 사용자가 하네스를 직접 만드는 대신 성공 기준과 제약 조건을 정의하면, Claude Code가 해당 태스크에 맞는 JavaScript 오케스트레이션 스크립트를 작성한다. 백그라운드 런타임은 이 스크립트를 실행하면서 서브에이전트의 생성, 병렬 처리, 검증, 결과 집계를 담당한다.

기존 서브에이전트 운용과 비교하면 실행 제어와 상태 보관 위치가 달라진다.

구분	기존 서브에이전트 방식	동적 워크플로우
오케스트레이션 주체	Claude(컨텍스트 창 내)	JavaScript 스크립트(런타임)
중간 결과 저장 위치	Claude 컨텍스트 창	스크립트 변수
병렬 실행 한계	컨텍스트 창 크기에 제한	최대 16개 동시, 총 1,000개
하네스 작성 주체	개발자 직접 작성	Claude 자동 생성
세션 반응성	오케스트레이션 중 차단	백그라운드 실행, 세션 유지

프롬프트와 컨텍스트를 넘어 실행을 설계한다

하네스 엔지니어링(Harness Engineering)은 2026년에 급부상한 AI 개발 패러다임이다. 프롬프트 엔지니어링이 모델에 전달할 언어를 다루고 컨텍스트 엔지니어링이 추론에 사용할 지식을 구성한다면, 하네스 엔지니어링은 에이전트가 작업을 수행하는 방식 자체를 통제한다.

프롬프트 엔지니어링의 대상은 지시문, 형식 제약, 예시처럼 즉각적인 응답에 영향을 주는 요소다. 다만 버전 관리와 팀 표준화가 어렵고, 출력 형식이 일정해 보여도 팩트 드리프트가 숨어드는 무음 실패(silent failure)가 발생할 수 있다.

컨텍스트 엔지니어링은 검색 문서, 대화 이력, 사용자 선호도, 사용 가능한 도구, 구조화된 출력 형식을 관리한다. 이 관점에서는 컨텍스트 창을 무한한 지식 저장소가 아니라 용량이 제한된 작업 메모리로 취급한다.

하네스 엔지니어링의 범위는 더 넓다. 작업을 어떤 단위로 나눌지, 어떤 서브에이전트를 생성할지, 각 에이전트에 어떤 도구를 줄지 결정한다. 여기에 출력 검증, 단계별 모델 배치, 상태 보존, 오류 복구까지 포함된다.

이 관계는 프롬프트 엔지니어링 ⊂ 컨텍스트 엔지니어링 ⊂ 하네스 엔지니어링으로 볼 수 있다. Princeton 연구에 따르면 하네스 구성만으로도 기본 설정 대비 해결률이 64% 향상될 수 있다.

⤢✕

요청에서 결과 집계까지 이어지는 실행 구조

사용자가 태스크를 전달하면 Claude는 먼저 요청을 분석하고 실행 계획을 세운다. 이어서 태스크에 특화된 JavaScript 하네스를 생성한다. 백그라운드 런타임이 하네스를 실행하면 작업 분해와 서브에이전트 팬아웃이 시작되고, 각 결과는 검증을 거쳐 하나의 결과로 집계된다. 이 과정에서도 사용자 세션의 반응성은 유지된다.

⤢✕

이때 하네스가 맡는 책임은 작업 분할(Task Decomposition), 서브에이전트 스폰(Agent Fanout), 도구 할당(Tool Assignment), 중간 상태 관리(State Management), 결과 검증(Verification), 오류 복구(Error Recovery)다.

큰 태스크는 병렬화할 수 있는 단위로 분리되고, 각 단위의 특성에 맞는 에이전트가 생성된다. 필요한 도구 역시 에이전트별로 독립 배정된다. 중간 결과는 Claude의 컨텍스트 창이 아니라 스크립트 변수에 남으며, 품질 기준을 통과한 출력만 최종 집계로 이동한다. 실패한 서브에이전트가 있으면 재시도하거나 다른 경로를 실행한다.

실행당 에이전트는 최대 16개까지 동시에 동작하며, CPU 코어 수가 낮은 머신에서는 자동 축소된다. 전체 실행에서 생성할 수 있는 에이전트 한계는 1,000개다. 지원 버전은 Claude Code v2.1.154 이상이고, 모든 유료 Claude Code 플랜에서 사용할 수 있다. 지원 인프라는 Anthropic API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry다.

태스크 구조에 맞춰 오케스트레이션 패턴을 고른다

팬아웃(Fan-out)은 서로 독립적인 작업을 동시에 실행한 뒤 결과를 모으는 스캐터·개더 방식이다. 보안 감사에서 9개의 서브에이전트가 서로 다른 소스를 스캔하고, 결과를 영향도순으로 정렬된 다이제스트로 합치는 구성이 이에 해당한다. 코드베이스 전체의 버그 탐색, 멀티소스 리서치, 500파일 마이그레이션, 보안 감사처럼 작업 단위를 분리하기 쉬운 태스크에 맞는다.

파이프라인(Pipeline)은 이전 단계의 출력이 다음 단계의 입력이 되는 순차 체인이다. 분석→설계→구현→검증처럼 단계 사이에 명확한 의존성이 있는 리팩터링에 사용할 수 있다.

디베이트(Debate)는 복수의 에이전트가 같은 문제를 독립적으로 다룬 뒤 서로의 결과를 검토하고 비판하도록 구성한다. 아키텍처 결정, 리스크가 높은 계획 수립, 코드 리뷰처럼 단일 관점에 의존하기 어려운 태스크에 적합하다.

슈퍼바이저(Supervisor)는 상위 에이전트가 전문 역할을 맡은 하위 에이전트를 감독하고 필요하면 작업을 다시 배정하는 계층형 패턴이다. 복합 기능 개발이나 멀티팀 코드베이스 통합처럼 조정 책임이 필요한 작업에 사용할 수 있다.

⤢✕

컨텍스트와 상태를 분리해 다룬다

모든 서브에이전트에 전체 대화 이력을 넘기면 토큰 비용이 크게 늘어난다. 따라서 하네스는 각 에이전트가 맡은 작업에 필요한 정보만 골라 전달하고, 에이전트별 컨텍스트 예산을 제어해야 한다.

상태 격리도 필요하다. 컨텍스트 창 안에서 오케스트레이션하면 여러 에이전트의 상태가 뒤섞일 수 있다. 동적 워크플로우는 중간 결과를 스크립트 변수로 관리해 작업별 상태를 분리한다.

최종 집계 전에 두는 검증 게이트는 출력이 품질 기준을 충족하는지 판정한다. 기준을 통과하지 못한 출력은 재시도 큐로 보내거나 폴백 경로에서 다시 처리한다. 하나의 서브에이전트가 실패해도 성공한 결과는 보존되므로 전체 워크플로우가 함께 중단되는 상황을 피할 수 있다.

모델 배치 역시 하네스의 제어 대상이다. 복잡한 분석 단계에는 Opus급 모델을, 단순 포매팅이나 필터링에는 Haiku급 모델을 지정하는 식으로 비용과 품질을 조정한다.

Claude Agent SDK의 서브에이전트는 query() 옵션의 agents 파라미터를 이용하는 프로그래밍 방식이나 .claude/agents/ 디렉토리의 YAML frontmatter를 가진 마크다운 파일을 두는 파일시스템 방식으로 정의할 수 있다. 이 서브에이전트는 자신의 하위 서브에이전트를 재귀적으로 생성할 수 없어 위임이 단일 레벨에 머문다. 반면 동적 워크플로우에서는 별도의 JavaScript 하네스가 런타임에서 작업 분해와 에이전트 생성, 결과 검증과 재시도를 조율한다는 점에서 위임 구조가 다르다.

대규모 코드와 여러 정보원을 나눠 처리한다

Jarred Sumner의 포팅 사례에서는 약 100만 줄의 Zig 코드를 파일별로 Rust로 옮기면서 기존 테스트 스위트를 통과시키는 작업을 6일 만에 완료했다. 팀 단위로 분기 이상 걸리던 규모의 작업을 서브에이전트 단위로 분해해 처리한 것이다.

같은 구조는 코드베이스 전체를 검사할 때도 쓸 수 있다. 에이전트별로 서로 다른 모듈을 맡기면 버그 탐색을 병렬화할 수 있다. 500파일 이상의 대규모 리팩터링도 파일 단위로 나눌 수 있으며, 보안 감사에서는 서로 다른 공격 벡터를 독립적으로 분석하게 할 수 있다. 발견 사항은 별도의 교차 검증 에이전트가 다시 검토하도록 두어, 탐색과 판정을 분리할 수 있다. 멀티소스 리서치는 출처별 검토와 상호 교차 검증으로 분리하고, 복잡한 프로젝트의 아키텍처는 여러 관점에서 동시에 분석할 수 있다.

CI/CD 파이프라인에서 검증 루프를 연결한다

대규모 리팩터링을 CI/CD에 연결할 때는 먼저 파일 의존성 그래프를 분석해 서로 독립적으로 수정할 수 있는 파일 그룹을 찾고, 이를 병렬 서브에이전트에 나눈다. 변경이 충돌하면 오케스트레이터가 머지 전략을 세워 해결한다.

테스트 자동화는 코드 변경 에이전트와 테스트 실행 에이전트를 연결하는 피드백 루프로 구성한다. 변경 사항이 기존 테스트를 통과하는지 계속 확인하고, 실패하면 해당 컨텍스트를 담은 재시도 신호를 코드 변경 에이전트에 돌려보낸다. 모든 서브에이전트의 작업이 끝난 뒤에는 변경 사항을 자동으로 커밋하고 PR을 만들 수 있으며, PR 설명에는 각 서브에이전트가 맡았던 작업의 요약이 포함된다.

실행 신뢰성과 비용이 모델 품질만큼 중요해졌다

2026년 현재 AI 에이전트 활용의 병목은 모델 품질에만 있지 않다. 여러 에이전트가 참여하는 실행을 얼마나 신뢰할 수 있게 조율하는지, 비용을 어떻게 통제하는지가 실용성을 좌우한다.

하네스로 실행 흐름을 코드화하면 검증, 버전 관리, 재현이 가능해진다. 단계별로 모델과 에이전트를 배치해 불필요한 토큰 소비를 줄일 수 있고, 태스크 규모에 따라 에이전트 수도 동적으로 조절할 수 있다.

Claude Code의 동적 워크플로우는 OpenAI Codex의 목표 모드(Goal Mode), Google Gemini의 에이전트 팀 기능과 함께 AI 에이전트 오케스트레이션 경쟁의 한 축을 이룬다. 공통된 흐름은 개발자가 로우레벨 오케스트레이션 코드를 직접 작성하는 대신 성공 기준과 제약을 제공하고, AI가 실행 계획을 생성하도록 추상화 수준을 높이는 것이다.

동적 워크플로우가 리서치 프리뷰에서 정식 출시로 전환된 뒤 주목할 다음 방향으로는 자주 쓰는 패턴을 재사용하는 하네스 템플릿 생태계, 실행 비용과 에이전트별 기여도를 보여주는 비용·성능 대시보드, Bedrock·Vertex AI·Foundry 사이에서 이식할 수 있는 크로스 플랫폼 하네스 표준 포맷이 있다.

⤢✕

적용 전에 성공 조건과 권한 범위를 적는다

동적 워크플로우를 사용하려면 Claude Code v2.1.154 이상으로 업데이트해야 한다. Max 플랜, Team 플랜 또는 Claude API 직접 사용자는 기본 활성화 대상이다. 태스크 설명에 “병렬로”, “전체 코드베이스”, “여러 파일”과 같은 표현을 넣어 동적 워크플로우 사용을 유도할 수 있다.

단일 대화에서 조율하기 어려울 만큼 많은 에이전트가 필요하거나, 오케스트레이션 로직을 코드로 남겨 재현하고 감사해야 할 때 활용 가치가 크다. 파일·소스·모듈처럼 병렬화 경계가 분명한 작업에도 맞는다. 중간 결과가 Claude의 컨텍스트 창을 초과하는 태스크라면 상태를 스크립트 쪽으로 옮기는 구조가 필요하다.

사용자가 직접 하네스를 설계하지 않더라도 다음 항목은 명확히 적어야 한다.

성공 기준(Success Criteria): “기존 테스트 스위트 100% 통과”, “CVSS 7.0 이상 취약점 전수 탐지”
제약 조건(Constraints): “외부 네트워크 호출 금지”, “데이터베이스 스키마 변경 없음”
신뢰 경계(Trust Boundaries): “파일 시스템 쓰기 권한 범위”, “API 호출 허용 목록”

Claude Code 동적 워크플로우가 바꾼 것은 에이전트의 수만이 아니다. 개발자가 실행 절차를 일일이 코딩하던 방식에서 성공 기준과 제약을 기술하고 하네스 생성을 위임하는 방식으로 역할의 경계가 이동했다. 대규모 마이그레이션, 전체 코드베이스 감사, 멀티소스 리서치를 단일 세션에서 다룰 수 있게 되면서 프롬프트와 컨텍스트뿐 아니라 실행 구조를 설계하는 능력도 AI 개발자의 작업 범위에 들어왔다.