GitHub Actions 기록은 언제 사라질까? 배포 증빙 보존을 자동화하는 방법

STEP 1
성공 표시도 영구 기록은 아니에요

배포 화면의 초록 체크는 그 시점의 결과를 확인하는 데 유용해요. 하지만 몇 달 뒤 같은 화면을 다시 열 수 있다는 보장은 별개의 문제입니다. 코드가 저장소에 남아 있어도 당시의 실행 기록, 테스트 결과물, 외부 검사 상태가 같은 기간 보관된다고 가정하면 조사에 필요한 연결고리가 끊길 수 있어요.

GitHub는 2026년 10월 1일부터 github.com의 checks, workflow runs, statuses에도 Actions 보존 설정을 적용한다고 공식 공지했어요. GitHub Actions뿐 아니라 외부 앱이 만든 checks와 statuses도 포함돼요. 설정 화면의 이름은 “Check, workflow run, status, artifact and log retention”입니다. 이미 삭제된 기록은 설정 기간을 늘려도 복원되지 않아요.

이 글은 10월 5~11일에 발표된 새로운 정책을 소개하는 기사가 아니에요. 직전에 적용된 변화가 현재의 배포 증빙에 어떤 빈틈을 만드는지 점검하는 실무 글입니다. 지금 필요한 질문은 “자동화가 성공했나?”에 하나를 더하는 것이죠. “문제가 늦게 발견돼도 그 성공의 근거를 다시 꺼낼 수 있나?”입니다.

작은 개인 서비스도 예외는 아니에요. 장애를 바로 발견하지 못하거나, 의존성 문제가 나중에 알려지거나, 운영 담당자가 바뀔 수 있죠. 다만 모든 실행을 영구 보관할 필요는 없어요. 반복적인 개발 브랜치 로그와 실제 운영에 반영한 릴리스의 증빙은 용도가 다르기 때문입니다.

STEP 2
무엇을 남길지 먼저 한 장으로 정해요

아래는 GitHub가 요구하는 표준이 아니라, 팀 규모에 맞게 바꿔 쓸 수 있는 운영 제안이에요. 먼저 배포 한 건을 다시 설명하는 데 필요한 최소 목록을 정해요. 원본 전체를 무조건 복제하기보다 누가 봐도 어떤 실행인지 식별할 수 있는 묶음을 만드는 방식입니다.

• 대상: 저장소, 배포 환경, 릴리스 이름 또는 버전
• 코드: 실제 빌드한 commit SHA와 workflow 경로
• 실행: run ID, 재실행 attempt, 시작·종료 시각과 최종 결과
• 검증: 테스트 요약, 필요한 검사 결과, 승인 근거의 위치
• 산출물: 배포한 파일 또는 이미지의 digest와 보관 위치
• 보존: 책임자, 만료일, 접근 범위와 삭제 기준

특히 버전 이름만으로는 부족할 수 있어요. 사람이 읽는 이름과 실제 바이트를 구분하려면 해시나 이미지 digest가 도움이 됩니다. 같은 이름을 다시 사용하거나 재실행했을 때도 어느 결과물을 배포했는지 연결할 수 있어야 해요. 재실행 번호까지 적는 이유도 여기에 있어요.

가상의 서비스에서 v2.4.0을 두 번 빌드했다고 해 볼게요. 두 번째 실행이 성공했어도 첫 번째 실패 로그를 성공 증빙에 섞으면 당시 경위를 오해할 수 있어요. 파일명에 run ID와 attempt를 넣고, 묶음 안의 메타데이터에도 같은 값을 적어 두면 이런 실수를 줄일 수 있습니다. 이는 이 글의 설명용 사례이며 실제 작성자의 운영 이력은 아닙니다.

승인자의 이름이나 내부 주소를 꼭 보관해야 하는지도 따져 봐요. 필요한 근거를 남기는 것과 모든 개인정보를 복제하는 것은 다른 문제예요. 접근 권한이 좁은 원본 시스템의 정보를 넓은 문서 저장소로 옮기면 보존은 좋아져도 정보 노출 위험은 커질 수 있어요.

STEP 3
실행 한 건부터 읽기 전용으로 꺼내 봐요

기존 인증과 저장소 읽기 권한이 있는 GitHub CLI 환경을 가정한 예제입니다. OWNER/REPO와 RUN_ID는 실제 대상 값으로 바꿔야 해요. 아래 명령은 로그와 아티팩트를 로컬로 내려받는 예시이며, 새 토큰 발급이나 외부 저장소 업로드까지 수행하지 않습니다.

set -euo pipefail
repo="OWNER/REPO"
run_id="RUN_ID"
out="evidence/${run_id}"
mkdir -p "$out"

gh run view "$run_id" --repo "$repo" \
  --json databaseId,attempt,headSha,conclusion,createdAt,updatedAt,url \
  > "$out/run.json"
gh run view "$run_id" --repo "$repo" --log \
  > "$out/workflow.log"
# 아티팩트가 있는 실행에만 별도로 실행해요.
gh run download "$run_id" --repo "$repo" \
  --dir "$out/artifacts"

gh run view의 JSON은 실행을 식별할 메타데이터, --log는 실행 로그, gh run download는 아티팩트를 가져오는 용도예요. 세 결과가 모든 외부 검사 기록이나 승인 기록을 자동으로 포함하는 것은 아니에요. 외부 앱의 검사 결과가 필요하다면 해당 시스템에서 별도로 보존해야 할 항목을 확인합니다.

자동 수집으로 옮기기 전에 성공 실행 한 건과 실패 실행 한 건을 직접 시험하는 편이 좋아요. 아티팩트가 없는 실행, 권한이 부족한 실행, 이미 만료된 실행은 같은 방식으로 처리되지 않을 수 있죠. 다운로드 명령이 실패했을 때 빈 폴더만 남았는데도 수집 완료로 표시하지 않도록 해야 해요.

이 코드는 로컬 증빙 묶음의 시작점이에요. 저장 대상의 암호화, 전송, 보관 정책, 실패 알림은 포함하지 않았어요. 토큰이나 환경변수가 로그에 들어갔는지 검토하는 단계도 필요해요. 로그가 자동으로 마스킹됐다는 이유만으로 공개 가능한 자료라고 판단하지 않는 것이 안전합니다.

STEP 4
보존 기간은 발견 시점에서 거꾸로 계산해요

공식 문서상 기본 보존 기간은 90일이고, 공개 저장소는 1~90일, 비공개 저장소는 1~400일 범위예요. 조직이나 엔터프라이즈의 상한이 더 낮으면 그 제한을 따라요. 설정 변경은 새 객체에 적용되며 기존 객체를 소급해서 바꾸는 것으로 해석하면 안 됩니다. 설정 화면에서 현재 유효한 기간과 상위 조직 정책을 함께 확인해야 해요.

팀이 실제로 필요한 기간은 제품의 특성에서 출발해요. 고객이 한 달 뒤에야 업데이트를 적용하는지, 분기별로 품질을 검토하는지, 지원 요청이 얼마나 늦게 들어오는지에 따라 조사 창이 달라져요. 저장 공간을 먼저 정하고 거기에 조사 절차를 억지로 맞추면 정작 중요한 시점의 근거가 사라질 수 있어요.

설명용 계산을 해 볼게요. 문제 발견까지 최대 60일, 조사에 필요한 여유 30일, 누락을 보완할 여유 14일을 가정하면 필요한 창은 60+30+14=104일이에요. 이는 권장 표준이나 측정값이 아니라 가상의 팀이 세운 가정입니다. 이 조건이라면 공개 저장소의 최대 90일만으로 요구를 충족한다고 말할 수 없죠. 별도 보존 대상과 위치를 결정해야 합니다.

그렇다고 모든 로그를 가장 긴 기간으로 올리는 것이 정답은 아니에요. 검사 상태 같은 메타데이터와 실제 파일 저장 비용을 구분하고, 덩치가 큰 임시 결과물은 짧게, 운영 릴리스 근거는 목적에 맞게 관리하는 편이 합리적입니다. 장기 보관 위치에도 만료일을 두어 불필요한 개인정보와 오래된 비밀이 쌓이지 않게 해요.

STEP 5
수집 성공보다 다시 읽는 시험이 중요해요

실행이 끝날 때 파일을 복사하는 것만으로는 보존 체계가 완성되지 않아요. 실제로는 다운로드 실패, 잘못된 실행 선택, 파일 이름 충돌, 권한 변경이 더 자주 빈틈을 만들 수 있어요. 수집 파이프라인에는 “성공” 한 줄보다 검증한 항목의 결과를 남기는 편이 좋아요.

1. 목록의 run ID와 commit SHA가 목표 릴리스와 맞는지 확인해요.
2. 필수 파일이 모두 있고 크기가 비정상적으로 작지 않은지 확인해요.
3. 배포 결과물의 digest와 기록에 적힌 digest를 대조해요.
4. 원래 담당자가 아닌 읽기 권한 보유자가 묶음을 열어 봐요.
5. 만료 전에 누락을 발견할 수 있도록 점검 시점을 정해요.

이 다섯 단계는 이 글에서 제안하는 확인 절차입니다. 파일의 해시가 같다는 것은 파일이 변하지 않았다는 단서이지, 빌드 과정이 신뢰할 만했다거나 승인 절차가 올바랐다는 증명은 아니에요. 각각의 질문을 별도로 확인해야 증빙의 의미가 과장되지 않습니다.

처음에는 최근 운영 배포 한 건만 골라도 좋아요. 실행 화면을 보지 않고 저장한 묶음만으로 “무슨 코드를, 어떤 검사 뒤에, 어느 환경에 반영했는지” 설명해 봅니다. 설명이 막히는 지점이 다음 자동화에서 보완할 필드예요. 반대로 아무도 쓰지 않는 자료는 수집 이유를 다시 물어볼 수 있죠.

이번 점검의 완료 기준은 보존 설정을 바꿨다는 사실이 아니에요. 팀이 정한 기간 동안 필요한 근거를 회수할 수 있고, 수집 실패와 접근 실패가 드러나며, 보관 책임자가 명확한 상태입니다. 배포 성공의 수명을 관리하는 일도 자동화의 마지막 단계라고 볼 수 있어요.

인수인계 문서에는 저장 위치만 적기보다 “어떤 자료가 어디에 없는지”도 남겨 두면 좋아요. 외부 보안 검사의 상세 보고서는 별도 서비스에만 남고, 빌드 로그에는 요약 결과만 있을 수 있죠. 두 자료를 한 묶음처럼 소개하면 나중에 상세 원인을 찾는 사람이 잘못된 기대를 갖게 됩니다. 원본의 범위와 수집본의 범위를 구분한 작은 목록이 이런 혼란을 줄여 줘요.

자동 수집을 추가할 때에는 작업 실행 주체도 확인해요. 배포 시스템이 쓰는 계정에 장기 보관소 전체를 삭제할 권한까지 줄 필요는 없을 수 있어요. 수집에 필요한 쓰기 권한과 보존 정책을 바꾸는 관리 권한을 분리할 수 있는지 검토합니다. 반대로 권한을 너무 줄여서 수집이 실패한다면 조용히 무시하지 않고 운영자가 알 수 있게 해야 해요.

보존 기간이 바뀌었을 때에는 설정값만 문서에 고쳐 적고 끝내지 않아요. 다음 실행에서 실제로 생성된 기록과 내려받은 파일이 예상대로 남는지 확인하고, 기존 증빙의 보존 조건은 별도로 점검해요. 보관 정책은 선언이고, 실제 회수 시험은 그 선언을 검증하는 증거에 가깝습니다.

정기 점검에 긴 회의를 만들 필요는 없어요. 릴리스마다 꼭 남겨야 할 항목 몇 개를 정하고, 누락된 항목이 있으면 해당 릴리스의 증빙 상태를 미완료로 표시하는 방식부터 시작할 수 있어요. 변경이 많지 않은 작은 프로젝트라도 책임자와 다음 확인 시점이 분명하면 담당자의 기억에만 의존하는 상황을 줄일 수 있습니다.

아카이브를 옮기거나 정리할 때에는 링크가 계속 열리는지도 확인해요. 파일 자체는 살아 있는데 릴리스 문서의 주소만 끊어진 상태도 사용자에게는 사실상 유실처럼 보일 수 있죠. 파일 식별자, 보관 위치, 접근 권한과 안내 문서를 함께 관리하는 것이 실제 회수 가능성을 높이는 방법입니다.

1. GitHub · Actions retention now covers checks, runs, and statuses2026-10-01 적용 범위, 외부 앱 검사 포함, 변경된 설정 이름과 삭제된 데이터의 복원 불가를 확인했어요. 원문 보기 ↗

   2026-10-01 적용 범위, 외부 앱 검사 포함, 변경된 설정 이름과 삭제된 데이터의 복원 불가를 확인했어요.

   원문 보기

2. GitHub Docs · 조직의 실행 기록 보존 기간기본 90일, 공개 1~90일·비공개 1~400일, 상위 정책 제한과 새 객체에 대한 설정 적용을 확인했어요. 원문 보기 ↗

   기본 90일, 공개 1~90일·비공개 1~400일, 상위 정책 제한과 새 객체에 대한 설정 적용을 확인했어요.

   원문 보기

3. GitHub CLI · gh run view실행 메타데이터의 JSON 필드, --repo와 --log 사용법을 예제에 반영했어요. 원문 보기 ↗

   실행 메타데이터의 JSON 필드, --repo와 --log 사용법을 예제에 반영했어요.

   원문 보기

4. GitHub CLI · gh run download실행 아티팩트를 지정 디렉터리로 내려받는 명령을 확인했어요. 원문 보기 ↗

   실행 아티팩트를 지정 디렉터리로 내려받는 명령을 확인했어요.

   원문 보기