Terraform vs. Ansible: 실제로 필요한 것은 어느 것인가?

Infrastructure as Code를 처음 접하는 사람들은 보통 두 가지 중 하나로 묻는다: "먼저 어느 도구를 배워야 하나" 또는 "왜 팀들이 둘 다 사용하나." 간단한 답변은 Terraform과 Ansible이 서로 다른 문제를 해결한다는 것이고, 대부분의 프로덕션 환경에서는 하나를 선택하기보다는 이들을 함께 사용한다는 것이다.

Terraform이 실제로 하는 일

Terraform은 프로비저닝 도구다. 인프라가 어떻게 존재해야 하는지를 선언한다: VPC, EC2 인스턴스 세 개, RDS 데이터베이스, 특정 정책을 가진 S3 버킷. HCL로 최종 상태를 기술하고, terraform plan으로 무엇이 변할지 확인한 다음, terraform apply로 실행한다. Terraform은 상태 파일(로컬 또는 DynamoDB 락이 있는 S3 버킷 같은 백엔드)을 유지하면서 config를 클라우드 제공자의 실제 리소스 ID로 매핑한다.

강점은 제공자 간의 종속성 해결에 있다. security group을 만들고 EC2 인스턴스에 붙이라고 Terraform에 말하면, 순서를 자동으로 파악한다. AWS, Azure, GCP, Cloudflare, Datadog 등 수십 개의 다른 제공자와 같은 워크플로우로 작동하며, 인프라가 여러 벤더에 걸쳐 있으면 이것이 중요해진다.

Terraform이 못하는 것은 머신 내부에서 일어나는 모든 일이다. 패키지 설치, config 파일 수정, 서비스 재시작 같은 것들을 의미 있게 처리하지 못한다. remote-exec 같은 provisioner가 존재하지만, HashiCorp 자신도 부트스트랩 이상의 것들에는 피할 것을 권장한다.

Ansible이 실제로 하는 일

Ansible은 설정 관리 도구다. SSH(또는 Windows용 WinRM)를 통해 연결하고 이미 존재하는 머신에 대해 작업을 실행한다: nginx 설치, config 파일 템플릿, 사용자 생성, 서비스 재시작, cron 작업이 있는지 확인. Playbook은 YAML이고, 모듈은 기본적으로 멱등성을 가지므로, 같은 playbook을 두 번 실행해도 시스템이 이미 원하는 상태와 일치하면 두 번째는 아무것도 변하지 않는다.

Ansible은 대상 호스트에 에이전트를 설치할 필요가 없고, Python과 SSH 접근만 있으면 되기 때문에 기존 인프라에 쉽게 추가할 수 있다. 엄격하게 "프로비저닝"이 아닌 오케스트레이션 작업도 잘 한다 — 플릿 전체의 롤링 재시작, blue-green 배포 단계, 한 호스트의 데이터베이스 마이그레이션 후 로드 밸런서 업데이트.

겹치는 부분과 사람들이 헷갈리는 곳

두 도구 모두 기술적으로 서로의 일을 조금 할 수 있다. Ansible은 클라우드 모듈(amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine)을 가지고 인프라를 시작할 수 있다. Terraform은 새 인스턴스에서 shell 명령을 실행할 수 있는 provisioner를 가지고 있다. 하지만 Ansible을 프로비저닝에 사용하면 Terraform의 상태 추적과 plan/diff 워크플로우를 포기하는 것이고, Terraform provisioner를 설정에 사용하면 멱등성 있고 반복 가능한 설정 관리를 포기하는 것이다.

대부분의 팀이 정착하는 실제 분할:

• Terraform은 인프라를 구축한다: 네트워크, 컴퓨트 인스턴스, 로드 밸런서, 관리형 데이터베이스, IAM 역할.
• Ansible은 위에 있는 것을 설정한다: 소프트웨어 설치, 사용자, config 파일, 서비스 상태, 애플리케이션 배포 단계.

핸드오프의 구체적 예

AWS의 로드 밸런서 뒤에 웹 서버 세 개를 설정한다고 하자.

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Terraform은 인스턴스를 생성하고 IP를 출력한다. 동적 Ansible 인벤토리(amazon.aws.aws_ec2 인벤토리 플러그인은 EC2 태그를 직접 읽으므로 수작업 복사가 필요 없음)에 그 출력을 넣은 후 실행한다:

ansible-playbook -i aws_ec2.yml site.yml

여기서 site.yml은 nginx를 설치하고, 앱 config를 배치하며, 서비스를 시작한다. Terraform은 nginx를 건드리지 않는다. Ansible은 VPC를 건드리지 않는다. 각 도구는 자신의 영역에 머물러 있고, 각각 자신의 상태/멱등성 모델을 가지고 있어서 다른 것과 충돌하지 않는다.

피할 가치가 있는 흔한 실수들

Terraform 상태를 git에 저장하는 것이 가장 흔한 초기 실수다 — 상태 파일은 평문 시크릿을 포함할 수 있고 머지 충돌을 일으켜 인프라 모델을 손상시킬 수 있다. 처음부터 원격 백엔드를 사용하자.

Ansible의 경우 실제로 멱등성 있지 않은 playbook을 작성하는 것이 실수다 — shell이나 command 모듈을 이미 check-then-act 로직을 올바르게 처리하는 proper 모듈(ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd)이 있는 것들에 사용하는 것이다.

무엇을 먼저 배울지 결정하는 중이라면: 클라우드 프로비저닝과 다중 환경 설정을 하고 있다면 Terraform을 배우고, 이미 가지고 있는 서버의 설정 편차를 관리하고 있다면 Ansible을 배우자. 대부분의 DevOps 역할은 첫 해 안에 둘 다에 대한 숙련도를 기대한다.

상태 관리, 동적 인벤토리, 이 도구들을 중심으로 한 전체 CI/CD 파이프라인 구축에 대해 더 알아보려면 Korra Studio의 관련 DevOps 및 Cloud 섹션을 확인하자.