GitHub Agentic Workflows 정식 출시: Markdown 자동화와 쓰기 권한을 분리하기

AI가 제안한 작업이 검증 경계를 거쳐 나가는 모습을 표현한 생성형 개념 이미지다. 실제 GitHub 화면이 아니다.

이슈를 정리하고 저장소 상태를 요약하는 일은 반복적이다. 그렇다고 AI에게 저장소 쓰기 권한부터 주기는 부담스럽다. GitHub Agentic Workflows를 도입할 때의 핵심은 자연어로 자동화를 만드는 것보다, AI의 판단과 실제 변경을 분리하는 것이다.

GitHub는 October 28, 2026 Agentic Workflows의 정식 출시를 발표했다. Markdown으로 작성한 지시를 GitHub Actions 워크플로로 컴파일하는 도구다. github.com의 Free·Team·Enterprise에서 사용할 수 있으며, 기본 Copilot CLI 엔진에는 Copilot 라이선스가 필요하다. “기능을 사용할 수 있다”와 “실행 비용이 없다”는 다른 뜻이다. 공식 출시 발표

Markdown도 코드처럼 검토해야 한다

작업의 설명은 Markdown 본문에, 트리거·도구·권한 같은 설정은 YAML frontmatter에 둔다. 컴파일 결과는 일반 Actions YAML이다. 자연어 파일만 리뷰하고 끝내지 말고, 생성된 실행 정의까지 함께 확인해야 한다.

기본 흐름은 공식 샘플을 가져오고, 자신의 저장소에 맞게 좁힌 뒤 컴파일하는 것이다. 아래 명령은 독자가 승인된 테스트 저장소에서 따라 할 절차이며 이 글을 작성하면서 실행한 결과가 아니다.

마법사는 엔진과 인증 등을 설정하고 파일을 추가할 수 있다. 마지막 실행 선택에서 바로 가동하지 말고, 생성된 .github/workflows/repo-status.md를 먼저 검토한다. 공식 샘플은 상태 보고 이슈를 만들 수 있으므로 “단순히 읽기만 하는 샘플”이라고 생각하면 안 된다. 조직의 인증·비용 정책을 확인하기 전에는 새로운 토큰을 만들거나 실행을 승인하지 않는다. 공식 Quick Start

read-only와 아무 변경도 없다는 말은 다르다

Safe outputs는 에이전트가 구조화된 작업 요청을 내고, 별도의 권한을 가진 작업이 허용된 요청을 실행하는 구조다. 에이전트 자체에 직접 쓰기 권한을 주지 않아도 이슈·댓글·PR이 생성될 수 있다.

특히 safe-outputs를 생략했다고 출력까지 비활성화되는 것은 아니다. 문서상 기본 이슈 생성이 활성화될 수 있다. 어떤 출력이 허용되는지 명시적으로 확인해야 한다. Safe라는 이름도 모든 결과에 사람의 승인이 필요하다는 보장은 아니다. 실제 검토 요구는 설정과 정책 게이트에 달려 있다. Safe Outputs 문서

처음에는 기존 frontmatter의 safe-outputs에 다음처럼 전역 staging을 켜는 방식을 권한다. 아래는 전체 워크플로가 아니라 기존 설정에 병합할 일부다. 같은 YAML 키를 두 번 만들지 않는다.

이 모드는 기본 제공 출력의 실제 쓰기 대신 Actions 단계 요약에 미리보기를 남긴다. 그러나 워크플로와 AI 분석 자체는 실행된다. 커스텀 코드, 외부 MCP, 별도 인증정보, 캐시·메모리 저장까지 막는 샌드박스는 아니다. 커스텀 출력 작업은 staging 신호를 직접 처리해야 한다. 따라서 staging만 켜고 외부 부작용이나 과금을 무시해서는 안 된다. Staged Mode 문서

컴파일 성공과 운영 성공을 나누어 확인한다

설정을 수정한 다음에는 컴파일하고 Markdown과 lock 파일의 차이를 함께 리뷰한다.

Frontmatter를 바꿨다면 다시 컴파일해야 한다. 원본만 수정하고 이전 lock 파일을 배포하면 의도와 실행이 어긋날 수 있다. Quick Start의 수정 절차

허용된 테스트 실행 후에는 상태와 로그를 별도로 확인한다. CLI는 실행 상태 조회, 로그 수집, 개별 실행 감사 기능을 제공한다. 아래 명령의 성공 여부만으로 결과 내용까지 올바르다고 판정하지 않는다. CLI Commands

실무 검토에서는 다음 질문을 추가하는 편이 좋다. 이는 제품의 자동 보장이 아니라 이 글에서 제안하는 도입 기준이다.

• 보고서의 각 결론이 실제 이슈나 커밋으로 연결되는가.

• 동일한 입력을 다시 처리했을 때 중복 이슈를 만들지 않는가.

• 변경할 필요가 없을 때도 정상적인 무작업 결과를 남기는가.

• 예상하지 않은 파일 접근이나 외부 전송이 없는가.

• 공개 이슈나 로그에 비밀값·비공개 업무 내용이 섞이지 않는가.

특히 외부 PR을 처리할 때는 트리거와 checkout 대상을 함께 검토해야 한다. 공식 시작 문서는 pull_request_target의 특권 컨텍스트에서 신뢰하지 않는 PR 코드를 실행하는 위험을 경고한다. 자연어 자동화도 기존 Actions 보안 규칙의 예외가 아니다. Quick Start 보안 주의

비용은 출력 개수보다 실행 횟수에서 먼저 본다

비용에는 Actions 실행 시간과 AI 추론 비용이 함께 들어간다. 이슈가 생성되지 않은 실행도 비용이 생길 수 있다. 비용 문서는 결정적인 규칙으로 해결할 수 있는 작업은 먼저 일반 도구로 처리하고, 필요한 경우에만 에이전트를 호출하도록 권한다.

gh aw logs와 gh aw audit의 사용량을 확인하되, AIC 추정치가 공급자의 실제 청구와 정확히 일치한다고 가정하지 않는다. 최종 비용은 해당 공급자의 청구 화면과 대조해야 한다. Cost Management

처음부터 모든 이슈 이벤트에 연결하기보다 대상·빈도·출력 종류를 좁히는 편을 권한다. 충분한 미리보기 검토 뒤 필요한 출력만 실제 쓰기로 전환한다. 성공률보다 먼저 확인할 것은 “틀렸을 때 어디까지 바꿀 수 있는가”다.

이 글에서 실제로 확인한 범위

공식 출시 발표와 위 문서를 October 29, 2026 확인했다. 로컬에서는 gh --version으로 GitHub CLI 2.46.0을 확인했다. gh extension list는 인증 안내를 반환해 확장 설치 상태를 확인하지 못했다.

새 인증정보를 만들거나 gh-aw를 설치·컴파일·실행하지 않았다. 따라서 이 글은 공식 문서에 근거한 도입 절차와 검토 제안이며, 실제 워크플로 실행 성공·성능·과금 측정 보고서가 아니다.