콘솔에서 클릭으로 만든 인프라는 한 번은 빠르지만, 두 번째부터 문제가 됩니다. "스테이징과 운영을 똑같이 만들어 줘"라거나 "이거 누가 보안 그룹 포트 열었어?"라는 순간, 클릭 기록은 남지 않습니다. Terraform은 인프라를 **코드(IaC, Infrastructure as Code)**로 적어두고, 그 코드를 그대로 클라우드에 반영하는 도구입니다. 같은 코드를 두 번 실행하면 같은 결과가 나오고, 변경 이력은 Git에 남습니다.
핵심 개념 3가지
| 개념 | 역할 | 비유 |
|---|---|---|
| Provider | AWS·GCP 등 어떤 클라우드와 통신할지 | 콘센트 규격(어느 나라 플러그) |
| Resource | 실제로 만들 대상(VPC, EC2, 버킷 등) | 설계 도면의 각 부품 |
| State | 지금 실제로 뭐가 만들어졌는지 기록 | 현재 시공 상태 대장 |
가장 헷갈리는 것이 state입니다. Terraform은 코드(원하는 상태)와 state 파일(현재 상태)을 비교해, 그 차이만 클라우드에 반영합니다. 그래서 state가 실제와 어긋나면 엉뚱한 변경이 일어납니다.
가장 작은 예시
S3 버킷 하나를 코드로 정의해 보겠습니다.
HCL
provider "aws" {
region = "ap-northeast-2"
}
resource "aws_s3_bucket" "logs" {
bucket = "my-app-logs-2026"
}
실행 흐름은 항상 세 단계입니다.
로컬 터미널
terraform init # provider 플러그인 다운로드
terraform plan # 무엇이 바뀔지 미리 보기 (실제 변경 없음)
terraform apply # 실제로 클라우드에 반영
plan이 핵심입니다. + create, ~ update, - destroy로 변경 내용을 미리 보여주므로, apply 전에 plan 출력을 읽는 습관이 사고를 막습니다.
입문자가 자주 밟는 함정
- state 파일을 로컬에만 둔다 — 혼자면 괜찮지만, 팀이면 서로 다른 state로 충돌합니다. S3 + DynamoDB 같은 원격 백엔드로 state를 공유하고 잠금(lock)을 겁니다.
- 콘솔에서 손으로 고친다 — 코드 밖에서 바꾼 변경은 다음
plan에서 "되돌리겠다"고 나옵니다(drift). 변경은 코드로만. - 하드코딩 — 리전·이름을 박아두면 재사용이 안 됩니다.
variable로 빼고 환경별로 값을 주입합니다.
요점 정리
- Terraform은 인프라를 코드로 적고
init → plan → apply로 반영한다. - provider(어디에)·resource(무엇을)·state(현재 상태) 세 축으로 이해한다.
- apply 전
plan을 반드시 읽고, state는 원격으로 공유하며, 변경은 코드로만 한다.
provider 설정부터 plan/apply, state 관리까지 직접 손으로 따라 하는 실습은 클라우드 트랙에서 회원가입 없이 무료로 시작할 수 있습니다.