깃허브에서 재현 정보가 빠진 이슈에만 댓글 달기

버그 신고에 “저장을 누르면 멈춘다”는 한 줄만 있다면, 어떤 순서로 눌렀는지와 원래 기대한 동작부터 물어야 한다. 깃허브가 10월 28일 정식 공개한 Agentic Workflows로 이 질문을 자동으로 요청하는 설정 파일을 만들고 컴파일했다. 이슈에 재현 순서·기대 결과·실제 결과가 모두 있으면 그대로 두고, 빈 항목이 있을 때만 댓글 한 건을 요청하는 예제다.

깃허브에서 이슈는 버그나 요청을 기록하는 게시물이고, Actions는 저장소 안에서 작업을 자동 실행하는 기능이다. 이 예제는 댓글을 실제로 게시하기 전에 자기 컴퓨터에서 설정을 검사하는 데까지 따라 할 수 있다. 확인에는 Windows용 GitHub CLI 2.103.3과 공식 확장 1.0.1을 썼다.

먼저, 어떤 이슈에 몇 번 답할지 정한다

연습용 Git 저장소의 맨 위 폴더에서 시작한다. 터미널에 gh --version을 입력해 GitHub CLI가 설치됐는지 확인한다. 공식 시작 안내는 2.0.0 이상을 요구한다. gh auth status로 로그인 상태를 확인한 뒤 gh extension install github/gh-aw로 확장을 설치한다. 다음 명령인 gh aw --version까지 버전 번호가 나와야 준비가 끝난다.

저장소 안에 .github/workflows 폴더를 만들고 아래 내용을 issue-check.md라는 이름으로 저장한다. 파일명 맨 뒤에 .txt가 붙지 않게 한다. 맨 위와 중간의 대시 세 개 사이에는 실행 조건을, 두 번째 대시 아래에는 사람이 한국어로 작업 지시를 쓴다. 들여쓰기도 설정의 일부이므로 복사할 때 줄바꿈과 앞 공백을 유지한다.

---
on:
  issues:
    types: [opened]
permissions:
  contents: read
  issues: read
  copilot-requests: none
engine: copilot
tools:
  github:
    toolsets: [issues]
safe-outputs:
  add-comment:
    max: 1
---

# 이슈 재현 정보 확인
현재 이슈의 제목과 본문에서 재현 순서, 기대 결과, 실제 결과를 확인한다.
빠진 항목만 한 댓글에 한국어로 질문한다.
세 항목이 모두 있으면 noop으로 완료한다.

편집기에서 선택한 max: 1은 한 번 실행할 때 AI가 요청할 수 있는 새 댓글의 상한이다. 바로 아래 한국어 지시는 그 한 번을 언제 쓸지 정한다. 가령 재현 순서와 실제 결과만 적힌 신고라면 기대 결과만 물어보도록 했다. 필요한 정보가 모두 있을 때의 noop은 별도의 댓글을 요구하지 않고 마친다는 뜻이다.

on 아래의 issues와 opened는 새 이슈를 열 때만 작업을 시작하라는 조건이다. 이미 있는 이슈를 수정하거나 닫았다 다시 여는 일은 이 설정에 포함되지 않는다. 기본 실행 자격도 있다. 관리자(admin), 유지보수 담당(maintainer), 쓰기(write) 권한 중 하나가 있는 사람이 연 이슈가 대상이다. 외부 방문자가 올린 첫 신고까지 검사한다고 보고 시험하면 실행 결과가 달라진다.

컴파일이 성공하면 어떤 권한이 생길까

파일을 저장한 뒤 같은 폴더에서 gh aw compile issue-check를 실행한다. 이어서 gh aw list를 입력하면 GitHub 서버에 접속해 이슈를 열지 않고도 로컬 파일의 상태를 볼 수 있다. 처음 컴파일할 때는 재사용할 공개 액션의 버전을 정확한 커밋에 연결하려고 인터넷이 필요할 수 있다. 실습에서는 버전을 한 번 확인한 뒤 외부 연결을 막고 다시 컴파일해도 같은 결과 파일이 나왔다.

터미널에서 gh aw list를 실행하면 issue-check 옆에 엔진은 copilot, compiled는 Yes로 나온다. 설정 파일 하나가 오류나 경고 없이 컴파일됐고, 그 결과인 issue-check.lock.yml이 원본 바로 옆에 생겼다. 이슈를 읽고 댓글을 요청하는 과정은 저장소에 올린 뒤 Actions가 실행될 때 시작된다.

생성된 파일을 열어 jobs 아래의 agent와 safe_outputs를 차례로 찾는다. 이 예제의 agent에는 contents: read, issues: read가 들어 있었다. AI가 코드나 이슈를 직접 고칠 권한은 없다. 반면 safe_outputs에는 issues: write와 pull-requests: write가 보인다. 댓글 처리가 이슈와 풀 리퀘스트를 모두 지원하기 때문이다. 이 설정에서 게시 대상은 작업을 일으킨 이슈이고, 본문 수정이나 라벨 변경은 허용한 출력에 들어 있지 않다.

두 작업 사이에는 제안된 출력을 검사하는 detection이 있다. 검사 통과와 사람의 승인은 다른 절차다. 이 예제에는 사람의 승인 단계를 추가하지 않았으므로 정상 요청은 후속 작업이 자동 게시할 수 있다. 저장소 관리자라면 파일 전체의 permissions와 각 작업의 권한을 함께 보는 편이 정확하다. AI에 읽기만 줬다고 해서 결과를 게시하는 작업의 토큰까지 읽기 전용인 것은 아니다.

실제 이슈로 돌리기 전

기본 Copilot 엔진을 쓰려면 Copilot 라이선스가 필요하다. 이 예제의 copilot-requests: none은 개인 자격으로 인증하는 구성이다. 개인 계정에서 Copilot Requests 권한을 Read로 준 세분화 토큰을 만들고, 저장소 Settings의 Secrets and variables → Actions에 COPILOT_GITHUB_TOKEN이라는 이름으로 등록한다. 조직 중앙 청구를 선택하면 필요한 정책과 권한이 달라진다.

실제 적용 때는 원본 .md와 생성된 .lock.yml을 함께 검토해 기본 브랜치에 반영한다. 이번 실습에서 함께 생성된 .github/aw/actions-lock.json은 사용한 액션 버전을 고정한 기록이다. 그 뒤 대상 권한이 있는 계정으로 새 이슈를 열고 Actions 탭에서 실행 내역을 확인한다. 앞 설정을 바꾸면 다시 컴파일해야 하고, 구분선 아래의 질문 문구만 고쳤다면 다음 실행 때 새 문구를 읽는다.

원격 실행에서는 저장소의 Actions 사용 시간과 AI 모델 사용량이 따로 계산된다. 공개 저장소에서 표준 GitHub 호스팅 실행기를 쓸 때처럼 Actions 시간이 무료인 경우에도 개인 토큰을 쓴 모델 사용량에는 그 토큰 소유자의 Copilot 조건이 적용된다. 로컬에서 확인한 컴파일 성공만으로 댓글의 답변 내용이나 실제 청구액이 정해지지는 않는다.