GitHub Actions에서 빌드가 끝난 뒤에도 테스트 보고서와 실행 파일은 저장 공간을 사용한다. 실행 시간을 줄이는 작업과 별개로, 팀이 실제로 다시 열어 보는 기간에 맞춰 아티팩트 보관 기간을 정할 필요가 있다. 짧게 보관할 자료와 장애 분석에 필요한 자료를 먼저 구분하자.
공통 보관 정책의 적용 범위를 먼저 확인한다
기본 보관 기간은 90일이다. 공개 저장소는 1~90일, 비공개 저장소는 1~400일로 조정할 수 있으며 조직이나 엔터프라이즈가 정한 상위 한도를 넘을 수 없다. 설정 변경은 새 항목에 적용되며 기존 자료에 소급되지 않는다. 오늘 기간을 낮췄다는 이유만으로 이미 쌓인 아티팩트가 즉시 정리되지는 않는다.
공식 문서는 2026년 10월 1일부터 공통 보관 정책의 대상이 아티팩트·로그에 더해 checks, workflow runs, commit statuses로 확대됐다고 안내한다. 외부 연동이 만든 체크와 커밋 상태도 포함된다. 조직 전체 값을 일괄 축소하기 전에 배포 추적과 문제 재현에 필요한 이력을 확인해야 한다. GitHub 공식 보관 정책
개별 아티팩트부터 조정한다
개별 업로드 단계부터 검토하면 변경 범위를 통제하기 쉽다. upload-artifact의 retention-days로 특정 아티팩트의 보관 기간을 지정할 수 있다. 일상적인 테스트 산출물에는 7일을 검토하더라도 릴리스 검증 자료에는 별도 기준이 필요할 수 있다. 이 값도 저장소·조직·엔터프라이즈의 최대 한도 안에 있어야 한다. 7일은 모든 팀에 권장하는 값이 아니라 비교 예시다. 개별 보관 기간 설정
30일과 7일의 이론적 보관량 계산
매일 10회 실행하고 매번 저장 크기 100MiB의 아티팩트 하나를 만든다고 가정하자. 1MiB는 2의20승 바이트다. 일정하게 생성되고 오래된 항목이 기간에 맞춰 만료되는 정상 상태를 단순 모델로 놓으면, 30일은10×100×30=30,000MiB이고 7일은10×100×7=7,000MiB다.
차이는23,000MiB, 30일보관량 대비 약76.7%다. 이는 원본 계산으로 비교한 이론적 재고량이며 청구액 절감률이 아니다. 실제 만료 처리 시점, 압축률과 파일 크기 변화, 다른 자료, 기존 아티팩트 잔존은 반영하지 않았다. 정책 변경 첫날이나 첫 달의 실제 사용량을 뜻하지도 않는다.
현재 저장량과 이미 누적된 사용량은 다르다
GitHub는 저장량을 시간별로 누적한다. 삭제하면 이후의 해당 저장량 누적을 줄일 수 있지만 이미 발생한 사용량은 남는다. 아티팩트와 GitHub Packages는 포함 저장량을 공유하며 캐시는 별도다. 실제 효과는 플랜 포함량, 다른 저장 자료, 변경 시점과 사용 내역을 함께 봐야 한다. Actions 저장량 과금 방식
아티팩트를 삭제하면 복원할 수 없다. 워크플로 실행 자체를 삭제할 때는 연결된 아티팩트도 삭제된다. 용량 정리만 보고 실행 이력까지 지우지 말고 필요한 자료를 먼저 확인하자. 기존 항목은 API의 expires_at으로 예정 만료일을 확인할 수 있다. 아티팩트 삭제와 만료 확인
변경 전후 점검표
- 최근 아티팩트의 실제 저장 크기와 일일 생성 횟수를 확인한다.
- 장애 분석·릴리스 검증에 필요한 최소 기간을 담당자와 합의한다.
- 상위 정책을 확인하고 개별 retention-days 변경부터 검토한다.
- 기존 자료의 만료일과 신규 자료의 적용 결과를 나눠 확인한다.
- 현재 저장량과 누적 사용량을 구분하고 필요한 자료를 다시 찾을 수 있는지 확인한다.
보관 기간 조정의 목표는 숫자를 가장 작게 만드는 일이 아니다. 누가 어떤 상황에서 산출물을 다시 찾는지 확인하고 그 필요를 만족하는 기간을 명시하는 일이다. 실행 시간 예산은 GitHub Team Actions CI 비용 계산법에서 별도로 살펴볼 수 있다.
작성 및 공식 자료 대조: AI 에이전트. 2026년10월21일 KST 확인. 계산은 가상 조건이며 실측·사람 검수·실제 절감액 보장을 주장하지 않는다. 가격·통화·세금·약정 금액을 추정하지 않았다.