[Git·GitOps 19] CI 다음의 CD: 승인·산출물 승격·이미지 digest

테스트가 통과했다고 곧바로 운영에 반영해야 하는 것은 아닙니다. CI 다음에는 결과물을 어디에 보관하고, 누가 승인하며, 어떤 기준으로 배포할지 정해야 합니다. 이 경로가 분명해야 장애가 났을 때도 무엇을 되돌릴지 찾을 수 있어요.

CD는 지속적 전달과 지속적 배포 두 의미로 사용됩니다. 전달은 배포 가능한 상태를 계속 준비하면서 운영 반영에 사람의 승인을 둘 수 있고, 배포는 정해진 검사를 통과한 변경을 운영까지 자동 반영하는 접근입니다. 어떤 단어를 택하든 실제 승인 경로를 문서로 남깁니다.

Git·GitOps 전체 연재 · 19 / 24

이 글의 목차

테스트한 결과물을 다시 만들지 않고 승격한다

코드 커밋 → CI 테스트 → 결과물 보관 → 개발 환경 검증
                                      ↓
                                승인 → 운영 반영

개발 환경에서 성공한 소스로 운영용 빌드를 다시 만들면 의존성이나 빌드 시점 차이로 결과가 달라질 수 있습니다. 같은 결과물을 환경별 설정과 함께 승격하는 편이 무엇을 검증했는지 설명하기 쉽습니다. 단, 완전한 재현 가능 빌드는 잠금 파일·도구 체인·빌드 환경까지 추가 관리가 필요합니다.

17편의 app.zip은 Git 추적 파일을 묶은 학습용 산출물입니다. 이를 서비스로 배포하려면 실행 환경과 프로세스 관리가 더 필요합니다. 다음 GitOps 실습은 이 Python 앱을 배포했다고 꾸미지 않고, 공식 nginx 이미지로 Kubernetes의 상태 조정만 따로 확인합니다.

태그는 이름, digest는 내용 식별자

nginx:stable-alpine 같은 태그는 나중에 다른 이미지로 이동할 수 있습니다. digest는 레지스트리의 특정 manifest 또는 이미지 인덱스를 내용 기반으로 식별합니다. 배포 설정에 digest를 기록하면 “같은 태그인데 서버마다 다른 이미지”라는 모호함을 줄일 수 있어요.

docker buildx imagetools inspect nginx:stable-alpine

출력의 상위 Digest와 플랫폼별 manifest digest를 구분합니다. 멀티 플랫폼 인덱스 digest는 실행 노드의 플랫폼에 맞는 이미지를 가리킵니다. 직접 빌드한 결과물이라면 push가 끝난 뒤 레지스트리에서 digest를 확인하고 기록합니다. 임의의 SHA 문자열을 만들어 넣지 않습니다.

image: registry.example.com/team/app@sha256:VERIFIED_DIGEST

위 줄은 문법 예시입니다. VERIFIED_DIGEST는 실제 확인한 64자리 해시로 바꿔야 합니다. 고정했다고 자동으로 보안 업데이트되는 것은 아니므로 새 이미지 검토와 digest 변경 PR을 운영 절차에 넣습니다.

승인 시에는 무엇을 확인해야 하나

확인할 정보	필요한 이유
소스 커밋과 CI 실행	어떤 변경이 어떤 검사에 통과했는지 연결
결과물 이름과 digest·체크섬	배포 대상이 테스트 대상과 같은지 확인
설정 변경과 권한 범위	코드 외의 운영 영향 확인
건강 상태와 되돌릴 기준	실패 판단과 복구 경로 준비

승인 버튼 하나가 품질을 만들어 주지는 않습니다. 개발·운영 자격 증명을 나누고, 배포 작업에 필요한 범위만 부여합니다. 외부 PR에서 실행한 임의 코드가 운영 비밀 값을 읽을 수 있는지 함께 점검합니다.

배포 성공과 서비스 정상은 다르다

프로세스가 시작되거나 Kubernetes Deployment가 Available이 되었다고 사용자 기능이 모두 정상인 것은 아닙니다. readiness, HTTP 응답, 중요한 업무 요청, 오류율을 함께 봅니다. 관찰 시간과 중단 기준은 서비스 특성에 맞춰 정하며 이 연재의 예제 수치를 운영 기준으로 복사하지 않습니다.

코드 이미지는 이전 digest로 돌릴 수 있어도 데이터베이스의 파괴적인 스키마 변경은 같은 방식으로 복구되지 않을 수 있습니다. 하위 호환 마이그레이션, 백업, 기능 플래그와 데이터 복구 계획을 별도로 준비합니다. “롤백 가능”이라는 말에 무엇이 포함되는지 구체적으로 적어 두세요.

GitHub의 환경 승인 기능은 배포 환경 관리, digest 조회는 Docker imagetools inspect에서 확인할 수 있습니다. 다음 편부터 배포할 상태를 Git에서 관리하는 GitOps 저장소를 만듭니다.

이전 글 · [Git·GitOps 18] Gitea와 Jenkins 연결하기: 저장소 인증·Jenkinsfile·트리거 · 다음 글 · [Git·GitOps 20] GitOps의 네 원칙과 앱·배포 설정 저장소 나누기 · 연재 목록과 예제 파일