GitHub Agentic Workflows 정식 출시, 자동화 전에 볼 권한과 비용

새 이슈에 라벨을 붙이고 실패한 CI 로그에서 원인을 찾는 일은 저장소마다 반복됩니다(예시). GitHub은 2026년 10월 28일 변경 기록에서 이런 일을 GitHub Actions 안의 코딩 에이전트로 자동화하는 GitHub Agentic Workflows를 정식 출시(generally available)했다고 밝혔습니다. 자동화 내용을 자연어 Markdown 파일로 쓰면 GitHub Agentic Workflows가 표준 Actions YAML로 컴파일하며, 변경 기록은 이슈 분류, CI 실패 분석, 문서 갱신, 테스트 작성을 쓰임새로 듭니다.

이 글은 GitHub 변경 기록과 날짜 표시가 없는 GitHub Agentic Workflows 공식 문서를 바탕으로 정리했습니다. 필자는 이 도구를 직접 설치하거나 실행해 보지 않았습니다.

1. 정식 출시 대상과 준비 조건

변경 기록에 따르면 GitHub Agentic Workflows는 GitHub Next의 오픈소스 프로젝트이고, github.com의 GitHub Free, Team, Enterprise에서 정식으로 쓸 수 있습니다. 워크플로가 GitHub Actions로 실행되므로 이미 쓰는 러너 그룹과 정책 제약이 그대로 적용됩니다. 공식 빠른 시작 문서는 GitHub Copilot, Claude Code, OpenAI Codex, Google Gemini, Pi 가운데 하나를 엔진으로 고르게 하고, 쓰기 권한이 있는 저장소와 켜져 있는 GitHub Actions, GitHub CLI를 준비 조건으로 적었습니다.

변경 기록에 따르면 공개 프리뷰 이후 자체 호스팅 ARC 러너와 Docker-in-Docker 지원, 정식 기능이 된 gh aw forecast 예산 예측, 워크플로별 모델 공급자 선택, 모델 라우터, 마이크로 VM 격리가 추가됐습니다.

2. 기본으로 켜져 있는 안전장치

변경 기록은 에이전트가 무결성 필터(integrity filter) 규칙에 따라 GitHub 콘텐츠에 접근하고, 기본으로 읽기 전용 권한으로 실행되며, Agent Workflow Firewall 뒤의 격리된 컨테이너 안에서 실행된다고 설명합니다. 에이전트가 낸 결과는 safe outputs 절차로 검증되고, 별도의 위협 탐지(threat detection) 작업이 제안된 변경을 적용 전에 검사합니다.

단계 이름, 권한, 방화벽과 위협 탐지 동작은 GitHub 변경 기록과 GitHub Agentic Workflows 공식 문서(Permissions, Security Architecture, Safe Outputs)에서 옮겼습니다. 구획 배치와 문구 요약은 작성자가 했습니다.

권한 문서에 따르면 쓰기 작업은 safe outputs가 맡습니다. 에이전트는 이슈 만들기나 댓글 달기 같은 요청을 구조화된 출력으로 남기고, 권한이 따로 정해진 별도 작업이 허용된 요청만 실행합니다. 문서는 이렇게 나누면 감사 기록이 생기고, 에이전트가 잘못 동작해도 피해 범위가 줄며, 프롬프트 주입 방어에도 도움이 된다고 설명합니다. safe-outputs 설정이 없으면 이슈 생성(최대 1건)이 기본으로 켜집니다. 다만 safe outputs 문서는 설정에 따라 콘텐츠 게시, 메타데이터 수정, PR 병합까지 자동으로 실행될 수 있다고 적었습니다.

Agent Workflow Firewall은 에이전트를 컨테이너에 넣고 HTTP·HTTPS 트래픽을 도메인 허용 목록이 걸린 프록시로 보내 데이터 유출을 막습니다. 보안 구조 문서는 한계도 밝힙니다. 읽기 전용 GITHUB_TOKEN이 다른 자격 증명을 없애 주지는 않고, 도메인 허용은 목적지만 제한할 뿐 허용된 서비스로 가는 요청이 모두 안전하다는 뜻은 아니라고 적었습니다. 위협 탐지 작업은 기본값(continue-on-error: true)에서 경고 모드로 동작합니다. 보안 구조 문서에 따르면 위협이나 탐지기 실패가 있을 때 검토할 수 있는 출력에는 주석을 달고, 브랜치 푸시는 검토용 풀 리퀘스트로 바꾸며, 검토할 수 없는 작업은 중단합니다. 탐지기가 실패하거나 결과가 유효하지 않으면 깨끗하다는 판정이 아니라 보안 판정이 없는 상태라고 문서는 설명합니다.

3. Copilot 엔진의 라이선스와 비용 청구 경로

변경 기록은 기본 엔진인 GitHub Copilot CLI로 워크플로를 실행하려면 Copilot 라이선스가 필요하다고 밝혔습니다. 공식 Billing 문서에 따르면 실행 비용은 GitHub Actions 사용 시간과 엔진 공급자의 추론 비용으로 나뉘어 따로 청구되고, Actions 시간은 저장소를 소유한 조직이나 사용자에게 청구됩니다. 엔진별 인증과 추론 비용 청구처를 문서 기준으로 옮기면 다음과 같습니다.

엔진	인증 방식	추론 비용 청구처
Copilot(조직 청구)	워크플로 권한에 copilot-requests: write, 조직 Copilot 정책에서 조직 청구 허용	조직의 Copilot 테넌트에 AI 크레딧으로
Copilot(개인 청구)	COPILOT_GITHUB_TOKEN(Copilot Requests 읽기 권한의 세분화된 PAT)	PAT 소유자의 Copilot 사용 권한 범위
Claude Code	ANTHROPIC_API_KEY 또는 Anthropic WIF	Anthropic 계정
OpenAI Codex	OPENAI_API_KEY(CODEX_API_KEY도 가능)	OpenAI 계정
Google Gemini	GEMINI_API_KEY 또는 Google WIF	Google Cloud·AI Studio 계정

조직 청구를 쓰려면 Billing 문서가 적은 조건을 모두 갖춰야 합니다. 조직 Copilot 정책에서 Copilot CLI의 "Allow use of Copilot CLI billed to the organization"을 켜고, 워크플로 frontmatter의 permissions에 copilot-requests: write를 직접 선언한 뒤, 컴파일한 .lock.yml을 저장소에 커밋해야 합니다. 컴파일러는 이 권한을 자동으로 넣지 않습니다. 조건이 하나라도 빠지면 개인 PAT 방식으로 설정해야 하고, 이때 추론 비용은 PAT 주인의 Copilot 사용 권한에 귀속됩니다. AI 크레딧 단가와 요금제별 차이는 GitHub의 Copilot 요금 문서를 따로 확인하십시오.

4. 실행 횟수와 1회 비용에 상한 걸기

비용 관리 문서는 결정적 도구로 풀 수 있는 일에는 그 도구를 쓰고 에이전트는 필요할 때만 쓰라고 권합니다. 문서는 대부분의 워크플로에서 비용을 가장 크게 좌우하는 것이 실행 빈도라고 설명합니다. push, check_run, check_suite 트리거는 바쁜 저장소에서 하루 수백 번 실행될 수 있어 위험이 높고, pull_request와 issues는 그다음으로 위험이 높으며, schedule과 workflow_dispatch는 예산을 세우기 쉽다고 분류합니다. 비용을 평가하는 동안에는 schedule이나 workflow_dispatch로 시작하라고 안내합니다.

비용 관리 문서에 따르면 기본 안전장치로 워크플로 실행 1회당 1000 AI 크레딧, 워크플로당 하루(24시간) 5000 AI 크레딧 상한이 적용되고, 1회 실행 상한은 frontmatter의 max-ai-credits로 바꿀 수 있습니다. 위협 탐지 실행에는 기본 400 AI 크레딧의 별도 상한이 있습니다. 문서의 대략 추정치로는 월 20건 이슈 분류에 Actions 약 10분이 쓰이고, 추론 비용은 모델과 프롬프트 크기에 따라 달라진다고만 적혀 있습니다. gh aw logs가 보여 주는 AI 크레딧 값은 models.dev 가격 자료로 계산한 추정치라 실제 청구와 다를 수 있으니, 공급자 청구 화면에서 확인하라고 문서는 안내합니다.

5. 이번 주에 해 볼 첫 단계

이슈 분류와 CI 실패 분석 가운데 하나를 골라, 공식 문서 갤러리의 해당 예시 워크플로를 읽어 보십시오. 쓸 엔진을 정하고, Copilot이라면 위 조직 청구 조건을 관리자와 확인합니다. 첫 시험은 schedule이나 workflow_dispatch 트리거로 시작하고 max-ai-credits에 기본값 1000보다 낮은 상한을 걸어 두면 됩니다. safe-outputs에는 이슈 생성이나 댓글처럼 사람이 결과를 보고 판단할 수 있는 출력만 열어 두고, PR 병합 같은 출력은 시험 결과를 본 뒤 정하십시오.