테라폼(Terraform) 핵심 정리
1. 테라폼이란?
테라폼(Terraform)은 인프라스트럭처를 코드로 관리하는 IaC(Infrastructure as Code) 도구다.
AWS, Azure, GCP, Kubernetes 같은 인프라를 선언적 구성 파일(HCL) 로 정의하고,
그 코드에 맞춰 실제 리소스를 생성·변경·삭제해 준다.
핵심 아이디어는 단순하다.
현재 상태(state) ↔ 원하는 목표 상태(desired state)를 비교해서
필요한 변경만 자동으로 계산하고 적용하는 도구
1-1. 프로비저닝(provisioning) 개념
프로비저닝은 서비스를 돌리기 위해 필요한 인프라를 준비하는 과정이다.
- 서버 생성
- 네트워크 설정
- 스토리지 할당
- 미들웨어 설치 등
이걸 클릭으로 수동 셋업하는 대신,
테라폼으로 코드에 적어두고 자동으로 구성하는 흐름이라고 보면 된다.
1-2. 테라폼이 등장한 배경
클라우드 인프라가 복잡해지면서 이런 문제가 생겼다.
- 콘솔에서 수동 설정 → 사람이 실수하기 쉬움
- 개발/스테이징/운영 환경 설정이 서로 조금씩 다름
- 같은 설정을 여러 번 반복해서 만들기 귀찮음
- 문서만으로는 실제 설정과 안 맞는 경우가 많음
이걸 해결하려고 2014년 HashiCorp가 Terraform을 만들었다.
- 인프라를 코드로 정의
- Git으로 버전 관리
- 코드 리뷰·PR 기반 협업
- 같은 코드를 여러 환경에 재사용
덕분에 DevOps 쪽에서 거의 기본 도구처럼 쓰이게 된 상태다.
1-3. 테라폼 장단점
장점
-
선언적 구성
- “무엇을 만들고 싶은지”만 적으면 됨
- 절차가 아니라 최종 상태를 정의하는 방식
-
멀티 클라우드 지원
- AWS, GCP, Azure, Kubernetes 등을 동일한 패턴으로 관리
- 특정 클라우드에 종속되지 않는 IaC 설계 가능
-
상태 관리(State Management)
terraform.tfstate파일에 현재 인프라 상태를 저장- plan/apply 시 이 파일을 기준으로 차이점 계산
-
멱등성(Idempotency)
- 같은 코드를 여러 번
terraform apply해도 결과는 항상 동일 - “이미 원하는 상태면 아무것도 안 함”
- 같은 코드를 여러 번
단점
-
학습 난이도
- HCL 문법, state 개념, provider 구조 등 익힐 게 꽤 많다
-
동적 구성 제약
- 아주 복잡한 분기/동적 로직은 코드가 금방 지저분해진다
-
State 관리 중요
tfstate가 꼬이거나 유실되면 apply 동작이 이상해질 수 있다- 팀 단위에서는 remote state(S3, GCS, Consul 등)로 따로 관리해야 안전하다
2. 테라폼 주요 개념
2-1. HCL(HashiCorp Configuration Language)
- Terraform 설정 언어
.tf확장자를 사용- JSON도 될 수는 있지만 대부분 HCL 문법을 사용
2-2. 프로바이더(Provider)
테라폼과 실제 시스템을 이어주는 플러그인 개념이다.
각 클라우드/서비스 별로 provider가 따로 있다.
| 서비스 모델 | 예시 프로바이더 |
|---|---|
| IaaS | AWS, Azure, GCP, Alibaba, Oracle Cloud |
| PaaS | Kubernetes, Docker, AWS Elastic Beanstalk |
| SaaS | GitHub, GitLab, Atlassian(Jira, Confluence) |
테라폼 코드에서 provider "aws" { ... } 이런 식으로 선언하고 사용한다.
2-3. 리소스(Resource)
프로바이더가 실제로 생성·관리하는 개별 인프라 요소다.
- AWS 기준: EC2, S3, RDS, IAM 등
- Kubernetes 기준: Deployment, Service, Ingress 등
코드에서는 보통 이렇게 선언한다.
resource "aws_s3_bucket" "example" {
bucket = "my-bucket"
}2-4. Terraform State
테라폼이 인프라 상태를 기억하는 방식이다.
-
terraform.tfstate파일에 현재 인프라 상태를 저장 -
이 파일을 기준으로
- 어떤 리소스를 만들었는지
- 어떤 속성으로 생성했는지
- 코드와 실제 상태가 어떻게 다른지
를 계산한다.
중요 포인트:
- tfstate 없으면 Terraform은 “지금 뭘 만들었는지” 모른다
- tfstate가 망가지면 plan/apply 결과도 망가질 수 있다
- 보안 이슈 때문에 Git에 그대로 올리면 안 된다
- 팀 작업에서는 S3/GCS 등으로 remote state를 사용해서 중앙 관리하는 패턴이 일반적이다
2-5. 멱등성(Idempotency)
테라폼의 큰 특징 중 하나다.
- 같은 코드를 가지고
terraform apply를 여러 번 실행해도 - 이미 원하는 상태라면 아무 변경도 하지 않는다
- 수정한 부분만 딱 집어서 생성/변경/삭제해 준다
결국 “코드가 곧 진실(source of truth)이고,
인프라는 항상 그 상태에 맞춰진다”는 구조를 만들어 준다.
3. Terraform 기본 워크플로우
Terraform 작업 흐름은 항상 이 패턴을 따른다.
init → plan → apply
3-1. init: 초기화
terraform init- 필요한 provider 플러그인 다운로드
- backend, state 저장 방식 준비
- 새 프로젝트를 처음 시작할 때, 또는 provider 설정을 바꿨을 때 실행
3-2. plan: 변경 사항 미리 보기
terraform plan- 현재 state ↔ 코드에 정의된 desired state 비교
- 어떤 리소스를 생성/변경/삭제할지 미리 보여준다
- 실제로 인프라를 건드리지는 않는다
코드 수정 후에는 항상 plan으로 확인하고,
변경 내용이 의도한 대로 나오는지 보고 나서 apply로 넘어가는 게 안전하다.
3-3. apply: 실제 변경 적용
terraform apply- plan에서 계산한 변경 사항을 실제 인프라에 반영
- apply 후 결과를 다시 tfstate에 반영해 state를 최신으로 유지
정리
- Terraform은 인프라를 코드로 선언하고, state 기반으로 자동 관리하는 IaC 도구다.
- HCL로 리소스를 정의하고, provider를 통해 각종 클라우드/플랫폼과 연동한다.
terraform.tfstate가 현재 인프라 상태의 기준점이라서, 이 파일 관리가 매우 중요하다.- 기본 흐름은 항상 init → plan → apply로 기억해 두면 된다.
여기에 Git 버전 관리까지 얹으면 인프라도 “코드처럼” 깔끔하게 협업 관리가 가능해진다.
