서버 배포 체크리스트: ⑤ 자동화 (CI/CD)

코드 변경 사항을 안전하고 빠르게 운영 환경에 반영하기 위한 자동화 파이프라인 구축 방법이다.

1. CI/CD의 기본 개념

• CI (Continuous Integration): 지속적인 통합이라는 의미로 개발자가 코드를 푸쉬하면 자동으로 빌드와 테스트를 수행하여 코드의 품질을 검증하는 것을 의미한다.
• CD (Continuous Deployment): 지속적 배포라는 의미로 검증된 코드를 실제 서버(운영 환경)에 자동으로 배포하는 것을 의미한다.

2. 모던 백엔드의 표준 배포 흐름 (Docker + ECS)

가장 많이 사용되는 것은 Github Actions와 AWS를 조합한 아래 5단계 흐름이다.

1. Code Push: 개발자가 깃허브의 master브랜치에 코드를 푸쉬한다.
2. Build & Test: Github Actions가 서버를 빌드하고 유닛 테스트를 실행한다.
3. Dockerize: 빌드된 결과물을 Docker 이미지로 만들고 태그(버전)를 붙인다.
4. Push to ECR: 생성된 이미지를 AWS의 이미지 저장소인 ECR (Elastic Container Registry)에 업로드한다.
5. Update ECS Service: ECS가 새로운 이미지를 내려받아 서버를 교체(Blud-Green 또는 Rolling Update)하도록 명력한다.

3. 주요 도구 비교

Github Actions

• 장점: 깃허브 내부에 포함되어있어 설정이 매우 쉽고 오픈소스 커뮤니티의 검증된 액션들이 많다.
• 용도: 빌드, 테스트, 간단한 AWS 배포 자동화.

AWS CodePipeline / CodeBuild / CodeDeploy

• 장점: AWS 내부 서비스들과 가장 깊게 통합되어있으며 보안(IAM) 설정이 직관적이다.
• 용도: 복잡한 엔터프라이즈급 배포 파이프라인 구축

4. 무중단 배포 전략 (Zero Downtime Deployment)

자동 배포를 할 때 서버가 잠시라도 꺼지면 안 된다. 아래는 ECS에서 제공하는 방식이다.

• 롤링 업데이트 (Rolling Update): 새 버전의 컨테이너를 하나 띄우고 성공하면 구 버전을 하나 끄는 식으로 점진적으로 교체한다.
• 블루-그린 배포 (Blue-Green): 새 버전의 서버 그룹(Green)을 통째로 다 띄운 뒤 로드밸런서의 타겟을 한 번에 구부전(Blue)에서 새 버전으로 바꾼다.

5. 체크리스트

• 빌드 자동화: 코드를 푸쉬했을 때 컴파일 에러나 테스트 실패 여부를 자동으로 확인할 수 있는가?
• 환경 변수 분리: 빌드 시점에 API 키나 DB 주소가 이미지에 박히지 않도록, 런타임에 주입받게 설계했는가 (Secrets Manager 연동)
• 배포 승인 절차: 운영 환경 배포 전에는 관리자의 승인(Approval) 단계를 거치도록 설정했는가?
• 롤백 계획: 배포된 서버에 문제가 생겼을 때, 클릭 한 번으로 버전 이미지로 돌아갈 수 있는가?
• 보안(Secrets): Github Actions 설정에 AWS Access Key가 노출되지 않았는가? (Gtihub Secrets Variables 사용 또는 OIDC 인증 권장)