대규모 코드 변경을 다루는 동적 워크플로 오케스트레이션

한 번의 요청으로는 추적할 수 없는 변경

Anthropic이 공개한 Dynamic Workflows는 개발자 개인이 수만에서 수십만 줄 규모의 패키지를 다룬 사례를 제시한다. 대규모 변경을 단일 요청에 몰아넣으면 컨텍스트 한계에 부딪히고, 오류가 쌓인 뒤에는 어느 지점에서 문제가 시작됐는지 추적하기 어렵다.

이 방식은 모델이 오케스트레이션 스크립트를 동적으로 작성하고, 작업을 하위 과제로 나눈 뒤 수십에서 수백 개의 서브에이전트를 하나의 세션에서 병렬 실행하는 구조다. 결과는 검증 단계를 거쳐 최종 산출물로 합쳐진다. 실행당 총 에이전트 수에는 1,000개 상한을 둬 무한한 확산을 막는다.

보고된 사례에는 약 100만 줄 규모의 Zig 코드를 Rust로 이식한 작업이 있다. 목표는 재작성보다 파일 단위의 충실한 이식이었고, 기존 테스트 스위트 통과가 완료 조건이었다. 또 다른 75만 줄 규모 Rust 작업에서는 기존 테스트 스위트 99.8%를 통과했고, 첫 커밋부터 머지까지 11일이 걸렸다.

성패는 모델이 모든 일을 맡는 데 있지 않다. 어떤 구간을 결정론적 코드로 처리하고 어느 지점부터 모델의 판단을 허용할지 정하는 일이 오케스트레이션의 중심이다.

작업 목록부터 결과 집계까지

처리 대상을 먼저 빠짐없이 열거해야 한다. 파일 목록, 심볼 목록, 호출 지점 목록처럼 결정론적으로 만들 수 있는 목록은 스크립트가 생성하는 편이 안전하다. 이 발견 과정을 모델에 전적으로 맡기면 누락이 발생해도 조용히 통과할 수 있다.

목록의 각 항목은 발견, 변환, 검증을 독립적으로 통과한다. 전체 결과가 필요한 중복 제거와 전량 집계 같은 경우가 아니라면 항목 간 배리어를 두지 않는 편이 낫다. 먼저 끝난 항목이 곧바로 완료되므로 전체 리드타임을 줄일 수 있다.

동시 실행에는 상한이 필요하다. 상한을 넘는 작업은 큐에서 기다리게 하고, 자원과 비용이 한꺼번에 폭주하지 않도록 제어한다. 병렬도는 컴퓨팅 자원만으로 정해지지 않는다. 사람이 검토할 수 없는 속도로 변경이 쌓이면 품질 통제도 함께 무너진다.

같은 파일을 여러 항목이 변경하면 충돌하므로, 실제 충돌 가능성이 있는 작업은 워크트리나 컨테이너로 분리한 뒤 병합한다. 단계 사이에는 자유 텍스트 대신 스키마로 규정된 중간 산출물을 전달한다. 스키마 위반은 해당 항목만 실패로 처리하고, 나머지 항목은 계속 진행할 수 있다.

실패는 전체 중단 사유가 아니라 집계 대상이다. 재시도에는 횟수 상한을 두고, 같은 조건을 반복하기보다 다른 프롬프트나 상위 모델 같은 다른 전략을 적용한다.

⤢✕

병렬성을 얻기 전에 정해야 할 통제 기준

분해 단위는 독립적으로 검증할 수 있고, 필요한 맥락이 컨텍스트에 들어가며, 실패해도 다른 항목에 영향을 주지 않아야 한다. 파일 단위가 흔한 선택이지만 파일 사이의 결합이 강하면 모듈 단위가 더 적합하다. 이 선택이 확보할 수 있는 병렬성의 상한을 결정한다.

실제 병렬도 상한은 자원 한계, 비용 예산, 사람의 검토 처리량 가운데 가장 낮은 값으로 잡는다. 설정한 상한과 대기 때문에 지연된 항목 수를 로그로 남겨야 그것이 병목인지 판단할 수 있다.

검증은 각 항목의 처리 직후에 둔다. 마지막 단계에 검증을 몰아넣으면 오류의 원인을 항목별로 분리하기 어렵다. 기존 테스트 스위트는 자동 변경에 가장 신뢰도 높은 검증 수단이며, 테스트가 없는 코드베이스라면 검증 단계를 먼저 마련해야 한다.

부분 완료의 수용 기준도 실행 전에 정해야 한다. 99.8% 같은 수치가 성공 사례로 언급되는 이유는 100%만을 성공으로 보지 않았기 때문이다. 남은 실패 항목을 사람이 처리할지, 후속 실행으로 넘길지, 범위에서 제외할지를 정책으로 명시한다.

실행당 총 에이전트 수와 토큰 예산에는 상한을 둔다. 항목별 진행 상태를 보여줘야 중단 여부를 판단할 수 있으며, 블랙박스 실행은 실패 발견을 늦춘다. 작업 목록, 항목별 결과, 재시도 내역은 실행 산출물로 보존해 감사와 재현에 사용한다. 자동 생성 변경이 코드 소유권이나 리뷰 정책과 충돌할 수 있으므로, 리뷰 기준 역시 실행 전에 합의해야 한다.

단일 프롬프트와 다른 비용 구조

구분	단계별 워크플로 분해	단일 대형 프롬프트
성공률	항목 단위 격리로 높음	컨텍스트 한계에 종속
오류 추적	항목별 분리 가능	원인 지점 불명
비용	병렬 실행으로 총량 큼	상대적 적음
리드타임	병렬로 단축	순차 누적
구현 부담	오케스트레이션 설계 필요	없음
적합 상황	대규모·반복 구조 작업	소규모 단발 작업

단계별 분해에서는 항목이 독립적으로 실패하고 재시도되므로, 실패 원인을 항목 단위로 특정할 수 있다. 반면 단일 프롬프트는 구현 부담이 적지만 작업 규모가 커지면 컨텍스트에 담기지 않고, 중간에 틀어진 원인을 사후에 찾기 어렵다. 규모가 작은 작업에서는 오케스트레이션 비용이 이득을 넘어설 수 있다.

병렬 파이프라인은 전체 시간을 항목 수가 아니라 가장 느린 단일 항목 체인에 가깝게 만든다. 순차 처리는 자원 사용과 진행 상황이 단순하지만, 대규모 작업에서는 시간이 선형으로 늘어난다. 병렬 실행에는 충돌 방지를 위한 격리 환경이 따라오며, 그 비용도 설계에 포함해야 한다.

목록 발견, 병합, 집계처럼 정답이 분명한 작업은 결정론적 스크립트로 처리할 때 재현성을 확보하고 누락을 줄일 수 있다. 전 구간을 모델에 맡기면 유연성은 생기지만 같은 입력에도 다른 결과가 나올 수 있어 감사와 재실행에 취약하다.

WBS와 품질 게이트로 보는 운영 방식

대규모 변경을 항목으로 나누고 병렬 처리하며 부분 완료를 허용하는 구조는 전통적인 프로젝트 관리와 닮아 있다. 달라진 점은 실행 주체가 사람에서 에이전트로 바뀌었다는 사실이다. 진행 상태와 실패 항목을 관리하지 못하면 자동화된 대규모 작업 역시 통제 불능 상태가 된다.

작업 분해 구조(WBS)의 상호 배타성과 완전성은 그대로 적용된다. 항목이 겹치면 충돌이 생기고, 빠진 항목은 누락으로 남는다. 여기에 각 분해 단위가 검증 가능해야 한다는 조건이 더해진다. 검증할 수 없는 단위는 병렬로 처리해도 품질을 보장하기 어렵다.

기존 테스트 스위트는 자동 변경의 품질 게이트 역할을 한다. 테스트 자산이 부실한 조직은 이 방식의 이득을 충분히 얻기 어렵다. 수용 기준을 100%가 아닌 수치로 정하고, 잔여분의 처리 경로까지 명시하는 것이 현실적인 품질 관리다.

2026년에 관찰되는 변화

오케스트레이션 스크립트 자체를 모델이 작성하는 방식이 확산되면서, 개발자의 역할은 코드 작성에서 워크플로 설계로 이동할 전망이다. 대규모 자동 변경의 리뷰도 라인 단위 검토에서 테스트 통과율과 샘플 검토를 기반으로 하는 방식으로 전환되는 흐름이 있다.

격리 실행 환경은 에이전트 플랫폼의 기본 기능으로 편입되고, 병렬 변경의 충돌 문제는 인프라 계층에서 해결되는 방향으로 갈 수 있다. 실행당 에이전트 수와 토큰 예산의 상한 관리 역시 조직 정책 항목으로 자리 잡으며, 비용 통제가 오케스트레이션 설계에 내장될 전망이다.