AI Agent도 이제 Workflow를 코드로 짠다

GitHub Copilot Dynamic Workflows — /fleet보다 중요한 변화가 나온 이유

AI Coding Agent를 쓰다 보면 처음에는 모든 걸 Prompt로 해결하게 됩니다.

이 Repository를 분석해.

문제를 찾아.

수정해.

Test하고,

문제가 있으면 다시 고쳐.

간단한 작업에서는 이걸로 충분합니다.

그런데 Agent가 여러 개가 되고 작업 시간이 길어지면 문제가 생깁니다.

같은 Prompt를 줬는데도 매번 작업 순서가 조금씩 달라집니다.

어제

분석
→ 코드 수정
→ Test
→ Review


오늘

분석
→ Test
→ 다른 파일까지 조사
→ 코드 수정
→ 또 조사
→ Review

결과가 좋을 수도 있습니다.

하지만 회사에서 반복적으로 돌리는 개발 업무라면 이야기가 달라집니다.

“AI가 알아서 잘 해주겠지”보다 매번 같은 절차로 움직이는 게 중요해집니다.

2026년 10월 1일 GitHub가 공개한 Copilot Dynamic Workflows는 바로 이 문제를 건드립니다.

핵심은 간단합니다.

Agent에게 Workflow를 생각하게 하지 말고, 중요한 Workflow는 코드로 정한다.

---

1. Dynamic Workflow가 나왔다

GitHub는 Dynamic Workflows를 다음 환경에 공개했습니다.

GitHub Copilot CLI

GitHub Copilot App

GitHub Copilot SDK

현재 Public Preview입니다.

Dynamic Workflow는 여러 Agent를 실행하는 기능만을 뜻하지 않습니다.

작업 순서 자체를 프로그램으로 정의하는 기능입니다.

예를 들어 장애 분석이라면:

로그 수집
   ↓
Telemetry 수집
   ↓
┌──────────────┬──────────────┐
↓              ↓
Backend Agent  Mobile Agent
↓              ↓
분석 결과      분석 결과
└───────┬──────┘
        ↓
결과 통합
        ↓
Root Cause 분석
        ↓
사람 Review
        ↓
Fix 진행

이 흐름을 매번 Agent가 새로 판단하는 게 아닙니다.

Workflow 자체가 이 순서를 가지고 있습니다.

---

2. 지금까지의 Agent와 가장 큰 차이는 ‘누가 순서를 정하느냐’다

기존 Copilot Agent에게 이런 요청을 해보겠습니다.

이 장애 원인 분석해줘.

그러면 Agent가 알아서 결정합니다.

로그 먼저 볼까?

코드를 먼저 볼까?

다른 Agent를 부를까?

테스트를 돌릴까?

몇 개 Agent로 나눌까?

이건 유연하다는 장점이 있습니다.

하지만 같은 업무를 반복해야 한다면 문제가 됩니다.

Dynamic Workflow에서는 개발자가:

1. 로그부터 수집

2. Backend와 Mobile을 병렬 분석

3. 두 결과를 구조화

4. 별도 Agent가 결과 검증

5. 사람이 확인

6. 승인되면 다음 단계

를 미리 정합니다.

즉:

Agent가 Workflow를 결정

에서

Workflow가 Agent를 사용

으로 관계가 바뀝니다.

이 차이가 꽤 큽니다.

---

3. 그래서 단순 Multi-Agent 기능과도 다르다

요즘 Coding Agent에는 이미 Subagent 기능이 많습니다.

GitHub Copilot에도 /fleet이 있습니다.

/fleet을 사용하면 Copilot이 큰 작업을 보고 스스로 여러 작업으로 나눕니다.

큰 작업
   ↓
Copilot 판단
   ↓
┌────────┬────────┬────────┐
↓        ↓        ↓        ↓
Agent A  Agent B  Agent C  Agent D

예를 들어:

src 전체에 Unit Test를 추가해.

라고 하면 Copilot이:

Auth
Payment
Profile
Network

처럼 작업을 나눠 여러 Subagent에 병렬로 맡길 수 있습니다.

중요한 건 어떻게 나눌지도 Copilot이 판단한다는 점입니다.

---

4. Dynamic Workflow는 /fleet과 여기서 갈린다

두 기능을 가장 쉽게 비교하면 이렇습니다.

/fleet

목표
 ↓
Copilot
 ↓
작업 분해
 ↓
Agent 선택
 ↓
병렬 실행

Dynamic Workflow

미리 정의된 Workflow
 ↓
정해진 단계
 ↓
필요한 위치에서 Agent 실행
 ↓
결과 검증
 ↓
다음 단계

즉 /fleet은:

“이 일을 빠르게 여러 Agent에게 나눠줘.”

에 가깝고,

Dynamic Workflow는:

“우리 회사에서는 이 일을 항상 이 절차대로 처리해.”

에 가깝습니다.

---

5. Autopilot과도 다르다

Copilot CLI에는 Autopilot도 있습니다.

Autopilot은 한 번 작업을 맡기면 중간마다 사용자의 답을 기다리지 않고 계속 진행합니다.

Prompt
 ↓
Copilot
 ↓
작업
 ↓
판단
 ↓
작업
 ↓
판단
 ↓
완료

핵심은 자율성입니다.

반면 Dynamic Workflow는 자율성보다 절차의 재현성이 중요합니다.

정리하면:

기능	핵심
일반 Prompt	한 번의 작업
Autopilot	끝날 때까지 알아서 진행
/fleet	여러 Agent로 병렬 처리
Dynamic Workflow	미리 정한 절차를 반복 실행

이렇게 보면 이해하기 쉽습니다.

---

6. 세 개를 섞어서 사용할 수도 있다

각 기능이 경쟁 관계인 것도 아닙니다.

예를 들어 Workflow 하나가:

Step 1
코드 검색

Step 2
/fleet 스타일 병렬 분석

Step 3
결과 통합

Step 4
사람 승인

Step 5
Agent가 수정

Step 6
Test

처럼 구성될 수도 있습니다.

Dynamic Workflow가 전체 공정이라면,

Agent와 Subagent는 그 안에서 특정 공정을 담당하는 셈입니다.

---

7. 중요한 단계는 deterministic하게 만들 수 있다

AI Agent의 가장 큰 장점은 유연성입니다.

하지만 모든 단계가 유연할 필요는 없습니다.

예를 들어 Release Workflow를 생각해보겠습니다.

Release 준비

↓

Test 실행

↓

Security Scan

↓

Build

↓

Version 확인

↓

Agent Review

↓

Human Approval

↓

Release

여기에서:

Test 실행

Security Scan

Build

은 AI 판단이 필요 없습니다.

그냥 반드시 실행하면 됩니다.

반면:

Test 실패 원인 분석

Security Finding 판단

Release 위험도 판단

은 Agent가 잘합니다.

Dynamic Workflow에서는 이 두 종류를 섞을 수 있습니다.

확실한 일
→ 코드로 실행

판단이 필요한 일
→ Agent에게 맡김

이게 핵심입니다.

---

8. 모든 걸 AI에게 시킬 필요가 없어진다

예를 들어 이런 Workflow가 있다고 해보겠습니다.

Repository 전체에서
deprecated API를 찾아서 교체해.

기존 Agent 방식에서는 모델이:

파일 검색

관련 코드 판단

수정 대상 분류

코드 변경

검증

전부 할 수도 있습니다.

그런데 검색 자체는:

rg "oldAPI"

한 번이면 끝날 수 있습니다.

Dynamic Workflow에서는:

Code
 ↓
oldAPI 위치 검색

Agent
 ↓
각 사용처의 의미 판단

Code
 ↓
결과 정리

Agent
 ↓
수정 계획

Agent
 ↓
실제 변경

Code
 ↓
Test

처럼 나눌 수 있습니다.

Agent가 굳이 잘하는 일이 아닌 곳에서 Token을 쓰지 않아도 됩니다.

---

9. Agent 결과도 그냥 문장으로 넘길 필요가 없다

여러 Agent를 연결할 때 흔히 생기는 문제가 있습니다.

Agent A가:

문제는 Network Layer의 Retry 정책에 있는 것 같습니다.
...

처럼 긴 문장을 반환합니다.

Agent B가 다시 이걸 읽고 해석해야 합니다.

Dynamic Workflow에서는 Agent에게 결과 형식을 미리 정할 수 있습니다.

예를 들어:

{
  "severity": "high",
  "affectedFiles": [...],
  "rootCause": "...",
  "recommendedFix": "...",
  "confidence": 0.91
}

같은 Structured Result를 요구할 수 있습니다.

다음 단계에서는 이 값을 그대로 사용할 수 있습니다.

Agent A
 ↓
Structured Result
 ↓
Workflow
 ↓
Agent B

Multi-Agent Workflow에서 상당히 중요한 부분입니다.

---

10. 형식이 틀리면 다시 고치게 할 수도 있다

Agent가 지정한 형태와 다른 응답을 반환할 수도 있습니다.

예를 들어:

severity가 없음

affectedFiles가 String임

필수 값 누락

같은 상황입니다.

Dynamic Workflow에서는 구조가 맞지 않으면 Agent에게 형식을 다시 맞추도록 요구할 수 있습니다.

즉 Agent끼리 주고받는 데이터를:

자연어 대화

만으로 두지 않고,

정해진 데이터 구조

로 만들 수 있습니다.

AI Workflow를 운영 환경에서 사용하려면 이런 부분이 꽤 중요합니다.

---

11. 여러 Agent가 서로 검증하게 할 수도 있다

GitHub가 공식적으로 소개한 기능 중 재미있는 부분입니다.

예를 들어 PR에 아직 의미 있는 Review Comment가 남아 있는지 판단한다고 해보겠습니다.

PR Comment
    ↓
Agent A
    ↓
여전히 유효?

Agent B
    ↓
여전히 유효?

그리고:

A = YES
B = YES

일 때만 결과를 보고하도록 만들 수 있습니다.

Agent A ─┐
         ├→ 둘 다 동의 → Report
Agent B ─┘

하나의 Agent 판단을 그대로 믿지 않는 겁니다.

---

12. 이 구조는 AI 작업에 꽤 중요하다

AI가:

정답일 확률 90%

이라도 Production 자동화에서는 불안할 수 있습니다.

하지만 독립적인 두 Agent가 같은 결과를 내고,

그다음 Deterministic Check까지 통과하게 만들면 안정성을 높일 수 있습니다.

Agent 판단
   ↓
Agent 재검증
   ↓
Rule Check
   ↓
Human Approval

AI를 많이 쓰는 것보다 AI를 어디에서 믿고 어디에서 확인할지 정하는 것이 중요해지는 겁니다.

---

13. 중간에 사람을 넣을 수도 있다

Dynamic Workflow는 완전 자동화만을 목표로 하지 않습니다.

중간에 Workflow를 멈출 수 있습니다.

예를 들어:

코드 분석
 ↓
수정 계획
 ↓
────────────
Human Review
────────────
 ↓
승인
 ↓
실제 코드 수정

입니다.

개발자가 수정 계획을 보고:

계속

을 누르면 다음 단계가 실행됩니다.

아니면 Workflow를 멈출 수도 있습니다.

---

14. 이게 실제 회사에서는 꽤 중요하다

AI Agent에게 모든 권한을 줘버리는 건 편합니다.

하지만 실제 회사에서는:

Production

Security

Payment

Database Migration

Release

같은 작업이 있습니다.

이런 단계에서:

AI가 판단했으니 계속

은 부담스럽습니다.

Dynamic Workflow에서는:

AI가 준비

↓

사람이 승인

↓

AI가 실행

으로 경계를 만들 수 있습니다.

---

15. Workflow를 멈췄다가 다시 시작할 수도 있다

긴 Agent 작업에서 또 하나 중요한 부분입니다.

작업이 몇 시간 걸리는데:

AI Credit 제한

Timeout

Human Checkpoint

에 도달했다고 해보겠습니다.

Workflow 상태와 중간 결과를 저장해두고 나중에 다시 Resume할 수 있습니다.

즉:

처음부터 다시

하지 않아도 됩니다.

장시간 Agent Workflow에서 생각보다 중요한 기능입니다.

---

16. Agent 사용량 제한도 걸 수 있다

Multi-Agent의 가장 큰 현실적인 문제 중 하나가 비용입니다.

Agent 하나가:

Agent 4개 생성
   ↓
각 Agent가 또 Tool 사용
   ↓
모델 호출 반복

하기 시작하면 사용량이 빠르게 늘어날 수 있습니다.

그래서 Dynamic Workflow에는 Limit을 설정할 수 있습니다.

예를 들어:

최대 동시 Subagent 수

전체 Subagent 수

Timeout

AI Credit 한도

입니다.

CLI 설정에는 다음 항목들이 있습니다.

workflows.defaultLimits.maxConcurrentSubagents

workflows.defaultLimits.maxTotalSubagents

workflows.defaultLimits.timeoutSeconds

workflows.defaultLimits.maxAiCredits

입니다.

---

17. AI Credit Limit은 생각보다 중요하다

예를 들어 대형 Repository 전체를 분석한다고 해보겠습니다.

100개 Directory

↓

각 Directory마다 Agent

↓

100 Agent

같은 일을 그대로 허용하면 비용이 상당히 커질 수 있습니다.

그래서 GitHub도 처음에는:

2~3개 파일

작은 Directory

에서 Workflow를 시험해보고 실제 AI Credit 사용량을 확인한 뒤 범위를 늘리는 방식을 권장합니다.

AI Agent Workflow에서도 결국:

Performance Budget

Cost Budget

가 필요해지고 있습니다.

---

18. 실제 실행은 생각보다 단순하다

Copilot CLI에서는 현재 Experimental 기능을 켜야 합니다.

/experimental on

또는 CLI를:

copilot --experimental

로 실행합니다.

그다음 Copilot에게 그냥 물어볼 수 있습니다.

What dynamic workflows are available?

설치되어 있는 Workflow가 있으면 목록을 알려줍니다.

---

19. Workflow 자체도 Copilot에게 만들어달라고 하면 된다

직접 처음부터 작성할 필요도 없습니다.

예를 들어:

Create a dynamic workflow named review-changed.

List all changed files,
ask agents to review them in parallel,
combine the findings,
and pause before applying any changes.

처럼 설명하면 Copilot이 Workflow를 작성합니다.

즉 Workflow를 코드로 정의하지만 그 코드를 사람이 모두 직접 작성해야 하는 것은 아닙니다.

사람
 ↓
업무 절차 설명
 ↓
Copilot
 ↓
Workflow 작성
 ↓
사람 검토

방식으로 시작할 수 있습니다.

---

20. 처음에는 현재 Session에서만 사용할 수 있다

Copilot에게 Workflow를 만들라고 하면 기본적으로 현재 Session의 Extension으로 생성됩니다.

한 번 테스트해보는 용도입니다.

마음에 들면:

Personal Extension

또는:

Project Extension

으로 옮길 수 있습니다.

Project에 넣으면 Repository와 함께 공유할 수 있습니다.

---

21. 결국 Workflow도 코드가 된다

이 부분이 개발자에게 제일 재미있습니다.

우리 팀은 이렇게 일해.

라는 설명이:

Repository 안의 Workflow

로 들어갑니다.

그러면:

Git

PR

Code Review

Version

관리도 가능합니다.

Workflow 자체를 Review할 수 있는 겁니다.

---

22. 예를 들어 PR Review Workflow를 만들어보자

보통 PR Review를 AI에게 시키면:

이 PR Review해줘.

입니다.

Dynamic Workflow를 사용하면 훨씬 구체적으로 만들 수 있습니다.

Changed Files 확인
        ↓
파일 종류별 분류
        ↓
┌────────┬────────┬────────┐
↓        ↓        ↓
Security Architecture Tests
Agent     Agent       Agent
↓        ↓        ↓
Finding  Finding    Finding
└────────┼────────┘
         ↓
중복 제거
         ↓
Critical Finding 재검증
         ↓
결과 정리
         ↓
Human Review

매 PR마다 같은 구조로 실행됩니다.

---

23. iOS 프로젝트라면 이런 Workflow도 가능하다

예를 들어 Swift 6 Migration입니다.

Target Module 선택
       ↓
Concurrency Warning 검색
       ↓
파일별 분류
       ↓
┌───────────────┬───────────────┐
↓               ↓
Actor 문제       Sendable 문제
Agent            Agent
↓               ↓
수정안           수정안
└───────┬───────┘
        ↓
Architecture Rule 확인
        ↓
코드 수정
        ↓
xcodebuild
        ↓
Test
        ↓
Warning 재검색
        ↓
Human Review

이걸 매 Module마다 같은 방식으로 돌릴 수 있습니다.

---

24. 대규모 API Migration에도 잘 맞는다

예를 들어 오래된 API를 제거해야 한다고 해보겠습니다.

Deprecated API 검색

↓

Directory 단위 분할

↓

여러 Agent 병렬 분석

↓

수정

↓

Build

↓

남은 사용처 재검색

↓

Test

이런 일은 Agent에게 매번 계획부터 세우게 하는 것보다 Workflow로 정해두는 게 훨씬 안정적입니다.

---

25. Incident 분석도 좋은 사용처다

GitHub가 대표 사례로 드는 것도 서비스 장애 분석입니다.

Incident 발생
 ↓
Logs
Metrics
Telemetry
 ↓
┌─────────┬─────────┬─────────┐
↓         ↓         ↓
API       DB        Client
Agent     Agent     Agent
↓         ↓         ↓
Finding   Finding   Finding
└─────────┼─────────┘
          ↓
Timeline
          ↓
Root Cause
          ↓
Report

중요한 건 다음 장애에서도 같은 조사 절차가 실행된다는 것입니다.

---

26. CI/CD에도 넣을 수 있다

Dynamic Workflow는 CLI에서 직접 실행할 수도 있습니다.

copilot workflow run WORKFLOW-NAME

입력값은 JSON으로 넘길 수 있습니다.

예를 들어:

copilot workflow run security-review \
  --args @workflow-input.json \
  --silent \
  --output-format json

같은 형태입니다.

그러면 Interactive Chat을 열지 않아도 됩니다.

스크립트나 CI/CD에서 호출할 수 있습니다.

---

27. 이 지점부터 Agent가 DevOps Pipeline 안으로 들어온다

예전 CI/CD는 거의 Deterministic했습니다.

Build

Test

Lint

Deploy

였습니다.

앞으로는 중간에:

Agent Review

Root Cause Analysis

Migration 판단

Risk 평가

같은 단계가 들어올 수 있습니다.

예를 들면:

Build
 ↓
Test
 ↓
Fail
 ↓
Agent가 원인 분석
 ↓
수정 가능성 판단
 ↓
Human Review
 ↓
다시 Build

입니다.

AI Agent가 CI/CD 밖에서 도와주는 도구가 아니라 Pipeline 안의 하나의 단계가 됩니다.

---

28. Schedule까지 걸 수 있다

Copilot CLI의 예약 기능과도 연결할 수 있습니다.

예를 들어 매일:

/every 1d

로 특정 Workflow를 실행할 수 있습니다.

예시를 들면:

매일 Main Branch 확인
        ↓
변경 파일 분석
        ↓
Deprecated API 검색
        ↓
Test 누락 확인
        ↓
보고서 생성

같은 반복 작업입니다.

즉:

Dynamic Workflow
+
Schedule

을 합치면 간단한 상시 Agent Workflow도 만들 수 있습니다.

---

29. 우리가 전에 봤던 Jev와도 역할이 다르다

Jev 같은 Decision Model은:

Input
 ↓
Decision
 ↓
어디로 보낼지 결정

에 강합니다.

Dynamic Workflow는:

전체 작업 과정

을 담당합니다.

둘을 개념적으로 같이 놓으면:

Request
   ↓
Decision Layer
   ↓
Workflow 선택
   ↓
Dynamic Workflow
   ↓
Agent A / Agent B / Tools
   ↓
Human Checkpoint
   ↓
Result

같은 구조를 생각할 수 있습니다.

다만 GitHub Dynamic Workflows가 Jev와 직접 연동된다는 뜻은 아닙니다.

역할을 나눠보면 이런 구조가 가능하다는 이야기입니다.

---

30. Paseo 같은 Orchestrator와도 차이가 있다

Paseo 같은 도구는 여러 AI Coding Agent를:

Claude

Codex

Gemini

처럼 한곳에서 운영하고 역할을 나누는 데 가깝습니다.

Dynamic Workflow는 그보다 업무 절차 자체에 집중합니다.

Paseo
→ 어떤 Agent들을 팀으로 운영할까

Dynamic Workflow
→ 그 Agent들이 어떤 순서로 일할까

라고 보면 이해하기 쉽습니다.

---

31. 결국 Agent Orchestration이 두 종류로 나뉘기 시작했다

요즘 Multi-Agent를 보면 크게 두 종류가 보입니다.

자유형 Orchestration

목표 전달
 ↓
Agent가 판단
 ↓
필요한 Agent 생성
 ↓
작업 분배

Workflow Orchestration

미리 정의된 과정
 ↓
정해진 지점에서 Agent 사용
 ↓
검증
 ↓
다음 단계

전자는 유연합니다.

후자는 예측하기 쉽습니다.

실제 회사 개발환경에서는 둘 다 필요합니다.

---

32. 모든 일을 Dynamic Workflow로 만들 필요는 없다

GitHub도 이 부분을 분명히 합니다.

예를 들어:

이 함수 이름 바꿔줘.

이 Bug 고쳐줘.

이 코드 설명해줘.

라면 그냥 Prompt가 낫습니다.

Workflow를 만드는 게 더 번거롭습니다.

Dynamic Workflow가 필요한 건:

반복되는 일

여러 단계가 있는 일

Agent가 여러 개 필요한 일

검증 절차가 있는 일

비용이나 권한을 제한해야 하는 일

입니다.

---

33. 쉽게 판단하는 기준이 있다

같은 Prompt를 개발팀에서 계속 복사하고 있다면 Workflow 후보입니다.

예를 들어 매번:

먼저 변경 파일 확인하고,

관련 Test 찾고,

Architecture 위반 확인하고,

Security 확인하고,

문제가 있으면 수정하지 말고 보고만 해줘.

라고 쓰고 있다면,

이건 더 이상 Prompt가 아닙니다.

업무 절차입니다.

Workflow로 옮길 가치가 있습니다.

---

34. Prompt보다 Workflow가 좋은 이유는 Review할 수 있기 때문이다

Prompt는 보통 개인 Session 안에 있습니다.

하지만 Workflow가 코드가 되면:

PR
 ↓
Review
 ↓
승인
 ↓
Merge

를 거칠 수 있습니다.

예를 들어 누군가:

Security Check 삭제

를 하면 Diff에서 바로 보입니다.

또:

Production 전 Human Approval 제거

같은 위험한 변경도 Code Review에서 확인할 수 있습니다.

이게 회사 환경에서는 꽤 큰 차이입니다.

---

35. Agent 시대의 Architecture가 조금씩 보이기 시작한다

최근 AI 개발도구를 계속 보면 각각의 역할이 나뉘고 있습니다.

Model
 ↓
Reasoning

Agent
 ↓
실제 작업

Subagent
 ↓
전문 작업 분담

Decision Model
 ↓
Routing

Dynamic Workflow
 ↓
전체 업무 절차

Human
 ↓
중요한 판단과 승인

예전에는 이걸 모두 Prompt 하나에 집어넣으려고 했습니다.

이제는 각각 별도의 계층으로 분리되고 있습니다.

---

36. 특히 회사에서는 ‘AI에게 뭘 시키느냐’보다 ‘어떤 절차로 시키느냐’가 중요해진다

개인 프로젝트에서는:

알아서 잘 해줘.

가 통할 수 있습니다.

회사에서는:

Security 검사는 반드시 수행

Production 변경은 반드시 승인

Test 실패 시 Merge 금지

두 Agent가 동의해야 Finding 등록

AI Credit 최대 500

같은 규칙이 필요합니다.

이걸 모두 Prompt 안에 넣으면 점점 복잡해집니다.

Dynamic Workflow는 그 규칙을 실행 가능한 코드로 옮깁니다.

---

37. AI Agent도 결국 CI/CD가 걸어온 길을 따라가는 것 같다

초기 CI도 단순했습니다.

개발자가 직접:

Build

Test

Deploy

했습니다.

그러다 반복되면서:

Pipeline

이 생겼습니다.

AI Agent도 비슷합니다.

처음에는:

Prompt

였습니다.

그다음:

Autopilot

Subagent

Multi-Agent

가 나왔습니다.

그리고 이제:

Agent Workflow

가 코드로 들어오기 시작했습니다.

---

38. 개인적으로 이번 기능에서 가장 중요한 건 Multi-Agent가 아니다

Dynamic Workflows 소개를 보면 여러 Agent가 병렬로 일한다는 부분이 가장 화려해 보입니다.

하지만 실제 개발에서는 그것보다 이게 더 중요합니다.

같은 작업을

같은 규칙으로

다시 실행할 수 있다.

Agent가 매번 조금씩 다른 생각을 하더라도 Workflow의 큰 틀은 흔들리지 않습니다.

Production 환경에서 Agent를 쓰려면 결국 이 방향이 필요합니다.

---

39. 앞으로는 Repository에 Workflow가 같이 들어갈 가능성이 크다

지금 Repository에는:

Source Code

Tests

CI

Architecture Docs

AGENTS.md

가 있습니다.

앞으로 여기에:

Agent Workflows

가 자연스럽게 들어갈 수 있습니다.

예를 들어:

.github/
  workflows/
  copilot/
    security-review
    migration
    release-check
    incident-analysis

처럼 팀 업무가 코드와 같이 관리되는 그림입니다.

정확한 저장 구조는 구현 방식에 따라 달라질 수 있지만 방향은 분명합니다.

Repository가 코드뿐 아니라 AI가 일하는 방법까지 저장하기 시작합니다.

---

40. 개발자라면 처음 만들 Workflow는 작게 잡는 게 좋다

처음부터:

AI가 우리 개발 프로세스를 모두 자동화

하려고 하면 실패하기 쉽습니다.

오히려:

PR Review

Changed Files
↓
병렬 Review
↓
결과 통합

Test Failure 분석

Test 실행
↓
실패 수집
↓
Agent 분석
↓
Report

Deprecated API 검색

검색
↓
분류
↓
Agent 판단
↓
Report

정도부터 시작하는 게 좋습니다.

반복적으로 안정되면 그다음 실제 코드 수정까지 열어주면 됩니다.

---

마치며

GitHub Copilot Dynamic Workflows를 처음 보면:

Copilot에 Multi-Agent 기능이 하나 더 생겼네.

라고 생각할 수 있습니다.

하지만 핵심은 Agent 숫자가 아닙니다.

이번 변화의 중심은:

Agent가 알아서 Workflow를 만든다

에서

개발자가 Workflow를 코드로 정한다

로 넘어가는 것입니다.

Autopilot은 끝날 때까지 일하게 하고,

/fleet은 여러 Agent에게 병렬로 나누게 하고,

Dynamic Workflow는 그 Agent들이 어떤 순서와 규칙으로 움직일지를 정합니다.

Autopilot
→ 자율성

/fleet
→ 병렬성

Dynamic Workflow
→ 재현성과 통제

라고 보면 가장 이해하기 쉽습니다.

그리고 회사에서 AI Agent를 실제 개발 프로세스에 넣으려면 마지막 항목이 특히 중요합니다.

개발팀은 매번 새로운 방식으로 Release하지 않습니다.

Security Review도 매번 기분에 따라 순서를 바꾸지 않습니다.

Incident 대응에도 Runbook이 있습니다.

그런 업무에 Agent가 들어온다면 AI 역시:

우리 팀의 절차

안에서 움직여야 합니다.

Dynamic Workflows는 그 절차를 이제 실행 가능한 코드로 만들기 시작한 기능입니다.

AI Coding Agent의 다음 단계는 더 똑똑한 Agent 하나가 아닐 수도 있습니다.

오히려:

여러 Agent가 예측 가능한 절차 안에서 함께 일하도록 만드는 것.

그리고 필요할 때 사람이 정확한 위치에서 개입하는 것.

Agentic Coding도 결국 CI/CD가 그랬던 것처럼,

Prompt에서 Workflow로 이동하기 시작했습니다.

참고자료

GitHub — Dynamic workflows in Copilot CLI and the Copilot app

2026년 10월 1일 공개된 Dynamic Workflows 공식 발표입니다. 순차·병렬 Agent 실행, Structured Result, 상호 검증, Human Checkpoint와 /fleet의 차이를 설명합니다.

https://github.blog/changelog/2026-10-01-dynamic-workflows-in-copilot-cli-and-the-copilot-app/

GitHub Docs — Dynamic workflows

Dynamic Workflow의 구조와 Autopilot·/fleet의 차이, Agent 결과 전달, Pause·Resume, Resource Limit 등 핵심 개념을 설명합니다.

https://docs.github.com/en/copilot/concepts/agents/dynamic-workflows

GitHub Docs — Using dynamic workflows

Copilot CLI와 Copilot 앱에서 Workflow를 만들고 실행하고 공유하는 방법, AI Credit 제한과 Scheduling 등을 확인할 수 있습니다.

https://docs.github.com/en/copilot/how-tos/use-copilot-agents/use-dynamic-workflows

GitHub Docs — Running tasks in parallel with /fleet

Copilot이 요청을 Subagent 작업으로 자동 분해하고 병렬 실행하는 /fleet의 동작 방식과 Dynamic Workflow와의 차이를 이해할 수 있습니다.

https://docs.github.com/en/copilot/concepts/agents/copilot-cli/fleet

GitHub Docs — Copilot CLI Autopilot

사용자 개입을 줄이고 Copilot이 작업 완료까지 계속 진행하는 Autopilot Mode의 구조와 권한·Continuation Limit을 설명합니다.

https://docs.github.com/en/copilot/concepts/agents/copilot-cli/autopilot

GitHub Docs — Copilot CLI Programmatic Reference

copilot workflow run을 이용해 Dynamic Workflow를 Script나 CI/CD에서 직접 실행하고 JSON 입력과 권한을 설정하는 방법을 확인할 수 있습니다.

https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-programmatic-reference