2026년 10월 1일부터 GitHub Actions 보존 설정이 체크, 워크플로 실행, 커밋 상태에도 적용됩니다. GitHub 공식 변경 공지를 기준으로 보면, 이번 주에는 조직 수준의 설정과 실제 적용 범위를 먼저 점검하고 장기 보관이 필요한 증거를 별도 저장소로 내보내야 합니다. 설정을 바꾸는 것만으로 이미 삭제된 자료가 돌아오지는 않으며, 빌드 파일은 별도 보관 대상으로 관리해야 합니다.
이 글은 조직과 저장소의 보존 설정을 책임지는 기업 IT 담당자, 게시와 감사의 연결을 증명해야 하는 보안 담당자, Mac CI 실행 기록과 빌드 파일을 관리하는 플랫폼 담당자를 위한 안내입니다.
마지막 확인: 2026년 10월 21일. GitHub 공식 변경 공지와 Actions 조직 보존 설정 문서를 대조하고, 실제 조직 설정은 별도로 확인해야 합니다.
감사 범위와 자동 정리 대상
체크 결과, 워크플로 실행, 커밋 상태는 서로 바꿔 부를 수 있는 한 덩어리의 자료가 아닙니다. GitHub는 적용 범위에 Actions와 서드파티 연동이 만든 관련 체크 및 상태도 포함한다고 밝혔습니다. 체크 실행 API 문서와 커밋 상태 API 문서를 따로 살펴보면 각 기록이 담는 정보와 조회 경로가 다릅니다.
특히 상태 정보가 조회된다는 이유만으로 실행 로그나 빌드 파일까지 남아 있다고 가정하면 안 됩니다. 로그와 워크플로 아티팩트는 별도 대상입니다. 워크플로 아티팩트 설명 및 실행 로그 다운로드 문서를 기준으로 각각 저장과 반출 여부를 확인해야 합니다.
증거 연결성과 추적 경로
감사에서 중요한 것은 개별 기록의 존재뿐 아니라 릴리스 결론까지 이어지는 경로입니다. 승인 또는 배포 판단을 커밋, 워크플로 실행, 체크 결과, 상태 출처와 연결할 수 있어야 합니다. 서드파티 연동이 생성한 체크와 상태도 같은 방식으로 생성 주체와 관련 실행을 확인합니다.
보존 범위 점검은 다음 연결을 기준으로 진행합니다.
- 커밋 식별자와 배포 버전이 서로 연결되는지 확인합니다.
- 워크플로 실행과 체크 결과의 조회 위치 및 식별자를 기록합니다.
- 커밋 상태의 출처가 Actions인지 외부 연동인지 구분합니다.
- 승인 및 배포 판단에 필요한 로그, 테스트 보고서가 실제로 남는지 살핍니다.
- 각 자료의 내보내기 위치와 복원 검증 결과를 색인에 연결합니다.
이는 체크와 상태의 기록이 있다는 것만으로 감사에 필요한 모든 증거가 갖춰진 것은 아니라는 뜻입니다. 팀의 감사 기준이 승인자나 배포 결과까지 요구한다면, 해당 자료도 보관 목록에 포함해야 합니다.
보존 설정과 감사 기간의 적합성
기업, 조직, 저장소 설정을 각각 살피고 실제 저장소에 적용되는 상한과 값을 확인합니다. 저장소 관리자가 설정한 값이 조직 수준 정책을 넘어설 수 있다고 전제하지 마십시오. 관리 권한이 있는 담당자가 조직 보존 설정 문서와 실제 관리 화면을 함께 확인해야 합니다.
아래 표는 자료의 소유 책임과 복원 확인을 분리하기 위한 점검표입니다. 기업의 감사 기간은 일률적인 값으로 정하지 말고, 내부 감사 요구와 사고 조사 필요에 맞춰 결정합니다.
| 증거 대상 | 확인할 원본과 책임 | 보관 및 복원 확인 |
|---|---|---|
| 체크 결과와 커밋 상태 | GitHub 기록과 생성 주체를 확인하고 플랫폼 담당자가 색인화합니다. | 커밋과 릴리스로 검색해 원본 기록과 보관본의 연결을 확인합니다. |
| 워크플로 실행 정보 | 실행 식별자, 커밋, 결과를 기록하고 CI 담당자가 관리합니다. | 해당 커밋에서 실행 정보를 조회하고 아카이브 색인과 대조합니다. |
| 실행 로그 | 워크플로 실행 로그와 내보낸 파일을 구분해 담당자를 지정합니다. | 로그 다운로드 안내에 따라 확인하고, 보관본을 실제로 열어봅니다. |
| 테스트 보고서와 빌드 파일 | 테스트 보고서, 앱 아카이브, 심볼 파일을 각각 별도 항목으로 기록합니다. | 아티팩트 삭제 안내도 참고해 원본 만료와 별도 보관의 차이를 확인합니다. |
Mac CI 감사 유지를 위해서는 GitHub의 실행 기록 보존과 CI 빌드 산출물 보관 책임을 한 설정으로 취급하지 않는 것이 중요합니다. 내부 정책에서 요구하는 기간을 먼저 정하고, 각 자료가 그 기간을 실제로 충족하는지 확인합니다. 확인되지 않은 보존 가능 기간이나 복구 성능을 임의로 가정하지 않습니다.
아카이브 복원성과 권한 책임
내보낸 파일이 있다는 사실만으로 복원 가능성이 입증되지는 않습니다. 커밋이나 릴리스 버전으로 자료를 찾고, 파일이 읽히며, 원래 실행과의 관계를 설명할 수 있어야 합니다. 권한도 함께 확인해 필요한 담당자는 접근할 수 있고, 불필요한 계정에는 접근이 허용되지 않는지 검토합니다.
설정 변경과 검증은 다음 순서로 실행합니다.
- 기업·조직·저장소 보존 설정을 확인하고, 관리 화면의 값과 정책 상한을 기록합니다.
- 실제 실행 하나를 골라 커밋, 실행, 체크, 상태의 연결 관계와 생성 주체를 확인합니다.
- 로그, 테스트 보고서, 빌드 아티팩트, 심볼 파일을 구분하고 각각의 담당자와 보관 위치를 지정합니다.
- 장기 보관이 필요한 자료를 독립 저장소로 내보내고, 커밋이나 릴리스 기준으로 검색할 색인을 작성합니다.
- 별도 담당자가 색인에서 자료를 찾아 파일을 열고, 실행과의 연결 및 접근 권한을 확인합니다.
- 설정 기록, 내보내기 색인, 복원 확인 결과와 예외 승인 내역을 검토 자료로 묶습니다.
명령줄에서 실행 및 상태 자료를 조회할 때는 저장소와 커밋을 실제 값으로 지정합니다. 다음 명령은 점검 출발점이며, 내보내기와 장기 보관은 별도로 설계해야 합니다.
gh api repos/OWNER/REPO/actions/runs \
--jq '.workflow_runs[] | {id, head_sha, status, conclusion, created_at}'
gh api repos/OWNER/REPO/commits/COMMIT_SHA/check-runs \
--jq '.check_runs[] | {id, name, status, conclusion, head_sha}'
gh api repos/OWNER/REPO/commits/COMMIT_SHA/status \
--jq '{state, statuses}'
출력에서 식별자와 커밋 연결을 확인하되, 결과를 기록한 화면만 캡처해서 아카이브 완료로 처리하지 않습니다. 실제 파일을 별도 위치에서 찾아 열어보는 복원 검증까지 수행해야 합니다.
자주 묻는 질문
보존 정책 변경 뒤 어떤 기록을 확인해야 하나요?
체크, 워크플로 실행, 커밋 상태가 새 보존 범위에 포함되는지 확인합니다. 서드파티 연동에서 만든 항목도 점검 대상입니다. 로그와 아티팩트는 각각 보존 설정과 원본 위치를 확인하고, 저장소에 남은 메타데이터가 파일까지 보장한다고 판단하지 않습니다. 조직 설정과 실제 실행 기록을 함께 대조해야 합니다.
체크와 상태 정보를 감사 증거로 연결하는 방법은 무엇인가요?
커밋, 실행 식별자, 체크 결과, 상태 생성 주체를 함께 기록합니다. 승인이나 게시 판단까지 추적해야 한다면 관련 승인 기록과 배포 버전도 연결합니다. 외부 연동이 생성한 항목을 구분하고, 내보낸 자료의 색인으로 원본과 보관본을 다시 찾아갈 수 있는지 검증합니다.
보존 기간을 늘리면 삭제된 기록도 복구되나요?
아닙니다. 설정 변경은 이미 삭제된 체크나 실행 기록을 되살리지 않습니다. 남아 있는 자료를 확인하고 장기 보관 대상은 별도로 내보내야 합니다. 삭제된 기록이 조사에 필요하다면 기존 아카이브나 조직의 다른 기록을 확인합니다. 보존 설정 변경과 복구 절차를 동일하게 취급하지 않습니다.
로그, 상태 정보, 빌드 파일은 어떻게 나눠 보관하나요?
상태와 체크, 실행 정보, 로그, 테스트 보고서, 빌드 아카이브와 심볼 파일을 별도 항목으로 관리합니다. 각 항목의 출처, 담당자, 보관 위치와 복원 검증 방법을 기록합니다. 커밋 또는 릴리스 기준으로 찾아 파일을 열고 실행과의 연결을 설명할 수 있어야 검증을 마친 것입니다.
먼저 표의 항목으로 현재 아카이브와 복원 절차의 빈틈을 확인하십시오. 직접 관리하는 Mac은 초기 구매 비용 외에도 장비 교체와 운영 관리가 필요하고, 사용량이 일정하지 않으면 유휴 자원이 남을 수 있습니다. 반대로 장기간 고정된 고부하 작업이나 물리 장치 연결이 필요한 팀에는 자체 장비가 더 알맞을 수 있습니다. 전용 macOS 빌드 노드가 필요하지만 상시 구매가 부담인 경우에는 NodeMini의 원격 Mac 환경을 검토할 수 있습니다. 원격 노드는 실행 환경 선택을 돕는 것이며, 감사 증거를 자동으로 보관하거나 규정 준수를 보증하는 대안은 아닙니다. 도입 전에는 Mac mini 주문 정보와 함께 접근 권한, 자료 반출, 별도 아카이브 운영 책임을 확인하십시오.