3 1 CD 적용 범위 및 승인 정책 - 100-hours-a-week/KTB4-13th-wiki GitHub Wiki

북적북적 V1은 약 3주간 운영하는 초기 POC입니다. 초기 가입자는 약 900명, 일반적인 Peak Traffic은 약 0.18 RPS로 예상합니다.

서비스는 다음 인프라에 배포합니다.

현재는 새로운 버전을 빠르게 반영하는 것도 중요하지만, 누가 배포하더라도 같은 버전과 같은 검증 절차를 거치도록 하는 것을 더 중요하게 보았습니다.

상시 운영하는 별도 Staging EC2는 V1에서 제외합니다. 배포 빈도가 낮은 초기 POC에서 App·AI EC2와 동일한 Staging 서버 2대를 추가로 운영하는 것은 비용 대비 효과가 작기 때문입니다.

대신 CI에서 GitHub Actions Runner에 Backend, AI Server, MySQL, Qdrant를 일회성 Docker Compose로 실행하여 배포 후보를 검증합니다.

운영까지 승인 없이 바로 배포하는 Continuous Deployment가 아니라, 배포 후보는 자동으로 준비하고 운영 배포는 사람의 승인 후 실행하는 Continuous Delivery를 선택합니다.

선택 근거는 다음과 같습니다.

• 약 2주 단위로 기능을 Release하므로 승인 단계가 배포 속도를 큰 폭으로 떨어뜨리지 않습니다.
• 장바구니·주문·결제와 같은 Write 요청이 있어 잘못된 배포의 영향이 큽니다.

v1.2.0과 같은 v* Release Tag가 GitHub에 Push되면 운영 CD Workflow가 시작됩니다.

CD Workflow가 시작되면 해당 Tag가 가리키는 Git Commit SHA의 Backend·AI Image와 Frontend 파일이 존재하는지 확인합니다. 배포 후보가 정상적으로 준비되어 있으면 GitHub production Environment의 승인 단계에서 대기합니다.

운영 담당자가 승인하면 AI EC2, App EC2, Frontend 순서로 배포하고 Health Check와 Smoke Test를 수행합니다. 승인이 거절되거나 검증 조건을 충족하지 못하면 운영 환경을 변경하지 않습니다.

긴급 롤백은 운영 담당자가 GitHub Actions에서 workflow_dispatch로 이전 Git SHA를 선택하여 수동으로 실행합니다. 롤백도 운영 환경을 변경하는 작업이므로 동일한 production 승인을 거칩니다.

• 파트별로 2명씩 인원이 있으므로 작성자 이외의 팀 인원이 승인하도록 합니다.
• 배포는 이용량이 높은 시간대를 피해 평일 10~11시를 기본 시간대로 설정합니다.
• 긴급 취약점과 중대 장애는 배포 시간대 제한에서 제외할 수 있지만 승인·기록·검증 절차는 유지합니다.

운영 배포에서는 latest를 사용하지 않습니다. 같은 Tag가 다른 Image를 가리키면 정확한 배포·롤백 대상을 확정할 수 없기 때문입니다.

Release Manifest에는 다음 정보를 저장합니다.

release_id: v1.2.0
git_sha: 6f2c1ab
backend_image: <backend-ecr-uri>@sha256:<digest>
ai_image: <ai-ecr-uri>@sha256:<digest>
frontend_prefix: s3://<bucket>/releases/6f2c1ab/
mysql_migration: true
qdrant_collection: books_v2
created_at: 2026-09-04T01:00:00Z

← 3단계 상위 페이지 | 다음: 3-2. 배포 전략 및 전체 CI/CD Pipeline →