GitHub Actions 과거 검사 기록, 보존 기간을 늘리면 복구될까?

기간을 늘려도 이미 삭제된 이력은 돌아오지 않는다

지난 릴리스의 PR을 열었는데 검사 결과가 없다면, 보존 기간을 늘리는 작업을 복구 수단으로 생각하면 안 된다. GitHub는 10월 1일 시행 공지에서 설정을 바꿔도 이미 제거한 데이터는 복원되지 않는다고 명시했다.

또한 조직 보존 문서에 따르면 사용자가 바꾼 기간은 새로 만들어지는 기록에 적용된다. 기존 객체의 보존 기간까지 소급해 바꾸는 설정이 아니다. ‘앞으로 더 오래 남긴다’와 ‘과거 기록을 되찾는다’는 서로 다른 작업이다.

실행 이력이 보이지 않는 원인을 개별 저장소에서 확인할 때도 이 구분이 필요하다. 보존 정책으로 삭제된 경우에는 기간 조정으로 되돌릴 수 없지만, 화면에서 찾지 못했다는 사실만으로 해당 기록이 자동 삭제됐다고 확정할 수는 없다.

GitHub 밖에서 돌린 CI도 결과를 올렸다면 대상이다

이번 변경으로 아티팩트와 로그에 적용하던 보존 설정이 검사, 워크플로 실행, 커밋 상태까지 관리한다. GitHub Actions뿐 아니라 타사 애플리케이션이 GitHub에 만든 검사와 상태도 포함된다. 외부 CI 서버를 쓴다는 이유로 GitHub에 표시되는 과거 결과가 영구 보관되지는 않는다.

Actions 로그 문서는 실행 하나마다 check suite가 생기고, 그 안에 job별 check run이 들어간다고 설명한다. 워크플로 실행 페이지, 검사 결과, 로그는 연결돼 있지만 각각 무엇을 남겨야 하는지는 구분해야 한다. 로그 파일을 확보했다고 모든 검사 메타데이터나 PR 대화까지 보관한 것은 아니다.

오래된 결과를 영구적인 증거로 전제하는 자동화도 영향을 받을 수 있다. 2025년 커뮤니티 질문에는 2년 전 병합한 PR의 커밋 상태가 API에서 없어져 CI가 테스트를 다시 실행했다는 사례가 있다. 이는 이번 10월 변경 이전의 사례지만, 과거 상태가 계속 조회된다는 전제에 의존할 때 생길 문제를 보여 준다.

공개 저장소는 최대 90일이며 상위 설정도 적용된다

기본 보존 기간은 90일이다. 변경할 수 있는 범위와 실제 허용되는 최댓값은 저장소 유형과 조직·엔터프라이즈 설정에 따라 정해진다. 저장소 설정 문서의 범위는 다음과 같다.

저장소의 Settings → Actions → General에서 검사·실행·상태·아티팩트·로그 보존 항목에 일수를 입력하고 Save로 저장한다. 같은 화면의 캐시 보존 설정은 별도 항목이므로 혼동하지 않아야 한다.

예를 들어 비공개 저장소에서 새 기록을 180일 남기려면 상위 조직·엔터프라이즈의 제한도 180일을 허용해야 한다. 이는 설정 관계를 설명하는 예시다. 공개 저장소의 90일 상한을 저장소 설정만으로 늘리는 방법은 아니다.

필요한 로그는 삭제되기 전에 다운로드한다

남아 있는 실행 로그는 저장소 읽기 권한으로 다운로드할 수 있다. Actions에서 워크플로와 실행을 고른 뒤 해당 job을 열고, 로그 오른쪽 위 메뉴의 Download log archive를 선택한다. 이는 공식 로그 다운로드 절차다.

일부 job만 재실행한 경우에는 내려받은 아카이브에 재실행한 job의 로그만 포함된다. 전체 시도의 로그가 필요하면 다른 job이 실행됐던 이전 시도의 아카이브도 확보해야 한다.

릴리스 검토에 무엇이 필요한지에 따라 로그, 검사 결과, 외부 CI의 원본 기록을 나눠 보관하는 편이 낫다. 우선 남아 있는 자료를 확보하고, 그다음 새 기록의 보존 기간을 맞춘다. 보존 설정은 앞으로의 기록을 남기는 장치이지, 사라진 이력을 되찾는 버튼이 아니다.