# Ansible vs Terraform 2026년 완벽 비교: IaC와 DevOps 면접 대비 가이드

> Ansible과 Terraform의 사용법을 상세히 설명합니다. 선언적 및 절차적 접근 방식의 차이, 상태 관리, OpenTofu 동향, DevOps 면접에서 자주 나오는 질문과 답변 예시를 소개합니다.

- Published: 2026-08-22
- Updated: 2026-08-22
- Author: Anthony Fillion-Maillet
- Reading time: 5 min

---

Ansible과 Terraform 비교는 DevOps 면접에서 가장 자주 나오는 질문 중 하나입니다. 그러나 이 질문의 틀 자체가 오해를 내포하고 있습니다. 두 도구는 서로 다른 문제를 해결합니다. Ansible 2.20은 구성 관리와 애플리케이션 배포를 담당하고, Terraform 1.15는 인프라 리소스 프로비저닝을 담당합니다. 각 도구가 뛰어난 영역, 겹치는 부분, 그리고 상호 보완하는 방법을 이해하는 것이 시니어 DevOps 엔지니어로서의 역량을 증명하는 핵심입니다.

> **핵심 차이점**
>
> Terraform은 인프라 상태를 선언적으로 관리합니다(VM, 네트워크, 데이터베이스). Ansible은 해당 인프라 위에서 실행되는 것들을 절차적으로 구성합니다(패키지, 서비스, 파일). 대부분의 프로덕션 환경에서는 두 도구를 모두 사용합니다.

## 선언적 vs 절차적: 근본적인 차이

Terraform은 선언적 접근 방식을 사용합니다. 구성 파일에서 원하는 최종 상태를 기술하면 Terraform이 해당 상태에 도달하는 데 필요한 변경 사항을 계산합니다. 이 접근 방식은 하나의 단위로 생성, 수정 또는 삭제해야 하는 인프라에 적합합니다.

```hcl
# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow HTTP and HTTPS"
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
```

`terraform apply`를 실행하면 리소스가 존재하지 않을 경우 두 리소스를 모두 생성하고, 구성과 일치하도록 업데이트합니다. 변경 사항 없이 다시 실행하면 작업이 발생하지 않습니다. Terraform은 구성을 상태 파일과 비교하여 변경이 필요 없음을 확인합니다.

Ansible은 절차적 접근 방식을 사용하여 태스크를 순서대로 실행합니다. Ansible 모듈은 종종 멱등성을 가지지만(두 번 실행해도 같은 결과), Playbook 자체는 최종 상태가 아닌 액션의 순서를 기술합니다.

```yaml
# webserver.yml
- name: Configure web server
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    
    - name: Copy nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
    
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
  
  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted
```

각 태스크는 순서대로 실행됩니다. notify/handler 패턴은 선언적인 동작을 제공합니다. handler는 트리거된 횟수와 관계없이 마지막에 한 번만 실행됩니다.

## 상태 관리: 면접의 핵심 주제

Terraform은 [상태 파일](https://developer.hashicorp.com/terraform/language/state)을 유지하여 구성을 실제 리소스에 매핑합니다. 이 상태는 리소스 ID, 의존성, 메타데이터를 추적합니다. 상태가 없으면 Terraform은 무엇이 존재하고 무엇을 변경해야 하는지 판단할 수 없습니다.

| 관점 | Terraform | Ansible |
|--------|-----------|----------|
| 상태 저장소 | 필수(로컬 파일 또는 원격 백엔드) | 기본적으로 없음 |
| 드리프트 감지 | `terraform plan`으로 내장 | 명시적 검사 필요 |
| 리소스 추적 | 상태를 통해 자동 | 인벤토리 기반 |
| 롤백 | 상태에서 삭제 후 재생성 | 네이티브 롤백 없음 |

Ansible에는 동등한 상태 파일이 없습니다. 대상 시스템에 연결하여 태스크를 실행하고, 현재 시스템 상태와 모듈의 멱등성에 의존합니다. 이로 인해 Ansible은 시작하기 쉽지만 시간에 따른 변경 추적이 어렵습니다.

면접에서 자주 묻는 질문 중 하나는 상태 파일 보안입니다. Terraform 상태에는 민감한 데이터가 포함될 수 있습니다: 데이터베이스 비밀번호, API 키, 리소스 식별자 등. 프로덕션 배포에서는 상태를 원격(S3, Azure Blob, Terraform Cloud)에 암호화 및 접근 제어와 함께 저장합니다.

```hcl
# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/infrastructure.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}
```

DynamoDB 테이블은 잠금을 제공하여 두 엔지니어가 동시에 상태를 수정하는 것을 방지합니다.

## 각 도구의 사용 시기

Terraform은 클라우드 인프라 프로비저닝에 뛰어납니다: 가상 머신, 관리형 데이터베이스, 로드 밸런서, IAM 역할, VPC. 리소스 간 의존성을 자동으로 처리하고 일관된 HCL 구문을 통해 모든 주요 클라우드 제공업체를 지원합니다.

Ansible은 기존 시스템 구성에 뛰어납니다: 패키지 설치, 사용자 관리, 애플리케이션 코드 배포, 멀티 스텝 배포 오케스트레이션. SSH(Windows의 경우 WinRM)를 통해 연결하며 대상 머신에 에이전트가 필요하지 않습니다.

중복 영역이 혼란을 야기합니다. 둘 다 VM에 소프트웨어를 설치할 수 있습니다. Terraform은 [provisioners](https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax)를 사용하여 리소스 생성 후 스크립트를 실행할 수 있습니다. Ansible은 `amazon.aws.ec2_instance`와 같은 모듈을 통해 클라우드 리소스를 생성할 수 있습니다. 그러나 각 도구를 강점 외의 영역에서 사용하면 유지보수 문제가 발생합니다.

> **피해야 할 안티패턴**
>
> Terraform provisioner를 구성 관리에 광범위하게 사용하면 취약한 인프라가 됩니다. Provisioner는 생성 시에만 실행되고 이후 apply에서는 실행되지 않습니다. 인프라에는 Terraform을, 구성에는 Ansible을 사용하세요.

## 프로덕션 환경의 통합 워크플로우

대부분의 조직에서는 두 도구를 함께 사용합니다. Terraform이 인프라를 프로비저닝하고 연결 세부 정보를 출력합니다. Ansible이 해당 출력을 사용하여 시스템을 구성합니다.

```hcl
# outputs.tf
output "web_server_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

output "db_endpoint" {
  value       = aws_rds_instance.main.endpoint
  description = "RDS endpoint for application config"
}
```

CI/CD 파이프라인은 먼저 Terraform을 실행하고 출력을 캡처한 다음, Ansible 인벤토리를 동적으로 생성하고 새 인프라에 대해 Playbook을 실행합니다.

```yaml
# ansible/inventory/aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
  instance-state-name: running
hostnames:
  - private-ip-address
groups:
  webservers: "'web' in tags.Role"
  databases: "'db' in tags.Role"
```

이 동적 인벤토리는 AWS에 직접 쿼리하여 태그를 기준으로 인스턴스를 그룹화합니다. 수동 IP 관리가 필요 없습니다.

## OpenTofu: 판도를 바꾼 포크

HashiCorp는 2023년 8월에 Terraform을 Business Source License(BSL) 하에 재라이선스했습니다. 커뮤니티는 Terraform 1.5를 [OpenTofu](https://opentofu.org/)로 포크했으며, 현재 Linux Foundation 산하에서 호스팅되고 있습니다.

2026년 8월 현재, OpenTofu 1.11.6은 대부분의 Terraform 워크플로우에서 드롭인 대체로 계속 작동합니다. 동일한 HCL 구문, 동일한 프로바이더 에코시스템, 동일한 상태 포맷입니다. OpenTofu는 Terraform 오픈소스 바이너리에 없는 기능을 추가했습니다: 상태 암호화, provider `for_each`, 조기 변수 평가 등입니다.

면접 준비를 위해 라이선스 차이를 이해해야 합니다. BSL은 내부 사용을 허용하지만 경쟁 제품 구축을 제한합니다. 벤더 종속성을 우려하거나 특정 컴플라이언스 요구사항이 있는 조직은 OpenTofu의 MPL 2.0 라이선스를 선호할 수 있습니다. 2024년 12월 IBM의 HashiCorp 인수는 벤더 관계 논의에 새로운 변수를 추가했습니다.

## DevOps 면접 빈출 질문

**Q: Ansible로 Terraform을 대체할 수 있습니까?**

효과적으로 대체할 수 없습니다. Ansible은 클라우드 리소스를 생성할 수 있지만 상태 관리 기능이 없습니다. 동일한 Playbook을 두 번 실행하면 중복 리소스가 생성될 수 있습니다. Terraform의 상태 파일은 존재하는 것을 추적하고 최소한의 변경을 계산합니다. Ansible은 장점인 구성 관리에 사용하세요.

**Q: Terraform에서 시크릿을 어떻게 처리합니까?**

시크릿을 버전 관리에 커밋하지 마세요. 환경 변수, Vault 통합 또는 클라우드 제공업체 시크릿 매니저를 사용하세요. 로그에 표시되지 않도록 변수를 sensitive로 표시하세요:

```hcl
# variables.tf
variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password from Vault or environment"
}
```

**Q: Ansible의 멱등성이란 무엇입니까?**

멱등적 작업은 한 번 실행하든 여러 번 실행하든 동일한 결과를 생성합니다. `apt` 모듈과 `state: present`는 패키지가 없으면 설치하고 이미 설치되어 있으면 아무것도 하지 않습니다. 멱등적 Playbook을 작성하면 반복 실행 시 의도하지 않은 변경을 방지합니다.

**Q: 인프라 코드를 어떻게 테스트합니까?**

Terraform: `terraform validate`로 구문 검사, `terraform plan`으로 변경 사항 미리보기, [Terratest](https://terratest.gruntwork.io/)와 같은 도구로 통합 테스트 실행. Ansible: `ansible-lint`로 문제 감지, `--check` 모드로 드라이런 실행, [Molecule](https://ansible.readthedocs.io/projects/molecule/)로 컨테이너에 대해 role 테스트.

Terraform 면접 준비를 더 깊이 하려면 [Terraform 면접 질문: Infrastructure as Code 완벽 가이드](/blog/devops/terraform-interview-questions-infrastructure-as-code)를 참조하세요. [Terraform 기초](/technologies/devops/interview-questions/terraform-basics) 및 [Ansible 구성 관리](/technologies/devops/interview-questions/ansible-configuration) 모듈에서 실습할 수 있습니다.

## 버전 호환성과 에코시스템

2026년 8월 현재 안정 버전:

| 도구 | 버전 | 출시일 | 주요 기능 |
|------|---------|--------------|-------------|
| Ansible | 2.20.5 | 2026년 4월 | 컬렉션 관리 개선 |
| Terraform | 1.15.8 | 2026년 7월 | Windows ARM64 지원, convert 함수 |
| OpenTofu | 1.11.6 | 2026년 4월 | 상태 암호화, provider for_each |

Ansible의 컬렉션 아키텍처는 핵심 기능과 프로바이더별 모듈을 분리합니다. `amazon.aws` 컬렉션은 Ansible 코어와 독립적으로 업데이트를 받습니다. 이는 CI/CD 파이프라인에서 버전 고정에 중요합니다.

Terraform의 프로바이더 버전 관리도 유사한 원칙을 따릅니다. 잠금 파일(`terraform.lock.hcl`)은 팀 구성원과 CI 시스템 간에 일관된 프로바이더 버전을 보장합니다.

```hcl
# versions.tf
terraform {
  required_version = ">= 1.15.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}
```

## 선택 기준: 의사결정 프레임워크

질문은 "Ansible이냐 Terraform이냐"가 아닙니다. 질문은 "어떤 도구가 어떤 책임을 담당하느냐"입니다.

| 사용 사례 | 권장 도구 |
|----------|------------------|
| VM, 데이터베이스, 네트워크 프로비저닝 | Terraform |
| OS 구성, 패키지 설치 | Ansible |
| Kubernetes 리소스 관리 | Terraform 또는 kubectl 및 Helm |
| 애플리케이션 코드 배포 | Ansible 또는 CI/CD 네이티브 |
| IAM 역할 및 정책 생성 | Terraform |
| 서버의 사용자 계정 관리 | Ansible |
| 모니터링 인프라 구축 | Terraform(리소스 생성) + Ansible(에이전트 구성) |

이러한 도구가 최신 배포 워크플로우에 어떻게 적합한지에 대한 전체 그림은 [CI/CD 파이프라인 면접 질문](/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins)을 참조하세요.

## 시니어 엔지니어가 알아야 할 Ansible과 Terraform

- Terraform은 인프라 상태를 선언적으로 관리하고, Ansible은 시스템을 절차적으로 구성합니다. 두 도구를 함께 사용하면 유지보수가 용이한 인프라가 됩니다.
- 상태 파일 보안이 중요합니다. Terraform 상태는 암호화와 잠금을 활성화하여 원격에 저장하세요.
- OpenTofu는 추가 기능이 있는 MPL 라이선스 Terraform 대안을 제공합니다. 대부분의 워크플로우에서 마이그레이션은 간단합니다.
- 멱등성은 자동이 아닙니다. 반복 실행에서 일관된 결과를 생성하는 Playbook을 작성하세요.
- 동적 인벤토리로 수동 호스트 관리가 필요 없습니다. 현재 인프라에 대해 클라우드 제공업체에 직접 쿼리합니다.
- 버전 고정으로 예기치 않은 상황을 방지합니다. Terraform에서 프로바이더 버전을 잠그고, Ansible에서 컬렉션 버전을 고정하세요.
- 인프라 코드 테스트는 다른 접근 방식이 필요합니다: 변경 미리보기에 `terraform plan`, Ansible 드라이런에 `--check` 모드, 두 도구 모두에 통합 테스트 프레임워크를 사용합니다.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/ko/blog/devops/ansible-vs-terraform-2026-infrastructure-as-code-devops-interview