2월 16일 오후, GitHub Next 팀의 블로그에 조용히 하나가 올라왔다. “Agentic Workflows — Technical Preview.” 제목만 보면 평범한 기능 업데이트 같았다. 그런데 The Register, InfoQ, InfoWorld, TechCrunch가 같은 주에 동시에 다뤘다. 뭔가 심상치 않다 싶어서 직접 파봤다.
결론부터 말하면, 이건 단순한 CI/CD 플러그인이 아니다. 코딩 에이전트가 GitHub Actions 러너 안에서 살면서, 레포를 스스로 관리하는 구조다.
Agentic Workflows가 뭘 하는 건가
기존 CI/CD와의 결정적 차이
기존 GitHub Actions는 YAML에 적힌 대로만 움직인다. on: push → run: test → deploy. 입력이 정해져 있고, 출력도 정해져 있다. 에이전트가 끼어들 틈이 없다.
Agentic Workflows는 다르다. 마크다운으로 의도(intent)를 기술하면, AI 코딩 에이전트가 그 의도를 해석해서 실행한다. YAML이 아니라 자연어에 가깝다.
# .github/workflows/triage.md (실제 워크플로우 파일)
name: Issue Triage
trigger: issues.opened
intent: |
새로 열린 이슈를 분석해서:
1. bug/feature/question 라벨을 자동 부여
2. 관련 코드 파일을 찾아 코멘트로 안내
3. 중복 이슈가 있으면 링크 연결
이게 진짜 돌아간다. GitHub Actions 러너 안에서 코딩 에이전트가 레포 컨텍스트를 읽고, 판단하고, 액션을 취한다.
5가지 핵심 유스케이스
GitHub Next 팀이 공개한 주요 시나리오를 정리하면 이렇다:
| 유스케이스 | 기존 방식 | Agentic 방식 |
|---|---|---|
| 이슈 분류 | 수동 라벨링 or 키워드 매칭 | 코드 컨텍스트 기반 자동 분류 |
| CI 실패 디버깅 | 로그 직접 분석 | 에이전트가 원인 분석 + 수정 PR 제안 |
| 문서 업데이트 | PR 머지 후 수동 반영 | 코드 변경 감지 → 문서 자동 수정 |
| 테스트 커버리지 | 수동으로 테스트 추가 | 미커버 코드 탐지 → 테스트 자동 생성 |
| 코드 리뷰 보조 | 린터 + 정적 분석 | 아키텍처 레벨 리뷰 코멘트 |
이 중에서 CI 실패 디버깅이 가장 파괴적이다. 빌드가 깨졌을 때 에이전트가 로그를 분석하고, 원인을 찾고, 수정 PR까지 올린다. 이전에 다뤘던 Claude Code 자동화 7단계에서 Level 6(이벤트 기반 자동화)에 해당하는 영역이 GitHub 플랫폼 레벨에서 네이티브로 구현된 셈이다.
보안은 어떻게 잡았나
샌드박스 실행 + Secure Output
AI 에이전트가 레포 안에서 자유롭게 돌아다닌다고? 당연히 보안이 첫 번째 질문이다.
GitHub Next와 Microsoft Research가 공동으로 설계한 보안 모델의 핵심은 두 가지다:
┌─────────────────────────────┐
│ GitHub Actions Runner │
│ ┌───────────────────────┐ │
│ │ Sandboxed Container │ │
│ │ ┌─────────────────┐ │ │
│ │ │ Coding Agent │ │ │
│ │ │ (제한된 권한) │ │ │
│ │ └─────────────────┘ │ │
│ │ • 읽기: 레포 전체 O │ │
│ │ • 쓰기: PR/코멘트만 O │ │
│ │ • 직접 머지: X │ │
│ │ • 시크릿 접근: X │ │
│ └───────────────────────┘ │
│ Secure Output Layer │
│ → 에이전트 출력 검증 후 반영 │
└─────────────────────────────┘
Secure Output이라는 개념이 눈에 띈다. 에이전트가 생성한 결과물(PR, 코멘트, 라벨)을 바로 반영하지 않고, 중간 검증 레이어를 거친다. 프롬프트 인젝션으로 에이전트를 조작해서 악성 코드를 머지시키는 공격을 차단하기 위한 장치다.
Eddie Aftandilian(GitHub 수석 연구원)의 표현을 빌리면: “Continuous AI — 기존 CI/CD의 에이전트 진화”라고 부른다.
실전에서 쓸 수 있나
아직은 “Technical Preview”
솔직히 말하면, 지금 당장 프로덕션에 넣기엔 이르다. GitHub Next 프로젝트 특성상 실험적 기능이고, 몇 가지 제약이 있다:
- 오픈소스 프로젝트만 지원 (프라이빗 레포는 추후)
- 코딩 에이전트 선택지 제한적 (현재 GitHub Copilot 기반)
- 비용 구조 미공개 (Actions 분 과금과 별도인지 불명확)
- 환각 리스크 — 에이전트가 잘못된 분류/수정을 할 수 있음
InfoWorld 기사에서도 “questions remain about controls over costs and access”라고 못 박았다. 비용과 접근 제어에 대한 답이 아직 없다는 뜻이다.
그래도 주목해야 하는 이유
하지만 방향 자체는 확실하다. 지금까지 AI 코딩 도구는 IDE 안에서 개발자 옆에 앉아 있었다. Copilot, Cursor, Claude Code 전부 그렇다. 개발자가 호출해야 움직인다.
Agentic Workflows는 이걸 뒤집는다. 에이전트가 레포 안에 상주하면서, 이벤트에 반응해서 스스로 움직인다. 개발자가 자고 있어도 이슈가 분류되고, CI가 고쳐지고, 문서가 업데이트된다.
TechCrunch는 이 흐름을 AI 코딩 도구가 오픈소스에 미치는 영향이라는 맥락에서 분석했다. “AI coding tools have caused as many problems as they have solved for open source” — AI 코딩 도구가 오픈소스에 문제만큼 해결도 가져왔다는 양면적 평가다.
CI/CD의 다음 단계가 시작됐다
GitHub Universe 2025에서 처음 언급되고, 4개월 만에 Technical Preview로 나온 속도를 보면, 올해 GA(정식 출시)도 불가능하진 않다. Microsoft Research가 공동으로 참여하고 있다는 점도 무게감을 더한다.
개발자가 해야 할 건 간단하다:
# 지금 당장 해볼 수 있는 것
# 1. 공식 레포 워치
gh repo watch github-next/agentic-workflows
# 2. 기존 워크플로우 중 자동화 가능한 것 리스트업
ls .github/workflows/
# 3. 이슈 분류, CI 실패 대응 — 매주 몇 시간 쓰는지 측정
매주 이슈 분류에 2시간, CI 디버깅에 3시간을 쓰고 있다면, 그 5시간이 0에 수렴하는 미래가 온다. 단, 에이전트가 올린 PR을 리뷰하는 시간이 새로 생길 거다. 결국 개발자의 역할이 “코드를 짜는 사람”에서 “에이전트를 감독하는 사람”으로 한 칸 더 이동한다.
재밌는 건, 이게 바로 얼마 전 GeekNews에서 42포인트를 받았던 “AI가 코드를 쏟아내는 시대, 물이 빠지면 누가 벌거벗고 수영했는지 드러난다“라는 글의 핵심 논지와 정확히 맞물린다는 점이다. CI/CD 파이프라인마저 에이전트가 관리하게 되면, 진짜 남는 건 설계를 이해하는 개발자뿐이다.