Copilot Dynamic Workflows: 재개는 새 예산도, 권한 승인도 아니다

오래 걸리는 코드 검토가 중간에 멈췄다. 결과 JSON 파일은 남아 있고, 실행 목록에는 다시 시작할 수 있는 항목이 보인다. 이때 다음 자동화가 파일만 읽어 배포로 넘어가도 될까? 예산을 늘려 재개하면 이전 사용량은 사라질까? 터미널에서 실행했으니 부족한 권한은 알아서 물어볼까? 결과·진행 상태·사용량·권한을 하나의 성공 신호로 묶으면 안 된다.

GitHub는 2026년 10월 1일 Copilot CLI, Copilot 앱, SDK에 Dynamic Workflows를 제공한다고 발표했다. 모든 Copilot 요금제가 대상이지만 공개 프리뷰이며 변경될 수 있다. 모든 요금제에서 제공한다는 말은 무료 실행이나 추가 사용량이 없다는 뜻이 아니다. CLI에서는 --experimental 또는 대화형 세션의 /experimental on으로 실험 기능을 활성화해야 한다. 발표상 앱에서는 별도 설정 없이 사용할 수 있지만, 클라이언트마다 입력과 확장 인터페이스 지원이 같다고 확대 해석하지 않는다.

이 글은 보존된 공식 발표와 문서의 동작 계약을 분석한 것으로, Copilot을 직접 실행하거나 비용·신뢰성을 독립 측정한 결과가 아니다. 아래 판단표와 운영 제안은 문서에 근거한 편집자 분석이다. 실제 제품 화면이나 측정 그래프 대신 각기 다른 경계를 설명하는 원본 도해를 사용했다.

1. 코드로 고정하는 것은 답변이 아니라 절차다

Dynamic Workflow는 확장 안에 들어 있는 프로그램이다. 작성자가 단계, 조건, 인계를 코드로 정의하고 분석·판단이 필요한 부분을 에이전트에 맡긴다. 순차 실행뿐 아니라 병렬 실행과 두 방식의 혼합도 가능하다. 조사 결과를 구조화해 다음 단계로 넘기거나 검토 시점에서 멈추는 절차를 재사용하기에 적합하다.

/fleet과의 차이는 에이전트 수가 아니다. /fleet에서는 Copilot이 그때그때 일을 나누고 조율한다. Dynamic Workflow에서는 작성자가 절차의 규칙을 정한다. 그렇다고 입력이 달라도 같은 경로를 지나거나 같은 답을 낸다는 뜻은 아니다. 공식 개념 문서도 입력·발견에 따라 경로가 달라질 수 있고, 에이전트 답변 역시 실행마다 달라질 수 있다고 명시한다. 반복 가능한 규칙과 검증된 결과는 별개다.

규칙 재사용 ≠ 같은 경로·같은 답변 보장。공식 문서를 바탕으로 작성한 개념 도해이며 실제 화면·측정 결과가 아니다. 출처: docs.github.com/en/copilot/concepts/agents/dynamic-workflows.

작업을 나눈 뒤 결과를 합치는 설명만으로는 이번 기능의 운영 가치를 판단하기 어렵다. 재사용할 절차가 있고, 중간 검토나 한도 때문에 멈췄다가 이어가야 할 때 더 유용하다. 한 번의 간단한 수정이나 짧은 질문이라면 일반 대화로도 충분하다는 것이 공식 문서의 구분이다.

2. 재개할 수 있다는 말은 모든 작업이 저장됐다는 뜻이 아니다

일시정지한 실행이나 한도에 도달해 멈춘 실행은 재개 가능 목록에 있을 때 이어갈 수 있다. 완료 단계와 하위 에이전트의 저장된 결과는 재사용할 수 있지만 저장되지 않은 작업은 다시 실행될 수 있다. 반대로 취소한 실행은 재개할 수 없다. 운영자가 잠깐 확인하려고 멈출 것인지, 실행 자체를 끝낼 것인지에 따라 선택이 달라진다.

일시정지·한도 중단은 재개 가능 목록에서 확인。공식 문서를 바탕으로 작성한 개념 도해이며 실제 화면·측정 결과가 아니다. 출처: docs.github.com/en/copilot/how-tos/use-copilot-agents/use-dynamic-workflows.

여기서 중요한 것은 체크포인트를 외부 부작용까지 정확히 한 번 실행하는 보장으로 읽지 않는 것이다. 예를 들어 외부 서비스에 쓰기를 요청한 뒤 진행 상태 저장 전에 중단됐다면, 저장된 결과의 유무만으로 그 쓰기가 없었다고 판단할 수 없다. 이는 제품에서 관측한 장애 사례가 아니라 문서의 재실행 가능성에서 도출한 가상 반례다. 재개 전에 외부 대상의 실제 상태를 확인하거나 작업별 중복 방지 식별자를 쓰는 설계는 별도 운영 책임으로 남는다.

확장 정의를 개인 디렉터리나 저장소에 복사해 공유하는 일도 구분해야 한다. 공유되는 것은 절차의 정의이지 원래 세션의 실행 이력이나 저장된 진행 상태가 아니다. 팀원이 같은 정의를 받았다고 해서 내 중단 지점까지 함께 받은 것은 아니다. 정의 변경과 기존 실행 재개를 같은 작업으로 취급하면 검토 대상도 흐려진다.

3. 한도를 높여도 이전 사용량은 새 총한도 안에 남는다

설정 가능한 제한은 동시에 활성화되는 에이전트 수, 실행 전체에서 생성되는 총 에이전트 수, 활성 실행 시간, 근사 AI credit 사용량이다. 각각 답하는 질문이 다르다. 동시 에이전트 제한에 도달하면 추가 에이전트가 기다리며, 그것만으로 워크플로가 중단되지는 않는다. 다른 제한은 실행을 멈출 수 있고 저장된 상태는 재개에 활용할 수 있다.

활성 실행 시간에는 일시정지 이전에 일한 시간도 포함된다. 멈춰 있는 동안의 시간은 포함되지 않는다. 한도에 도달한 실행을 이어가려면 한도를 높여야 하지만 새 값은 추가 지급량이 아니라 실행 전체의 총한도다. 중단 전에 이미 쓴 사용량을 지운 채 다시 계산하지 않는다.

AI credit은 근사 상한: 진행 중 작업으로 초과 가능。공식 문서를 바탕으로 작성한 개념 도해이며 실제 화면·측정 결과가 아니다. 출처: docs.github.com/en/copilot/concepts/agents/dynamic-workflows.

AI credit 제한은 특히 하드 상한이 아니다. 사용량은 발생한 뒤 보고되므로, 총량이 한도에 도달했을 때 새 작업을 막아도 이미 진행 중인 작업 때문에 한도를 넘을 수 있다. 따라서 반드시 지출을 특정 금액 이하로 고정해야 하는 상황에서 이 설정 하나만으로 결제 안전장치를 완성했다고 말할 수 없다. 소규모 범위에서 실제 사용량을 확인한 뒤 확대하라는 공식 권고와 함께 읽어야 한다.

한도는 프롬프트, 워크플로 코드, 개인 설정 순으로 우선한다. 프롬프트의 해당 제한이 코드나 개인 기본값을 덮어쓸 수 있다. 매 실행의 임시 지시와 저장된 정의를 분리해 기록해야 다음 실행에 무엇이 적용됐는지 추적하기 쉽다. 문서에 나오는 credit 수나 초 단위 값은 설명용 예시이지 제품의 보편 기본값이나 추천 예산이 아니므로 이 글에서는 권장 수치로 옮기지 않았다.

4. 결과 파일과 이번 실행의 성공을 따로 확인한다

--result-file은 워크플로가 성공적으로 완료하고 결과를 반환할 때 그 반환값을 JSON 파일로 저장한다. 파일에는 진행 메시지나 실행 상세가 아니라 반환값만 들어간다. 기존 파일은 새 결과를 성공적으로 기록한 뒤 교체한다. 일시정지·실패·중단된 실행은 기존 파일을 그대로 남긴다.

따라서 어제 성공한 파일이 오늘 실패한 실행 뒤에도 존재할 수 있다. 결과 파일이 있다는 이유만으로 다음 배포 단계를 열지 않는다. 아래 표는 직접 실행 로그가 아니라 공식 동작을 후속 자동화의 판단으로 번역한 표다.

관측한 상황	문서상 의미	후속 단계의 판단 제안
결과 파일만 존재	과거 결과일 수 있음	이번 실행 ID·상태와 결과의 대응을 먼저 확인
이번 실행이 성공했고 결과도 반환	결과 파일 기록 조건 충족	반환값 내용과 대상 입력까지 확인한 뒤 소비
일시정지 또는 한도 도달	재개 가능한 상태일 수 있음	저장 결과와 미저장 작업을 구분하고 총한도 재검토
취소	해당 실행 재개 불가	외부 상태를 확인한 뒤 새 실행 여부 결정
직접 CLI 실행에서 권한 거절	자동 승인할 수 없는 요청 거절	필요한 최소 권한과 신뢰할 확장을 검토; 포괄 허용으로 우회하지 않음

실행별 결과 경로를 나누고 실행 ID·상태를 별도 기록하는 방법은 편집자의 제안이지 Copilot이 모든 결과 파일에 자동 부여하는 보장이 아니다. 공식 문서의 --silent --output-format json은 워크플로 이름, 실행 ID, 상태, 반환 결과가 있는 JSON 레코드를 받을 수 있다고 설명한다. 반환값 파일과 실행 메타데이터를 구분해 소비하는 근거로 활용할 수 있지만, 이 글은 특정 CI 구현이나 종료 코드별 동작을 재현했다고 주장하지 않는다.

5. 무인 실행의 권한과 확장 코드의 신뢰는 별도다

하위 에이전트는 시작 세션의 권한 허용을 상속한다. 대화형 CLI에서는 아직 허용되지 않은 요청이 일반 승인 프롬프트로 나타나고 해당 에이전트가 답을 기다린다. 세션 동안 허용한 권한은 같은 권한이 필요한 다른 하위 에이전트에도 적용된다.

그러나 copilot workflow run으로 직접 실행할 때는 터미널이라도 승인 프롬프트를 표시하지 않는다. 필요한 권한을 시작 전에 준비해야 하며 자동 승인할 수 없는 요청은 거절된다. 사람 없는 실행이 중단되지 않게 하려고 넓은 권한을 일괄 허용하는 것이 이 글의 권고는 아니다. 작업이 읽기만 필요한지, 파일 쓰기나 특정 서비스 접근까지 필요한지 범위를 먼저 좁혀야 한다.

에이전트 권한 ≠ 확장 전체의 샌드박스。공식 문서를 바탕으로 작성한 개념 도해이며 실제 화면·측정 결과가 아니다. 출처: docs.github.com/en/copilot/concepts/agents/dynamic-workflows.

더 큰 경계는 확장 자체다. 공식 문서는 확장이 승인 프롬프트 바깥에서 자체 코드를 직접 실행할 수도 있다고 밝힌다. 에이전트 도구 권한 설정을 확장 코드 전체의 샌드박스로 부르면 안 된다. CI에서 신뢰하지 않은 작업 디렉터리의 프로젝트 확장을 로드하도록 허용하는 설정 역시 저장소 코드를 실행하게 하는 결정이며 신뢰한 코드에만 사용해야 한다. 권한 허용과 코드 신뢰 검토를 서로 대신하는 절차로 만들지 않는 것이 핵심이다.

도입 판단: 먼저 작은 읽기 작업으로 경계를 확인한다

반복되는 검토 절차가 없으면 워크플로 작성 비용부터 늘어날 수 있다. 도입 후보가 있다면 작은 읽기 전용 범위에서 어떤 결과가 저장되고, 중단 뒤 무엇을 다시 실행하며, 어느 권한이 필요한지 확인하는 순서가 합리적이다. 이후 외부 쓰기를 추가할 때는 대상 상태 대조와 중복 방지를 별도 설계한다. 이는 공식 소규모 시험 권고에 운영 경계를 덧붙인 제안이며 검증된 비용 절감 비율이나 성공률을 제공하지 않는다.

이번 발표를 “여러 에이전트가 알아서 끝내 준다”로 요약하면 가장 중요한 계약이 빠진다. 재개는 새 예산이 아니고, 파일 존재는 이번 성공이 아니며, 도구 승인은 확장 전체의 실행 격리가 아니다. 이 세 경계를 후속 자동화에 명시적으로 남길 수 있을 때 절차 재사용의 이점도 안전하게 평가할 수 있다.

출처와 검토 범위

• GitHub 공식 발표: Dynamic workflows in Copilot CLI and the Copilot app: 제공 범위와 공개 프리뷰. 최초 공개와 수정 시각은 별도이며, 보존된 발표 메타데이터는 각각 2026-10-01 16:30:10 UTC와 20:28:05 UTC다.
• 공식 개념 문서: Dynamic workflows: 절차와 fleet의 차이, 권한, 한도, 저장 결과 재사용.
• 공식 사용 문서: Using dynamic workflows: 직접 CLI 실행, 결과 파일, 스크립트, 재개와 취소의 차이.

자료는 이번 항목의 선정 단계에서 보존된 공식 본문을 재사용했다. 프리뷰 동작은 변경될 수 있으므로 실제 도입 전 사용 중인 클라이언트의 현재 문서와 동작을 확인해야 한다. 성능 벤치마크, SDK별 UI 동일성, 모든 외부 작업의 정확히 한 번 실행은 검증 범위에 포함되지 않는다.