부제: "yes/no 하나에 인프라 운명이 갈린다"
🐣 Intro
Terraform은 인프라 IaC의 구세주입니다.
terraform apply 한 방이면 서버, DB, 네트워크, 로드밸런서까지 전부 자동화 🚀
하지만…
가끔은 이 apply 버튼이
👉 서비스 킬 스위치처럼 느껴질 때가 있습니다.
오늘은 제가 직접 겪거나 들었던
Terraform apply 치다가 심장이 철렁한 순간들을 정리해봤습니다.
1️⃣ Production에서 terraform apply 눌렀을 때
개발 환경에서 하려고 했는데…
context를 안 바꿔서 prod workspace에서 실행! 😱
terraform apply
...
# aws_instance.prod will be destroyed👉 눈앞이 깜깜해졌다.
🙃 DevOps 엔지니어의 한마디:
"이거… 롤백 되죠?"
2️⃣ plan에서는 + create, apply는 - destroy
terraform plan에서는 리소스가 추가될 줄 알았는데,
막상 apply 하니 기존 리소스 삭제 후 재생성 😱
Load Balancer 교체 → 5분 다운타임 발생
Security Group 새로 생성 → 트래픽 차단
👉 plan은 항상 꼼꼼히 봐야 한다는 교훈
3️⃣ S3 버킷 force_destroy = true
테스트한다고 무심코 force_destroy = true 넣고 apply…
👉 운영 데이터 들어있던 버킷이 증발 😱
🙄 동료 한마디:
"백업은 있지…?"
"…없습니다"
4️⃣ VPC/Subnet 교체 시 전체 서버 증발
VPC를 갈아엎었더니…
해당 VPC에 붙어 있던 모든 리소스가 Cascade 삭제 😱
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
}VPC 교체 하나로 → DB, EC2, LB, NAT 전부 gone.
5️⃣ terraform destroy 치려다 Enter를 잘못…
테스트 환경에서 지우려고 했는데
커서 위치 잘못 잡아서 prod 리소스 날려버린 경우 😭
👉 Destroy는 진짜 무서운 친구다.
6️⃣ 잘못된 provider alias
멀티 계정 관리하다가 provider alias 설정을 잘못해서
dev에서 하려던 리소스가 prod에 생김 😱
비용 폭탄 💣
이상한 리소스들 cleanup하느라 반나절 날림
7️⃣ apply 도중 네트워크 끊김
적용 중에 노트북 와이파이가 끊김 → State file 꼬임.
👉 리소스 반쯤 생성된 상태에서 멈춤.
그 뒤로는 항상 remote backend + state lock 필수로 씀.
🛟 생존 전략
Terraform apply 때 멘탈을 지키려면:
plan 꼼꼼히 확인하기
terraform plan -out=tfplan
terraform show tfplan
workspace/environment 분리
dev, stage, prod 분리
context 안 바꾸면 apply 금지
state 관리 철저히
remote backend (S3 + DynamoDB lock, etcd 등)
state file 수동 편집 금지
DRY RUN 문화
PR/MR 리뷰에서 plan 출력 확인 필수
실험은 dev에서만
절대 prod에서 테스트 금지
🎬 마무리
Terraform은 강력하지만,
👉 한 번 잘못 apply하면 서비스가 통째로 날아갈 수도 있습니다.
오늘도 기억하세요:
"terraform apply는 인프라판 rm -rf /다"
(apply 한 번 눌렀을 뿐인데… 서비스가 증발했다)
