terraform plan # 확인
terraform apply # 코드와 실제 상태 일치시킴
전략 B: 인프라를 코드 기준으로 되돌리기 (드리프트 제거)
무단 변경이라면 apply로 코드 기준 상태로 되돌린다.
# 코드는 수정하지 않고 그대로 apply
terraform apply
# → 8080 규칙이 제거되고 코드 상태로 복원
드리프트 시나리오에서 apply 권장 시점 정리
✅ terraform plan -refresh-only로 드리프트 범위 파악 후
✅ 드리프트가 의도된 것인지 무단 변경인지 판단 후
✅ 전략 A(코드 업데이트) 또는 전략 B(원상복구) 결정 후
❌ 드리프트 원인도 모른 채 무작정 apply하면 안 됨
⚠️ 주의사항: apply 전 반드시 확인할 것들
1. plan 없는 apply는 사고의 지름길
# ❌ 절대 금지 패턴
terraform apply -auto-approve
CI/CD 자동화에서도 plan 결과를 사람이 검토하는 단계를 반드시 넣어야 한다.
2. State 파일은 절대 수동으로 편집하지 말 것
드리프트가 발생했다고 해서 .tfstate 파일을 직접 수정하면 더 큰 문제가 생긴다. 반드시 terraform state 명령어를 사용한다.
# 특정 리소스를 State에서 제거 (인프라는 유지)
terraform state rm aws_s3_bucket.old_bucket
# State에서 리소스 목록 확인
terraform state list
3. 원격 State 사용은 선택이 아닌 필수
팀 환경에서 로컬 State를 쓰면 드리프트와 충돌이 일상이 된다.
# S3 + DynamoDB로 원격 State 구성
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "prod/terraform.tfstate"
region = "ap-northeast-2"
dynamodb_table = "terraform-lock"
encrypt = true
}
}
4. 프로덕션에서는 target 플래그 사용을 최소화
# ⚠️ 긴급 상황이 아니면 피할 것
terraform apply -target=aws_instance.web
특정 리소스만 골라서 apply하면 의존 관계가 꼬일 수 있다.
✅ 정리: 마이그레이션 vs 드리프트, 뭐가 다른가?
구분 마이그레이션 드리프트 수정
구분
마이그레이션
드리프트 수정
상황
기존 인프라를 Terraform으로 편입
관리 중 인프라가 외부에서 변경됨
State 상태
해당 리소스 State 없음
State와 실제 인프라 불일치
apply 전 작업
terraform import 또는 import 블록
terraform plan -refresh-only
apply 목적
코드와 State 동기화
코드 기준 복원 또는 코드 업데이트 후 동기화
위험도
높음 (잘못하면 삭제/재생성)
중간 (의도치 않은 변경 적용 가능)
결론: 둘 다 apply를 쓴다. 하지만 절차가 다르다.
terraform apply는 도구일 뿐이다. 마이그레이션이든 드리프트 수정이든, 핵심은 apply 전에 plan을 보고, 어떤 변경이 일어나는지 이해한 상태에서 실행하는 것이다. Terraform의 진짜 위력은 apply 명령 한 줄이 아니라, 그 전에 수행하는 plan과 refresh에서 나온다.
