GitHub Issue artifacts 공개: AI가 만든 계획과 조사 결과를 이슈에 남기기

계획과 조사 기록을 한 작업에 묶는 모습을 표현한 생성형 개념 이미지. 실제 GitHub 화면이 아니다.

AI 에이전트가 만든 계획을 다음 작업에서도 쓰려면 어디에 남겨야 할까. 대화나 이슈 댓글에만 넣으면 최종 판단과 오래된 초안이 섞이기 쉽다. GitHub의 새 Issue artifacts는 이런 산출물을 해당 이슈에 붙여 관리하는 기능이다.

GitHub는 October 28, 2026 공개 프리뷰를 발표했다. Markdown 문서, 외부 링크, HTML 시각화 등을 작업 이슈 옆에 두고 수정 이력을 보존한다. 코드 변경뿐 아니라 무엇을 조사했고 왜 이 계획을 선택했는지를 이어받는 데 활용할 수 있다. 공식 발표

먼저 저장할 자료를 좁힌다

처음부터 모든 대화 기록을 옮길 필요는 없다. 한 이슈에서 다음 세 가지 정도를 남기는 방식이 실용적이다.

구현 계획: 목표, 제외 범위, 완료 조건

조사 결과: 확인한 사실, 근거 링크, 아직 모르는 점

검증 기록: 수행한 테스트, 결과, 수행하지 못한 항목

이 목록은 기능의 필수 규격이 아니라 운영 제안이다. 에이전트가 만든 문서에도 검토자와 확인 날짜를 적으면, 다음 담당자가 추론과 검증된 사실을 구별하기 쉽다.

이슈는 논의의 중심으로 유지하고, 반복해서 읽을 결과물만 artifact로 정리한다. 코드와 함께 버전 관리해야 하는 설계 규칙은 저장소 문서로 유지하는 편이 나을 수 있다.

CLI에서 계획을 붙이는 예시

공식 CLI는 파일 하나마다 artifact 하나를 만든다. 문서 유형은 기본적으로 generic이며 계획은 plan 유형을 명시할 수 있다. 아래 명령은 공식 사용법을 바탕으로 구성한 예시이며 실제 저장소에 실행하지 않았다. OWNER/REPO와 이슈 번호는 자신이 변경 권한을 가진 대상으로 바꿔야 한다.

파일명 뒤에 이름을 붙이거나 --name 옵션을 사용하는 방식도 지원한다. 이미지는 --attach로 연결할 수 있다. 다만 로그나 캡처를 붙이기 전에는 토큰·계정·내부 주소가 포함됐는지 먼저 확인하는 편이 안전하다. 생성 명령 문서

저장했으면 다시 읽어 확인한다

명령 성공 메시지만으로 검증을 끝내지 않는다. 대상 이슈의 목록을 읽고 생성된 번호로 내용을 다시 확인한다.

목록은 번호 순서로 조회되며, view는 현재 버전과 수정 이력을 확인하는 데 쓰인다. 특정 시점의 판단을 재검토할 때는 최신 내용만 보지 말고 버전을 함께 확인한다. 목록 · 내용과 버전 조회

설치된 gh가 명령을 아는지부터 확인한다

웹 문서에 명령이 있다고 해서 로컬 CLI에도 바로 생기는 것은 아니다.

이 글을 준비한 환경에서는 gh 2.46.0이 설치되어 있었고, artifact 도움말 대신 기존 issue 명령 목록이 표시됐다. 따라서 위 생성·조회 예시의 실제 원격 동작은 이 환경에서 검증하지 않았다.

확인한 발표와 명령 문서에는 최소 CLI 버전 번호가 명시되지 않았다. 숫자를 추정하기보다 설치본의 도움말에서 명령 지원을 확인하고, 조직에서 승인한 배포 경로의 최신 CLI 문서와 맞추는 것이 낫다. CLI 문서도 이 기능이 프리뷰이며 예고 없이 바뀔 수 있다고 안내한다. CLI 기능 안내