‘안전한 복구 전략’입니다.

GitHub에서 Release를 잘못 게시했다고 해서 삭제(Delete) 버튼이

곧 복구(Recovery)를 의미하지는 않습니다.

이미 공개된 Release는 누군가가 다운로드했을 수도 있고,

캐시·미러 서버에 저장되었을 수도 있으며, 공개 이력 역시 남아 있습니다.

즉, 삭제는

화면에서 사라질 뿐, 배포된 사실까지 되돌려 주지는 않습니다.

이번 github-release-guide v0.9.0은 이러한 실수를 줄이기 위해 만들어진 Claude Code/Codex용 Agent Skill입니다. Release를 수정하거나

삭제하기 전에 현재 상태를 먼저 점검하고, 위험한 작업이라면

한 번 더 멈춰 생각할 수 있도록 안내합니다.

Release 삭제 전에 반드시 확인해야 할 두 가지

① 이미 외부에 공개되었는가?

다음과 같은 경우라면 삭제만으로 문제를 해결할 수 없습니다.

* 이미 사용자가 다운로드한 Release

* CDN 캐시 또는 미러 서버에 저장된 파일

* 공개 저장소에서 배포된 Asset

* 노출 여부를 확인할 수 없는 상태(Unknown)

공개 이력이 있다면 기존 Tag를 유지하고 새로운 Patch Release를 배포하는 것이 가장 안전한 방법입니다.

② GitHub에서 실제로 수정 가능한 상태인가?

Release마다 수정 가능 여부가 다릅니다.

* Draft Release

* Mutable Release

* Immutable Release

특히 Immutable Release는 삭제하더라도 연결된 Tag 이름을 다시 사용할 수 없습니다.

따라서 삭제보다 새로운 Tag를 생성하고 후속 Release를 게시하는 방식이 권장됩니다.

github-release-guide가 제공하는 두 가지 모드

Assess (읽기 전용 점검)

저장소를 변경하지 않고 현재 상태만 분석합니다.

다음 항목을 자동으로 확인합니다.

* Release 준비 상태

* Tag 보호 설정

* CHANGELOG 존재 여부

* LICENSE 포함 여부

* 민감 정보 포함 여부

* 설치 방법 검증

* GitHub Actions 설정

* Release Notes

* Asset 상태

확인하지 못한 항목은 Unknown으로 표시하여 추측하지 않습니다.

Guided (변경 전 승인)

실제 변경 작업은 자동으로 실행하지 않습니다.

먼저

어떤 파일이 변경되는지

어떤 Commit이 생성되는지

어떤 Tag가 만들어지는지

어떤 Release가 게시되는지

순서대로 보여주고,

사용자가 승인한 작업만 실행합니다.

실행 직전에 저장소 상태가 변경되었다면 작업을 중단하고 다시 확인하도록 설계되어 있습니다.

Release 체크리스트

배포 전에는 다음 사항을 반드시 확인하세요.

버전 번호와 CHANGELOG 일치 여부

LICENSE 포함 여부

API Key·Secret 등 민감 정보 노출 여부

Tag 보호 정책

설치 문서 및 실행 예제 정상 동작

GitHub Actions Workflow 검증

Release Notes 완성도

Asset 다운로드 가능 여부

자주 발생하는 실수

Release를 삭제하면 모든 것이 원래대로 돌아간다고 생각한다.

이미 배포된 파일과 공개 이력은 회수되지 않습니다.

기존 Tag를 다른 Commit으로 이동한다.

기존 사용자의 설치 환경과 자동 배포가 예기치 않게 깨질 수 있습니다.

Immutable Release를 삭제한다.

동일한 Tag 이름을 다시 사용할 수 없습니다.

기존 Release를 수정하려고 한다.

새로운 Tag + Patch Release를 생성하는 것이 안전한 운영 방법입니다.

실무 권장 전략

Release 운영의 핵심은 “삭제”가 아니라 “추적 가능성(Traceability)과 안정성(Stability)”입니다.

잘못된 Release가 배포되었다면 기존 이력을 유지한 상태에서 새로운 Patch Release를 게시하는 것이 GitHub 운영 모범 사례이며, 사용자와 자동화 환경 모두를 안정적으로 보호할 수 있습니다.

좋은 DevOps는 문제를 숨기는 것이 아니라, 변경 이력을 투명하게 관리하고 안전하게 개선하는 과정입니다.

여러분은 Release를 잘못 게시했을 때 어떤 방법을 사용하시나요?

— 이춘곤(Mark) · ISC.studio · ISC출판 도서 안내

이 글은 저자의 Facebook에 처음 게시한 글입니다. Facebook 원문 보기