인프라를 코드로,
Terraform vs CloudFormation

안녕하세요. 클라우드 인프라를 웹 콘솔에서 마우스로 클릭하며 생성하던 시대는 지났습니다. 이제는 코드로 인프라를 정의하고 관리하는 IaC(Infrastructure as Code)가 표준이 되었죠.

‍

하지만 IaC를 도입하려고 하면 첫 번째 관문에 부딪힙니다. 바로 도구 선택입니다. AWS가 직접 만든 CloudFormation을 쓸 것인가? 아니면 업계 표준으로 자리 잡은 Terraform을 쓸 것인가?

‍

오늘은 이 두 도구의 결정적인 차이점인 상태 관리(State Management) 방식을 중심으로, 우리 팀에는 어떤 도구가 맞는지 명쾌한 가이드를 제시해 드립니다.

‍

1. AWS CloudFormation: AWS의, AWS에 의한, AWS를 위한 도구

CloudFormation은 AWS가 제공하는 네이티브 관리형 서비스입니다. JSON이나 YAML 형식으로 템플릿을 작성하면, AWS가 알아서 리소스를 생성해 줍니다.

‍

AWS 네이티브의 장점 별도의 설치나 서버 구성이 필요 없습니다. AWS 콘솔 자체가 관리 도구입니다. AWS의 새로운 기능이나 리소스가 출시되면 가장 빠르게(물론 가끔 늦을 때도 있지만) 지원됩니다. 서비스 간 통합이 매끄럽고, 기술 지원(Support Plan)을 받을 수 있습니다.

‍

단점 문법이 장황합니다. (JSON/YAML 특성상 코드가 매우 길어집니다.) AWS 이외의 리소스(예: Datadog, GitHub 등)를 관리하기가 매우 까다롭거나 불가능합니다.

‍

2. Terraform: 멀티 클라우드의 절대 강자

HashiCorp가 만든 Terraform은 사실상 IaC의 업계 표준입니다. HCL(HashiCorp Configuration Language)이라는 자체 언어를 사용하는데, 가독성이 매우 뛰어납니다.

‍

오픈소스 생태계의 장점 AWS뿐만 아니라 Azure, GCP, Kubernetes, 심지어 Domino's Pizza 주문까지 가능한 수천 개의 Provider를 지원합니다. 모듈(Module) 생태계가 강력해서, 남들이 잘 만들어둔 아키텍처를 쉽게 가져다 쓸 수 있습니다. HCL 언어가 직관적이고 배우기 쉽습니다.

단점 상태 파일(State File)을 직접 관리해야 하는 부담이 있습니다. 버전 호환성 문제나 Provider 업데이트 이슈를 직접 챙겨야 합니다.

‍

3. 핵심 승부처: 상태(State)를 누가 관리하는가?

두 도구의 가장 큰 차이점은 바로 현재 인프라의 상태를 저장하는 방식에 있습니다. 이 차이가 운영 난이도를 결정합니다.

‍

CloudFormation: 관리형 상태 (Managed State) CloudFormation은 상태 파일을 사용자가 관리할 필요가 없습니다. AWS 내부적으로 스택(Stack) 정보를 저장하고 관리합니다. 사용자는 그저 템플릿을 업데이트하고 배포만 하면 됩니다. 상태가 꼬였을 때 사용자가 직접 수정할 수 있는 방법이 제한적이지만, 반대로 말하면 상태 관리에 신경 쓸 필요가 없다는 뜻입니다.

‍

Terraform: 상태 파일 (State File, tfstate) Terraform은 terraform.tfstate라는 파일에 현재 인프라의 상태를 기록합니다. 이 파일은 인프라의 지도이자 진실의 원천(Source of Truth)입니다. 따라서 이 파일을 아주 소중하게 다뤄야 합니다. 로컬 PC에 저장하면 팀원 간 공유가 안 되므로 S3 같은 원격 저장소(Remote Backend)에 저장해야 합니다. 동시에 여러 명이 수정하지 못하도록 DynamoDB 등을 이용해 잠금(Locking) 설정을 별도로 해줘야 합니다. 상태 파일이 꼬이거나 삭제되면 실제 인프라와 연결이 끊기는 대형 사고가 발생할 수 있습니다.

‍

4. 선택 가이드: 그래서 뭘 써야 할까요?

무조건적인 정답은 없지만, 상황에 따른 추천은 있습니다.

‍

이런 경우 CloudFormation(또는 AWS CDK)을 추천합니다. 우리 회사는 100% AWS만 사용한다. 별도의 상태 파일(tfstate) 관리나 백엔드 구성이 귀찮고 부담스럽다. AWS 기술 지원(Enterprise Support)을 통해 인프라 문제를 해결하고 싶다. AWS CDK(프로그래밍 언어로 인프라 정의)를 사용하고 싶다. (CDK는 CloudFormation으로 컴파일됩니다.)

‍

이런 경우 Terraform을 추천합니다. AWS 외에 온프레미스, 타 클라우드, SaaS(Datadog, GitHub 등)도 함께 관리해야 한다. (가장 큰 이유) DevOps 엔지니어 채용이 중요하다. (Terraform 경험자가 시장에 훨씬 많습니다.) 커뮤니티의 방대한 모듈을 활용해 빠르게 구축하고 싶다. JSON/YAML보다는 프로그래밍 언어스러운 HCL의 깔끔함을 선호한다.

마치며

과거에는 Terraform의 압승 분위기였으나, 최근에는 프로그래밍 언어(Python, TypeScript 등)로 인프라를 짜는 AWS CDK가 등장하면서 CloudFormation 진영도 다시 강력해졌습니다.

하지만 멀티 클라우드 환경이나 다양한 3rd Party 도구와의 연동을 고려한다면 Terraform은 여전히 가장 강력한 선택지입니다.

중요한 것은 도구가 아니라 인프라를 코드로 관리하겠다는 의지입니다. 팀의 상황에 맞춰 가장 익숙하고 편한 도구부터 시작해 보세요.