이번 포스트에서는 IaC(Infrastructure as Code, 코드형 인프라)의 대표주자인 Terraform 에 대하여 자세히 파헤쳐보겠습니다.
최근 몇 년 사이 클라우드 환경이 보편화되면서, 인프라 관리 방식도 크게 변화하고 있습니다. 예전에는 서버를 구축하려면 데이터센터에 직접 가서 물리 서버를 세팅하고, 케이블을 연결하는 등 손이 많이 가는 작업이었죠. 하지만 AWS, Azure, GCP 같은 클라우드가 등장하면서, 이제는 클릭 몇 번으로 서버를 띄울 수 있게 되었습니다.
그런데 여기서 또 다른 문제가 생깁니다. 서비스가 커지면서 관리해야 할 서버와 리소스가 수십, 수백 개로 늘어나면 어떻게 될까요? 일일이 콘솔에 들어가서 클릭하며 관리하는 건 비효율적이고, 실수하기도 쉽습니다. 이런 문제를 해결하기 위해 등장한 것이 바로 IaC(Infrastructure as Code, 코드형 인프라), 그리고 그 대표주자인 Terraform입니다.
오늘은 Terraform이 무엇인지, 왜 많은 개발팀에서 사용하는지, 그리고 어떻게 시작하면 되는지 차근차근 살펴보겠습니다.
1. Terraform이란 무엇인가요?
Terraform은 HashiCorp에서 개발한 오픈소스 인프라 자동화 도구입니다. 쉽게 말하면, 클라우드 인프라를 코드로 작성하고 관리할 수 있게 해주는 도구예요. 2025년 2월에는 IBM이 HashiCorp를 인수하면서 Terraform의 미래에 대한 관심도 높아지고 있습니다.
예를 들어볼까요? AWS에서 EC2 인스턴스를 하나 만든다고 생각해보세요. 보통은 AWS Management Console에 로그인해서, EC2 메뉴를 찾고, Launch Instance(인스턴스 시작) 버튼을 클릭하고, 인스턴스 타입을 선택하고, Security Group(보안 그룹) 설정하고… 이런 과정을 거치게 됩니다. 하지만 Terraform을 사용하면 이 모든 과정을 코드 몇 줄로 표현할 수 있습니다.
resource "aws_instance" "my_server" {
ami = "ami-04876f29fd3a5e8ba"
instance_type = "t2.micro"
tags = {
Name = "MyWebServer"
}
}
이렇게 작성한 코드를 실행하면, Terraform이 알아서 AWS와 통신해서 서버를 만들어줍니다. 마법 같지 않나요?
2. 왜 Terraform을 사용해야 할까요?
“그냥 콘솔에서 클릭하면 되는데, 굳이 코드로 작성해야 하나요?”라고 생각하실 수 있습니다. 충분히 이해가 가는 의문입니다. 하지만 Terraform을 사용하면 얻을 수 있는 장점이 정말 많습니다.
인프라를 버전 관리(Version Control)할 수 있어요
코드로 작성된 인프라는 Git 같은 버전 관리 시스템으로 관리할 수 있습니다. 언제, 누가, 무엇을 변경했는지 모두 기록되고(Commit History), 문제가 생기면 이전 버전으로 롤백(Rollback)할 수도 있죠. 마치 소스 코드를 관리하듯이 인프라도 관리할 수 있습니다.
실수를 줄일 수 있어요
콘솔에서 수동으로 작업하다 보면 설정을 잘못 입력하거나, 중요한 옵션을 놓치는 경우가 생깁니다. 하지만 코드로 작성하면 팀원들이 Code Review(코드 리뷰)를 통해 실수를 미리 잡아낼 수 있고, 같은 설정을 여러 번 재사용할 때도 일관성을 유지할 수 있습니다.
똑같은 환경을 빠르게 복제할 수 있어요
개발 환경(Development), 테스트 환경(Staging), 운영 환경(Production)을 각각 구축해야 한다고 가정해보세요. 콘솔에서 일일이 클릭하면서 만들면 시간도 오래 걸리고, 환경마다 미묘한 차이가 생길 수 있습니다. 하지만 Terraform 코드가 있다면 변수만 바꿔서 동일한 구성을 순식간에 여러 곳에 배포할 수 있습니다.
여러 클라우드를 한 번에 관리할 수 있어요
Terraform은 AWS, Azure, GCP뿐만 아니라 Kubernetes, Docker, GitHub 등 다양한 플랫폼을 지원합니다. 하나의 도구로 여러 클라우드를 통합 관리할 수 있다는 건 큰 장점이에요. 이를 Multi-Cloud 관리라고 부릅니다.
실제로 얼마나 빨라질까요?
Puppet의 2016 DevOps 리포트에 따르면, IaC를 적용했을 때:
- 배포 주기가 200배 이상 빨라짐
- 장애 복구 시간이 24배 단축됨
- 개발에서 운영 배포까지의 리드타임이 2,000배 이상 줄어듦
물론 모든 경우에 이런 극적인 효과를 보는 건 아니지만, 자동화를 통해 생산성이 크게 향상되는 건 분명합니다.
3. Terraform은 어떻게 작동하나요?
Terraform의 작동 원리를 이해하면 더 효과적으로 사용할 수 있습니다. 기본적으로 Terraform은 선언적(Declarative) 방식으로 동작합니다.
선언적 vs 절차적
| 구분 | 절차적 (Procedural) | 선언적 (Declarative) |
|---|---|---|
| 방식 | “어떻게” 만들지 단계별 명령 | “무엇”을 원하는지만 정의 |
| 예시 | “VPC를 만들고, 서브넷을 만들고, 라우팅 테이블을 설정해” | “VPC와 서브넷이 있는 상태” |
| 장점 | 세밀한 제어 가능 | 간결하고 이해하기 쉬움 |
| 단점 | 코드가 길고 복잡함 | 내부 동작 파악이 어려울 수 있음 |
절차적 방식은 “A를 만들고, 그 다음 B를 만들고, 그 다음에 C를 만들어”처럼 단계별로 명령을 내리는 방식입니다. 반면에 선언적 방식은 “최종적으로 이런 상태가 되었으면 좋겠어”라고 원하는 결과만 정의하면, Terraform이 알아서 그 상태를 만들기 위한 단계를 계산하고 실행합니다.
Terraform의 핵심 구성 요소
Provider (프로바이더) AWS, GCP, Azure 같은 클라우드 공급자를 Provider라고 부릅니다. Terraform은 이 Provider들과 API로 통신하면서 리소스를 생성하거나 관리합니다. Terraform Registry에서 4,000개 이상의 Provider를 찾을 수 있습니다.
Resource (리소스) 실제로 생성할 인프라 구성 요소들을 Resource라고 합니다. EC2 Instance, Load Balancer(로드 밸런서), RDS Database(데이터베이스) 등이 모두 리소스에 해당합니다.
State File (상태 파일) Terraform은 terraform.tfstate라는 JSON 형식의 파일에 현재 배포된 인프라의 상태를 기록합니다. 이 파일을 통해 Terraform은 실제 인프라와 코드의 차이를 파악하고, 무엇을 변경해야 할지 결정합니다.
HCL (HashiCorp Configuration Language) Terraform 설정 파일은 HCL이라는 전용 언어로 작성되며, .tf 확장자를 사용합니다. HCL은 읽기 쉽고 작성하기도 간단한 편이라 처음 접하는 분들도 금방 익숙해질 수 있습니다.
Module (모듈) 공통적으로 사용하는 인프라 코드를 한 곳에 모아서 재사용 가능하게 만든 것이 Module입니다. 프로그래밍의 함수나 라이브러리와 비슷한 개념이에요.
4. Terraform의 기본 워크플로우
Terraform을 사용한 인프라 관리는 보통 init → plan → apply → destroy의 라이프사이클을 따릅니다. 하나씩 살펴볼까요?
terraform init (초기화)
프로젝트를 시작할 때 가장 먼저 실행하는 명령어입니다. init을 실행하면 Terraform이 필요한 Provider 플러그인을 다운로드하고 프로젝트를 초기화합니다.
terraform init
실행하면 .terraform 디렉터리가 생성되고, .terraform.lock.hcl 파일에 Provider 버전 정보가 기록됩니다. 이후 변경 사항을 추적할 수 있게 됩니다.
terraform plan (계획 확인)
plan 명령어는 코드를 실제로 적용하기 전에, 어떤 변경이 일어날지 미리 보여줍니다. 마치 시뮬레이션을 돌려보는 것과 같아요.
terraform plan
실행하면 다음과 같은 형식으로 결과가 표시됩니다:
Plan: 1 to add, 0 to change, 0 to destroy.
+기호: 생성될 리소스~기호: 변경될 리소스-기호: 삭제될 리소스
이 단계에서는 실제 인프라에 아무런 변화도 일어나지 않으니 안심하고 확인할 수 있습니다. plan 결과를 파일로 저장할 수도 있습니다:
terraform plan -out=tfplan
terraform apply (적용)
plan으로 확인한 내용이 맞다면, apply 명령어로 실제로 인프라를 생성하거나 변경합니다.
terraform apply
실행하면 한 번 더 확인을 요청하고, “yes”를 입력하면 실제로 클라우드에 리소스가 생성됩니다. apply가 완료되면 State File이 업데이트됩니다.
자동으로 승인하려면(CI/CD 환경에서 유용):
terraform apply -auto-approve
terraform destroy (삭제)
더 이상 필요 없는 리소스를 삭제할 때 사용합니다.
terraform destroy
이 명령어를 실행하면 Terraform이 관리하는 모든 리소스가 삭제되니 주의해서 사용해야 합니다! 특히 운영(Production) 환경에서는 더욱 조심해야 해요.
5. Terraform 설치하고 시작하기
이제 실제로 Terraform을 설치하고 간단한 예제를 만들어보겠습니다.
설치 방법
Mac 사용자
Mac에서는 Homebrew를 사용하면 간단하게 설치할 수 있습니다:
brew tap hashicorp/tap
brew install hashicorp/tap/terraform
버전 관리 도구인 tfenv를 사용하면 여러 버전을 쉽게 관리할 수 있습니다:
brew install tfenv
tfenv install 1.9.0
tfenv use 1.9.0
Windows 사용자
Windows에서는 Chocolatey를 사용할 수 있습니다:
choco install terraform
또는 Terraform 다운로드 페이지에서 직접 다운로드할 수 있습니다.
Linux 사용자 (Ubuntu/Debian)
wget -O - https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform
설치 확인
설치가 완료되었는지 확인해봅시다:
terraform version
다음과 같이 버전 정보가 표시되면 성공입니다:
Terraform v1.9.0
on darwin_arm64
첫 번째 Terraform 프로젝트 만들기
이제 실제로 간단한 프로젝트를 만들어보겠습니다. AWS를 예시로 들겠지만, 다른 클라우드도 비슷한 방식으로 작동합니다.
사전 준비: AWS 계정 및 인증 설정
먼저 AWS Access Key와 Secret Key가 필요합니다. AWS Console → IAM → Users → Security credentials에서 생성할 수 있습니다.
환경변수로 설정:
export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
더 안전한 방법은 AWS CLI를 설치하고 aws configure 명령으로 자격 증명을 설정하는 것입니다.
1단계: 프로젝트 디렉터리 생성
mkdir my-first-terraform
cd my-first-terraform
2단계: Provider 설정 파일 작성
provider.tf 파일을 만들어서 AWS Provider를 설정합니다:
terraform {
required_version = ">= 1.0.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "ap-northeast-2" # 서울 리전 (Seoul Region)
}
3단계: 리소스 정의 파일 작성
main.tf 파일을 만들어서 간단한 VPC를 정의합니다:
# VPC 생성
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
tags = {
Name = "my-terraform-vpc"
}
}
# 서브넷 생성
resource "aws_subnet" "public" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.1.0/24"
tags = {
Name = "my-terraform-subnet"
}
}
# Output으로 VPC ID 출력
output "vpc_id" {
description = "The ID of the VPC"
value = aws_vpc.main.id
}
4단계: 초기화 및 실행
# 초기화 (Initialize)
terraform init
# 포맷 검사 (Format Check)
terraform fmt
# 유효성 검증 (Validation)
terraform validate
# 계획 확인 (Plan)
terraform plan
# 적용 (Apply)
terraform apply
축하합니다! 첫 번째 Terraform 프로젝트를 성공적으로 실행했습니다. AWS Console → VPC Dashboard에서 확인해보면 실제로 VPC와 서브넷이 생성된 것을 볼 수 있을 거예요.
정리하기
테스트가 끝났다면 리소스를 삭제합니다:
terraform destroy
6. Terraform 사용 시 알아두면 좋은 팁
State 파일 관리가 중요합니다
terraform.tfstate 파일에는 현재 인프라의 모든 정보가 담겨 있고, 보안에 민감한 정보(비밀번호, Access Key 등)도 포함될 수 있습니다. 따라서:
- Git에 커밋하지 마세요!
.gitignore에 추가하세요 - AWS S3 같은 원격 저장소(Remote Backend)에 보관하세요
- State 파일에 암호화를 적용하세요
원격 백엔드 설정 예시:
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "terraform.tfstate"
region = "ap-northeast-2"
encrypt = true
}
}
Plan을 습관화하세요
apply를 바로 실행하지 말고, 항상 plan으로 먼저 확인하는 습관을 들이세요. 예상치 못한 변경이나 삭제를 미리 발견할 수 있습니다. 특히 Production 환경에서는 더욱 중요합니다!
모듈을 활용하세요
비슷한 구성을 반복해서 사용한다면, Module로 만들어서 재사용하는 것이 효율적입니다. 마치 프로그래밍에서 함수를 만드는 것과 같은 개념이에요.
예시:
module "vpc" {
source = "./modules/vpc"
vpc_cidr = "10.0.0.0/16"
vpc_name = "production-vpc"
}
콘솔 수정은 피하세요
Terraform으로 관리하는 리소스는 AWS Console에서 직접 수정하지 않는 것이 좋습니다. 콘솔에서 수정하면 Terraform의 State 파일과 실제 인프라가 불일치(Drift)하게 되어 문제가 생길 수 있습니다.
만약 콘솔에서 수정이 불가피했다면, terraform refresh 명령어로 State를 동기화하거나 terraform import로 기존 리소스를 가져올 수 있습니다.
작은 블록으로 나누세요
하나의 거대한 Terraform 프로젝트보다는, MSA(Micro Service Architecture) 구조처럼 작은 단위로 나누는 것이 좋습니다. 네트워크, 데이터베이스, 애플리케이션 등으로 분리하면:
- 변경 범위가 제한되어 안전함
- 테스트가 쉬워짐
- 팀 협업이 용이함
7. Terraform의 최신 동향 (2025년 말 기준)
IBM의 HashiCorp 인수
2025년 2월, IBM이 HashiCorp를 64억 달러에 인수했습니다. 이로 인해 Terraform의 미래에 대한 관심이 높아지고 있으며, 기업 고객을 위한 지원이 더욱 강화될 것으로 예상됩니다.
라이선스 변경과 OpenTofu
HashiCorp는 2023년 Terraform의 라이선스를 기존 MPL 2.0에서 BUSL 1.1(Business Source License)로 변경했습니다. 이에 대응해 커뮤니티는 OpenTofu라는 오픈소스 포크 프로젝트를 시작했고, Linux Foundation 산하의 CNCF로 이관되었습니다.
Terraform vs OpenTofu 비교
| 구분 | Terraform | OpenTofu |
|---|---|---|
| 라이선스 | BUSL 1.1 | MPL 2.0 (완전 오픈소스) |
| 관리 주체 | HashiCorp (IBM) | Linux Foundation |
| 상용 서비스 제공 | 제한 있음 | 제한 없음 |
| 기능 호환성 | 원본 | 1.5.6 버전 기반 포크 |
| 커뮤니티 | 성숙함 | 성장 중 |
대부분의 사용자에게는 이런 변화가 큰 영향을 미치지 않지만, 장기적인 관점에서 OpenTofu도 함께 지켜보는 것이 좋습니다. OpenTofu는 Terraform과 거의 동일한 방식으로 작동하며, 기존 Terraform 코드를 그대로 사용할 수 있습니다.
Terraform의 대안들
Terraform 외에도 다양한 IaC 도구들이 있습니다:
- Pulumi: TypeScript, Python 등 일반 프로그래밍 언어 사용
- AWS CDK: AWS 전용, 프로그래밍 언어로 작성
- Crossplane: Kubernetes 네이티브 IaC
- Ansible: 설정 관리에 특화
각 도구마다 장단점이 있으니, 프로젝트 상황에 맞는 것을 선택하면 됩니다.
OpenTofu란? Terraform의 대안, 오픈소스 IaC(Infrastructure as Code) 툴
8. 실전 활용 사례
사례 1: 멀티 리전 배포
여러 리전에 동일한 인프라를 배포할 때:
variable "regions" {
default = ["ap-northeast-2", "us-east-1", "eu-west-1"]
}
module "vpc" {
for_each = toset(var.regions)
source = "./modules/vpc"
region = each.value
}
사례 2: 환경별 설정 분리
개발/스테이징/운영 환경 구분:
# dev.tfvars
environment = "dev"
instance_type = "t2.micro"
# prod.tfvars
environment = "prod"
instance_type = "t3.large"
실행 시:
terraform apply -var-file="dev.tfvars"
terraform apply -var-file="prod.tfvars"
사례 3: 조건부 리소스 생성
variable "create_database" {
type = bool
default = false
}
resource "aws_db_instance" "this" {
count = var.create_database ? 1 : 0
# ... 설정
}
9. 문제 발생 시 해결 팁
Plan과 Apply 결과가 다를 때
Plan에서는 문제 없었는데 Apply에서 오류가 나는 경우가 있습니다. 주로:
- 리소스 이름 중복
- 권한 부족
- 의존성 문제
디버깅 방법:
# 상세 로그 확인
export TF_LOG=DEBUG
terraform apply
State 파일이 꼬였을 때
# State 새로고침
terraform refresh
# State 목록 확인
terraform state list
# 특정 리소스 제거
terraform state rm aws_instance.example
Import로 기존 리소스 가져오기
AWS Console에서 먼저 만든 리소스를 Terraform으로 관리하고 싶다면:
# 1. 코드 작성
# main.tf에 리소스 정의
# 2. Import 실행
terraform import aws_instance.example i-1234567890abcdef0
# 3. Plan으로 검증
terraform plan
10. Terraform을 배우기 좋은 리소스 출처
공식 문서 및 튜토리얼
- Terraform 공식 문서 – 가장 정확하고 최신 정보
- Terraform Registry – Provider와 Module 검색
- HashiCorp Learn – 단계별 실습 튜토리얼
- Terraform AWS 시작하기 – AWS 초보자용
커뮤니티 및 포럼
- Terraform 공식 포럼
- Reddit r/Terraform
- 국내 DevOps 커뮤니티 및 블로그
추천 도서
- “Terraform: Up & Running” by Yevgeniy Brikman
- “Terraform in Action” by Scott Winkler
연습 환경
- Terraform Cloud – 무료 티어 제공
- LocalStack – 로컬에서 AWS 테스트
Terraform은 처음에는 새로운 개념과 명령어들 때문에 어렵게 느껴질 수 있습니다. 하지만 기본적인 워크플로우를 이해하고 간단한 예제부터 시작하면, 생각보다 금방 익숙해질 수 있습니다.
중요한 건 완벽하게 알고 시작하려고 하기보다는, 작은 프로젝트부터 직접 만들어보면서 경험을 쌓는 것입니다. 처음에는 실수도 하고 에러도 만나겠지만, 그런 과정을 통해 더 깊이 있게 이해하게 됩니다. 인프라를 코드로 관리한다는 건 단순히 새로운 도구를 배우는 것 이상의 의미가 있습니다. 개발 방식 자체를 바꾸고, 팀 협업을 개선하며, 결과적으로 더 안정적이고 효율적인 시스템을 만들 수 있게 해줍니다.
실제로 많은 기업들이 Terraform을 도입한 후 인프라 관리 시간이 크게 줄어들고, 배포 속도가 빨라졌으며, 오류도 현저히 감소했다고 보고하고 있습니다. 처음에는 어느정도의 학습량이 필요하지만, 그 투자는 충분히 가치가 있습니다.
궁금한 점이 있다면 공식 문서와 커뮤니티를 적극 활용해보세요. 다른 개발자들의 경험담도 많은 도움이 될 거예요. 🙂