본문
IaC 선택의 기로: Terraform vs CloudFormation 실전 비교
AWS/운영 및 관리 2026. 1. 13. 17:12
Infrastructure as Code (IaC)를 본격적으로 도입하기로 했을 때, 가장 먼저 마주하는 질문은 "그래서 뭘 쓸 것인가?"입니다.
AWS 환경에서 서비스를 운영하다 보면 자연스럽게 Terraform과 AWS CloudFormation 두 가지 선택지로 좁혀집니다.
"AWS 쓰니까 당연히 네이티브인 CloudFormation이 낫지 않나?"라고 단순하게 접근했다가, 실제 운영 환경의 복잡도와 확장성을 고려하며 고민에 빠졌던 경험을 바탕으로 두 도구의 핵심 차이를 정리해 봅니다.
1. 벤더 종속성: 닫힌 생태계 vs 열린 확장성
가장 본질적인 차이는 '어디까지 관리할 수 있는가'입니다.
- CloudFormation: AWS의, AWS에 의한, AWS를 위한 도구입니다. AWS 신규 서비스가 출시되면 가장 빠르게 지원하고 통합도 매끄럽습니다. 하지만 AWS 울타리를 벗어나는 순간 무용지물이 됩니다.
- Terraform: 특정 벤더에 종속되지 않습니다. Provider 매커니즘을 통해 AWS, Azure, GCP는 물론 Datadog 같은 서드파티 솔루션까지 하나의 워크플로우로 관리할 수 있습니다. 멀티 클라우드나 하이브리드 환경을 조금이라도 고려한다면 Terraform이 유일한 대안입니다.
2. 상태(State) 관리의 주체: 블랙박스 vs 화이트박스
운영하면서 피부로 가장 크게 와닿는 차이점입니다.
- CloudFormation: 상태 관리를 AWS가 알아서 해줍니다. 편리하지만, 가끔 스택이 꼬였을 때 내부에서 어떤 일이 벌어지는지 알기 어려운 '블랙박스'처럼 느껴질 때가 있습니다.
- Terraform: 상태 파일(terraform.tfstate)을 사용자가 직접 관리해야 합니다. S3 백엔드 구성과 Locking 설정 등 초기 공수가 필요하지만, 현재 인프라 상태를 명확하게 파악하고 제어할 수 있는 '화이트박스'에 가깝습니다. 팀 단위 협업 시 이 상태 파일 관리가 매우 중요해집니다.
3. 언어와 가독성: HCL vs JSON/YAML
"코드로 정의한다"는 측면에서 개발 경험(DX)도 무시할 수 없습니다.
- CloudFormation: 범용적인 JSON이나 YAML을 사용합니다. 익숙하지만, 리소스가 조금만 많아져도 파일이 비대해지고 가독성이 급격히 떨어지는 고통을 맛보게 됩니다.
- Terraform: 자체 언어인 HCL(HashiCorp Configuration Language)을 사용합니다. 처음엔 낯설 수 있지만, 인프라 정의에 최적화되어 있어 변수 사용, 모듈화, 조건문 처리 등이 훨씬 직관적이고 간결합니다.
AWS 내에서만 빠르게 인프라를 구축하고, 상태 관리의 복잡함에서 벗어나고 싶다면 CloudFormation이 합리적인 선택입니다. 반면, 조금이라도 복잡도가 높거나 멀티 클라우드 확장 가능성을 열어두어야 한다면, 학습 곡선을 감내하더라도 Terraform을 선택하는 것이 장기적으로 유리했습니다.
- Terraform (좌측): 외부의 'State File'을 참조하며 Provider를 통해 멀티 클라우드 리소스를 제어합니다.
- CloudFormation (우측): 템플릿을 AWS에 업로드하면, AWS 내부 엔진이 상태를 관리하며 리소스를 생성합니다.
댓글