<aside>
☁️ 클라우드웨이브 · W06 · 5/5 · 예상 읽기 6~8분
</aside>
이번 주의 마지막에는 Ansible과 Terraform을 나란히 놓고 자동화의 경계를 정리했다. 둘 다 코드를 사용하고 반복 가능한 실행을 지향하지만, 다루는 대상과 생애주기가 다르다. 이 차이를 모르면 서버 설정 도구로 네트워크 자원을 만들려 하거나, 인프라 도구로 애플리케이션 내부의 모든 파일을 관리하려는 식의 혼선이 생긴다.
DevOps를 도구 목록으로만 이해하면 CI/CD 파이프라인을 추가하는 데서 멈추기 쉽다. 핵심은 변경을 작게 만들고, 자동 검증과 피드백을 통해 개발과 운영의 책임을 연결하는 것이다. IaC는 인프라 구성을 코드와 리뷰의 대상으로 바꾸어 환경의 재현성과 변경 이력을 높인다.
Ansible은 구성 관리에 적합하다. 원격 호스트의 패키지, 파일, 서비스, 권한을 원하는 상태로 맞추는 흐름을 표현한다. Terraform은 프로바이더를 통해 클라우드나 온프레미스의 네트워크, 컴퓨팅, 저장소 같은 자원을 선언하고 그 생애주기를 추적한다. 두 도구를 함께 쓸 때는 누가 어떤 상태의 소유자인지 경계를 정해야 한다.
flowchart LR
A[인프라 요구사항] --> B[Terraform plan]
B --> C{변경 검토}
C -->|승인| D[Terraform apply]
D --> E[자원 상태와 output]
E --> F[Ansible 구성 적용]
F --> G[서비스 검증]
절차적 접근은 실행 순서를 세밀하게 지시한다. 선언적 접근은 최종적으로 어떤 상태를 원하는지 설명하고 도구가 현재 상태와의 차이를 계산하게 한다. 실제 시스템에서는 두 관점이 섞인다. Terraform의 리소스 정의는 선언적이지만, 변경 계획을 검토하고 승인하는 운영 절차는 명확한 순서를 가진다. Ansible도 원하는 상태를 표현하면서 작업 간 의존성을 관리한다.
선언적이라고 해서 위험이 자동으로 사라지는 것은 아니다. 잘못된 코드도 원하는 상태로 반영될 수 있으므로 변경 전 계획과 범위 검토가 필수다. 특히 state는 Terraform이 관리 대상과 현재 구성을 추적하는 중요한 정보이므로 협업 환경에서는 접근 권한, 공유 저장소, 잠금, 백업과 복구를 함께 설계해야 한다.
기본 흐름은 초기화, 계획, 반영, 결과 확인으로 나눈다. init은 필요한 플러그인과 백엔드를 준비한다. plan은 실제 변경 전에 생성·수정·삭제될 내용을 보여준다. apply는 검토된 계획을 반영하고, output은 다른 시스템이나 운영자가 확인할 값을 노출한다. 출력에는 공개해도 되는 값만 포함해야 한다.
variable "environment" {
type = string
default = "learning"
}
output "environment_name" {
value = var.environment
}
CI/CD는 이 흐름을 자동 실행하는 다음 연결고리다. Week 7에서는 코드 변경이 검증, 계획, 승인, 배포로 이어지는 파이프라인을 살펴볼 수 있다. 다만 자동화된 apply를 먼저 만들기보다, 사람이 계획을 읽고 위험을 판단할 수 있는 단계부터 정착시키는 편이 안전하다.
새 환경을 만들 때 Terraform으로 자원 경계를 정의하고, 생성된 호스트의 운영체제와 서비스 설정은 Ansible Role로 맞추는 식으로 책임을 나눈다. 변경 전에는 plan을 저장하고 검토하며, 적용 뒤에는 output과 실제 서비스 상태를 비교한다. state를 코드 저장소에 무심코 포함하지 않고 공유 방식과 잠금 정책을 먼저 정하는 것도 중요하다.