클라우드에 서버 한 대를 띄우는 일은 콘솔에서 클릭 몇 번이면 끝난다. 그런데 서버가 수십 대로 늘고, 개발·스테이징·운영 환경을 똑같이 세 벌 만들어야 하고, 여기에 네트워크·보안 그룹·데이터베이스·로드밸런서까지 얽히기 시작하면 이야기가 달라진다. 누가 무엇을 언제 바꿨는지 아무도 모르는 상태, 이른바 구성 드리프트(configuration drift)가 생긴다. Terraform은 바로 이 문제를 “인프라를 코드로 관리한다”는 발상으로 푸는 도구다. 이 글은 Terraform이 무엇이고 왜 IaC(Infrastructure as Code)의 사실상 표준이 되었는지, 핵심 개념과 실제 워크플로우, 그리고 2023년 이후 불거진 라이선스 논쟁까지 입문자 눈높이로 정리한다.
Terraform이란 무엇인가
Terraform은 HashiCorp가 2014년 공개한 오픈소스 IaC 도구다. 한마디로 “어떤 인프라를 원하는지”를 코드로 선언하면, 실제 클라우드에 그 상태를 그대로 만들어 주는 프로그램이다. AWS·Azure·Google Cloud 같은 퍼블릭 클라우드는 물론이고 Kubernetes·Cloudflare·Datadog·GitHub까지, API를 가진 거의 모든 서비스를 대상으로 삼을 수 있다.
핵심은 선언형(declarative) 방식이라는 점이다. “EC2 인스턴스를 실행하려면 이 명령을 순서대로 쳐라”(명령형)가 아니라, “웹 서버 2대, t3.micro 사양, 이 보안 그룹에 연결된 상태가 최종 목표다”라고 결과만 서술한다. 목표 상태에 도달하기 위해 무엇을 생성·수정·삭제할지는 Terraform이 알아서 계산한다. 건축에 비유하면, 벽돌을 어떤 순서로 쌓을지 일일이 지시하는 대신 완성된 건물의 설계도를 건네는 셈이다.
2026년 7월 기준 Terraform의 최신 안정 버전은 1.15.7(2026년 6월 24일 릴리스)이다. 도구 자체는 Go로 작성됐고, 단일 실행 파일(CLI)로 배포돼 macOS·Linux·Windows 어디서든 동일하게 동작한다. HashiCorp의 공식 정의는 Terraform 공식 문서에서 확인할 수 있다.
IaC(코드형 인프라)가 왜 필요한가
Terraform을 이해하려면 먼저 IaC라는 배경을 짚어야 한다. IaC는 서버·네트워크·스토리지 같은 인프라를 사람이 콘솔에서 손으로 만드는 대신, 코드 파일로 정의하고 버전 관리하는 방식이다. Red Hat의 설명에 따르면 IaC의 목표는 “환경 구성을 반복 가능하고 예측 가능하게 만드는 것”이다.
수동 관리(콘솔 클릭)의 문제는 명확하다.
- 재현이 안 된다: 운영 환경과 똑같은 테스트 환경을 다시 만들려면 클릭 순서를 기억에 의존해야 한다.
- 기록이 없다: 누가 보안 그룹 규칙을 열었는지 추적이 어렵다.
- 휴먼 에러: 손으로 만들다 보면 한 곳만 설정을 빠뜨리는 일이 잦다.
IaC는 이 세 가지를 코드로 해결한다. 인프라 정의가 Git에 올라가므로 코드 리뷰·버전 관리·롤백이 모두 가능해지고, 같은 코드를 실행하면 언제나 같은 결과가 나온다. AWS 문서는 이를 “인프라 프로비저닝을 소프트웨어 개발과 동일한 규율로 다루는 것”이라고 표현한다. Terraform은 이 IaC 철학을 특정 클라우드에 종속되지 않고 여러 벤더를 하나의 언어로 다룰 수 있게 구현한 대표 주자다.
Terraform의 핵심 구성요소 4가지
Terraform을 처음 배울 때 반드시 알아야 할 개념은 네 가지다. HCL, Provider, Resource, 그리고 State다.
HCL — 인프라를 서술하는 언어
Terraform 설정은 .tf 확장자 파일에 HCL(HashiCorp Configuration Language)로 작성한다. HCL은 JSON·YAML과 달리 사람이 읽기 쉬우면서도 변수·표현식·반복문을 지원하는 도메인 특화 언어다. 아래는 AWS에 EC2 인스턴스 한 대를 정의하는 최소 예시다.
# AWS 프로바이더를 서울 리전으로 설정
provider "aws" {
region = "ap-northeast-2"
}
# EC2 인스턴스 리소스 선언
resource "aws_instance" "web" {
ami = "ami-0abcdef1234567890"
instance_type = "t3.micro"
tags = {
Name = "itinsights-web-server"
}
}
코드만 봐도 “서울 리전에 t3.micro 웹 서버 한 대”라는 의도가 읽힌다. 이 가독성이 HCL의 핵심 가치다.
Provider — 클라우드로 향하는 어댑터
Provider(프로바이더)는 Terraform과 실제 서비스의 API를 이어 주는 플러그인이다. aws 프로바이더는 AWS API를, google 프로바이더는 GCP API를 호출한다. 각 프로바이더는 내부적으로 해당 서비스가 노출하는 REST API를 대신 호출해 준다. 2026년 현재 Terraform Registry에는 수천 개의 공식·커뮤니티 프로바이더가 등록돼 있어, AWS·Azure·GCP 같은 메이저 클라우드뿐 아니라 Cloudflare·MongoDB·PagerDuty 같은 SaaS도 코드로 관리할 수 있다. 이 방대한 프로바이더 생태계가 Terraform이 CloudFormation 같은 벤더 전용 도구보다 널리 쓰이는 이유다.
Resource — 실제로 만들 대상
Resource(리소스)는 Terraform이 생성·관리하는 인프라 단위 하나하나다. 위 예시의 aws_instance가 리소스이며, 이 밖에 VPC·서브넷·S3 버킷·IAM 역할 등이 모두 리소스로 표현된다. 리소스들은 서로 참조할 수 있어, 예컨대 인스턴스가 특정 보안 그룹의 ID를 참조하도록 연결하면 Terraform이 의존성 그래프를 만들어 생성 순서를 자동으로 결정한다.
State — Terraform의 기억 장치
가장 중요하면서도 입문자가 가장 자주 데는 개념이 State(상태)다. Terraform은 자신이 만든 리소스의 현재 상태를 terraform.tfstate라는 JSON 파일에 기록한다. 이 파일이 있어야 Terraform은 “내가 관리하는 서버가 지금 몇 대이고 어떤 설정인지”를 안다. 다음번 실행 때 Terraform은 매번 클라우드를 전수 조회하는 대신 이 State를 신뢰하고, 코드와 State의 차이만 계산한다.
문제는 이 State 파일이 팀 협업에서 골칫거리가 된다는 점이다. 여러 사람이 각자 로컬의 State로 작업하면 충돌이 나고, State에는 DB 비밀번호 같은 민감 정보가 평문으로 남기도 한다. 그래서 실무에서는 State를 S3·Terraform Cloud 같은 원격 백엔드에 저장하고 잠금(lock)을 거는 것이 사실상 필수다. 이는 Terraform을 도입할 때 반드시 설계해야 하는 부분이다.
Terraform 워크플로우: init → plan → apply
Terraform의 일상 작업은 네 개의 명령으로 요약된다. 개념보다 이 흐름을 몸에 익히는 것이 입문의 지름길이다.
# 1. 초기화 — 프로바이더 플러그인 다운로드
terraform init
# 2. 계획 — 무엇이 생성/변경/삭제될지 미리 보기
terraform plan
# 3. 적용 — 실제 인프라에 반영
terraform apply
# 4. 파괴 — 만든 리소스 전부 정리
terraform destroy
여기서 plan이 Terraform의 진짜 강점이다. apply를 실행하기 전에 “리소스 3개 추가, 1개 변경, 0개 삭제” 식으로 변경 사항을 미리 보여 주기 때문에, 실수로 운영 DB를 지우는 사고를 사전에 걸러낼 수 있다. 이 “미리 보기 후 적용” 패턴은 Google Cloud의 Terraform 가이드에서도 안전한 인프라 변경의 핵심으로 강조된다. 오케스트레이션을 다뤄 본 독자라면 쿠버네티스의 선언형 매니페스트를 적용하는 흐름과 비슷한 “선언 → 실행” 리듬을 느낄 수 있을 것이다.
Terraform vs 다른 도구 — 어디에 서 있나
IaC 영역에는 Terraform 외에도 여러 도구가 있다. 각자 지향점이 다르므로 비교로 위치를 잡아 보자.
| 도구 | 방식 | 언어 | 범위 | 특징 |
|---|---|---|---|---|
| Terraform | 선언형 프로비저닝 | HCL | 멀티클라우드 | 프로바이더 생태계 최대, 사실상 표준 |
| OpenTofu | 선언형 프로비저닝 | HCL | 멀티클라우드 | Terraform 오픈소스 포크(호환) |
| AWS CloudFormation | 선언형 프로비저닝 | YAML/JSON | AWS 전용 | AWS 네이티브, 벤더 종속 |
| Pulumi | 선언형 프로비저닝 | 범용 언어(TS·Python 등) | 멀티클라우드 | 익숙한 프로그래밍 언어 사용 |
| Ansible | 명령형 구성 관리 | YAML | 서버 설정 | 프로비저닝보다 설정 관리에 강점 |
핵심 구분선은 두 가지다. 첫째, 프로비저닝이냐 구성 관리냐다. Terraform은 “서버·네트워크를 만드는” 프로비저닝에 특화됐고, Ansible은 “이미 있는 서버 안에 소프트웨어를 설치·설정하는” 쪽에 강하다. 실무에서는 Terraform으로 인프라를 만들고 Ansible로 그 안을 채우는 조합이 흔하다. 둘째, 멀티클라우드냐 벤더 종속이냐다. CloudFormation은 AWS만 다루지만 Terraform은 하나의 언어로 여러 클라우드를 넘나든다. 이 이식성이 컨테이너 오케스트레이션이나 서버리스 함수 같은 이질적 인프라를 한데 묶어 관리해야 하는 팀에게 특히 매력적이다.
라이선스 논쟁과 OpenTofu의 등장
Terraform을 2026년 시점에서 이야기하려면 라이선스 사건을 빼놓을 수 없다. 오랫동안 Terraform은 완전한 오픈소스(MPL 2.0)였다. 그런데 2023년 8월, HashiCorp는 라이선스를 BSL(Business Source License) 1.1로 전환한다고 발표했다. BSL은 “HashiCorp와 경쟁하는 방식으로는 쓸 수 없다”는 제한을 두는 소스 공개 라이선스로, 순수 오픈소스는 아니다.
이 결정에 반발한 커뮤니티와 여러 벤더는 마지막 MPL 버전인 Terraform 1.5를 포크해 OpenTofu라는 이름의 대체 프로젝트를 만들었고, 이를 Linux Foundation 산하 오픈소스로 올렸다. OpenTofu는 Terraform과 명령·문법이 호환되며, 2026년 6월 기준 최신 버전은 1.12.3이다. 흥미롭게도 OpenTofu는 State 암호화, 프로바이더 for_each 같은 일부 기능을 Terraform 오픈소스 CLI보다 먼저 출시하며 독자 노선을 걷고 있다.
여기에 2025년 2월 27일, IBM이 HashiCorp를 64억 달러에 인수하며 지형이 한 번 더 바뀌었다. Terraform Cloud는 2024년 4월 HCP Terraform으로 리브랜딩됐고, IBM은 이를 Ansible 등 자사 자동화 포트폴리오와 통합하는 방향을 제시하고 있다. 따라서 지금 IaC를 새로 도입하는 팀이라면 “HashiCorp/IBM의 Terraform이냐, 커뮤니티의 OpenTofu냐”를 함께 저울질하게 된다. 두 도구는 대부분 호환되므로 학습 자체는 어느 쪽으로 시작해도 무방하다.
한계와 도입 판단 기준
Terraform이 만능은 아니다. 도입 전 알아야 할 현실적 한계도 분명하다.
- State 관리의 부담: 앞서 짚었듯 원격 백엔드·잠금·비밀 관리를 제대로 설계하지 않으면 오히려 사고의 근원이 된다.
- 드리프트(drift): 누군가 콘솔에서 손으로 리소스를 바꾸면 코드와 실제가 어긋난다. Terraform은 이를 감지하지만, 팀 규율이 없으면 무용지물이다.
- 러닝 커브: HCL 문법은 쉬워도 모듈 설계·워크스페이스·의존성 관리는 규모가 커질수록 복잡해진다.
- 상태 손상 위험: State 파일이 깨지면 복구가 까다롭다.
그렇다면 언제 도입해야 할까? 서버가 한두 대뿐이고 앞으로도 변화가 거의 없다면 콘솔 관리로 충분할 수 있다. 반면 환경을 반복 생성해야 하거나, 여러 명이 인프라를 함께 다루거나, 멀티클라우드를 쓰는 팀이라면 Terraform의 투자 대비 효과가 크다. 여러분의 조직은 지금 인프라를 몇 명이, 얼마나 자주 바꾸고 있는가? 이 질문의 답이 도입 시점을 알려 준다.
정리
지금까지 살펴본 것처럼 Terraform은 인프라를 코드로 선언하고, plan으로 미리 확인한 뒤 apply로 반영하는 IaC 도구다. HCL로 목표 상태를 서술하면 Provider가 각 클라우드 API를 호출하고, State가 그 결과를 기억한다. 프로바이더 생태계의 폭과 멀티클라우드 이식성 덕분에 사실상 업계 표준으로 자리 잡았지만, State 관리와 드리프트라는 숙제, 그리고 BSL 전환 이후 OpenTofu와의 양립이라는 새 변수도 함께 안게 됐다.
입문자라면 로컬에서 프로바이더 하나로 리소스 한 개를 만들었다 지우는 init → plan → apply → destroy 사이클부터 손에 익히는 것을 권한다. 그 감각이 잡히면 모듈·원격 State·CI 연동으로 자연스럽게 확장할 수 있다. 컨테이너 오케스트레이션을 함께 공부하고 싶다면 쿠버네티스 입문 글을, 인프라 밑단에서 서비스들이 어떻게 통신하는지 궁금하다면 REST API란 무엇인가 글을 이어서 읽어 보길 권한다.
IT 인프라 도구는 버전과 라이선스 정책이 자주 바뀐다. 본문의 버전·수치는 2026년 7월 기준이며, 실제 도입 시에는 공식 문서와 최신 릴리스 노트를 함께 확인하기를 권한다.