해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 59 - Continuous Delivery pipelines for cloud infrastructure
1. 더 빠르고 안전한 IaC를 위하여
오늘날 Terraform, Ansible, Pulumi와 같은 도구들이 널리 사용되고 있음에도 불구하고, 많은 조직에서 인프라 변경을 운영 환경에 배포하는 데에는 여전히 오랜 시간이 소요된다.
또한, 이 과정은 완전히 자동화된 절차라기보다는 배포 후 문제가 없기를 바라는 기도에 가까운 경우가 많다.
따라서, 해당 프레젠테이션에서는 이러한 IaC의 허점을 지적하며 인프라를 더 빠르고, 안전하고, 반복 가능하게 전달하기 위한 '인프라 지속적 인도 (Continuous Delivery for Infrastructure)의 3대 원칙'을 제시한다.
2. Everything as Code
CI/CD의 가장 기초가 되는 첫 번째 원칙은 인프라를 구성하는 모든 요소를 코드로 정의하고 버전 관리 시스템(VCS)에 저장하는 것이다.
그렇다면 IaC에서는 어떤 것들을 코드화해야되는가?
.
├── infra-code
│ └── ...
├── pipeline.yaml
├── config.yaml
├── tests/
├── policies/
├── README.md
├── backend.tf
├── terraform-dev.tfvars
└── ...-
인프라 코드: 실제 리소스를 정의하는 테라폼 등의 코드
-
파이프라인 정의: 배포 과정을 자동화하는 CI/CD 파이프라인 스크립트
-
설정(Configuration): 도구 자체의 설정뿐만 아니라, 운영(Prod), 사전 운영(Pre-prod), 테스트 등 환경을 분리하기 위한 모든 설정값
-
테스트 코드: 인프라를 검증하기 위한 자동화된 테스트 스크립트
-
규정 준수(Compliance) 정책: 보안 및 규정 위반을 탐지하는 정책 코드
-
문서: 저장소 사용법, 아키텍처 등을 설명하는 문서
앞서 설명한 자동화해야하는 요소들을 하나의 저장소에서 폴더 구조로 관리할 때 얻을 수 있는 이점이 존재한다.
-
추적성(Traceability): 모든 변경 사항이 커밋으로 기록되므로, '누가, 언제, 무엇을' 변경했는지에 대한 완벽한 감사 추적이 가능하다. 배포 시 태그를 활용하면 배포 이력 관리도 수월해진다.
-
재현 가능성(Reproducibility): 인프라 코드와 도구 버전, 설정이 함께 묶여 관리되므로, 언제든 특정 시점의 인프라 상태를 똑같이 복원할 수 있다.
다만, 인프라 코드 관리 시 주의사항이 존재하는데 브랜치(Branch) 전략이다.
인프라 코드는 브랜치를 오래 유지하는 것과 궁합이 좋지 않으므로, CI의 핵심 요건에 따라 브랜치를 사용하더라도 최소 하루에 한번은 메인 브랜치에 Merge하여 코드의 파편화를 막아야한다.
3. 지속적 테스트와 전달
두 번째 원칙은 작업 중인 모든 내용을 지속적으로 테스트하고 전달하는 것이다.
이를 위해 여러 단계의 방어막을 구축하는 '스위스 치즈 모델(Swiss Cheese Model)'을 적용한다.
개별 테스트 단계가 완벽하지 않더라도, 겹겹이 쌓인 레이어를 통해 최종적으로는 거의 모든 오류를 걸러낼 수 있다.
1단계: 오프라인 테스트
가장 빠르고 저렴한 테스트 단계로, 개발자의 로컬 머신이나 파이프라인 최초 단계에서 수행한다. 해당 테스트는 품질과 보안 검증을 개발 초기 단계로 앞당기는 'Shift Left' 전략의 핵심이다.
-
유효성 검사: terraform validate 등을 통해 문법 오류나 변수 초기화 여부를 확인
-
린팅(Linting): tflint와 같은 도구로 팀의 코딩 컨벤션 준수 여부를 체크
-
정책 검사: 규정 준수 도구를 사용해 보안 정책 위반 사항을 사전에 차단
2단계: 온라인 스택 테스트
실제 클라우드 환경에 인프라 리소스를 생성해보는 단계로, Terratest와 같은 도구(Go 언어 기반)를 활용한다.
-
주의점: 도구 자체를 테스트하지 마라. 예를 들어 "테라폼이 리소스를 생성했는가?"를 확인하는 것은 무의미하다. -> 테라폼의 기본 기능이므로 테스트 자체가 무의미
-
올바른 테스트: "생성된 DB 유저와 자격 증명으로 실제 DB 로그인이 가능한가?"와 같이 상위 레벨의 워크플로우를 검증해야 한다.
3단계: 통합 및 여정 테스트
개별 스택이 아닌 여러 구성 요소를 결합했을 때의 동작을 검증한다.
더 넓은 범위의 리소스가 상호작용하는 시나리오를 테스트한다.
4단계: 운영 환경 모니터링
모든 테스트를 통과하고 배포된 이후에도, 문제가 발생했을 때 즉시 감지하고 대응할 수 있는 모니터링 체계를 갖추는 것이 마지막 안전망이다.
해당 테스트 과정을 거치며 가장 중요한 점은 테스트된 코드는 절대 수정하면 안된다는 것이다.
파이프라인의 초기 단계(Dev/Test)에서 검증된 인프라 코드는 변경되지 않은 채, 오직 Config만 교체되며 상위 환경(Pre-prod -> Prod)으로 승격되어야 한다.
이를 통해 각 환경마다 서로 다른 코드가 실행되는 스노플레이크(Snowflake) 현상을 방지하고 배포의 신뢰성을 보장한다.
4. 작고 단순한 조각으로의 분리
거대한 인프라를 한 번에 관리하는 것은 위험하므로, 세 번째 원칙은 독립적으로 변경 가능한 작고 단순한 조각으로 인프라를 나누는 것이다.
-
인프라 계층 구조
-
비즈니스 역량: 최상위 레벨 (제품, 애플리케이션).
-
기술 역량 (IDP): 내부 개발 플랫폼 형태로 제공되는 기술적 기반.
-
인프라 스택 : 함께 관리되는 리소스의 묶음 (예: 쿠버네티스 클러스터 + 노드 그룹 + 로드 밸런서).
-
클라우드 리소스: 최하위 레벨 (AWS, Azure, GCP 리소스).
-
이때, 효율적인 관리를 위해 스택을 나누는 기준은 다음과 같다.
-
팀/도메인 경계: 해당 인프라를 사용하고 관리하는 팀 단위로 나눈다.
-
변경 빈도: 자주 변경되는 요소(예: 권한, Key Vault)와 거의 변경되지 않는 요소(예: VPC, 네트워크)를 분리하여, 불필요한 전체 배포를 막는다.
-
권한 경계: 특정 리소스에 대한 접근 권한을 세분화하기 위해 스택을 분리한다.
하지만, 하나의 모듈을 너무 많은 팀이 공유하게 되면, 한팀의 변경사항이 다른 팀에 영향을 주거나 모듈 관리팀이 Bottleneck이 될 수 있다.
따라서, 때로는 약간의 코드 중복이 조직적인 의존선을 만드는 것보다 나을 수 있다.
5. 구현 전략 및 도전 과제
시작하기: 워킹 스켈레톤 (Walking Skeleton)
처음부터 완벽한 파이프라인을 구축하려 하지 마라.
프로젝트 시작 시점에 단순히 개발 환경에 terraform apply를 실행하는 수준의 뼈대(Skeleton)만이라도 갖추고 시작해야 한다.
그리고 운영 환경으로의 배포 경로를 프로젝트 막바지까지 미루지 말고, 일찍 그리고 자주 연습해야 한다.
도전 과제 1: 폭발 반경 (Blast Radius)
변경 사항이 실패했을 때 시스템에 미치는 잠재적 손상 범위를 항상 고려해야 한다.
인프라를 잘게 나누는 것(3원칙)이 이 폭발 반경을 줄이는 핵심이다.
도전 과제 2: 불변(Immutable) vs 증분(Incremental)
-
애플리케이션: 컨테이너 이미지를 통째로 교체하는 불변 배포가 일반적이다.
-
인프라: 기존 상태 위에 변경 사항만 덧입히는 '증분 배포' 방식이다.
해결책: 파이프라인 설계 시, 이전 상태의 인프라를 먼저 생성한 뒤 -> 최신 변경 사항을 적용하는 과정을 포함시켜야 한다.
6. 결론
성공적인 클라우드 인프라 배포를 위한 핵심은 "모든 것의 코드화, 지속적인 테스트, 독립적인 스택 분리라는 3대 원칙"을 준수하는 것이다.
인프라 코드와 설정을 엄격히 분리하여 검증된 코드를 상위 환경으로 승격시키는 파이프라인을 구축하면 환경 간 불일치 리스크가 제거되게 된다.
이를 통해 변경 사항의 폭발 반경(Blast Radius)을 최소화하고 피드백 주기를 단축함으로써 인프라 운영의 안전성과 배포 속도를 동시에 확보할 수 있다.
결과적으로 인프라를 단순한 리소스 묶음이 아닌 신뢰 가능한 소프트웨어 제품으로 관리할 수 있게 된다.
