이슈 본문을 읽는 에이전트에게 저장소 쓰기 토큰까지 줘야 할까요? GitHub Agentic Workflows를 검토할 때 먼저 볼 것은 프롬프트의 문장보다, 에이전트의 요청이 실제 GitHub 변경으로 넘어가는 경계입니다.

10월 28일 공식 GA 발표는 Markdown으로 정의한 작업을 Actions YAML로 컴파일하는 방식을 정식 제공한다고 설명합니다. 기본 읽기 권한, 격리 실행, 방화벽, 출력 검증을 함께 제시합니다. 이 글은 10월 29일 문서 검토이며 제품 실행 후기가 아닙니다.

읽기 권한과 쓰기 실행은 서로 다른 곳에 있다

Safe Outputs 문서의 핵심은 에이전트가 구조화된 작업 요청을 내고, 별도의 권한 통제 job이 허용된 요청을 실행한다는 것입니다. 에이전트 프로세스가 직접 쓰지 않더라도 워크플로는 이슈나 PR을 만들 수 있습니다.

외부 이슈·코드 → 에이전트가 분석 → 구조화된 변경 요청
                                      ↓
                              검증·정책 경계
                                      ↓
                         쓰기 권한을 가진 별도 job

도식은 공식 UI가 아닌 문서에 근거한 설명입니다. 여기서 구분할 대상은 요청을 만드는 주체와 변경 권한을 행사하는 주체입니다. 보고서에 악성 링크나 부정확한 결론이 들어가는 문제까지 읽기 전용 토큰 하나로 해결되지는 않습니다. 실행 권한뿐 아니라 게시할 내용과 대상도 검토해야 합니다.

특히 같은 문서에는 safe-outputs를 생략하거나 시스템 출력만 두면 기본 create-issue가 활성화될 수 있다고 나옵니다. “쓰기 옵션을 추가하지 않았다”는 사실만으로 외부 변경이 없다고 판단하면 곤란합니다.

별도로 발표된 Copilot Automations의 개선 제안은 구성이 Git과 별도로 저장됩니다. Markdown과 생성된 lock 파일을 함께 리뷰하는 이 경로와 구별하세요. “에이전트 자동화”라는 이름이 같아도 변경 기록과 승인 근거를 남기는 위치가 다릅니다.

생성물 리뷰를 위한 다섯 가지 질문

다음은 CodeBridge의 검토 기준입니다. 특정 컴파일 결과를 관찰한 보고가 아닙니다.

검토 대상 찾아야 할 증거 막으려는 실수
트리거와 checkout 어떤 이벤트가 어떤 ref의 코드를 실행하는가 외부 PR 코드가 권한 있는 문맥에서 실행됨
에이전트 job 실제 토큰 권한, 노출되는 secrets, 허용된 네트워크 프롬프트 제한만 믿고 자격증명을 전달함
출력 처리 job 허용 작업 종류, 대상 저장소, 호출 한도 “분석만” 요청했는데 이슈·PR까지 생성됨
결과 검증 거부 시 동작, 로그, 검토할 diff 검증 실패를 성공으로 오인함
재실행 중복 요청 식별과 이미 수행한 작업 기록 재시도가 같은 이슈를 계속 만듦

이 표를 쓰는 현실적인 방법은 작은 읽기 작업 하나를 고른 뒤 각 행에 생성된 job 이름과 해당 설정을 적는 것입니다. 근거를 찾지 못한 행이 있으면 권한 확대를 미룹니다. 테스트 실행처럼 이미 결정적인 도구로 처리되는 작업에는 에이전트를 추가할 이유부터 확인하는 편이 낫습니다.

컴파일을 확인하는 로컬 절차

Quickstart는 Markdown 원본과 생성된 .lock.yml을 함께 커밋하도록 안내합니다. 컴파일 산출물이 실제 실행 설정이기 때문입니다. 아래는 Git·GitHub CLI·gh aw 설치와 기존 워크플로 원본을 전제한 미실행 예시입니다. 설치나 워크플로 실행은 이 글에서 수행하지 않았습니다.

# 기존 워크플로가 있는 검토용 브랜치에서 실행
gh aw compile
git status --short -- .github/workflows
git diff -- .github/workflows

예상 결과는 해당 버전과 설정에 맞는 생성 파일 및 diff입니다. 새 파일은 git diff에 본문이 나타나지 않으므로 git status에 표시된 .lock.yml을 직접 열어야 합니다. 이 명령 묶음에는 push나 원격 실행이 없습니다. 컴파일 자체의 통과가 출력의 안전성을 보증하지도 않습니다.

처음부터 “매일 이슈 생성”을 켜기보다, 필요 없는 출력을 명시적으로 끄는 구성을 검토하세요. 공식 문서의 create-issue: false는 기본 이슈 생성 출력을 끄는 설정이며, 다른 쓰기 출력을 모두 막는 전역 스위치는 아닙니다. 마찬가지로 방화벽 허용 목록은 목적지를 제한하는 장치이지 그 목적지로 보내는 모든 데이터의 적절성을 판정하는 장치는 아닙니다.

도입 기준은 생성된 변경을 설명할 수 있는가다

실패 로그를 읽고 원인 후보를 보고하는 작업은 시작점으로 적합합니다. 자동 수정 PR은 그 다음입니다. 분석 결과가 자주 틀리는 상태에서 쓰기 권한을 넓히면 검토 비용도 함께 커집니다. 성공률뿐 아니라 오분류 후 복구 시간과 중복 출력까지 관찰해야 합니다.

GA 발표에 인용된 고객의 생산성 사례는 해당 조직의 보고입니다. 우리 팀의 절감 시간이나 오류 감소율로 옮겨 적을 근거는 아닙니다. 이 글에서도 벤치마크나 비용을 실측하지 않았습니다.

기존 Queue와 Ledger 글이 작업을 이어가는 상태를 다뤘다면, 이번 도입 판단의 질문은 “이 요청이 어디에서 실제 변경이 되는가”입니다. 그 경계를 원본과 .lock.yml 양쪽에서 설명할 수 있을 때 작은 작업부터 적용하세요.

실행과 검증을 분리하는 에이전트 설계를 더 배우려면 아래 공개 유료 강의가 연결됩니다. gh-aw 전용 강의로 소개하는 것은 아니며, 아래 링크는 홍보 링크입니다.