GitHub Actions 보관 정책 확대: 초록 체크를 릴리스 증거로 남기는 법
배포가 끝난 날에는 초록 체크와 실행 링크가 충분해 보입니다. 몇 달 뒤 같은 빌드를 재현하거나 고객 문의를 조사할 때 그 링크가 사라져 있다면, 통과했다는 기억과 확인할 수 있는 증거는 전혀 다른 자산이 됩니다.
GitHub는 2026년 10월 1일 Actions 보관 설정의 적용 범위를 검사, 워크플로 실행, 상태까지 확대한 사실을 공지했습니다. 로그와 산출물만 생각했던 팀이라면 이제 릴리스 기록을 어디에 남길지 다시 정해야 합니다. 아래 운영 절차는 공식 변경을 바탕으로 한 제안이며 GitHub의 필수 규칙은 아닙니다.
변경된 보관 범위부터 확인하기
검사·실행·상태는 설정된 기간을 넘으면 자동 정리되며, 서드파티 애플리케이션이 만든 검사와 상태도 대상입니다. 저장소 설정은 조직·엔터프라이즈 상한의 영향을 받습니다. 공개 저장소의 최대 기간은 90일이며 설정 변경으로 이미 제거된 기록이 복원되지는 않습니다.
지금 필요한 질문은 기간을 무조건 늘릴 것인가가 아닙니다. 출시 근거가 워크플로 URL 하나에만 있는지 먼저 찾아보세요. 코드 서명 확인, 테스트 결과, 승인 기록, 산출물 해시가 서로 다른 시스템에 있다면 어느 링크가 사라져도 조사할 수 있는지 살펴야 합니다.
릴리스 한 건의 증거 묶음 만들기
제가 권하는 최소 묶음은 commit SHA, 릴리스 이름, 실행 ID와 URL, 결과 시각, 테스트 요약, 산출물 해시입니다. 사람이 승인했다면 승인 주체와 대상을 기록하되 비밀번호·토큰·개인정보가 담긴 원본 로그를 통째로 복사하지 않습니다. 보관할 목적과 접근 권한도 함께 정합니다.
체크가 통과했다는 한 줄은 무엇을 검사했는지 설명하지 못합니다. 예를 들어 테스트가 일부만 실행되었다면 범위를 적고, 재현에 필요한 런타임·의존성 잠금파일 정보를 남기세요. 저장소의 현재 파일이 아니라 출시 당시 파일을 가리켜야 나중의 코드 변경과 혼동하지 않습니다.
삭제보다 앞서 내보내기 검증하기
대상 저장소 하나와 출시 한 건을 골라 작은 시범을 진행합니다. 보관 설정과 조직 상한을 읽고 필요한 요약만 별도 기록으로 저장한 뒤, 원래 실행 링크를 열지 않고도 다른 사람이 출시를 설명할 수 있는지 확인합니다. 자동 수집을 붙이기 전에 이 읽기 검증이 먼저입니다.
내보내기는 새 보안 경계가 됩니다. 보존 기간, 담당자, 수정 권한, 비밀값 제거 기준을 정하지 않은 채 로그를 다른 저장소에 옮기면 조사 편의와 함께 불필요한 노출도 늘어납니다. 모든 기록을 영구 보존하기보다 배포 근거와 단기 디버깅 자료를 목적별로 나누세요.
사라진 기록을 곧바로 실패로 읽지 않기
운영 질문은 '검사가 없으니 실패했는가'가 아니라 '만료·권한·조회 조건 중 무엇을 확인했는가'입니다. API 빈 결과만으로 과거 테스트가 없었다고 결론 내리지 말고 당시 실행 ID, 설정, 별도 릴리스 근거를 대조하세요. 이 글은 특정 커뮤니티의 공감 수를 증거로 삼지 않으며, 그 질문을 실무 점검 가설로 다룹니다.
이번 주에는 출시 기록 템플릿에 증거 위치와 보존 기한을 추가하고 한 건을 실제로 읽어 보세요. CI 링크를 오래 보관하는 것만으로 모든 감사 요구를 충족한다고 보장할 수는 없습니다. 팀이 필요한 설명을 제때 복원할 수 있는지 확인하는 것이 이번 변경에 대응하는 실질적인 목표입니다.