1) terraform init

역할: 작업 디렉토리 초기화, 프로바이더 플러그인 설치, 백엔드(S3 등) 설정.

주요 옵션

• -upgrade : 잠긴 버전 범위 안에서 플러그인 최신으로 갱신
• -reconfigure : 백엔드 설정 재구성(원격 상태 위치 바꿀 때)
• -migrate-state : 기존 상태를 새 백엔드로 이전
• -backend-config=FILE : 백엔드 값 외부 파일로 분리(예: backend.hcl)
• -lockfile=readonly : CI에서 잠금파일(.terraform.lock.hcl) 변경 금지

생기는 것
.terraform/ 디렉토리, .terraform.lock.hcl(프로바이더 버전 고정)

팁
백엔드 바꿀 때는 보통 init -reconfigure -migrate-state -backend-config=backend.hcl.

2) terraform validate

역할: HCL 문법/구성 검증(정적 체크). 리소스 실제 생성 X.

주요 옵션

• -json : 기계가 읽기 쉬운 결과(CI 리포팅용)
• -no-color : 컬러 제거(CI 로그용)

주의
validate는 변수 값이 실제로 유효한지(존재하는 AMI 등)까지 확인하진 않음. init 이후 실행해야 정확.

3) terraform plan

역할: 현재 상태↔코드 차이를 미리보기(무엇이 생성/변경/삭제될지).

주요 옵션

• -out=plan.bin : 검토한 계획을 파일로 저장(나중에 그대로 apply)
• -var 'k=v', -var-file=*.tfvars : 변수 주입
• -detailed-exitcode : 종료코드 차등(0=변경 없음, 2=변경 있음, 1=에러)
• -target=addr : 특정 리소스만(디버그·비상시에만 제한적으로)
• -refresh-only : 실제와 상태 동기화만(변경 적용 X)
• -replace=addr : 특정 리소스를 다시 만들기로 표시
• -parallelism=N : 병렬 작업 수 제한(디버그/속도 조절)

팁
CI에선 보통 plan -out + -detailed-exitcode로 변경 여부를 게이트에 사용.

4) terraform apply

역할: 계획을 실제 인프라에 적용하고 상태 갱신.

사용 패턴

• terraform apply plan.bin : 가장 안전(검토한 그대로 적용)
• terraform apply -auto-approve : 프롬프트 없이 바로 적용(CI에서만 권장)

유용 옵션

• -var, -var-file : 필요 시 직접 변수 주입
• -replace=addr, -target=addr : 특정 리소스 재생성/부분 적용(가급적 최소화)
• -parallelism=N : 동시 작업 수 조절
• -refresh-only : 실제 변경 없이 상태만 갱신
• (전면 삭제는 terraform destroy 사용 권장)

출력
성공 시 Outputs: 섹션 표시 + *.tfstate(또는 원격 백엔드) 업데이트.

실전 예시(서울 리전)

# 초기화(플러그인 설치, 백엔드 구성)
terraform init -upgrade

# 형식/검증
terraform validate

# 계획 생성(변수 파일 반영) + 변경 여부를 종료코드로 판단
terraform plan -var-file=dev.tfvars -out=plan.bin -detailed-exitcode

# 사람/PR에서 검토 후, 그대로 적용
terraform apply plan.bin

원격 상태(S3 + DynamoDB 락) 초기화 예시

backend.hcl:

bucket         = "my-tf-state-bucket"
key            = "projectA/terraform.tfstate"
region         = "ap-northeast-2"
dynamodb_table = "tf-lock"
encrypt        = true

명령:

terraform init -reconfigure -migrate-state -backend-config=backend.hcl

체크리스트

• init 안 함 → validate/plan에서 “프로바이더 없음” 에러
• 백엔드 변경 후 상태 미이전 → 리소스 이중 생성 위험 → -migrate-state 필수
• -target 남용 → 의존성 깨짐·드리프트 유발 → 진단용 최소 사용
• -auto-approve를 로컬에서 사용 → 오타로 대형 변경 적용 위험
• state를 깃에 커밋 → 절대 금지(.gitignore에 *.tfstate, .terraform/ 등 포함)