2단계 CI(지속적 통합) 파이프라인 설계

PR마다 변경 사항을 검증하고, 배포에 사용할 추적 가능한 컨테이너 이미지를 만드는 흐름을 정리한다. 이 문서는 정책과 선택 이유를 전달하기 위한 요약이며, 상세 트리거와 테스트 조건은 CI 파이프라인 설계 원문을 참고한다.

목차

• 1. CI의 역할과 흐름
• 2. 변경 검증과 실패 처리
• 3. 이미지 생성과 버전 관리
• 4. Dev에서 Prod로의 승격

1. CI의 역할과 흐름

CI는 코드를 운영 환경에 배포하는 단계가 아니라, 변경 사항이 통합 가능한 상태인지 확인하고 배포 가능한 Release Artifact를 준비하는 단계다. V1은 PR을 기준으로 자동 검증을 실행하고, 변경이 통합된 뒤 이미지를 만들고 저장한다. 이 흐름을 통해 팀원별 로컬 환경 차이와 API·스키마 불일치를 Dev 통합 단계 이전에 발견할 수 있도록 한다.

Pull Request → 변경 범위 판단 → Build·Test → 이미지 생성·Push

프론트엔드와 백엔드 등 변경된 영역을 기준으로 필요한 검증을 실행해 불필요한 작업을 줄인다. 다만 공통 설정이나 API 계약처럼 여러 구성 요소에 영향을 미치는 변경은 관련 검증 범위에 포함해야 한다. 실제 브랜치 정책과 파트별 CI 트리거는 CI 파이프라인 설계 원문의 CI 트리거 정책을 따른다.

2. 변경 검증과 실패 처리

CI에서는 각 애플리케이션의 빌드와 테스트를 수행하고, 프론트엔드와 백엔드가 약속한 API 계약이 유지되는지 확인한다. 모여타의 참여 기능은 동시에 요청이 들어올 때 좌석 초과 승인이나 중복 참여, 좌석 상태 불일치가 생길 수 있으므로 정상 응답을 반환하는지 확인하는 것만으로 충분하지 않다. 이런 동시성 시나리오를 별도로 검증해 핵심 데이터 정합성 문제를 통합 전에 발견한다.

필수 빌드나 테스트가 실패하면 해당 변경을 통합 또는 배포 가능한 것으로 취급하지 않는다. 원인을 수정한 뒤 같은 검증 절차를 다시 통과해야 한다. 이미지 생성이나 레지스트리 Push가 실패한 경우에도 기존 정상 Release를 유지하고, 실패한 산출물을 운영에 사용하지 않는다. 실패 유형별 상세 처리 기준은 원문 CI 실패 처리 정책에 있다.

3. 이미지 생성과 버전 관리

검증이 끝난 코드는 컨테이너 이미지로 패키징해 ECR에 저장한다. 저장소를 서비스 단위로 구성하고 태그에 Git 변경 식별자와 Release 정보를 연결해, 어떤 소스에서 이미지가 만들어졌는지 추적할 수 있도록 한다. 배포 시에는 태그 이름만으로 이미지를 식별하지 않고 이미지 Digest를 기준으로 고정해 동일한 산출물을 다시 선택할 수 있게 한다.

이미지 태그는 개발·운영 환경에서 이미지의 용도를 알아보기 쉽도록 정하되, Git 태그와 이미지 태그가 맡는 역할을 구분한다. 오래된 산출물은 수명주기 정책으로 정리할 수 있지만, 현재 운영 중인 버전과 롤백에 필요한 이전 Release는 보존해야 한다. ECR 구성, 태그 네이밍과 보관 정책의 구체적인 규칙은 원문 이미지 관리 정책에 정의되어 있다.

4. Dev에서 Prod로의 승격

환경마다 이미지를 다시 빌드하면 Dev에서 검증한 코드와 Prod에 반영되는 코드가 달라질 수 있다. 따라서 CI에서 이미지를 한 번 생성한 뒤, 그 동일한 이미지와 Release 식별자를 Dev에 배포해 검증하고 승인된 결과를 Prod로 승격한다.

Build once → 이미지 저장 → Dev 배포·검증 → 동일 이미지 Prod 승격

이 원칙은 환경 간 산출물 차이를 막고, 장애가 발생했을 때 운영 버전과 소스 변경을 정확히 대응시켜 복구 대상을 찾게 한다. 환경별 승인과 실제 배포·롤백 순서는 3단계 CD 파이프라인 설계 요약에서 이어진다.

홈