서버 한 대를 만들고 그 안에 웹 서버를 설치해야 한다. Terraform과 Ansible을 모두 쓰는 자료를 보면 “둘 중 하나만 써야 하나?”라는 질문이 생긴다. 두 도구는 겹치는 일을 할 수도 있지만, 이 예에서는 클라우드 자원을 만들고 추적하는 일과 만들어진 서버의 소프트웨어를 설정하는 일로 책임을 나누면 이해하기 쉽다.
Terraform은 어떤 상태를 관리할까?
도식은 Terraform → VM·네트워크 → Ansible의 순서로 소유 경계를 나눈다. 이는 도구가 절대 할 수 없는 일을 가르는 선이 아니라, 인프라 수명주기와 서버 내부 설정의 책임을 겹치지 않게 두기 위한 기준이다.
Terraform은 구성 파일에 원하는 인프라를 선언하고, 상태 데이터로 관리 중인 실제 자원과의 연결을 추적한다. 가상 예를 들면 VM, 네트워크, 방화벽 규칙을 만들고 변경 계획을 확인하는 역할이다.
Terraform 구성: VM 1대 + 네트워크 규칙
현재 클라우드: VM 0대
plan에서 확인할 질문: 어떤 자원이 새로 생기고 바뀌는가?terraform plan은 변경을 제안하고 apply는 변경을 실행한다. 계획을 읽지 않고 적용하면 의도하지 않은 삭제나 재생성이 있을 수 있다. 상태 파일에는 인프라 정보가 담기므로 접근 권한과 보관 방식을 신중히 정해야 한다. 교육 자료의 init → plan → apply 순서는 이런 변경 흐름을 이해하는 출발점이다.
Ansible은 만들어진 서버에서 무엇을 할까?
Ansible은 인벤토리에서 관리 대상을 정하고 Playbook의 작업으로 소프트웨어 설치·설정 같은 단계를 자동화한다. 예를 들어 Terraform이 VM을 만든 뒤, Ansible이 그 VM에 웹 서버 패키지와 설정 파일을 적용하는 식이다.
관리 대상: 새로 만든 VM
Playbook의 목표: 웹 서버 패키지 설치, 설정 파일 배치
다시 실행할 때 확인할 질문: 이미 맞는 설정도 불필요하게 바꾸는가?Ansible의 많은 모듈은 원하는 상태가 이미 맞으면 변경하지 않도록 설계되지만, 모든 Playbook이 자동으로 멱등적인 것은 아니다. 임의 셸 명령이나 외부 API 호출을 넣었다면 반복 실행 결과를 직접 확인해야 한다. 이 경계는 Ansible Playbook 설명과 대조했다.
경계를 나눈 뒤 어떤 실패를 점검할까?
VM은 생성됐는데 Ansible 연결이 실패한다면 먼저 VM 주소·네트워크 규칙·접속 계정을 확인한다. 패키지는 설치됐는데 앱이 동작하지 않는다면 설정 파일, 서비스 상태와 로그를 본다. 두 단계의 오류를 한 덩어리로 취급하면 Terraform 구성을 다시 적용해야 할지, Playbook만 고쳐야 할지 판단하기 어렵다.
반대로 Terraform 밖에서 클라우드 자원을 수동 변경하면 상태와 실제 인프라가 어긋날 수 있다. plan으로 차이를 보고 수동 변경을 유지할지 되돌릴지 결정한다. Ansible도 대상 서버에 수동 변경이 쌓이면 반복 실행 시 덮어쓸 수 있으므로, 변경 책임과 소유자를 정해야 한다. 두 도구를 동시에 적용할 때는 출력값 전달, 실행 순서, 실패 후 재시도 범위를 명확히 한다.
도구를 하나만 써도 될까?
작은 실습에서 특정 도구 하나로 필요한 일을 모두 처리할 수는 있다. 이 글의 구분은 절대 법칙이 아니라 책임을 읽기 쉽게 나누는 설계 예다. 팀이 익숙한 도구, 관리 자원의 종류, 변경 승인·감사 요구에 따라 경계는 달라진다. 중요한 것은 같은 자원을 서로 다른 도구가 경쟁해 덮어쓰지 않도록 소유권을 정하는 것이다.
핵심 요약: 생성과 내부 구성을 책임별로 나눈다
Terraform은 클라우드 자원 구성과 상태 추적, Ansible은 서버 안의 소프트웨어·설정 적용에 적합한 경우가 많다. 먼저 변경 계획과 반복 실행 결과를 각각 확인하고, 두 도구가 같은 설정을 동시에 소유하지 않게 한다.
작성자
기초 개념을 구현과 검증, 실제 운영 판단까지 연결해 기록합니다.
