<aside>
☁️ 클라우드웨이브 · W07 · 3/5 · 예상 읽기 7분
</aside>
코드가 저장소에 들어갔다는 사실만으로 배포 가능한 것은 아니다. 변경을 검사하고, 재현 가능한 이미지나 패키지를 만들고, 승인된 환경에 단계적으로 반영해야 한다. 오늘은 GitLab CI/CD와 Jenkins Pipeline을 경쟁 도구가 아니라 같은 운영 원리를 구현하는 두 방식으로 바라보았다.
변경 이벤트가 발생하면 먼저 문법과 정적 검사를 수행한다. Terraform은 초기화, 형식 검사, 검증, 계획 결과를 순서대로 확인하고, 계획은 사람이 읽고 승인할 수 있는 산출물로 남긴다. 애플리케이션은 테스트 후 이미지를 빌드하고 식별 가능한 태그로 저장한다. 배포 단계는 앞선 증거와 승인 조건을 확인한 뒤 실행한다.
flowchart LR
C[변경 제출] --> V[검증과 테스트]
V --> P[IaC 계획 검토]
V --> I[이미지 빌드와 저장]
P --> G[배포 게이트]
I --> G
G --> D[단계적 배포]
D --> M[지표 확인과 롤백 판단]
GitLab은 설정 파일 중심으로 단계와 작업을 표현할 수 있고, Jenkins는 Pipeline 문법으로 조건·병렬화·승인을 세밀하게 조합할 수 있다. 어느 도구를 쓰든 비밀값은 변수 저장소나 권한 있는 자격증명 연동에 맡기고, 로그에 평문이 남지 않도록 마스킹과 출력 규칙을 확인한다.
빌드 결과물은 다시 만들 수 있는 이미지, 테스트 보고서, Terraform 계획 파일처럼 다음 단계가 검증할 수 있는 형태여야 한다. 이미지 태그를 단순히 최신으로만 두면 어떤 코드를 배포했는지 추적하기 어렵다. 커밋과 빌드 식별자를 연결하고, 취약점 검사와 기본 실행 검사를 통과한 결과만 다음 환경으로 이동시킨다.
배포 게이트는 사람의 승인을 무조건 늘리는 장치가 아니다. 파괴적 인프라 변경, 운영 환경 반영, 데이터 스키마 변경처럼 실패 비용이 큰 경계에 집중한다. 승인자는 계획의 변경 범위, 예상 용량, 롤백 가능성, 관측 지표를 보고 판단할 수 있어야 한다.
Terraform은 네트워크, 로드 밸런서, 인스턴스와 같은 인프라 자원의 생명주기를 만들고 연결한다. Ansible은 이미 준비된 호스트나 실행 환경의 패키지, 설정 파일, 서비스 상태를 원하는 상태로 맞춘다. 둘을 한 작업에서 연계할 수 있지만 같은 자원을 양쪽이 동시에 소유하면 변경 순서와 드리프트가 모호해진다.
stages:
- validate
- plan
- build
- deploy
위 예시는 단계 이름만 보여 주는 안전한 축약이다. 실제 파이프라인에서는 각 단계의 실행 주체, 권한, 캐시, 아티팩트 보존 기간, 실패 시 중단 조건을 명시해야 한다.
파이프라인을 설계할 때 성공 경로만 그리면 운영에서 가장 중요한 장면이 빠진다. 검증 실패는 병합을 멈추고, 이미지 빌드 실패는 이전 산출물을 임의로 재사용하지 않게 하며, 배포 뒤 지표 악화는 자동 중단이나 수동 롤백으로 이어져야 한다. 각 단계의 로그에는 민감한 값이 섞이지 않는지 확인하고, 아티팩트에는 보존 기한과 접근 주체를 설정한다. 이렇게 해야 빠른 배포와 감사 가능한 변경 이력을 동시에 얻을 수 있다.
실패를 정상적인 흐름으로 다루는 것이 자동화의 완성도도 높인다.